С ТРУКТУРНЕ проектування інформаційних систем

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

Структурним підходом до проектуваня ІС називається нисхідний підхід, при якому:

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

• формується ієрархічна структура функцій системи з обмеженим числом елементів на одному рівні (3-7);

• функції системи ув’язуються з даними.

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

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

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

Окрім опису функцій системи при структурному проектуванні зазвичай створюється також модель даних ІС, при цьому використовуються діаграми „сутність-зв’язок” – ERD, описані в розділі 5 п.2. Деякі методології структурного проектування передбачають також опис поводження системи в часі, за допомогою спеціальних типів діаграм.

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

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

• принцип "розділяй і пануй" - рішення складних проблем шляхом їхньої розбивки на менші незалежні задачі, легкі для розуміння і рішення;

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

• принцип „краще один раз побачити” – широке використання графічних нотацій;

• дуальність даних до функцій - що дані повинні бути структуровані й ієрархічно організовані.

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

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

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

узгодження - обґрунтування і погодженння елементів (зі спеціалістом предметної області).

10.2. загальна характеристика та класифікація Методологій структурного аналізу і проектування

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

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

• SADT (Structured Analysіs and Desіgn Technіgue), та методології, розроблені на його основі, наприклад, IDEF0, які використовують функціональні діаграми;

• Група методологій структурного аналізу і проектування, в основі яких лежить використання діаграм потоків даних (DFD):

• SA (Structured Analysis) - структурного аналізу Де Марко (DeMarco, 1978);

• SD (Structured Design) – структурного проектування Стівенса, Майера, Константайна (Stevens, Myers, Constantine);

• SSA (Structured Systems Analysis) -  структурного системного аналізу Гейна-Сарсона (Gane-Sarson, 1979;

• SA/SD – структурного системного аналізу і проектування Йордана (Yourdon, 1989) );

• та ін.

• Методології структурного проектування систем реального часу, що включають контроль потоків робіт та діаграми станів:

• SDRTS (Structured Design of Real Time Systems) – структурного проектування систем реального часу Уорда-Меллора (Ward-Mellor, 1985), розширення SA/SD;

• SA/RT (Structured Analysis with Real-time-Extensions) - структурного аналізу з розширенням для систем реального часу Хартлі (Hatley/Pirbhai, 1987), аналог SDRTS, та ін.;

• IE (Information Engineering) - Інформаційного моделювання Мартіна (Martіn) та ін.

Різні методології в тій чи іншій мірі описують різні структурні аспекти ІС за допомогою різних типів діаграм. Так, в межах однієї методології можуть використовуватися і діаграми потоків даних (DFD) - для відображення функціонування системи, сумісно із словниками даних і специфікаціями процесів; і діаграми сутність-зв’язок (ERD) - для відображення даних; і навіть діаграми переходів станів (STD) – для відображення поведінки системи і часі.

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

Співвідношення застосування в існуючих CASE-засобах методів структурного аналізу, складає за матеріалами CASE Consulting Group 90% для DFD і 10% для SADT. За іншими даними[], це співвідношення виглядає як 94% до 3%, відповідно (ще 3% CASE-засобів використовують інші структурні методи).

Залежно від використовуваних методів та засобів, методології структурного аналізу і проектування дозволяють підтримувати певні стадії життєвого циклу ІС. Більшість структурних методологій підтримують початкові стадії життєвого циклу інформаційної системи. В термінах ГОСТ 34.601—90 це 1-5 стадії, в термінах спіральної моделі життєвого циклу це фази аналізу вимог і проектування специфікацій.

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

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

При проектуванні специфікацій, як правило, дотримується наступна послідовність кроків:

• поділ проекту на деяку кількість модулів (10-15) ;

• організація ієрархії модулів;

• визначення маршрутів даних між модулями;

• визначення форматів зовнішніх файлів;

• визначення способів доступу до зовнішніх файлів;

• визначення структур даних;

• проектування ключових алгоритмів;

• визначення підпрограм кожного модуля.

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

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

10.3. Функціональне моделювання SADT

SADT (Structured Analysіs Desіgn Technіque) була розроблена співробітниками Массачусетского технологічного інституту Д. Россом , Д. Маркою і К. Макгоуэном на початку 60-х рр. за завданням Міністерства оборони. Надалі розробники заснували свою власну компанію Softech, що у даний час займається розробкою складних систем автоматизації.

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

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

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

Результатом застосування методології SADT є модель, що складається з діаграм, фрагментів текстів і глосарія (словника даних), що мають посилання один на одне.

Основним компонентом діаграм є так званий „функціональний блок” (рис.10.1), за допомогою якого описується функція та її зв’язки.

