Уніфікована мова моделювання (Unified Modeling Language - UML)

Zosym Maxym

Jun 14, 2023 • 7 min read

Уніфікована мова моделювання (Unified Modeling Language - UML) - це мова моделювання загального призначення, яка призначена для забезпечення стандартного способу візуалізації проектування системи.

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

Створення UML спочатку було мотивоване бажанням стандартизувати розрізнені нотаційні системи та підходи до проектування програмного забезпечення. Вона була розроблена в компанії Rational Software в 1994-1995 роках, а її подальший розвиток відбувався під їхнім керівництвом до 1996 року[1].

У 1997 році UML була прийнята як стандарт Групою управління об'єктами (Object Management Group - OMG), і з тих пір знаходиться під управлінням цієї організації. У 2005 році UML також був опублікований Міжнародною організацією зі стандартизації (ISO) як затверджений стандарт ISO. З того часу стандарт періодично переглядається, щоб охопити останню версію UML.

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

Історія уніфікованої мови моделювання (Unified Modeling Language - UML)

Перед UML 1.0

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

Спочатку вона базувалася на нотаціях методу Буха, методу об'єктного моделювання (ОМТ) та об'єктно-орієнтованої програмної інженерії (ООІ), які були інтегровані в єдину мову.

Історія об'єктно-орієнтованих методів та нотації

Корпорація Rational Software найняла Джеймса Рамбо з General Electric у 1994 році, і після цього компанія стала джерелом двох найпопулярніших об'єктно-орієнтованих підходів до моделювання на сьогоднішній день: Метод об'єктного моделювання Румбо (object-modeling technique - OMT) та метод Грейді Буча (Grady Booch). Незабаром їм у цьому допоміг Івар Якобсон (Ivar Jacobson), творець об'єктно-орієнтованого методу розробки програмного забезпечення (object-oriented software engineering - OOSE), який приєднався до них в Rational в 1995 році.

UML 1.x

Під технічним керівництвом цих трьох (Румбо, Якобсон і Буч) у 1996 році було організовано консорціум під назвою UML Partners, який завершив розробку специфікації Уніфікованої мови моделювання (Unified Modeling Language - UML) і запропонував її Групі управління об'єктами (Object Management Group - OMG) для стандартизації.

До партнерства також увійшли інші зацікавлені сторони (наприклад, HP, DEC, IBM і Microsoft). Проект UML 1.0 від UML Partners був запропонований консорціумом OMG у січні 1997 року. Того ж місяця UML Partners сформували групу, призначену для визначення точного значення мовних конструкцій, під головуванням Кріса Кобрина та під керівництвом Еда Ейхоскдксахдксахдскдаса

специфікацію та інтегрувати її з іншими зусиллями зі стандартизації. Результат цієї роботи, UML 1.1, було представлено на розгляд OMG у серпні 1997 року і прийнято OMG у листопаді 1997 року.

Після першого випуску було сформовано робочу групу для покращення мови, яка випустила кілька незначних редакцій, 1.3, 1.4 та 1.5.

Створені нею стандарти (як і оригінальний стандарт) були відзначені як неоднозначні та непослідовні.

Нотація кардинальності

Як і у випадку з діаграмами баз даних Chen, Bachman та ISO ER, моделі класів визначені для використання кардинальності "look-across", хоча деякі автори (Merise, Elmasri & Navathe серед інших) надають перевагу односторонній або "look-here" для ролей, а також мінімальній та максимальній кардинальності. Нещодавні дослідники (Feinerer, Dullea та ін.) показали, що техніка "подивись навпроти", яка використовується в UML та ER-діаграмах, є менш ефективною та менш узгодженою, коли застосовується до n-арних відношень, порядок яких строго більший за 2.

Файнерер каже: "Проблеми виникають, якщо ми оперуємо семантикою перехресних зв'язків, яка використовується для асоціацій UML. Хартманн досліджує цю ситуацію і показує, як і чому різні перетворення зазнають невдачі.", і: "Як ми побачимо на наступних сторінках, наскрізна інтерпретація вводить кілька труднощів, які перешкоджають розширенню простих механізмів від бінарних до n-арних асоціацій".

UML 2

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

Хоча UML 2.1 так і не був випущений як офіційна специфікація, версії 2.1.1 і 2.1.2 з'явилися в 2007 році, а потім UML 2.2 в лютому 2009 року. UML 2.3 був офіційно випущений у травні 2010 року. UML 2.4.1 була офіційно випущена в серпні 2011 року. UML 2.5 було випущено у жовтні 2012 року як версію "У процесі розробки", а офіційно випущено у червні 2015 року. Офіційна версія 2.5.1 була прийнята в грудні 2017 року.

Специфікація UML 2.x складається з чотирьох частин:

Надбудова, яка визначає нотацію та семантику для діаграм та їхніх модельних елементів
Інфраструктура, яка визначає основну метамодель, на якій базується надбудова
Мова об'єктних обмежень (Object Constraint Language, OCL) для визначення правил для елементів моделі
Обмін діаграмами UML, який визначає, як відбувається обмін макетами діаграм UML 2

До UML 2.4.1 останніми версіями цих стандартів були:

UML Superstructure версія 2.4.1
UML Infrastructure версія 2.4.1
OCL версія 2.3.1
UML Diagram Interchange версія 1.0.

Починаючи з версії 2.5, специфікація UML була спрощена (без надбудови та інфраструктури), і зараз це останні версії цих стандартів:

Специфікація UML 2.5.1
OCL версія 2.4

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

Дизайн

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

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

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

Методи розробки ПЗ

UML не є методом розробки сам по собі; однак він був розроблений для сумісності з провідними об'єктно-орієнтованими методами розробки програмного забезпечення свого часу, такими як OMT, Booch method, Objectory і особливо RUP, з якими він спочатку призначався для використання, коли починалася робота в Rational Software.

Моделювання

Важливо розрізняти UML-модель і набір діаграм системи. Діаграма - це часткове графічне представлення моделі системи. Набір діаграм не обов'язково повинен повністю покривати модель, і видалення діаграми не змінює модель. Модель може також містити документацію, яка керує елементами моделі та діаграмами (наприклад, письмові варіанти використання).

Діаграми UML представляють два різних погляди на модель системи:

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

UML-моделями можна обмінюватися між інструментами UML за допомогою формату обміну метаданими XML (XML Metadata Interchange, XMI).

В UML одним з ключових інструментів для моделювання поведінки є модель варіантів використання (use-case model), викликана OOSE. Варіанти використання - це спосіб визначення необхідних варіантів використання системи. Зазвичай вони використовуються для фіксації вимог до системи, тобто того, що система повинна робити.

Діаграми

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

Всі ці діаграми можуть містити коментарі або примітки, що пояснюють використання, обмеження або наміри.

Структурні діаграми (Structure diagrams)

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

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

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

Діаграма сценаріїв використання (Use case diagram)

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

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

Діаграма Послідовності (Sequence Diagrams)

Комунікаційна схема (Communication diagram)

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

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

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

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

Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.