Диаграммы классов

Цели и задачи

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

Концептуальная модель

Составьте словарь предметной области по материалам ЛР 2, спецификации варианта использования и процессу из ЛР 4. Для каждого значимого термина зафиксируйте определение, синонимы, источник, связанные правила и сценарии. Выделите кандидаты в классы из текстов — например, методом Аббота — и кратко объясните, почему каждый выбранный кандидат остаётся в модели или исключается.

Постройте концептуальную диаграмму классов. Она описывает понятия предметной области, а не таблицы, контроллеры, API и классы реализации. Покажите:

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

Не добавляйте агрегацию, композицию, навигацию или свойства полюсов ради полноты нотации. Композиция уместна лишь при жизненной зависимости части от целого; навигация — когда направление ответственности действительно важно.

Техническая модель и архитектурное решение

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

1. Короткий ADR: контекст, выбранное решение, альтернативы и последствия.
2. Техническую диаграмму классов с классами и интерфейсами, необходимыми для реализации выбранного сценария; атрибуты и операции здесь должны быть достаточно конкретны для реализации. Каждый технический класс и интерфейс отнесите к пакету или слою из следующего пункта: поместите его в пространство имён пакета либо используйте квалифицированное имя.
3. Диаграмму пакетов или слоёв с назначением каждого пакета и направлением зависимостей. Трёхслойная архитектура допустима, но не обязательна: выберите структуру, которую обосновывают требования и ADR. Не дублируйте на этой обзорной диаграмме классы и интерфейсы: она показывает крупную структуру и допустимые зависимости.
4. Диаграмму компонентов с ответственностями и предоставляемыми или требуемыми интерфейсами. Зафиксируйте владельца значимых данных и тип информационного потока между компонентами или внешними системами.

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

Оценивание

Максимум за эту лабораторную работу — 14 баллов. За что снимаются баллы:

• отсутствуют словарь, концептуальная или техническая модель, ADR, диаграмма пакетов/слоёв либо диаграмма компонентов;
• концептуальная модель смешана с реализацией или не проверена примерами объектов;
• технические классы и интерфейсы не отнесены к пакетам или слоям, либо общая диаграмма пакетов дублирует их вместо показа структуры и зависимостей;
• техническая структура, потоки данных или зависимости не обоснованы требованиями и сценариями;
• несоблюдение нотации и методических рекомендаций, нечитаемая вёрстка, некорректное оформление отчёта, неподходящее ПО или сдача после дедлайна.

Методические рекомендации

• Ассоциация выражает значимую связь в модели; не дублируйте её атрибутом без причины и не добавляйте связь только потому, что классы «похожи».
• Реализацию интерфейса, включая lollipop-нотацию, используйте в технической модели, когда интерфейс — реальный контракт компонентов или классов.
• У агрегации и композиции ромб допускается только на одном конце ассоциации. Слабая агрегация не нужна, если её смысл неотличим от обычной ассоциации.
• Большую концептуальную модель можно разбить на предметные пакеты; не подменяйте ими архитектурные слои реализации.