Методология DFD

Диаграммы потоков данных (Data Flow Diagrams) представляют сеть связанных между собой работ. Их удобно использовать для описания документооборота и обработки информации.

DFD описывает:

1. функции обработки информации (работы);

2. документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;

3. внешние ссылки (external reference), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;

4. таблицы для хранения документов (хранилища данных, data store).

Для построения диаграмм DFD в BPwin используется нотация Гейна-Сарсона (таблица 1).

 

Таблица 1 – Нотация Гейна-Сарсона

Компонент	Обозначение
Поток данных
Процесс (работа)
Хранилище
Внешняя сущность

Потоки данных используются для моделирования передачи информации (или физических компонентов) из одной части системы в другую. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т. д. Потоки изображаются на диаграмме именованными стрелками, ориентация которых указывает направление движения информации. Стрелки могут подходить к любой грани прямоугольника работы и могут быть двунаправленными для описания взаимодействия типа «команда-ответ».

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

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

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

Рисунок 24 – Внешняя сущность

 

Диаграммы DFD можно использовать как дополнение к диаграммам IDEFO для описания документооборота и обработки информации.

 

Диаграммы потоков данных (Data Flow Diagrams)

Для дополнения модели IDEFO диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count указать тип диаграммы DFD (рисунок 25).

 

Рисунок 25 – Диалог Activity Box Count

 

Рассмотрим работу «Выполнение запроса». Запросы в систему поступают от пользователей, поэтому запросы от каждой категории будут обрабатываться отдельно. Выделим внешние сущности диаграммы согласно каждой категории пользователей, определяя потоки данных, которыми они обмениваются с системой. Получим диаграмму, изображенную на рисунке 26.

Рисунок 26 – DFD-декомпозиция работы «Выполнение запроса»

 

Согласно описанию системы проведем декомпозицию полученных блоков (рисунки 26– 29).

Рисунок 26 – Декомпозиция работы «Обработать запрос студента»

Рисунок 27 – Декомпозиция работы «Обработать запрос декана»

 

Рисунок 28 – Декомпозиция работы «Обработать запрос фирмы»

 

Рисунок 29 – Декомпозиция работы «Обработать запрос эксперта»

 

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

Проведем анализ полученных диаграмм. Рассматривая диаграмму, изображенную на рисунке 30, необходимо отметить наличие в ней лишнего блока «Обработать запрос администратора». При составлении первого варианта диаграммы работы были определены исходя из категорий пользователей. Это привело к возникновению конфликта с функциями системы и с точкой зрения на модель. Администратор не обслуживается системой как обычный клиент, он обеспечивает ее мониторинг. Администратор может добавлять пароли, изменять уровень доступа в систему, добавлять нового пользователя и т. д. С точки зрения клиента системы, деятельность администратора является второстепенной, поэтому на всех диаграммах отсутствует описание функций администратора, представляя его влияние как «механизм» для других функций. Поэтому принимаем решение удалить работу «Обработать запрос администратора».

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

Рисунок 30 – Декомпозиция работы «Обработать запрос студента» (вариант 2)

 

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

Рисунок 31 – Декомпозиция работы «Обработать запрос декана» (вариант 2)

 

Перейдем к следующей диаграмме – «Обработать запрос эксперта» (рисунок 32). Корректировок эта диаграмма не требует, кроме уточнения названия функций. Перед проведением экспертной оценки эксперт должен выбрать студента. Термин «определить» может подразумевать вмешательство эксперта, при котором он на основании каких-либо предпочтений выбирает студента для проведения оценки. На самом деле студент просто выбирается из общего списка. Хотя здесь могут существовать внешние факторы, например требование фирмы на составление экспертной оценки для студента. Эта ситуация должна отражаться на диаграмме «Обработать запрос фирмы», т. е. необходимо внести дополнительную работу «Найти экспертные оценки студента». Причем если такие оценки не найдены, то необходимо генерировать запрос для эксперта на их составление.

Помимо указанных недостатков, диаграмма «Обработать запрос фирмы» имеет еще несколько. Можно объединить работы «Составить приглашение» и «Отослать студенту» в одну работу «Составить и отослать приглашение», упростив диаграмму.

 

Рисунок 32 – Декомпозиция работы «Обработать запрос фирмы» (вариант 2)

Рисунок 33 – Декомпозиция работы «Обработать запрос эксперта» (вариант 2)

Рисунок 34 – DFD-декомпозиция работы «Выполнение запроса» (вариант 3)