Далее рассмотрим стандартные методы системного структурного анализа, описанные серией федеральных стандартов США «Icam Definition », в соответствии с . Подробную информацию по всем стандартам этой серии можно найти на сайте http://www.idef.com.

Стандарт IDEF0 (FIPS183) предназначен для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Данный документ представляет собой оформление (по инициативе Министерства обороны США) в виде стандарта технологии анализа сложных систем SADT (Structured Analysis and Design Technique), разработанной группой американских аналитиков во главе с Дугласом Россом в 1973 году.

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

Методология IDEF0 основана на следующих положениях:

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

2. Блочное моделирование и его графическое представление . Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме (чаще говорят SADT-диаграмме), основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.

3. Строгость и формализм . Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже с точки зрения технологии SADT. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.

4. Итеративное моделирование . Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.

5. Отделение «организации» от «функций» . При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во-вторых – предложить решения, направленные на совершенствование этой структуры.

Примеры задач, решаемых на основе методологии моделирования IDEF0:

Анализ и реинжиниринг бизнес-процессов.

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

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

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

Задачи анализа рисков в плане информационной безопасности.

Рассмотрим в соответствии с работой принципы построения диаграмм по технологии SADT (IDEF0).

Графический язык SADT прост и гармоничен. В основе методологии лежат четыре основных понятия.

Первым из них является понятие «функциональный блок ». Функциональный блок графически изображается в виде прямоугольника (см. рис. 3.23) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги », а не «производство услуг »). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: верхняя сторона имеет значение «управление » (contr ol); левая сторона имеет значение «вход » (input ); правая сторона имеет значение «выход » (output ); нижняя сторона имеет значение «механизм » (mechanism ). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

16 сентября 2010 г. 13:08

«Divide et impera»
Максима римского сената

Шёл 1981 год, департамент ВВС США разрабатывал программу автоматизации промышленных предприятий, которая сокращённо называлась ICAM (Integrated Computer Aided Manufacturing ). Для успешного хода проекта необходимо было уметь моделировать автоматизированное предприятие всем участникам параллельно. Специально для этих целей был разработан набор стандартов IDEF (ICAM DEFinition ). Одним из стандартов набора являлась нотация функционального моделирования под кодовым названием IDEF0 , которая слегка видоизменялась с ходом времени, и спецификация для последней на данный момент версии была выпущена в декабре 1993 года.
Расскажу немного об особенностях процесса функционального моделирования бизнес-процесса с помощью нотации IDEF0 и одновременно помогу упомянутому мною в предыдущей статье Аристарху Григорьевичу: опишу бизнес-процесс приготовления борща.

Функциональное моделирование начинается с того, что выделяется основная задача, которая решается путём выполнения этого бизнес-процесса. В нашем случае эта задача формулируется следующим образом: «Приготовить борщ». Мне кажется, что эффективнее начинать процесс моделирования с того, что определить, какими данными и материалами мы обладаем до выполнения бизнес-процесса (Входные данные / Input), а также чётко уяснить, что мы хотим получить в результате выполнения бизнес-процесса (Выходные данные / Output). Это позволит выявить чёткие требования к бизнес-процессу и отбросить несбыточные надежды: обладая лишь горсткой сомнительного происхождения камней невозможно получить золотые слитки. В случае приготовления борща на входе имеются, например, овощи и мясо (их может, конечно, и не быть, но допустим, что все продукты были предусмотрительно закуплены). На выходе мы должны вполне логично получить борщ.

Нотация IDEF0 предполагает также, что для проведения функционального моделирования нужно выделить так называемый механизм (mechanism), т.е. тех исполнителей, которые будут задействованы в бизнес-процессе. В нашем примере в качестве механизма выступает собственно Аристарх Григорьевич ну и, скажем, его старший сын Коля. Правильное выполнение процесса должно чем-то контролироваться (какими-то стандартами, методиками, технологиями и проч.). Это что-то в нотации IDEF0 называется «управлением» (control) и обязательно должно фигурировать на функциональной диаграмме.

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

Рис. 1. Контекстная диаграмма

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

