PrIS

101

4. Мови об'єктно-орієнтованого моделювання.

102

РОЗДІЛ 5. Структурний підхід

Принципи структурного проектування

Методологія структурного проектування

Інструментальні засоби структурного проектування

Діаграми структурного проектування

Урозділі описано принципи структурного проектування. Охарактеризовано основні діаграми структурного проектування. Подано визначення структурного аналізу та методологій структурного

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

5.1. Принципи структурного підходу до проектування

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

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

Структурне проектування відносять до традиційних технологій проектування. Основні характеристики традиційних методологій подані в таблиці 5.1.

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

структурний аналіз,

структурне проектування,

104

Усі найпоширеніші методології структурного підходу [31, 44] базуються на ряді загальних принципів [1]. Як два базові принципи використовуються такі:

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

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

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

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

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

105

принцип несуперечності – полягає в обґрунтованості й узгодженості елементів;

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

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

Інакше кажучи, засобами структурного аналізу логічна модель повинна описувати, що має робити проектована система.

5.3. Структурне проектування

Структурний підхід до проектування ІС (структурний аналіз/структурне проектування SA/SD — Structure Analyses & Structure Design) – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.

Методологія SADT розроблена Дугласом Россом і отримала подальший розвиток в роботі [4]. На її основі розроблена, зокрема, відома методологія IDEF0 (розглянуто нижче).

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

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

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

обмеження кількості блоків на кожному рівні декомпозиції (правило 15.6 блоків);

зв'язність діаграм (номери блоків);

унікальність міток і назв (відсутність імен, що повторюються);

106

синтаксичні правила для графіки (блоків і дуг);

розділення входів і управлінь (правило визначення ролі даних);

відділення організації від функції, тобто виключення впливу

організаційної структури на функціональну модель. Методологія SADT може використовуватися для моделювання

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

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

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

Кожен компонент моделі може бути декомпозиційований на іншій діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі.

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

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

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

108

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

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

(Computer Aided System/Software Engineering – комп’ютер-орієнтована системна/програмна інженерія).

Методологія IDEF0 є основою для широко відомої програмної системи BPwin (Business Process for Windows). Модель будується за допомогою “функціональних блоків” та “інтерфейсних дуг”. Перші нагадують кусково-лінійні аґреґати [9], а за допомогою дуг, які пов’язують між собою блоки, можна зобразити процес будь-якого рівня складності.

Нотація IDEF2 ніколи не була повністю реалізована. Нотація IDEF1 1985 року була розширена і перейменована в IDEF1X. Методологія IDEFSADT знайшла застосування в урядових і комерційних організаціях, оскільки на той період часу цілком задовольняла різним вимогам, що пред'являються до моделювання широкого класу систем.

На початку 1990 року спеціальна група користувачів IDEF (IDEF Users Group), у співпраці з Національним інститутом зі стандартизації і технології США (National Institutes for Standards and Technology, NIST),

зробила спробу створення стандарту для IDEF0 і IDEF1X. Ця спроба виявилася успішною і завершилася ухваленням 1993 року стандарту уряду США, відомого як FIPS для цих двох технологій – IDEF0 і IDEF1X. Протягом подальших років цей стандарт продовжував активно розвиватися і став основою для реалізації в деяких перших CASE-засобах.

Для підтримки стандартів IDEF1/IDEF1X існує багато інструментальних засобів, оскільки головною метою у цьому випадку виступають бази даних. СКБД – системи управління базами даних, – які при цьому використовуються, історично мають у своєму складі відповідні програмні рішення. Ще до офіційної появи стандартів IDEF1 вже існували та використовувалися методологія Oracle, методологія Power Builder та ін. Із появою стандартів цього класу до лідерів приєдналася програмна система ERwin, а саму методологію стали називати ER-моделюванням.

Останнім часом обидві програмні системи BPwin та ERwin випускають у складі інтеґрованого CASE-засобу AllFusion Modeling Suite.

109

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

Методології IDEF3, IDEF4 та IDEF5 можна вважати більш “екзотичними”, ніж попередні, тому важко назвати відомі приклади інструментальних засобів їх підтримки. Але як елементи інтеґрованих технологій вони можуть використовуватися. Крім того, стандарт IDEF4 має конкурента в особі стандарту MDA (Model Driven Architecture – архітектура, керована моделлю), який на сьогодні вважається індустріальним ІТ-стандартом для об’єктно-орієнтованих систем. Цей стандарт ґрунтується на використанні мови UML (Unified Modeling Language – уніфікована мова моделювання) [10].

Не можна не згадати про ARIS (від Architecture of Integrated Information Systems), яка являє собою методологію та програмний продукт компанії IDS Sheer, призначений для моделювання бізнеспроцесів. Основною перевагою ARIS можна вважати її високу інтеґрованість. Фактично вона включає підтримку більшості стандартів, які ми розглядали окремо. Зрозуміло, що такий продукт призначений виключно для великих проектів. Остання обставина робить її менш доступною для “ізольованого” використання, коли задіяні тільки окремі функції з великого переліку.

5.5. Інструментальні засоби структурного аналізу та проектування

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

BFD (Bussiness Function Diagram) – діаграма бізнес-функцій;

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

STD (State Transition Diagram) – діаграма переходів станів;

ERD (Entity Relationship Diagram) – модель «сутність-зв'язок» даних предметної області (інформаційно-логічна модель);

SSD (System Structure Diagram) – діаграма структури програмного застосування.

Проте зі всього різноманіття цих моделей найчастіше на практиці застосовуються діаграми потоків даних (DFD), діаграми «сутністьзв'язок» (ERD) і діаграми переходів станів (STD). Усі вони містять графічні та текстові засоби моделювання: для зручності демонстрування

110

основних компонентів моделі і забезпечення точного визначення її компонентів і зв'язків.

Висновки

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

2.Є два базових принципи структурного аналізу та проектування: принцип «розділяй та владарюй» та принцип ієрархічного впорядкування..

3.Сукупність стандартів IDEF використовується в методології структурного аналізу.

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

5.Структурний підхід до проектування ІС (структурний аналіз/структурне проектування SA/SD — Structure Analyses & Structure Design) – метод визначення вхідних даних, процесів та вихідних даних системи і поділ систем на підсистеми або модулі, що показують логічну графічну модель потоків інформації.

Контрольні запитання

1.Основні принципи структурного підходу.

2.Особливості структурного аналізу.

3.Методології структурного проектування.

4.Інструментальні засоби структурного аналізу та проектування.