Лекція 05

Функціонально-орієнтоване проектування

та проектування на основі структур даних

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

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

Структурне програмування - методологія розробки програмного забезпечення, в основі якої лежить подання програми у вигляді ієрархічної структури блоків. Запропонована в 70-х роках XX століття Э. Дейкстрой, розроблена та доповнена Н. Віртом.

Будь-яка програма являє собою структуру, побудовану із трьох типів базових конструкцій:

послідовне виконання

однократне виконання операцій у тому порядку, у якому вони записані в тексті програми

розгалуження

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

цикл

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

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

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

Розробка програми ведеться по-кроково, методом "зверху вниз".

Функціональна схема

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

Таблиця "Стандартні позначення для функціональних схем"

Функціональні схеми, більш інформативні, ніж структурні. На рисунку «Приклад функціональної схеми програмного комплексу» наведено функціональну схему програмного комплексу, що реалізовує різні методи сортування масивів.

Рисунок. Приклад функціональної схеми програмного комплексу

Структурна схема розроблювального ПЗ

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

Структурна схема визначається архітектурою розроблювального ПЗ.

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

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

Компоненти структурної схеми

Компонентами структурної схеми програмної системи або програмного комплексу можуть служити:

програми,

підсистеми,

бази даних,

бібліотеки ресурсів і т.п.

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

Рисунок «Приклад структурної схеми програмного комплексу»

Приклади струкурних схем

Структурні карти Джексона

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

Техніка структурних карт Джексона заснована методі структурного програмування Джексона, що виявляє відповідність між структурою потоків даних і структурою програми. Основну увагу в методі сконцентровано на відповідності вхідних і вихідних потоків даних. Структури на діаграмах Джексона будуються із чотирьох основних компонентів, представлених на рисунку «Елементи структурних діаграм Джексона»:

операція - блок кодів, що має один вхід й один вихід (а);

проходження - послідовне виконання операцій ліворуч праворуч (б);

вибір - виконання однієї з операцій залежно від виконання усло-вия (в);

ітерація - багаторазове виконання блоку (г)

Рисунок Елементи структурних діаграм Джексона

Приклад:

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

Характеристики гарної моделі реалізації

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

Один з фундаментальних принципів структурного проектування полягає в тому, що більша система повинна бути розчленована на доступні для огляду модулі. При цьому істотним є те, що це розчленовування повинне бути виконано таким чином, щоб модулі були як можна більш незалежні (критерій зчеплення - couplіng), і щоб кожен модуль виконував єдину (пов’язану із загальним завданням) функцію (критерій зв’язності - cohesіon).

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

Рисунок Приклад "гарної" структурної карти Джексона

Зчеплення (couplіng)

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

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

- зменшення кількості з'єднань між двома модулями призводить до зменшення ймовірності появи "хвильового ефекту" (помилка в одному модулі впливає на роботу інших модулів);

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

- при супроводі модуля відсутність необхідності турбуватися про внутрішні деталі інших модулів;

- спрощення системи для розуміння, наскільки це можливо.

Слабке зчеплення може бути досягнуте за рахунок комбінування трьох наступних способів дій:

- видалення необов'язкових зв'язків;

- зменшення кількості необхідних зв'язків;

- спрощенням необхідних зв'язків

Практичні рекомендації для ослаблення зчеплення модулів:

1. Створюйте мінімальні по кількості параметрів міжмодульні зв’язки.

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

3. Створюйте локалізовані зв'язки (наприклад, значення списку параметрів обчислюйте безпосередньо перед викликом модуля).

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

5. Створюйте гнучкі зв'язки для полегшення модифікацій.

Зчеплення є лише одним із критеріїв оцінки якості розбивки системи на частині: воно оцінює, наскільки добре модулі відділені один від іншого.

Зв’язність (cohesіon)

Іншим критерієм оцінки якості розчленовування системи є критерій зв’язності, що контролює, як дії в одному модулі зв'язані один з одним.

Фактично зчеплення й зв’язність є двома взаємозалежними способами виміру розчленовування системи на частини: зв’язність модуля часто визначає якість його зчеплення з іншими модулями.

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

Розміщення сильно зв'язаних об'єктів у тому самому модулі зменшує міжмодульні взаємозв'язки й взаємовпливи.

Рівні зв’язності:

функціональна зв’язність,

Функціонально зв'язний модуль містить об'єкти, призначені для виконання одного і лише завдання, наприклад:

