Построение диаграмм потоков данных dfd. Методологии моделирования предметной области

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

DFD - общепринятое сокращение от англ. Data Flow Diagrams - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD)(Рис.2.1.) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Рис.2.1. Диаграмма потоков данных.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.

Нотация DFD - удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы - диаграмма SADT, диаграмма Диаграмма вариантов использования.

Для решения задачи функционального моделирования на базе структурного анализа традиционно применяются два типа моделей: IDEF0-диаграммы и диаграммы потоков данных.

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

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

Диаграммы потоков данных (Data flow diagramming, DFD):

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

· создаются для моделирования существующего процесса движения информации;

· используются для описания документооборота, обработки информации;

· применяются как дополнение к модели IDEFO для более наглядного отображения текущих операций документооборота (обмена информацией);

· обеспечивают проведение анализа и определения основных направлений реинжиниринга ИС.

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

В случае наличия в моделируемой системе программной/программируемой части (практически всегда) предпочтение, как правило, отдается DFD по следующим соображениям.

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

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

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

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

· функции процесса;

· входящая и исходящая информация, при описании документов;

· внешние бизнес-процессы, описанные на других диаграммах;

· точки разрыва при переходе процесса на другие страницы.

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

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

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

· Диаграмм потоков данных.

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

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

Миниспецификация.

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

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

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

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

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

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

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

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

Основные символы DFD-диаграмм по этим нотациям:

Рис. 3.1. Основные символы DFD-диаграмм

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

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

В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием (реинжинирингом процессов). Этому способствует также тесная связь IDEF0 с методом функционально - стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель.

2.2.4.3. Терминология DFD-нотации .

DFD-БЛОКИ – графическое изображение операции (процесса, функции, работы) по обработке или преобразованию информации (данных). Смысл DFD-блока, отображающего функцию совпадает со смыслом блоков IDEFO и IDEF3, заключающиеся в преобразовании входов в выходы. DFD-блоки также имеют входы и выходы, но не поддерживают управление и механизмы, как IDEFO.

Назначение функции состоит в создании из входных потоков выходных в соответствии с действием, определяемым именем процесса. Поэтому имя функции должно содержать глагол в неопределенной форме с последующим дополнением. Функции обычно именуются по названию системы, например "Разработка системы автоматизированного проектирования"". Рекомендуется использовать глаголы, отображающие динамические отношения, например: «рассчитать», «получить», «заказать», «фрезеровать», «точить», «вычислить», «включить», «моделировать» и т.д. Если автор использует такие глаголы, как “обработать”, “модернизировать”, или “отредактировать”, то это означает, что он, вероятно, пока недостаточно глубоко понимает данную функцию процесса и требуется дальнейший анализ.

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

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

DATA FLOW (поток данных) – механизм, использующийся для моделирования передачи информации между участниками процесса информационного обмена (функциями, хранилищами данных, внешними ссылками). По нотации Гейн-Сарсона поток данных (документы, объекты, сотрудники, отделы или иные участники обработки информации) изображается стрелкой между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной, причем направление стрелки указывает направление потока. Каждая стрелка должна иметь источник и цель. В отличие от стрелок IDEF0-диаграммы (ICOM), стрелки DFD могут входить или выходить из любой стороны блока.

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

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

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

DATA FLOW ДИАГРАММА (DFD-диаграмма) (Рис.4.1.)– диаграммы применяемые для графического представления (flowchart) движения и обработки информации в организации или в каком-либо процессе. Обычно диаграммы этого типа используются для проведения анализа организации информационных потоков и для разработки ИС. DFD-диаграммы являются ключевой частью документа спецификации требований - графическими иерархическими спецификациями, описывающими систему с позиций потоков данных. Каждый узел-процесс в DFD может развертываться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей. Рис.4.1. Пример DFD- диаграммы потоков данных.

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

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

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

Рис.4.2. Хранилище данных.

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

в материальных системах - там, где объекты ожидают обработки, например в очереди;

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

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

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

EXTERNAL REFERENCE (внешняя ссылка, внешняя сущность, external entities) (Рис.4.3.)– объект диаграммы потоков данных, являющийся источником или приемником информации извне модели. Внешние ссылки/сущности изображают входы и/или выходы, т.е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы. Внешними ссылками системы обычно являются логические классы предметов или людей, представляющие собой источник или приемник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т.д. Это могут быть специфические источники, такие, как бухгалтерия, информационно-поисковая система, служба нормоконтроля, склад. Если рассматриваемая система принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешней системы. Без объекта «внешняя сущность» аналитику бывает иногда сложно определить, откуда пришла в компанию данные документы. Или какие документы еще приходят от, такой внешней сущности как, например, "клиент".

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

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

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

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

