Tema 5:Projektovanje arhitekture softverskih sistema

Size: px

Start display at page:

Download "Tema 5:Projektovanje arhitekture softverskih sistema"

Aubrey Colleen Barrett
5 years ago
Views:

1 Tema 5:Projektovanje arhitekture softverskih sistema dr Vladislav Miškovic Fakultet za računarstvo i informatiku PROJEKTOVANJE INFORMACIONIH SISTEMA 2017/2018 1

2 Sadržaj predavanja 1. Uvod 2. Arhitektura softverskih sistema 3. Modeliranje arhitekture sistema u jeziku UML 4. Projektovanje arhitekture softverskih sistema 5. Primer arhitekture jednostavne aplikacije 2

3 1. Uvod Arhitektura informacionog sistema Ilustracija: Struktura i međusobna zavisnost komponenti sistema Arhitektura u malim i velikim softverskim projektima 3

4 Arhitektura informacionog sistema Arhitektura sistema je osnovna organizacija sistema, koja obuhvata njegove komponente, njihove relacije, okruženje i principe dizajna i razvoja [IEEE Std ] Arhitektura je kontekstno zavisna, npr. u softverskom inženjerstvu razlikujemo softversku arhitekturu sistemsku arhitekturu aplikativnu arhitekturu organizacionu arhitekturu informacionu arhitekturu itd. 4

5 Arhitektura softvera Arhitektura softvera obuhvata skup strateških odluka o organizaciji softverskog sistema definiše strukturu -dekompozicijusistema u komponente/module/podsisteme 5

6 Ilustracija: Struktura sistema i međusobna zavisnost komponenti Osnovna pitanja arhitekture identifikacija komponenti koje se mogu menjati redukcija direktnih zavisnosti od tih komponenti Prevelika međusobna zavisnost komponenti nije poželjna Cilj je da se kreira sistem koji je pogodniji za izmene K1 K2 K3 K4 Komponenta drugog proizvođača Arhitektura 1 Četiri komponente sistema direktno zavise od komponente drugog proizvođača (third party) U slučaju izmene ili zamene te komponente, u sistemu treba promeniti svezavisne komponente K1, K2, K3, K4 K1 K2 K3 K4 K5 (interfejs) Komponenta drugog proizvođača Arhitektura 2 Samo jednakomponenta direktno zavisi od komponente drugog proizvođača. U slučaju izmene ili zamene te komponente, u sistemu treba promeniti samokomponentu K5(interfejs) 6

7 Arhitektura u malim i velikim softverskim projektima [Boehm,Turner,2004] 1. Ulaganje napora u razvoj arhitekturesmanjuje potrebu za kasnijim prepravkama softvera 2. Potreban rad na arhitekturi proporcionalan je veličini projekta 3. Manji projekti imaju promenljive zahteve, dok je za veće projekte neizvesnost zahteva ograničena (bezbednosno kritični sistemi) Produženje vremena Vreme rada Produženje vremena Vreme rada a) mali projekti b) veliki projekti rad na arhitekturi rad na prepravkama ukupno

8 2. Arhitektura softverskih sistema 1. Opšti obrasci arhitekture sistema 2. Aplikaciona arhitektura 8

9 2.1 Opšti obrasci arhitekture sistema Monolitna arhitektura (desktop) Dvoslojna arhitektura (client-server) Troslojna/višeslojna arhitektura (three-tier/multi-tier) četvoroslojna arhitektura SAP R/3, mobilnih sistema Servisno orijentisana arhitektura (SOA) (Web) servisi Standardi zasnovani na XML: SOAP+WSDL+UDDI Web servisi kao sastavni elementi SOA find-bind-execute ESB ESOA Ostali opšti obrasci arhitekture(message broker, pipeline)

10 Logičke komponente aplikacije PRESENTATION LOGIC I/O PROCESSING LOGIC BUSINESS LOGIC DATA MANAGEMENT LOGIC DATA STORAGE LOGIC 1. Korisnički interfejs 2. Provera ulazno-izlaznih podataka (Data Validation) 3. Logika aplikacije (poslovna pravila) 4. Referencijalni integritetidrugi uslovi integriteta 5. Održavanje podataka i strukture za pristup

11 2.2 Aplikaciona arhitektura 1. Monolitna arhitektura (desktop) 2. Klijent-server arhitektura (file-server, 2/3-slojna, višeslojna) 11

12 2.2.1 Monolitna arhitektura (desktop) Monolitnastruktura (svi elementi se nalaze na jednom mestu, uključujući bazu podataka) Nema jasnog razdvajanja pojedinih logičkih komponenti

