Моделирование бизнес-процессов

Глава 3 МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ 3.1. Виды моделей 3.1.1. Понятия модели и моделирования Человек формирует представление об объектах и явлениях окружающего мира в виде некоторых абстрактных структур в его сознании, которые он может воплощать и в виде материальных объектов, например, в виде макетов, чертежей, карт и т. д. Подобные абстрактные и материальные образы реальных объектов и называются моделью. Модель представляет искусственный, созданный человеком объект любой природы (умозрительный или материально реализованный), который замещает или воспроизводит исследуемый объект [16]. Модель не обязательно является объектом-заместителем реально существующего в материальной природе объекта-оригинала. Оригиналом может быть и представление человека о несуществующем (возможно, пока не существующем или вообще неосуществимом) объекте, явлении, понятии. Гипотезы, проекты, планы — это тоже модели. Человек использует модели в познавательной деятельности, а также для планирования, организации практической деятельности, потому что они позволяют в более наглядной, «выпуклой», 60 Глава 3. Моделирование бизнес-процессов структурированной форме представить знания. Можно говорить о модели как о способе существования знаний или структурированном знании. Процесс построения, изучения и применения моделей называется моделированием. Модель не тождественна оригиналу. Она соответствует оригиналу в каком-то определенном смысле и до определенной степени. Это упрощенный приближенный образ, отображающий оригинал лишь в конечном числе отношений. И дело не только в том, что, создавая модель, человек зачастую ограничен в ресурсах и времени. Дело в том, что человек формирует модель с какой-то целью, для решения определенной задачи, и при этом он сознательно отображает в модели только главные, наиболее существенные (с точки зрения решаемой им задачи) свойства оригинала и опускает ненужные детали, лишь отвлекающие от решения задачи. Модель является целевым отображением [6]. Для одного и того же объекта может быть построено множество различных моделей, отвечающих различным целям. Например, для дизайнера часов важна модель, отображающая форму, внешний вид часов, а для изучения принципов работы часов больше подходит модель в виде структурной схемы часов. На рис. 3.1 приведены обе этих модели. Датчик времени Индикатор Эталон времени а б Рис. 3.1. Различные модели часов: а — модель внешнего вида часов; б — структурная схема часов Приведенные на рисунке модели иллюстрируют два вида подобия. Если подобие модели внешнему виду часов на рис. 3.1, а можно считать прямым, то схема на рис. 3.1, б являет собой ус- Виды моделей 61 ловное подобие: прямоугольники с текстом внутри мы условились считать отображением подсистем часов, а линии со стрелками — отображением сигналов. Соответствие модели оригиналу называется адекватностью модели. Адекватность включает требования полноты и точности (правильности, истинности) модели. Однако поскольку модели в принципе ограничены (от них и не требуется полного подобия), то для того чтобы считать модель адекватной, вышеперечисленные требования должны выполняться в той мере, которая достаточна для достижения цели [6]. В конечном итоге истинность моделей всегда определяется практикой. Если применение знаний, полученных с помощью модели, в практической деятельности приносит ожидаемые результаты, то модель можно считать адекватной. Как и все в мире, модели проходят свой жизненный цикл: они возникают, развиваются, уступают место другим моделям. Процесс моделирования можно структурировать, выделив в нем этапы. Например, при проектировании сложной системы ее модель развивается от концептуальной до модели реализации. Таким образом, основными свойствами моделей являются:  конечность — модели отображают оригинал лишь в конечном числе его отношений;  упрощенность — модели отображают только существенные стороны объекта, действительность отображается моделями грубо или приблизительно;  адекватность — модели отражают моделируемую систему с достаточной полнотой и точностью;  динамичность — модели развиваются, уточняются, переходят одна в другую. 3.1.2. Классификация моделей Классифицировать модели можно по разным признакам. Рассмотрим некоторые из классификаций моделей, приведенные на рис. 3.2. Глава 3. Моделирование бизнес-процессов 62 Модели Познавательные Материальные Статические Нормативные Абстрактные Динамические Декларативные Содержательные Детерминированные Процедурные Формализованные Стохастические Рис. 3.2. Классификации моделей 1. В зависимости от реального существования объекта, отражаемого в модели (уже существующие объекты или объекты, которые должны быть осуществлены либо желательно их осуществить), выделяются следующие модели:  познавательные (объяснительные) модели, предназначенные для упорядочения и структурирования знания об исследуемом объекте, выявления взаимосвязей между компонентами, соотношений между характеристиками, закономерностей поведения и т. д.;  нормативные (прагматические) модели, являющиеся средством отображения идеального объекта или будущего результата некоторых практических действий. Это образец, эталон, стандарт или программа действий, план, алгоритм. Существуют разные градации нормативных моделей по степени приближенности — от эталонной, или референтной, модели, построенной для целого класса объектов, до модели конкретного объекта. Референтные модели (reference model, master model) служат основой для разработки более конкретных моделей. Так, референтной моделью бизнес-процесса называется модель эффективного делового процесса, созданная для предприятия конкретной отрасли, внедренная на практике и предназначенная для исполь- Виды моделей 63 зования при разработке (реорганизации) деловых процессов на других предприятиях. 2. В зависимости от учета в модели фактора времени, модели разделяют:  статические модели, не учитывающие временной фактор. Они отражают постоянные, устойчивые состояния объекта, его состав, структуру, устойчивые внутренние и внешние связи. Это как бы «моментальная фотография» объекта;  динамические модели, отражающие изменения объекта, происходящие с течением времени, — поведение объекта (изменение во времени его состояний), последовательность действий, операций, внутренних и внешних взаимодействий и т. д. При этом сама модель динамического процесса может быть статичной, не изменяющей своего состояния. Примеры таких моделей — календарный график работ, блок-схема алгоритма, формула изменения некоторой характеристики во времени. Однако существует класс динамических моделей, которые сами могут находиться в динамике. Это имитационные модели, имитирующие реальные процессы, например: действующая механическая модель солнечной системы; деловая игра, имитирующая какой-либо бизнеспроцесс; военные учения; компьютерная имитационная модель процесса обслуживания клиентов, «проигрываемая» с помощью специальной программы в сжатом режиме времени. 3. По способу воплощения модели подразделяются на классы материальных (реальных, вещественных) моделей и абстрактных (идеальных) моделей. Материальные модели построены из реальных объектов. К ним относятся, например, манекены, чучела животных, макеты зданий (кораблей, автомобилей, самолетов), тренажеры, имитирующие кабину машиниста поезда или салон автомобиля, и т. д. Абстрактные модели представляют собой идеальные конструкции, выполненные средствами мышления, сознания [6]. Модели этого типа могут не только находиться в сознании человека, они могут иметь материальное воплощение, с тем чтобы их можно было хранить и передавать от одного человека другому. 64 Глава 3. Моделирование бизнес-процессов Схемы, чертежи, диаграммы, формулы, таблицы, нарисованные на бумаге, напечатанные в книге, записанные в виде компьютерных файлов, — все это вещественные формы абстрактных моделей. Как правило, они описываются на каком-либо языке (естественном, математическом, графическом и др.), предполагающем наличие некоторых соглашений о том, из каких элементов (знаков) формируется модель, что обозначают эти элементы, по каким правилам строятся конструкции из элементов языка, как преобразовывать, использовать построенные конструкции и т.д. Абстрактные модели, в свою очередь, тоже могут быть классифицированы по различным признакам. Некоторые из них будут рассмотрены ниже. 4. В зависимости от представления в модели либо описания свойств объектов, либо описания действий объектов различают:  декларативные модели, в которых отражаются свойства, структуры, состояния (причем как в статике, так и в динамике);  процедурные модели, в которых находит отражение процедурное, операционное знание. 5. В зависимости от учета фактора случайности выделяют классы детерминированных и стохастических моделей. Первые отражают процессы и явления, не подверженные случайностям, вторые — случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями. 6. По степени абстрактности различают целый спектр моделей — от формализованных до слабоформализованных, или содержательных (семантических). Как правило, чем меньше семантики (смысла, содержания) отражается в модели, тем она более формализована. К сильноформализованным относятся математические модели. Они универсальны в том смысле, что одна и та же модель может описывать весьма различные физические процессы или может вообще не иметь смысловой интерпретации. В слабо формализованных, содержательных моделях сохраняется семантика моделируемого объекта. В этом смысле данные модели уникальны. Виды моделей 65 Примеры содержательных моделей: дерево целей, модель организационной структуры компании, блок-схема алгоритма. Основным преимуществом формализованных моделей является наличие формального аппарата оперирования моделью (поиска решений на модели). Однако многие объекты, процессы, явления с трудом поддаются формализованному описанию. Семантическую же модель в виде описания на естественном языке можно создать практически для любого объекта. 7. В зависимости от языка описания моделей различают аналитические, численные, логические, лингвистические, графические и другие модели. Каждый из языков имеет свой набор символов — условных обозначений, свои правила формирования модели и ее интерпретации. Остановимся подробнее на характеристике графических моделей, так как этот вид наиболее распространен при моделировании бизнес-процессов. Модель на графическом языке представляется в виде некоторого графического образа — в виде схемы, диаграммы, графика, гистограммы, чертежа. Основным достоинством подобных моделей является наглядность. Графические образы зачастую лучше воспринимаются и запоминаются, чем, скажем, формулы и тексты. Существуют различные методологии построения графических моделей, отличающиеся используемой ими нотацией. Нотация — система условных обозначений, принятая в конкретной модели [8]. Нотация графической модели предполагает наличие строго определенного набора взаимоувязанных графических изображений (геометрических фигур, пиктограмм) — элементов графического языка и правил их использования. К нотации модели предъявляются следующие основные требования [8]:  простота — простой знак при прочих равных условиях предпочтительнее сложного;  наглядность — хотя бы отдаленное сходство с оригиналом облегчает использование модели;  индивидуальность — достаточное отличие от других обозначений; 66 Глава 3. Моделирование бизнес-процессов  однозначность — недопустимость обозначения одним символом различных объектов;  единообразие — применение аналогичных правил при моделировании однородных объектов;  определенность — четкие правила использования модели;  учет устоявшихся традиций. В данном пункте рассмотрены универсальные классификации моделей. В различных областях теории и практики используются свои собственные классификации. В следующем пункте будут рассмотрены типы моделей, используемых при моделировании бизнес-процессов. 3.1.3. Классификация методологий моделирования бизнеса При моделировании бизнеса используются различные модели, отображающие следующие компоненты [8]:  функции, которые бизнес-система должна выполнять — что она делает, для кого, с какой целью;  процессы, обеспечивающие выполнение указанных функций, последовательность отдельных шагов процессов (работ, операций);  данные, необходимые при выполнении процессов, и отношения между этими данными;  организационные структуры, обеспечивающие выполнение процессов;  материальные и информационные потоки, возникающие в ходе выполнения процессов. Выделяют четыре основные группы методологий моделирования бизнеса (рис. 3.3): структурные, объектно-ориентированные, имитационные, интегрированные. В основе структурных методов моделирования бизнеса лежит декомпозиция системы на подсистемы, которые, в свою очередь, делятся на более мелкие подсистемы и т. д. Базовыми принципами структурного подхода являются [17]: Виды моделей 67  «разделяй и властвуй» — принцип решения сложных проблем путем их разбиения на множество мелких задач, легких для понимания и решения;  иерархическое упорядочивание — принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Методологии моделирования бизнеса Структурные IDEF Объектно-ориентированные IDEF1X IDEF3 DFD Имитационные GPSS Сети Петри OMT Booch OOSE UML Интегрированные SIMAN ARIS G2 BRM Рис. 3.3. Классификация методологий моделирования бизнеса Выделяются две группы структурных методологий: моделирующие функциональную структуру и моделирующие структуру данных. При моделировании бизнеса чаще используются функциональные модели. Главным структурообразующим элементом таких моделей является функция (действие, операция) [18]. Бизнес-процессы представляются на разных уровнях детальности в виде последовательности функций, с которыми связаны входные и выходные объекты (материальные, информационные) и используемые ресурсы (человеческие, технические). Наибольшее распространение получили следующие нотации структурного моделирования:  IDEF0 — функциональные модели, основанные на методе структурного анализа и проектирования SADT (Structured Ana-lysis and Design Technique) Дугласа Росса; 68 Глава 3. Моделирование бизнес-процессов  IDEF1X — модели данных, основанные на диаграммах «сущность-связь» (ERD, Entity-Relationship Diagrams);  IDEF3 — диаграммы потоков работ (Work Flow Diagrams);  DFD (Data Flow Diagrams) — диаграммы потоков данных. Методы объектно-ориентированного моделирования (ООМ) изначально создавались для разработки информационных систем, а именно для формирования моделей систем с целью их последующей реализации в виде объектно-ориентированных программ. Однако в дальнейшем методы ООМ стали применяться не только и не столько для программирования, сколько для анализа и перепроектирования бизнес-процессов. Главным структурообразующим элементом в объектно-ориентированном подходе является объект. В программировании объектом называется информационная структура, объединяющая данные (атрибуты) и процедуры. При моделировании бизнеса объектами являются, прежде всего, участники бизнес-процесса (активные объекты) — организационные единицы, конкретные исполнители, информационные системы, а также пассивные объекты — материалы, документы, оборудование, над которыми выполняют действия активные объекты [18]. Таким образом, в объектно-ориентированных методах модель бизнес-процессов строится вокруг участников процессов и их действий. Разные авторы создавали различные языки объектно-ориентированного моделирования, отличающиеся составом, видом диаграмм, используемыми обозначениями. Наиболее известными к середине 1990-х годов стали: метод Booch’93 Г. Буча, метод OMT (Object Modeling Technique) Дж. Румбаха и метод OOSE (ObjectOriented Software Engineering) А. Джекобсона. Авторы этих методов решили объединить свои представления и создать унифицированный метод, что и привело к появлению языка UML. Благодаря поддержке консорциума OMG этот язык стал фактически стандартом в области объектно-ориентированного моделирования. Имитационное моделирование — это имитация на компьютере (с помощью специальных программ) процесса функционирования реальной системы. Методы имитационного моделиро- Виды моделей 69 вания позволяют получить наиболее полную картину состояния процесса в любой момент времени. Они копируют бизнеспроцессы путем отображением «живой» картины процесса в режиме сжатого времени. В моделях можно задать временные и вероятностные параметры, например: время поступления заявки в систему, определяемое по некоторому закону распределения; время выполнения той или иной операции обработки заявки и др. К наиболее распространенным методам имитационного моделирования относятся:  сети Петри и модификация этого метода — раскрашенные сети Петри (CPN, Colored Petri Nets);  GPSS (General Purpose Simulating System) — унифицированный язык имитационного моделирования;  SIMAN (SIMulation ANalysis) — язык визуального моделирования. Интегрированные методы моделирования объединяют различные виды моделей, отражающие соответственно разнообразные аспекты системы. Так, популярная методология ARIS (Architecture of Integrated Information System) рассматривает деятельность предприятия с различных точек зрения, в частности, она предполагает отражение в единой интегрированной модели организационной структуры, функций, данных и процессов. Для описания различных аспектов бизнеса в ARIS используются множество типов моделей: дерево функций, событийно-ориентированная модель, диаграмма цепочек добавленной стоимости, модели производственного и офисного процессов и т. д. Ряд интегрированных методологий наряду с методами построения статических и динамических моделей использует методы интеллектуального моделирования (инженерии знаний, экспертных систем). Среди них можно назвать методологию создания динамических интеллектуальных систем G2, методологию управления бизнес-правилами (BRM — Business Rules Management). 70 Глава 3. Моделирование бизнес-процессов 3.2. Структурные методологии моделирования 3.2.1. Методология моделирования IDEF0 Начало разработке семейства методологий структурного анализа IDEF (Integration DEFinition) положил проект ICAM (Integrated Computer-Aided Manufacturing), предложенный в конце 1970-х гг. ВВС США. Цель проекта состояла в определении подходов, обеспечивающих повышение эффективности производства благодаря систематическому внедрению компьютерных технологий. Согласно проекту ICAM были разработаны три самостоятельные методологии IDEF0, IDEF1 и IDEF2 для создания соответственно функциональной, информационной и динамической моделей производственной системы. Данные методологии позднее дополнялись и модифицировались, в результате чего появился ряд усовершенствованных методологий IDEF. Методология IDEF0 является одной из самых известных и широко используемых методологий моделирования. Системные аналитики всего мира используют ее для решения широкого спектра проблем, включая разработку программного обеспечения, бизнес-анализ, проектирование, планирование и управление производственными системами, управление финансами и материально-техническими ресурсами, обучение персонала и т. д. Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований. При создании новых систем IDEF0 может применяться как для определения требований и функций, так и для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. При исследовании уже существующих систем IDEF0 может использоваться для анализа функций и механизмов их исполнения. IDEF0-модель использует графический язык для отражения информации о конкретной системе. Модель состоит из диа- Структурные методологии моделирования 71 грамм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения) [19]. Основной конструкцией модели является функциональный блок (activity — активность), представленный в виде прямоугольника и отображающий некоторую функцию (действие, процесс, операцию). Внутри блока записывается его наименование. Оно должно содержать глагол или отглагольное существительное. Например: «разработать проект», «изготовление продукта», «планирование». Дуги, изображаемые на диаграмме в виде линий со стрелками на конце, играют роль связей блоков с внешней для них средой. Каждая из дуг имеет метку, характеризующую ее. Назначение дуг зависит от стороны блока, в которую стрелка входит или выходит (рис. 3.4) [19]:  «вход» (I — input) — дуги, входящие слева от блока. Они представляют собой предметы или данные, необходимые для выполнения функции блока (сырье, материалы, исходная информация);  «выход» (O — output) — дуги, выходящие справа из блока. Они показывают предметы или данные, полученные в результате выполнения функции (продукция, услуга, выходные данные);  «управление» (C — control) — дуги, входящие сверху блока. Они описывают условия или данные, которые управляют выполнением функции (инструкции, требования, стандарты);  «механизм» (M — mechanism) — дуги, входящие снизу блока. Они обозначают исполнителей или средства, выполняющие функцию (персонал, подразделения фирмы, оборудование, инструменты, информационная система). Выход и вход показывают, что и из чего делается функциональным блоком, управление показывает, как и почему это делается, а механизм показывает, кем и с помощью чего это делается. Глава 3. Моделирование бизнес-процессов 72 Управление Входы Функциональный блок Выходы Механизм Рис. 3.4. Функциональный блок IDEF0-диаграммы Необходимо подчеркнуть, что дуги — это не обязательно входные или выходные потоки. Входящие дуги — это необходимые условия (ограничения), для того чтобы действие могло произойти, выходящие — результат действия. Например, оборудование, инструменты необходимы для изготовления изделия, однако они не обязательно должны поступать в систему, производящую изделие, так как уже могут находиться в системе. Функциональный блок может быть декомпозирован, т. е. представлен в виде совокупности других взаимосвязанных функциональных блоков, которые детально описывают исходный блок. Блоки, полученные в результате декомпозиции, вместе со связанными с ними дугами размещаются на отдельной диаграмме декомпозиции. При необходимости каждый из этих блоков также может быть декомпозирован, т. е. может породить свою «дочернюю» диаграмму декомпозиции. Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм (рис. 3.5). На диаграмме корневого уровня представлена вся система в виде одного блока и дуг, изображающих связи с внешним окружением. На диаграмме декомпозиции первого уровня система представлена более детально в виде совокупности блоковподмодулей, соединенных дугами друг с другом и с окружением. На диаграммах декомпозиции следующего уровня детализируются блоки диаграммы первого уровня и т. д. [19]. Структурные методологии моделирования 73 Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера узлов. Например, блок А0 на диаграмме верхнего уровня А-0 детализируется на диаграмме А0 совокупностью блоков А1, А2, А3, …(рис. 3.5). В свою очередь, блок А1 детализируется на диаграмме А1 совокупностью блоков А11, А12, А13, …, блок А2 детализируется на диаграмме А2 совокупностью блоков А21, А22, А23, … и т. д. Диаграмма А-0 А0 Диаграмма А0 С1 I1 ( ) А1 А2 М1 Диаграмма А1 I1 А11 А12 I2 O1 А3 I2 O1 А13 М1 Рис. 3.5. Иерархия диаграмм IDEF0-модели Глава 3. Моделирование бизнес-процессов 74 Каждая диаграмма обычно содержит 3–6 блоков, размещаемых по «ступенчатой» схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие. Построение модели начинается с диаграммы верхнего уровня A-0, называемой контекстной диаграммой. Помимо единственного блока, отображающего систему в целом, и дуг, связывающих систему с внешним окружением, контекстная диаграмма содержит описание цели моделирования и точки зрения, с которой разрабатывается модель (рис. 3.6). Цель указывает, для чего создается модель, а точка зрения — для кого (для какого должностного лица или подразделения организации). Спецификации ( ) Заявка Материалы Создание продукта Доставленный продукт Оборудование Персонал Цель: описать процесс создания продукта на заказ Точка зрения: аналитик Рис. 3.6. Пример контекстной диаграммы После разработки контекстной диаграммы проводят декомпозицию. Например, блок «Создание продукта» может быть расчленен на блоки «Прием заявки», «Изготовление продукта» и «Доставка продукта». Блоки, полученные в результате декомпозиции, размещаются на диаграмме декомпозиции первого уровня (рис. 3.7). Кроме того, на диаграмму декомпозиции с родительской (контекстной) диаграммы переносятся и дуги, связывающие родительский блок с окружением. Это внешние дуги, имеющие источник или получатель вне диаграммы. Структурные методологии моделирования I1 Прием заявки Заявка Деньги I2 75 Заказ А1 Изготовление продукта А2 Материалы Отдел приема заявок Цех Станок Продукт Доставка продукта Отдел доставки O1 А3 Доставленный продукт Транспорт M1 Персонал M2 Оборудование Рис. 3.7. Пример диаграммы декомпозиции Источники или получатели внешних дуг называются портовыми узлами. Для их обозначения используются специальные коды. В зависимости от того, является ли дуга, связанная с портовым узлом, входом, выходом, управлением или механизмом, код содержит одну из четырех букв: I (Input), C (Control), O (Output), M (Mechanism). Эти буквы сопровождаются номером (позиции дуг нумеруются слева направо или сверху вниз). Процесс перенесения дуг с родительской диаграммы на диаграммы декомпозиции (диаграммы-потомки) называется ICOM-кодогенерацией. С его помощью поддерживается связь между диаграммами-родителями и диаграммами-потомками и обеспечивается непротиворечивость модели [19]. На диаграмме декомпозиции можно отобразить внешнюю дугу, для которой на родительской диаграмме нет соответствующей дуги, и наоборот, можно на родительской диаграмме отобразить дугу, которая не будет отображаться на дочерней диаграмме. Такие дуги называются «туннельными». Вокруг одного из концов такой дуги изображаются круглые скобки («туннель»). 76 Глава 3. Моделирование бизнес-процессов Туннель возле свободного конца дуги показывает, что этой стрелки нет на диаграмме-родителе, т. е. на верхнем уровне декомпозиции эта стрелка неважна. Туннель у блока говорит о том, что эта стрелка не важна на диаграмме-потомке и там она не отобразится. Рассмотрим перенос внешних дуг на примере моделей, приведенных на рис. 3.6 и 3.7. Блок А0 на контекстной диаграмме (см. рис. 3.6) связан с шестью дугами — двумя входами, одним выходом, одним управлением и двумя механизмами. Но дуга управления помещена в туннель. На диаграмме декомпозиции (см. рис. 3.7) дугам родительского блока соответствуют внешние дуги, связанные с узлами I1, I2, O1, M1, М2. Дуга управления не была перенесена на дочернюю диаграмму (портового узла С1 на диаграмме декомпозиции нет). Зато на ней появилась новая дуга входа с меткой «Деньги», которой не было на родительской диаграмме (у данной дуги туннель размещен возле свободного конца). Помимо внешних дуг на диаграммах декомпозиции отображаются дуги, связывающие блоки друг с другом. Выходные дуги одних блоков могут являться либо входами, либо управлением, либо механизмом других. Нужно подчеркнуть, что внутренние дуги — это отражение взаимовлияния блоков, а не последовательности их выполнения. Блоки могут выполняться и параллельно. Таким образом, ни последовательность выполнения функций, ни время не указаны явно на IDEF0-диаграммах. Различают следующие типы связей между блоками [19]:  связь по входу — выход вышестоящего блока направляется на вход нижестоящего для дальнейшего преобразования;  связь по управлению — выход вышестоящего блока направляется на управление нижестоящего (например, один блок вырабатывает план, предписывающий, что и как должен делать другой блок);  обратная связь по входу — выход нижестоящего блока направляется на вход вышестоящего (например, результатом функции контроля качества может быть отбракованный продукт, который передается на вторичную переработку); Структурные методологии моделирования 77  обратная связь по управлению — выход нижестоящего блока направляется на управление вышестоящего (например, результат корректировки проекта может передаваться на повторную реализацию проекта);  связь выход-механизм — выход одного блока направляется на механизм другого (например, один блок подготавливает ресурсы, необходимые для работы другого блока). На диаграмме декомпозиции, приведенной на рис. 3.7, присутствуют первые два типа связей. Пример связи по входу — дуга «Продукт», являющаяся результатом блока А2 «Изготовление продукта» и предметом деятельности для блока А3 «Доставка продукта». К связи по управлению относится дуга «Заказ», являющаяся результатом блока А1 «Прием заявки» и управлением для блоков А2 и А3, так как она показывает соответственно, каким должен быть изготавливаемый продукт (в заказе должны быть указаны тип, цвет, размеры и другие характеристики продукта) и кому готовый продукт должен быть доставлен (в заказе указывается имя, адрес, телефон клиента). Дуги (как внешние, так и внутренние) могут разветвляться, в случае если одни и те же данные или объекты могут использоваться сразу в нескольких функциональных блоках либо разные части выходных данных (объектов) направляются разным блокам. Каждая из ветвей может представлять один и тот же объект или различные объекты одного и того же типа. Например, на диаграмме, приведенной на рис. 3.7, дуга, идущая от портового узла М1 «Персонал», разветвляется на три ветви — «Отдел приема заявок», «Цех» и «Отдел доставки», являющиеся соответственно механизмами блоков А1, А2 и А3. Кроме того, дуги могут сливаться. Например, разные блоки могут вырабатывать одинаковые или однородные данные (объекты), которые в дальнейшем используются или перерабатываются в одном месте. После того как будет построена модель декомпозиции первого уровня, каждый из блоков этой диаграммы также может быть декомпозирован. Пример иерархии функциональных блоков («дерева узлов») приведен на рис. 3.8. Построение диаграмм Глава 3. Моделирование бизнес-процессов 78 нижестоящих уровней осуществляется аналогично процедуре построения диаграммы первого уровня. А0 Создание продукта А1 Прием заявки А11 А12 Выбор Оформление продукта заказа А2 Изготовление продукта А13 Оплата А21 Подготовка материалов А3 Доставка продукта А22 Изготовление деталей А23 Сборка Рис. 3.8. Пример дерева узлов На конечном этапе разработки модели к каждой диаграмме могут быть приложены страница с сопроводительным текстом и глоссарий. Глоссарий содержит подробную информацию об элементах модели [19]. 3.2.2. Методология моделирования IDEF3 IDEF3-методология предназначена для описания потоков работ. Она широко используется для документирования технологических процессов, особенно в случаях, когда в модели необходимо показать последовательность выполнения процесса. Как и методология IDEF0, IDEF3 построена на принципах декомпозиции и иерархического упорядочения: контекстная диаграмма отражает процесс в целом, а диаграммы декомпозиции — процесс в виде совокупности более мелких работ. Однако IDEF3-диаграммы, в отличие от IDEF0-диаграмм, позволяют описать логику процесса — всевозможные варианты ветвления и слияния потоков работ [12]. Выделяют четыре базовых элемента IDEF3-модели (диаграммы) [20] (рис. 3.9): Структурные методологии моделирования 79 1) единицы работ (Unit of work, UOW) (рис. 3.9, а), отображающие действия, процессы, события, этапы выполнения работ. Имя задается в форме глагола, указывается номер и исполнитель работы. У любой единицы работ может быть только один вход и один выход; 2) ссылки (Referents) (рис. 3.9, б) — объекты, используемые для комментариев к элементам модели, для описания циклических переходов, ссылок на другие диаграммы. Имя ссылки задается именем существительным, номер — числом; 3) связи (Links), представленные несколькими типами:  передающие действия от одной единицы работ к другой (изображаются сплошной линией со стрелкой (рис. 3.9, в));  соединяющие ссылку с единицей работ (изображаются пунктирной линией со стрелкой (рис. 3.9, г));  передающие поток объектов от одной единицы работ к другой (изображаются сплошной линией с двойной стрелкой на конце (рис. 3.9, д)); 4) перекрестки (Junctions) — элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса. Перекрестки бывают двух видов: перекрестки слияния — Fan-in (рис. 3.9, е) и перекрестки ветвления — Fanout (рис. 3.9, ж). И перекрестки слияния, и перекрестки ветвления бывают пяти типов [23]. Наименование и смысл каждого типа ветвления приведены в таблице 3.1. ИМЯ (глагол) № Исполнитель ИМЯ (существительное) № в г д а б е ж Рис. 3.9. Элементы IDEF3-диаграммы: а — единица работы; б — ссылка; в — связь последовательности; г — связь отношений; д — поток объектов, е — перекресток слияния; ж — перекресток ветвления Все перекрестки на диаграмме автоматически нумеруются, каждый номер имеет префикс J. Глава 3. Моделирование бизнес-процессов 80 Таблица 3.1 Типы перекрестков Смысл для перекрестка слияния Асинхронное И Выходной процесс & & Asynchronous AND запустится, если завершились все входные процессы Синхронное И Выходной процесс && Synchronous AND запустится, если завершились одновременно все входные процессы Асинхронное ИЛИ Выходной процесс O O Asynchronous OR запустится, если завершился один или несколько входных процессов Синхронное ИЛИ Выходной процесс O O Synchronous OR запустится, если завершились один или несколько входных процессов, причем завершились одновременно Исключающее ИЛИ Выходной процесс XX Exclusive OR (XOR) запустится, если завершился только один входной процесс Знак Наименование Смысл для перекрестка ветвления После завершения входного процесса запустятся все выходные процессы После завершения входного процесса запустятся одновременно все выходные процессы После завершения входного процесса запустятся один или несколько выходных процессов После завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно После завершения входного процесса запустится только один выходной процесс Пример IDEF3-диаграммы приведен на рис. 3.10. После выполнения работы 1 запускаются работы 2 и 4. Причем запускаются не обязательно одновременно, так как они следуют после перекрестка разветвления типа асинхронного «И». После завершения работы 2 запускается работа 3. Структурные методологии моделирования Изготовить детали каркаса Собрать каркас 2 Разработать проект 1 3 && 4 && Нанести рисунок J1 Изготовить щит 81 Собрать изделие J4 7 5 OO OO J2 Наклеить пленку J3 6 Рис. 3.10. Пример IDEF3-диаграммы После завершения работы 4 запускается либо работа 5, либо работа 6, либо обе вместе (в этом случае работы могут запускаться в разное время), так как работы 5 и 6 следуют за перекрестком ветвления типа асинхронного «ИЛИ». Для запуска работы 7 требуется завершение работы 3 и хотя бы одной из работ 5 или 6, причем завершиться эти работы могут не обязательно одновременно, поскольку им предшествует перекресток слияния типа асинхронного «И». Правила создания перекрестков [20]: 1) каждому перекрестку слияния должен предшествовать перекресток ветвления; 2) перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ»; 3) перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И»; 4) перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой; 5) перекресток не может быть одновременно перекрестком слияния и ветвления. Если нужно одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков. 82 Глава 3. Моделирование бизнес-процессов Относительно единиц работ имеется лишь одно правило: в блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки. В отличие от нотации IDEF0, в нотации IDEF3 стороны блока, изображающего работу (функцию, процесс), не используют для привязки входов различного типа [12]. В методологии IDEF3 разрешается множественная декомпозиция работ. При этом для одной и той же работы может быть создано несколько диаграмм декомпозиции. Это позволяет в одной модели описать альтернативные варианты реализации работы — сценарии развития ситуаций. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ: номер работы состоит из номера родительской работы, номера декомпозиции и собственного номера работы на текущей диаграмме [20]. Например, номер А13.1.2 означает, что родительская работа имеет код А13, номер декомпозиции 1 и номер работы на текущей диаграмме 2. Основным достоинством методологии IDEF3 в сравнении с методологией IDEF0 является возможность явно показать последовательность выполнения процесса. Недостатком является тот факт, что отобразить оборудование, используемое работой (функцией), управление, входные и выходные данные и другое можно только посредством привязки к работе ссылки с комментарием относительно связанных с работой объектов. Это менее наглядно, чем явное указание объектов (в виде меток) и их роли (через соединение меток дугами с определенной стороной блока) в IDEF0-модели. 3.2.3. Методология моделирования DFD Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации. С их помощью система разбивается на функциональ- Структурные методологии моделирования 83 ные компоненты (процессы, которые преобразуют входные данные в выходные) и представляется в виде сети, связанной потоками данных [17]. При построении диаграмм потоков данных наиболее часто используют две нотации: Йордана и Гейна-Сарсона. Обе нотации имеют одинаковый по названиям и значению элементный состав, но имеют различное его графическое изображение. В методологии DFD используется четыре типа структурных элементов: процессы, потоки данных, внешние сущности и хранилища данных. Графические обозначения элементов в нотации Гейна-Сарсона приведены на рис. 3.11. Номер Имя Исполнитель Имя Имя Имя а б в г Рис. 3. 11. Элементы DFD-диаграммы в нотации Гейна-Сарсона: а — процесс; б — поток данных; в — хранилище данных; г — внешняя сущность Процессы. Процессы в DFD обозначают функции, операции, действия, которые обрабатывают и изменяют информацию. Они показывают, каким образом входные потоки данных преобразуются в выходные. Процесс обозначается в виде прямоугольника со скругленными углами, разделенного на три поля. Верхнее поле содержит номер процесса, среднее — его имя, нижнее — имя исполнителя процесса. Потоки данных. Потоки данных используются для отображения взаимодействия процессов с внешним миром и между собой. Поток данных соединяет выход процесса (или объекта) с входом другого процесса (или объекта) и обозначается в виде именованной стрелки (имя отражает содержимое потока). Внешние сущности. Внешние сущности определяют элементы вне контекста системы, которые участвуют в процессе Глава 3. Моделирование бизнес-процессов 84 обмена информацией с системой, являясь источниками или приемниками информации. Внешние сущности изображают входы в систему и/или выходы из системы. Как правило, они представляют собой материальный предмет или физическое лицо, например: заказчик, персонал, поставщик, клиент, склад, банк. Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ. Эти данные также могут быть созданы или изменены процессами. В отличие от потоков данных, описывающих данные в движении, хранилища данных отображают данные в покое, т. е. данные, которые сохраняются в памяти между последующими процессами. Информация, которую содержит хранилище данных, может использоваться в любое время после её определения. При этом данные могут выбираться в любом порядке. Начинается построение DFD-модели с создания контекстной диаграммы, на которой представлены, помимо цели и точки зрения, вся система в целом, внешние сущности и потоки данных, связывающие систему с внешними сущностями. Затем система декомпозируется и создаются диаграммы декомпозиции. Пример диаграммы потоков данных приведен на рис. 3.12. Заказчик Счет Заявка 1 Формирование заказа Заказ 1 База данных «Заказ» Платеж 3 Оплата заказа Стоимость 2 Расчет стоимости заказа 2 Цена База данных «Прайс» Рис. 3.12. Пример DFD-диаграммы Диаграммы могут быть дополнены мини-спецификациями и словарями. Объектно-ориентированный язык моделирования UML 85 3.3. Объектно-ориентированный язык моделирования UML 3.3.1. Объектно-ориентированное моделирование Язык UML предназначен для создания моделей информационных систем с целью их последующей реализации в виде объектно-ориентированных программ. Поскольку в основе UML лежит методология объектно-ориентированного программирования, необходимо пояснить, в чем ее суть. Бурное развитие объектно-ориентированного программирования началось в 1980-е гг., что во многом было обусловлено широким распространением операционной системы Windows. В рамках этого подхода основной программной единицей становится не процедура или функция, как это было в традиционном процедурно-ориентированном программировании, а объект — структура, объединяющая данные и методы их обработки. Возможность конструировать новые объекты на основе стандартных путем их расширения и переопределения, называемая наследованием, позволила создавать программы из готовых «кирпичиков» — библиотечных объектов. Для различных языков программирования были созданы библиотеки стандартных классов объектов, реализующих стандартные визуальные компоненты, — окна, меню, списки выбора, командные кнопки и т. д. Библиотечные классы компонентов, построенные на принципах прямого манипулирования, «умеют» в ответ на манипуляции пользователя мышью или ввод с клавиатуры совершать стандартные действия — вызывать соответствующие методы. Появились средства «визуального» программирования, или средства быстрой разработки приложений (RAD — Rapid Application Development), с помощью которых программист создает большую часть программы путем манипулирования мышью (передвигая на экране визуальные компоненты) и 86 Глава 3. Моделирование бизнес-процессов ввода свойств компонентов, а соответствующий программный код генерируется автоматически. Внимание программистов переключилось с непосредственного написания программного кода на предшествующие этапы — анализ предметной области и проектирование программы. Появились методы объектно-ориентированного анализа и проектирования (OOA/OOD — Object-Oriented Analysis/Design), которые позволяли моделировать системы до написания кода, так что весь проект находился не в голове ведущего разработчика, а с самого начала был документирован. Модель — это картина системы. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат. Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения. Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:  структурные модели, описывающие структуру системы, – классы, компоненты, подсистемы и т. д.;  модели поведения, отражающие функциональные возможности системы, логику выполнения процессов обработки данных, взаимодействие объектов в ходе выполнения процессов и т. д. В дальнейшем язык UML стал применяться не только и не столько для создания информационных систем (ИС), сколько для анализа и перепроектирования бизнес-процессов. Вместо моделей процессов, реализуемых информационной системой, строятся модели бизнес-процессов, даже если они и не будут подвергнуты автоматизации, вместо объектов ИС (программных объектов) в моделях отражаются объекты бизнес-процессов (исполнители, продукция, услуги и т. д.), вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса (поставщики, партнеры, клиенты). Моделирование бизнеса с помощью UML предполагает последовательное построение двух видов моделей: Объектно-ориентированный язык моделирования UML 87 1) прецедентной модели (аналога модели поведения), опиисывающей функциональность — бизнес-процессы (прецеденты), их взаимодействие с окружением; 2) объектной модели (аналога структурной модели), описывающей внутреннее устройство бизнеса — объекты, участвующие в выполнении бизнес-процессов, их взаимодействие. 3.3.2. Прецедентная модель бизнеса Построение прецедентной модели бизнеса (Business Use Case Model) начинается с формирования так называемой внешней диаграммы, или диаграммы вариантов использования (Use Case Diagram). Она описывает бизнес так, как он виден извне, т. е. как он воспринимается клиентами и другим окружением. Данная диаграмма отражает представление о том, что делает бизнес, а не как делает. Основными элементами диаграммы являются прецедент (вариант использования, business use case), актор (действующее лицо, business actor), отношение ассоциации, зависимость, отношение обобщения, примечание. Условные обозначения этих элементов приведены на рис. 3.13, пример диаграммы — на рис. 3.14. Notes Registration Customer а б в г д е Рис. 3.13. Элементы диаграммы вариантов использования модели бизнеса: а — актор; б — прецедент; в — ассоциация; г — зависимость; д — обобщение; е — примечание Акторами в модели бизнеса являются элементы окружения. Они обозначают все то в окружении, что взаимодействует с бизнесом. Это может быть человек (не работающий в компании или работающий в подразделениях, не охваченных моделью бизнеса), Глава 3. Моделирование бизнес-процессов 88 другая компания, органы власти. Примеры акторов: клиент, покупатель, поставщик, партнер, акционер, заказчик. Обобщенный актор Покупатель мебели <> Мебель Покупатель <> Обобщенный прецедент Продукт Фрагмент прецедента <> Продажа мебели Продажа продукта Исполнение заказа Рис. 3.14. Диаграмма вариантов использования модели бизнеса Актор представляет собой абстракцию субъекта (кого-либо), использующего бизнес. Он обозначает роль, которую ктолибо может играть по отношению к бизнесу. Не следует путать реальных людей с акторами: реальная личность может играть несколько ролей в бизнесе. Например, конкретный человек может быть и клиентом, и поставщиком [4]. Прецедент модели бизнеса — это относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному действующему лицу (актору) [21]. Это, прежде всего, «внешние» бизнес-процессы, ориентированные на клиента, т. е. заканчивающиеся получением продукта (товара или услуги) — измеримой потребительской ценности для некоторого индивидуального клиента бизнес-системы. В виде прецедентов могут быть представлены и «внутренние» бизнес-процессы, клиентами которых выступают другие части бизнес-системы, не участвующие в выполнении процесса. Примеры прецедентов: производство продукта, продажа продукта, сервисное обслуживание, разработка продукта, маркетинг и сбыт. Объектно-ориентированный язык моделирования UML 89 Прецеденты представляют собой поток взаимосвязанных событий. При этом прецеденты могут иметь множество вариантов хода событий. Каждый конкретный вариант называется экземпляром или реализацией прецедента. Он отражает конкретный поток событий в конкретных условиях. Похожие варианты хода событий группируются в классы прецедентов. Можно рассматривать класс как обобщенный прецедент. Например, класс прецедентов «Продажа» описывает общий ход событий, выполняемых при продаже любого продукта любому клиенту. Конкретный экземпляр прецедента «Продажа» может отличаться в деталях, например в зависимости от того, новый это клиент или нет, компетентный или несведущий и т. п. Так же как и для прецедентов, для акторов различают понятия класса и экземпляра. Класс описывает общие характеристики некоторого типа акторов, а экземпляр — характеристики конкретного актора. На диаграмме вариантов использования, как правило, отображаются классы прецедентов и классы акторов. Причем их расположение может быть произвольным (в любом месте диаграммы). Акторы, принадлежащие разным классам, могут иметь общие характеристики или общие обязательства по отношению к бизнесу. Можно ввести обобщенный класс акторов, объединяющий общие характеристики нескольких более конкретных классов акторов. Например, для классов «Покупатель мебели» и «Покупатель компьютеров» может быть введен обобщенный класс акторов «Покупатель». В этом случае между обобщенным типом актора и более конкретным устанавливается отношение обобщения (см. рис. 3.14). Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate). Они моделируют информационные и материальные потоки, т. е. обмен прецедентов с субъектами окружения объектами материальной или информационной природы (данными, документами продукцией, сырьем и т. д.). Следует заметить, что между акторами отношения коммуникации обычно не указываются, так как с точки зрения бизнес-системы они не 90 Глава 3. Моделирование бизнес-процессов представляют интереса. Между прецедентами отношения коммуникации, как правило, также не устанавливаются, так как в процессе своего выполнения они не «обращаются» друг к другу. Допустимо установление отношений зависимости между прецедентами, а также отношений, структурирующих прецеденты, — отношений обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend). Подробнее структуризация прецедентов будет рассмотрена ниже. Для каждого элемента модели составляется спецификация. В спецификации актора указывается наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др. Спецификация прецедента содержит его наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов. Наиболее важным для описания прецедента является документ, называемый «потоком событий» (flow of events). Он описывает сценарии осуществления прецедента в виде последовательности шагов процесса. Рассмотрим для примера поток событий прецедента «Продажа продукта»: 1) Продавец получает заявку Клиента; 2) если в заявке указан готовый продукт, то Продавец проверяет наличие требуемого продукта на складе. Если продукта нет в наличии, прецедент заканчивается. Иначе прецедент продолжается с шага 4; 3) если в заявке указывается заказной продукт, то Продавец формирует заказ и передает его Изготовителю продукта: 3а — Изготовитель производит продукт; 3б — Изготовитель сообщает о готовности изделия Продавцу и отправляет продукт на Склад; 4) Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату; 5) Продавец сообщает Отправителю количество продукта и адрес клиента и заказывает транспорт; 6) Отправитель получает продукт со склада и доставляет его Клиенту. Объектно-ориентированный язык моделирования UML 91 Каждый шаг (событие) прецедента представляет собой некоторое действие, переводящее прецедент в новое состояние. В свою очередь, новое состояние прецедента является стимулом для выполнения следующего шага (события). Таким образом, прецедент рассматривается как машина состояний-событий. Поток событий прецедента может быть представлен в виде диаграммы деятельности (Activity diagram), являющейся поддиаграммой прецедента. Данный вид диаграммы имеет некоторое сходство со структурной схемой алгоритма [21]. На рис. 3.15 приведены условные обозначения основных элементов диаграммы. а б в г д е Рис. 3.15. Элементы диаграммы деятельности: а — начальное состояние; б — конечное состояние; в — действие; г — переход; д — ветвление; е — синхронизация На рис. 3.16 приведен пример диаграммы, иллюстрирующий ход событий прецедента «Продажа продукта», описанного выше. Процесс начинается с начального состояния и переходит от одного действия к другому, заканчиваясь конечным состоянием. В ходе выполнения процесса могут возникать ветвления на альтернативные потоки. В этом случае ставится знак ветвления в виде ромба, имеющего одну входящую стрелку и две или более выходящих. Для каждой из выходящих стрелок указывается соответствующее условие, при котором выполняется данный переход. Кроме того, процесс может иметь параллельные потоки действий. Для разделения на параллельные потоки либо слияния параллельных потоков используется символ синхронизации. Описание потока событий прецедента, отображаемое на диаграмме деятельности, может быть очень сложным и запутанным, содержать различные альтернативные потоки событий, в том числе достаточно редкие и исключительные, выполняемые лишь при определенных условиях. Поэтому чтобы упростить Глава 3. Моделирование бизнес-процессов 92 описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования. Получить заявку Указан готовый продукт Указан заказной продукт Передать заказ изготовителю Проверить наличие на складе Изготовить продукт Сообщить о готовности Продукт имеется Нет продукта Отправить на склад Принять оплату Заказать транспорт Доставить продукт Рис. 3.16. Диаграмма деятельности прецедента «Продажа продукта» Первый способ структурирования сложных прецедентов заключается в использовании отношения включения (include). Если из общего описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент и между ним и исходным прецедентом устанавливается отношение включения. Поток событий включенного прецедента «встраивается» в поток событий базового прецедента, т. е. когда экземпляр базового прецедента в процессе своего выполнения достигает точки Объектно-ориентированный язык моделирования UML 93 включения, выполняется последовательность шагов включенного прецедента, после чего продолжается выполнение исходного прецедента. Например, из прецедента «Продажа продукта» можно выделить фрагмент, содержащий последовательность действий, выполняемую только в том случае, если клиент в заявке указывает заказной продукт. Представим этот фрагмент в виде отдельного прецедента «Исполнение заказа». На диаграмме вариантов использования (см. рис. 3.14) между прецедентами «Продажа продукта» и «Исполнение заказа» устанавливается отношение включения. Для прецедента «Исполнение заказа» создается собственная диаграмма деятельности (рис. 3.17). Получить заявку Указан готовый продукт Проверить наличие на складе Нет продукта Продукт имеется Указан заказной продукт Вызов прецедента «Исполнение заказа» Передать заказ изготовителю Изготовить продукт Принять оплату Заказать транспорт Сообщить о готовности Отправить на склад Доставить продукт а б Рис. 3.17. Структурирование модели посредством отношения включения: а — диаграмма деятельности прецедента «Продажа продукта»; б — диаграмма деятельности прецедента «Исполнение заказа» При этом на диаграмме деятельности прецедента «Продажа продукта» вместо извлеченного фрагмента размещается действие, осуществляющее вызов прецедента «Исполнение заказа». 94 Глава 3. Моделирование бизнес-процессов Частным случаем структурирования с помощью выделения фрагментов является использование отношения расширения (extend). Данное отношение устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях. Второй способ структурирования сложных прецедентов основан на использовании отношения обобщения (generalization). Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский) и установить между ним и исходными отношение обобщения. В этом случае общее поведение описывается только один раз. Описания конкретных прецедентов (потомков) содержат только дополнительные шаги (или модифицированные шаги), которых нет в обобщенном описании. Например, с прецедентом «Продажа продукта» могут быть связаны его потомки — прецеденты «Продажа мебели», «Продажа компьютера», которые отличаются в деталях от родительского прецедента. При этом на диаграмме вариантов использования необходимо отразить отношения обобщения (см. рис. 3.14), а в диаграммах деятельности прецедентов-потомков можно осуществлять вызов родительского прецедента, описывающего шаги, оставшиеся без изменений. 3.3.3. Объектная модель бизнеса Прецедентная модель иллюстрирует функции бизнеса (бизнес-процессы) и его окружение. Однако для более полного понимания бизнеса такого описания недостаточно. Необходима модель, показывающая кем, с помощью чего реализуются прецеденты. Объектная модель раскрывает внутреннее устройство бизнеса, а именно: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют. Объектную модель бизнеса называют также моделью бизнесанализа (Business Analysis Model). Основным понятием модели бизнес-анализа является понятие объекта. Объекты модели Объектно-ориентированный язык моделирования UML 95 бизнеса представляют людей, участвующих в выполнении процессов, и различного рода сущности, которые обрабатываются или создаются бизнесом (продукцию, предметы, задачи и т.д.). Участники процессов (исполнители) называются активными объектами, сущности — пассивными. Похожие объекты группируются в классы. Класс — это множество объектов, связанных общностью свойств и поведения. Каждый конкретный объект рассматривается как экземпляр некоторого класса. Например, объекты, соответствующие конкретным служащим, могут быть объединены в класс Служащий. Объекты обладают свойствами и поведением. Свойства объекта описываются с помощью характеристик, называемых атрибутами. При этом состав атрибутов одинаков для всего класса, различные экземпляры одного класса отличаются лишь набором конкретных значений атрибутов. Например, класс Служащий может иметь атрибуты: ФИО, Стаж, Квалификация и т.д. Разные объекты данного класса будут иметь разные значения этих атрибутов. Причем значения атрибутов могут изменяться со временем. Поведение определяет действия объекта и его реакцию на запросы от других объектов. Поведение представляется с помощью набора операций, которые может выполнять объект. Примеры операций класса Служащий: Принять заказ, Оформить договор, Принять оплату и т. д. Для отображения взаимосвязей между классами используется диаграмма классов (Class diagram). На рис. 3.18 представлены условные обозначения основных элементов диаграммы классов модели бизнес-анализа. Notes Clerk Account б а в г д е Рис. 3.18. Элементы диаграммы классов объектной модели бизнеса: а — исполнитель; б — сущность; в — ассоциация; г — зависимость; д — обобщение; е — примечание Глава 3. Моделирование бизнес-процессов 96 Как правило, используются классы со стереотипом business worker (исполнитель) и business entity (сущность). На рис. 3.19 представлен пример диаграммы классов, построенной для прецедента «Продажа продукта». <> Продавец <> <> <> <> Служащий Изготовитель <> Заказ <> Продукт <> <> Отправитель Склад Рис. 3.19. Диаграмма классов для прецедента «Продажа продукта» На диаграмме отражены классы исполнителей, выполняющих прецедент (Продавец, Исполнитель, Склад, Отправитель), а также классы объектов-сущностей, используемых в ходе выполнения прецедента (Заказ, Продукт). Между классами исполнителей установлены отношения коммуникации (ассоциации со стереотипом communicate), отражающие их взаимодействие. Между классами объектов-сущностей, как правило, отношения коммуникации не устанавливаются. Класс сущности может быть связан с классом исполнителя отношением использования (ассоциации со стереотипом uses), в случае если исполнитель некоторым образом использует сущность. Например, Продавец создает Заказ, Изготовитель использует Заказ для получения описания продукта, Отправитель использует Заказ для получения информации о том, куда доставлять продукт. Соответствующие отношения использования представлены на рис. 3.19. Объектно-ориентированный язык моделирования UML 97 На диаграмме классов могут быть отражены также отношения структурирования — обобщения и включения. Так, на рис. 3.19 показаны отношения обобщения между абстрактным классом Служащий и более конкретными классами Продавец, Отправитель. Для каждого класса создается спецификация, в которой указывается состав атрибутов и обязательств (операций). Для того чтобы отразить последовательность взаимодействия объектов во время выполнения бизнес-процессов, используется диаграмма последовательности (Sequence diagram). На рис. 3.20 представлена диаграмма прецедента «Продажа продукта» (его реализация для случая заказного продукта). Каждый объект, участвующий в реализации прецедента, изображается в верхней части диаграммы в виде прямоугольника, от которого вниз проведена линия («линия жизни»). Внутри прямоугольника записывается имя объекта, следом через двоеточие может быть указано имя класса. Вся запись подчеркивается, что является признаком объекта, отличающим его от класса. Продавец Изготовитель Склад Отправитель Клиент Подача заявки Оформление заказа Передача заказа Сообщение о готовности Сообщение Изготовление продукта Отправка продукта Оплата Заказ транспорта Доставка продукта Запрос Отгрузка Рис. 3.20. Диаграмма последовательности прецедента «Продажа продукта» 98 Глава 3. Моделирование бизнес-процессов Если в прецеденте участвуют акторы, они также могут быть отражены на диаграмме. Объекты-сущности обычно не представлены на данной диаграмме, так как они не осуществляют взаимодействия. Между объектами (акторами) устанавливаются отношения сообщений (message), отражающие аналогично отношениям коммуникации передачу информации (или некоторый материальный поток) между объектами. Сообщение изображается отрезком горизонтальной линии со стрелкой, проведенной от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение. При этом прием сообщения инициирует выполнение определенных действий тем объектом, которому сообщение передано. Сообщения должны быть упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее — ниже, следующее — еще ниже и т. д. Таким образом, ось времени в диаграмме идет сверху вниз. Однако она не связана с метрикой и служит только для идентификации порядка взаимодействия, т. е. расстояние между взаимодействиями (сообщениями) на диаграмме не имеет ничего общего с интервалами времени между событиями. Анализ диаграммы последовательности помогает выявить все обязательства активного объекта. Так, из диаграммы, представленной на рис. 3.20, можно определить, что к обязательствам объекта Продавец относятся: Прием заявки, Оформление заказа, Передача заказа Изготовителю, Прием сообщения о готовности продукта, Сообщение клиенту о готовности продукта, Прием оплаты, Заказ транспорта. Данные операции должны быть внесены в спецификацию соответствующего класса Продавец. Взаимодействие объектов может быть показано и на диаграмме кооперации (Collaboration diagram). Она является статической моделью, поэтому на ней не может быть представлена последовательность взаимодействий. Язык имитационного моделирования SIMAN 99 3.4. Язык имитационного моделирования SIMAN SIMAN является гибким дискретно-событийным языком моделирования и анализа деятельности предприятий. Он распространяется вместе с инструментальным средством имитационного моделирования Arena, которое позволяет формировать модель на языке SIMAN, воспроизводящую процесс функционирования системы во времени, а также осуществлять многократные испытания модели с разными входными данными. Целями имитационного моделирования могут быть: выявление «узких» мест моделируемых бизнес-процессов; прогнозирование возможных сценариев развития процессов; сравнение различных вариантов реализации системы. Имитационное моделирование в ряде случаев гораздо менее затратное, чем проведение экспериментов с реальными системами. Тем более что иногда эксперименты на реальных системах в принципе невозможны. Моделирование позволяет изучить длительный интервал функционирования системы в сжатые сроки или, наоборот, изучить более подробно работу системы в развернутый интервал времени [22]. В основе языка SIMAN лежит математический аппарат систем массового обслуживания, дополненный рядом требований, таких как гибкость моделей, возможность задания стохастических параметров процесса, возможность обработки статистических данных, создание разнообразных отчетов по результатам моделирования. Имитационная модель на языке SIMAN включает следующие основные элементы [20, 23]:  процессы (Process) — работы, операции, действия;  ресурсы (Resource), выполняющие процессы, — персонал (продавцы, клерки, рабочие) или оборудование (станки, компьютеры);  сущности (Entity), обрабатываемые процессами, — заказы, документы, заготовки изделий, клиенты и т. д.; Глава 3. Моделирование бизнес-процессов 100  очереди (Queue) из ожидающих обработки сущностей, образующиеся перед процессами, которые в данный момент заняты. Процессы отображаются в виде схемных модулей. Для процессов разного типа используются разные графические обозначения. На рис. 3.21 приведены обозначения некоторых процессов. а б г в д Рис. 3.21. Графические модули языка SIMAN: а — модуль Create; б — модуль Dispose; в — модуль Process; г — модуль Decide; д — модуль Assign Модуль Create (рис. 3.21, а), или Источник, создает сущности, обрабатываемые в системе. Он имитирует, например, прибытие клиентов в банк или в магазин, поступление документов (заказов, чеков), начало изготовления продукции на производственной линии. Скорость поступления сущностей от Источника обычно задается статистической функцией. Модуль Process (рис. 3.21, в) является основным модулем процесса обработки в имитационной модели. Он имитирует, например, обслуживание клиентов, обработку документов или деталей, выполнение заказов. Время обработки сущности в процессе (производительность процесса) обычно задается статистической функцией. Язык имитационного моделирования SIMAN 101 Модуль Decide (рис. 3.21, г) служит для принятия решений в имитационной модели. Он позволяет проверять условия и в зависимости от результата проверки направлять сущности по той или иной ветке (тому или иному процессу). Обычно условия основаны на значениях атрибутов (характеристик) сущностей. Например, если клиенту банка требуется операция снятия со счета, то он направляется в один отдел, если он хочет оформить кредит, то — в другой отдел. Модуль Assign (рис. 3.21, д) предназначен для задания значения переменной в системе, в частности значения атрибута сущности. Например, можно задать номер операции, требуемой клиентом, или тип документа. Обычно задается случайное значение по заданной статистической функции. Модуль Dispose (рис. 3.21, б), или Сток, удаляет сущности из системы. Он имитирует, например, уход клиентов из банка или магазина, окончание обработки документа или изготовления изделия. Схемные модули соединяются между собой на диаграмме в соответствии с логикой выполнения имитируемого процесса. Существуют также модули данных, к которым относятся модули сущностей, очередей, ресурсов, переменных. Они не отображаются физически в блок-схеме модели, но с их помощью можно задать различные характеристики элементов модели [23]. На рис. 3.22 приведена в качестве примера имитационная модель системы обслуживания клиентов в банке. Модуль Crate 1 имитирует приход клиентов в банк. Распределение времени между приходами клиентов описывается некоторым законом. Примеры распределения: равномерное — клиенты приходят равномерно, раз в 5–9 минут; треугольное — клиенты приходят через 7±2 минуты, но наиболее часто — через 7 минут. Модуль Assign 1 присваивает клиентам атрибут Oper, характеризующий кассовую операцию (номер операции). Может быть назначен один из трех видов операций, для каждого из которых задана вероятность. Модуль Decide 1 распределяет клиентов по Глава 3. Моделирование бизнес-процессов 102 кассам в зависимости от операции, которую им необходимо выполнить. Модули Process 1, Process 2, …, Process 5 имитируют работу соответственно первого, второго, …, пятого кассиров. Время выполнения операций описывается некоторым законом распределения. Process 1 Create 1 Assign 1 Decide 1 False Dispose 1 Oper = 1 Oper = 2 Process 2 True Decide 2 False True Process 3 Process 4 Decide 3 False Process 5 Рис. 3.22. Имитационная модель системы обслуживания в банке Модуль Decide 2 распределяет клиентов между вторым и третьим кассирами, выполняющими операцию 2. Он направляет клиента тому кассиру, очередь у которого меньше. Модуль Decide 3 распределяет клиентов между четвертым и пятым кассирами аналогично модулю Decide 2. Модуль Dispose 1 имитирует уход клиента из банка. После того как имитационная модель будет создана, ее можно «проиграть». После «проигрывания» модели автоматически генерируются отчеты по следующим элементам [23]: Интегрированная методология моделирования ARIS 103  по сущностям, находящимся в системе, — общее время нахождения в системе, суммарное время ожидания, количество сущностей, вошедших в систему или вышедших из системы;  по очередям, образующимся в модулях процессов, — время ожидания обработки в очереди, количество сущностей, ожидающих в очереди;  по процессам — статистика для каждого повторения;  по ресурсам — статистика по затраченным ресурсам. Например, для модели, представленной на рис. 3.22, можно получить отчет по времени ожидания клиентов в очередях перед кассирами. Построив и «проиграв» несколько моделей для некоторой системы, отражающих различные варианты выполнения бизнеспроцессов, можно выбрать оптимальный вариант. Например, для системы обслуживания клиентов в банке, рассмотренной выше, можно построить другие модели, отличающиеся распределением операций между кассирами. «Проиграв» каждую из моделей в течение одинакового промежутка времени, можно сравнить среднее время ожидания клиентов в очередях системы. Тот вариант, в котором время ожидания минимально, можно считать наилучшим. 3.5. Интегрированная методология моделирования ARIS 3.5.1. Виды и типы моделей ARIS Методология «Архитектура интегрированных информационных систем» (Architecture of Integrated information System — ARIS) разработана в 1990-х годах профессором А.-В. Шеером [24]. Большую популярность этот аппарат моделирования приобрел благодаря широкому распространению программного продукта ARIS (IDS Scheer AG), реализующего данную концепцию. 104 Глава 3. Моделирование бизнес-процессов Основная идея методологии ARIS состоит в том, что такую сложную систему, как организация (предприятие) необходимо описывать с различных точек зрения. Причем для отражения различных аспектов организации используются модели разного типа с собственным набором элементов, подходящим для описания соответствующей предметной области. Нелогично использовать одну и ту же нотацию для описания таких различных предметных областей, как организационная структура, цели, продукты, ИТ-системы, документы, данные, технические ресурсы. Таким образом, модель организации должна быть представлена множеством моделей разного типа. Однако модели не должны быть изолированными, ведь это различные взгляды на одну и ту же систему. Интегрирующим центром должна быть модель процессов, так как именно процессы показывают, каким образом и для чего используются различные ресурсы предприятия (организационные единицы, документы, ИТ-системы, оборудование), и связывают их воедино. В методологии ARIS выделено четыре вида моделей (четыре представления), отражающие основные аспекты организации (рис. 3.23) [8, 24]: 1) организационные модели, представляющие структуру организации — иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними; 2) функциональные модели, описывающие функции, выполняемые в организации, а также иерархию целей, стоящих перед аппаратом управления; 3) информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы; 4) модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы. Методология ARIS не накладывает ограничений на последовательность формирования данных представлений. Процесс анализа и проектирования можно начинать с любого из них, в зависимости от конкретных условий и целей, стоящих перед ис- Интегрированная методология моделирования ARIS 105 полнителями [8]. Для каждого из четырех представлений можно построить от одного до нескольких десятков типов моделей. Методология ARIS включает большое количество методов моделирования. Программная система ARIS 5.0, например, позволяет строить 130 типов диаграмм [18]. Организационная модель Модель данных Модель процессов/ управления Модель функций Рис. 3.23. Виды моделей, используемых ARIS Интегрированная модель системы подразделяется не только на виды представлений, но и на уровни описания. Деление на уровни используется в случае разработки информационных систем (ИС), автоматизирующих бизнес-процессы. Уровни описания связаны с этапами разработки ИС. На уровне определения требований необходимо описать требования к ИС, формируемые на основе анализа бизнеса. На уровне спецификации проекта описывается логическая структура разрабатываемой системы. На уровне описания реализации спецификация проекта трансформируется в конкретные аппаратные и программные компоненты. Модель ARIS любого типа представляет собой совокупность объектов, объединенных друг с другом различными связями, и ряда вспомогательных элементов. Каждый тип модели предполагает использование определенного набора объектов и Глава 3. Моделирование бизнес-процессов 106 связей. В рамках одной модели количество типов объектов и количество типов связей может меняться от единиц до нескольких десятков. Рассмотрим основные типы моделей, используемых при моделировании бизнеса. Это, прежде всего, «Организационная схема» (Organizational chat), относящаяся к виду организационных моделей. Пример модели представлен на рис. 3.24. Петров А.Н. Плановый отдел Директор Дирекция Отдел продаж Маркетолог Отдел маркетинга Рекламный агент — организационная единица; Зав. отделом Дизайнер — должность; — сотрудник Рис. 3.24. Организационная схема Основными типами объектов данной модели являются организационная единица (подразделение), должность, сотрудник. Модель строится иерархически — от верхнего уровня структуры к нижнему. Каждое структурное подразделение детализируется на структурные подразделения в его составе. Низшим уровнем является описание подразделений на уровне должностей — штатных единиц, занимаемых конкретными сотрудниками [8]. Наиболее распространенными функциональными моделями являются «Дерево функций» (Function Tree) и «Диаграмма целей» (Objective diagram). Пример дерева функций приведен на Интегрированная методология моделирования ARIS 107 рис. 3.25. В данной модели используется только один тип объекта — функция (действие, работа, этап в рамках процесса). Создание продукта Изготовление продукта Прием заявки Доставка продукта Выбор продукта Подготовка материалов Отгрузка со склада Оформление заказа Изготовление деталей Транспортировка Оплата Сборка Разгрузка Рис. 3.25. Дерево функций На верхнем уровне описываются функции, представляющие собой некоторый бизнес-процесс. Детализация функций образует иерархическую структуру. Нижний уровень представляют базовые функции, т. е. функции, которые уже не могут быть разделены на составные элементы. Декомпозиция функций на подфункции может быть выполнена по различным основаниям: в соответствии с последовательностью выполнения процесса; в соответствии с различными способами выполнения функции; в соответствии с видами операций, выполняемых над некоторым объектом. К моделям данных относится, в частности, модель технических терминов (Technical Term Models), которая позволяет описать множество терминов, определяющих информационные и иные объекты в организациях, с тем чтобы они однозначно понимались всеми сотрудниками. Технические термины могут быть взаимосвязаны и иерархически упорядочены. На рис. 3.26 Глава 3. Моделирование бизнес-процессов 108 приведен пример модели технических терминов. Здесь использованы два типа объекта — «Технический термин» (прямоугольник с символами FB в правом нижнем углу) и «Кластер» (прямоугольник с боковыми сторонами из тройных линий). Связь между объектами имеет тип «изображает, описывает (depicts)» [18]. Конструкторская документация FB Чертежи Схемы Рабочий Проектный Электриче- Гидравчертеж чертеж ская схема лическая FB FB FB схема FB Инструкции Инструкция Инструкция по настройке по контролю FB FB Рис. 3.26. Модель технических терминов Одной из наиболее популярных моделей процессов / управления является «Событийная цепочка процесса» (Extended event driven process chain — eEPC). Модель отражает последовательность событий и функций в рамках бизнес-процесса, а также связанные с функциями ресурсы (человеческие, информационные, материальные) и выходы. Пример модели eEPC приведен на рис. 3.27. Основными типами объектов модели eEPC являются: функции, события, логические операторы [8, 18]. Функция представляет некоторое действие (шаг процесса). С функцией могут быть связаны исполнители (сотрудники или подразделения), входные и выходные документы, используемое программное обеспечение и т. д. Событие описывает какое-либо завершенное производственно-экономическое состояние системы, которое управляет или влияет на дальнейший ход процесса. С одной стороны, события Интегрированная методология моделирования ARIS 109 являются началом деятельности (инициируют выполнение функций), с другой — они следуют из предшествующих функций и описывают, таким образом, их результат. Заказ получен Отследить заказ на производство Заказ обработан Появилась необходимость во внешней детали Изготовить изделие Отдел ИТ Закупить деталь Деталь получена Изделие создано Сведения о поставщиках Сопроводительные документы Отгрузить деталь Заказ клиента обработан — функция; — событие; — оператор И Рис. 3.27. Событийная цепочка процесса (eEPC) С помощью логических операторов AND (И), OR (ИЛИ), XOR (исключающее ИЛИ) моделируются логические разветвления в потоке процесса. Операторы могут связывать как события, так и функции. Например, логический оператор AND, связывающий события, используется, когда функция является результатом одновременного наступления нескольких событий (рис. 3.28, а) или когда функция инициирует наступление нескольких событий (рис. 3.28, б). Оператор AND, связывающий функции, используется, когда событие является результатом одновременного Глава 3. Моделирование бизнес-процессов 110 выполнения нескольких функций (рис. 3.28, в) или когда событие инициирует одновременное выполнение нескольких функций (рис. 3.28, г). а б в г Рис. 3.28. Связывание событий и функций логическим оператором И: а — наступление двух событий инициирует функцию; б — функция инициирует наступление двух событий; в — выполнение двух функций инициирует событие; г — событие инициирует выполнение двух функций Аналогичные правила используются для связывания событий и функций операторами OR и XOR. Однако имеется одно исключение. Операторы ИЛИ и исключающее ИЛИ не могут связывать функции, инициируемые некоторым событием, так как события не могут принимать решения, какую из функций следует выполнять. 3.5.2. Взаимосвязь моделей ARIS Основной особенностью методологии ARIS является взаимосвязь моделей, которая обеспечивается с помощью двух механизмов: 1) интеграции различных моделей посредством использования общих объектов; 2) детализации объектов путем установления ссылок на детализирующие диаграммы. Механизм интеграции осуществляется благодаря репозитарию — специальной базе данных, в которой хранится вся информация об объектах и их связях. Когда при формировании неко- Интегрированная методология моделирования ARIS 111 торой модели создается новый объект, в репозитарии появляется отдельная запись, задающая описание объекта. Описание включает уникальное имя, тип объекта, его атрибуты и др. Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste. При этом будет создан еще один экземпляр существующего объекта [8]. На рис. 3.29 показан пример осуществления взаимосвязи моделей различного типа за счет использования общих объектов. Организационная модель FB FB FB Модель данных Модель процессов/управления Модель функций Рис. 3.29. Механизм интеграции моделей Механизм детализации позволяет определять для объекта текущей модели ссылки на другие модели, являющиеся подробным описанием этого объекта. Типы моделей детализации, разрешенные к использованию в конкретном случае, зависят от типа детализируемого объекта. Например, для объекта типа «функция» детализирующей моделью может быть дерево функций, модель eEPC или модель окружения функции. Пример детализации приведен на рис. 3.30. Пиктограмма рядом с функцией «Обработать заявку» означает, что с данной функцией связана детализирующая диаграмма. Глава 3. Моделирование бизнес-процессов 112 Механизм детализации позволяет избегать перегрузки моделей информацией, делая их более наглядными. В частности, в моделях иерархического типа («Дерево функций», «Организационная схема» и др.) детализация позволяет уменьшить количество уровней на одной диаграмме: объекты, начиная с четвертого или пятого уровня, детализируются моделями того же типа, где и отражаются следующие уровни иерархии [18]. Диаграмма eEPC Диаграмма окружения функции Поступила заявка SAP Данные о продажах Сохранить заявку Заявка сохранена Обработать заявку Заявка обработана SD Обработать заявку Заявки клиентов Отдел продаж Рис. 3.30. Связь моделей с помощью детализации С помощью детализации может быть построена модель процесса на принципах структурного подхода. Например, иерархию IDEF3-диаграмм можно представить с помощью иерархии диаграмм eEPC. На исходной диаграмме будет отражена событийная цепочка процесса, содержащая обобщенные функции. Механизм выполнения каждой из функций может быть раскрыт с помощью детализирующих eEPC-диаграмм. Контрольные вопросы 1. Что такое модель? Каковы ее основные свойства? 2. Приведите различные классификации моделей. Дайте краткую характеристику моделей различного типа. 3. Перечислите и охарактеризуйте основные группы методологий моделирования бизнеса. Интегрированная методология моделирования ARIS 113 4. Каковы основные структурные элементы IDEF0-модели? 5. Что такое контекстная диаграмма, диаграмма декомпозиции? Как связаны диаграммы в рамках одной IDEF0-модели? 6. Какие типы связей между блоками IDEF0-модели Вы знаете? 7. Перечислите базовые элементы IDEF3-модели. 8. Приведите примеры использования различных типов перекрестков IDEF3-модели. 9. Охарактеризуйте основные элементы DFD-модели. Приведите пример модели. 10. В чем состоят особенности объектно-ориентированного моделирования? 11. Что такое прецедент? Что такое актор? Что обозначают эти понятия при моделировании бизнеса? 12. Что отображается на диаграмме вариантов использования языка UML? 13. Что такое поток событий прецедента? Как отражается поток событий на диаграмме деятельности языка UML? 14. Какие способы структурирования прецедентов Вы знаете? 15. Опишите основные элементы диаграммы классов объектной модели бизнеса. 16. Что отображается на диаграмме последовательности языка UML? 17. Как формируется и используется имитационная модель на языке SIMAN? 18. Какие виды и типы моделей ARIS Вы знаете? Приведите примеры различных типов моделей. 19. Что представляет собой событийная цепочка процесса? Какие типы логических операторов в ней используются? 20. Опишите механизмы интеграции и детализации моделей ARIS.