Metodologija razvoja softvera Arhitektura softvera Prof dr Branko

Metodologija razvoja softvera Arhitektura softvera Prof. dr Branko Perišić: bperisic@singidunum. ac. rs

Pristupi razvoju softvera - Arhitektura Varijable Programska paradigma Strukture Klase, objekti Struktura problema Tipovi podataka Dizajnerski šabloni Komponente Arhitektura softvera Radni okviri (Frameworks)

Arhitektura - motivacija q Sa porastom OBIMA i KOMPLEKSNOSTI softverskih sistema izbor adekvatnih ALGORITAMA i STRUKTURA PODATAKA postaju MANJE VAŽAN u odnosu na izbor ISPRAVNOG SASTAVA (STRUKTURE); q Arhitektura softvera OPISUJE strukturu rešenja na APSTRAKTNOM i KONKRETNOM nivou; q Arhitektura softvera ima značajnu ulogu u različitim fazama životnog ciklusa softvera (razumevanje, analiza, ocena, upravljanje, ponovna upotreba, . . . ) Branko Perišić 3

Arhitektura - koristi q U literaturi postoji opšta saglasnost da osnovne prednosti (koristi) koje nastaju izradom i dokumentovanjem arhitekture softverskog proizvoda obuhvataju: v ANALITIČNOST (Analytical capability) v VIZUALIZACIJA STRUKTURE (Structural visibility) v USPOSTAVLJAVANJE UREĐENOSTI (Establish systems discipline) v OČUVANJE KONCEPTUALNOG INTEGRITETA (Maintain conceptual integrity) Branko Perišić 4

Arhitektura - definicija Pod arhitekturom podrazumevaju se: softverskih sistema q Topologija: v KOMPONENTE; v VEZE IZMEĐU KOMPONENTI; v VEZE SA OKRUŽENJEM q i principi koji definišu dizajn i ocenu (evaluaciju) topologije; 5

Arhitektura - IEEE 1471 standard koncepturalni radni okvir 6

Arhitektura – pozicioniranje I Branko Perišić 7

Arhitektura – pozicioniranje II Zainteresovane strane – skup uloga koje pokazuju interes za određene aspekte softverskog proizvoda. Definišu se u ranim fazama specifikacije projekta • Izrada vizije (specifikacija IDEJE); • Prikupljanje zahteva • Izrada specifikacije zahteva • Analiza zahteva • Izrada i Verifikacija modela zahteva Ponovo pojavljuju u Završnim : fazama implementacije proizvoda: 1. Funkcionalno testiranje 2. Test prihvatanja 3. Instalacija 4. Operativna upotreba Branko Perišić 8

Arhitektura – pozicioniranje III Tipične zainteresovane strane: q Klijent q Investitor q Vlasnik q Korisnik q Planer (Organizator) q Pružalac usluga q Posrednik q Prodavac q Podizvođač (Kooperant) q Rukovalac (Operativni) q Arhitekta sistema q Sistem inženjer q Projektant (Designer) q Programer q Konfigurator (Builder) q Serviser (Maintainer) Branko Perišić 9

Arhitektura – pozicioniranje III Branko Perišić 10

Arhitektura – Sistem Pod pojmom SISTEM podrazumevamo organizovan skup činilaca, sa jasno definisanim međusobnim vezama, koji deluju radi ispunjenja nekog postavljenog cilja. Bez obzira na način na koji je nastao, svaki pojedinačni sistem poseduje: (a) MISIJU (cilj ili skup ciljeva zbog kojih postoji) (b) ORGANIZACIONU STRUKTURU (skup činilaca i veze među njima koje formiraju topologiju sistema) (c) FUNKCIONALNU STRUKTURU (aktivnosti koje sprovodi) (d) INFORMACIONU STRUKTURU (sveukupnost semantičkih pretstava sa kojima i nad kojima obavlja funkcionalne transformacije (c)) (e) UPRAVLJAČKU STRUKTURU (prinudu, unutrašnju ili spoljašnju, koja usklađuje ukupno ponašanje sistema) (f) VEZE SA OKRUŽENJEM - KONTEKSTOM 11

