SOFTVERSKO INZENJERSTVO 2 Sk 2020/21 PREDMETNI NASTAVNIK: doc. dr Ljubica Kazi Datum: 25.12.2020. TEMA 34.– VIŠESLOJNA I MVC SOFTVERSKA ARHITEKTURA 34.1. VIŠESLOJNA SOFTVERSKA ARHITEKTURA TROSLOJNA (3-TIER) KLIJENT-SERVER SOFTVERSKA ARHITEKTURA U softverskom inženjerstvu, troslojna klijent-server softverska arhitektura sastoji se iz fizički odvojenih delova - prezentacija, procesiranje aplikacije i funkcije upravljanja podacima se najčešće nalaze se na različitim računarima.. U troslojnom modelu klijent-server sistema, osnovni čvorovi sistema na kojima se nalaze elementi arhitekture su: 1. Server baze podataka – zadužen je za podršku upravljanja čuvanjem i obradom podataka 2. Aplikacioni server – zadužen je za podršku logike aplikacije 3. Aplikacioni klijent – zadužen je za podršku upravljanja prezentacijom. U troslojnoj klijent-server softverskoj arhitekturi aplikativni softver se sastoji iz:

prezentacioni sloj (presentation tier) sloj domenske logike (domain logic tier) sloj podataka (data storage tier).

SLOJEVITA (LAYERED) I N-TIER SOFTVERSKA ARHITEKTURA Kod slojevite softverske arhitekture, celina aplikativnog softvera podeljena je na slojeve u logičkom smislu, a neposredna implementacija može biti kreiranjem zasebnih fizičkih celina (projekata) za svaki sloj. Fizičke celine (slojevi) se mogu nalaziti na istom računaru ili na više različitih računara. Kada ima više od 3 sloja, naziva se višeslojna. Kod n-tier (višeslojne) klijent-server arhitekture:

Više od 3 sloja (n slojeva) slojevi se ne nalaze na istom računaru.

KLIJENT SERVER N-TIER SOFTVERSKA ARHITEKTURA

SLOJEVITA SOFTVERSKA ARHITEKTURA (Layered)

Komponente se ne nalaze na istom računaru Logička podela na slojeve

3-slojna – server baze podataka, aplikacioni server, aplikacioni klijent

Fizička podela na komponente

n-tier – više komponenti Može imati više slojeva i podslojeva (višeslojna).

PREDNOSTI SLOJEVITE I N-TIER SOFTVERSKE ARHITEKTURE Slojevita i N-tier aplikaciona arhitektura obezbeđuje strukturu softvera takvu da koristi prednosti modularizacije softvera:

mogu da se kreiraju fleksibilne aplikacije pogodne za održavanje i ponovno korišćenje komponenti (reusable) Razdvajanjem aplikacije na slojeve, dobija se mogućnost izmene ili dodavanja specifičnih slojeva, umesto da se

celokupna aplikacija ponovo implementira zbog promena Omogućava se timski rad (podela posla) Ubrzava se razvoj (jednom kada se biblioteke klasa naprave i testiraju, u narednom softveru sličnog tipa se brže

realizuje softver). Bolji kvalitet softvera – ponavljanje radnih operacija uvodi rizik od ljudske greške, kada jedan modul dobro

funkcioniše (ranije testiran i korišćen), može se ponovo koristiti.

OSNOVNI ELEMENTI SLOJEVITE SOFTVERSKE ARHITEKTURE

Naredna slika prikazuje osnovna 4 sloja slojevite (layered) softverske arhitekture. Leva slika daje detaljniji prikaz

na engleskom jeziku, preuzet sa MSDN veb sajta, a desno je pojednostavljeni prikaz na srpskom jeziku, bez detalja, tj.

podslojeva.

OSNOVNA ŠEMA SLOJEVITE

SOFTVERSKE ARHITEKTURE SA 4 SLOJA

[1] [2]

U nastavku je dat opšti model višeslojne softverske arhitekture, na osnovu prethodno prikazane slike, prošireno

relevantnim aspektima I komponentama koje su ranije pomenute.

SISTEM ILI EKSTERNO

SLOJ PODSLOJ

SISTEM PREZENTACIONI SLOJ (Presentation layer)

Korisničkiinterfejs

Prezentaciona logika

SLOJ SERVISA (Services layer)

Servisni interfejsi (komponenta koja vezuje aplikaciju za servis koji je eksterno raspoloživ sa svojim funkcijama) i tipovi poruka

