Unified Modeling Language UML 2

1. Aplikativni softver Fakultet za informatiku i menadžment Univerzitet Singidunum www.fim.singidunum.ac.yu Unified Modeling Language UML 2 2008/2009. Violeta Tomašević Literatura Martin Flowler, UML ukratko, prevod Mikro knjiga, 2004. Alan Shalloway & James Trott, Projektni obrasci, prevod Mikro knjiga, 2004.

2. UML 2 Opis problema Nedovoljna apstraktost programskih jezika dovela je do pojave grafičkih metoda. Projektovanje softvera Grafičkemetode • Problemi • Prenos znanja i ideja • Komunikacija • Razumevanje OOSE OOAD OMT Rasprave o projektovanju softvera su lakše ukoliko postoji izvestan nivo apstrakcije. UML Neusaglašenost postojećih grafičkih metoda dovela je do pojave UML-a.

3. UML 2 Istorija UML – a • Sredinom 70-ih godina prošlog vekapojavljuju se jezici za OO modelovanje zbog povećane kompleksnosti softverskih sistema. • U periodu 1989-1994.godinedrastično se povećao broj metoda (sa 10 na više od 50). Najveći uticaj su imale Booch metoda, OMT (Object Modeling Technique, Rambaugh), OOSE (Object Oriented Software Engineering, Jacobson), Shlaer-Mellor metoda i dr. • 1994. godinepočinje rad na UML-u kada se Rumbaugh pridružio Boochu u firmi Rational (sada je to deo IBM-a). • U oktobru 1995.godine pojavila se verzija 0.8 dokumenta UM (Unified Method) • U jesen 1995.godine Jacobson se pridružuje Rational-u i otpočinje rad na objedinjenju UM i OOSE. • U junu 1996.godine pojavila se verzija 0.9 UML-a. Uključuju se važni partneri: DEC, HP, IBM, Microsoft, Oracle i dr. • U januaru 1997.godine grupi OMG (Object Management Group) podnet je predlog za standardizaciju UML 1.0. Lista partnera se proširuje: Object Time, Ericsson i dr. • U novembru 1997.godine UML 1.1 postaje standard prihvaćen od OMG. • U junu 2003.godine izlazi verzija UML 2.

4. UML 2 Korisnici UML – a • Sistem-analitičari i krajnji korisnici: specificiraju zahtevanu strukturu i ponašanje sistema • Rukovodioci projekata: vođenje i usmeravanje kadrova i upravljanje resursima • Arhitekti: projektuju sistem koji zadovoljava zahteve • Razvojni inženjeri: transformišu arhitekturu u izvršni kod • Kontrolori kvaliteta:proveravaju strukturu i ponašanje sistema • Evidentičari komponenata: kreiraju i katalogiziraju komponente

5. UML 2 Objedinjen jezik za modelovanje Čemu služi UML? UML se koristi za modelovanje i projektovanje softverskih sistema, naročito sistema pravljenih primenom objektno-orijentisanih tehnologija. UML je skup grafičkih notacija zasnovanih na jedinstvenom metamodelu. Notacija je skup grafičkih elemenata koji se koriste u modelima, tj. grafička sintaksa jezika za modelovanje. Metamodel predstavlja dijagram koji definiše koncepte jezika za modelovanje. Iako je notacija često intuitivna, a ne formalna, vrlo se uspešno koristi u praksi. Metamodel predstavlja pokušaj da se strožije definiše notacija, bez narušavanja njene korisnosti.Ni notacija ni metamodel se ne moraju strogo primenjivati.

6. UML 2 Postupcirazvoja Direktni razvoj (forward engineering) generisanje UML dijagram Programski kod Povratna analiza (reverse engineering) tumačenje Programski kod UML dijagram

7. UML 2 Načini korišćenja UML-a Izrada skica Izrada projekata UML Programski jezik

8. UML 2 Izrada skica • Skiceopisuju pojedine aspekte sistema korišćenjem UML-a kao pomoćnog sredstva. • Osobine skica: • predstavljaju najčešći način upotrebe UML-a • obično se generišu neformalno i dinamički, tako da se rade brzo i na tabli • nepotpune su i uglavnom imaju obaveštajni karakter • omogućavaju jednostavno ispitivanje više alternativnih rešenja • mogu se koristiti u dokumentaciji • Skice u direktnom razvoju: • sadrže samo nekoliko značajnih problema koji će se javiti u kodu • saopštavaju ideje i alternative predstojećeg posla • vizualizuju delove projekta pre programiranja • Skice u povratnoj analizi: • objašnjavaju kako radi neki deo sistema (samo klase o kojima je važno razgovarati)

