Софтуерен инженеринг базиран на компоненти

Софтуерно инженерство 19 Slide 1

Софтуерен инженеринг базиран на компоненти


Цели

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

Да опише компонентите и моделите им Да покаже основните действия в процеса

CBSE Да се обсъдят подходите при

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


Теми

Компоненти и модели на компоненти Процесът на CBSE Съчетаване на компоненти Component composition


Разработка базирана на компоненти

CBSE е подход за разработка на софтуер, който почива на многократното използване.

Този подход е резултат от неуспеха на ОО разработването да поддържа многократното използване. Единичните класове са твърде подробни и специфични.

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


Съществени елементи на CBSE

Независими компоненти специфицирани от интерфейсите си.

Стандарти за компонентите за улеснение на интегрирането на компонентите.

Middleware – междинни компоненти, които осигуряват поддръжката на взаимодействието м/у компонентите

Процес на разработка, пригоден за проект на многократно използване


CBSE принципите на проектиране

Освен на многократното използване, CBSE се основава на сигурни принципи:• Компонентите са независими и не си влияят;• Реализацията на компонентите е скрита;• Комуникацията се извършва чрез добре

дефинирани интерфейси.• Съществуват споделени платформи на

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


Проблеми при CBSE

Степен на доверие в компонентата – как може да се вярва в качествата на компонента без сорс код.

Сертифициране на компонентата – кой ще сертифицира качеството на компонентите?

Предвиждане на интегралните свойства – как ще се предскажат интегралните (emergent) свойства на взаимодействащите се компоненти?

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


Компоненти

Компонентите доставят услуга като не е от значение, къде се изпълнява компонентата или програмния език, на който е написана.• Компонентата е независим изпълнима

единица,, която може да е съставена от един или повече изпълними обекти.

• Интерфейсът на на компонентата е публичен и всички взаимодействия се извършват чрез него.


Дефиниции на компоненти

Councill and Heinmann:• A software component is a software element that

conforms to a component model and can be independently deployed and composed without modification according to a composition standard.

Szyperski:• A software component is a unit of composition with

contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third-parties.


Компонентата като доставчик на услуги

Компонентата е независима изпълнима единица. Не е нужно да се компилира преди да се използва с други компоненти.

Всички предлагани услуги са достъпни през интерфейс и всички взаимодействия с компонентата се извършват през този интерфейс.


Характеристики на компонентите 1

Стандартизирани Това означава, че компонентата, използвана в процеса на CBSE, трябва да отговаря на някакъв стандартизиран модел. Този модел може да дефинира интерфейсите, мета-данните, документацията, композирането и предаването.

Независими Компонентата трябва да е независима – трябва да може да се композира и предава, без да са необходими други специфични компоненти. Там, където компонентата има нужда от външно доставени услуги, те трябва да са указани в спецификация ‘requires’ на интерфейса.

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

Всички външни взаимодействия трябва да се извършват през публично дефиниран интерфейс. Освен това, компонентата трябва да дава достъп до информация за себе си като методи и атрибути.


Характеристики на компонентите 2

Готова за предаване Компонентата трябва да независима и да способна да функционира като самостоятелна единица на някаква компонентна платформа, която компонентния реализира модел. Това обикновено означава, че компонентната е бинарна и не се нуждае от компилация преди да бъде предадена.

Документирана Компонентите трябва да са напълно документирани, за да могат потенциалните потребители да решат, дали компонентата отговаря на нуждите им. Синтаксисът и семантиката на интерфейса трябва да са описани.


Интерфейси на компонентите

Изходен интерфейс (provides interface)Дефинира услугите, които се доставят чрез

интерфейса от компонентата към други компоненти.

Входен интерфейс (requires interface)Дефинира услугите, които трябва да са

достъпни, за да може компонентата да работи според спецификацията.


Интерфейси на компонентите

Изходен интерфейсВходен интерфейс

ComponentДефинира услугите от обкръжението на компонентата, които тя използва

Дефинира услугите, доставяни от компонентата


Компонента за събиране на данни

Provides interfaceRequires interface

Data collector

addSensorremoveSensorstartSensor

stopSensor

testSensor

listAllreport

initialise

sensorManagement

sensorData


Компоненти и обекти

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

Компонентите не дефинират типове Реализацията на компонентите е скрита. Компонентите са независими от езика. Компонентите са стандартизирани.


Компонентен модел

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

Примери на компонентни модели• EJB model (Enterprise Java Beans)• COM+ model (.NET model)• Corba Component Model

Компонентният модел специфицира, как трябва да се дефинира интерфейсът и елементите, които трябва да се включат в тази дефиниция.


Елементи на компонентен модел

Component model

InterfacesUsage

