Бизнес-объект

Бизнес-объект - еще одна новая вершина, покоряемая OMG на пути к реализации всеобщей информационной программной среды. Чтобы достичь ее, в рамках OMG несколько лет назад был организован специальный комитет - Business Оbject Domain Task Force (BODTF), который вполне можно назвать заботливой нянькой бизнес-объекта.

0 нем, любимом

Естественно, не стоит так долго ходить вокруг да около столь "интересной личности", как бизнес-объект, и даже не попытаться его описать. Нужно немедленно исправить это упущение. Итак, 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), разделенный на пять стадий.

Рисунок 2. Процесс разработки прикладного ПО

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

Удобным средством описания бизнес-объекта как компонента прикладной системы является UML (Unified Modelling Language), который можно определить как "язык для спецификации, создания, просмотра и документирования элементов программных систем". UML выглядит как набор диаграмм, отражающих и статическую информацию о системе, и взаимоотношение между ее компонентами (рис.3).

Его жизнь

Вернемся к рис.2 и рассмотрим все этапы жизни бизнес-объекта.

Разработка требований
При выработке требований определяется, какие конкретно бизнес-объекты, с какими атрибутами и каким поведением следует создавать. Именно к этому этапу создания промышленных приложений относится столь модное понятие, как перестройка (реинжиниринг) бизнес-процессов (BPR – Business Process Reingineering), чьи родственные отношения с нашим "объектом" несомненны, но трудноопределимы, они ему вроде троюродных дядюшек или двоюродных дедушек. В классическом труде М.Хаммера BPR был определен как "фундаментальное переосмысление и радикальное изменение бизнес-процессов для достижения серьезного выигрыша в важнейших показателях деятельности предприятия, таких как цена, качество, сервис и скорость". К этому И.Якобсон добавляет: "BPR означает, что вы описываете существуюшее положение вещей и обдумываете, почему вы делаете то, что делаете, почему вы делаете это именно этим способом, почему... Короче говоря, BPR требует, чтобы вы ответили на вопрос относительно существующих операций и попытались изменить их с целью использования новых технологий для лучшего обслуживания ваших заказчиков" .

Анализ
Анализ заключается в ревизии содержимого имеющихся в вашем распоряжении хранилищ бизнес-компонентов (Business Component Repository). В таких продуктах, как, например, San Francisco (IBM), предлагается достаточно удачный набор готовых бизнес-компонентов, а недостающие или приобретаются, или разрабатываются. На этой стадии выявляются классы распределенных компонентов и так называемые встроенные (embedded) классы - нераспределенные, чьи реализации не просматриваются по сети. Здесь же выявляются взаимоотношения классов, три типа которых поддерживает UML:

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

Дизайн
На этой стадии строится BOUI (Business Object User Interface) - пользовательский интерфейс для бизнес-объектов, обычно похожий на шаблон для их просмотра и изменения. Один из краеугольных камней нового подхода - практическое отделение представления бизнес-объекта от его сущности. Такая архитектура обеспечивает удобную раздельную реализацию и независимое изменение, а также позволяет использовать разные инструментальные средства для создания объекта и его представления. Бизнес-объект может иметь разные представления в зависимости от вкусов пользователя или других условий. Представление может быть реализовано на клиентской части, на сервере или частично на том и на другом. В итоге получится подробная схема будущей системы - некий аналог стандартных блок-схем.

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

Бизнес-объект можно охарактеризовать как "конкретная сущность, которую деловые люди используют для ведения дел, например "Покупатель", "Счет", "План", "Заказ" и т. д.", иначе можно сказать, что "бизнес-объект - это специализация общей концепции объекта в сфере бизнеса". Обратимся к "материнской" формулировке OMG: "Абстракция бизнес-объекта, которая моделирует реальный мир, реализуется как один объект или более в информационной системе. Каждый такой объект информационной системы, представляющий собой ее прикладной компонент, должен быть поддержан технической инфраструктурой. Технологическая инфраструктура, которая поддерживает Plug & Play npuкладных бизнес-компонент, - это Business Object Facility (BOF)". По OMG - это "инфраструктура (прикладная архитектура, сервисы и т. д.), требуемая для поддержки бизнес-объектов, существующих как взаимодействующие прикладные компоненты в распределенной объектной среде". Можно выделить две основные задачи BOF в реальном времени.

