Что описывает диаграмма dfd
DFD и WorkFlow (IDEF3)
Дополнение моделей процессов диаграммами DFD и WorkFlow (IDEF3)
Цель работы:
Диаграммы потоков данных
Эти диаграммы представляют сеть связанных между собой работ. Их удобно использовать для описания документооборота и обработки информации.
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или физических компонентов) из одной части системы в другую. Потоки изображаются на диаграмме именованными стрелками, ориентация которых указывает направление движения информации. Стрелки могут подходить к любой грани прямоугольника работы и могут быть двунаправленными для описания взаимодействия типа •« команда-ответ ».
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое. В случае, когда поток данных входит в хранилище или выходит из него и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником данных системы. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах.
Рис. 3.1. Внешняя сущность
Для дополнения модели ID ЕГО диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count указать тип диаграммы DFD.
Диаграммы IDEF3
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEFO и содержит все необходимое для построения моделей, которые могут быть использованы для имитационного моделирования.
Диаграммы
Диаграмма является основной единицей описания в IDEF3-модели. Организация диаграмм в IDEF3 является наиболее важной, если модель редактируется несколькими людьми. В этом случае разработчик должен определять, какая информация будет входить в ту или иную модель.
Связи
Показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными.
Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fanout Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.
Типы перекрестков
| Обозначение | Наименование | Смысл в случае слияния стрелок | Смысл в случае разветвления стрелок |
 | Asynchronous AND | Все предшествующие процессы должны быть завершены | Все следующие процессы должны быть запущены |
 | Synchronous AND | Все предшествующие процессы завершены одновременно | Все следующие процессы запускаются одновременно |
 | Asynchronous OR | Один или несколько предшествующих процессов должны быть завершены | Один или несколько следующих процессов должны быть запущены |
 | Synchronous OR | Один или несколько предшествующих процессов завершены одновременно | Один или несколько следующих процессов запускаются одновременно |
 | XOR(Exclusive OR) | Только один процесс завершен | Только один следующий процесс запускается |