Maper – integriše druge softverske komponente

SLOJ POSLOVNE LOGIKE (Business layer)

Aplikaciona logika (jezgro funkcionalnosti samog aplikativnog softvera)

Radni tokovi

Poslovni entiteti

Poslovna pravila (ugrađena u metode klasa poslovnih entiteta)

SLOJ ZA RAD SA PODACIMA (data layer)

Klase za rad sa podacima koji se čuvaju u raznim formatima (baze podataka) – Data Access Components Pomoćne klase (helperi, uslužne klase) Servisni agenti (komuniciraju sa sofverskim servisima koji su izvan sistema)

EKSTERNO IZVORI PODATAKA DBMS i baza podataka (tabele, stored procedure), drugi formati (XML)

EKSTERNI SOFTVERSKI SERVISI

Javno dostupni veb servisi, koji su pozvani u okviru ovog sistema

EKSTERNI APLIKATIVNI SOFTVER KOJI KORISTI SERVISE SISTEMA

Ako aplikacija ima sopstvene servise, druge aplikacije se mogu integrisati i koristiti te servise.

KORISNICI Neposredni korisnici aplikacije, ljudi

Obrazovni model višeslojne veb aplikacije uz primenu .NET razvojnog okruženja dat je u nastavku:

PRIPADNOST SLOJ PODSLOJ IMPLEMENTACIJA

Aplikativni softver

PREZENTACIONI SLOJ Korisnički interfejs Aspx projekat veb aplikacije

Prezentaciona logika Class library (dll)

SERVISNI SLOJ Servis kao eksterna funkcija ASMX (SOAP) projekat kreiran za potrebe ovog aplikativnog softvera

Servis kao međusloj Maper klase (dll)

SLOJ POSLOVNE LOGIKE

Poslovne klase sa implementacijom poslovnih pravila

Class library (dll)

Radni tokovi Profili korisnika - Meniji, master stranice

SLOJ ZA RAD SA PODACIMA

Biblioteka klasa za rad sa tabelama iz baze podataka

Class Library (dll): (Klase podataka)– za svaku tabelu u bazi podataka 3 klase (pojedinac, lista, DB) Više načina: 1. DB koristi standardne klase za rad sa bazom podataka (sa stored procedurama ili upitima), 2. DB koristi tehnološku biblioteku klasa (izdvojena tehnologija konkretnog DBMS), 3. DB sadrži vezu ka Entity framework klasama koje su generisane

Biblioteka klasa za rad sa drugim formatima

Class Library (dll) – utility klase koje rade sa XML, TXT

Eksterno BAZA PODATAKA I DBMS

DRUGI EKSTERNI SERVISI

ASMX veb servisi koji su javno dostupni na internetu

PREZENTACIONI SLOJ Prezentacioni sloj se sastoji iz dva dela:

1. Korisnički interfejs – zadužen za predstavljanje podataka korisniku, neposredni prijem komandi korisnika u toku korišćenja aplikacije, organizaciju dostupnosti funkcija kroz personalizaciju funkcija različitim tipovima korisnika.

2. Prezentaciona logika – zadužena za (izlaz): preuzimanje podataka iz dubljih slojeva, formatiranje i dostavljanje podataka korisničkom interfejsu, (ulaz) prijem, proveru i prosleđivanje podataka dubljim slojevima aplikacije, nakon unosa podataka i komandi od strane korisnika. Određene strukture podataka služe za prijem i predstavljanje podataka i mogu se značajno razlikovati u odnosu na strukture podataka koje se nalaze u poslovnom sloju i sloju podataka. Posebne klase objektno-orjentisane implementacije obezbeđuju odgovarajuće strukture podataka, kao i funkcije prikaza i organizacije funkcija, odnosno prijema komandi sa korisničkog interfejsa. Te klase mogu biti univerzalne, pa se mogu koristiti u implementaciji različitih tipova korisničkih interfejsa (desktop, web, mobilne aplikacije). Takođe, ovom sloju pripadaju i standardne klase za grafičko uređenje korisničkog interfejsa.

SLOJ SERVISA Namena sloja servisa - može se koristiti kao:

a) softverska celina koja pruža određene usluge (funkcionalnosti) drugim delovima aplikativnog softvera ili eksternim aplikacijama koje se vezuju za njih,

