Недоліки й переваги UML

Незважаючи на те, що UML досить широко розповсюджений і використовуваний стандарт, його часто критикують через наступні недоліки:

– Надмірність мови. 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 розширює й дозволяє вводити власні текстові й графічні стереотипи, що сприяє його застосуванню не тільки в сфері програмної інженерії;

– UML одержала широке поширення й динамічно розвивається.