Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов

Подождите немного. Документ загружается.

131

несколько логических архитектурных слоёв. Перечень уровней, слоев, и месте их

расположения приведены в табл. 5.1.

Т а б л и ц а 5.1

Уровень архитектуры Слой уровня архитектуры Место

размещения

Отображение (клиентская часть) Клиент

Внешние службы

Представление

Контролер приложения (серверная часть)

Веб-сервер

Прикладные службы Логика применения

Бизнес-логика, модель домена

Преобразование, отображение моделей

данных

Источник данных

Менеджеры ИР, коннекторы

Сервер приложений

Логика управления ресурсом Информационные ресурсы

Данные, информация

Сервер баз данных,

файловая система

Уровень представления. Цель – это подготовка, формирование и отображение

результатов работы приложения для конечного пользователя, а также обеспечение

интерфейса с этим приложением для взаимодействия с ним. В частности, на этом

уровне находится графический интерфейс пользователя (GUI).

Уровень логики приложения. На нем находится основная функциональность

приложения, бизнес процессы и алгоритмы обработки данных.

Уровень источников данных. Уровень предназначен для определения связи с

информационными ресурсами (ИР) приложения. Каждый источник рассматривается

как компонент с унифицированным интерфейсом, который инкапсулирует

внутренние детали реализации и хранения данных.

Уровень информационных ресурсов. Здесь находятся такие ресурсы: базы данных,

файловые структуры, отдельные документы и др.

При построении приложения на разных архитектурных уровнях могут быть

использованы определенные ЯП, компонентные модели, методы, технологии и др.,

которые подходят для реализации соответствующих программных средств для

создания корпоративных систем, приведенных в табл. 5.2.

Рассмотрим несколько базовых классификационных характеристик.

Характеристика T

будет соответствовать уровню архитектуры, т.е. множество

компонентов для построения корпоративных систем разделяем на количество

уровней архитектуры:

={Представление, логика приложения, источники данных, ИР).

Характеристика T

соответствует месту нахождения компонента согласно

архитектурному уровню (из табл.5.1. видно, что компоненты уровня представления

размещаются на клиенте и веб-сервере).

Данная характеристика имеет вид

={Клиент, Веб-сервер, Сервер приложений, Сервер данных}. (5.4)

Приведенные характеристики – примеры формирования классификационных

характеристик для построения значительно большей системы классификации.

В частности, в таблицу необходимо включить такие классификационные

характеристики:

132

Т а б л и ц а 5.2

Слой уровней

архитектуры

Функциональность

слоя архитектуры

Средство реализации

Реализация отображения Средства и языки разметки (HTML,

XML)

Логика формирования

отображения

Скриптовые компоненты, аплеты (Java,

JavaScript, VB Script)

Отображение (клиентская

часть)

Управление функциями

отображения

Интернет-браузер

Внешние службы Веб-службы XML, SOAP, WSDL, UDDI, др.

Контролер приложения

(серверная часть)

Контролер, адаптер

генерации представления

Сервлеты, JSP, ASP, PHP-script, Perl–

script

Прикладные службы Инкапсуляция бизнес

логики, прикладные

интерфейсы

Интерфейсы POJO, EJB, CORBA, .NET,

COM, DCOM

Бизнес-логика, модель

домена

Функциональные

алгоритмы системы

Объектные и компонентные модели на

основе POJO, EJB, CORBA, .NET, COM,

DCOM

Преобразование и

отображение для обеспе-

чения совместимости

поведения

ORM-средства, Table Module, DataSet,

DOM, др.

Преобразование,

отображение моделей

данных

Преобразование и

отображение для обеспе-

чения совместимости

структуры

ORM-Средства, Table Module, DataSet,

DOM, др.

Унифицированные

интерфейсы для

информационных ресурсов

Интерфейсы ODBC, JDBC,

специализированные интерфейсы

Менеджеры

информационных

ресурсов, коннекторы

Механизмы соединения с

информационными

ресурсами

Драйверы ODBC, JDBC,

специализированные коннекторы

Управление ресурсом СУБД, информационные оболочки Логика, управление

ресурсом

Первичная обработка,

