Моделювання реалізацій - структурні карти

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

Структурні карти Константайна

Структурні карти Константайна є моделлю відносин ієрархії між програмними модулями (складовими програмної системи).

Базовим елементом структурної карти є модуль. Можна використовувати різні типи модулів.

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

Рис.10.23. Типи викликів модулів

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

Для моделювання умовних і циклічних викликів застосовуються вузли, подані на рис. 10.24.

Рис. 10.24. Умовні і циклічні виклики модулів

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

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

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

Зв'язки за даними і керуванням між модулями (передані як параметри) розкриваються анотуванням потоків-викликів (рис. 10.25). Стрілками відзначаються напрямки зв'язків.

Приклад структурної карти наведений на рис. 10.26.

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

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

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

Діаграма Джексона може включати елементи наступних типів (рис.10.27):

Модуль- використовується для представлення фрагмента обробки.

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

Бібліотека - відрізняється від підсистеми тим, що визначена поза проектом даної системи.

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

Для взаємопов’язування блоків використовуються зв'язки наступних типів:

· послідовний зв'язок, що забезпечує послідовне виконання блоків зліва направо;

· паралельний зв'язок, що забезпечує одночасне виконання блоків;

· умовний зв'язок, що забезпечує вибір однієї з альтернатив;

· ітераційний зв'язок, що забезпечує виконання блоку в циклі.

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

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

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

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

Зчеплення – coupling – кожний модуль має бути максимально незалежним від інших (навантаження по виходу не повинне перевищувати 6-7 модулів).

При цьому виділяють три типи нормального зчеплення: зчеплення за даними (data coupling), зчеплення за зразком (stamp coupling), зчеплення по керуванню (control coupling).

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

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

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

Існує також два види зчеплення, які не рекомендується використовувати при структурному проектуванні: зчеплення по загальній області (common coupling) та зчеплення по вмісту (content coupling).

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

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

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

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

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

Принцип відсутності пам'яті– ніякий модуль після виконання „не пам’ятає” свій попередній стан.

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

Слід також відмітити, що структурні карти можна отримати також з діаграм потоків даних (DFD) за допомогою так званого трансформаційного аналізу.:

10.6. МЕТОДОЛОГІЇ структурного Аналізу і проектування систем реального часу, діаграми STD

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

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

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

Обидва методи частіше згадують під однією абревіатурою - SA/RT.

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

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

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

На STD можуть бути наявні наступні елементи (рис10.29):

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

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

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

Взаємовідношення між DFD та STD діаграмами показано на рис.10.30.

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

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

За другим способом спочатку будується початковий стан, потім той, в який він може перейти і т.д.

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

· визначеність всіх станів і унікальніть їх імен;

· задання умов та дій для всіх потоків;

·
досяжність станів та можливість виходу з них.

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

Таблиця 10.3.

ПОТОЧНИЙ СТАН

УМОВА

ДІЯ

НАСТУПНИЙ СТАН

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

Таким чином, методологія Уорда-Меллора передбачає використання розширених DFD-діаграм, STD-діаграм, а також ERD-діаграм для специфікації даних.

Основна відмінність між методологіями Уорда-Меллора і Хатлі-Пірбхея у тому, що останні розділяють DFD-діаграми та контролюючі потоки на два окремих представлення. Це, на думку багатьох авторів ускладнює розуміння діаграм.

Якщо ж говорити про інструментальні засоби, що підтримують вищеописані методології, то серед таких можна назвати:

· Aonix (www.aonix.com) – підтримує як методи SA/SD, так і SA-RT.

· System Architect (www.popkin.com ) – підтримує методи Гейна-Сарсона, Йордона-Де-Марко, Йорда-Меллора, SSADM

