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

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

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

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

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

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

Примітка

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

Таким чином, в язиці UML використовується чотири основні види графічних конструкцій:

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

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

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

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

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

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

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

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

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

Примітка

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

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

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

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

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

Примітка

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

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

Примітка

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

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

РОЗДІЛ 4

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

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

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

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

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

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

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

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

Примітка

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

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

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