Целью данной работы будет сравнительный анализ case-средств: CA ERwin Process Modeler (BPwin) , IBM Rational Rose и Oracle Process Modeller. Поэтому, мы не будем создавать сложных моделей, а сделаем это на упрощенной модели страхования автогражданской ответственности (как наиболее актуальной в наши дни).

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

ЧАСТЬ 1. МОДЕЛЬ BPWIN

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

Далее, определим основные процессы страхования. Это будут:

• консультации;
• заключение договора;
• страховые выплаты.

Отразим эти блоки на диаграмме первого уровня С0 (рис.2). Входными данными модели будут:

• вопросы клиентов;
• документы клиентов;
• заявления на выплаты и другие документы.

Кроме этого, страховщик обязан регулярно вносить обусловленную договором страхования плату (страховую премию).

Выходными данными модели будут:

• отказ в страховании;
• страховой полис и договор;
• страховое возмещение.

Теперь создадим диаграмму "Консультации" (рис.3). Здесь все просто: сотрудник, являющийся консультантом, используя законодательные документы и внутренние инструкции, находит ответ на вопрос и сообщает его клиенту по телефону.

"Заключение договора" (рис.4) состоит из двух частей: Предварительная беседа и Оформление договора.

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

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

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

Несомненным удобством при работе с CA ERwin Process Modeler (BPwin) является то, что по каждому блоку и стрелке можно записать комментарий. Есть также функция проверки грамматики, но только английской. Русского языка (как обычно) в перечне нет. А как присоединить русский словарь, непонятно, хотя опция присоединения словаря есть. Но откуда его брать? Самому писать что ли?

Удобно также менять названия стрелок. Можно сразу изменить название определенной стрелки во всех диаграммах. Удобно двигаются надписи по отношению к стрелкам.

Стрелки можно объединять и создавать иерархию данных. Например: город, дом, улица, - объединить в Адрес. Тогда, на верхний уровень будет выходить только адрес. Для этого надо сделать ответвление со стрелки и назвать его по-другому.

Большим преимуществом BPWin по сравнению с другими изобразительными средствами является то, что при построении иерархических диаграмм потоки родительской диаграммы, входящие в дочернюю, автоматически переносятся туда. И, наоборот, выходящие из дочерней, сразу отображаются в родительской. Если в родительской диаграмме мы удаляем стрелку, то в дочерней ее вход заключается в скобки. Это очень удобно, так как позволяет отслеживать потоки между уровнями. Попробуйте нарисуйте такие схемы в Wordе, замучаетесь.

Главной ценностью, на мой взгляд, в методологии IDEF0 и DFD является иерархический подход, позволяющий описывать процессы любой сложности. В результате весь процесс отображается набором диаграмм различной степени обобщения, что мы и сделали. Верхние можно показывать начальству, нижние - исполнителям, программистам. Хотя, конечно, мы любим потрясать воображение начальства схемами на полстены. Но теория (SADT) утверждает, что обычный человек не может воспринять смысл схемы более чем из 5-6 блоков. Во как!

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

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

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

Войдем в него. В его состав включим: договорный отдел, отдел страховых выплат, ну и еще начальника (рис.10). Видите, как это полезно: мы уже начали думать над структурой центра. В реальном процессе, конечно, существует гораздо больше организационных единиц, но так как наша модель учебная, мы ее упростим. Теперь вернемся на верхний уровень и подумаем о том, с какими внешними объектами мы будем взаимодействовать. Во-первых, - это страхователь, который будет заключать договор. Во-вторых, - это опять страхователь J, который будет получать страховое возмещение. А больше никого. Ну очень простая модель! Не будем мы рассматривать взаимодействие с банками, органами внутренних дел, судебные споры, материально - техническое обеспечение, рекламу и т.д. Потому, что цель у нас другая: показать BPWin во всей его красе!

Итак, посмотрим, что у нас будет делать страхователь. Для этого обратимся к модели IDEF0. Он будет:

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

