до них приєднався А. Джекобсон, головний технолог з компанії Objectory AB (Швеція), з метою інтеграції свого методу OOSE з двома попередніми. p align="justify"> Спочатку автори методів Booch, ОМТ і OOSE припускали розробити уніфікована мова моделювання тільки для цих трьох методик. З одного боку, кожен з цих методів був перевірений на практиці і показав свою конструктивність при вирішенні окремих завдань ООАП. Це давало підставу для подальшої їх модифікації на основі усунення наявного невідповідності окремих понять і позначень. З іншого боку, уніфікація семантики і нотації повинна була забезпечити деяку стабільність на ринку об'єктно-орієнтованих CASE-засобів, яка необхідна для успішного просування відповідних програмних інструментаріїв. Нарешті, спільна робота давала надію на істотне поліпшення всіх трьох методів. p align="justify"> Починаючи роботу з уніфікації своїх методів, Г. Буч, Дж. румби і А. Джекобсон сформулювали наступні вимоги до мови моделювання. Він повинен:
В· Дозволяти моделювати не тільки програмне забезпечення, але і більш широкі класи систем і бізнес-додатків, з використанням об'єктно-орієнтованих понять.
В· Явним чином забезпечувати взаємозв'язок між базовими поняттями для моделей концептуального та фізичного рівнів.
В· Забезпечувати масштабованість моделей, що є важливою особливістю складних багатоцільових систем.
В· Бути зрозумілий аналітикам і програмістам, а також повинен підтримуватися спеціальними інструментальними засобами, реалізованими на різних комп'ютерних платформах.
Розробка системи позначень або нотації для ООАП виявилася несхожою на розробку нової мови програмування. По-перше, необхідно було вирішити дві проблеми:
. Чи повинна дана нотація включати в себе специфікацію вимог?
. Чи слід розширювати дану нотацію до рівня мови візуального програмування?
По-друге, було необхідно знайти вдалий баланс між виразністю і простотою мови. З одного боку, занадто проста нотація обмежує коло потенційних проблем, які можуть бути вирішені за допомогою відповідної системи позначень. З іншого боку, занадто складна нотація створює додаткові труднощі для її вивчення та застосування аналітиками і програмістами. У разі уніфікації існуючих методів необхідно враховувати інтереси фахівців, які вже мають досвід роботи з ними, оскільки внесення серйозних змін в нову нотацію може спричинити за собою нерозуміння і неприйняття її користувачами колишніх методик. Щоб виключити неявне опір з боку окремих фахівців, необхідно враховувати інтереси самого широкого кола користувачів. Подальша робота над мовою UML мала врахувати всі ці обставини. ...
