Г.4.2. Компонентное программное обеспечение

 

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

 

Г.4.2.1. Объекты

 

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

Системы разрабатываются на уровне типов, т. е. похожие объекты группируются в классы. В этой книге мы не разграничиваем понятия «объект» (уровень экземпляров) и «классы» (уровень типов), а говорим просто об объектах. О каком именно понятии идет речь, становится ясно из контекста. Еще одной характеристикой объектов является их наследственная функциональность. Она позволяет подчиненным классам наследовать методы и атрибуты, присущие вышестоящим классам, посредством обобщения или специализации. Наследование лежит в основе принципа многократного использования.

Очевидно, что характеристики объектно-ориентированных методов можно было бы описать гораздо подробнее, однако для целей данной работы достаточно и беглого обзора. Рис. 52 иллюстрирует объектно-ориентированное описание процесса «обработка заказа», рассмотренного в разделе Б.1. Здесь представлены объекты, их имена, атрибуты и методы. Показан также обмен сообщения ми, включая метод соответствующего целевого объекта, передаваемые данные и данные, содержащиеся в ответе. В отличие от рис. 5, где приведен информационный поток, здесь мы дифференцируем функции, активизирующие обмен данными. Поток сообщений, который является результатом потока управления бизнес-процессом, использовать необязательно, так как последовательность выполнения функций внутри объектов не указана. Напомним, что бизнес-процессы характеризуются рядом потоков, включая функциональный, выходной, информационный и организационный. В управлении workflow акцент делается на функциональном потоке, тогда как в фокусе объектно-ориентированной концепции находится поток сообщений между информационными объектами.

Рис. 52. Объектно-ориентированное представление процесса «обработка заказа»

Рис. 53. Бизнес-объекты в примере «обработка заказа»

Объектная ориентация лежит в основе различных языков программирования (Java, C++, и т. д.). При разработке программ объектные библиотеки позволяют многократно использовать протестированные объекты.

Однако реализация этих базовых принципов с помощью объектно-ориентированного языка программирования ни в какой мере не гарантирует повышения эффективности по сравнению с традиционными модульными концепциями. Одной из самых распространенных причин громоздкости комплексных систем является чрезмерное структурирование их объектов. К тому же сильно структурированные объекты трудно активизировать с помощью приемлемой системы workflow. Именно поэтому объекты нередко объединяются в более крупные единицы — так называемые «бизнес-объекты», включающие прикладную информацию о взаимодействии внутренних объектов.

 

Г.4.2.2. Бизнес-объекты

 

Степень структурирования в рамках объектно-ориентированных концепций (и как следствие программирования) для разработки «стиля сборки» программного обеспечения дает слишком мелкие объекты. Для этой цели требуются логические блоки «покрупнее». Например, объектно-ориентированная концепция UML предлагает использование так называемых «пакетов», описывающих более крупные объекты в соответствии с их прикладной функцией. Такой тип представления, рассчитанный на приложение, легче понять, если обозначить его как «бизнес-объект». Бизнес-объекты включают бизнес-процессы вместе с соответствующими данными и функциями, выполняемыми для их обработки. Таким образом, бизнес-объекты содержат несколько объектно-ориентированных объектов, о которых говорилось выше. Их характеристики, такие как инкапсуляция, многократное использование (благодаря наследованию) и нежесткая связь (построенная на обмене сообщений), вытекают из объектно-ориентированной концепции.

Пример обработки заказа, приведенный на рис. 52, содержит три бизнес-объекта: «прием заказа», «заказ на поставку» и «изготовление». На рис. 53 эти бизнес-объекты представлены через их характеристики. Интерфейсы различных объектов, активизируемых извне, «проходят через» бизнес-объекты и обозначаются точками вдоль внешних границ объектов. Однако интерфейсы, используемые только в рамках бизнес-объекта, остаются в пределах внутренних объектов. Бизнес-объекты не предполагают заранее заданную степень структурирования. Степень структурирования выбирается исходя из здравого смысла с ориентацией на рабочие единицы приложения, например на то, как тесно связаны их содержание и организационная структура, насколько прочны внутренние связи (и насколько слабы внешние). При выборе ее учитывается также возможность многократного использования бизнес-объектов и их эффективности.

Бизнес-объекты не обязательно должны создаваться из индивидуальных, жестко объектно-ориентированных объектов. Когда существующая система разбита по принципу «сверху-вниз», их можно формировать из обычных программных компонентов. Главным условием при этом является соответствие бизнес-объекта объектно-ориентированным принципам, как это реализовано, например, в SAP R/3. На сегодняшний день SAP предоставляет 170 бизнес-объектов, хранящихся в репозитории бизнес-объектов (BOR). Их внутренняя структура описана на языке АВАР 4GL, который (пока) не является объектно-ориентированным.

Г.4.2.3. Java-аплеты

 

Компонентное программное обеспечение поддерживается и программными концепциями, где используются простейшие аппаратные клиенты — так называемые сетевые компьютеры. Приложения хранятся в сети (Интернете или интрасетях) и запускаются клиентом по мере надобности. В этом отношении функциональные возможности Java представляют особую ценность. Благодаря использованию в качестве пользовательских интерфейсов Java-аплетов и популярных Web-браузеров стала реальна платформно-независимая обработка.

Для создания Java-аплета разрабатывается исходный код в среде разработки Java в любой системе. Затем законченная программа — так называемый байт-код — компилируется в среде разработки, а не в исполняемой программе. Байт-код не зависит от платформы, и чтобы обеспечить его соответствие техническим требованиям клиентской системы, перед исполнением его необходимо еще раз интерпретировать. Это осуществляется при помощи виртуальной машины Java (JVM) после загрузки. JVM адаптирует байт-код к различным клиентским требованиям.

Язык Java можно использовать на трех уровнях. Команды могут вводиться прямо в текст HTML-страницы как исходный код JavaScript. Этот код команд лишь отчасти идентичен Java, хотя оба языка основаны на C++. Однако JavaScript позволяет реализовать лишь небольшие приложения, например, для проверки значений или отображения «шапки» в строке состояния браузера. Кроме того, JavaScript не способен обеспечить осуществлять прямую связь между клиентом и сервером.

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

Эту концепцию можно включить в инфраструктуру АБИ (см. рис. 54). Процессы, управляемые на уровне III системой workflow, описываются на уровне моделирования. Приложения на уровне IV могут быть доступны в виде байт-кода на серверах глобально распределенных приложений. При открытии папки для обработки какого-либо события система workflow создает Web-страницу, соответствующую данному этапу обработки. Эта Web-страница запускает аплет и вызывает сервер приложений. Подключившись к аплету, пользователи выполняют необходимые функции, после чего данные возвращаются и передаются системе workflow.

Данные включают также информацию о времени и продолжительности процесса, которая агрегируется с помощью системы workflow и возвращается для управления процессами. Этот процесс поддерживает любую операционную систему и аппаратную платформу. Нужные для обработки аплеты, включая обрабатываемый объект, загружаются через пользовательский интерфейс браузера. Пользователи могут выполнять функции децентрализовано. Клиенты имеют непосредственный доступ к любому методу. После обработки преобразованные объекты возвращаются на сервер, который передает их на дальнейшую обработку.

В процессе обработки событий серверы workflow постоянно контролируют запуск любых других серверов и обработку данных. Супервизоры могут запрашивать информацию о времени и продолжительности процесса, а также о состоянии процесса в любой момент, хотя доступ к объектам во время их обработки невозможен.