PrIS
.pdf341
інструментальні CASE-засоби. Наявність останніх має принципове значення для усебічного поширення й використання мови UML.
4.Опис мови UML повинен містити в собі семантичний базис для розуміння загальних особливостей ООАП.
Говорячи про цю особливість, мають на увазі самодостатність мови UML для розуміння не тільки її базових конструкцій, але, що не менш важливо, – розуміння загальних принципів ООАП. У зв'язку з цим зазначимо, що оскільки мова UML не є мовою програмування, а служить засобом для вирішення завдань об’єктно-орієнтованого моделювання систем, опис мови UML повинен містити в собі всі необхідні поняття для ООАП. Без цієї властивості мова UML може виявитися непотрібною для більшості користувачів, які не знайомі із проблематикою ООАП складних систем.
З іншого боку, які б не були посилання на додаткові джерела, що містять важливу для розуміння мови UML інформацію, на думку розробників з OMG, мають бути виключені. Це дозволить уникнути неоднозначного тлумачення принципових особливостей процесу ООАП і їхньої реалізації у формі базових конструкцій мови UML.
5.Заохочувати розвиток ринку об'єктних інструментальних засобів. Понад 800 провідних виробників програмних і апаратних засобів,
зусилля яких зосереджені в рамках OMG, бачать перспективи розвитку сучасних інформаційних технологій і основу свого комерційного успіху в широкому просуванні на ринок інструментальних засобів, що підтримують об'єктні технології. Говорячи ж про об'єктні технології, розробники з OMG мають на увазі, насамперед, сукупність технологічних рішень CORBA і UML. Із цього погляду мові UML придзначається роль базового засобу для опису й документування різних об'єктних компонентів CORBA.
6. Сприяти розширенню об'єктних технологій і відповідних понять ООАП.
Це завдання тісно пов'язане з попереднім й має з ним багато спільного. Якщо вилучити з розгляду рекламні заяви розробників про виняткову гнучкість і потужність мови UML, а спробувати скласти об'єктивну картину можливостей цієї мови, то можна прийти до такого висновку. Варто визнати, що зусилля досить великої групи розробників були спрямовані на інтеґрацію в рамках мови UML багатьох відомих технік візуального моделювання, які успішно зарекомендували себе на практиці (див. розділ 4). Хоча це привело до ускладнення мови UML у порівнянні з відомими нотаціями структурного системного аналізу, розплатою за складність є дійсно висока гнучкість і візуальні можливості вже перших версій мови UML. Своєю чергою, використання мови UML для вирішення різних практичних завдань буде тільки сприяти її
342
подальшому вдосконалюванню, а отже і подальшому розвитку об'єктних технологій і практики ООАП.
7. Інтеґрувати в собі новітні й найкращі досягнення практики ООАП.
Мова UML безупинно вдосконалюється розробниками, і основою цієї роботи є її подальша інтеґрація із сучасними модельними технологіями. При цьому різні методи системного моделювання одержують своє прикладне осмислення в рамках ООАП. Надалі ці методи можуть бути включені до складу мови UML у формі додаткових базових понять, які найадекватніше відображають найкращі досягнення практик ООАП.
Щоб вирішити зазначені вище завдання, за свою недовгу історію мова UML певним чином еволюціювала. У результаті опис самої мови UML став нетривіальним, оскільки семантика базових понять містить у собі цілий ряд перехресних зв'язків з іншими поняттями і конструкціями мови. У зв'язку із цим так званий лінійний або послідовний розгляд основних конструкцій мови UML став практично неможливим, тому що ті самі поняття можуть використовуватися під час побудови різних діаграм або подань. Одночасно кожне з подань моделі має власні семантичні особливості, які накладають відбиток на семантику базових понять мови загалом.
Примітка
Відзначаючи складність опису мови UML, відзначимо наявну всім формальним мовам складність їхнього строгого подання, що випливає з необхідності в тому чи іншому ступені використовувати природну мову для специфікації базових примітивів. У цьому випадку природна мова виступає в ролі метамови, тобто мови для опису формальної мови. Оскільки природна мова не є формальною, то і її застосування для опису формальних мов у тому чи іншому ступені страждає неточністю. Хоча в завдання мови UML не входить аналіз відповідних логіко-лінґвістичних конструкцій, однак ці особливості відбилися на структурі опису мови UML, зокрема, роблячи стиль опису всіх його основних понять напівформальним.
З огляду на ці особливості, прийнята послідовність вивчення мови UML ґрунтується на розгляді основних графічних засобів моделювання, а саме – канонічних діаграм. Всі потрібні для побудови діаграм поняття вводяться в міру необхідності. Проте в цьому розділі ми зупинимося на загальних особливостях мови UML, які впливають на розуміння її базових конструкцій.
17.2. Загальна структура мови UML
343
Із загального погляду опис мови UML складається із двох частин, які взаємодіють, таких як:
семантика мови UML, яка являє собою деяку мета-модель, що визначає абстрактний синтаксис і семантику понять об'єктного моделювання мовою UML;
нотація мови UML, що являє собою графічну нотацію для
візуального подання семантики мови UML.
Абстрактний синтаксис і семантика мови UML описується з використанням деякої підмножини нотацій UML. Крім того, нотація UML описує відповідність або відображає графічну нотацію в базові поняття семантики. Отже, з погляду функціональності ці дві частини доповнюють одна одну. При цьому семантика мови UML описується на основі деякої мета-моделі, що має три окремих подання: абстрактний синтаксис, правила коректної побудови виразів і семантику. Розгляд семантики мови UML припускає деякий "напівформальний" стиль викладу, що поєднує природну і формальну мови для подання базових понять і правил їхнього розширення.
Семантика визначається для двох видів об'єктних моделей: структурних моделей і моделей поведінки. Структурні моделі, відомі також як статичні моделі, описують структуру сутностей або компонентів деякої системи, включаючи їхні класи, інтерфейси, атрибути й відношення. Моделі поведінки, які називаються інколи динамічними моделями, описують поведінку або функціонування об'єктів системи, включаючи їхні методи, взаємодію і співпрацю між ними, а також процес зміни станів окремих компонентів і системи загалом.
Для вирішення настільки широкого діапазону завдань моделювання розроблена досить повна семантика для всіх компонентів графічної нотації. Вимоги семантики мови UML конкретизуються під час побудови окремих видів діаграм, послідовний розгляд яких служить темою наступних розділів. Нотація мови UML містить в собі опис окремих семантичних елементів, які можуть застосовуватися під час побудови діаграм.
Формальний опис самої мови UML ґрунтується на деякій загальній ієрархічній структурі модельних подань, що складається із чотирьох рівнів:
мета-мета-модель,
мета-модель,
модель,
об'єкти користувача.
344
Рівень мета-мета-модель утворює вихідну основу для всіх метамодельних подань. Головне призначення цього рівня полягає в тому, щоб визначити мову для специфікації мета-моделі. Мета-мета-модель визначає модель мови UML на найвищому рівні абстракції і є найкомпактнішим її описом. З іншого боку, мета-мета-модель може специфікувати декілька мета-моделей, чим досягається потенційна гнучкість включення додаткових понять. Хоча у цьому навчальному посібнику цей рівень не розглядається, він найтісніше пов'язаний з теорією формальних мов. Прикладами понять цього рівня служать мета-клас, мета-атрибут, метаоперація.
Примітка
Зазначимо, що семантика мета-мета-моделі не входить в опис мови UML. З одного боку, це робить мову UML простішою для вивчення, оскільки не вимагає знання загальної теорії формальних мов і формальної логіки. З іншого боку, наявність мета-мета-моделі надає мові UML статусу науковості, що необхідна їй для того, щоб бути несуперечливою формальною мовою. Якщо ці особливості можуть бути мало цікавими для багатьох програмістів, то розробники інструментальних засобів ніяк не можуть їх іґнорувати.
Мета-модель є екземпляром або конкретизацією мета-мета-моделі. Головне завдання цього рівня – визначити мову для специфікації моделей. Цей рівень є більш конструктивним, ніж попередній, оскільки володіє більш розвинутою семантикою базових понять. Всі основні поняття мови UML – це поняття рівня мета-моделі. Приклади таких понять – клас, атрибут, операція, компонент, асоціація й багато інших. Саме розгляду семантики і графічної нотації понять рівня мета-моделі присвячені наступні розділи.
Модель у контексті мови UML є екземпляром мета-моделі в тому розумінні, що будь-яка конкретна модель системи повинна використовувати тільки поняття мета-моделі, конкретизувавши їх стосовно певної ситуації. Це рівень для опису інформації про конкретну предметну область. Однак, якщо для побудови моделі використовуються поняття мови UML, необхідна повна погодженість понять рівня моделі з базовими поняттями мови UML рівня мета-моделі. Прикладами понять рівня моделі можуть служити, наприклад, імена полів проектованої бази даних, такі як ім'я і прізвище співробітника, вік, посада, адреса, номер телефону. При цьому такі поняття використовуються лише як імена відповідних інформаційних атрибутів.
Конкретизація понять моделі відбувається на рівні об'єктів. У справжньому контексті об'єкт є екземпляром моделі, оскільки містить конкретну інформацію про те, чому насправді відповідають ті чи інші поняття моделі. Прикладом об'єкту може бути такий запис у проектованій
345
базі даних: "Любомира Лугова, 25 років, викладач, вул. Сихівська, 1020, 100-0000".
Опис семантики мови UML припускає розгляд базових понять тільки рівня мета-моделі, що являє собою лише приклад або окремий випадок рівня мета-мета-моделі. Мета-модель UML є за своєю суттю швидше логічною моделлю, ніж фізичною або моделлю реалізації. Особливість логічної моделі полягає в тому, що вона зосереджує увагу на декларативній або концептуальній семантиці, опускаючи деталі конкретної фізичної реалізації моделей. При цьому окремі реалізації, що використовують таку логічну мета-модель, мають бути узгоджені з її семантикою, а також підтримувати можливості імпорту й експорту окремих логічних моделей.
Одночасно, логічна мета-модель може бути реалізована різними способами для забезпечення необхідного рівня продуктивності й надійності відповідних інструментальних засобів. У цьому полягає недолік логічної моделі, яка не містить на рівні семантики вимог, обов'язкових для її ефективної подальшої реалізації. Однак погодженість мета-моделі з конкретними моделями реалізації є обов'язковою для всіх розробників програмних засобів, що забезпечують підтримку мови UML.
Мета-модель мови UML має досить складну структуру, що містить у собі 90 мета-класів, понад 100 мета-асоціацій і майже 50 стереотипів, кількість яких зростає з появою нових версій мови. Щоб впоратися із цією складністю мови UML, всі її елементи організовані в логічні пакети. Тому розгляд мови UML на мета-модельному рівні полягає в описі трьох її найзагальніших логічних блоків або пакетів: основні елементи, елементи поведінки й загальні механізми.
Примітка
Говорячи про пакети в контексті загального опису мови, ми, за суттю, приступаємо до розгляду графічної нотації мови UML. Справа в тому, що для опису мови UML використовуються засоби самої мови, і одним з таких засобів є пакет. У загальному випадку пакет служить для групування елементів моделі. При цьому самі елементи моделі, якими можуть бути довільні сутності, віднесені до одного пакета, виступають як єдине ціле. Пакети, так само як і інші елементи моделі, можуть бути вкладені в інші пакети. Важливою особливістю мови UML є той факт, що всі види елементів моделі UML можуть бути організовані в пакети.
346
17.3. Пакети в мові UML
Пакет – основний спосіб організації елементів моделі в мові UML. Кожний пакет володіє всіма своїми елементами, тобто тими елементами, які включені в нього. Про відповідні елементи пакета говорять, що вони належать до пакету або входять у нього. При цьому кожний елемент може належати тільки до одного пакету. Своєю чергою, одні пакети можуть бути вкладені в інші пакети. У цьому випадку перші називаються підпакетами, оскільки всі елементи підпакета будуть належати більш загальному пакету. Тим самим для елементів моделі задається відношення вкладеності пакетів, що являє собою ієрархію.
Примітка
При розгляді відношення "пакет-підпакет" найбільш природно асоціювати його з більш загальним відношенням "множина-підмножина", що розглядалося в розділі 4. Дійсно, оскільки пакет можна розглядати як частковий випадок множини, така інтерпретація допомагає нам використовувати і графічні засоби для подання відповідних відношень між пакетами.
Із розділу 4 нам також відомо, що для графічного подання ієрархій можуть використовуватися графи спеціального вигляду, які називаються деревами (див. рис. 4.5-4.6). Однак у мові UML ці графічні позначення настільки модифіковані, що відповідні асоціації із загальнотеоретичними поняттями можуть складати певні труднощі для розробників-початківців. Важливо вміти асоціювати спеціальні конструкції мови UML з відповідними поняттями теорії множин і системного моделювання, що, у деякому сенсі формує стиль мислення системного аналітика. В іншому випадку не виключені прикрі помилки не тільки на початковому етапі концептуалізації предметної області, але й у процесі побудов різних подань систем.
У мові UML для візуалізації пакетів розроблена спеціальна символіка або графічна нотація, якою ми й будемо користуватися надалі. Саме з опису цієї системи позначень ми приступимо до вивчення основних елементів цієї мови.
Для графічного зображення пакетів на діаграмах застосовується спеціальний графічний символ – великий прямокутник з невеликим прямокутником, приєднаним до лівої частини верхньої сторони першого (рис. 17.2 а, б). Можна сказати, що візуально символ пакету нагадує піктограму папки в популярному графічному інтерфейсі. Всередині великого прямокутника може записуватися інформація, що відноситься до цього пакету. Якщо такої інформації немає, то всередині великого прямокутника записується ім'я пакету, що має бути унікальним у межах
347
розглянутої моделі (рис. 17.2, а). Якщо ж така інформація є, то ім'я пакету записується у верхньому маленькому прямокутнику (рис. 17.2, б).
Рис. 17.2. Графічне зображення пакету в мові UML.
Говорячи про ім'я пакету, зупинимося на загальному погодженні про імена в мові UML. У цьому випадку іменем пакету може бути рядок (або кілька рядків) тексту, що містить будь-яку кількість літер, цифр і деяких спеціальних знаків. З метою зручності специфікації пакетів прийнято як їхні імена використовувати одне або кілька іменників, наприклад, контролер, графічний інтерфейс, форма введення даних.
Перед іменем пакету може розташовуватися рядок тексту, що містить деяке ключове слово. Подібними ключовими словами є заздалегідь визначені в мові UML слова, які називають стереотипами. Такими стереотипами для пакетів є слова facade, framework, stub і topLevel. Як вміст пакету можуть використовуватися імена його окремих елементів і їх властивостей, такі як видимість елементів за межами пакету. Більш докладно стереотипи і видимість елементів будуть розглянуті в наступних розділах.
Звичайно, самі собою пакети можуть мати обмежене застосування, оскільки містять лише інформацію про склад елементів моделі, що у них входять. Не менш важливо зображати графічно відношення, які можуть мати місце між окремими пакетами. Як і в теорії графів, для візуалізації відношень у мові UML застосовуються відтинки ліній, зовнішній вигляд яких передає зміст.
Одним з типів відношень між пакетами є відношення вкладеності або включення пакетів один в одного. З одного боку, у мові UML це відношення може бути зображене без використання ліній простим розміщенням одного пакету-прямокутника всередині іншого пакетупрямокутника (рис. 17.3). Так, у цьому випадку пакет з іменем Пакет_1 містить у собі два підпакети: Пакет_2 і Пакет_3.
348
Рис. 17.3. Графічне зображення вкладеності пакетів один в одного.
Рис. 17.4. Графічне зображення вкладеності пакетів один в одного за допомогою явної візуалізації відношень включення.
З іншого боку, це саме відношення може бути зображене за допомогою відтинків ліній аналогічно до графічного подання дерева. У цьому випадку найбільш загальний пакет (мета-пакет або контейнер) зображається у верхній частині рисунку, а його підпакети – рівнем нижче. Мета-пакет з'єднується з підпакетами суцільною лінією, на кінці якої, пов'язаною з мета-пакетом, зображається спеціальний символ (знак плюс у кружечку). Цей символ означає, що підпакети є "власністю" або частиною контейнера, і, крім цих підпакетів, контейнер не містить ніяких інших підпакетів. Розглянутий вище приклад (рис. 17.3) може зображатися за допомогою явної візуалізації відношення включення (рис. 17.4).
На графічних діаграмах між пакетами можуть вказуватися й інші типи відношень, частина з яких будуть розглянуті в наступних розділах.
17.4. Основні пакети мета-моделі мови UML
349
Повертаючись до розгляду мови UML, нагадаємо, що основою її подання на метамодельному рівні є опис трьох її логічних блоків або пакетів: Основні елементи, Елементи поведінки й Спільні механізми (рис. 17.5).
Рис. 17.5. Основні пакети мета-моделі мови UML.
Ці пакети, своєю чергою, поділяються на окремі підпакети. Наприклад, пакет Основні елементи складається з підпакетів: Елементи ядра, Допоміжні елементи, Механізми розширення і Типи даних (рис. 17.6). При цьому пакет Елементи ядра описує базові поняття й принципи включення у структуру мета-моделі основних понять мови, таких як метакласи, мета-асоціації та мета-атрибути. Пакет Допоміжні елементи визначає додаткові конструкції, які розширюють базові елементи для опису залежностей, шаблонів, фізичних структур і елементів подань. Пакет Механізми розширення задає правила уточнення й розширення семантики базових елементів моделей. Пакет Типи даних визначає основні структури даних для мови UML.
Основні
елементи
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Елементи |
|
Допоміжні |
|
|
|
|
Механізми |
|
Типи даних |
||||||||||
ядра |
|
елементи |
|
|
|
|
розширення |
|
|||||||||||
|
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 17.6. Підпакети пакета Основні елементи мови UML.
Пакет Основні елементи
Нижче дається коротка характеристика елементів кожного з перерахованих підпакетів, що входять до складу пакету Основні елементи. Повний розгляд окремих компонентів мета-моделі подається в наступних розділах, присвячених вивченню окремих видів канонічних діаграм. Останні акумулюють у собі не тільки різні подання модельованої
350
системи, але й детальніше розкривають семантичні особливості застосування базових конструкцій мови UML у процесі побудови конкретних моделей.
Пакет Елементи ядра
Пакет Елементи ядра є найфундаментальнішим зі всіх підпакетів, які входять у пакет Основні елементи мови UML. Цей пакет визначає основні абстрактні й конкретні компоненти, необхідні для розроблення об'єктних моделей. При цьому абстрактні компоненти мета-моделі не мають екземплярів або прикладів і використовуються винятково для уточнення інших компонентів моделі. Конкретні компоненти мета-моделі мають екземпляри і відображають особливості подання осіб, які розробляють об'єктні моделі.
Примітка
Зазначимо, що розвиненим мовам подання знань загалом, і мові UML зокрема, властива неоднозначність виразних можливостей. Мова йде про те, що та сама модельована сутність або система може подаватися засобами мови UML по-різному. При цьому різні розробники можуть побудувати об'єктні моделі однієї і тієї самої системи, що істотно відрізняються не тільки формою свого подання, але й складом використовуваних у моделі компонентів.
Пакет Елементи ядра специфікує базові конструкції, необхідні для опису вихідної мета-моделі, і визначає архітектурний "кістяк" для приєднання додаткових конструкцій мови, таких як мета-класи, метаасоціації та мета-атрибути. Хоча пакет Елементи ядра містить семантику, достатню для визначення всієї іншої частини мови UML, він не є мата- мета-моделлю UML.
У цей пакет входять основні мета-класи мови UML: клас (Class), атрибут (Attrіbute), асоціація (Assocіatіon), асоціація-клас
(AssocіatіonClass), кінець асоціації (AssocіatіonEnd), властивість поведінки (BehavіoralFeature), класифікатор (Classіfіer), обмеження
(Constraіnt), тип даних (DataType), залежність (Dependency), елемент (Element), право на елемент (ElementOwnershіp), властивість (Feature),
узагальнення (Generalіzatіon), елемент відношення узагальнення
(GeneralіzableElement), інтерфейс (Іnterface), метод (Method), елемент моделі (ModelElement), простір імен (Namespace), операція (Operatіon),
параметр (Parameter), структурна властивість (StructuralFeature), правила правильної побудови виразів (Well-Formedness rules).
Пакет Допоміжні елементи
Пакет Допоміжні елементи є підпакетом пакету Основні елементи і специфікує додаткові конструкції мови UML, які розширюють пакет Елементи ядра. Допоміжні елементи забезпечують понятійний базис для залежностей, шаблонів, фізичних структур і елементів подань. У цей
