Архитектурно проектиране
Download
1 / 51

Архитектурно проектиране - PowerPoint PPT Presentation


  • 125 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Архитектурно проектиране' - julie


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Цели

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

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

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

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


Основни теми

  • Проектни решения за архитектурата

  • Организация на системата

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

  • Модели на управление

  • Референтни модели


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

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

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


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

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

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

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

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


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

  • Комуникация с поръчителите

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

  • Анализ на системата

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

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

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


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

  • Ефективност

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

  • Сигурност

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

  • Безопасност

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

  • Достъпност

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

  • Поддръжка

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


Противоречия характеристики

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

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

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


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

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

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

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


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


Блок диаграми пакетиращ робот

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

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


Проектни решения пакетиращ робот

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

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


Проектни решения... пакетиращ робот

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

  • Как ще се разпредели системата?

  • Кой архитектурен стил е подходящ?

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

  • Как ще се декомпозира на модули?

  • Каква стратегия за управление ще се използва?

  • Как ще се оценява архитектурния проект?

  • Как ще се документира архитектурата?


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

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

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


Архитектурни стилове пакетиращ робот

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

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

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


Архитектурни модели пакетиращ робот

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

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


Архитектурни модели пакетиращ робот

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

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

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

    • Интерфейсен модел – интерфейсите на подсистемите

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

    • Модел на разпределението – показва как подсистемите се разпределят м/у компютрите.


Системна организация пакетиращ робот

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

  • Широко се използват 3 организационни стила:

    • С поделено хранилище на данни

    • С поделени услуги и сървъри.

    • На абстрактна машина или на слоеве


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

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

    • Поделените данни се намират в централна база от данни или хранилище.

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

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


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


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

  • Предимства

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

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

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

  • Недостатъци

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

    • Еволюцията на данните е скъпа и трудна.

    • Няма място за специфични управленски политики,

    • Трудно се извършва ефикасно разпределение.


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

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

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

  • Набор от клиенти, които извикват тези услуги

  • Мрежа, чрез която имадостъп досървърите



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

  • Предимства

    • Разпространението на данните е просто и ясно

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

    • Лесно е да се добави нов сървър или да се надстрои стар такъв

  • Недостатъци

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

    • Излишни разходи за управление на всеки сървър

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


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

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

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

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

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



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

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

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


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

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

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


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

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

  • Два основни модела се разискват

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

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

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


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

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

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

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



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

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

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

  • Широко се използват ОО езици.

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


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

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

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

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

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



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

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

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

  • Лесно е да се добави нова трансформация

  • Относително е лесно да се осъществи като последователна или конкурентна система.

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


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

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

  • Централизирано управление

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

  • Управление базирано на събития

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


Централизирано управление тръбопровода

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

  • Модел “Call-return”

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

  • Модел на мениджъра

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


Call return
Модел “ тръбопроводаCall-return”



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

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

  • Два основни модел

    • Модел на оповестяване (Broadcast). Събитието се разпространява до всички подсистеми. Коя да е система, която може да го обработи го прави

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


Модел на оповестяване време

  • Ефективен при интегриране на подсистеми разпределени в компютрите на мрежа

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

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

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



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

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

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

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

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



Специфични архитектури прекъсвания

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

  • Два типа специфични модели

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

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

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


Референтни архитектури прекъсвания

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

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

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


OSI прекъсваниямодел


CASE прекъсванияреферентен модел

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

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

  • Услуги за интегриране на данните

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

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

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

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

    • комуникация м/у средствата и със обкръжението

  • Услуги за потребителския интерфейс

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


ECMA прекъсванияреферентен модел


Обобщение прекъсвания

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

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

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

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


Обобщение... прекъсвания

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

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

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


ad