Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проектирование ИС 2011.doc
Скачиваний:
72
Добавлен:
11.03.2015
Размер:
356.86 Кб
Скачать

13. Диаграммы потоков данных. Назначение. Нотации dfd. Рекомендации по построению

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD  – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища). Рекомендации по построению1. Размещать на каждой диаграмме от 3 до 6-7 процессов. 2. Не загромождать диаграммы несущественными на данном уровне деталями. 3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. 4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры. 5.  Соблюдать следующие этапы:

1) Идентификация внешних объектов, с которыми система должна быть связана. 2) Идентификация основных видов информации, циркулирующей между системой и внешними объектами. 3) Предварительная разработка контекстной диаграммы. 4) Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям. 5) Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков. 6) Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы. 7) Проверка основных требований по DFD первого уровня. 8) Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса. 9) Проверка основных требований по DFD соответствующего уровня. 10) Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах. 11) Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям. 12) После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели. 13) Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.

14. Основные элементы диаграмм dfd

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