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

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

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

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

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

 

     Глава 2. Особенности моделирования  информационных процессов  с использованием ППП

     2.1.Построение диаграммы последовательности транзакций (TSD)

 

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

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

     2. Интерфейсный объект В-модели, взаимодействующий с актором, сам становится актором, инициирующим работу информационной системы.

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

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

 
 
 
 
 
 

Рис.2.1. Пример перехода от П-модели к диаграмме последовательности транзакций (TSD) 

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

 
 
 
 
 

           _{Рис. 2.2. Пример взаимодействия различных АРМов} 
 

     2.2. Построение диаграммы структуры объектов (OSD)

 

     При построении OSD используются следующие типы объектов:

 

                                          Интерфейсный объект (Interface Object) – форма

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

           (экранная форма,  меню, командная строка) 

         Управляющий объект (Control Object) –  активный объект,

                                     _{агент,  автоматическая функция} 

                                          Сущность(Entity Object) – пассивный объект, обрабатываемая

                                          структура данных 

     О-модель отображается в OSD по следующим правилам:

     1.   Для интерфейсного объекта О-модели (актора TSD) создается один или  несколько интерфейсных объектов OSD, через которые организуется  информационный обмен пользователя  с информационной системой

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

     3.   В случае полной автоматизации работы управляющего объекта О-модели для него создается соответствующий управляющий объект OSD.

     4.   Для  объектов-сущностей  О-модели  создаются  информационные  объекты-сущности

     OSD.

     5.   Акторы П-модели представляются  объектами-сущностями, отражающими хранимые атрибуты акторов.

     Также как и в О-модели OSD отражает статические  и динамические отношения объектов  (рис.  2.3.).  Динамические  отношения объектов  представляются  пунктирными стрелками, статические – сплошными стрелками. В представленном примере отношения обобщения (is a) классифицируют заказы на заказы на закупку и на заказы клиентов, последние в свою очередь могут быть принятыми и отложенными. Отношение агрегации в примере рассматривает комплект документов из заказа, счета и накладной. 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 

      Рис. 2.3. Диаграмма структуры объектов (OSD)

     2.3. Построение диаграммы взаимодействия объектов (OID)

 

     В OID различают два типа взаимодействий объектов, реализующих динамические отношения:

     • Событие (event) – вызов метода объекта актором.

     • Сообщение (message) – вызов метода объекта из процедуры метода другого объекта.

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

 
 
 
 
 
 
 

Рис.2.4. Возможные взаимодействия объектов 

Технология  построения OID:

1.   Создать OID-диаграмму для последовательности  транзакций TSD.

2.   Скопировать из репозитория все  необходимые объекты, определенные  ранее в OSD.

3.   Установить динамические связи  между объектами в соответствии  с OSD.

4.   Описать объекты, события и сообщения.

Параметры описания объектов (рис. 2.5.):

- Has/redefine operation  – имена методов объекта, вызываемых событиями или сообщениями.

- Communicates with – имена всех связанных объектов, которым посылает сообщение объект. Заполняется системой автоматически.

- Sends – имена сообщений (вызываемых методов), которые посылает объект.

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

 
 
 
 

      Рис. 2.5. Графическая интерпретация параметров описания объектов

Параметры описания событий  (рис. 2.6.)

- Sent by – имя актора (источник),  вызывающего событие.

- Invokes – имя события (вызываемого метода).

- Received by – имя объекта (адресата), обрабатывающего событие (выполняющего метод).

 
 
 
 

Рис. 2.6. Графическая интерпретация параметров описания событий 

Параметры описания сообщений  (рис. 2.7.)

- Triggered by (источник сообщения) – имя предшествующего метода, из которого осу-

ществляется вызов сообщения (метода).

- Invokes – имя события (вызываемого метода)

- Received by – имя объекта (адресата), обрабатывающего сообщение (выполняющего метод).

 
 
 

Рис. 2.7. Графическая интерпретация параметров описания сообщений 
 
 
 
 

Заключение

 

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

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

     Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

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

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