Объектный подход к моделированию бизнес-процессов

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

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

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

· обеспечить понимание структуры организации и динамики происходящих в ней процессов;

· обеспечить понимание проблем организации и возможностей их решения;

· убедиться, что заказчики, пользователи и разработчики одинаково понимают цели и задачи организации;

· создать базу для формирования требований к информационной системе.

Объектно-ориентированный подход к моделированию бизнес-процессов с использованием языка UML реализован в технологии Rational Unified Process. Методика моделирования предусматривает построение двух моделей:

· модели бизнес-процессов (Business Use Case Model);

· модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов – модель, описывающая бизнес-процессы организации в терминах ролей и их потребностей. Представляет собой расширение модели вариантов использования за счет введения стереотипов Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования).

Business Actor (действующее лицо бизнес-процессов) – это некоторая роль, внешняя по отношению к бизнес-процессам организации. Потенциальными кандидатами в действующие лица бизнес-процессов являются: акционеры, заказчики, поставщики, партнеры, потенциальные клиенты, местные органы власти, сотрудники не охваченных моделью подразделений организации, внешние системы.

Список действующих лиц составляется путем ответа на следующие вопросы:

· кто извлекает пользу из существования организации?

· кто помогает организации осуществлять свою деятельность?

· кому организация передает информацию и от кого получает?

Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Методика концентрирует внимание на элементарных бизнес-процессах. Такой процесс можно определить как задачу, выполняемую одним человеком в одном месте в одно время в ответ на некоторое событие, приносящую конкретный результат и переводящую данные в некоторое устойчивое состояние (например, подтверждение платежа по кредитной карте). Выполнение такой задачи обычно включает 5–10 шагов, может занимать от нескольких минут до нескольких дней, но рассматривается как один сеанс взаимодействия действующего лица с исполнителями. Каждый Business Use Case отражает цель или потребность некоторого действующего лица. Описание Business Use Case включает:

· наименование;

· краткое описание;

· цели и результаты (с точки зрения действующего лица);

· описание сценариев (основного и альтернативных);

· специальные требования (ограничения по времени или другим ресурсам);

· расширения (исключительные ситуации);

· связи с другими Business Use Case;

· диаграммы деятельности (для наглядного описания сценариев).

Для каждого Business Use Case строится модель бизнес-анализа – объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов)двух классов – Business Worker и Business Entity.

Business Worker (исполнитель) – активный класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют сущностями, участвуя в реализациях сценариев Business Use Case. На диаграмме классов исполнитель представляется в виде класса со стереотипом «business worker».

Business Entity (сущность) – пассивный класс, не инициирующий никаких взаимодействий. Объект такого класса может участвовать в реализациях различных Business Use Case. Сущность является объектом различных действий со стороны исполнителей. Понятие Business Entity аналогично понятию сущности в модели ERM (в ERM не определяется поведение сущности). На диаграмме классов сущность представляется в виде класса со стереотипом «business entity».

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

· диаграммы последовательностей (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций;

· диаграммы деятельностей с потоками объектов и «плавательными дорожками», описывающие связи между сценариями одного или разных Business Use Case;

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

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

· все действующие лица, варианты использования и диаграммы вариантов использования для бизнес-процессов помещаются в пакет Business Use Case Model;

· все классы и диаграммы моделей бизнес-анализа помещаются в пакет Business Analysis Model;

· если моделируется деятельность нескольких подразделений организации, то совокупность всех классов-исполнителей и классов-сущностей для различных Business Use Case разделяется на пакеты, соответствующие этим подразделениям;

· все диаграммы модели бизнес-анализа, относящиеся к конкретному Business Use Case помещаются в кооперацию с именем данного Business Use Case и стереотипом «business use-case realization» (реализация бизнес-процесса). Все кооперации помещаются в пакет с именем Business Use Case Realizations.

Достоинства методики моделирования Rational Unified Process:

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

· моделирование на основе вариантов использования способ­ствует хорошему пониманию бизнес-модели со стороны за­казчиков.

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

2. работа в среде Rational Rose

2.1. Инструментальное средство Rational Rose

Одним из лидеров в области создания методологий и программных решений является корпорация Rational Software (сейчас – в составе IBM). Спектр выпускаемого ею программного обеспечения покрывает потребности всех участников проекта. Все программно-методологические решения – это итоги многолетнего труда аналитиков и разработчиков корпорации и ее партнеров. Так появился RUP (Rational Unified Process) – методологическая энциклопедия, в которой описаны шаги, необходимые для создания качественного программного продукта. Использование этой энциклопедии и соответствующих инструментов позволяет создавать информационные системы качественно и в срок. Основным инструментальным средством является Rational Rose.

Rational Rose – CASE -средство, предназначенное для автоматизации этапов анализа и проектирования программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows, ObjectPro). Основной вариант – Rational Rose / C++ – позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонентов в новых проектах. Rational Rose допускает как высокоуровневое (абстрактное) представление (схема автоматизации предприятия), так и низкоуровневое проектирование (интерфейс программы, схема базы данных, описание классов).

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

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

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

