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

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

Висновки

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

2. Граф – сукупність двох множин: множина крапок або вершин і множина ліній, що сполучають їх, або ребер. Формально граф задається у вигляді двох множин: G=(V, Е), де V={v1v2..., vn} – множина вершин графа, а Е={ е1, е2..., еm} – множина ребер графа.

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

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

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

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

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

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

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

4. Мови об'єктно-орієнтованого моделювання.

РОЗДІЛ 5. Структурний підхід

à Принципи структурного проектування

à Методологія структурного проетування

à Інструментальні засоби структурного проектування

à Діаграми структурного проектування

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

5.1. Принципи структурного підходу до проектування

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

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

Структурне проектування відносять до традиційних технологій проектування. Основні характеристики традиційних методологій представлені в таблиці 5.1.

Методологія структурної розробки або структурний підхід виділяють у традиційних методологіях. Основою цих методологій є:

¨ структурний аналіз,

¨ структурне проектування,

¨ структурне програмування.

Детальніше опишемо структурний аналіз та структурне проектування.

Структурне програмування не розглядається у цій книжці.

Таблиця 5.1. Характеристики традиційних методологій розробки

5.2. Структурний аналіз

Структурний аналіз надзвичайно наочний метод, що покладається головним чином на діаграми, а не на описовий текст. Його основний інструмент – діаграми, що формують графічне представлення складених процесів системи й інтерфейсів між ними.

Структурний аналіз пропонує логічну графічну модель потоку інформації, поділяючи системи на модулі, що показують рівні, які піддаються керуванню та деталізації.

Особливості структурного аналізу представлені в таблиці 5.2.

Таблиця 5.2. Структурний аналіз

Усі найпоширеніші методології структурного підходу [31, 44] базуються на ряді загальних принципів [1]. Як два базові принципи використовуються наступні:

¨ принцип "розділяй і володарюй" - принцип вирішення складних проблем шляхом їх розбиття на безліч менших незалежних завдань, легких для розуміння і вирішення;

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

Виділення двох базових принципів не означає, що останні принципи є другорядними, оскільки ігнорування будь-яке з них може привести до непередбачуваних наслідків (у тому числі і до провалу всього проекту). Основними з цих принципів є наступні:

¨ принцип абстрагування - полягає у виділенні істотних аспектів системи і відвернення від неістотних;

¨ принцип формалізації - полягає в необхідності строгого методичного підходу до вирішення проблеми;

¨ принцип несуперечності - полягає в обгрунтованості і узгодженості елементів;

¨ принцип структуризації даних - полягає в тому, що дані мають бути структуровані і ієрархічно організовані.

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

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

5.3. Структурне проектування

Структурний підхід до проектування ІС (структурний аналіз/структурне проектування SA/SD — Structure Analyses & Structure Design) – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.

Методологія SADT розроблена Дугласом Россом і отримала подальший розвиток в роботі [4]. На її основі розроблена, зокрема, відома методологія IDEF0 (розглянуто нижче).

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

¨ Графічне представлення блокового моделювання. Графіка блоків і дуг SADT-діаграми відображує функцію у вигляді блоку, а інтерфейси входа/выхода представляються дугами, що відповідно входять в блок і виходять з нього. Взаємодія блоків один з одним описуються за допомогою інтерфейсних дуг, що виражають "обмеження", які у свою чергу визначають, коли і яким чином функції виконуються і управляються.

¨ Строгість і точність. Виконання правив SADT вимагає достатньої строгості і точності, не накладаючи в той же час надмірних обмежень на дії аналітика. Правила SADT включають:

¡ обмеження кількості блоків на кожному рівні декомпозиції (правило 15.6 блоків);

¡ зв'язність діаграм (номери блоків);

¡ унікальність міток і назв (відсутність імен, що повторюються);

¡ синтаксичні правила для графіки (блоків і дуг);

¡ розділення входів і управлінь (правило визначення ролі даних);

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

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

Результатом методології SADT є модель, яка складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми - головні компоненти моделі, усі функції ІС й інтерфейси на них представлені як блоки і дуги. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керівна інформація в блок зверху, тоді як інформація, яка піддається опрацюванню, показана з лівого боку блоку, а результати виходу показані з правого боку. Механізм (людина або автоматизована система), який здійснює операцію, представляється дугою, що входить в блок знизу.

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

