Вступ до OMG’s Unified Modeling Language™ (UML®)

This article was originally written in English by Object Management Group. The English-language version of this article is the normative version and can be found at http://www.uml.org/what-is-uml.htm

(Оновлено у липні 2005 року, щоб репрезентувати офіційне прийняття UML 2.0 Superstructure)

 

 

Великі корпоративні додатки — ті, які підтримують ключові бізнес-додатки та забезпечують роботу компанії — це не просто зібрання модулів коду. Вони повинні бути структуровані таким чином, щоб забезпечити масштабованість, безпеку та надійну роботу в стресових умовах, і їх структура, часто згадувана як їх архітектура, повинна бути чітко визначена, щоб програмісти технічного обслуговування могли (швидко!) знаходити та виправляти помилку, яка з’являється після того, як оригінальні автори перейшли до інших проектів. Тобто, ці програми повинні бути розроблені таким чином, щоб відмінно працювати у багатьох сферах, бізнес-функціональність не єдина (хоча це, безумовно, це головна необхідність). Звичайно, добре спроектована архітектура має переваги будь-якій програмі, а не просто у найбільших, як ми вже тут зазначили. Ми згадали великі додатки першими, оскільки структура — це спосіб боротьби з ускладненістю, тому переваги структури (і моделювання та дизайну, як ми продемонструємо) ростуть, як тільки розмір програми збільшується. Іншою перевагою структури є те, що це дозволяє повторно використовувати код: час проектування — це найпростіший час для структурування додатку як колекції автономних модулів або компонентів. Зрештою, підприємства створюють бібліотеку моделей компонентів, кожна з яких представляє собою реалізацію, що зберігається в бібліотеці кодів модулів. Якщо інша програма потребує такої ж функції, конструктор може швидко імпортувати цей модуль з бібліотеки. Під час кодування розробник може так само швидко імпортувати модуль коду в додаток.

 

Моделювання — це проектування програмного забезпечення перед написанням коду. Моделювання є важливою частиною великих програмних проектів, і корисно для середніх і навіть невеликих проектів. Модель відіграє аналогічну роль у розробці програмного забезпечення, яку при будівництві хмарочосу відіграють креслення та інші плани (карти місця, висоти, фізичні моделі). Використовуючи модель, ті, хто відповідає за успіх проекту розробки програмного забезпечення, можуть впевнитися, що бізнес-функціональність є повною та правильною, потреби кінцевого користувача задовольняються, а розробка програм підтримує вимоги до масштабованості, надійності, безпеки, розширюваності та інших характеристик до того, як їх доведеться важко і дорого робити зміни в уже реалізованому коді. Опитування показують, що великі програмні продукти мають величезну ймовірність невдачі — і справді, більш ймовірно, що велике програмне забезпечення не зможе вкластися у часові та бюджетні рамки, ніж що запуск буде успішним. Якщо ви запускаєте один з таких проектів, вам потрібно зробити все можливе, щоб збільшити шанси на успіх, а моделювання  — це єдиний спосіб візуалізувати свій дизайн та протестувати його на відповідність вимогам, перш ніж ваша команда почне писати код.

 

Підвищення рівня абстрагування

 

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

 

Unified Modeling Language™ OMG (UML®) допомагає вам уточнювати, візуалізувати та документувати моделі програмного забезпечення, включаючи їх структуру та дизайн таким чином, щоб відповідати усім зазначеним вище вимогам. (Ви також можете використовувати UML для бізнес-моделювання та моделювання інших непрограмних систем.) Використовуючи будь-який з величезної кількості інструментів на базі UML, представлених на ринку, ви можете проаналізувати свої вимоги до майбутньої програми та спроектувати рішення, яке їх задовольнить, презентуючи його за допомогою тринадцяти стандартних типів діаграм UML 2.0. Ви можете моделювати в UML практично будь-який тип програми чи додатку, що працює під будь-яким типом і у будь-яких поєднаннях обладнання, операційної системи, мови програмування та мережі. Ця гнучкість дозволяє моделювати дистрибутивні додатки, які використовують лише проміжні продукти на ринку. Побудована на фундаментальних концепціях OO, включаючи клас і операцію, це природно підходить для об’єктно-орієнтованих мов та середовищ, таких як C++, Java та відносно новий C#, але ви також можете використовувати його для моделювання не-OO-додатків, наприклад, Fortran, VB або COBOL. Профілі UML (тобто підмножини UML, призначені для конкретних цілей) допомагають вам моделювати транзакційні системи, системи реального часу та системи, що не допускають помилки, природним способом.

 

