Arhitektualni stilovi

Nemanja Vlahović

Smer: Microsoft Development

Generacija: 2016

Datum predaje rada: 27.03.2020.

Arhitektualni stilovi Nemanja Vlahović

SADRŽAJ
1.UVOD...................................................................................................................................................... 2

2. MVC ARHITEKTURA......................................................................................................................... 3

2.1. Istorija.......................................................................................................................................................... 3

2.2. Primena........................................................................................................................................................ 5

3. KLIJENT-SERVER ARHITEKTURA................................................................................................ 6

3.1. Uloga klijenta i servera.................................................................................................................................. 6

3.2. Komunikacija između klijenata i servera........................................................................................................ 7

3.3. Primena........................................................................................................................................................ 8

4. ZAKLJUCAK......................................................................................................................................... 9

5. LITERATURA.................................................................................................................................... 11

1
Arhitektualni stilovi Nemanja Vlahović

1.Uvod

Arhitektura web aplikacija definiše interakcije između aplikacija, sistema srednjeg softvera i
baze podataka da bi se osiguralo da više aplikacija može raditi zajedno. Kada korisnik otkuca URL
i dodirne „Idi“, pregledač će pronaći računar okrenut prema Internetu na kome živi web lokacija
i zahteva tu određenu stranicu.

Server zatim reaguje slanjem datoteka u pretraživač. Nakon te akcije, pregledač izvršava te
datoteke kako bi korisniku prikazao traženu stranicu. Sada korisnik stupa u interakciju sa web
stranicom. Naravno, sve ove akcije se izvode u roku od nekoliko sekundi. U suprotnom, korisnici
se ne bi mučili sa web lokacijama.

Ono što je ovde važno je kod koji je pregledao pregledač. Ovaj sam kod može ili ne mora imati
specifična uputstva koja govore pretraživaču kako da reaguje na širok spektar unosa. Kao
rezultat toga, arhitektura web aplikacija uključuje sve podkomponente i razmene spoljnih
aplikacija za celu softversku aplikaciju.

Naravno, dizajniran je tako da efikasno funkcioniše uz ispunjavanje njegovih specifičnih potreba

i ciljeva. Arhitektura web aplikacija je kritična jer većina globalnog mrežnog saobraćaja i svaka
pojedina aplikacija i uređaj koristi komunikaciju zasnovanu na internetu. Bavi se skalom,
efikasnošću, robusnošću i sigurnošću.

Kako radi arhitektura veb aplikacija

Kod web aplikacija imate server naspram klijenta. U suštini, postoje dva programa koja se
istovremeno pokreću:

 Kod koji živi u pretraživaču i reaguje na unos korisnika

 Kod koji živi na serveru i odgovara na HTTP zahteve

2
Arhitektualni stilovi Nemanja Vlahović

2. MVC arhitektura
MVC (енгл. Model-view-controller) arhitektura je projektni uzorak (engl. patern) koji se obično
koristi za razvoj korisiničkih interfejsa. Počiva na ideji o ponovnoj upotrebi već postojećeg
softverskog koda, olakšavanju razvoja i kasnijem održavanju aplikacionog softvera metodom
razdvajanja na posebne komponente: model, prikaz podataka (pogled) i kontrolor (upravljač),
pri čemu je komponenta za prikaz informacija odvojena od interakcije korisnika sa tim
informacijama.

2.1. Istorija
MVC arhitektura se sastoji od određenih komponenti u kojima je svaka zadužena za obavljanje
specifičnih funkcija. Takvo rešenje je mnogo bolje u odnosu na ranije rešenja u kojima se sve
nalazilo na jednom mestu, što je dovodilo do otežanog čitanja izvornog koda, otežanog
pronalaženja i ispravljanja grešaka, kao i do znatno manje funkcionalnosti i fleksibilnosti. MVC je
kao okvir softverske arhitekture nastao pre nego što je izmišljen web-pregledač, i u početku je
korišćen samo za kreiranje grafičkog korisničkog okruženja.