Контекстная диаграмма не даёт полного видения процесса, а лишь общий взгляд. Для того, чтобы просмотреть последовательность выполнения процесса, нужно подкрутить колёсико микроскопа: декомпозировать диаграмму, т.е. дать чуть более детальное описание процесса. Мне всегда было удобнее разбивать гигантскую общую задачу на 4-5 более мелких, примерно равной степени детализации. Задачи эти могут быть как последовательными, так и параллельными по времени их выполнения. Скажем, в случае приготовления борща эти задачи сводятся к: приготовлению бульона, подготовке овощей, собственно варке и подаче блюда на стол. Понятно, что готовить бульон и подготавливать овощи можно одновременно, а вот подать борщ до того, как он заправлен, уже получится плохо. Получим диаграмму, например, такую, как показано на рисунке 2.

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

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

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

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

В следующих сериях вас ждут захватывающие истории о нотациях BPMN, EPC и UML.

(4,77 - оценили 43 чел.)

Цель работы:

• изучение основных принципов методологии IDEF0,
• создание нового проекта в BPWin,
• формирование контекстной диаграммы,
• проведение связей.

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

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

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

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

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

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

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

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

Типы стрелок

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

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

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

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

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

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

Рис. 2.1 Типы стрелок

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

Рис. 2.2. Связь по выходу

Рис. 2.3. Связь по управлению

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

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

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

Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.

Рис. 2.4. Обратная связь по входу

Рис. 2.5. Обратная связь по управлению

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

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

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

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

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

Рис. 2.6. Связь выход-механизм

• непомеченные ветви содержат вес объекты, указанные в общей меткедуги после слияния;
• помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,

Количественный анализ диаграмм

Для проведения количественного анализа диаграмм перечислим показатели модели:

• количество блоков на диаграмме - N;
• уровень декомпозиции диаграммы - L ;
• сбалансированность диаграммы - В;
• число стрелок, соединяющихся с блоком, - А

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

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

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

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

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

После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C - произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.

Инструментарий BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).

Рис.2.8 Диалог создания модели

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

Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Пример

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

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

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

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

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

Контекстная диаграмма

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

Рис 2.9. Контекстная диаграмма системы

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

• Определение уровня доступа в систему.
• Выбор подсистемы.
• Обращение к подсистеме.
• Изменение БД (при необходимости).

Получим диаграмму, изображенную на рис. 2.10.

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

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

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

Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»

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

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

• Открытие БД.
• Выполнение запроса.
• Генерация отчетов.

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).

Необходимо отметить, что в «Выполнение запроса» включается работа различных подсистем. Например, если запрос включает в себя тестирование, то его будет исполнять подсистема профессиональных и психологических тестов. На этапе выполнения запроса может потребоваться изменениесодержимого БД, например при составлении экспертных оценок. Поэтому, на диаграмме необходимо предусмотреть такую возможность.

Рис. 2.12.

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

При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.

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

Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 - 2.15).

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

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

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

• БД пользователей,
• БД студентов,(вариант 2)
• БД вакансий,
• БД успеваемости,
• БД тестов,
• БД экспертных оценок,
• БД резюме.

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

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

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

Рис. 2.16. Декомпозиция работы «Изменение БД»

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12

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

Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента К b у двух вариантов моделей.

для второго варианта

Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

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

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

Список Контрольных вопросов :

1. Что представляет собой модель в нотации IDEF0?
2. Что обозначают работы в IDEF0?
3. Назовите порядок наименования работ?
4. Какое количество работ должно присутствовать на одной диаграмме?
5. Что называется порядком доминирования?
6. Как располагаются работы по принципу доминирования?
7. Каково назначение сторон прямоугольников работ на диаграммах?
8. Перечислите типы стрелок.
9. Назовите виды взаимосвязей.
10. Что называется граничными стрелками?
11. Объясните принцип именования разветвляющихся и сливающихся стрелок.
12. Какие методологии поддерживаются BPWin?
13. Перечислите основные элементы главного окна BPWin.
14. Опишите процесс создания новой модели в BPWin.
15. Как провести связь между работами?
16. Как задать имя работы.
17. Опишите процесс декомпозиции работы.
18. Как добавить работу на диаграмму?
19. Как разрешить туннелированные стрелки?
20. Может ли модель BPWin содержать диаграммы нескольких методологий?

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

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (Рис. 3.).

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

