Диаграммы состояний и последовательности

Цели и задачи

В этой лабораторной работе свяжите жизненный цикл предметного объекта и взаимодействие участников при выполнении сценария.

Диаграмма состояний

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

Состояние должно выражать устойчивое условие объекта. Подписывайте значимые переходы в форме триггер [guard] / effect: событие, guard и effect указывайте только когда они несут смысл. Guard должен выражать проверяемое бизнес-правило, а не повторять название перехода. Покажите хотя бы один недопустимый или заблокированный переход через отсутствие допустимого пути либо явно сформулированное ограничение.

Согласуйте диаграмму с концептуальной моделью: объект, его данные, правила и события должны быть известны в словаре и связанных моделях. Если при этом появилось новое предметное понятие или правило, обновите ЛР 5.

Диаграмма последовательности

Опишите на sequence-диаграмме тот же сценарий или логически связную его часть, которую ранее показала activity-диаграмма. Участниками могут быть акторы, внешние системы и экземпляры технических классов или компонентов из ЛР 5. Сообщения должны выражать вызовы, события или передачу данных; возвращаемое значение показывайте, когда оно существенно для дальнейшего поведения.

Порядок сообщений задаётся вертикальной осью, поэтому сквозная нумерация необязательна (но желательна). Используйте alt, opt, loop и другие комбинированные фрагменты только для реальных альтернатив, условий и повторений сценария. Отметьте синхронность или асинхронность сообщения, если от этого зависит поведение или надёжность системы.

В отчёте кратко укажите трассировку: требование и правило → вариант использования → activity-диаграмма → классы/компоненты → state или sequence.

Оценивание

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

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

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

• Не путайте жизненный цикл объекта с протокольным автоматом. В этой работе нужен жизненный цикл; протокольный автомат описывает допустимую последовательность вызовов потребителя интерфейса.
• Для значимого перехода назовите событие или причину. entry, do и exit относятся к состоянию, а не к переходу.
• Асинхронное сообщение показывает, что отправитель не ждёт завершения обработки. Оно не означает автоматически немедленную доставку пользователю.
• Соедините фрагменты выполнения на линии жизни только в соответствии с синхронным вызовом; визуальная настройка Visual Paradigm не должна менять смысл взаимодействия.