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

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

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

принципів. В якості двох базових принципів використовуються наступні:
принцип "розділяй

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

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

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

ілюструють функції, виконувані системою і відносини між даними. Кожній групі

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

що відбивають структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм

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

правил і процедур, призначених для побудови функціональної моделі об'єкта будь-якої

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

складається з діаграм, фрагментів текстів та глосарію, що мають посилання

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

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

модель.











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

взаємозв'язки, показана структура SADT-моделі. Кожен компонент моделі може бути декомпозирований

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

і з'єднання дуг з блоками.

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

зв'язки, ітерації, що тривають процеси і перекриваються (за часом) функції

можуть бути зображені з допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і т.д. (Рисунок 5).

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

ІС за допомогою методології SADT є точна узгодженість типів зв'язків

між функціями. Розрізняють принаймні сім типів зв'язування:

конкретна зв'язок між функціями мала або повністю відсутня. Це відноситься

до ситуації, коли імена даних на SADT-дугах в одній діаграмі мають малу зв'язок один з одним. Крайній варіант цього випадку показаний на рисунку 8.

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

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

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

того, що вони виконуються протягом однієї і тієї ж частини

циклу або процесу. Приклад процедурно-зв'язаної діаграми наведено на рисунку 7.

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

групуються внаслідок того, що вони використовують одні і ті ж

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

показаної на рисунку 10, має наступний вигляд:
C =

g (B) = g (f (A))

Рис. 10. Функціональна зв'язність

Обидва стандарти моделювання були розроблені разом і органічно доповнюють один

одного, зазвичай використовуються в зв'язці. Обидва стандарти входять в методологію SADT (Structured Analysis and Design Technique).

Стандарт IDEF3, на відміну від стандарту IDEF0, дозволяє описувати логіку виконання дії. Простіше кажучи, якщо IDEF0 покликаний дати відповідь на питання ЩО робиться в організації, то IDEF3 відповідає на питання про те, ЯК це робиться.

моделювання:
функціональне моделювання (IDEF0);
опис бізнес-процесів (IDEF3);
діаграми потоків даних (DFD).

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

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

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

повинен бути змодельованим, що повинна показувати модель, що отримає клієнт.
Під

точкою зору розуміється перспектива, з якою спостерігалась система при побудові моделі.
IDEF0 – модель представляє наявність чітко сформованої цілі, єдиного суб’єкта моделювання і однієї точки зору. Для занесення області, цілі та точки зору в модель IDEF0 в BРwin слід вибрати пункт меню Model/Model Properties викликаючий діалог Model Properties (рис. 11). В закладці Purpose слід внести ціль і точку зору, а в закладку Definition – визначення моделі та опис області.

(робочий варіант, чорновий, завершений та ін.), час створення і останнього

редагування (відслідковується на далі автоматично по системній даті). В закладці Source описуються джерела інформації для побудови моделі (наприклад, «Опитування експертів предметної області та аналіз документації»). Закладка General служить для внесення імені проекту і моделі, імені і ініціалів автора та тимчасових рамок моделі – AS-IS i TO-BE (рис. 12).

автора і тимчасових рамок моделі

AS-IS (як є), її аналіз та покращення бізнес-процесів, тобто створення

моделі TO-BE (як буде), і тільки на основі моделі TO-BE будується модель даних, прототип, а потім кінцевий варіант ІС.
Результат опису моделі можна отримати у звіті Model Report. Діалог налаштування звітів викликається із пункта меню Tools/Reports/Model Repot.
В діалозі налаштування слід вибрати необхідні поля, при цьому автоматично відображається черговість виведення інформації в звіт (рис. 13, рис.14).

Модель в нотації IDEF0 представляє собою сукупність ієрархічно упорядкованих і

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

загальний опис системи і її взаємодію з зовнішнім середовищем.
Після

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

між ними. Діаграм дерев вузлів може бути в моделі скільки

завгодно, оскільки дерево може бути побудоване на вільну глибину і не обов’язково з кореня.
Діаграми для експозиції (FEO) будуються для ілюстрації окремих фрагментів моделі, для ілюстрації альтернативної точки зору або для спеціальних цілей.
Роботи (Activity) визначають процеси, функції або задачі, які виконуються на протязі певного часу та мають розпізнавальні результати. Роботи відображаються у вигляді прямокутників. Всі роботи повинні бути названі і визначені. Ім’я роботи повинно відображати дію («Діяльність компанії», «Прийом замовлення», «Створення інформаційної системи» та ін.).

з єдиною роботою, яка відображає систему в цілому (рис.15).

Рис.

15 Приклад контекстної діаграми

загальну «родственную работу». Далі створюємо діаграму декомпозиції (рис. 16)

Рис. 16

Приклад діаграми декомпозиції

в моделі і дозволяють розглядати всю модель цілком, але не

показує взаємозв’язки між роботами.

Рис. 17 Діаграма дерева вузлів.

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

явно синтаксисом IDEF0. Діаграми FEO дозволяють порушити любе синтаксичне правило, оскільки являється по суті просто картинками – копіями стандартних діаграм і не включаються в аналіз синтаксису. Для створення діаграми FEO слід вибрати пункт меню Diagram/Add FEO Diagram. У виникаючому діалозі слід вказати ім’я діаграми FEO.

по моделі виклакаються із пункта меню Report. Всього є сім

типів звітів:
Model Report. Включає інформацію про контекст системи – ім’я моделі, точку зору, область, ціль, ім’я автора, дату створення та ін.
Diagram Report. Звіт по конкретній діаграмі. Включає список об’єктів (робіт, стрілок, схованок даних, зовнішні посилання та ін.).
Diagram Object Report. Найбільш повний звіт по моделі. Може включати повний список об’єктів моделі (робіт, стрілок з вказуванням їх типів та ін.) та властивості визначені користувачем.
Activity Cost Report. Звіт про результати вартісного аналізу.
Arrow Report. Звіт по стрілкам. Може мати інформацію із словника стрілок, інформація про роботу – джерело, роботі- призначенні стрілки і інформацію про розгалуження та злиття стрілок.
Data Usage Report. Звіт про результати зв’язку моделі процесів і моделі даних.
Model Consistency Report. Звіт, який має список синтаксичних похибок моделі.