9. UML 2 Izrada UML projekata • UML projektiopisuju sistem sveobuhvatno, kako bi se programiranje koje predstoji svelo uglavnom na mehaničku aktivnost. • Osobine UML projekata: • za izradu projekata koriste se složeni, tzv. CASE alati za računarsko projektovanje softvera • projekti se moraju dosledno sprovoditi Direktni razvoj: Projekti sadrže detaljan opis sistema, obično do nivoa interfejsa podsistema (dalja razrada realizacije se prepušta programerima), na osnovu koga se piše kod. CASE alati omogućavaju crtanje dijagrama i čuvanje informacija u memoriji. Povratna analiza: Projekti sadrže detaljne informacije o kodu u obliku papirne ili elektronske dokumentacije. Mogu prikazati svaki detalj neke klase u grafičkom obliku koji programer razume. CASE alati čitaju izvorni kod, tumačenja stavljaju u memoriju i generišu dijagrame.

10. UML 2 UML kao programski jezik UML modelovanje celog sistema Intenzivno UML modelovanje Parcijalno UML modelovanje programiranje Izvorni kod CASE alati CASE alati automatizacija Programski kod Programski kod Programski kod UML postaje programski jezik u slučaju kada se celokupni sistem modelira UML dijagramima, a zatim se ti dijagrami primenom CASE alata neposredno prevode u izvršni kod. Tada UML postaje izvorni kod, što odgovara programskom jeziku. Ovaj način upotrebe UML-a još nije doživeo punu praktičnu afirmaciju. .

11. UML 2 Dijagrami UML-a

12. UML 2 Klasifikacija dijagrama Dijagram klasa Dijagram komponenata Dijagram složene strukture Dijagram strukture Dijagram raspoređivanja Dijagram objekata Dijagram paketa Dijagram Dijagram aktivnosti Dijagram slučajeva korišćenja Dijagram sekvence Dijagram mašine stanja Dijagram ponašanja Dijagram komunikacije Dijagram pregleda interakcije Dijagram interakcije Vremenski dijagram

13. UML 2 Dijagrami klasa (Class diagrams) • Dijagram klasaopisuje tipove objekata u sistemu i različite vrste statičkih veza koje postoje među njima, kao i ograničenja u načinu njihovog povezivanja. • Dijagrami klasa su najčešće korišćeni dijagrami UML-a. • Najbogatiji skup tehnika za modelovanje u UML-u imaju upravo dijagrami klasa. Primer klase Model klase Porudžbina datumNaručivanja:Date[0..1] plaćenoUnapred:Boolean[1] Broj:String[1] cena:Novac pošalji zaključi Ime klase Atributi klase Operacije klase

14. UML 2 Svojstva klase (properties) Svojstva klasepredstavljaju strukturne karakteristike klase. Načini predstavljanja na dijagramu Upotreba za predstavljanje manje važnih svojstava, kao što su datumi ili logičke promenljive Atributi Svojstva klase za eksplicitno isticanje važnih klasa u sistemu Asocijacije Većina informacija se može prikazati ravnopravno na oba navedena načina, mada postoje i neke razlike među njima. Izbor načina prikazivanja se ne zasniva na značenju pojmova, već na tome šta želimo da naglasimo na dijagramu.

15. UML 2 Kardinalnost(multiplicity) • Kardinalnostpokazuje na koliko objekata se odnosi neko svojstvo. Definiše se donjom (DG) i gornjom granicom (GG) u obliku DG..GG, za koje važe sledeća pravila: • Donja granica može biti bilo koji pozitivan broj ili 0. • Gornja granica može biti bilo koji pozitivan broj ili *(znači da nema ograničenja). • Ako su donja i gornja granica jednake, može se koristiti jedan broj. • Umesto 0.. *, što je čest slučaj, može se koristiti samo *. • Najčešći primeri kardinalnosti • 2..4 (pr. U timu mogu da učestvuju 2 do 4 programera.) • 1 (pr. Jedna porudžbina mora imati tačno jednog kupca.) • 0..1 (pr. Za klijentsku firmu može biti zadužen poseban predstavnik, ali ne mora.) • * (pr. Kupac može poslati nula ili više porudžbina, nema gornje granice.) UML 2 ne dozvoljava kardinalnost sa prekidima (bilo dozvoljeno u UML 1).

