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

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

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

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

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

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

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

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

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

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

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

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

1. процесс имеет два-три входных и выходных потока;
2. процесс может быть описан в виде преобразования входных данных в выходные;
3. процесс может быть описан в виде последовательного алгоритма .

Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные.

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

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

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

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

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

Материал из ПИЭ.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 строк).

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

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

Задание 1. Общие сведения

Ознакомьтесь с изложенными ниже общими сведениями.

Общие сведения

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

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

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

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

• внешние сущности;
• системы и подсистемы;
• процессы;
• накопители данных;
• потоки данных.

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

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

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

Для этого целесообразно:

• размещать на каждой диаграмме от 3 до 7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один процесс или два;
• не загромождать диаграммы не существенными на данном уровне деталями;
• декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой;
• выбирать понятные имена процессов и потоков, не использовать аббревиатуры.

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

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

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

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

Для сложных систем строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит набор подсистем, соединенных потоками данных.

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

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

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

При детализации процессов нужно выполнять следующие правила:

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

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

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

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

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

Спецификации должны удовлетворять следующим требованиям:

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

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

Задание 2. Знакомство с компонентами диаграммы потоков данных (DFD) в BPwin

Ознакомьтесь с результатом использования DFD для описания процесса отгрузки горючего (рис.1 ).

На диаграмме продемонстрированы процессы, преобразующие входные данные в выходные.

Рис.2. Изображение процесса

• потоки данных. Изображаются в виде стрелок (рис.3 ), входящих и исходящих в блоки процессов и других компонентов диаграммы. Стрелки имеют название, описывающее вид информации на входе или выходе какого-то из процессов. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику:

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

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

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

• накопитель данных - это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопи­тель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т. д. Накопитель данных на диаграмме потоков данных идентифицируется буквой D (рис. 5 ) и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных является прообразом будущей базы данных, и описание, хранящихся в нем данных должно быть увязано с информационной моделью (ERD). Накопители данных - хранилища информации, к которым можно обратиться за данными, или куда можно поместить преобразованные данные. Изображаются в виде прямоугольника с двойной чертой:

Рис. 6. Выбор типа диаграммы

В появившемся диалоговом окне (рис. 6 ) поставьте переключатель в положение DFD. Задайте имя модели в поле Name. В появившемся окне на вкладке General задайте имя автора Author.

• Внимательно рассмотрите панель инструментов и рис. 7. Ознакомьтесь с инструментами создания диаграммы потоков данных.

Рис. 7. Панель инструментов среды BPwin для создания диаграмм.

Задание 4. Создание компонентов контекстной диаграммы.

• Ознакомьтесь с описанием задачи.

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

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

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

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

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

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

Используя панель инструментов (рис.7 ), создайте контекстную DFD диаграмму, моделирующую потоки данных поликлиники, следуя (рис. 8 ).

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

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

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

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

Рис. 9. Окно свойств процесса

Укажите на вкладке Fonts

Рис. 10. Задание шрифта

Полученное изображение процесса можно перемещать, изменять его размер

• Добавьте на контекстную диаграмму внешние сущности: Пациент, Врач, Администрация больницы, выбирая последовательно инструмент External ReferenceTool (Сущность рис. 7 ).
• Задайте имена сущностям, используя контекстное меню и соответствующую вкладку появившегося окна.
• Добавьте на контекстную диаграмму потоки данных. Стрелки создаются инструментом с изображением горизонтальной стрелки Precedence Arrow Tool.

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

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

Задание 5. Декомпозиция контекстной диаграммы

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

• Перейдите на следующий уровень декомпозиции, щелкнув по кнопке "Переход к дочернему уровню" (рис. 7 ).
• Задайте количество подпроцессов на листе декомпозиции – 3. Назовите их, как указано на рис. 11 .
• Продлите стрелки, перешедшие с контекстной диаграммы до нужного процесса (рис. 11 ). Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.

Название накопителя	Атрибуты	Откуда поступает информация	Куда передается

Описать данные, которые могут быть представлены для отчетов:

Данные о принятых за день пациентах; История болезни пациента.

Задание 8. Анализ информационных процессов при снятии денег со счета в банке.

Создать контекстную диаграмму (DFD). Придумать ей название.

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

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

• клиент вставляет свою карточку в банкомат;
• банкомат выдает приветствие и предлагает клиенту ввести свой персональный идентификационный номер;
• клиент вводит номер;
• банкомат выводит список доступных действий:
  • снять деньги со счета;
  • проверить счет;
• клиент выбирает пункт "Снять деньги";
• банкомат запрашивает, сколько денег нужно снять;
• Клиент вводит требуемую сумму;
• банкомат определяет, достаточно ли на счету денег;
• банкомат вычитает требуемую сумму из счета клиента;
• банкомат выдает клиенту требуемую сумму наличными;

Задание 9. Декомпозиция контекстной диаграммы.

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

Задание 10. Альтернативные процессы.

Измените созданную диаграмму с учетом следующих условий:

банкомат подтверждает введенный клиентом номер. Если номер не подтверждается, выполняется альтернативный поток событий.

Ввод неправильного идентификационного номера:

• клиент получает информацию о том, что введен неправильный пин-код;
• банкомат возвращает клиенту его карточку.

Если денег на счету меньше суммы, затребованной клиентом, то выполняется следующий поток событий:

Сумма на счету меньше требуемой:

• банкомат информирует клиента, что денег на его счету недостаточно;
• банкомат возвращает клиенту его карточку.

Контрольные вопросы

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

Версия для печати

Тема 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.

Основой данной методологии графического моделирования информационных систем является специальная технология построения диаграмм потоков данных DFD. В разработке методологии DFD приняли участие многие аналитики, среди которых следует отметить Э. Йордона (Е. Yourdon). Он является автором одной из первых графических нотаций DFD . В настоящее время наиболее распространенной является так называемая нотация Гейна-Сарсона (Gene-Sarson), основные элементы которой будут рассмотрены в этом разделе.

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

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

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

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

Процессы

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

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

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

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

Рис. 2.15. Изображение внешней сущности на диаграмме потоков данных

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

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

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

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

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

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

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

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

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

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

Рис. 2.19. Пример диаграммы DFD для процесса получения некоторой суммы наличными по кредитной карточке