====== Учебный проект ======

Учебный проект выполняется командой в составе 2-4 человек.

Проект должен быть оформлен в виде архива с именем <№ группы>-<Проект>-<Фамилия1Фамилия2Фамилия3>.zip (пример 093-ИнПлан-ИвановСидоров.zip) включающий:
  - Файл PDF или DOC (.doc, .odt) с описанием проекта: постановка задачи, диаграммы, текст вариантов использования, обоснование, артефакты
  - Папка с проектом реализованным в среде моделирования

Проект присылается **один** раз. Он может быть возвращен на доработку, если имеются ошибки в оформлении. Частично выполненные проекты, по которым спрашиваются комментарии, будут рассматриваться как завершенные. Вопросы можно задавать, но конкретные (а не вида "какие у нас здесь ошибки, мы исправим и пришлем?"), в том числе на семинарах.


==== Задание 1 ====

Шаблон задания доступен {{::pps-report-analysis-20121002.doc| здесь}}.

Задание включает:
  - Модель анализа - диаграммы вариантов использования, диаграммы классов, схемы состояний.
  - Описание ключевых вариантов использования в текстовом виде (4-6 штук) и в виде деятельности.
  - Артефакты разработки (допустимо фотографии с бумаги): списки потенциальных классов, карточки CRC, промежуточные варианты диаграмм

Также необходимо обосновать представленную модель, то есть почему получены именно такие классы, почему важен тот или иной вариант использования, почему необходимо моделировать данную ассоциацию и т.п.

** Описание поведения **

При описании поведения объектов предметной области действия, выполняемые акторами в сценариях вариантов использования, должны быть согласованы с действиями в деятельности, описывающей данный вариант использования, а также с операциями, назначенными классам.

Жизненный цикл объектов предметной области, при необходимости, описывается схемами состояний (например, экземпляры класса Заказ). Переходы в схемах состояний должны быть согласованы с изменениями состояний объектов, участвующих в деятельности / сценариях вариантов использования.

** Сдача задания **

Сдача задания происходит на семинаре, артефакты на бумажном носителе можно не прикладывать, а принести с собой. 

**Задержка отправки задания приводит к снижению оценки на 0.5 балла каждые 3 дня**


==== Задание 2 ====


Шаблон задания доступен {{::pps-report-design-20121020.doc | здесь}}.

Суть второго задания состоит в реализации модели задания №1 на выбранной платформе. Платформа включает в себя набор классов, реализующий функции доступа к базам данных, коммуникации по сети, рисование пользовательского интерфейса и решающие другие вспомогательные задачи. Для каждого проекта классы, входящие в платформу оговариваются отдельно. Обратитесь к своему семинаристу для согласования списка классов платформы реализации.

Задание включает:
  - Задание 1 (модель анализа, описание вариантов использования, диаграммы, обоснование)
  - Модель реализации - диаграммы вариантов использования, диаграммы классов
  - Интерпретация ключевых взаимодействий/конечных автоматов динамической модели (2-3 штуки)
  - Обоснование применения шаблонов проектирования и других проектировочных решений

Модель реализации должна включать **отдельную** диаграмму (или несколько, если требуется) классов (или внутренней структуры), на которой описано, каким образом реализована модель предметной области, используя библиотеки и классы выбранной платформы.

Отдельное внимание следует уделить моделированию поведения. Лучшим кандидатом для моделирования является описание реализации ключевых вариантов использования с помощью взаимодействий, схем состояний или деятельности. Одним из ключевых результатов является разработка **согласованных** статической и динамической моделей (то есть если при описании взаимодействия мы вызываем метод принять() у класса А, он должен быть в статической модели).

В дополнение к первому заданию, второе должно включать:

  - описания основного и альтернативных сценариев в каждом варианте использования
  - диаграмма классов реализации, в том числе их взаимодействия с платформой / выбранным каркасом
  - (при необходимости) диаграммы конечных автоматов для описания жизненного цикла классов реализации
  - диаграммы кооперации и для каждой из них описание взаимодействия, описывающее реализацию сценариев данного варианта использования
  - диаграммы деятельности для демонстрации основных сценариев вариантов использования (актеры и boundary классы).
 