Что будет на выходе? То есть, что он может получить:

• ответ на вопрос;
• страховой полис;
• страховое возмещение;
• отказ в страховании;
• отказ в выплате страхового возмещения (вот так-то).

Кроме того, он сам может отказаться от… (вы подумали - от страхового возмещения J), нет, - от заключения договора.

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

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

Теперь, создадим хранилище данных: архив, куда будут помещаться копии документов.

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

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

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

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

Ну, посмотрели? Что можно сказать.

Во-первых, везде присутствует англоязычное обрамление. И заменить английские слова на русские в шаблоне (то есть создать русскоязычный шаблон) невозможно (во всяком случае, мне найти не удалось). Можно только править текст HTML- или Word-документа. Но ведь не будешь же это делать каждый раз! Может быть в лицензионной или какой-нибудь расширенной версии это возможно?? HTML-отчет создается несколько по-уродски и мне пришлось потрудиться, чтобы поместить его в Интернет. Конечно, отчет можно было сделать более полноценным, записав комментарии к объектам. Но мне это лень было делать. Кстати, и всем остальным тоже, - редкий автор добирается в своей модели до полноценных комментариев. Ну, а если доберется, то тут же и упадет замертво.

Кроме этого можно выдавать стандартные текстовые отчеты. Но это вообще убожество. Пример отчета по диаграмме:

Report for Diagram: С0, Страхование автогражданской ответственности

Activity Name: Консультации

Activity Number: С1

Activity Name: Заключение договора

Activity Number: С2

Activity Name: Страховые выплаты

Activity Number: С3

В версии 4.0 имеется такой недостаток, как искажение русских шрифтов при генерации отчета в Word. Я объясняю это тем, что там все еще используются старые 16-битные шрифты. Не следят за прогрессом, понимаешь! В MS Word 2000/ХР это исправляется очень просто: из меню "Сервис" выбираем пункт "Восстановить поврежденный текст", ставим "Язык" - русский и галочку "Ко всему документу". Вуаля!

Имеется возможность создавать Определенные Пользователем Свойства (User Defined Property, UDP). Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report. Через UDP могут быть запущены другие документы и приложения.

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

Для это потребуется создать Центры затрат (Cost centers), которые можно трактовать как статьи расхода. При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег, затем описываются центры затрат и, наконец для каждой работы на диаграмме декомпозиции назначаются продолжительность (duration), частота проведения данной работы в рамках общего процесса (frequency) и суммы по каждому центру затрат, то есть задается стоимость каждой работы по каждой статье расхода. Этот очень упрощенный принцип подсчета справедлив, если работы выполняются последовательно.

Возьмем, например, диаграмму С22: "Оформление договора" и проведем расчет стоимости. Основные исходные данные возьмем из модели: "Из опыта использования средства Arena для моделирования работы центра страхования автогражданской ответственности". Будем считать, что в этом процессе участвуют: руководитель, который утверждает документы; четыре инспектора, которые заключают договоры страхования; один кассир, который принимает деньги. Ежедневно поступает 40 заявлений на страхование. Будем считать, что зарплата инспектора - 300 р/день, руководителя 500 р/день, а кассира - 200 р/день. Создадим следующие центры затрат:

• зарплата;
• оборудование;
• расходные материалы.

В блок "Проверка транспорта" запишем всю дневную зарплату инспекторов (чтобы не делить ее на несколько частей) - 300рх4=1200р. Продолжительность проверки примем равной 0,2 час.

В блоке "Заполнение страхового полиса" определим, что на все полисы в день потребуется: 200р на расходные материалы и 50р на амортизацию оборудования. Продолжительность операции примем равной 0,3 час.

В блоке "Прием оплаты" запишем всю дневную зарплату кассира - 200р. Продолжительность операции примем равной 0,1 час. Затраты на расходные материалы - 50р, на оборудование - 50р.

В блоке "Подпись и выдача страхового полиса" запишем всю дневную зарплату руководителя - 500р, на расходные материалы - 50р, на оборудование - 0р. Продолжительность примем равной 0,1 час.

