Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

PrIS

.pdf
Скачиваний:
45
Добавлен:
07.12.2018
Размер:
7.24 Mб
Скачать

91

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

Рис. 4.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б).

У першому випадку (рис. 4.6, а) вершина утворює перший рівень ієрархії, вершини – другий рівень ієрархії, вершина – третій і останній рівень ієрархії. При цьому листям такого неорієнтованого дерева є вершини . У другому випадку (рис. 4.6, б) вершини утворюють перший рівень ієрархії, вершини v4 і v6 – другий рівень ієрархії, вершина – третій і останній рівень ієрархії. Листям такого орієнтованого дерева є вершини .

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

4.1.3. Семантичні мережі

Семантичні мережі розвивалися в рамках наукового напряму, пов'язаного з поданням знань для моделювання міркувань людини. Ця

92

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

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

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

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

Як конкретний варіант подання інформації у вигляді семантичної мережі розглянемо приклад з класом "Автомобіль" із розділу 3. Фраґмент семантичної мережі, яка описує ієрархію класів цієї предметної області, може бути зображено таким чином (рис. 4.7). На цьому рисунку окремі вершини семантичної мережі зображаються прямокутниками із заокругленими кінцями і служать для умовного позначення класів предметної області. Ребра, які з’єднують вершини, мають цілком певний

93

сенс або семантику. А саме, вони явно вказують, що вершина або клас, розташовані на рисунку нижче, є підкласом класу вищого за рівнем.

Рис 4.7. Фраґмент семантичної мережі для зображення ієрархії класів "Автомобіль".

Наприклад, класи "Легковий автомобіль" і "Вантажний автомобіль" є підкласами класу "Автомобіль", а класи "Модель ВАЗ-21083" і "Модель ВАЗ-21099" є підкласами класу "Легковий автомобіль ВАЗ". Ребра або зв'язки цієї семантичної мережі мають єдиний тип, визначений семантикою включення класів один в одного. Тому жодних додаткових позначень вони не містять.

Примітка

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

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

94

інформації. Найбільшого поширення в ці роки набув підхід до моделювання програмних систем, який назвали системним структурним аналізом (ССА). Оскільки багато ідей ССА безпосередньо вплинули на розвиток мови UML (Unified Modeling Language), а використовувана графічна нотація була реалізована в деяких CASE-засобах, нижче наводиться коротка характеристика основних компонентів цього напряму графічного моделювання програмних систем.

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

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

У рамках цього напряму в програмній інженерії прийнято розглядати три графічні нотації, що отримали назви діаграм: діаграми

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

4.3. Основні етапи розвитку UML

Мови об'єктно-орієнтованого моделювання почали з'являтися в період між серединою 1970-х і кінцем 1980-х років, коли різні дослідники і програмісти пропонували свої підходи до ООАП. У період між 19891994 рр. загальна кількість найвідоміших мов моделювання зросла з 10 до більш, ніж 50. Жодна з мов ООАП не задовольняла всіх вимог, що пред'являються до побудови моделей складних систем. Прийняття окремих методик і графічних нотацій як стандартів (IDEF0, IDEF1X) не змогло змінити ситуацію непримиренної конкуренції, що склалася між ними на початку 90-х років, яка також названа "Війною методів".

До середини 1990-х років деякі з методів були істотно покращені і набули самостійного значення під час вирішення різних завдань ООАП. Найвідомішими в цей період стають:

95

метод Ґраді Буча (Grady Booch), що отримав умовну назву Booch або

Booch'91, Booch Lite (пізніше – Booch'93);

метод Джеймса Румбаха (James Rumbaugh), що отримав назву Object Modeling Technique, – ОМТ (пізніше – ОМТ-2);

метод Айвара Джекобсона (Ivar Jacobson), що отримав назву ObjectOriented Software Engineering, – OOSE.

Кожний з цих методів був орієнтований на підтримку окремих етапів ООАП. Наприклад, метод OOSE містив засоби відображення варіантів використання, які мають істотне значення на етапі аналізу вимог у процесі проектування бізнес-програм. Метод ОМТ-2 був найбільш придатним для аналізу процесів опрацювання даних в інформаційних системах. Метод Booch'93 знайшов найбільше застосування на етапах проектування і розроблення різних програмних систем.