b) jedinica funkcionalnosti koja realizuje poslovne funkcije, tj. slučajeve korišćenja aplikativnog softvera, c) međusloj između drugih slojeva ili podslojeva, kako bi omogućio integrisanje slojeva i premostio različite sisteme

šifriranja podataka (maperski sloj, tj. sloj mapiranja). Softverski servisi mogu biti locirani:

deo aplikativnog softvera, izdvojen u poseban modul, eksterno dostupni, povezuju se putem Interneta (URL).

SLOJ POSLOVNE LOGIKE Sloj poslovne logike može biti realizovan na različite načine:

1. U okviru objektno-orjentisanog aplikativnog softvera, sloj poslovne logike najčešće sadrži: o Klase kojima se opisuju poslovni entiteti (poslovni objekti, događaji, dokumenti) – opisuju entitete rečnika

poslovnog domena kroz odgovarajuće podatke i ponašanje. o Poslovna pravila – uključena u metode klasa o Radni tokovi – primenom personalizacije (meniji) i povezivanjem ekrana uslovima (stanjima) koje je

potrebno zadovoljiti da bi se koristio. 2. Primenom specijalizovanih softvera:

o Workflow management sistemi - Sistem za upravljanje radnim tokovima sastoji se iz: vizuelno-orjentisanih alata za definisanje radnih zadataka, odgovornosti i redosleda njihovog

izvršavanja, modula koji implementira zadate sekvence radnih aktivnosti u okviru osnovnog aplikativnog

softvera. Sistem za upravljanje radnim tokovima je zasnovan na modelu kojim se definišu zadaci kao čvorovi i njihova međusobna povezanost. Zadaci se aktiviraju ukoliko su uslovi njihove međusobne povezanosti sa drugim zadacima ispunjeni. Teorijska osnova upravljanja radnim tokovima je teorija grafova i petrijeve mreže. Upravljanje radnim tokovima implementira se kroz softversku podršku koja najčešće uključuje kreiranje atomarnih funkcionalnih jedinica, koje se pozivaju i kombinuju u radnim tokovima. Atomarne funkcionalne jedinice mogu biti funkcionalne jedinice unutar aplikativnog softvera ili web servisi. Postoje standardi I jezici za definisanje načina povezivanja web servisa za primenu u podršci radnim tokovima. Posebno definisan jezik Web Services Business Process Execution Language (WS-BPEL) predstavlja standardni jezik za specifikaciju akcija u okviru poslovnih procesa koji se realizuju putem web servisa.

Business rules management sistemi - Sistemi za upravljanje poslovnim pravilima (BRMS – business rule management system) je softverski sistem koji se koristi za definisanje, postavljanje, izvršavanje, monitoring i održavanje različitih elemenata logike odlučivanja koje se koriste u poslovno-orjentisanom softveru. Logika odlučivanja uključuje poslovna pravila, politike, zahteve, uslovne rečenice koje se koriste kako bi se utvrdile akcije koje bi se primenile u aplikacijama i sistemima. Prednosti korišćenja BRMS sistema odnose se na smanjivanje zavisnosti organizacionih jedinica od IT odeljenja kada su u pitanju promene pravila poslovanja, povećan nivo kontrole nad logikom odlučivanja, unapređenje preciznosti

odlučivanja i efikasnosti zbog automatizacije odlučivanja. Osnovna arhitektura BRMS sistema minimalno mora sadržavati:

o Skladište (repozitorijum) gde će biti smešteni elementi logike odlučivanja (pravila odlučivanja), izdvojeni iz programskog koda jezgra softverske aplikacije – najčešće su snimljena u obliku formalnog jezika, tj. rečenica predikatskog računa

o Alati kojima se definiše i održava logika odlučivanja – najčešće su to vizualno-orjentisani alati, koji olakšavaju ne-IT osoblju firmi da predstave pravila poslovanja.

o Izvršno okruženje (Business Rule Engine), koje omogućava aplikaciji da izvršava logiku odlučivanja u kombinaciji sa podacima iz osnovne poslovne aplikacije.

Funkcionalne mogućnosti sistema za upravljanje poslovnim pravilima najčešće obuhvataju: Razvojna okruženja za kreiranje poslovnih pravila uz povezivanje sa programskim kodom Alati za razvoj poslovnih pravila bez pisanja programskog koda Alati za proveru i vrednovanje poslovnih pravila Simulaciona okruženja za testiranje novih ili izmenjenih poslovnih pravila Integracija poslovnih pravila na određene radne platform Podrška za životni ciklus I odgovornost nad poslovnim pravilima

PRIMERI VEB-BAZIRANOG WORKFLOW MANAGEMENT SOFTVERA Vizuelno radno okruženje za definisanje elemenata poslovnog procesa i redosleda izvršavanja aktivnosti:

[3] Karakteristike Workflow management sistema:

[4]

[4]

[4]

[4]

[4]

PRIMER VIZUELNOG ALATA ZA DEFINISANJE POSLOVNOG PRAVILA (Alat Visual Rules v4, Bosch)

[6] SLOJ ZA RAD SA PODACIMA (Sloj za pristup podacima - Data Access Layer - DAL) To je sloj računarskog programa koji obezbeđuje jednostavniji pristup podacima koji su smešteni u okviru nekog trajnog skladišta podataka (persistent storage), npr. u okviru relacione baze podataka ili fajl sistema. DAL čine klase koje obezbeđuju podatke iz npr. baze podataka, a koje mogu pristupati podacima pozivom stored procedura iz baze podataka. DAL sakriva kompleksnost skladištenja podataka, a može da sadrži upite i nad više različitih izvora podataka i više baza podataka. DAL može biti zavisan od konkretnog DBMS (sistema za upravljanje bazom podataka), odnosno servera baze podataka ili nezavisan. DAL koji podržava više različitih tipova DBMS (ili je univerzalan u tom smislu) je lakši za održavanje, jer se lako izvrši izmena podrške konkretnom DBMS, dok ostali elementi ostaju nepromenjeni. Osnovna podrška DAL treba da bude za CRUD (Create, Read, Update, Delete) operacije nad podacima. U ovom sloju može biti primenjeno objektno-relaciono mapiranje (Object-Relational Mapping), gde se primenjuje “active record” model (kreiranje klasa koje su povezane objektno-relacionim mapiranjem sa bazom podataka i automatski realizuju sve promene u bazi podataka, nakon što je došlo do promena stanja objekata klasa sa kojima je povezana). MIDDLEWARE Middleware je treba razlikovati od srednjeg aplikativnog sloja. Definicija - Middleware je računarski softver koji obezbeđuje servise aplikativnom softveru da bude nezavistan od operativnog sistema i hardverske platforme na kojoj se izvršavaju. Middleware olakšava softverskim developerima da implementiraju komunikaciju i ulaz-izlaz, bez poznavanja i rada sa tehničkim detaljima operativnog sistema i hardvera i na ovaj način oni se mogu fokusirati na specifične namene njihovih aplikacija. Termin je najčešće korišćen u značenju softvera koji omogućuje komunikaciju i upravljanje podacima u distribuiranim aplikacijama. Middleware je definisan i kao “servisi koji su iznad transportnog sloja OSI modela, ali ispod aplikacionog okruženja, odnosno aplikacionog API nivoa. U ovom specifičnom smislu, middleware povezuje klijent i server, odnosno dva peer-a u peer-to-peer vezi. Middleware se takođe definiše i kao softverski sloj koji je između operativnog sistema i aplikacija na svakoj strani distribuiranog sistema u mreži. Servisi koji pripadaju middleware uključuju: middleware orjentisan na poruke (Message oriented middleware), object request brokers (ORBs) i enterprise service bus (ESB). Pod pojmom middleware podrazumevaju se i servisi za rad sa bazom podataka, kao što su: ODBC, JDBC i drugi.

34.2. MVC SOFTVERSKI ARHITEKTURNI DIZAJN PATERN Model–view–controller (MVC) je softverski arhitekturni (dizajn) patern. Deli aplikaciju na tri međusobno povezane komponente, kao bi se razdvojile interne prezentacije informacija od načina kako je informacija prezentovana i prihvaćena od strane korisnika. Na ovaj način, MVC dizajn patern omogućava paralelni razvoj komponenti i ponovnu iskoristivost koda (code reuse). Ova arhitektura je postala popularna za dizajn web i mobilnih aplikacija. Najčešće korišćeni programski jezici Java, C#, PHP i Ruby imaju svoje popularne MVC framework-e koji se koriste u razvoju aplikacija. Komponente MVC softverskog arhitekturnog dizajn šablona su [7]:

MODEL – klase za rad sa podacima aplikacije, ali sadrži i klase poslovne logike (domenske klase), čime se realizuje logika aplikacije i izvršavaju pravila koja su ugrađena u aplikaciju.

