Уточняем описание функций системы с помощью диаграммы Sequence

Уточняем описание функций системы с помощью диаграммы Sequence (продолжение «Белки»)

В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].

Для начала поясню, что мы будем детализировать.
В 1-ой части статьи «От моделирования процессов к проектированию автоматизированной системы» мы моделировали процессы «сказочной» предметной области — строчки про белку из «Сказки о царе Салтане» А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.

Рисунок 1. Связь требования и функции

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

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

Основными элементами диаграммы Sequence являются взаимодействующие объекты с различными стереотипами и связи между ними — взаимодействующие объекты обмениваются между собой некоторой информацией (Рисунок 2).

Рисунок 2. Основные элементы Sequence диаграммы

Объекты расположены в горизонтальной последовательности, между ними передаются сообщения. Ось времени ориентирована сверху вниз.
Элемент Actor может использоваться для представления пользователя, инициирующего поток событий.
Каждый объект имеет пунктирную линию, называемую «линией жизни», где этот элемент существует и потенциально принимает участие во взаимодействиях. Фокус управления обозначается прямоугольником на линии жизни объекта.
Сообщения, которыми обмениваются объекты, могут быть нескольких типов, сообщения также могут быть настроены для отражения операций и свойств исходного и целевого элементов.
Стереотипные элементы, такие как границы (Boundary), элементы управления (Control) и сущности (Entity), могут использоваться для моделирования пользовательского интерфейса (GUI), контроллеров и элементов базы данных, соответственно.
Повторяющийся поток обмена сообщениями может быть обозначен как фрагмент с типом «loop».

Итак, мы планируем уточнить описание функции «Добавить в ведомость информацию о новом орехе».
Договоримся о следующих дополнительных обобщениях и допущениях.

1. Орех, ядро и скорлупки — это все материальные ценности соответствующих типов (Рисунок 3).
   
   Рисунок 3. Уточнение диаграммы классов
2. В ведомость наш пользователь будет вносить информацию о любых материальных ценностях.
3. Уточним название ведомости — «Ведомость учета мат.ценностей».
4. Допустим, что наш пользователь, работая с GUI «Ведомость учета мат.ценностей», может добавить новую мат.ценность через GUI «Карточка учета мат.ценности».
5. В зависимости от типа мат.ценности меняется структура данных и GUI.
6. При заполнении полей карточки учета мат.ценности происходит проверка корректности введенных данных.

Диаграмма, построенная с учетом этих допущений, приведена на Рисунке 4.

Рисунок 4. Уточнение описания функции «Добавить в ведомость информацию о новом орехе»

О применении других видов диаграмм UML можно почитать здесь:

• От моделирования процессов к проектированию автоматизированной системы (Часть 1);
• От моделирования процессов к проектированию автоматизированной системы (Часть 2);
• Два подхода к структурированию диаграммы Activity.

Список источников

1. Сайт Sparx Systems. [Электронный ресурс] Режим доступа: Интернет: https://sparxsystems.com
2. OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Электронный ресурс] Режим доступа: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF

Источник: habr.com