Типовий хід подій

Прецедент подає взаємодію між користувачем і системою і відображає уявлення користувача про поведінку системи, не визначаючи її реалізації. Відповідно, прецедент не реалізується напряму в програмному коді, його поведінка реалізується у вигляді класів і компонентів (Рис.2.3). Прецедент містить функціональні вимоги щодо проектованої системи загалом

Таблиця.2.2. Виконавець-система

Дії виконавця	Відгук системи
Завдання об’єкта будівництва
Завдання опису об’єкта	Внесення в БД характеристик об’єкта
Опис топології СМ	Внесення БД термінів робіт
Опис робіт СМ	Визначення в БД опису робіт
Опис потреби в часі	Введення термінів за типом та побудова графіку
Виведення результату	Підсумування результатів та завершення роботи з БД

Кожен прецедент повинен мати назву, що відповідає його призначенню і відрізняє цей прецедент від інших. Назва прецеденту має бути унікальною всередині пакета. В IBM Rational Rose назва прецеденту — це текстовий рядок, що складається з довільної кількості літер, цифр і деяких розділових знаків за винятком двокрапки, що відокремлює назву прецеденту від назви пакета. На практиці для пойменування прецедентів використовують стислі фрази з дієсловами або віддієслівними іменниками, що позначають деяку поведінку і використовуються у предметній області проектованої ІС. Текст починається з великої літери.

На діаграмі прецедент зображується овалом Прецедент, усередині якого стоїть його назва.

При визначенні прецедентів часто виникають проблеми, пов’язані з вибором рівня їх деталізації. Рекомендацією є включення до окремого прецеденту окремого елемента функціональності, що здійснюється від початку до кінця і приносить значущий для актора результат. Водночас різні дії, що ініціюються одним актором і виконуються з однією сутністю, наприклад, введення, коригування та знищення даних у певному довіднику, також доцільно об’єднати в один прецедент. Модель типової системи зазвичай містить від 20 до 50 прецедентів.

В IBM Rational Rose варіантам використання можуть бути присвоєні пріоритети (ранги), що визначатимуть порядок, у якому слід працювати над ними.

До окремого прецеденту діаграми можна прикріпити файл з описом потоку подій, сценаріїв, специфікацій вимог або іншими документами з приблизними прототипами цього варіанта використання. Також може бути прикріплене посилання на Webсторінку.

Актор (діюча особа) — це зовнішня стосовно ІС сутність, яка може взаємодіяти з системою. Акторами можуть бути люди, зовнішні ІС або пристрої. При цьому актор — це не конкретна особа чи пристрій, а логічно пов’язана між собою множина ролей, що їх відіграють користувачі прецедентів під час взаємодії з ними. Наприклад, як актор «Бухгалтер» може виступати весь штат бухгалтерії. Водночас одна особа може відігравати кілька ролей стосовно системи. Головний бухгалтер може виступати як актор з таким іменем, але може використовувати систему і як актор «бухгалтер». Кожен актор може використовувати систему по-різному, тобто ініціювати виконання різних прецедентів.

На основі таблиці прецедентів (Табл.2.1, табл..2.2.) будуємо UML- діаграму, де показуємо зв’язки та взаємодію між виконавцем та системою

Опис роботи

Затвердження змін

Розрахунок термінів

Побудова графіка

Рис.2.3. UML-діаграма «Побудова інформаційної платформи»

Суть даної діаграми полягає в наступному: проектована система представляється у вигляді безлічі сутностей чи акторів, що взаємодіють із системою за допомогою так званих варіантів використання. Варіант використання використовують для описання послуг, які система надає актору. Іншими словами, кожен варіант використання визначає деякий набір дій, який виконує система при діалозі з актором. При цьому нічого не говориться про те, яким чином буде реалізована взаємодія акторів із системою.

У мові UML є кілька стандартних видів відношень між акторами і варіантами використання:

• асоціації ;

• включення ;

• розширення ;

• узагальнення ;

При цьому загальні властивості варіантів використання можуть бути представлені трьома різними способами, а саме — за допомогою відношень включення, розширення і узагальнення.

Відношення асоціації — одне з фундаментальних понять у мові UML і в тій чи іншій мірі використовується при побудові всіх графічних моделей систем у формі канонічних діаграм.

Включення у мові UML — це різновид відношення залежності між базовим варіантом використання і його спеціальним випадком. При цьому відношенням залежності є таке відношення між двома елементами моделі, при якому зміна одного елемента (незалежного) приводить до зміни іншого елемента (залежного).