UML англ Unified Modeling Language уніфікована мова моделювання використовується у парадигмі об єктно орієнтованого прог

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

Перша версія (1.0) UML вийшла 13 січня 1997, вона була створена консорціумом UML Partners за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних. Після обговорення, у вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG. Розробку UML підтримали і вже тоді використовували як стандарт такі гранди ринку інформаційних технологій, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Sybase, Logic Works й інші.

Поточна версія — 2.0.

Застосування

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

Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код.

Основною причиною використання мови UML є спілкування розробників між собою.

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

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

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

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

UML необхідний:

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

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

Історія створення

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

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

Протягом 1994-96 років творці трьох найпоширеніших методологій — Граді Буч (BOOCH), (OMT — Object Modeling Technique) і Айвар Якобсон (OOSE — Object Oriented Software Engineering) об'єднали свої зусилля під егідою для створення єдиної мови моделювання, яка б об'єднала всі істотні й успішні розробки в даній галузі і стала би стандартом мови об'єктного моделювання. Грандіозна робота, у якій поряд з Rational брали участь представники багатьох компаній, таких, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology і кількох сотень інших завершилася створенням у січні 1997 року UML 1.0, яка після бурхливого обговорення протягом 1997 року у вересні під версією 1.1 і була передана в OMG для прийняття як галузевий стандарт мови об'єктного моделювання.

Діаграми

В UML використовується 14 видів діаграм (для уникнення непорозумінь, також наведено англомовні назви):

Structure Diagrams:

Class diagram
Component diagram
Composite structure diagram
- Collaboration (UML2.0)
Deployment diagram
Object diagram
Package diagram

Behavior Diagrams:

Activity diagram
State Machine diagram
Use case diagram
Interaction Diagrams:
- Collaboration (UML1.x) /
  Communication diagram (UML2.0)
- Interaction overview diagram (UML2.0)
- Sequence diagram
- UML Timing Diagram (UML2.0)

Структурні діаграми:

Класів
Компонентів
Композитної/складеної структури
- Кооперації (UML2.0)
Розгортування
Об'єктів
Пакетів

Діаграми поведінки:

Діаграми взаємодії:

Кооперації (UML1.x) /
Комунікації (UML2.0)
Огляду взаємодії (UML2.0)
Послідовності
Синхронізації (UML2.0)

Структурні діаграми

(англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні архітектури програмного забезпечення.

Діаграма профілю

Діаграма профілю (англ. Profile Diagram) — діаграма профілю працює на рівні метамоделі, щоб показати стереотипи як класи зі стереотипом «стереотип», а профілі як пакети зі стереотипом «профіль». Відношення розширення (суцільна лінія із замкнутим, заповненим наконечником стрілки) вказує, який елемент метамоделі поширює даний стереотип. Діаграма профілю не існувала в UML 1. Вона була представлена в UML 2 для відображення використання профілів. До її впровадження для відображення цієї проблеми використовувалися інші діаграми.

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

Докладніше: Діаграма класів

Діаграма класів (англ. Class Diagram) — статична структурна діаграма, яка описує струкутру системи, демонструє класи системи, їхні атрибути, методи й залежності між класами.

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

Діаграма компонентів (англ. Component diagram) — статична структурна діаграма, яка показує поділ програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. В якості фізичних компонентів можуть виступати файли, бібліотеки, модулі, файли виконання, пакети й т.п.

Діаграма композитної/складеної структури

Decorator template

Діаграма композитної/складеної структури (англ. Composite structure diagram) — статична структура діаграма, яка демонструє внутрішню структура класів й, за можливістю, взаємодію елементів (частин) внутрішньої структури класу.

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

Діаграми композитної структури можуть використовуватися разом з діаграмами класів.

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

Діаграма розгортання, діаграма розміщення (англ. Deployment diagram) — слугує для моделювання працюючих вузлів (апаратних засобів, англ. node) й артефактів, які на них розгорнуті. У UML2 на вузлах розгортаються артефакти, (англ. artifact), тоді як у UML1 на вузлах розгоралися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, установлюється залежність маніфестації.

Діаграма об'єктів

Діаграма об'єктів (англ. Object diagram) — демонструє повний або частковий знімок системи, яка моделюється, у заданий момент часу. На діаграмі об'єктів відображуються примірники класів (об'єкти) системи з указанням поточних значень їхніх атрибутів й зв'язків між об'єктами.

Діаграма пакетів

Діаграма пакетів (англ. Package diagram) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.

Діаграма станів (кінцевих автоматів)

Докладніше: Діаграма станів (UML)

Діаграма синхронізації

Докладніше: Діаграма синхронізації (UML)

Призначення та рівні моделей

Залежно від цілей використання моделі можуть бути таких основних рівнів:

концептуальна модель, модель аналізу (англ. conceptual model) — модель предметної області, у ній присутні тільки класи прикладних об'єктів, використовується для управління процесом мислення, розуміння; потребує концептуальної цілісності (англ. consistency);
модель проектування (англ. design model) — високороівневий (на рівні підсистем) та низькорівневий (на рівні класів) опис програмної системи; на її основі розробляється програмний код застосунку; призначена для подальшої розробки моделей реалізації; головна вимога — зрозумілість (англ. usability).
модель реалізації (англ. implementation model) — призначена для автоматичного перетворення в інший вид, наприклад, у програмний код, який виконується; (при використанні об'єктно-орієнтованих мов програмування); головна вимога — повнота (англ. completeness).

Метамоделювання

Object Management Group (OMG) розробила архітектуру метамоделювання для визначення UML, яка називається Meta-Object Facility (MOF). MOF розроблена як чотиришарова архітектура, як показано на зображенні праворуч. Вона забезпечує мета-мета-модель у верхній частині, яка називається шаром M3. Ця M3-модель є мовою, що використовується Meta-Object Facility для побудови метамоделей, які називаються M2-моделями.

Найяскравішим прикладом мета-об'єктної моделі 2-го рівня є метамодель UML, яка описує саму мову UML. Ці M2-моделі описують елементи M1-рівня, а отже, і M1-моделі. Це можуть бути, наприклад, моделі, написані на UML. Останній рівень - це M0-рівень або рівень даних. Він використовується для опису екземплярів системи під час виконання.

Мета-модель може бути розширена за допомогою механізму, який називається стереотипізацією. Він був підданий критиці як недостатній/неприйнятний Брайаном Хендерсоном-Селлерсом та Сезаром Гонсалесом-Пересом у статті "Використання та зловживання механізмом стереотипів в UML 1.x та 2.0".

Представлення моделей

Представлення UML 1

Представлення використання

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

Представлення проектування

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

Представлення процесів

Представлення процесів (англ. Process view) — опис взаємодії елементів управління (процесів, потоків) під час роботи системи. Структурні аспекти передаються за допомогою концепції активних класів, які представляють процеси і потоки, а поведінкові аспекти — діаграмами взаємодії, стану і діяльності.

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

Представлення компонентів (англ. Component view) — опис системи на рівні артефактів (компонентів, файлів і т.д.), які використовуються для збирання, випуску, конфігурації програмного продукту. Структурні аспекти передаються діаграмами компонентів, а поведінкові аспекти — діаграмами взаємодії, стану і діяльності.

Представлення розгортання

Представлення розгортання (англ. Deployment view) — відображення топології зв'язків апаратних засобів і розміщення на них компонентів. Структурні аспекти передаються діаграмами розгортання, а поведінкові аспекти — діаграмами взаємодії, стану і діяльності.

Представлення UML 2

Статичне представлення

Статичне представлення (англ. Static view) — відображення статичної структури системи без опису динаміки у будь-якому прояві. Як правило, статичне представлення відображує логічні концепції програмного забезпечення, основою якого є класи і їх відносини.

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

Представлення проектування

Представлення проектування (англ. Design view) — більш деталізований варіант статичного представлення, з виділенням класифікацій, які забезпечують необхідну функціональність системи.

Діаграми, які використовуються для представлення проектування: діаграма внутрішньої структури, діаграма комунікації, діаграма компонентів.

Представлення використання

Представлення використання (англ. Use Case view) — опис функціонування системи у термінах варіантів використання і розглядає їх з точки зору зацікавлених дійових осіб.

Діаграми, які використовуються для представлення використання: діаграма використання (діаграма прецедентів).

Представлення кінцевих автоматів

Представлення кінцевих автоматів (англ. State machine view) — відображує поведінку окремих елементів, до яких можна застосувати поняття життєвого циклу, який описується набором станів і переходів між ними.

Діаграми, які використовуються для представлення кінцевих автоматів: діаграма кінцевих автоматів (діграма станів).

Представлення діяльності

Представлення діяльності (англ. Activity view) — опис системи з точки зору різних елементів діяльності, які поєднані потоками управління і потоками даних.

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

Представлення взаємодії

Представлення взаємодії (англ. Interaction view) — відображення послідовності обміну повідомленнями між елементами системи під час виконання додатку.

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

Представлення розгортання

Представлення управління моделлю

Критика

Попри те, що UML є широко визнаним стандартом мови моделювання, вона часто підпадає під критику через такі причини:

Надмірність мови
Неточна семантика
Проблеми у вивченні та застосуванні
Візуальна неоднорідність
Намагається подобатись усім

Див. також

Примітки

Фаулер М., Скотт К. UML. Основы. — Пер. с англ. — СПб: Символ-Плюс, 2002. [ 14 грудня 2012 у Wayback Machine.] — C. 23.
Iman Poernomo (2006) "The Meta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposium on Applied computing. pp. 1845–1849
"UML 2.4.1 Infrastructure". Omg.org. 5 August 2011. Retrieved 10 April 2014.
B. Henderson-Sellers; C. Gonzalez-Perez (2006). "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". in: Model Driven Engineering Languages and Systems. Springer Berlin / Heidelberg.

Посилання

Офіційний сайт UML [ 30 вересня 2019 у Wayback Machine.]
Журнал «Інформаційні технології», UML: історія, специфікація, бібліографія [ 13 листопада 2007 у Wayback Machine.]
UML 2.5 — заготовки та шаблони для MS Visio [ 12 листопада 2015 у Wayback Machine.]

Література

Підручник з Umbrello UML Modeller [ 14 березня 2014 у Wayback Machine.]
Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. — Пер. с англ. — М.: ДМК, 2000. — 432 с.

[Fauler-1] Фаулер М., Скотт К. UML. Основы. — Пер. с англ. — СПб: Символ-Плюс, 2002. [ 14 грудня 2012 у Wayback Machine.] — C. 23.

[2] Iman Poernomo (2006) "The Meta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposium on Applied computing. pp. 1845–1849

[3] "UML 2.4.1 Infrastructure". Omg.org. 5 August 2011. Retrieved 10 April 2014.

[4] B. Henderson-Sellers; C. Gonzalez-Perez (2006). "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". in: Model Driven Engineering Languages and Systems. Springer Berlin / Heidelberg.