PrIS

371

Примітка

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

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

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

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

18.2. Актори

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

372

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

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

Примітка

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

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

іінша сутність, що має відношення до концептуальної моделі відповідної предметної області.

Примітка

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

Актор використовується для моделювання зовнішньої по відношенню до проектованої системи сутності, яка взаємодіє із системою

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

373

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

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

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

18.3. Інтерфейси

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

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

375

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

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

18.4. Примітки

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

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

376

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

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

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

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

378

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

Примітка

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

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

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

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

2.Два цілі невід’ємні числа, розділені двома крапками й записані у вигляді: "перше число .. друге число". Такий запис у мові UML відповідає нотації для множини або інтервалу цілих чисел, яка застосовується в деяких мовах програмування для позначення меж масиву елементів. Цей запис треба розуміти як множину цілих невід’ємних чисел, що розташовані у порядку, що послідовно зростає:

{перше_число, перше_число+1, перше_число+2 ..., друге_число]. Очевидно, що перше число має бути строго менше від другого числа в арифметичному сенсі, при цьому перше число може дорівнювати 0.

Приклад такої форми запису кратності асоціації – "1..5". Цей запис означає, що кількість окремих екземплярів певного компонента, які можуть виступати як елементи певної асоціації, дорівнює деякому заздалегідь невідомому числу із множини цілих чисел {1, 2, 3, 4, 5}. Ця ситуація може мати місце, наприклад, коли актор – клієнт банку, а варіант

379

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

3.Два символи, розділені двома крапками. При цьому перший з них

єцілим невід’ємним числом або 0, а другий – спеціальний символ "*". Цей символ "*" означає довільне кінцеве ціле невід’ємне число, значення якого невідоме на момент задання відповідного відношення асоціації.

Приклад такої форми запису кратності асоціації – "2..*". Запис означає, що кількість окремих екземплярів такого компонента, які можуть виступати як елементи певної асоціації, дорівнює деякому заздалегідь невідомому числу з підмножини натуральних чисел: {2, 3, 4}.

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

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

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

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

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

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

380

властивості екземпляра варіанту використання В можуть бути доповнені завдяки наявності властивостей у розширеного варіанту використання А.

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

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

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

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

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

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