ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.10.2023
Просмотров: 133
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью диаграмм "сущность-связь" (Entity-Relationship Diagrams, ERD).
DFD можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.
Для изображения DFD традиционно используются две различные нотации:
Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson).
В Ramus для построения диаграмм потоков данных используется нотация Гейна-Сарсона.
Основные символы DFD в нотации Гейна-Сарсона изображены на рис. 1.20. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных.
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным.
| Название символа | Изображение символа |
| Поток данных |  |
| Процесс |  |
| Хранилище |  |
| Внешняя сущность |  |
Рис. 1.20 Основные символы диаграммы потоков данных
Назначение процесса (функционального блока) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением
(например, «Обработать заказ»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
Внешняя сущность (внешняя ссылка) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, «Клиент». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Включение внешних сущностей в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
Если создается независимая DFD модель, то контекстная диаграмма содержит один процесс и внешние сущности (рис. 1.21).
Рис. 1.21 Пример контекстной DFD диаграммы
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как данные двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение данных, хранение данных, поставка и распространение данных (рис. 1.22).
Рис. 1.22 Пример DFD диаграммы
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD система может рассматриваться как совокупность предметов. В этом случае функциональны блоки именуются по названию системы, например «Система обработки информации».
Слияние и разветвление стрелок. В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя.
Построение диаграмм DFD. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.
Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением, в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.
Затем модель окружения описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один функциональный блок, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует.
Наконец, модель поведения показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник изображает каждое событие из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения.
Полученные диаграммы могут быть преобразованы с целью более наглядного представления системы, в частности работы на диаграммах могут быть декомпозированы.
-
Создание смешанной модели
Авторы нотаций IDEF0 и DFD не предполагали совместного использования диаграмм различной нотации в одной модели, поэтому создание смешанной модели имеет ряд особенностей. Во-первых, существуют определенные правила декомпозиции работы одной нотации в диаграмму другой. Во-вторых, Ramus позволяет разместить объекты одной нотации на диаграмме другой. Рассмотрим эти особенности.
Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге «Создание новой диаграммы» кликнуть по радио-кнопке DFD
(рис. 1.23).
Рис. 1.23 Дополнение модели IDEF0 диаграммой DFD
Создается новая диаграмма DFD, и стрелки, которые касаются родительской работы, мигрируют на диаграмму нижнего уровня так, как если бы это была диаграмма IDEF0 (рис. 1.24 и 1.25). Стрелки входа родительской работы на дочерней диаграмме DFD
показываются входящими стрелками с левой стороны диаграммы DFD, стрелки управления — входящими стрелками с верхней стороны диаграммы и т. д.
Рис. 1.24 Декомпозируемый функциональный блок на диаграмме IDEF
Рис. 1.25 Диаграмма DFD. Декомпозиция процесса «Принять заказ и ввести данные»
В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
-
Добавить в диаграмму внешнюю ссылку
. Внешняя ссылка является источником или приемником данных извне модели. -
Добавить в диаграмму хранилище данных
. Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в функциональных блоках.
Согласно нотации DFD диаграмма не должна иметь граничных стрелок-все стрелки должны начинаться и заканчиваться на работах, хранилищах данных или внешних сущностях. Поэтому, если строго следовать правилам нотации, следует:
-
Удалить все граничные стрелки на диаграмме DFD. -
Создать соответствующие внешние сущности и хранилища данных.
Для этого нужно добавить в диаграмму внешнюю сущность или хранилище данных, выбрав соответствующую кнопку на панели инструментов, затем сделать по объекту двойной щелчок и в появившемся диалоговом окне выбрать кнопку
«Задать DFD объект» (рис. 1.26).
Рис. 1.26 Диалоговое окно «Свойства DFD объекта»
В появившемся диалоговом окне в контекстном меню выбрать пункт Создать элемент (рис. 1.27).
Рис. 1.27 Создание элемента классификатора
Название классификатора можно ввести в созданную строку, дважды, медленно кликнув мышью по строке, или же нажав клавишу F2, предварительно выделив нужную строку мышью (рис. 1.28). Собственно, таким образом можно редактировать название любого классификатора из созданных (рис. 1.29).
Рис. 1.28 Создание классификатора Внешние сущности
Рис. 1.29 Создание элемента Заказчик классификатора Внешние сущности
Для завершения создания элемента необходимо щелкнуть по кнопке ОК
(рис. 1.30)
Рис. 1.30 Завершение создания DFD объекта
Аналогично создаются хранилища данных (рис. 1.31)
Рис. 1.31 Создание хранилища данных
-
Создать внутренние стрелки, начинающиеся с внешних сущностей вместо граничных стрелок. -
Стрелки на диаграмме IDEF0 затоннелировать.
Результат этих действий представлен на рис. 1.32 и 1.33.
Рис. 1.32 Тоннелирование стрелок на диаграмме IDEF0
Рис. 1.33 Замена граничных стрелок внутренними на диаграмме DFD
Строго придерживаться правил нотации DFD при создании смешанных моделей не всегда удобно, поэтому Ramus позволяет создавать граничные стрелки на диаграммах DFD и не идентифицирует такие стрелки как синтаксическую ошибку.
В результате дополнения диаграмм IDEF0 диаграммами DFD может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ в смешанной модели можно увидеть в окне Модели (рис 1.34). Для отображения окна Модели, необходимо выполнить действия, показанные на рис. 1.35.