VIEW – može biti bilo koji prikaz informacija (output representation). Za iste informacije može biti više različitih prikaza – grafikoni, tabelarni prikazi i slično, a takođe, mogu se koristiti i različite platforme (desktop, veb aplikacija, mobilna aplikacija...). U veb aplikacijama segment View se odnosi na čiste HTML stranice (ne sadrže ili imaju minimalnu količinu aktivnog koda), već sadrže samo vizualne komponente koje su povezane sa elementima modela, kako bi mogle da prezentuju sadržaje na određeni način.

KONTROLER – preuzima zahteve (http request) kao ulaze i konvertuje ih u komande koje su upućene MODELU ili VIEW. Predstavlja skup klasa koje obrađuju komunikaciju sa korisnikom, upravljaju celokupnim tokom rada aplikacije i logikom specifičnom za aplikaciju.

Redosled izvršavanja aktivnosti u okviru MVC aplikacije opisuje princip funkcionisanja MVC:

Kada stigne HTTP request do MVC aplikacije, request preuzima kontroler i on tada obrađuje taj zahtev, obraćajući se modelu ili pogledu.

S obzirom da je MODEL zadužen za podatke, KONTROLER zadaje komande modelu za preuzimanje podataka, za zatim kontroler zadaje komande kojima se preuzeti podaci vezuju za određeni VIEW i prikazuju (šalju korisniku koji je poslao zahtev).

KONTROLER može da šalje komande MODELU da promeni stanje modela. Kontroler može da šalje komande na VIEW da se izmeni prikaz podataka na osnovu izmena modela ili da se prikaže druga vrsta ili način ponašanja VIEW.

Slika 1. Šema ilustracije principa funkcionisanja MVC aplikacija [2]

MVC concept u Microsoft tehnologiji ASP.NET MVC je web development framework Microsoft-a, koji kombinuje osobine MVC (Model-View-Controller) architecture sa ASP.NET platformom. Predstavlja alternativu traditionalnim ASP.NET Web Forms tipu aplikacije. Predstavlja nadogradnju nad uobičajeni ASP.NET.

[7]

LITERATURA

[1] SLOJEVITA ARHITEKTURA, MICROSOFT MSDN, https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658109(v=pandp.10) [2] Ivanković Z, Lacmanović D: Softversko inženjerstvo 2, Tehnički fakultet „Mihajlo Pupin“ Zrenjanin, skripta. [3] https://www.integrify.com/site/assets/files/1709/integrify-process-designer.jpg [4] https://kissflow.com/ [5] https://www.trustradius.com/business-rules-management-brms [6] https://www.pressebox.de/pressemitteilung/innovations-software-technology-gmbh/Visual-Rules-4-Die-naechste-Generation-des-Business-Rules-Managements/boxid/142792 [7] https://www.tutorialspoint.com/asp.net_mvc/asp.net_mvc_tutorial.pdf PITANJA

1. Objasniti karakteristike troslojne klijent-server softverske arhitekture. 2. Objasniti razliku između layered (slojevite) i n-tier softverske arhitekture. 3. Prednosti slojevite i n-tier softverske arhitekture. 4. Navesti i objasniti osnovna 4 sloja slojevite softverske arhitekture. 5. Nacrtati osnovnu šemu slojevite softverske arhitekture sa 4 sloja. 6. Nacrtati tabelu i objasniti opšti model višeslojne softverske arhitekture. 7. Nacrtati tabelu i objasniti obrazovni model višeslojne softverske arhitekture uz primenu .NET razvojnog okruženja. 8. Objasniti 2 podsloja prezentacionog sloja. 9. Uloga prezentacione logike. 10. Namena sloja servisa – navesti, objasniti. 11. Lociranje softverskih servisa – navesti, objasniti. 12. Opisati implementaciju sloja poslovne logike u okviru objektno-orjentisanog aplikativnog softvera. 13. Objasniti poslovne entitete u sloju poslovne logike. 14. Opisati implementaciju sloja poslovne logike primenom specijalizovanih softvera. 15. Objasniti workflow management sisteme. 16. Objasniti namenu WSBPEL. 17. Objasniti business rules management sisteme. 18. Objasniti DAL. 19. Objasniti CRUD. 20. Objasniti koncept active record u ORM. 21. Definicija i značaj middleware. 22. Komponente MVC. 23. Princip funkcionisanja MVC – opis redosleda izvršavanja aktivnosti. 24. Nacrtati šemu kojom se ilustruje princip funkcionisanja MVC aplikacija.