Верхняя сторона имеет значение "Управление" (Control);

Левая сторона имеет значение "Вход" (Input);

Правая сторона имеет значение "Выход" (Output);

Нижняя сторона имеет значение "Механизм" (Mechanism).

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

Рис. 3. - Функциональный блок

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

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

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

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

Рис. 4. - Схема декомпозиции функциональных блоков модели

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

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

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

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

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

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме.

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

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

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

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

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

При этом их интересуют ответы на следующие вопросы:

Что поступает в подразделение "на входе"?

Какие функции и в какой последовательности выполняются в рамках подразделения?

Кто является ответственным за выполнение каждой из функций ?

Чем руководствуется исполнитель при выполнении каждой из функций ?

Что является результатом работы подразделения (на выходе)?

На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

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

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

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

Условные обозначения формата IDEF0 представлены в таблицах 2,3.

Таблица 2. - Графические символы нотации IDEF0

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

Таблица 3. - Графические символы нотации IDEF0

1. Функциональное моделирование информационной системы с использованием CASE-технологии IDEF.
2. Описание логики взаимодействия и последовательности выполнения работ.

2. План занятия

1. Контроль знаний путем тестирования (тест ИСЭ002).
2. Разработка многоуровневой модели деятельности информационной системы (модель AS - IS) с помощью CASE-средства BPwin с использованием технологий IDEF 0 и IDEF 3 :
   • Описание свойств модели (Model Properties).
   • Создание ПЕРВОГО уровня функциональной модели – разработка контекстной диаграммы.
   • Создание ВТОРОГО уровня функциональной модели – проведение детализации контекстной работы и разработка диаграммы декомпозиции.
   • Создание ТРЕТЬЕГО уровня функциональной модели – проведение детализации работы второго уровня, реализующей функцию Учет деятельности организации. Выполнение данного этапа разработки допускает создание диаграммы декомпозиции с использованием одной из двух методологий – IDEF 0 (1-й вариант) или IDEF 3 (2-й вариант). По 2-му варианту создание сценария и диаграммы последовательности выполнения отдельных работ (Workflow Diagram) в процессе учета деятельности выполняется с использованием методологии IDEF 3.
3. Разработка словаря работ и словаря стрелок, которые позволяют отобразить описание соответствующих фрагментов модели.

1. Функциональное моделирование информационной системы с использованием технологии IDEF необходимо проводить, используя CASE-средство BPwin , которое загружается командой Пуск/Программы/Computer Associates/BPwin 4.0/BPwin4.0 . Технологические процессы IDEF-моделирования изложены в разделе 4 «Теоретические сведения к практическому занятию».
2. Разрабатывая контекстную диаграмму, следует учитывать, что свойства модели можно оформить следующим образом, используя сведения соответствующие моделируемой предметной области:
   • Model Name : Деятельность фирмы «Имя»;
   • Project (название проекта): Модель деятельности фирмы «Имя»;
   • ФИО, группа;
   • Scope (область моделирования, включающая цель моделирования, т.е. вопросы, на которые построенная модель должна дать ответ) – например, «Общее управление бизнесом компании: исследование рынка, закупка компонентов, тестирование и продажа продукции» или «Технологические, финансовые и управленческие аспекты деятельности фирмы»;
   • Time Frame (тип модели) : AS-IS;
   • Definition (определение , назначение модели) : Учебная модель, описывающая деятельность фирмы «Имя»;
   • Viewpoint (точка зрения – лицо, чья точка зрения принята при разработке) : Руководитель предприятия и главный менеджер;
   • Status : WORKING;
   • Purpose (цель) : Моделировать текущие бизнес-процессы фирмы «Имя» с целью регламентации ее деятельности;
   • Source (источник информации) : Анализ предметной области и анализ входных документов;
   • Author Name : ФИО.
