Общая концепция

Метод моделирования процессов - потоков данных (DFD)

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

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

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

Для построения DFD используют две различные нотации, соответствующие методам Йордана и Гейна – Серсона. Далее в примерах будет использоваться более популярная сегодня нотация Гейна – Серсона.

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

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

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

2. Системы и подсистемы.

3. Процессы.

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

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

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

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

Системы и подсистемы декомпозируются на процессы – компоненты диаграмм, предназначенные для преобразования входных потоков данных в выходные в соответствии с определённым алгоритмом.

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

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

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

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

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

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

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

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

1.Размещать на каждой диаграмме от 3 до 6÷7 процессов.

3. Стараться не использовать аббревиатуры.

4. Не загромождать диаграммы несущественными деталями.

9.3. Диаграммы «сущность-связь»

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

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

IT-стандарты

В комментариях к одной из моих прошлых статей, посвященной 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 нотация состоит из следующих элементов:

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

Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных. Для работы с процессами я рекомендую использовать BPMN или IDEF3 (о ней я расскажу в другой раз).

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

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

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

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

Эту последовательность действий нам необходимо увидеть с точки зрения хранения данных и работы с ними в IT-системе.

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

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

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

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

Как будет выглядеть диаграмма (без декомпозиции, верхний уровень):

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

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

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

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

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

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

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

Основными компонентами диаграмм потоков данных являются: внешние сущности; системы и подсистемы; процессы; накопители данных; потоки данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый поток данных имеет имя, отражающее его содержание.

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

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

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

Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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