Спонсор: Microsoft
Московский физико-технический институт
Опубликован: 24.09.2008 | Доступ: свободный | Студентов: 2628 / 769 | Оценка: 4.52 / 4.48 | Длительность: 25:15:00
Специальности: Системный архитектор
Лекция 6:

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

5.1.4. Компонентный подход

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

Компонентное проектирование сложных программ из готовых компонентов является наиболее производительным [5.8-5.13].

Переход к компонентам происходил эволюционно: от подпрограмм, модулей, функций. При этом усовершенствовались элементы, методы их композиции и накопления для дальнейшего использования (табл. 5.1).

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

Компоненты конструируются как некоторая абстракция, включающая в себя информационный раздел и артефакты (спецификация, код, контейнер и др.). В этом разделе содержатся сведения: назначение, дата изготовления, условия применения (ОС, среда, платформа и т.п.). Артефакт - это реализация (implementation), интерфейс (interface) и схема развертывания (deployment) компонента.

Реализация - это код, который будет выполняться при обращении к операциям, определенным в интерфейсах компонента. Компонент может иметь несколько реализаций в зависимости от операционной среды, модели данных, СУБД и др. Для описания компонентов, как правило, применяются языки объектно-ориентированной ориентации, а также язык JAVA, в котором понятие интерфейса и класса - базовые, используются в инструментах Javabeans и Enterprise Javabeans и в объектной модели CORBA [5.14].

Таблица 5.1. Схема эволюции элементов компонентов
Элемент композиции Описание элемента Схема взаимодействия Представление, хранение Результат композиции
Процедура, подпрограмма, функция Идентификатор Непосредственное обращение. оператор вызова Библиотеки подпрограмм и функций Программа
Модуль Паспорт модуля, связи Вызов модулей. интеграция модулей Банк, библиотеки модутей Программа с модульной структурой
Объект Описание класса Создание экземпляров классов, вызов методов Библиотеки классов Объектно- ориентированная программа
Компонент Описание логики (бизнес), интерфейсов (APL, IDL), схемы развертывания Удаленный вызов в компонентных моделях (CQV1 CORBA,OSF,...) Регозитарий компонентов. серверы и контейнеры компонентов Распределенное компонентно- ориентированное приложение
Сервис Описание бизнес-логики интерфейсов сервиса (XML, WSDL, ...) Удаленный вызов (RPC, НИР, SOAP,...) Индексация и каталогизация сервисов (XML, UDDL..) Распределенное сервисо- ориентированное приложение

Интерфейс отображает операции обращения к реализации компонента, описывается в языках IDL или APL, включает в себя описание типов и операции передачи аргументов и результатов для взаимодействия компонентов. Компонент, как физическая сущность, может иметь множество интерфейсов.

Развертывание - это выполнение физического файла в соответствии с конфигурацией (версией), параметрами настройки для запуска на выполнение компонента.

Компоненты наследуются в виде классов и используются в модели, композиции и в каркасе (Фреймворке) интегрированной среды. Управление компонентами проводится на архитектурном, компонентном или интерфейсном уровнях, между которыми существует взаимная связь.

Компонент описывается в языке программирования, не зависит от операционной среды (например, от среды виртуальной машины JAVA) и от реальной платформы (например, от платформ в системе CORBA), где он будет функционировать.

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

Компонентная модель - отражает проектные решения по композиции компонентов, определяет типы шаблонов компонентов и допустимые между ними взаимодействия, а также является источником формирования файла развертывания ПС в среде функционирования.

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

Каркас типа "белый ящик" включает абстрактные классы для представления цели объекта и его интерфейса. При реализации эти классы наследуются в конкретные классы с указанием соответствующих методов реализации. Использование такого типа каркаса является характерным для OOП.

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

Композиция компонентов может быть следующих типов:

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

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

Повторное использование в компонентном программировании - это применение готовых порций формализованных знаний, добытых во время реализации ПС, в новых разработках [5.13-5.15].

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

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

Главным преимуществом создания ПС из компонентов является уменьшение затрат на разработку за счет выбора готовых компонентов с подобными функциями, пригодными для практического применения и настройки их к новым условиям, на что тратится меньше усилий, чем на аналогичную разработку.

Поиск готовых компонентов основывается на методах классификации и каталогизации. Метод классификации предназначен для представления информации о компонентах с целью быстрого поиска и отбора. Метод каталогизации - для физического их размещения в репозитариях с обеспечением доступа к ним в процессе интеграции.

Методология компонентной разработки ПС. Создание компонентной системы начинается с анализа ПрО и построения концептуальной модели, на основе которой создается компонентная модель (рис. 5.7) , включающая проектные решения по композиции компонентов, использованию разных типов шаблонов, связей между ними и операции развертывания ПС в среде функционирования.

 Концептуальна схема построения ПС из компонентов в среде Интернет

Рис. 5.7. Концептуальна схема построения ПС из компонентов в среде Интернет

Готовые компоненты берутся из репозитариев Интернета и используются при создании ПС, технология построения которых описывается следующими этапами ЖЦ.

  1. Поиск, выбор ПИК и разработка новых компонентов, исходя из системы классификации компонентов и их каталогизации, формализованное определение спецификаций интерфейсов, поведения и функциональности компонентов, а также их аннотирования и размещения в репозитарии системы или в Интернет.
  2. Разработка требований (Requirements) к ПС - это формирование и описание функциональных, нефункциональных и др. свойств ПС.
  3. Анализ поведения (Behavioral Analysis) ПС заключается в определении функций системы, деталей проектирования и методов их выполнения.
  4. Спецификация интерфейсов и взаимодействий компонентов (Interface and Interaction Specification) отражает распределение ролей компонентов, интерфейсов, их идентификацию и взаимодействие компонентов через поток действий (workflow).
  1. 5. Интеграция набора компонентов и ПИК (Application Assembly and Component Reuse) в единую среду основывается на подборе и адаптации ПИК, определении совокупности правил, условий интеграции и построении конфигурации каркаса системы.
  1. Тестирование компонентов и среды (Component Testing) основывается на методах верификации и тестирования для проверки правильности как отдельных компонентов и ПИК, так и интегрированной из компонентов ПС.
  2. Развертывание (System Deployment) включает оптимизацию плана компонентной конфигурации с учетом среды пользователя, развертку отдельных компонентов и создание целевой компонентной конфигурации для функционирования ПС.
  3. Сопровождения ПС (System Support and Maintenance) состоит из анализа ошибок и отказов при функционировании ПС, поиска и исправления ошибок, повторного ее тестирования и адаптации новых компонентов к требованиям и условиям интегрированной среды.
Максим Цапко
Максим Цапко

Я наконец закончил курс "Управление ИТ-проектами". Как получить документ об окончании курса.

давайн Нкунда
давайн Нкунда
Владимир Карпенко
Владимир Карпенко
Украина, Киев, Национальный Авиационный Университет, 2009
Михаил Адигеев
Михаил Адигеев
Россия