Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

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




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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

 

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

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

 

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

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

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

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

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

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

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

 

 

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

 

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

 

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

 

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

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

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

 

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

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

 

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

 

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

 

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

 

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

 

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

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

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

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

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

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

 

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







Дата добавления: 2014-11-12; просмотров: 4503. Нарушение авторских прав


Рекомендуемые страницы:


Studopedia.info - Студопедия - 2014-2020 год . (0.009 сек.) русская версия | украинская версия