стали предъявляться все более серьезные требования к бизнес-приложениям, которые от простейшего расчета заработной платы или печати счетов-фактур перешли к сложным алгоритмам планирования и распределения ресурсов. Создание одного "монолитного" программного продукта, способного решать все задачи современного промышленного предприятия, становится все более трудоемким и зачастую, пожалуй, просто неподъемным делом. Кроме того, к сожалению, и здесь все подчиняется правилу: или качество, или количество. Либо много узкоспециализированных качественных программ, либо одно "неповоротливое" приложение, стремящееся объять необъятное пространство современной промышленной корпорации. Идеология, предложенная OMG, чтобы выбраться из ямы раздробленности высококлассных программ, - выработка единых спецификаций, которые позволят программным продуктам различных фирм взаимодействовать друг с другом в общей информационной среде. Естественно, такое решение приводит к дополнительным сложностям и увеличивает "накладные расходы" при разработке программного обеспечения, поэтому в последние годы само существование спецификаций OMG было под вопросом: "Примут - не примут? Поддержат - не поддержат?" Наконец в 1997 г. количество программ, разработанных в новой идеологии, перешло "принципиальный" рубеж, что позволило сделать однозначный вывод - путь, предложенный OMG, стал "дорогой жизни" для промышленных приложений.
Главное детище OMG - это, несомненно, CORBA (Common Object Request Broker Architecture) [1-3]. Ее центральной частью является ORB (Object Request Broker - брокер объектных запросов) - спецификация на программный продукт, обычно представляющий собой набор демонов или динамических библиотек, который обеспечивает взаимодействие различных программ в распределенной компьютерной среде. Наиболее известные на сегодняшний день брокеры - ORBIX фирмы Iona Technologies и Visigenic компании Inprise.
Также OMG разработала спецификации обмена информацией между брокерами различных фирм-производителей GIOP (General Inter ORB Protocol) и конкретно для работы в Internet - IIOP (Internet Inter ORB Protocol). Фирма Iona Technologies создала интерфейсы между CORBA- и COM/DCOM-приложениями (спецификация промежуточного ПО, созданная и поддерживаемая Microsoft), включив тем самым продукцию корпорации в сферу влияния CORBA. Для задания спецификаций используется специальный язык описания интерфейса IDL (Interface Definition Language), для которого разработаны компиляторы, генерирующие текст на Си++, Смолток, Ада, Java.
Бизнес-объект - еще одна новая вершина, покоряемая OMG на пути к реализации всеобщей информационной программной среды. Чтобы достичь ее, в рамках OMG несколько лет назад был организован специальный комитет - Business Object Domain Task Force (BODTF), который вполне можно назвать заботливой нянькой бизнес-объекта.
О нем, любимом
Естественно, не стоит так долго ходить вокруг да около столь "интересной личности", как бизнес-объект, и даже не попытаться его описать. Нужно немедленно исправить это упущение. Итак, alma-mater бизнес-объекта - OMG охарактеризовала его как представление активных структур (единиц, понятий, атомов) бизнеса, которое обязательно включает в себя имя, определение, атрибуты, поведение, взаимосвязи, правила, политику и ограничения. Бизнес-объект может представлять собой, например, персону, место, событие, бизнес-процесс или концепцию, а совсем уж конкретно-служащего, продукт, счет-фактуру и платеж. Следовательно, в "паспорте" или "свидетельстве о рождении" бизнес-объекта должны быть приведены все необходимые данные.
Имя. В паспорте человека указываются имя, отчество и фамилия. Бизнес-объект может "именоваться" пятью способами:
- уникальным в распределенной объектной системе CORBA-именем, необходимым для получения права быть включенным в сетевое взаимодействие с помощью брокера объектных запросов (ORB), так как бизнес-объект должен удовлетворять соответствующей службе имен;
- неповторяющимся внутри бизнес-домена идентификатором, определяющим бизнес-объект в реальной сфере деятельности, причем это имя обычно включает тип объекта и уникальный для него ключ;
- идентификатором (PersistentID), напоминающим библиотечную карточку, по которому он хранится и извлекается из общего хранилища;
- внешними идентификаторами, представляющими собой имя или код, которые определяют реалии внешнего мира, ассоциированные с бизнес-объектом. Это имя зависит от контекста, в котором действует наш герой, и по смыслу близко кличкам: в каждой компании - своя;
- квалификационным именем для связи с внешней службой имен, которое зачастую представляет собой композицию предыдущих четырех.
Определение - декларирование значения и целей, присвоенных бизнес-объекту.
Атрибуты - ассоциированные с бизнес-объектом элементы данных или объекты, причем значение атрибута не обязательно должно быть уникальным, поскольку относится только к конкретному бизнес-объекту. Такие "несамостоятельные атрибуты" называются зависимыми типами (dependent types). В качестве атрибутов могут выступать как отдельные параметры, так и сложная обширная структура данных. Обращение к ним возможно с помощью методов доступа через специальные формы, независимые от конкретной реализации бизнес-объекта.
Поведение - деятельность бизнес-объекта в тех или иных условиях в соответствии с определенными правилами, в частности отображения бизнес-объекта, последовательности операций (включая условные переходы, распознаваемые события, изменение атрибутов и реакцию на внешние запросы).
Взаимосвязи. "Общительность" бизнес-объекта - необходимое условие для его полноценной жизни. Схемы взаимодействия бизнес-объектов различны: "один-к одному" (one-to-one) или "один-ко многим" (one-to-many), одно- или двунаправленные (рис. 1). Реализация связей инкапсулирована и для поддержания целостности системы в большинстве случаев управляется Business Object Facility (BOF). Например, если два бизнес-объекта поддерживают между собой управляемую двустороннюю связь, то при ее разрыве одним объектом другой должен отреагировать соответствующим образом. К взаимосвязям, как и атрибутам, можно обращаться через методы доступа, реализованные в виде некоторых форм.
Правила, политика и ограничения определяют поведение, атрибуты и внешние связи бизнес-объекта, а реализуются чаще всего через механизм описания событий.
Можно попытаться взглянуть на бизнес-объект с разных точек зрения. Одно из подразделений OMG - Business Object Management Special Interest Group (BOMSIG) - характеризует бизнес-объект как компонент прикладного уровня, используемый в ситуациях, которые невозможно было спрогнозировать на стадии его создания, т. е. интеллектуальный компонент, который умеет самостоятельно реагировать на воздействия внешней среды. Пожалуй, наступил момент прояснить родственные взаимоотношения двух понятий - бизнес-объекта и компонента. Следует оговориться, что далее этими понятиями мы будем оперировать на "планете" распределенных программных приложений, в мире, выстроенном и поддерживаемом OMG. Собственно, само понятие "компонент" без связанного с ним определения может относиться к чему угодно, и поэтому бизнес-объект также является компонентом прикладной системы. Если же под ним понимать распределенный компонент CORBA, то можно проследить за постепенными взаимовлияниями и метаморфозами двух понятий.
Рассмотрим процесс разработки прикладного ПО (рис. 2), разделенный на пять стадий. Понятие "бизнес-объект" употребляется на всех этапах создания готовой системы, в то время как распределенный компонент - реализация бизнес-объекта, который, появляясь на стадии анализа, уходит со сцены после завершения разработки. Таким образом, распределенный компонент - это как бы кокон, в котором пребывает бизнес-объект, перед тем как занять свое важное место в мире "живых" работающих приложений. Для уточнения: программный же компонент - это просто достаточно независимая часть программного кода, которая легко встраивается в программу и несет информацию о себе самой.
Удобным средством описания бизнес-объекта как компонента прикладной системы является UML (Unified Modelling Language), который в работе [4] определен как "язык для спецификации, создания, просмотра и документирования элементов программных систем". UML выглядит как набор диаграмм, отражающих и статическую информацию о системе, и взаимоотношение между ее компонентами (рис.3).
Его жизнь
Разработка требований
При выработке требований определяется, какие конкретно бизнес-объекты, с какими атрибутами и каким поведением следует создавать. Именно к этому этапу создания промышленных приложений относится столь модное понятие, как перестройка (реинжиниринг) бизнес-процессов (BPR - Business Process Reingineering), чьи родственные отношения с нашим "объектом" несомненны, но трудноопределимы, они ему вроде троюродных дядюшек или двоюродных дедушек. В классическом труде М.Хаммера [6] BPR был определен как "фундаментальное переосмысление и радикальное изменение бизнес-процессов для достижения серьезного выигрыша в важнейших показателях деятельности предприятия, таких как цена, качество, сервис и скорость". К этому И.Якобсон добавляет: "BPR означает, что вы описываете существующее положение вещей и обдумываете, почему вы делаете то, что делаете, почему вы делаете это именно этим способом, почему... Короче говоря, BPR требует, чтобы вы ответили на вопрос относительно существующих операций и попытались изменить их с целью использования новых технологий для лучшего обслуживания ваших заказчиков" [7].
Анализ
Анализ заключается в ревизии содержимого имеющихся в вашем распоряжении хранилищ бизнес-компонентов (Business Component Repository). В таких продуктах, как, например, San Franсisсo (IBM), предлагается достаточно удачный набор готовых бизнес-компонентов, а недостающие или приобретаются, или разрабатываются. На этой стадии выявляются классы распределенных компонентов и так называемые встроенные (embedded) классы - нераспределенные, чьи реализации не просматриваются по сети. Здесь же выявляются взаимоотношения классов, три типа которых поддерживает UML:
- ассоциация или простое объединение, в котором каждому объекту дается определенная роль. Ей ставится в соответствие коэффициент, показывающий, сколько объектов могут участвовать в объединении;
- агрегация, т.е. один объект является частью другого;
- генерализация; при этом объекты принадлежат к классам, связанным отношением наследования.
Дизайн
На этой стадии строится BOUI (Business Object User Interface) - пользовательский интерфейс для бизнес-объектов, обычно похожий на шаблон для их просмотра и изменения. Один из краеугольных камней нового подхода - практическое отделение представления бизнес-объекта от его сущности. Такая архитектура обеспечивает удобную раздельную реализацию и независимое изменение, а также позволяет использовать разные инструментальные средства для создания объекта и его представления. Бизнес-объект может иметь разные представления в зависимости от вкусов пользователя или других условий. Представление может быть реализовано на клиентской части, на сервере или частично на том и на другом. В итоге получится подробная схема будущей системы - некий аналог стандартных блок-схем.
Сборка
И в заключение о сборке готового приложения, когда из разработанных компонентов строится ПО, соответствующее бизнес-процессам, определенным при выработке требований.
В работе [9] бизнес-объект характеризуется как "конкретная сущность, которую деловые люди используют для ведения дел, например "Покупатель", "Счет", "План", "Заказ" и т. д.", иначе можно сказать, что "бизнес-объект - это специализация общей концепции объекта в сфере бизнеса". Обратимся к "материнской" формулировке OMG: "Абстракция бизнес-объекта, которая моделирует реальный мир, реализуется как один объект или более в информационной системе. Каждый такой объект информационной системы, представляющий собой ее прикладной компонент, должен быть поддержан технической инфраструктурой. Технологическая инфраструктура, которая поддерживает Plug & Play прикладных бизнес-компонент, - это Business Object Facility (BOF)". По OMG - это "инфраструктура (прикладная архитектура, сервисы и т. д.), требуемая для поддержки бизнес-объектов, существующих как взаимодействующие прикладные компоненты в распределенной объектной среде". Можно выделить две основные задачи BOF в реальном времени.
1. Поддержка обмена сообщениями между бизнес-объектами. В рамках CORBA все взаимодействия между компонентами осуществляются через ORB, а BOF представляет собой как бы proxy между бизнес-объектом и ORB, его "контактное лицо" при общении с внешним миром (рис.4). Спектр передаваемых сообщений достаточно широк: синхронные и асинхронные, условные, запрос на создание или разрушение бизнес-объекта.
2. Поддержка компонентного построения системы. В этой роли BOF по запросу одного бизнес-объекта может активизировать другой, т.е. реально осуществлять Plug & Play динамических компонент. Кроме вышеперечисленных важных функций, на BOF, являющийся представителем бизнес-объекта в непростом мире CORBA, возложены обязанности поддержки некоторых необходимых CORBA-сервисов:
- сервис жизненного цикла. Включает в себя основные вехи существования бизнес-объекта: создание, разрушение, активацию (занесение в оперативную память компьютера) и дезактивацию (удаление из памяти);
- сервис событий. Бизнес-объекты поддерживают, например, события изменения своего состояния. Вместе с тем они могут "подписаться" на какое-либо интересующее событие другого объекта и в соответствии с этим получить через ORB уведомление о том, что оно произошло;
- сервис транзакций. Одно из основных понятий любой бизнес-системы - транзакция представляет собой такое действие над данными системы, которое сохраняет ее устойчивость.Ее классический вариант - ACID-транзакция (Atomicity, Consistency, Isolation, Durability), которая определена в работе [8] как набор операций со следующими свойствами:
- - atomicity (неделимость). Транзакция является единицей изменения состояния системы: или все изменения, входящие в нее, происходят, или ни одно не происходит. К ним относятся исправления в базе данных, в сообщениях и действия над структурой системы;
- - consistency (устойчивость). Транзакция - корректная программа, не нарушающая целостность ограничений, наложенных на состояние системы.
- -isolation (независимость). В каждый момент времени выполняется только одна транзакция, даже если они были запущены одновременно;
- -durability (продолжительность во времени). Только после успешного завершения транзакции изменения состояния системы становятся действующими.
Механизм транзакций занимает почетное место в CORBA-идеологии, и бизнес-объекты под давлением BOF подчиняются этим суровым правилам. Получив от бизнес-объекта сообщение о начале транзакции, BOF пересылает его на ее сервер (специальной программе, управляющей транзакциями), а также уведомляет его о завершении, регистрирует всех участников транзакции и обрабатывает ее подтверждение или "откат".
В апреле 1998 г. BODTF выпустил спецификации для Business Object Component Architecture (BOCA), регламентирующие построение программных систем из компонент-объектов, созданных на основе технологии CORBA/IIOP. Новая архитектура разрабатывалась для создания живого открытого рынка программных компонент; интеграции бизнес-решений с Internet- и intranet-технологиями; упрощения процесса разработки прикладных программ.
Основное понятие, с которым работает BOCA, - framework. Без этого нового члена "дружной семейки", сплотившейся вокруг бизнес-объекта, его описание было бы неполным. Framework, или организатор, работает как инструмент объединения бизнес-объектов в действующую систему, предоставляя им своего рода удобные рабочие "места-кабинеты" для выполнения возложенных на них задач. Организатор, так же как компонент, требует определения, и может быть, например, техническим или бизнес-организатором в зависимости от рода деятельности, которую призван координировать (рис. 5). Бизнес-организатор собирает бизнес-объекты внутри некоторой сферы бизнеса (домена) в соответствии со специальным соглашением, иначе "контрактом", регламентирующим роли и ответственность компонентов. Контракт, написанный на языке CDL (Сomponent Definition Language - IDL-совместимый язык, представляющий более высокую по отношению к нему степень обобщения для описания семантики бизнес-объектов в вертикальных доменах), позволяет бизнес-организатору собирать компоненты согласно необходимой бизнес-логике. Технический организатор объединяет программные компоненты бизнес-объектов в работоспособную программную структуру.
Бизнес-объекты участвуют в бизнес-процессах, тесное родство которых с нашим героем уже очевидно. На условном генеалогическом древе бизнес-процесс можно изобразить в качестве его брата-близнеца рядом с бизнес-объектом. Последний может быть как статическим - бизнес-объект - данные (например, Заказчик), так и динамическим - бизнес-объект - процесс (например, заказ гостиничного номера или авторизация плательщика), причем во втором случае братья становятся сиамскими близнецами. По OMG бизнес-процесс определяется как "поток работы или информации на всем протяжении бизнеса". Жизненный цикл бизнес-процесса (рис. 6) варьируется от длительного (например, в случае заказа) до короткого (годовой отчет).
Долгожители бизнес-процессы представляют собой типичный предмет реинжиниринга (BPR). Говоря о них, нельзя не упомянуть о документообороте (workflow), стандартизация которого также является предметом заботы BODTF. По определению Workflow Management Coalition - международной организации, наиболее активно развивающей его философию, под документооборотом понимается "автоматизация бизнес-процесса целиком или какой-либо его части, в результате которой документы, информация или задачи проходят от одного участника к другому в соответствии с набором процедурных правил". Таким образом, он является частью реализации бизнес-объекта "процесс".
Ниже рассмотрим такой основной элемент бизнес-процесса, как активность. Каждый бизнес-процесс состоит из одной или нескольких активностей и сам является активностью высокого уровня. В каждый момент времени выполняется только одна активность, а момент их смены называется переходом, причем он может быть связан с некоторыми условиями.
* * *
Рождение бизнес-объекта произвело настоящий переворот в стане промышленных программных приложений. Давно назревавшая классическая "революционная ситуация", когда низы (те, кто работает с программным обеспечением, - пользователи и разработчики) не хотят, а верхи (те, кто принимает решение об использовании программного средства) не могут жить по-старому, разрешилась описанным выше подходом к созданию таких систем. Попробуем охарактеризовать основные требования к новой политике:
- возможность адаптации. Даже безупречная готовая система обязательно потребует дополнительных усилий для ее подгонки под конкретные задачи;
- унифицированность. В строго конкретных задачах зачастую можно выделить общую для любых предприятий основу и индивидуальные особенности;
- сокращение сроков создания;
- упрощение внедрения. Многочисленные теории, призванные ускорить этот процесс, взваливают все усилия на команду внедрения и персонал предприятия, исходя из того, что система есть. Но ведь можно перенести центр тяжести на саму систему;
- приспособляемость. Информационная система как модель предприятия обязана развиваться вместе с ним;
- возможность информационного обмена между старыми и новыми системами, работающими на предприятии;
- ориентация на Internet.
Бизнес-объект и вся его замечательная "семейка" чудесным образом отвечает предъявленным требованиям. Современные инструменты, разработанные OMG, позволяют перейти к качественно новой творческой технике создания программных приложений. Это как бы шаг от натурального феодального хозяйства к интенсивному специализированному труду. Классическое программирование становится средством создания инструментов разработки бизнес-объектов и уходит из повседневной жизни отделов информационных технологий и даже разработчиков прикладных систем. Бизнес-объект выступает как самостоятельный товар на рынке программных средств. Его биография продолжается.
Литература
1. Offali R., Harkey D., Edwards J. Essential Distributed Objects Survival Guide. Wiley, 1996.
2. Offali R., Harkey D., Edwards J. Instant CORBA. Wiley Inc., 1997.
3. Baker S. Corba Distributed Objects: Using Orbix. 1997
4. Rational Software Corporation. Unified Modelling Language version 1.1. 1997.
5. Jacobson I. Object-oriented software engineering. Addison-Wesley, Reading, Massachusetts, 1992.
6. Hammer M., Champy J. Reengineering the Corporation. 1993.
7. Jacobson I., Ericsson M., Jacobson A. Business Process Reengineering with Object Tecnology. Addison-Wesley Publishing company, 1994.
8. Gray J. and Reuter A. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993.
9. Eeles P. and Sims O. Building Business Objects. John Wiley & Sons, 1998.
Список Internet-адресов
http://www.omg.org/library/schedule.htm - докуметы OMG, относящиеся к проблематике бизнес-объектов
http://home.gte.net/pfingar - библиотека объектно-ориентированных решений для бизнес-инжиниринга
ОБ АВТОРЕ
Марина Аншина - руководитель сектора разработок и системной поддержки компании "ТопС, системный интегратор".
Тел.: (095) 253-6318, e-mail: marinaa@tops-msk.co