Unified Modeling Language

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

UML logo
Технологія розробки програмного забезпечення
Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Допоміжні дисципліни
Практики
Інструменти
Стандарти та галузі знань

Перша версія (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 є спілкування розробників між собою.[1]

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

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

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

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

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

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

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

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

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

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

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

Діаграми
Колаж з різних діаграм UML

В 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критика

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

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

Див. також

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

Посилання

Література
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.