Software Engineering, 7th edition. Chapter 11 Slide 1 Архитектурно проектиране
Feb 14, 2016
Software Engineering, 7th edition. Chapter 11 Slide 1
Архитектурно проектиране
Software Engineering, 7th edition. Chapter 11 Slide 2
Цели
Да направи въведение в архитектурното проектиране и да се обсъди важността му
Да се обяснят архитектурните решения, които трябва да се вземат.
Да въведат три допълнителни архитектурни стила, които са за организацията, декомпозицията и управлението.
Да обсъди как специфични за предметната област референтни модели могат да се използват за сравняване на архитектурата на софтуера
Software Engineering, 7th edition. Chapter 11 Slide 3
Основни теми
Проектни решения за архитектурата Организация на системата Модели на декомпозиция Модели на управление Референтни модели
Software Engineering, 7th edition. Chapter 11 Slide 4
Софтуерна архитектура
Процесът на проектиране за определяне на подсистемите, които съставят системата и рамката на управление и комуникация се нарича архитектурно проектиране
Резултатът от този процес е описание на софтуерната архитектура
Software Engineering, 7th edition. Chapter 11 Slide 5
Архитектурно проектиране
Ранен етап на процеса на проектиране на с-мата
Представлява връзката м/у процесите на спецификация и проектиране
Често е паралелен на някои дейности от спецификацията
Извършва определянето на главните компоненти на с-мата и комуникацията м/у тях
Software Engineering, 7th edition. Chapter 11 Slide 6
Предимства на явната архитектура
Комуникация с поръчителите• Архитектурата може да бъде основа за
дискусия с поръчителите Анализ на системата
• Анализ за това, дали е възможно системата да удовлетвори нефункционалните изисквания
Повторно използване• Архитектурата може да се използва
повторно за голям кръг системи
Software Engineering, 7th edition. Chapter 11 Slide 7
Архитектура и системни характеристики
Ефективност• Да се съберат на едно място критичните операции и да се
минимизират комуникациите. Да се използват едри компоненти. Сигурност
• Да се използва слоеста архитектура, като критичните елементи с във вътрешните слоеве.
Безопасност• Да се съберат критичните за безопасността елементи в малък
брой подсистеми. Достъпност
• Да се предвидят резервни компоненти и механизми за преодоляване на грешки
Поддръжка• Да се използват малки компоненти, които могат да се заместват
Software Engineering, 7th edition. Chapter 11 Slide 8
Противоречия
Използването на едри компоненти подобрява ефективността и усложнява поддръжката
Включването на излишни данни подобрява достъпността, но усложнява поддържането на сигурността.
Събирането на критичните за безопасността елементи увеличава комуникациите и намалява ефективността.
Software Engineering, 7th edition. Chapter 11 Slide 9
Структуриране на системата
Занимава се с декомпозирането на системата в взаимодействащи подсистеми
Архитектурният проект обикновено се показва като блок-диаграма представляваща поглед в/у структурата на системата.
Могат да се разработят и по-специфични модели показващи, как подсистемите си поделят данните, са разпределени и взаимодействат помежду си.
Software Engineering, 7th edition. Chapter 11 Slide 10
Система за управление на пакетиращ робот
Система зазрение
Система заидентиф икация
на обекти
Система заизбор на
пакет
Система запакетиране Контролер
наконвейра
Контролерна хващ ача
Контролерна ръката
Software Engineering, 7th edition. Chapter 11 Slide 11
Блок диаграми
Много абстрактни – не показват естеството на отношенията м/у компонентите, нито външните свойства на подсистемите – не са за разработчици.
Обаче са полезни при разговорите с поръчителите и за планирането на процеса
Software Engineering, 7th edition. Chapter 11 Slide 12
Проектни решения
Архитектурното проектиране е творчески процес, така че много зависи от типа на разработваната система.
Обаче има решения общи за всички процеси на проектиране
Software Engineering, 7th edition. Chapter 11 Slide 13
Проектни решения...
Има ли типова архитектура, която може да се използва?
Как ще се разпредели системата? Кой архитектурен стил е подходящ? Кой подход ще се използва, за да се структурира
системата? Как ще се декомпозира на модули? Каква стратегия за управление ще се използва? Как ще се оценява архитектурния проект? Как ще се документира архитектурата?
Software Engineering, 7th edition. Chapter 11 Slide 14
Повторно използване
В една област системите често имат подобна архитектура, която отразява особеностите на областта
Приложните продукти се изграждат около основна архитектура с варианти, които удовлетворяват изискванията на клиента.
Software Engineering, 7th edition. Chapter 11 Slide 15
Архитектурни стилове
Архитектурният модел на системата може да отговаря на типов архитектурен модел или стил.
Запознаването с тези стилове може да опрости проблема за дефиниране на системната архитектура.
По-големите системи са хетерогенни и не следват единствен стил.
Software Engineering, 7th edition. Chapter 11 Slide 16
Архитектурни модели
По време на процеса на проектиране могат да се създадат различни архитектурни модели.
Всеки модел представя различна перспектива на системата
Software Engineering, 7th edition. Chapter 11 Slide 17
Архитектурни модели
Използвате са за документиране на архитектурния проект:• Статичен структурен модел, който показва главните
компоненти на системата• Динамичен модел на системата – структурата на рън-
тайм процесите.• Интерфейсен модел – интерфейсите на подсистемите• Модел на отношенията – като модела на потоците от
данни, който показват връзките м/у подсистемите• Модел на разпределението – показва как
подсистемите се разпределят м/у компютрите.
Software Engineering, 7th edition. Chapter 11 Slide 18
Системна организация
Отразява базовата стратегия на структуриране на системата.
Широко се използват 3 организационни стила: • С поделено хранилище на данни • С поделени услуги и сървъри.• На абстрактна машина или на слоеве
Software Engineering, 7th edition. Chapter 11 Slide 19
Модел с общо хранилище
Подсистемите трябва да обменят данни. Това може да стане по 2 начина:• Поделените данни се намират в централна
база от данни или хранилище.• Всяка подсистема поддържа собствена база
от данни и предава явно данните на други подсистеми.
Когато трябва да се поделят големи количества данни, най-вече се използва този модел.
Software Engineering, 7th edition. Chapter 11 Slide 20
Архитектура на CASE комплект
П роектенредактор
Хранилищ е на проекта
Анализаторна проект
Генераторна отчети
Транслаторна проект
Програменредактор
Кодгенератор
Software Engineering, 7th edition. Chapter 11 Slide 21
Характеристики на модела с хранилище
Предимства• Ефикасен начин за обмен на голямо количество
данни• Няма нужда подсистемите да се занимават как се
поддържат данните. Централизирано управление (бекъп, сигурност и др.)
• Моделът на поделяне се представя като схема на хранилището
Недостатъци• Всички подсистеми използват един и същ модел на
данните. Компромисът е неизбежен.• Еволюцията на данните е скъпа и трудна.• Няма място за специфични управленски политики,• Трудно се извършва ефикасно разпределение.
Software Engineering, 7th edition. Chapter 11 Slide 22
Модел клиент-сървър
Разпределен модел, който показва как данните и обработката се разпределят в цяла поредица от компоненти
Множество от самостоятелни сървъри, които осигуряват специфични услуги като печат, управление на данните и т.н.
Набор от клиенти, които извикват тези услуги Мрежа, чрез която има достъп до сървърите
Software Engineering, 7th edition. Chapter 11 Slide 23
Библиотека за филми и снимки
Клиент 2
Ш ироколентова W EB мрежа
Клиент 1 Клиент 4Клиент 3
Каталоженсървър
Каталог
Видео сървър
Ф айлове склипове
Ф ото сървър
Ф айлове сдигитални
снимки
Хипертекстсървър
ХипертекстW EB
Software Engineering, 7th edition. Chapter 11 Slide 24
Характеристики на Клиент-сървър
Предимства• Разпространението на данните е просто и ясно• Ефективно използва мрежите. Може да изисква по-
евтин хардуер.• Лесно е да се добави нов сървър или да се надстрои
стар такъв Недостатъци
• Не е модел с поделени данни – всички подсистеми използват различна организация на данните. Обмена на данни може да е неефикасен
• Излишни разходи за управление на всеки сървър• Няма централен регистър на имената и услугите –
може да е трудно да се намери кои сървъри и услуги са достъпни
Software Engineering, 7th edition. Chapter 11 Slide 25
Модел на абстрактна машина (на слоеве)
Използва за моделиране на интерфейса между подсистемите
Организира системата в множество от слоеве (или абстрактни машини), всяка от които осигурява множество от услуги
Поддържа инкрементелна разработка на подсистемите от различните слоеве. Когато се променя интерфейсът на слой, засегнат е само съседният слой
Обаче, структурирането на системата е затруднено и малко изкуствено
Software Engineering, 7th edition. Chapter 11 Slide 26
Система за управление на версиите
Configuration management system layer
Database system layer
Operating system layer
Object management system layer
Software Engineering, 7th edition. Chapter 11 Slide 27
Стилове за декомпозиция на модули
Стилове за декомпозиране на подсистемите на модули
Няма строга граница между организация на системата и модулна декомпозиция
Software Engineering, 7th edition. Chapter 11 Slide 28
Подсистеми и модули
Подсистемата е пълноправна система, чиято работа не зависи от услугите, доставяни от други подсистеми.
Модулът е системна компонента, която доставя услуги за други компоненти, но не може нормално да се разглежда като отделна система
Software Engineering, 7th edition. Chapter 11 Slide 29
Модулна декомпозиция
Друго структурно ниво, където подсистемите се декомпозират на модули
Два основни модела се разискват• Обектен модел, при който системата се декомпозира
до взаимодействащи си обекти• Модел на потоците от данни, при който системата се
декомпозира на функционални модули, които превръщат входните данни в изходни. Познат като модел на “тръбопровода”
Ако е възможно, решенията за конкурентност (паралелност) трябва да се отложат до осъществяването на модулите
Software Engineering, 7th edition. Chapter 11 Slide 30
Обектни модели
Структурира системата в хлабаво куплирани обекти с добре дефинирани интерфейси
Обектно-ориентираната декомпозиция се занимава с идентифициране на класовете от обекти, техните атрибути и операции
При осъществяването се създават обекти от тези класовете и се използва някой модел на управление, за да се координират операциите на обектите.
Software Engineering, 7th edition. Chapter 11 Slide 31
Система за обработка на фактури
Фактура
Фактура #ДатаСумаКлиент
ИздаванеИзпр.напомнянеприемане плащанеДаване разписка
Клиент
Клиент#ИмеАдресПериод на кредита
Плащане
Фактура#ДатаСумаКлиент#
Разписка
Фактура#ДатаСумаКлиент#
Software Engineering, 7th edition. Chapter 11 Slide 32
Предимства на обектния модел
Обектите са слабо куплирани, така че осъществяването им може да бъде променяно без да засягат други обекти
Обектите могат да отразяват същности от реалния свят.
Широко се използват ОО езици. Обаче, промени в интерфейса на обектите могат
да предизвикат проблеми и сложните обекти от реалния свят трудно се представят като информационни обекти.
Software Engineering, 7th edition. Chapter 11 Slide 33
Модели на потоците от данни (тръбопровод)
Функционални преобразования обработват техния вход и създават изхода
Може да се направи аналогия с модела на тръбопровод и филтър (UNIX shell)
Често се срещат варианти на този подход. Когато преобразованията са последователни, това е последователния пакетен (batch) модел, широко използван в системите за обработка на данни
Неподходящ за интерактивни системи
Software Engineering, 7th edition. Chapter 11 Slide 34
Система за обработка на фактури
Четене наф актура
Идентиф ициране наплащ ане
И здаванена разписка
Издаванена
напомняне
Н амиране напредстоящ о
плащ ане
Фактури Плащ ания
Разписки
Н апомняния
Software Engineering, 7th edition. Chapter 11 Slide 35
Предимства на модела на тръбопровода
Позволява повторното използване на трансформациите
Интуитивна организация за комуникация с поръчителите
Лесно е да се добави нова трансформация Относително е лесно да се осъществи като
последователна или конкурентна система. Обаче, по целия тръбопровод се изисква общ
формат на данните и трудно се поддържа взаимодействие основано на събития
Software Engineering, 7th edition. Chapter 11 Slide 36
Стилове на управление
Занимават се с управленските потоци между подсистемите. Различни от декомпозиционните модели
Централизирано управление• Една подсистема е изцяло отговорна за управлението
и пуска и спира другите подсистеми Управление базирано на събития
• Всяка подсистема може да отговаря на външни събития генерирани от други подсистеми или от системното обкръжение
Software Engineering, 7th edition. Chapter 11 Slide 37
Централизирано управление Управляваща подсистема е отговорна за
управлението на изпълнението на другите подсистеми
Модел “Call-return” • Модел, в който главната в йерархията подпрограма
управлява останалите по дървото като им предава управлението чрез извикване и го поема след изпълнението, Става само за последователни системи
Модел на мениджъра• Приложим за конкурентни системи. Една компонента
управлява стартирането, спирането и координацията на другите системни процеси. Може да се прилага и за последователни процеси като case оператор
Software Engineering, 7th edition. Chapter 11 Slide 38
Модел “Call-return”
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
Software Engineering, 7th edition. Chapter 11 Slide 39
Управление на система в реално време
Systemcontroller
Userinterface
Faulthandler
Computationprocesses
Actuatorprocesses
Sensorprocesses
Software Engineering, 7th edition. Chapter 11 Slide 40
Системи управлявани от събития
Управляват се генерирани отвън събития, като управлението се предава на подсистемата, която обработва на събитието
Два основни модел• Модел на оповестяване (Broadcast). Събитието се
разпространява до всички подсистеми. Коя да е система, която може да го обработи го прави
• Управление с прекъсвания. Използват се в системите реално време. Прекъсването се открива от хендлър и се предава на някоя компонента, който го обработва.
Software Engineering, 7th edition. Chapter 11 Slide 41
Модел на оповестяване Ефективен при интегриране на подсистеми
разпределени в компютрите на мрежа Подсистемата регистрира интерес към
специфично събитие. Когато то настъпи, управлението се насочва към подсистемата, която може да го отработи
Политиката на управление не е вградена в събитието и в обработчика (handler) на съобщения, а в самата подсистема, която го обработва
Обаче, подсистемата не знае, кога ще се появи събитие, което трябва да се обработи
Software Engineering, 7th edition. Chapter 11 Slide 42
Селективно оповестяване
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
Software Engineering, 7th edition. Chapter 11 Slide 43
Системи управлявани с прекъсвания
Използват с в системите реално време, когато бързата реакция е съществена
Дефинирани са типове прекъсвания с хендлър за всеки тип прекъсване
Всеки тип е асоцииран с адрес в паметта и хардуерен ключ прехвърля управлението на съответния хендлър
Позволява бърза реакция, но е сложно да се програмира и валидира
Software Engineering, 7th edition. Chapter 11 Slide 44
Управление с прекъсвания
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Interrupts
Interruptvector
Software Engineering, 7th edition. Chapter 11 Slide 45
Специфични архитектури
Архитектурни модели може да са специфични за дадена област на приложение
Два типа специфични модели• Типови модели, които са абстракции на голям брой
реални системи и които отразяват основните характеристики на тези системи
• Референтни модели, които са по-абстрактни, идеални модели. Те дават информация за този клас системи, стандарти за постигане
Типовите модели са обикновено модели създадени отдолу-нагоре, а референтните отгоре-надолу
Software Engineering, 7th edition. Chapter 11 Slide 46
Референтни архитектури
Референтният модел се извлича от изучаването на областта на приложение, а не от съществуващите системи
Може да бъде използван като основа за осъществяване на системата или за сравнение на различни системи. Действа като стандарт за оценка на системата
OSI моделът е модел на нивата на комуникационна система
Software Engineering, 7th edition. Chapter 11 Slide 47
OSI модел
Presentation
Session
Transport
Network
Data link
Physical
7
6
5
4
3
2
1
Communications medium
Network
Data link
Physical
Application
Presentation
Session
Transport
Network
Data link
Physical
Application
Software Engineering, 7th edition. Chapter 11 Slide 48
CASE референтен модел
Услуги за съхранение на данните• Съхранение и управление на отделните данни
Услуги за интегриране на данните• Управление на групи от обекти
Услуги за управление на задачите• Дефиниция и осъществяване на моделите на
процесите Услуги по предаване на съобщения
• комуникация м/у средствата и със обкръжението Услуги за потребителския интерфейс
• Разработка на потребителски интерфейс
Software Engineering, 7th edition. Chapter 11 Slide 49
ECMA референтен модел
Toolslots
Messageservices
Task management servicesUser interface services
Data repository servicesData integration services
Software Engineering, 7th edition. Chapter 11 Slide 50
Обобщение
Софтуерната архитектура е основната рамка за структуриране на системата
Проектните решенията са решения по архитектурата на приложението, по разпределението и за архитектурните стилове, които да се използват
Могат да се разработят различни архитектурни модели като структурен модел, модел ма управлението и декомпозиционен модел
Системните организационни модели са модел с хранилище, клиент-сървър и абстрактна машина.
Software Engineering, 7th edition. Chapter 11 Slide 51
Обобщение...
Модулните декомпозиционни модели са обектните модели и “тръбопровода”
Моделите на управлението са централизиран контрол и събитиен
Референтните архитектури могат да се използват за обсъждане на специфични за дадена област архитектури и за оценка и сравнение на архитектурни проекти.