обеспечение целостности

Триггеры, процедуры, которые

сохраняются

Представление

структурированных данных

Таблицы СКБД, другие структуры

данных

Данные, информация

Представление

неструктурированных

данных

Произвольные файлы и данные

– тип функциональности, которая реализуется на соответствующем слое

архитектуры (для каждого слоя уровня архитектуры представляет группы

функциональности для компонентов приложения соответствующего слоя);

– тип компонентной модели (частичной, так как в корпоративной системе

существуют средства, которые разрабатываются без ориентации на компонентную

модель);

– системная среда, ОС;

– ЯП компонентов;

133

– типовые компоненты, которые реализуют общие (типовые) шаблоны

проектирования (например, ORM-средства, Table Module, DataSet) и др.

Совокупность приведенных характеристик – основа формирования системы

классификации компонентов для построения корпоративных приложений.

5.1.4. ОСНОВЫ КЛАССИФИКАЦИИ КОМПОНЕНТОВ

ВЕБ-ПРИЛОЖЕНИЙ

Схема классификации компонентов для корпоративных приложений используется

при построении основ классификации компонентов веб-приложений с учетом

архитектурных требований. К классификации компонентов относятся такие

типовые решения и элементы:

– структура компонента;

– структура базовой компонентной среды (framework);

– схема и механизмы взаимодействия компонентов на основе интерфейсов;

– механизмы развертывания и конфигурации компонентов в каркасе;

– системные сервисы, которые поддерживают функционирование

компонентной среды и взаимодействие компонентов.

Эти решения и элементы являются обязательными составляющими любого

компонентного подхода и соответствующих компонентных моделей. Каждая

система классификации по компонентным признакам должна учитывать эти

типовые решения, элементы и каждый элемент классификации должен иметь

классификационные свойства, которые связаны с такими решениями.

Архитектурные признаки классификации компонентов для веб-приложений

определяются на основе следующих архитектурных и структурных решений [200]:

– общая архитектура веб-приложения;

– архитектура клиента приложения;

– архитектура серверной компоненты.

Обобщенная типовая архитектура веб-приложения. Такая архитектура –

клиент серверная архитектура, а именно Интернет-браузер. Основа серверной части

– веб-сервер, в среде которого реализуются компоненты обработки запросов и

генерации ответов. Такие серверные компоненты реализуют дополнительную

функциональность по взаимодействию с другими серверами, доступ к базам

данных, обращение к разным классам приложений и др. Иными словами, веб-

сервер – это компонент веб-приложения, который инкапсулирует у клиента все

операции, выполняемые для обработки запросов. Определим следующие

классификационные характеристики.

Характеристика T

соответствует местоположению компонента в клиент

серверной архитектуре, т.е. T

= {Клиент, Сервер}.

Учитывая, что основу клиента составляет Интернет-браузер, определим

характеристику, которая связана с типом браузера:

= {MS Internet Explorer, Mozilla, Opera, Netscape, Konqueror}.

– частичная характеристика, иерархически упорядочена относительно

характеристики T

Характеристика T

будет связана с типом веб-сервера:

= {Internet Information Server, Apache, Tomcat, JBoss, WebSphera, WebLogic,

Cloudscape}.

134

Как и предыдущая характеристика T

– это частичная характеристика и

иерархически упорядочена относительно характеристики T

Типовая архитектура клиента веб-приложения. Эта архитектура построена

на основе типовых моделей, объектов данных, операций, которые применяются в

среде Интернет-браузера. Она состоит из нескольких логических уровней, каждый

из которых определяется своими множествами структур данных и операций над

ними. Этим уровням принадлежат:

– уровень распределенной среды;

– базовый уровень клиента;

– уровень формирования объектов данных клиента;

– функциональный уровень клиента;

– уровень отображения объектов данных.

Уровень распределенной среды. Этот уровень является логическим

представлением сетевой среды, которая состоит из сети Интернета, корпоративных

сетей, локальных вычислительных сетей и др.

Базовый уровень клиента. Типичная реализация этого уровня – Интернет-

браузер, определяет среду клиента, обеспечивает формирование и отправку

запросов к серверному компоненту, а также получение и базовую обработку ответа

от сервера. Кроме этого, браузер предоставляет механизмы поддержки реализации

других уровней архитектуры клиентов веб-приложений.

Уровень формирования объектов данных клиента. На этом уровне создаются и

формируются объекты данных для реализации функциональности клиента.

Объекты подаются как иерархически упорядоченное множество. Функции

построения и упорядочения выполняет браузер. Каждый объект имеет

совокупность атрибутов и свойств, а также методов, которые определяют

функциональность этого объекта.

Функциональный уровень клиента. Этому уровню соответствуют два вида

функций. К первому виду относятся те, которые выполняются во время

формирования запроса к серверу приложения на основе данных, вводимых

конечным пользователем. Функции второго вида обеспечивают обработку данных,

которые получены в ответ со стороны сервера, и формирование визуального

представления результатов обработки запроса.

Уровень отображения объектов данных. На этом уровне непосредственно

происходит формирование визуального изображения, которое может видеть

пользователь клиента веб-приложения. Оно строится согласно иерархической

модели данных в соответствии с правилами отображения для каждого типа

объектов данных.

Классификационная характеристика T

определяет функциональную группу, к

которой принадлежат компонент:

={формирование объектов данных, функциональные компоненты,

отображение объектов данных}.

Примерами таких компонентов могут быть компоненты в одном из скриптовых

ЯП, который воспринимает браузер:

– компоненты построения и работы с массивами, таблицами, списками

(формирование объектов данных);

– функциональные компоненты для валидации, т.е. для проверки данных,

которые вводит конечный пользователь;

135

– компоненты для работы с нестандартными окнами браузера для отображения

объектов данных.

Характеристика T

определяет ЯП, в котором описан компонент:

= {JavaScript, VB Script, Java, HTML, XML}.

Характеристики T

и T

– частичные характеристики, иерархически

упорядочены относительно характеристик T

Дополнительные классификационные характеристики компонентов клиента

связаны непосредственно с конкретной обработкой данных, и их выбор обусловлен

субъективными факторами. Эти характеристики целесообразно вводить для

некоторой предметной области, определенных методов обработки данных и др.

Такие характеристики выходят за рамки архитектурных признаков.

Типовая архитектура сервера веб-приложения. Серверная часть

значительно превосходит клиентскую по сложности и функциональности. Поэтому

для нее существует больше классификационных характеристик. Типовая

архитектура серверной части веб-приложения представлена на рис.5.1.

Рис. 5.1. Типовая архитектура серверной части веб-приложения

Уровень распределенной среды. Назначение и функции этого уровня полностью

совпадают с аналогичным уровнем для клиентов.

Уровень прикладных компонентов веб-сервера. Этот уровень представляет

собой совокупность компонентов, которые обеспечивают функциональность

серверной части веб-приложений для обработки запросов со стороны клиентов и

формирования соответствующих результатов. Современная архитектура обработки

запросов, как правило, основана на шаблоне проектирования MVC (model-view-

controller), согласно которому серверные компоненты выполняют функции

контролера, представления и обработки данных, формирования и представления

результатов клиентских запросов.

Уровень управления обработкой запроса. Этот уровень является логическим

представлением модели обработки запросов клиентов, для которой существуют

следующие группы функций обработки запросов:

– анализ запросов (проверка синтаксиса и семантики, определение типов и

видов запросов);

136

– обработка запросов (поиск и отбор данных, операции над данными, внесение

изменений в базы и файлы данных, определение объектов данных для генерации

ответа, обеспечение целостности объектов данных);

– генерация ответа.

Уровень реализации операций обработки данных. Этот уровень является

логическим уровнем операций обработки данных. Каждая операция

инкапсулируется в определенном объекте данных. Типичные элементы этого

уровня – объекты данных, которые выбирают из баз или файлов данных

определенную информацию с критерием отбора, выполняют логическую

обработку данных, генерируют фрагменты, как составляющие ответа клиенту.

Уровень представления данных. На этом уровне архитектуры находятся

элементы, которые являются представлением данных веб-приложения и

используются во время обработки запроса клиента.

Классификационные характеристики для серверной части. Первая важная