В блоке "Помещение копии страхового полиса в архив" запишем на расходные материалы - 30р, на оборудование - 20р. Продолжительность примем равной 0,1 час.

В результате на диаграмме будут отражены результаты расчета стоимости. А на диаграмме верхнего уровня будет выведена стоимость 2350р.

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

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

Какие недостатки можно отметить в CA ERwin Process Modeler (BPwin), касающиеся интерфейса и удобства работы:

• Нельзя менять мышью размеры текстового поля. Приходится при наборе текста делать перевод строки так, чтобы размеры были такие, какие требуется на диаграмме.
• Отсутствует возможность самому редактировать текст Header/footer. Английские слова в заголовках формы заменить на русские невозможно.
• Несколько дубоватый, не совсем Windows-ный интерфейс: при сохранении, при закрытии проекта. Одно "Close without saving" чего стоит.
• Устаревшие кириллические шрифты, которые, если диаграммы копировать, не видны в MS Office 2000, XP.
• Невозможность выделения и копирования одного или группы объектов, - только диаграмма полностью.

Неудобством является и то, что по каждому объекту (блоку, стрелке) свойства (цвет, толщину линий) надо устанавливать отдельно. Обобщение или, например, выделение группы объектов отсутствует.

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

Ну, а если мы хотим вставить дополнительный уровень, то есть создать диаграмму между двумя существующими, то это превращается в настоящее мучение. Я всегда холодным потом покрываюсь, когда надо такое сделать J. Иногда даже легче удалить весь нижний уровень и начать все сначала. В качестве примера привожу "простенький" алгоритм вставки нового уровня.

Пример: Дана модель с диаграммами A1, A2 и A3 (все они уже подвергнуты декомпозиции). Мы хотим, чтобы текущая диаграмма A2 стала диаграммой A21, и заменить текущую диаграмму А2 новой диаграммой.

В диаграмме A0, нажать правую кнопку мыши над A2 и выбрать пункт Разбиение Модели (Split Model). Ввести имя модели (например, "park"). Вновь созданная модель будет иметь диаграмму A2 , как контекстную операцию, а предыдущая операция A2 будет иметь стрелку вызова с названием "park". Предыдущая операция A2 теперь является висячей (или конечной) операцией и может быть подвергнута декомпозиции, для создания новой диаграммы A2 в оригинальной модели. Вы должны переименовать или контекстную операцию новой модели (park) или предыдущую операцию A2. Затем надо удалить стрелку вызова "park" из предыдущей операции и поместить новую стрелку вызова "park" в операцию в новой декомпозиции, где должна быть расположена предыдущая диаграмма A2 (в данном случае A21). Контекстной операции новой модели "park" следует дать такое же название, как и операции А21 (Activity A21) в новой декомпозиции. Воспользуйтесь меню правой кнопки мыши над операцией A21 или над стрелкой вызова "park", выберите пункт Слияние Модели (Merge Model) и вновь объедините модель "park" с оригинальной моделью. Необходимо отметить, что новая диаграмма будет иметь обрамляющие стрелки (border arrows), которые соответствуют традиционным туннельным (square tunneled) стрелкам, соединяющим помещенную нами операцию А21 (Activity A21). Эти стрелки можно соединять так, как вы сочтете нужным.

Ну вот! Вроде с BPWin в основном разобрались.

ЧАСТЬ 2. Модель Rational Rose

Контекстную диаграмму здесь нам заменит диаграмма прецедентов или Use Case - диаграмма (рис.1). Она определяет, - что система будет делать (а не как она будет это делать).

Что на ней отражается? Отражаются на ней основные прецеденты. Еще их называют сценарии, варианты использования.

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

Это означает, что клиент является инициатором некоего процесса, а страховое агентство, - его исполнителем.

