Главная » Персонал » Состав диаграмм потоков данных. Методологии моделирования предметной области Диаграмме информационные потоки равномерно

Состав диаграмм потоков данных. Методологии моделирования предметной области Диаграмме информационные потоки равномерно

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

Общие положения. 1

Модель DFD.. 3

Виды DFD нотаций.. 3

Структура DFD модели.. 4

Основные элементы DFD и их назначение. 6

Выводы: 11

Общие положения

Существует легенда о том, как появились DFD.

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

Пример DFD диаграммы показан на схеме (Рис. 87).

Рис. 87. Пример DFD диаграммы

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

При проведении проекта создания ИС нотация DFD может использоваться в качестве основной нотации функционального моделирования, однако, часто она применяется как дополнительная по отношению к IDEF0 (Рис. 88).

Информационные сети" href="/text/category/informatcionnie_seti/" rel="bookmark">обработки информации . В отличие от IDEF0, где система рассматривается как взаимосвязанные функциональные блоки, а дуги представляют собой жесткие взаимосвязи, стрелки в DFD показывают лишь то, как объекты (включая данные) движутся от одной работы к другой. DFD отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных.

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

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

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

Модель DFD

Виды DFD нотаций

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

Так как DFD не является стандартом, на настоящее время нет единой нотации со своими однозначно определенными примитивами. Для представления моделей применяются ряд различных нотаций DFD. Наибольшее распространение среди них получили нотации Гейна-Сарсона и Йодана/де Марко (Рис. 89). Помимо этих нотаций имеются и другие. Например, нотация применяемая в CA BPwin имеет свои особенности.

Рис. 89. Наиболее распространенные нотации DFD

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

Структура DFD модели

Иерархия DF диаграмм показана на схеме (Рис. 90).

Колл" href="/text/category/koll/" rel="bookmark">коллективы разработчиков.

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

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

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

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

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

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

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

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

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

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

Основные элементы DFD и их назначение

Синтаксис DFD включает четыре основных элемента:

– поток данных;

– процесс;

– хранилище;

– внешняя сущность.

Рассмотрим эти элементы подробнее.

Поток данных

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

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

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

В отличие от дуг в IDEF0 потоки данных в DFD могут быть не только однонаправленными, но и двунаправленными.

Процесс

ОПР .: Процесс преобразует значения данных.

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

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

Как уже говорилось ранее из-за отсутствия единого стандарта, объекты DFD могут иметь разное обозначение (Рис. 92).

Особо следует подчеркнуть, что в отличие от SADT, в DFD все стороны блока равнозначны (это очевидно, если посмотреть на обозначение процесса в нотации Йодана/де Марко). Другими словами, в отличие от IDEF0 диаграмм, в DFD диаграммах не используются стрелки управления для обозначения правил выполнения действия и стрелки механизмов для обозначения требуемых ресурсов.

Базы данных" href="/text/category/bazi_dannih/" rel="bookmark">базы данных информационной системы организации.

ОПР . 2: ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

На диаграмме хранилище обозначаются как показано на схеме (Рис. 93).

https://pandia.ru/text/80/146/images/image009_14.gif" width="555" height="183 src=">

Рис. 94. Обозначение внешней сущности в разных нотациях DFD

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

https://pandia.ru/text/80/146/images/image011_14.gif" width="567" height="394 src=">

Рис. 96. Пример DFD диаграммы

Выводы:

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

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

Серьезными недостатками DFD является то, что:

– во-первых, выразительная сила нотации DFD оказывается недостаточной при анализе модели, выявлении «узких мест», поиске путей усовершенствования и т. д.;

– во-вторых, DFD методологией не является, что приводит к возможности неоднозначной трактовки результатов моделирования.

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

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

Учитывая то, что тенденции IT-ранка однозначно показывают тупиковость пути «лоскутной автоматизации» и необходимость отхода от самописных систем, становится очевидным, почему в деятельности консалтинговых компаний резко сокращается применение нотации DFD и, наоборот, резко возрастает популярность IDEF0.