informationDeployment

and use

Interfacedefinition

Specificinterfaces

Composition

Namingconvention

Meta-dataaccess

Customisation

Packaging

Documentation

Evolutionsupport


Поддържащи системи

Компонентният модел е основа за система, която осигурява поддръжката на изпълняваните компоненти.

Тези системи осигуряват:• Платформени услуги, които позволяват компоненти

написани съгласно модела да комуникират помежду си.

• Хоризонтални услуги – независими от приложението услуги, използвани от различните компоненти

За да използват услугите на модела, компонентите се оформят в контейнер. Това е набор от интерфейси, използвани за достъп до реализацията на услугите на модела и за достъп на услугите на компонентата от други компоненти.


Услуги на компонентния модел

Platform services

AddressingInterfacedefinition

Componentcommunications

Exceptionmanagement

Horizontal services

Security

Transactionmanagement

Concurrency

Componentmanagement

Persistence

Resourcemanagement


Разработка на компоненти за многократно използване

За да се пригодят за многократно използване, компонентите, които са разработени за специфично приложение, се нуждаят от обобщаване.

Една компонента е по-пригодна за многократно използване, ако е свързана със стабилна абстракция на областта на приложение (бизнес обекта).

Например, за една болница, стабилните абстракции са свързани с основното предназначение – сестри, пациенти, лечение и др.


Разработка на компоненти за многократно използване

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

Многократното използваната компонента трябва• Да се основава на стабилна абстракция на областта;• Да крие представянето на състоянията;• Да бъде колкото се може по-независима• Да публикува изключенията чрез интерфейса си.

Има компромис м/у многократност и използваемостКолкото по-общ е интерфейсът, толкова по-вече приложения

могат да я използват, но тогава е по-сложен и по-малко използваем.


Промени правени за многократно използване.

Премахват се специфичните методи Променят се имената с по-общи. Добавят се методи за да се разшири

приложението. Обработката на изключенията се прави

последователна. Добавя се конфигурационен интерфейс за

адаптация Интегриране на изискваните компоненти, за да

се намали зависимостта.


Компоненти от наследени с-ми

Съществуващи с-ми, които изпълняват полезни бизнес функции могат да се препакетират като компоненти за многократно използване.

Това предполага написването на обгръщаща (wrapper) компонента, която реализира интерфейсите на наследената с-ма.

Макар и скъпо, това може и да много по-евтино отколкото пренаписването на наследената с-ма.


Компоненти за многократно използване

Разработката на компоненти за многократно използване може да е по-скъпо от разработката на специфични такива. Това увеличение на цената трябва да по-скоро за сметка на организацията, отколкото на проекта.

Обобщените компоненти може да са по-малко ефективни, като изисквания за памет и процесорно време от техните специфични еквиваленти.


Процесът на CBSE

Когато се използват готови компоненти, е съществено да се направи компромис м/у идеалните изисквания и услугите доставяни от разполагаемите компоненти.

Това включва:• Разработка на предварителни изисквания;• Търсене на компоненти и след това промяна

на изискванията в съответствие със съществуващата функционалност.

• Ново търсене на по-добри компоненти удовлетворяващи новите изисквания.


Процесът на CBSE

Identify candidatecomponents

Outlinesystem

requirements

Modifyrequirements

according to discoveredcomponents

Identify candidatecomponents

Architecturaldesign

Composecomponents tocreate system


Процес на идентификация на компонентите

Componentselection

Componentsearch

Componentvalidation


Въпроси на идентификацията на компонентите

Доверие. Трябва да се има доверие на доставчика на компонентата. В най-добрия случай калпавата компонента няма да работи както е в рекламата, а в най-лошия ще пробие сигурността.

Изисквания. Различни групи от компоненти удовлетворяват различни изисквания.

Валидиране• Спецификацията на компонентата може де не е

достатъчно подробна, за да се разработят добри тестове.

• Компонентите могат да имат нежелана функционалност. как може да се тества дали тя няма да влияе на конкретното приложение?


Провалът при изстрелването на Ariane

През 1996 г. се провали първият опит за изстрелване на Ariane 5, когато софтуерът на изстрелването излезе от контрол 37 сек. след началото.

