Тема 6. Основні компоненти універсальної мови моделювання UML

1 2 3 4 5 6 7 8 9 10

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

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

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

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

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

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

К&нвчньй гіуіьі&ЙЙЇИІЬ Внешние и внутренние структурные отношения

Предсгйипении происисл фу и кц" и ній ро в ан ии

Погичвсков прерст-авленив

Сметанный интегратор Гпоиойпл.чрлшйсть и масщпвн^амоса киманентве системы

Првдсі>ВЛ«іріі| рсэни)йцми

МОДЄРІЬ СЛОЖНОМ системы

Ли н^ии чесная модель сложней

СИІІЇНМ

Прогрзичис-Ї Отчошекич МРЗДУ кпмгсанентэчн Прогримілий го обеспечения

Прйдср&Вліжмі; |нїу їиііния ко ип он вн то и

Системный администратор Т(л0л0гия изиирс с Р?С П и коммуникаций юо^паивмтї

Стати- четная иодепь -сложней «стоны

СИСТР иы

Л V

Концептуальная иолепі. Сложней сн стены

Физическая модель сложной снпдаи

Рис. 6.1. Загальна схема взаємозв'язків моделей і представлень складної системи в процесі об'єктно-орієнтованого аналізу і проектування

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

Призначення мови имі

Мова имь призначена для вирішення наступних задач:

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

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

3. Опис мови имь повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних мов програмування і інструментальних засобів проектування програмних систем.

4. Опис мови имь повинен включати в себе семантичний базис для розуміння загальних особливостей ООАП.

5. Сприяти розвитку ринку об'єктних інструментальних засобів.

6. Сприяти розповсюдженню об'єктних технологій і відповідних понять

ООАП.

7. Інтегрувати в себе новітні і найкращі досягнення практики ООАП.

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

Загальна структура мови

З самої загальної точки зору опис мови ЦМЬ складається з двох взаємодіючих частин, таких як:

- Семантика мови ЦМЬ. Представляє собою деяку метамодель, яка визначає абстрактний синтаксис і семантику понять об'єктного моделювання на мові ЦМЬ.

- Нотація мови ЦМЬ. Представляє собою графічну нотацію для візуального представлення семантики мови ЦМЬ.

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

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

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

Формальний опис самої мови ЦМЬ базується на деякій загальній ієрархічній структурі модельних представлень, які складається з чотирьох рівнів:

- Мета-метамодель;

- Метамодель;

- Модель;

- Об'єкти користувача.

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

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

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

Конкретизація понять моделі відбувається на рівні об'єктів. В даному контексті об'єкт є екземпляром моделі, оскільки містить конкретну інформацію відносно того, чому в дійсності відповідають ті чи інші поняття моделі. Прикладом об'єкта може служити наступний запис в проектованій базі даних: «Іван Петренко, 30 років, програміст, вул. Невидима, 10-20, 100-0000».

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

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

Моделями реалізації є обов'язковою для всіх розробників програмних засобів, які забезпечують підтримку мови ЦМЬ.

Метамодель мови имь має доволі складну структуру, яка включає в себе порядку 90 метакласів, більше 100 метаасоціацій і майже 50 стереотипів, кількість яких зростає з появою нових версій мови. Щоб справитися з цією складністю мови ЦМЬ, всі його елементи організовані в логічні пакети.

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

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

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

Имя пакета

Содержимое пакета

А) 6)

Рис. 6.2. Графічне зображення пакету мовою UML

Перед іменем пакету може розміщуватися стрічка тексту, яка містить деяке ключове слово - стереотип. Такими стереотипами для пакетів є слова facade, framework, stub і toplevel. Як вміст пакету можуть виступати імена його окремих елементів і їх властивості, такі як видимість елементів за межами пакету.

$Описание: E:\..\A261~1\AppData\Local\Temp\FineReader10\media\image3.jpeg$

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

$Описание: E:\..\A261~1\AppData\Local\Temp\FineReader10\media\image4.jpeg$

Рис. 3.4. Графическое изображение вложенности пакетов друг в друга с помощью явной визуализации отношения включения

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

Основні пакети мета-моделі мови UML

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

Ці пакети у свою чергу діляться на окремі підпакети.

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

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

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

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

- Семантики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Діаграма варіантів використання;

- Діаграма класів;

- Діаграма станів;

- Діаграма діяльності;

- Діаграма послідовності;

- Діаграма кооперації;

- Діаграма компонентів;

- Діаграма розгортання.

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

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

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

Особливості зображення діаграм мови имі

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

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

- Зв'язки, які представляються різними лініями на площині.

- Текст, який міститься в межах окремих геометричних фігур.

- Графічні символи, що зображаються поруч тих чи інших візуальних елементів діаграм.

Таким чином, в мові имь використовується чотири основних види графічних конструкцій:

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

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

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

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

При графічному зображенні діаграм потрібно дотримуватися наступних основних рекомендацій:

- Кожна діаграма повинна служити закінченим представленням відповідного фрагменту модельованої предметної області.

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

- Вся інформація про сутності повинна бути явно представлена на діаграмах.

- Діаграми не повинні містити суперечної інформації.

- Діаграми не потрібно перевантажувати текстовою інформацією.

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

- Кількість типів діаграм для конкретної моделі не є строго фіксованим.

Будь-яка з моделей системи повинна містити тільки ті елементи, які

Визначені в нотації мови UML.

Процес побудови окремих типів діаграм має свої особливості, які тісно зв'язані з семантикою елементів цих діаграм. Сам процес ООАП в контексті мови UML отримав спеціальну назву - раціональний уніфікований процес (Rational Unified Process, RUP). Концепція RUP і основні його елементи розроблені А. Джекобсоном в ході його роботи над мовою UML.

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

1 2 3 4 5 6 7 8 9 10 Наверх ↑