Архитектурно проектиране

1. Архитектурно проектиране

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

3. Основни теми • Проектни решения за архитектурата • Организация на системата • Модели на декомпозиция • Модели на управление • Референтни модели

4. Софтуерна архитектура • Процесът на проектиране за определяне на подсистемите, които съставят системата и рамката на управление и комуникация се нарича архитектурно проектиране • Резултатът от този процес е описание на софтуерната архитектура

5. Архитектурно проектиране • Ранен етап на процеса на проектиране на с-мата • Представлява връзката м/у процесите на спецификация и проектиране • Често е паралелен на някои дейности от спецификацията • Извършва определянето на главните компоненти на с-мата и комуникацията м/у тях

6. Предимства на явната архитектура • Комуникация с поръчителите • Архитектурата може да бъде основа за дискусия с поръчителите • Анализ на системата • Анализ за това, дали е възможно системата да удовлетвори нефункционалните изисквания • Повторно използване • Архитектурата може да се използва повторно за голям кръг системи

7. Архитектура и системни характеристики • Ефективност • Да се съберат на едно място критичните операции и да се минимизират комуникациите. Да се използват едри компоненти. • Сигурност • Да се използва слоеста архитектура, като критичните елементи с във вътрешните слоеве. • Безопасност • Да се съберат критичните за безопасността елементи в малък брой подсистеми. • Достъпност • Да се предвидят резервни компоненти и механизми за преодоляване на грешки • Поддръжка • Да се използват малки компоненти, които могат да се заместват

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

9. Структуриране на системата • Занимава се с декомпозирането на системата в взаимодействащи подсистеми • Архитектурният проект обикновено се показва като блок-диаграма представляваща поглед в/у структурата на системата. • Могат да се разработят и по-специфични модели показващи, как подсистемите си поделят данните, са разпределени и взаимодействат помежду си.

10. Система за управление на пакетиращ робот

11. Блок диаграми • Много абстрактни – не показват естеството на отношенията м/у компонентите, нито външните свойства на подсистемите – не са за разработчици. • Обаче са полезни при разговорите с поръчителите и за планирането на процеса

12. Проектни решения • Архитектурното проектиране е творчески процес, така че много зависи от типа на разработваната система. • Обаче има решения общи за всички процеси на проектиране

13. Проектни решения... • Има ли типова архитектура, която може да се използва? • Как ще се разпредели системата? • Кой архитектурен стил е подходящ? • Кой подход ще се използва, за да се структурира системата? • Как ще се декомпозира на модули? • Каква стратегия за управление ще се използва? • Как ще се оценява архитектурния проект? • Как ще се документира архитектурата?

14. Повторно използване • В една област системите често имат подобна архитектура, която отразява особеностите на областта • Приложните продукти се изграждат около основна архитектура с варианти, които удовлетворяват изискванията на клиента.

15. Архитектурни стилове • Архитектурният модел на системата може да отговаря на типов архитектурен модел или стил. • Запознаването с тези стилове може да опрости проблема за дефиниране на системната архитектура. • По-големите системи са хетерогенни и не следват единствен стил.

16. Архитектурни модели • По време на процеса на проектиране могат да се създадат различни архитектурни модели. • Всеки модел представя различна перспектива на системата

17. Архитектурни модели • Използвате са за документиране на архитектурния проект: • Статичен структурен модел, който показва главните компоненти на системата • Динамичен модел на системата – структурата на рън-тайм процесите. • Интерфейсен модел – интерфейсите на подсистемите • Модел на отношенията – като модела на потоците от данни, който показват връзките м/у подсистемите • Модел на разпределението – показва как подсистемите се разпределят м/у компютрите.

18. Системна организация • Отразява базовата стратегия на структуриране на системата. • Широко се използват 3 организационни стила: • С поделено хранилище на данни • С поделени услуги и сървъри. • На абстрактна машина или на слоеве

19. Модел с общо хранилище • Подсистемите трябва да обменят данни. Това може да стане по 2 начина: • Поделените данни се намират в централна база от данни или хранилище. • Всяка подсистема поддържа собствена база от данни и предава явно данните на други подсистеми. • Когато трябва да се поделят големи количества данни, най-вече се използва този модел.

20. Архитектура на CASE комплект

21. Характеристики на модела с хранилище • Предимства • Ефикасен начин за обмен на голямо количество данни • Няма нужда подсистемите да се занимават как се поддържат данните. Централизирано управление (бекъп, сигурност и др.) • Моделът на поделяне се представя като схема на хранилището • Недостатъци • Всички подсистеми използват един и същ модел на данните. Компромисът е неизбежен. • Еволюцията на данните е скъпа и трудна. • Няма място за специфични управленски политики, • Трудно се извършва ефикасно разпределение.

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

23. Библиотека за филми и снимки

24. Характеристики на Клиент-сървър • Предимства • Разпространението на данните е просто и ясно • Ефективно използва мрежите. Може да изисква по-евтин хардуер. • Лесно е да се добави нов сървър или да се надстрои стар такъв • Недостатъци • Не е модел с поделени данни – всички подсистеми използват различна организация на данните. Обмена на данни може да е неефикасен • Излишни разходи за управление на всеки сървър • Няма централен регистър на имената и услугите – може да е трудно да се намери кои сървъри и услуги са достъпни

25. Модел на абстрактна машина (на слоеве) • Използва за моделиране на интерфейса между подсистемите • Организира системата в множество от слоеве (или абстрактни машини), всяка от които осигурява множество от услуги • Поддържа инкрементелна разработка на подсистемите от различните слоеве. Когато се променя интерфейсът на слой, засегнат е само съседният слой • Обаче, структурирането на системата е затруднено и малко изкуствено

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