характеристика – ЯП для описания серверных компонентов. Для формирования

характеристик существует два решения. Первое решение – введение единой

характеристики для всех возможных ЯП. Однако, такой подход имеет недостаток.

ЯП серверных компонентов зависят от выбора конкретного веб-сервера и поэтому

целесообразно применять второе решение – введение нескольких характеристик в

зависимости от конкретного сервера. Кроме того, такое решение для

классификации является информативнее первого.

Для сервера MS Internet Information Server эта характеристика имеет такой вид:

IIS

= {ASP, JavaScript (серверный), VB Script (серверный), C, C++, ASP.NET,

C#, C++ .NET, VB .NET, J# .NET, XML, SQL}.

Сервер Apache не поддерживает программирование в разных ЯП. Однако, для

него существует много дополнительных средств функционирования компонентов,

написанных в разных ЯП. Для наиболее распространенных языков

APACHE

= {PERL, PHP, PYTHON, XML, SQL},

и характеристика Java-среды (Tomcat, JBoss, WebSphera, WebLogic и др.) имеет

вид:

JAVA

= {JAVA, JSP, JSTL, JSF,XML, SQL}.

Следующая классификационная характеристика связана с архитектурными

уровнями серверной части веб-приложения. Она не охватывает уровень

распределенной среды (это сетевой уровень и он существует независимо от веб-

приложений) и базовый уровень веб-сервера

= {прикладные компоненты веб-сервера, управление обработкой запроса,

операции обработки данных, представление данных}.

Компоненты уровня прикладных компонентов веб-сервера имеют следующую

характеристику, что вводит признаки типового шаблона проектирования MVC:

={контролер, серверные страницы, функциональные компоненты}.

К контролерам принадлежат компоненты, реализующие логику управления

работой всех прикладных компонентов серверной части веб-приложения.

Серверные страницы – это компоненты формирования HTML-ответа, который

отправляется клиенту. Функциональные компоненты - это обобщенное название

всех компонентов для реализации бизнес логики и обработки данных.

Для компонентов уровня управления обработкой запроса введем такую

характеристику: T

= {анализ запроса, обработка запроса, генерация ответа}.

137

Компоненты этого уровня непосредственно реализуют логику обработки запросов.

Они встроены в компоненты предыдущего уровня. Для своей работы такие

компоненты используют функциональность компонентов, которые находятся на

уровнях обработки данных и представления данных.

Для компонентов уровня реализации операций обработки данных введем

следующую характеристику:T

={отбор данных, обработка данных, формирование

результатов}.

Компоненты этого уровня выполняют основные функции бизнес логики веб-

приложения для операций обработки данных. Эквивалент таких компонентов –

сессионные компоненты в модели EJB, основная задача которых состоит в анализе

потребностей и инициирования выбора данных, необходимых для выполнения

операции и формирования результатов, которые применяются при генерации

ответа клиенту. Операции для доступа к данным и их сохранения в

информационных ресурсах выполняют компоненты следующего уровня.

Для компонентов уровня представления данных введем следующую

классификационную характеристику:

={модели данных, описание доступа, операции обработки данных}.

Компоненты этого уровня непосредственно связаны с данными, находящимися в

информационных ресурсах (базы данных, документы, файлы и др.), ответственны

за доступ к данным и поддержку взаимодействия с ресурсами. Аналогом таких

компонентов являются entity-компоненты в модели EJB.

Дополнительные классификационные характеристики серверных компонентов

связаны непосредственно с конкретной бизнес–логикой, обработкой данных, их

выбор обусловлен субъективными факторами. Такие характеристики

целесообразно вводить для определенной предметной области, определенных

методов обработки данных и др. Для серверных компонентов возможно введение

качественных характеристик. Все эти характеристики выходят за рамки

архитектурных признаков и потому не рассматриваются.

Совокупность классификационных характеристик T = {T

, T

IIS,

APACHE

, T

JAVA

, T

} определяют систему классификации компонентов

для веб-приложений с архитектурными признаками (рис.5.2.).

JAVA

APACHE

Рис. 5.2. Дерево классификационных характеристик компонентов веб-приложений

5.2. КЛАССИФИКАЦИЯ КОМПОНЕНТОВ ПОВТОРНОГО

ИСПОЛЬЗОВАНИЯ

КПИ могут быть готовые программные элементы, как готовые «детали», которые

138

можно объединить в более сложную программную конструкцию. Именно эта

особенность характеризует повторное использование как систематическую и

целенаправленную деятельность, как по классификации и каталогизации КПИ в

хранилищах, а также по применению их в новых разработках программных и

информационных систем [20–22, 133, 221, 227] .

Систематическое повторное использование в программировании – это

капиталоемкий подход, предусматривает построение, накопление КПИ и

конструирование из них новых ПС.

Построение готовых ресурсов как КПИ исходит из решения типичных задач

для семейства систем, описания их в виде обычных компонентов или КПИ и

хранения их в каталогах хранилищ для организации поиска по запросам

пользователей.

С общей точки зрения новый компонент или КПИ определяют по-разному в

зависимости от среды и функций. Приведем некоторые определения.

Определение 1. КПИ – это некоторая функция с определенными свойствами и

атрибутами, обеспечивающая взаимодействие со средой и задает поведение.

Определение 2. Готовый КПИ – это совокупность методов с определенной

сигнатурой и типами данных, которые передаются и возвращаются после

реализации соответствующего метода некоторым объектом.

Определение 3. Компонент – это самостоятельный программный элемент,

который удовлетворяет определенным функциональным требованиям

относительно архитектуры, структуры и организации взаимодействия в заданной

среде, имеет спецификацию, которая помогает пользователю применять и

объединять его с другими компонентами в сложную систему.

Определение 4. Программный компонент – это независимый от ЯП

самостоятельно реализованный объект, обеспечивающий выполнение

определенной совокупности прикладных сервисов, доступ к которым возможен

через интерфейсы, указывающие функции и операции обращения к компоненту.

Данные определения отвечают разным условиям использования компонентов и

КПИ и дают возможность создавать из них новые ПС.

Конструирование новых ПС из подобранных готовых ресурсов из разных

хранилищ возможно осуществлять средствами межъязыкового и межмодульного

интерфейса сборочного программирования.

Построение КПИ требует капиталовложений, а конструирование новых ПС с

применением КПИ приносит прибыль за счет уменьшения трудозатрат на

повторную разработку. Инвестиции в повторное использование требуют оценки

вложения капитала, прогнозирования сроков и объемов возвращения этого

вложения, оценки рисков и др. Прибыль при повторном использовании, как любой

бизнес, требует специальных условий менеджмента инженерной деятельности

создания продуктов из КПИ.

Сущность успеха такого бизнеса состоит в следующем:

1) повторное использование КПИ требует меньших трудозатрат, чем их новая

