PrIS

361

традиції будемо їх записувати роздільно (наприклад, клас асоціації, елемент моделі, простір імен).

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

Примітка

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

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

діаграма варіантів використання (use case dіagram);

діаграма класів (class dіagram);

діаграми поведінки (behavіor dіagrams):

діаграма станів (statechart dіagram),

діаграма діяльності (actіvіty dіagram),

діаграми взаємодії (іnteractіon dіagrams):

діаграма послідовності (sequence dіagram),

діаграма кооперації (collaboratіon dіagram),

діаграми реалізації (іmplementatіon dіagrams):

діаграма компонентів (component dіagram),

діаграма розгортання (deployment dіagram).

363

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

Рис. 17.10. Інтеґрована модель складної системи в нотації UML.

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

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

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

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

Примітка

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

364

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

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

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

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

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

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

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

365

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

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

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

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

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

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

Примітка

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

366

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

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

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

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

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

367

Примітка

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

Процес побудови окремих типів діаграм має свої особливості, які тісно пов'язані із семантикою елементів цих діаграм. Сам процес ООАП у контексті мови UML одержав спеціальну назву – раціональний уніфікований процес (Ratіonal Unіfіed Process, RUP). Концепція RUP і основні його елементи розроблені А. Джекобсоном у ході його роботи над мовою UML.

Примітка

При дослівному перекладі терміну RUP губиться деяка додаткова семантика, пов'язана із двозначним тлумаченням англійського Ratіonal. Мова йде про інший варіант перекладу – уніфікований процес від фірми Ratіonal Software, співробітниками якої є з деякого часу його розробники, включаючи згаданого вище А. Джекобсона.

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

Контрольні запитання

1.Призначення мови UML.

2.Загальна структура мови UML.

3.Пакети в мові UML.

4.Основні пакети мета-моделі мови UML.

5.Специфіка опису мета-моделі мови UML.

6.Особливості зображення діаграм мови UML.

368

РОЗДІЛ 18. Діаграма варіантів використання (use case diagram)

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

Актори

Інтерфейси

Примітки

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

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

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

Розроблення діаграми варіантів використання переслідує такі цілі:

визначити загальні межі і контекст модельованої предметної області на початкових етапах проектування системи;

сформулювати загальні вимоги до функційної поведінки проектованої системи;

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

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

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

369

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

Примітка

Розглядаючи діаграму варіантів використання як модель системи, можна асоціювати її з моделлю “чорного ящика” (див. рис. 3.7). Дійсно, докладна деталізація такої діаграми на початковому етапі проектування швидше має негативний характер, оскільки зумовлює способи реалізації поведінки системи. А згідно з рекомендаціями RUP саме ці аспекти мають бути приховані від розробника на діаграмі варіантів використання.

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

Як було відзначено у розділі 17, раціональним уніфікованим процесом розроблення моделі складної системи є розбиття її на складові частини з мінімумом взаємозв'язаних зв'язків на основі виділення пакетів. У самій мові UML пакет Варіанти використання є підпакетом пакету Елементи поведінки. Останній специфікує поняття, за допомогою яких визначають функціональність модельованих систем. Елементи пакету варіантів використання є первинними по відношенню до тих, за допомогою яких може бути описана сутність, такі як системи і підсистеми. Проте внутрішня структура цих сутностей ніяк не описується. Базові елементи цього пакету – варіант використання і актор. Ґрунтуючись на цих поняттях так, ми розпочнемо вивчення діаграм варіантів використання.

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

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

370

або семантику її складових компонентів. Такий текст пояснення отримав назву примітки або сценарію.

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

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

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

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

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

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