Функциональные структурные модели ИС

---

О чем речь. Структурный анализ и проектирование. Диаграммы потоков данных DFD. Построение моделей процессов по стандарту IDEF0. Модели потоков работ. Структура программных модулей; методы представления и разработки алгоритмов и описания бизнес-логики приложения; логический анализ структур ИС. CASE-средство построения функциональных моделей BPwin.

4.1 Структурный подход к проектированию ИС

4.1.1. Сущность структурного подхода

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

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

- принцип "разделяй и властвуй" – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

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

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

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

- принцип непротиворечивости – заключается в обоснованности и согласованности элементов;

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

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

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы, реализуемые в стандарте IDEF0 (подраздел 4.2);

- DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 4.3);

- IDEF3 (Process Description Capture) – модели документирования процессов, происходящих в системе.

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

4.1.2 Методология функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

- графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

- связность диаграмм (номера блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных).

- отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

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

4.2. Моделирование потоков данных

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

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

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

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

Таким образом, основными компонентами диаграмм потоков данных являются:

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

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

- процессы;

- накопители данных;

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

4.2.1. Внешние сущности

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

Внешняя сущность обозначается прямоугольником (рис. 4.1):

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

4.2.2. Системы и подсистемы

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

Подсистема (или система) на контекстной диаграмме изображается следующим образом (рис. 4.2).

Рис. 4.2 – Подсистема

Номер подсистемы (справа) служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

4.2.3. Процессы

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

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

Рис. 4.3 – Процесс

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

"Ввести сведения о клиентах";

"Выдать информацию о текущих расходах";

"Ввести адрес".

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

4.2.4. Накопители данных

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

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

Рис. 4.4 – Накопитель данных

Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

4.2.5. Потоки данных

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

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

Рис. 4.5 – Поток данных

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

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

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

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

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

Признаками сложности (в смысле контекста) могут быть:

- наличие большого количества внешних сущностей (десять и более);

- распределенная природа системы;

- многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

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

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

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

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

Рис. 4.6 – Пример контекстной диаграммы потоков данных

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

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

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

- правило нумерации – означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

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

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

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

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

- возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

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

Логика иерархии диаграмм описана в п. 3.2.3, она полностью применима и к DFD диаграммам.

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

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

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

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

Пример диаграммы детализации показан на рис. 4.7.

Рис. 4.7 – Диаграмма детализации

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

4.3. Модели процессов по стандарту IDEF0

4.3.1. Состав функциональной модели

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

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

Рис.4.8 – Функциональный блок и четыре типа интерфейсных дуг (стрелок)

На рисунке 4.9, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

4.3.2. Иерархия диаграмм

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

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

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

Рис. 4.9 – Структура SADT-модели. Декомпозиция диаграмм

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

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

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

На рисунках 4.8–4.9 представлены различные варианты выполнения функций и соединения дуг с блоками.

Рис. 4.10 – Одновременное выполнение

Рис. 4.11 – Соответствие должно быть полным и непротиворечивым

Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.

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

Например, на рисунке 4.12, отображающем процесс разработки конструкторской документации (КД), дуга «Архивные файлы других отделов» отражает обратную связь по управлению, «Неутвержденная КД» – обратную связь по выходу/входу. Выход «Утвержденная КД» становится управлением для функции «Создание архива». Выход работы «Разработка ТЗ» является входом работы «Разработка КД и файлов по ТЗ». Функции «Утверждение ТЗ» и «Документооборот» могут выполняться одновременно.

Рис. 4.12 – Пример обратной связи по управлению

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

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

Рис. 4.13 – Пример входов (слева), выходов (справа), управлений (сверху)

и механизмов (снизу)

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 4.14 показано типичное дерево диаграмм (Node Tree).

Рис. 4.14 – Иерархия диаграмм

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

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

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

4.3.3. Типы связей между функциями

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

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

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

Различают, по крайней мере, семь типов связывания (табл. 4.1).

Таблица 4.1 – Типы связывания функциональных блоков

Тип связи	Относительная значимость
Случайная	0
Логическая	1
Временная	2
Процедурная	3
Коммуникационная	4
Последовательная	5
Функциональная	6

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.

