Уточнюємо опис функцій системи за допомогою діаграми Sequence (продовження "Білки")
У статті розглянемо, як можна деталізувати (уточнити) опис автоматизованої функції з допомогою UML Sequence Diagram — діаграми послідовності.
У цьому прикладі я використовую середовище Enterprise Architect від австралійської компанії [1].
Повну специфікацію UML див. [2].
Для початку поясню, що ми деталізуватимемо.
В ми моделювали процеси «казкової» предметної області - рядки про білку з «Казки про царя Салтана» А.С.Пушкіна. І розпочали ми з діаграми Activity. Потім у ми розробили функціональну модель за допомогою діаграми Use-case, на малюнку 1 представлений фрагмент.
Малюнок 1. Зв'язок вимоги та функції
Тепер ми хочемо уточнити інформацію про виконання цієї функції, що автоматизується:
- з якими компонентами інтерфейсу взаємодіятиме наш користувач;
- які керуючі компоненти нам знадобляться;
- що ми зберігатимемо;
- якими повідомленнями обмінюватимуться користувач та компоненти системи для виконання функції.
Основними елементами діаграми Sequence є об'єкти, що взаємодіють, з різними стереотипами і зв'язки між ними — взаємодіючі об'єкти обмінюються між собою деякою інформацією (Малюнок 2).
Рисунок 2. Основні елементи Sequence діаграми
Об'єкти розташовані у горизонтальній послідовності, між ними передаються повідомлення. Вісь часу орієнтована зверху донизу.
Елемент Actor може бути використаний для подання користувача, що ініціює потік подій.
Кожен об'єкт має пунктирну лінію, яка називається «лінією життя», де цей елемент існує і потенційно бере участь у взаємодіях. Фокус управління позначається прямокутником лінії життя об'єкта.
Повідомлення, якими обмінюються об'єкти, можуть бути декількох типів, повідомлення також можуть бути налаштовані для відображення операцій та властивостей вихідного та цільового елементів.
Стереотипні елементи, такі як межі (Boundary), елементи управління (Control) та сутності (Entity), можуть використовуватися для моделювання інтерфейсу користувача (GUI), контролерів і елементів бази даних, відповідно.
Потік обміну повідомленнями, що повторюється, може бути позначений як фрагмент з типом «loop».
Отже, ми плануємо уточнити опис функції «Додати інформацію інформацію про новий горіх».
Домовимося про наступні додаткові узагальнення та припущення.
- Горіх, ядро і шкаралупки — це матеріальні цінності відповідних типів (Малюнок 3).
Рисунок 3. Уточнення діаграми класів - До відома наш користувач вноситиме інформацію про будь-які матеріальні цінності.
- Уточнимо назву відомості — «Відомість обліку мат.цінностей».
- Припустимо, що наш користувач, працюючи з GUI «Відомість обліку мат.цінностей», може додати нову мат.цінність через GUI «Картка обліку мат.цінності».
- Залежно від типу мат.цінності змінюється структура даних та GUI.
- При заповненні полів картки обліку мат.цінності відбувається перевірка коректності введених даних.
p align="justify"> Діаграма, побудована з урахуванням цих припущень, наведена на Малюнку 4.
Рисунок 4. Уточнення опису функції «Додати у відомість інформацію про новий горіх»
Про застосування інших видів діаграм UML можна прочитати тут:
Список джерел
- Сайт Sparx Systems. [Електронний ресурс] Режим доступу: Веб:
- OMG Unified Modeling Language (OMG UML) Спеціалізація. Version 2.5.1. [Електронний ресурс] Режим доступу: Веб:
Джерело: habr.com