2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.

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

В той же час розробники з OMG вважають украй небажаним перевизначення базових понять язика по якій би то не було причині. Це може привести до неоднозначної інтерпретації їх семантики і можливої плутанини. Базові поняття язика UML не слід змінювати більше, ніж це необхідне для їх розширення. Всі користувачі повинні бути здатні будувати моделі систем для більшості звичайних додатків з використанням тільки базових конструкцій язика UML без вживання механізму розширення. При цьому нові поняття і нотації доцільно застосовувати тільки в тих ситуаціях, коли наявних базових понять явно недостатньо для побудови моделей системи.

Язик UML допускає також спеціалізацію базових понять. Йдеться про те, що в конкретных7приложениях користувачі повинні уміти доповнювати наявні базові поняття новими характеристиками або властивостями, які не суперечать семантиці цих понять в язиці UML.

3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.

Йдеться про те, що жодна з конструкцій язика UML не повинна залежати від особливостей її реалізації у відомих язиках програмування. Тобто, хоча окремі поняття язика UML і пов'язані з останніми дуже тісно, їх жорстка інтерпретація у формі яких би то не було конструкцій програмування не може бути визнана коректною. Іншими словами, розробники з OMG вважають необхідним властивістю язика UML його контекстно‑ програмну незалежність.

З другого боку, язик UML повинен володіти потенційною можливістю реалізації своїх конструкцій на тому або іншому язиці програмування. Звичайно, в першу чергу маються на увазі язики, що підтримують концепцію ООП, такі як C++, Java, Object Pascal. Саме ця властивість язика UML робить його сучасним засобом рішення задач моделювання складних систем. В той же час, передбачається, що для програмної підтримки конструкцій язика UML можуть бути розроблені спеціальні інструментальні CASE‑ засоби. Наявність останніх має принципове значення для широкого розповсюдження і використовування язика UML.

4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.

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

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

5.  Заохочувати розвиток ринку об'єктних інструментальних засобів.

Більше 800 ведучих виробників програмних і апаратних засобів, зусилля яких зосереджені в рамках OMG, бачать перспективи розвитку сучасних інформаційних технологій і основу свого комерційного успіху в широкому просуванні на ринок інструментальних засобів, що підтримують об'єктні технології. Кажучи ж про об'єктні технології, розробники з OMG мають у вигляді, перш за все, сукупність технологічних рішень CORBA і UML. З цієї точки зору язику UML відводиться роль базового засобу для опису і документування різних об'єктних компонентів CORBA.

6.  Сприяти розповсюдженню об'єктних технологій і відповідних понять ООАП.

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