21296

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

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2013-08-02

504 KB

138 чел.

Лекція 2. Діаграма варіантів використання
(use case diagram)

Вступ

  Візуальне моделювання в UML можна уявити, як певний процес поуровневого спуску від найбільш обший і абстрактної концептуальної моделі вихідної системи до логічної, а потім і до фізичної моделі відповідної програмної системи. Для досягнення цих цілей спочатку будується модель у формі, так званої діаграми варіантів використання (use case diagram), яка описує функціональне призначення системи або, іншими словами, те, що система буде робити в процесі свого функціонування. Діаграма варіантів використання є вихідним концептуальним поданням чи концептуальною моделлю системи в процесі її розробки і впровадження.

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

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

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

Варіант використання

  Конструкція або стандартний елемент мови UML варіант використання застосовується для специфікації загальних особливостей поведінки системи або будь-який інший сутності предметної області без розгляду внутрішньої структури цієї сутності. Кожен варіант використання визначає послідовність дій, які повинні бути виконані проектованої системою при взаємодії її з відповідним актором. Діаграма варіантів може доповнюватися пояснювальним текстом, який розкриває зміст або семантику складових її компонентів. Такий пояснювальний текст отримав назву фрагмент або сценарію.

  Окремий варіант використання позначається на діаграмі еліпсом, всередині якого міститься його коротку назву або ім'я у формі дієслова з пояснювальними словами (рис. 1).

Рис. 1. Графічне позначення варіанта використання

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

  Кожен варіант використання відповідає окремому сервісу, який надає модельовану сутність або систему по запиту користувача (актора), тобто визначає спосіб застосування цієї сутності. Сервіс, що інстанціюється по запиту користувача, представляє собою закінчену послідовність дій. Це означає, що після того, як система закінчить обробку запиту користувача, вона повинна повернутися в початковий стан, в якому готова до виконання наступних запитів.

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

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

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

  У метамоделі UML варіант використання є підкласом класифікатора, який описує послідовності дій, виконуваних окремим екземпляром варіанту використання. Ці дії включають зміни стану та взаємодії із середовищем варіанту використання. Ці послідовності можуть описуватися різними способами, включаючи такі, як графи діяльності та автомати.

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

Актори

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

Рис. 2. Графічне позначення актора

  У деяких випадках актор може позначатися у вигляді прямокутника класу з ключовим словом «актор» і звичайними складовими елементами класу. Імена акторів повинні записуватися заголовними буквами та дотримуватися рекомендацій використання імен для типів і класів моделі. При цьому символ окремого актора пов'язує відповідне опис актора з конкретним ім'ям. Імена абстрактних акторів, як і інших абстрактних елементів мови UML, рекомендується позначати курсивом.

  Примітка

  Ім'я актора повинно бути достатньо інформативним з точки зору семантики. Цілком підходять для цієї мети найменування посад в компанії (наприклад, продавець, касир, менеджер, президент). Не рекомендується давати акторам імена власні або моделей конкретних пристроїв (наприклад, «маршрутизатор Cisco 3640»), навіть якщо це з очевидністю випливає з контексту проекту. Справа в тому, що одна й та сама особа може виступати в кількох ролях і, відповідно, звертатися до різних сервісів системи. Наприклад, відвідувач банку може бути як потенційним клієнтом, і тоді він затребує один з його сервісів, а може бути і податковим інспектором або слідчим прокуратури. Сервіс для останнього може бути абсолютно винятковим за своїм характером.

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

  Примітка

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

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

  Будь-яка сутність, яка узгоджується з подібним неформальним визначенням актора, являє собою екземпляр чи приклад актора. Для модельованої системи акторами можуть бути як суб'єкти-користувачі, так і інші системи. Оскільки користувачі системи завжди є зовнішніми по відношенню до цієї системи, то вони завжди представляються у вигляді акторів.

  Так як в загальному випадку актор завжди знаходиться поза системою, його внутрішня структура ніяк не визначається. Для актора має значення тільки його зовнішнє уявлення, тобто те, як він сприймається з боку системи. Актори взаємодіють з системою за допомогою передачі і прийому повідомлень від варіантів використання. Повідомлення являє собою запит актором сервісу від системи та отримання цього сервісу. Ця взаємодія може бути виражене за допомогою асоціацій між окремими акторами і варіантами використання або класами. Крім цього, з акторами можуть бути пов'язані інтерфейси, які визначають, яким чином інші елементи моделі взаємодіють з цими акторами.

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