Важнейшим свойством Rational Rose является открытость архитектуры, что позволяет дополнять имеющийся инструментарий новыми функциями. Благодаря большому списку стандартных модулей (С++, ADA, CORBA, Visual Basic, XML, COM, Oracle), Rational Rose способна проводить прямое и обратное проектирование в данных системах. Если стандартный вариант Rational Rose не поддерживает кодогенерацию, например, на Ассемблере, то создание дополнительного модуля позволяет решить подобную проблему. Таким образом, Rational Rose позволяет:

· проектировать системы любой сложности;

· давать развернутое представление о проекте;

· выполнять кодогенерацию;

· выполнять обратное проектирование систем.

Основные особенности Rational Rose:

· открытый для дополнений интерфейс;

· интеграция со средствами разработки;

· поддержка языка UML;

· наличие средств автоматического контроля;

· удобный графический интерфейс пользователя;

· возможность работы на разных платформах;

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

2.2. Элементы экрана Rational Rose

Пятью основными элементами интерфейса Rational Rose (рис. 22) являются:

· браузер (browser);

· окно документации (documentation window);

· панели инструментов (toolbars);

· окно диаграмм (diagram window);

· журнал (log).

Рис. 22. Интерфейс Rational Rose

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

С помощью браузера можно:

· добавлять элементы к модели;

· просматривать существующие элементы модели;

· просматривать существующие связи между элементами модели;

· перемещать элементы модели;

· переименовывать эти элементы;

· добавлять элементы модели на диаграмму;

· связывать элемент с файлом или Интернет-адресом;

· группировать элементы в пакеты

· работать с детализированной спецификацией элемента;

· открывать диаграмму.

Браузер поддерживает четыре представления – вариантов использования, компонентов, размещения и логическое представление. Они будут описаны ниже. Браузер имеет древовидную структуру. Каждый элемент модели может содержать другие элементы, находящиеся в иерархии ниже его. Знак «–» около элемента означает, что его ветвь полностью раскрыта. Знак «+» – что его ветвь свернута.

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

Панели инструментов обеспечивают быстрый доступ к наиболее распространенным командам. В среде Rational Rose существует два типа панелей инструментов – стандартная панель и панель диаграммы. Стандартная панель видна всегда, ее кнопки соответствуют командам, которые могут использоваться для работы с любой диаграммой. Панель диаграммы своя для каждого типа диаграмм UML.

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

1) выберите пункт меню Tools > Options;

2) выберите вкладку Toolbars;

3) пометьте (снимите пометку) контрольный переключатель Show Standard ToolBar (Show Diagram ToolBar).

Чтобы увеличить размер кнопок на панели инструментов:

1) щелкните правой кнопкой мыши на требуемой панели;

2) выберите во всплывающем меню пункт Use Large Buttons (Использовать большие кнопки).

Чтобы настроить панель инструментов:

1) щелкните правой кнопкой мыши на требуемой панели;

2) выберите пункт Customize (Настроить);

3) чтобы добавить или удалить кнопки, выберите кнопку и щелкните мышью на кнопке Add (Добавить) или Remove (Удалить), как показано на рис. 23.

Существует два способа удалить элемент модели – из одной диаграммы или из всей модели. Чтобы удалить элемент модели из диаграммы:

1) выделите элемент на диаграмме;

2) нажмите на клавишу Delete;

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

Рис. 23. Настройка стандартной панели инструментов

Чтобы удалить элемент из модели:

1) выделите элемент на диаграмме;

2) выберите пункт меню Edit > Delete from Model или нажмите CTRL + D.

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

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

2.3. Четыре представления модели Rational Rose

В модели Rational Rose поддерживается четыре представления (views):

· представление вариантов использования;

· логическое представление;

· представление компонентов;

· представление размещения.

Представление вариантов использования (Use Case View) содержит модель бизнес-процессов и модель вариантов использования.

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

· классы;

· диаграммы классов (для описания используется несколько диаграмм);

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

· диаграммы состояний;

· пакеты, являющиеся группами взаимосвязанных классов.

Представление компонентов (Component View) содержит:

· компоненты, являющиеся физическими модулями кода;

· диаграммы компонентов;

· пакеты, являющиеся группами связанных компонентов.

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

· процессы (потоки, исполняемые в отведенной для них области памяти);

· процессоры, включающие любые компьютеры, способные обрабатывать данные (любой процесс выполняется на одном или нескольких процессорах);

· устройства, то есть любая аппаратура, не способная обрабатывать данные (терминалы ввода-вывода, принтеры и т.д.);

· диаграмма размещения.