slide1
Download
Skip this Video
Download Presentation
Архитектурно проектиране

Loading in 2 Seconds...

play fullscreen
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
slide2
Цели
  • Да направи въведение в архитектурното проектиране и да се обсъди важността му
  • Да се обяснят архитектурните решения, които трябва да се вземат.
  • Да въведат три допълнителни архитектурни стила, които са за организацията, декомпозицията и управлението.
  • Да обсъди как специфични за предметната област референтни модели могат да се използват за сравняване на архитектурата на софтуера
slide3
Основни теми
  • Проектни решения за архитектурата
  • Организация на системата
  • Модели на декомпозиция
  • Модели на управление
  • Референтни модели
slide4
Софтуерна архитектура
  • Процесът на проектиране за определяне на подсистемите, които съставят системата и рамката на управление и комуникация се нарича архитектурно проектиране
  • Резултатът от този процес е описание на софтуерната архитектура
slide5
Архитектурно проектиране
  • Ранен етап на процеса на проектиране на с-мата
  • Представлява връзката м/у процесите на спецификация и проектиране
  • Често е паралелен на някои дейности от спецификацията
  • Извършва определянето на главните компоненти на с-мата и комуникацията м/у тях
slide6
Предимства на явната архитектура
  • Комуникация с поръчителите
    • Архитектурата може да бъде основа за дискусия с поръчителите
  • Анализ на системата
    • Анализ за това, дали е възможно системата да удовлетвори нефункционалните изисквания
  • Повторно използване
    • Архитектурата може да се използва повторно за голям кръг системи
slide7
Архитектура и системни характеристики
  • Ефективност
    • Да се съберат на едно място критичните операции и да се минимизират комуникациите. Да се използват едри компоненти.
  • Сигурност
    • Да се използва слоеста архитектура, като критичните елементи с във вътрешните слоеве.
  • Безопасност
    • Да се съберат критичните за безопасността елементи в малък брой подсистеми.
  • Достъпност
    • Да се предвидят резервни компоненти и механизми за преодоляване на грешки
  • Поддръжка
    • Да се използват малки компоненти, които могат да се заместват
slide8
Противоречия
  • Използването на едри компоненти подобрява ефективността и усложнява поддръжката
  • Включването на излишни данни подобрява достъпността, но усложнява поддържането на сигурността.
  • Събирането на критичните за безопасността елементи увеличава комуникациите и намалява ефективността.
slide9
Структуриране на системата
  • Занимава се с декомпозирането на системата в взаимодействащи подсистеми
  • Архитектурният проект обикновено се показва като блок-диаграма представляваща поглед в/у структурата на системата.
  • Могат да се разработят и по-специфични модели показващи, как подсистемите си поделят данните, са разпределени и взаимодействат помежду си.
slide10
Система за управление на пакетиращ робот
slide11
Блок диаграми
  • Много абстрактни – не показват естеството на отношенията м/у компонентите, нито външните свойства на подсистемите – не са за разработчици.
  • Обаче са полезни при разговорите с поръчителите и за планирането на процеса
slide12
Проектни решения
  • Архитектурното проектиране е творчески процес, така че много зависи от типа на разработваната система.
  • Обаче има решения общи за всички процеси на проектиране
slide13
Проектни решения...
  • Има ли типова архитектура, която може да се използва?
  • Как ще се разпредели системата?
  • Кой архитектурен стил е подходящ?
  • Кой подход ще се използва, за да се структурира системата?
  • Как ще се декомпозира на модули?
  • Каква стратегия за управление ще се използва?
  • Как ще се оценява архитектурния проект?
  • Как ще се документира архитектурата?
slide14
Повторно използване
  • В една област системите често имат подобна архитектура, която отразява особеностите на областта
  • Приложните продукти се изграждат около основна архитектура с варианти, които удовлетворяват изискванията на клиента.
slide15
Архитектурни стилове
  • Архитектурният модел на системата може да отговаря на типов архитектурен модел или стил.
  • Запознаването с тези стилове може да опрости проблема за дефиниране на системната архитектура.
  • По-големите системи са хетерогенни и не следват единствен стил.
slide16
Архитектурни модели
  • По време на процеса на проектиране могат да се създадат различни архитектурни модели.
  • Всеки модел представя различна перспектива на системата
slide17
Архитектурни модели
  • Използвате са за документиране на архитектурния проект:
    • Статичен структурен модел, който показва главните компоненти на системата
    • Динамичен модел на системата – структурата на рън-тайм процесите.
    • Интерфейсен модел – интерфейсите на подсистемите
    • Модел на отношенията – като модела на потоците от данни, който показват връзките м/у подсистемите
    • Модел на разпределението – показва как подсистемите се разпределят м/у компютрите.
