3.5. Специфіка опису метамоделі язика uml

Метамодель язика UML описується на деякому напівформальному язиці з використанням трьох видів уявлень:

Абстрактного синтаксису

Правил правильної побудови виразів

Семантики

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

Правила правильної побудови виразів використовуються для завдання додаткових обмежень або властивостей, якими винні володіти ті або інші компоненти моделі. Оскільки початковим поняттям ООП є поняття класу, його загальними властивостями винні володіти всі екземпляри, які в цьому значенні повинні бути інваріантні один одному. Для завдання цих інваріантних властивостей класів і відносин необхідно використовувати спеціальні вирази деякого формального язика, в рамках UML язика об'єктних обмежень, що одержав назву (Object Constraint Language, ВІСЬ). Хоча язик ВІСЬ і використовує природний язик для формулювання правил правильної побудови виразів, особливості його вживання є темою самостійного обговорення. Основні особливості язика ВІСЬ розглянуті в додатку.

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

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

Примітка

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

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

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

Явно указувати в тексті екземпляр деякого метакласса. Йдеться про те, що в природній мові ми часто опускаємо слово «приклад» або «екземпляр», кажучи просто «клас». Так, фразу «Атрибут вік класу співробітник має значення 30 років» слід записати більш точно, а саме: «атрибут вік екземпляра класу співробітник має значення 30 років».

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

Терміни язика UML можуть включати тільки один з допустимих префіксів, таких як под‑ , супер– або мета-. При цьому сам термін з префіксом записується одним словом.

На додаток до цього використовуватимуться наступні правила виділення тексту:

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

Імена метаклассов є елементом нотації язика UML і є іменником і, можливо, приєднаним до нього прикметником. В цьому випадку ім'я метакласса на англійському записується одним словом з виділенням кожної складової частини імені заголовною буквою (наприклад, ModelElement, StructuralFeature).

Імена метаассоциаций і асоціацій класів записуються аналогічним чином (наприклад, ElementReference).

Імена інших елементів язика UML також записуються одним словом, але повинні починатися з маленької букви (наприклад, ownedElement, allContents).

Імена метаатрибутов, які приймають булеві значення, завжди починаються з префікса «is» (наприклад, isAbstract).

Перечислімиє типи повинні завжди закінчуватися словом «Kind» (наприклад, AggregationKind).

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

Імена стандартних позначень (стереотипів) полягають в лапки і починаються з рядкової букви (наприклад, «type»).

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

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

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

Примітка

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

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

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

Діаграма класів (class diagram)

Діаграми поведінки (behavior diagrams)

Діаграма станів (statechart diagram)

Діаграма діяльності (асtivity diagram)

Діаграми взаємодії (interaction diagrams)

Діаграма послідовності (sequence diagram)

Діаграма кооперації (collaboration diagram)

Діаграми реалізації (implementation diagrams)

Діаграма компонентів (component diagram)

Діаграма розгортання (deployment diagram)

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

1.  Діаграма варіантів використовування (див. розділ 4).

2.  Діаграма класів (див. розділ 5).

3.  Діаграма станів (див. розділ 6).

4.  Діаграма діяльності (див. розділ 7).

5.  Діаграма послідовності (див. розділ 8).

6.  Діаграма кооперації (див. розділ 9).

7.  Діаграма компонентів (див. розділ 10).

8. Діаграма розгортання (див. розділ 11).

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

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

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

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

Примітка

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