13 2.2.2 Klijent-server arhitektura Klijent je svaki proces koji traži usluge od servera Server je svaki proces koji pruža tražene usluge klijentima Klijent/server je relacija između dva računarska programa gde jedan od njih (klijent) postavlja zahtev za neku uslugu drugom(server), koji zahtev izvršava klijent/server relacija se može realizovati i na jednom računaru klijent/server model je uobičajeni načinza povezivanje programakoji su distribuirani na više različitih lokacija u mreži

14 Klijent-server arhitektura: file-server Udaljena je samo baza podataka na fajl serveru je održavanje podataka (data storage logic) Sve ostalo na klijentu interfejs (presentation) provera podataka (data validation) logika (business logic) integritet podataka (data managemenet)

15 Klijent-server arhitektura: dvoslojna (2-tier) Server deo provere podataka (data validation): okidači(triggers) integritet podataka (data managemenet): okidači(triggers) održavanje podataka (data storage) Klijenti interfejs (presentation) deo provere podataka (data validation) logika (business logic)

16 Okidači (triggers) Okidači su SQL izrazi uskladišteni u bazi podataka, koji se pokreću određenim događajima npr. upis novog reda u tabelu, brisanje reda, izmena,... Mogu se upotrebiti za kontrolu integriteta baze podataka Sintaksa zavisi od konkretnog sistema, npr. kreiranje okidača za Microsoft SQL Server i Transact-SQL CREATE TRIGGER [naziv_seme.]naziv_okidaca... ON { tabela pogled }... AS sql_naredbe...

17 Primer: Primena okidača (Transact SQL) Automatsko slanje porukemenadžeru prodaje za narudžbe prioritetnih korisnika Tabela Racuni: CREATE TABLE Racuni ( Racun_ID int IDENTITY,..., Racun_Prioritet varchar(10) ) Unos nove narudžbe se vrši SQL naredbom INSERT Za svaku novu narudžbukôd okidača proverava prioritet klijenta u tabeli Racuni Za prioritetne korisnike, vraća unapred zadanu adresu CREATE TRIGGER tr_racuni_insert ON Racuni FOR INSERT AS IF (SELECT COUNT(*) FROM inserted WHERE Racun_Prioritet = 'Visok') = 1 BEGIN PRINT 'menadzer@kompanija.com' END; 17

18 Klijent-server arhitektura: troslojna (3-tier, n-tier) Serveri server 1: aplikativni server veći deo provere podataka (data validation logic): okidači(triggers) logika (business logic): uskladištene procedure (storage procedures) server 2: server baze podataka integritet podataka (data managemenet): okidači(triggers) održavanje podataka (data storage) Klijenti interfejs (presentation) manji deo provere podataka (data validation)

19 Uskladištene procedure (stored procedures) Skupovi naredbikoje se često koriste, smešteni na serveru baze podataka, koje se mogu pokrenuti npr. iz aplikacije prevođenje naredbi procedure vrši DBMS server naredbe se nalaze na jednom mestu, u bazi podataka, pa je olakšano njihovo ažuriranje najmanje opterećenje mreže, poboljšavajuperformanse, pošto se sledećem sloju šalju samo rezultati obrade podataka Koristi se proširenje jezika SQL, specifično za svaki DBMS npr. Oracle PL/SQL, Microsoft SQL Server Tansact-SQL Sintaksa zavisi od konkretnog sistema, npr. za Transact-SQL: CREATE {PROC PROCEDURE} [sema.]naziv_proc... AS [BEGIN] sql_naredbe [;]... [END] [;]

20 Primer: Primena uskladištene procedure (Transact SQL) Automatsko slanje porukemenadžeru prodaje za narudžbe prioritetnih korisnika Tabela Racuni: CREATE TABLE Racuni ( Racun_ID int IDENTITY,..., Racun_Prioritet varchar(10)) Unos nove narudžbevršise SQL naredbom INSERT Procedura služi za unos podatka o prioritetu, a kod za slanje a je umetnut nazive T-SQL parametara i promenljivih CREATE PROCEDURE varchar(10) AS BEGIN TRANSACTION INSERT Racuni(Racuni_Prioritet) VALUES (@Racuni_Prioritet) <> 0 GOTO ErrorCode = 'Visok' PRINT 'menadzer@kompanija.com' COMMIT TRANSACTION ErrorCode: <> 0 END; PRINT 'Error Code' 20

21 Ilustracija: Osnovne komponentei arhitektura Web aplikacija Osnovne komponente Web aplikacija Višeslojna arhitektura Web aplikacija 21

