Главная
страница 1
Разработка КПИ - компонентов повторного использования
Модель интерфейса

CInt = (IntName, IntFunc, IntSpec),

де IntName –имя интерфейса, IntFunc имя функции, IntSpec – спецификатор интерфейса.


Модель компонентной среды

CE = (NameSpace, IntRep, ImpRep, CServ, CServImp),

где
NameSpace = {CNamem} – множество имен компонентов;
IntRep = {IntRepi} – репозитарий интерфейсов компонентов;
ImpRep = {ImpRepj} – репозитарий рализаций;
CServ = CServr} – интерфейс множества сервисов;
CServImp = {CServImpr} –множество реализаций сервисов.


Компонентная алгебра -

 = 1  2 = {CSet, CESet, 1, 2}
Внешняя
Внешняя алгебра: 1 = { CSet, CESet, 1}.

Операции алгебры W1= { CE1 , CE2, CE3 , CE4}:

1. инсталляции (развертки) CE = Comp Å CE1

2. объединение компонентных сред CE3 = CE1 È CE2


3. Удаление компонента из среды


CE2 = CE1 \ Comp

4-замена компонента Comp1 на Comp2 ,


CE2 = Comp2 Å (CE1 \ Comp1).
Внутренняя алгебра: 2 = {CSet, CESet, 2}.

Операции
Операции алгебры: 2 = {Оrefac, Oreing, Orevers},



Модель рефакторинга компонентов:
Мrefac = {Orefac, {CSet = {NewCompn}},

операции


Оrefac = {AddOImp, AddNImp, ReplImp, AddInt}.

Модель реинженерии компонентов:
МReing = {Oreing, {CSet = {NewCompn}},

операции

Oreing = {rewrite, restruc, adop, supp, conver }.
 

Модель реверсной инженерии компонентов:

Мrevers = {Orevers , {CSet = {NewCompn}},

операции Orevers = {visual, design, destruct, rewrite).

Операции компонентной алгебры реализованы в системе ГП для обработки компонентов или КПИ в репозитории, а также на фабриках программ в технологии сборки КПИ.



ЖЦ построения компонентной системы


  1. Анализ предметной области для декомпозиции на подсистемы и отделения отдельных функций будущей системы для их подачи отдельными компонентами или поиск готовых с подобными функциями.

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

  3. Разработка требований (Requirements) по ПС – это формирование и описание функциональных, нефункциональных и других свойств ПС.

  4. Анализ поведения (Behavioral Analysis) ПС заключается в определении функций системы, деталей проектирования и методов их использования.

  5. Спецификация интерфейсов и взаимодействий компонентов (Interface and Interaction Specification) отражает распределение параметров компонентов для задания интерфейсов и взаимодействий компонентов через потоки действий или работ (workflow).

  6. Интеграция набора компонентов и КПИ (Application Assembly and Component Reuse) в единую среду основывается на подборе и адаптации КПИ, определенные совокупности правил , условий интеграции (сборки) и построения конфигурации системы.

  7. Тестирование компонентов (Components Testing) основывается на методах верификации и тестирования для проверки правильности как отдельных компонентов и КПИ, так и интегрированной из компонентов программной системы.

  8. Развертка (System Deployment) содержит в себе оптимизацию плана компонентной конфигурации с учетом среды, развёртки отдельных компонентов и создания целевой компонентной конфигурации для функционирования ПС.

  9. Сопровождение ПС (System Support and Maintenance) состоит из анализа ошибок и отказов в работе ПС, поиска и исправления ошибок , повторного его тестирования и адаптации новых компонентов к требованиям и условиям интегрированной среды.



Технология обработки КПИ – это следующие процессы:

- описания КПИ языками программирования;

- спецификации интерфейсов КПИ (IDL, XML, Icontract, SIDL…);

- инженерии разработки доменов, семейств программ и систем – СПС;

- сборки
0-

0-


  1. Компонентов из КПИ готовых программ и систем;

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

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



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

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

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

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

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

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

К компонентам среды относятся:

- Серверы компонентов;

- Контейнеры компонентов;

- реализации функций, представленные как экземпляры внутри контейнеров;

- реализация компонентных моделей, объектов, удовлетворяющих установку и конфигурирование отдельных компонентов для некоторой компьютерной платформы;

- Клиентские компоненты и интерфейсы, обеспечивающие конечного пользователя, реализованы в виде различных типов клиентов (веб-клиенты, полноценные реализации графического интерфейса и т.д.);

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

К архитектуре компонентной системы отнесены:

- Серверы компонентов;

- Контейнеры компонентов;

- Реализации функций, представленных как экземпляры внутри контейнеров;

- Реализация компонентных моделей, объектов, удовлетворяющих установку и конфигурирование отдельных компонентов для некоторой компьютерной платформы;

- Клиентские компоненты и интерфейсы, обеспечивающие конечного пользователя, реализованные в виде различных типов клиентов (веб-клиенты, полноценные реализации графического интерфейса и т.д.);

- Компонентные применения, как совокупность компонентов и КПИ.

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

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

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



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

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


Смотрите также:
Разработка кпи компонентов повторного использования Модель интерфейса
74.04kb.
1 стр.
Модель вариантов использования системы ведения видеоархива телеканала юургу-тв технический отчет tr-videoStorm-01
164.75kb.
1 стр.
Модель вариантов использования системы ведения видеоархива телеканала юургу-тв технический отчет tr-videoStorm-01
174.01kb.
1 стр.
«Разработка аналого-цифровых интегральных компонентов с расширенным диапазоном рабочих частот и пониженной потребляемой мощностью»
51.23kb.
1 стр.
Цены на производство виртуальных туров и ориентировочное время выполнения работ
31.58kb.
1 стр.
Разработка и программная реализация модульной интегрируемой системы предоставления средств голосового интерфейса для разработки программного обеспечения
808.52kb.
4 стр.
Магнитный сверлильный станок мва-38 Новая модель 2012г
135.86kb.
1 стр.
Термины и определения Архитектура
143.25kb.
1 стр.
Профессиональные навыки и знания
31.44kb.
1 стр.
Методическая разработка учебного мини-проекта по математике «Модель машины времени» ос «Школа 2100»
57.61kb.
1 стр.
Объектно-ориентированное программирование: Разработка пользовательского интерфейса
94.69kb.
1 стр.
Методическая разработка «праздники, обычаи, традиции великобритании»
457.99kb.
4 стр.