Для внесения объекта-ссылки служит кнопка Объект-ссылки отображается в виде прямоугольника. Объекты-ссылка должны быть связаны с единицами работ или перекрестками пунктирными линиями.
При внесении объектов-ссылок необходимо указать их тип.
Типы объектов-ссылок
Тип объекта-ссылки
Цель описания
Описывает участие важного объекта в работе
Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток
UQB (Unit of behavior)
Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовления изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ
Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму
Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках
Пример
Диаграммы DFD
Диаграммы DFD можно использовать как дополнение к диаграммам IDEFO для описания документооборота и обработки информации.
Диаграммы IDEF3
С помощью диаграмм IDEF3 обычно моделируют последовательности работ, имеющие технологические и временные связи. К таким моделям можно отнести проект разработки системы службы занятости, который и будет рассмотрен в данном примере.
Перед началом моделирования необходимо создать иерархическую структуру работ, описывающую процесс разработки системы.
1. Разработка технического задания.
3. Разработка модульной структуры.
4. Проектирование БД.
Согласно созданной структуре работ определим диаграммы, добавив на них взаимосвязи между работами.
Рис. 3.2. Диаграмма «Разработка системы службы занятости»
На стадии разработки технического задания заказчик системы играет важную «роль, снабжая разработчиков необходимой информацией для создания системы. Поэтому на диаграмме показан соответствующий объект-ссылка, влияющий на работу «Разработка технического задания».
Проведем декомпозицию работ по созданию службы занятости, ориентируясь на созданную структуру работ.
Рис. 3.3. Декомпозиция работы «Разработка технического задания»
Полученные диаграммы описывают процесс создания системы службы занятости на основе структуры работ по процессам. Обычно для более точного описания проекта создают несколько структур. В данном случае полезно создать структуру «по подсистемам», описав работы, необходимые для создания конкретных подсистем службы занятости.
Рис. 3.4. Декомпозиция работы «Анализ»
Рис. 3.5. Декомпозиция работы «Разработка модульной структуры»
Структура работ по подсистемам
1. Разработка технического задания.
2. Разработка подсистемы профессиональных и психологических тестов.
Рис. 3.6. Декомпозиция работы «Проектирование БД»
3. Разработка подсистемы обработки запросов. Определение межсистемных соглашений.
4. Разработка подсистемы экспертных оценок.
5. Разработка подсистемы контроля успеваемости студентов.
6. Разработка архитектуры всей системы.
7. Объединение подсистем.
При формировании структуры операций «по подсистемам» обнаружилась возможность создания типового фрагмента проектирования подсистемы, включающего один и тот же перечень работ. Такой подход часто упрощает описание проектов, позволяя формировать проекты любой сложности из небольших фрагментов. Выделим полученный типовой фрагмент в отдельную диаграмму (рис. 3.9).
Создадим пакет диаграмм, соответствующий структуре работ «по подсистемам».
Что такое DFD (диаграммы потоков данных)
В комментариях к одной из моих прошлых статей, посвященной IDEF0, один из пользователей высказал просьбу рассказать подробнее о том, что такое DFD. Понятие это несколько запутанное, многие мои клиенты также задают вопросы о потоках данных и стандартах построения диаграмм. А потому я решил эту статью посвятить DFD.
DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия
По моему мнению, определение из русскоязычной Википедии, несколько перегружено информацией и, в результате, излишне сложно для понимания. Кроме того, лично я считаю, что DFD и UML — это разные инструменты, а потому некорректно утверждать, что DFD — это просто предшественник UML.
Для себя я вывел следующую формулировку:
DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.
Зачем нужна нотация DFD?
Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:
Сам я пользуюсь только одним из вариантов, по Гейну и Сарсону. Но когда я изучал материал перед написанием этой статьи, я увидел эту таблицу сравнения. Считаю, что она важна не столько для выбора варианта синтаксиса, он будет зависеть, скорее от выбора программного обеспечения для создания нотаций и ваших личных предпочтений, сколько как наглядная иллюстрация того факта, что в DFD нет жесткого синтаксиса, как, например, в BPMN. Здесь можно использовать разные варианты, главное, чтобы они были понятны вам и вашим клиентам. Нотации DFD — удобный инструмент для создания нерегламентированных диаграмм, которые можно сделать быстро и с максимумом свободы.
Применяется этот вид нотации в случае, когда требуется описание системы как хранилища данных. Т.е. нотация должна наглядно ответить на вопросы:
Как создавать нотации DFD
Давайте для примера рассмотрим нотацию автоматизации продаж. Допустим, у нас есть клиент, который делает заявку через сайт или по телефону. Есть менеджер, который регистрирует эту заявку. Таким образом, в системе появляются данные – клиент и его заказ. Работник склада должен это увидеть и произвести отгрузку товара с оформлением всех необходимых документов и передать документы клиенту.
Последовательность получается такая:
С точки зрения DFD у нас имеются:
И декомпозиция основного элемента нашей диаграммы:
Где используются DFD нотации
DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:
Например, для выявления проблем документооборота, дублирования документов или, наоборот, недостающей документации или электронных данных в системе, очень удобно создать отдельно – описание бизнес-процесса, а потом к нему – DFD-нотацию. Либо наоборот, предварительно для понимания основ работы бизнеса и особенностей реализации документооборота создается DFD-нотация. Она помогает выявить, например, отсутствие в системе автоматизации важных документов, которые на самом деле создаются (на бумаге), но в системе никак не отображаются. А потом уже строится оптимизированный бизнес-процесс с учетом выявленных нюансов документооборота.
DFD нотации – это просто!
Я считаю, что DFD нотации – это действительно много проще, чем это кажется на первый взгляд. Главное, четко понимать ограничения построения этого типа диаграмм (отсутствие условий, времени и т.д.) и применять их там, где именно такой подход окажется удобнее. Возможно, вы найдете собственные варианты применения DFD, которые я выше не описал. В моем перечне присутствуют только те варианты, которые я использую на практике.
Что в DFD-нотациях особенно удобно, здесь не обязательно придерживаться строгих правил и синтаксиса, как, например, в BPMN. Эти нотации не будут исполнимыми, они нужны для понимания особенностей документооборота, структуры и последующей работы с данными. А потому, если ваша диаграмма понятна и вам, и заказчику, какие-то отступления от стандартов DFD вполне допустимы.
Рисовать диаграммы DFD можно, в принципе, где и как вам удобнее. Но если вы хотите работать с декомпозицией, выстраивать систему на разных уровнях детализации, то «рисовалки» (Visio, Paint и тому подобные) придется забыть. Вам потребуются специализированные программы для моделирования.
Лично я пользуюсь программой ERwin и всем ее рекомендую. Одна из причин моего выбора – это особенности декомпозиции. В ERwin, как и в некоторых других подобных системах, существует возможность декомпозирования DFD-процессов в формате IDEF3, т.е. основная диаграмма будет в формате DFD, и на самом общем уровне вы будете видеть основные потоки данных и «узлы» их обработки. А при декомпозиции вы сможете использовать уже процессный подход, что также бывает очень удобно для разработки крупных систем или работе с разными подразделениями бизнеса.
Вопросы и ответы
В чем разница между DFD и UML?
Существует язык создания нотаций UML, который также позиционирует себя как нотации, основанные на работе с данными. Но при этом UML — это уже язык программирования, здесь есть жесткий синтаксис, требования, но и возможностей для описания различных функций также много больше. DFD — это нотации, которые применяются более свободно, подходят, скорее, для планирования, изучения возможных вариантов решения, обсуждения с заказчиком и т.д.
Если вы — разработчик, и знаете UML, волне возможно, что даже какие-то предварительные решения вам будет удобнее создавать в этой нотации. А для бизнес-консультанта DFD всегда будет удобнее в качестве инструмента, так как бизнес-консультанту не требуется подробное описание функций с точки зрения автоматизации, это — задача технических специалистов. Зато время и силы DFD значительно экономит.
При этом не стоит рассматривать DFD как упрощенный вариант UML. Не смотря на схожесть в подходе, это — разные инструменты, предназначенные для разных целей.
Какое количество элементов может использоваться в DFD?
В отличие от систем с жестким синтаксисом и регламентом, в DFD нет ограничения по количеству элементов, которые могут находиться на одной диаграмме. Для сравнения: в IDEF0 количество таких элементов, дальше — только детализация (декомпозиция) или разные нотации.
С одной стороны, это большой плюс, так как отсутствие ограничений дает максимум свободы и комфорта при составлении нотации. С другой стороны, этой свободой злоупотреблять не рекомендуется. Помните, чем больше элементов у вас на диаграмме, тем сложнее ее читать.
Можно ли использовать нотации DFD для работы с клиентами?
В принципе, запретить это делать никто не может. Более того, в ограниченных количествах как иллюстрацию к каким-то вашим пояснениям такие нотации прекрасно подойдут и при обсуждении особенностей проекта с клиентом. Но все же, клиенты обычно слабо разбираются в вопросах автоматизации, структуре хранения данных, возможностях обработки и т.д. Это все находится в компетенции разработчиков. А нотации DFD строятся с учетом особенностей работы с данными, потому я все же рекомендую применять их преимущественно при обсуждении проекта специалистами, при создании технического описания и задания разработчикам, для повышения понимания именно разработчиками сути и особенностей проекта. Неподготовленному заказчику даже объяснить особенности DFD-нотаций может быть сложно.
Зачем вам DFD-диаграммы или как описать движение потоков данных в бизнес-процессах
Рассмотрим еще одну нотацию моделирования, которая не часто используется для непосредственного описания бизнес-процессов, а потому редко применяется начинающими системными и бизнес-аналитиками. Читайте далее, что такое DFD-диаграмма, зачем она нужна и как ее использовать в проектах интеграции информационных систем и управления данными.
Что такое DFD-нотация и зачем она нужна
Хотя BPMN и EPC нотации позволяют отлично описать логику выполнения бизнес-процессов, о чем мы писали здесь и здесь, иногда требуется показать эту деятельность не с позиции совершаемых действий, а с точки зрения обрабатываемых данных. Иначе говоря, нужно ответить на вопросы, из каких источников данных приходят, как преобразуются и куда отправляются. Обычно такая задача возникает в проектах, связанных с управлением данными (Data Management) и интеграции информационных систем. Методы и способы интеграции ИС мы рассмотрим в другой раз, а пока сфокусируемся на описании движения потоков данных. Именно для этого и нужны DFD-диаграммы (Data Flow Diagram).
Подобно IDEF0, DFD-нотация относится к SADT-методологии и соответствует структурному подходу, поддерживая принципы декомпозиции, иерархической упорядоченности и смыслового разделения сущностей. Хотя DFD и не содержит логических операторов (XOR, AND, OR), которые мы разбирали здесь, а также имеет очень ограниченное число элементов, она отлично позволяет описать последовательность возникновения, изменения и преобразования данных через их движение между процессами и хранилищами. Существует 2 разновидности DFD-диаграмм (Гейна-Сарсона и Йордана-Де Марко), которые немного отличаются лишь обозначениями некоторых элементов.
Итак, DFD-диаграмма включает следующие компоненты:
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
Ближайшая дата курса
Длительность обучения
8 ак.часов
Стоимость обучения
15 000 руб.
Правил для построения DFD-диаграмм совсем немного, и все они очень простые:
Чтобы показать реализацию этих правил на наглядном примере, далее рассмотрим уже упоминавшийся кейс нашей системы генерации промокодов после прохождения тестов, которые дают возможность оплатить курс со скидкой. Описание этой системы с помощью UML-диаграмм изложено в прошлой статье.
Как построить диаграмму движения потоков данных: практический пример
В конце лета наша Школа прикладного бизнес-анализа запустила маркетинговую акцию для частных клиентов, выдавая промокод на скидку по определенному курсу после прохождения тематического теста на сайте. Таким образом, всю последовательность действий по генерации промокода и его применению можно упрощенно представить следующим образом:
Таким образом, здесь можно выделить следующие хранилища данных:
Чтобы визуально выделить процессы, которые совершает пользователь, на диаграмме они отмечены голубым цветом. А хранилища данных, которые видны пользователю – желтым. Это не соответствует правилам DFD-нотации, но и не нарушает их: о цветовой маркировке блоков в первоисточниках ничего не сказано. Вообще прием с цветовым выделением некоторых блоков довольно удобен – я часто использую его на практике, чтобы облегчить читателю чтение диаграмм. В итоге для этого примера была составлена следующая DFD-диаграмма, показанная на рисунке ниже (контекстная диаграмма здесь не отображена).
Практический пример DFD-диаграммы (кликабельно, нажмите для увеличения)
В реализацию пошли не все описанные идеи этого кейса, но основные задумки реализованы. Проверить, как работает выдача промокодов на оплату наших курсов по бизнес-анализу со скидкой мы можете, выполнив любой открытый тест на нашем сайте бесплатно и без регистрации. А научиться самостоятельно разрабатывать DFD-диаграммы и освоить другие нотации моделирования бизнес-процессов вам помогут мои авторские курсы в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
Что описывает диаграмма dfd
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.