|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Поля заголовка каркаса (слева направо)
Таблица 3. Поля подвала каркаса (слева направо)
Значения полей каркаса задаются в диалоге Diagram Properties (меню Diagram - Diagram Properties).
Методология IDEF0
С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать «узкие места» в управлении и оптимизировать общую схему бизнеса. Понятие «моделирование бизнес-процессов» пришло одновременно с появлением программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Для моделирования сложных систем существуют проверенные методологии. К таким методологиям относится IDEF0 - методология функционального моделирования. С помощью графического языка IDEF0, изучаемая система изображается в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Графический язык IDEF0 использует четыре основных понятия: 1). Функциональный блок (Activity Box), который изображают как прямоугольник (Рис.12). Он обозначает конкретную функцию в рамках рассматриваемой системы. Название каждого функционального блока формулируют в глагольном наклонении (например, «оказать услуги»). Каждая из сторон функционального блока имеет определенное значение (роль):
Каждый функциональный блок в рамках единой системы должен иметь уникальный идентификационный номер.
Рис. 12. Функциональный блок.
2). Интерфейсная дуга (Arrow), которую также называют потоком или стрелкой. Интерфейсная дуга – это элемент системы, который обрабатывает функциональный блок или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графически интерфейсная дуга - однонаправленная стрелка. Каждая интерфейсная дуга имеет уникальное наименование (Arrow Label), которое должно быть оборотом существительного. Интерфейсные дуги отображают объекты, определяющие процессы, происходящие в системе. Такими объектами могут быть, например, детали и вагоны, сотрудники и потоки данных, документы и инструкции. В зависимости от стороны, с которой соединена интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». «Источником» и «приемником» каждой дуги могут быть только функциональные блоки. «Источником» может быть только выходная сторона блока (правая), а «приемником» любая из трех оставшихся. Функциональный блок по требованиям методологии должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Следует различать входящие и управляющие интерфейсные дуги. Существуют пять основных типов объектов, вызывающих сложность определения характера интерфейсных дуг: · материальные потоки (детали, товары, сырье и т.д.), · финансовые потоки (наличные и безналичные, инвестиции и т.д.), · потоки документов (коммерческие, финансовые и организационные документы), · потоки информации (информация, данные о намерениях, устные распоряжения и т.д.) · ресурсы (сотрудники, станки, машины и т.д.). В различных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими - только относящиеся к потокам документов и информации, а дугами-механизмами - только ресурсы. 3). Третьим понятием стандарта IDEF0 является декомпозиция (Decomposition). Этот принцип применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко понимаемой. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0». В пояснительном тексте к контекстной диаграмме указывают цель (Purpose) построения модели и точку зрения (Viewpoint). Цель определяет те области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Фиксация точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Цель должна отвечать на следующие вопросы: · Почему этот процесс должен быть смоделирован? · Что должна показывать модель? · Что может получить читатель? Примеры формулирования цели: · Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений, · Идентифицировать роли и ответственность служащих для написания должностных инструкций, · Описать функциональность предприятия с целью написания спецификаций информационной системы. Точка зрения (Viewpoint). Модель должна строиться с единой точки зрения. Ее можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Как правило, выбирают точка зрения человека, ответственного за моделируемую работу в целом. При выборе точки зрения документируют дополнительные альтернативные точки зрения на эту модель. Для этого используют диаграммы FEO (For Exposition Only). Для внесения области, цели и точки зрения в модели IDEF0 средствами AllFusion Process Modeler выбирают пункт меню Model - Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения (Рис. 13), а в закладку Definition - определение модели и описание области (Рис.14).
Рис. 13. Диалог Model Properties, закладка Purpose
Рис. 14. Диалог Model Properties, закладка Definition
В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source (Рис.15) описываются источники информации для построения модели (например, " Опрос экспертов предметной области и анализ документации" ).
Рис. 15. Диалог Model Properties, закладка Source
Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ (Рис.16).
Рис. 16. Диалог Model Properties, закладка General В процессе декомпозиции, функциональный блок контекстной диаграммы, отображающий систему как единое целое, детализируется на другой диаграмме. Диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему. Каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box. Функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели (Рис.17).
Рис. 17. Декомпозиция функциональных блоков
Каждый блок имеет уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Если такое обозначение отсутствует, то декомпозиция для данного блока не выполнена. В случаях, когда отдельные интерфейсные дуги не имеет смысла в дочерних диаграммах ниже или выше какого-то уровня в иерархии, используют понятие туннелирования. Его также применяют, когда нужно избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Обозначение «туннеля» (Arrow Tunnel) в виде двух скобок вокруг начала интерфейсной дуги обозначает, что она не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. Такое же обозначение вокруг конца стрелки вблизи от блока – приёмника означает, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Если отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, то они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля». 4). Последним понятием IDEF0 является глоссарий (Glossary). Для каждого элемента - диаграмм, функциональных блоков, интерфейсных дуг - создают и поддерживают набор определений, ключевых слов, повествовательных изложений, характеризующих объект, отображенный данным элементом. Этот набор называют глоссарий. Он описывает сущность данного элемента. IDEF0-модели содержат сложную информацию. Для ограничения перегруженности и удобства чтения в методологии приняты ограничения сложности: · На диаграмме может быть от трех до шести функциональных блоков. · Один функциональный блок соединен не более чем с четырьмя интерфейсными дугами.
Разработка IDEF0-модели
Процесс разработки модели итеративный и состоит из условных этапов: · Создание модели авторами (Authors). Построение модели – это динамический процесс, опроса авторами компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов авторы создают черновик модели (Model Draft). · Распространение, рассмотрение, согласование и комментирование черновика. На этой стадии читатели - компетентные лица обсуждают черновик модели. Письменно критикуется и комментируется, а затем передается автору каждая из диаграмм черновой модели. Автор же, письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению. · Официально утверждает модель руководитель рабочей группы. Он делает это, если у авторов модели и читателей нет разногласий. Окончательная модель - это согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели. Проведение обследования и разработка моделей позволяют отобразить механизм деятельности предприятия посредством построения функциональных диаграмм для каждого подразделения. Диаграммы должны отвечать на следующие вопросы: · Что поступает в подразделение «на входе»? · Какие функции, и в какой последовательности выполняются в рамках подразделения? · Кто отвечает за выполнение каждой функции? · Чем руководствуется исполнитель при выполнении каждой из функций? · Что является результатом работы подразделения «на выходе»? После согласования черновиков диаграмм внутри каждого подразделения, консультант собирает их в черновую модель предприятия. После устранения неувязок отдельных диаграмм и их спорных мест модель вновь проходит согласование и корректировку в функциональных отделах. В результате получается IDEF0-модель предприятия по принципу AS-IS «Как есть», Она представляет предприятие с позиции сотрудников, которые в нем работают. В дальнейшем эту модель будут анализировать и модифицировать аналитики, устраняющие «узкие места» в управлении компанией и оптимизирующие основные процессы. Итогом этого является модель ТО-ВЕ «Как должно быть». На ее основе рекомендуют пути реорганизации системы. Описание модели отражается в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools – Reports – Model Report ( Рис. 1 18).
Рис. 18. Вызов диалога настройки отчета модели
В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет. Соответствующими кнопками отчет можно просмотреть, распечатать или сохранить (Рис.19).
Рис. 19. Настройка отчета модели
После выполнения декомпозиции хотя бы контекстной диаграммы появляется возможность построить диаграмму дерева узлов. Она показывает иерархическую зависимость функциональных блоков с родительской диаграммой, но не взаимосвязи между работами. Диаграмм деревьев узлов в модели может быть любое количество. Диаграммы FEO строят для иллюстрации отдельных фрагментов модели, либо для показа альтернативной точки зрения. Функциональные блоки (Activity box) или «Работы» - это поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Их изображают в виде прямоугольников и они должны быть названы. Имя «работы» выражают глаголом, глагольной фразой или отглагольным существительным, обозначающим действие, например, «Изготовление детали», «Прием заказа». Каждый функциональный блок модели должен иметь определение (Definition). Например, функциональный блок «Изготовление детали» имеет следующее определение: «Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия».Для внесения имени (определения) работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name (Definition) и в появившемся диалоге Activity Properties внести имя (определение) работы ( Рис.20).
Рис. 20. Диалог «Свойства функционального блока»
Для создания новой модели надо выбрать пункт меню File/New. При этом автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. В результате заполнения имени и определения работы, вынесения на диаграмму интерфейсных дуг и присвоения им имен, в рабочей области появляется контекстная диаграмма ( Рис. 21).
Рис. 21. Контекстная диаграмма
Как уже отмечалось выше, контекстная диаграмма показывает взаимодействие системы с внешним миром в терминах управления, входов, механизмов и выходов. Следующим шагом в создании модели является детализация рассматриваемого функционального блока. Детализация осуществляется таким образом, чтобы на первой декомпозиции были отражены основные деятельности системы и их взаимосвязи. Для создания диаграммы декомпозиции в левом окне - Model Explorer – выбирают режим просмотра Activity, нажимают правую кнопку мыши и выбирают Decompose или, выделив мышкой работу, нажимают кнопку Рис.22).
Рис. 22. Создание дочерней диаграммы – декомпозиция
В диалоге Activity Box Count ( Рис. 23) указывают нотацию новой диаграммы и количество «работ» в ней.
Рис.23. Диалог выбора нотации числа работ для диаграммы декомпозиции
Появляется диаграмма декомпозиции. Допустимый интервал числа работ от 2 до 8. Для наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме. Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, выбрав в палитре инструментов кнопку Рис.24).
Рис. 24. Декомпозиция контекстной диаграммы В левом верхнем углу располагается самая важная функция или «работа», выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже функциональные блоки. Это облегчает чтение диаграмм и позволяет показать взаимосвязи «работ». Каждый из функциональных блоков на диаграмме любого уровня декомпозиции может быть в свою очередь декомпозирован. Диаграмма декомпозиции детализирует «работы» проектируемой системы. В отличие от моделей, отображающих структуру организации, «работа» на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими «работами». Функциональные блоки нижнего уровня - это те же «работы» верхнего уровня в более детальном изложении. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показан в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Взаимодействие функциональных блоков с внешним миром (на контекстной диаграмме) и между собой (на диаграммах декомпозиции) обозначается интерфейсными дугами. Стрелкам присваивают имена, обозначаемые существительными, например, «Заготовка», «Изделие», «Заказ». В IDEF0 различают пять типов стрелок: 1). Вход (Input) обозначает материал либо информацию. Они используются или преобразуются функциональным блоком для получения результата (выхода). Допускается, что «работа» может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего «работу», или выходит из нее. Стрелка входа примыкает к левой грани блока. 2). Управление (Control) – это правила или стратегии, процедуры или стандарты, инструкции или законы, которым подчиняется «работа». Каждая «работа» должна иметь хотя бы одну стрелку управления. Стрелка управления примыкает к верхней грани функционального блока. Управление влияет на «работу», но не преобразуется ею. Если данные изменяются после обработки функциональным блоком, то они обозначаются как вход. Если они остаются неизменными, то – как управление. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления. 3). Выход (Output) - материальный или виртуальный результат, производимый «работой». Функциональный блок должен иметь хотя бы одну стрелку выхода. «Работа» без результата не имеет смысла и не должна моделироваться. Стрелка выхода исходит из правой грани «работы». 4). Механизм (Mechanism) - ресурсы, выполняющие «работу», например персонал предприятия, станки, устройства. Стрелка механизма входит в нижнюю грань «работы». 5). Вызов (Call) - специальная стрелка, указывает на другую модель работы. Стрелка вызова исходит из нижней грани работы. Стрелка вызова указывает, что некоторая работа выполняется за пределами моделируемой системы. В AllFusion Process Modeler стрелки вызова используются в механизме слияния и разделения моделей. Граничные стрелки - это интерфейсные дуги на контекстной диаграмме. Они показывают взаимодействие системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Для внесения граничной стрелки входа следует: · щелкнуть на панели инструментов по кнопке с символом стрелки · перенести курсор к левой стороне экрана, пока не появится начальная темная полоска (Рис. 25а); · щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части блока со стороны входа (Рис. 25б);
а) б) Рис. 25. Создание стрелки входа · на панели инструментов выбрать кнопку редактирования стрелки · щелкнуть правой кнопкой мыши на линии стрелки, выбрать в контекстном меню Name (Definition) и добавить имя (определение) стрелки. Стрелки управления, выхода, механизма и вызова изображаются аналогично. Имена и определения вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary) (Рис. 26).
Рис. 26. Вызов словаря стрелок Словарь (Dictionary) в программе AllFusion Process Modeler решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т.е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик - автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а, чтобы не возникло неоднозначных трактовок, в словаре каждому понятию можно дать расширенное и, если это необходимо, формальное определение. Для того чтобы просмотреть или редактировать содержимое словаря, необходимо выбрать пункт меню Dictionary и далее необходимый объект, например, стрелки ( Ошибка! Источник ссылки не найден. ). Содержимое словаря можно распечатать в виде отчета. Для этого надо выбрать пункт меню Tools – Reports и далее необходимый вид отчета. Например, чтобы распечатать словарь стрелок надо выбрать пункт меню Tools – Reports – Arrow Report и получить толковый словарь терминов предметной области, использующихся в модели. При декомпозиции функционального блока входящие в него и исходящие из него стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (правило миграции стрелок), но при этом они не касаются «работ». Такие стрелки называются несвязанными (Рис. 27).
Рис. 27. Пример несвязанных стрелок
Для связывания стрелок входа, управления или механизма необходимо перейти в режим их редактирования. Затем щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту «работы». Для связывания стрелки выхода в режиме редактирования, щелкают по сегменту выхода «работы» и затем по стрелке. Для связи работ между собой используются внутренние стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются у одного и кончаются у другого функционального блока. Для рисования внутренней интерфейсной дуги необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной «работы» и затем по сегменту (например, входа) другой «работы». В IDEF0 различают пять типов связей «работ». 1). Связь по входу (output-input), когда стрелка выхода вышестоящей «работы» (выход) является входом нижестоящей (Рис. 28).
Рис. 28. Пример связи по входу
2). Связь по управлению (output-control), когда выход вышестоящей работы является управлением нижестоящей (Рис. 29).
Рис. 29. Пример связи по управлению
Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. 3). Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей (Рис. 30).
Рис. 30. Пример обратной связи по входу
Такая связь, как правило, используется для описания циклов. 4). Обратная связь по управлению (output-control feedback), когда выход нижестоящей «работы» направляется на управление вышестоящей (Рис. 31).
Рис. 31. Пример обратной связи по управлению
Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса. 5). Связь выход-механизм (output-mechanism) - это когда выход одной «работы» формирует механизм другой (Рис. 32).
Рис. 32. Пример связи выход-механизм Эта взаимосвязь используется реже остальных и показывает, что одна «работа» подготавливает ресурсы, необходимые для проведения другой «работы». Явная стрелка имеет источником одну единственную «работу» и назначением тоже одну единственную «работу». Разветвляющиеся и сливающиеся стрелки обозначают одни и те же данные или объекты, порожденные одной «работой», которые могут быть использованы сразу в нескольких других «работах». С другой стороны, стрелки, порожденные в разных «работах», могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки (Рис. 33). Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки. Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления. Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления.
Рис. 33. Примеры разветвляющихся и сливающихся стрелок
Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. Такая стрелка в AllFusion Process Modeler является синтаксической ошибкой. Правила именования сливающихся стрелок полностью аналогичны. Ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после этого вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Для их «перетаскивания» наверх нужно сначала щелкнуть по квадратным скобкам граничной стрелки правой кнопкой мыши и выбрать пункт меню Arrow Tunnel (Рис.34).
Рис. 34. Вызов диалога редактора граничных стрелок
Появляется диалог Border Arrow Editor (Рис. 35).
Рис. 35. Диалог Редактор граничных стрелок
Если включить опцию Resolve it to border arrow, стрелка мигрирует на диаграмму верхнего уровня, если же включить опцию Change it to resolved rounded tunnel, то стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце. Туннелирование может быть применено для изображения малозначительных стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется «не-в-родительской-диаграмме». Другим примером туннелирования может быть ситуация, когда стрелка мигрирует с верхнего уровня на нижний, причем на нижнем уровне эта стрелка используется одинаково во всех работах без исключения. В этом случае стрелка на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть туннелирована. Такое туннелирование называется «не-в-дочерней-работе». Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) «работа» дерева имеет номер А-0. «Работы» первой декомпозиции А0 имеют номера А1, А2, A3 и т. д. «Работы» декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, А33, А34.
Диаграммы дерева узлов
Диаграмма дерева узлов показывает иерархию «работ» в модели и позволяют рассмотреть всю модель целиком, но не показывает взаимосвязи (стрелки) между «работами» ( Рис. 36).
Рис. 36. Диаграмма дерева узлов
Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, AllFusion Process Modeler имеет мощный инструмент навигации по модели Model Explorer, который позволяет представить иерархию «работ» и диаграмм удобном и компактном виде, однако этот инструмент не является составляющей стандарта IDEF0. Для создания диаграммы дерева узлов следует выбрать в меню Diagram пункт Add Node Tree (Рис. 37).
Рис.37. Вызов диалога построения дерева узлов
Диалог формирования диаграммы дерева узлов предлагает два шага для настройки дерева узлов. В диалоге Node Tree Wizard на первом шаге указывают глубину дерева - Number of Levels (по умолчанию 3) и корень дерева (по умолчанию - родительская «работа» текущей диаграммы) ( Рис. 38).
Рис. 38. Два шага настройки дерева узлов
По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные «работы» - в виде прямоугольников. Для отображения всего дерева в виде прямоугольников на втором шаге следует выключить опцию Bullet Last Level (Рис. 39).
Рис. 39. Два шага настройки дерева узлов
При создании дерева узлов следует указать имя диаграммы. 2.5. Диаграммы " только для экспозиции" (FEO)
Эти диаграммы часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку являются просто картинками - копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, «работа» на диаграмме FEO может не иметь стрелок управления и выхода. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной «работой» и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Diagram – Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы ( Рис. 40).
Рис.40. Диалог создания диаграммы «только для экспозиции»
Новая диаграмма получает номер, который генерируется автоматически. Популярное:
|
Последнее изменение этой страницы: 2016-04-11; Просмотров: 1420; Нарушение авторского права страницы
на панели инструментов (
; 
