1. Многократно използване

2. Цели
Да обясни ползите от многократното използване (МИ) и някои проблеми при него
Да обсъди различните начини за реализация на МИ
Да обясни как понятията в МИ могат да се използват като модели или да се вградят в програмни генератори.
Да се обсъди МИ на COTS
Да се опише разработката на софтуерни продуктови фамилии (product lines)

3. Основни теми Обща картина Модели (Design patterns)
МИ основано на генератори
Приложни работни рамки (frameworks)
МИ на приложни с-ми

4. МИ на софтуера
В повечето инженерни дисциплини с-мите се проектират като се сглобяват съществуващи компоненти, използвани в други с-ми.
Отначало софтуерното инженерство се е съсредоточавало в/у оригинални проекти, но сега се признава, че за да се получи по-добър софтуер, по-бързо и по-евтино, ние се нуждаем от проектен процес основан на систематично МИ.

5. СИ основано на МИ МИ на приложни с-ми МИ на компоненти
Една цяла приложна с-ма може да се използва без промяна в други с-ми (COTS) или чрез разработка на фамилии приложения
МИ на компоненти
Могат да се използват компоненти с размер от подс-ми до отделни обекти (разгл. по-късно)
МИ на обекти и функции
Могат да се използват софтуерни компоненти, които реализират добре отделен дефиниран обект или функция.

6. Ползи от МИ 1

7. Ползи от МИ 2

8. Проблеми при МИ 1

9. Проблеми при МИ 2

10. Различни подходи към МИ
Въпреки че МИ често се разглежда като просто използване на компоненти, има много различни подходи към използването на МИ.
МИ е възможно на много нива от прости функции до цели приложни с-ми.

11. Различни подходи към МИ

12. Подходи 1

13. Подходи 2

14. Фактори при планиране на МИ
Разписанието за разработка на софтуера.
Очакваното време на живот на софтуера
Произходът, уменията и опита на екипа.
Критичността на софтуера и нефункционалните изисквания.
Областта на приложение
Платформата, на която ще се изпълнява софтуера.

15. Концептуално МИ
Когато използвате програмни или проектни компоненти, трябва да следвате проектните решения, направени от първоначалния разработчик на компонента.
Това може да ограничи възможностите за МИ
По-абстрактна форма на МИ е концептуалното МИ, когато се описва даден подход по начин предполагащ независимо осъществяване и след това се разработва последното.
Два основни подхода за концептуално МИ са:
Проектни модели (Design patterns)
Генериране на програми

16. Проектни модели
Проектният модел е начин да се използва абстрактното знание за проблема и решението му.
Моделът е описание на програмата и същността на решението
Той трябва да е достатъчно абстрактен, за да може да се използва в различни ситуации.
Моделите често се основават на обектни характеристики като наследяване и полиморфизъм.

17. Елементи на моделите Име Описание на модела Описание на решението
Смислен идентификатор на модела
Описание на модела
Описание на решението
Не конкретен проект, а модел за проектно решение, което може да бъде реализирано по различни начини.
Последствия
Резултатите и компромисите при прилагането на модела.

18. Многобройни представяния

19. Модел на наблюдателя Име Описание Описание на проблема
Observer.
Описание
Разделя представянето на обекта от самия обект
Описание на проблема
Нужен, когато са нужни няколко представяния на състоянието
Описание на решението
Виж UML слайда
Последствия
Не е практично да се оптимизира производителността на представянето.

20. Модел Observer

21. МИ основано на програмна генерация
Програмните генератори включват МИ на стандартни модели и алгоритми.
Последните са вградени в генератора и се параметризират чрез команди на потребителя. След това програмата се генерира автоматично
Този подход е възможен, когато могат да се определят абстракциите на областта и тяхното съответствие в като програмен код.
Използва се специфичен за областта език за съставяне и управление на тези абстракции.

22. Типове програмни генератори
Генератори на приложения за обработка на бизнес данни.
Синтактичен и лексичен анализатори за програмни езици
Код генератори в CASE средствата
Този подход е много евтин, но използването му е ограничено до сравнително малък брой области на приложение.
Това е по-лесен начин за крайния потребител за разработка сравнен с другите основани на компоненти методи за МИ.

23. МИ чрез генериране на програми

24. Аспектно ориентирана разработка
Този подход решава един голям проблем – разделянето на грижите.
Грижите са не просто свързани с функционалността на приложението, но и преминават границите на компонентите “напречно” – напр. Всички компоненти трябва да следят собствените си операции, всички компоненти могат да поддържат сигурността и др.
Тези “напречни” грижи се реализират като аспекти и динамично се втъкават в програмата. Кодът се използва многократно и новата с-ма се генерира от аспектния генератор (weaver).

25. Аспектно ориентирана разработка

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

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

28. Разширяване на работните рамки
Рамките са обобщени и се разширяват, за да се създават по-специфични приложения или под-с-ми.
Разширяването включва:
Добавяне на конкретни класове, които наследяват абстрактните класове в рамката
Добавяне на методи, които се извикват като реакции на събития, разпознавани от с-мата.
Недостатък на работната рамка е сложността й, което значи, че нужно много време, за да може да се използва ефективно.

29. Model-view controller
Работна рамка за с-мна инфраструктура – GUI проект
Позволява много представяния на един обект и взаимодействия с тези представяния.
MVC рамката включва конкретизацията на няколко модела ( като се обсъждаше по-рано при концептулното МИ).