· функции преобразуют входящие потоки данных в выходящие;

· хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов;

· преобразования потоков данных во внешних ссылках игнорируется.

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

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

Построение диаграмм.

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEFO:

· строится физическая модель, отображающая текущее состояние дел;

· полученная модель преобразуется в логическую модель, которая отображает требования к существующей системе;

· строится модель, отображающая требования к будущей системе;

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

Альтернативным подходом является подход, применяемый при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы:

· логическая модель строится как совокупность процессов и документирования того, что эти процессы должны делать;

· с помощью модели окружения система описывается как взаимодействующий с событиями из внешних сущностей объект. Модель окружения (environment model) обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один блок, изображающий систему в целом, внешние сущности, с которыми система взаимодействует, ссылки и некоторые стрелки, импортированные из диаграмм IDEF0 и DFD. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему;

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

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

Пример DFD-диаграмм по нотации Гейна-Сарсона для предприятия, строящего свою деятельность по принципу "изготовление на заказ" приведен на рисунке 5.1.

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

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

Рис.5.1. Пример DFD-диаграмм по нотации Гейна-Сарсона для предприятия

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

К преимуществам методики DFD относятся:

· возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

· возможность проектирования сверху вниз, что облегчает построение модели "как должно быть";

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

К недостаткам модели отнесем:

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

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

Список литературы:

1. Андрейчиков А. В. Андрейчикова О. Н. Интелектуальные информационные системы Изд. «Финансы и статистика» г.Москва 2004г. 422с.

2. Анисимов Б.П., Котов В.В. «Современные методологии структурного анализа и проектирования систем обработки информации» журнал "Программные продукты и системы" № 2 за 1997 год.[ 24.06.1997 ]

3. Козленко Л. «Проектирование информационных систем. Часть 1. Этапы разработки проекта: стратегия и анализ» журнал КомпьютерПресс, 9"2001г.

4. Марка Д.А. МакГоуэк К. SADT-методология структурного анализа и проектирования изд. Метатехнология, М. 1993г.

5. Вендров А.М. CASE-технологии современные методы и средства проектирования и систем изд. Финансы и статистика М. 1998г.

Интернет ресурсы:

http://www.aiportal.ru/

http://www.itstan.ru/

http://www.intuit.ru/

SADT-тенология

Введение

SADT (Structured Analysis and Design Technique) - одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Россом (Ross). SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем. управление финансами и материально-техническим снабжением и др. Данная методология широко поддерживается Министерством обороны США. которое было инициатором разработки стандарта IDEF0 как подмножества SADT. Это, наряду с растущей автоматизированной поддержкой, сделало ее более доступной и простой в употреблении.

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

SADT-диаграммы

Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом чем выше уровень диаграммы, тем она менее детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. SADT требует, чтобы в диаграмме было 3-6 блоков: в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используются несколько небольших взаимосвязанных моделей, значения которых взаимодополняют друг друга, делая понятной структуризацию сложного объекта. Однако такое жесткое требование на число блоков на диаграмме ограничивает применение SADT для ряда предметных областей. Например, в банковских структурах имеется 15-20 равноправных деятельностей, которые целесообразно отразить на одной диаграмме. Искусственное их растаскивание по разным уровням SADT-модели явно не улучшает ее понимаемость.

Структура блоков

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

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

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

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

Взаимосвязи

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

Рассмотрим построение DFD модели информационной системы для сети магазинов по продажам сумок. Дополним диаграмму IDEF0, построенную в лабораторной работе № 1 DFD-диаграммой. Построим DFD-диаграмму для функции A4 «Анализировать работу» См. рис. 4.

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

Задание

1. Изучить метод DFD.
2. Дополнить функциональную модель информационной системы, построенную в лабораторной работе № 1, диаграммой потоков данных, для тех функциональных блоков IDEF0 модели, для которых требуется показать движение данных.
3. Ответить на контрольные вопросы.
4. Оформить отчет (Титульный лист, задание, DFD диаграмма)

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

1. Какие процессы в системе описываются с помощью диаграмм потоков данных?
2. Какие основные объекты диаграмм потоков данных?
3. Используется ли принцип декомпозиции при построении DFD диаграмм?
4. Место подхода стрелки к блокам или место выхода стрелки из блока может быть произвольным или подчиняется определенным правилам?
5. Каким образом происходит выделение объекта во внешнюю сущность?

