Диаграммы потоков данных позволяют специфицировать как функции разрабатываемого программного обеспечения, так и обрабатываемые им данные. При использовании этой модели систему представляют в виде ие-рархии диаграмм потоков данных, описывающих асинхронный процесс пре-образования информации с момента ввода в систему до выдачи пользовате¬лю. На каждом следующем уровне иерархии происходит уточнение процес¬сов, пока очередной процесс не будет признан элементарным.
Модели потоков данных были независимо предложены сначала Е. Иорданом (1975), затем Ч. Геймом и Т. Сарсоном (1979). На этих моделях основаны классические методологии структурного анализа и проектирования программного обеспечения соответст¬венно Йордана-Де Марка и Гейна-Сарсона. Та же модель используется в методологии структурного анализа и проектирования SSADM (Structured Systems Analysis and Design Method), принятой в Великобритании в качестве национального стандарта разработки информацион¬ных систем.
В основе модели лежат понятия внешней сущности, процесса, хранили-ща (накопителя) данных и потока данных.
Внешняя сущность - материальный объект или физическое лицо, вы-ступающие в качестве источников или приемников информации, например: заказчики, персонал, поставщики, клиенты, банк и т. п.
Процесс - преобразование входных потоков данных в выходные в соот-ветствии с определенным алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем, который осуществляет данное преобра¬зование. Как в случае функциональных диаграмм, физически преобразова¬ние может осуществляться компьютерами, вручную или специальными уст¬ройствами. На верхних уровнях иерархии, когда процессы еще не определе¬ны, вместо понятия «процесс» используют понятия «система» и «подсистема», которые обозначают соответственно систему в целом или ее функционально законченную часть.
Хранилище данных - абстрактное устройство для хранения информа¬ции. Тип устройства и способы помещения, извлечения и хранения для тако¬го устройства не детализируют. Физически это может быть база данных, файл, таблица в оперативной памяти, картотека на бумаге и т. п.
Поток данных - процесс передачи некоторой информации от источника к приемнику. Физически процесс передачи информации может происходить по кабелям под управлением программы или программной системы или вручную при участии устройств или людей вне проектируемой системы.
Таким образом, диаграмма иллюстрирует как потоки данных, порожден¬ные некоторыми внешними сущностями, трансформируются соответствую¬щими процессами (или подсистемами), сохраняются накопителями данных и передаются другим внешним сущностям - приемникам информации. В ре¬зультате мы получаем сетевую модель хранения/обработки информации.
Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Иордана и Гейна-Сарсона (таблица 7.1).
Над линией потока, направление которого обозначают стрелкой, указывают, какая конкретно информация в данном случае передается (рис. 7.9).
Рисунок 7.9 - Пример потока данных (нотация Гейна-Сарсона)
Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида - контекстной диаграммы, которая определяет наиболее об¬щий вид системы. На такой диаграмме показывают, как разрабатываемая си¬стема будет взаимодействовать с приемниками и источниками информации без указания исполнителей, т. е. описывают интерфейс между системой и внешним миром. Обычно начальная контекстная диаграмма имеет форму звезды.
Если проектируемая система содержит большое количество внешних сущностей (более 10-ти), имеет распределенную природу или включает уже существующие подсистемы, то строят иерархии контекстных диаграмм.
При разработке контекстных диаграмм происходит детализация функ-циональной структуры будущей системы, что особенно важно, если разра¬ботка ведется несколькими коллективами разработчиков.
Полученную таким образом модель системы проверяют на полноту ис-ходных данных об объектах системы и изолированность объектов (отсутст¬вие информационных связей с другими объектами).
На следующем этапе каждую подсистему контекстной диаграммы дета-лизируют при помощи диаграмм потоков данных. В процессе детализации соблюдают правило балансировки - при детализации подсистемы можно использовать компоненты только тех подсистем, с которыми у раз-рабатываемой подсистемы существует информационная связь (т. е. с кото¬рыми она связана потоками данных).
Решение о завершении детализации процесса принимают в следующих случаях:
- процесс взаимодействует с 2-3-мя потоками данных;
- возможно описание процесса последовательным алгоритмом;
- процесс выполняет единственную логическую функцию преобразова-ния входной информации в выходную.
На недетализируемые процессы составляют спецификации, которые должны содержать описание логики (функций) данного процесса. Такое опи-сание может выполняться: на естественном языке, с применением структурированного естественного языка (псевдокодов), с применением таблиц и деревьев решений, в виде схем алгоритмов, в том числе flow-форм и диаграмм Насси-Шнейдермана.
Для облегчения восприятия процессы детализируемой подсистемы ну-меруют, соблюдая иерархию номеров: так процессы, полученные при дета-лизации процесса или подсистемы «1», должны нумероваться «1.1», «1.2» и т. д. Кроме этого желательно размещать на каждой диаграмме от 3-х до 6-7-ми процессов и не загромождать диаграммы деталями, не существенны¬ми на данном уровне.
Декомпозицию потоков данных необходимо осуществлять параллельно с декомпозицией процессов.
Окончательно разработку модели выполняют в два этапа.
I этап - построение контекстной диаграммы - включает выполнение следующих действий:
- классификацию множества требований и организацию их в основные функциональные группы - процессы;
- идентификацию внешних объектов - внешних сущностей, с которыми система должна быть связана;
- идентификацию основных видов информации - потоков данных, циркулирующей между системой и внешними объектами;
- предварительную разработку контекстной диаграммы;
- изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при изучении вопросы по всем ее частям;
- построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
2 этап - формирование иерархии диаграмм потоков данных - включает для каждого уровня:
- проверку и изучение основных требований по диаграмме соответствующего уровня (для первого уровня - по контекстной диаграмме);
- декомпозицию каждого процесса текущей диаграммы потоков данных с помощью детализирующей диаграммы или - если некоторую функцию сложно или невозможно выразить комбинацией процессов, построение спецификации процесса;
- добавление определений новых потоков в словарь данных при каждом появлении их на диаграмме;
- проведение ревизии с целью проверки корректности и улучшения наглядности модели после построения двух-трех уровней.
Полная спецификация процессов включает также описание структур данных, используемых как при передаче информации в потоке, так и при хра-нении в накопителе. Описываемые структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что соответствующие элементы данных в структуре могут отсутствовать. Альтернатива означает, что в структуру может входить один из перечислен¬ных элементов. Итерация означает, что элемент может повторяться некото¬рое количество раз.
Кроме того, для данных должен быть указан тип: непрерывное или дис-кретное значение. Для непрерывных данных могут определяться единицы измерений, диапазон значений, точность представления и форма физическо¬го кодирования. Для дискретных - может указываться таблица допустимых значений.
Полученную законченную модель необходимо проверить на полноту и согласованность. Под согласованностью модели в данном случае понимают выполнение для всех потоков данных правила сохранения информации: все поступающие куда-либо данные должны быть считаны и записаны.