Скачать презентацию Софтуерен инженеринг базиран на компоненти Софтуерно инженерство 19 Скачать презентацию Софтуерен инженеринг базиран на компоненти Софтуерно инженерство 19

8970b311df62d63039dc6b543f0298f9.ppt

  • Количество слайдов: 48

Софтуерен инженеринг базиран на компоненти Софтуерно инженерство 19 Slide 1 Софтуерен инженеринг базиран на компоненти Софтуерно инженерство 19 Slide 1

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

Теми l l Компоненти и модели на компоненти Процесът на CBSE Съчетаване на компоненти Теми l l Компоненти и модели на компоненти Процесът на CBSE Съчетаване на компоненти Component composition Софтуерно инженерство 19 Slide 3

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

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

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

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

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

Дефиниции на компоненти l Councill and Heinmann: • l A software component is a Дефиниции на компоненти 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 Компонентата е независима изпълнима единица. Не е Компонентата като доставчик на услуги l l Компонентата е независима изпълнима единица. Не е нужно да се компилира преди да се използва с други компоненти. Всички предлагани услуги са достъпни през интерфейс и всички взаимодействия с компонентата се извършват през този интерфейс. Софтуерно инженерство 19 Slide 10

Характеристики на компонентите 1 Софтуерно инженерство 19 Slide 11 Характеристики на компонентите 1 Софтуерно инженерство 19 Slide 11

Характеристики на компонентите 2 Софтуерно инженерство 19 Slide 12 Характеристики на компонентите 2 Софтуерно инженерство 19 Slide 12

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

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

Компонента за събиране на данни Requires int erface Provides int rface e sensor. Management Компонента за събиране на данни 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 Компонентите са самостоятелни, готови за предаване единици. Компонентите Компоненти и обекти l l l Компонентите са самостоятелни, готови за предаване единици. Компонентите не дефинират типове Реализацията на компонентите е скрита. Компонентите са независими от езика. Компонентите са стандартизирани. Софтуерно инженерство 19 Slide 16

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

Елементи на компонентен модел Софтуерно инженерство 19 Slide 18 Елементи на компонентен модел Софтуерно инженерство 19 Slide 18

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

Услуги на компонентния модел Софтуерно инженерство 19 Slide 20 Услуги на компонентния модел Софтуерно инженерство 19 Slide 20

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

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

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

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

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

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

Процесът на CBSE Софтуерно инженерство 19 Slide 27 Процесът на CBSE Софтуерно инженерство 19 Slide 27

Процес на идентификация на компонентите Софтуерно инженерство 19 Slide 28 Процес на идентификация на компонентите Софтуерно инженерство 19 Slide 28

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

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

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

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

Типове на сглобяване Софтуерно инженерство 19 Slide 33 Типове на сглобяване Софтуерно инженерство 19 Slide 33

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

Несъвместими компоненти Софтуерно инженерство 19 Slide 35 Несъвместими компоненти Софтуерно инженерство 19 Slide 35

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

Сглобяване чрез адаптер l Компонентата post. Code. Stripper е адаптер, който улеснява последователната композиция Сглобяване чрез адаптер l Компонентата post. Code. Stripper е адаптер, който улеснява последователната композиция на компонентите address. Finder и mapper. Софтуерно инженерство 19 Slide 37

Адаптер за компонентата за събиране на данни Софтуерно инженерство 19 Slide 38 Адаптер за компонентата за събиране на данни Софтуерно инженерство 19 Slide 38

Семантика на интерфейса l l За да решите, дали съвместими по синтаксис интерфейси са Семантика на интерфейса l l За да решите, дали съвместими по синтаксис интерфейси са действително съвместими, вие трябва да разчитате на документацията. Да разгледаме интерфейс на компонента Photo. Library Софтуерно инженерство 19 Slide 39

Сглобяване на Photo library Софтуерно инженерство 19 Slide 40 Сглобяване на Photo library Софтуерно инженерство 19 Slide 40

Документация на Photo Library “This method adds a photograph to the library and associates Документация на 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 е проектиран да дефинира ограниченията Object Constraint Language (OCL) l l Object Constraint Language е проектиран да дефинира ограниченията асоциирани с UML моделите. Основава се на понятието за спецификация пре и пост условията – подобно на езика Z. Софтуерно инженерство 19 Slide 42

Формално описание на фотобиблиотеката Софтуерно инженерство 19 Slide 43 Формално описание на фотобиблиотеката Софтуерно инженерство 19 Slide 43

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

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

Събиране на данни и генериране на отчети Софтуерно инженерство 19 Slide 46 Събиране на данни и генериране на отчети Софтуерно инженерство 19 Slide 46

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

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