Norveški informatičar Trigvi Riensku (norv. Trygve Reenskaug) je tokom posete Ziroksu
sedamdesetih godina prvi put predstavio MVC arhitekturu primenjenu na Smalltalk-76. On je
MVC kao apstraktni prikaz arhitekture softvera definisao na sledeći način:

 Model predstavlja podatke. Podaci mogu biti samo jedan objekat ili struktura objekata.
Veza između modela i onoga što vidi korisnik trebala bi da bude 1 na 1. Komunikacija
između modela i spoljašnjeg sveta bi trebao da se obavlja uz pomoć kontrolora.

 Pogled ili vizualna prezentacija modela, je povezana sa modelom ili jednim njegovim
delom. Ponaša se kao filter, koji iz modela naglašava određene vrednosti koji opisuju
podatke (atributi), dok neke druge potiskuje i tako filtrirane podatke prikazuje korisniku.
Takođe, ima mogućnost ažuriranja modela, slanjem odgovarajućih zahteva korisnika.

 Kontrolor je veza između korisnika i podataka. On korisniku, u zavisnosti od njegovog

zahteva prikazuje podatke.

Zatim su osamdesetih godina Džejms Altof (нем. James Althoff) i drugi upotrebili verziju MVC-a
za Smalltalk-80 biblioteku klasa. Tek u članku iz 1988-e MVC je predstavljen kao poseban pojam.

3
Arhitektualni stilovi Nemanja Vlahović

U početku MVC šablon nije funkcionisao kao danas, već je izgledao ovako:

Model je podatak koji aplikacija prikazuje

prikaz podataka iz modela, pri čemu jedan podatak može više načina prikazivanja. Na primer,
očitanje temperature se može prikazati visinom stupca ili oznakom za temperaturu

kontrolor prikuplja akcije koje korisnik napravi i na osnovu njih menja model. Tako na primer,
kontrolor može da prikuplja akcije koje korisnik napravi mišem, a zatim, na osnovu njih može da
izmeni model. U tom smislu, kontrolor je predstavljen kao program koji radi s ulaznim
podacima, slično kao što se u korisničkom okruženju radi sa izlaznim podacima.

Na taj način, prikaz podataka se ažurira direktno, na osnovu izmena u modelu. Kada se model
izmeni, on pokrene akciju koja menja prikaz podataka, pri čemu kontrolor ne upravlja prikazom
podataka, već samo menja model, a prikaz podataka se ažurira tek nakon promena realizovanih
u modelu.

2.2. Primena
Osnovna prednost MVC arhitekture je što se razdvajanjem u posebne celine, kod velikih
projekata, na kome može da radi više osoba, omogućava laka izmena nekog elementa, bez
velike intervencije u drugim elementima, kao i ponovno korišćenje već napravljenih elemenata.

Prednosti MVC arhitekture:

 model se može prikazati na više načina

 lakše je dodati novi prikaz podataka (na primer novu internet stranicu koja prikazuje
postojeće podatke ili deo njih)
 lakša se menja interakcija sa korisnikom
 više programera može raditi istovremeno i paralelno na različitim komponentama
 mogućnost ponovna korišćenja koda

 pojedinačni delovi se mogu lako testirati, menjati i poboljšavati

 prikaz podataka je odvojen od logike obrade podataka
Mane MVC arhitekture su:

 previše kompleksna za primenu kod razvoja manjih aplikacija, što dovodi do pogoršanja kako
njenog dizajna, tako i njenih karakteristika
 usled čestih izmena modela prikaz podataka može ostati preplavljen zahtevima za izmenu,
što može dovesti do kašnjenja u odgovorima na zahteve.

4
Arhitektualni stilovi Nemanja Vlahović

MVC projektni šablon se sastoji od tri zasebne, ali međusobno povezane komponente:

 model — je centralni deo aplikacije, koja obuhvata promenljivu (dinamičku) strukturu

podataka, direktno upravljanje podacima, logikom i pravilima aplikacije
 prikaz, pogled ili pregled podataka (енгл. view) - bilo koji izlazni prikaz podataka u
korisničkom okruženju (na primer grafički pomoću dijagrama), pri čemu se isti podaci
mogu prikazati na više načina (na primer stubični dijagrami za menadžment i tabelarni
prikaz za računovodstvo)
 upravljač ili kontrolor (енгл. controller) — ulazne podatke pretvara u komande koje