Arhitektura – pozicioniranje IV Opis arhitekture – uključuje formalno predstavljanje arhitekture posmatranog sistema u formi specifikacija. Ø Postoji širok spektar načina SPECIFIKACIJE (OPISA) arhitekture softverskih sistema. Ø Izbor adekvatne specifikacije i implementacije arhitekture predstavlja “kvaran” problem (Problem koji znamo kako je trebalo da ga rešimo kada ga bar jednom rešimo kako nije trebalo!) 12

Arhitektura - IEEE 1471 standard koncepturalni radni okvir 13

Opis arhitekture (OA) Razdvajanje pogleda od pozicije (ugla posmatranja): POGLED (view): Pretstavlja OPIS SISTEMA sa aspekta skupa povezanih odgovornosti. Sastoji se od jednog ili više modela. ; POZICIJA (viewpoint): Definiše RESURSE i PRAVILA na osnovu kojih se gradi POGLED (view); Branko Perišić 14

Opis arhitekture (OA) pogledi Ø Arhitektonski pogledi: Konkretan OPIS sistema: Ø Podržavaju više uloga od kojih svaka može posedovati više odgovornosti; ost manjuje nu Ø razdvajanjem nadležnosti (separation of concerns); Branko Perišić 15

Opis arhitekture (OA) pogledi q Pogledi nisu ORTOGONALNI (postoji linearna ili nelinearna zavisnost između različitih pogleda) q Pogledi su MODULARNI: § Pogled može da sadrži jedan ili više modela arhitekture i omogućava: 1. Upotrebu više NOTACIJA 2. Delenje modela između različitih pogleda q Moraju dokumentovati prisustvo poznatih nekonzistentnosti između sadržanih pogleda. Branko Perišić 16

Opis arhitekture (OA) pogledi q Pogledi su DOBRO STRUKTURIRANI: Ø Svaki pogled (view) odgovara jednom i samo jednom uglu posmatranja (viewpoint); Ø Ugao posmatranja(viewpoint) definiše resurse i pravila za konstrukciju pogleda(view); q Odgovornosti upravljaju izborom pozicije: Ø Pogled uspostavlja svrhu i auditorijum kao i metode i tehnike koje će se, u sklopu pogleda, koristiti; Ø Svaka odgovornost je predmet opisa bar jednog pogleda; Branko Perišić 17

Opis arhitekture (OA) pogledi q Uobičajeni pogledi: v. Konceptualni pogled v. Funkcionalni pogled, v. Fizički pogled v. Tehnički pogled v. Pogled sa aspekta modula v. Pogled sa aspekta koda v. Pogled sa aspekta izvršavanja Branko Perišić 18

Pogled – primer modela Model mogućnosti (Capability): Branko Perišić 19

Opis arhitekture (OA) pogledi q Pozicije su koncepti prvog reda: Ø Striktno se definišu PRE UPOTREBE; q Ne postoji predefinisani skup pozicija: Ø Iskustvo u razvoju dovodi do formiranja biblioteke pozicija koja vremenom evoluira u radni okvir (framework). Branko Perišić 20

Opis arhitekture (OA) pozicije q Uobičajene pozicije: v Struktura (Structure); v Ponašanje (Behaviour); v Povezanost (Physical conectivity); v Dekompozicija (Decomposition); v Dodela (Allocation) v Organizacija (Enterprise) Branko Perišić 21

Arhitektura softvera ?

Metodologija razvoja softvera Arhitektura softvera - Šabloni Prof. dr Branko Perišić: bperisic@singidunum. ac. rs

Arhitektura - šabloni n Arhitektonski šablon predstavlja osnovnu strukturu organizacije softverskih sistema. n Obezbeđuje skup predefinisanih podsistema, podsistema njihovih odgovornosti, odgovornosti pravila i uputstava za organizaciju međusobnih veza tih podsistema. Branko Perišić 24

Arhitektura - šabloni n Grupe arhitektonskih šablona: n Šabloni arhitektonskih stilova n Opšta Struktura Slojevi (Layer) v Cevi i filtri (Pipes and Filters) v Tabla (Blackboard) v n Distribuirani sistemi v Posrednik (Broker) Mikrojezgro (Mikrokernel) v Cevi i filtri (Pipes and Filters) v Branko Perišić 25

Arhitektura - Slojevi n Pomaže prilikom strukturiranja aplikacije koju je moguće dekomponovati u grupe podzadataka pri čemu je svaka od tih grupa na posebnom nivou apstrakcije. 26