3. При выполнении декомпозиции контекстной диаграммы следует учитывать, что она, являясь вторым уровнем декомпозиции модели системы, представляет собой подпроцесс или дочернюю работу , реализованную в виде контекстной работы, которая в этом случае выступает как родительская работа , реализованная в виде родительской диаграммы (Parent Diagram ) . Диаграмма декомпозиции второго уровня должна содержать не менее трех функциональных блоков, один из которых должен выполнять функцию моделирования учета деятельности организации, а остальные должны выполнять функцию моделирования бизнес-процессов , реализуемых в системе.
4. На каждом шаге декомпозиции следует следить за процессом автоматического перемещения интерфейсных дуг (стрелок) на нижние уровни модели и стараться без необходимости не допускать создания туннелированных стрелок. В случае их появления следует убирать туннели.
5. При реализации третьего уровня декомпозиции следует учитывать, что каждая из разработанных диаграмм декомпозиции является третьим уровнем декомпозиции работ второго уровня и представляет собой подпроцесс или дочернюю работу, реализованную в виде дочерней диаграммы (Child Diagram) соответствующей работы третьего уровня. Все работы второго уровня в этом случае выступают как родительские работы , реализованные в виде родительских диаграмм (Parent Diagrams ).
6. Декомпозицию работы второго уровня, моделирующей функцию учета, и создание сценария взаимодействия работ следует выполнять, используя технологию IDEF 3, которая использует в качестве функциональных блоков единицы работы (Unit of Work, UOW ) , а также и необходимые объекты ссылок (Referents) , которые могут быть как внедрены в сценарий из словаря стрелок, так и созданы заново.
7. Словарь работ и словарь стрелок создаются на каждом уровне декомпозиции модели, причем необходимым условием их разработки является наличие описания работы (activity) и описания данных, зафиксированных на интерфейсной дуге (arrow ) .
8. Результаты работы сохранить в файле Функц_модель ИС_Имя_ IDEF.bp1 в своей папке ИСЭ .
9. Пример обобщенной функциональной модели приведен в

4. Теоретические сведения к практическому занятию

4.1. IDEF 0-технология

Методология IDEF0 предназначена для моделирования деятельности организации. На начальном этапе разработки проекта создается модель, предназначенная для описания существующих бизнес-процессов и технологических процессов на предприятии по принципу «AS - IS» («Как есть»), причем, что немаловажно, она представляет предприятие с позиции сотрудников, которые на нем работают и досконально знают все нюансы, в том числе и неформальные. AS-IS – «что мы делаем сегодня», перед тем, как перепрыгнуть на то, «что мы будем делать завтра».

Модель деятельности или, иначе говоря, функциональная модель. Функциональная модель рассматривает систему как набор действий, в котором каждое действие преобразует некоторый объект или набор объектов . Технология IDEF 0 использует принцип функциональной декомпозиции систем (разбиение системы на фрагменты). Принцип декомпозиции означает, что функциональную модель следует строить по правилу «сверху вниз» , от общего вида модели к частным моделям. Поэтому обычно функциональная модель решения задачи представляет собой совокупность частных функциональных моделей .

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

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

Функциональный блок

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

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

• Верхняя сторона – управление.
• Нижняя сторона – механизм.
• Правая сторона – выход.
• Левая сторона – вход.

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

Интерфейсная дуга

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

Имя стрелки указывает ее роль (совокупность возможных ролей обозначается – ICOM ):

Вход функционального блока – I nput .

Управление – C ontrol .

Выход функционального блока – O utput .

Механизм – M echanism .

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

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

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

Выход (Output) – материал или информация, которые производятся работой. Обязательна хотя бы одна стрелка выхода, исходящая из правой грани работы.

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

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

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

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

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

Создание диаграмм в технологии IDEF0

При разработке модели деятельности организации следует использовать три типа диаграмм:

• I тип диаграммы – Контекстная диаграмма (может быть только одна) – вершина древовидной структуры, которая представляет собой наиболее абстрактный уровень описания системы и ее взаимодействие с внешней средой. В ней определена контекстная функция ;
• II тип диаграммы – Диаграмма декомпозиции .

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

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

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

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

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