Ви також можете робити інші корисні речі з UML

 

Наприклад, деякі інструменти аналізують існуючий вихідний код (або, як деякі стверджують, об’єктний код!) та зворотно проектують у набір UML-діаграм. Інший приклад. Деякі інструменти на ринку використовують UML-моделі, як правило, одним із двох способів: деякі інструменти інтерпретують вашу модель таким чином, щоб дозволити вам підтвердити, що вона справді робить те, що ви хочете, але без такої масштабованості та швидкості, які будуть необхідні у вашому розгорнутому додатку. Інші інструменти (зазвичай розроблені для роботи лише у сфері обмеженого застосування, як наприклад телекомунікації або фінанси) створюють код мови програми з UML, продукуючи більшу частину безпомилкової розгорнутої програми, яка працює швидко, якщо генератор коду включає в себе найкращі практичні масштабовані шаблони для, наприклад, транзакційних операцій баз даних або інших загальних завдань програми. (Команда OMG працює над специфікацією для Executable UML зараз.) Наша остання позиція у цій категорії: ряд інструментів на ринку генерують тестові та верифікаційні набори з UML-моделей.

 

UML AND OMG’S MODEL DRIVEN ARCHITECTURE® (MDA®)

 

Кілька років тому (насправді, напрочуд мало!) найбільша проблема, з якою стикався розробник, коли розпочинав проект дистрибутивного програмування, полягала у пошуку проміжного програмного забезпечення з необхідною функціональністю, яке б запускалося на базі обладнання та операційних систем, якими він користувався. Сьогодні, зіткнувшись з надзвичайно багатим набором платформ проміжного програмного забезпечення, розробник має три різні проблеми проміжного програмного забезпечення: по-перше, вибрати одне; по-друге, змусити його працювати з іншими платформами, вже розгорнуті не тільки у власній компанії, а й у його клієнтів та постачальників; і, по-третє, взаємодіяти з (або, що ще гірше, перейти до) новою «наступною найкращою штукою», коли з’являється нова платформа, яка скрізь привертає увагу аналітиків і, обов’язково, CIO.

 

Завдяки своїй багатій палітрі та незалежному проміжному програмному забезпеченню, UML є основою моделі Model Driven Architecture® (MDA®) OMG. Фактично, UML-модель може бути незалежною від платформи або специфічною для платформи, як ми обираємо, і процес розробки MDA використовує обидві ці форми: кожен стандарт або додаток MDA заснований, нормативно, на платформі незалежної моделі (PIM), який дуже точно відображає його бізнес-функції та поведінку, але не включає технічні аспекти. З PIM, інструменти розробки з підтримкою MDA використовують стандартизовані OMG відображення для створення однієї або декількох специфічних для платформи моделей (PSM), а також у UML, по одній для кожної цільової платформи, яку розробник вибирає. (Цей крок перетворення дуже автоматизований, але не магічний: перш ніж інструмент видає PSM, розробник повинен анотувати базовий PIM, щоб створювати більш специфічний, але все ще незалежний від платформи PIM, який включає в себе деталі потрібної семантики та керує вибором інструменту, який ми повинні обрати. Через подібності (схожості) серед платформ проміжного програмного забезпечення заданого жанру — компонентного або на основі обміну повідомленнями — ці вказівки можуть бути включені в PIM без подання специфічної платформи. Проте, розробникам доведеться налаштувати утворені PSM для певного розширення; більше в перші дні MDA, але згодом все менше і менше, так як інструменти та алгоритми покращуються.)

 

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

 