Кожен компонент моделі може бути декомпозиціонований на іншій діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі.

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

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

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

5.4. Методологія структурного аналізу

Представлення діяльності організації окремими взаємоузгодженими процесами та постійний контроль за ними і їх результатами є втіленням процесного підходу в управлінні [3; 7]. У цьому напрямі розроблено велику кількість стандартів та методологій, найпоширенішими серед яких є сукупність стандартів IDEF. Ця абревіатура походить від ICAM Definition Method, де ICAM розшифровується як Integrated Computer Aided Manufacturing, тобто “Інтегроване комп’ютер-орієнтоване виробництво”. Кожний із стандартів IDEF визначає певну систему нотацій (перш за все графічних) та конкретну методологію її використання.

Сьогодні до сукупності IDEF можна віднести такі стандарти:

¨ IDEF0 - методологія функціонального моделювання;

¨ IDEF1 - методологія моделювання інформаційних потоків усередині системи, яка дозволяє відображати та аналізувати їх структуру і взаємозв’язки;

¨ IDEF1X (IDEF1 Extended) - методологія побудови реляційних структур (баз даних), яка належить до типу методологій “Сутність-відношення” (ER - Entity-Re­lationship) та, як правило, використовується для моделювання реляційних баз даних;

¨ IDEF2 - методологія динамічного моделювання розвитку систем (у зв’язку з серйозними складностями аналізу динамічних систем від цього стандарту прак­тично відмовились, і його розвиток зупинився на початковому етапі);

¨ IDEF3 - методологія документування технологічних процесів;

¨ IDEF4 - методологія побудови об’єктно-орієнтованих систем, яка дозволяє ві­дображати структуру об’єктів та принципи їх взаємодії, дозволяючи тим самим аналі­зувати й оптимізувати складні об’єктно-орієнтовані системи;

¨ IDEF5 - стандарт онтологічного дослідження складних систем (під онтологі­єю тут розуміють певну формалізовану інформаційну архітектуру об’єкта).

Крім вищезгаданої сукупності до категорії поширених слід віднести стан­дарти DFD (Data Flow Diagram - діаграми потоків даних), SADT (Structured Analysis and Design Technique - моделі і відповідні функціональні діаграми) та WFD (Work Flow Diagram - діаграми робочих потоків). Вони містять набори символів або позначень, за допомо­гою яких може бути описаний бізнес-процес. Ці позначення прийнято називати мовою або методологією опису процесів. Незважаючи на різницю у назвах, ці методології є майже ідентичними за філософією побудови моделей управлінських процесів.

Практично всі названі вище стандарти мають відповідну комп’ютерну підтримку у вигляді програмних рішень. Більше того, практичні всі вони використову­ються для підтримки процесів побудови інформаційних систем, для автоматизації ок­ремих бізнес-процесів. З огляду на це програмні засоби відносять до категорії CASE-засобів (Computer Aided System/Software Engineering - комп’ютер-орієнтована систе­мна/програмна інженерія).

Методологія IDEF0 є основою для широко відомої програмної системи BPwin (Business Process for Windows). Модель будується за допомогою “функціональних блоків” та “інтерфейсних дуг”. Перші нагадують кусково-лінійні агрегати [9], а за допомогою дуг, які пов’язують між собою блоки, можна зобразити процес будь-якого рівня складності.

Нотація IDEF2 ніколи не була повністю реалізована. Нотація IDEF1 в 1985 році була розширена і перейменована в IDEF1X. Методологія IDEF-SADT, знайшла застосування в урядових і комерційних організаціях, оскільки на той період часу цілком задовольняла різним вимогам, що пред'являються до моделювання широкого класу систем.

На початку 1990 року спеціальна група користувачів IDEF (IDEF Users Group), в співпраці з Національним інститутом по стандартизації і технології США (National Institutes for Standards and Technology, NIST), зробила спробу створення стандарту для IDEF0 і IDEF1X. Ця спроба виявилася успішною і завершилася ухваленням в 1993 році стандарту уряду США, відомого як FIPS для даних двох технологій IDEF0 і IDEF1X. Протягом подальших років цей стандарт продовжував активно розвиватися і став основою для реалізації в деяких перших CASE-засобах.

Для підтримки стандартів IDEF1/IDEF1X існує багато інструментальних засобів, оскільки головною метою у цьому випадку виступають бази даних. СКБД - системи управління базами даних, - які при цьому використовуються, історично мають у сво­єму складі відповідні програмні рішення. Ще до офіційної появи стандартів IDEF1 вже існували та використовувалися методологія Oracle, методологія Power Builder та ін. З появою стандартів цього класу до лідерів приєдналася програмна система ERwin, а саму методологію стали називати ER-моделюванням.

Останнім часом обидві програмні системи BPwin та ERwin випускають у складі інтегрованого CASE-засобу AllFusion Modeling Suite.

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

Методології IDEF3, IDEF4 та IDEF5 можна вважати більш “екзотичними”, ніж попередні, тому важко назвати відомі приклади інструментальних засобів їх підтримки. Але як елементи інтегрованих технологій вони можуть викорис­товуватись. Крім того, стандарт IDEF4 має конкурента в особі стандарту MDA (Model Driven Architecture - архітектура, керована моделлю), який на сьогодні вважається ін­дустріальним ІТ-стандартом для об’єктно-орієнтованих систем. Цей стандарт ґрунту­ється на використанні мови UML (Unified Modeling Language - уніфікована мова мо­делювання) [10].

Не можна не згадати про ARIS (від Architecture of Integrated Information Systems), яка являє собою методологію та програмний продукт компанії IDS Sheer, при­значений для моделювання бізнес-процесів. Основною перевагою ARIS можна вва­жати її високу інтегрованість. Фактично вона включає підтримку більшості стандар­тів, які ми розглядали окремо. Зрозуміло, що такий продукт призначений виключно для великих проектів. Остання обставина робить її менш доступною для “ізольовано­го” використання, коли задіяні тільки окремі функції з великого переліку.

5.5. Інструментальні засоби структурного аналізу та проектування

У якості інструментальних засобів структурного аналізу і проектування виступають наступні діаграми:

¨ BFD (Bussiness Function Diagram) - діаграма бізнес - функцій;

¨ DFD (Data Flow Diagram) – діаграма потоків даних;

¨ STD (State Transition Diagram) - діаграма переходів станів;

¨ ERD (Entity Relationship Diagram) - модель «сутність-зв'язок» даних предметної області (інформаційно-логічна модель);

¨ SSD (System Structure Diagram) - діаграма структури програмного застосування.

Проте зі всього різноманіття цих моделей найчастіше на практиці застосовуються діаграми потоків даних (DFD), діаграми «сутність-зв'язок» (ERD) і діаграми переходів станів (STD). Усі вони містять графічні та текстові засоби моделювання: для зручності демонстрування основних компонент моделі і забезпечення точного визначення її компонент і зв'язків.

Висновки

1. Структурний підхід до проектування ІС – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.

2. Є два базових принципи структурного аналізу та проектування: принцип «розділяй та владарюй» та принцип ієрархічного впорядкування..

3. Сукупність стандартів IDEF використовується в методології структурного аналізу.

4. Інструментальними засобами структурного аналізу є: діаграма бізнес-функцій, діаграма потоків даних, діаграма сутність-зв’язок, діагарма переходів станів, діаграма структури програмного застомування.

5. Структурний підхід до проектування ІС (структурний аналіз/структурне проектування SA/SD — Structure Analyses & Structure Design) – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.

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

1. Основні принципи структурного підходу.

2. Особливості структурного аналізу.

3. Методології структурного проектування.

4. Інструментальні засоби структурного аналізу та проектування.

РОЗДІЛ 6. Методологія функціонального моделювання SADT

à Основні елементи діаграм.

à Типи зв’язків.

à Техніка побудови діаграм.

à Діаграма бізнес-функцій.

У розділі викладено базові вимоги до побудови діаграм структурного проектування. Описано діаграму бізнес-функцій.

6.1. Основні елементи

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

Розглянемо стисло ці основні поняття методології IDEF-SADT, які використовуються під час побудови діаграм функціонального моделювання. Діяльністю є деяка дія або набір дій, які мають фіксовану мету і приводять до деякого кінцевого результату. Іноді діяльність називають просто процесом. Моделі IDEF0 відстежують різні види діяльності системи, їх опис і взаємодію з іншими процесами. На діаграмах процес зображається прямокутником, який називається блоком. Дуга служить для позначення деякого носія або дії, які забезпечують перенесення даних або об'єктів від однієї діяльності до іншої. Дуги також необхідні для опису діяльностей і спожитих ними ресурсів. Це так звані ролі дуг – ICOM – скорочення перших букв від назв відповідних дуг IDEF0. Розрізняють дуги чотирьох видів:

¨ I (Input) – вхід, тобто все, що поступає в процес або споживається процесом.

¨ С(Control) – керування або обмеження на виконання операцій процесу.

¨ О (Output) – вихід або результат процесу.

¨ М (Mechanism) – механізм, який використовується для виконання процесу.

Методологія IDEF0 однозначно визначає, яким чином зображаються на діаграмах дуги кожного виду ICOM. Дуга Вхід (Input) виходить з лівої сторони рамки робочого поля і входить зліва в прямокутник процесу. Дуга Керування (Control) входить і виходить зверху. Дуга Вихід (Output) виходить з правої сторони процесу і входить в праву сторону рамки. Дуга Механізм (Mechanism) входить в прямокутник процесу знизу. Таким чином, базове подання процесу на діаграмах IDEF0 має наступний вигляд (рис. 6.1).

Рис. 6.1. Позначення процесу і стрілок ICOM на діаграмах IDEF0

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

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

На SADT-діаграмах не вказані явно ні послідовність, ні час. Зворотні зв'язки, ітерації, процеси, що продовжуються, і функції, що перекриваються (за часом), можуть бути подані за допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і так далі.

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

Кожен блок на діаграмі має свій номер. Блок будь-якої діаграми може бути далі описаний діаграмою нижнього рівня, яка, у свою чергу, може бути далі деталізована за допомогою необхідної кількості діаграм. Таким чином, формується ієрархія діаграм.

Для того, щоб вказати положення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 на діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є верхньою діаграмою моделі.

6.2. Типи зв’язків

Одним з важливих моментів при проектуванні ІС за допомогою методології SADT є точна узгодженість типів зв'язків між функціями. Розрізняють принаймні сім типів зв’язків:

¨ випадковий 0

¨ логічний 1

¨ тимчасовий 2

¨ процедурний 3

¨ комунікаційний 4

¨ послідовний 5

¨ функціональний 6

Нижче кожен тип зв'язку коротко визначений і проілюстрований за допомогою типового прикладу з SADT.

(0) Тип випадкової зв'язності: найменш бажаний.

Випадкова зв'язність виникає, коли конкретний зв'язок між функціями малий або повністю відсутній. Це відноситься до ситуації, коли імена даних на SADT-дугах в одній діаграмі мають малий зв'язок один з одним.

(1) Тип логічної зв'язності. Логічне скріплення відбувається тоді, коли дані і функції збираються разом унаслідок того, що вони потрапляють у загальний клас або набір елементів, але необхідних функціональних зв’язків між ними не виявляється.

(2) Тип тимчасової зв'язності. Зв'язані за часом елементи виникають унаслідок того, що вони представляють функції, зв'язані в часі, коли дані використовуються одночасно або функції включаються паралельно, а не послідовно.

(3) Тип процедурної зв'язності. Процедурно-зв'язані елементи є згрупованими унаслідок того, що вони виконуються протягом однієї і тієї ж частини циклу або процесу.

(4) Тип комунікаційної зв'язності. Діаграми демонструють комунікаційні зв'язки, коли блоки групуються унаслідок того, що вони використовують одні і ті ж вхідні дані і проводять одні і ті ж вихідні дані.

(5) Тип послідовної зв'язності. На діаграмах, що мають послідовні зв'язки, вихід однієї функції служить вхідними даними для наступної функції. Зв'язок між елементами на діаграмі є тіснішим, ніж на розглянутих вище рівнях в'язок, оскільки моделюються причинно-наслідкові залежності.

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

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

Таблиця 6.1. Зв’язки у методології SADT

6.3. Техніка побудови

Техніка побудови діаграм є головною особливістю методології IDEF-SADT. Місце з'єднання стрілки з блоком визначає тип інтерфейсу. При цьому всі функції модельованої системи і інтерфейси на діаграмах представляються у вигляді відповідних блоків процесів і стрілок ICOM. Інформація, що керує, входить в блок зверху, тоді як інформація, яка піддається опрацюванню, зображається з лівого боку блоку. Результати процесу представляються як виходи процесу і показуються з правої сторони блоку. Як механізм може виступати людина або автоматизована система, яка реалізує цю операцію. Відповідний механізм на діаграмі представляється стрілкою, яка входить в блок процесу знизу.

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

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

Рис. 6.2. Приклад початкової діаграми IDEF-SADT для процесу оформлення кредиту в банку

Зрештою модель IDEF-SADT є серією ієрархічно взаємозв'язаних діаграм з супровідною документацією, яка розбиває початкове представлення складної системи на окремі складові частини. Деталі кожного з основних процесів представляються у вигляді детальніших процесів на інших діаграмах. У цьому випадку кожна діаграма нижнього рівня є декомпозицією деякого процесу із загальнішої діаграми. Тому на кожному кроці декомпозиції загальніша діаграма конкретизується на ряд детальніших діаграм.

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

6.4. Діаграма бізнес – функцій

6.4.1. Призначення діаграми бізнес-функцій

Як правило, дана модель (Business function diagram – BFD) застосовується для складання розгорненого плану робіт в процесі експрес-обстеження при автоматизації великих об'єктів і обмежується першими рівнями декомпозиції бізнес-процесів, оскільки при зайвій деталізації важко здійснювати читання і супровід моделі.

На BF-діаграмі відображають кроки бізнес-процеса і потік документів і керування. Також на діаграмі можна відображати засоби автоматизації кроків бізнес-процесів. Цей тип діаграм зазвичай використовується для відображення третього і нижче за рівень декомпозиції бізнес-процесів (за перший рівень вважається ідентифікований перелік бізнес-процесів, а другим - функції, що виконуються в рамках бізнес-процесів).

Типовий приклад діаграми – діаграма з граничними рамками, які називаються каркасом діаграми. Каркас містить заголовок (верхня частина рамки), що складається з назви діаграми (номери і імена БП 1-го і 2-го рівнів) і версії. Заголовок каркаса використовується для відстежування діаграми в процесі моделювання.

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

6.4.2. Основні елементи

На схемах бізнес-процеса відображаються:

¨ функції процесу (біля кожної функції процесу вказані: назва, ідентифікатор, що складається з номер бізнес-процеса і номер функції, розділених крапкою);

¨ вхідна і вихідна інформація, при описі документів;

¨ зовнішні бізнес-процеси, описані на інших діаграмах;

¨ блоки прийняття рішення;

¨ точки розриву під час переходу процесу на інші сторінки.

У таблиці 6.2 поданий опис основних елементів BFD-діаграми.

Таблиця 6.2. Основні елементи BF-діаграми

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

Висновки

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

2. Основними елементами діаграм є процеси та дуги.

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

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

1. Основні елементи на діаграмах при структурному проектуванні.

2. Типи зв’язків між функціями.

3. Основні елементи BFD-діаграм.

РОЗДІЛ 7. Діаграми потоків даних

à Призначення діаграм потоків даних

à Зовнішні сутності

à Процеси

à Потоки даних

à Сховища даних

à Методології побудови

У розділі описано методологію побудови діаграм потоків даних та їх основне призначення.

7.1. Призначення діаграм потоків даних та основні елементи

Основою даної методології графічного моделювання інформаційних систем є спеціальна технологія побудови діаграм потоків даних (Data Flow Diagram - DFD). Це діаграми, на яких відображаються потоки даних, процеси перетворення вхідних потоків на вихідні, сховища інформації, джерела і споживачі інформації, зовнішні щодо системи.

У розробці методології DFD взяли участь багато аналітиків,серед яких слід відзначити Е.Йордона (E.Yourdon). Він є автором однієї з перших графічних нотацій DFD. В даний час найпоширенішою є так звана нотація Гейне-Сарсона (Gene-Sarson).

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

Відповідно до DFD методології, модель системи визначається як ієрархія діаграм потоків даних, що описують процеси перетворення інформації від моменту її введення в систему до видачі кінцевому користувачеві. Діаграми верхніх рівнів ієрархії – контекстні діаграми, задають межі моделі, визначаючи її оточення(зовнішні входи та виходи) і основні розглянуті процеси. Контекстні діаграми деталізуються за допомогою діаграм наступних рівнів.

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

Основними елементами діаграм потоків даних є:

¨ зовнішні сутності;

¨ процеси;

¨ накопичувачі даних;

¨ потоки даних.

7.1.1. Зовнішні сутності

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

В якості зовнішньої сутності на DF-діаграмі можуть виступати контрагенти, біржа, банки та інші. На жаль, DFD методологія не оформлена як стандарт. З цієї причини в діаграмах потоків даних використовуються різні умовні позначення. На рис.7.1 показані символи зовнішніх сутностей, що використовуються у нотації «Yourdon and Coad Process Notation» і «Gane and Sarson Process Notation».

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

Зовнішня сутність позначається прямокутником з тінню (рис. 7.1), всередині якого вказується її назва. При цьому як назву рекомендується використовувати іменник в називному відмінку. Іноді зовнішню сутність називають також термінатором.

Рис. 7.1.Символи зовнішніх сутностей.

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

7.1.2. Процеси

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

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

Рис. 7.2.Символи процесів.

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

Рис. 7.3. Зображення підсистеми на діаграмі потоків даних

Номер процесу служить для його ідентифікації. У полі імені вводиться найменування процесу у вигляді пропозиції з дієсловом у неозначеній формі (обчислити, розрахувати, перевірити, визначити, створити, отримати) і це пояснюють іменниками, наприклад: «Надрукувати адресу одержувача», «акцептувати рахунок». Інформація на нижньому полі символу процесу вказує, який підрозділ організації, співробітник, програма або апаратний пристрій виконує даний процес. Якщо таке поле відсутнє, то подібна інформація може бути вказана в текстовій примітці.

7.1.3. Накопичувачі даних

Накопичувачі (сховища) даних призначені для зображення абстрактних пристроїв для зберігання інформації, яку можна туди в будь-який момент часу помістити або витягти, відносно до їхньої конкретної фізичної реалізації. Накопичувачі даних являються прототипом бази даних інформаційної системи організації.

Найчастіше символи накопичувачів даних зображаються так, як на рис.7.4.

Рис. 7.4. Символи накопичувачів даних

Всередині символу вказується його унікальну в рамках даної моделі назву, яка найточніше, з точки зору аналітика, відображає інформаційну сутність вмісту, наприклад, «Угода», «Клієнти», і т.д. Символи накопичувачів даних в якості додаткових елементів ідентифікації можуть містити порядкові номери.

7.1.4. Потоки даних

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

7.2. Методологія побудови DFD.

Мета побудови ієрархічно взаємозв'язаних DFD - зробити вимоги до системи ясними на кожному рівні деталізації. Для цього треба користуватися наступними рекомендаціями:

¨ на кожному рівні від 15.6 процесів і не більше;

¨ не захаращувати діаграму неважливими елементами на заданому рівні деталізації;

¨ декомпозицію процесів і потоків вести паралельно;

¨ вибирати зрозумілі імена для всіх об'єктів DFD;

¨ одноразово визначати функціонально ідентичні процеси (у інших місцях просто посилатися на цей процес - де наслідування відбувається не автоматично).

¨ використовувати DFD для технічних процесів, які можна за допомогою її описати.

Побудову DFD можна звести до наступних кроків:

¨ декомпозиція вимог на основні функції груп;

¨ ідентифікація зовнішніх об'єктів (по відношенню до системи);

¨ ідентифікація інформації, яка перетікає між процесами;

¨ розроблення контекстної діаграми;

¨ контроль контекстної діаграми і уточнення, якщо це потрібно;

¨ формування DFDпершого рівня, де відображені основні функції системи;

¨ подальша декомпозиція кожного процесу до тих пір, поки процес найнижчого рівня можна буде представити у вигляді деякої специфікації (алгоритму);

¨ провести ревізію всіх рівнів з метою з'ясування некоректності, якщо некоректності виявлені - усунути.

Графічне подання елементів DFD у різних нотаціях подано у таблиці 7.1.

Таблиця 7.1. Графічне відображення елементів DFD

	Йордона	Гейна-Сарсона	SADT	SAG
Процес
Потік даних
Сховище даних			---
Джерело /приймач інформації			текстова мітка
Сутність	---	---	---
Читання /запис	---	---	---
Групування (зчеплення) потоків				(треба робити додатковий процес)
Розгрупування				немає
Невикористаний вузол (на схемі є, але в системі не описаний)		---
Вузли-предки (наслідування вузлів)			I, O, M, C	Автомати - наслідуван-ня не відбу-вається

Таким чином, інформаційна модель системи в нотації DFD будується у вигляді діаграм потоків даних, які графічно представляються з використанням відповідної системи позначень. Як приклад розглянемо спрощену модель процесу отримання деякої суми готівкою з кредитної картки клієнтом банку. Зовнішньою сутністю цього прикладу є клієнт банку і, можливо, службовець банку, який контролює процес обслуговування клієнтів. Сховищем даних може бути база даних про стан рахунків окремих клієнтів банку. Окремі потоки даних відображають характер передаваної інформації, необхідної для обслуговування клієнта банку. Відповідна модель для даного прикладу може бути представлена у вигляді діаграми потоків даних (рис. 7.5).

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

Рис. 7.5. Приклад діаграми DFD для процесу отримання деякої суми готівкою з кредитної картки

Висновки

1. Діаграма потоків даних – це діаграми на яких відображаються потоки даних, процеси перетворення вхідних потоків на вихідні, сховища інформації, джерела і споживачі інформації, зовнішні щодо системи..

2. Основними елементами діаграм даних є сутності, процеси, сховища даних, потоки даних.

3. Нотації DFD: Йордона, Гейна-Сарсона, SADT, SAG.

Контрольні приклади

1. Призначення діаграм потоків даних.

2. Основні елементи діаграм потоків даних.

3. Особливості побудови діаграм потоків даних.

4. Нотації діаграм потоків даних.

РОЗДІЛ 8. Діаграми "сутність-зв'язок", атрибутів, категоризації

à Призначення діаграм «сутність-зв’язок»

à Деталізація сутностей

à Методологія IDEF1

У розділі описано методологію побудови діаграм «сутність-зв’язок», а також діаграм деталізації сутностей.

8.1. Діаграма «сутність-зв’язок»

Діаграми «сутність-зв'язок» – entity-relation diagram (ERD) призначені для розроблення моделей даних і забезпечують стандартний спосіб визначення даних і відношень між ними. Фактично за допомогою ERD здійснюється деталізація сховищ даних проектованої системи, а також документуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об'єктів, важливих для предметної області, властивостей цих об'єктів (атрибутів) і їх відношень з іншими об'єктами (зв'язків).

Ця нотація була введена Ченом (Chen) і одержала подальший розвиток у роботах Баркера (Barker).

Нотація Чена надає багатий набір засобів моделювання даних, включаючи власне ERD, а також діаграми атрибутів і діаграми декомпозиції. Ця діаграмна техніка використовується, перш за все, для проектування табличних моделей даних (хоча також може з успіхом застосовуватися і для моделювання як ієрархічних, так і мережевих моделей даних) [133].

Сутність – множина екземплярів реальних або абстрактних об'єктів (людей, подій, станів, ідей, предметів тощо), що мають загальні атрибути або характеристики. Будь-який об'єкт системи може бути поданий тільки однією сутністю, яка повинна бути унікально ідентифікована. При цьому назва сутності повинне відображати тип або клас об'єкту, а не його конкретний екземпляр (наприклад, Аеропорт, а не Львівський).

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

Відношення (зв’язок) в найзагальнішому вигляді є зв'язком між двома і більше сутностями. Іменування відношення здійснюється за допомогою граматичного обороту дієслова (МАЄ, ВИЗНАЧАЄ, МОЖЕ МАТИ тощо). Прикладами зв'язків можуть бути споріднені відношення типу "батько-син" або виробничі відношення типу "начальник-підлеглий". Інший тип зв'язків задається відношеннями "мати у власності" або "володіти властивістю".

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

¨ забезпечення зберігання інформації в єдиному місці (навіть якщо вона використовується в різних комбінаціях);

¨ використання цієї інформації різними застосуваннями.

Символи ERD, які подають сутності і зв’язки, наведені на рис. 8.1.

Рис. 8.1. Символи ERD в нотації Чена.

Незалежна сутність подає незалежні дані, які завжди присутні в системі. При цьому зв’язки з іншою сутністю можуть як існувати, так і бути відсутніми. У свою чергу, залежна сутність подає дані, залежні від іншої сутності в системі. Тому вона повинна завжди мати зв’язки з іншою сутністю. Асоціативна сутність подає дані, які асоціюються зв’язками між двома і більше сутностями.

Необмежений зв’язок – це безумовне відношення, тобто відношення, яке завжди існує доти, поки існують екземпляри сутностей, що входять у зв’язок. Обмежений зв’язок – це умовне відношення між сутностями. Суттєво-обмежений зв’язок використовується тоді, коли відповідна сутність взаємно-залежна в системі.

Для ідентифікації вимог, відповідно до яких сутність залучається до зв’язку, використовуються типи зв’язків. Практика показала, що достатньо використовувати наступні типи зв’язків:

а) 1:1 (один-до-одного): зв’язок цього типу використовується, як правило, на верхніх рівнях ієрархії моделі даних, а на нижніх рівнях зустрічаються порівняно рідко;

