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. Ця версія мови моделювання була досить добре визначена, забезпечувала необхідну виразність і потужність і припускала вирішення широкого класу завдань.
Примітка
Всіма партнерами консорціуму усвідомлюється важливість стандартизації мови 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 не є власністю і не запатентована ким-небудь, хоча вказаний вище документ захищений законом про авторське право. В той же час абревіатура 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 Repository, що розробляються разом з Texas Instruments. При створенні мови UML Microsoft внесла свій внесок до інтеграції UML зі своїми стандартами типу ACTIVEX і СОМ і у використання мови UML зі своєю технологією Microsoft Repository.
Рис. 4.20. Історія розвитку мови UML
На основі технології 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 потенційні можливості можуть бути використані не тільки для об'єктно-орієнтованого моделювання систем, але і для представлення знань в інтелектуальних системах, якими, по суті, стануть перспективні складні програмно-технологічні комплекси.
Висновки
Множина – сукупність однотипних елементів, що не мають порядку і не повторюються.
Граф – сукупність двох множин: множина крапок або вершин і множина ліній, що сполучають їх, або ребер. Формально граф задається у вигляді двох множин: G=(V, Е), де V={v1v2 ..., vn} – множина вершин графа, а Е={ е1, е2 ..., еm} – множина ребер графа.
Дерево – граф D=<V, E>, між будь-якими двома вершинами якого існує єдиний простий ланцюг, тобто неорієнтований маршрут, у якого вершини і ребра не повторюються; це орієнтований граф, якщо між коренем дерева v0 і будь-якою іншою вершиною існує єдиний шлях, що бере початок в v0.
Семантична мережа – граф Gs= =(Vs, Es), у якому множина вершин Vs і множина ребер Es розділені на окремі типи, що володіють спеціальною семантикою, характерною для конкретної предметної області. У цій ситуації множина вершин може відповідати об'єктам або сутностям предметної області і мати замість номерів вершин відповідні явні імена цих сутностей.
UML розвивається ще досі, орієнтована для застосування як мова моделювання різними користувачами і науковими співтовариствами для вирішення широкого класу завдань ОКАП.
Контрольні питання
1. Поняття множини.
2. Елементи теорії графів.