Інтерфейси

  Інтерфейс (interface) служить для специфікації параметрів моделі, які видимі ззовні без вказівки їх внутрішньої структури. В UML інтерфейс є класифікатором і характеризує тільки обмежену частину поведінки модельованої сутності. Стосовно до діаграм варіантів використання, інтерфейси визначають сукупність операцій, які забезпечують необхідний набір сервісів nсостояній, ні спрямованих асоціацій. Вони містять лише операції без вказівки особливостей їх реалізації. Формально інтерфейс еквівалентний абстрактного класу без атрибутів і методів з наявністю тільки абстрактних операцій.

  На діаграмі варіантів використання інтерфейс зображується у вигляді маленького кола, поряд з яким записується його ім'я (рис. 3, а). Як ім'я може бути іменник, яке характеризує відповідну інформацію або сервіс (наприклад, "датчик", "відеокамера"), але частіше рядок тексту (наприклад, "запит до бази даних", "форма вводу", "пристрій подачі звукового сигналу" ). Якщо ім'я записується англійською, то воно повинно починатися з великої літери I, наприклад, ISecurelnformation, ISensor (рис. 3, б).

Рис. 3. Графічне зображення інтерфейсів на діаграмах варіантів використання

  Примітка 

  Імена інтерфейсів підкоряються загальним правилам найменування компонентів мови UML, тобто ім'я може складатися з будь-якого числа літер, цифр і деяких знаків пунктуації, таких як подвійне двокрапка "::". Останній символ використовується для більш складних імен, які включають у себе не тільки ім'я самого інтерфейсу (після знаку), а й ім'я суті, яка включає в себе даний інтерфейс (перед знаком). Прикладами таких імен є: "Мережа підприємства сервер" для вказівки на сервер мережі підприємства або "Система аутентифікації клієнтів:: форма введення пароля".

  Графічний символ окремого інтерфейсу може єднатися на діаграмі суцільною лінією з тим варіантом використання, який його підтримує. Суцільна лінія в цьому випадку вказує на той факт, що пов'язаний з інтерфейсом варіант використання повинен реалізовувати всі операції, необхідні для даного інтерфейсу, а можливо і більше (рис. 4, а). Крім цього, інтерфейси можуть з'єднуватися з варіантами використання пунктирною лінією зі стрілкою (рис. 4, б), що означає, що варіант використання призначений для специфікації тільки того сервісу, який необхідний для реалізації даного інтерфейсу.

Рис. 4. Графічне зображення взаємозв'язків інтерфейсів з варіантами використання

  З системно-аналітичної точки зору інтерфейс не тільки відокремлює специфікацію операцій системи від їх реалізації, а й визначає спільні кордони проектованої системи. У подальшому інтерфейс може бути уточнений явним зазначенням тих операцій, які специфікують окремий аспект поведінки системи. У цьому випадку він зображується у формі прямокутника класу з ключовим словом "interface" в секції імені, з порожньою секцією атрибутів і з непорожній секцією операцій. Однак подібне графічне представлення використовується на діаграмах класів або діаграмах, що характеризують поведінку модельованої системи.

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

  Примітки

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

  Графічно примітки позначаються прямокутником з "загнутим" верхнім правим куточком (рис. 5). Усередині прямокутника міститься текст примітки. Примітка може ставитися до будь-якого елементу діаграми, в цьому випадку їх з'єднує пунктирна лінія. Якщо примітка стосується декількох елементів, то від нього проводяться, відповідно, кілька ліній. Зрозуміло, примітки можуть бути присутніми не тільки на діаграмі варіантів використання, а й на інших канонічних діаграмах.

