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

Слайд 1

СОФТУЕРНО
ИНЖЕНЕРСТВО
СОФТУЕРНИ АРХИТЕКТУРИ

Слайд 2

СОФТУЕРНИ АРХИТЕКТУРИ
Софтуерната архитектура е абстрактно описание на:
- Набора от важни решения за организиране на системата;
- Избора на конструктивни елементи и техните интерфейси - как системата се декомпозира до подсистеми (модули);
- Взаимодействията между отделните конструктивни елементи;
- Рамката на управление и комуникация в системата;
- Платформите и използваните технологии;
- Архитектурния стил, който ръководи организацията на системата.

Слайд 3

СОФТУЕРНИ АРХИТЕКТУРИ
Могат да се обобщят следните характеристики на софтуерната архитектура:
- Ефективност – обобщават се критичните операции и се минимизират комуникациите;
- Сигурност – при използване на слоеста архитектура, критичните елементи се поставят на по-вътрешните слоеве;
- Яснота - Архитектурата може да бъде основа за дискусия с клиентите;
- Поддръжка - при използване на малки компоненти, те могат да се заместват и актуализират без това да нарушава работоспособността на цялата система.

Слайд 4

СОФТУЕРНИ АРХИТЕКТУРИ

Архитектурното проектиране е творчески процес и решенията зависят от типа на разработваната система.
В практиката на софтуерното инже-нерство са се наложили множество шаблони за софтуерни архитектури, които са подходящо решение за определен клас проблеми/нужди. Всеки от тези шаблони има както предимства, така и недостатъци, и при проектирането на софтуерен продукт трябва да се прецени коя архитектура е най-подходяща за конкретния случай.

Слайд 5

СОФТУЕРНИ АРХИТЕКТУРИ

Клиент-сървър архитектура (Client-Server)
Това е разпределена архитектура, при която системата е разделена на един или повече сървъри и множество клиенти, следователно е нехомогенна. Сървърът предоставя определени услуги на клиентите. Клиентите инициират връзката със сървъра. При по-сложните системи е възможно едно звено едновременно да бъде клиент за едни звена и сървър за други.

Слайд 6

СОФТУЕРНИ АРХИТЕКТУРИ

Трислойна архитектура (Three-Tier)
Системата е разделена на три слоя – за данни, бизнес и презентационен. Всеки слой е изолиран от реализацията на останалите. По този начин се минимизира ефектът от промени в реализацията на някой от слоевете.

Слайд 7

ТРИСЛОЙНА АРХИТЕКТУРА
За повечето уеб приложения могат да се обособят три типа функционалност:
- представяне на информация на потребителя и взаимодействие с него;
-обработка, която реализира логиката на приложението;
- управление на данните.
Трислойната архитектура много често се използва за представяне на уеб приложения. Трите типа функционалност са разделени съответно в три логически слоя: презентационен слой (front-end), бизнес слой (middle tier) и съхранение на данните (back-end).

Слайд 8

ТРИСЛОЙНА АРХИТЕКТУРА
На клиентския слой се осъществява комуникацията между клиента и уеб приложението. В него от една страна се обработва информацията получена от потребителя и се предоставя за по-нататъшна обработка, а от друга – по подходящ начин на екрана се извежда създадената от приложението информация в уеб браузера.
Най-важният слой е средния слой – бизнес логиката, в който се намират функции за обработка на входно-изходната информация както за клиента, така и за данните от третото ниво. Това се осъществява с уеб сървър, който обработва и генерира динамично съдържание.
На третия слой са системите за управление на БД. Слоят за съхранение на данни (back-end) е отговорен за достъпа и съхранението на данните, като той извършва операциите с базата от данни.

Слайд 9

ТРИСЛОЙНА АРХИТЕКТУРА
Предимства на трислойния модел
Основното предимство на този модел е разделянето на трите типа функционалност. Това обособяване позволява промяна в някой от трите слоя да не окаже влияние върху останалите. Например, ако се промени бизнес логиката, изменение ще се наложи само във втория слой, като това не трябва да се отрази на работата с данните или представянето на информацията на потребителя.
Друго предимство е голямата скалируемост и по-малкото натоварване на клиента, тъй като той само визуализира данните, а логиката е изнесена в бизнес слоя, което дава възможност за лесно отстраняване на проблеми и обновяване само на бизнес слоя.
Друго предимство е възможността да имаме различни типове клиенти, използващи един и същ бизнес слой. Например едно приложение може да е достъпно едновременно през настолен клиент или мобилен.

