2.3. Основні етапи розвитку uml
Окремі язики об'єктно-орієнтованого моделювання сталі з'являтися в період між серединою 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‑ засобів, яка необхідна для успішного просування відповідних програмних ин‑ струментариев. Нарешті, спільна робота давала надію на істотне поліпшення всіх трьох методів.
Починаючи роботу по уніфікації своїх методів, Р. Буч, Дж. Румбах і А. Дже‑ кобсон сформулювали наступні вимоги до язика моделювання. Він повинен:
Дозволяти моделювати не тільки програмне забезпечення, але і більш широкі класи систем і бізнес‑ додатків, з використанням об'єктно-орієнтованих понять.
Явним чином забезпечувати взаємозв'язок між базовими поняттями для моделей концептуального і фізичного рівнів.
Забезпечувати масштабованість моделей, що є важливою особливістю складних багатоцільових систем.
Бути зрозумілий аналітикам і програмістам, а також повинен підтримуватися спеціальними інструментальними засобами, реалізованими на різних комп'ютерних платформах.
Розробка системи позначень або нотації для ООАП виявилася несхожою на розробку нового язика програмування. По-перше, необхідно було розв'язати дві проблеми:
1. Чи повинна дана нотація включати специфікацію вимог?
2. Чи слід розширювати дану нотацію до рівня язика візуального програмування?
По-друге, було необхідно знайти вдалий баланс між виразністю і простотою язика. З одного боку, дуже проста нотація обмежує круг потенційних проблем, які можуть бути вирішені за допомогою відповідної системи позначень. З другого боку, дуже складна нотація створює додаткові труднощі для її вивчення і вживання аналітиками і програмістами. У разі уніфікації існуючих методів необхідно враховувати інтереси фахівців, які вже мають досвід роботи з ними, оскільки внесення серйозних змін в нову нотацію може спричинити за собою нерозуміння і неприйняття її користувачами колишніх методик. Щоб виключити неявний опір з боку окремих фахівців, необхідно враховувати інтереси найширшого круга користувачів. Подальша робота над язиком 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. Ця версія язика моделювання була достатньо добре визначена, забезпечувала необхідну виразність і потужність і припускала рішення широкого класу задач.
Примітка
Всіма партнерами консорціуму усвідомлюється важливість стандартизації язика UML, яка є необхідною основою для подальшої розробки інструментальних CASE‑ засобів. При цьому розробка кожного стандарту в рамках консорціуму OMG починається з випуску документа, званого запитом пропозицій (Request For Proposals, RFP). Документи RFP відповідно до встановленої в OMG процедури явно формулюють цілі майбутньої розробки, вимоги, яким винні задовольняти пропозиції, що претендують на стандартизацію, і оголошуються терміни їх уявлення. Окремі RFP є офіційними документами, якими керуються розробники варіантів проектів відповідних стандартів.
Інструментальні 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 графічно представлена на мал. 2.20.
Мал. 2.20. Історія розвитку язика UML
Статус язика 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 з своїми стандартами типа ActiveX і СОМ і у використовування язика 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 потенційні можливості можуть бути використані не тільки для об'єктно-орієнтованого моделювання систем, але і для представлення знань в інтелектуальних системах, якими, по суті, стануть перспективні складні програмно‑ технологічні комплекси.
РОЗДІЛ 3
Основні компоненти язика UML
Язик UML є спільноцільовим язиком візуального моделювання, який розроблений для специфікації, візуалізації, проектування і документування компонентів програмного забезпечення, бізнес‑ процесів і інших систем. Язик UML одночасно є простим і могутнім засобом моделювання, який може бути ефективно використаний для побудови концептуальних, логічних і графічних моделей складних систем самого різного цільового призначення. Цей язик увібрав в себе якнайкращі якості методів програмної інженерії, які з успіхом використовувалися протягом останніх років при моделюванні великих і складних систем.
Язик UML заснований на деякому числі базових понять, які можуть бути вивчені і застосовані більшістю програмістів і розробників, знайомих з методами об'єктно-орієнтованого аналізу і проектування. При цьому базові поняття можуть комбінуватися і розширятися таким чином, що фахівці об'єктного моделювання дістають можливість самостійно розробляти моделі великих і складних систем в самих різних областях додатків.
Конструктивне використовування язика UML грунтується на розумінні загальних принципів моделювання складних систем і особливостей процесу об'єктно-орієнтованого аналізу і проектування зокрема. Вибір виразних засобів для побудови моделей складних систем зумовлює ті задачі, які можуть бути вирішені з використанням даних моделей. При цьому одним з основних принципів побудови моделей складних систем є принцип абстрагування, який наказує включати в модель тільки ті аспекти проектованої системи, які мають безпосереднє відношення до виконання системою своїх функцій або свого цільового призначення. При цьому всі другорядні деталі опускаються, щоб надмірно не ускладнювати процес аналізу і дослідження одержаної моделі.
Іншим принципом побудови моделей складних систем є принцип многомодельности. Цей принцип є твердженням про те, що ніяка єдина модель не може з достатнім ступенем адекватності описувати різні аспекти складної системи. Стосовно методології ООАП це означає, що достатньо повна модель складної системи допускає деяке число взаємозв'язаних уявлень (views), кожне з яких адекватно відображає деякий аспект поведінки або структури системи. При цьому самими загальними представленнями складної системи прийнято рахувати статичне і динамічне уявлення, які у свою чергу можуть підрозділятися на інші більш приватні уявлення.) феномен складної системи якраз і полягає в тому, що ніяке її єдине уявлення не є достатнім для адекватного виразу всіх особливостей модельованої системи.
Ще одним принципом прикладного системного аналізу є принцип ієрархічної побудови моделей складних систем. Цей принцип наказує розглядати процес побудови моделі на різних рівнях абстрагування або деталізації в рамках фіксованих уявлень. При цьому початкова або первинна модель складної системи має саме загальне уявлення (метапредставление). Така модель будується на початковому етапі проектування і може не містити багатьох деталей і аспектів модельованої системи.
Мал. 3.1. Загальна схема взаємозв'язків моделей і представлень складної системи в процесі об'єктно-орієнтованого аналізу і проектування
Таким чином, процес ООАП можна представити як порівневий спуск від самих загальних моделей і представлень концептуального рівня до більш приватних і детальних представлень логічного і фізичного рівня. При цьому на кожному з етапів ООАП дані моделі послідовно доповнюються все великою кількістю деталей, що дозволяє їм більш адекватно відображати різні аспекти конкретної реалізації складної системи. Загальна схема взаємозв'язків моделей ООАП представлена на мал. 3.1.
Примітка
Назва «фізична модель» в термінології ООАП і язика UML відрізняється від загальноприйнятого трактування цього терміну в загальній класифікації моделей систем. В останньому випадку під фізичною моделлю системи розуміють деяку матеріальну конструкцію, що володіє властивостями подібності з формою оригіналу. Прикладами таких моделей можуть служити моделі технічних систем (літаків, кораблів), архітектурних споруд (будівель, мікрорайонів). Що стосується використовування цього терміну в ООАП і язиці UML, то тут фізична модель відображає компонентний склад проектованої системи з погляду її реалізації на деякій технічній базі і обчислювальних платформах конкретних виробників.
3.1. Призначення язика UML
Язик UML призначений для вирішення наступних задач :
1. Надати в розпорядження користувачів легко сприйманий і виразний язик візуального моделювання, спеціально призначений для розробки і документування моделей складних систем самого різного цільового призначення.
Йдеться про те, що важливим чинником подальшого розвитку і повсюдного використовування методології ООАП є інтуїтивна ясність і зрозумілість основних конструкцій відповідного язика моделювання. Язик UML включає не тільки абстрактні конструкції для представлення метамоделей систем, але і цілий ряд конкретних понять, що мають цілком певну семантику. Це дозволяє язику UML одночасно досягти не тільки універсальності представлення моделей для самих різних додатків, але і можливості опису достатньо тонких деталей реалізації цих моделей стосовно конкретних систем.
Практика системного моделювання показала, що абстрактного опису язика на деякому метарівні недостатньо для розробників, які ставлять свою за мету реалізацію проекту системи в конкретні терміни. В даний час має місце деякий концептуальний розрив між загальною методологією моделювання складних систем і конкретними інструментальними засобами швидкої розробки додатків. Саме цей розрив за задумом OMG і покликаний заповнити язик UML.
Звідси витікає важливе слідство – для адекватного розуміння базових конструкцій язика UML важливо не тільки володіти деякими навиками об'єктно-орієнтованого програмування, але і добре уявляти собі загальну проблематику процесу розробки моделей систем. Саме інтеграція цих уявлень утворює нову парадигму ООАП, практичним слідством і центральним стрижнем якої є язик UML.