Рис. 5. Приклад примітки в UML

  Якщо у примітці вказується ключове слово "constraint", то ця примітка є обмеженням, що накладаються на відповідний елемент моделі, але не на саму діаграму. При цьому запис обмеження полягає у фігурні дужки і повинна відповідати правилам правильної побудови виразів мови ОСl. Більш докладно мова об'єктних обмежень і приклади його використання буде викладено далі. Однак для діаграм варіантів використання обмеження включати в моделі не рекомендується, оскільки вони досить жорстко регламентують окремі аспекти системи. Подібна регламентація суперечить неформального характеру загальної моделі системи, в якості якої виступає діаграма варіантів використання.

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

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

  В UML є кілька стандартних видів відносин між акторами і варіантами використання: • Ставлення асоціації (association relationship) • Відношення розширення (extend relationship) • Відношення узагальнення (generalization relationship) • Відношення включення (include relationship)

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

  Відношення асоціації

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

  Стосовно до діаграм варіантів використання воно служить для позначення специфічної ролі актора в окремому варіанті використання. Іншими словами, асоціація специфікує семантичні особливості взаємодії акторів і варіантів використання в графічній моделі системи. Таким чином, це відношення встановлює, яку конкретну роль грає актор при взаємодії з примірником варіанту використання. На діаграмі варіантів використання, так само як і на інших діаграмах, ставлення асоціації позначається суцільною лінією між актором і варіантом використання. Ця лінія може мати додаткові умовні позначення, такі, наприклад, як ім'я та кратність (рис. 6).

Рис. 6. Приклад графічного представлення відносини асоціації між актором і варіантом використання

  Кратність (multiplicity) асоціації вказується поруч з позначенням компонента діаграми, який є учасником цієї асоціації. Кратність характеризує загальна кількість конкретних екземплярів даного компонента, які можуть виступати в якості елементів даної асоціації. Стосовно до діаграм варіантів використання кратність має спеціальне позначення у формі однієї або декількох цифр і, можливо, спеціального символу "*" (зірочка).

  Для діаграм варіантів використання найбільш поширеними є чотири основні форми запису кратності відносини асоціації: • Ціле невід'ємне число (включаючи цифру 0). Призначено для вказівки кратності, яка є строго фіксованою для елемента відповідної асоціації. У цьому випадку кількість примірників акторів або варіантів використання, які можуть виступати в якості елементів відносини асоціації, точно дорівнює зазначеному числу.

  Прикладом цієї форми запису кратності асоціації є вказівка кратності "1" для актора "Клієнт банку" (рис. 4.6). Цей запис означає, що кожен екземпляр варіанту використання "Оформити кредит для клієнта банку" може мати в якості свого елемента єдиний екземпляр актора "Клієнт банку". Іншими словами, при оформленні кредиту в банку необхідно мати на увазі, що кожен конкретний кредит оформляється на єдиного клієнта цього банку. • Два цілих невід'ємних числа, розділені двома крапками і записані у вигляді: "перше число .. друге число". Даний запис в UML відповідає нотації для безлічі або інтервалу цілих чисел, яка застосовується в деяких мовах програмування для позначення меж масиву елементів. Приклад такої форми запису кратності асоціації - "1 .. 5". Цей запис означає, що кількість окремих екземплярів даного компонента, які можуть виступати в якості елементів даної асоціації, так само деякому заздалегідь невідомому числу з безлічі цілих чисел {1, 2, 3, 4, 5}. Ця ситуація може мати місце, наприклад, у разі розгляду в якості актора - клієнта банку, а в якості варіанту використання - процедуру відкриття рахунку в банку. При цьому кількість окремих рахунків кожного клієнта в цьому банку, виходячи з деяких додаткових міркувань, може бути не більше 5. Ці додаткові міркування як раз і є зовнішніми вимогами по відношенню до проектованої системи і визначаються її замовником на початкових етапах ООАП. • Два символи, розділені двома крапками. При цьому перший з них є цілим числом ненегативним або 0, а другий - спеціальним символом "*". Тут символ "*" позначає довільне кінцеве ціле невід'ємне число, значення якого невідомо на момент завдання відповідного відносини асоціації.

  Приклад такої форми запису кратності асоціації - "2 ..*". Запис означає, що кількість окремих екземплярів даного компонента, які можуть виступати в якості елементів даної асоціації, так само деякому заздалегідь невідомому числу з підмножини натуральних чисел: {2, 3, 4}. • Єдиний символ "*", який є скороченням запису інтервалу "0 ..*". У цьому випадку кількість окремих екземплярів даного компонента відносини асоціації може бути будь-яким цілим невід'ємним числом. При цьому 0 означає, що для деяких екземплярів відповідного компонента дане відношення асоціації може зовсім не мати місця.

  Як приклад цього запису можна навести кратність відносини асоціації для варіанту використання "Оформити кредит для клієнта банку" (рис. 6). Тут кратність "*" означає, що кожен окремий клієнт банку може оформити для себе кілька кредитів, при цьому їх загальна кількість заздалегідь невідомо й нічим не обмежується. При цьому деякі клієнти можуть зовсім не мати оформлених на своє ім'я кредитів (варіант значення 0).

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

  Відношення розширення Відношення розширення визначає взаємозв'язок примірників окремого варіанту використання з більш загальним варіантом, властивості якого визначаються на основі способу спільного об'єднання даних примірників. У метамоделі ставлення розширення є направленим і вказує, що стосовно до окремих прикладів деякого варіанти використання повинні бути виконані конкретні умови, визначені для розширення даного варіанту використання. Так, якщо має місце відношення розширення від варіанту використання А до варіанту використання В, то це означає, що властивості примірника варіанту використання В можуть бути доповнені завдяки наявності властивостей у розширеного варіанту використання А.

  Відношення розширення між варіантами використання позначається пунктирною лінією зі стрілкою (варіант ставлення залежності), спрямованої від того варіанту використання, який є розширенням для початкового варіанту використання. Дана лінія зі стрілкою позначається ключовим словом "extend" ("розширює"), як показано на рис. 7.

