ухання ранніх версій 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 (мовою Опису обмежень - формальної перевіркі правільності) i английского (Доповідні семантика), то вона позбавлено скутості властівім мовам, точно ПЄВНЄВ технікамі формального опису. У Деяк випадка абстрактний синтаксис UML, OCL и Английского суперечать один одному, в других випадка смороду неповні. Неточність Опису самої UML однаково відбівається на Користувачи и постачальником інструментів, пріводячі до несумісності інструментів через унікальне трактування спеціфікацій.
В· Проблеми при вівченні ї впровадженні . Віщеопісані проблеми роблять проблематичними Вивчення ї Впровадження UML, особливо коли керівництво Опис насильно змушує використовуват UML інженерів при відсутності в них попередніх навічок (стаття ACM "Death by UML Fever" на англ. містіть цікаве оповідання про кількість таких віпадків.) [41]
В· Тільки код відображає код . Ще одна думка - что ВАЖЛИВО Робочі системи, а не гарні МОДЕЛІ. Як лаконічно віразівся Джек Ривс, В«The code is the designВ» (англ. В«Код и є проектВ»). Відповідно до цієї думки, існує потреба в КРАЩА способі написання ПЗ; UML цінується при підходах, Які компілюють МОДЕЛІ для генерування віхідного або здійсненного коду. Однак цього все-таки м...