1. Поддержка обмена сообщениями между бизнес-объектами. В рамках CORBA все взаимодействия между компонентами осушествляются через ОRВ, а ВОF представляет собой как бы ргоху между бизнес-объектом и ОRВ, его "контактное лицо" при общении с внешним миром (рис. 4). Спектр передаваемых сообшений достаточно широк: синхронные и асинхронные, условные, запрос на создание или разрушение бизнес-объекта.
2. Поддержка компонентного построения системы. В этой роли BOF по запросу одного бизнес-объекта может активизировать другой, т.е. реально осуществлять Plug & Play динамических компонент. Кроме вышеперечисленных важных функций, на ВОF, являющийся представителем бизнес-объекта в непростом мире CORBA, возложены обязанности поддержки некоторых необходимых CORBA-сервисов:
   • сервис жизненного цикла. Включает в себя основные вехи существования бизнес-объекта: создание, разрушение, активацию (занесение в оперативную память компьютера) и дезактивацию (удаление из памяти);
   • сервис событий. Бизнес-объекты поддерживают, например, события изменения своего состояния. Вместе с тем они могут "подписаться" на какое-либо интересующее событие другого объекта и в соответствии с этим получить через ОRВ уведомление о том, что оно произошло;
   • сервис транзакций. Одно из основных понятий любой бизнес-системы - транзакция представляет собой такое действие над данными системы, которое сохраняет ее устойчивость. Ее классический вариант - ACID-транзакция (Atomicity, Consistency, Isolation, Durability), которую можно определить как набор операций со следуюшими свойствами:
     - atomicity (неделимость). Транзакция является единицей изменения состояния системы: или все изменения, входящие в нее, происходят, или ни одно не происходит. К ним относятся исправления в базе данных, в сообщениях и действия над структурой системы;
     - consistency (устойчивость). Транзакция - корректная программа, не нарушающая целостность ограничений, наложенных на состояние системы.
     - isolation (независимость). В каждый момент времени выполняется только одна транзакция, даже если они были запущены одновременно;
     - durability (продолжительность во времени). Только после успешного завершения транзакции изменения состояния системы становятся действуюшими.
     
     Механизм транзакций занимает почетное место в CORBA-идеологии, и бизнес-объекты под давлением ВОF подчиняются этим суровым правилам. Получив от бизнес-объекта сообщение о начале транзакции, BOF пересылает его на ее сервер (специальной программе, управляющей транзакциями), а также уведомляет его о завершении, регистрирует всех участников транзакции и обрабатывает ее подтверждение или "откат".

В апреле 1998 г. BODTF выпустил спецификации для Business Object Component Architecture (ВОСА), регламентирующие построение программных систем из компонент-объектов, созданных на основе технологии CORBA/IIOP. Новая архитектура разрабатывалась для создания живого открытого рынка программных компонент; интеграции бизнес-решений с Internet- и intranet-технологиями; упрощения процесса разработки прикладных программ.

Основное понятие, с которым работает ВОСА, - framework. Без этого нового члена "дружной семейки", сплотившейся вокруг бизнес-объекта, его описание было бы неполным. Framework, или организатор, работает как инструмент объединения бизнес-объектов в действующую систему, предоставляя им своего рода удобные рабочие "места-кабинеты" для выполнения возложенных на них задач. Организатор, так же как компонент, требует определения, и может быть, например, техническим или бизнес-организатором в зависимости от рода деятельности, которую призван координировать (рис. 5).

Рисунок 5. Бизнес-организатор и технический организатор

Бизнес-организатор собирает бизнес-объекты внутри некоторой сферы бизнеса (домена) в соответствии со специальным соглашением, иначе "контрактом", регламентирующим роли и ответственность компонентов. Контракт, написанный на языке CDL. (Component Definition Language IDL - совместимый язык, представляющий более высокую по отношению к нему степень обобщения для описания семантики бизнес-объектов в вертикальных доменах), позволяет бизнес-организатору собирать компоненты согласно необходимой бизнес-логике. Технический организатор объединяет программные компоненты бизнес-объектов в работоспособную программную структуру.

Бизнес-объекты участвуют в бизнес-процессах, тесное родство которых с нашим героем уже очевидно. На условном генеалогическом древе бизнес-процесс можно изобразить в качестве его брата-близнеца рядом с бизнес-объектом. Последний может быть как статическим - бизнес-объект – данные (например, Заказчик), так и динамическим - бизнес-объект - процесс (например, заказ гостиничного номера или авторизация плательщика), причем во втором случае братья становятся сиамскими близнецами. По OMG бизнес-процесс определяется как "поток работы или информации на всем протяжении бизнеса". Жизненный цикл бизнес-процесса (рис. 6) варьируется от длительного (например, в случае заказа) до короткого (годовой отчет).

Рисунок 6. Пример бизнес-процесса

Долгожители бизнес-процессы представляют собой типичный предмет реинжиниринга (BPR). Говоря о них, нельзя не упомянуть о документообороте (workflow), стандартизация которого также является предметом заботы BODTF. По определению Workflow Management Coalition международной организации, наиболее активно развивающей его философию, под документооборотом понимается "автоматизация бизнес-процесса целиком или какой-либо его части, в результате которой документы, информация или задачи проходят от одного участника к другому в соответствии с набором процедурных правил". Таким образом, он является частью реализации бизнес- объекта "процесс".

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

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

Бизнес-объект и вся его замечательная "семейка" чудесным образом отвечает предъявленным требованиям. Современные инструменты, разработанные OMG, позволяют перейти к качественно новой творческой технике создания программных приложений. Это как бы шаг от натурального феодального хозяйства к интенсивному специализированному труду. Классическое программирование становится средством создания инструментов разработки бизнес-объектов и уходит из повседневной жизни отделов информационных технологий и даже разработчиков прикладных систем. Бизнес-объект выступает как самостоятельный товар на рынке программных средств. Его биография продолжается.

Предыдующее       Следующее