В основі даної методології (методології 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 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.
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.