Обидві ці категорії еволюції змін істотно виграли б від автоматизації. Із цією метою автори розробили узагальнений процесор трансформацій для маніпулювання моделями, названий ними C-Saw (Constraint-Specification Aspect Weaver). C-Saw – це - модуль, що підключається, для GME (див. вище огляд статті "Розробка додатків з використанням керованих моделями середовищ розробки").
Для роботи зі змінами, що перетинають ієрархію, в C-Saw використовується кілька принципів аспектно-орієнтованого підходу. Комбінація трансформації моделі з компонуванням аспектів забезпечує потужну технологію для швидкого перетворення успадкованих систем на основі високорівневих властивостей, описуваних моделлю. Далі, шляхом застосування аспектно-орієнтованих методів і перетворення програм невеликі зміни на модельному рівні можуть ініціювати дуже великі трансформації на рівні вихідного коду.
Останню статтю тематичної добірки - "Модельно-модельно-орієнтована розробка з використанням UML 2.0: обіцянки й прорахунки" ("Model-Driven Development Using UML 2.0: Promises and Pitfalls") - написали Роберт Франс, Судипто Гош, Трунг Динх-Тронг і Арнор Солберг (Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, Colorado State University, Arnor Solberg, SINTEF). [10.5]
Досвід показує, що ефективні механізми керування складністю автоматизують звичайні завдання розробки й забезпечують надійну підтримку поділу відповідальностей. Наприклад, сучасні високорівневі мови програмування й інтегровані середовища розробки забезпечують абстракції, що захищають розроблювачів від складних низькорівневих деталей і підтримують автоматичне перетворення абстрактних представлень вихідного коду в дійсні форми, які виконує машина.
Досягнення в областях розробки програмного забезпечення й технологій обробки інформації привели до спроб створення більш складних програмних систем. Ці спроби демонструють неадекватність абстракцій, забезпечуваних сучасними мовами високого рівня. Виникає потреба в мовах, моделях і технологіях, що підвищують рівень абстракції, на якому замислюються, створюються й розвиваються.
OMG (Object Management Group) відповідає на цю вимогу підготовкою версії 2.01 мови UML і ініціативою MDA (Model Driven Architecture). Проблеми, на рішення яких на початку були націлені розроблювачі UML 2.0, включали очевидне розпухання ранніх версій UML і відсутність правильно певної семантики.
У ході розробки стандарту в число вимог була додана підтримка модельно-модельно-керованої розробки (MDD), а точніше, підходу MDA до MDD. Широка поінформованість про проблеми ранніх версій UML разом зі зростаючим інтересом до MDD породили надії на те, що розроблювачам UML 2.0 удасться зробити версію мови з істотно скороченим набором модельних понять для точного й зручного описів найрізноманітніших додатків.
Очікувалося також, що в цій версії буде бути точна семантика, що могла б полегшити автоматизацію, необхідну для просування MDD за межі традиційних можливостей існуючих CASE-Засобів. Деякі люди очікували, що розроблювачам UML 2.0 удасться зробити срібну кулю мов моделювання або, принаймні, тісно наблизитися до цього.
Ті, хто не знаком із внутрішніми роботами в області, проведеній співтовариством стандартизації мов, знаходять разючими розмір і складність стандарту UML 2.0. Дійсно, кінцеві результати здаються далекими від посилок, які мотивували початок цієї роботи з великого перегляду мови. З погляду очорнителя, численні модельні поняття, погано певна семантика й легковагі механізми розширень затрудняють вивчення мови і його застосування в середовищі MDD. Ці реальні проблеми вимагають рішення, але нам не слід дивуватися тому, що ця мова моделювання першого покоління далека від досконалості.
Як відзначають деякі розроблювачі UML, розробка мов моделювання усе ще переживає період становлення. Для прискорення процесу виявлення знань, пов'язаних з MDD, нам потрібна конструктивна критика UML. У цьому змісті UML 2.0 може зіграти важливу роль як явна форма експерименту з мовою моделювання, що може вивчатися, аналізуватися й критикуватися зацікавленими сторонами.
Захисники UML 2.0 відзначають, що в цьому стандарті відбитий кращий виробничий досвід застосування моделювання. Вони говорять про наступні основні вдосконалення:
· Поліпшено підтримку UML як сімейства мов за рахунок використання профілів і крапок семантичних варіацій (semantic variation point), які позначають частини UML, які навмисне залишені без семантики, щоб можна було навантажити їхньою семантикою, обумовленої користувачами.
· Поліпшено виразність моделювання, включаючи моделювання бізнес-процесів, підтримку класифікаторів повторного використання моделювання й підтримку архитектур розподілених неоднорідних систем.
· Зроблено інтеграцію семантики дій (Action Semantics), що може використовуватися розроблювачами для визначення семантики моделей під час виконання й забезпечує семантичну точність, необхідну для аналізу моделей і їхньої трансляції в реалізації.
На думку авторів, що занадто висока оцінка UML і відповідних технологій MDD може бути настільки ж пагубної, як і несправедлива критика. Це може привести до росту очікувань користувачів до недосяжного в цей час рівня. У своїй статті автори намагаються розвіяти хмари реклами, що оточують UML 2.0, і представити обґрунтовану оцінку забезпечуваної цієї версії мови підтримку MDD [10.4].
6. Критика й переваги UML
Незважаючи на те, що UML досить широко розповсюджений і використовуваний стандарт, його часто критикують через наступні недоліки [40, 41]:
· Надмірність мови. UML часто критикується, як невиправдано велика і складна. Вона включає багато надлишкових або практично невикористовуваних діаграм і конструкцій. Частіше це можна почути у відношенні UML 2.0, чим UML 1.0, тому що більше нові ревізії включають більше « розроблених-комітетом» компромісів.
· Неточна семантика. Тому що UML визначена комбінацією себе (абстрактний синтаксис), OCL (мовою опису обмежень — формальної перевірки правильності) і Англійської (докладна семантика), то вона позбавлена скутості властивим мовам, точно певним техніками формального опису. У деяких випадках абстрактний синтаксис UML, OCL і Англійської суперечать один одному, в інших випадках вони неповні. Неточність опису самої UML однаково відбивається на користувачах і постачальниках інструментів, приводячи до несумісності інструментів через унікальне трактування специфікацій.
· Проблеми при вивченні й впровадженні. Вищеописані проблеми роблять проблематичним вивчення й впровадження UML, особливо коли керівництво насильно змушує використовувати UML інженерів при відсутності в них попередніх навичок (стаття ACM "Death by UML Fever" на англ. містить цікаве оповідання про кількість таких випадків.) [41]
· Тільки код відображає код. Ще одна думка — що важливо робочі системи, а не гарні моделі. Як лаконічно виразився Джек Ривс, «The code is the design» (англ. «Код і є проект»). Відповідно до цієї думки, існує потреба в кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідного або здійсненного коду. Однак цього все-таки може бути недостатньо, тому що UML не має властивостей повноти по Тьюрінгу і будь-який згенерований код буде обмежений тим, що може розглянути або припустити інтерпретуючий UML інструмент.
· Кумулятивне навантаження/Неузгодженість навантаження (Cumulative Impedance/Impedance mismatch). Неузгодженість навантаження — термін з теорії системного аналізу для позначення нездатності входу системи сприйняти вихід іншої. Як у будь-якій системі позначень UML може представити одні системи більш коротко й ефективно, чим інші. Таким чином, розроблювач відмінюється до рішень, які більш комфортно підходять до переплетенню сильних сторін UML і мов програмування. Проблема стає більш очевидної, якщо мова розробки не дотримується принципів ортодоксальної об’єктно-орієнтованої доктрини (не намагається відповідати традиційним принципам ВОП).
· Намагається бути всім для всіх. UML — це мова моделювання загального призначення, що намагається досягти сумісності з усіма можливими мовами розробки. У контексті конкретного проекту, для досягнення командою проектувальників певної мети, повинні бути обрані застосовні можливості UML. Крім того, шляхи обмеження області застосування UML у конкретній області проходять через формалізм, що не повністю сформульований, і який сам є об'єктом критики. [40]
· UML об’єктно-орієнтована, у результаті чого методи опису результатів аналізу й проектування семантично близькі до методів програмування на сучасних ВО-Мовах;
· UML дозволяє описати систему практично із всіх можливих точок зору й різні аспекти поведінки системи;
· Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;
· UML розширює й дозволяє вводити власні текстові й графічні стереотипи, що сприяє його застосуванню не тільки в сфері програмної інженерії;
· UML одержала широке поширення й динамічно розвивається.
7. Висновок
UML є потужним, гнучким засобом моделювання, опис стандарту якого є відкритим для наступного вдосконалювання. Неоднозначність як деяких конструкцій самої мови, так і підходів до його формальної семантики, наявність у специфікації неформальних описів вимагає подальшого розвитку формальної основи для повної й несуперечливої інтерпретації мови.
Перелік літератури
[1] G. Booch, Jim Rumbaugh, Ivar Jacobson The Unified Modeling Language User Guide: Addison-Wesley Publishing Co., 1999, 512 p.
[2] Booch G., Rumbaugh J. UML 1.1 Semantics. (http://www.rational.com/uml/)1997.
[3]RogerR.Flynn,EditorinChief,Computersciences.Volume2.SoftwareandHardware.MacmillianreferenceUSA.ThomsonGaleCompany,Inc.2002572p.
[4]BoochG.Object-orientedanalysisanddesignwithapplications. Secondedition.TheBenjamin/CummingsPublishingCompany,Inc.1994.589p.//
[5]RumbaughJ.,BlachaM.PremerlaniW.,EddyF.LorensenW.Object-OrientedModelingandDesign.Prentice-Hall,Inc.,1991
[6]JacobsonI.Object-OrientedSoftwareEngineering. AUseCaseDrivenApproach.Addison-WesleyPublishingCompany,1993.
[7]BoochG.,RumbaughJ.UMLNotationGuide(www.rational.com/uml/)1997.
[8]ARationalApproach toSoftwareDevelopment Using Rational Rose4.0http://www.rational.com/support/techpapers/roseapproach/. 1997