16. UML 2 Atributi (1)(attributes) Atributopisuje neko svojstvo u jednom redu teksta unutar odgovarajućeg dela klase. Potpuni oblik zapisa atributa vidljivost ime: tip kardinalnost = podrazumevana-vrednost {opis-svojstva} Objašnjenje • vidljivost (visibility) označava da li je atribut javni (+) ili privatni (-) • ime (name) određuje ime atributa u klasi • tip(type)ukazuje na tip atributa u klasi • kardinalnost(multiplicity) ukazuje na broj objekatana koje se odnosi atribut • podrazumevana-vrednost (default value) je vrednost atributa u novom objektu • opis-svojstva (property string) definiše dodatne osobine atributa

17. UML 2 Atributi (2) • Primer 1 • name: String [1] = “Bez naslova”{readOnly} Primer 2 Porudžbina + datumNaručivanja:Date[0..1] + plaćenoUnapred:Boolean[1] + stavke:StavkaPorudzbine[*]{ordered}

18. UML 2 Asocijacije (associations) Asocijacijaopisuje neko svojstvo punom linijom između dve klase, usmerenom od izvorne klase ka odredišnoj. Ime svojstva je na odredišnom kraju asocijacije, kao i njena kardinalnost. Odredišna klasa određuje tip svojstva. Kardinalnost asocijacije može biti definisana na oba kraja linije. ime svojstva Izvorna klasa Odredišna klasa kardinalnost Primer asocijacije + plaćenoUnapred 0..1 Boolean Porudžbina Date + datumNaručivanja 1 1 izvor stavke {ordered} odredište * StavkaPorudžbine

19. UML 2 Operacije (1)(operations) Operacijesu aktivnosti koje klasa može da obavi. • Vrste operacija: • Upiti • ne menjaju stanje sistema, tj. nemaju sporedne efekte • vraćaju pročitanu vrednost iz klase • redosled izvršavanja im se može menjati, a da se ne promeni ponašanje sistema • Modifikatori • menjaju stanje sistema • obično nemaju rezultat operacija klasemetod klase deklaracija procedure telo procedure Primer polimorfizma Nadtip operacija metod Podtip operacija Podtip operacija Podtip operacija metod2 metod1 metod3

20. UML 2 Operacije (2)(operations) Sintaksa operacija na UML-u vidljivost ime (lista-parametara) : tip-rezultata {opis-svojstva} Primer operacije + stanjeNa (datum:Datum) : Novac • vidljivost označava da li je operacija javna (+) ili privatna (-) • ime je niz znakova • lista-parametara je lista parametara operacije Sintaksa parametara operacije je: smer ime: tip = podrazumevana-vrednost • ime, tip i podrazumevana-vrednost imaju isto značenje kao u sintaksi atributa • smer pokazuje da li je parametar ulazni (in), izlazni (out), ili ulazno-izlazni (inout) • tip-rezultata ukazuje na tip rezultata operacije • opis-svojstva ukazuje na svojstva operacije (pr. query) Objašnjenje

21. UML 2 Generalizacija Generalizacijapodrazumeva smeštanje zajedničkih osobina u opštu klasu koja predstavlja nadtip. Sve što važi za klasu koja je nadtip, važi i za klasu koja je podtip. Nadtip Podtip 1 Podtip 2 • Generalizacija se realizuje nasleđivanjem (inheritance). Važne posledice nasleđivanja su: • Zemenljivost (substitutability) koja omogućava da se umesto nadtipa može koristiti objekat bilo kog podtipa te klase. • Polimorfizam koji omogućava dobijanje različitih odgovora ne vodeći računa o pozivanju od strane klijenta.

