UML - язык графического описания для объектного моделирования

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

* Надмірність мови. UML часто критикується, як невиправдано великий і складний. Він включає багато надлишкових або практично невживаних діаграм і конструкцій. Частіше це можна почути відносно UML 2. 0, чим UML 1. 0, оскільки новіші ревізії включають більше розробленим «комітетом» компромісів.

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

 * Проблеми при вивченні і впровадженні. Вищеописані проблеми роблять проблематичним вивчення і внедреніє UML, особливо коли керівництво насильно заставляє використовувати UML інженерів у них попередніх навиків (стаття ACM на англ. містить цікаве оповідання про кількість таких випадків. )

 * Лише код відображає код. Ще одна думка — що важливі робочі системи, а не красиві моделі. Як лаконічно виразився Джек Рівс, «The code is the design. » (англ. «Код і є проект»)[1][2] Відповідно до цієї думки, існує потреба в кращому способі написання ПО; UML цінується при підходах, які компілюють моделі для генерування вихідної або здійснимої коди. Проте цього все ж може бути недостатньо, оскільки UML не має властивостей повноти по Т'юрингу і будь-який код, що згенерував, буде обмежений тим, що може розгледіти або передбачити інструмент, що інтерпретує, UML.

 * Кумулятивна нагрузка/рассогласованіє навантаження (Cumulative Impedance/impedance mismatch). Розузгодження навантаження — термін з теорії системного аналізу для позначення неспособностивходу системи сприйняти вихід інший

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

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

 Уніфікована мова моделювання UML

12. 1. Об’єктно-орієнтований підхід при моделюванні

12. 2. Технологія моделювання. Зв’язки між класами

12. 3. Переваги і недоліки уніфікованої мови

UML- вик. об’єктно-орієнтованого моделювання, дозволяє разом з аналізом ств-ти документацію для проектування скл. ієрархічних с-м.

Є універсальною мовою проектування (проекти, програмний продукт).

Це мова візуального проектування.

Призначається для спілкування розробників різних моделей.

Пакет UML може описувати класи, об’єкти (екземпляр класу) і компоненти, що належать різним предметним галузям – це все наз.

1 2 3

Похожие работы

Рефераты

Курсовые

Дипломные