Для чего строится dfd модель as is что она показывает

Берримор, ты потерял рецепт овсянки? Не беда, нам поможет DFD!

— Это что… мясо, по-вашему?

— Овсянка, сэр… Маленькая птица… отряда воробьиных.

Вступление

Мы познакомились с двумя нотациями функционального моделирования:

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

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

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

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

Правильно построенная диаграмма в методологии DFD даст ответы на такие вопросы как:

Немного истории

Диаграммы потоков данных известны очень давно и были предложены Лари Константином в 70-е гг. ХХ века. Однако, есть еще более раннее их упоминание, относящееся к 1920-м гг. Так, в литературе упоминается возможное использования диаграммы для оптимизации пространства в офисе для работы клерков. При осуществлении реорганизации специалист обозначил кружком каждого клерка, а стрелкой – каждый документ, передаваемый между ними. Нарисовав таким образом диаграмму, он предложил схему оптимизации, в соответствии с которой клерки, осуществляющие максимальную передачу документов между собой, были посажены рядом, а клерки с небольшим взаимодействием – на большом расстоянии.

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

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

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

Логическая и физическая DFD

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

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

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

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

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

Таким образом, любая диаграмма потока данных (DFD) отображает поток информации для процесса или системы, тогда как логическая диаграмма предоставляет «что» происходит, а физическая – «как» это происходит. Это две разные точки зрения на один и тот же поток данных, каждая из которых предназначена для визуализации и уточнения системы.

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

Рассмотрим оба варианта.

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

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

Физическая DFD смотрит на то, как реализована система.

Использование DFD

Применение методологии DFD очень разнообразно:

Логический DFD «as is» фиксирует текущие и необходимые действия, требуемые для процесса. Логический DFD «to be» моделирует новый набор действий и функций.

Физический DFD «as is» отображает текущее программное обеспечение, оборудование, базы данных и людей для выполнения действий, тогда как физический DFD «to be» моделирует новую реализацию системы.

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

В области анализа так же применимы и логические, так и физические DFD.

Логический DFD помогает выявить бизнес-требования, которые могли бы остаться незамеченными. Это повлекло бы пересмотр и перемоделирование системы в целом и срыву оговоренных сроков исполнения. Модель, представленная в методологии DFD, наглядно продемонстрирует и «нетехническим» специалистам проблемные места в работе системы и возможные способы оптимизации. Т.е. станет неким инструментом коммуникации, который позволит найти проблемы и выразить ее в доступным всем заинтересованным лицам языке.

Далее построение физического DFD покажет информационной системе «как» управлять полученными требованиями.

DFD и другие нотации моделирования процессов

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

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

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

Нотации и элементы, используемые при DFD-моделировании

Диаграммы потоков данных стали известны широкой публике с конца 1970-х годов благодаря книге «Структурное проектирование» пионеров вычислительной техники Эда Йордана и Ларри Константина («Structured Design» Yourdon & Constantine, 1974).

Наиболее распространенные нотации (системы символов):

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

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

Источник

Для чего строится dfd модель as is что она показывает

6.8. Назначение и состав DFD

При построении функциональной модели системы альтернативой методологии IDEF0 является методология диаграмм потоков данных (Data Flow Diagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели «TO-BE».

Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko). В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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

6.9. Элементы графической нотации DFD

Согласно DFD источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации [17, 19].

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

Таблица 6.1. Элементы графической нотации DFD

Далее в примерах будет использоваться нотация Гейна-Сарсона.

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

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

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

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

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

— «Ввести сведения о клиентах»;

— «Рассчитать допускаемую скорость»;

— «Сформировать ведомость допускаемых скоростей»

Номер процесса служит для его идентификации и ставится с учетом декомпозиции. В отличие от IDEF0 вложенность процессов обозначается через точку (например, в IDEF0 – «236», в DFD – «2.3.6»).

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

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

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

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

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

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

6.10. Правила и рекомендации построения DFD

Правила и рекомендации построения модели DFD в основном совпадают с принятыми в IDEF0. Часть из них приведена в подразд. 6.9.

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

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

Наличие только выходящих потоков из накопителя также является ошибкой. Прежде чем использовать данные из накопителя, они должны там появиться в результате работы какого-либо процесса (подсистемы, внешней сущности). Исключением из правил считается случай, когда накопитель является внешней сущностью. Тогда допускается наличие либо только входящих стрелок, либо только выходящих стрелок (см. рис. 6.23, накопитель «БД АРМ-П или СБД-П»).

6.11. Пример построения модели DFD для системы определения допускаемых скоростей

Описание задачи приведено в подразд. 6.6.

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

Рис. 6.23. Контекстная диаграмма системы определения допускаемых скоростей (методология DFD)

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

В то же время в системе оставлена возможность ее ручного ввода и корректировки. Несмотря на то, что БД АРМ-П или СБД-П по отношению к системе являются внешними сущностями, они, в целях лучшего восприятия, показаны в виде накопителя данных.

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

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

Рис. 6.24. Диаграмма декомпозиции первого уровня (методология DFD)

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

При построении диаграммы декомпозиции блоки системы в одних случаях показаны как процессы (имя начинается с глагола), в других – как подсистемы (имя начинается со слова «подсистема»). Это сделано в целях иллюстрации правил именования блоков. В то же время декомпозицию системы можно было бы представить, либо используя только процессы, либо только подсистемы.

Контекстная диаграмма и диаграмма декомпозиции выполнены с использованием BPwin 4.0.

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

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

— возможности описания процессов в виде простого алгоритма;

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

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

6.12. Расширения DFD для систем реального времени

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

Квазинепрерывный поток (лат. quasi – как будто, якобы) – поток данных, непрерывный во времени. Отображается линией с двумя стрелками на конце.

Рис. 6.25. Квазинепрерывный поток

Управляющий процесс – процесс, формирующий сигналы управления на выходе.

Рис. 6.26. Управляющий процесс

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

Рис. 6.27. Управляющий поток

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

Накопитель управлений – накопитель управляющих потоков.

Рис. 6.28. Накопитель управления

На рис. 6.29 показан пример использования новых элементов на DFD.

Рис. 6.29. Фрагмент DFD системы реального времени

Вопросы для самопроверки

2. Дайте краткую характеристику моделей AS-IS, «TO-BE» и «SHOULD-BE».

13. Перечислите отличия методологии IDEF0 от DFD.

Источник

Для чего строится dfd модель as is что она показывает

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

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

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

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

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

[Грошев А. Основы работы с базами данных: http://www.intuit.ru/studies/courses/93/93/info]

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

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

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

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

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

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

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

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

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

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

Процесс на диаграмме потоков данных изображается, как показано на Рис. 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Базы данных: Учебник для высших учебных заведений /Под ред. проф. А.Д. Хомоненко. – Спб.: КОРОНА принт, 2000. –416с. Стр. 147–161.]

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

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

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

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

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

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

[Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник / Под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2002.]

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

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

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

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

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

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

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

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

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

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

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

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

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

Определяются атрибуты сущностей. Выделяются атрибуты-идентификаторы. Проверяются связи, выделяются (при необходимости) связи «супертип-подтип».

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

Источник