22. Obuhvata kamionete i džipove, ali ne i motocikle UML 2 Napomene i komentari Napomenepredstavljaju objašnjenja na dijagramu. Mogu biti nezavisne od drugih elemenata dijagrama, ali mogu biti i spojene isprekidanom linijom sa elementima dijagrama koje objašnjavaju. Kao oznaka kraja linije može se koristiti kružić. Auto Komentarje tekst koji se može dodati elementu dijagrama pomoću dve crtice ispred teksta (--). Napomene i komentari se mogu pojaviti na svim vrstama dijagrama.

23. UML 2 Zavisnost(dependency) Zavisnostizmeđu dva elementa postoji ako promene definicije jednog elementa, tzv. davaoca (supplier), mogu izazvati promene drugog elementa, tzv. klijenta (client). Upravljanje zavisnostima je vrlo važno jer se svaka promena u sistemu reflektuje na druge elemente koji se onda moraju menjati. Izmene u klasama se reflektuju samo preko interfejsa. • Razlozi zavisnosti između klasa: • jedna klasa šalje poruku drugoj • jedna klasa sadrži drugu klasu • objekat jedne klase prosleđuje objekat druge klase kao parametar neke operacije Prozor za pregled bonusa klijent zavisnost Zaposleni davalac Podaci o bonusima Podaci o zaposlenima

24. UML 2 Ograničenja(constraints) Ograničenjau sistemu se u velikoj meri opisuju osnovnim elementima dijagrama klasa kao što su atributi, asocijacija i generalizacija. Ipak, ne mogu se sva ograničenja prikazati na taj način. UML dopušta proizvoljan opis ograničenja uz jedino pravilo da taj opis mora biti između vitičastih zagrada. • Predstavljanje ograničenja • Prirodni jezik (neprecizan, ali se preporučuje) • Programski jezik • OCL (Object Constraint Language) UML-ov formalni jezik ograničenja (neophodno dobro razumevanje jezika) Primer {onemogućiti neregularnost: student mora položiti ispit pre upisa ocene}

25. UML 2 Dijagramisekvence(Sequence diagrams) Dijagram sekvence (DS)opisuje saradnju objekata prilikom neke aktivnosti. DS uspešno prikazuju saradnju, tj. interakciju između objekata, ali nisu pogodni za precizno definisanje ponašanja objekata. Korisni su kada treba analizirati više slučajeva korišćenja. DS opisuju interakciju pomoću: Linije života(lifeline) –vertikalna isprekidana linija koja predstavlja učesnika u interakciji Poruke(message) –linije završene strelicom koje se čitaju odozgo na dole Traka aktivnosti(activationbar) –pravougaonik na liniji života koji pokazuje kada je učesnik aktivan u interakciji Ime klase linija života poruka traka aktivnosti

26. UML 2 Primer Imamo porudžbinu i hoćemo da joj uputimo komandu koja će izračunati cenu. Da bi izvršila komandu, porudžbina mora da pregleda sve svoje stavke i izračuna njihove cene na osnovu pravila formiranja cena odgovarajućih proizvoda. Kada obradi sve stavke, porudžbina izračunava ukupan popust na osnovu pravila koja važe za kupca.

27. UML 2 Centralizovano upravljanje porudžbina stavka porudžbine proizvod kupac računajCenu uzmiKoličinu učesnik uzmiProizvod primljena poruka proizvod povratak uzmiPodatkeOCeni računajOsnovnuCenu povratni poziv računajPopuste uzmiPodatkeOPopustima Kod centralizovanog upravljanja, jedan učesnik obrađuje najveći deo podataka, dok ga drugi učesnici snabdevaju njima. Ovaj način upravljanja je jednostavniji i pogodan za početnike, s obzirom da se celokupna obrada odvija na jednom mestu.

28. UML 2 Distribuirano upravljanje porudžbina stavka porudžbine proizvod kupac računajCenu parametar računajCenu uzmiCenu(količina:number) uzmiCenuSaPopustom(porudžbina) uzmiOsnovnuCenu povratak cenaSaPopustom Kod distribuiranog upravljanja, obrada je raspoređena između više učesnika, od kojih svaki izvršava deo algoritma. Ovaj način upravljanja je manje pregledan, ali je efikasan i obično ga koriste iskusniji projektanti.

