- •1.1. Методологія процедурно‑ орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого програмування
- •1.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •1.4. Методологія системного аналізу і системного моделювання
- •Розділ 2
- •2.1. Передісторія. Математичні основи
- •Мал. 2.4. Приклади неорієнтованого (а) і орієнтованого (б) графів
- •Мал. 2.5. Приклади неорієнтованого (а) і орієнтованого (б) дерев
- •Мал. 2.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б)
- •2.2. Діаграми структурного системного аналізу
- •I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
- •2.3. Основні етапи розвитку uml
- •2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.
- •3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.
- •4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.
- •7. Інтегрувати в себе новітні і якнайкращі досягнення практики ооап.
- •3.2. Загальна структура язика uml
- •3.3. Пакети в язиці uml
- •3.4. Основні пакети метамоделі язика uml
- •3.5. Специфіка опису метамоделі язика uml
- •3.6. Особливості зображення діаграм язика uml
- •4.1. Варіант використовування
- •4.2. Актори
- •4.3. Інтерфейси
- •4.4. Примітки
- •4.5. Відносини на діаграмі варіантів використовування
- •4.6. Приклад побудови діаграми варіантів використовування
- •4.7. Рекомендації по розробці діаграм варіантів використовування
- •5.1. Клас
- •5.2. Відносини між класами
- •5.5. Шаблони або класи, що параметризуються
- •5.6. Рекомендації по побудові діаграм класів
- •6.1. Автомати
- •Include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
- •6.3. Перехід
- •6.4. Складовий стан і підстан
- •6.5. Історичний стан
- •Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
- •6.6. Складні переходи
- •Мал. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
- •6.7. Заключні рекомендації по побудові діаграм станів
- •7.1. Стан дії
- •7.2. Переходи
- •7.5. Рекомендації по побудові діаграм діяльності
- •8.2. Повідомлення
- •Мал. 8.7. Діаграма послідовності із стереотипними значеннями повідомлень
- •8.3. Приклад побудови діаграми послідовності
- •8.4. Заключні рекомендації по побудові діаграм послідовності
- •9.1. Кооперація
- •9.3. Зв'язки
- •9.4. Повідомлення
- •9.6. Заключні рекомендації по побудові діаграм кооперації
- •10.1. Компоненти
- •10.2. Інтерфейси
- •10.3. Залежність
- •10.4. Рекомендації по побудові діаграми компонентів
- •11.1. Вузол
- •11.2. З'єднання
- •Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
- •11.3. Рекомендації по побудові діаграми розгортання
- •12.1. Загальна характеристика case‑ засобу Rational Rose 98/2000
- •12.2. Особливості робочого інтерфейсу Rational Rose
- •12.3. Початок роботи над проектом в середовищі Rational Rose
- •12.4. Розробка діаграми варіантів використовування в середовищі Rational Rose
- •12.5. Розробка діаграми класів в середовищі Rational Rose
- •12.6. Розробка діаграми станів в середовищі Rational Rose
- •12.7. Розробка діаграми послідовності в середовищі Rational Rose
- •12.8. Розробка діаграми кооперації в середовищі Rational Rose
- •12.9. Розробка діаграми компонентів в середовищі Rational Rose
- •12.10. Розробка діаграми розгортання в середовищі Rational Rose
4.1. Варіант використовування
Конструкція або стандартний елемент язика UML варіант використовування застосовується для специфікації загальних особливостей поведінки системи або будь-якого іншого єства наочної області без розгляду внутрішньої структури цього єства. Кожний варіант використовування визначає послідовність дій, які повинні бути виконані проектованою системою при взаємодії її з відповідним актором. Діаграма варіантів може доповнюватися текстом пояснення, який розкриває значення або семантику становлячих її компонентів. Текст такого пояснення одержав назву примітки або сценарію.
Окремий варіант використовування позначається на діаграмі еліпсом, усередині якого міститься його коротка назва або ім'я у формі дієслова із словами пояснень (мал. 4.1).
Мал. 4.1. Графічне позначення варіанту використовування
Мета варіанту використовування полягає в тому, щоб визначити закінчений аспект або фрагмент поведінки деякого єства без розкриття внутрішньої структури цього єства. Як таке єство може виступати початкова система або будь-який інший елемент моделі, який володіє власною поведінкою, подібно підсистемі або класу в моделі системи.
Кожний варіант використовування відповідає окремому сервісу, який надає модельоване єство або систему по запиту користувача (актора), т. е. визначає спосіб вживання цього єства. Сервіс, який ініціалізувався по запиту користувача, є закінченою послідовністю дій. Це означає, що після того, як система закінчить обробку запиту користувача, вона повинна повернутися в початковий стан, в якому готова до виконання наступних запитів.
Варіанти використовування описують не тільки взаємодії між користувачами і єством, але також реакції єства на отримання окремих повідомлень від користувачів і сприйняття цих повідомлень за межами єства. Варіанти використовування можуть включати опис особливостей способів реалізації сервісу і різних виняткових ситуацій, таких як коректна обробка помилок системи. Безліч варіантів використовування в цілому повинна визначати всі можливі сторони очікуваної поведінки системи. Для зручності безліч варіантів використовування може розглядатися як окремий пакет.
З системно‑ аналітичної точки зору варіанти використовування можуть застосовуватися як для специфікації зовнішніх вимог до проектованої системи, так і для специфікації функціональної поведінки вже існуючої системи. Окрім цього, варіанти використовування неявно встановлюють вимоги, що визначають, як користувачі повинні взаємодіяти з системою, щоб мати нагоду коректно працювати з сервісами, що надаються даною системою!
Примітка
Кожний виконуваний варіантом використовування метод реалізується як неподільна транзакція, т. е. виконання сервісу не може бути перервано ніяким іншим екземпляром варіанту використовування.
Вживання варіантів використовування на всіх рівнях діаграми дозволяє не тільки досягти необхідного рівня уніфікації позначень для представлення функціональності підсистем і системи в цілому, але і є могутнім засобом послідовного уточнення вимог до проектованої системи на основі напіврівневого спуску від пакетів системи до операцій класів. З другого боку, модифікація окремих операцій класу може зробити зворотний вплив на уточнення сервісу відповідного варіанту використовування, т. е. реалізувати ефект зворотного зв'язку з метою уточнення специфікацій або вимог на рівні пакетів системи.
В метамоделі UML варіант використовування є підкласом класифікатора, який описує послідовності дій, виконуваних окремим екземпляром варіанту використовування. Ці дії включають зміни стану і взаємодії з середовищем варіанту використовування. Ці послідовності можуть описуватися різними способами, включаючи такі, як графи діяльності і автомати.
Прикладами варіантів використовування можуть бути наступні дії: перевірка стану поточного рахунку клієнта, оформлення замовлення на покупку товару, отримання додаткової інформації про кредитоспроможність клієнта, відображення графічної форми на екрані монітора і інші дії.