Проблемът беше в използвана от предишна версия компонента ((the Inertial Navigation System), която отказа, защото предположенията, при които беше разработвана компонентата не бяха верни за Ariane 5.

Функционалността, която беше причина за срива, не се изискваше за Ariane 5.


Сглобяване на компонентите

Процес на събиране на компонентите за създаване на действаща с-ма.

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

Нормално трябва да се пише "свързващ код" (glue code), за да се свържат компонентите.


Типове на сглобяване

Последователно, при което компонентите се изпълнява последователно. Това предполага сглобяване на изходните интерфейси на всяка компонента.

Йерархично, при което една компонента извиква услугите на друга. Изходният интерфейс на едната компонента се сглобява с входния интерфейс на другата.

Адитивна, когато интерфейсите на 2 компоненти се събират за създаването на нова компонента.


Типове на сглобяване

(a)

A A

B B

A B

(b) (c)


Несъвместимост на интерфейсите

Несъвместимост на параметрите – операциите имат еднакви имена, но различни типове.

Несъвместимост на операциите – имената на операциите в сглобяваните интерфейси са различни.

Незавършеност на операциите – изходният интерфейс на едната компонента е подмножество на входния интерфейс на другата.


Несъвместими компоненти

addressFinder

phoneDatabase (string command)string location(string pn)

string owner (string pn)

string propertyType (string pn)

mapper

mapDB (string command)displayMap (string postCode, scale)

printMap (string postCode, scale)


Компоненти - адаптери

Служат за решаване на проблема на несъвместимостта като съгласуват интерфейсите, които трябва да се сглобят.

За различните типове сглобяване са нужни различни типове адаптери.

addressFinder и mapper могат да се сглобят чрез адаптер, който извлича пощенския код от един адрес и го подава на компонентата mapper.


Сглобяване чрез адаптер

Компонентата postCodeStripper е адаптер, който улеснява последователната композиция на компонентите addressFinder и mapper.


Адаптер за компонентата за събиране на данни

Data collector

addSensorremoveSensorstartSensor

stopSensortestSensor

listAllreportinitialise

sensorManagement

sensorData

Adaptersensor

start

getdata

stop


Семантика на интерфейса

За да решите, дали съвместими по синтаксис интерфейси са действително съвместими, вие трябва да разчитате на документацията.

Да разгледаме интерфейс на компонента PhotoLibrary

public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc) ;public Photograph retrieve (Identifier pid) ;public CatalogEntry catEntry (Identifier pid) ;


Сглобяване на Photo library

PhotoLibrary

adaptorImage

Manager

getImage

UserInterface

getCatalogEntry

addItem

retrieve

catEntry


Документация на Photo Library

“This method adds a photograph to the library and associates the photograph identifier and catalogue descriptor with the photograph.”

"какво се случва ако идентификаторът е вече асоцииран със снимка в библиотеката?""дали описанието на снимката е асоциирано кактос каталога, така и със самата снимка, т.е. ако изтрия снимката, ще изтрия ли и информацията в каталога?"


Object Constraint Language (OCL)

Object Constraint Language е проектиран да дефинира ограниченията асоциирани с UML моделите.

Основава се на понятието за спецификация пре и пост условията – подобно на езика Z.


Формално описание на фото-библиотеката


Условия за фото-библиотеката

Както е показано OCL асоцииран с компонентата Photo Library казва,че:• Не може да има снимка в библиотеката със същия

идентификатор както на тази, която се добавя;• Библиотеката трябва да съществува – предполага се,

че със създаването на библиотеката се добавя един елемент;

• Всеки добавен елемент увеличава размера на библиотеката с 1

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

• Ако търсите в каталога, използвайки същия идентификатор, ще намерите елемента, който сте създали.


Компромиси при сглобяването

Когато сглобявате компоненти, може да откриете конфликти м/у функционалните и нефункционалните изисквания и конфликти м/у нуждата за бързо приключване и усъвършенстване на с-мата.

Трябва да вземете някои решения като:• Коя композиция от компоненти е ефективна за

осигуряване на функционалните изисквания?• Коя композиция от компоненти позволява бъдещи

промени?• Какви ще бъдат интегралните свойства на

композираната с-ма?


Събиране на данни и генериране на отчети

(a) Datacollection

(b)

Datamanagement

Reportgenerator

Datacollection Data base

Report

Report


Обобщение

CBSE е подход, основан на многократното използване и на съчетаването на слабо свързани компоненти в с-ми.

Компонента е софтуерна единица, чиято функционалност и зависимост са напълно определени от интерфейсите й.

Един компонентен модел дефинира набор стандарти, които трябва да се следват от доставчиците и създателите на с-ми.

По време на CBSE процеса, процесите на инженеринга на изискванията и на проектирането на с-мата се припокриват.


Обобщение

Композирането на с-мата е процес на "навързване" на компонентите, за да се създаде с-ма

Когато се сглобяват готови компоненти, обикновено трябва да се пишат адаптери, които съгласуват интерфейсите им.

Когато се избират компоненти, трябва да се взимат под внимание функционалните изисквания, нефункционалните изисквания и перспективата за еволюция на с-мата.

Documents

Софтуерен инженеринг базиран на компоненти