upravljaju modelom ili prikazom podataka u korisničkom okruženju.

Praktično, u ovakvoj arhitekturi, model predstavlja „telo”, prikaz podataka su „oči”, a konotrolor
„mozak” projekta.

SLIKA 1. Graficki prikaz MVC.

5
Arhitektualni stilovi Nemanja Vlahović

3. Klijent-Server arhitektura
Model klijent—server je struktura distribuiranih aplikacija koja deli zadatke između onih koji
obezbeđuju resurse ili usluge — servera i onih koji traže usluge — klijenta. Najčešće klijenti i
serveri komuniciraju preko kompjuterske mreže na odvojenom hardveru, ali mogu biti smešteni
u istom sistemu. Server host pokreće server programe koji dele svoje resurse sa klijentima.
Klijent ne deli svoje resurse, ali zahteva serverov sadržaj ili uslugu. Klijenti započinju sesiju
komunikacije sa serverima koji čekaju dolazeće zahteve. Primeri kompjuterskih aplikacija koji
koriste klijent—server model su imejl, web.

3.1. Uloga klijenta i servera

Klijent—server opisuje vezu programa u aplikaciji koji sarađuju. Server obezbeđuje funkciju ili
uslugu jednom ili više klijenta koji zahtevaju tu uslugu. Serveri se klasifikuju po vrsti usluge koje
pružaju. Na primer, veb-server omogućava pregled veb-stranica, a fajl server obezbeđuje
kompjuterske fajlove. Deljeni resurs može biti bilo koji deo softvera i elektronskih komponenti
server računara, od programa i podataka do procesora i uređaja za čuvanje podataka. Serveri
pružaju usluge tako što dele svoje resurse.

Da li je kompjuter klijent, server, ili oba određuje vrsta aplikacije koje zahtevaju uslugu. Na
primer, jedan računar može istovremeno pokretati softver i za veb server i za fajl server da bi
obezbedio različite podatke klijentima koji imaju različite zahteve. Softver klijenta može
komunicirati sa softverom servera unutar istog računara. Komunikacija između servera, na
primer sinhronizacija podataka, se naziva inter-server ili server-to-server komunikacija.

3.2. Komunikacija između klijenata i servera

Uopšteno, usluga je apstrakcija kompjuterskih resursa i klijent ne mora da brine o tome kako
server radi dok ispunjava zahtev i isporučuje odgovor. Klijent samo mora da razume odgovor
koji se zasniva na dobro poznatom protokolu za aplikaciju, odnosno sadržaj i format podataka za
zahtevanu uslugu.

6
Arhitektualni stilovi Nemanja Vlahović

Klijenti i serveri razmenjuju poruke u vidu zahtev-odgovor komunikacijskog šablona. Klijent

pošalje zahtev, a server vrati odgovor. Ova razmena poruka je primer interprocesne
komunikacije. Da bi komunicirali, računari moraju da imaju zajednički jezik i da slede pravila da
bi i klijent i server znali šta da očekuju. Jezik i pravila komunikacije se definišu protokolom za
komunikaciju. Svi klijent- server protokoli funkcionišu u sloju aplikacija. Protokol sloja aplikacija
definiše osnovni šablon dijaloga. Da bi se razmena podataka formalizovala još više, server može
da implementira aplikacioni programski interfejs (API). API je sloj apstrakcije za pristupanje
usluzi. Ograničavajući komunikaciju na tačno određeni format sadržaja olakšava se
raščlanjivanje, a time što se apstrahuje pristup olakšava se razmena podataka na različitim
platformama.

Server može primiti zahteve od velikog broja različitih klijenata u kratkom vremenskom
intervalu. Kompjuter može ispuniti ograničeni broj zadataka u datom trenutku i oslanja se na
sistem rasporedjivanja da bi prioritizovao dolazeće zahteve od klijenata i da bi ih ispunio. Da bi
se sprečila zloupotreba i povećala dostupnost, softver servera može da ograniči dostupnost
klijentima. DoS napadi su dizajnirani da iskoriste obavezu servera da obradi dolazeće zahteve
tako što ga preopterete sa previše zahteva u kratkom vremenskom intervalu.

