Структурний підхід до проектування ІС Сутність структурного підходу

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

Усі найбільш поширені методології структурного підходу [9,11,12,13] базуються на ряді загальних принципів [3]. В якості двох базових принципів використовуються наступні:  принцип "розділяй і володарюй" - принцип вирішення складних      проблем шляхом їх розбиття на безліч менших незалежних завдань, легень      для розуміння і рішення;  принцип ієрархічного упорядкування - принцип організації      складових частин проблеми в ієрархічні деревоподібні структури з      додаванням нових деталей на кожному рівні.

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

У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, що виконуються системою і відносини між даними. Кожній групі коштів відповідають певні види моделей (діаграм), найбільш поширеними серед яких є наступні:  SADT (Structured Analysis and Design Technique) моделі і      відповідні функціональні діаграми (підрозділ 2.2);  DFD (Data Flow Diagrams) діаграми потоків даних (підрозділ 2.3);        ERD (Entity-Relationship Diagrams) діаграми      "сутність-зв'язок" (підрозділ 2.4).

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

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

Методологія SADT розроблена Дугласом Россом і отримала подальший розвиток в роботі [4]. На її основі розроблена, зокрема, відома методологія IDEF0 (Icam DEFinition), яка є основною частиною програми ICAM (Інтеграція комп'ютерних та промислових технологій), що проводиться з ініціативи ВПС США.

Методологія SADT являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі об'єкта будь-якої предметної області. Функціональна модель SADT відображає функціональну структуру об'єкта, тобто вироблені їм дії й зв'язки між цими діями. Основні елементи цієї методології грунтуються на наступних концепціях:  графічне подання блокового моделювання. Графіка блоків і      дуг SADT-діаграми відображає функцію у вигляді блоку, а інтерфейси      входу/виходу представляються дугами, відповідно входять до блоку і      що виходять з нього. Взаємодія блоків один з одним описуються      за допомогою інтерфейсних дуг, що виражають "обмеження", які      в свою чергу визначають, коли і яким чином функції виконуються і      управляються;  строгість і точність. Виконання правил SADT вимагає достатньої      строгості й точності, не накладаючи в той же час надмірних обмежень      на дії аналітика. Правила SADT включають:  обмеження кількості блоків на кожному рівні декомпозиції      (правило 3-6 блоків);  зв'язність діаграм (номера блоків);  унікальність міток і найменувань (відсутність повторюваних імен);        синтаксичні правила для графіки (блоків і дуг);  поділ входів і управлінь (правило визначення ролі даних).  відділення організації від функції, тобто виключення впливу      організаційної структури на функціональну модель.

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

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

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

Рис. 2.1. Функціональний блок та інтерфейсні дуги

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

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

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

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

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

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

Рис. 2.2. Структура SADT-моделі. Декомпозиція діаграм

На малюнках 2.3 - 2.5 представлені різні варіанти виконання функцій і з'єднання дуг із блоками.

Рис. 2.3. Одночасне виконання

Рис. 2.4. Відповідність має бути повним і несуперечливим

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

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

Рис. 2.5. Приклад зворотного зв'язку

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

Рис. 2.6. Приклад механізму

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

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

Рис. 2.7. Ієрархія діаграм Типи зв'язків між функціями

Одним з важливих моментів при проектуванні ІС за допомогою методології SADT є точна узгодженість типів зв'язків між функціями. Розрізняють за Принаймні сім типів зв'язування:         Тип зв'язку          Відносна значимість             Випадкова         0             Логічна         1             Тимчасова         2             Процедурна         3             Комунікаційна         4             Послідовна         5             Функціональна         6     

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

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

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

Рис. 2.8. Випадкова зв'язність

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

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

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

Рис. 2.9. Процедурна зв'язність

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

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

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

Рис. 2.10. Комунікаційна зв'язність

Рис. 2.11. Послідовна зв'язність

У математичних термінах необхідна умова для простого типу функціональної зв'язності, наведеної на малюнку 2.12, має такий вигляд: C = g (B) = g (f (A))

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

Рис. 2.12. Функціональна зв'язність         Значимість          Тип зв'язності          Для функцій          Для даних              0         Випадкова         Випадкова         Випадкова              1         Логічна         Опції одного і того ж безлічі або типу (наприклад, "редагувати всі входи")         Дані одного і того ж безлічі або типу              2         Тимчасова         Опції одного і того ж періоду часу (наприклад,
"операції ініціалізації")         Дані, що використовуються в будь-якому часовому інтервалі              3         Процедурна         Функції, які працюють в одній і тій же фазі або ітерації (наприклад, "перший прохід компілятора")         Дані, які використовуються під час однієї і тієї ж фази або ітерації              4         Коммунікаціоннная         Функції, що використовують одні й ті ж дані         Дані, на які впливає одна й та сама діяльність              5         Послідовна         Функції, що виконують послідовні перетворення одних і тих самих даних         Дані, що перетворюються послідовними функціями              6         Функціональна         Функції, що об'єднуються для виконання однієї функції         Дані, пов'язані з однією функцією      Література  Вендров А.М. Один з підходів до вибору засобів проектування баз      даних і додатків. "СУБД", 1995, № 3.  Зіндера Е.З. Бізнес-реінжиніринг і технології системного      проектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996        Калянов Г.М. CASE. Структурний системний аналіз (автоматизація та      застосування). М., "Лорі", 1996.  Марка Д.А., МакГоуен К. Методологія структурного аналізу і      проектування. М., "МетаТехнологія", 1993.  Міжнародні стандарти, що підтримують життєвий цикл програмних      коштів. М., МП "Економіка", 1996  Створення інформаційної системи підприємства. "Computer      Direct ", 1996, N2  Шлеер С., Меллор С. Об'єктно-орієнтований аналіз: моделювання      ми?? а в станах. Київ, "Діалектика", 1993.  Barker R. CASE * Method. Entity-Relationship Modelling. Copyright      Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.  Barker R. CASE * Method. Function and Process Modelling. Copyright      Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.  Boehm B.W. A Spiral Model of Software Development and Enhancement.      ACM SIGSOFT Software Engineering Notes, Aug. 1986  Chris Gane, Trish Sarson. Structured System Analysis.      Prentice-Hall, 1979.  Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.  Tom DeMarco. Structured Analysis and System Specification. Yourdon      Press, New York, 1978.  Westmount I-CASE User Manual. Westmount Technology B.V.,      Netherlands, 1994.  Uniface V6.1 Designers 'Guide. Uniface B.V., Netherlands, 1994.