1999Р. Березень-липень uml 1.3

1997р. вересень-листопад UML 1.1 Підтримка OMG

1997р. ссічень UML 1.0 Партнери з розробки UML

1996р. червень-жовтень UML 0.9/0.91

1995р. листопад Уніфікований метод 0.8 Метод OOSE

Інші методи Метод Booch ’93 Метод OMT-2 Метод Fusion

Методи Метод Booch ’91 Метод OMT

SADT

ERD

DFD

Правила роботи з об’єктами UML

1. Явно вказується у тексті екземпляр деякого класу.

2. Використовуються лише ті значення слова, які написані у імені відповідно конструкції UML.

3. Існує 3 допустимі префікси.

4. Посилання на конструкцію UML записується звичайним шрифтом.

5. Імена класів це іменник і можливо прикметник; ім’я записується одним словом, кожна частина записується з великої літери.

6. Ім’я асоціації записується аналогічно до імені класів.

7. Ім’я інших елементів записується одним словом але починається з малої літери.

8. Імена атрибутів, які приймають логічні значення з префіксом is.

9. Перераховані типи закінчуються словом kind.

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

11. Імена стандартних позначень заключаються у рядки і починаються з маленької літери.

Графічні конструкції UML:

1. Значки або піктограми – графічні фігури фіксованого розміру і форми.

2. Графічні символи на площині – певні геометричні фігури різної висоти та ширини.

3. Шляхи – послідовність відрізків які поєднують певні графічні символи.

4. Рядки тексту – для представлення інформації в певній граматичній формі.

Діаграма варіантів використання (use case diagram)

Мета розробки:

1. Визначити загальні межі та контекст предметної області, яка моделюється на початкових етапах проектуванні системи.

2. Сформувати загальні вимоги до функціонування поведінки ПС.

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

4. Підготувати початкову документацію для взаємодії розробників з замовниками та користувачами.

Система представляється у вигляді множини акторів, які взаємодіють з системою за допомогою варіантів використання.

Варіант використання – це послідовність дій, які повинні бути виконані системою при взаємодії з відповідним актором.

П означається:

Актор – це зовнішня до системи сутність, яка взаємодіє з нею для досягнення певних цілей.

П означається:

Ім’я актора – записується з великої літери, не повинно бути власним; за звичай це посада. Імена абстрактних акторів записуються курсивом.

Інтерфейс потрібен для визначення параметрів моделей без зазначення їх внутрішньої структури, вони визначають сукупність операцій необхідних для акторів.

П означається:

Інтерфейс з’єднується за допомогою:

1. означає, що зв’язаний з інтерфейсом варіант використання реалізує всі операції необхідні для даного інтерфейсу, а можливо і більше.

2. означає, що варіант використання призначений для визначення лише того сервісу, який необхідний для реалізації даного інтерфейсу.

Для включення в модель текстової інформації використовують примітки.

П означається:

Якщо в примітці вказується ключове слово “constraint”, то це обмеження на елемент моделі, а не на діаграму.

Відношення на діаграмі варіантів використання:

1. Асоціації – вказує конкретну роль, яку грає актор при взаємодії з варіантом використання

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

2. Розширення – визначає зв'язок екземплярів одного варіантів використання з більш загальним.

“extend” Стрілка направлена до більш загального варіанту використання.

3. Узагальнення – вказує що варіант використання А може бути узагальненим до варіанту використання В; А – є спеціалізацією або нащадком, В- пращур.

А В

4. Включення – вказує що деяка поведінка варіанту використання являється складовою поведінки іншого варіанту використання.

“ include” Стрілка направлена від базового елементу до менш загального.

Приклад: