Нотация dfd (Data Flow Diagramming)

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

Элементы DFD диаграмм показаны в таблице 3.

Таблица 3.

№	Наименование	Описание	Графическое представление
1	Работа (Activity)	Объект обозначает функции или процессы, которые обрабатывают и изменяют информацию.
2	Информационный поток (Precedence)	Объект обозначает информационный поток от объекта-источника к объекту-приемнику.
3	Внешняя ссылка (External reference)	Указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы.
4	Хранилище данных (Data store)	Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.

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

1. Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

2. Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

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

6. Пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью DFD, то это и необходимо делать, а не использовать для описания более сложные объекты.

7. Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.

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

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

2. Идентификация внешних объектов, с которыми система должна быть связана.

3. Идентификация основных видов информации, циркулирующей между системой и внешними объектами.

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

5. Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.

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

7. Формирование DFD первого уровня на базе процессов предвари тельной контекстной диаграммы.

8. Проверка основных требований по DFD первого уровня.

9. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

10. Проверка основных требований по DFD соответствующего уровня.

11. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

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

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

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count "кликнуть" по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

• (External Reference) — добавить в диаграмму внешнюю ссылку;

• (Data store) — добавить в диаграмму хранилище данных;

• Diagram Dictionary Editor – ссылка на другую страницу. В отличие от IDEF0 этот инструмент позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

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

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать деятельность предприятия с трех ключевых точек зрения:

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

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

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

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

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

Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу.

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

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

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

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

• Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.

• Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.

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

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

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

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

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

Синтаксические ошибки IDEF0 с точки зрения BPwin разделяются на три типа:

• Во-первых, это ошибки, которые BPwin выявить не в состоянии. Например, синтаксис IDEF0 требует, чтобы имя работы было выражено отглагольным существительным или глагольной формой, выражающей действие ("Изготовление изделия" и т. д.), а имя стрелки должно быть выражено существительным. BPwin не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игнорирует ошибки этого типа. Выявление таких ошибок - ручная работа, которая ложится на плечи аналитиков и должна контролироваться руководителем проекта.

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

• Третий тип ошибок BPwin позволяет допустить, но их определяет. Полный их список можно получить в отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления (Activity "Сборка блоков" has no Control, Activity "Сборка блоков" has no Output), и т. д.

Лабораторная работа 1. Изучение пространства разработчика BPWin.

Теоретические сведения.

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT – Structured Analysis and Design Technique.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

В отличие от других методов структурного анализа в SADT каждая сторона блока имеет вполне определенное особое назначение: левая сторона блока предназначена для Входов (Input), верхняя – для Управления (Control), правая – для Выходов (Output), нижняя - для Исполнителей (Mechanism). Такое обозначение отражает определенные принципы активности: Входы преобразуются в Выходы, Управления ограничивают или предписывают условия выполнения, Исполнители описывают, за счет чего выполняются преобразования. Один из общих принципов методологии IDEF0 требует: к каждому блоку на диаграмме должна быть присоединена хотя бы одна стрелка управления, отображающая условия правильного функционирования блока.

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

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

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

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

Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее – просто выход) направляется на вход нижестоящей,

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей.

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.

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

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

Графическая диаграмма - главный компонент модели, содержащий блоки, стрелки, соединения блоков и стрелок. Диаграмма является единицей описания системы и располагается на отдельном листе.

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

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой.

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

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

Цель - это краткая формулировка причины создания модели. Цель должна отвечать на вопросы: почему этот процесс должен быть смоделирован? что должна показать модель? что может получить читатель?

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

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

Выполнение работы.

В качестве примера рассматривается деятельность гипотетической компании, занимающейся сборкой компьютеров «Computer World». Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры (в том числе и ноутбуки).

Основные виды работ в компании таковы:

• продавцы принимают заказы клиентов;

• операторы группируют заказы по типам компьютеров;

• операторы собирают и тестируют компьютеры;

• операторы упаковывают компьютеры согласно заказам;

• кладовщик отгружает клиентам заказы.

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

После запуска программы (All Fusion Process Modeler 7) на экране появится диалог ModelMart Connection Manager, нажмите на кнопку Cancel (Отмена).

Далее появится диалоговое окно All Fusion Process Modeler, в котором необходимо выбрать модель, которая будет спроектирована. Каким образом осуществляется переход от одной модели к другой будет сказано ниже.