Диаграммы потоков данных (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 для построения диаграмм «сущность-связь» включает девать основных компонентов.

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

Материал из ПИЭ.Wiki

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

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

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

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

процессы;

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

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

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

Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации. В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие. К сожалению, DFD методология не оформлена как стандарт. По этой причине в диаграммах потоков данных используются различные условные обозначения. На рисунке 1 показаны символы внешних сущностей, используемые в нотациях «Yourdon and Coad Process Notation» и «Gane and Sarson Process Notation».

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

Процессы

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

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

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

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

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

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

В DFD используются следующие типы объектов: · работа (activity) - синоним работе в IDEF0 и IDEF3; · внешняя сущность (external entity) - объекты - источники/получатели информации/данных, изменяемых или используемых в данной функции. · стрелка (data flow) - обозначение потока информации (данных); · data store (хранилище данных) - любой механизм или абстракция (например, запись в базе данных), в которой хранятся данные. Потоки данных между работами в DFD возможны не только опосредованно, через хранилища данных, но и непосредственно между работами, если данные не поступают сначала в хранилище. Нотации IDEF0, IDEF3 и DFD могут быть последовательно использованы при все более и более глубокой проработке модели организации, завершающим этапом которой может быть детальное описание бизнес-процессов и информационной системы организации

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

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

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

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

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

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

Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или миниспецификации. При детализации должны выполняться следующие правила: правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме; правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев: наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); возможности описания преобразования данных процессом в виде последовательного алгоритма; выполнения процессом единственной логической функции преобразования входной информации в выходную; возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

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

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

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

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

Процессы;

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 10.1

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

Название сущности	Описание
Пользователь	Человек, использующий данную систему (данное ПО)
	Операционная система (MS Windows), предоставляет: настройки интерфейса ОС, такие как параметры принтера, размер, стиль, цвет шрифта, цвет фона и т.д.; разрешения на действия с файлом; текущие дату и время
Логические и/или физические диски	Предоставляют (предоставляет) пользователю список файлов и папок, хранящихся на компьютере, а также дают (дает) возможность для записи и хранения новых данных
Файловая система
	Внешнее хранилище, позволяющее сохранять в себе произвольную информацию с возможностью последующего ее извлечения
Внешний накопитель	Жесткий диск, дискета, CD-ROM, сетевой диск и т.д.

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

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

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

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

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

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

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

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

Системы, подсистемы, процессы, действия (или работы) изображаются одинаково: прямоугольниками со скругленными углами — функциональными блоками (рис. 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

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

Название поля		Описание
Имя файла	Текстовый
Кодировка цвета	Числовой, целый	Код кодировки
Содержимое	Текстовый	Содержимое графического файла — информация о наборе пикселей, составляющих изображение Размер изображения в памяти зависит от ширины и высоты рисунка. Максимальный размер изображения: 99999*99999 пикселей

Таблица 10.4

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

Название полей		Описание
Ширина картинки	Числовой, целый	Поле хранит ширину картинки в пикселях (max 99999)
Высота картинки	Числовой, целый	Поле хранит высоту картинки в пикселях (max 99999)
Вид палитры	Логический	Цветная или черно-белая (1/0)
Единицы измерения	Логический	Сантиметр, дюйм, точка

Таблица 10.5

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

Название полей		Описание
Ширина рабочего окна	Числовой, целый	Поле хранит ширину рабочего окна в пикселях (max 1600)
Высота рабочего окна	Числовой, целый	Поле хранит высоту рабочего окна в пикселях (max 1200)
Набор инструментов	Логический	Показать/Скрыть (1/0)
	Логический	Показать/Скрыть (1/0)
Строка состояния	Логический	Показать/Скрыть (1/0)
Панель атрибутов текста	Логический	Показать/Скрыть (1/0)

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

Таблица 10.6

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

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

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

Таблица 10.7

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

Название поля		Описание
Название шрифта	Текстовый	Название одного из возможных шрифтов, например, Times New Roman
Начертание шрифта	Текстовый	Название одного из возможных начертаний, например, курсив, полужирный
Размер шрифта	Числовой, целый	Значение, соответствующее одному из возможных размеров шрифта
Перенос текста	Логический	1 — перенос включен, 0 — отключен

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

Таблица 10.8

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

Название полей			Описание
Название параметра	Текстовый		Поле хранит название параметра
Список возможных значений этого параметра	Массив числовой, целый (или Массив логический, или Массив строк)	4 байта (или 1 бит, или размер одной строки) * кол-во вариантов значений	Поле хранит список значений параметра
И так по каждому параметру, хранимому в накопителе данных