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

Software Engineering, 7th edition. Chapter 11 Slide 1

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


Цели

Да направи въведение в архитектурното проектиране и да се обсъди важността му

Да се обяснят архитектурните решения, които трябва да се вземат.

Да въведат три допълнителни архитектурни стила, които са за организацията, декомпозицията и управлението.

Да обсъди как специфични за предметната област референтни модели могат да се използват за сравняване на архитектурата на софтуера


Основни теми

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


Софтуерна архитектура

Процесът на проектиране за определяне на подсистемите, които съставят системата и рамката на управление и комуникация се нарича архитектурно проектиране

Резултатът от този процес е описание на софтуерната архитектура


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

Ранен етап на процеса на проектиране на с-мата

Представлява връзката м/у процесите на спецификация и проектиране

Често е паралелен на някои дейности от спецификацията

Извършва определянето на главните компоненти на с-мата и комуникацията м/у тях


Предимства на явната архитектура

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

дискусия с поръчителите Анализ на системата

• Анализ за това, дали е възможно системата да удовлетвори нефункционалните изисквания

Повторно използване• Архитектурата може да се използва

повторно за голям кръг системи


Архитектура и системни характеристики

Ефективност• Да се съберат на едно място критичните операции и да се

минимизират комуникациите. Да се използват едри компоненти. Сигурност

• Да се използва слоеста архитектура, като критичните елементи с във вътрешните слоеве.

Безопасност• Да се съберат критичните за безопасността елементи в малък

брой подсистеми. Достъпност

• Да се предвидят резервни компоненти и механизми за преодоляване на грешки

Поддръжка• Да се използват малки компоненти, които могат да се заместват


Противоречия

Използването на едри компоненти подобрява ефективността и усложнява поддръжката

Включването на излишни данни подобрява достъпността, но усложнява поддържането на сигурността.

Събирането на критичните за безопасността елементи увеличава комуникациите и намалява ефективността.


Структуриране на системата

Занимава се с декомпозирането на системата в взаимодействащи подсистеми

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

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


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

Система зазрение

Система заидентиф икация

на обекти

Система заизбор на

пакет

Система запакетиране Контролер

наконвейра

Контролерна хващ ача

Контролерна ръката


Блок диаграми

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

Обаче са полезни при разговорите с поръчителите и за планирането на процеса


Проектни решения

Архитектурното проектиране е творчески процес, така че много зависи от типа на разработваната система.

Обаче има решения общи за всички процеси на проектиране


Проектни решения...

Има ли типова архитектура, която може да се използва?

Как ще се разпредели системата? Кой архитектурен стил е подходящ? Кой подход ще се използва, за да се структурира

системата? Как ще се декомпозира на модули? Каква стратегия за управление ще се използва? Как ще се оценява архитектурния проект? Как ще се документира архитектурата?


Повторно използване

В една област системите често имат подобна архитектура, която отразява особеностите на областта

Приложните продукти се изграждат около основна архитектура с варианти, които удовлетворяват изискванията на клиента.


Архитектурни стилове

Архитектурният модел на системата може да отговаря на типов архитектурен модел или стил.

Запознаването с тези стилове може да опрости проблема за дефиниране на системната архитектура.

По-големите системи са хетерогенни и не следват единствен стил.


Архитектурни модели

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

Всеки модел представя различна перспектива на системата


Архитектурни модели

Използвате са за документиране на архитектурния проект:• Статичен структурен модел, който показва главните

компоненти на системата• Динамичен модел на системата – структурата на рън-

тайм процесите.• Интерфейсен модел – интерфейсите на подсистемите• Модел на отношенията – като модела на потоците от

данни, който показват връзките м/у подсистемите• Модел на разпределението – показва как

подсистемите се разпределят м/у компютрите.


Системна организация

Отразява базовата стратегия на структуриране на системата.

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


Модел с общо хранилище

Подсистемите трябва да обменят данни. Това може да стане по 2 начина:• Поделените данни се намират в централна

база от данни или хранилище.• Всяка подсистема поддържа собствена база

от данни и предава явно данните на други подсистеми.

Когато трябва да се поделят големи количества данни, най-вече се използва този модел.


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

П роектенредактор

Хранилищ е на проекта

Анализаторна проект

Генераторна отчети

