Unified Modeling Language, версія 2.0, Комерція, Різне, статті

Введення


На початку 90-х років минулого століття виник величезний інтерес до парадигми об’єктів та суміжних технологій. Були розроблені і прийняті нові мови програмування, засновані на цій парадигмі (такі як Smalltalk, Eiffel, C + + і Java). Все це супроводжувалося надмірним і збивають з пантелику кількістю методів проектування об’єктно-орієнтованого програмного забезпечення (ГО) і систем позначень процесу моделювання. Так, у своєму вичерпному огляді об’єктно-орієнтованих методів проектування та аналізу (що охоплює понад 800 сторінок) Грехем (Graham) перерахував понад 50 основних методів. Виходячи з того, що об’єктна парадигма складається з відносно невеликого набору фундаментальних концепцій (включаючи інкапсуляцію, успадкування і поліморфізм), було не просто перекрити і концептуально охопити всі ці методи – багато з них приховані за позначеннями, інші мають незначні відмінності. Це викликало велике нерозуміння і зайву фрагментацію ринку, які в свою чергу препятствовалі прийняття нової корисної парадигми. Розробники програмного забезпечення повинні були робити важкий, що зв’язує їх вибір між внутрішньо несумісними мовами, інструментальними засобами, методами і постачальниками.


З цієї причини, коли Rational Software запропонувала ініціативу Unified Modeling Language (UML) (під керівництвом Граді Буча (Grady Booch), Івара Якобсона (Ivar Jacobson) і Джима Рамбо (Jim Rumbaugh)) реакція була негайною і позитивною. Метою проекту було не пропозиція чогось нового, а (через спільну роботу лідерів передової технічної думки) об’єднання найкращих функціональних можливостей різних ГО підходів в один, незалежний від виробників мова моделювання і систему позначень. З цієї причини UML дуже швидко став широко практикуються стандартом. Після його прийняття організацією Object Management Group в 1996 він став затвердженим промисловим стандартом.


З тих пір, UML:



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


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


Деяка неадекватність програмних моделей може бути пояснена надзвичайно деталізованою і чутливої ​​природою сучасних технологій мов програмування. Невеликі помилки і ледь виявляються помилки кодування (такі як не вирівняні покажчики або не початкові змінні) можуть мати величезні наслідки. Наприклад, існує добре документована ситуація, коли один відсутній break в операторі switch призвів до недоступності служби переговорів на великі відстані для великої частини Сполучених Штатів, що призвело до негайних економічних втрат. Якщо така на вигляд незначна деталь може привести до настільки жахливих наслідків, як ми можемо гарантувати адекватність моделей (оскільки моделі з визначення приховують або усувають деталі)?


Керована моделями розробка


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


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


Потенціал, прихований за цією потужною комбінацією абстракції і автоматизації, Веде до появи нових технологій моделювання та відповідних методів розробки, що відносяться до так званої керованої моделями розробки (Model-driven development – MDD). Визначальною особливістю MDD є те, що моделі стають основними артефактами дизайну програми, переміщаючи, таким чином, фокус з відповідного коду програми. Вони виступають в якості креслень, з яких різні автоматизовані і напівавтоматизованих процеси витягують програми та відповідні моделі. Ступінь автоматизації, використовувана сьогодні в MDD, варіюється від вилучення простого скелетного коду до генерування повного автоматичного коду (що порівнянно з традиційною компіляцією). Очевидно, що чим вище рівні автоматизації, тим більш адекватними є моделі і тим більшими перевагами володіє MDD.


Керовані моделями методи розробки програмного забезпечення не є чимось кардинально новим – вони використовувалися зі змінним успіхом і раніше. Причиною підвищеного уваги до них в даний час є те, що підтримують технології досягли такого рівня, при якому практичної автоматизації піддається значно більше процесів, ніж раніше. І не тільки з точки зору ефективності, але і масштабованості, а також здатності таких інструментальних засобів інтегруватися з традиційними засобами і методами. Це розвиток відбивається в появі MDD-стандартів, що веде до уніфікації відповідних коштів і очевидним вигодам для користувачів. Одним з таких стандартів є переглянута версія Unified Modeling Language.


Обгрунтування перегляду UML 1


UML2.0 – це перша основна версія стандарту UML, за якою послідувала серія молодших редакцій. Навіщо потрібно було переглядати UML?


Основною мотивацією для перегляду мови було бажання забезпечити кращу підтримку MDD-засобів і методів. За останнє десятиліття ряд виробників розробили засновані на UML інструментальні засоби, які підтримували значно вищий рівень автоматизації, ніж традиційні CASE-засоби (computer-aided software engineering).


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


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


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


Відмінні риси UML 2.0


Нові розробки в UML 2.0 можуть бути згруповані в наступні п’ять основних категорій, перерахованих в порядку значимості:



Зараз ми детально досліджуємо кожну з них


Ступінь точності


Більшість ранніх мов моделювання програм були визначені неформально, мало уваги приділялося точності. Найчастіше концепції моделювання виражалися з використанням неточних і природних мов. Це вважалося достатнім на той час, оскільки більшість мов моделювання використовувалися або для документування, або для того, що Мартін Фоулер (Martin Fowler) назвав створенням ескізу дизайну (design sketching). Ідея полягала у передачі основних властивостей дизайну, залишаючи роботу з деталями на час реалізації.


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


