Компоненты диаграммы
Потоки данных показывают, как объекты двигаются от одного управляющего процесса (работы) до другого, и в отличие от стрелок IDEF0, не представляют собой жесткие взаимосвязи.
Примеры диаграммы DFD приведены на рисунках 1 - 3.
При создании DFD-диаграммы (см. рис.4) часто возникают ошибки из-за непонимания экономической сущности задачи. Разберём некоторые из них:
Ошибка 1 - неправильно названа внешняя сущность. Внешней сущностью в данном случае может быть, например, клиент.
Ошибка 2 - не назван поток данных, идущий от внешней сущности. Его можно назвать «Заявки на заказ».
На рисунке 5 представлена DFD диаграмма бизнес-процесса «Планирование
закупок и размещение заказов поставщикам». При построении диаграммы допущены несколько типичных ошибок. Все они касаются использования элемента «Внешняя сущность». Согласно стандарту DFD, внешняя сущность - это элемент, который не является частью системы. Это часть внешней среды бизнеса.
Под цифрой 1 зелёным прямоугольником выделена внешняя сущность, у которой неверно указано название. Более подходящим названием будет
«Поставщики», а название исходящей стрелки (исходящего потока данных) -
«Прайс-листы».
Под цифрой 2 синим прямоугольником выделена внешняя сущность, у которой также неверно указано название. Её лучше разбить на две составляющие, первую из которых, внешнюю сущность, назвать «Консалтинговое агентство», от которого пойдёт поток данных «Отчёт о продажах на рынке товаров ...». Вместо многоточия нужно будет указать название товара. Вторую составляющую о внутренней статистике лучше обозначить хранилищем данных с рабочим названием «Внутренняя статистика продаж». Более подходящее название придумайте сами.
Цифрами с 3,4,5 и 6 которых вообще не должно быть на диаграмме. Директор и менеджеры отдела закупок просто не могут быть внешними сущностями по отношению к рассматриваемой системе. Эти элементы необходимо убрать с диаграммы. Поскольку мы рассматриваем функциональное моделирование, на диаграмме мы показываем функции (обозначены овалами). Стандартные функции прописываются в модели бизнес-процесса. Под эти функции подбираются на рынке труда специалисты и руководители.
Ещё недостатком является то, что не везде даны названия потокам данных, обозначенных стрелками.
Ошибками на рисунке 6 являются дублирование потоков данных от
поставщиков (выделено красным цветом). Это может привести к противоречивости данных.
Ошибками на рисунке 7 являются дублирование хранилища данных «Заказы на поставку».
IDEF3 - это метод моделирования потока процессов на основе сценария, созданный для отображения описательных действий. Цель IDEF3 - предоставить структурированный метод для выражения знаний эксперта в предметной области о том, как работает конкретная система или организация. В IDEF3 прямоугольники представляют реальные мировые процессы как события; они называются работами.
Стрелки, соединяющие поля, указывают приоритет действий. Соединения представляют собой ограничения и позволяют ветвление процесса (табл. 2). Кроме того, соединения включают выбор среди множества параллельных или альтернативных подпроцессов. Логические решения включают: AND (&), OR (O) и EXCLUSIVE-OR (X), а также синхронный или асинхронный запуск и завершение процессов (табл. 3).
Объекты проиллюстрированы в виде кружков, которые представляют их различные состояния, соединенные стрелками, у которых есть ссылки, чтобы указать условия входа, перехода, состояния и выхода.
Итоговая диаграмма декомпозиции работы в нотации IDEF3 имеет вид:
