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

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

Выбор методологии моделирования

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

Методология IDEF0 [2]. Для построения модели предметной области «как надо»;

Методология IDEF1x [2]. Для информационного моделирования и разработки логической структуры БД;

Нотация UML 2.0. Для моделирования и проектирования информационной системы.

IDEFO является языком моделирования бизнес-процессов, предложенным в 1973 году Дугласом Россом (SoftTech, Inc.) и называвшимся первоначально SADT — Structured Analysis and Design Technique.

В IDEFO система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. [2].

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

верхняя сторона имеет значение «управления» .

левая — «входа» .

правая — «выхода» .

нижняя — «механизма» .

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

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

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

IDEF1X является статическим методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы — универсального представления структуры данных в рамках коммерческого предприятия, независимого от конечной реализации базы данных и аппаратной платформы. [3].

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

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

Язык UML (Unified Modeling Language) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. 5,6].

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

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

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

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

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

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

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

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

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