4.2. Технологический процесс IDEF0-моделирования:

Рис. 2.2

CASE-средство BPWin имеет простой и понятный пользовательский интерфейс для построения требуемых функциональных моделей и сценариев. Он зависит от используемой технологии. На рис. 2.2 показано окно BPWin (Computer Associates BPWin ).

Основная панель инструментов окна Computer Associates BPwin содержит следующие кнопки:

	– создание новой модели,
	– открытие имеющейся модели,
	– сохранение построенной модели,
	– печать модели,
	– выбор масштаба,
	– масштабирование,
	– проверка правописания,
	– включение/выключение навигатора модели,
	– включение/выключение Model Mart.

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

Панель специальных инструментов содержит следующие основные кнопки:

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

Подготовка модели

1. Нажать кнопку создания модели для вызова окна диалогового окна BPWin (рис. 2.3):

В диалоговом окне BPWin произвести следующие действия:

• выбрать Business Process (IDEF0) ;
• задать имя модели и нажать кнопку ОК ;
• в окне Properties for New Model зафиксировать фамилию автора модели;
• нажать кнопку ОК .

1. Командой Model/Model Properties вызвать диалоговое окно Model Properties (рис. 4), в котором оформить свойства модели в соответствии с методическими рекомендациями, изложенными в разделе 2.

Первый уровень моделирования

1. Оформить функциональный блок в окне модели, выполнив следующие действия:
   • в контекстном меню функционального блока выбрать команду Name … ;
   • в диалоговом окне Activity Properties (рис. 2.5) в закладке Name задать имя работы (краткое), помещаемой в данный функциональный блок, а в закладке Definition в поле Definition описание работы;
   • в закладке Font задать шрифт Arial Cyr и установить флажки, позволяющие использовать этот шрифт во всех функциональных блоках диаграммы (All activities in this diagram, All activities in this model и Change all occurrences of this font in the model ), после чего нажать кнопку ОК .

• в диалоговом окне Arrow Properties (рис. 2.7), в закладке Name задать имя стрелки (краткое), а в закладке Definition в поле Definition вписать достаточно подробное описание назначения этой стрелки;

• в контекстном меню стрелки выбрать команду Font … ;
• в диалоговом окне Arrow Properties (рис. 2.8), в закладке Font задать шрифт Arial Cyr и установить флажки, позволяющие использовать этот шрифт для всех стрелок диаграммы (All Arrows in this diagram, All Arrows in this model, All instances of this Arrow и Change all occurrences of this font in the model );

1. Оформить стрелку Выход, левые границы правыми ;
2. Оформить стрелку Управление , для чего повторить п. 2, заменив левые границы верхними ;
3. Оформить стрелку Механизм, для чего повторить п. 2, заменив левые границы нижними .

Второй уровень моделирования

Любой уровень моделирования

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

• активизировать щелчком конкретный функциональный блок;
• повторить п. 3 для текущего уровня модели.

1. Тип и стиль оформления стрелки можно выбрать в диалоговом окне Arrow Properties (рис. 2.9), вызываемом командой Style из контекстного меню стрелки.

1. Для установки переноса по словам следует, выделив название, уменьшить размер прямоугольника, после чего он автоматически увеличится книзу.
2. Каждая стрелка, нарисованная на диаграмме высшего уровня, должна обязательно присутствовать на диаграмме более низкого уровня.
3. Новая стрелка, нарисованная на диаграмме низкого уровня (неразрешенная (unresolved ) стрелка), помещается в квадратные скобки (туннели), которые подчеркивают отсутствие такой стрелки на более высоком уровне. Чтобы убрать туннели следует:
   • выбрать пункт меню Arrow Tunnel ;
   • в диалоговом окне Border Arrow Editor (Редактор граничных стрелок) выбрать опцию Resolve it to Border Arrow (Разрешить как граничную стрелку). В результате туннель на текущем уровне будет убран, а стрелка появится на предыдущем уровне, причем если он не первый, то она – туннелированная (рис. 2.10).