(0) Тип случайной связности: наименее желательный.

Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме не имеют связи друг с другом. Крайний вариант этого случая показан на рисунке 4.15.

Рис. 4.15 – Случайная связность

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

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

(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 4.16.

Рис.4.16 – Процедурная связность

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

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

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

Рис. 4.17 – Коммуникационная связность

Рис. 4.18 – Последовательная связность

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

C = g(B) = g(f(A))

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

Рис. 4.19 – Функциональная связность

Таблица 4.2 – Значимость типов связности

Значи-мость	Тип связности	Для функций	Для данных
0	Случайная	Случайная	Случайная
1	Логическая	Функции одного и того же множества или типа (например, "редактировать все входы")	Данные одного и того же множества или типа
2	Временная	Функции одного и того же периода времени (например, "операции инициализации")	Данные, используемые в каком-либо временном интервале
3	Процедурная	Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора")	Данные, используемые во время одной и той же фазы или итерации
4	Коммуника­ционнная	Функции, использующие одни и те же данные	Данные, на которые воздействует одна и та же деятельность
5	Последова­тельная	Функции, выполняющие последовательные преобразования одних и тех же данных	Данные, преобразуемые последовательными функциями
6	Функцио­нальная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией

4.3.4. Моделирование процессов по стандарту IDEF0

Процесс моделирования какой-либо системы в IDEF0 начинается с оп­ределения контекста, т.е. наиболее абстрактного уровня описания системы в целом.

В контекст входит определение:

- субъекта моделирования (Области моделирования (Scope));

- цели моделирования (Purpose);

- точки зрения на модель (Viewpoint).

Область моделирования (Scope). Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматри­вать как компоненты системы, а что как внешнее воздействие. На опреде­ление субъекта системы будет существенно влиять позиция, с которой рас­сматривается система, и цель моделирования – вопросы, на которые по­строенная модель должна дать ответ. Другими словами, первоначально не­обходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначаль­но, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необ­ходимо учитывать два компонента – широту и глубину. Широта подразуме­вает определение границ модели – мы определяем, что будет рассматри­ваться внутри системы, а что снаружи. Глубина определяет, на каком уров­не детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени – трудоемкость построения модели растет в геометрической профессии от глубины деком­позиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объ­екты модели взаимосвязаны, внесение нового объекта может быть не про­сто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плава­ющей области").

Цель моделирования (Purpose). Модель не может быть построена без чет­ко сформулированной цели. Цель должна отвечать на следующие вопросы:

- Почему этот процесс должен быть промоделирован?

- Что должна показывать модель?

- Что может получить пользователь модели?

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

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит сис­тему в нужном для моделирования аспекте. Точка зрения должна соответ­ствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответствен­ного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесе­ния области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в за­кладку Definition – определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черно­вой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построе­ния модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели – AS-IS и ТО-ВЕ.

4.3.5. Модели AS-IS и ТО-ВЕ

Обычно сначала строится модель существую­щей организации работы – AS-IS (как есть). На основе модели AS-IS дос­тигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыг­нуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состо­ять преимущества новых бизнес-процессов и насколько глубоким измене­ниям подвергнется существующая структура организации бизнеса. Детали­зация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Призна­ками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный до­кумент не оказывается в нужном месте в нужное время), отсутствие обрат­ных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при созда­нии модели ТО-ВЕ (как будет) – модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших пу­тей выполнения работы и документирования того, как компания будет де­лать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного испол­нителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную ин­формацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно бы быть, хорошо бы так было).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несо­вершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая про­цесс перехода от начального к конечному состояния системы, поскольку такой переход – это тоже бизнес-процесс.

Результат описания модели можно получить в отчете Model Report. Диа­лог настройки отчета по модели вызывается из пункта меню Report/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 4.20).

Model Name: Movie Rental

Definition: Учебная модель

Scope: Технологические, Финансовые и управленческие аспекты деятельности условного предприятия.

Viewpoint: Руководитель предприятия

