DFD и WorkFlow (IDEF3)

Дополнение моделей процессов диаграммами DFD и WorkFlow (IDEF3)

Цель работы:

  • построение диаграмм потоков данных (DFD),
  • описание взаимосвязей между процессами при помощи диаграмм IDEF3 (WorkFlow). 

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

DFD описывает:

  1. функции-обработки информации (работы);
  2. документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;
  3. внешние ссылки (external reference), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
  4. таблицы для хранения документов (хранилища данных, data store). 

Для построения диаграмм DFD в BPWin используется нотация Гейна -Сарсона.

 

 

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

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

Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое. В случае, когда поток данных входит в хранилище или выходит из него и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

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

 

 

Рис. 3.1. Внешняя сущность

Для дополнения модели ID ЕГО диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count указать тип диаграммы DFD.

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

Цель IDEF3 - дать аналитикам описание последовательности выполнения процессов, а также объектов, участвующих совместно в одном процессе.

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

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

Единицы работы - Unit of Work (UOW), также называемые работами, являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя, обозначающее процесс действия и номер (идентификатор). В имя обычно включается основной результат работы (например, приготовление обеда). 

Показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными.

Старшая (Precedence) линия - сплошная линия, связывающая единица работ. Рисуется слева направо или сверху вниз. Показывает., что работа-источник должна закончиться прежде, чем работа-цель начнется.

Линия отношения (Relation Link) - пунктирная линия, использующаяся для изображения связей между единицами работ, а также между единицами работ и объектами ссылок.

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

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

Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fanout Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. 

 

Обозначение Наименование Смысл в случае слияния стрелок Смысл в случае разветвления стрелок
Asynchronous AND Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены
Synchronous AND Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно
Asynchronous OR Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
Synchronous OR Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно
XOR(Exclusive OR) Только один процесс завершен Только один следующий процесс запускается

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

Для внесения объекта-ссылки служит кнопка Объект-ссылки отображается в виде прямоугольника. Объекты-ссылка должны быть связаны с единицами работ или перекрестками пунктирными линиями.

При внесении объектов-ссылок необходимо указать их тип. 

Тип объекта-ссылки

Цель описания

OBJECT

Описывает участие важного объекта в работе

GOTO

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

UQB (Unit of behavior)

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

NOTE

Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму

ELAB (Elaboration)

Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках 

Диаграммы DFD

Диаграммы DFD можно использовать как дополнение к диаграммам IDEFO для описания документооборота и обработки информации.

Диаграммы IDEF3

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

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

1. Разработка технического задания.

  • Составление технического задания.
  • Утверждение технического задания.

2. Анализ

  • Определение объектов системы и их атрибутов.
  • Определение категорий пользователей.
  • Создание запросов к системе.

3. Разработка модульной структуры.

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

4. Проектирование БД.

  • Проектирование логической структуры БД.
  • Проектирование физической структуры БД.
  • Определение взаимосвязей между БД.
  • Выбор СУБД. 

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

 

Рис. 3.2. Диаграмма «Разработка системы службы занятости»

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

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

 

Рис. 3.3. Декомпозиция работы «Разработка технического задания»

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

Рис. 3.4. Декомпозиция работы «Анализ»

Рис. 3.5. Декомпозиция работы «Разработка модульной структуры»

1. Разработка технического задания.

  • Составление технического задания.
  • Подписание технического задания.

2. Разработка подсистемы профессиональных и психологических тестов.

  • Определение межсистемных соглашений.
  • Определение объектов и их атрибутов.
  • Определение категорий пользователей.
  • Создание запросов к системе.
  • Проектирование структуры БД.

 

Рис. 3.6. Декомпозиция работы «Проектирование БД»

3. Разработка подсистемы обработки запросов. Определение межсистемных соглашений. 

  • Определение межсистемных соглашений.
  • Определение объектов и их атрибутов.
  • Определение категорий пользователей,
  • Создание запросов к системе.
  • Проектирование структуры БД.

4. Разработка подсистемы экспертных оценок.

  • Определение межсистемных соглашений.
  • Определение объектов и их атрибутов.
  • Определение категорий пользователей.
  • Создание запросов к системе.
  • Проектирование структуры БД.

5. Разработка подсистемы контроля успеваемости студентов.

  • Определение межсистемных соглашений.
  • Определение объектов и их атрибутов.
  • Определение категорий пользователей.
  • Создание запросов к системе.
  • Проектирование структуры БД.

6. Разработка архитектуры всей системы.

7. Объединение подсистем.

  • Проверка соблюдения межсистемных соглашений.
  • Определение взаимосвязей между БД.

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

Создадим пакет диаграмм, соответствующий структуре работ «по подсистемам». 

 

  1. Что описывает диаграмма DFD?
  2. Какая нотация используется в BPWin для построения диаграмм DFD?
  3. Что описывает диаграмма IDEF3?
  4. Перечислите составные части диаграммы DFD.
  5. В чем состоит назначение процесса?
  6. Что называется внешней сущностью?
  7. Что описывают хранилища?
  8. Объясните механизм дополнения диаграммы IDEFO диаграммой DFD.
  9. Перечислите составные элементы диаграмм IDEF3.
  10. Что показывают связи в диаграммах IDEF3?
  11. Перечислите типы стрелок в диаграммах IDEF3.
  12. Что называется перекрестком?
  13. Назовите типы перекрестков.
  14. Что называется объектом-ссылкой?
  15. Какие бывают типы объектов-ссылок?
  16. Как добавить объект-ссылку?