10.5.1. Суть методологій 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 ):

Моделювання оточуючого середовища. Функціональне моделювання (моделювання поведінки системи). Моделювання реалізації

SA SD

Рис. 10.15. Основні етапи методології SA/SD

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

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

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

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

Функціональне моделювання передбачає використання:

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

• Словників даних;

• Простих спеціфікацій процесів;

• ERD –діаграм (див. розділ 5.п.2).

Взаємозв’язок між цими інструментами подано на рис.10.16.

Моделювання реалізацій використовує:

• Структурні моделі – міжмодульна взаємодія;

• Узгодження всередині модулів.

Розглянемо коротко ці засоби.

10.5.2. Діаграми потоків даних- 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. Після побудови двох-трьох рівнів проведення ревізії з метою перевірки коректності і поліпшення зрозумілості моделі.

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