🥇Уточняваме описанието на функциите на системата с помощта на диаграмата 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».

Следователно, планираме да уточним описанието на функцията «Добави в ведомост информация за новия орех».
Да се споразумеем за следните допълнителни обобщения и предположения.

Орех, ядро и черупки — това са всички материални стойности на съответните типове (Рисунок 3).

Рисунок 3. Уточнение на диаграмата на класовете
В ведомостта нашият потребител ще въвежда информация за всякакви материални стойности.
Нека уточним името на ведомостта — «Ведомост за отчитане на материални стойности».
Да предположим, че нашият потребител, работейки с GUI «Ведомост за отчитане на материални стойности», може да добави нова материална стойност през GUI «Карточка за отчитане на материална стойност».
В зависимост от типа на материалната стойност, структурата на данните и GUI варират.
При попълване на полетата в карточката за отчитане на материалната стойност се извършва проверка на коректността на въведените данни.

Диаграмата, изградена с оглед на тези предположения, е показана на Рисунок 4.

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

За приложението на други видове диаграми UML можете да прочетете тук:

Списък с източници

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

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