Соединение и разъединение стрелок

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

Построение моделей IDEF0

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

Контекстная диаграмма — диаграмма самого верхнего уровня иерархии, дает самое общее представление о системе. На контекстной диаграмме (КД) отображается только один функциональный блок (контекстная функция).

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

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

Ниже представлена типовая модель IDEF0: контекстная диаграмма и диаграмма детализации контекстной функции (диаграмма первого уровня детализации).

Цель: показать основные складские операции и их взаимосвязь.

Точка зрения: работник склада.

 

 

Порядок построения модели:

1. Определение цели моделирования.

2. Определение точки зрения (непосредственный исполнитель процесса, управленец, внешний аналитик и т.п.).

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

Определение цели моделирования и точки зрения позволяют выявить границы моделирования: ширину и глубину охвата.

Часто строится целый набор моделей для разных точек зрения.

Общие рекомендации по построению модели:

1. На каждом уровне представлять не более 3-6 функциональных блоков.

2. Не загромождать диаграмму несущественными на текущем уровне функциями и объектами.

3. Одновременно вести декомпозицию функций и объектов.

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

5. Следует выбирать ясные и полные наименования элементов.

Нумерация блоков и диаграмм. Все блоки нумеруются. Номер имеет вид <префикс><цифра>. Префикс представляет совокупность некоторой строки (обычно символ “A”) и номера родительского блока. Для блоков первого уровня детализации номер родительского не указывается. Контекстная функция обозначается как A0, декомпозирующие ее блоки — A1, A2, A3,... Далее, блок A1 может декомпозироваться на A1.1, A1.2,...; A1.1 — на A1.1.1, A1.1.2,... Точки обычно не ставятся, поскольку на грамотно построенной диаграмме не бывает больше 6-7 блоков. Т.е.: A0, A1, A11, A111,...

Туннелирование

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

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

Если скобки ставятся около начала стрелки, то она не показывается на родительской диаграмме.

 

 

Другие типы диаграмм IDEF0

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

Презентационная диаграмма (For Exposition Only, FEO) допускает любые нарушения синтаксиса IDEF0. Фактически, это любая иллюстрацию. Обычно такие диаграммы используются для более полного описания функциональных блоков и их совокупностей.

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

 

DFD

Аналогично IDEF0, диаграммы потоков данных (Data Flow Diagrams — DFD) позволяют моделировать систему как набор функций (действий, операций и т.п.), соединенных стрелками.

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

Имеется два основных варианта DFD: метод Гейна-Сарсона (Gane-Sarson) и метод Йордана-Де Марко (Yourdon-DeMarco). Нотации этих методов различаются.

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

Основными элементами DFD являются:

- внешние сущности;

- системы и подсистемы;

- процессы;

- накопители (хранилища) данных (data store);

- потоки данных.

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

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

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

Наименование системы и подсистемы представляет собой существительное или некоторое предложение с подлежащим.

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

Наименование процесса: активный глагол в неопределенной форме, за которым следует дополнение в виде существительного в винительном падеже («вычислить квадратный корень» и т.п.).

Накопитель данных — абстрактное устройство для хранения информации. Накопитель данных часто является прообразом будущей БД.

Наименование накопителя данных представляет собой существительное.

Поток данных — информация, передаваемая от источника к приемнику по некоторому каналу (соединению).

В зависимости от нотации, элементы DFD могут обозначаться по-разному.

Элемент	Нотация Гейна-Сарсона	Нотация Йордана-Де Марко
Внешняя сущность
Процесс
Накопитель данных
Поток данных

 

В некоторых модификациях метода Гейна-Сарсона для процессов могут быть показаны ресурсы, аналогичные механизмам исполнения IDEF0:

Потоки могут быть двунаправленными:

Простейший фрагмент диаграмм — два процесса, связываемых потоком данных, — выглядит следующим образом:

 

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

В самом общем случае, порядок построения иерархии DFD следующий:

1. Создание контекстной диаграммы; обычно для простой ИС строится одна диаграмма со звездообразной топологией: центр звезды — система, углы — внешние сущности.