Слайд 10

ТРИСЛОЙНА АРХИТЕКТУРА
Недостатъци на трислойния модел
Обикновено функционалността на отделните слоеве (без потребителския интерфейс) се изпълнява от различни сървъри. Например бизнес логиката може да е на сървър за приложения, а съхранението и достъпът до данните да се извършва от друг сървър. Това може да създаде проблеми при евентуални неизправности и/или външни влияния.
Друг проблем е намаляването на производителността заради нуждата от комуникация между слоевете - трябва да се осигурят надеждни механизми за комуникация между слоевете и да се предвидят проблемите при изчезване на свързаността между тях.

Слайд 11

СОФТУЕРНИ АРХИТЕКТУРИ

Многослойна архитектура (n-Tier)
Подобно на трислойната архитектура, системата е разделена на множество слоеве с цел локализиране на отговорността и промените. Няма ограничение за броя на слоевете.

Слайд 12

МНОГОСЛОЙНА АРХИТЕКТУРА

Предимства на многослойна архитектура (n-Tier)
- Позволява разпределяне на натоварването посредством физическо разпределение на слоевете;
-Позволява употребата на различни технологии;
-Слоевете са тънки, независими, следователно лесни за поддръжка и развитие;
- Лесно проследяване на транзакциите и проблемите свързани с тях.

Слайд 13

СОФТУЕРНИ АРХИТЕКТУРИ
Изглед (View) - тази част от изходния код на приложението, отговорна за показването на данните от модела. Например изгледът може да се състои от PHP шаблони, JSP страници, ASP страници и др.
Контролер - тази част от сорс кода, която взима данните от модела или извиква допълнителни методи върху модела, предварително обработва данните, и чак след това ги дава на изгледа. Контролерът извиква определена команда и/или променя определени данни на Модела. Контролерът също така решава кой Изглед ще се използва за визуализирането на Модела.
Модел-Изглед-Контролер (Model-View-Controller- MVC) е архитектурен шаблон за дизайн в програмирането, основан на разделянето на функционалността в три взаимодействащи си части – Модел, Изглед и Контролер.
.
Модел - съдържа цялата "бизнес" логика – вътрешната обработка на данните, получени от модела и други източници. Моделът не се интересува от това как е представен (т.е. неговите данни и вътрешно състояние) пред клиента.

Слайд 14

MVC АРХИТЕКТУРА
Предимства на MVC архитектурата:
- Могат да се правят промени в Изгледа без да се променя цялата бизнес логика;
- Може да се капсулира Моделът - т.е. да няма възможност за пряко модифициране или четене на данните му. Това се постига чрез използването на данни с ограничен достъп (protected/private) и публични методи за тяхното модифициране/четене;
- Капсулирането на бизнес-ролите в компоненти подпомага тестването, повишава качеството и предразполага към многократно използване.

Слайд 15

Event-Driven архитектура
При тази архитектура отделните компоненти се обвързват чрез събития, за които се абонират. При настъпването на събитие, абонираните за него компоненти го обработват по специфичен за тях начин. Докато в стандартните клиент-сървър системи действията се инициират от страна на клиентите, в event-driven системите действията се инициират от компонентите, предоставящи събитията/услугите.
СОФТУЕРНИ АРХИТЕКТУРИ

Слайд 16

СОФТУЕРНИ АРХИТЕКТУРИ
Архитектура с обмяна на съобщения (Message Passing)
Системите с обмяна на съобщения представляват мрежи от обработващи звена, свързани с опашки/канали за съобщения. Обработващите звена може да отсяват съобщенията, да ги преразпределят по избрани канали към други звена, или да трансформират съобщенията в нови и да ги предават по-нататък по мрежата.

Слайд 17

