Моделювання потоків даних (процесів)

В основі даної методології (методології Gane/Sarson [11]) лежить побудова моделі аналізованої ІС - проектованої або реально існуючої. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС з зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому процес стають елементарними і деталізувати їх далі неможливо.

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

зовнішні сутності;

системи/підсистеми;

процеси;

накопичувачі даних;

потоки даних Зовнішні суті

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

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

Рис. 2.13. Зовнішня сутність Системи і підсистеми

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

Підсистема (або система) на тематичній діаграмі зображується наступним чином (малюнок 2.14).

Рис. 2.14. Підсистема

Номер підсистеми служить для її ідентифікації. У полі імені вводиться найменування підсистеми у вигляді пропозиції з підметом і відповідними визначеннями та доповненнями. Процеси

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

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

Рис. 2.15. Процес

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

"Ввести відомості про клієнтів";

"Видати інформацію про поточні витрати";

"Перевірити кредитоспроможність клієнта".

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

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

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

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

Рис. 2.16. Накопичувач даних

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

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

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

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

Рис. 2.17. Потік даних Побудова ієрархії діаграм потоків даних

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

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

наявність великої кількості зовнішніх сутностей (десять і більше);

розподілена природа системи;

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

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

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

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

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

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

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

правило нумерації - означає, що при деталізації процесів повинна підтримуватися їх ієрархічна нумерація. Наприклад, процеси, деталізують процес з номером 12, отримують номери 12.1, 12.2, 12.3 та т.д.

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

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

наявності у процесу відносно невеликої кількості вхідних та вихідних потоків даних (2-3 потоку);

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

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

можливості опису логіки процесу за допомогою мініспеціфікаціі невеликого обсягу (не більше 20-30 рядків).

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

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

Вендров А.М. Один з підходів до вибору засобів проектування баз даних і додатків. "СУБД", 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 B.W. 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 B.V., Netherlands, 1994.

Uniface V6.1 Designers 'Guide. Uniface B.V., Netherlands, 1994.

IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools.

IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools.

PVCS Version Manager. User's Guide.