22 Ilustracija: Osnovna arhitektura Web aplikacija zasnovanih na CMS sistemima Klijent Sistem isporuke sadržaja Web server Server za upravljanje sadržajem Server za isporuku sadržaja Dispečerski servis Servis objavljivanja Servis sindikacije Baza podataka sadržaja Statički dokumenti Partner Servisi agregacije podataka Eksterne baze podataka 22

23 3. Modeliranje arhitekture sistemau jeziku UML 1. Modeliranje arhitekture i jezik UML 2. Modeliranje arhitekture i RUP 3. UML dijagrami

24 3.1 Modeliranje arhitekture i jezik UML Jezik UML je sredstvo za dokumentovanje arhitekture jer omogućava nedvosmislenu semiformalnu notaciju postoje brojni softverski alati, mnogi su besplatni ili otvorenog koda UML omogućava istovremeno kreiranje više arhitekturnih pogleda (dijagrama) težište analitičara i projektanata je logički pogled (Logical View) 24

25 UML notacija: paket Osnovni UML element za prikaz arhitekture je paket (package) mehanizam opšte namene koji služi za organizovanje elemenata u grupe može da sadrži druge elemente modela i omogućava prikaz hijerarhije koristi se u toku razvoja i za upravljanje konfiguracijom sistema paket

26 UML notacija: zavisnost paketa Relacija zavisnosti između paketa (dependency) elementi paketa mogu koristiti elemente drugih paketa ako paket zavisi od klase iz drugog paketa, on je klijent (client package), a paket od kog zavisi je dobavljač (supplier package) relacija podrazumeva promene kod paketa dobavljača može uticati na klijentski paket klijent ski paket se ne može samostalno koristiti jer zavisi od drugog paketa klase u klijentskom paketu mogu pristupati klasama u paketu dobavljaču paket zavisnost

27 UML notacija: cirkularne zavisnosti paketa U analizi arhitekture eliminišu se cirkularne zavisnosti otežavaju višestruko korišćenje paketa paketi se razbijaju na manje pakete Hijerarhija treba da bude aciklična Cirkularne zavisnosti onemogućavaju višestruku upotrebu jednog paketa bez ostalih

28 3.2Modeliranje arhitekturei RUP Jezik UML je alat za dokumentovanje arhitekture jer omogućava semiformalnu, nedvosmislenu notaciju Postoje brojni softverski alati Omogućava istovremeno kreiranje više arhitekturnih pogleda (dijagrama) i validaciju arhitekture RUP je iterativna metodologija razvoja Arhitektura softverskog sistema razvija se u fazi razrade (elaboration)u okviru discipline analiza i projektovanje(analysis and design) 28

29 Arhitektura i faze RUP Aktivnosti faze razrade (elaboration) definisanje arhitekture softvera održavanje integriteta softvera procenjivanje tehničkih rizika definisanje redosleda i sadržaja uzastopnih iteracija planiranje svake iteracije Discipline procesa razvoja Poslovno modeliranje Specifikacija zahteva Analiza i projektovanje Implementacija Testiranje Isporuka (Deployment) Pomoćne discipline Upravljanje konfiguracijom Menadžment Čovekova okolina) Početna Inception Razrada Elaboration Faze Realizacija Construction Isporuka Transition Preliminarne Iteracije Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Iteracije 29

30 3.3UML Dijagrami Dijagram paketa i model dijagram Dijagram klasa(class) Dijagram sekvenci (sequence) Dijagram komponenti(component) Dijagram isporuke/rasporeda/realizacije (deployment) 30

31 Dijagram paketa i model dijagram Elementi modela su paketi sadržaj paketa su različiti UML elementi Veze zavisnosti <<use>>,<<access>>,<<import>> Prikaz hijerarhije komponenti sistema Alternativni način prikaza arhitekture: nestandardni strukturni Model dijagram prikaz paketa unutar paketa 31

32 Dijagram komponenti (Component) Modelfizičkihkomponenti softverskog rešenja komponente (components) izvorni kôd COM+.exe,.dll.NET klase Web servisi čvorovi (nodes) zavisnosti (dependencies) interfejsi (interfaces)

33 Dijagram isporuke/rasporeda/realizacije Način realizacije rešenja procesori uređaji komunikacije (procesor-uređaj) (Deployment)

34 4. Projektovanje arhitekture sistema 1. Pristup od dna prema vrhu (botoom up) 2. Pristup od vrha prema dole(top down) 3. Servisno orijentisana arhitektura (SOA) 4. Platforme 5. Kriterijumi kvaliteta arhitekture