1. Чтобы копировать туннелированные стрелки с нижнего уровня на верхний следует:
   • щелкнуть правой клавишей мыши по квадратным скобкам;
   • выбрать пункт меню Off Page Reference ;
   • в диалоговом окне Off_Page Arrow Reference выбрать диаграмму, на которую следует поместить стрелку и установить требуемый переключатель типа стрелки (рис. 2.11);

• нажать одну из кнопок: ОК and Go To Diagram (перейти к выбранной диаграмме) или ОК and Remain In Current Diagram (остаться в текущей диаграмме).

Недопустимо оставление несвязанных граничных стрелок (unconnected border arrow ) – стрелок, автоматически переносимых в диаграмму декомпозиции из родительской диаграммы (режим миграции стрелок). Эти стрелки не касаются работ и должны быть связаны с работами в режиме Создание стрелок (Precedence Arrow Tool – ).

Оформление правильного расположения и начертания стрелок по умолчанию:

• выполнить команду Model/Model Properties ;
• в окне Model Properties (рис. 2.12) выбрать закладку Layout ;
• установить флажок (опцию) Automatically space arrows в группе Arrows

1. При создании стрелки обратной связи по управлению следует установить опцию указания направления стрелки Extra Arrowhead (из контекстного меню).
2. Если надписи на стрелках расположены неудачно (очень далеко и т. п.), следует установить флажок Squiggle (в контекстном меню) для выноски надписи.

1. В диаграмме декомпозиции слева вверху располагается функциональный блок, в котором помещается наиболее важная и выполняемая первой работа. Последовательно вниз идут работы менее важные или выполняемые позже.
2. Перенос по словам внутри работ производится в режиме Name Editor … нажатием клавиши Enter .
3. Диагональ в левом верхнем углу прямоугольника означает, что соответствующая работа не декомпозирована.
4. Чтобы показать не только номера дочерних работ, которые появляются автоматически, но и префиксы (А), следует выбрать команду Model/Model Properties, закладку Numbering, флажок (опция) Show prefix (рис. 2.13).

1. Чтобы у дочерних работ показать номера работ и номера уровней (двух-, трех-, четырехзначные номера) следует выбрать команду Model/Model Properties, закладку Numbering, флажок (опция) Use diagram numbering format (рис. 2.13).
2. Чтобы различить разные версии одной и той же диаграммы, отдельным версиям следует присвоить номера (C - number), задаваемые произвольно в меню Diagram Properties на закладке Kit.

Построение дерева модели

• командой Diagramm/Add/Node Tree вызвать диалоговое окно Node Tree Wizard_Step 1 of 2 (рис. 2.14);
• провести диалог, выбрав нужное количество уровней дерева узлов (Number of levels );
• нажать кнопку Готово.

4.3. IDEF3-технология

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

Технология IDEF3 использует категорию сценариев для упрощения структуры описаний сложного многоэтапного процесса. Сценарий ( Scenario) – это повторяющаяся последовательность ситуаций или действий, которые описывают типичный класс проблем, присутствующих в организации или системе, а также – это описание последовательности свойств объекта в рамках рассматриваемого процесса. IDEF0-модели связаны с IDEF3-сценариями, так как каждая IDEF0-модель может быть представлена в виде одного или нескольких IDEF3-сценариев.

Технология IDEF3 предназначена для обеспечения сбора данных о процессе и позволяет:

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

Сценарий в IDEF3-технологии

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

При использовании IDEF3-технологии в основе всех построений лежат два типа диаграмм:

1. Диаграмма описания последовательности этапов процесса.
2. Диаграмма состояний объекта.

Используются следующие стандартные условные обозначения:

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

Регламентация последовательности выполнения единиц работы осуществляется внедрением в диаграмму перекрестков (Junction ) разного назначения.

Символ J перекрестка может принимать одно из следующих значений:

• & – слияние результатов всех действий, если стрелки входят в перекресток; запуск всех действий, если стрелки выходят из него;
• О – слияние результатов действий, если хотя бы одно из входных действий завершено; запуск хотя бы одного действия;
• Х – слияние только одного действия из ряда входящих в перекресток; запуск только одного действия из выходящих из него.

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

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

	Работа 3 происходит, когда выполнены Работа 1 и Работа 3
	Работа 1 и Работа 2 происходят вместе
	Работа 3 происходит, когда выполнены Работа 1 или Работа 2, или обе вместе
	Работа 1 и Работа 2 происходят вместе или отдельно
	Работа 3 происходит, когда выполнены Работа1 или Работа 2
	Происходит Работа 1 или Работа 2

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