З в’язки (інтерфейси) зображаються стрілками з відповідного боку блоку, мають певний напрямок, визначають обмеження щодо виконання функцій і можуть бути 5-ти типів:

Вхід – стрілка входить в блок з лікого боку, означає інформацію, що підлягає обробці в блоці.

Вихід – стрілка виходить з правого боку блоку і означає результатну інформацію.

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

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

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

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

При цьому:

• на кожнім рівні декомпозиції виділяють як правило 3-6 блоків;

• діаграми зв’язані між собою за допомогою номерів блоків, таким чином формується ієрархія діаграм і можна побудувати дерево діаграм;

• найменування блоків унікальні (відсутність повторюваних імен).

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

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

В SADT виділяється декілька типів зв’язності між функціями:

( 0) Випадкова зв’язність виникає, коли конкретний зв'язок між функціями малий або цілком відсутній (не використовуються однакові дані), у цьому разі функції не будуть пов’язані між собою стрілками.

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

(2) Часова зв’язність виникає тоді, коли дані використовуються одночасно або функції включаються паралельно, а не послідовно.

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

( 4) Комунікаційна зв’язність існує, коли блоки групуються внаслідок того, що вони використовують ті самі вхідні дані і/або роблять ті самі вихідні дані.

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

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

Методологія структурного аналізу і проектування SADT передбачає наступні етапи:

1. Створення функціональних моделей і діаграм. Збір інформації (Джерела інформації, Типи опитування, Процес опитування)

2. Резензування діаграм і моделей

3. Складання вихідної документації

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

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

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

10.4. IDEFo

В США в рамках програми ICAM (Інтеграція комп'ютерних і промислових технологій), проведеної з ініціативи ВВС, було розроблено стандарт IDEF0 (Icam DEFinition), який є підмножиною SADT. Документацію цього і ряду інших методів ІDEF можна знайти на сайті http://www.іdef.com . У США методи ІDEF оформлені і затверджені як федеральні стандарти обробки інформації (FІPS). IIDEF0 відповідає стандарт РФ Р50.1.028-2001. „Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования.”

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

AllFusion Process modeler 4.1 (Bpwin 4.1) компанії Computer Associates (www.ca.com) США.

WorkFlow Modeler (Design/IDEF.) – розробка компанії Meta Software Corporation (www.metasoftware.com) США.

IDEF0/EMTool – білоруської фірми ИП ОРИЕНТСОФТ (www.orientsoft.by).

10.4.1.Принципи побудови моделі іdef0

На сьогоднішній день ІDEF0 широко використовується для розв’язання двох типів задач:

1. Реінжиніринг бізнес-процесів організації.

2. Проектування інформаційних систем.

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

Тому слід відмітити, що при проектуванні інформаційних систем в ІDEF0 інформаційна система представляється:

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

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

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

Процес моделювання інформаційної системи в ІDEF0 починається з визначення контексту, тобто найбільш абстрактного рівня опису системи в цілому. У контекст входить визначення суб'єкта моделювання (Scope), мети (Purpose) і точки зору на модель (Vіewpoіnt). Також вказуються часові рамки моделі - AS-ІS чи ТО-ВE.Технологія проектування ІС передбачає спочатку створення моделі AS-ІS, її аналіз і поліпшення бізнесів-процесів, після чого створюється модель ТО-ВЕ, і тільки на основі моделі ТО-ВЕ будується модель даних, прототип і потім остаточний варіант ІС.

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

Поширеною помилкою при створенні моделі AS-ІS є створення ідеалізованої моделі. Прикладом може служити створення моделі на основі знань керівника, а не конкретного виконавця робіт.

10.4.2. Діаграми іdef0

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

Модель може мати чотири типи діаграм:

• контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);

• діаграми декомпозиції;

• діаграми дерева вузлів;

• діаграми тільки для експозиції (FEO).

К онтекстна діаграма (рис.10.8 ) є вершиною деревоподібної структури діаграм і являє собою самий загальний опис системи і її взаємодії з зовнішнім середовищем.

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

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

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

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

Старі версії якоїсь діаграми можна зберігати у виді паперової копії або як FEO-діаграму.

У будь-якому випадку варто відрізняти різні версії однієї і тієї ж діаграми. Для цього існує спеціальний номер - С-numbеr, що повинний привласнюватися автором моделі вручну. C-number - це довільний рядок, але рекомендується дотримувати стандарту, коли номер складається з буквеного префікса і порядкового номера, причому як префікс використовуються ініціали автора діаграми, а порядковий номер відслідковується автором вручну, наприклад МСВ00021.