У даному прикладі використовується методологія 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 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.