slide18
Системна организация
  • Отразява базовата стратегия на структуриране на системата.
  • Широко се използват 3 организационни стила:
    • С поделено хранилище на данни
    • С поделени услуги и сървъри.
    • На абстрактна машина или на слоеве
slide19
Модел с общо хранилище
  • Подсистемите трябва да обменят данни. Това може да стане по 2 начина:
    • Поделените данни се намират в централна база от данни или хранилище.
    • Всяка подсистема поддържа собствена база от данни и предава явно данните на други подсистеми.
  • Когато трябва да се поделят големи количества данни, най-вече се използва този модел.
slide21
Характеристики на модела с хранилище
  • Предимства
    • Ефикасен начин за обмен на голямо количество данни
    • Няма нужда подсистемите да се занимават как се поддържат данните. Централизирано управление (бекъп, сигурност и др.)
    • Моделът на поделяне се представя като схема на хранилището
  • Недостатъци
    • Всички подсистеми използват един и същ модел на данните. Компромисът е неизбежен.
    • Еволюцията на данните е скъпа и трудна.
    • Няма място за специфични управленски политики,
    • Трудно се извършва ефикасно разпределение.
slide22
Модел клиент-сървър
  • Разпределен модел, който показва как данните и обработката се разпределят в цяла поредица от компоненти
  • Множество от самостоятелни сървъри, които осигуряват специфични услуги като печат, управление на данните и т.н.
  • Набор от клиенти, които извикват тези услуги
  • Мрежа, чрез която имадостъп досървърите
slide24
Характеристики на Клиент-сървър
  • Предимства
    • Разпространението на данните е просто и ясно
    • Ефективно използва мрежите. Може да изисква по-евтин хардуер.
    • Лесно е да се добави нов сървър или да се надстрои стар такъв
  • Недостатъци
    • Не е модел с поделени данни – всички подсистеми използват различна организация на данните. Обмена на данни може да е неефикасен
    • Излишни разходи за управление на всеки сървър
    • Няма централен регистър на имената и услугите – може да е трудно да се намери кои сървъри и услуги са достъпни
slide25
Модел на абстрактна машина (на слоеве)
  • Използва за моделиране на интерфейса между подсистемите
  • Организира системата в множество от слоеве (или абстрактни машини), всяка от които осигурява множество от услуги
  • Поддържа инкрементелна разработка на подсистемите от различните слоеве. Когато се променя интерфейсът на слой, засегнат е само съседният слой
  • Обаче, структурирането на системата е затруднено и малко изкуствено
slide27
Стилове за декомпозиция на модули
  • Стилове за декомпозиране на подсистемите на модули
  • Няма строга граница между организация на системата и модулна декомпозиция
slide28
Подсистеми и модули
  • Подсистемата е пълноправна система, чиято работа не зависи от услугите, доставяни от други подсистеми.
  • Модулът е системна компонента, която доставя услуги за други компоненти, но не може нормално да се разглежда като отделна система
slide29
Модулна декомпозиция
  • Друго структурно ниво, където подсистемите се декомпозират на модули
  • Два основни модела се разискват
    • Обектен модел, при който системата се декомпозира до взаимодействащи си обекти
    • Модел на потоците от данни, при който системата се декомпозира на функционални модули, които превръщат входните данни в изходни. Познат като модел на “тръбопровода”
  • Ако е възможно, решенията за конкурентност (паралелност) трябва да се отложат до осъществяването на модулите
slide30
Обектни модели
  • Структурира системата в хлабаво куплирани обекти с добре дефинирани интерфейси
  • Обектно-ориентираната декомпозиция се занимава с идентифициране на класовете от обекти, техните атрибути и операции
  • При осъществяването се създават обекти от тези класовете и се използва някой модел на управление, за да се координират операциите на обектите.
slide32
Предимства на обектния модел
  • Обектите са слабо куплирани, така че осъществяването им може да бъде променяно без да засягат други обекти
  • Обектите могат да отразяват същности от реалния свят.
  • Широко се използват ОО езици.
  • Обаче, промени в интерфейса на обектите могат да предизвикат проблеми и сложните обекти от реалния свят трудно се представят като информационни обекти.
slide33
Модели на потоците от данни (тръбопровод)
  • Функционални преобразования обработват техния вход и създават изхода
  • Може да се направи аналогия с модела на тръбопровод и филтър (UNIX shell)
  • Често се срещат варианти на този подход. Когато преобразованията са последователни, това е последователния пакетен (batch) модел, широко използван в системите за обработка на данни
  • Неподходящ за интерактивни системи
