Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов
Подождите немного. Документ загружается.
161
упорядоченности пары, или первого и второго понятия. Взаимоотношение между
объектами – это упорядоченная взаимосвязь объектов, которая возникает
вследствие определения отношений между ними, и включают в себя:
1) множество – множество;
2) элемент множества – элемент множества;
3) элемент множества – множество;
4) множество – элемент множества.
Рассмотрим смысл взаимоотношений.
1. Множество-множество включает в себя:
обобщение – взаимоотношение, в соответствии с которыми каждое внутреннее
свойство первого множества является внешним свойством второго множества.
специализация – взаимоотношение, обратное предыдущему;
агрегация – взаимоотношение, в соответствии с которым второе множество
пары – агрегированное множество, а первое – один из сомножителей декартового
произведения;
детализация – вариант взаимоотношений, где первое множество пары –
агрегированное множество, а второе – сомножитель декартова произведения;
ассоциация – произвольное взаимоотношение двух объектов, структурная
упорядоченность которых отсутствует.
2. Элемент множества – множество включает в себя такие понятия:
классификация – вариант взаимоотношений, отвечающий случаю, когда
внешнее свойство соответствующего элемента множества является внутренним
свойством множества;
экземпляризация – как вариант взаимоотношений, при котором внутреннее
свойство множества является внешним свойством элемента множества. Такой
тип имеет: родовидовое отношение (IS–A), которое определяет обобщение или
специализацию; часть–целое (PART–OF), которое определяет агрегацию или
классификацию.
Взаимоотношения базируются на структурной упорядоченности между парами
объектов. Для полноты картины введем понятие ассоциации, которое достаточно
часто используют в практических ОМ (например, "дружеские" функции в языке
программирования С++).
Поведенческий уровень. Для объектов, которые определены на
характеристическом уровне, концепция поведения обеспечивает рассмотрение
характеристик объектов ПрО в зависимости от времени на отрезке оси,
соответствующей времени существования данного объекта.
Понятие времени – конкретный параметр системы, значения которого
упорядочены и каждый из них отвечает определенному состоянию отдельных
объектов и системы в целом. Математический аппарат формализованного
представления объектов в данной концепции – модель событий и сообщений.
Отличительная особенность объектов – разные значения времени. Если объект и
его характеристики не изменяются, то он не зависитот от времени и его отличие
устанавливается другими концепциями.
Состояние объекта включает в себя:
– атрибут, который соответствует характеристике объекта и принимает
значение истины при конкретном состоянии этого объекта;
– статический атрибут характеризует состояние с одним свойством;
162
– динамический атрибут характеризует состояние из нескольких свойств;
– значения атрибута состояния – это значения характеристики объекта, с
помощью которого определяется данный атрибут.
Для статического атрибута состояние – постоянное значение, отвечающее
существующему свойству. Для динамического атрибута состояние – значение,
зависящее от параметра, моделирующего время, и отвечающее свойству объекта
при определенном значении этого параметра
Существуют такие виды состояний:
– состояние объекта – это совокупность статических и динамических
атрибутов состояния конкретного объекта, которое моделирует время;
– пространство состояний – это множество всех возможных состояний, в
которых может находиться определенный объект модели;
– жизненный цикл объекта – это упорядоченная во времени
последовательность состояний, которая принадлежит соответствующему
пространству состояний и охватывает эволюцию объекта (рождение,
существование, уничтожение);
– диаграмма перехода состояний – это совокупность всех возможных
переходов между парами элементов пространства состояний и вариантами ЖЦ
объекта;
– метод – это операция, которая обеспечивает переход между состояниями
объекта соответственно диаграмме перехода состояний;
– состояние объектной модели – это совокупность состояний всех объектов
модели при одном и том же значении параметра времени;
– событие – это реакция модели объектов, которая приводит к изменению
состояния. Событие может включать в себя отправку и получение сообщения,
определенное значению параметра времени;
– сообщение – это действие, которое предназначено для изменения состояния
одного или нескольких объектов;
– отправка сообщения – это событие, связанное с необходимостью инициации
сообщения;
– получение сообщения – это событие, связанное с реакцией объекта на
необходимость изменения своего состояния.
Таким образом, соответственно концепции поведения объектов с учетом
совокупности их атрибутов и значений определяют последовательности состояний
объектов и строят их жизненные циклы, которые отображают в диаграммах
переходов состояний. Взаимосвязи между объектами формируют бинарные
предикаты, которые связаны со свойствами объектов ПрО, и детализируют уровень
взаимосвязей между состояниями объектов. Зависимость от параметра времени
достигается внесением в ОМ специального объекта Timer, основное назначение
которого состоит в рассылке специальных сообщений текущего времени с
определенным уровнем дискретности. Каждый объект имеет соответствующий
метод, который анализирует полученное значение и выполняет переход к другому
состоянию или оставляет его без изменения.
6.1.2. ФУНКЦИИ И АЛГЕБРА ОБЪЕКТНОГО АНАЛИЗА
К формальному аппарату объектного анализа отнесем множество базовых
функций, которые обеспечивают декомпозиционные и композиционные изменения
163
денотатов и концептов объектов при концептуальном моделировании ПрО,
расширение или сужение концептов отдельных объектов, а также увеличение или
уменьшение количества объектов (детализация, экземпляризация, агрегация и др.).
Такие изменения соответствуют определенным правилам и условиям, которые
обеспечивают корректность выполнения функций, а также отражают приведенный
многоуровневый подход в объектном анализе [64].
Рассмотрим следующие функции объектного анализа.
Декомпозиционные изменения денотата:
– соответствующая сущность действительной реальности, которая
соответствует определенному объекту, подается как совокупность однородных
предметов;
– соответствующая сущность действительной реальности, которая
соответствует определенному объекту, подается как совокупность неоднородных
предметов.
Композиционные изменения денотата:
– денотаты нескольких однородных предметов подаются в составе
определенной сущности из выбранной предметной области;
– денотаты нескольких неоднородных предметов подаются в составе
определенной сущности из выбранной предметной области.
Изменения концептов, связанных с декомпозиционным изменением денотатов:
– концепты новых детализированных объектов формируются на основе
концепта начального объекта;
– концепты новых детализированных объектов формируются без учета
концепта начального объекта.
Изменения концептов, связанных с композиционным изменениям денотатов:
– концепт нового композиционного объекта формируется на основе одинаковых
концептов начальных объектов;
– концепт нового композиционного объекта формируется на основе разных
концептов начальных объектов.
Изменения уровня детализации (абстракции) концептов:
– из концепта объекта исключается одно или несколько свойств или
характеристик при формировании концепта нового объекта с одинаковым
денотатом;
– в концепт объекта включается одно или несколько свойств или характеристик
при формировании концепта нового объекта с одинаковым денотатом.
Алгебра объектного анализа
Пусть О=(О
1
, О
2
,, …, О
n
) – множество объектов на определенном уровне
объектного анализа и О
i
= О
i
(Name
i
, Den
i
, Con
i
),
где Name
i
, Den
i
, Con
i
– знак (имя), денотат и концепт соответственно, P = (P
1
, P
2
, …,
P
r
) – множество предикатов, на основе которых определяют концепты объектов
Con
i
= (P
i1
, P
i2
,…, P
is
).
Базовые операции объектного анализа такие:
1. Декомпозиционное изменение денотата для формирования новых однородных
объектов:
decds (О
i
): О
i
(О
i1
, … О
ik
),
где О
ij
= О
ij
(Name
ij
, Den
ij
, Con
ij
);
j Con
ij
= Con
i
; Den
i
= Den
i1
. . .
Den
ik
.
164
2. Декомпозиционное изменение денотата для формирования новых
неоднородных объектов:
decdn (О
i
): О
i
(О
i1
, … О
ik
),
где О
ij
= О
ij
(Name
ij
, Den
ij
, Con
ij
);
j Con
ij
=
; Den
i
= Den
i1
. . .
Den
ik
.
3. Композиционное изменение денотатов однородных объектов для
формирования нового объекта:
comds (О
i1
, …, О
ik
): (О
i1
, … О
ik
)
О
i
,
где О
i
= О
i
(Name
i
, Den
i
, Con
i
);
j Con
i
= Con
ij
; Den
i1
. . .
Den
ik
= Den
i
.
4. Композиционное изменение денотатов неоднородных объектов для
формирования нового объекта:
comdn (О
i1
, …, О
ik
): (О
i1
, …, О
ik
)
О
i
,
где О
i
= О
i
(Name
i
, Den
i
, Con
i
); Con
i
=
; Den
i1
. . .
Den
ik
= Den
i
.
5. Расширение концепта существующего объекта. Если предикат P
t
P, P
t
Con
i
и P
t
(О
i
) принимает значение истины, то
conexp (О
i
, P
t
): О
i
О
i
',
где О
i
' = О
i
' (Name
i
, Den
i
, Con
i
`); Con
i
{P
t
} = Con
i
'.
6. Сужение концепта существующего объекта. Если предикат P
t
Con
i
, то
connar (О
i
, P
t
): О
i
О
i
',
где О
i
' = О
i
' (Name
i
, Den
i
, Con
i
'); Con
i
'= Con
i
\ P
t
.
Это множество функций определяет алгебру объектного анализа
= (О',
),
где О' =(О
1
, О
2
,…, О
n
) – множество объектов,
= {decds, decdn, comds, comdn, conexp, connar} – множество операций над
элементами О'.
Каждая из операций имеет определенный приоритет и арность, а также связана
с соответствующими допустимыми изменениями денотатов и концептов.
Переход от функций объектного анализа к операциям алгебры объектного
анализа показан следующей теоремой.
Теорема 6.1. Множество операций
алгебры
– полная система операций
относительно функций объектного анализа.
Правила объектного анализа. Концептуальное моделирование определенной
ПрО имеет итеративный характер и вытекает из определения самой ПрО как
начального объекта. Сначала в моделировании применяют функции объектного
анализа, которые приближают структуру и свойство ОМ к конечным целям.
Каждая из функций рассматривается как последовательность выполнения операций
алгебры объектного анализа, что поддерживает целостность представления ОМ.
Процесс завершается формализованным описанием сущностей и модели ПрО с
учетом каждого аспекта абстрагирования и применения соответствующего
математического аппарата.
Рассмотрим основные правила объектного анализа:
– объектный анализ выполняется при условии минимизации потери информации
из описания действительной реальности для выбранной ПрО;
– все изменения, которые происходят с объектной моделью, отвечают
процессам детализации описания ПрО и определяются в рамках представления
множества объектов, как совокупности треугольников Фреге;
– каждый шаг объектного анализа определяется изменениями денотата или
концепта одного или нескольких объектов ОМ;
165
– новые объекты на определенном шаге объектного анализа определяют
соответственно изменения денотатов существующих объектов;
– все изменения, которые происходят с объектной моделью, отвечают условиям
существования и определения формальных уровней абстракции представления
объектов;
– функции объектного анализа определяют преобразования в соответствии с
допустимыми изменениями ОМ и ее отдельных элементов;
– каждый шаг объектного анализа обеспечивается условиями целостности ОМ.
Приведенные формализмы предназначены для определения и приведения в
порядок базовой терминологии ООП, суть которой состоит в последовательной
дефиниции терминов в соответствии с построением отношений между понятиями.
Эти дефиниции выполняются на уровнях с постоянным уточнением и развитием
характеристик и свойств объекта. Так, на обобщающем уровне определяется
основной термин – объект. Структурно-упорядоченный уровень обеспечивает
детализацию для объекта таких понятий, как класс, экземпляр класса, абстрактный
класс и др. На характеристическим уровне дается определение следующих
понятий: свойство объекта, отношения между объектами, агрегация; детализация,
классификация, экземпляризация, ассоциация, характеристика объекта и т.п. На
поведенческом уровне определяются понятия, которые связаны с состоянием
объекта, а именно: атрибут состояния, статический или динамический атрибут
состояния, пространство состояний, метод и другие.
Представление объектной модели в новых формализмах. Используя
приведенные выше дефиниции объекта и его свойства, дадим формальное
определение объектной модели ПС в следующем виде:
OМS = (OClass, G),
где OClass = {OClass
i
} – множество классов, G – объектный граф, в котором
вершины – классы, а дуги задают отношения объектов.
Каждый класс из OClass представляется как модель
OClass
i
= (ClassName
i
, Method
i
, Field
i
},
в которой ClassName
i
– имя класса; Method
i
= {Method
j
i
} – множество методов
класса; Field
i
= {Field
n
i
} – множество переменных, которые определяют состояние
экземпляров класса.
Пусть PField
i
Field
i
– множество внешних переменных (public) класса.
Каждому PField
n
i
PField
i
поставим в соответствие методы get<PField
n
i
> и
set<PField
n
i
> для доступа и модификации значений переменных, т.е. эти
переменные являются атрибутами.
Новое множество методов имеет вид
IMethod
i
= Method
i
{get<PField
n
i
>}
{set<PField
n
i
>}.
Каждому множеству IMethod
i
ставит в соответствие определенный интерфейс
IFunc
i
, состоящий из прототипов методов IMethod
i
, реализация которых
обеспечивает функциональность методов класса и их атрибуты.
Интерфейсная модель имеет следующий вид: ISyst = (IFunc, IG),
где IFunc = {IFunc
i
} – множество интерфейсов для классов OClass; IG –
интерфейсный граф, эквивалентный графу G. В IG вершины – это интерфейсы, а
дуги – отношения между компонентами соответствующие отношениям между
интерфейсами.
Таким образом, между графами G объектной модели и IG компонентной
166
модели существует изоморфное отображение, а функциональность реализаций для
интерфейсов IFunc
i
эквивалентна функциональности класса OClass
i
. Для классов
OClass определяются условия, которые способствует формированию их
представления в виде элементов множества интерфейсов в интерфейсном графе.
Определение 6.1. Декларированная в классе переменная называется
управляемой по доступу к ее значению со стороны других классов, если она
является public-переменной или для нее реализован доступ с помощью public-
методов класса.
Если внешнее взаимодействие с классом происходит с помощью public-
методов и управляемых переменных, то для него реализуется интерфейсный
принцип доступа. Это означает, что не существует другого способа внешнего
доступа к функциональности класса или его переменным.
Теорема 6.2. Для каждой ОМ внешнее взаимодействие с классами которой
происходит на основе public-методов и управляемых переменных, образуется
единое интерфейсное представление ISyst с эквивалентной функциональностью.
Эта теорема определяет условия существования единого эквивалентного
отображения между объектным и интерфейсным представлениями компонентов.
6.2. ТЕОРИЯ КОМПОНЕНТНОГО ПРОГРАММИРОВАНИЯ
В связи с широким практическим использованием компонентного программирования
далее рассмотрим основания компонентного программирования, а, именно, модели,
формализмы представления компонентов, интерфейсы объектов, внешнюю и
внутреннюю компонентные алгебры, операции которых предназначены для
манипулирования компонентами среды, самой средой, а также для изменения,
реконструирования и перепрограммирования наследуемых программных
компонентов и КПИ [64–67].
Приведена обновленная парадигма сборки компонентов, базисом которой
являются алгебраические системы преобразования типов данных и методы
композиции компонентов в разные программные структуры.
Проведен анализ стандарта ГОСТ 3901–99, ориентированного на представление
языков описания типов данных для всех действующих ЯП и использование для
системного преобразования переданных другому компоненту параметров, данные
которых могут отличаться от тех, что не входят в этот язык. Рассмотрены
современные подходы к решению проблем взаимодействия разноязыковых
компонентов и их реализация в общесистемных средах (CORBA, COM, JAVA).
Концепция компонента связана с фундаментальной идеей сборки, которая
развивается соответственно уже сформированным тенденциям программирования.
Усовершенствование, отождествление этих понятий и пополнение новыми для
создания целостной теоретической базы компонентного программирования – суть
этой главы.
Под компонентным программированием понимается метод создания ПС,
базирующийся на применении концепций сборки (композиции) на всех процессах
ЖЦ, где базовым элементом сборки является компонент.
Сборка компонентов – это процесс объединения отдельных компонентов в
более сложную компонентную структуру, в которой принимают участие
программные компоненты, каркасы, контейнеры и т.п. Сборка задается описанием
связей (ассоциаций) между компонентными элементами, а также утверждениями о
167
компонентах и их связях. Сборку представляют теориями первого порядка, а
правильность сборки зависит от языка спецификации компонентов.
Представление сложного патерна включает в себя предикаты описания классов,
состояний переменных, методов и их отношений. Класс и объект, а также патерн
создают сорта объектов первого класса, могут также использоваться сорта bool и
int.
Обеспечение условий повторного применения компонента – одно из основных
целей процессов компонентной разработки. Кроме унификации и стандартизации
архитектурных, структурных, технологических характеристик компонента, важную
роль играет определение его функциональности и методов доступа. Это, в свою
очередь, требует более детального подхода к определению спецификации
компонента для определенной ПрО и задач, которые решаются ею, конкретных
функций обработки данных и т.п. Сложность такого подхода состоит в том, что для
компонента не существует заведомо определенных функциональных требований,
как в случае спецификации компонентов для конкретной целевой системы.
Поэтому необходимым условием разработки КПИ является существование
определенных объективных концепций, принципов, критериев выбора и
спецификации их функциональных свойств.
6.2.1. ОСНОВНЫЕ ПОНЯТИЯ КОМПОНЕНТНОГО ПРОГРАММИРОВАНИЯ
Компонентное программирование – это разновидность сборочного
программирования, где роль элемента сборки играет программный компонент, далее
– компонент. Сущность такого программирования определяют как процесс создания
ПС из базовых объектов ОМ, целевых компонентов и КПИ. В соответствии с
жизненным циклом построения таких систем согласно объектно-компонентному
методу ОКМ проектирование новых систем выполняют как совокупность
взаимодействующих объектов, компонентов и КПИ в рамках компонентной среды.
Соответственно этому методу компонентное проектирование связано с
построением отдельных компонентов в рамках определенной ОМ ПрО. Для
обеспечения перехода от объектов ОМ к компонентному представлению объектов
установлена связь между объектно-ориентированным анализом и компонентным
проектированием ПС. Для формализации процесса компонентного проектирования
в рамках ОКМ разработан соответствующий формальный аппарат с базовой
терминологией элементов (компонент, каркас, компонентная модель, компонентная
среда и т.п.), их модели и компонентная алгебра.
Определения 6.2. Компонент – это независимый от ЯП, самостоятельно
реализованный программный объект, который обеспечивает выполнение
определенной совокупности прикладных сервисов, доступ к которым возможен
только с помощью интерфейсов, определяющие функциональные возможности
компонента и порядок обращения к его операциям.
В данном представлении компонент – отображение типового решения для
некоторого фрагмента ПрО и имеет типовую архитектуру, структуру,
характеристики и атрибуты интерфейсной части для обмена данными в
компонентной среде. Иными словами компонент, представленный таким образом,
становится неделимым и инкапсулированным программным элементом, который
удовлетворяет функциональным требованиям, а также требованиям относительно
архитектуры системы и компонентной среды.
168
Определения 6.3. Компонентная программа – это совокупность компонентов,
которые необходимы для обеспечения функциональных и нефункциональных
требований. Она строится и функционирует в соответствии с правилами
определения компонентных конфигураций и компонентного взаимодействия в
рамках объектных и компонентных моделей.
Обобщение компонентной архитектуры. Современная архитектура
компонентной среды – один из основных источников идей и подходов
компонентного программирования. Архитектура – расширение классической
модели “клиент–сервер” с учетом специфики построения и функционирования
компонентов, а также результатов практических реализаций и их апробаций.
Основа компонентной среды – множество серверов компонентов (или серверов
приложений – application servers). Внутри сервера разворачиваются компоненты,
представленные как контейнеры. Для каждого сервера может существовать
произвольное количество контейнеров.
Контейнер – это оболочка, внутри которой реализуются функции компонентва.
Взаимосвязь и взаимодействие контейнера с сервером строго регламентированы и
осуществляются через стандартизированные интерфейсы. Контейнер управляет
порождаемыми им экземплярами компонента, реализациями соответствующей
функциональности. В общем случае внутри него может существовать произвольное
число экземпляров-реализаций, каждая из которых имеет уникальный
идентификатор.
С каждым контейнером связано два типа интерфейсов для взаимодействия с
другими компонентами и интерфейс системных сервисов, необходимых для
функционирования самого контейнера и реализации специальных функций,
например, поддержка распределенных транзакций, в которых принимают участие
несколько компонентов.
Первый тип интерфейса (в некоторых архитектурах называется Home interface)
обеспечивает управлениt экземплярами компонента с обязательными реализациями
методов поиска, создания и удаления отдельных экземпляров.
Ко второму типу относятся интерфейсы, которые обеспечивают доступ к
реализации функциональности компонента. Фактически с каждым экземпляром
связан свой функциональный интерфейс.
Классы компонентов. Исходя из принципов выполнения систем компоненты
можно разделить на три класса:
– компоненты развертывания (Deployment components), которые служат
основой для формирования программы с развертыванием в компьютерной среде
(библиотеки, фрагменты готовое для выполнения, файлы конфигурации, базы
данных и др.);
– компоненты как рабочие продукты (Work product components), которые
являются по сути промежуточными и вспомогательными элементами процесса
программирования (файлы текстов с компонентами и данными, элементы с
описаниями архитектуры, правилами генерации конечного кода и др.);
– компоненты среды выполнения (Execution components), которые создаются в
процессе выполнения программы (временные программные объекты, файлы,
таблицы БД и др.).
Кроме этого разделения, каждый класс имеет несколько других видов, а именно:
программы, библиотеки, файлы, таблицы баз данных, документы и т.п.
169
Требования к компонентам. Основные требования такие:
1. Компонент имеет один или больше интерфейсов, которые имеют уникальные
имена и описания, определяющие структуру интерфейсов. Компонент обязательно
должен иметь хотя бы один интерфейс, так как компоненты используются с
помощью их интерфейсов.
2. Каждый интерфейс состоит из определенного количества операций (методов).
Каждая операция имеет собственный идентификатор, множество входных и
выходных параметров, каждый из которых имеет тип из заведомо определенного
множества простых и структурных типов данных. Совокупность параметров (с
учетом их приведения в порядок) и их типов определяет сигнатуру операции, а
совокупность сигнатур всех операций определяет сигнатуру соответствующего
интерфейса. Каждый интерфейс должен иметь по крайней мере одну операцию.
3. Каждый компонент относительно схемы взаимодействия может быть как
сервером, так и клиентом. Если к нему обращаются другие компоненты, то он –
сервер. Для поддержки компонентом определенного сервиса в некоторых случаях
необходимо обращаться к другим объектам, например, к компоненту, который
отвечает за сохранение данных. В этом случае компонент – клиент.
Последовательность их взаимодействий может быть сложной.
4. Совокупность интерфейсов можно разделить на два типа. К первому типу
относятся интерфейсы, которые непосредственно описывают функциональность
компонента, т.е. его сервисные возможности. Ко второму типу относятся ссылка на
интерфейсы других компонентов, операции которых необходимо выполнить для
обеспечения нормального функционирования компонента.
5. Все возможные взаимодействия между компонентами определяются на
основе их интерфейсов. Такое требование запрещает существование скрытых
(hidden) взаимодействий. Объекты, между которыми могут быть скрытые
взаимодействия должны входить в состав одного компонента и рассматриваться
как единое целое. Иными словами, компоненты поддерживают инкапсуляцию и их
интерфейсы являются открытыми (public).
6. Информация, которая приведена в открытых интерфейсах, должна быть
полной для описания внешнего поведения компонента и исключать
неопределенность в при его применении. Все внутренние характеристики и
особенно защита компонента в середине и извне – недоступны.
Общие свойства компонентов. Компоненты, как определенный тип
программных объектов, имеют характерные и общие свойства, присущие всему
множеству компонентов. Компонент имеет такие дополнительные свойства:
1. Компонент - инкапсулированный (encapsulated) объект. Инкапсуляция –
процесс упрятывания (закрытости) реализации и кода, которые обеспечивают
выполнение компонентом своих функций. Инкапсуляция компонента означает, что
весь код закрытый, доступ к нему происходит с помощью специальных
интерфейсов.
2. Компонент - самоопределенный (descriptive) объект. Пользователь
компонента должен четко понимать как его назначение, так и особенности
функционирования. Этого можно достичь лишь при наличии полной и
всесторонней информации о нем. Соответственно структура компонента должна
описывать три аспекта – интерфейсы, реализацию, развертывание.
3. Компонент – взаимозаменяющий (replaceable) объект. Это свойство является
170
следствием задания инкапсуляции и самоопределения. Первое свойство разрешает
пользователю не учитывать внутренние особенности компонента, а второе –
определяет его поведение, связи с другими компонентами и требования к внешней
среде. В этом случае любой компонент с необходимой функциональностью и
соответствующими интерфейсами может быть использован не только при
построении программы, и при сопровождении и развитии (например, новый
компонентов более качественно реализует функциональность или требует меньше
ресурсов).
4. Компонент – расширяющий объект (extensible). Это свойство
обуславливается необходимостью развивать и усовершенствовать компонент в
целях улучшения существующих показателей и добавления новых функций.
Модели компонентного программирования. Формальные модели
компонентного программирования обеспечивают простой переход от теории к
практике с применением архитектуры и моделей современных систем CORBA,
COM, EJB и реализацию базиса формальных методов построения компонентных
программ и систем. Такие задачи не реализуются в рамках одной определенной
модели. Предлагается семейство формальных моделей и других абстрактных
структур с единой понятийной, терминологической и математической базой:
– модель компонента;
– модель компонентной среды;
– внешняя компонентная алгебра;
– модели сборки (композиции) компонентов.
Эти модели – типичны и ориентированы на применение их при теоретических
исследованиях и построении элементов теории компонентного программирования.
6.2.2. МОДЕЛЬ КОМПОНЕНТА И ИНТЕРФЕЙСА
Под моделью компонента понимают абстрактное представление, которое отражает
основные свойства, характеристики, типичную структуру, а также способность к
взаимодействию с другими элементами компонентной среды.
Модель произвольного компонента в общем случае имеет вид
Comp = (CName, CInt, CFact, CImp, CServ), (6.3)
где CName – уникальное имя компонента; CInt = {CInt
i
} – множество
интерфейсов, связанных с компонентом; CFact – интерфейс управления
экземплярами компонента; CImp = {CImp
j
} – множество реализаций компонента;
CServ = {CServ
r
} – интерфейс, который определяет множество системных сервисов,
необходимых для поддержки функционирования компонента и взаимодействия с
компонентной средой.
Суть данной концепции модели сводится к следующим аксиомам:
1) операции алгебры определяются над элементами данной модели и только на
них;
2) операций алгебры обеспечивают необходимые условия целостности
компонента.
Фактически это означает, что сложные модели (6.3) определяют основное
множество элементов компонентной алгебры.
Имя компонента уникально в любом пространстве имен для компонентной
среды. Для разрешения коллизий применяют метод квалификационных признаков
(глава 5). Фактически это означает, что каждое имя входит в некоторое