30. Model-view-controller

31. МИ на приложни с-ми
Включва използването на цяло приложение било чрез конфигуриране на с-мата за дадена среда, било чрез интегриране на 2 или повече с-ми за създаване на ново приложение.
Има 2 подхода
Интегриране на COTS продукти
Разработка на продуктова фамилия

32. МИ на COTS продукти COTS - Commercial Off-The-Shelf systems.
COTS с-мите са обикновено завършени приложения, които предлагат API (Application Programming Interface).
Изграждането на големи с-ми чрез интегриране на COTS с-ми е обещаваща стратегия за някои типове софтуер като електронна търговия.
Основни ползи са по-бързата разработка и обикновено по-ниските разходи за нея.

33. Избори при COTS проектирането
Може да има няколко подобни продукта
Как ще се обменят данните?
Отделните продукти използват собствени структура и формат на данните.
Кои качества на продукта ще се използват?
Повечето продукти имат повече от нужните функции. Вие трябва да откажете достъпа до ненужните функции.

34. Система за Е-доставки

35. Използвани COTS продукти
От страната на клиента – стандартни програми за ел. поща и браузер.
На съсрвъра една платформа за електронна търговия трябва да се интегрира със съществуваща система за поръчване
Трябва да се напише адаптер, така че те да могат да обменят данни.
Също трябва да се интегрира с-ма, за да генерира съобщения за клиентите. Това също изисква адаптер, за да се приемат данни от с-мата за поръчки и фактуриране.

36. Проблеми при интегриране на COTS с-ми
Липса на контрол над функционалността и ефективността
COTS с-мите може да са по-неефективни отколкото изглеждат
Проблеми с взаимодействието
Различните COTS може да правят различни предположения, което затруднява интегрирането
Няма контрол в/у еволюцията на с-мата
Разработчиците на COTS, а не клиентите управляват еволюцията
Поддръжка от продавачите на COTS
Продавачите може да не предлагат поддръжка за целия живот на с-мата.

37. Продуктови фамилии
Софтуерните продуктови фамилии са приложения с обобщена функционалност, които могат да се адаптират и конфигурират за употреба в специален контекст
Адаптирането може да включи:
Конфигурация на с-мата и компонентите
Добавяне на нова компонента
Избор от библиотека на съществуващи компоненти
Промяна на компоненти, за да отговорят на нови изисквания

38. Специализация на COTS продукти
Според платформата
За различни платформи се разработват различни версии на приложението
Според средата
Различни версии се разработват, за да оперират в различна операционна среда, напр. различно комуникационно оборудване
Според функционалността
Създават се различни версии за клиенти с различни изисквания
Според процеса
Създават се различни версии да поддържат различни бизнес процеси

39. Конфигуриране на COTS Конфигурация по време на доставката
Обобщената с-ма се конфигурира чрез вграждане на знание за клиентските изисквания. Софтуерът не се променя
Конфигурация по време на проектирането
Адаптира се и се променя общия код в зависимост от изискванията на даден клиент.

40. Организация на ERP с-ма

41. ERP системи
С-ма за планиране на ресурсите на предприятието (ERP) е обобщена с-ма, която поддържа общи бизнес процеси като поръчки и фактуриране, производство и др.
Тези с-ми широко се използват в големи компании – представляват може би най-използваната форма на МИ на софтуер
Обобщеният код се адаптира, като се включват модули и като се вгражда знание за бизнес процесите и правилата.

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

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

44. С-ма за управление на ресурсите

45. Диспечиране на коли
Специализирана с-ма за разпределение на ресурсите, където целта да се определят ресурси (коли), за да се справят с произшествията.
Адаптациите включват:
На ниво потр. интерфейс има компоненти за дисплей комуникации на оператора.
На ниво I/O има компоненти, които се грижат за автентикацията, отчитането и планирането на маршрутите.
На ниво управление на ресурсите има компоненти за определяне на местоположението на колите и разпределението им, управление на статуса им и дневник на произшествията.
Базата от данни включва оборудване, коли и база от карти.

46. Диспечерска с-ма

47. Разработка на конкретен продукт

48. Разработка на конкретен продукт
Извличане на изискванията на поръчителите
За прототип се използва съществуващ член от фамилията
Избор на най-подходящия член от фамилията
Открива се членът, който най-добре отговаря на изискванията
Предоговаряне на изискванията
Адаптиране на изискванията, ако е необходимо към възможностите на с-мата
Адаптиране на съществуващата с-ма
Разработват се нови модули и се правят промени в члена от фамилията
Доставка на новия член от фамилията
Документират се новите особености за по-нататъшно развитие на члена.

49. Обобщение
Предимствата на МИ са по-ниските разходи, по-бързата разработка и по-ниските рискове
Проектните модели са абстракции от високо ниво, документират успешни проектни решения.
Програмните генератори също се занимават с МИ – използваемите концепти са вградени в генераторната с-ма
Програмните работни рамки са колекции от конкретни и абстрактни обекти, които проектирани за МИ чрез специализация.

50. Обобщение
МИ на COTS продукти е свързано с използването на големи, закупени с-ми
Проблемите с МИ на COTS са свързани контрол в/у функционалността, ефективността и еволюцията и с взаимодействието
ERP с-мите се създават чрез конфигуриране обобщена с-ма с информация за бизнеса на клиента
Софтуерните продуктови фамилии са сродни приложения с общо ядро от споделена функционалност.