Історія розвитку мови UML бере початок з жовтня 1994 року, коли Ґраді Буч і Джеймс Румбах з Rational Software Corporation почали роботу з уніфікації методів Booch і ОМТ (див. рис. 4.20). Хоча самі собою ці методи були достатньо популярними, спільна робота була направлена на вивчення всіх відомих об'єктно-орієнтованих методів з метою об'єднання їх переваг. При цьому Ґ.Буч і Дж. Румбах зосередили зусилля на повній уніфікації результатів своєї роботи. Проект так званого уніфікованого методу (Unified Method) версії 0.8 був підготовлений і опублікований у жовтні 1995 року. Цієї осені до них приєднався А. Джекобсон – головний технолог з компанії Objectory AB (Швеція), з метою інтеґрації свого методу OOSE з двома попередніми.

Спочатку автори методів Booch, ОМТ і OOSE припускали розробити уніфіковану мову моделювання тільки для цих трьох методик. З одного боку, кожний з цих методів був перевірений на практиці і показав свою конструктивність під час вирішення окремих завдань ООАП. Це дало підставу для подальшої їх модифікації на основі усунення наявної невідповідності окремих понять і позначень. З іншого боку, уніфікація семантики і нотації мала забезпечити деяку стабільність на ринку об'єктно-орієнтованих CASE-засобів, яка необхідна для успішного просування відповідних програмних інструментаріїв. Нарешті, спільна робота давала надію на істотне покращення всіх трьох методів.

Починаючи роботу з уніфікації своїх методів, Ґ. Буч, Дж. Румбах і А. Джекобсон сформулювали такі вимоги до мови моделювання:

дозволяти моделювати не тільки програмне забезпечення, але й ширші класи систем і бізнес-програм з використанням об'єктно-орієнтованих понять;

явним чином забезпечувати взаємозв'язок між базовими поняттями для моделей концептуального і фізичного рівнів;

96

забезпечувати масштабованість моделей, що є важливою особливістю складних багатоцільових систем;

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

Рис. 4.20. Історія розвитку мови UML.

Розроблення системи позначень, або нотації, для ООАП виявилося несхожим на розроблення нової мови програмування. По-перше, необхідно було вирішити дві проблеми.

1.Чи повинна ця нотація включати специфікацію вимог?

2.Чи треба розширювати цю нотацію до рівня мови візуального програмування?

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

97

відповідної системи позначень. З іншого боку, надто складна нотація створює додаткові труднощі для її вивчення і застосування аналітиками та програмістами. У разі уніфікації наявних методів необхідно враховувати інтереси фахівців, які вже мають досвід роботи з ними, оскільки внесення серйозних змін до нової нотації може спричинити нерозуміння і неприйняття її користувачами попередніх методик. Подальша робота над мовою 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. Ця версія мови моделювання була досить добре визначена, забезпечувала необхідну виразність і потужність і припускала вирішення широкого класу завдань.

Примітка

Усіма партнерами консорціуму усвідомлюється важливість стандартизації мови UML, яка є необхідною основою для подальшого

98

розроблення інструментальних 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 не є власністю і не запатентована будь-ким, хоча вказаний вище документ захищений законом про авторське право. У той же час абревіатура UML, як і деякі інші (OMG, CORBA, ORB), є торговою маркою їх законних власників, про що треба пам’ятати в такому контексті.

99

Мова 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 Repository, що розробляються разом з 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 може бути розширена без перевизначення її ядра.

100

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

Висновки

1.Множина – сукупність однотипних елементів, що не мають порядку і не повторюються.

2.Граф – сукупність двох множин: множина крапок, або вершин, і множина ліній, що сполучають їх, або ребер. Формально граф

задається у вигляді двох множин:

G=(V, Е), де V={

}

множина вершин графу, а Е={

} – множина ребер графу.

3. Дерево – граф D=<V, E>, між будь-якими двома вершинами якого існує єдиний простий ланцюг, тобто неорієнтований маршрут, у якого вершини і ребра не повторюються; це орієнтований граф, якщо між коренем дерева v0 і будь-якою іншою вершиною існує єдиний шлях, що бере початок у v0 .

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

5. UML розвивається ще досі, орієнтована для застосування як мова моделювання різними користувачами і науковими співтовариствами для вирішення широкого класу завдань ООАП.

Контрольні запитання

1.Поняття множини.

2.Елементи теорії графів.

3.Семантичні мережі.