2. Детализация системы и процессов. При этом должно соблюдаться правило балансировки: на диаграмме детализации могут указываться только те источники и приемники информации, которые показаны для детализируемой системы (процесса). Правило нумерации процессов: номер имеет вид типа X.Y, где Y — порядковый номер процесса, детализирующего процесс X.

3. Завершение детализации. Детализация процесса не выполняется в следующих случаях:

- небольшое число входных и выходных потоков данных (2-3 потока);

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

- преобразование входной информации в выходную описывается единственной логической функцией;

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

4. Верификация (проверка на корректность). Должно выполняться правило сохранения информации: все поступающие данные должны быть считаны, все считываемые — записаны.

Внешние сущности и накопители данных также обычно нумеруются. Номер накопителя данных состоит из префикса D (Data store) и уникального порядкового номера накопителя во всей модели DFD. Номер внешней сущности состоит из префикса E (External entity) и ее уникального порядкового номера в модели.

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

При построении диаграмм DFD полезно придерживаться следующих принципов:

- размещать на одной диаграмме 3-7 процессов (меньше 3 — малоосмысленная детализация, больше 7 — излишне сложная схема);

- декомпозировать потоки совместно с детализацией процессов;

- давать емкие и недвусмысленные наименования, избегать сокращений и аббревиатур;

при наличии вариантов возможных декомпозиций выбирать самый простой.

При построении диаграмм DFD часто удобно придерживаться такой последовательности действий:

1. Разложить множество требований в крупные группы по функциональному признаку, получить в результате основные функциональные группы.

2. Выявить все важные внешние объекты.

3. Определить основные виды передаваемой информации.

4. Разработать предварительную контекстную диаграмму (КД). Основные функциональные группы станут процессами, внешние объекты — внешними сущностями, основные виды информации — потоками данных.

5. Изучить предварительную КД, внести требуемые изменения.

6. Построить КД путем объединения всех процессов предварительной диаграммы в один процесс, который станет системой, и группирования потоков данных.

7. Сформировать диаграмму первого уровня детализации на базе процессов предварительной КД.

8. Проверить корректность DFD первого уровня.

9. (Иерархический спуск сверху вниз) Описать каждый процесс текущей диаграммы с помощью детализирующей диаграммы или миниспецификации.

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

11. Проверить соблюдения основных требований для текущей диаграммы.

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

Пример использования DFD

Пусть разрабатывается несложная ИС для обеспечения работы пункта проката видеокассет. Назначение ИС: ведение БД постоянных клиентов, учет видеокассет, аренды видеокассет, поставщиков. ИС должна генерировать регламентированные отчеты по запросу руководства.

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

С учетом указанных сведений, контекстная диаграмма может иметь вид:

 

Диаграмма декомпозиции получается в результате разбиения системы «Библиотека» на подсистемы и детализации потоков данных. Следует обратить внимание, что одна и та же внешняя для системы сущность «Руководитель» показана дважды. Такой прием позволяет уменьшить число пересечений и длину стрелок.

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

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

IDEF3

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

IDEF3 был специально разработан для закрытого проекта ВВС США. Метод ориентирован на получение описания деталей процесса от экспертов в предметной области и разработки схем таких процессов, для которых важно понять последовательность выполнения действий и взаимозависимости между ними. Метод может быть также использован при проектировании бизнес-процессов и анализе систем имитационными методами. IDEF3 получил широкое распространение как средство детализации схем IDEF0.

Метод достаточно прост, не имеет жестких ограничений по синтаксису и семантике.

IDEF3 позволяет описывать:

- объекты;

- роли, выполняемые объектами;

- отношения между объектами в ходе выполнения процесса;

- состояния объектов;

- изменения, которым подвергаются объекты;

- время выполнения работ, контрольные точки синхронизации работ;

- ресурсы, необходимые для выполнения работ.

В IDEF3 определены 2 типа взаимосвязанных схем (моделей):

1. Process Flow Description Diagrams — описание процесса как логической последовательности действий;

