- •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.2. Актори
Актор є будь-яким зовнішнім по відношенню до модельованої системи єством, яке взаємодіє з системою і використовує її функціональні можливості для досягнення певної мети або рішення приватних задач. При цьому актори служать для позначення злагодженої безлічі ролей, які можуть грати користувачі в процесі взаємодії з проектованою системою. Кожний актор може розглядатися як якась окрема роль щодо конкретного варіанту використовування. Стандартним графічним позначенням актора на діаграмах є фігурка «чоловічка», під якою записується конкретне ім'я актора (мал. 4.2).
Мал. 4.2. Графічне позначення актора
В деяких випадках актор може позначатися у вигляді прямокутника класу з ключовим словом «актор» і звичайними становлячими елементами класу. Імена акторів повинні записуватися заголовними буквами і слідувати рекомендаціям використовування імен для типів і класів моделі. При цьому символ окремого актора зв'язує відповідний опис актора з конкретним ім'ям. Імена абстрактних акторів, як і інших абстрактних елементів язика UML, рекомендується позначати курсивом.
Примітка
Ім'я актора повинне бути достатньо інформативним з погляду семантики. Цілком підходять для цієї мети найменування посад в компанії (наприклад, продавець, касир, менеджер, президент). Не рекомендується давати акторам імена власні (наприклад, «Про.Бендер») або моделей конкретних пристроїв (наприклад, «маршрутизатор Cisco 3640»), навіть якщо це з очевидністю виходить з контексту проекту. Річ у тому, що одна і та ж особа може виступати в декількох ролях і, відповідно, звертатися до різних сервісів системи. Наприклад, відвідувач банку може бути як потенційним клієнтом, і тоді він запитає один з його сервісів, а може бути і податковим інспектором або слідчим прокуратури. Сервіс для останнього може бути абсолютно винятковим по своєму характеру.
Прикладами акторів можуть бути: клієнт банку, банківський службовець, продавець магазина, менеджер відділу продажів, пасажир авіарейса, водій автомобіля, адміністратор готелю, стільниковий телефон і інші єства, що мають відношення до концептуальної моделі відповідної наочної області.
Примітка
В метамоделі актор є підкласом класифікатора. Актори можуть взаємодіяти з безліччю варіантів використовування і мають безліч інтерфейсів, кожний з яких може представляти особливості взаємодії інших елементів з окремими акторами.
Актори використовуються для моделювання зовнішніх по відношенню до проектованої системи єств, які взаємодіють з системою і використовують її як окремі користувачі. Як актори можуть виступати інші системи, підсистеми проектованої системи або окремі класи. Важливо розуміти, що кожний актор визначає деяку злагоджену безліч ролей, в яких можуть виступати користувачі даної системи в процесі взаємодії з нею. В кожний момент часу з системою взаємодіє цілком певний користувач, при цьому він грає або виступає в одній з таких ролей. Найнаочніший приклад актора – конкретний користувач системи з своїми власними параметрами аутентифікації.
Будь-яке єство, яке узгоджується з подібним неформальним визначенням актора, є екземпляром або прикладом актора. Для модельованої системи акторами можуть бути як суб'єкти‑ користувачі, так і інші системи. Оскільки користувачі системи завжди є зовнішніми по відношенню до цієї системи, то вони завжди представляються у вигляді акторів.
Оскільки в загальному випадку актор завжди знаходиться поза системою, його внутрішня структура ніяк не визначається. Для актора має значення тільки його зовнішнє уявлення, т. е. те, як він сприймається з боку системи. Актори взаємодіють з системою за допомогою передачі і прийому повідомлень від варіантів використовування. Повідомлення є запитом актором сервісу від системи і отримання цього сервісу. Ця взаємодія може бути виражене за допомогою асоціацій між окремими акторами і варіантами використовування або класами. Окрім цього, з акторами можуть бути зв'язані інтерфейси, які визначають, яким чином інші елементи моделі взаємодіють з цими акторами.
Два і більш актора можуть мати загальні властивості, т. е. взаємодіяти з одним і тим же множеством варіантів використовування однаковим чином. Така спільність властивостей і поведінки представляється у вигляді відношення узагальнення, що розглядається нижче, з іншим, можливо, абстрактним актором, який моделює відповідну спільність ролей. Сукупність відносин, які можуть бути присутні на діаграмі варіантів використовування, буде розглянута нижче в даному розділі.