35 4.1 Pristup odozdo (Bottom-Up Architecture Development) Počinje analizom domena Komponente se grupišu i sistem se gradi postepeno Nedostatak ovog pristupa je što se analiza sistema na početku opterećuje detaljima implementacije

36 4.2 Pristup s vrha (Top-Down Architecture Development) Prvo se identifikuju komponente sistema i interfejsi, a zatim se detaljnije analiziraju podsistemi Prednosti ovog pristupa su: skraćuje vreme analize i projektovanja, jer se na početku zanemaruju detalji sistem se retko gradi od početka, pase lako dodaju gotovi, dobro definisani elementi upotreba standarda takođe omogućava dodavanje komponenti na visokom nivou

37 Projektovanje arhitekture upravljano kriterijumima [4] Metod Attribute-Driven Design (ADD)na početku zahteva skup kriterijuma(architectural drivers) s prioritetima funkcije sistema na osnovu svojstava proizvoda, zahteva kvaliteta i ograničenja Postupak primeni se prvi kriterijum i izvrši prva dekompozicija sistema postupak se ponavlja za naredne kriterijume,sve dok struktura ne zadovoljisve kriterijume u dovoljnoj meri 1 Kriterijum Podrška dodavanju novih uređaja 2 Podrška višejezičnosti 3 Podrška nestandardnim jedinicama mere 4 Kašnjenje upozorenja 5 Uslovi opterećenja Izvor Zahtevi kvaliteta: podrška uređajima različitih proizvođača Svojstva proizvoda: dinamičko upravljanje uređajima Ograničenja: prilagodljivost Zahtevi kvaliteta: podrška višejezičnosti Svojstva proizvoda: internacionalizacija Zahtevi kvaliteta: podrška konverziji mernih jedinica Svojstva proizvoda: dinamička rekonfiguracija Ograničenja: prilagodljivost Zahtevi kvaliteta: usaglašenost s propisima Svojstva proizvoda: upravljanje događajima/alarmima Ograničenje: prilagodljivost Prioritet (posl/teh) visok/ visok srednji/ srednji visok/ srednji visok/ visok visok/ visok

38 4.3 Servisno orijentisana arhitektura (SOA) Arhitekturni stil projektovanja prilikom razvoja i integracije aplikacija servisje diskretna jedinica ponovo upotrebljive poslovne (ili tehničke) funkcije Objektno-orjentisan i pristup, koji se bavi podacima za implementaciju rešenja koristi otvorene standarde i softverske elemente kao servise aplikacije se sklapaju (assembly) od dobro definisanih komponenti jedan od načina za opis Web servisa je WSDL(Web Services Description Language) baziran na XML-u

39 4.4 Platforme Hardverske platforme(pc, Apple, Sun SPARC) Hardversko-softverske platforme (PC+Windows, Apple+OS X, Sun+Solaris) Softverske platforme Java platforma (Java ME/SE/EE) Microsoft.NET SAP NetWeaver IBM WebSphere LAMP/WAMP

40 Java platforma Prevođenje i pokretanje Java EE Tehnologije 4-slojne Java EE arhitekture Razvojni alati

41 Microsoft.NET platforma Naziv za integrisani skup različitih Microsoft tehnologija Platforma, jer obezbeđuje skup alata i mehanizama za razvoj i izvršavanje programa Ciljevi distribuirano računarstvo pojednostavljenje višestruke upotrebe komponenti Internet interoperabilnost (upotreba Web servisa) nezavisnost od programskog jezika integracija programskih jezika na nivou programiranja veća pouzdanost obezbeđenje bezbednosne infrastrukture

42 Microsoft.NET okvir(framework) Komponente.Net Visual Studio.NET Serveri BizTalk Server Commerce Server SQLServer Exchange Server CMS i dr.

43 IBM WebSphere Platforma za razvoj, isporuku i izvršavanje Webzasnovanih informacionih sistema razvojni alati (WebSphere Studio i IBM alati, npr. IBM Rational Software Architect) run-time alati (WebSphere Application Server, WebSphere MQ, WebSphere Enterprise Service Bus, WebSphere Commerce, WebSphere Portal)

44 SAP NetWeaver Poslovno orijentisana sopstvena platforma kompanije SAP za razvoj novih i integraciju postojećih informacionih sistema, koji koriste drugačiju infrastrukturu (.NET, Java, WebSphere) integracija informacija preko otvorenih standarda: XML, SOAP, UDDI, WSRP (Web Services for Remote Portlets) i WSBPEL (Web Services Business Execution) osnova za ESOA Cilj: integracija ljudi, informacija i poslovnih procesa