Вносите имя модели в текстовое поле Name (в некоторых случаях существуют проблемы с русификацией из-за отсутствия некоторых файлов, поэтому здесь пишем латиницей!): "Тhe company's activities " и выберите Туре – Business Process (IDEF0). Нажмите кнопку ОК. Затем открывается диалоговое окно Properties for New Models (Свойства новой модели).

Вводите в текстовое поле Author (Автор) имя автора модели (латиницей или убедится, что русификация работает) и в текстовое поле Author initials его инициалы. Автоматически создается незаполненная контекстная диаграмма.

При запуске BPwin по умолчанию появляется: стандартная панель инструментов, палитра инструментов и, в левой части, навигатор модели - Model Explorer (Браузер модели).. Инструмент Model Explorer имеет тривкладки - Activities, Diagrams, Objects. Обратите внимание на кнопку на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации - Model Explorer. Вкладка Activities показывает в виде раскрывающегося иерархического списка все блоки модели. Одновременно могут быть показаны все модели, открытые в BPwin. Блоки диаграмм IDEF0 показываются зеленым цветом, IDEF3 - желтым, DFD - голубым.

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

Пункт меню	Описание
Insert Before	Создать новый блок перед текущим
Insert After	Создать новый блок после текущего
Decompоse	Декомпозировать блок. В результате будет создана диаграмма декомпозиции
Name	Вызов редактора имени
Definition/Note	Вызов редактора определения и примечания
Font	Изменение шрифта
Color	Изменение цвета
Costs	Задание стоимости
Data Usage	Ассоциация блока с данными
UDP	Задание свойств, определяемых пользователем
UOW	Задание свойств для блока IDEF3

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

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

Стандартная панель инструментов обеспечивает быстрый доступ к часто выполняемым задачам. Вы можете показывать или скрывать панель, используя команду меню View | Standard Toolbar. Ниже показаны элементы стандартной панели.

Палитра инструментов содержит инструменты для работы с объектами в диаграмме BPwin. Вы можете показывать или скрывать ее, используя команду меню View | BPwin Toolbox. Вид палитры зависит от выбранной нотации (IDEF0, IDEF3, DFD). В таблице 3 показаны основные элементы палитры инструментов.

Элемент управления		Описание
		Создать новую модель
		Открыть модель
		Сохранить модель
		Печать модели
		Вызвать генератор отчетов
		Выбор масштаба
		Масштабирование
		Проверка правописания
		Включение и выключение навигатора модели Model Explorer
		Включение и выключение дополнительной панели инструментов работы с ModelMart
	Указатель (Pointer) - редактирование, перемещение объектов
	Блок (Activity Box) - создание блока на диаграмме IDEF0
	Стрелка (Precedence Arrow) - создание стрелки
	Тильда (Squiggle) - создание тильды
	Текст (Text) - создание текстовых комментариев
	Родительская диаграмма (Go to Parent Diagram) - открытие родительской диаграммы
	Дочерняя диаграмма (Go to Child Diagram) - создание диаграммы декомпозиции

Если вам непонятно, как выполнить то или иное действие, вы можете вызвать контекстную помощь - клавиша F1 или воспользоваться меню Help.

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

Поля заголовка каркаса (слева направо)

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

 

Поля подвала каркаса (слева направо)

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

 

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

В пункте меню Model|Default fonts выбираете, что именно будете русифицировать:

И далее видите следующий диалог для настройки шрифтов:

Выбираете кириллицу и нажимаете «ОК».

Перейдите в меню Model/Model Properties. Во вкладке General диалогового окна Model Properties в текстовое поле Model name внесено имя модели "The company’s activities", а в текстовое поле Project вносим самостоятельно имя проекта "The company’s activities model", и, наконец, в текстовое Time Frame (Временной охват) - AS-IS (Как есть).

Во вкладке Purpose диалогового окна Model Properties в текстовое поле Purpose (цель) внесите данные о цели разработки модели - " Моделировать текущие (AS-IS) бизнес-процессы компании", а в текстовое поле Viewpoint (точка зрения) - "Директор".

Во вкладке Definition диалогового окна Model Properties в текстовое поле Definition (Определение) внесите "Учебная модель деятельности компании" и в текстовое поле Scope (охват) - " Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов".

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

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

Во вкладке Name внесите имя "The company’s activities". Здесь на всякий случай используем латиницу, поскольку это название будет отражено внизу в рамке.

Во вкладке Definition диалогового окна Activity Properties в текстовое поле Definition (Определение) внесите "Текущие бизнес-процессы компании". Текстовое поле Note (Примечания) оставьте незаполненным.