Розрахунок заробленої плати,

Зчитування даних кредитної карти.

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

послідовна зв’язність,

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

Відкрити файл - Прочитати запис - Закрити файл.

інформаційна зв’язність,

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

назву книги, її автора й ціну.

Ці три підзадачі є зв'язаними тому, що всі вони працюють із тим самим вхідним інформаційним об'єктом - ІSBN, що і робить цей модуль информационно зв'язним.

процедурна зв’язність,

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

Як приклад приведемо наступний перелік кроків у деякому процедурно зв'язному модулі:

1. Зробити зарядку

2. Прийняти душ

3. Зварити каву

4. Одягтися

5. Відправитися на службу

Відправитися на службу - це останній крок, внесений у список цього «модуля». Але, наприклад, дії Прочитати газету або Сходити в магазин можуть бути рівною мірою придатними кандидатами для кроку 5, оскільки кроки в цьому списку зв'язані тільки тим, що вони відбуваються в даному порядку протягом конкретного дня.

тимчасова зв’язність,

Тимчасово зв'язним є модуль, об'єкти якого включені в підзадачі, зв'язані часом виконання. Уявімо собі картину пізнього вечора:

1. Почистити зуби

2. Вимкнути телевізор

3. Вигнати кота в коридор

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

логічна зв’язність,

Модулем з логічною зв’язністю є модуль, об'єкти якого сприяють вирішенню однієї загальної підзадачі, для якої ці об'єкти відібрані в зовнішньому стосовно модуля світі.

Наприклад, збираючись у поїздку, можна скласти собі наступний список:

1. Поїхати автомобілем

2. Поїхати поїздом

3. Поплисти на кораблі

4. Полетіти на літаку

Що зв'язує ці дії? Всі вони є способами переміщення. Але вирішальний момент полягає в тому, що для будь-якої поїздки людина повинна вибрати конкретний спосіб переміщення, тому що малоймовірно, що хто-небудь буде використовувати їх усі для окремої поїздки.

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

випадкова зв’язність.

Випадково зв'язковим є модуль, об'єкти якого відповідають під-завданням, незначно зв'язаним один з одним:

1. Ремонтувати автомобіль

2. Пити пиво

3. Дивитися фільм

Випадково зв'язний модуль подібний логічно зв'язному модулю, його объекти не зв'язані ні потоками даних, ні потоками керування. Однак, підзадачі в логічно зв'язному модулі є принаймні однієї категорії; для випадково-зв'язного модуля навіть це невірно.

Функціонально-орієнтована методологія

Функціональна методика потоків даних

Діаграма потоків даних

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

Рисунок «A sample data flow diagram»

Рисунок «Data Flow diagram: Level 1 Diagram»

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

Історично склалося так, що для опису діаграм DFD використаються дві нотації - Йодана (Yourdon) і Гейна-Сарсона (Gane-Sarson), що відрізняються синтаксисом.

На наведеній нижче ілюстрації використана нотація Гейна-Сарсона:

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

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

Крім того, нотація DFD підтримує поняття підсистеми - структурної компоненти розроблювальної системи.

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

Мета методики потоків даних

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

При створенні діаграми потоків даних використаються чотири основних поняття:

- потоки даних,

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

- процеси (роботи) перетворення вхідних потоків даних у вихідні,

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

- зовнішні сутності,

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

- накопичувачі даних (сховища).

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

Процес побудови DFD

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

Рисунок «Діаграма типу «зірка» »

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

Критерії складності методики потоків даних

- наявність великої кількості зовнішніх сутностей,

- багато-функціональність системи,

- її розподілений характер.

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

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

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

1. процес має два-три вхідних і вихідних потоку;

2. процес може бути описаний у вигляді перетворення вхідних даних у вихідні;

3. процес може бути описаний у вигляді послідовного алгоритму.

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

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

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

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

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

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

Повнота діаграми забезпечується, якщо в системі немає «висячих» процесів, не використовуваних у процесі перетворення вхідних потоків у вихідні.

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

на діаграмі не може бути потоку, що зв'язує дві зовнішні сутності - ця взаємодія видаляється з розгляду;

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

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

Переваги та недоліки

До переваг методики DFD відносяться:

- можливість однозначно визначити зовнішні сутності, аналізуючи потоки інформації усередині та поза системою;

- можливість проектування зверху вниз, що полегшує побудову моделі "як повинно бути";

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

До недоліків методики DFD віднесемо:

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

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

30