slide35
Предимства на модела на тръбопровода
  • Позволява повторното използване на трансформациите
  • Интуитивна организация за комуникация с поръчителите
  • Лесно е да се добави нова трансформация
  • Относително е лесно да се осъществи като последователна или конкурентна система.
  • Обаче, по целия тръбопровод се изисква общ формат на данните и трудно се поддържа взаимодействие основано на събития
slide36
Стилове на управление
  • Занимават се с управленските потоци между подсистемите. Различни от декомпозиционните модели
  • Централизирано управление
    • Една подсистема е изцяло отговорна за управлението и пуска и спира другите подсистеми
  • Управление базирано на събития
    • Всяка подсистема може да отговаря на външни събития генерирани от други подсистеми или от системното обкръжение
slide37
Централизирано управление
  • Управляваща подсистема е отговорна за управлението на изпълнението на другите подсистеми
  • Модел “Call-return”
    • Модел, в който главната в йерархията подпрограма управлява останалите по дървото като им предава управлението чрез извикване и го поема след изпълнението, Става само за последователни системи
  • Модел на мениджъра
    • Приложим за конкурентни системи. Една компонента управлява стартирането, спирането и координацията на другите системни процеси. Може да се прилага и за последователни процеси като case оператор
slide40
Системи управлявани от събития
  • Управляват се генерирани отвън събития, като управлението се предава на подсистемата, която обработва на събитието
  • Два основни модел
    • Модел на оповестяване (Broadcast). Събитието се разпространява до всички подсистеми. Коя да е система, която може да го обработи го прави
    • Управление с прекъсвания. Използват се в системите реално време. Прекъсването се открива от хендлър и се предава на някоя компонента, който го обработва.
slide41
Модел на оповестяване
  • Ефективен при интегриране на подсистеми разпределени в компютрите на мрежа
  • Подсистемата регистрира интерес към специфично събитие. Когато то настъпи, управлението се насочва към подсистемата, която може да го отработи
  • Политиката на управление не е вградена в събитието и в обработчика (handler) на съобщения, а в самата подсистема, която го обработва
  • Обаче, подсистемата не знае, кога ще се появи събитие, което трябва да се обработи
slide43
Системи управлявани с прекъсвания
  • Използват с в системите реално време, когато бързата реакция е съществена
  • Дефинирани са типове прекъсвания с хендлър за всеки тип прекъсване
  • Всеки тип е асоцииран с адрес в паметта и хардуерен ключ прехвърля управлението на съответния хендлър
  • Позволява бърза реакция, но е сложно да се програмира и валидира
slide45
Специфични архитектури
  • Архитектурни модели може да са специфични за дадена област на приложение
  • Два типа специфични модели
    • Типови модели, които са абстракции на голям брой реални системи и които отразяват основните характеристики на тези системи
    • Референтни модели, които са по-абстрактни, идеални модели. Те дават информация за този клас системи, стандарти за постигане
  • Типовите модели са обикновено модели създадени отдолу-нагоре, а референтните отгоре-надолу
slide46
Референтни архитектури
  • Референтният модел се извлича от изучаването на областта на приложение, а не от съществуващите системи
  • Може да бъде използван като основа за осъществяване на системата или за сравнение на различни системи. Действа като стандарт за оценка на системата
  • OSI моделът е модел на нивата на комуникационна система
slide48
CASE референтен модел
  • Услуги за съхранение на данните
    • Съхранение и управление на отделните данни
  • Услуги за интегриране на данните
    • Управление на групи от обекти
  • Услуги за управление на задачите
    • Дефиниция и осъществяване на моделите на процесите
  • Услуги по предаване на съобщения
    • комуникация м/у средствата и със обкръжението
  • Услуги за потребителския интерфейс
    • Разработка на потребителски интерфейс
slide50
Обобщение
  • Софтуерната архитектура е основната рамка за структуриране на системата
  • Проектните решенията са решения по архитектурата на приложението, по разпределението и за архитектурните стилове, които да се използват
  • Могат да се разработят различни архитектурни модели като структурен модел, модел ма управлението и декомпозиционен модел
  • Системните организационни модели са модел с хранилище, клиент-сървър и абстрактна машина.
slide51
Обобщение...
  • Модулните декомпозиционни модели са обектните модели и “тръбопровода”
  • Моделите на управлението са централизиран контрол и събитиен
  • Референтните архитектури могат да се използват за обсъждане на специфични за дадена област архитектури и за оценка и сравнение на архитектурни проекти.