Рис. 7. Приклад графічного зображення відносини розширення між варіантами використання

  Відношення розширення

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

  Один з варіантів використання може бути розширенням для декількох базових варіантів, а також мати в якості власних розширень кілька інших варіантів. Базовий варіант використання може додатково ніяк не залежати від своїх розширень.

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

  У представленому вище прикладі (рис. 7) при оформленні замовлення на придбання товару тільки в деяких випадках може знадобитися надання клієнту каталогу всіх товарів. При цьому умовою розширення є запит від клієнта на отримання каталогу товарів. Очевидно, що після отримання каталогу клієнтові необхідно деякий час на його вивчення, протягом якого оформлення замовлення призупиняється. Після ознайомлення з каталогом клієнт вирішує або на користь вибору окремого товару, або відмови від купівлі взагалі. Сервіс або варіант використання "Оформити замовлення на придбання товару" може відреагувати на вибір клієнта вже після того, як клієнт отримає для ознайомлення каталог товарів.

Рис. 8. Графічне зображення відношення розширення з примітками умов виконання варіантів використання

  Точка розширення може бути як окремої точкою в послідовності дій, так і безліччю окремих точок. Важливо уявляти собі, що якщо відношення розширення має деяку послідовність точок розширення, тільки перша з них може визначати безліч окремих точок. Всі інші повинні визначати в точності одну таку точку. Яка з точок повинна бути першою точкою розширення, тобто визначатися єдиним розширенням. Такі посилання на розташування точок розширення можуть бути представлені різними способами, наприклад, за допомогою тексту примітки на природній мові (рис. 8), перед-і Післяумови, а також з використанням імен станів в автоматі.

  Відношення узагальнення Відношення узагальнення служить для вказівки того факту, що деякий варіант використання А може бути узагальнений до варіанту використання В. У цьому випадку варіант А буде спеціалізацією варіанту В. При цьому В називається предком або батьком по відношенню А, а варіант А - нащадком по відношенню до варіанту використання В. Слід підкреслити, що нащадок успадковує всі властивості і поведінку свого батька, а також може бути доповнений новими властивостями і особливостями поведінки. Графічно дане відношення позначається суцільною лінією зі стрілкою у формі зафарбований трикутника, яка вказує на батьківський варіант використання (рис. 9). Ця лінія зі стрілкою має спеціальну назву - стрілка "узагальнення".

Рис. 9. Приклад графічного зображення відношення узагальнення між варіантами використання

  Відношення узагальнення

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

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

  Між окремими акторами також може існувати відношення узагальнення. Дане ставлення є направленим і вказує на факт спеціалізації одних акторів відносно інших. Наприклад, відношення узагальнення від актора А до актора У відзначає той факт, що кожен екземпляр актора А є одночасно примірником актора В і володіє всіма його властивостями. У цьому випадку актор В є батьком по відношенню до актора А, а актор А, відповідно, нащадком актора В. При цьому актор А має здатність грати таке ж безліч ролей, що і актор В. Графічно дане відношення також позначається стрілкою узагальнення, т. е. суцільною лінією зі стрілкою у формі зафарбований трикутника, яка вказує на батьківського актора (рис. 10).

Рис. 10. Приклад графічного зображення відношення узагальнення між акторами

  Відношення включення

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

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

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

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

