Информационный поток

Логически информационный поток есть информация, передаваемая через некоторое соединение от источника к приемнику. В реальности информационный поток есть, например, информация, передаваемая по кабелю между двумя устройствами, письма, пересылаемые между респондентами, магнитная лента или дискета, переносимая между ЭВМ. Информационный поток может физически содержаться в телефонном звонке, при переходе от программы к программе через спутниковую информационную связь - при любом варианте прохождения данных от одного объекта или процесса к другому.

Рис. 12. Условные обозначения информационных потоков

Поток данных

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

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

Правила соединения узлов на диаграммах

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

Рис. 14. Допустимые соединения для потока данных

Все остальные типы соединений запрещены.

Правила детализации подсистем и процессов при помощи диаграмм

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

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

Рис. 16. Контекстная диаграмма системы обработки заказов

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

Рис. 17. Дочерняя диаграмма, детализирующая "Систему обработки заказов"

Эти диаграммы являются сбалансированными. Вы можете убедиться, что на дочерней диаграмме с внешними сущностями ИЗДАТЕЛИ и ЗАКАЗЧИКИ связаны только те потоки данных, которые определены на контекстной (материнской) диаграмме. И если, например, мы захотели бы связать потоком данных процесс "1.яПроверка достоверности заказа" с внешней сущностью ИЗДАТЕЛИ на дочерней диаграмме, то это нарушило бы правило балансировки. Если же такой поток действительно необходим, то он должен, прежде всего, быть введен на материнской диаграмме. Правило нумерации. Иерархическая нумерация подсистем и процессов поддерживается так, как это показано на рис. 18.

Рис. 18. Иерархическая нумерация процессов

Каждый сыновний процесс более низкого уровня соотносится с отцовским процессом верхнего уровня при помощи идентифицирующего номера, который является десятичным знаком номера отцовского процесса, например 29 получает десятичные обозначения 29.1, 29.2, 29.3 и т.д., при необходимости можно перейти на третий уровень, т.е. для 29.3 получим 29.3.1, 29.3.2 и т.д.