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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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