Клиент и Страховое агентство, - это классы. UML, в целях удобства группировки классов по их назначению позволяет присваивать им стереотип, а Rose дает возможность отображать их графически. Так, клиент имеет стереотип Business Actor (бизнес - актер). Между актером и прецедентом устанавливается связь, которая называется ассоциацией.

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

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

Ассоциация отображается простой стрелкой и означает, что Сотрудник агентства - работает в Страховом агентстве. Генерализация отображается треугольной стрелкой и означает, что Консультант, Страховщик, Кассир и т.д., являются сотрудником агентства. Это очень полезно, т.к. позволяет в некоторых случаях описывать конкретную роль, а когда этого не требуется, использовать обобщенное понятие (вместо того, чтобы рисовать их всех). Так как все они являются сотрудниками агентства, они имеют некоторые общие свойства. Но каждый из них имеет и свои особенности. Можно еще было бы отразить, что Сотрудник агентства может быть мужчиной или женщиной, а они, в свою очередь, являются людьми. Но это было бы лишним, т.к. выходит за рамки нашей модели. (Если, конечно, мы не будем рассматривать автоматизацию туалетов :).

Клиент, в свою очередь, может быть юридическим или физическим лицом (Рис. 3).

Пока мы отразили только одну сторону бизнес-процессов на основе Use Case. Для дальнейшего уточнения процессов могут использоваться и другие диаграммы.

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

Сценарий - это некоторая последовательность действий, иллюстрирующая поведение системы. Он описывается диаграммами действий (Activity). Диаграмма действий в модели деловых прецедентов иллюстрирует поток работ делового прецедента.

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

Здесь все, примерно, как и в модели BPWin. Диаграмма действий по-сути соответствует IDEF3.

При обращении клиента (точка инициации) консультант выполняет поиск информации и сообщает ответ клиенту. Ну мы не будем рассматривать случай, когда ответа нет. Хотя надо бы!

Данная диаграмма, для обозначения ответственных за шаг процесса использует разделительные линии (Swim Lines). Такое, кстати, есть и в BPWin.

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

Общее описание документов можно представить в следующем виде.

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

Аналогичным образом построим диаграмму документов клиента (Рис.7).

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

Еще в Rose имеется хорошая возможность связать объект с конкретным файлом документа. Войдя в свойства объекта можно вызвать этот документ.

Теперь настало время подумать над организационной структурой агентства. Отобразим ее на диаграмме прецедентов (Рис. 8).

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

Теперь продолжим и опишем реализацию прецедента "Заключить договор страхования".

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

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

Диаграмма реализации прецедента "Выплата страхового возмещения" будет иметь следующий вид (Рис. 10).

Здесь она выполнена без Swim line, что не запрещается. Пунктирными стрелками обозначены потоки объектов (данных).

Итак, какие же можно отметить недостатки продукта IBM Rational Rose :

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

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

Зато там много других достоинств :

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

Итак, в данной работе мы выполнили моделирование предметной области, которое включает:

1. Модель функций предметной области (Business Use case model) - рис.1, 4, 9, 10;
2. Модель объектов предметной области (Business object model) - рис.2, 3, 5-8;
3. Спецификации, описывающие производственный процесс - вот этого мы не делали;
4. Словарь терминов предметной области - ну это в принципе ясно.

Мы сделали только первый шаг, - начало построения модели системы. Дальнейшими шагами должны быть:

• Моделирование реализации системы (Use case model). Цель - определить функции создаваемой автоматизированной системы.
• Определение требований (Requirements). Цель - определить, что система должна делать, согласовать это с заказчиком и задокументировать. Основным результатом этапа определения требований к системе является:
  1. Модель функций системы (Use case model), т.е., фактически описание автоматизируемых функций.
  2. Прототип пользовательского интерфейса (User-Interface Prototype).
  3. Спецификации функций системы (Supplementary Specifications).
• Анализ и проектирование. Цель - преобразовать требования к системе в проект системы. Основным результатом здесь является модель стадии проектирования (Design Model). Она показывает каким образом функции системы будут реализовываться посредством объектов и классов.

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