Шеер. Бизнес-процессы. Основные понятия. Теория. Методы
Подождите немного. Документ загружается.
Рис. 55. Архитектура управления объектами
Центральным элементом этой архитектуры является брокер запросов к объектам (ORB),
предназначенный для обмена сообщениями между объектами на гетерогенных платформах в
соответствии со стандартом CORBA (Common Object Request Broker Architecture — Общая
архитектура брокера запросов к объектам).
CORBA — это стандарт, устанавливающий взаимодействие клиентских и серверных
объектов. Клиентский объект может активизировать тот или иной метод с помощью ORB. При
этом ему совершенно не обязательно «знать» местонахождение серверного объекта.
Одна из задач OMG заключается в описании стандарта CORBA. Конкретную реализацию
оставляют на усмотрение различных поставщиков. Среди существующих коммерческих
реализаций можно выделить ORBIX фирмы IONA Technologies, Ltd.
Дальше этого попытки стандартизации объектов приложений пока не идут. Ведется,
однако, работа по определению так называемых «общих бизнес-объектов» (СВО), о которых
речь пойдет далее. Службы CORBA (CORBA services) предоставляют базовые услуги,
например, проверку целостности. Средства CORBA (CORBA facilities) можно сравнить с
универсальной библиотекой классов: они включают стандартные функции, наиболее часто
встречающиеся во многих приложениях, что существенно экономит время и силы
пользователей при работе с приложениями. Домены CORBA (CORBA domains) предлагают
специализированные функции, например, для систем автоматизированного проектирования.
Корпорация Microsoft разработала стандарты для связывания объектно-ориентированных
компонентов. Стандарты СОМ (компонентная объектная модель) для однопользовательских
систем и DCOM (распределенная компонентная объектная модель) для распределенных систем
обеспечивают взаимодействие между объектами. В настоящее время разрабатываются
интерфейсы со стандартом CORBA.
101
Рис. 56. Бизнес-объект SAP
Компания SAP также разработала концепцию взаимодействия с бизнес-объектами,
которая называется BAPI (интерфейс программирования бизнес-приложений). Интерфейсы
BAPI реализуются в качестве методов работы с бизнес-объектами SAP, предоставляя открытый
доступ к бизнес-функциям. Структура бизнес-объектов SAP представлена на рис. 56.
Ядро бизнес-объекта SAP заключает в себе базовую бизнес-логику. Второй слой содержит
бизнес-правила, отвечающие за целостность. Третий слой охватывает объектные методы,
атрибуты, а также средства управления входными событиями, выходные события и описания
BAPI. В качестве интерфейсов поддерживаются стандарты СОМ/ DCOM, CORBA и Java.
В расширенной версии этой концепции бизнес-объекты группируются в пакеты — так
называемые бизнес-компоненты. На первом этапе вся система R/3 включала лишь три
компонента (HR — человеческие ресурсы, LO — логистику и FI/CO — финансы/контроллинг).
Впоследствии было добавлено еще с десяток вновь разработанных компонентов (например,
Business Engineer и Business Information Warehouse). Взаимодействие между этими
компонентами, осуществляемое при помощи технологии ALE (возможность связи
приложений), можно сравнить со способом взаимодействия между независимыми системами R/
3 и между системами R/3 и R/2(см. рис. 57). Концепция ALE поддерживается Группой OAG,
что является залогом продолжения разработки общего стандарта Она также обеспечивает
взаимодействие с Интернет-приложениями.
102
Рис. 57. Бизнес-компоненты
103
Рис.58. Встраивание общих бизнес-объектов
Интерфейсы BAPI и сообщения ALE служат методами доступа к бизнес-объектам или
компонентам Главное различие между ними заключается в степени структурированности. В то
время как сообщение ALE способно активизировать через Интернет сложное приложение,
например, всю процедуру обработки заказа, интерфейсы BAPI предполагают более детальные
методы, скажем, проверку доступности. Сообщения ALE могут обрабатываться асинхронно в
отличие от синхронной работы интерфейсов BAPI.
104
Рис. 59. Рабочее пространство с взаимозаменяемыми компонентами
Опираясь на результаты CORBA, Группа OMG также выступила поборником
стандартизации бизнес-объектов. В 1996 году она опубликовала документ RFP-4, приглашая
специалистов высказать свои идеи относительно стандартизации общих бизнес-объектов (СВО
— Common Business Objects). Задача заключалась в том, чтобы создать описание базовых
приложений, из которых можно было бы конструировать конкретные объекты. Принцип
встраивания СВО показан на рис. 58. Например, СВО может представлять собой объект,
используемый для обработки информации о продажах или данных финансового учета.
Некоторые предложения были связаны с проблемами расчета обменных курсов валюты (этот
вопрос был поднят корпорацией IBM), другие относились к приложениям workflow. Описание
объектов должно создаваться в соответствии с рекомендациями (OMG. Common Business
Objects. 1996, с. 17), разработанными по следующим аспектам:
обозначение СВО,
атрибуты объектов
отношения между СВО,
условия, необходимые для СВО и их взаимоотношений,
правила бизнес-процесса, применяемые к СВО и их взаимоотношениям,
спецификация интерфейсов и методов СВО на языке описания IDL, принятом Группой
OMG.
Благодаря этой деятельности открывается наиболее реальная возможность поставить
разработку программного обеспечения «на конвейер». Одним из ключевых факторов,
способствующих успеху такого подхода, является концепция инфраструктуры.
105
Рис. 60. Промышленная производственная система
Г.5. Рабочее пространство (инфраструктура)
Г.5.1. Концепция рабочего пространства
Объектно-ориентированный подход благодаря принципу наследования расширил
модульную концепцию и упростил процесс внесения изменений, исключив необходимость в
создании новых разновидностей модулей. Концепция инфраструктуры идет еще дальше,
позволяя объединять различные компоненты в конкретное приложение (см. рис. 59). На первый
взгляд это напоминает бизнес-объект. Однако данная концепция включает также
инфраструктурные компоненты (системы workflow, средства моделирования и
межплатформенное программное обеспечение), связывающие бизнес-объекты в приложение в
рамках инфраструктуры. Более того, принцип наследования, присущий объектно-
ориентированному методу, заменяется принципом компонования.
Взаимозаменяемые компоненты в инфраструктуре являются «горячими точками»;
пользователи могут заменять их собственными компонентами в соответствии со своими
потребностями. На рис.59 эти компоненты заштрихованы. Компоненты, которые нельзя
заменить, являются «застывшими точками». Адаптация рабочего пространства путем замены
компонентов называется компонованием и представляет собой альтернативу объектно-
ориентированной адаптации, где подклассы обладают свойством наследования. Таким образом,
рабочие пространства — это незаконченные прикладные системы, которые пользователь может
настроить применительно к конкретным нуждам путем «переключения» компонентов.
Следовательно, этот подход позволяет многократно использовать не только сами компоненты,
но и архитектурное ноу-хау для их связывания.
Программные продукты в этом случае концентрируют внимание на самих рабочих
пространствах и на включении межплатформенного программного обеспечения, перекидывая
мостик между приложениями, операционной системой и аппаратными средствами.
106
Рис. 61. Информационная система, управляемая workflow
Мы попытались провести аналогию между промышленными производственными
системами и информационными системами. Эта аналогия особенно очевидна, когда
информационные системы основаны на технологии workflow и рабочего пространства.
На рис. 60 представлена промышленная производственная система, а на рис. 61 —
информационная система, управляемая workflow, в эквивалентной структуре. Проектирование
и описание продуктов осуществляются на стадии инжиниринга. На стадии планирования
определяются графики выполнения производственных процессов. В информационной системе
это соответствует уровню I концепции АБИ. Производственная система управляется системой
производственных графиков, которая соответствует уровню II концепции АБИ.
Система транспортировки материалов связывает склад, где хранятся подлежащие
обработке объекты, и машинную систему, выполняющую функции обработки. Процесс
реализуется в соответствии с графиком работ. Система перемещения материалов соответствует
системе workflow уровня III концепции АБИ. Хранение и выполнение функций уровня IV
соответствуют базе данных и бизнес-объектам.
Надеемся, что аналогия между приведенными системами прослеживается достаточно
отчетливо. Применительно к информационным системам концепция АБИ подразделяет всю
систему на склад (хранилище данных), систему транспортировки материалов (workflow) и
выполнение функций (бизнес-объекты). Уровни I и II представлены соответственно
моделированием продуктов и процессов — с одной стороны, и планированием и управлением
процессами — с другой. Структурирование информационных систем на подсистемы упрощает
их разработку и управление, а также обеспечивает более гибкую индивидуальную настройку.
Г.5.2. Концепции реализации
107
Сегодня концепции реализации, оперирующие понятием «рабочее пространство»,
находятся на различных этапах разработки. Тем не менее, они наглядно свидетельствуют о
важной роли этой концепция в будущем.
Г.5.2.1. Рабочее пространство (инфраструктура) ARIS
Концепция рабочего пространства (РП) ARIS, разработанная фирмой IDS Sheer AG в
качестве прототипа, совместима с концепцией АБИ, поскольку ARIS Toolset предоставляет
инструментальные средства моделирования и анализа на уровне инжиниринга процессов.
На уровне планирования и управления бизнес-процессами имеются специальные
интегрированные продукты для пооперационного исчисления стоимости, мониторинга,
составления графиков и регулирования мощностей, а также интерфейсы с продуктами
сторонних поставщиков, например, MS Project.
На уровне workflow ARIS предоставляет функции создания прототипов и интерфейсы
примерно с десятью разными системами workflow.
На уровне прикладных систем, помимо интерфейсов для работы со стандартными
программными решениями типа SAP R/3 через процедуры вызова удаленных функций (RFC) и
интерфейсов BAPI, если таковые имеются, представлены обобщенные (родовые) бизнес-
объекты для решений, связанных с логистикой.
Прикладное ноу-хау хранится на уровне I в моделях-прототипах и служит для наполнения
содержанием других уровней. Индивидуальная настройка моделей-прототипов позволяет
адаптировать обобщенные бизнес-объекты, разработанные на уровне IV, к конкретным
приложениям. На рис. 62 представлена архитектура рабочего пространства ARIS, где
управление бизнес-объектами на сервере приложений осуществляется менеджером объектов.
Связь данных с сервером приложений устанавливается при помощи независимого интерфейса с
реляционными базами данных. Шлюз CORBA обеспечивает интерфейс с внешними системами,
которые активизируются событиями. Система workflow в рабочем пространстве ARIS
управляет процессами, происходящими в рамках бизнес-объектов и между ними, а также
связями с внешними системами.
Связь клиентов Windows с сервером приложений реализуется через интерфейсы CORBA.
Бизнес-объекты можно конфигурировать на уровне моделирования, используя типы
моделей уровня I.
Модели данных позволяют вводить дополнительные атрибуты или отбрасывать
ненужные. Визуальные представления (экраны) бизнес-объектов создаются с помощью моделей
шаблонов. Функции бизнес-объектов можно выбирать, используя модели функций. Модели
процессов задают связь между функциями и моделями. Они также управляют процессами в
рамках бизнес-объектов. Привилегии функций и данных описываются организационными
диаграммами и диаграммами привилегий.
Г.5.2.2. Рабочее пространство SAP
Бизнес-объекты и компоненты SAP, представленные на рис. 56 и 57, иллюстрируют
ключевые элементы рабочего пространства SAP. Эти элементы включают модель-прототип
SAP, где бизнес-процессы описываются диаграммами EPC, технологию интеграции ALE,
бизнес-workflow SAP, технологию интерфейсов BAPI для бизнес-объектов и сами бизнес-
объекты.
108
Рис. 62. Архитектура рабочего пространства ARIS
109
Рис. 63. Компоненты SAP Business Engineer
В концепцию рабочего пространства следует включить и SAP Business Engineer (BE)
вместе с его возможностями конфигурирования, хотя этот элемент не упомянут. В общем виде
Business Engineer представлен на рис. 63. Несмотря на индивидуальную разработку различных
компонентов (BE, workflow, моделирование данных и]т.]д.), в настоящее время все более
широкую популярность приобретает интеграция решений. Рабочее пространство SAP
интегрирует не только программные решения SAP, но и решения сторонних производителей
ПО. Это открывает путь к созданию комплексных решений для вертикальных рынков. В то же
время рабочее пространство и технология SAP могут служить инструментарием при разработке
пользователями собственных усовершенствований к SAP R/3.
Г.5.2.3. SNI-ComUnity
Инфраструктура, предложенная фирмой Siemens-Nixdorf, сочетает в себе систему
workflow под названием Workparty, инструментарий для конфигурирования ComUnity и
различные бизнес-объекты для промышленных приложений. Связывая средства моделирования
ARIS на уровне I и (несколько позже) на уровне II, SNI создает концептуальную схему, в той
или иной степени соответствующую концепции АБИ. Архитектура технической платформы
Workparty представлена на рис. 64. Как видим, для нее характерно частое использование
стандартов Microsoft.
110