разработка;

2) поиск пригодных для использования компонентов требует меньших усилий,

чем реализация необходимых функций в проектируемой системе;

3) сборка или развертывание КПИ в новых условиях применения нуждается в

меньших трудозатратах, чем полностью выполненная разработка.

139

Архитектура, в которую встраивается готовый КПИ, поддерживает

стандартные механизмы работы с компонентами как со строительными блоками.

Высокая эффективность повторного использования повышает функциональность,

удобство и качество реализации будущей системы.

Классификация КПИ

КПИ с общей точки зрения – это артефакты деятельности разработчиков

программных продуктов, которые необходимые другим для применения в новых

разработках. Ими могут быть следующие:

– модели ПрО в терминах понятий и лексики этой области;

– готовые компоненты, системы или отдельные части систем;

– промежуточные продукты процесса разработки ПС (требования, постановки

задач, архитектура и др.);

– диаграммы, паттерны объектов, которые могут использоваться другими и др.

Артефакты, как готовые ресурсы, должны удовлетворять таким требованиям,

как независимость от конкретной платформы, наличие стандартного интерфейса и

параметров настройки на новые условия выполнения, возможность

взаимодействия с другими компонентами.

КПИ могут быть прикладными и общесистемными. Прикладные компоненты

выполняют отдельные задачи и функции прикладной области (домены бизнеса,

коммерции, экономики и т.п.), которые могут использоваться в дальнейшем как