4.4. Технологический процесс IDEF3-моделирования

Подготовка модели

1. Нажать кнопку создания модели.
2. В диалоговом окне BPWin выполнить следующие действия:
   • выбрать Process Flow (IDEF3) ;
   • задать имя модели;
   • нажать кнопку ОК ;
   • в диалоговом окне Properties for New Model подтвердить указанные там свойства.

Оформление действия

1. Нажать кнопку создания действия (Activity Box Tool ).
2. В нужном месте окна модели щелкнуть левой клавишей мыши.
3. В контекстном меню действия выбрать команду Name …
4. В диалоговом окне Activity Properties , в закладке Name задать имя действия (рис. 2.16).

1. В диалоговом окне Activity Properties в закладке Font задать Arial Cyr, ОК .

Оформление данных

1. Нажать кнопку создания данных. (Referent Tool ).
2. В нужном месте окна Referent щелкнуть левой клавишей мыши, чтобы внедрить имена данных из созданного словаря сущностей (опция Entity ) или из созданного словаря стрелок (опция Arrow ), или создать их заново (опция Other ) (рис. 2.17).

1. В диалоговом окне Referent Properties (рис. 2.18), в закладке Font задать Arial Cyr установить нужные флажки и нажать кнопку ОК .

5. Домашнее задание к следующему занятию

1. Продумать и определить материальные объекты или физические лица, представляющие собой источники или приемники информации (внешние сущности).
2. Продумать и разработать реляционную модель данных, обрабатываемых информационной системой:
   • составить список сущностей и их атрибутов,
   • показать отношения между сущностями.
3. На основе разработанного технического задания продумать и предложить преподавателю названия отдельных работ, реализуемых в системе в процессе выполнения каждой из ключевых работ, помещенных в диаграмму декомпозиции второго уровня.
4. Выполнение п.п. 1–3 домашнего задания зафиксировать в файле с именем «Информация ко 3-му занятию.doc », выполненном в Word, и представить преподавателю.
5. Проработать раздел «Теоретические сведения к практическому занятию » практикума по 3-му занятию.

1.6. Фрагмент диаграммы дерева узлов (Node Tree Diagram) при выполнении декомпозиции блока учет деятельности по второму варианту (IDEF3)

Словарь работ (Activity Dictionary)

Name	Definition
	Анализ информации, считанной из БД, на удовлетворение заданным критериям
Анализ документов	Анализ сопроводительных и входящих документов на соответствие нормативам
Ведение БД	Выполнение операций обновления данных
ВЫПОЛНЯЕМАЯ РАБОТА	Имя контекстной функции, определяющей ЦЕЛЬ и ГРАНИЦЫ моделирования
Завершающая обработка	Принятие и формулировка решения (ПОЛОЖИТЕЛЬНОГО в случае удовлетворения данных заданным критериям и ОТРИЦАТЕЛЬНОГО в противном случае), а также со­здание и оформление необходимых документов
Контроль качества и тестирование	Работа, завершающая производственный процесс или процесс разработки
Обработка данных	Выполнение операций поиска и анализа данных и принятие решения на основе проведенного анализа
Обработка результатов контроля качества	Систематизация и анализ результатов на соответствие стандарту
Обработка результатов тестирования	Анализ результатов на исправность, надежность и живучесть
Оформление документов	Прием документов и выбор информации для занесения в базу данных
	Поиск данных в таблицах БД на основе запросов, созданных пользователем