27. Стилове за декомпозиция на модули • Стилове за декомпозиране на подсистемите на модули • Няма строга граница между организация на системата и модулна декомпозиция

28. Подсистеми и модули • Подсистемата е пълноправна система, чиято работа не зависи от услугите, доставяни от други подсистеми. • Модулът е системна компонента, която доставя услуги за други компоненти, но не може нормално да се разглежда като отделна система

29. Модулна декомпозиция • Друго структурно ниво, където подсистемите се декомпозират на модули • Два основни модела се разискват • Обектен модел, при който системата се декомпозира до взаимодействащи си обекти • Модел на потоците от данни, при който системата се декомпозира на функционални модули, които превръщат входните данни в изходни. Познат като модел на “тръбопровода” • Ако е възможно, решенията за конкурентност (паралелност) трябва да се отложат до осъществяването на модулите

30. Обектни модели • Структурира системата в хлабаво куплирани обекти с добре дефинирани интерфейси • Обектно-ориентираната декомпозиция се занимава с идентифициране на класовете от обекти, техните атрибути и операции • При осъществяването се създават обекти от тези класовете и се използва някой модел на управление, за да се координират операциите на обектите.

31. Система за обработка на фактури

32. Предимства на обектния модел • Обектите са слабо куплирани, така че осъществяването им може да бъде променяно без да засягат други обекти • Обектите могат да отразяват същности от реалния свят. • Широко се използват ОО езици. • Обаче, промени в интерфейса на обектите могат да предизвикат проблеми и сложните обекти от реалния свят трудно се представят като информационни обекти.

33. Модели на потоците от данни (тръбопровод) • Функционални преобразования обработват техния вход и създават изхода • Може да се направи аналогия с модела на тръбопровод и филтър (UNIX shell) • Често се срещат варианти на този подход. Когато преобразованията са последователни, това е последователния пакетен (batch) модел, широко използван в системите за обработка на данни • Неподходящ за интерактивни системи

34. Система за обработка на фактури

35. Предимства на модела на тръбопровода • Позволява повторното използване на трансформациите • Интуитивна организация за комуникация с поръчителите • Лесно е да се добави нова трансформация • Относително е лесно да се осъществи като последователна или конкурентна система. • Обаче, по целия тръбопровод се изисква общ формат на данните и трудно се поддържа взаимодействие основано на събития

36. Стилове на управление • Занимават се с управленските потоци между подсистемите. Различни от декомпозиционните модели • Централизирано управление • Една подсистема е изцяло отговорна за управлението и пуска и спира другите подсистеми • Управление базирано на събития • Всяка подсистема може да отговаря на външни събития генерирани от други подсистеми или от системното обкръжение

37. Централизирано управление • Управляваща подсистема е отговорна за управлението на изпълнението на другите подсистеми • Модел “Call-return” • Модел, в който главната в йерархията подпрограма управлява останалите по дървото като им предава управлението чрез извикване и го поема след изпълнението, Става само за последователни системи • Модел на мениджъра • Приложим за конкурентни системи. Една компонента управлява стартирането, спирането и координацията на другите системни процеси. Може да се прилага и за последователни процеси като case оператор

38. Модел “Call-return”

39. Управление на система в реално време

40. Системи управлявани от събития • Управляват се генерирани отвън събития, като управлението се предава на подсистемата, която обработва на събитието • Два основни модел • Модел на оповестяване (Broadcast). Събитието се разпространява до всички подсистеми. Коя да е система, която може да го обработи го прави • Управление с прекъсвания. Използват се в системите реално време. Прекъсването се открива от хендлър и се предава на някоя компонента, който го обработва.

41. Модел на оповестяване • Ефективен при интегриране на подсистеми разпределени в компютрите на мрежа • Подсистемата регистрира интерес към специфично събитие. Когато то настъпи, управлението се насочва към подсистемата, която може да го отработи • Политиката на управление не е вградена в събитието и в обработчика (handler) на съобщения, а в самата подсистема, която го обработва • Обаче, подсистемата не знае, кога ще се появи събитие, което трябва да се обработи

42. Селективно оповестяване

43. Системи управлявани с прекъсвания • Използват с в системите реално време, когато бързата реакция е съществена • Дефинирани са типове прекъсвания с хендлър за всеки тип прекъсване • Всеки тип е асоцииран с адрес в паметта и хардуерен ключ прехвърля управлението на съответния хендлър • Позволява бърза реакция, но е сложно да се програмира и валидира

44. Управление с прекъсвания

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

46. Референтни архитектури • Референтният модел се извлича от изучаването на областта на приложение, а не от съществуващите системи • Може да бъде използван като основа за осъществяване на системата или за сравнение на различни системи. Действа като стандарт за оценка на системата • OSI моделът е модел на нивата на комуникационна система

47. OSI модел

48. CASE референтен модел • Услуги за съхранение на данните • Съхранение и управление на отделните данни • Услуги за интегриране на данните • Управление на групи от обекти • Услуги за управление на задачите • Дефиниция и осъществяване на моделите на процесите • Услуги по предаване на съобщения • комуникация м/у средствата и със обкръжението • Услуги за потребителския интерфейс • Разработка на потребителски интерфейс

49. ECMA референтен модел

50. Обобщение • Софтуерната архитектура е основната рамка за структуриране на системата • Проектните решенията са решения по архитектурата на приложението, по разпределението и за архитектурните стилове, които да се използват • Могат да се разработят различни архитектурни модели като структурен модел, модел ма управлението и декомпозиционен модел • Системните организационни модели са модел с хранилище, клиент-сървър и абстрактна машина.