Arhitektonski Šabloni (3) n Grupe arhitektonskih šablona: n Šabloni arhitektonskih stilova n Interaktivni sistemi v Model-View-Control (MVC) v Presentation-Abstraction-Control (PAC) q Adaptivni sistemi q Mikrokernel q Odraz (Reflection) Branko Perišić 27

SOA – Servisno Orijentisana Arhitektura APLIKACIJE I SERVISI MREŽE i POZADINSKI ELEMENTI Postojeća infrastriktura ne poseduje dovoljan stepen agilnosti da bi održala korak sa poslovnim ciljevima

SOA – Servisno Orijentisana Arhitektura �Servis orijentisana arhitektura (SOA) predstavlja pristup računarskoj obradi baziran na: standardizovanim, slabo spregnutim i od protokola nezavisnim komponentama kod koje se pod servisima podrazumevaju softverski resursi raspoloživi na mreži. �Postoji uverenje da će SOA predstavljati tehnologiju budućnosti za tzv. enterprise rešenja, koja donosi agilnost i fleksibilnost za kojom su do sada tragali korisnici poslovnih sistema sa željom da obezbede informacionu integraciju posredstvom kompozicije servisa nad više

Karakteristike Granularnost servisa se �Softverske komponente kod odnosisunaservisi obim SOA funkcionalnosti koju servis eksponira. zasnovani na standardnim protokolima. Fino granulirani (mikroservisi) su �Servisi kod 1. SOA posedujuservisi minimalan stepen zavisnosti. od male koristi u poslovnim procesima kao što je npr. pristup podacima. �Komunikaciona infrastruktura koja se koristi u 2. se Servisi sa grubom se sklopu SOA projektuje tako dagranulacijom je nezavisna sastoje od fino granuliranih servisa koji od nivoa protokola. su ORKESTRIRANI sa ciljem �Nudi grube forme poslovnihpojedinačnih servisa, zaposlovnih razliku zadovoljavanja od finih pozivapotreba. softverskih funkcija. �Koristi granularnost servisa za obezbeđenje efektivne kompozicije, enkapsulacije i rukovanja servisima.

Kompozicija servisa

Rukovanje servisima �Postoje tri nivoa rukovanja servisima ◦ Rukovanje servisima i njihovim interfejsima ◦ Rukovanje “sadržanim” sistemom ◦ Rukovanje interakcijama između servisa i “sadržanog” sistema

Šta predstavljaju SOA koncepti? � Sisteme komponovane od autonomnih servisa � Servis je program sa kojim se stupa u interakciju posredstvom razmene poruka ◦ Predstavljaju trajna dobra ◦ Raspoloživost i stabilnost su kritična svojstva � Skup aktivnih servisa čini SISTEM. SOA predstavlja usklađenu (orkestriranu) sekvencu razmene poruka, transformacija, usmeravanja i obrade događaja kod koje XML tehnologije služe za predstavljanje sadržaja poruka i komponente koje rade nad porukama.

Sirvisi Objekti �Različit model raspoređivanja ◦ Servisi se “ugošćavaju” (to host), umesto “prosleđuju” (forward-deployed) ◦ Enkapsulacija je na nivou interfjesa, interfjesa umesto u sklopu implementacije ◦ Postoji mogućnost međuskladištenja i protočne obrade (pipeline processing) ◦ Postoji mogučnost kontekst osetljivog usmeravanja (contexti-sensitive routing) i usmeravanja na osnovu sadržaja (contentsensitive routing) �Integracija dizajna ◦ Sve platforme prihvataju ugovore i poruke ◦ Mogućnost razvoja zajedničkog modela entiteta sa

Prelazak na servise – mentalni model Sa Veze = trošak � Orijentacija na funkcije � Trajna rešenja � Produžen razvoj � • “Stovarište “aplikacija • Čvrsta sprega • Objekt-orijentisane Na Veze = vrednost � Orijentacija na procese � Promenljiva rešenja � Inkrementalna isporuka � • Orkestrirana rešenja • Slabo spregnuta • Orijentisana na poruke

Ključni koncepti orijentacije na servise Aplikacije Operacioni zahtevi Stanje sastavljene od nameće Politike poseduje rukovođeni rukuje Servisi ograničen sa razmenjuje Poruke Šablon za razmenu poruka Ugovori opisuje sadrži je skup Šema definiše strukturu

