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 є спілкування розробників між собою.[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 використовується 14 видів діаграм (для уникнення непорозумінь, також наведено англомовні назви):
|
Structure Diagrams:
Behavior Diagrams:
|
Структурні діаграми:
Діаграми поведінки: Діаграми взаємодії:
|
Структурні діаграми (англ. Structure Diagrams) відображають статичні стани системи. За їхньою допомогою виділяються основні елементи системи, яка проектується. Оскільки структурні діаграми відображують саме структури, вони використовуються при документуванні ��рхітектури програмного забезпечення.
Діаграма профілю (англ. 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) — структуран діаграма, основним змістом якої є пакети і відношення між ними. Жорсткий розділ між різними структурними діаграмами не проводиться, тому дана назва пропонується виключно для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутніми на інших структурних діаграмах). Діаграми пакетів служать, насамперед, в організацію елементів у групи за ознакою з метою спрощення структури та організації роботи з моделлю системи.
Залежно від цілей використання моделі можуть бути таких основних рівнів:
- концептуальна модель, модель аналізу (англ. conceptual model) — модель предметної області, у ній присутні тільки класи прикладних об'єктів, використовується для управління процесом мислення, розуміння; потребує концептуальної цілісності (англ. consistency);
- модель проектування (англ. design model) — високороівневий (на рівні підсистем) та низькорівневий (на рівні класів) опис програмної системи; на її основі розробляється програмний код застосунку; призначена для подальшої розробки моделей реалізації; головна вимога — зрозумілість (англ. usability).
- модель реалізації (англ. implementation model) — призначена для автоматичного перетворення в інший вид, наприклад, у програмний код, який виконується; (при використанні об'єктно-орієнтованих мов програмування); головна вимога — повнота (англ. completeness).
Object Management Group (OMG) розробила архітектуру метамоделювання для визначення UML, яка називається Meta-Object Facility (MOF).[2] MOF розроблена як чотиришарова архітектура, як показано на зображенні праворуч. Вона забезпечує мета-мета-модель у верхній частині, яка називається шаром M3. Ця M3-модель є мовою, що використовується Meta-Object Facility для побудови метамоделей, які називаються M2-моделями.
Найяскравішим прикладом мета-об'єктної моделі 2-го рівня є метамодель UML, яка описує саму мову UML. Ці M2-моделі описують елементи M1-рівня, а отже, і M1-моделі. Це можуть бути, наприклад, моделі, написані на UML. Останній рівень - це M0-рівень або рівень даних. Він використовується для опису екземплярів системи під час виконання.[3]
Мета-модель може бути розширена за допомогою механізму, який називається стереотипізацією. Він був підданий критиці як недостатній/неприйнятний Брайаном Хендерсоном-Селлерсом та Сезаром Гонсалесом-Пересом у статті "Використання та зловживання механізмом стереотипів в UML 1.x та 2.0".[4]
Представлення використання (англ. Use Case View) — опис поведінки системи з точки зору зовнішніх дійових осіб, опис її функціональних вимог. Структурні аспекти відображуються за допомогою діаграм варіантів використання, а поведінкові — за допомогою діаграмам взаємодії, стану і діяльності.
Представлення проектування (англ. Design View) — призначене для опису словника предметної області, тобто класів, а також допоміжних сутностей, таких як інтерфейси та кооперації. Структурні аспекти передаються діаграмами класів і об'єктів, а поведінкові — діаграмами взаємодії, стану і діяльності.
Представлення процесів (англ. Process view) — опис взаємодії елементів управління (процесів, потоків) під час роботи системи. Структурні аспекти передаються за допомогою концепції активних класів, які представляють процеси і потоки, а поведінкові аспекти — діаграмами взаємодії, стану і діяльності.
Представлення компонентів (англ. Component view) — опис системи на рівні артефактів (компонентів, файлів і т.д.), які використовуються для збирання, випуску, конфігурації програмного продукту. Структурні аспекти передаються діаграмами компонентів, а поведінкові аспекти — діаграмами взаємодії, стану і діяльності.
Представлення розгортання (англ. Deployment view) — відображення топології зв'язків апаратних засобів і розміщення на них компонентів. Структурні аспекти передаються діаграмами розгортання, а поведінкові аспекти — діаграмами взаємодії, стану і діяльності.
Статичне представлення (англ. 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. Основы. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 192 с., ил. ISBN 5-93286-032-4
- Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. — Пер. с англ. — М.: ДМК, 2000. — 432 с.
| ||||||||||||||||||||||||||||||||||||||||||