Dfd правила построения. Методология DFD - Учебная и научная деятельность Анисимова Владимира Викторовича

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

DFD - общепринятое сокращение от англ. data flow diagrams - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия

Для себя я вывел следующую формулировку:

DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.

Зачем нужна нотация DFD?

Сам я пользуюсь только одним из вариантов, по Гейну и Сарсону. Но когда я изучал материал перед написанием этой статьи, я увидел эту таблицу сравнения. Считаю, что она важна не столько для выбора варианта синтаксиса, он будет зависеть, скорее от выбора программного обеспечения для создания нотаций и ваших личных предпочтений, сколько как наглядная иллюстрация того факта, что в DFD нет жесткого синтаксиса, как, например, в BPMN. Здесь можно использовать разные варианты, главное, чтобы они были понятны вам и вашим клиентам. Нотации DFD - удобный инструмент для создания нерегламентированных диаграмм, которые можно сделать быстро и с максимумом свободы.

Применяется этот вид нотации в случае, когда требуется описание системы как хранилища данных. Т.е. нотация должна наглядно ответить на вопросы:

• Из чего состоит информационная система?
• Что нужно, чтобы обработать информацию?

• Процесс (англ. Process) , т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
• Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
• Хранилище данных (англ. Data store) . Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
• Поток данных (англ. Data flow) . В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

Как создавать нотации DFD

Последовательность получается такая:

1. Клиент предоставляет свои данные и заявку.
2. Менеджер проверяет и вносит полученные данные в систему.
3. Работник склада формирует документы, например, расходную накладную, и отгружает товар.
4. Клиент получает товар и пакет документов к нему.

С точки зрения DFD у нас имеются:

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

• Каждый процесс должен иметь хотя бы один вход и один выход. Смысл процессов здесь заключается в обработке данных, а потому процесс должен получить данные (входящая стрелка) и отдать куда-то после обработки (исходящая стрелка);
• Процесс обработки данных должен иметь внешнюю входящую стрелку (данные от внешней сущности). Для того, чтобы любой подобный процесс начал работать, мало использовать данные из хранилища, должна поступить новая информация для последующей обработки;
• Стрелки не могут связывать напрямую хранилища данных, все связи идут через процессы. Нет смысла просто перемещать данные из одного места в другое, а именно так читается прямая связь двух хранилищ стрелкой. Данные поступают для того, чтобы производились какие-то действия, в нашем примере – осуществлялся процесс продажи. А это возможно только посредством обработки (процесса);
• Все процессы должны быть связаны либо с другими процессами, либо с другими хранилищами данных. Процессы не существуют сами по себе, а потому результат должен куда-то передаваться;
• Декомпозиция. В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий. Например, мы можем создать процесс «создание заявки», который потом декомпозировать на последовательность действий, например, на получение заявки, отдельно – проверку и получение данных клиента, если товар в интернет-магазине продается под заказ, то также при формировании заявки потребуется получить данные от поставщика о наличии нужных наименований и т.д. И тогда на верхней диаграмме у нас будет блок «обработка заявки», а при декомпозировании мы получим диаграмму с подробной последовательностью действий на этом этапе. При этом ни на одном этапе у нас не будет условий и ветвления. Будет процесс и его декомпозиция глубиной до 3-4 уровней.

И декомпозиция основного элемента нашей диаграммы:

Где используются DFD нотации

• хранилища данных – это электронные таблицы и базы данных,
• внешние сущности – клиенты или другие базы данных, в том числе, из других программ (интеграция и обмен данными),
• процессы – это выполняемые функции и модули в системе.

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

DFD нотации – это просто!

Что в DFD-нотациях особенно удобно, здесь не обязательно придерживаться строгих правил и синтаксиса, как, например, в BPMN. Эти нотации не будут исполнимыми, они нужны для понимания особенностей документооборота, структуры и последующей работы с данными. А потому, если ваша диаграмма понятна и вам, и заказчику, какие-то отступления от стандартов DFD вполне допустимы.

Рисовать диаграммы DFD можно, в принципе, где и как вам удобнее. Но если вы хотите работать с декомпозицией, выстраивать систему на разных уровнях детализации, то «рисовалки» (Visio, Paint и тому подобные) придется забыть. Вам потребуются специализированные программы для моделирования.