Purpose: Описать функциональность предприятия с целью написания спецификаций информационной системы.

Рис. 4.20 – Отчет по модели

4.3.6. Моделирование в стандарте IDEF0

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

Модель может содержать четыре типа диаграмм:

- контекстную диаграмму (в каждой модели может быть только одна кон­текстная диаграмма);

- диаграммы декомпозиции;

- диаграммы дерева узлов;

- диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаи­модействия с внешней средой. После описания системы в целом проводит­ся разбиение ее на крупные фрагменты. Этот процесс называется функ­циональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами деком­позиции. После декомпозиции контекстной диаграммы проводится деком­позиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого се­анса декомпозиции проводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после про­хождения экспертизы без замечаний можно приступать к следующему се­ансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания систе­мы в целом и каждого ее фрагмента одинаков во всей модели.

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

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

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

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

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

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

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

Точка зрения. Система моделируется с точки зрения руководителя конструкторского отдела.

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

Рисунок 4.19 – Контекстная диаграмма системы

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

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

Например, при "Обработке анкеты" анкета может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назна­чение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе – "Проверенная анкета "). Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 4.21 стрелки "Стандарты, нормативные документы, справочники", "Данные о сотрудниках", "Данные о разработках" являются управ­лением для работы "Хранение и учет конструкторской документации". Управление влияет на работу, но не преобразуется работой. Если цель работы – изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

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

- входные элементы (потоки данные или материальные объекты) изменяются, преобразуясь в выходные. Управление для некоторой функции не изменяется в этой функции (но может изменяться в других функциях) ;

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

Например, если работа заключается во вводе в ЭВМ данных с бумажного бланка анкет (даже без изменения их смыслового содержания), тогда:

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

- выходом будут данные в электронной форме;

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

Выход (Output) – материал или информация, которые производятся ра­ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка вы­хода рисуется как исходящая из правой грани работы. На рис. 4.19 стрелка "Архивная КД " является выходом для работы "Хранение и учет конструкторской документации".

Механизм (Mechanism) – ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рису­ется как входящая в нижнюю грань работы. На рис. 4.19 стрелка "Персонал предприятия" является механизмом для работы "Хранение и учет конструкторской документации". По усмотрению аналитика стрелки механизма могут не изображаться в модели (или туннелироваться).

Вызов (Call) – специальная стрелка, указывающая на другую модель ра­боты. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис. 4.19 стрелка "Другая модель хранения документации" является вызовом для работы "Хранение и учет конструкторской документации". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.

В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

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

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 4.22 – Пример несвязанных стрелок

На рис. 4.22 приведен фрагмент диаграммы декомпозиции с несвязан­ными стрелками, генерирующийся BPwin при декомпозиции работы "Хранение и учет конструкторской документации" (см. рис. 4.21). Стрелки входа, выхода, управления и механизма необходимо связать с соответствующими им блоками.

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

В IDEF0 различают пять типов связей работ.

1) Связь по входу (output-input), когда стрелка выхода вышестоящей рабо­ты (далее – просто выход) направляется на вход нижестоящей (например, на рис. 4.23 стрелка "Файлы документов" связывает работы "разработка ТЗ" и "Разработка КД и файлов ТЗ").

2) Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показыва­ет доминирование вышестоящей работы. Данные или объекты выхода вы­шестоящей работы не меняются в нижестоящей. На рис. 4.23 стрелка "Утвержденная КД" связывает работы "Утвержденная КД" и "Создание архива"), при этом чертеж не претерпевает изменений в процессе изготов­ления деталей.

3) Обратная связь по входу (output-input feedback), когда выход нижестоя­щей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 4.23 стрелка "Неутвержденная КД " связывает работы "Утверждение КД" и "Разработка КД и файлов ТЗ", при этом выявлен­ные при утверждении несоответствия КД направляются для устранения замечаний.

4) Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Рекомендации", рис. 4.23). Обратная связь по управлению часто свидетельствует об эффективности бизнес – процесса. На рис. 4.23 стрелка "Архивные файлы других отделов" связывает работы "Документооборот" и "Разработка КД и файлов ТЗ", при этом возможно повторное использование архивных файлов или их фрагментов при разработке КД. На рис. 4.23 качество документации может быть повышено путем непосредственного регулирования процессами разработки в зависимости от результатов (выхода) работы "Документооборот" (наличия аналогичной документации в архиве).

5) Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже ос­тальных и показывает, что одна работа подготавливает ресурсы, необходи­мые для проведения другой работы (рис. 4.24).

Несвязанные граничные стрелки (unconnected border arrow). При деком­позиции работы входящие в нее и исходящие из нее стрелки (кроме стрел­ки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки назы­ваются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

Рисунок 4.24 – Связь выход-механизм

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

Рисунок 4.23 – Диаграмма декомпозиции первого уровня

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

Смысл разветвляющихся и сливающихся стрелок передается именова­нием каждой ветви стрелок. Существуют определенные правила именова­ния таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. 4.24).

Рисунок 4.24 – Именование разветвляющихся стрелок

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

Правила именования сливающихся стрелок полностью аналогичны – ошибкой будет считаться стрелка, которая после слияния не именована; а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после этого вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.

Первый блок первого подуровня модели процессов называется «Разработка ТЗ» и содержит подуровень, который более детально раскрывает этот блок (рисунок 4.25).

Рисунок 4.25 –Второй подуровень «Разработка ТЗ»

Первый блок «Разработка ТЗ и прикрепление файлов» декомпозирован на третий подуровень (рисунок 4.26).

Рисунок 4.26 –Третий подуровень «Разработка ТЗ и прикрепление файлов»

Блок «Разработка ТЗ и прикрепление файлов» подразумевает создание документа технического задания (блок «Создание файла документа ТЗ»), создание новой записи о задании в БД – номер ТЗ, название, тема (блок «Создание нового ТЗ в БД») и прикрепление к заданию файлов, необходимых для его выполнения (блок «Прикрепление к ТЗ файлов необходимых для разработки»).

Блок «Визирование и простановка сроков» (рисунок 4.25) имеет смысл в том, что новое задание должно быть завизировано начальником подразделения разработчика ТЗ (задание может составлять как сотрудник, так и начальник). Начальник должен назначить подразделение-исполнитель и назначить сроки разработки по ТЗ.

Блок «Отправка в отдел-исполнитель» подразумевает, что после визирования ТЗ, у начальника отдела исполнителя появляется запись о новых невыполненных заданиях. После этого он должен назначить конкретного исполнителя, что и показано на четвертом блоке «Назначение исполнителя».

Второй блок «Разработка КД и файлов по ТЗ» (рисунок 4.23) отображает процесс полной разработки документации, файлов для производства и сопутствующих файлов, печати конструкторской документации, обмена информацией с другими подразделениями, что подразумевается в блоке «Документооборот».

Третий блок «Утверждение КД» (рисунок 4.23) отображает, что разработанная документация должна быть проверена начальником, нормоконтролером и утверждена во всех инстанциях. Если КД не утверждена, ее нужно доработать и исправить ошибки. После утверждения КД разработчик имеет право делать электронный архив файлов.

Четвертый блок «Создание архива» отображает порядок создания архива и детализирован на втором подуровне на три составляющих функции (рисунок 4.27).

Рисунок 4.27 –Второй подуровень «Создание архива»

Блок «Создание папки архива» (рисунок 4.27) подразумевает создание названия архива и выбор номера ТЗ, после чего происходит создание папки хранения архива на сервере БД. Второй блок «Прикрепление файлов» показывает запись файлов в папку архива. Третий блок «Сохранение и ввод информации об архиве» выполняет сохранение данных об авторе архива, присвоение версии архива и простановку даты создания архива.

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

Шестой блок «Документооборот» второго подуровня модели процессов (рисунок 4.23) отображает работы по хранению и извлечению файлов документации из архивов.

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

Рис. 4.28 – Неразрешенная (unresolved) стрелка

