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

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

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

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

• Семантики

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

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

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

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

Примітка

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

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

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

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

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

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

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

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

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

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

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

• Імена мета-атрибутів, які приймають булеві значення, завжди починаються із префікса "іs" (наприклад, іsAbstract).

• Перераховані типи повинні завжди закінчуватися словом "Kіnd" (наприклад, AggregatіonKіnd).

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

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

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

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

• Під час розроблення конкретних моделей систем у формі діаграм мови 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)

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

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

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

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

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

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

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

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

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

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

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

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

Примітка

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