Создайте ICOM-стрелки на контекстной диаграмме ICOM (аббревиатура от Input, Control, Output и Mechanism) (таблица 4).

Таблица 4 - Стрелки контекстной диаграммы

Название стрелки (Arrow Name)	Определение стрелки (Arrow Definition)	Тип стрелки (Arrow Type)
Звонки клиентов	Запросы информации, заказы, техподдержка и т. д.	Input
Правила и процедуры	Правила продаж, инструкции по сборке, процедуры тестирования, критерии производительности и т. д.	Control
Проданные продукты	Настольные и портативные компьютеры	Output
Бухгалтерская система	Оформление счетов, оплата счетов, работа с заказами	Mechanism

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

Затем направляем мышь на диаграмму:

Щелкаем на черном треугольнике и стрелка проведена.

Аналогично проводим стрелки снизу, сверху и выходную.

Если стрелка проведена неправильно, выбираем первую кнопку – стрелка вверх, щелкаем на стрелке, она станет выделенной и нажимаем кнопку «Delete».

Далее необходимо создать подписи на стрелках.

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

Затем с помощью кнопки «Т» внесите текст в поле диаграммы: точку зрения и цель. При выбранной кнопке «Т» и нажатии мыши на диаграмме над стрелкой откроется окно для ввода текста:

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

Полученный результат:

Ну и поскольку русификация может не поддерживаться – заменим названия стрелок на английские: calls of clients, rules, products, bookkeeping.

Для того, чтобы удалить прежние названия в пункте меню выбираем: Model|Arrow Editor

В результате получаем окончательный вид диаграммы:

Создадим предварительный отчет по модели. В меню Tools/Reports/Model Report зададим опции генерирования отчета (установить галочки). Порядок нажимания галочек влияет на порядок отображения информации в отчете!

Далее нажмите кнопку Preview (Предварительный просмотр).

Контрольные вопросы:

1. В чем состоит особенность структурного подхода к проектированию ИС? Опишите основные принципы структурного подхода и объясните на решение каких задач он ориентирован.

2. Что такое CASE технология? Какие задачи призваны решать CASE технологии

3. Какие принципы лежат в основе структурного анализа? Перечислите и коротко охарактеризуйте их.

4. Какие существуют средства структурного анализа? Охарактеризуйте каждое из них.

5. Опишите последовательность проведения анализа и проектирования с использованием технологии SADT.

Лабораторная работа 2. Создание диаграммы декомпозиции.

Теоретические сведения.

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

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

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

Нумерация работ и диаграмм. Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции.

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

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

Связь по входу(output-input), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей.