Програми MDA схожі: якщо ви імпортуєте PIM-файли для модулів, служб або інших MDA-додатків у свій інструмент розробки, ви можете спрямувати його на генерування запитів за допомогою будь-яких інтерфейсів та протоколів навіть якщо вони запущені на різних платформах. А ще додатки MDA є перевіреними майбутнім: коли з’явиться нова «наступна найкраща штука», команда OMG генерує і стандартизує відображення до неї, а ваш постачальник оновить свій інструмент, що підтримує MDA, щоб ту нову найкращу штуку до нього включити. Скориставшись цими розробками, ви зможете генерувати міжплатформенні запити на новій платформі і навіть портувати у нього наявні програми MDA, автоматично використовуючи ваші існуючі PIM-файли.

 

Моделі та методології

 

Процес збору та аналізу вимог програми та їх включення у програму розробки є складним, зараз галузь підтримує безліч методологій, що визначають формальні процедури, в яких описано, як це все зробити. Одна з характеристик UML — вона не залежить від методології. Незалежно від методології, яку ви використовуєте для виконання аналізу та дизайну, ви можете використовувати UML для вираження результатів. І, використовуючи XMI® (XML Metadata Interchange, інший стандарт OMG), ви можете перенести свою модель UML з одного інструмента у сховище або в інший інструмент для виправлення або наступного кроку у вибраному процесі розробки. І це переваги стандартизації!


Що ви можете моделювати з UML?

 

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

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

 

Ми не хочемо, щоб ця ознайомлювальна веб-сторінка була повноцінним UML-підручником, тому не будемо перелічувати жодні подробиці різних типів діаграм тут. Щоб дізнатись більше, ви можете ознайомитись з одним із багатьох онлайнових навчальних посібників або придбати книгу. (Останній раз, коли ми перевірили, набравши «UML» у вікно пошуку для основних онлайн-книгарень, запит видав список із більш ніж 100 найменувань!) Або, якщо ви спеціаліст і хочете знати все, ви можете завантажити саму специфікацію UML на веб-сайті OMG. Це, звичайно, безкоштовно, але також дуже спеціалізовано і лаконічно, тому початківцям буде дуже важко зрозуміти. (Трохи більше абзаців про те, чому специфікації важко читати, подивіться тут.)

 

Я збираюся розпочати свій перший проект, що базується на UML. Що мені потрібно робити?

 

