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

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

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

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

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

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

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

Примітка

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

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

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

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

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

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

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

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

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

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

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

Примітка

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

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

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

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

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

Примітка

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

Процес побудови окремих типів діаграм має свої особливості, які тісно пов'язані із семантикою елементів цих діаграм. Сам процес ООАП у контексті мови 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

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

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

• Актори

• Інтерфейси

• Примітки

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

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

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

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

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

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

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

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

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

Примітка

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

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

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