Примітка. Зображений вище фрагмент семантичної мережі може бути розширений специфікою вирішуваного завдання

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

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

4.2. Діаграми структурного системного аналізу

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

У рамках цього напряму в програмній інженерії прийнято розглядати три графічні нотації, що отримали назви діаграм: діаграми "сутність-зв'язок (Entity-Relationship Diagrams, ERD)", діаграми функціонального моделювання (Structured Analysis and Design Technique, SADT) і діаграми потоків даних (Data Flow Diagrams, DFD).

4.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 р.). Ці документи послужили своєрідним каталізатором для широкого обговорення мови 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. Ця версія мови моделювання була досить добре визначена, забезпечувала необхідну виразність і потужність і припускала вирішення широкого класу завдань.

Поиск по сайту: