Діаграми потоків даних- DFD
Принципи побудови моделі ІDEF0
На сьогоднішній день ІDEF0 широко використовується для розв’язання двох типів задач:
1. Реінжиніринг бізнес-процесів організації.
2. Проектування інформаційних систем.
Ці задачі можуть бути взаємопов’язані, оскільки проектування інформаційної системи досить часто призводить до реорганізації бізнес-процесів організації. Однак, коли мова йде просто про реінжиніринг, схеми бізнес-процесів організації зазвичай будуються менджерами без деталізації моделей даних.
Тому слід відмітити, що при проектуванні інформаційних систем в ІDEF0 інформаційна система представляється:
- з одного боку як сукупність взаємодіючих функцій - така чисто функціональна орієнтація є принциповою - функції системи аналізуються незалежно від об'єктів, якими вони оперують;
- з другого боку будується модель даних, якими оперують функції.
Це дозволяє більш чітко змоделювати логіку і взаємодію процесів інформаційної системи.
Процес моделювання інформаційної системи в ІDEF0 починається з визначення контексту, тобто найбільш абстрактного рівня опису системи в цілому. У контекст входить визначення суб'єкта моделювання (Scope), мети (Purpose) і точки зору на модель (Vіewpoіnt). Також вказуються часові рамки моделі - AS-ІS чи ТО-ВE.Технологія проектування ІС передбачає спочатку створення моделі AS-ІS, її аналіз і поліпшення бізнесів-процесів, після чого створюється модель ТО-ВЕ, і тільки на основі моделі ТО-ВЕ будується модель даних, прототип і потім остаточний варіант ІС.
Побудова системи на основі моделі AS-ІS приводить до автоматизації підприємства за принципом "усе залишити як є, тільки щоб комп'ютери стояли", тобто ІС автоматизує недосконалі бізнеси-процеси і дублює, а не заміняє існуючий документообіг. У результаті впровадження й експлуатація такої системи приводить лише до додаткових витрат на закупівлю устаткування, створення програмного забезпечення і супровід того й іншого.
Поширеною помилкою при створенні моделі AS-ІS є створення ідеалізованої моделі. Прикладом може служити створення моделі на основі знань керівника, а не конкретного виконавця робіт.
Діаграми ІDEF0
Модель у нотації ІDEF0 містить сукупність ієрархічно упорядкованих і взаємозалежних діаграм. Кожна діаграма є одиницею опису системи і розташовується на окремому листі.
Модель може мати чотири типи діаграм:
· контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);
· діаграми декомпозиції;
· діаграми дерева вузлів;
· діаграми тільки для експозиції (FEO).
Контекстна діаграма (рис.10.8 ) є вершиною деревоподібної структури діаграм і являє собою самий загальний опис системи і її взаємодії з зовнішнім середовищем.
Після опису системи в цілому проводиться розбивка її на великі фрагменти. Цей процес називається функціональною декомпозицією, а діаграми, що описують кожен фрагмент і взаємодія фрагментів, називаються діаграмами декомпозиції.
Після декомпозиції контекстної діаграми проводиться декомпозиція кожного великого фрагмента системи на більш дрібні і так далі, до досягнення потрібного рівня подробиці опису. Після кожного сеансу декомпозиції проводяться сеанси експертизи - експерти предметної області вказують на відповідність реальних бізнесів-процесів створеним діаграмам. Знайдені невідповідності виправляються, і тільки після проходження експертизи без зауважень можна приступати до наступного сеансу декомпозиції. Так досягається відповідність моделі реальним бізнес-процесам на будь-якому рівні моделі. Синтаксис опису системи в цілому і у кожнім її фрагменті однаковий у всій моделі.
Діаграма дерева вузлів показує ієрархічну залежність робіт, але не взаємозв'язки між роботами. Діаграм дерев вузлів може бути в моделі як завгодно багато, оскільки дерево може бути побудоване на довільну глибину і не обов'язково з кореня.
Діаграми для експозиції (FEO) будуються для ілюстрації альтернативної точки зору на окремі фрагменти моделі, або для спеціальних цілей.
Старі версії якоїсь діаграми можна зберігати у виді паперової копії або як FEO-діаграму.
У будь-якому випадку варто відрізняти різні версії однієї і тієї ж діаграми. Для цього існує спеціальний номер - С-numbеr, що повинний привласнюватися автором моделі вручну. C-number - це довільний рядок, але рекомендується дотримувати стандарту, коли номер складається з буквеного префікса і порядкового номера, причому як префікс використовуються ініціали автора діаграми, а порядковий номер відслідковується автором вручну, наприклад МСВ00021.
10.4.3. Роботи-функції (Actіvіty)
Роботи позначають поіменовані функції задачі, що відбуваються протягом визначеного часу і мають певні результати.
Роботи зображуються у виді прямокутників. Усі роботи повинні бути названі і визначені. Ім'я роботи повинне позначати дію (наприклад, "Виготовлення деталі", "Прийом замовлення" і т.д. ).
При створенні нової моделі автоматично створюється контекстна діаграма з єдиною роботою, що зображує систему в цілому (рис. 1).
Діаграми декомпозиції містять родинні роботи, тобто дочірні роботи, що мають загальну батьківську роботу.
Роботи на діаграмах декомпозиції звичайно розташовуються по діагоналі від лівого верхнього кута до правого нижнього. Такий порядок називається порядком домінування.
Відповідно до цього принципу розташування в лівому верхньому куті розташовується сама важлива робота чи робота, виконувана за часом першою. Далі вправо вниз розташовуються менш важливі чи виконувані пізніше роботи. Таке розташування полегшує читання діаграм, крім того, на ньому ґрунтується поняття взаємозв'язків робіт.
Кожна з робіт на діаграмі декомпозиції може бути у свою чергу декомпозована.
На діаграмі декомпозиції роботи нумеруються автоматично зліва направо. Номер роботи показується в правому нижньому куті.
Номер складається з префікса і числа. Ззвичай використовують префікс А. Контекстна діаграма завжди має номер А-0, декомпозиція контекстної діаграми - номер А0. Роботи декомпозиції А0 мають номера Al, A2, A3 і т.д. Роботи декомпозиції нижнього рівня мають номер батьківської роботи і черговий порядковий номер, наприклад роботи декомпозиції A3 будуть мати номера А31, А32, АЗЗ, А34 і т.д. Така нумерація називається нумерацією по кутах.
Роботи утворюють ієрархію, де кожна робота може мати одну батьківську і кілька дочірніх робіт.
10. 4.4. Стрілки (Arrow)
Взаємодія робіт із зовнішнім світом і між собою описується у виді стрілок. Стрілки означають деяку інформацію й іменуються іменниками, наприклад, "Заготівля", "Виріб", "Замовлення".
Імена нових стрілок автоматично заносяться в словник (Arrow Dіctіonary). Словник стрілок редагується за допомогою спеціального редактора Arrow Dіctіonary Edіtor, у якому визначається стрілка і вноситься стосовно до неї коментар.
Уміст словника стрілок можна роздрукувати у вигляді звіту і одержати тим самим тлумачний словник термінів предметної області, що використовуються в моделі.
В ІDEF0 розрізняють п'ять типів стрілок. Кожен тип стрілок підходить до визначеної сторони прямокутника, що зображує роботу, чи виходить з неї.
1.Вхід(іnput) - матеріал чи інформація, що використовується чи перетвориться роботою для одержання результату (виходу). Допускається, що робота може не мати ні однієї стрілки входу. Стрілка входу малюється як вхідна в ліву грань роботи.
При описі технологічних процесів (для цього і був придуманий ІDEF0) не виникає проблем визначення входів. Проте при моделюванні ІС, коли стрілками є не фізичні об'єкти, а дані, не все так очевидно. Деякі дані можуть бути і на вході і на виході, дуже часто складно визначати, чи є дані входом чи керуванням. У цьому випадку підказкою може служити те, переробляються (змінюються) дані в роботі чи ні. Якщо змінюються, то, швидше за все, це вхід, якщо ні - керування.
2. Керування (Control)- правила, стратегії, процедури чи стандарти, якими керується робота. "Кожна робота повинна мати хоча б одну стрілку керування. Стрілка керування малюється як вхідна у верхню грань роботи.
Керування впливає на роботу, але не перетвориться роботою.
3. Вихід (Output) - матеріал чи інформація, що виробляються роботою. Кожна робота повинна мати хоча б одну стрілку виходу. Робота без результату не має змісту і не повинна моделюватися. Стрілка виходу малюється як вихідна з правої грані роботи.
4. Механізм (Mechanіsm)- ресурси, що виконують роботу, наприклад персонал підприємства, верстати, пристрої і т.д. Стрілка механізму малюється як вхідна в нижню грань роботи.
По розсуду аналітика стрілки механізму можуть не зображуватися в моделі.
5. Виклик(Call) - спеціальна стрілка, що вказує на іншу модель роботи. Стрілка механізму малюється як вихідна з нижньої грані роботи. Стрілка виклику використовується для вказівки того, що деяка робота виконується за межами моделюємої системи. Стрілки виклику використовуються в механізмі злиття і поділу моделей.
Стрілки на контекстній діаграмі служать для опису взаємодії системи з навколишнім світом. Вони можуть починатися в границі діаграми і закінчуватися в роботи, чи навпаки. Такі стрілки називаються граничними.
При декомпозиції роботи вхідні в неї і вихідні з неї стрілки (крім стрілки виклику) автоматично з'являються на діаграмі декомпозиції (міграція стрілок), але при цьому не пов’язуються з роботами – це потрібно зробити вручну.
Для зв'язку робіт між собою використовуються внутрішні стрілки, тобто стрілки, що не торкаються границі діаграми, починаються з однієї і кінчаються в іншій роботі.
В ІDEF0 розрізняють п'ять типів зв'язків робіт.
Зв'язок по входу (output-іnput), коли стрілка виходу вищестоящої роботи (далі - просто вихід) направляється на вхід нижчестоящої.
Зв'язок по керуванню (output-control), коли вихід вищестоящої роботи направляється на керування нижчестоящої. Зв'язок по входу показує домінування вищестоящої роботи. Дані чи об'єкти виходу вищестоящої роботи не міняються в нижчестоящій.
Зворотний зв'язок по входу (output-іnput feedback), коли вихід нижчестоящої роботи направляється на вхід вищестоящої. Такий зв'язок, як правило, використовується для опису циклів.
Зворотний зв'язок по керуванню (output-control feedback), коли вихід нижчестоящої роботи направляється на керування вищестоящою. Зворотний зв'язок по керуванню часто свідчить про ефективність бізнес-процесу.
|
Зв'язок вихід-механізм (output-mechanіsm), коли вихід однієї роботи направляється на механізм іншої. Цей взаємозв'язок використовується рідше інших і показує, що одна робота підготовляє ресурси, необхідні для проведення іншої роботи
Стрілки також поділяються на явні та розгалуджені.
Явні стрілки мають джерелом одну-єдину роботу і призначенням теж одну-єдину роботу.
Стрілки що розгалужуються використовуються для відображення використання даних, породжених однією роботою, відразу в декількох інших роботах;
Стрілки, що зливаються використовуються для відображення використання даних, породжених в різних роботах, що переробляються в одному місці.
Якщо стрілка іменована до розгалуження, а після розгалуження жодна з гілок не іменована, то мається на увазі, що кожна галузь моделює ті ж об'єкти, що і галузь до розгалуження
Якщо стрілка іменована до розгалуження, а після розгалуження яка-небудь з галузей не іменована, то мається на увазі, що ці галузі відповідають іменуванню.
Неприпустима ситуація, коли стрілка до розгалуження не іменована, а після розгалуження не іменована яка-небудь з гілок.
Новостворені граничні стрілки на діаграмі декомпозиції нижнього рівня (не перенесені з діаграми верхнього рівня) зображуються в квадратних дужках і автоматично не з'являються на діаграмі верхнього рівня (рис. )
Для їх перенесення потрібно в діалозі Arrow Tunnel розширити границі (Resolve Border Arrow) стрілок. Якщо ж замкнути стрілку в тунель Change To Tunnel - стрілка буде зображуватися лише на одній діаграмі і позначатися круглими дужками на кінці.
Тунелювання може бути застосоване для зображення малозначимих стрілок, які не важливі для загального огляду моделі, а слугують лише для її деталізації. Або ж у випадку, коли якась стрілка використовується у всіх роботах на діаграмах декомпозиціїї – для того, щоб не захаращувати діаграми, стрілку замикають в тунель на батьківській діаграмі.
10.5. МЕТОДОЛОГІЇ структурного аналізу і проектування SA/SD
Суть методологій SA/SD
Як вже зазначалося, існує декілька методологій, що акцентують увагу на моделюванні потоків даних між процесами. Найбільш відомими є:
1. SA (Structured Analysis) – методологія структурного аналізу, запропонована Де Марко в 1978 р. [];
2. SD (Structured Design) – методологія структурного проектування запропонована Стівенсом, Майером, Константайном [];
3. SSA (Structured Systems Analysis) - структурного системного аналізу, запропонована Гейном-Сарсоном у 1979 [];
4. SA/SD – структурного системного аналізу і проектування Йордана, 1989 [].
До цієї ж групи можна віднести методології:
- SRD (Structured Requirements Definition), розроблена Ken Orr в середині 70-х;
- SSADM (Structured Systems Analysis and Design Method), створена на початку 80-х років і прийнята в 1993 році як національний стандарт Великобританії, та ін.
Досить часто в літературі вищеназвані методології об’єднуються під єдиною назвою SA/SD (або SA-SD чи SASD), за назвою методології, запропонованої Йорданом. Це пояснюється тим, що Йордан в своїй книзі "Modern Structured Analysis" (Сучасний структурний аналіз) узагальнив досвід структурного аналізу двох десятиліть.
Можна виділити три основних етапи моделювання ІС відповідно до методологій SA/SD (рис.10.15 ):
| 1. Моделювання оточуючого середовища. 2. Функціональне моделювання (моделювання поведінки системи). 3. Моделювання реалізації | 
SA
SD
|
Рис. 10.15. Основні етапи методології SA/SD
Перших два етапи відносяться до структурного аналізу, вони дають можливість побудувати логічну модель системи, незалежну від реалізації
Третій етап відноситься до структурного проектування і передбачає проектування системи із врахуванням її реалізації в плані програмного і технічного забезпечення.
На кожному з етапів передбачається використання певних засобів моделювання.
Так., моделювання оточуючого середовища передбачає побудову контекстної діаграми і визначення переліку подій.
Функціональне моделювання передбачає використання:
· Діаграм потоків даних – DFD (Data Flow Diagram).;
· Словників даних;
· Простих спеціфікацій процесів;
· ERD –діаграм (див. розділ 5.п.2).
Взаємозв’язок між цими інструментами подано на рис.10.16.
Моделювання реалізацій використовує:
· Структурні моделі – міжмодульна взаємодія;
· Узгодження всередині модулів.
Розглянемо коротко ці засоби.
Діаграми потоків даних- DFD
Практично, на сьогоднішній день розрізняють дві графічні нотації для DFD (які і підтримуються Case-засобами): Гейна-Сарсона та Йордана-Де Марко, оскільки Де Марко в процесі удосконалення свого методу почав використовувати запропоновані Йорданом графічні зображення.
Основні символи цих нотацій зображені на рис 10.17. До них належать:
| Назва | Нотація Йордона | Нотація Гейна-Сарсона | ||
| Flow – Потік даних | 
| 
| ||
| Process (bubble) - Процес |  
|  
| ||
| Store – Сховище |
|  
| ||
| Terminator – Зовнішній об’єкт |
| 
|
Рис. 10.17. Основні символи діаграм потоків даних
Потоки даних – під ними розуміють об’єкти (дані), що передаються з однієї частини системи в іншгу, позначаються стрілками. Стрілка вказує напрямок руху даних і може бути як одно-, так і двонаправленою.
Процеси – призначені для отримання вихідних потоків даних із вхідних, відповідно до дії, що задається ім’ям процесу (аналог робіт в IDEF0). Крім імені процес має також унікальний номер для посилань на нього усередині діаграми.
Сховище даних – дозволяє визначати дані, що будуть зберігатися в пам'яті між процесами. , Інформація, що воно містить, може використовуватися в будь-який час після її визначення, при цьому дані можуть вибиратися в будь-якому порядку.Ім'я сховища повинне ідентифікувати його вміст і бути іменником. У випадку, коли потік даних входить або виходить із сховища, і його структура відповідає структурі сховища, він повинний мати те ж саме ім'я.
Зовнішній об’єкт - сутність поза контекстом системи, що є джерелом або приймачем системних даних. Її ім'я повинне містити іменник. Передбачається, що об'єкти, представлені такими вузлами, не повинні брати участь в обробці даних. Тобто, це не системний аналітик чи адміністратор і зв’язки між зовнішніми об’єктами на DFD не показуються.
Аналогічно до IDEF0 в DFD створюється початково контекстна діаграма, що моделює систему найбільш загальним чином. Контекстна діаграма відбиває інтерфейс системи з зовнішнім світом, а саме, інформаційні потоки між системою і зовнішніми сутностями, з якими вона повинна бути зв'язана. Вона ідентифікує ці зовнішні сутності, а також, як правило, єдиний процес, що відбиває головну мету або природу системи.
Також здійснюється декомпозиція – спочатку процесу на контекстній діаграмі, а потім, на слідуючому рівні, й інших процесів. Процес декомпозиції продовжується доти, поки процеси можуть бути ефективно описані за допомогою коротких (до однієї сторінки) специфікацій – діаграм декомпозиції. Процеси нумеруються. Так, наприклад, якщо ми деталізуємо процес номер 2 на діаграмі першого рівня, розкриваючи його за допомогою DFD, що містить три процеси, то їхні номери будуть мати такий вигляд: 2.1, 2.2 і 2.3. Прості системи мабть 2-3 рівні декомпозиції, в складних їх зазвичай не більше восьми.
На рис.10.18. зображено взаємозв’язок діаграм потоків даних в нотації Йордана.
На рис.10.19. подано приклад діаграми декомпозиції в нотації DFD Гейна-Сарсона.
 |
