Окремі мови об’єктно-орієнтованого моделювання сталі з'являтися в період між серединою 1970-х і кінцем 1980-х років, коли різні дослідники й програмісти пропонували свої підходи до ООАП. У період між 1989-1994 р. загальне число найбільш відомих мов моделювання зросло з 10 до більш ніж 50. Багато користувачів зазнавали серйозних труднощів при виборі мови ООП, оскільки жоден з них не задовольняв всім вимогам, пропонованим до побудови моделей складних систем. Прийняття окремих методик і графічних нотацій як стандарти (IDEF0, IDEF1X) не змогло змінити сформовану ситуацію непримиренної конкуренції між ними на початку 90-х років, що теж одержала назву "війни методів".
До середини 1990-х деякі з методів були істотно поліпшені й придбали самостійне значення при рішенні різних завдань ООП. Найбільш відомими в цей період стають:
- Метод Гради Буча (Grady Booch), що одержала умовну назву Booch або Booch'91, Booch Lite (пізніше - Booch'93).
- Метод Джеймса Румбаха (James Rumbaugh), що одержав назву Object Modeling Technique - ОМТ (пізніше - ОМТ-2).
- Метод Айвара Джекобсона (Ivar Jacobson), що одержав назву Object-Oriented Software Engineering - OOSE.
Кожний із цих методів був орієнтований на підтримку окремих етапів ООП. Наприклад, метод OOSE містив засобу подання варіантів використання, які мають істотне значення на етапі аналізу вимог у процесі проектування бізнесі - додатків. Метод ОМТ-2 найбільше підходив для аналізу процесів обробки даних в інформаційних системах. Метод Booch'93 знайшов найбільше застосування на етапах проектування й розробки різних програмних систем.
Історія розвитку мови UML бере початок з жовтня 1994 року, коли Гради Буч і Джеймс Румбах з Rational Software Corporation почали роботу з уніфікації методів Booch і ОМТ. Хоча самі по собі ці методи були досить популярні, спільна робота була спрямована на вивчення всіх відомих об’єктно-ориентированих методів з метою об'єднання їхніх достоїнств. При цьому Г. Буч і Дж. Румбах зосередили зусилля на повній уніфікації результатів своєї роботи. Проект так званого уніфікованого методу (Unified Method) версії 0.8 був підготовлений і опублікований у жовтні 1995 року. Восени того ж року до них приєднався А. Джекоб-Сон, головний технолог з компанії Objectory AB (Швеція), з метою інтеграції свого методу OOSE із двома попередніми.
Спочатку автори методів Booch, ОМТ і OOSE припускали розробити уніфіковану мову моделювання тільки для цих трьох методик. З одного боку, кожний із цих методів був перевірений на практиці й показав свою конструктивність при рішенні окремих завдань ООАП. Це давало підставу для подальшої їхньої модифікації на основі усунення наявної невідповідності окремих понять і позначень. З іншого боку, уніфікація семантики й нотації повинна була забезпечити деяку стабільність на ринку об’єктно-орієнтованих CASE-Засобів, що необхідна для успішного просування відповідних програмних інструментів. Нарешті, спільна робота давала надію на істотне поліпшення всіх трьох методів.
Починаючи роботу з уніфікації своїх методів, Г. Буч, Дж. Румбах і А. Дже-Кобсон сформулювали наступні вимоги до мови моделювання. Він повинен:
- Дозволяти моделювати не тільки програмне забезпечення, але й більше широкі класи систем і бізнес-додатків, з використанням об’єктно-орієнтованих. понять.
- Явно забезпечувати взаємозв'язок між базовими поняттями для моделей концептуального й фізичного рівнів.
- Забезпечувати масштабованість моделей, що є важливою особливістю складних багатоцільових систем.
- Бути зрозумілий аналітикам і програмістам, а також повинен підтримуватися спеціальними інструментальними засобами, реалізованими на різних комп'ютерних платформах.
Розробка системи позначень або нотації для ООП виявилася несхожої на розробку нової мови програмування. По-перше, необхідно було вирішити дві проблеми:
- Чи належна дана нотація містити в собі специфікацію вимог?
- Чи варто розширювати дану нотацію до рівня мови візуального програмування?
По-друге, було необхідно знайти вдалий баланс між виразністю й простотою мови. З одного боку, занадто проста нотація обмежує коло потенційних проблем, які можуть бути вирішені за допомогою відповідної системи позначень. З іншого боку, занадто складна нотація створює додаткові труднощі для її вивчення й застосування аналітиками й програмістами. У випадку уніфікації існуючих методів необхідно враховувати інтереси фахівців, які вже мають досвід роботи з ними, оскільки внесення серйозних змін у нову нотацію може викликати нерозуміння й неприйняття її користувачами колишніх методик. Щоб виключити неявний опір з боку окремих фахівців, необхідно враховувати інтереси самого широкого кола користувачів. Наступна робота над мовою UML повинна була врахувати всі ці обставини.
У цей період підтримка розробки мови UML стає однієї із цілей консорціуму OMG (Object Management Group). Хоча консорціум OMG був утворений ще в 1989 році з метою розробки пропозицій по стандартизації об'єктних і компонентних технологій CORBA, мова UML придбав статус другого стратегічного напрямку в роботі OMG. Саме в рамках OMG створюється команда розроблювачів під керівництвом Ричарда Солі, що буде забезпечувати подальшу роботу з уніфікації й стандартизації мови UML. У червні 1995 року OMG організувала нараду всіх великих фахівців і представників вхідним у консорціум компаній по методологіях ООП, на якому вперше в міжнародному масштабі була визнана доцільність пошуку індустріальних стандартів в області мов моделювання під егідою OMG.
Зусилля Г. Буча, Дж. Румбаха й А. Джекобсона привели до появи перших документів, що містять опис властиво мови UML версії 0.9 (червень 1996 р.) і версії 0.91 (жовтень 1996 р.). Що мають статус запиту пропозицій RTP (Request For Proposals), ці документи послужили своєрідним каталізатором для широкого обговорення мови UML різними категоріями фахівців. Перші відкликання й реакція на мову UML указували на необхідність його доповнення окремими поняттями й конструкціями.
У цей же час стало ясно, що деякі компанії й організації бачать у мові UML лінію стратегічних інтересів для свого бізнесу. Компанія Rational Software разом з декількома організаціями, що виявили бажання виділити ресурси для розробки строгого визначення версії 1.0 мови UML, заснувала консорціум партнерів UML, у який спочатку ввійшли такі компанії, як Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI і Unisys. Ці компанії забезпечили підтримку наступної роботи з більше точного й строгого визначення нотації, що привело до появи версії 1.0 мови UML. У січні 1997 року був опублікований документ із описом мови UML 1.0, як початковий варіант відповіді на запит пропозицій RTP. Ця версія мови моделювання була досить добре визначена, забезпечувала необхідну виразність і потужність і припускала рішення широкого класу завдань.
Інструментальні CASE-Засоби й діапазон їхнього практичного застосування у великому ступені залежать від удалого визначення семантики й нотації відповідної мови моделювання. Специфіка мови UML полягає в тім, що він визначає семантичну метамодель, а не модель конкретного інтерфейсу й способи подання або реалізації компонентів.
З більш ніж 800 компаній і організацій, що входять у цей час до складу консорціуму OMG, особливу роль продовжує грати Rational Software Corporation, що стояла в джерел розробки мови UML. Ця компанія розробила й випустила в продаж одне з перших інструментальних CASE-Засобів Rational Rose 98, у якому був реалізований мова UML.
У січні 1997 року цілий ряд інших компаній, серед яких були IBM, ObjecTime, Platinum Technology і деякі інші, подали на розгляд OMG свої власні відповіді на запит пропозицій RFP. Надалі цій компанії приєдналися до партнерів UML, пропонуючи включити в мову UML деякі свої ідеї. У результаті спільної роботи з партнерами UML була запропонована переглянута версія 1.1 мови UML. Основна увага при розробці мови UML 1.1 було приділено досягненню більшої ясності семантики мови в порівнянні з UML 1.0, а також обліку пропозицій нових партнерів. Ця версія мови була представлена на розгляд OMG і була схвалена й прийнята як стандарт OMG у листопаді 1997. року.
У цей час всі питання подальшої розробки мови UML сконцентровані в рамках консорціуму OMG. Відповідна група фахівців забезпечує публікацію матеріалів, що містять опис наступних версій мови UML і запитів пропозицій RFP по його стандартизації. Черговий етап розвитку даної мови закінчився в березні 1999 року, коли консорціумом OMG був опублікований опис мови UML 1.3 (alpha R5). Останньою версією мови UML на момент написання книги є UML 1.3, що описана у відповідному документі - "OMG Unified Modeling Language Specification", опублікованому в червні 1999 року.
Статус мови UML визначений як відкритий для всіх пропозицій по його доробці й удосконалюванню. Сама мова UML не є чиєї-або власністю й не запатентований ким-небудь, хоча зазначений вище документ захищений законом про авторське право. У той же час абревіатура UML, як і деякі інші (OMG, CORBA, ORB), є торговельною маркою їхніх законних власників, про що варто згадати в даному контексті.
Мова UML орієнтована для застосування як мова моделювання різними користувачами й науковими співтовариствами для рішення широкого класу завдань ООАП. Багато фахівців з методології, організації й постачальники інструментальних засобів зобов'язалися використовувати мову у своїх розробках. При цьому термін "уніфікований" у назві UML не є випадковим і має два аспекти. З одного боку, він фактично усуває багато хто з несуттєвих розходжень між відомими раніше мовами моделювання й методиками побудови діаграм. З іншого боку, створює передумови для уніфікації різних моделей і етапів їхньої розробки для широкого класу систем, не тільки програмного забезпечення, але й бізнес-процесів. Семантика мови UML визначена таким чином, що вона не є перешкодою для наступних удосконалень із появою нових концепцій моделювання.
У цьому зв'язку слід зазначити увага гіганта комп'ютерної індустрії компанії Microsoft до технології UML. Ще в жовтні 1996 р. Microsoft і Rational Software Coiporation оголосили про своє стратегічне партнерство, що, по їхній загальній думці, здатно вплинути на ринок засобів об’єктно-орієнтованоїрозробки програм. При цьому Microsoft ліцензувала в Rational Software деякі технології візуального моделювання, у результаті чого був розроблений Microsoft Visual Modeler for Visual Basic. У свою чергу Rational Software ліцензувала в Microsoft Visual Basic і Microsoft Repositoiy, розроблювальні разом з Texas Instruments. При створенні мови UML Microsoft внесла свій внесок в інтеграцію UML зі своїми стандартами типу Active і СОМ і у використання мови UML зі своєю технологією Microsoft Repository.
На основі технології UML Microsoft, Rational Software і інші постачальники засобів розробки програмних систем розробили єдину інформаційну модель, що одержала назву UML Information Model. Передбачається, що ця модель дасть можливість різним програмам, що підтримують ідеологію UML, обмінюватися між собою компонентами й описами. Все це дозволить створити стандартний інтерфейс між засобами розробки додатків і засобами візуального моделювання.
Уже в цей час розроблені засоби візуального програмування на основі UML, що забезпечують інтеграцію, включаючи пряму й зворотну генерацію коду програм, з найпоширенішими мовами й середовищами програмування, такими як MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Оскільки при розробці мови UML були прийняті в увагу багато передових ідей і методи, очікується, що на чергові версії мови UML також вплинуть і інші перспективні технології й концепції. Крім того, на основі мови UML можуть бути визначені багато нових перспективних методів. Мова UML може бути розширений без перевизначення його ядра.
Підбиваючи підсумок аналізу методології ООАП і історичних передумов появи UML, можна затверджувати наступне. Є всі підстави припускати, що в найближчі роки мова UML у його сучасному виді стане основою для розробки й реалізації в багатьох перспективних інструментальних засобах: в RAD-Засобах візуального й імітаційного моделювання, а також в CASE-Засобах всілякого цільового призначення. Більше того, закладені в мові UML потенційні можливості можуть бути використані не тільки для об’єктно-орієнтованого моделювання систем, але й для подання знань в інтелектуальних системах, якими, по суті, стануть перспективні складні програмно-технологічні комплекси.
Призначення мови UML
Мова UML призначена для рішення наступних завдань:
- Надати в розпорядження користувачів легко сприймана й виразна мова візуального моделювання, спеціально призначений для розробки й документування моделей складних систем всілякого цільового призначення.
Мова йде про те, що важливим фактором подальшого розвитку й повсюдного використання методології ООАП є інтуїтивна ясність і зрозумілість основних конструкцій відповідної мови моделювання. Мова UML містить у собі не тільки абстрактні конструкції для подання метамоделі систем, але й цілий ряд конкретних понять, що мають цілком певну семантику. Це дозволяє мові UML одночасно досягти не тільки універсальності подання моделей для всіляких додатків, але й можливості опису досить тонких деталей реалізації цих моделей стосовно до конкретних систем.
Практика системного моделювання показала, що абстрактного опису мови на деякому метарівні недостатньо для розроблювачів, які ставлять своєю метою реалізацію проекту системи в конкретний термін. У цей час має місце деякий концептуальний розрив між загальною методологією моделювання складних систем і конкретних інструментальних засобів швидкої розробки додатків. Саме цей розрив за задумом OMG і покликаний заповнити мова UML.
Звідси випливає важливий наслідок - для адекватного розуміння базових конструкцій мови UML важливо не тільки володіти деякими навичками об’єктно-орієнтованого програмування, але й добре уявляти собі загальну проблематику процесу розробки моделей систем. Саме інтеграція цих подань утворить нову парадигму ООАП, практичним наслідком і центральним стрижнем якої є мова UML.
- Постачити вихідні поняття мови UML можливістю розширення й спеціалізації для більше точного подання моделей систем у конкретній предметній області.
Хоча мова UML є формальною мовою - специфікацій, формальність його опису відрізняється від синтаксису як традиційних формально-логічних мов, так і відомих мов програмування. Розроблювачі з OMG припускають, що мова UML як ніякий інший може бути пристосований для конкретних предметних областей. Це стає можливим з тієї причини, що в самому описі мови UML закладений механізм розширення базових понять, що є самостійним елементом мови й має власний опис у формі правил розширення.
У той же час розроблювачі з OMG уважають украй небажаним перевизначення базових понять мови по який би те не було причині. Це може привести до неоднозначної інтерпретації їхньої семантики й можливій плутанині. Базові поняття мови UML не слід змінювати більше, ніж це необхідно для їхнього розширення. Всі користувачі повинні бути здатні будувати моделі систем для більшості звичайних додатків з використанням тільки базових конструкцій мови UML без застосування механізму розширення. При цьому нові поняття й нотації доцільно застосовувати тільки в тих ситуаціях, коли наявних базових понять явно недостатньо для побудови моделей системи.
Мова UML допускає також спеціалізацію базових понять. Мова йде про те, що в конкретних7 додатках користувачі повинні вміти доповнювати наявні базові поняття новими характеристиками або властивостями, які не суперечать семантиці цих понять у мові UML.
- Опис мови UML повинно підтримувати таку специфікацію моделей, що не залежить від конкретних мов програмування й інструментальних засобів проектування програмних систем.
Мова йде про те, що жодна з конструкцій мови UML не повинна залежати від особливостей її реалізації у відомих мовах програмування. Тобто, хоча окремі поняття мови UML і пов'язані з останніми дуже тісно, їхня тверда інтерпретація у формі яких би те не було конструкцій програмування не може бути визнана коректної. Інакше кажучи, розроблювачі з OMG вважають за необхідне властивістю мови UML його контекстно-програмну незалежність.
З іншого боку, мова UML повинен мати потенційну можливість реалізації своїх конструкцій на тій або іншій мові програмування. Звичайно, у першу чергу маються на увазі мови, що підтримують концепцію ООП, такі як C++, Java, Object Pascal. Саме ця властивість мови UML робить його сучасним засобом рішення завдань моделювання складних систем. У той же час, передбачається, що для програмної підтримки конструкцій мови UML можуть бути розроблені спеціальні інструментальні CASE-Засоби. Наявність останніх має принципове значення для широкого поширення й використання мови UML.
- Опис мови UML повинне містити в собі семантичний базис для розуміння загальних особливостей ООАП.
Говорячи про цю особливість, мають на увазі самодостатність мови UML для розуміння не тільки його базових конструкцій, але що не менш важливо - розуміння загальних принципів ООАП. У цьому зв'язку необхідно відзначити, що оскільки мова UML не є мовою програмування, а служить засобом для рішення завдань об’єктно-орієнтованого моделювання систем, опис мови UML повинне по можливості містити в собі всі необхідні поняття для ООАП. Без цієї властивості мова UML може виявитися марною й незатребуваною більшістю користувачів, які не знайомі із проблематикою ООАП складних систем.
З іншого боку, які б те не було посилання на додаткові джерела, що містять важливу для розуміння мови UML інформацію, на думку розроблювачів з OMG, повинні бути виключені. Це дозволить уникнути неоднозначного тлумачення принципових особливостей процесу ООАП і їхньої реалізації у формі базових конструкцій мови UML.
- Заохочувати розвиток ринку об'єктних інструментальних засобів.
Більше 800 провідних виробників програмних і апаратних засобів, зусилля яких зосереджені в рамках OMG, бачать перспективи розвитку сучасних інформаційних технологій і основу свого комерційного успіху в широкому просуванні на ринок інструментальних засобів, що підтримують об'єктні технології. Говорячи ж про об'єктні технології, розроблювачі з OMG мають на увазі, насамперед, сукупність технологічних рішень CORBA і UML. Із цього погляду мові UML приділяється роль базового засобу для опису й документування різних об'єктних компонентів CORBA.
- Сприяти поширенню об'єктних технологій і відповідних понять ООАП.
Це завдання тісно пов'язана з попередньої й має з нею багато загального. Якщо виключити з розгляду рекламні заяви розроблювачів про виняткову гнучкість і потужність мови UML, а спробувати скласти об'єктивну картину можливостей цієї мови, то можна прийти до наступного висновку. Варто визнати, що зусилля досить великої групи розроблювачів були спрямовані на інтеграцію в рамках мови UML багатьох відомих технік візуального моделювання, які успішно зарекомендували себе на практиці. Хоча це привело до ускладнення мови UML у порівнянні з відомими нотаціями структурного системного аналізу, платою за складність є дійсно висока гнучкість і зображальні можливості вже перших версій мови UML. У свою чергу, використання мови UML для рішення всіляких практичних завдань буде тільки сприяти його подальшому вдосконалюванню, а значить і подальшому розвитку об'єктних технологій і практики ООАП.
- Інтегрувати в себе новітні й найкращі досягнення практики ООАП.
Мова UML безупинно вдосконалюється розроблювачами, і основою цієї роботи є його подальша інтеграція із сучасними модельними технологіями. При цьому різні методи системного моделювання одержують своє прикладне осмислення в рамках ООАП. Надалі ці методи можуть бути включені до складу мови UML у формі додаткових базових понять, найбільше адекватно й найкращі досягнення, що повно відбивають, практики ООАП.
Щоб вирішити зазначені вище завдання, за свою недовгу історію мова UML перетерпів певну еволюцію. У результаті опис самої мови UML стало нетривіальним, оскільки семантика базових понять містить у собі цілий ряд перехресних зв'язків з іншими поняттями й конструкціями мови. У зв'язку із цим так званий лінійний або послідовний розгляд основних конструкцій мови UML стало практично неможливим, тому що ті самі поняття можуть використовуватися при побудові різних діаграм або подань. У той же час кожне з подань моделі має власні семантичні особливості, які накладають відбиток на семантику базових понять мови в цілому.
