Послан клиенту

Отпечатан

Ошибка печати

Доставлен

, Утерян на почте .

Предъявлен первый чек

Действующий

Клиент закрывает счет

-► Признан I недействительным!

Клиент закрывает счет

Закончен

W Предъявлен -ЯЯт

Сдан в архив

последний чек

Истекло три года

Рис. 3.30. Диаграмма жизненного цикла чека

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

Диаграммы потока данных

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

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

иллюстрируют Бнещние механизмы подачи данных, которые потребуют наличия интерфейса некоторого вида;

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

ф выполняют ориентированное на данные секционирование всей системы.

На рис. 3.31 изображена простая диаграмма потока данных, на котороп 5Ь1 можете увидеть многие из типовых конструкций. Прямоугольник с надписью Customer ( Клиент ) представляет повторяющуюся внешнюю суш-ность. Обратите внимание: эта сущность встречается на диаграмме дважды. Такое повторение - типичная особенность ДПД Луте показывать поток слева направо, чем пытаться замкнуть его на первую конструкцию. Циклы несколько чужды концепции ДПД, потому что они, скорее, напоминают обработку, а не поток данных.

Клиент

Заказ сделан

Заказ подтвержден

Прием заказа

Склад

Сведения о заказе

Отгрузка заказа

D8 Адрес отгрузки клиента

Фактура

Товары отгружены

Рис 3 31 Простая ДПД, описывающая поток данных в системе обработки

заказов

Прямоугольники с закругленными углами Р1 и Р2 - это процессы обработки данных. Возможно, в конечном итоге эти высокоуровневые процессы будут разбиты на более подробные ДПД. Например, процесс Take Order ( Прием заказа , Р1) будет, вероятно, определять метод оплаты и проверять кредитоспособность клиента. Блоки D4, D7 и D8 - это хранилища данных.

О диаграммах потока данных можно говорить очень много, но здесь мы лишь коснулись этой темы, поскольку ДПД являются инструментом анализа и предметом нашей книги не являются.

Проектирование, управляемое данными, и л1етамодели

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

Если изъять правила из приложения и поместить их в базу данных, то это сделает приложение более гибким. В большинстве проектов результаты анализа включают ряд справочных таблиц. Некоторые из них часто используются для хранения текстовых толкований закодированных значений (например, соответствий FR - France, DE - Germany). Вероятно, может возникнуть желание хранить в таблицах значения некоторых констант, используемых в программе (например, ставок налога и лимитов ассигнований). Но мы не классифицируем такой подход как проектирование, управляемое данными, и вообще считаем это плохим стилем программирования.

Однако в некоторых проектах очевидно, что пользователям требуется (или может потребоваться, что совсем не одно и то же) обеспечить возможность изменять порядок работы приложения, может быть, даже отдельно для каждой записи. Часто требуется, например, присваивать записи произвольное свойство - автоматизированный эквивалент комментария на визитной карточке (рис. 3.32).

Name: Jack Smith Address: 101 Main Street Anytown

Email: jack smith@some company.com Phone: (121) 123567

caee

Рис. 3.32. Присваивание записи произвольного свойства