Построение иерархии диаграмм потоков данных

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

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

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

Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

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

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

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

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

• правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
• правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

• наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
• возможности описания преобразования данных процессом в виде последовательного алгоритма;
• выполнения процессом единственной логической функции преобразования входной информации в выходную;
• возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.

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

4.4 Моделирование потоков работ (IDEF3).

Моделирование потоков работ.

(Workfow diagramming)

IDEF3

Методы моделирования процессов IDEF0, DFD обеспечивают разработку структуры процесса, но не позволяют моделировать сценарии выполнения процесса. Для моделирования работ выполняемых в процессе и выполнения их последовательности предназначен метод IDEF3. IDEF3 - метод описания потоков работ процесса, его первичная цель состоит в том, чтобы обеспечить описание последовательности работ и объектов используемых для их выполнения. IDEF3 модели в основном используются для описания сценариев выполнения последовательности действий, моделируемого процесса. Также может использоваться для моделирования состояний объектов и событий вызывающих изменения состояний. Мы рассмотрим только моделирование сценариев. Основной единицей модели IDEF3, также как и в других методиках является диаграмма.

Синтаксис и семантика

IDEF3 модели.

Диаграмма IDEF3 может содержать следующие элементы:

- единица работы;

- объект ссылки;

- перекресток;

- связь.

Единица работы (UOW).

Единица работы моделирует операцию (деятельность) выполняемую

при реализации процесса.

На диаграмме изображается прямоугольником, разделенным на 3 части. еденица работы называется глаголом или фразой глагол с существительным и имеет уникальный идентификатор номер. Номеру(числу) работы обычно предшествует номер ее родительской работы (рис. 2-2).

Объект ссылки.

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

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

Рис. 36

Связи

Возможный порядок или очередность выполнения действий описываемого процесса в IDEF3 задается связями

Связи обозначают существенные отношения между единицами работ и объектами ссылки. Изображаются на диаграмме стрелками.

Существует 3 типа связей

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

Дата добавления: 2014-01-11