Каждая объявленная или использованная (в пунктах 1-5) операция,  должна быть реализована. То есть для нее должен быть  создан метод, реализующий алгоритм на псевдоязыке или скриптом (напр. JavaScript, Groovy, ...), или представлена диаграмма деятельности. При этом операции классов и интерфейсов платформы реализовывать не нужно.

Рекомендуется применять паттерны проектирования. Их обоснованное использование дает дополнительные плюсы при проверке задания.

Сдача задания происходит на семинаре в виде презентации, артефакты на бумажном носителе можно не прикладывать, а принести с собой. 


**Примечание**
Перед отправкой проверьте, что Вы можете ответить положительно на следующие вопросы по проекту:
  - Реализованы 2-3 варианта использования: имеются необходимые диаграммы, для всех операций либо есть метод (opaqueBehavior) на псевдоязыке, либо деятельность, либо это операция платформы.
  - Проект успешного проходит валидацию в MagicDraw по simulationProfile (ТОДО). 
  - Отчет по проекту оформлен в виде курсовой работы: титульный лист, оглавление, содержательная часть, заключение
  - Вы прочитали и поняли требования к структуре и содержанию второго задания
  - Вы изучили пример {{::pps.spring2011-theater.zip| Театральная касса}}

==== Задание 2+ ====

В учебном году 2016 ранее дополнительное задание становится обязательным. Вместе с моделью реализации должен быть предоставлен прототип реализации.

=== План тестирования ===

В виду того, что курс по тестированию читается параллельно с данным курсом, при сдаче данного задания нужно также подготовить план тестирования для выявления возможных несоответствий реализации требованиям, сформулированным в задании 1. 

План тестирования указывает реализованные и проверяемые варианты использования и тест кейсы для них. Формат:

Описание конфигурации системы (заголовок 2 уровня)
Дать инструкции предварительной настройке и какой файл запустить.
Укзать, что является объектом тестирования.

Название варианта использования (заголовок 2 уровня)

Таблица с тестами

^#^Действие актора^Ожидаемый результат^Соответствие^
|1. <Проверить основной сценарий>||||
|1.1|Актор нажимает кнопку|Система показывает окно|<номер шага в варианте использования>|
|1.2|Актор вводит значние "Привет" и нажимает |Система обновляет окно и показывает "Привет" в поле А|<номер шага в варианте использования>|
|2. <Название теста>||||
|2.1|Актор нажимает кнопку|Система показывает окно|<номер шага в варианте использования>|
|2.2|...|...|

=== Вариант 1. Исполняемая модель (экспериментальное задание) ===

Один из двух возможных вариантов реализации данного задания. 

Задание состоит в детализации модели до уровня, когда она может быть исполнена (на выбор)
  * Cameo Simulation Toolkit
  * BridgePoint (https://xtuml.org/) или Papyrus xtUML (https://projects.eclipse.org/proposals/papyrus-xtuml)
  * Papyrus RT (https://www.eclipse.org/papyrus-rt/)

Задание включает реализацию 1-2 сценариев вариантов использования, указанных в плане тестирования:
  - поведение (деятельность или конечный автомат), описывающее действия системы и актеров (взаимодействие с пользовательскими интерфейсами)
  - реализация использованных операций граничных классов ("веб-страниц")
  - реализация вызываемых операций классов предметной области

Проверяющее поведение в пункте 1 может быть заменено пользовательским интерфейсом.

Пример исполняемой модели для Cameo Simulation Toolkit: {{::software_design-example-simtoolkit.zip|Секундомер}} на конечных автоматах.

=== Вариант 2. Реализация в исходных кодах ===

Задание состоит в реализации модели на языке программирования и создании работающего прототипа.

Задание включает реализацию 1-2 сценариев вариантов использования, указанных в плане тестирования.

Требование к реализации (предварительно):
  * Запускается и проходит smoke-test
  * Отсутствуют серьезные расхождения с планом тестирования

Типовые нефункциональные требования:
  * Реализация выполняется не только на компьютерах участников команды проекта