Его жизнь

Вернемся к рис.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 в реальном времени.

Рисунок 4. Обмен сообщениями между бизнес-объектами

1. Поддержка обмена сообщениями между бизнес-объектами. В рамках CORBA все взаимодействия между компонентами осушествляются через ОRВ, а ВОF представляет собой как бы ргоху между бизнес-объектом и ОRВ, его "контактное лицо" при общении с внешним миром (рис. 4). Спектр передаваемых сообшений достаточно широк: синхронные и асинхронные, условные, запрос на создание или разрушение бизнес-объекта.

2. Поддержка компонентного построения системы. В этой роли BOF по запросу одного бизнес-объекта может активизировать другой, т.е. реально осуществлять Plug & Play динамических компонент. Кроме вышеперечисленных важных функций, на ВОF, являющийся представителем бизнес-объекта в непростом мире CORBA, возложены обязанности поддержки некоторых необходимых CORBA-сервисов:

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

o сервис событий. Бизнес-объекты поддерживают, например, события изменения своего состояния. Вместе с тем они могут "подписаться" на какое-либо интересующее событие другого объекта и в соответствии с этим получить через ОRВ уведомление о том, что оно произошло;

o сервис транзакций. Одно из основных понятий любой бизнес-системы - транзакция представляет собой такое действие над данными системы, которое сохраняет ее устойчивость. Ее классический вариант - 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, позволяют перейти к качественно новой творческой технике создания программных приложений. Это как бы шаг от натурального феодального хозяйства к интенсивному специализированному труду. Классическое программирование становится средством создания инструментов разработки бизнес-объектов и уходит из повседневной жизни отделов информационных технологий и даже разработчиков прикладных систем. Бизнес-объект выступает как самостоятельный товар на рынке программных средств. Его биография продолжается.