UML dijagrami u programskom inženjerstvu PDF - Zavod za elektroniku

Zavod za elektroniku, mikroelektroniku, računalne i inteligentne sustave PROGRAMSKO INŽENJERSTVO ak. god. 2021./2022. Primjena UML dijagrama u programskom inženjerstvu ...

Zavod za elektroniku, mikroelektroniku, računalne i inteligentne sustave PROGRAMSKO INŽENJERSTVO ak. god. 2021./2022. Primjena UML dijagrama u programskom inženjerstvu  Tema ◼ UML dijagram stanja ◼ sintaksa i semantika ◼ primjer ◼ UML dijagram aktivnosti ◼ sintaksa i semantika ◼ primjer ◼ UML dijagram komponenti ◼ sintaksa i semantika ◼ primjer ◼ UML dijagram razmještaja ◼ sintaksa i semantika ◼ primjer Pripremili i prilagodili: Vlado Sruk, Alan Jović, Nikolina Frid Ovaj dokument namijenjen je studentima Fakulteta elektrotehnike i računarstva Sveučilišta u Zagrebu. U pripremi materijala osim literature upotrijebljeni su materijali nastali tijekom godina na predmetu Oblikovanje programske potpore i drugi izvori, te zahvaljujem autorima. Primjena UML dijagrama u programskom inženjerstvu 2  Literatura ◼ About the Unified Modeling Language Specification Version 2.5.1, Omg.org, https://www.omg.org/spec/UML/. ◼ B. Unhelkar, Software Engineering With UML.: Auerbach Publications, 2020. ◼ Simon Bennett, John Skelton, Ken Lunn: Schaum's Outline of UML, Second Edition, 2005 ◼ Zadaci za vježbu ◼ https://moodle.fer.hr/mod/url/view.php?id=10302 ◼ A. Jović, M. Horvat, I. Grudenić: “UML dijagrami – Zbirka zadataka i riješenih primjera” (sveučilišni priručnik) Primjena UML dijagrama u programskom inženjerstvu 3  UML 2.5 UML dijagrami Strukturni Ponašajni dijagram razreda obrasci uporabe dijagram složene strukture dijagram stanja objektni dijagram dijagram aktivnosti dijagram komponenti Interakcija dijagram implementacije sekvencijski dijag. dijagram paketa dij. komunikacije dijagram profila pregled interakcije dijagram razmještaja vremenski dijag. Primjena UML dijagrama u programskom inženjerstvu 4 UML DIJAGRAM STANJA  UML Dijagram stanja ◼ engl. UML State Machine Diagram ◼ Opisuje dinamičko ponašanje dijela sustava (objekt, komponenta, podsustav…) u vremenu ◼ objekt (dio sustava) se promatra izolirano od ostatka sustava ◼ izlaz ne ovisi samo o trenutnim ulazima nego i o povijesti ◼ pogodno za opis diskretnog ponašanja (engl. discrete-event) ◼ Prikazuje stanja objekta te prijelaze iz jednog stanja u drugo temeljene na događajima ◼ stanje modelira situaciju tijekom koje vrijedi određeni skup uvjeta ◼ sadrži konačan broj stanja i prijelaza između stanja ◼ unutar stanja mogu se odvijati određene aktivnosti ◼ U OOA se koristi za opis ponašanja razreda ◼ dijagram stanja definira se za razred, a svaki objekt (instance razreda) ima svoj vlastiti automat Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 6  Aktivnosti OO oblikovanja Izlučivanje Dijagram Funkcionalni zahtjevi obrazaca zahtjeva uporabe Nefunkcionalni zahtjevi Sekvencijski dijagram Ponašajni model Analiza Dijagram stanja Objektni model Dijagram razreda Oblikovanje sustava Prilagođeno na temelju: Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering Using UML, Patterns, and Java 3rd Edition„ … Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 7  Stanje ◼ Stanje objekta je definirano skupom invarijanti ◼ skup zadovoljenih uvjeta, određena vrijednost jednog ili više atributa objekta ◼ 1 početno stanje, 0..* krajnjih stanja ◼ Unutar stanja: ◼ entry – akcija pri ulasku u stanje ◼ do – aktivnost koja se izvodi sve dok je stanje aktivno ◼ interni prijelazi - događaji koji pokreću kratkotrajne i neprekidive akcije ◼ exit – akcija pri izlasku iz stanja naziv stanja interni prijelaz Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 8  Prijelazi ◼ engl. transition ◼ Dozvoljene promjene stanja iz trenutnog u novo stanje ◼ može biti to isto stanje ◼ Potaknuti događajima uz zadovoljenje uvjeta ◼ KADA se nešto dogodi, AKO je zadovoljen uvjet” ◼ interakcija ◼ asinkroni prijem signala – primljene poruke (engl. signal) ◼ sinkroni poziv objekta (engl. call) ◼ vremenski ◼ proteklo vrijeme – istek vremenskog intervala ◼ apsolutno vrijeme – unaprijed zadani vremenski trenutak ◼ mogu prenositi parametre ◼ Sintaksa: događaj [uvjet]/akcija [ [‘,’ ]* [‘[‘ ’]’] [‘/’ ]] ◼ Moguć implicitni prijelaz nakon završetka aktivnosti složenog stanja ◼ Trajanje izvođenja prijelaza je 0 i ne može se prekinuti Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 9  Primjer ◼ Npr: prodaja dionica (bid = ponuđena cijena) uvjet događaj akcija Prijelaz u isto stanje Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 10  Pseudostanja ◼ Vrsta stanja u UML metamodelu koje predstavlja točku prijelaza unutar dijagrama stanja početno stanje povijest (engl. *najviše jedno H shallow history) završno stanje *pamti posljednje stanje na *ne mora uopće postojati istoj razini duboka povijest izbor (engl. choice) (engl. shallow history) H* spajanje (engl. junction) *pamti posljednje stanje na svim razinama grananje/račvanje ulazna točka (engl. fork) *ulazak u složeno stanje *početak paralelizma izlazna točka *izlazak iz složenog stanja spajanje/sinkronizacija završetak (engl. (engl. join) *završetak paralelizma terminate) *kraj postojanja objekta čija su stanja modelirana, ne izvode se exit akcije Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 11  Uvjetna grananja ◼ Statičko uvjetovanje grananja ◼ uvjeti su poznati prije grananja odluka ovisi o varijabli value čija je vrijednost unaprijed poznata Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 12  Uvjetna grananja ◼ Dinamičko uvjetovanje grananja ◼ uvjeti se izračunavaju pri izlasku iz stanja - evaluiraju se u točki grananja odluka ovisi o varijabli gain čija se vrijednost izračunava tek u trenutku odluke Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 13  Složeno stanje ◼ engl. composite state ◼ Interna struktura sastavljena od više podstanja (engl. substate) ◼ moguće je višerazinsko ugnježđivanje stanja – hijerarhija stanja (engl. hierarchically nested states) ◼ podstanja mogu biti slijedna ili paralelna (ortogonalna) ◼ složeno stanje ima jednu ili više regija ◼ svaka regija može imati početno i završno pseudostanje ◼ ulazak u složeno stanje podrazumijeva prijelaz u početna pseudostanja svake regije ◼ ako složeno stanje ima definiranu ulaznu točku, iz nje ide prijelaz u točno jedno stanje u svakoj regiji ◼ ako složeno stanje ima definiranu izlaznu točku, prijelaz iz nekog podstanja (u bilo kojoj regiji) u izlaznu točku implicitno označava i izlaz iz složenog stanja (aktivira exit akcije) ◼ regije su međusobno ortogonalne ◼ Olakšava prikaz složenih problema ◼ ako je sustav u ugnježdenom stanju/podstanju (engl. nested states,substate) podrazumijeva se da je ujedno i u stanju nadređene hijerarhije ◼ Kada ne stane na isti dijagram označava se simbolom Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 14  Primjer prijelazom iz stanja verifyCard u stanje readAmount, implicitno se dolazi u početno pseudostanje iz kojeg implicitno ide prijelaz u podstanje selectAmount 15 u stanju readAmount dolaskom u završno pseudostanje implicitno se izlazi iz stanja readAmount i prelazi u stanje verifyTransaction Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja  Hijerarhija stanja ◼ Redoslijed akcija: ◼ IZLAZI iz stanja se izvode PRIJE akcije PRIJELAZA, iznutra prema van ◼ ULAZI u stanje se izvode NAKON akcije PRIJELAZA, izvana prema unutra exS11 → ex S1 → actE → enS2 → initS2 → enS21 Najprije se ulazi u stanje S1, a odmah zatim u stanje S11. Na događaj E, najprije se izlazi iz S11 (izlazna akcija exS11), zatim iz S1 (izlazna akcija exS1). Zatim se obavlja akcija prijelaza (actE). Slijedi ulazak u S2 i obavljanje akcije enS2, zatim se odmah ulazi u S21 (akcija initS2 - prijelaz iz pseudostanja i enS21 - akcija ulaza u stanje S21). Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 16  Ortogonalna područja ◼ engl. orthogonal regions ◼ Složeno stanje podijeljeno u dva ili više područja odvojena crtkanom linijom ◼ Jedno stanje svakog područja je uvijek aktivno u bilo kojem trenutku ◼ istodobnost podstanja (engl. concurrent substates) ◼ Moguće modelirati ◼ jedan objekt s kompleksnom logikom - nema istodobnosti ◼ višestruka perspektiva jednog objekta, smanjuje broj stanja ◼ istodobnost podobjekata ◼ Ulaz: prijelaz u stanje s ortogonalnim područjima aktivira početna stanja svih područja ◼ moguć i eksplicitan ulaz ◼ Izlaz: završno stanje mora biti dostignuto u svim područjima prije izlaza ili mora biti definirana izlazna točka ◼ moguć eksplicitan izlaz Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 17 Primjeri ortogonalnosti Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 18  Primjer višestruke perspektive ◼ Višestruka perspektiva istog objekta ◼ istodobno reagiraju na iste događaje financije dob dob financije Dijete Dijete Siromašan bankrotirao postao punoljetan postao punoljetan zaradio 1M EUR Siromašan Odrastao Odrastao Bogat zaradio 1M EUR otišao u mirovinu otišao u mirovinu bankrotirao Umirovljenik Umirovljenik Bogat Može li postojati interakcija između područja? Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 19  Interakcija između područja ◼ Uporabom dijeljenih varijabli Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 20  Povijest ◼ Mogućnost povratka na prethodno stanje ◼ povijest – engl. Shallow History (H) ◼ povratak na posljednje posjećeno stanje na istoj razini ◼ duboka povijest - engl. Deep History (H*) ◼ povratak na posljednje stanje (bez obzira na kojoj razini se dogodio prekid) povijest (Shallow History) Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 21  Duboka povijest ◼ Potrebna kod složenih stanja s više od dvije razine Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 22  Eliminacija višestrukih prijelaza ◼ Česti su prijelazi iz više stanja u jedno ◼ pogreška ◼ izlaz Greška ◼ prekid ◼ iznimka ◼ Duplikati se mogu kombinirati u jedan prijelaz ◼ prijelaz iz nadređenog vrijedi za sva obuhvaćena stanja Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 23  Varijable stanja ◼ engl. extended state variable ◼ pojednostavnjuju modeliranje Mealyev automat Mooreov automat - izlaz je funkcija ulaza i trenutnog stanja - izlaz je funkcija trenutnog stanja Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 24  Primjer ◼ Vrijednost varijable x nakon događaja e1 e2 e3 e6 e7 ? Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 25  Rješenje 1: start/ x=3 2: entryA/ x=x*2 3: e1 4: entryC / x++ 5: entryG / x++ 6: e2/ x=x*2 7: e3 8: exitG/ x=x-2 9: entryH/ x = x:2 10: e6 Kada se dogodi prijelaz mora se prvo izaći iz hijerarhije stanja (obavljaju se sve izlazne akcije). 11: exitC / x— 12: exitA/ x— Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 26  Rješenje - nastavak … Tek nakon toga se obavlja akcija prijelaza. 13: x=(x*4)+2 (od e6) 14: e7 15: exitY/ x=x:2 16: entryA/ x=x*2 17: entryC/ x++ 18: entryG/ x++ Ulaz u G je zbog init-a u stanju C Shallow history pamti posljednje stanje na ISTOJ RAZINI, a to je C. Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 27  Primjer – duboka povijest ◼ Što kad bi se radilo o H* (deep history)? … (sve isto) 14: e7 15: exitY/ x=x:2 16: entryA/ x=x*2 17: entryC/ x++ 18: entryH/ x=x:2 Posljednje stanje unutar stanja A je bilo stanje H (gledaju se sve razine). Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 28  Primjer: Sustav za praćenje kvalitete zraka ◼ Modelirati stanja razreda MjernaPostaja ◼ Koraci: 1. Identificirati temeljna stanja 2. Odrediti prijelaze između stanja 3. Razrada stanja ◼ odrediti ulazne i izlazne akcije te aktivnosti unutar stanja ◼ odrediti moguća podstanja Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 29  Razred Mjerna postaja ◼ Prošireni opis: ◼ Prilikom dodavanja u sustav, svaka mjerna postaja je neaktivna (isključena). U svakom trenutku moguće ju je uključiti čime ona postaje aktivna ili isključiti čime ponovno postaje neaktivna. Samo neaktivnu postaju je moguće ukloniti iz sustava. ◼ Aktivna postaja prati stanje senzora s kojih prikuplja podatke. Senzor postaje aktivan uključivanjem, a neaktivan isključivanjem. Inicijalno su svi senzori isključeni. Aktivni senzori mogu biti ispravni ili pokvareni. Pri uključivanju senzor se smatra ispravnim. ◼ Svakih 5 min postaja pokušava očitati svaki ispravni aktivni senzor. Ukoliko očitanje senzora ne uspije, senzor se smatra pokvarenim i do isključenja ga se više ne očitava. Dok ima pokvarenih senzora šalje se SMS dežurnom djelatniku svakih 60 min. Unatoč pokvarenom senzoru, postaja dalje nastavlja s ciklusom očitavanja ispravnih senzora svakih 5 min. Ukoliko očitana vrijednost prijeđe graničnu, izdaje se upozorenje. ◼ Aktivna mjerna postaja mora se povezati putem interneta sa fizičkom postajom na kojoj su senzori. Veza može biti uspostavljena ili prekinuta. Inicijalno se veza smatra prekinutom. Mjerenja sa senzora je moguće dohvatiti samo kada je veza uspostavljena. ◼ Aktivna postaja svakih 30 min sprema podatke dobivene sa senzora u bazu podataka. Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 30  Analiza dijagrama razreda ◼ Stanje vezano uz vrijednosti atributa razreda ◼ Događaji i akcije na događaje vezani uz metode razreda Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 31  Korak 1: identificiranje stanja ◼ Stanja postaje: ◼ Aktivna ◼ postaje aktivna uključivanjem ◼ vrijednost varijable status = TRUE ◼ Neaktivna ◼ početno stanje prilikom dodavanja u sustav ◼ ako je bila aktivna, postaje neaktivna isključivanjem ◼ vrijednost varijable status = FALSE ◼ neaktivnu postaju je moguće ukloniti ◼ brisanje objekta tipa MjernaPostaja Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 32 Korak 2: identificiranje prijelaza Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 33  Korak 3: razrada stanja ◼ Neaktivna ◼ po ulasku vrijednost varijable status postaviti u FALSE ◼ Aktivna ◼ po ulasku vrijednost varijable status postaviti u TRUE ◼ prati stanje senzora: aktivni/neaktivni, reagira na uključivanje i isključivanje senzora ◼ aktivni senzori mogu biti: ispravni ili pokvareni ◼ dok ima pokvarenih senzora šalje se upozorenje dežurnom djelatniku svakih 60 min ◼ prati stanje internet veze s fizičkom postajom: uspostavljena/prekinuta ◼ senzore se može očitati samo kad je veza uspostavljena ◼ svakih 30 min sprema podatke u bazu Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 34  Rješenje Interakcija između područja se ostvaruje varijablom veza Primjena UML dijagrama u programskom inženjerstvu: Dijagram stanja 35 UML DIJAGRAM AKTIVNOSTI  UML dijagram aktivnosti ◼ engl. UML Activity Diagram ◼ Aktivnost - modeliranje ponašanja nizom akcija ◼ mogu biti definirani odgovarajući uvjeti prije izvođenja (engl. preconditions) i nakon izvođenja (engl. postconditions) ◼ Primjenjuju se za modeliranje: ◼ poslovnih procesa – tijek zadataka i poslova ◼ upravljačkog i podatkovnog toka ◼ analiza tijeka obrazaca uporabe i tijeka između različitih obrazaca uporabe ◼ oblikovanje detalja operacija i algoritama ◼ Semantika zasnovana na Petrijevim mrežama ◼ modeliranje toka upravljanja ◼ novi korak nakon završenog prethodnog (neovisno da li su ulazi dostupni, ispravni ili potpuni u tom času) – tzv. “pull” način djelovanja ◼ modeliranje toka podataka ◼ sljedeći korak kada su svi ulazni podaci dostupni – tzv. “push” način djelovanja ◼ Pogodni za opisivanje sinkronizacije i konkurentnosti ◼ Ne primjenjuju se za modeliranje događajima poticanog ponašanja Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 37  Elementi ◼ Čvorovi (eng. Activity nodes) ◼ čvor akcije (eng. action node) ◼ kratkotrajno, neprekidivo ponašanje ◼ mogu biti definirani odgovarajući lokalni uvjeti prije izvođenja (eng. local preconditions) i nakon izvođenja (engl. local postconditions) ◼ upravljački čvor (eng. control node) ◼ objekt (eng. object node) ◼ Veze (eng. Activity edges) ◼ upravljački tijek (eng. control flow) ◼ tijek objekta kroz aktivnosti (eng. object flow) ◼ Particije (eng. swim lanes) ◼ Grupiranje (vrlo često po aktorima koji sudjeluju u izvođenju aktivnosti) → Aktivnost obuhvaća više čvorova i veza koji predstavljaju odgovarajući slijed zadataka Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 38  Značke ◼ engl. tokens ◼ dio semantike bez grafičkog prikaza ◼ Modeliraju izvođenje aktivnosti ◼ proizvode ih čvorovi ◼ kreću se od izvorišta prema odredištu vezama ovisno o: ◼ ispunjenim uvjetima izvornog čvora ◼ postavljenim uvjetima veza (engl. edge guard conditions) ◼ preduvjetima ciljnog čvora Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 39  Čvor akcije ◼ Započinje izvođenje kada: ◼ postoji odgovarajući broj znački na svim ulazima ◼ zadovoljeni su svi lokalni preduvjeti akcije ◼ Nakon izvođenja: ◼ provjerava se zadovoljavanje izlaznih uvjeta akcije ◼ prosljeđuju se značke na sve izlaze Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 40  Tipovi čvorova akcije ◼ Pozivanje akcije (engl. call action) ◼ obrada osnovnih operacija ◼ pozivanje složenih aktivnosti ili ponašanja ◼ Slanje signala (engl. send signal) ◼ asinkroni signal Popuni zahtjev ◼ Prihvaćanje događaja (engl. accept event) Potvrda plaćanja ◼ čekanje na neki događaj ◼ Vremenski događaj (engl. time event) čekaj 10 s ◼ definiran vremenskim izrazom Početak semestra Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 41  Upravljački čvorovi ◼ Početni čvor ◼ Završni čvor moguće je postojanje više od jednog početnog čvora kraj jednog toka kraj cijele aktivnosti (ne utječe na ostale tokove) ◼ Čvor odluke prije prosljeđivanja značke na izlaz ◼ Spajanje (eng. merge) evaliraju se uvjeti izlaznih grana svi tokeni s ulaza prosljeđuju se na izlaz, nema sinkronizacije ◼ Grananje (eng. fork) ◼ Sinkronizacija (eng. join) početak paralelnog kraj paralelnog izvođenja dvaju ili izvođenja dvaju ili više tokova više tokova Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 42  Tijek znački značka Generiraju se 2 značke Ovisno o ispunjenju uvjeta izvršit će se samo jedna grana (1 značka) Moraju stići obje značke da bi se nastavilo dalje Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 43  Podjela aktivnosti – particije ◼ Dijagram aktivnosti može biti Obrada pogreške Mjesto podijeljen u particije (engl. Zagreb Sisak swim lanes) Razvoj Podrška Uprava ◼ horizontalno, vertikalno, Prijava pogreške proizvoljno ◼ hijerarhija [else] A ◼ Ne utječu na tijek odvijanja popravak [prioritet=1] aktivnosti vrednovanje ◼ način grupiranja testiranje planiranje A testiranje Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 44  Objektni čvorovi ◼ Prikazuju podatke i objekte ◼ objektni čvor ukazuje na raspoloživost u danoj točki aktivnosti ◼ uobičajeno označeni imenom razreda i predstavljaju instancu ◼ Ulazne i izlazne veze predstavljaju tok objekta ◼ opisuju kretanje objekta unutar aktivnosti ◼ Objekte stvaraju i upotrebljavaju akcijski čvorovi ◼ Objektne značke ◼ kada objektni čvor primi značku, nudi ju na svim izlaznim vezama koje se natječu za značku. Značku dobiva prva veza koja ju je spremna prihvatiti ◼ Objektni čvorovi se ponašaju kao međuspremnici (engl. buffer) ◼ pohranjuju objektne značke Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 45  Priključnice ◼ engl. pins ◼ Objektni čvor s jednim ulazom ili izlazom prema čvoru akcije ◼ može prikazati naziv, stanje i brojnost. ◼ Pojednostavljuju grafički prikaz dijagrama aktivnosti s većim brojem objektnih čvorova Učitaj broj kartice[ispravan] broj kartice Verificiraj korisnika Učitaj PIN[ispravan] PIN Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 47  Primjer uporabe signala Objektni čvor U dijagramu aktivnosti katkada je potrebno poslati ili primiti signal. Signal slanja (engl. send) preslikava se u prijelaz i akciju slanja signala ▪ moguće je poslati objekt Signal primitka (engl. receive) preslikava se u stanje čekanja na signal bez akcije Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 48  Područje aktivnosti ◼ engl. Expansion Region ◼ posebno označeno područje ◼ Stereotip označava svojstva područja ◼ «parallel» ◼ «iterative» ◼ «stream » ◼ engl. Interruptible Activity Region ◼ Područje čija aktivnosti može biti prekinuta ◼ crtkani okvir ◼ signal prekida ◼ akcija obrade prekida ◼ započete akcije se obavljaju do završetka, a prekid nakon toga upravljanje predaje akciji obrade prekida Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 49  Podaktivnost ◼ engl. Subactivity ◼ Namjena funkcionalne dekompozicije ◼ Ugniježđenje drugog dijagrama aktivnosti ◼ Ulaskom u podaktivnost pokreće se njegova početna akcija ◼ Po završetku podaktivnosti, nastavlja se izvođenje prethodne aktivnosti ima daljnje podaktivnosti Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 50  Koraci oblikovanja 1. Pronalaženje aktora i obrazaca uporabe 2. Identificiranje ključnih scenarija ◼ Identificiranje aktivnosti (korake) procesa ◼ Odredite tko / što obavlja aktivnosti (korake postupka) 3. Kombiniranje scenarija za izradu opsežnih tijekova rada opisanih pomoću dijagrami aktivnosti 4. Odredite točke odlučivanja (ako-tada) 5. Odredite je li korak u petlji 6. Odredite paralelnost 7. Utvrdite redoslijed aktivnosti 8. Gdje je to prikladno, pridružite aktivnosti područjima (engl. swimlanes) 9. Razmotrite potrebu ugniježđenih aktivnosti Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 51  Primjer: Sustav za praćenje kvalitete zraka ◼ Modelirati tijek aktivnosti dohvata povijesnih podataka ◼ modeliranje tijeka obrasca uporabe – visoka razina apstrakcije ◼ primjenjivo tijekom oblikovanja ◼ Koraci: 1. Pronalaženje aktora i obrazaca uporabe 2. Identificiranje ključnih scenarija 3. Određivanje točki odlučivanja 4. Utvrđivanje redoslijeda aktivnosti 5. Pridruživanje aktivnosti područjima Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 52  Primjer: Sustav za praćenje kvalitete zraka ◼ Obrazac uporabe UC2 ◼ Aktori i aktivnosti ◼ Korisnik ◼ šalje upit za određeno mjesto i razdoblje ◼ Web aplikacija ◼ prosljeđuje upit bazi ◼ na temelju rezultata, ako ima podataka, sastavlja izvješće ◼ prikazuje izvješće korisniku ◼ Baza podataka ◼ isporučuje podatke na upit aplikacije Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 53 Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 54  Primjer: Sustav za praćenje kvalitete zraka ◼ Modelirati izvođenje operacije ocitajSenzore razreda MjernaPostaja ◼ niska razina apstrakcije - primjenjivo tijekom implementacije ◼ opis ponašanja zadan kod primjera dijagrama stanja (sl. 30) ◼ dodatak opisu: ◼ vremenski brojač od 5 min se postavlja izvan metode ocitajSenzore i po njegovom isteku se poziva metoda ocitajSenzore ◼ veza s postajom se pokušava uspostaviti unutar metode ocitajSenzore, najviše 3 puta i ako ne uspije, metoda završava ◼ slanje SMS-a i čekanje od max 60 min na odgovor dežurnog djelatnika treba obaviti korištenjem zasebne dretve koja se stvara i pokreće iz metode ocitajSenzore ◼ nakon što je očitala sve aktivne i ispravne senzore, metoda završava izvođenje Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 55 Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 56  Primjer: Sustav za praćenje kvalitete zraka ◼ Komentari na prethodni dijagram: ◼ objekt Mjerenje je instanca razreda Mjerenja unutar kojeg je pohranjena vrijednost očitanja koja se provjerava i zato je svakako dobro istaknuti taj objekt na dijagramu ◼ objekt SMS predstavlja instancu jedne SMS poruke, ali nije ga nužno navesti budući da njegov sadržaj nije relevantan za ovaj dijagram ◼ uočiti čvorove kraja toka na krajevima paralelnih grana ◼ ako bi se umjesto toga upotrijebio čvor , završetkom jedne paralelne grane bi završila cijela aktivnost što nije dobro ako je npr. dretva koja šalje SMS i čeka na odgovor dežurnog djelatnika još aktivna Primjena UML dijagrama u programskom inženjerstvu: Dijagram aktivnosti 57 UML DIJAGRAM KOMPONENTI  UML dijagram komponenti ◼ engl. UML Component Diagram ◼ Strukturni, statički UML dijagram – dio specifikacije arhitekture programske potpore ◼ vizualizacija organizacije i međuovisnosti između implementacijskih komponenata (interna struktura) te odnos programske potpore prema okolini ◼ naglasak na implementaciju sustava ◼ modeliranje komponenti započinje nakon što je oblikovanje sustava dovršeno ◼ oblikuju ih arhitekti programske potpore i programeri ◼ Posebno pogodan za komponentno-usmjeren model razvoja PP (engl. Component- Based Development) i uslužno-orijentiranu arhitekturu (engl. Service-Oriented Architecture) ◼ organiziranje sustava u upravljive, ponovo uporabljive i zamjenjive dijelove ◼ utvrđivanje koraka implementacije sustava ◼ određivanje prioriteta aktivnosti provedbe ◼ Osnovni elementi: ◼ komponente – zasebna enkapsulirana cjelina programske potpore koje su zamjenjive i ponovno iskoristive ◼ sučelja – imenovani skup javno vidljivih atributa i apstraktnih operacija ◼ poveznice – spojnica, delegacija i ovisnost Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 59  Komponenta ◼ engl. component ◼ Zasebna enkapsulirana cjelina programske potpore s dobro definiranim sučeljem ◼ Predstavljaju veće cjeline programskog koda koje su zamjenjive (s komponentama jednakih sučelja i funkcionalnosti) i ponovno iskoristive ◼ viša razina apstrakcije od razreda ◼ može sadržavati druge komponente – prikaz interne strukture ◼ definira ponašanje kroz ponuđena i zahtijevana sučelja ◼ mogu imati definirane portove (engl. port) – točka interakcije s okolinom ◼ Mogu imati definirane stereotipove: ◼ entity, process, service, subsystem … ◼ Vrste: ◼ logičke – npr. poslovna logika, procesi … ◼ fizičke – npr. EJB, COM+ and.NET, WSDL, CORBA… Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 60  Sučelje ◼ engl. interface ◼ Imenovan skup javno vidljivih atributa i apstraktnih operacija ◼ implementaciju osiguravaju razredi uključivanjem atributa i implementacijom operacija ◼ Tipovi sučelja: ◼ Ponuđeno/implementirano sučelje – engl. provided interface ◼ usluga koja se nudi ◼ ostvaruje komponenta (tj. razredi unutar komponente) ◼ Zahtijevano sučelje – engl. required interface ◼ ono što je potrebno komponenti za njezin rad (a nudi ga neku druga komponenta) Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 61  Poveznice ◼ Tipovi poveznica: ◼ Spojnica (engl. assembly connector) ◼ povezuje sučelja komponenti unutrašnje strukture koje surađuju ◼ “ball-and-socket”, “lollipop” ◼ Delegacija (engl. delegation connector) ◼ povezuje vanjsko sučelje komponente s internom strukturom ◼ interakcija s okolinom preko portova ◼ Ovisnost (engl. dependency) ◼ komponenti je za rad potrebna neka druga komponenta, ali nije «executable» FERweb eksplicitno definirano sučelje preko «uses» kojeg te komponente komuniciraju «component» «component» Moodle ISVU Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 62  Modeliranje komponenti 1. Identificirati komponente i ovisnosti 2. Prepoznati razine podkomponenti 3. Utvrditi i definirati sučelja između komponenti ◼ Iterativni postupak: ◼ dodavanja komponenti na dijagram ◼ grupiranja (po potrebi) ◼ dodavanja pomoćnih komponenti ◼ određivanje odnosa između elemenata Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 63  Primjer: Sustav za praćenje kvalitete zraka ◼ Modelirati komponente sustava ◼ Uz osnovni tekst zadataka uzeti u obzir: ◼ Klijent (korisnik) pristupa web aplikaciji koristeći web preglednik i sučelje REST API ◼ podržane su operacije GET i POST protokola HTTP ◼ Web aplikacija je organizirana modularno: ◼ modul Podaci je zadužen za dohvat i obradu podatka iz baze preko sučelja SQL API ◼ modul Logika je zadužen za komunikaciju s fizičkim mjernim postajama i modulom Podaci ◼ modul REST odgovara na upite klijenta i komunicira s modulom Logika ◼ Na fizičkoj mjernoj postaji aplikacija SWPostaja kominicira s web aplikacijom preko sučelja PostajaSSH Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 64 Primjer: Sustav za praćenje kvalitete zraka u sučelju komponente moguće je deklarirati operacije na isti način kao i na dijagramu razreda Primjena UML dijagrama u programskom inženjerstvu: Dijagram komponenti 65 UML DIJAGRAM RAZMJEŠTAJA  UML dijagram razmještaja ◼ engl. UML Deployment Diagram ◼ Strukturni statički UML dijagram koji opisuje topologiju sustava i usredotočen je na odnos sklopovskih i programskih dijelova ◼ ostvarenje u obliku koda i podataka koji se nalaze i izvršavaju na računalnim resursima ◼ prikaz sklopovskih komponenti, komunikacijskih puteva te smještaja i izvođenja programskih artefakata ◼ Vrste: ◼ specifikacijski dijagram razmještaja ◼ dijagram razmještaja instanci ◼ implementacijski dijagram ◼ dijagram mrežne arhitekture ( uobi;ajeno se ne upotrebljabva yapis u uUML formatu) ◼ Osnovni elementi: ◼ čvorovi – uređaji i okolina izvođenja ◼ artefakti (programske komponente) – implementirani moduli i podaci ◼ spojevi (veze) – komunikacijski putevi Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 67  Elementi dijagrama razmještaja ◼ Čvorovi (engl. nodes) ◼ Uređaj (engl. device) ◼ oznaka (engl. stereotype): ◼ stvarni uređaji (npr. računalo, pamenti telefon) i virtualni stroj niže razine (npr. XenServer) ◼ Okolina izvođenja (engl. execution environment) ◼ oznaka: ◼ programski sustav: OS, virtualni stroj više razine ◼ npr., VirtualBox, JRE, Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 68  Elementi dijagrama razmještaja (2) ◼ Artefakti ◼ Konkretne realizacije programskih komponenti ◼ datoteke s izvornim i izvršnim kodom, tablice u bazama podataka, skripte, knjižnice… ◼ stereotipovi: document, executable, file, library, script, source … ◼ Izvršavaju se na čvorovima ◼ Ovisnosti (engl. dependencies) – prikazuju odnos između artefakata Artefakt “App.jar” ovisi o artefaktu “Hibernate3.jar” (*međuovisne komponente mogu biti i na različitim čvorovima) Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 69  Vrste dijagrama razmještaja ◼ Specifikacijski dijagram (engl. Specification Level Deployment Diagram) ◼ prikazuje pregled implementacije artefakata bez upućivanja na specifične slučajeve artefakata ili čvorova ◼ Dijagram razmještaja instanci (engl. Instance Level Deployment Diagram) ◼ prikaz razmještaja instanci artefakta na specifične uređaje ◼ pogodno za dokumentaciju različitih okolina (razvojan, ispitna, produkcijska…) ◼ Implementacijski dijagram (engl. Implementation/Manifestation of components by artifacts) ◼ prikazuje implementaciju komponenti pomoću artefakata te unutarnju strukturu artefakata ◼ Dijagram mrežne arhitekture (engl. Network Architecture) ◼ logička ili fizička mrežna arhitektura sustava Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 70 Primjer: specifikacijski dijagram Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 71  Primjer: dijagram instanci naziv instance: vrsta instance Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 72  Primjer: implementacijski dijagram artefakt artefakti artefakti 73 implementacija implementacija komponente Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja  Primjer: Sustav za praćenje kvalitete zraka ◼ Prikaz razmještaja dijelova sustava na razini specifikacije ◼ Uz osnovni tekst zadataka uzeti u obzir: ◼ Web aplikacija je zapakirana kao arhiva “WebApp.war” i nalazi se na Tomcat web poslužitelju na kojem se nalazi web aplikacija ◼ Baza podataka (shema “Podaci”) se nalazi na Oracle poslužitelju baze podataka ◼ Web poslužitelj i poslužitelj baze podataka su na istom računalu ◼ Klijentsko računalo pristupa aplikaciji putem web preglednika i protokola HTTPS ◼ Na fizičkoj mjernoj postaji je pokrenut SSH poslužitelj i aplikacija “SWPostaja.exe” Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 74 Primjer: Sustav za praćenje kvalitete zraka Uočiti stereotipove čvorova i artefakata - moguće je koristiti generičke nazive (“device”, “exec. environment” i “artifact”), ali i konkretnije nazive ako želimo točnije opisati svojstvo čvora ili artefkata (npr. “schema”, “service”) Primjena UML dijagrama u programskom inženjerstvu: Dijagram razmještaja 75  Zaključak ◼ UML dijagrami podupiru cijeli proces razvoja programske potpore: specifikaciju, oblikovanje i implementaciju ◼ Vrlo bogata specifikacija koja pruža širok raspon alata za modeliranje i vizualizaciju ◼ u ovom i prethodnim predavanjima na temu UML-a prikazani su najčešće korišteni dijagram s osnovnim značajkama ◼ Standard prikaza modela programske potpore ◼ Za uporabu često dovoljno poznavati i mali dio specifikacije UML-a ◼ Napredna svojstva UML-a omogućuju prilagodbu UML-a za specifične potrebe (npr. sustavi za rad u stvarnom vremenu, domena sigurnosti računalnih sustava, formalno modeliranje …) ◼ Velik broj alata za podršku modeliranju ◼ Nedostatak predstavlja nepostojanje interoperabilnosti između alata ◼ Održavanje konzistentnosti slabo podržano Primjena UML dijagrama u programskom inženjerstvu 76  Zavod za elektroniku, mikroelektroniku, računalne i inteligentne sustave PROGRAMSKO INŽENJERSTVO ak. god. 2021./2022. Arhitekture raspodijeljenih sustava  Teme ◼ Podsjetnik na osnove arhitekture. ◼ Arhitekturni stilovi raspodijeljenih sustava: ◼ Arhitektura klijent-poslužitelj ◼ Višerazinska i posrednička arhitektura ◼ Uslužno usmjerena arhitektura Arhitekture raspodijeljenih sustava 2  Literatura ◼ Sommerville, I., Software engineering, 10th ed., Pearson, 2016. ◼ Timothy C. Lethbridge, Robert Laganière, Object-Oriented Software Engineering: Practical Software Development using UML and Java, Second Edition, McGraw Hill, 2005. ◼ A. Jović, N. Frid, D. Ivošević: Procesi programskog inženjerstva, e- skripta, FER, 2020. Arhitekture raspodijeljenih sustava 3  Podsjetnik na uvod u arhitekturu programske potpore ◼ Arhitektura programske potpore (definicije i fokus na odlukama) ◼ Oblikovanje arhitekture programske potpore ◼ Donošenje ispravnih odluka u oblikovanju arhitekture ◼ Stilovi arhitekture programske potpore ◼ Modeli i pogledi na arhitekturu ◼ Procjena arhitekture (metoda kompromisa te analiza troškova i dobiti) ◼ Vrednovanje i sukladnost arhitekture s principima oblikovanja (12 + 5) ◼ Dokumentiranje arhitekture ◼ Oblikovanje arhitekture objektno usmjerenih sustava (dokumentiranje UML dijagramima) Arhitekture raspodijeljenih sustava 4  Arhitekturni stil ◼ To je familija sustava definirana sličnim oblicima strukturne organizacije i opisana jasno definiranim rječnikom komponenti i konektora te pripadajućim topološkim ograničenjima. ◼ Najviša razina apstrakcije programske potpore - ne opisuje nisku implementacijsku razinu (programiranje). ◼ Racionalizira odluke oblikovanja arhitekture na visokom nivou i organizaciji programa. ◼ Daje smjernice za primjenu stila na razini podsustava (komponenata) i njihovih odnosa. ◼ Omogućuje ponovnu uporabu programskih komponenti ◼ Oblikovanje temeljem iskustva drugih (Princip oblikovanja #6) ◼ Inženjeri koji oblikuju programsku potporu trebaju izbjegavati razvoj (dijela) programske potpore koja je već bila razvijena. Arhitekture raspodijeljenih sustava 5 ARHITEKTURE RASPODIJELJENIH SUSTAVA 7  Raspodijeljeni sustav ◼ engl. Distributed System, Distributed Computing ◼ Raspodijeljeni sustav sastoji se od skupa nezavisnih računala, povezanih mrežom i posredničkim programima, koja omogućuje koordinaciju rada i dijeljenje resursa, tako da korisnici doživljavaju sustav kao jedinstveni računalni sustav. ◼ Značajke raspodijeljenih sustava: ◼ Obradu podataka i izračunavanja obavljaju raspodijeljeno smješteni programi. ◼ Uobičajeno je da su ti odvojeni programi na odvojenom sklopovlju (računalima, čvorovima). ◼ Odvojeni programi međusobno komuniciraju računalnom mrežom. ◼ U praksi postoji velik broj različitih sklopovskih i programskih arhitektura raspodijeljenih sustava Arhitekture raspodijeljenih sustava: Arhitekture raspodijeljenih sustava 8  Značajke raspodijeljenih sustava Svojstva Izazovi ◼ Dijeljenje resursa ◼ Složenost ◼ Otvorenost (heterogenost) ◼ Sigurnost ◼ Konkurentnost (engl. ◼ Upravljanje (engl. Concurrency) Manageability) ◼ Skalabilnost ◼ Nepredvidljivost (engl. ◼ Neosjetljivost na greške Unpredictability) ◼ Transparentnost Arhitekture raspodijeljenih sustava: Arhitekture raspodijeljenih sustava 9  Primjeri raspodijeljenih sustava ◼ Klijent – poslužitelj - najčešća ◼ Sustavi ravnopravnih sudionika (engl. Peer-to-Peer) P2P ◼ svaki čvor u sustavu ima jednake mogućnosti i odgovornosti (čvor je istovremeno poslužitelj i klijent). ◼ snaga obrade podataka i izračunavanja u P2P sustavu ovisi o pojedinim krajnjim čvorovima, a ne o nekom skupnom radu čvorova. ◼ Srodne socijalne mreže (engl. affinity communities) ◼ jedan korisnik se povezuje s drugim korisnikom u cilju razmjene informacija (MP3, video, slike itd.). ◼ Kolaborativno izračunavanje (engl. collaborative computing) ◼ neiskorišteni resursi (CPU vrijeme, prostor na disku) mnogih računala u mreži kombiniraju se u izvođenju zajedničkog zadatka (GRID computing, SETI@home, …). ◼ Slanje poruka u stvarnom vremenu (engl. Instant Messaging) ◼ izmjena tekstualnih i drugih poruka ◼ Upravljanje složenim sustavima (automobil, tramvaj, …) Arhitekture raspodijeljenih sustava: Arhitekture raspodijeljenih sustava 10  Problemi oblikovanja raspodijeljenih sustava ◼ Kako se alociraju i pokreću funkcije poslužitelja? ◼ Kako se definiraju i šalju parametri između klijenta i poslužitelja? ◼ Kako se rukuje neuspjesima (pogreškama) u komunikaciji? ◼ Kako se postavlja i rukuje sa sigurnošću? ◼ Kako klijent pronalazi poslužitelja? ◼ Koje strukture podataka koristiti i kako rukovati s njima? ◼ Koja su ograničenja u istovremenom radu dijelova raspodijeljenog sustava? ◼ Kako se uopće skupina komponenata usuglašava oko zajedničkih pitanja? Arhitekture raspodijeljenih sustava: Arhitekture raspodijeljenih sustava 11 ARHITEKTURA KLIJENT - POSLUŽITELJ 13  Klijent - poslužitelj ◼ Primjer raspodijeljenog sustava ◼ Jedna od najpoznatijih i najrasprostranjenijih arhitektura ◼ Poslužitelj (engl. server) ◼ Program koji dostavlja uslugu drugim programima koji su spojeni na njega preko komunikacijskog kanala. ◼ Klijent (engl. client): ◼ Program koji pristupa poslužitelju (ili više njih) tražeći uslugu ◼ Poslužitelju mogu pristupiti mnogi klijenti istovremeno ◼ Aplikacija se modelira kao skup usluga koje pružaju poslužitelji i skup klijenata koji koriste te usluge (više poslužitelja i više klijenata) ◼ Klijenti znaju za poslužitelje, ali poslužitelji ne moraju znati ništa o klijentima ◼ Klijenti i poslužitelji su logički procesi ◼ Pridruživanje procesora i procesa nije nužno 1 na 1 Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 14 Elementi arhitekture klijent-poslužitelj Poslužitelj Klijent Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 15  Primjeri arhitekture klijent-poslužitelj ◼ The World Wide Web ◼ Poslužitelji: ◼ E-mail ◼ Application Servers ◼ Network File System -NFS ◼ Audio/Video Servers ◼ Transaction Processing ◼ Chat Servers System ◼ Fax Servers ◼ Remote Display System ◼ FTP Servers ◼ Communication System ◼ Mail Servers ◼ Database System ◼ News Servers ◼... ◼ Proxy Servers ◼ Web Servers ◼... Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 16  Primjer sustava bankomata Klijenti Poslužitelj Upravljački Baza podsustav (nadglednik) podataka Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 17  Oblikovanje arhitekture klijent-poslužitelj ◼ Potrebno proučiti: ◼ Sekvencu aktivnosti ◼ Prednosti i rizike ◼ Funkcionalnosti poslužitelja i klijenta ◼ Protokole ◼ Oblikovanje klijent – poslužitelj arhitekture uz princip #6 „Povećaj uporabu postojećeg oblikovanja” (engl. reuse) kroz radne okvire ◼ Objektni radni okvir klijent – poslužitelj Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 18  Arhitektura klijent-poslužitelj ◼ Sekvenca aktivnosti: 1. Poslužitelj započinje s radom. Spajanje još nije dozvoljeno. 2. Poslužitelj dozvoljava spajanje („sluša”) i čeka na dolazak klijentskog zahtjeva. 3. Klijenti započinju s radom i obavljaju razne operacije, ◼ neke operacije traže zahtjeve i odgovore s poslužitelja. 4. Kada klijent pokuša spajanje na poslužitelja, poslužitelj mu to omogući (ako želi). 5. Poslužitelj čeka na poruke koje dolaze od spojenih klijenata. 6. Kada pristigne poruka nekog klijenta poslužitelj poduzima akcije kao odziv na tu poruku. 7. Klijenti i poslužitelj nastavljaju s navedenim aktivnostima sve do odspajanja ili prestanka rada. Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 19 Poslužitelj u komunikaciji s dva klijenta početak rada i slušanje spajanje šalje poruku šalje odgovor odspajanje prestanak slušanja Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 20  Funkcionalnost poslužitelja ◼ Inicijalizacija poslužitelja. ◼ Započinje slušati klijentska Initializing spajanja. ◼ Rukuje sljedećim tipovima For the server as a whole: događaja koje potiču klijenti: poslužitelj Waiting start l i steni ng 1. Prihvaća spajanje kao stop l i steni ng 2. Odgovara na poruke cjelina Waiting f or Connections 3. Rukuje odspajanjem klijenta accep t co nnection ◼ Može prestati slušati. For eac h connection: ha ndl e ◼ Mora čisto završiti rad! Handling a Connection di sconn ecti on do : react to me ssage s za svako spajanje termin ate rukuje spajanjem, reagira na poruku Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 21  Funkcionalnost klijenta ◼ Inicijalizira klijenta. ◼ Inicijalizira spajanje na inicijalizacija poslužitelja. ◼ Šalje poruke. inicijalizacija veze s poslužiteljem ◼ Rukuje sljedećim tipovima događaja koje potiče poslužitelj: interakcija s odzivi na događaje korisnikom koje je inicirao poslužitelj ◼ odgovara na poruke. slanje poruka ◼ rukuje odspajanjem od poslužitelju odspajanje poslužitelja. ◼ Mora čisto završiti rad. završetak Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 22  klijent-poslužitelj: višedretveni rad Cl ie nt S ide (Cl i ent A ) Server Si de i nteract wai t for server wai t for wai t for wai t for i nteract with wi th u se r events co nne ctio ns messa ges: messa ges: server u se r cl i ent A cl i ent B crea te dretva co nne ct crea te nastala send messa ge kreiranjem repl y to me ssage objekta di sp la y re pl y klijenta send messa ge repl y to me ssage di sp la y re pl y kil l cli ent di sp la y di sconn ect di sconn ect dretva kreirana otvaranjem dretva kreirana dretve kreirane kad veze s poslužiteljem otvaranjem slušanja se spoje klijenti Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 23  Komunikacijski protokoli ◼ Klijent i poslužitelj u komunikaciji razmjenjuju poruke uporabom dva jezika: jezik klijenta i jezik poslužitelja. ◼ Ta dva jezika i pravila konverzacije čine zajedničkim imenom protokol. ◼ Internet Protocol (IP) ◼ određuje put poruka od jednog računala do drugog. ◼ Transmission Control Protocol (TCP) - pouzdan protokol ◼ razbija veliku poruku na dijelove i šalje uporabom IP protokola. ◼ osigurava da je poruka uspješno primljena i ispravno sastavljena. ◼ Svako računalo (čvor) u mreži ima jedinstvenu IP adresu i ime (engl. host name). ◼ nekoliko poslužitelja mogu raditi na jednom čvornom računalu. ◼ svaki poslužitelj na računalu je identificiran preko jedinstvenog broja ulaznog porta (engl. port number) u rasponu 0 to 65535. ◼ portovi 0-1023 su rezervirani (npr. port 22 za siguran FTP). ◼ klijent mora znati host name i port number poslužitelja. Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 24  Oblikovanje arhitekture klijent-poslužitelj ◼ Oblikuj temeljne poslove poslužitelja i klijenta. ◼ Odredi kako će se posao raspodijeliti. ◼ tanki (manje posla na toj strani) nasuprot debelog klijenta. ◼ Oblikuj detalje skupa poruka koje se razmjenjuju. ◼ komunikacijski protokol. ◼ Oblikuj mehanizme: ◼ Inicijalizacije ◼ Rukovanja spajanjima. ◼ Slanja i primanja poruka. ◼ Završetka rada. ◼ U oblikovanju koristi princip “Povećaj uporabu postojećih rješenja i investicija” (princip #6) Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 25  Alternative arhitekturi klijent-poslužitelj 1. Implementacija jednog programa na jednom računalu koji obavlja sve poslove ◼ monolitna programska potpora 2. Računala nisu spojena u mrežu, već svako računalo obavlja svoj posao odvojeno. 3. Ostvariti neki drugi mehanizam (osim klijent-poslužitelj) kako bi računala u mreži razmjenjivala informacije. ◼ npr. jedan program upisuje u bazu podataka (ili oglasnu ploču) a drugi čita. Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 26  Prednosti arhitekture klijent-poslužitelj ◼ Posao se može raspodijeliti na više računala (strojeva). ◼ Klijenti udaljeno pristupaju funkcionalnostima poslužitelja. ◼ Klijent i poslužitelj mogu se oblikovati odvojeno. ◼ Oba entiteta mogu biti jednostavnija. ◼ Svi podaci mogu se držati na jednom mjestu (na poslužitelju). ◼ Obrnuto, podaci se mogu distribuirati na više udaljenih klijenata i poslužitelja. ◼ Poslužitelju može istodobno pristupiti više klijenata. ◼ Klijenti mogu ući u natjecanje za uslugu poslužitelja (a i obrnuto). Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 27  Rizici arhitekture klijent-poslužitelj ◼ Sigurnost ◼ Sigurnost je veliki problem bez savršenog rješenja. Potrebno uporabiti enkripciju, zaštitne zidove (engl. firewalls) i sl. ◼ Najčešće se napada komunikacijski kanal. ◼ Prijetnje klijentu: virusi, trojanci i drugi maliciozni programi. ◼ Prijetnje poslužitelju: DoS (engl. Denial of Service, service overloading, message overloading), prisluškivanje komunikacije. ◼ Potreba za adaptivnim održavanjem ◼ Budući da se programska potpora za klijente i poslužitelja oblikuje odvojeno potrebno je osigurati da sva programska potpora bude: kompatibilna prema unatrag (engl. backwards) i prema unaprijed (engl. forwards) – vidi princip “Planiraj zastaru”, te kompatibilna s drugim verzijama klijenata i poslužitelja. Arhitekture raspodijeljenih sustava: Klijent - poslužitelj 28 OBJEKTNI RADNI OKVIR KLIJENT-POSLUŽITELJ 29  Objektni radni okvir klijent-poslužitelj ◼ engl. Object Client-Server Framework - OCSF ◼ Metoda oblikovanja arhitekture klijent-poslužitelj temeljena na ponovnoj i višestrukoj uporabi. ◼ Pravila uporabe: ◼ ne mijenjati apstraktne razrede u OCSF; ◼ kreirati podrazrede; ◼ konkretizirati metode u podrazredima; ◼ ponovo definirati (engl. override) neke metode u podrazredima; ◼ napisati kod koji kreira instance i inicira akcije. ◼ Izvorni kod OCSF u Javi nalazi se na web stranicama knjige ◼ T.C.Lethbridge, R.Laganiere: Object-Oriented Software Engineering, 2nd ed., McGraw-Hill, 2005. ◼ http://www.site.uottawa.ca/school/research/lloseng/supportMaterial/sour ce/ Arhitekture raspodijeljenih sustava: OCSF 30 Objektni radni okvir klijent-poslužitelj konkretan razred Sve operacije u razredima su kategorizirane Arhitekture raspodijeljenih sustava: OCSF 31  Klijentska strana Jadan razred AbstractClient ◼ Skup operacija služi za komunikaciju s poslužiteljem. ◼ Operacija handleMassageFromSerkver() u dijelu rukuje s porukom pristiglom od poslužitelja. ◼ Skup operacija omogućuje dodavanje opcijskih funkcionalnosti (princip #5: Povećaj ponovnu uporabivost). ◼ Skup operacija služi za dohavaćanje i postavljenje parametara poslužitelja. Aktivnosti oblikovanja (vidi višedretveni rad prikazan ranije): ◼ Kreiraj podrazred od AbstractClient ◼ U podrazredu implementiraj handleMessageFromServer() ◼ Instanciraj razred – kreiraj klijenta/objekt (start prve dretve) ◼ Zovi openConnection() koja: ◼ Kreira vezu s poslužiteljem), objekte za prijenos poruka i dretvu. ◼ Nakon toga starta drugu dretvu koja sluša dolazak poruke. Kad poruka stigne zove handleMessageFromServer() ◼ Ako se želi poslati poruka poslužitelju, to se radi u okviru prve dretve metodom sendToServer() iz skupa. Arhitekture raspodijeljenih sustava: OCSF 32  Poslužiteljska strana ◼ Poslužiteljska strana sadrži dva razreda: AbstractServer i konkretan razred ConnectionToClient. ◼ Skupovi operacija označeni su jednako kao u AbstractClient. ◼ Nazivi operacija razumljivo objašnjavaju njihove funkcionalnosti. ◼ Sukladno sekvencijskom dijagramu koji pokazuje višedretveni rad (vidi ranije) potrebne su dretve: jedna koja sluša novo spajanje klijenta, druga(e) koje rukuju vezama s klijentima (po jedna za pojedinog klijenta) posebna dretva je potrebna za interakciju s korisnikom (administratorom) na poslužitelju Arhitekture raspodijeljenih sustava: OCSF 33  Poslužiteljska strana Aktivnosti oblikovanja poslužiteljeske strane ◼ Kreiraj podrazred od AbstractServer razreda. ◼ U podrazredu implementiraj handleMessageFromClient() ◼ Napiši kod koji: ◼ Kreira instancu podrazreda od AbstractServer ◼ Poziva listen() metodu s kojom počinje dretva slušanja Ako i kada se klijent spoji: ◼ Za svakog spojenog klijenta kreira se po jedan objekt razreda ConnectionToClient i započinje njegova zasebna dretva. ◼ Objekt razreda ConnectionToClient prihvaća poruku od klijenta te zove handleMessageFromClient() u AbstractServer (ne u ConnectionToClient). ◼ Eventualna poruka klijentu šalje se metodom sendToClient() u konkretnom razredu ConnectionToClient. Arhitekture raspodijeljenih sustava: OCSF 34  Vrednovanje arhitekture klijent-poslužitelj kroz principe oblikovanja 1. Podijeli pa vladaj: Podjelom sustava na klijenta i poslužitelja je uspješan način optimalne podjele. klijent i poslužitelj mogu se oblikovati odvojeno. 2. Povećaj koheziju: Poslužitelj osigurava kohezijski spojenu uslugu. 3. Smanji međuovisnost: Uobičajeno je da postoji samo jedan komunikacijski kanal preko kojega se prenose jednostavne poruke. 4. Povećaj apstrakciju: Odvojene raspodijeljene komponente su dobar način povećanja apstrakcije. 5. Povećaj ponovnu uporabivost: Skup operacija omogućuje dodavanje opcijskih funkcionalnosti 6. Povećaj uporabu postojećeg: često je moguće pronaći odgovarajući radni okvir (engl. framework) temeljem kojega se oblikuje raspodijeljeni sustav. Međutim, klijent-poslužitelj arhitektura je često specifična s obzirom na primjenu. Arhitekture raspodijeljenih sustava: OCSF 35  Vrednovanje arhitekture klijent-poslužitelj 7. Oblikuj za fleksibilnost: Raspodijeljeni sustavi se često vrlo lako mogu rekonfigurirati dodavanjem novih poslužitelja ili klijenata. 8. Planiraj zastaru: Paziti na tehnologije. 9. Oblikuj za prenosivost: Klijenti se mogu oblikovati za nove platforme bez promjene poslužiteljske strane. 10. Oblikuj za ispitivanje: Klijenti i poslužitelji mogu se ispitivati neovisno. 11. Oblikuj konzervativno: U kod koji rukuje porukama mogu se ugraditi stroge provjere (npr. rukovanje iznimkama). 12. Oblikuj po ugovoru: po potrebi može se ugraditi u komunikaciju. Arhitekture raspodijeljenih sustava: OCSF 36 VIŠERAZINSKA ARHITEKTURA 37  Višerazinska arhitektura ◼ engl. Multi layer, multi tier ◼ Obzirom na složenost distibuiranih sustava ne postoji univerzalni model organizacije sustava koji je primjeren svim okolnostima primjene ◼ Postoje različiti distribuirani arhitektonski stilovi: multi-layer, broker,… ◼ Potrebno odabrati arhitektonski stil koji podržava kritične nefunkcionalne zahtjeve ◼ Višerazinska organizacija ◼ Organizira program u razinama. ◼ Svaki sloj je grupa modula koja nudi kohezivni skup usluga. ◼ Upotreba mora biti jednosmjerna. Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 38  Trorazinska klijent-poslužitelj arhitektura ◼ engl. Three-tier (layer) architecture ◼ Predstavlja vrstu arhitekture klijent-poslužitelj ◼ Znatno bolje promovira skalabilnost i mogućnost jednostavnije modifikacije. ◼ Nastoji otkloniti neke nedostatke klasične klijent-poslužitelj arhitekture, a posebice nastoji povećati performanse, raspoloživost i sigurnost. ◼ Općenito trorazinska arhitektura sadrži ◼ korisničku razinu Korisnička razina engl. user; presentation; client tier ◼ logičku ili poslovnu razinu engl. business; logic; middle tier Logička razina ◼ podatkovnu razinu engl. data tier Razina podataka Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 39  Primjer trorazinske arhitekture ◼ Postoje mnoge varijacije trorazinske arhitekture, ovisno koliko se funkcionalnosti pridodaje svakoj razini. HTML, Java, C#, JavaScript, SQL i Python,.NET varijante CSS Odluke ? ? oblikovanja Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 40  Tanki i debeli klijent ◼ Sustav tankog klijenta (engl.Thin-client) ◼ klijent je oblikovan da bude što je moguće manji i jednostavniji. ◼ većina posla obavlja se na poslužiteljskoj strani. ◼ oblikovnu strukturu klijenta i izvršni kod jednostavno se preuzima preko računalne mreže. ◼ Sustav debelog klijenta (engl. Fat-client) ◼ što je moguće više posla delegira se klijentima. ◼ poslužitelj na taj način može rukovati s više klijenata. lagano izračunavanje Klijent Poslužitelj obilno izračunavanje Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 41  Višerazinska arhitektura ◼ engl. n-tier architecture ◼ Klijenti i poslužitelji se organiziraju u više razina. ◼ Svaka razina pruža uslugu razini iznad. ◼ Svaka razina oslanja se na razinu ispod. ◼ Razina zatvara (skriva, enkapsulira) skup usluga i implementacijske detalje niže razine o kojoj ovisi. ◼ Često niža razina predstavlja virtualni stroj za razinu iznad. ◼ Višerazinska arhitektura nije u posebnom smislu slojevita (engl. layered). ◼ slojevita arhitektura odnosi se na strukturu modula, dakle na statički pogled, ◼ višerazinska arhitektura (engl. tiered) odnosi na organizaciju u izvođenju (engl. run-time), dakle na dinamički pogled. Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 42  Arhitektura s više razina ◼ engl. N-tier ◼ Funkcionalne odgovornosti: Najviša razina apstrakcije funkcionalnih zahtjeva. Zahtjevi se raščlanjuju i pridjeljuju razinama. ◼ Primjer odgovornosti web programa: prezentacijska razina povezivanje web usluge logička (poslovna) razina podatkovna razina ◼ (trajno čuvanje) Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 43  Arhitektura s više razina Potrebno je razlikovati alociranje odgovornosti od skupa komponenata u izvođenju. Preslikavanje odgovornosti na komponente u izvođenju može se izvesti na više načina. Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 44  Primjer arhitekture s više razina Rana izvedba Google pretraživača Različite programske usluge Dijelovi skladišne arhitekture Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 45  Google pretraživač Crawler – kontinuirani proces, locira i dohvaća sadržaj Web-a, slijedi sve linkove i rezultat se smješta u Repository. Indexer – generira indeks sadržaja na webu. Preslikava riječi s web stranice. Osim indeksa riječi pamti se i indeks linkova. Rezultat se smješta u skup Barrels. Operacija Sorter indeksira po riječima i linkovima. Indexer također izvlači informacije iz linkova i smješta u Anchors. Generira se i Lexicon riječi (> 20M riječi). URL Resolver generira bazu linkova Links, kao i DocIndex za daljnje pretraživanje stranica Searcher-om (uz PageRank). Rangiranje– Page Rank algoritam: što više drugih stranica pokazuje na neku stranicu to je ona važnija, ali pri tome se uzima i važnost stranica koje pokazuju na ciljanu. Searcher je Google jezgrena operacija (uzima u obzir nekoliko indeksa, PageRank i leksikon). Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 46  Prednosti i nedostaci arhitekture s više razina ◼ Prednosti: oblikovanje temeljem više razine apstrakcije. podupire povećanje i poboljšanje sustava promjena na jednoj razini utječe samo još na razinu ispod i iznad. podupire ponovnu uporabu, prenosivost i sl. ◼ Nedostaci: teško je odrediti optimalno preslikavanje odgovornosti na razine. ponekad se izračunavanje i funkcionalnosti sustava ne mogu razbiti na razine. ako se želi poboljšati performanse, mora se preskakati ili „tunelirati” kroz razinu. Arhitekture raspodijeljenih sustava: Višerazinska arhitektura 47 POSREDNIČKA I ZASTUPNIČKA ARHITEKTURA 48  Posrednička arhitektura ◼ Logička razina u trorazinskoj arhitekturi može se prošireno promatrati kao posrednička razina definirana međuslojem (engl. middleware). ◼ Nalazi se između klijenata i poslužitelja. ◼ Posrednička razina (engl. middleware) je sveobuhvatna programska podrška koja omogućava uzajamno djelovanje aplikacija bez potrebe za poznavanjem i kodiranjem svih operacija nužnih za implementaciju usluge. ◼ skriva osobama koje oblikuju raspodijeljeni sustav detalje operacijskog sustava i druge specifičnosti implementacije. ◼ preuzima detalje komunikacijske mreže. ◼ omogućuje osobama koje oblikuju raspodijeljeni sustav da se usredotoče na primjenski (aplikacijski dio). ◼ Ova razina ima definiran skup rutina/sučelja (API). ◼ Olakšava oblikovanje i razvoj raspodijeljenih sustava. Arhitekture raspodijeljenih sustava: Posrednička arhitektura 49  Posrednička i zastupnička arhitektura Postoje tri vrste ovih arhitektura: Transakcijski usmjerena (komunikacija s bazama podataka). Zasnovana na porukama (pouzdana, asinkrona komunikacija). Objektno usmjerena (komunikacija između raspodijeljenih/udaljenih objekata). Najpopularnije posredničke i zastupničke arhitekture: DotNET – Microsoft-ova standardna tehnologija EJB (Enterprise JavaBeans), zasnovana na aktiviranju poruka, (engl. Remote Message Invocation - RMI) kao dio J2EE. CORBA – standardizirani zastupnik (engl. broker) MPI (engl. Message Passing Interface) – za paralelne sustave ◼ Interkcija komponeanta u ovoj raspodijeljenoj arhitekturi temelji se na nekom mehanizmu udaljenog pozivu procedura – RPC (engl. Remote Procedure call). Arhitekture raspodijeljenih sustava: Posrednička arhitektura 51  Posrednička arhitektura – RPC mehanizam RPC uveden u UNIX U objektno usmjerenom kontekstu: okruženje (1980. Remote Method Invocation (RMI) god.) Mora znati sve o poslužitelju Ključni dio Može čekati na odziv Mogući odgovor poslužitelja Arhitekture raspodijeljenih sustava: Posrednička arhitektura 52.NET i J2EE arhitekture Microsoft.NET arhitektura je komponentni model objektno usmjerenih raspodijeljenih sustava. Standard jena binarnoj razini te specificira pozive metoda sučelja (engl. interface) u interakciji između objekata. Pojedini objekti dinamički otkrivaju sučelja drugih objekata. EJB se temelji na Java beans programskim komponentama (standardiziranom razredu) koje se mogu razmjestiti po mreži i na bilo kojem operacijskom sustavu. Java beans posjeduju univerzalni ugovor koji omogućuje njihovo otkrivanje i pristup. Obje su višerazinske arhitekture i podržane brojnim alatima..NET je jednostavniji za oblikovanje, podržava više programskih jezika na jedinstvenoj platformi, manje izvornog koda. J2EE je otvoreni standard, omogućuje veće ponovno korištenje i rad na više platformi, Odluka oblikovanja o izboru uvjetovana netehničkim razlozima. Arhitekture raspodijeljenih sustava: Posrednička arhitektura 53.NET i J2EE arhitekture (značajke iz 2016. g.) Koncepti J2EE.NET Prezentacijska razina JSP/Servlets ASP.NET Logička razina EJB/Servlets Code Behind Remoted Classes Jezik Java C#, VB.NET,, drugi Platforma Any Windows Pristup bazama JDBC ADO.NET (OLE-DB, ODBC) Web Servisi JWSDP (Dev. pack) Web Services Runtime JRE CLR-Common Lang. Runtime Raspodijeljene komp. RMI, CORBA, SOAP SOAP, DCOM XML Parser JAXP, drugi Built-in (System.XML) Arhitekture raspodijeljenih sustava: Posrednička arhitektura 54  CORBA Opća arhitektura posrednika zahtjeva za objektima - Common Object Request Broker Architecture - CORBA Standardna implementacijska posrednička/zastupnička razina za oblikovanje raspodijeljenih objektno usmjerenih sustava. CORBA standard razvija OMG (Object Managemant Group) Klijent rukuje podacima i metodama u poslužiteljskom objektu samo preko sučelja. Implementacija je potpuno skrivena klijentu. Klijenti i poslužitelji ne brinu se o lokaciji jednog ili drugog. Klijenti i poslužitelji mogu se programirati različitim programskim jezicima. IIOP Objekt A Objekt B Sučelje Sučelje Internet CORBA protokol Arhitekture raspodijeljenih sustava: Posrednička arhitektura 55  MPI arhitektura ◼ MPI (engl. Message Passing Interface) je knjižnica procedura zasnovana na dogovoru 40 organizacija i pojedinaca. ◼ MPI je standard za komunikaciju između (raspodieljenih) procesa prijenosom poruka. ◼ Svaki proces ima jednoznačni identifikator. ◼ Podaci se prenose iz adresnog prostora jednog procesa u adresni prostor drugog procesa. ◼ Podržani su programski jezici C, C++, Java, Python i drugi. ◼ Mpi nije IEEE ili ISO standard već de facto „industrijski standard”. ◼ MPI je dominantan model za HPC (engl. High performance computing). Arhitekture raspodijeljenih sustava: Posrednička arhitektura 56  Prednosti i nedostaci posredničke i zastupničke arhitekture Prednosti transparentnost lokacija; izmjenjivost i proširivost komponenti; prenosivost; interoperabilnost različitih sustava; ponovna uporaba. Nedostaci smanjena efikasnost veća osjetljivost na pogreške engl. fault-tolerance Arhitekture raspodijeljenih sustava: Posrednička arhitektura 57  Principi oblikovanja i posredničko/zastupnička arhitektura 1. Podijeli pa vladaj: udaljeni objekti mogu biti neovisno oblikovani. 5. Povećaj ponovnu uporabu: često je moguće oblikovati udaljene objekte tako da ih i drugi sustavi mogu koristiti. 6. Povećaj uporabu postojećeg: mogu se koristiti objekti koje su drugi oblikovali. 7. Oblikuj za fleksibilnost: posrednik (zastupnik) se može ažurirati. objekti se mogu zamijeniti. 9. Oblikuj za prenosivost: može se oblikovati klijente za novu platformu i još uvijek pristupati postojećim zastupnicima i udaljenim klijentima na drugim platformama. 11. Oblikuj konzervativno: može se rigorozno provjeriti nedvosmisleno ponašanje i obilježja udaljenih objekata. Arhitekture raspodijeljenih sustava: Posrednička arhitektura 58 USLUŽNO USMJERENA ARHITEKTURA 59  Uslužno usmjerena arhitektura ◼ engl. Service oriented architecture (SOA), Service oriented architectural pattern (SOAP) ◼ Uslužno usmjerena arhitektura organizira primjenski program (cjelovitu aplikaciju) kao kolekciju usluga koje međusobno komuniciraju uporabom dobro definiranih sučelja i protokola. ◼ Npr. Internet okruženje – Web usluge (engl. Web services) ◼ web usluga = aplikacija dostupna putem Interneta, u svrhu izgradnje složenog sustava ◼ omogućava integraciju s ostalim Web uslugama. ◼ dobro definirana funkcija. ◼ samodostatna (ne ovisi o drugim uslugama). ◼ komunikacija – standardnim protokolima razmjene podataka npr. XML. Arhitekture raspodijeljenih sustava: Uslužno usmjerena arhitektura 60  Model web uslužne arhitekture ◼ Oglašavanje, otkrivanje selekcija i uporaba web usluge ◼ tehnologije zasnovane na XML-u ◼ Simple Object Access Protocol (SOAP) ◼ razmjena poruka Web usluga ◼ Web Service Description Language (WSDL) ◼ definira web uslugu ◼ Universal Description, Discovery, and Integration (UDDI) ◼ API za registar usluga Service