45 LAMP/WAMP LAMP-Platforma za razvoj softvera otvorenog koda (Linux, Apache, MySQL, Perl/Python/PHP) WAMP-Platforma za razvoj softvera otvorenog kodaza operativne sisteme Windows (Apache, MySQL, Perl/Python/PHP)

46 4.5 Kriterijumi kvaliteta arhitekture Osnovni kriterijumi (precizni, merljivi) Pouzdanost (reliability) Raspoloživost (availability) Prenosivost (portability) Skalabilnost (scalability) Performanse (performance) 46

47 Inženjerstvo performansi: osnovne performanse sistema Propusnost (throughput)- izvršeni rad u jedinici vremena transaction per secod (tps) messages per second(mps) srednja, masimalna, minimalna Vreme odziva (response time)-vreme od postavljanja do izvršenja nekog zahteva važno za sve interaktivne sisteme CPU % MST (mps) Broj niti (threads) 47

48 5. Primeri arhitekture 1. MVC arhitektura jednostavne konzolne aplikacije 2. MVC arhitektura.net aplikacije 3. Prikaz arhitekture u sistemu Visual Studio 4. Validacija logičke arhitekture u sistemu Visual Studio

49 5.1 MVC arhitektura jednostavne konzolne aplikacije Jednostavna konzolna aplikacija telefonski imenik Pregledati materijal r-hellorsav7-a4.pdfposvećenuml projektovanju i implementaciji aplikacije pomoću razvojnog alata IBM RSA Kreiranje UML dijagrama (dijagram slučajeva korišćenja, dijagram klasa i dijagram sekvenci) 2. Publikovanje dokumentacije projektovanog rešenja 3. Ažuriranje projekta u hodu (transformacija u Java kod i reverzni inženjering Java koda u UML dijagrame) 4. Implementacija i testiranje sistema (tekstualni interefjs)

50 Arhitektura aplikacije Arhitekturni obrazac MVC (Model-View-Controller) koji objektno orijentisanu aplikaciju deli u tri celine Model-upravlja podacima (npr. Java ili C# klase) View-upravlja prikazom informacija (npr. JSP ili ASP.NET) Controller-logika aplikacije (interpretira ulaze i prenosi zahteve) Postoji ASP.NET MVC

51 UML dijagram klasa kao model arhitekture aplikacije (statička struktura sistema)

52 5.2 MVC arhitektura.net aplikacije Tip projekta prema verziji.net, npr. ASP.NET MVC 4 Web Application Struktura foldera ASP.NET MVC aplikacije u sistemu Visual Studio 2010 C M V

53 5.3 Prikaz arhitekture u sistemu Visual Studio 1. Za prikaz logičkearhitekture dijagram klasa, paketa ili slojeva (Layer diagram) može se kreirati reverznim inženjeringom 2. Za prikaz zavisnosti i drugih relacija u postojećem kodu koriste se grafovi zavisnosti (Dependency graphs) 53

54 5.4 Validacija logičke arhitekture u sistemu Visual Studio Visual Studio 2010/2012/2013/2015 Architecture Explorer Struktura sistema UML dijagram komponenti UML dijagram klasa Dijagram slojeva (Layers): logička arhitektura sistema Validacija dijagrama slojeva Visual Studio 2017 dijagrami i validacija zavisnosti u realnom vremenu isualstudio.mp4

55 Literatura 1. Miškovic V., Projektovanje informacionih sistema (predavanja), Univerzitet Sinergija, Sommerville I., Software Engineering, 10thEd, Addison Wesley, Bruegge B., Dutoit A. H., Object-Oriented Software Engineering Using UML, Patterns, and Java, Prentice Hall, Schach S.R., Object-oriented Software Engineering, McGraw-Hill, Gorton I., Essential Software Architecture, Springer-Verlag, Berlin Heidelberg, Garland J., Anthony R., Large-Scale Software Architecture, John Waley & Sons, Sangwan R.S., Software and Systems Architecture in Action, CRC Press, Pressman C., Software Engineering: A Practitioner s Approach, 5thEd, McGrow- Hill, IBM Rational Product Training: DEV475 Mastering Object-Oriented Analysis and Design with UML 10. Priručnici za programske alate i Web reference 55

56 dr Vladislav Miškovic Projektovanje informacionih sistema Tema 5: Projektovanje arhitekture softverskih sistema Pitanja? 56

Abstract Cover letter. Igor Pašti

Abstract Cover letter. Igor Pašti Abstract Cover letter Igor Pašti Istraživanje Identifikacija tematike/pretraga literature Postavka eksperimenta Izrada eksperimenta Analiza i diskusija rezultata Priprema publikacije Proces publikovanja