Софтуерен инженеринг базиран на компоненти Софтуерно инженерство 19 Slide 1
Цели l l Да покаже, че тази тема е свързана с разработката на стандартни компоненти и съчетаването им в приложения. Да опише компонентите и моделите им Да покаже основните действия в процеса CBSE Да се обсъдят подходите при съчетаването на компонентите и проблемите, които могат да възникнат. Софтуерно инженерство 19 Slide 2
Теми l l Компоненти и модели на компоненти Процесът на CBSE Съчетаване на компоненти Component composition Софтуерно инженерство 19 Slide 3
Разработка базирана на компоненти l l l CBSE е подход за разработка на софтуер, който почива на многократното използване. Този подход е резултат от неуспеха на ОО разработването да поддържа многократното използване. Единичните класове са твърде подробни и специфични. Компонентите са по абстрактни от класовете обекти и могат да се разглеждат като самостоятелни доставчици на услуги. Софтуерно инженерство 19 Slide 4
Съществени елементи на CBSE l l Независими компоненти специфицирани от интерфейсите си. Стандарти за компонентите за улеснение на интегрирането на компонентите. Middleware – междинни компоненти, които осигуряват поддръжката на взаимодействието м/у компонентите Процес на разработка, пригоден за проект на многократно използване Софтуерно инженерство 19 Slide 5
CBSE принципите на проектиране l Освен на многократното използване, CBSE се основава на сигурни принципи: • • Компонентите са независими и не си влияят; Реализацията на компонентите е скрита; Комуникацията се извършва чрез добре дефинирани интерфейси. Съществуват споделени платформи на високо ниво, които намаляват разходите за разработка. Софтуерно инженерство 19 Slide 6
Проблеми при CBSE l l Степен на доверие в компонентата – как може да се вярва в качествата на компонента без сорс код. Сертифициране на компонентата – кой ще сертифицира качеството на компонентите? Предвиждане на интегралните свойства – как ще се предскажат интегралните (emergent) свойства на взаимодействащите се компоненти? Компромис на изискванията – как да анализираме баланса между възможностите на различни компоненти? Софтуерно инженерство 19 Slide 7
Компоненти l Компонентите доставят услуга като не е от значение, къде се изпълнява компонентата или програмния език, на който е написана. • • Компонентата е независим изпълнима единица, , която може да е съставена от един или повече изпълними обекти. Интерфейсът на на компонентата е публичен и всички взаимодействия се извършват чрез него. Софтуерно инженерство 19 Slide 8
Дефиниции на компоненти l Councill and Heinmann: • l 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. Софтуерно инженерство 19 Slide 9
Компонентата като доставчик на услуги l l Компонентата е независима изпълнима единица. Не е нужно да се компилира преди да се използва с други компоненти. Всички предлагани услуги са достъпни през интерфейс и всички взаимодействия с компонентата се извършват през този интерфейс. Софтуерно инженерство 19 Slide 10
Характеристики на компонентите 1 Софтуерно инженерство 19 Slide 11
Характеристики на компонентите 2 Софтуерно инженерство 19 Slide 12
Интерфейси на компонентите l Изходен интерфейс (provides interface) Дефинира услугите, които се доставят чрез интерфейса от компонентата към други компоненти. l Входен интерфейс (requires interface) Дефинира услугите, които трябва да са достъпни, за да може компонентата да работи според спецификацията. Софтуерно инженерство 19 Slide 13
Интерфейси на компонентите Входен интерфейс Изходен интерфейс Дефинира услугите от обкръжението на компонентата, които тя използва Component Софтуерно инженерство 19 Дефинира услугите, доставяни от компонентата Slide 14
Компонента за събиране на данни Requires int erface Provides int rface e sensor. Management Data collector sensor. Data Софтуерно инженерство 19 add. Sensor remove. Sensor start. Sensor stop. Sensor test. Sensor initialise report list. All Slide 15
Компоненти и обекти l l l Компонентите са самостоятелни, готови за предаване единици. Компонентите не дефинират типове Реализацията на компонентите е скрита. Компонентите са независими от езика. Компонентите са стандартизирани. Софтуерно инженерство 19 Slide 16
Компонентен модел l l Това е дефиниция на стандарти за реализация, документация и предаване на компонентите. Примери на компонентни модели • • • l EJB model (Enterprise Java Beans) COM+ model (. NET model) Corba Component Model Компонентният модел специфицира, как трябва да се дефинира интерфейсът и елементите, които трябва да се включат в тази дефиниция. Софтуерно инженерство 19 Slide 17
Елементи на компонентен модел Софтуерно инженерство 19 Slide 18
Поддържащи системи l l Компонентният модел е основа за система, която осигурява поддръжката на изпълняваните компоненти. Тези системи осигуряват: • • l Платформени услуги, които позволяват компоненти написани съгласно модела да комуникират помежду си. Хоризонтални услуги – независими от приложението услуги, използвани от различните компоненти За да използват услугите на модела, компонентите се оформят в контейнер. Това е набор от интерфейси, използвани за достъп до реализацията на услугите на модела и за достъп на услугите на компонентата от други компоненти. Софтуерно инженерство 19 Slide 19
Услуги на компонентния модел Софтуерно инженерство 19 Slide 20
Разработка на компоненти за многократно използване l l l За да се пригодят за многократно използване, компонентите, които са разработени за специфично приложение, се нуждаят от обобщаване. Една компонента е по-пригодна за многократно използване, ако е свързана със стабилна абстракция на областта на приложение (бизнес обекта). Например, за една болница, стабилните абстракции са свързани с основното предназначение – сестри, пациенти, лечение и др. Софтуерно инженерство 19 Slide 21
Разработка на компоненти за многократно използване l l l Тези компоненти могат да са разработени специално чрез обобщаване на съществуващи такива. Многократното използваната компонента трябва • Да се основава на стабилна абстракция на областта; • Да крие представянето на състоянията; • Да бъде колкото се може по-независима • Да публикува изключенията чрез интерфейса си. Има компромис м/у многократност и използваемост Колкото по-общ е интерфейсът, толкова по-вече приложения могат да я използват, но тогава е по-сложен и по-малко използваем. Софтуерно инженерство 19 Slide 22
Промени правени за многократно използване. l l l Премахват се специфичните методи Променят се имената с по-общи. Добавят се методи за да се разшири приложението. Обработката на изключенията се прави последователна. Добавя се конфигурационен интерфейс за адаптация Интегриране на изискваните компоненти, за да се намали зависимостта. Софтуерно инженерство 19 Slide 23
Компоненти от наследени с-ми l l l Съществуващи с-ми, които изпълняват полезни бизнес функции могат да се препакетират като компоненти за многократно използване. Това предполага написването на обгръщаща (wrapper) компонента, която реализира интерфейсите на наследената с-ма. Макар и скъпо, това може и да много поевтино отколкото пренаписването на наследената с-ма. Софтуерно инженерство 19 Slide 24
Компоненти за многократно използване l l Разработката на компоненти за многократно използване може да е поскъпо от разработката на специфични такива. Това увеличение на цената трябва да по-скоро за сметка на организацията, отколкото на проекта. Обобщените компоненти може да са помалко ефективни, като изисквания за памет и процесорно време от техните специфични еквиваленти. Софтуерно инженерство 19 Slide 25
Процесът на CBSE l l Когато се използват готови компоненти, е съществено да се направи компромис м/у идеалните изисквания и услугите доставяни от разполагаемите компоненти. Това включва: • • • Разработка на предварителни изисквания; Търсене на компоненти и след това промяна на изискванията в съответствие със съществуващата функционалност. Ново търсене на по-добри компоненти удовлетворяващи новите изисквания. Софтуерно инженерство 19 Slide 26
Процесът на CBSE Софтуерно инженерство 19 Slide 27
Процес на идентификация на компонентите Софтуерно инженерство 19 Slide 28
Въпроси на идентификацията на компонентите l l l Доверие. Трябва да се има доверие на доставчика на компонентата. В най-добрия случай калпавата компонента няма да работи както е в рекламата, а в най-лошия ще пробие сигурността. Изисквания. Различни групи от компоненти удовлетворяват различни изисквания. Валидиране • • Спецификацията на компонентата може де не е достатъчно подробна, за да се разработят добри тестове. Компонентите могат да имат нежелана функционалност. как може да се тества дали тя няма да влияе на конкретното приложение? Софтуерно инженерство 19 Slide 29
Провалът при изстрелването на Ariane l l l През 1996 г. се провали първият опит за изстрелване на Ariane 5, когато софтуерът на изстрелването излезе от контрол 37 сек. след началото. Проблемът беше в използвана от предишна версия компонента ((the Inertial Navigation System), която отказа, защото предположенията, при които беше разработвана компонентата не бяха верни за Ariane 5. Функционалността, която беше причина за срива, не се изискваше за Ariane 5. Софтуерно инженерство 19 Slide 30
Сглобяване на компонентите l l l Процес на събиране на компонентите за създаване на действаща с-ма. То включва интегриране на компонентите една с друга и с инфраструктурата. Нормално трябва да се пише "свързващ код" (glue code), за да се свържат компонентите. Софтуерно инженерство 19 Slide 31
Типове на сглобяване l l l Последователно, при което компонентите се изпълнява последователно. Това предполага сглобяване на изходните интерфейси на всяка компонента. Йерархично, при което една компонента извиква услугите на друга. Изходният интерфейс на едната компонента се сглобява с входния интерфейс на другата. Адитивна, когато интерфейсите на 2 компоненти се събират за създаването на нова компонента. Софтуерно инженерство 19 Slide 32
Типове на сглобяване Софтуерно инженерство 19 Slide 33
Несъвместимост на интерфейсите l l l Несъвместимост на параметрите – операциите имат еднакви имена, но различни типове. Несъвместимост на операциите – имената на операциите в сглобяваните интерфейси са различни. Незавършеност на операциите – изходният интерфейс на едната компонента е подмножество на входния интерфейс на другата. Софтуерно инженерство 19 Slide 34
Несъвместими компоненти Софтуерно инженерство 19 Slide 35
Компоненти - адаптери l l l Служат за решаване на проблема на несъвместимостта като съгласуват интерфейсите, които трябва да се сглобят. За различните типове сглобяване са нужни различни типове адаптери. address. Finder и mapper могат да се сглобят чрез адаптер, който извлича пощенския код от един адрес и го подава на компонентата mapper. Софтуерно инженерство 19 Slide 36
Сглобяване чрез адаптер l Компонентата post. Code. Stripper е адаптер, който улеснява последователната композиция на компонентите address. Finder и mapper. Софтуерно инженерство 19 Slide 37
Адаптер за компонентата за събиране на данни Софтуерно инженерство 19 Slide 38
Семантика на интерфейса l l За да решите, дали съвместими по синтаксис интерфейси са действително съвместими, вие трябва да разчитате на документацията. Да разгледаме интерфейс на компонента Photo. Library Софтуерно инженерство 19 Slide 39
Сглобяване на Photo library Софтуерно инженерство 19 Slide 40
Документация на Photo Library “This method adds a photograph to the library and associates the photograph identifier and catalogue descriptor with the photograph. ” "какво се случва ако идентификаторът е вече асоцииран със снимка в библиотеката? " "дали описанието на снимката е асоциирано кактос каталога, така и със самата снимка, т. е. ако изтрия снимката, ще изтрия ли и информацията в каталога? " Софтуерно инженерство 19 Slide 41
Object Constraint Language (OCL) l l Object Constraint Language е проектиран да дефинира ограниченията асоциирани с UML моделите. Основава се на понятието за спецификация пре и пост условията – подобно на езика Z. Софтуерно инженерство 19 Slide 42
Формално описание на фотобиблиотеката Софтуерно инженерство 19 Slide 43
Условия за фото-библиотеката l Както е показано OCL асоцииран с компонентата Photo Library казва, че: • • • Не може да има снимка в библиотеката със същия идентификатор както на тази, която се добавя; Библиотеката трябва да съществува – предполага се, че със създаването на библиотеката се добавя един елемент; Всеки добавен елемент увеличава размера на библиотеката с 1 Ако извличате, като използвате същия идентификатор, ще получите снимката, която сте добавили; Ако търсите в каталога, използвайки същия идентификатор, ще намерите елемента, който сте създали. Софтуерно инженерство 19 Slide 44
Компромиси при сглобяването l l Когато сглобявате компоненти, може да откриете конфликти м/у функционалните и нефункционалните изисквания и конфликти м/у нуждата за бързо приключване и усъвършенстване на с-мата. Трябва да вземете някои решения като: • • • Коя композиция от компоненти е ефективна за осигуряване на функционалните изисквания? Коя композиция от компоненти позволява бъдещи промени? Какви ще бъдат интегралните свойства на композираната с-ма? Софтуерно инженерство 19 Slide 45
Събиране на данни и генериране на отчети Софтуерно инженерство 19 Slide 46
Обобщение l l CBSE е подход, основан на многократното използване и на съчетаването на слабо свързани компоненти в с-ми. Компонента е софтуерна единица, чиято функционалност и зависимост са напълно определени от интерфейсите й. Един компонентен модел дефинира набор стандарти, които трябва да се следват от доставчиците и създателите на с-ми. По време на CBSE процеса, процесите на инженеринга на изискванията и на проектирането на с-мата се припокриват. Софтуерно инженерство 19 Slide 47
Обобщение l l l Композирането на с-мата е процес на "навързване" на компонентите, за да се създаде с-ма Когато се сглобяват готови компоненти, обикновено трябва да се пишат адаптери, които съгласуват интерфейсите им. Когато се избират компоненти, трябва да се взимат под внимание функционалните изисквания, нефункционалните изисквания и перспективата за еволюция на с-мата. Софтуерно инженерство 19 Slide 48
Скачать презентацию Софтуерен инженеринг базиран на компоненти Софтуерно инженерство 19
8970b311df62d63039dc6b543f0298f9.ppt