29. UML 2 Pravljenje i brisanje učesnika upit nad bazom podataka Upravljač • Notacija za pravljenje učesnika • Nacrtati strelicu poruke koja je povezana neposredno sa oznakom učesnika. • Ime poruke se može zadati (nov), ali ne mora. • Ako učesnik odmah po nastanku započne aktivnost, traka aktivnosti se crta neposredno ispod oznake učesnika. • Notacija za brisanje učesnika • Oznaka za brisanje učesnika je X. • Brisanje jednog učesnika od strane drugog označava se strelicom poruke. • X na kraju linije života znači da učesnik briše samog sebe. nov Upit Naredba baze podataka nov pravljenje izvrši rezultati brisanje iz drugog objekta izdvoj rezultate zatvori rezultati brisanje samog sebe

30. UML 2 Petlje i uslovi • Notacija za prikazivanje petlji • Uvode se okviri interakcije (interaction frames) koji obuhvataju deo dijagrama sekvence (fragment). • Svaki okvir sadrži operator, a može mu biti pridružen i uslov. proizvod kupac porudžbina stavka [for each stavka] loop uslov uzmiKoličinu uzmiProizvod operator proizvod uzmiPodatkeOCeni Napomena: Dijagrami sekvence nisu pogodni za prikazivanje petlji i uslova, pa je za njihovo modelovanje bolje koristiti dijagrame aktivnosti ili kod. računajOsnovnuCenu računajPopuste uzmiPodatkeOPopustima okvir interakcije

31. UML 2 Sinhroni i asinhroni pozivi Vrsta poziva Oznaka Objašnjenje Sinhrona poruka Ako pošiljalac šalje sinhronu poruku, mora sačekati da se poruka obradi da bi nastavio dalje sa radom (kao poziv podprograma). Asinhrona poruka Ako pošiljalac šalje asinhronu poruku, može da nastavi da radi, ne čekajući odgovor. Ove poruke imaju brži odziv, ali otežavaju otkrivanje grešaka.

32. UML 2 Slučajevi korišćenja(Use Case diagrams) • Slučajevi korišćenja su način prikupljanja funkcionalnih zahteva sistema. Oni opisuju uobičajene interakcije između korisnika i sistema u obliku priče. • Slučaj korišćenja je skup scenarija povezanih jednim ciljem korisnika. • Scenario je niz koraka koji opisuje interakciju između korisnika i sistema. • Primer tri scenarija • Kupac pregleda katalog i dodaje proizvode u korpu. Kada hoće da plati, on daje informacije o načinu dostave i platnoj kartici i potvrđuje kupovinu. Sistem proverava ispravnost podataka o platnoj kartici i potvrđuje prodaju. • Podaci o kartici su netačni. • Ako je kupac redovan, nije potrebno uzimati podatke o dostavi i kartici. Razlika između slučaja korišćenja i funkcija sistema je u tome što imaju različitu namenu. Funkcije opisuju sistem, a slučajevi korišćenja opisuje kako korisnici koriste sistem.

33. UML 2 Učesnici (actors) Učesnici su korisnici sistema. Oni izvode slučajeve korišćenja. • Veći broj ljudi može predstavljati jednog učesnika (na primer kupci). • Jedna osoba se može nalaziti na mestu više učesnika (na primer direktor prodaje može obavljati i ulogu prodavca). • Učesnik ne mora biti ljudsko biće (može na primer računar). Ko može biti učesnik? Odnos učesnik – slučaj korišćenja? • Jedan učesnik može izvoditi više slučajeva korišćenja. • Jedan slučaj korišćenja može imati više učesnika. Glavni učesnik (primary actor) je onaj koji traži uslugu od sistema. Ostali učesnici sa kojima sistem komuncira u datom slučaju korišćenja su sporedni učesnici (secondary actors).

