Приклад використання структурного підходу 2.5.1. Опис предметної області

У даному прикладі використовується методологія Yourdon [12], реалізована в CASE-засобі Vantage Team Builder [14].

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

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

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

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

На фазі аналізу будується модель середовища (Environmental Model). Побудова моделі середовища включає:  аналіз поведінки системи (визначення призначення ІС, побудова      початковій контекстної діаграми потоків даних (DFD) та формування      матриці списку подій (ELM), побудову тематичних діаграм);  аналіз даних (визначення складу потоків даних та побудова      діаграм структур даних (DSD), конструювання глобальної моделі даних в      вигляді ER-діаграми).

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

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

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

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

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

Рис. 2.42. Початкова контекстна діаграма

Список подій будується у вигляді матриці (ELM) і описує різні дії зовнішніх сутностей і реакцію ІС на них. Ці дії являють собою зовнішні події, що впливають на бібліотеку. Розрізняють такі типи подій:         Абревіатура          Тип             NC         Нормальне управління             ND         Нормальні дані             NCD         Нормальне управління/дані             TC         Тимчасове управління             TD         Тимчасові дані             TCD         Тимчасове управління/дані     

Всі дії позначаються як нормальні дані. Ці дані є подіями, які ІС сприймає безпосередньо, наприклад, зміна адреси клієнта, що має бути відразу зареєстровано. Вони з'являються в DFD в якості вмісту потоків даних.

Матриця списку подій має такий вигляд:         №          Опис          Тип          Реакція              1         Клієнт бажає стати членом бібліотеки         ND         Реєстрація клієнта в якості члена бібліотеки              2         Клієнт повідомляє про зміну адреси         ND         Реєстрація зміненого адреси клієнта              3         Клієнт запитує оренду фільму         ND         Розгляд запиту              4         Клієнт повертає фільм         ND         Реєстрація повернення              5         Керівництво надає повноваження новому постачальнику         ND         Реєстрація постачальника              6         Постачальник повідомляє про зміну адреси         ND         Реєстрація зміненого адреси постачальника              7         Постачальник направляє фільм до бібліотеки         ND         Отримання нового фільму              8         Керівництво запитує новий звіт         ND         Формування необхідного звіту для керівництва     

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

На наведеній DFD (малюнок 2.43) накопичувач даних "бібліотека" є глобальним або абстрактним поданням сховища даних.

Аналіз функціонального аспекту поведінки системи дає уявлення про обмін та перетворення даних у системі. Взаємозв'язок між "абстрактними" потоками даних та "конкретними" потоками даних на діаграмі нульового рівня виражається в діаграмах структур даних (малюнок 2.44).

На фазі аналізу будується глобальна модель даних, яка надається у вигляді діаграми "сутність-зв'язок" (малюнок 2.45).

Між різними типами діаграм існують наступні взаємозв'язки:  ELM-DFD: події - вхідні потоки, реакції - вихідні потоки  DFD-DSD: потоки даних - структури даних верхнього рівня  DFD-ERD: накопичувачі даних - ER-діаграми  DSD-ERD: структури даних нижнього рівня - атрибути сутностей

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

Рис. 2.43. Контекстна діаграма

Рис. 2.44. Діаграма структур даних

Результатами проектування архітектури є:  модель процесів (діаграми архітектури системи (SAD) і      мініспеціфікаціі на структурованому мовою);  модель даних (ERD і подсхеми ERD);  модель для користувача інтерфейсу (класифікація процесів на      інтерактивні та Неінтерактивні функції, діаграма послідовності форм      (FSD - Form Sequence Diagram), що показує, які форми з'являються в      додаток і в якому порядку. На FSD фіксується набір і структура викликів      екранних форм. Діаграми FSD утворюють ієрархію, на вершині якої      знаходиться головна форма програми, що реалізує підсистему. На другому      рівні знаходяться форми, що реалізують процеси нижнього рівня функціональної      структури, зафіксованої на діаграмах SAD.

Рис. 2.45. Діаграма "сутність-зв'язок"

На фазі детального проектування будується модульна модель. Під модульної моделлю розуміється реальна модель проектованої прикладної системи. Процес її побудови включає в себе:  уточнення моделі бази даних для наступної генерації      SQL-пропозицій;  уточнення структури призначеного для користувача інтерфейсу;  побудова структурних схем, що відбивають логіку роботи      призначеного для користувача інтерфейсу і модель бізнес-логіки (Structure Charts      Diagram - SCD) і прив'язка їх до форм.

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

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

На основі аналізу потоків даних і взаємодії процесів з сховищами даних здійснюється остаточне виділення підсистем (попереднє має було бути зроблено і зафіксовано на етапі формулювання вимог в технічному завданні). При виділенні підсистем необхідно керуватися принципом функціональної зв'язаності і принципом мінімізації інформаційної залежності. Необхідно враховувати, що на підставі таких елементів підсистеми як процеси і дані на етапі розробки повинно бути створено програму, здатне функціонувати самостійно. З іншого боку, при угруповання процесів і даних в підсистеми необхідно враховувати вимоги до конфігурації продукту, якщо вони були сформульовані на етапі аналізу. Література  Вендров А.М. Один з підходів до вибору засобів проектування баз      даних і додатків. "СУБД", 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.