Главная страница « Информация « ООАП «

Требования к отчету по 2-му заданию по ООАП (МАППО). 2019-20 учебный год


Оформление отчёта не является необходимым, но если Вы выполните его, то сможете получить за это дополнительные технические баллы по курсу. Для оформления отчёта не устанавливаются контрольные сроки сдачи и не начисляются штрафы за просрочку. Если в оформлении отчёта обнаруживаются дефекты или если текст отчёта не является полным, то он может быть зачтён не на частичную сумму баллов. Полная сумма баллов за оформленный отчёт -- 10.

Отчет пишется на русском языке, предоставляется в электронном виде преподавателю (верстка в формат А4, "портрет", pdf, doc или odt).

Отчет состоит из следующих частей:

Титульный лист, с «шапкой» – «Московский государственный университет имени М. В. Ломоносова, факультет Вычислительной математики и кибернетики». Далее следует заголовок: «Отчёт по объектно-ориентированному анализу», тема задания, сведения об исполнителе (фамилия, имя и отчество полностью, номер группы) и преподавателе, принявшем задание. Внизу титульного листа указывается город и год. Нелишне обратить внимание на то, что точки после заголовков не ставятся.


Содержание состоит из перечня названий глав и подглав, сопровождаемых указанием номеров страниц, с которых они начинаются. Нумеруются все страницы, за исключением титульного листа. Номер страницы с содержанием: 2.


Первая глава, названная «Постановка задачи» содержит формулировку задания. Каждую главу следует начинать с новой страницы.


Вторая глава, названная «Определение требований» содержит глоссарий, UML-диаграмму вариантов использования, описания действующих лиц и ключевых вариантов использования. Для одного из ключевых вариантов использования приводится UML-диаграмма деятельности. Все приводимые в отчёте диаграммы должны быть свёрстаны так, чтобы текст на них был читаемым, и чтобы можно было составить полное впечатление о диаграмме. Если диаграмма не помещается на странице, то следует либо изменить её в среде VP, либо опять таки в среде VP разбить её на части (используя ref-блоки и тому подобные средства языка UML).


Третья глава, названная «Анализ вариантов использования» содержит UML-диаграмму классов Key Abstractions, UML-диаграммы последовательности, описывающие взаимодействия между объектами в рамках потоков событий трёх ключевых вариантов использования, UML-диаграммы классов VOPC трёх ключевых ВИ. UML-диаграммы следует сопроводить пояснениями, указывающими, какому потоку событий они соответствуют (если это не ясно из их названия), и комментариями об объектах (классах), присутствующих на диаграммах. Приводимые в отчёте UML-диаграммы должны быть обозримыми и читаемыми. См. замечание выше.


Четвёртая глава, названная «Проектирование архитектуры системы» содержит UML-диаграмму с указанием уровней системы, перечень пакетов и подсистем с указанием их назначения, UML-диаграммы пакетов для уровней, состоящих из более чем одного пакета. Также приводится UML-диаграмма размещения с пояснениями о каждом узле на ней. Для встроенных систем (варианты со словом «терминал» в названии, вариант «Турникет», вариант «Пиццамат») диаграмма размещения должна изображать связи между процессором и устройствами, а также узлами внешних систем. В остальных вариантах диаграмма размещения показывает узлы вычислительной среды системы, узлы внешних систем, связи между ними и размещение процессов разрабатываемой системы по узлам. Приводимые в отчёте UML-диаграммы должны быть обозримыми и читаемыми. См. замечание выше.

Пятая глава, названная «Проектирование элементов системы» содержит описания проектных классов системы (всех ключевых абстракций и всех классов, участвующих в смоделированых реализациях вариантов использования), сгруппированных по пакетам. Сведения о классе включают в себя: краткое описание – ответственность класса; описание атрибутов и операций в виде таблицы из 2-х столбцов: полная сигнатура атрибута или операции, его или её назначение. Допускается не приводить описание тривиальных описаний как-то геттеров, сеттеров, конструкторов. Также приводятся UML-диаграммы проектных классов системы, отображающие связи между классами, диаграммы состояний (не менее 1), описывающие поведение экземпляров отдельных классов (как правило, классов-контроллеров или классов-сущностей), и диаграммы деятельности (не менее 1), моделирующие реализации нетривиальных операций классов. Нетривиальной считается реализация с логическим ветвлением потока и циклом. Для одной смоделированной подсистемы приводится описание её интерфейса (полные сигнатуры операций и описания), диаграмма классов подсистемы (вид подсистемы изнутри) и диаграммы последовательности, описывающие реализацию операций интерфейса подсистемы (достаточно описать 3-4 реализации разнородных операций, если в интерфейсе их больше). Во всех вариантах в отчёт должна быть обязательно включена UML-диаграмма классов, моделирующая схему БД. Приводимые в отчёте UML-диаграммы должны быть обозримыми и читаемыми. См. замечание выше.


• Если выполнялось моделирование дополнительных ВИ (дополнительной подсистемы), то сведения о нём могут быть включены в отчёт по усмотрению исполнителя задания. Если сведения будут включены, то могут быть начислены дополнительные баллы за это.


Заключение (оно не нумеруется), в котором подводится общий итог работы, завершает отчёт. В заключении можно указать характеристики трудоёмкости созданной модели: общее количество вариантов использования; количество проектных классов и подсистем; количество UML-диаграмм разных видов.

Предупреждение


Размещение на других ресурсах, а также коммерческое использование материалов, опубликованных в данном разделе, возможно только с разрешения авторов. По всем вопросам пишите:   

  

© Кафедра системного программирования ВМК МГУ.

Обновлено: 19.XII.2019