Матрица событий.

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

В конце анализа функций системы строится полная контекстная диаграмма с включением диаграммы 0-го уровня. При этом процесс "фильмотека" декомпозируется на 4 процесса с отражением основных видов деятельности администрации.

"Абстрактные" потоки данных между терминаторами и процессами преобразуются в потоки, выражающие обмен данными на более конкретном уровне. Список событий показывает существующие на этом уровне потоки: каждое событие из списка формирует входной поток, реакция - выходной поток. Один "абстрактный" поток можно разделить на несколько"конкретный" потоков (см. табл. 3.5.3.).

Табл. 3.5.3.

Формирование потоков данных диаграммы нулевого уровня.

Потоки на диаграмме верхнего уровня	Потоки на диаграмме нулевого уровня
Информация от клиента	Данные о клиенте, Запрос об аренде
Информация для клиента	Членская карточка, Ответ на запрос об аренде
Информация от руководства	Запрос отчета о новых членах, Новый поставщик, Запрос отчета о поставщиках, Запрос отчета об аренде, Запрос отчета о фильмах
Информация для руководства	Отчет о новых членах, Отчет о поставщиках, Отчет об аренде, Отчет о фильмах
Информация от поставщика	Данные о поставщике, Новые фильмы

На DFD (рис. 3.5.1.2.) накопитель данных "фильмотека" - глобальное или абстрактное представление хранилища данных.

Анализ функций системы информирует об обмене и преобразовании данных в ней. Взаимосвязь между "абстрактными" и "конкретными" потоками данных на диаграмме нулевого уровня выражаен диаграммами структур данных (рис. 3.5.1.3.).

На этой фазе строится глобальная модель данных в виде диаграммы "сущность-связь" (рис. 3.5.1.4.).

Рис. 3.5.1.2. Контекстная диаграмма.

Рис. 3.5.1.3. Диаграмма структур.

Рис. 3.5.1.4. Пример диаграммы "сущность-связь".

Между типами диаграмм существует ряд взаимосвязей:

ELM-DFD: события - входные потоки, реакции - выходные потоки;

DFD-DSD: потоки данных - структуры данных верхнего уровня;

DFD-ERD: накопители данных - ER-диаграммы;

DSD-ERD: структуры данных нижнего уровня - атрибуты сущностей.

Фаза проектирования архитектуры строит предметную модель, что вкключает:

детальное описание функционирования системы;

дальнейший анализ данных и построение их логической модели для проектирования базы данных;

определение структуры пользовательского интерфейса, спецификаций форм и порядка их появления;

уточнение диаграмм потоков данных и списка событий с выделением интерактивных и неинтерактивных процессов нижнего уровня, определение них миниспецификаций.

Итоги проектирования архитектуры:

модель процессов (диаграммы архитектуры системы SAD и миниспецификации на языке структур);

модель данных (ERD и ее подсхемы);

модель пользовательского интерфейса (выделение интерактивных и неинтерактивных функции с разделением процессов; диаграмма последовательности форм (FSD - Form Sequence Diagram) показывает формы приложения и их порядок. В 70-80-ые годы при проектировании для интерактивных подсистем строилась схема диалога пользователя, позволяющая «связать» все выходные и входные формы диалоговой системы для ее целостности, а для других подсистем выпускался альбом выходных форм. Отметить важность и полезность создания таких документов при проектировании модели пользовательского интерфейса и сейчас.

На FSD фиксируется набор и структура вызовов экранных форм. Иерархия диаграмм FSD имеет на вершине главную форму приложения, реализующего подсистему. На втором уровне - формы реализации процессов нижнего уровня функциональной структуры из диаграмм SAD.

Фаза детального проектирования порождает модульную, т.е. реальную модель проектируемой прикладной системы. Этот процесс включает:

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

уточнение структуры пользовательского интерфейса;

построение структурных схем для логики работы пользовательского интерфейса и модель бизнес-логики (Structure Charts Diagram - SCD) с привязкой их к формам.

Итоги детального проектирования:

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

модель данных (определение в ERD всех нужных параметров для приложений);

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

Фаза реализации включает:

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

уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.

После анализа потоков данных и взаимодействия процессов с хранилищами данных окончательно выделяют подсистемы (предварительно это фиксируется при формулировке требований в техническом задании). Выделение подсистем использует принципы функциональной связанности и минимизации информационной зависимости. На основании процессов и данных подсистемы на этапе разработки создают приложение, способное функционировать самостоятельно. Кроме того при группировке процессов и данных в подсистемы надо учитывать требования к конфигурированию продукта, данные на этапе анализа.