Лично я пользуюсь программой ERwin и всем ее рекомендую. Одна из причин моего выбора – это особенности декомпозиции. В ERwin, как и в некоторых других подобных системах, существует возможность декомпозирования DFD-процессов в формате IDEF3, т.е. основная диаграмма будет в формате DFD, и на самом общем уровне вы будете видеть основные потоки данных и «узлы» их обработки. А при декомпозиции вы сможете использовать уже процессный подход, что также бывает очень удобно для разработки крупных систем или работе с разными подразделениями бизнеса.

Вопросы и ответы

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

Если вы - разработчик, и знаете UML, волне возможно, что даже какие-то предварительные решения вам будет удобнее создавать в этой нотации. А для бизнес-консультанта DFD всегда будет удобнее в качестве инструмента, так как бизнес-консультанту не требуется подробное описание функций с точки зрения автоматизации, это - задача технических специалистов. Зато время и силы DFD значительно экономит.

При этом не стоит рассматривать DFD как упрощенный вариант UML. Не смотря на схожесть в подходе, это - разные инструменты, предназначенные для разных целей.

Какое количество элементов может использоваться в DFD?

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

Можно ли использовать нотации DFD для работы с клиентами?

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

Основными компонентами диаграмм потоков данных являются:

Внешние сущности (External Reference);

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

Процессы;

Накопители данных (Data store);

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

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

Внешняя сущность

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

Имя сущности должно содержать существительное , например , "ОС", "Файловая система", "Пользователь", "Внешний накопитель", "Поставщик(и)", "Клиент(ы)", "Склад".

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

Поэтому это не могут быть механизмы из модели в нотации IDEF0. Особый случай составляют механизмы модели в нотации IDEF0 такие, как "Пользователь".

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

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

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

Каждая внешняя сущность идентифицируется буквой "E" и произвольным числом (одним и тем же на разных копиях сущности). Каждой внешней сущности дается текстовое описание .

Примеры сущностей с возможными текстовыми описаниями приведены в табл. 10.1.

Таблица 10.1

Примеры внешних сущностей

Система и подсистема

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

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

Процесс, действие (или работа)

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

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

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

Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

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

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

Каждому функциональному блоку дается текстовое описание .

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

Поток данных (стрелка)

Поток данных описывает движение объекта из одной части системы в другую.

В качестве источников и приемников данных для потоков могут выступать внешние сущности, процессы и накопители.

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

Ориентация стрелки показывает направление потока. Могут применяться двунаправленные стрелки для описания диалогов типа "команда-ответ". В каждом конкретном случае аналитик решает, что удобнее изобразить: двунаправленный поток или два различных потока в противоположных направлениях.

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

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

В приложении к "Техническому заданию" приводятся имена и текстовые описания потоков данных в виде словаря данных.

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

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

Структура данных — поименованная, логически связанная группа элементов и подструктур данных, хранящаяся в накопителе или передаваемая в информационном потоке. Средство для задания состава и взаимосвязи отдельных элементов данных.

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

Например, в детализируемую работу входит поток "Данные", на детализирующей диаграмме этот поток удаляют, а вместо него вводят потоки "Данные для работы с изображением", "Данные о параметрах интерфейса", "Данные об атрибутах изображения", как будто бы они переданы из детализируемой работы.

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

Накопитель (хранилище) данных

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

Накопитель изображает объект в покое в отличие от потока данных, описывающего объект в движении.

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

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

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

Накопитель данных изображается, как показано на рис. 10.3. Один накопитель может быть использован многократно на одной или нескольких диаграммах. Идентифицируется накопитель данных порядковым номером (одним и тем же на разных копиях накопителя).

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

Таблица 10.2

Примеры накопителей

Данные, которые хранятся в накопителе — это объекты предметной области и при построении модели данных они будут моделироваться в виде "сущностей" (не путать с сущностями нотации DFD).

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

Табл. 10.3 — 10.5 являются примерами таких таблиц для модели "Графический редактор (Paint)" в нотации DFD, показанной на рис. 10.4 – 10.7.

Таблица 10.3

Содержимое накопителя данных "Изображение в памяти"

Таблица 10.4

