3.3. Моделирование потоков данных

В основу данной методологии (методологии Gane/Sarson) положена модель системы - реально существующей или проектируемой. По этой методологии модель определяется иерархией диаграмм потоков данных (ДПД или DFD), описывающих асинхронное преобразование информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются диаграммами нижнего уровня. Этот процесс создавая многоуровневой иерархии диаграмм продолжается, до достижения уровня декомпозиции, на котором процессы становятся элементарными без нужды в дальнейшей детализации.

Внешние сущности создают информационные потоки, доставляющие информацию к подсистемам и процессам. Последние преобразуют информацию и создают новые потоки, для ее передачи на следующие уровни, к накопителям данных или внешним потребителям информации.

Итак, основные компоненты диаграмм потоков данных суть:

• внешние сущности;

• системы/подсистемы;

• процессы;

• накопители данных;

• потоки данных.

Внешние сущности.

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

Рис. 3.3.1. Внешняя сущность.

Системы и подсистемы.

При построении модели сложную систему можно представить в общем виде на контекстной диаграмме в виде единого целого, либо ее можно декомпозировать на ряд подсистем. Изображение подсистемы на диаграмме дано на рис. 3.3.2.

Рис. 3.3.2. Изображение подсистемы на диаграмме потоков данных.

Номер подсистемы нужен для ее идентификации, в поле имени дано наименование подсистемы в виде развернутого предложения.

Процессы.

Процесс есть преобразование входных потоков данных в выходные по определенному алгоритму. Физически преобразование можно реализовать по-разному: как отдел по обработке входных документов и выпуску отчетов, аппаратно реализованное логическое устройство, программа и т.д.

Изображение процесса на диаграмме потоков данных дано на рис. 3.3.3.

Рис. 3.3.3. Изображение процесса на диаграмме потоков данных.

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

"Ввести сведения о клиентах";

"Выдать информацию о кредитной истории".

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

Накопители данных.

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

Рис. 3.3.4. Изображение накопителя данных на диаграмме потоков данных.

Идентифицикатор накопителя содержит букву "D" и произвольное число, его имя выбирается по наибольшей информативности для проектировщика.

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

Потоки данных.

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

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

Рис. 3.3.5. Изображение потока данных на диаграмме.

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

Для иерархии диаграмм потоков данных (ДПД) сначала строятся контекстные диаграммы. В относительно простых системах строится одна диаграмма с топологией «звезда», где в центре находится главный процесс, соединенный с приемниками и источниками информации, играющими роль внешнего интерфейса системы.

Если в сложной системе оставить одну контекстную диаграмму, то в ней будет слишком много источников и приемников информации, что трудно отобразить на бумаге нормального формата, да и один главный процесс не отражает структуру распределенной системы. Признаки контекстной сложности:

• порядка 10 и более внешних сущностей;

• распределенная природа системы;

• многофункциональность системы со сгруппированными подсистемами функций.

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

Иерархией контекстных диаграмм дано взаимодействие основных функциональных подсистем между собой и с внешними объектами (источниками и приемниками информации) и потоками данных. Тем самым решается проблема определения функциональной структуры системы на ранних этапах ее проектирования.

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

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

При детализации соблюдают следующие правила:

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

нумерация - детализация процессов сохраняет их иерархическую нумерацию. Так, процессы, детализирующие процесс 12, имеют номера 12.1, 12.2, 12.3 и т.д.

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

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

Миниспецификация процесса должна формулировать его основные функции так, чтобы дальше при реализации проекта, их можно было выполнить непосредственно. Завершение детализации процесса происходит по следующим критериям:

• наличие у процесса 2-3 потоков входных и выходных данных;

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

• выполнение процессом одной функции преобразования информации;

• не более 20-30 строк для миниспецификации описания логики процесса.

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

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