прикладные системы в других доменах с аналогичными функциями.

К общесистемным компонентам относятся компоненты общего и

универсального назначения, а также общесистемные сервисные средства, которые

обеспечивают системное обслуживание и предоставляют разные виды сервиса для

многих создаваемых ПС различного назначения. Компоненты общего назначения –

это трансляторы, редакторы текстов, системы генерации, интеграции, загрузчики и

др. Они используются прикладными системами в процессе их проектирования и

выполнения.

Универсальные системные компоненты обеспечивают функционирование

любых (в том числе и прикладных) компонентов, обмен данными и передачу

сообщений между всеми видами систем и компонентов, размещенных в разных

операционных средах. К ним относятся: ОС, СУБД, сетевое обеспечение,

электронная почта и др.

Связь между прикладными и общесистемными средствами осуществляется

посредством стандартных интерфейсов, которые обеспечивают взаимодействие

разных типов компонентов через механизмы передачи данных и сообщений.

Приведем классификацию готовых компонентов:

– процедуры и функции на ЯП высокого уровня;

– алгоритмы, программы;

– классы объектов и абстрактные классы;

– структуры данных и часто используемая информация (например,

информационные ресурсы Интернета);

– API, IDL-модули в библиотеках (например, GUI, графика и др.);

– Веб-ресурсы и сервисы;

– средства развертывания систем и компонентов в операционной среде

(например, CORBA, COM, .NET) [40, 166, 176, 209];

140

– готовые решения в виде абстракций – паттерны, фреймы и др.

Все разнообразие видов и типов готовых компонентов требует от разработчиков

новых ПС поиска КПИ и изучения их особенностей для использования в этих ПС.

Разработка ПС из КПИ выполняется по следующим общим процессам:

– анализ функций КПИ присущих группам объектов в репозитарии;

– разработка новых функциональных компонентов и доводка их к уровню

повторного использования;

– разработка или поиск интерфейсов КПИ в репозитарии;

– сборка КПИ в новую конфигурацию системы.

Спецификация КПИ

КПИ могут быть классами, созданными в рамках объектно-ориентированного

программирования (например, огромная библиотека классов в С++) вместе с

реализацией их методов.

В компонентном программировании наследуется реализация компонента и его

интерфейсы. Компонент может изменяться и пополняться новыми

функциональными возможностями и интерфейсами. Один компонент может

содержать реализацию нескольких разных интерфейсов, а один интерфейс, в свою

очередь, может быть реализован в разных компонентах. Замена одного компонента

другим не приводит к перекомпиляции ПС или перенастройке связей в ней.

Пример КПИ – это контейнерные классы, которые сохраняют структуры

данных с правилами их запоминания или выдачи элемента, который входит в

контейнер. Механизм контейнеров реализован в С++ в виде так называемых

шаблонов (templates) и их библиотек.

Каждый компонент имеет связь с внешними компонентами, наследует

интерфейс и инкапсулирован как «черный ящик» без возможности вмешательства в

его исходный код.

Модель спецификации имеет такой вид:

КПИ

= (T, I, F, R, S),

где T – тип компонента; I – множество интерфейсов компонента; F –

функциональность компонента; R – реализация, скрытая часть – программный код;

S – сервис для взаимодействия со средой или набор правил развертки.

Каждый элемент спецификации компонента представляет собой видимую или

скрытую от пользователя часть его абстракции.

Другой вид классификации КПИ определяется сложностью:

– простые компоненты (функция, модуль, класс и др.);

– компонент как объект, который имеет интерфейс, функцию и реализацию, а

также возможность дополнять спецификацию шаблоном развертки и интеграции;

– готовые к использованию КПИ (например, beans компоненты в Java, AWT-

компоненты и т.п.);

– КПИ типа каркасов, паттернов с элементами группирования нескольких

простых КПИ в структуру, где они взаимодействуют в процессе решения задач

системы.

Для удобства работы с КПИ создается метаинформация о том, какие классы

совместимы с семантическими ограничениями, явным образом определенными в

спецификации КПИ, содержащая описание информации вида:

– интерфейсов, которые реализуют компоненты;