Рис. 11. Приклад графічного зображення відношення включення між варіантами використання

  Примітка

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

Приклад побудови діаграми варіантів використання

  В якості прикладу розглянемо процес моделювання системи продажу товарів за каталогом, яка може бути використана при створенні відповідних інформаційних систем.

  В якості акторів даної системи можуть виступати два суб'єкти, один з яких є продавцем, а інший - покупцем. Кожен з цих акторів взаємодіє з розглянутій системою продажу товарів за каталогом і є її користувачем, тобто вони обидва звертаються до відповідного сервісу "Оформити замовлення на покупку товару". Як випливає із суті висунутих до системи вимог, цей сервіс виступає в якості варіанту використання розроблюваної діаграми, первісна структура якої може включати в себе лише двох зазначених акторів і єдиний варіант використання (рис. 12).

Рис. 12. Вихідна діаграма варіантів використання для прикладу розробки системи продажу товарів за каталогом

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

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

  З іншого боку, продаж товарів за каталогом припускає наявність самостійного інформаційного об'єкта - каталогу товарів, який у певному сенсі не залежить від реалізації сервісу по обслуговуванню покупців. У нашому випадку, каталог товарів може запитуватися покупцем або продавцем при необхідності вибору товару та уточнення деталей його продажу. Цілком резонно представити сервіс "Замовити каталог товарів" як самостійного варіанту використання.

  Отримана в результаті подальшої деталізації уточнена діаграма варіантів використання буде містити 5 варіантів використання і 2 акторів (рис. 13), між якими встановлені відношення включення та розширення.

Рис. 13. Уточнений варіант діаграми варіантів використання для прикладу системи продажу товарів за каталогом

  Наведена вище діаграма варіантів використання, в свою чергу, може бути деталізована далі з метою більш глибокого уточнення пред'являються до системи вимог і конкретизації деталей її подальшої реалізації. У рамках загальної парадигми ООАП подібна деталізація може виконуватися в двох основних напрямках.

  З одного боку, деталізація може бути виконана на основі встановлення додаткових відносин типу відносини "узагальнення-спеціалізація" для вже наявних компонентів діаграми варіантів використання. Так, в рамках розглянутої системи продажу товарів може мати самостійне значення і специфічні особливості окрема категорія товарів - комп'ютери. У цьому випадку діаграма може бути доповнена варіантом використання "Оформити замовлення на покупку комп'ютера" і акторами "Покупець комп'ютера" і "Продавець комп'ютерів", які пов'язані з відповідними компонентами діаграми ставленням узагальнення (рис. 14).

  Уточнений таким способом варіант діаграми варіантів використання містить одну важливу особливість, яку необхідно відзначити. А саме, хоча на даній діаграмі (рис. 14) відсутні зображення ліній відносини асоціації між актором "Продавець комп'ютерів" і варіантом використання "Оформити замовлення на покупку комп'ютера", а також між актором "Покупець комп'ютера" і варіантом використання "Оформити замовлення на покупку комп'ютера ", наявність відношення узагальнення між відповідними компонентами дозволяє їм наслідувати ставлення асоціації від своїх предків. Оскільки принцип наслідування є одним з фундаментальних принципів об'єктно-орієнтованого програмування, в нашому прикладі можна з упевненістю стверджувати, що ці лінії відносини асоціації з відповідними кратностямі присутні на даній діаграмі в прихованому вигляді.

Рис. 14. Один з варіантів подальшого уточнення діаграми варіантів використання для прикладу розглянутої системи продажу

  Побудова діаграми варіантів використання є найпершим етапом процесу об'єктно-орієнтованого аналізу і проектування, мета якого - представити сукупність вимог до поведінки проектованої системи. Специфікація вимог до проектованої системі у формі діаграми варіантів використання являє собою самостійну модель, яка в мові UML отримала назву моделі варіантів використання і має своє спеціальне стандартне ім'я чи стереотип "useCaseModel".

  У подальшому всі задані в цій моделі вимоги представляються у вигляді загальної моделі системи, яка складається з пакету Системи. Останній у свою чергу може представляти собою ієрархію пакетів, на самому верхньому рівні яких міститься безліч класів моделі проектованої системи. Якщо ж пакет системи зі стандартним ім'ям "topLevel Package" є підсистемою, то її абстрактне поведінку в точності такий же, як і у вихідної системи.  

Рекомендації з розробки діаграм варіантів використання

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

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

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