Уніфікована мова моделювання (UML - Unified Modeling Language) є стандартним інструментом для створення документованих каркасів ( "креслень") програмного забезпечення. За допомогою UML можна візуалізувати, уточняти, конструювати і документувати процес розробки програмних систем. UML розроблений таким чином, щоб задовольняти потреби при моделюванні будь-яких систем.
Концептуальна модель UML містить три основні елемента мови: базові конструкції, правила, що визначають, яким чином ці конструкції можуть поєднуватися між собою, і деякі загальні механізми мови.
UML не залежить від модельованої реальності, найкраще застосовувати його, коли процес моделювання заснований на розгляді текстового опису процесів, що відбуваються в предметній області, є ітеративним і покроковим, а сама система має чітко виражену архітектуру.
Таким чином він ідеально підходить для Уніфікованого процесу розробки.
UML - це мова для візуалізації, специфицирования, конструювання та документування артефактів програмних систем.
UML складається зі словника і правил, що дозволяють комбінувати входять до нього слова і отримувати осмислені конструкції. У мові моделювання словник і правила орієнтовані на концептуальне і фізичне уявлення системи.
Добре організований процес повинен показати, які потрібні артефакти, які ресурси необхідні для їх створення, як можна використовувати ці артефакти для того, щоб оцінити виконану роботу і керувати проектом в цілому.
В UML є чотири типи сутностей: структурні; поведінкові; группирующие; анотаційні.
Суті є основними об'єктно-орієнтованими елементами мови, з їх допомогою можна створювати коректні моделі. Структурні суті - це імена іменники в моделях на мові UML. Сім різновидів структурних сутностей знайшли своє відображення у вигляді графічного образу UML.
Клас (class) - це опис сукупності об'єктів із загальними атрибутами, операціями відносинами і семантикою. Графічно клас зображується у вигляді прямокутника, в якому записані його ім'я, атрибути і операції:
-PrivateAttribute. char #ProtectedAttribute + PublicAttribute
+Operation1 (in S. String) + Operation2 ()
Інтерфейс (interface) - це сукупність операцій, які визначають певну службу (сервіс, набір послуг), які надає клас або компонент.
На діаграмах інтерфейс зображується у вигляді кола, під яким вказується його ім'я. Інтерфейс зазвичай приєднується до реалізує його класу або компоненту.
Кооперація (collaboration) визначає взаємодію, вона являє собою сукупність ролей і інших елементів, які, працюючи разом, виробляють певний кооперативний ефект, що не зводиться до зазвичай сумі доданків. Графічно кооперація зображується у вигляді еліпса, який обмежується пунктиром, всередині звичайно укладено тільки ім'я.
Прецедент (use case) - це опис послідовності виконуваних системою дій, яка виробляє спостережуваний результат. Графічно прецедент зображується у вигляді еліпса, обмеженого безперервної лінією, що містить ім'я.
Активним класом (active class) називається клас, об'єкти якого залучені в один або кілька процесів, або ниток (threads), і тому можуть ініціювати керуючий вплив. Графічно активний клас зображується як простий клас, обмежується прямокутником з жирною лінією, і включає ім'я, атрибути і операції.
-PrivateAttribute. char #ProtectedAttribute + PublicAttribute
+Operation1 (in S. String) + Operation2 ()
Компонент (component) - це фізична замінна частина системи, яка відповідає деякому набору інтерфейсів і забезпечує його реалізацію. Графічно компонент зображується у вигляді прямокутника з вкладками, що містить ім'я.
Вузол (node) - це елемент реальної (фізичної) системи, який існує під час функціонування програмного продукту і є певний обчислювальний ресурс, що володіє деяким об'ємом пам'яті і можливістю обробки. Графічно для зображення вузла використовується куб, зазвичай містить тільки ім'я вузла.
Перераховані сім базових елементів: класи, інтерфейси, кооперації, прецеденти, активні класи, компоненти і вузли - є основними структурними сутностями, які можуть бути використані в моделі UML.
Поведінкові суті (behavioral things) є динамічними складовими моделі UML. Це дієслова мови, вони описують поведінку моделі в часі і в просторі. Існує всього два основних типи поведінкових сутностей.
Взаємодія (interaction) - це поведінка, суть якого полягає в обміні повідомленнями (messages) між об'єктами в рамках конкретного контексту для досягнення певної мети. За допомогою взаємодії можна описати як окрему операцію, так і поведінку сукупності об'єктів. Взаємодія передбачає ряд інших елементів, таких як повідомлення, послідовності дій (поведінка, ініційоване повідомленнями) і зв'язку (між об'єктами). Графічно повідомлення зображується у вигляді стрілки, над якою пишеться ім'я відповідної операції.
Автомат (state machine) - алгоритм поведінки, який визначає послідовність станів, через які об'єкт або взаємодія проходять протягом свого життєвого циклу в відповідь на різні події і реакції на ці події. За допомогою автоматів описуються поведінку окремого класу або кооперації класів. З автоматом пов'язаний ряд інших елементів: стану, переходи з одного стану в інший, події - сутності ініціюють переходи і види дій - реакція на переходи.
Взаємодії і автомати є основними поведінковими сутностями, що входять в модель UML. Семантично вони часто бувають пов'язані з різними структурними елементами, в першу чергу з класами, кооперації та об'єктами.
Групуються суті є організують частинами моделі UML. Це блоки, на які можна розкласти модель.
Така первинна сутність є в єдиному екземплярі - це пакет.
Пакети (packages) представляють собою універсальний механізм організації елементів в групи. У пакет можна помістити структурні, поведінкові та інші группирующие суті. На відміну від компонентів пакети носять чисто концептуальний характер і існують тільки в процесі розробки.
У мові UML визначено чотири типи відносин: · залежність; · Асоціація; · Узагальнення; · Реалізація. Ці відносини є основними сполучними конструкціями в UML і застосовуються для побудови коректних моделей.
Залежність (dependency) - це семантичне відношення між двома сутностями, при якому зміна однієї з них, незалежної, може вплинути на семантику іншого, залежною.
Асоціація (association) - структурний ставлення, яке описує сукупність зв'язків, де під зв'язком розуміється деяка смислова зв'язок між об'єктами. Різновидом асоціації є агрегування (aggregation) - так називається структурний відношення між цілим і його частинами. Графічно асоціація зображується у вигляді лінії, поруч з якою можуть бути присутніми додаткові позначення.
Узагальнення (generalization) - це відношення "спеціалізація / узагальнення", при якому об'єкт спеціалізованого елемента (простіше кажучи, нащадок) може бути підставлений замість об'єкта узагальненого елемента (одного з батьків, предка). Як і належить в об'єктно-орієнтованому програмуванні, нащадок (child) успадковує структуру і поведінку свого предка (parent). Графічно відношення узагальнення зображається у вигляді лінії з незафарбовані стрілкою, що вказує на предка.
Реалізація (realization) - це семантичне відношення між класифікаторами, при якому один класифікатор визначає зобов'язання, а інший гарантує його виконання. Ставлення реалізації зустрічаються в двох випадках: між інтерфейсами і реалізують їх класами або компонентами і між прецедентами і реалізують їх кооперації. Ставлення реалізації зображується у вигляді пунктирною лінії з незафарбовані стрілкою.
Існують також їх варіанти, наприклад уточнення (refinement), трасування (trace), включення та розширення для залежностей.
Діаграма в UML - це графічне представлення набору елементів, зображуване у вигляді пов'язаного графа з вершинами (сутностями) і ребрами (відносинами).
Основна мета діаграм - візуалізація розроблюваної системи з різних точок зору. Діаграми дають згорнуте представлення елементів, з яких складається розробляється система. Один і той же елемент може бути присутнім у всіх діаграмах, або тільки в декількох (самий часто зустрічається варіант), або не бути присутнім в жодній (дуже рідко). Відповідно до теорії діаграми можуть містити будь-які комбінації сутностей, проте в практиці моделювання застосовується порівняно невелика кількість типових комбінацій, кожна з яких відповідає одному з п'яти найбільш необхідних видів, складових архітектуру програмної системи. Таким чином, в UML визначені дев'ять типів діаграм.
Діаграма класів (class diagram), на яких показують класи, інтерфейси, об'єкти і кооперації, відносини. При моделюванні об'єктно-орієнтованих систем цей тип діаграм використовує найбільш часто.
Діаграми об'єктів (object diagram), на яких представляються об'єкти і відносини між ними. Це статичні знімки примірників сутностей, показаних на діаграмах класів.
Діаграми прецедентів (use case diagram), на яких представлені прецеденти, актори (окремий випадок класів), відносини між ними. Діаграми прецедентів відносяться до статичного виду системи з точки зору можливостей її використання. Це вид діаграм особливо важливий при організації і моделювання поведінки системи.
Діаграми взаємодії, на яких представлені зв'язку між об'єктами, показані, зокрема, повідомлення, якими об'єкти можуть обмінюватися. Зазвичай розглядаються два окремих випадки діаграм: діаграми послідовностей (sequence diagram), які відображають тимчасову упорядкованість повідомлень, і діаграми кооперації (collaboration diagram), на яких показана структурна організація обмінюються повідомленнями об'єктів. Ці види діаграм є ізоморфними, тобто вільно можуть бути трансформовані один в одного.
Діаграми станів (statechart diagram) представляють автомат, що включає в себе стану, переходи, події і види дій. Ці діаграми відносяться до динамічного виду системи, особливо важлива їх роль при моделюванні поведінки інтерфейсу, класу або кооперації.
Діаграми діяльності (activity diagram) - це окремий випадок діаграм станів. На діаграмі представляються переходи потоку управління від однієї діяльності до іншої всередині системи. Цей вид діаграм відноситься до динамічних уявленням системи, і є найбільш корисним при моделюванні її функціонування, так як відображає передачу потоку управління між об'єктами.
Діаграми компонентів (component diagram), на яких представлена організація сукупності компонентів і існуючі між ними залежності. Діаграми компонентів відносяться до статистичного увазі системи з точки зору реалізації. Вони можуть бути пов'язані з діаграмами класів в силу дуже простий причини: один компонент зазвичай відображається на один або кілька класів, інтерфейсів або кооперацій.
Діаграми розгортання (deployment diagram), на яких представлена конфігурація обробних вузлів системи і розміщених в них компонентів. Діаграми розгортання відносяться до статичного виду системи з точки зору розгортання. Вони пов'язані з діаграмами компонентів, оскільки в вузлі зазвичай розміщуються один або кілька компонентів.
Конструкції UML можна об'єднувати один з одним в довільному порядку. В UML існує набір правил, які визначають, як повинна виглядати добре оформлена модель.
Семантичні правила, які є в UML, дозволяють коректно і однозначно визначати:
· Імена, які можна давати сутностей, відносин і діаграм;
· Області дії - контексти, в яких ім'я має деяке значення;
· Видимість, коли імена видимі і можуть використовуватися іншими елементами;
· Цілісність, як елементи повинні правильно і злагоджено співвідноситися один з одним;
· Виконання, що означає виконати або імітувати певну динамічну модель.
Моделі, які створюються в процесі розробки програмних продуктів, з часом мають властивість еволюціонувати, і можуть неоднозначно розглядатися різними членами команди розробників в різний час.
З цієї причини створюються не тільки добре оформлені моделі, а й такі, які:
· Містять приховані елементи (ряд елементів не показують, щоб спростити сприйняття);
· Неповні (окремі елементи пропущені);
· Неузгоджені (цілісність моделі не гарантується).
ЗАГАЛЬНІ МЕХАНІЗМИ МОВИ UML
Моделювання спрощується і ведеться більш ефективно, якщо дотримуватися деяких угод. Роботу з UML істотно полегшує послідовне використання загальних механізмів: · специфікації (specifications); · Доповнення (adornments); · Прийняті ділення (common divisions); · Механізми розширення (extensibility mechanisms).
При моделюванні об'єктно-орієнтованих систем реальність ділиться з урахуванням двох методів.
По-перше, існує поділ на класи і об'єкти. Клас - це абстракція, а об'єкт - конкретне втілення цієї абстракції. У зв'язку з цим, практично всі конструкції мови характеризуються дихотомією "клас / об'єкт". Наприклад, є прецеденти і екземпляри прецедентів, компоненти і екземпляри компонентів, вузли та екземпляри вузлів і т. Д. У графічному поданні для об'єкта прийнято використовувати той же символ, що і для класу, а назва підкреслювати.
По-друге, існує поділ на інтерфейс і його реалізацію. Інтерфейс декларує зобов'язання, а реалізація представляє конкретне втілення цих зобов'язань і зобов'язується точно слідувати оголошеної семантиці інтерфейсу. А в зв'язку з цим, майже всі конструкції UML характеризуються дихотомією "інтерфейс / реалізація".
Механізми розширення UML включають:
· Стереотипи (stereotype), які розширюють словник UML, дозволяючи на основі існуючих блоків мови створювати нові, специфічні для вирішення конкретної проблеми;
· Помічені значення (tagged value), які розширюють властивості основних конструкцій UML, дозволяючи включати нову інформацію в специфікацію елемента;
· Обмеження (constraints), які розширюють семантику конструкцій UML, дозволяючи створювати нові і скасовувати існуючі правила.
За допомогою механізмів розширення можна створювати нові конструкції мови, модифікувати існуючі та навіть змінювати їх семантику.
Модель - це спрощення реальності, абстракція, яка створюється для кращого розуміння системи. Система, дуже часто розкладена на ряд підсистем, - це безліч елементів, організованих певним чином для виконання певної мети. Системи описується набором моделей, по можливості розглядають її з різних точок зору. Важливими складовими частинами моделі є структурні сутності.
В UML всі абстракції програмної системи організовуються у вигляді моделей, кожна з яких представляє відносно незалежний, але важливий аспект, що розробляється. Для візуалізації абстракцій можна використовувати діаграми.
В UML передбачені кошти для графічного представлення систем і підсистем. Така нотація дозволяє візуалізувати декомпозицію системи на менші підсистеми.
Система (system), можливо розкладена на ряд підсистем, - це безліч елементів, організованих певним чином для виконання певної мети. Підсистема (subsystem) - це об'єднання елементів, ряд яких складає специфікацію поведінки, запропонованого іншими її елементами.
Система є тією самою сутністю, для якої розробляється модель, і охоплює всі артефакти, що складають цю сутність, включаючи моделі і елементи цих моделей, такі як класи, інтерфейси, компоненти, вузли і зв'язки між ними.
Основне відношення між системами і підсистемами - це агрегування. Система (ціле) може складатися з нуля і більше підсистем (частин).
Модель - це спрощення реального світу, реальність в ній описується в контексті модельованої системи, це абстракція системи.