Содержимое накопителя данных "Атрибуты изображения в памяти"

Таблица 10.5

Содержимое накопителя данных "Параметры интерфейса в памяти"

Для ПО "Текстовый редактор (Блокнот из группы Стандартные ОС Windows)", в котором ведется работа с текстовым файлом и в ОП хранится содержимое текстового файла, содержимое накопителя "Открытый документ в ОП" может быть таким, как показано в табл. 10.6.

Таблица 10.6

Содержимое накопителя данных "Открытый документ в ОП"

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

Таблица 10.7

Содержимое накопителя данных "Текущий формат отображения"

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

Таблица 10.8

Содержимое накопителя данных "Варианты параметров настройки программы"

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

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов (далее в примерах используется нотация Гейна-Сэрсона).

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

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

Состав диаграмм потоков данных

Основными компонентами диаграмм потоков данных являются: внешние сущности; системы и подсистемы; процессы; накопители данных; потоки данных.

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

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

Рисунок 1. Графическое изображение внешней сущности

При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Подсистема (или система) на контекстной диаграмме изображается так, как она представлена на Рис. 2.

Рисунок 2. Подсистема по работе с физическими лицами (ГНИ - Государственная налоговая инспекция)

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

Рисунок 3. Графическое изображение процесса

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

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

Рисунок 4. Графическое изображение накопителя данных

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

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

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

Каждый поток данных имеет имя, отражающее его содержание.

Рисунок 5. Поток данных

Построение иерархии диаграмм потоков данных

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

Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

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

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

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

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

Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

Наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

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

Выполнения процессом единственной логической функции преобразования входной информации в выходную;

Возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

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

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

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

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

Логика процесса должна быть выражена четко и недвусмысленно.

При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Для каждого потока данных формируется список всех его элементов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных (например, строкам документов или объектам предметной области). Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре (например, структура "данные о страховании" для объекта "служащий"). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне (например, элемент "имя ребенка" для объекта "служащий"). Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных могут указываться единица измерения, диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.

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

При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей "AS-IS" и "AS-TO-BE", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними. При этом описание используемых в организации данных на концептуальном уровне, независимом от средств реализации базы данных, выполняется с помощью модели "сущность-связь".

Ниже перечислены основные виды и последовательность работ при построении бизнес-моделей с использованием методики Йордона:

1. Описание контекста процессов и построение начальной контекстной диаграммы.

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

2. Спецификация структур данных.

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

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

4. Построение диаграмм потоков данных нулевого и последующих уровней.

Для завершения анализа функционального аспекта деятельности организации детализируется (декомпозируется) начальная контекстная диаграмма.

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

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

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

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

5. Уточнение концептуальной модели данных.

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

Общая концепция

Метод моделирования процессов - потоков данных (DFD)

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

Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Пример . Америка 20-е годы. Консультант офиса обозначил кружком каждого клерка, а стрелкой – каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой два клерка, обменивающихся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии друг от друга. Так появился первый прототип DFD.

Для построения DFD используют две различные нотации, соответствующие методам Йордана и Гейна – Серсона. Далее в примерах будет использоваться более популярная сегодня нотация Гейна – Серсона.

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

Основными компонентами диаграмм потоков данных являются:

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

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

3. Процессы.

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

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

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

Системы и подсистемы являются элементами верхнего уровня декомпозиции и отображаются на контекстных диаграммах в виде единого целого.

Системы и подсистемы декомпозируются на процессы – компоненты диаграмм, предназначенные для преобразования входных потоков данных в выходные в соответствии с определённым алгоритмом.

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

Использование на диаграммах таких глаголов, как «обработать», «модернизировать» или «отредактировать», означает недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

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

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

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

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

На диаграмме поток данных изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее её содержание.

При построении DFD-диаграмм принято пользоваться следующими рекомендациями:

1.Размещать на каждой диаграмме от 3 до 6÷7 процессов.

3. Стараться не использовать аббревиатуры.

4. Не загромождать диаграммы несущественными деталями.

9.3. Диаграммы «сущность-связь»

Нотация ERD для построения диаграмм «сущность-связь» включает девать основных компонентов.

Чаще всего информационные модели подобного типа применяются для проектирования структуры базы данных.