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

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

2. Цели • Да покаже, че тази тема е свързана с разработката на стандартни компоненти и съчетаването им в приложения. • Да опише компонентите и моделите им • Да покаже основните действия в процеса CBSE • Да се обсъдят подходите при съчетаването на компонентите и проблемите, които могат да възникнат.

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

4. Разработка базирана на компоненти • CBSE е подход за разработка на софтуер, който почива на многократното използване. • Този подход е резултат от неуспеха на ОО разработването да поддържа многократното използване. Единичните класове са твърде подробни и специфични. • Компонентите са по абстрактни от класовете обекти и могат да се разглеждат като самостоятелни доставчици на услуги.

5. Съществени елементи на CBSE • Независими компонентиспецифицирани от интерфейсите си. • Стандарти за компонентитеза улеснение на интегрирането на компонентите. • Middleware– междинни компоненти, които осигуряват поддръжката на взаимодействието м/у компонентите • Процес на разработка, пригоден за проект на многократно използване

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

7. Проблеми при CBSE • Степен на доверие в компонентата– как може да се вярва в качествата на компонента без сорс код. • Сертифициране на компонентата– кой ще сертифицира качеството на компонентите? • Предвиждане на интегралните свойства– как ще се предскажат интегралните (emergent)свойства на взаимодействащите се компоненти? • Компромис на изискванията – как да анализираме баланса между възможностите на различни компоненти?

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

9. Дефиниции на компоненти • 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.

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

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

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

13. Интерфейси на компонентите • Изходен интерфейс (provides interface) Дефинира услугите, които се доставят чрез интерфейса от компонентата към други компоненти. • Входен интерфейс (requires interface) Дефинира услугите, които трябва да са достъпни, за да може компонентата да работи според спецификацията.

14. Интерфейси на компонентите Входен интерфейс Изходен интерфейс Дефинира услугите, доставяни от компонентата Дефинира услугите от обкръжението на компонентата, които тя използва Component

15. Компонента за събиране на данни Requires int er face Provides int er face addSensor removeSensor sensorManagement star tSensor Data collector stopSensor testSensor sensorData initialise repor t listAll

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

17. Компонентен модел • Това е дефиниция на стандарти за реализация, документация и предаване на компонентите. • Примери на компонентни модели • EJB model (Enterprise Java Beans) • COM+ model (.NET model) • Corba Component Model • Компонентният модел специфицира, как трябва да се дефинира интерфейсът и елементите, които трябва да се включат в тази дефиниция.

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

19. Поддържащи системи • Компонентният модел е основа за система, която осигурява поддръжката на изпълняваните компоненти. • Тези системи осигуряват: • Платформени услуги, които позволяват компоненти написани съгласно модела да комуникират помежду си. • Хоризонтални услуги – независими от приложението услуги, използвани от различните компоненти • За да използват услугите на модела, компонентите се оформят в контейнер. Това е набор от интерфейси, използвани за достъп до реализацията на услугите на модела и за достъп на услугите на компонентата от други компоненти.

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

21. Разработка на компоненти за многократно използване • За да се пригодят за многократно използване, компонентите, които са разработени за специфично приложение, се нуждаят от обобщаване. • Една компонента е по-пригодна за многократно използване, ако е свързана със стабилна абстракция на областта на приложение (бизнес обекта). • Например, за една болница, стабилните абстракции са свързани с основното предназначение – сестри, пациенти, лечение и др.

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

23. Промени правени за многократно използване. • Премахват се специфичните методи • Променят се имената с по-общи. • Добавят се методи за да се разшири приложението. • Обработката на изключенията се прави последователна. • Добавя се конфигурационен интерфейс за адаптация • Интегриране на изискваните компоненти, за да се намали зависимостта.

24. Компоненти от наследени с-ми • Съществуващи с-ми, които изпълняват полезни бизнес функции могат да се препакетират като компоненти за многократно използване. • Това предполага написването на обгръщаща (wrapper) компонента, която реализира интерфейсите на наследената с-ма. • Макар и скъпо, това може и да много по-евтино отколкото пренаписването на наследената с-ма.

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