2. Object State Transition Network — сеть переходов состояний объекта.

На практике схемы первого типа используются значительно чаще. Именно это подмножество IDEF3 рассматривается ниже, и под моделью IDEF3 будет пониматься Process Flow Description Diagrams.

Элементы IDEF3

Диаграмма

Главной структурной единицей модели IDEF3 является диаграмма. Совокупность диаграмм образует модель. На диаграмме графически показывается исследуемый процесс или его фрагмент как набор взаимосвязанных компонентов.

Действие

Основным компонентом IDEF3 является действие, или, следуя терминологии IDEF3, единица поведения (Unit of Behavior, UOB). Смысл этого компонента соответствует смыслу функционального блока IDEF0 и процессу DFD, т.е. это отображение некоторой функции, переводящей входные параметры в выходные.

Действие обозначается посредством прямоугольника. Именуется с помощью глагола или отглагольного существительного. Каждое действие имеет уникальный в границах всей модели номер. Причем этот номер не используется вновь даже в том случае, когда действие исключается из схемы в процессе ее разработки или обновления. Обычно перед собственно номером действия указывается номер родительского действия, например: X.Y (X — уникальный номер родительского действия, Y — уникальный номер рассматриваемого действия; Y входит в декомпозицию X).

Обычно на действие с номером X.Y ссылаются как на действие AX.Y, где префикс 'A' указывает на то, что данный объект — действие. Например, A1.2 — это действие с уникальным номером 2, родительское действие которого имеет уникальный номер 1.

Связь

С помощью связи (link) показывается значимое взаимоотношение между действиями.

Все связи однонаправлены. Связь обозначается как стрелка.

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

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

1. Временное предшествование (temporal precedence) — показывает, что исходное действие должно завершиться до начала выполнения конечного действия; это связь типа «строгая зависимость»; обозначается как обычная стрелка ;

2. Нечеткое отношение (relational link) — вид взаимодействия, не укладывающийся в рамки первых двух; смысл такой связи обязательно должен быть раскрыт с помощью развернутого наименования, т.к. стрелка такого типа сама по себе говорит лишь о наличии некоторого отношения, никоим образом не указывая на его суть; объяснение смысла связи также может быть выполнено с помощью ссылки; обозначается как пунктирная стрелка .

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

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

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

Например, схеме

может соответствовать следующая временная диаграмма выполнения действий:

 

т.е. A1.3 инициируется за 1 секунду до завершения выполнения A1.2 (выполнение соответствующего действия показано сплошной линией).

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

Соединение (узел)

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

Типы соединений:

Обозначение	Название	Вид	Смысл
	Соединение «И»	Разворачивающее	Каждое последующее действие обязательно инициируется
		Сворачивающее	Каждое предыдущее действие обязательно должно завершиться
	Соединение «ИЛИ»	Разворачивающее	Одно или несколько последующих действий инициируются
		Сворачивающее	Одно или несколько предыдущих действий должны завершиться
	Соединение «исключающее ИЛИ»	Разворачивающее	Одно и только одно последующее действие инициируется
		Сворачивающее	Одно и только одно предыдущее действие должно закончиться

 

В полностью построенной модели все узлы должны быть иметь уникальное наименование. Наименование имеет вид Jx, где x — порядковый номер узла, например:

Соединение «И».

Пример:

       Корректные диаграммы для данного фрагмента модели:

 

       Главное, чтобы A1.3 и A1.4 начали выполняться после завершения выполнения A1.2, и чтобы A1.5 начало выполняться после окончания как A1.3, так и A1.4.

Соединение «ИЛИ».

Пример:

       Корректные временные диаграммы:

       Главное, чтобы после окончания A1.2 начали выполняться одно из действий A1.3 A1.4 или оба вместе, и чтобы перед началом выполнения A1.5 завершилось одно из действий A1.3, A1.4.

Обычно соединения типа «ИЛИ» явно описываются обычным текстом, при этом указывается, в каких ситуациях происходит инициация (завершения) некоторой совокупности действий.