34. UML 2 Sadržaj slučaja korišćenja Primer uobičajenog zapisa • Način pisanja sadržaja slučaja korišćenja nije standardizovan, pa format zavisi od slučaja. • Postupak pisanja • Navesti osnovni uspešni scenario u vidu numerisanih koraka. • Navesti sva odstupanja od osnovnog scenarija, tj. proširenja, sa referisanjem na mesta povratka (ako ih ima). • Korisni saveti • Svaki korak predstavlja deo interakcije učesnika i sistema. • Opis koraka mora biti jasan i da ukazuje na njegovog izvršioca. • Korak pokazuje nameru učesnika, a ne način kako se nešto ostvaruje. • Kupovina proizvoda • Nivo cilja: osnovni • Osnovni uspešan scenario: • Kupac pregleda katalog i bira proizvode koje hoće da kupi • Kupac završava pregled kataloga • Kupac unosi podatke o isporuci (adresa, isporuka kroz tri dana) • Sistem prikazuje sve podatke o troškovima (sa poštarinom) • Kupac unosi podatke o platnoj kartici • Sistem proverava podatke o načinu plaćanja • Sistem odmah potvrđuje prodaju • Proširenja: • 3.a Kupac je redovan • :1 Sistem prikazuje podatke o isporuci, cenama i iznosu računa • :2 Kupac potvrđuje ili menja podrazumevane vrednosti, povratak na korak 6. • 6.a Podaci o platnoj katrici nisu ispravni • :3 Kupac može ponovo uneti podatke o kartici ili prekinuti rad

35. UML 2 Uključeni slučajevi korišćenja Jedan, složeniji slučaj korišćenja može da uključuje (includes) druge, jednostavnije slučajeve korišćenja. Ne postoji standardan način tekstualnog prikazivanja uključenog slučaja korišćenja, ali se kao pogodna mogućnost preporučuje podvlačenje koje ukazuje na hipervezu. Kada se koriste uključeni SK? Primer • Kupovina proizvoda • Nivo cilja: osnovni • Osnovni uspešan scenario: • Kupac pregleda katalog i bira proizvode koje hoće da kupi • Kupac završava pregled kataloga • .................... • Pogodni za opisivanje složenih koraka koji bi zauzeli puno prostora u osnovnom scenariju. • Pogodni za opisivanje koraka koji se ponavljaju u više slučajeva korišćenja. • Nije pogodno praviti više nivoa ugnježdavanja.

36. UML 2 Dodatne informacije • Slučaju korišćenja mogu se dodati i sledeće opšte informacije: • Preduslov (pre-condition) opisuje šta mora biti ispunjeno pre nego što sistem dopusti da počne slučaj korišćenja. • Garancije (guarantee) opisuju stanje sistema na kraju slučaja korišćenja. • Okidač (trigger) određuje događaj koji dovodi do započinjanja slučaja korišćenja. • Saveti: • Količina neophodnih detalja zavisi od rizika u posmatranom slučaju korišćenja. • Elemente treba oprezno dodavati, jer slučaj korišćenja mora bit sažet i čitljiv (detaljni opisi se obično ne čitaju).

37. Ažuriranje podataka o računima Definisanje ograničenja Sistem naplate Komercijalni direktor Analiza rizika Utvrđivanje vrednosti Utvrđivanje cene Komercijalista Prodavac Utvrđivanje potražnje UML 2 Dijagrami slučajeva korišćenja • Dijagram slučajeva korišćenja je grafički prikaz sadržaja skupa slučajeva korišćenja. Ukazuje na granice sistema i njegovu interakciju sa spoljnim svetom. Prikazuje učesnike, slučajeve korišćenja i veze između njih: • koji učesnici izvršavaju koje slučajeve korišćenja • koji slučajevi korišćenja uključuju druge slučajeve korišćenja uključuje «include» «include» učesnik slučaj korišćenja granica sistema

38. UML 2 Nivoi slučajeva korišćenja • Slučajevi korišćenja se mogu razvrstati po sledećim nivoima: • Osnovni nivo (sea-level) – centralni slučajevi koji obično predstavljaju pojedinačne interakcije između glavnog učesnika i sistema. Oni daju rezultat značajan za glavnog učesnika. • Niži nivo (fish-level) - slučajevi korišćenja uključeni u slučajeve osnovnog nivoa. • Viši nivo (kite-level) – obično poslovni slučajevi korišćenja koji pokazuju kako se slučajevi osnovnog nivoa uklapaju u širi kontekst poslovnih interakcija. • Najveći broj slučajeva korišćenja treba da bude na osnovnom nivou.

