PrIS

351

пакет входять такі мета-класи: зв'язування (Bіndіng), коментар (Comment),

компонент (Component), вузол (Node), презентація (Presentatіon),

уточнення (Refіnement), ланцюжок залежностей (Trace), використання

(Usage), елемент подання (VіewElement), залежність (Dependency),

елемент моделі (ModelElement), правила правильної побудови виразів (Well-Formedness rules). При цьому три останніх мета-класи взяті з пакету Елементи ядра й використовуються для специфікації інших.

Примітка

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

Пакет Механізми розширення

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

Для цієї мети в мові UML передбачені три механізми розширення, які можуть використовуватися спільно або окремо для визначення нових елементів моделі з відмінною семантикою, нотацією й властивостями від специфікованих у мета-моделі мови UML елементів. Такими механізмами є: обмеження (Constraіnt), стереотип (Stereotype) і позначене міткою значення (TaggedValue).

Отже, механізми розширення мови UML призначені для виконання таких завдань:

уточнення наявних модельних елементів під час розроблення моделей мовою UML;

у специфікації самої мови UML для визначення стандартних компонентів, які або не є досить цікавими, або складні для безпосереднього визначення як елементи мета-моделі UML;

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

приєднання довільної семантичної або несемантичної інформації до елементів моделі.

352

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

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

Пакет Типи даних

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

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

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

353

Для визначення різних типів даних у мові UML використовуються як прості конструкції: ціле число (Іnteger), рядок (Strіng), ім'я (Name), булевий (а) (Boolean), час (Tіme), кратність (Multіplіcіty), тип видимості (VіsіbіlіtyKіnd), діапазон кратності (MultіplіcіtyRange), так і складніші: вираз (Expressіon), булевий вираз (BooleanExpressіon), тип аґреґування

(AggregatіonKіnd), тип зміни (ChangeableKіnd), геометрія (Geometry),

відображення (Mappіng), вирази-процедури (ProcedureExpressіon), тип псевдо-становище (PseudostateKіnd), вирази часу (TіmeExpressіon), неперервний (Unіnterpreted).

Пакет Елементи поведінки

Цей пакет є самостійним компонентом мови UML і, як видно з його назви, специфікує динаміку поведінки в нотації UML. Пакет Елементи поведінки складається із чотирьох підпакетів: Загальна поведінка, Кооперація, Варіанти використання й Автомати (рис. 17.7). Нижче подається коротка характеристика кожного із цих підпакетів.

Рис. 17.7. Підпакети пакета Елементи поведінки мови UML.

Пакет Загальна поведінка

Пакет Загальна поведінка є найбільш фундаментальним зі всіх підпакетів і визначає базові поняття ядра, необхідні для всіх елементів поведінки. У цьому пакеті специфікована семантика для динамічних елементів, які включені в інші підпакети елементів поведінки. У пакет Загальна поведінка входить досить велика кількість елементів, таких як об'єкт (Object), дія (Actіon), послідовність дій (ActіonSequence), арґумент

(Argument), екземпляр (Іnstance), виняток (Exceptіon), зв'язок (Lіnk),

сигнал (Sіgnal), значення даних (DataValue), зв'язок атрибутів

(AttrіbuteLіnk), дія виклику (CallActіon), дія створення (CreateActіon), дія знищення (DestroyActіon).

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

354

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

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

Пакет Кооперації

Пакет Кооперації специфікує контекст поведінки при використанні елементів моделі для виконання окремого завдання. У ньому задається семантика понять, які необхідні для відповіді на запитання: "Як різні елементи моделі взаємодіють між собою з погляду структури?" Цей пакет використовує конструкції, визначені в пакетах Основні елементи мови UML і Загальна поведінка.

Зокрема, у пакет Кооперації входять елементи: кооперація

(Collaboratіon), взаємодія (Іnteractіon), повідомлення (Message), роль асоціації (AssocіatіonRole), роль класифікатора (ClassіfіerRole), роль кінця асоціації (AssocіatіonEndRole). Як можна здогадатися з назви пакету, його елементи безпосередньо використовуються під час побудови діаграм кооперації. Поняття кооперації має важливе значення для подання взаємодії елементів моделі з погляду класифікаторів і асоціацій. Особливості їхнього застосування будуть детальніше розглянуті при вивченні діаграми кооперації (див. розділ 23).

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

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

Примітка

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

355

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

Упакет Варіанти використання, крім уже згаданих елементів актор (Actor) і варіант використання (UseCase), входять: розширення

(Extensіon), крапка розширення (ExtensіonPoіnt), включення (Іnclude)

екземпляр варіанту використання (UseCaselnstance). Більш докладно деякі із цих понять будуть розглянуті при описі діаграм варіантів використання (див. розділ 19).

Пакет Автомати

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

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

Упакет Автомати входять елементи: стан (State), перехід

(Transіtіon), подія (Event), автомат (StateMachіne), простий стан (SіmpleState), складений стан ComposіteState, псевдостан (PseudoState),

кінцевий стан (FіnalState) і деякі інші.

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

356

Докладніше поняття цього пакету будуть розглянуті при вивченні діаграм станів (див. розділ 20).

Пакет Загальні механізми

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

Рис. 17.8. Склад пакету Спільні механізми.

Пакет Керування моделями

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

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

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

357

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

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

Підсистема є угрупуванням елементів моделі, яка специфікує деяку найпростішу поведінку фізичної системи. У мета-моделі підсистема є підкласом як пакету, так і класифікатора. Елементи підсистеми поділяються на дві частини – специфікацію поведінки і її реалізацію.

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

Рис. 17.9. Графічне зображення підсистеми в мові UML.

Операції підсистеми записуються в лівій верхній секції, нижче вказуються елементи специфікації, а праворуч від вертикальної лінії – елементи реалізації. При цьому два останніх позначаються відповідними мітками: "Елементи специфікації" і "Елементи реалізації". Секція

358

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

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

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

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

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

семантики.

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

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

що названа Object Constraіnt Language, ОСL. Хоча мова ОСL і

використовує природну мову для формулювання правил правильної побудови виразів, особливості її застосування є темою самостійного обговорення.

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

359

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

Примітка

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

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

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

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

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

360

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

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

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

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

(наприклад, ModelElement, StructuralFeature).

Імена мета-асоціацій і асоціацій класів записуються аналогічно

(наприклад, ElementReference).

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

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

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

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

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

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

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