3.3. Primena
Klijent-server model ne zahteva da server-domaćin mora da ima više resursa nego klijent-
domaćin, već omogućava da bilo koji računar opšte namene proširi svoje mogućnosti koristeći
deljene resurse drugih domaćina. Centralizovano računarstvo, međutim, konkretno dodeljuje
velike količine resursa malom broju računara. Što je više obrade prebačeno od klijenta-
domaćina na centralne računare, toliko klijenti-domaćini mogu biti jednostavniji. Najvećim
delom se oslanja na mrežne resurse (servere i infrastrukture) za obradu i skladištenje. Čvor bez
diska učitava čak i operativni sistem sa mreže, a računarski terminal uopšte nema operativni
sistem; već je samo ulazno/izlazni interfejs prema serveru. Suprotno, debeli (zahtevni) klijent,
poput personalnog računara, ima mnogo resursa, i ne oslanja se na server u izvršavanju
osnovnih funkcija.

7
Arhitektualni stilovi Nemanja Vlahović

Kako se cena mikroračunara smanjivala, a njihova moć rasla od osamdesetih do kasnih

devedesetih godina 20. veka, mnoge organizacije su se prešle sa centralizovanih servera, poput
mejnfrejm računara i miniračunara, ka debelim klijentima. To je omogućilo veću,
individualizovanu dominaciju nad računarskim resursima, ali komplikovano upravljanje
informacionim tehnologijama. Tokom 2000-ih godina, web aplikacije su se razvile dovoljno da
budu konkurentne aplikacionom softveru razvijenom za posebne mikroarhitekture. Ovaj
napredak, pristupačnije masovno skladištenje i pojava servisno orijentisanih arhitektura, bio je
među faktorima koji su ubrzali računarstvo u oblaku od 2010-ih.

SLIKA 2. Grafički prikaz Klijent-Server

8
Arhitektualni stilovi Nemanja Vlahović

4. Zakljucak
Kada pišete aplikaciju, na veb programeru je da odluči šta će kod na serveru raditi u odnosu na
kod u pregledaču. Sa kodom na strani servera jezici uključuju:

 Rubi na šine
 PHP
 C#
 Java
 Pithon
 Javascript

U stvari, svaki kod koji može odgovoriti na HTTP zahteve ima mogućnost pokretanja na serveru.
Evo još nekoliko atributa koda na strani servera:

 Korisnik ga nikada ne vidi (osim u retkim kvarovima)

 Pohranjuje podatke poput korisničkih profila, tweeta, stranica itd ...
 Stvara stranicu koju je korisnik tražio

Sa kodom na strani klijenta, jezici koji se koriste uključuju:

 CSS
 Javascript
 HTML

Zatim ih pregledava korisnik pregledač. Pored toga, korisnik može videti i uređivati kod na strani
klijenta. Osim toga, mora komunicirati samo preko HTTP zahteva i ne može direktno čitati
datoteke sa servera. Dalje, reaguje na unos korisnika.

9
Arhitektualni stilovi Nemanja Vlahović

Arhitektura web aplikacija je važna za podršku budućem rastu

Razlog zašto je neophodno imati dobru arhitekturu web aplikacija je taj što je nacrt za podršku
budućem rastu koji može doći iz povećane potražnje, buduće interoperabilnosti i povećanih
zahteva za pouzdanošću. Kroz objektno orijentisano programiranje, organizacioni dizajn
arhitekture web aplikacija precizno definiše kako će aplikacija funkcionisati. Neke funkcije
uključuju:

 Dostavljanje trajnih podataka putem HTTP-a, koji se mogu razumjeti kodom na strani
klijenta i obrnuto
 Obavezni zahtevi sadrže validne podatke
 Nudi autentifikaciju za korisnike
 Ograničava ono što korisnici mogu videti na osnovu dozvola
 Stvara, ažurira i briše zapise

10
Arhitektualni stilovi Nemanja Vlahović

5. Literatura
 https://sr.wikipedia.org/wiki/MVC_arhitektura
 https://sr.wikipedia.org/wiki/Model_klijent—server
 https://stackify.com/web-application-architecture/
 https://google.com

11