· WinA&D 5.1 (http://www.excelsoftware.com ) - дозволяє зображувати DFD, ERD та інші моделі.

10.7. Інформаційне моделювання Мартіна

Методологія Інформаційного Моделювання, або Інформаційного Інжинірингу описана Джеймсом Мартіном (James Martin ) і Клівом Фінкельштейном (Clive Finkelstein) у 1981 році. Після чого кожен з авторів розвивав методологію самостійно, однак версія саме Мартіна набула популярності у 90-х.

Початково, Інформаційний Інжиніринг забезпечував аналіз даних та техніки проектування баз даних, які могли бути використані адміністраторами баз даних та системними аналітиками для розробки баз даних і систем, виходячи з розуміння операційних потреб організацій у 80-і роки.

Після 1983 року Мартін зфокусувався на можливостях автоматизації процесів розробки ІС і методологія Мартіна забезпечила основу для розробки CASE-систем. Сам Мартін доклав зусиль до розробк як мінімум чотирьох CASE-засобів: InTech (Excelerator), Higher Order Software, KnowledgeWare (Database Design Inc), і James Martin Associates.

На початку 90-хроків Інформаційне Моделювання Мартіна включало і Rapid Application Development (RAD) і Business Process Re-engineering (BPR), а незабаром і об’єктно-орієнтований напрямок.

Що ж собою являє Інформаційне Моделювання?

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

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

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

Підхід Мартіна базується на двох концепціях:

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

· первісної спрямованості на моделювання даних, а потім на функціональне моделювання

До основних етапів підходу Мартіна відносяться:

1. Іінформаційне стратегічне планування - Information Strategy Planning (ISP) - інформаційне стратегічне планування починається з побудови стратегічного плану розробки системи, що підтримуватиме бізнесові потреби.

2. Аналіз предметної області – включає:

- Outline Business Area Analysis(OBAA) – Загальний аналіз предметної області передбачає виділення задач для включення їх в проект. Визначаються спеціфічні інформаційні потреби і пріоритети для предметної області.

- Detailed Business Area Analysis(DBAA) – Детальний аналіз предметної області має на меті забезпечити деталізацію моделей, як основи для розробки системи.

3. Логічне проектуваннясистеми – включає:

- Business System Design–Проектування бізнес-систем , має на меті специфікацію всіх аспектів систем, які пов’язані з користувачами.

- Technical Design–Технічне проектування - передбачає підготовку системи до побудови і впровадження.

4. Фізичне проектування і реалізація – включає:

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

- Transition -Перехід – визначається як період, під час якого новостворені частини системи пов’язуються з існуючими процедурами.

- Production – Виробництво – робота системи.

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

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

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

· Діаграми залежності (Dependency Diagrams) - використовуються, щоб представити залежності функцій, процесів і процедур.

· Діаграми потоків даних (Data Flow Diagrams) – для моделювання погтоків даних.

· Діаграми аналізу і структури даних (Data Analysis and Data Structure Diagrams) – для опису структур даних.

· Діаграми „сутність-зв’язок” – дозволяють будувати моделі бінарних відносин між об’єктами. Поряд з їх побудовою виконується нормалізація даних.

· Діаграми навігації даних Data Navigation Diagrams - використовуються для представлення запитів та режиму доступу до об’єктів моделі „сутність-зв’язок”.

· Дерева рішень і Таблиці рішень – використовують decision table technique (DTAB).

· Діаграми переходів станів (State Transition Diagrams)- для моделювання станів процесів реального часу.

· Діаграми розробки діалогу (Dialog Design Diagrams) – для розробки і представлдення діалогу користувача.

На рис. 10.31. наведені методи і техніки, що використовуються при Інформаційному Моделюванні.

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

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

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

Серед інструментальних засобів, що підтримували Інформаційне Моделювання, можна назвати:

· Information Engineering Facility (IEF, від Texas Instruments Software, з 2006 - ALLFusion Gen)

· Information Engineering Workbench (IEW), пізніше переіменовано в Application Development Workbench (ADW) від компанії KnowledgeWare. На сьогоднішній день не використовується.

· Пакет Visio на сьогодні забезпечує підтримку діаграм для деяких технік Мартіна.

КОНТРОЛЬНІ ЗАПИТАННЯ

1. Дайте визначення структурного підходу до проектування ІС .

2. Назвіть основні принципи структурного підходу.

3. Прокласифікуйте структурні методології проектування ІС.

4. Які типи зв’язків використовуються у функціональних блоках моделі SADT?

5. З якою метою використовуються діаграми IDEF0?

6. Назвіть типи діаграм в IDEF0.

7. Які типи зв’язків між роботами можуть використовуватися в IDEF0?

8. Для чого використовується тунелювання стрілок в IDEF0?

9. Призначення діаграм DFD.

10. Які основні елементи використовуються на DFD-діаграмах?

11. Призначення словників даних.

12. Для чого використовуються IDEF3-діаграми?

13. Які основні елементи використовуються на IDEF3-діаграмах?

14. Чи можна задати розгалудження стрілок без перехрестя в IDEF3?

15. Для чого використовуються структурні карти?

16. Назвіть відомі Вам методології структурного аналізу і проектування систем реального часу.

17. Яка відмінність між SDRTS-діаграмами та DFD?

18. Для чого використовуються STD-діаграми?

19. У чому суть інформаційного моделювання Мартіна?