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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Сутність структурного підходу

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

Усі найбільш поширені методології структурного підходу [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 BW 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 BV, Netherlands, 1994. Uniface V6.1 Designers 'Guide. Uniface BV, Netherlands, 1994.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
32.4кб. | скачати


Схожі роботи:
Системний підхід до проектування
Структурний функціоналізм
Структурний аналіз
Структурний функціоналізм
Структурний аналіз галузей
Структурний аналіз Зубостругальний механізму
Держава як структурний елемент суспільства
Структурний функціоналізм в соціології релігії
Мовна комунікація 2 Структурний аналіз
© Усі права захищені
написати до нас