Korisnik – poslovni procesi – skladište Grubi Web Servisi Finiji Interni Servisi Fini pozivi Objekata i baze činjenica Business Component Korisnička Aplikacija Poslovni Procesi

MVC - koncept �MVC koncept dekomponuje aplikacije ili interfejse u tri dela: MODEL, MODEL POGLED i KONTROLER Model A --> 25 % B --> 60 % C --> 15 % Korisnik je u interakciji sa kontrolerom (npr. , dugmad), vrši izmene na modelu (npr. , podaci), što se odražava na pogled (npr. , graf). Pogled(i) Kontroler Draw Graph

Model-View-Controller (MVC) n Model - sadrži osnovnu funkcionalnost i enkapsulira strukturu podataka n Pogledi – prikazuju podatke korisniku. n Kontroleri – rukuju spregom sa korisnikom n Mehanizam propagacije promena osigurava konzistentnost između korisničkog interfejsa i modela. 41

MVC 42

Arhitektura: MVC obrazac pune linije: direktna asocija isprekidane linije: indirektna asocija (observer obrazac [pattern] )

MVC - struktura 44

MVC - Sekvenca 45

MVC - Inicijalizacija 46

MVC - prednosti n Više različitih pogleda na isti model n Sinhronizovani pogledi: propagacija promena n Jednostavno dodavanje pogleda i kontrolera n Jednostavna zamena spoljašnje pojave (‘look and feel’) n Poseduje potencijal za izgradnju frejmvork-a 47

MVC - mane n n n n Povečana kompleksnost Potencijalno veliki broj ažuriranja pri promeni elemenata modela Jaka sprega između Pogleda i Kontrolera Jako sprezanje (Pogleda i Kontrolera) sa Modelom Neefikasnost pristupa podacima u sklopu Pogleda Potreba za promenom Pgleda i Kontrolera pri prenosu u različita okruženja. Teškoće pri korišćenju MVC koncepta u kontekstu savremenih alata za kreiranje korisničkog interfejsa. 48

Arhitektura: Primer 1. Model odvojen od manipulacije podacima Branko Perišić

Arhitektura: Primer 2. Model povezan sa manipulacijom podacima Branko Perišić

M-V-C ili M-VC (Delegat) ? �M-V-C: odvajanje modela podataka, pogleda, i kontrolera koji upravlja pogledom i modelom podataka �M-VC: spajanje kontrolera i pogleda u jednu celinu (JAVA SWING – Model. Delegate) Branko Perišić

MVC u Swing-u �Swing koristi pojednostavljenu verziju MVC strukture, koja se naziva modeldelegat Swing Komponenta Pogled Model UI-delegat Kontroler Branko Perišić

SWING-MD arhitektura Svaki UI-delegat je izveden iz apstraktne (Model-delegate architecture) klase Component. UI čije metode opisuju Swing uključuje više grupa UI-delegata pri način na UI-delegat i komponenta Swing pakuje Pogled i Kontroler objekat koji se čemu svaka od koji njihuihjedan sadrži implementaciju koriste uzaprocesu Postoje tri osnovne implementacije PLAF komunikacije. : Swing componenti; naziva UI-delegat. Component. UI večinu Svaka metoda kao look parametar Windows: ove grupe obično nazivamo and feel prima ili objekatlook klase JComponent. com. sun. java. swing. plaf. windows. Windows. Look. And. Feel pluggable and feel (PLAF) CDEMotif: implementacije. com. sun. java. swing. plaf. motif. Motif. Look. And. Feel javax. swing. plaf paket sadrži apstraktne klase Metal (default): izvedene iz Component. UI dok klase iz javax. swing. plaf. metal. Metal. Look. And. Feel javax. swing. plaf. basic paketa proširuju ove apstraktne klase u cilju implementacije Basic look and feel. Branko Perišić

Implementacija: Controller �Observer klasa za view �“Vidi” model i view �Glavna uloga-state machine �Obaveštava view, menja model Branko Perišić

Implementacija: Controller �Mogućnost da se rastereti kontroler primenom command obrasca �Grupisanjem akcija Branko Perišić

MVC: Zašto? Pomaže pri razumevanje složenih Swing paketa. ? Postavlja okvir za razvoj budućih paketa Zbog čega je bitan? Omogućava korisničko podešavanje modela ili pogleda bez preprogramiranja oba sloja (Imate nešto drugo na umu? ) Branko Perišić

57

Arhitektura softvera ?