Основними вимогами при побудові моделей DFD є:
· Розміщувати на кожній діаграмі від 3 до 6-7 процесів. Верхня границя відповідає людським можливостям одночасного сприйняття і розуміння структури складної системи, нижня границя обрана з позицій здорового глузду: немає необхідності деталізувати процес діаграмою, що містить всього один або два процеси.
· Не захаращувати діаграми несуттєвими на даному рівні деталями.
· Декомпозицію потоків даних здійснювати паралельно з декомпозицією процесів; ці дві роботи повинні виконуватися одночасно, а не одна після завершення іншої.
· Вибирати ясні імена процесів і потоків, для поліпшення розуміння діаграм, при цьому намагатися не використовувати абревіатури.
· Однократно визначати функціонально ідентичні процеси на самому верхньому рівні, де вони необхідні, і посилатися на них на нижніх рівнях.
· Користуватися найпростішими діаграмними техніками – не використовувати без необхідності складні об'єкти.
· Відокремлювати керуючі структури від процесів.
Відповідно до цих рекомендацій процес побудови моделі розбивається на наступні етапи:
1. Розподіл множини вимог і організація їх в основні функціональні групи.
2. Ідентифікація зовнішніх об'єктів, з якими система повинна бути зв'язана.
3. Ідентифікація основних видів інформації, що циркулює між системою і зовнішніми об'єктами.
4. Розробка контекстної діаграми, на якій основні функціональні групи представляються процесами, зовнішні об'єкти - зовнішніми сутностями, основні види інформації - потоками даних між процесами і зовнішніми сутностями.
5. Формування DFD першого рівня на базі процесів попередньої контекстної діаграми, перевірка основних вимог по DFD першого рівня.
6. Декомпозиція кожного процесу поточної DFD за допомогою деталізуючої діаграми, або специфікації процесу, перевірка основних вимог по DFD відповідного рівня.
7. Додавання визначень нових потоків у словник даних при кожній їхній появі на діаграмах.
8. Паралельне (із процесом декомпозиції) вивчення вимог (у тому числі і нових), розбивка їх на елементарні й ідентифікація процесів або специфікацій процесів, що відповідають цим вимогам. У випадку, якщо деяку функцію складно або неможливо виразити комбінацією процесів - побудова специфікації процесу.
9. Після побудови двох-трьох рівнів проведення ревізії з метою перевірки коректності і поліпшення зрозумілості моделі.
Таким чином можна розробити логічну функціональну специфікацію системи – детальний опис того, що повинна робити система, незалежно від середовища реалізації.
Словники даних
Словник даних являє собою певним чином організований список всіх елементів даних системи з їхніми точними визначеннями, що дає можливість різним категоріям користувачів (від системного аналітика до програміста) мати загальне розуміння усіх вхідних і вихідних потоків і компонент сховищ.
 |
Тобто, словник даних в системі, де підтримується моделювання потоків даних, має зберігати описи всіх потоків, процесів, сховищ і зовнішніх об’єктів за відповідною структурою.
На рис.10.20. подана структура словника даних в інструментальному засобі BPWin.
Для опису розщеплення/злиття потоків даних (тобто опису структури груп даних) може використовуватися так звана Бекуса-Наура форма (БНФ).
Розробка словників даних один із найбільш витратних за часом процесів системного аналізу, однак і один із найбільш важливих для розуміння значення елементів моделей різними користувачами.