б) 1:N (один-до-багатьох): зв’язок цього типу найчастіше використовується;

в) N:M (багато-до-багатьох): зв’язок цього типу зазвичай використовуються на ранніх етапах проектування з метою прояснення ситуації.

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

Наведемо приклад ERD для предметної області «Обслуговування банкоматів» (рис. 8.2).

Рис. 8.2. ERD обслуговування банкомату.

Кожна сутність містить один або декілька атрибутів, які однозначно ідентифікують кожен екземпляр сутності. При цьому будь-який атрибут може бути визначений як ключовий.

8.2. Діаграма атрибутів

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

Діаграма атрибутів обслуговування банкомату подана на рис. 8.3.

Сутність може бути розділена і подана у вигляді двох або більше сутностей-категорій, кожна з яких має загальні атрибути і/або зв’язки, які визначаються один раз на верхньому рівні й успадковуються на нижньому.

Сутність-категорія може мати і свої власні атрибути і/або зв’язки, а також, у свою чергу, може бути декомпозована своєю сутністю-категорією на наступному рівні.

Рис. 8.3. Діаграма атрибутів обслуговування банкомату.

Розщеплювана на категорії сутність одержала назву загальної сутності (відзначимо, що на проміжних рівнях декомпозиції одна і та ж сутність може бути як загальною сутністю, так і сутністю-категорією).

8.3. Діаграма категоризації

Для демонстрації декомпозиції сутності на категорії використовуються діаграми категоризації. Така діаграма містить загальну сутність, дві і більше сутностей-категорій і спеціальний вузол-дискримінатор, який описує способи декомпозиції сутності (див. рис. 8.4).

Рис. 8.4. Діаграма категоризації.

Існують 4 можливих типи дискримінатора (рис.8.5):

1. Повне і обов'язкове входження E/M (exclusive/mandatory) – сутність повинна бути однією і лише однією із вказаних категорій. Для прикладу на рис. 2.4 це означає, що адміністративною одиницею є країна, або область, або місто, або адміністративний центр.

2. Повне і необов'язкове входження E/O (exclusive/optional) – сутність може бути однією і лише однією з належних категорій. Це означає, що адміністративною одиницею є країна, або область, або місто (або районний центр).

Рис. 8.5. Типи дискримінаторів.

3. Неповне і обов'язкове входження I/M (inclusive/mandatory) – сутність повинна бути принаймні однією з вказаних категорій. Це припускає на додаток до першого типу задавати наступну ситуацію: адміністративна одиниця є одночасно і містом і адміністративним центром.

4. Неповне і необов'язкове входження I/O (inclusive/optional) – сутність може бути принаймні однією з вказаних категорій. На додаток до другого типу адміністративна одиниця є ще, крім того, що вона містом, і районним центром.

8.4. Обмеження діаграм сутність-зв’язок

Розглянемо як простий приклад ситуацію, яка описується двома сутностями: "Співробітник" і "Компанія". Як зв'язок природно використовувати відношення приналежності співробітника до компанії. Якщо врахувати міркування про те, що в компанії працюють декілька співробітників, і ці співробітники не можуть бути працівниками інших компаній, то дана інформація може бути представлена графічно у вигляді такої діаграми "сутність-зв'язок" (рис. 8.5). На цьому рисунку буква "N" біля зв'язку означає той факт, що в компанії можуть працювати більше за одного співробітника, при цьому значення N заздалегідь не фіксується. Цифра "1" на іншому кінці зв'язку означає, що співробітник може працювати тільки в одній конкретній компанії, тобто не допускається прийом на роботу співробітників за сумісництвом з інших компаній або установ.

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