3.4. Основні пакети метамоделі язика uml

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

Ці пакети у свою чергу діляться на окремі підпакети. Наприклад, пакет Основні елементи складається з підпакетів: Елементи ядра, Допоміжні елементи, Механізми розширення і типи даних (мал. 3.6). При цьому пакет Елементи ядра описує базові поняття і принципи включення в структуру метамоделі основних понять язика, таких як метаклассы, метаассоциации і метаатрибуты. Пакет Допоміжні елементи визначає додаткові конструкції, які розширюють базові елементи для опису залежності, шаблонів, фізичних структур і елементів уявлень. Пакет Механізми розширення задає правила уточнення і розширення семантики базових елементів моделей. Пакет Типи даних визначає основні структури даних для язика UML.

Мал. 3.5. Основні пакети метамоделі язика UML

Мал. 3.6. підпакети пакету Основні елементи язика UML

Пакет Основні елементи

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

Пакет Елементи ядра

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

Примітка

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

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

В цей пакет входять основні метаклассы язика UML: клас (Class), атрибут (Attribute), асоціаціях (Association), асоціація‑ клас (AssociationClass), кінець асоціації (AssociationEnd), властивість поведінки (BehavioralFeature), класифікатор (Classifier), обмеження (Constraint), тип даних (DataType), залежність (Dependency), елемент #@:, право на елемент #@;, властивість #@

Пакет Допоміжні елементи

Пакет Допоміжні елементи є підпакетом пакету Основні елементи і специфікує додаткові конструкції язика UML, які розширюють пакет Елементи ядра. Допоміжні елементи забезпечують понятійний базис для залежності, шаблонів, фізичних структур і елементів уявлень. В цей пакет входять наступні метаклассы: скріплення (Binding), коментар (Comment), компонент (Component), вузол (Node), презентація (Presentation), уточнення (Refinement), ланцюжок залежності (Trace), споживання (Usage), елемент уявлення (ViewElement), залежність (Dependency), елемент моделі #@:, правила правильної побудови виразів #@;. При цьому три останніх метакласса узяті з пакету Елементи ядра і використовуються для специфікації інших.

Примітка

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

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

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

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

Таким чином, механізми розширення язика UML призначені для виконання наступних задач:

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

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

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

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

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

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

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

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

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

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

Для визначення різних типів даних в язиці UML використовуються як прості конструкції: ціле число (Integer), рядок (String), ім'я (Name), Булевий (Boolean), час (Time), кратність (Multiplicity), тип видимості (VisibilityKind), діапазон кратності (MultiplicityRange), так і складніші: вираз (Expression), булевий вираз (BooleanExpression), тип агрегації #@:, тип зміни #@;, геомет

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

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

Мал. 3.7. підпакети пакету Елементи поведінки язика UML

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

Пакет Загальна поведінка є найфундаментальнішим зі всіх підпакетів і визначає базові поняття ядра, необхідні для всіх елементів поведінки. В цьому пакеті специфікована семантика для динамічних елементів, які включені в інші підпакети елементів поведінки. В пакет Загальна поведінка входить достатньо велике число елементів, таких як об'єкт (Object), дія (Action), послідовність дій (ActionSequence), аргумент (Argument), екземпляр (Instance), виключення (Exception), зв'язок (Link), сигнал (Signal), значення даних (DataValue), зв'язок атрибутів (AttributeLink), дія виклику #@:, дія створення #@;, дія знищення #@

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

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

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

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

Зокрема, в пакет Кооперації входять елементи: кооперація (Collaboration), взаємодія (Interaction), повідомлення (Message), роль асоціації (AssociationRole), роль класифікатора (ClassifierRole), роль кінця асоціації (AssociationEndRole). Якомога здогадатися з назви пакету, його елементи безпосередньо використовуються при побудові діаграм кооперації. Поняття кооперації має важливе значення для представлення взаємодії елементів моделі з погляду класифікаторів і асоціацій. Особливості їх вживання будуть більш детально розглянуті при вивченні діаграми кооперації (див. розділ 9).

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

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

Примітка

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

В пакет Варіанти використовування окрім вже згаданих елементів актор (Actor) і варіант використовування (UseCase) входять: розширення (Extension), точка розширення (ExtensionPoint), включення (Include) і екземпляр варіанту використовування (UseCaselnstance). Більш детально деякі з цих понять будуть розглянуті при описі діаграм варіантів використовування (див. розділ 4).

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

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

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

В пакет Автомати входять елементи: стан (State), перехід (Transition), подія (Event), автомат (StateMachine), простий стан (SimpleState), складовий стан CompositeState, псевдостан (PseudoState), кінцевий стан (FinalState) і деякі інші.

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

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

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

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

Мал. 3.8. Склад пакету Загальні механізми

Пакет Управління моделями

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

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

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

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

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

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

Мал. 3.9. Графічне зображення підсистеми в язиці UML

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