Транслаторна проект

Програменредактор

Кодгенератор


Характеристики на модела с хранилище

Предимства• Ефикасен начин за обмен на голямо количество

данни• Няма нужда подсистемите да се занимават как се

поддържат данните. Централизирано управление (бекъп, сигурност и др.)

• Моделът на поделяне се представя като схема на хранилището

Недостатъци• Всички подсистеми използват един и същ модел на

данните. Компромисът е неизбежен.• Еволюцията на данните е скъпа и трудна.• Няма място за специфични управленски политики,• Трудно се извършва ефикасно разпределение.


Модел клиент-сървър

Разпределен модел, който показва как данните и обработката се разпределят в цяла поредица от компоненти

Множество от самостоятелни сървъри, които осигуряват специфични услуги като печат, управление на данните и т.н.

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


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

Клиент 2

Ш ироколентова W EB мрежа

Клиент 1 Клиент 4Клиент 3

Каталоженсървър

Каталог

Видео сървър

Ф айлове склипове

Ф ото сървър

Ф айлове сдигитални

снимки

Хипертекстсървър

ХипертекстW EB


Характеристики на Клиент-сървър

Предимства• Разпространението на данните е просто и ясно• Ефективно използва мрежите. Може да изисква по-

евтин хардуер.• Лесно е да се добави нов сървър или да се надстрои

стар такъв Недостатъци

• Не е модел с поделени данни – всички подсистеми използват различна организация на данните. Обмена на данни може да е неефикасен

• Излишни разходи за управление на всеки сървър• Няма централен регистър на имената и услугите –

може да е трудно да се намери кои сървъри и услуги са достъпни


Модел на абстрактна машина (на слоеве)

Използва за моделиране на интерфейса между подсистемите

Организира системата в множество от слоеве (или абстрактни машини), всяка от които осигурява множество от услуги

Поддържа инкрементелна разработка на подсистемите от различните слоеве. Когато се променя интерфейсът на слой, засегнат е само съседният слой

Обаче, структурирането на системата е затруднено и малко изкуствено


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

Configuration management system layer

Database system layer

Operating system layer

Object management system layer


Стилове за декомпозиция на модули

Стилове за декомпозиране на подсистемите на модули

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


Подсистеми и модули

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

Модулът е системна компонента, която доставя услуги за други компоненти, но не може нормално да се разглежда като отделна система


Модулна декомпозиция

Друго структурно ниво, където подсистемите се декомпозират на модули

Два основни модела се разискват• Обектен модел, при който системата се декомпозира

до взаимодействащи си обекти• Модел на потоците от данни, при който системата се

декомпозира на функционални модули, които превръщат входните данни в изходни. Познат като модел на “тръбопровода”

Ако е възможно, решенията за конкурентност (паралелност) трябва да се отложат до осъществяването на модулите


Обектни модели

Структурира системата в хлабаво куплирани обекти с добре дефинирани интерфейси

Обектно-ориентираната декомпозиция се занимава с идентифициране на класовете от обекти, техните атрибути и операции

При осъществяването се създават обекти от тези класовете и се използва някой модел на управление, за да се координират операциите на обектите.


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

Фактура

Фактура #ДатаСумаКлиент

ИздаванеИзпр.напомнянеприемане плащанеДаване разписка

Клиент

Клиент#ИмеАдресПериод на кредита

Плащане

Фактура#ДатаСумаКлиент#

Разписка

Фактура#ДатаСумаКлиент#


Предимства на обектния модел

Обектите са слабо куплирани, така че осъществяването им може да бъде променяно без да засягат други обекти

Обектите могат да отразяват същности от реалния свят.

Широко се използват ОО езици. Обаче, промени в интерфейса на обектите могат

да предизвикат проблеми и сложните обекти от реалния свят трудно се представят като информационни обекти.


Модели на потоците от данни (тръбопровод)

Функционални преобразования обработват техния вход и създават изхода

Може да се направи аналогия с модела на тръбопровод и филтър (UNIX shell)

Често се срещат варианти на този подход. Когато преобразованията са последователни, това е последователния пакетен (batch) модел, широко използван в системите за обработка на данни

Неподходящ за интерактивни системи


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

Четене наф актура

Идентиф ициране наплащ ане

И здаванена разписка