Для мінімізації двозначності (і на відміну від більшості мов моделювання того часу) було специфіковано перший стандартизоване визначення UML, використовує метамодель. Це модель, яка визначає характеристики кожної UML-концепції моделювання і свої взаємини з іншими концепціями моделювання. Метамодель була визначена за допомогою елементарного підмножини UML і доповнена набором формальних обмежень, написаних на мові Object Constraint Language (OCL).


Примітка: Це підмножина UML, спочатку охоплює концепції, визначені в діаграмах класів UML, називається Meta-Object Facility (MOF). Це підмножина було вибрано тому, що його можна було використовувати для визначення інших мов моделювання.


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


Однак ступінь точності, яка використовується в цій першій UML-метамоделі, була недостатньою для підтримки всього потенціалу MDD. Зокрема, специфікація семантик (Або значень) UML-концепцій моделювання залишалася неадекватною для таких заснованих на MDD операціях, як автоматичне генерування коду або формальна верифікація.


Тому використовувана у визначенні UML 2.0 ступінь точності була значно збільшена. Це було досягнуто наступними засобами:



Рисунок 1. Семантична середу UML 2.0

На малюнку 4 зображено модель розширеного взаємодії. В даному випадку взаємодія ATMAccess спочатку “ініціює” іншу транзакцію меншого рівня з ім’ям CheckPIN (зміст цієї взаємодії на діаграмі не показано). Зверніть увагу, що останнє взаємодія має параметр (в даному випадку, скажімо, максимальна кількість спроб введення PIN-коду перед анулюванням транзакції). Після цього клієнт посилає асинхронне повідомлення, яке вказує потрібний тип взаємодії і (в залежності від вказаного значення) виконується або взаємодія DispenseCash, або взаємодія PayBill.


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


Кінцеві автомати


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


Ще одним примітним нововведенням кінцевих автоматів в UML 2.0 є уточнення спадкування кінцевих автоматів між класами і його підкласами.


Можливості спеціалізації мови


Досвід UML 1 показав, що самий звичайний спосіб застосування UML – спочатку визначити UML-профіль для конкретної проблеми чи області застосування, а потім використовувати цей профіль замість або як доповнення до загальному UML. По суті профілі були способом визначення мови, широко відомого зараз під назвою DSL (domain specific language).


Альтернатива використання UML-профілів – визначити новий традиційний мова моделювання, використовуючи стандарт MOF та інструментальні засоби. Останній підхід має очевидні переваги чистого аркуша, дозволяючи визначення мови, який оптимально підходить для поточної проблеми. На перший погляд це може здатися кращим підходом до визначення DSL, але більш уважне дослідження показує, що у цього підходу можуть бути серйозні недоліки.


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


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


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



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


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


Виходячи з цих міркувань, механізм профілів UML 2.0 був вдосконалений, а його можливості розширені. Також була уточнена концептуальна зв’язок між стереотипом і розширюють його UML-концепціями. В сутності, стереотип UML 2.0 визначається як якби він був просто підкласом існуючого UML-метакласи з асоційованими атрибутами (представляють теги для тегів значень), операціями і обмеженнями. Були повністю визначені механізми написання таких обмежень з використанням такої мови як OCL.


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


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


Загальне об’єднання


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


Видалення перекриваються і уточнення слабо певних концепцій було ще одним важливим вимогою для UML 2.0. Ця вимога впливає на три основні області застосування:



Дії були представлені в UML 1.5. Концептуальна модель дій навмисно була зроблена досить узагальненій для узгодження з обома моделями обчислення – як моделями, заснованими на потоці даних, так і моделями, заснованими на потоках управління. Це призвело до значного концептуального подобою моделі активностей. В UML 2.0 було використано цю подобу для забезпечення загального синтаксису і фундаменту семантики для дій і активностей. З вашої точки зору вони є формалізмами, що виникають на різних рівнях абстракції, оскільки вони зазвичай моделюють явища на різних рівнях деталізації. Однак загальна концептуальна база призводить до загального спрощення і більшої ясності.


В UML 1 шаблони були визначені дуже узагальнено: будь UML-концепція могла бути представлена ​​в шаблоні. На жаль, така спільність була перешкодою для додатків, оскільки дозволяла потенційно не мають значення типи шаблонів і підстановку шаблонів. Механізм шаблонів в UML 2.0 був обмежений до добре розуміються випадків: класифікаторів, операцій і пакетів. Перші два були змодельовані аналогічно механізмам шаблонів в популярних мовах програмування.


В області компонентного проектування UML 1 мав заплутане достаток концепцій. Ви могли використовувати класи, компоненти або підсистеми. Ці концепції мали багато спільного, але були трохи різними. Чи не було чіткого розмежування, яку використовувати в даній ситуації. Чи була система просто “великим” компонентом? Якщо так, наскільки великим міг бути компонент, перед тим як стати підсистемою? Класи забезпечували інкапсуляцію і реалізовували інтерфейси, але це ж робили компоненти і підсистеми.


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


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


Підсумки


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


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


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


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


Механізми розширення мови були трохи реструктуризовані і спрощені, що надало більш прямий спосіб визначити специфічні для сфери застосування мови (domain-specific languages ​​- DSL) на основі UML. Ці мови мають помітну вигоду, оскільки здатні безпосередньо використовувати переваги інструментальних засобів UML та практичного застосування, які представлені в повному обсязі.


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*