39. UML 2 Dijagramiaktivnosti(Activity diagrams) Dijagrami aktivnosti služe za opisivanje logike procedura, poslovnih postupaka i toka posla. početni čvor Akcija • Struktura dijagrama aktivnosti • Početak: akcija početnog čvora (initialnode) • Izvršavanje akcije • Grananje (fork): ima jedan ulazni tok i nekoliko paralelnih izlaznih tokova • Spajanje (join): ima više ulaznih tokova i jedan izlazni tok koji započinje tek kada svi ulazni tokovi stignu do tačke spajanja • Kraj: završni čvor grananje Akcija spajanje Akcija završni čvor Postoji razlika između aktivnosti i akcije. Aktivnost predstavlja niz akcija, pa dijagram aktivnosti prikazuje aktivnost koja je sačinjena od akcija. Čvorovi u dijagramu aktivnosti su akcije, a ne aktivnosti.

40. UML 2 Paralelno izvršavanje početni čvor Primljena narudžbina Dijagram aktivnosti ima mogućnost prikazivanja paralelnih ponašanja, što je bitno jer se mnogi postupci u praksi odvijaju paralelno. Redosled izvršavanja akcija koje se odvijaju paralelno nije važan (mogu se naizmenično kombinovati akcije iz različitih tokova). Kod paralelnog izvršavanja bitna je sinhronizacija, što se prikazuje oznakom spajanja. grananje akcija Pošalji fakturu Pripremi naručeno [prioritetna narudžbina] odluka [else] tok/ivica Hitna isporuka Obična isporuka Naplati stapanje spajanje Zaključi narudžbinu završni čvor

41. UML 2 Uslovno ponašanje početni čvor U dijagramu aktivnosti uslovno ponašanje se opisuje odlukama i stapanjima. Odluka (decision) ima jedan ulazni tok i nekoliko uslovnih izlaznih tokova. Svakom izlaznom toku je pridružen jedan uslov, tj. logički izraz između ugaonih zagrada. Pri svakom nailasku na odluku moguće je nastaviti samo jednim od izlaznih tokova, pa uslovi treba da budu međusobno isključivi. Rezervisana reč [else] kao uslov ukazuje na tok kojim treba nastaviti ukoliko su netačni svi ostali uslovi odluke. Stapanje (merge) ima više ulaznih tokova i jedan izlazni. Označava kraj uslovnog ponašanja započetog odlukom. Primljena narudžbina grananje akcija Pošalji fakturu Pripremi naručeno [prioritetna narudžbina] odluka [else] tok/ivica Hitna isporuka Obična isporuka Naplati stapanje spajanje Zaključi narudžbinu završni čvor

42. UML 2 Razlaganje akcija Akcije se mogu razložiti u podaktivnosti (subactivities). Dijagram podaktivnosti se može prikazati primenom simbola račve. Ime aktivnosti Primljena narudžbina Isporuči narudžbinu Obična isporuka [else] Pošalji fakturu Pripremi naručeno Narudžbina Narudžbina [prioritetna narudžbina] Hitna isporuka Naplati Isporuči narudžbinu izlazni prametar ulazni parametar račva ukazuje na dijagram podaktivnosti Zaključi narudžbinu Pomoćni dijagram aktivnosti Poziv aktivnosti sa pomoćnog dijagrama

43. UML 2 Particije Magacin Korisnička služba Računovodstvo Primljena narudžbina Dijagrami aktivnosti pokazuju šta se dešava, ali ne i ko šta radi. Da bi se prikazalo ko izvršava koje akcije, dijagram aktivnosti se deli u particije. Particije (partitions) pokazuju koje akcije izvršava jedna organizaciona celina. Pošalji fakturu Pripremi naručeno Isporuči narudžbinu Naplati Zaključi narudžbinu Postoje jednodimenzionalna (često se zove plivačka staza) i dvodimenzionalna podela na particije.

44. Stiže taksi Potvrđen plan UML 2 Signali Akcije mogu primati i slati signale. Signali omogućavaju interakciju sa spoljnim procesima. Ukoliko aktivnost prima događaj iz spoljnog procesa, ona neprekidno osluškuje signale, a na dijagramu je opisano kako aktivnost reaguje nakon prijema signala. Oznake za prijem mogu imati i ulazni tok čime se označava da osluškivanje započinje tek kada tok aktivira prijem. Aktivnost može i da pošalje poruku, pa da sačeka odgovor pre nego što nastavi sa radom. Vremenski signal nastaje zbog protoka vremena. Primer 1 Primer 2 vremenski signal Rezerviši mesto prijem signala Pakuj stvari Dva sata pre poletanja Potvrdi putovanje Kreni na aerodrom Pošalji plan Odustani od putovanja slanje signala prijem signala Čekaj 48 sati