Тоннелирование может быть применено для изображения малозначи­мых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо на­править на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутст­вует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое Тоннелирование называется "не-в-родительской-диаграмме". Например, стрелки «Брак», «Отходы» можно тоннелировать на соответствующем уровне.

Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исклю­чения. (Предполагается, что не нужно детализировать стрелку механизма, т.е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на водительской диаграмме она может быть затоннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использо­ваться во всех работах дочерней диаграммы декомпозиции. Такое тоннелирование называется "не-в-дочерней-работе" (рис. 4.29). Оно означает, что все работы нижестоящего уровня могут использовать затоннелированный механизм по умолчанию.

Рис. 4.29 – Типы тоннелирования стрелок

4.3.7. Нумерация работ и диаграмм

Все работы модели нумеруются. Номер состоит из префикса и числа Может быть использован префикс любой длины, но обычно использую* префикс А. Контекстная (корневая) работа дерева имеет номер АО. Работы декомпозиции АО имеют номера Al, A2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядке вый номер, например работы декомпозиции A3 будут иметь номера А31 А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам. Имеются незначительные варианты нумерации.

Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграмм имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-1 декомпозиция контекстной диаграммы – номер А0, остальные диаграмм декомпозиции – номера по соответствующему узлу (например, А1, А2, А2, А13 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т.е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могу быть созданы различные версии одной и той же (с точки зрения ее pacnоложения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии, либо как FEO диаграмму. В любом случае следует отличать различные версии одно и той же диаграммы. Для этого существует специальный номер – C-number, который должен присваиваться автором модели вручную. C-number – произвольная строка, но рекомендуется придерживаться стандарта, который, например, состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а поряд­ковый номер отслеживается автором вручную, например SM00011.

4.3.8. Диаграммы дерева узлов и FEO

Диаграмма дерева узлов показывает иерархию работ в модели и позво­ляет рассмотреть всю модель целиком, но не показывает взаимосвязи меж­ду работами (стрелки) (рис. 4.30). Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ деком­позиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели – Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент не является состав­ляющей стандарта IDEF0.

Рис. 4.30 – Диаграмма дерева узлов

4.3.9. Каркас диаграммы

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

Смысл элементов каркаса приведен в табл. 4.3 и 4.4.

Таблица 4.3 – Поля заголовка каркаса (слева направо)

Поле	Смысл
Used At	Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посред­ством стрелки вызова
Autor, Date, Rev, Project	Имя создателя диаграммы, дата создания и имя проек­та, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы
Notes 12345678910	Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания
Status	Статус отображает стадию создания диаграммы, ото­бражая все этапы публикации
Working	Новая диаграмма, кардинально обновленная диаграм­ма или новый автор диаграммы
Draft	Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению
Recommended	Диаграмма и все ее сопровождающие документы про­шли экспертизу. Новых изменений не ожидается
Publication	Диаграмма готова к окончательной печати и публика­ции
Reader	Имя читателя (эксперта)
Date	Дата прочтения (экспертизы)
Context	Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показывается надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы:

Таблица 4.4 – Поля подвала каркаса (слева направо)

Поле	Смысл
Node	Номер узла диаграммы (номер родительской работы)
Title	Имя диаграммы. По умолчанию – имя родительской работы
Number	C-Number, уникальный номер версии диаграммы
Page	Номер страницы, может использоваться как номер страницы при формировании папки

4.3.10. Рекомендации по рисованию диаграмм

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, раз­ветвляться и пресекаться. Такие диаграммы могут стать очень плохо читае­мыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих пра­вил AllFusion Process Modeler (BPwin) поддерживает автоматически, выполнение других следует обес­печить вручную.

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

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

Обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению – "верхней". BPwin автоматически ри­сует обратные связи нужным образом. Его можно "обмануть", но лучше этого не делать.

Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwin не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала соз­дать обычную связь по входу, затем разветвить стрелку, направить но­вую ветвь обратно к входу работы-источника и, наконец, удалить ста­рую ветвь стрелки выхода

Следует вручную минимизировать число пересечений, петель и поворотов стре­лок.

Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм.

Панель инструментов BPwin [9] содержит инструменты для рисова­ния объектов в диаграмме. В BPwin существует три разных панели инструментов — по числу поддерживаемых програм­мой методологий (IDEF0 DFD IDEF3) .

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