Три речі, ймовірно (але не обов’язково) в цьому порядку:

  1. Оберіть методологію: Методологія формально визначає процес, який ви використовуєте для збору вимог, аналізує їх та розробляє програму, яка їм відповідає. Існує багато методологій, кожна з яких по-своєму відрізняється від інших. Є багато причин, чому одна методологія може бути кращою за іншу для вашого конкретного проекту: наприклад, деякі з них краще підходять для великих корпоративних програм, а інші — для розробки невеликих вбудованих або критично захищених систем. На іншій осі методології, які краще підтримують велику кількість архітекторів та дизайнерів, що працюють над одним проектом, тоді як інші працюють краще при використанні однією людиною або невеликою групою.OMG, як нейтральна організація, не має власної точки зору про жодну з методологій.
  2. Виберіть інструмент розробки UML: оскільки більшість (хоча й не всі) інструменти на базі UML реалізують певну методологію, в деяких випадках може бути недоцільно вибрати інструмент, а потім спробувати використати його за методологією, яка не була для цього призначена. (Для інших комбінацій інструментів/методологій це може бути не проблема, або це можна буде легко обійти.) Але деякі методології були впроваджені на декількох інструментах, тому це не суто єдине вибране середовище. Ви можете знайти такий інструмент, який найкраще підходить для вашої програми чи організації, тому захочете змінити методології для його використання. Якщо це так, продовжуйте — наша порада спершу вибрати методологію є загальною, вона може не підходити для конкретного проекту. Інша можливість: ви можете знайти методологію, яка вам подобається, але яка не реалізована в інструменті, що відповідає розмірам вашого проекту або його бюджету, тому вам потрібно буде її змінити. Якщо будь-який із цих випадків трапляється з вами, спробуйте вибрати альтернативну методологію, яка не надто сильно відрізняється від тієї, яку ви спочатку хотіли.Як і у випадку з методологією, OMG не має думки про інструменти моделювання чи їх рейтинг на основі UML, але у нас є посилання на декілька списків тут. Це допоможе вам розпочати свій вибір.
  3. Пройдіть тренінг: Вам і вашому персоналу (якщо вам не пощастило найняти досвідчених архітекторів UML) потрібно буде пройти тренінг в UML. Найкраще буде підібрати тренінг, який навчить як використовувати обраний інструмент з обраною методологією, яка зазвичай забезпечується постачальником інструментів або методологістом. Якщо ви вирішите не йти цим шляхом, перегляньте навчальну сторінку OMG та знайдіть курс, який відповідає вашим потребам. Як тільки ви дізналися про UML, ви можете стати OMG-сертифікованим UML професіоналом — перегляньте тут детальну інформацію.

 

UML 2.0 — ключове оновлення

 

«Доступна» версія специфікацій UGB 2.0 Superstructure (тобто версії, яка здійснила перший реліз технічного обслуговування та була вбудована в продукти постачальників) була завершена і доступна для вільного завантаження. Три окремі частини UML 2.0 – Інфраструктура (тобто мета-метамоделі), Object Constraint Language та Діаграма обміну все ще проходять перше технічне обслуговування і стануть доступними специфікаціями, коли процес завершиться. Тут є опис поточного стану всіх чотирьох специфікацій, а також посилання на всі.


Що нового в UML 2.0

 

Ми вже інтегрували нові функції в цей текст, але ось короткий зміст:

 

  • Вкладені класифікатори: це надзвичайно потужна концепція. У UML класифікатором є майже кожен типовий будівельний блок, з яким ви працюєте (класів, об’єктів, компонентів, поведінки — таких як діяльність, а також статичні машини тощо). У UML 2.0 ви можете вкласти набір класів всередині компонента, який ними керує, або вкладати поведінку (наприклад, стану машини) усередині класу або компонента, який його реалізує. Ця можливість також дозволяє створювати складні моделі поведінки з більш простих, здатність, яка визначає діаграму огляду взаємодії. Ви можете шарувати різні рівні абстракції різними способами: наприклад, ви можете створити модель свого підприємства та збільшити масштаб врахованих вбудованих веб-сайтів, а потім переглядати відомства на сайті, а потім — програми відділу. Крім того, ви можете включати обчислювальні моделі в рамки моделі бізнес-процесу. Спеціальна цільова група домену інтеграції бізнесу компанії Business Enterprise Integration Domain Task Force OMG (BEI DTF) в даний час працює над декількома цікавими новими стандартами в бізнес-процесах та бізнес-правилах.
  • Покращене поведінкове моделювання. У UML 1.X різні моделі поведінки були незалежними, але в UML 2.0 всі вони випливають із фундаментального визначення поведінки (за винятком випадків використання, котрий помітно відрізняється, але все ще бере участь у новій організації).
  • Поліпшення взаємозв’язку між структурними та поведінковими моделями. Як зазначалося в розділі «Вкладені класифікатори», UML 2.0 дозволяє визначити, що поведінка, що представляє, наприклад, статична машина чи діаграма послідовності — це поведінка класу або компонента.

 

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

 

Під час процесу оновлення були включені декілька доповнень до мови, у тому числі мова обмеження об’єктів (OCL) та семантика дій.