Пополнение БД	Занесение новых данных в таблицы БД
Прием и регистрация документов	Прием и регистрация входящих сопроводительных документов
Производство или разработка	Наименование ключевого бизнес процесса компании (модель производственной части предметной области)
Работа на 1-м этапе бизнес-процесса1	Действие, обобщающее технологические операции на первой стадии производственного процесса
Работа на 2-м этапе бизнес-процесса1	Действие, обобщающее технологические операции на второй стадии производственного процесса
Работа на 3-м этапе бизнес-процесса1	Действие, обобщающее технологические операции на третьей стадии производственного процесса
Обработка результатов производственной деятельности	Прием и анализ документов по результатам выполнения текущих работ и контроля
Редактирование БД	Изменение записей в таблицах БД
УЧЕТ ДЕЯТЕЛЬНОСТИ	Обработка документации и ведение отчетности (модель непроизводственной части предметной области)

Словарь стрелок (Arrow Dictionary)

Name	Definition
	Объекты, не соответствующие требованиям стандарта
ВХОДНЫЕ ДАННЫЕ	Входящие документы и объекты обработки
Входные данные БД	Данные для записи в таблицы БД
Входящие документы	Документы, сопровождающие объекты обработки и документы, инициирующие бизнес-процесс
ВЫХОДНЫЕ ДАННЫЕ	Выходящие документы, новые и измененные объекты
Выходящие документы	Документы (бланки, отчеты, инструкции, ведомости, договора и т. п.), создаваемые в процессе учета
Государственный стандарт	Государственный стандарт на оформление документации
Данные таблиц БД	Данные, считываемые из таблиц БД
Данные, полученные в результате анализа	Информация, предназначенная для оформления выходящих документов и используемая при принятии решения
Данные, характеризующие результаты работы с документами	Информация, отражающая реквизиты (качественные и количественные характеристики) обрабатываемых объектов
Документы по результатам тестирования и контроля	Документы, отражающие данные, полученные на этапе завершающей стадии обработки объектов
Должностная инструкция	Инструкция, отражающая должностные обязанности исполнителя
Запросы пользователя
Новые и измененные объекты	Объекты, созданные и измененные в процессе реализации производственного цикла
Объекты БД	Таблицы, формы, запросы, отчеты, макросы и модули
Объекты обработки	Объекты, изменяемые на разных стадиях исполнения производственного процесса
Объекты, обработанные на 1-м этапе	Объекты, изменяемые на 1-м этапе производственного процесса
Объекты, обработанные на 2-м этапе	Объекты, изменяемые на 2-м этапе производственного процесса
Объекты, обработанные на 3-м этапе	Объекты, изменяемые на 3-м этапе производственного процесса
	Отдел технического контроля, проверяющий создаваемый объект на удовлетворение требованиям стандарта
Подразделения компании и специалисты-профессионалы	Субъекты, участвующие в производственном процессе или в процессе разработки
ПРАВИЛА ВЫПОЛНЕНИЯ	Правила преобразования процессов и данных
Правила учета	Система учета и оформления документации, сопровождающей производственный процесс или процесс разработки
ПРИНЯТОЕ РЕШЕНИЕ	Положительное или отрицательное решение, принимаемое в зависимости от удовлетворения анализируемых данных заданным критериям
Принятые документы	Документы, прошедшие регистрацию
Программное обеспечение	Платформа, на базе которой реализована разрабатываемая БД
Результаты анализа документов	Результаты, полученные после анализа входящих и сопроводительных документов на соответствие нормативам
Результаты контроля качества
Результаты поиска	Информация из таблиц БД, полученная по запросам пользователя
Результаты тестирования	Данные, полученные на завершающем этапе обработки
Руководство пользователя	Инструкции и правила для работы с БД
Служба учета	Подразделения, занятые процессом учета и оформления документации
Сопроводительные документы	Документы, сопутствующие входящим объектам обработки
Специалисты- профессионалы	Субъекты, участвующие в производственной деятельности
Технологическая инструкция	Последовательность операций технологического процесса
Запросы пользователя	Запросы, создаваемые пользователем для выборки необходимой информации из БД и для создания выходящих документов
МЕХАНИЗМ ИСПОЛНЕНИЯ	Ресурсы, выполняющие преобразование входных данных в выходные
Новые записи	Записи в таблицах БД, появившиеся после занесения новых данных
Коррекция
	Субъект, производящий экспертизу

Версия для печати