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

Требования к отчету по 2-му заданию по ООАП/МАППО в группах 528, 620, 623, 627. 2021-22 учебный год


Составление и сдача отчёта могут быть выполнены по желанию для получения дополнительных баллов. Отчёты присланные позднее чем за сутки до дня закрытия экзаменационной ведомости не приносят баллов. Отчёт покрывает те этапы, которые Вы успели выполнить. Если какой-то из этапов не был выполнен, тогда текст соответствующей части отчёта имеет вид: Этап № ... не выполнен.

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

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

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


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


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


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


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


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

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


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


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

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


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

  

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

Обновлено: 14.X.2021