Приклад використання структурного підходу

Опис предметної області

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

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

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

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

Організація проекту

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

На фазі аналізу будується модель середовища (Envіronmental Model). Побудова моделі середовища включає:

- аналіз поводження системи (визначення призначення ІС, побудова початкової контекстної діаграми потоків даних (DFD) і формування матриці списку подій (ELM), побудова контекстних діаграм);

- аналіз даних (визначення складу потоків даних і побудову діаграм структур даних (DSD), конструювання глобальної моделі даних у вигляді ER-діаграми).

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

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

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

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

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

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

Список подій будується у вигляді матриці (ELM) і описує різні дії зовнішніх сутностей і реакцію ІС на них. Ці дії являють собою зовнішні події, що впливають на бібліотеку. Розрізняють наступні типи подій:

Абревіатура	Тип
NC	Нормальне керування
ND	Нормальні дані
NCD	Нормальне керування /дані
TC	Тимчасове керування
TD	Тимчасові дані
TCD	Тимчасове керування/дані

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

Матриця списку подій має такий вигляд:

№	Опис	Тип	Реакція
	Клієнт бажає стати членом бібліотеки	ND	Реєстрація клієнта як член бібліотеки
	Клієнт повідомляє про зміну адреси	ND	Реєстрація зміненої адреси клієнта
	Клієнт запитує оренду фільму	ND	Розгляд запиту
	Клієнт повертає фільм	ND	Реєстрація повернення
	Керівництво надає нові повноваження постачальникові	ND	Реєстрація постачальника
	Постачальник повідомляє про зміну адреси	ND	Реєстрація зміненої адреси постачальника
	Постачальник направляє фільм у бібліотеку	ND	Одержання нового фільму
	Керівництво запитує новий звіт	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 Dіagram), що показує, які форми з'являються в додатку і в якому порядку. На FSD фіксується набір і структура викликів екранних форм. Діаграми FSD утворюють ієрархію, на вершині якої перебуває головна форма додатку, що реалізує підсистему. На другому рівні перебувають форми, що реалізують процеси нижнього рівня функціональної структури, зафіксованої на діаграмах SAD.

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

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

- уточнення моделі бази даних для наступної генерації SQL-пропозицій;

- уточнення структури користувацького інтерфейсу;

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

Результатами детального проектування є:

- модель процесів (структурні схеми інтерактивних і неінтерактивних функцій);

- модель даних (визначення в ERD всіх необхідних параметрів для додатків);

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

На фазі реалізації будується реалізаційна модель. Процес її побудови містить у собі:

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

- уточнення структурних схем (SCD) і діаграм послідовності форм (FSD) з наступною генерацією коду додатків.

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