2.7 Техника моделирования потоков данных

2.7.1. Модель потоков данных существующей системы (мпд сс)

Основная цель этой модели - точно отразить существующую систему и ее окружение в терминах информационных потоков так, чтобы все задачи существующих служб могли быть определены и. согласованы, а затем отражены в виде требований в «Каталоге требований». Здесь же определяются и описываются службы, которые должны появиться в новой системе. Процесс синтеза МПД СС помогает установить связь между аналитиком и пользователем, а также вовлечь пользователя в процесс проектирования.

2.7.1.1. Начало моделирования

В начале процесса построения МПД трудности возникают только, в том случае, когда метод используется впервые. В этом случае полезно воспользоваться следующими правилами:

а) согласовать с пользователями предмет и рамки исследований и определи исходную границу системы, опираясь на объём проекта, указанный в инициирующих этот проект документах;

6) определить ключевые входы и выходы системы (если это делается для существующей системы, то могут рассматриваться традиционные документы, формы отчеты);

в) определить источники и потребителей данных для каждого потока, лежащего за пределами системы, и представить их на СПД в виде внешних объектов;

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

д) нарисовать внешние объекты, процессы, хранилища данных и соединить линиями потоков данных;

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

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

з) проверить схему на содержательность и полноту, а затем в неофициальном порядке рассмотреть ее с пользователями.

Действие (ж) должно выполняться с осторожностью, т.к. аналитик должен быть уверен, что потоки между процессами не требуют логического упорядочения и связаны между собой временными зависимостями.

Выборки

Требования к выбираемым и отчетным данным, которые могут быть запросами и которые не являются вставляемыми, модифицируемыми или удаляемыми записями лучше специфицировать не в МПД, а в «Каталоге требований». Например, такая выборка как «Поиск всей подходящей заявителю собственности», может быть определена в виде требования. Бели таких выборок больше 15 то, даже если описывать того, как будут выпускаться отчеты, они существенно запутают МПД. Такие выборки должны определяться исключительно как функции запроса, поддерживаемые путями доступа, через логическую структуру данных требуемой системы (ЛСД ТС), метод, построения которой описывается в следующей главе Отображение на СПД выборки в виде процесса оправдано только тогда, когда выборка является основной частью функционирования системы и выполняемых действий.

Полностью описание СПД 1-го уровня для «Жилищной системы» приведено в Приложении 1, а на рис. 2.11 изображен фрагмент этого приложения.

Рис. 2.11. Выдержка из схемы потоков данных первого уровня «Жилищной системы»

Проверка полноты и содержательности

Перед просмотром СПД с пользователями должны быть выполнены некоторые простые проверки содержательности и полноты. Эти проверки состоят в следующем:

• имя каждого процесса в идеале должно содержать точный глагол, описывающий действия и единственную цель (например, «Изъять чек»). Если подходящее название найти трудно, то возможно, что не все процессы будут ясно понимаемы и необходимо в дальнейшем их декомпозировать;

• все потоки данных, связанные с одним процессом, обычно должны быть согласованы с остальными потоками;

• чем меньше информации проходит между двумя процессами, тем лучше будет их разделение;

• процессы не должны быть источниками данных или их потребителями. Процесс только преобразует входной поток в выходной. Он может управлять некоторыми единицами данных, такими как результаты и итоги, но не должен использовать данные без выдачи другому процессу, хранилищу данных или внешнему объекту;

• к хранилищам данных присоединяются входящий и наследующий его потоки. Другими словами, данные должны создаваться и использоваться процессами или внешними объектами и храниться постоянно или временно в хранилищах. Тривиальные процессы на СПД 1-го уровня не показываются с целью сокращения размеров схемы.

Это дает возможность обеспечить сквозное прохождение данных от входа в систему через обработку на хранение и к выходу. Проверка правильности прохождения данных обычно делается путем просмотра схемы. В случае очень сложной схемы нужно, чтобы проверка полноты СПД производилась по отдельным документопотокам с целью уточнения входов и выходов системы. Разработка схем отдельных документопотоков описывается в 2.7.1.3.

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