СОФТУЕРНИ АРХИТЕКТУРИ
Архитектура с общо хранилище (Shared Repository)
В центъра на тази архитектура стои общо хранилище за данни. Отделните компоненти на системата взаимодействат помежду си непряко – през данните в хранилището.

Слайд 18

СОФТУЕРНИ АРХИТЕКТУРИ
Архитектура с разпределяне на товара
(Load Balancing)
Когато софтуерната система трябва да осигурява висока производителност и/или надеждност е възможно да се използват повече от едно звена, изпълняващи еднакви функции, като заявките към тях се разпределят от специално звено (load balancer), така че натоварването на всяко звено да е съизмеримо и производителността на системата да бъде оптимална. В допълнение, при проблем в работата на едно от дублираните звена е възможно останалите да поемат неговата част от операциите без нарушаване работата на цялата система.

Слайд 19

СОФТУЕРНИ АРХИТЕКТУРИ
Архитектура, ориентирана към услуги (Service-Oriented Architecture, SOA)
При тази архитектура системата предоставя предварително описан набор от услуги за употреба от външни системи. Архитектурата, ориентирана към услугите, се основава на подход за построяване, при който всеки бизнес процес се разглежда като набор от взаимодействащи бизнес операции – услуги.

Слайд 20

АРХИТЕКТУРА
ОРИЕНТИРАНА КЪМ УСЛУГИ
Софтуерната услуга може да се характеризира по следния начин: тя е софтуерен компонент, който осигурява функционалност на други софтуерни компоненти. Услугата дефинира интерфейс, който да бъде използван от клиентите, за да имат достъп до нея. Съществена характеристика е, че създаването на софтуерна услуга не е свързано със съществуването на потребители. Софтуерната услуга е абстрактна концепция, която може да има различни реализации. Услуга е отделен ресурс, който се предлага от софтуерна система.
В бъдещето, все повече понятията софтуер и софтуерни услуги ще са неразделно цяло, което ще се отрази и на същността на софтуерните приложения.

Слайд 21

АРХИТЕКТУРА
ОРИЕНТИРАНА КЪМ УСЛУГИ
Понятието Софтуер като услуга (Software as a Service - SaaS) е модел за разпространение на софтуер, където софтуерна компания разработва уеб-базирано приложение и го предоставя и поддържа за своите клиенти по интернет. Клиентите на това софтуерно приложение не добиват собственост върху софтуера, но плащат за неговото използване. Потребителите използват софтуерното приложение чрез публичен интерфейс през интернет. Приложенията се стопанисват (host) от т.нар. доставчик на услуги (service provider) и са достъпни за клиентите.

Слайд 22

АРХИТЕКТУРА
ОРИЕНТИРАНА КЪМ УСЛУГИ
При традиционния модел на разпространение на софтуер клиентът си закупува лиценз за използване на софтуер и той му принадлежи. Софтуерът е под контрола на клиента и на практика клиентът притежава софтуера за неограничено използване като време и честота. При модела Софтуерът като услуга клиентите не притежават софтуера, който използват. Вместо това те могат да си платят абонамент за съответния софтуер, който на практика се изпълнява на отдалечено място в мрежата. В такъв случай клиентите няма да могат да продължат да използват софтуерното приложение, ако не си заплащат дължимите суми за абонамент - прекратяване на плащанията означава край на потреблението.

Слайд 23

АРХИТЕКТУРА
ОРИЕНТИРАНА КЪМ УСЛУГИ
Ориентирана към услуги архитектура (SOA) е концептуална архитектура, поддържаща идеята и характеристиките на софтуерните услуги. SOA е логически начин на разработване на разпределени системи, като градивните елементи на тези системи са услуги. В минималния сценарий на SOA съществуват поне доставчик на услуга (service provider) и консуматор на услуга (service consumer).
Публикуването на услугата включва създаването на софтуерен артефакт и обявяването му като достъпен за потенциални консуматори.
След като консуматор е открил
подходяща услуга, той може да изпрати
заявка на доставчика на услугата за
ползване и съответно да получи отговор.

Слайд 24