Литература

1. Федотова, Д.Э. CASE-технологии: Практикум/ Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик. - М.: Горячая линия – Телеком, 2005. - 160 с.: ил.
2. Калашян, А.Н. Структурные модели бизнеса: DFD-технологии/ А.Н. Калашян, Г.Н. Калянов. - М.: Финансы и статистика, 2003.
3. DFD -диаграммы потоков данных. - http://www.proinfotech.ru/dmdlr2.htm.
4. Методы моделирования бизнесс-процессов. - http://www.jetinfo.ru/2004/10/1/article1.10.2004153.html.

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

Цель работы:

• построить диаграмму декомпозиции в нотации DFD одной из работ диаграмм IDEF0, построенных в предыдущих лабораторных работах

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

Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

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

Рисунок 1. Работа в DFD

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

Рисунок 2. Внешняя сущность в DFD

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

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

Рисунок 3. Хранилище данных в DFD

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

• удалить все граничные стрелки на диаграмме DFD;
• создать соответствующие внешние сущности и хранилища данных;
• создать внутренние стрелки, начинающиеся с внешних сущностей вместо граничных стрелок;
• стрелки на диаграмме IDEF0 затоннелировать

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

Построение диаграммы декомпозиции. Проведем декомпозицию работы Отгрузка и снабжение диаграммы А0 "Деятельность предприятия по сборке и продаже компьютеров и ноутбуков". В этой работе мы выделили следующие дочерние работы:

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

Выделим работу Отгрузка и снабжение диаграммы А0 "Деятельность предприятия по сборке и продаже компьютеров и ноутбуков", нажмем на кнопку "GotoChildDiagram" панели инструментов и выберем нотацию DFD. При создании дочерней диаграммы BPWin переносит граничные стрелки родительской работы, их необходимо удалить и заменить на внешние сущности. Стрелки механизмов, стрелки управления "Правила и процедуры", "Управляющая информация" и стрелку выхода "Отчеты" на дочерней диаграмме задействованы не будут, чтоб не загромождать диаграмму менее существенными деталями. Остальные стрелки заменим на внешние сущности - кнопка "ExternalReferenceTool" на панели инструментов, в появившемся окне выбрать переключатель "Arrow" и выбрать из списка нужное название (рис. 4):

Рисунок 4. Добавление внешней сущности

Рисунок 5. Работы и внешние сущности

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

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

Рисунок 6. Итоговая диаграмма декомпозиции

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

Работа "Хранение комплектующих и собранных компьютеров" работает с информацией о получаемых и выдаваемых комплектующих и собранных компьютеров, поэтому стрелки, соединяющая работу с хранилищами данных "Список комплектующих" и "Список собранных компьютеров" двунаправленные. Также эта работа при получении комплектующих должна делать отметку о том, что заказ поставщикам выполнен. Для этого она связана с хранилищем данных "Список заказов" однонаправленной стрелкой. Обратите внимание, что на DFD диаграммах одно и тоже хранилище данных может дублироваться.

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

Последним действием необходимо стрелки родительской работы затуннелировать (рис. 7):

Рисунок 7. Диаграмма IDEF0 с затуннелированными стрелками работы "Отгрузка и снабжение"

• краткое описание декомпозируемой работы
• диаграмма декомпозиции

Пример DFD-диаграммы процесса «Составление технологического задания» средствами Bpwin

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

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

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

Для построения ЭГО-диаграмм используются две различные нотации, соответствующие методам Иордана и Гейна-Сэрсона, которые незначительно отличаются графическими изображениями символов. Далее при построении примеров будет использоваться нотация Гейна-Сэрсона. Построение БРЭ-диаграмм в основном ассоциируется с разработкой программных систем, и нотация ЭРЭ изначально была разработана для этих целей.

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

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

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

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

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

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

ной системы как единого целого либо может быть декомпозирована на несколько подсистем (рис. 5.13).

Рис. 5.12.

Идентификатор

Поленомера

Полеимени Поле

физической

реализации

Рис. 5.13. Контекстная диаграмма

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

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

Поле номера

Поле имени Поле

физической

реализации

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

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

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

идентификации

Поле имени

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

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

Сформировать отчетность по подоходному налогу

отчетности

Отчетность по

подоходном у налогу

Рис. 5.16.

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

Записать адрес налогоплательщика

Отдел учета налогоплательщиков

Рис. 5.17.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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