Файл: Курс лекций по дисциплине проектирование информационных систем Для студентов iv курса специальности 080801 Прикладная информатика (по областям).doc

11. ФУНКЦИОНАЛЬНЫЕ МЕТОДИКИ DFD и IDEF3

Рассматриваемые вопросы:

1. Методика построения модели в контексте DFD

2. Правила построения диаграмм модели DFD

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

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы).

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

Основные понятия:

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

---

2. Процесс (работа) – это элемент, который преобразует входные потоки в выходные в соответствии с действием, задаваемым именем процесса. Процесс представляет собой совокупность операций по преобразованию входных потоков данных в выходные в соответствии с определенным алгоритмом или правилом. Хотя физически процесс может быть реализован различными способами, наиболее часто подразумевается программная реализация процесса. Процесс на диаграмме потоков данных изображается прямоугольником с закругленными вершинами. Имя процесса должно содержать глагол в неопределенной форме (например, «получить документы по отгрузке продукции»). Каждый процесс имеет уникальный номер для ссылок на него.
3. Хранилище (накопитель) данных представляет собой абстрактное устройство или способ хранения информации, перемещаемой между процессами. Хранилище данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Предполагается, что данные можно в любой момент поместить в накопитель и через некоторое время извлечь, причем физические способы помещения и извлечения данных могут быть произвольными. Накопитель данных может быть физически реализован различными способами, но наиболее часто предполагается его реализация в электронном виде на магнитных носителях. Накопитель данных на диаграмме потоков данных изображается прямоугольником с двумя полями. Имя хранилища должно определять его содержимое и быть существительным.
4. Внешняя сущность представляет собой материальный объект или физическое лицо вне системы, являющейся источником или приемником системных данных. Примерами внешних сущностей могут служить: клиенты организации, заказчики, персонал, поставщики. Внешняя сущность обозначается прямоугольником с тенью, внутри которого указывается ее имя Ее имя должно содержать существительное, например, «склад товаров». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.
1 этап. Процесс построения DFD начинается с создания основной диаграммы типа «звезда», на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует.

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

---

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

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

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

4. 
   процесс имеет два-три входных и выходных потока;
   
5. 
   процесс может быть описан в виде преобразования входных данных в выходные;
   
6. 
   процесс может быть описан в виде последовательного алгоритма.
   

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

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

2. Многочисленные потоки данных между двумя компонентами можно показывать двумя линиями потока данных или двунаправленной стрелкой.

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

4. Символы могут быть повторены для облегчения чтения диаграммы.
После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость.

Полнота диаграммы

---

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

Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов:

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

Преимущества:

• 
  возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;
  
• 
  возможность проектирования сверху вниз, что облегчает построение модели «как должно быть».
  

Недостатки:

необходимость искусственного ввода управляющих процессов;

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

Клиенты




Информация для заказа

Информация о клиенте










Заказ клиента





Заявка на заказ




Пример диаграммы DFD

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

---

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

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

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

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

Диаграмма является основной единицей описания в IDEF3.

Единицы работы (Unit of Work (UOW)) –также называемые работами (activity), являются центральными компонентами модели. Они изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, «Изготовление изделия»).

Связи показывают взаимоотношения работ. Все связи однонаправлены и могут быть направлены куда угодно, но обычно диаграммы строятся так, чтобы связи были направлены слева направо.

Различают три типа стрелок, изображающих связи:

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

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

Потоки объектов (Object Flow)

---