Издаванена

напомняне

Н амиране напредстоящ о

плащ ане

Фактури Плащ ания

Разписки

Н апомняния


Предимства на модела на тръбопровода

Позволява повторното използване на трансформациите

Интуитивна организация за комуникация с поръчителите

Лесно е да се добави нова трансформация Относително е лесно да се осъществи като

последователна или конкурентна система. Обаче, по целия тръбопровод се изисква общ

формат на данните и трудно се поддържа взаимодействие основано на събития


Стилове на управление

Занимават се с управленските потоци между подсистемите. Различни от декомпозиционните модели

Централизирано управление• Една подсистема е изцяло отговорна за управлението

и пуска и спира другите подсистеми Управление базирано на събития

• Всяка подсистема може да отговаря на външни събития генерирани от други подсистеми или от системното обкръжение


Централизирано управление Управляваща подсистема е отговорна за

управлението на изпълнението на другите подсистеми

Модел “Call-return” • Модел, в който главната в йерархията подпрограма

управлява останалите по дървото като им предава управлението чрез извикване и го поема след изпълнението, Става само за последователни системи

Модел на мениджъра• Приложим за конкурентни системи. Една компонента

управлява стартирането, спирането и координацията на другите системни процеси. Може да се прилага и за последователни процеси като case оператор


Модел “Call-return”

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


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

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses


Системи управлявани от събития

Управляват се генерирани отвън събития, като управлението се предава на подсистемата, която обработва на събитието

Два основни модел• Модел на оповестяване (Broadcast). Събитието се

разпространява до всички подсистеми. Коя да е система, която може да го обработи го прави

• Управление с прекъсвания. Използват се в системите реално време. Прекъсването се открива от хендлър и се предава на някоя компонента, който го обработва.


Модел на оповестяване Ефективен при интегриране на подсистеми

разпределени в компютрите на мрежа Подсистемата регистрира интерес към

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

Политиката на управление не е вградена в събитието и в обработчика (handler) на съобщения, а в самата подсистема, която го обработва

Обаче, подсистемата не знае, кога ще се появи събитие, което трябва да се обработи


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

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


Системи управлявани с прекъсвания

Използват с в системите реално време, когато бързата реакция е съществена

Дефинирани са типове прекъсвания с хендлър за всеки тип прекъсване

Всеки тип е асоцииран с адрес в паметта и хардуерен ключ прехвърля управлението на съответния хендлър

Позволява бърза реакция, но е сложно да се програмира и валидира


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

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector


Специфични архитектури

Архитектурни модели може да са специфични за дадена област на приложение

Два типа специфични модели• Типови модели, които са абстракции на голям брой

реални системи и които отразяват основните характеристики на тези системи

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

Типовите модели са обикновено модели създадени отдолу-нагоре, а референтните отгоре-надолу


Референтни архитектури

Референтният модел се извлича от изучаването на областта на приложение, а не от съществуващите системи

Може да бъде използван като основа за осъществяване на системата или за сравнение на различни системи. Действа като стандарт за оценка на системата

OSI моделът е модел на нивата на комуникационна система


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


CASE референтен модел

Услуги за съхранение на данните• Съхранение и управление на отделните данни

Услуги за интегриране на данните• Управление на групи от обекти

Услуги за управление на задачите• Дефиниция и осъществяване на моделите на

процесите Услуги по предаване на съобщения

• комуникация м/у средствата и със обкръжението Услуги за потребителския интерфейс

• Разработка на потребителски интерфейс


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

Toolslots

Messageservices

Task management servicesUser interface services

Data repository servicesData integration services


Обобщение

Софтуерната архитектура е основната рамка за структуриране на системата

Проектните решенията са решения по архитектурата на приложението, по разпределението и за архитектурните стилове, които да се използват

Могат да се разработят различни архитектурни модели като структурен модел, модел ма управлението и декомпозиционен модел

Системните организационни модели са модел с хранилище, клиент-сървър и абстрактна машина.


Обобщение...

Модулните декомпозиционни модели са обектните модели и “тръбопровода”

Моделите на управлението са централизиран контрол и събитиен

Референтните архитектури могат да се използват за обсъждане на специфични за дадена област архитектури и за оценка и сравнение на архитектурни проекти.

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

Documents