УЕБ УСЛУГА
На практика уеб услугите са един от възможните начини за реализация на парадигмата за архитектура, ориентирана към услуги.
Основната цел на технологията уеб услуги е да осигури възможност различни софтуерни приложения да си взаимодействат по стандартизиран начин, така че да няма нужда от намеса на човек. Уеб услугите могат да извикват други уеб услуги, за да прехвърлят изпълнението на част от сложни транзакции. Това осигурява висока степен на гъвкавост и адаптируемост.
Уеб услугите са модулни, самопознаващи се и самоописващи се приложения. Това означава, че дадена уеб услуга знае каква функционалност може да извърши и какви входни данни са й необходими, за да генерира изходни данни.
Уеб услугите са по-видими и по-управляеми, отколкото уеб базираните приложения. Състоянието на уеб услугите може да бъде наблюдавано и управлявано по всяко време.

Слайд 25

ВИДОВЕ УЕБ УСЛУГИ
Принципно могат да се разграничат два вида уеб услуги:
прости (информационни) – Информационните услуги поддържат само операциите заявка/отговор. Те чакат заявка, обработват я и след това отговарят.
сложни (съставни услуги или услуги бизнес процеси) - Сложните услуги реализират някаква форма на координация между съществуващи прости услуги, които могат да се намират в различни организации, но заедно извършват някаква функционалност на много стъпки.
От друга страна, може да се разграничат уеб услуги, които поддържат или не поддържат състояние. Ако уеб услуга поддържа някакво състояние между различни извиквания на услугата от един и същ или от различни клиенти, се казва, че е поддържаща състояние (stateful). Обикновено простите услуги са такива, а сложните поддържат информация за контекста и състоянието от предишни извиквания на услугата.

Слайд 26

РАЗРАБОТВАНЕ НА СОФТУЕРНА СИСТЕМА НА БАЗАТА НА УСЛУГИ
Могат да се обособят девет фази при разработване на SOA приложения:
- Планиране - фазата планиране определя същността и обхватът на потенциално софтуерно решение на базата на услуги в контекста на отделната организация;
- Анализ - идентифицират се изискванията към новото приложение;
- Дизайн - тази фаза изисква моделиране и дефиниране на основните услуги;
- Конструиране - тази фаза включва разработването на уеб услуги, дефиниране и описание на интерфейси на услуги;
- Тестване - тази фаза анализира имплементацията на услуга в тестова среда, за да може евентуално да открие повреди, които биха могли да се проявят по-късно при интегриране, конфигуриране и работа в различни платформи;

Слайд 27

РАЗРАБОТВАНЕ НА СОФТУЕРНА СИСТЕМА НА БАЗАТА НА УСЛУГИ
- Доставяне – на тази фаза се поддържат дейностите на консуматора и доставчика на услугата. Тя включва модели за сертифициране на услугата, одитиране на услугата, заплащане за услугата и други управляващи операции, които контролират поведението на услугата по време на използването й;
- Внедряване - включва публикуване на интерфейс на услугата, внедряване на услугата в средата, в която ще се изпълнява, създаване на дефиниция на имплементацията на услугата;
- Изпълнение - тази фаза включва действителното обвързване и реална работа на услугата - взаимодействие с други услуги;
- Наблюдение - по време на тази фаза уеб услугите се наблюдават, за да се добие представа за поведението им в реална работна среда.

Слайд 28

OБЛАЧНИ АРХИТЕКТУРИ
При облачните архитектури се използват при поискване, достъпни чрез Интернет услуги. При приложенията, изградени с облачни архитектури изчислителната инфраструктура се използва само когато е необходима, т.е. заделят се при поискване необходимите ресурси, свършва се определената работата, а след това ненужните вече ресурси се освобождават. По време на работа, приложението се мащабира нагоре и надолу в зависимост от нуждите му за ресурси.
Облачните архитектури са сравнително нов модел за управление на виртуализирани ресурси, които са достъпни като услуга в Интернет. Чрез този модел, софтуерните специалисти могат да създадат високоинтерактивни приложения и в някои случаи да заместят дори традиционните декстоп приложения.

Слайд 29

OБЛАЧНИ УСЛУГИ

Слайд 30