🥇Уточняваме описанието на функциите на системата с помощта на диаграма 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) Спецификация. Версия 2.5.1. [Електронен ресурс] Достъп: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF

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