Связь по управлению(output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей.

Обратная связь по входу(output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.

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

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

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

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

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

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

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

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

Выполнение работы.

Выберите кнопку перехода на нижний уровень в палитре инструментов

и в диалоговом окне Activity Box Count установите число работ на диаграмме нижнего уровня - 3 - и нажмите кнопку ОК.

Автоматически будет создана диаграмма декомпозиции:

Правой кнопкой мыши щелкните по работе расположенной в левом верхнем углу области редактирования модели, выберите в контекстном меню опцию Name и внесите имя работы. Повторите операцию для оставшихся двух работ. Затем внесите определение, статус и источник для каждой работы согласно данным таблицы 5.

Таблица 5 - Работы диаграммы декомпозиции А0

Название работы (Activity Name)	Определение работы (Activity Definition)
Продажи и маркетинг/Sales and marketing	Маркетинг и презентации, выставки
Сборка и тестирование компьютеров/Computer assembly and testing	Сборка и тестирование настольных и портативных компьютеров
Отгрузка и получение/Shipment and receipt of goods	Отгрузка заказов клиентам и получение компонентов от поставщиков

Диаграмма декомпозиции примет вид:

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

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

Теперь продолжим работу с диаграммой: перейдите в режим рисования стрелок и свяжите граничные стрелки, воспользовавшись кнопкой на палитре инструментов, щелкните на стрелке, потом ведите мышь к прямоугольнику

результат должен получиться, как показано ниже:

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

Продолжим работу с диаграммой. Правой кнопкой мыши щелкните по ветви стрелки управления работы "Computer assembly and testing" и переименуйте ее в "Rules of assembly and testing".

Внесите определение для новой ветви: "Rules of Computer assembly and testing" (правая кнопка мыши – контекстное меню – definition). Далее правой кнопкой мыши щелкните по ветви стрелки механизма работы "Sales and marketing" и переименуйте ее как "System of ordering" (система оформления заказов).

Альтернативный метод внесения имен и свойств стрелок - использование словаря стрелок (вызов словаря - меню Dictionary/ Arrow). Если внести имя и свойства стрелки в словарь, ее можно будет внести в диаграмму позже.

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

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

Создайте стрелку обратной связи (по управлению) "Result of assembly and testing", идущую от работы "Computer assembly and testing" к работе "Sales and marketing". Измените, при необходимости, стиль стрелки (толщина линий из контекстного меню). Методом drag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите из контекстного меню Squiggle (Загогулину). Результат возможных изменений показан ниже. Напоминаю, что следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.

Создайте новую граничную стрелку выхода "Marketing data", выходящую из работы "Sales and marketing". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике .

Щелкните правой кнопкой мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel.

В диалоговом окне Border Arrow Editor (Редактор Граничных Стрелок) выберите опцию Resolve it to Border Arrow (Разрешить как Граничную Стрелку).

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

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

Создание диаграммы декомпозиции А2.

Декомпозируем работу "Computer assembly and testing".

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

• Производственный отдел получает заказы клиентов от отдела продаж по мере их поступления.

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

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

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

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

На основе этой информации внесите новые работы и стрелки (таблица 6 и 7).

Таблица 6- Работы диаграммы декомпозиции А2

Название работы (Activity Name)	Определение работы (Activity Definition)
Отслеживание расписания и управление сборкой и тестированием/Ordering of schedule and assemble and testing management	Просмотр заказов, установка расписания выполнения заказов, просмотр результатов тестирования, формирование групп заказов на сборку и отгрузку
Сборка настольных компьютеров/Computer assembly	Сборка настольных компьютеров в соответствии с инструкциями и указаниями диспетчера
Сборка ноутбуков/Notebook assembly	Сборка ноутбуков в соответствии с инструкциями и указаниями диспетчера
Тестирование компьютеров/Testing of computers	Тестирование компьютеров и компонентов. Замена неработающих компонентов

Таблица 7 - Стрелки диаграммы декомпозиции А2

Наименование стрелки (Arrow Name)	Источник стрелки (Arrow Source)		Тип стрелки источника (Arrow Source Type)	Приемник стрелки (Arrow Dest.)		Тип стрелки приемника (Arrow Dest. Type)
Диспетчер/manager	Персонал производственного отдела/ manufacturing department staff			Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management		Mechanism
Заказы клиентов/orders of clients	Граница диаграммы		Control	Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management		Control
Заказы на настольные компьютеры/orders for computers	Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management		Output	Сборка настольных компьютеров/ Computer assembly		Control
Заказы на ноутбуки/ orders for notebooks	Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management		Output	Сборка ноутбуков/ Notebook assembly		Control
Компоненты/Components	"Tunnel"		Input	Сборка настольных компьютеров/ Computer assembly		Input
				Сборка ноутбуков/ Notebook assembly		Input
				Тестирование компьютеров/Computer testing		Input
Настольные компьютеры/Computers	Сборка настольных компьютеров/ Computer assembly		Output	Тестирование компьютеров/ Computer testing		Input
Ноутбуки/Notebooks	Сборка ноутбуков/ Notebook assembly		Output	Тестирование компьютеров/ Computer testing		Input
Персонал производственного отдела/ manufacturing department staff		"Tunnel"			Сборка настольных компьютеров/Computer assembly		Mechanism
					Сборка ноутбуков/ Notebook assembly		Mechanism
Правила сборки и тестирования/ Rules of assembly and testing		Граница диаграммы			Сборка настольных компьютеров/ Computer assembly		Control
					Сборка ноутбуков/ Notebook assembly		Control
					Тестирование компьютеров/ Computer testing		Control
Результаты сборки и тестирования/ Result of assembly and testing		Сборка настольных компьютеров/ Computer assembly	Output		Граница диаграммы		Output
		Сборка ноутбуков/ Notebook assembly	Output
		Тестирование компьютеров/ Computer testing	Output
Результаты тестирования/Results of testing		Тестирование компьютеров/ Computer testing	Output		Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management		Input
Собранные компьютеры/ready computers		Тестирование компьютеров/ Computer testing	Output		Граница диаграммы		Output
Тестировщик/Tester		Персонал производственного отдела/ manufacturing department staff			Тестирование компьютеров/ Computer testing		Mechanism
Указание передать компьютеры на отгрузку/computers for shipping		Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management	Output		Тестирование компьютеров/ Computer testing		Control

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

Контрольные вопросы:

1. В чем заключается суть методологии SADT? Из каких основных частей она состоит, какие типы диаграмм использует? Коротко опишите каждый тип диаграммы.

2. Опишите правила построения SADT диаграммы.

3. Опишите назначение и правила обозначения основных элементов такой диаграммы (работ, стрелок) и порядка их расположения.

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

5. Объясните что такое «тоннелирование стрелок». Какие типы тоннелирования бывают, для чего используются и как обозначаются в SADT диаграммах?

Лабораторная работа 3. Создание диаграммы узлов, FEO диаграммы, организационной диаграммы, расщепление и слияние моделей.

Теоретические сведения:

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

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

Слияние и расщепление моделей

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

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

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

Для слияния необходимо выполнить следующие условия:

• Обе сливаемые модели должны быть открыты в BPwin.

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

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

• Имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать.

• Модель-источник должна иметь, по крайней мере, одну диаграмму декомпозиции.

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

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

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

Выполнение работы:

Выберите пункт главного меню Diagram/Add Node Tree .

В первом диалоговом окне гида Node Tree Wizard внесите имя диаграммы, укажите диаграмму корня дерева и количество уровней.

Во втором диалоговом окне гида Node Tree Wizard установите опции, как показано ниже.

Щелкните по кнопке Готово (Finish). В результате будет создана диаграмма дерева узлов (Node tree Diagram):

Диаграмму дерева узлов можно модифицировать. Нижний уровень может быть отображен не в виде списка, а в виде прямоугольников, так же как и верхние уровни. Для модификации диаграммы правой кнопкой мыши щелкните по свободному месту, не занятому объектами, выберите меню Node tree Diagram Properties

и во вкладке Style диалога Node Tree Properties отключите опцию Bullet Last Level. Щелкните по ОК. Результат модификации диаграммы дерева узлов показан ниже:

Создание FEO диаграммы

Предположим, что при обсуждении бизнес-процессов возникла необходимость детально рассмотреть взаимодействие работы "Computer assembly and testing" с другими работами. Чтобы не портить диаграмму декомпозиции, создайте FEO-диаграмму(FEO – расшифровывается как «только для экспозиции»), на которой будут только стрелки работы "Computer assembly and testing".

Для этого выберите пункт главного меню Diagram/Add FEO Diagram

В диалоговом окне Add New FEO Diagram выберите тип и внесите имя диаграммы FEO как показано на рисунке. Щелкните по кнопке ОК.

Для определения содержания диаграммы перейдите в пункт меню Diagram/Diagram Properties и во вкладке Diagram Text внесите определение.

Удалите лишние стрелки на диаграмме FEO. Результат показан на рисунке.

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

Организационная диаграмма.

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

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

Создаем словарь Role Group:

Заполняем его и сохраним словарь.

Теперь создадим словарь Role.

Сохраним словарь.

По правилам AllFusion Process Modeler на организационной диаграмме могут отображаться:

• элементы словаря Role Group, если содержат хотя бы одну роль Role;

• элементы словаря Role, если они входят хотя бы в одну группу Role Group;

• элементы словаря Resource, если они приписаны хотя бы к одной роли (должности).

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

В нашем случае добавим в словарь Role элементы: Администрация, Отдел менеджмента, отдел сборки и тестирования (Engineering). Кроме этого для представления вершины иерархии добавим название предприятия Computer World в словарь Role Group и в словарь Role.

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

Создание первого варианта организационной диаграммы с помощью Мастера Organization Chart Wizard

В меню Diagram выберем Add Organization Chart. Запустится Мастер организационной диаграммы (Organization Chart Wizard).

В первом диалоге Мастера указать:

• Name - название организационной диаграммы,

• Role Group - название компании,

• Role - название компании

• Author - автор (см. диалог).

Нажать «Next»

Во втором диалоге Мастера пройтись по каждому подразделению (Group Role) и перетащить в список отображаемых элементов все имеющиеся роли. Выбранные роли отобразятся внизу диалога в виде "группа-роль" (см. диалог). Для этого надо нажать клавишу Shift и, удерживая ее, отметить все роли в этой группе.

Когда все роли будут собраны - нажать "Далее".

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

Нажать "Готово".

В результате сгенерируется 2-х уровневая оргструктура. На первом уровне - название организации, на 2-м уровне - названия всех подразделений и должностей. Все требуемые блоки организационной диаграммы отобразились в области диаграмм AllFusion Process Modeler.