26. Процесът на CBSE • Когато се използват готови компоненти, е съществено да се направи компромис м/у идеалните изисквания и услугите доставяни от разполагаемите компоненти. • Това включва: • Разработка на предварителни изисквания; • Търсене на компоненти и след това промяна на изискванията в съответствие със съществуващата функционалност. • Ново търсене на по-добри компоненти удовлетворяващи новите изисквания.

27. Процесът на CBSE

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

29. Въпроси на идентификацията на компонентите • Доверие.Трябва да се има доверие на доставчика на компонентата. В най-добрия случай калпавата компонента няма да работи както е в рекламата, а в най-лошия ще пробие сигурността. • Изисквания. Различни групи от компоненти удовлетворяват различни изисквания. • Валидиране • Спецификацията на компонентата може де не е достатъчно подробна, за да се разработят добри тестове. • Компонентите могат да имат нежелана функционалност. как може да се тества дали тя няма да влияе на конкретното приложение?

30. Провалът при изстрелването на Ariane • През 1996 г. се провали първият опит за изстрелване на Ariane 5, когато софтуерът на изстрелването излезе от контрол 37 сек. след началото. • Проблемът беше в използвана от предишна версия компонента ((the Inertial Navigation System), която отказа, защото предположенията, при които беше разработвана компонентата не бяха верни за Ariane 5. • Функционалността, която беше причина за срива, не се изискваше за Ariane 5.

31. Сглобяване на компонентите • Процес на събиране на компонентите за създаване на действаща с-ма. • То включва интегриране на компонентите една с друга и с инфраструктурата. • Нормално трябва да се пише "свързващ код" (glue code), за да се свържат компонентите.

32. Типове на сглобяване • Последователно, при което компонентите се изпълнява последователно. Това предполага сглобяване на изходните интерфейси на всяка компонента. • Йерархично,при което една компонента извиква услугите на друга. Изходният интерфейс на едната компонента се сглобява с входния интерфейс на другата. • Адитивна,когато интерфейсите на 2 компоненти се събират за създаването на нова компонента.

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

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

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

36. Компоненти - адаптери • Служат за решаване на проблема на несъвместимостта като съгласуват интерфейсите, които трябва да се сглобят. • За различните типове сглобяване са нужни различни типове адаптери. • addressFinder и mapper могат да се сглобят чрез адаптер, който извлича пощенския код от един адрес и го подава на компонентата mapper.

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

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

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

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

41. Документация на Photo Library “This method adds a photograph to the library and associates the photograph identifier and catalogue descriptor with the photograph.” "какво се случва ако идентификаторът е вече асоцииран със снимка в библиотеката?" "дали описанието на снимката е асоциирано кактос каталога, така и със самата снимка, т.е. ако изтрия снимката, ще изтрия ли и информацията в каталога?"

42. Object Constraint Language(OCL) • Object Constraint Language е проектиран да дефинира ограниченията асоциирани с UML моделите. • Основава се на понятието за спецификация пре и пост условията – подобно на езика Z.

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

44. Условия за фото-библиотеката • Както е показано OCL асоцииран с компонентата Photo Library казва,че: • Не може да има снимка в библиотеката със същия идентификатор както на тази, която се добавя; • Библиотеката трябва да съществува – предполага се, че със създаването на библиотеката се добавя един елемент; • Всеки добавен елемент увеличава размера на библиотеката с 1 • Ако извличате, като използвате същия идентификатор, ще получите снимката, която сте добавили; • Ако търсите в каталога, използвайки същия идентификатор, ще намерите елемента, който сте създали.

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

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

47. Обобщение • CBSE е подход, основан на многократното използване и на съчетаването на слабо свързани компоненти в с-ми. • Компонента е софтуерна единица, чиято функционалност и зависимост са напълно определени от интерфейсите й. • Един компонентен модел дефинира набор стандарти, които трябва да се следват от доставчиците и създателите на с-ми. • По време на CBSE процеса, процесите на инженеринга на изискванията и на проектирането на с-мата се припокриват.

48. Обобщение • Композирането на с-мата е процес на "навързване" на компонентите, за да се създаде с-ма • Когато се сглобяват готови компоненти, обикновено трябва да се пишат адаптери, които съгласуват интерфейсите им. • Когато се избират компоненти, трябва да се взимат под внимание функционалните изисквания, нефункционалните изисквания и перспективата за еволюция на с-мата.