45. A A UML 2 Tokovi ili ivice (flow or edge) Tok ili ivica su sinonimi za opisivanje veze između dve akcije. Četiri ekvivalentna načina za prikazivanje ivica • Obična linija sa strelicom između dve akcije. Ivici se može dodeliti ime, ali ne mora. • Veznik (connector) olakšava crtanje i mora se koristiti u parovima. Oba veznika moraju biti isto obeležena. Po jedan veznik se crta za ulazni i izlazni tok. • Prosleđivanje objekata duž ivice crtanjem simbola klase. • Prosleđivanje objekata duž ivice dodavanjem nožica simbolima akcija. Primi fakturu Plati veznik Primi fakturu Plati čvor objekta Primi fakturu Plati Narudžbina nožica Narudžbina Primi fakturu Plati Narudžbina

46. «transformation» pregled.obaveštenjeOOtkazivanju «transformation» pregled.pacijent UML 2 Nožice i transformacije (pins) Akcije mogu imati parametre, kao što ih imaju metode. Informacije o parametrima se po potrebi mogu prikazivati pomoću nožica. Transformacija parametara se naznačava u slučaju kada izlazni parametri jedne akcije ne odgovaraju ulaznim parametrima sledeće akcije. Izraz za transformaciju ne sme proizvoditi sporedne efekte. To je u stvari upit na izlaznom delu nožice, a tip rezultata upita treba da odgovara ulaznoj nožici. Primer Otkaži pregled Pregled nožica za parametar Pacijent Poruka Obavesti pacijenta Izraz za transformaciju

47. UML 2 Oblasti primene akcija (expansion region) U situaciji kada nakon neke akcije treba više puta izvršiti drugu akciju, koristi se oblast primene koja predstavlja deo dijagrama aktivnosti u kome se akcije izvršavaju po jednom za svaki element kolekcije. Na sledeću akciju se prelazi nakon kompletiranja izlazne kolekcije. Brojevi elemenata u ulaznoj i izlaznoj kolekciji ne moraju biti isti (ako se oblast primene ponaša kao filtar). Dva načina obrade elemenata ulazne kolekcije • Paralelna obrada (označava se rezervisnom rečju concurrent), kada se elementi obrađuju istovremeno. • Iterativna obrada, kada se elementi moraju obrađivati jedan za drugim. Primer oblast primene rezervisana reč lista tema «concurrent» Pregledaj tekst Napiši tekst Objavi bilten nožica u obliku liste

48. UML 2 Završetak toka (flow final) Završetak toka ukazuje na kraj jednog toka, bez prekidanja cele aktivnosti. Primer Izaberi teme oblast primene lista tema Zahvaljujući završetku toka, omogućeno je da se oblasti primene ponašaju kao filtri, jer izlazna kolekcija može biti manja od ulazne. «concurrent» Pregledaj tekst Napiši tekst [prihvatanje] Objavi bilten [odbijanje] završetak toka

49. UML 2 Specifikacija spajanja (join specification) Obično se podrazumeva da spajanje dozvoljava izvršavanje izlaznog toka kada svi ulazni tokovi dođu do tačke spajanja, ali je nekad korisno uvesti složenije pravilo. Specifikacija spajanja je logički izraz koji se pridružuje spajanju. Vrednost izraza se računa svaki put kada neki tok dođe u fazu spajanja i ako je uslov ispunjen, ide se na sledeću akciju. Primer Izaberi piće A Sipaj piće B Ubaci novac {joinSpec = A i B i vrednost ubačenog novca >= cena izabranog pića} specifikacija spajanja

50. UML 2 Projektni uzorci (Design Patterns) • Projektni uzorak, obrazac ili šablon predstavlja zabeleženo široko primenjivano iskustvo u projektovanju vezano za neki opšti problem. Uzorak opisuje problem koji se često ponavlja, daje suštinu njegovog rešenja i to na takav način da se to rešenje može primenjivati u mnogim posebnim kontekstima u kojima se dati problem pojavljuje. • Osnovni elementi projektnog uzorka su: • naziv uzorka • postavka problema • opis rešenja • diskusija konsekvenci