Embed Size (px)
DESCRIPTION
A plikativn i softver. Fakultet za informatiku i menadžment Univerzitet Singidunum www.fim.singidunum.ac.yu. Unified Modeling Language UML 2. 200 8 /200 9. Violeta Tomašević Literatura Martin Flowler, UML ukratko , prevod Mikro knjiga, 2004. - PowerPoint PPT Presentation
Citation preview
Unified Modeling Language UML 2
Violeta Tomašević
Literatura
• Martin Flowler, UML ukratko, prevod Mikro knjiga, 2004.• Alan Shalloway & James Trott, Projektni obrasci, prevod Mikro knjiga, 2004.
2008/2009.
Fakultet za informatiku i menadžmentUniverzitet Singidunumwww.fim.singidunum.ac.yu
Aplikativni softver
2UML 2
Aplikativni softver
Opis problema
Rasprave o projektovanju softvera su lakše ukoliko postoji izvestan nivo apstrakcije.
Projektovanje softvera
Problemi
Prenos znanja i ideja
Komunikacija
Razumevanje
OOADOOSE
OMT
Grafičke metode
UML
Nedovoljna apstraktost programskih jezikadovela je do pojave grafičkih metoda.
Neusaglašenost postojećih grafičkih metoda dovela je do pojave UML-a.
3UML 2
Aplikativni softver
Istorija UML – a Sredinom 70-ih godina prošlog veka pojavljuju se jezici za OO modelovanje zbog povećane kompleksnosti softverskih sistema. U periodu 1989-1994.godine drastič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. godine poč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.
4UML 2
Aplikativni softver
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
5UML 2
Aplikativni softver
Objedinjen jezik za modelovanje
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.
UML se koristi za modelovanje i projektovanje softverskih sistema, naročito sistema pravljenih primenom objektno-orijentisanih tehnologija.
Čemu služi UML?
6UML 2
Aplikativni softver
Postupci razvoja
Direktni razvoj (forward engineering)
UML dijagram Programski kod
Povratna analiza (reverse engineering)
Programski kod UML dijagram
generisanje
tumačenje
7UML 2
Aplikativni softver
Načini korišćenja UML-a
UML
Izrada projekataIzrada skica
Programski jezik
8UML 2
Aplikativni softver
Izrada skicaSkice opisuju 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)
9UML 2
Aplikativni softver
Izrada UML projekataUML projekti opisuju 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.
10UML 2
Aplikativni softver
UML kao programski jezik
.
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.
ParcijalnoUML modelovanje
Programski kod
programiranj
e
Intenzivno UML modelovanje
CA
SE
alati
UML modelovanje celog sistema
CA
SE
alati
automatizacija
Programski kod Programski kod
Izvorni kod
11UML 2
Aplikativni softver
Dijagrami UML-aDijagram Namena Uvedeno u verziji
Aktivnosti proceduralno i paralelno ponašanje UML 1
Klasa klase, odlike i veze UML 1
Komponenata struktura i veze komponenata UML 1
Komunikacije interakcija između objekata-naglasak na vezama UML 1
Mašine stanja kako događaji menjaju objekat tokom njegovog postojanja
UML 1
Objekata primeri konfiguracije instanci Nezvanično u UML 1
Paketa hijerarhijska struktura tokom prevođenja Nezvanično u UML 1
Pregleda interakcije kombinacija dijagrama sekvence i aktivnosti Novo u UML 2
Raspoređivanja raspoređivanje artefakata po čvorovima UML 1
Sekvence interakcija između objekata-naglasak na sekvenci UML 1
Složene strukture razlaganje klasa tokom izvršavanja Novo u UML 2
Slučajeva korišćenja Interakcija korisnika i sistema UML 1
Vremenski interakcija između objekata-naglasak na vremenskoj promeni
Novo u UML 2
12UML 2
Aplikativni softver
Klasifikacija dijagrama
Dijagram
Dijagramponašanja
Dijagramstrukture
Dijagram mašinestanja
Dijagram slučajevakorišćenja
Dijagram aktivnosti
Dijagram interakcije
Dijagram objekata
Dijagram složenestrukture
Dijagram klasa
Vremenski dijagram
Dijagram pregledainterakcije
Dijagram komunikacije
Dijagram sekvence
Dijagram paketa
Dijagram raspoređivanja
Dijagram komponenata
13UML 2
Aplikativni softver
Dijagrami klasa (Class diagrams)
Model klase
Ime klase
Atributi klase
Operacije klase
Dijagram klasa opisuje 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.
Porudžbina
datumNaručivanja:Date[0..1]plaćenoUnapred:Boolean[1]Broj:String[1]cena:Novac
pošaljizaključi
Primer klase
14UML 2
Aplikativni softver
Svojstva klase (properties)
Svojstva klase predstavljaju strukturne karakteristike klase.
Svojstva klase
Načini predstavljanjana dijagramu
Upotreba
Asocijacije
Atributi
za predstavljanje manje važnih svojstava, kao što su datumi ili logičke promenljive
za eksplicitno isticanje važnih klasa u sistemu
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.
15UML 2
Aplikativni softver
Kardinalnost (multiplicity)
UML 2 ne dozvoljava kardinalnost sa prekidima (bilo dozvoljeno u UML 1).
Kardinalnost pokazuje 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.)
16UML 2
Aplikativni softver
Atributi (1) (attributes)
Atribut opisuje neko svojstvo u jednom redu teksta unutar odgovarajućeg dela klase.
Potpuni oblik zapisa atributa
vidljivost ime: tip kardinalnost = podrazumevana-vrednost {opis-svojstva}
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 objekata na koje se odnosi atribut podrazumevana-vrednost (default value) je vrednost atributa u novom objektu
opis-svojstva (property string) definiše dodatne osobine atributa
Objašnjenje
17UML 2
Aplikativni softver
Atributi (2)
Primer 1
-name: String [1] = “Bez naslova” {readOnly}
Porudžbina
+ datumNaručivanja:Date[0..1]+ plaćenoUnapred:Boolean[1]+ stavke:StavkaPorudzbine[*] {ordered}
Primer 2
18UML 2
Aplikativni softver
Asocijacije (associations)
Date
StavkaPorudžbine
BooleanPorudžbina+ datumNaručivanja
+ plaćenoUnapred
stavke{ordered}
izvor
odredište
1
0..1
*
1
Asocijacija opisuje 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.
Izvorna klasa Odredišna klasaime svojstva
kardinalnost
Primer asocijacije
19UML 2
Aplikativni softver
Operacije (1) (operations)
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
Operacije su aktivnosti koje klasa može da obavi.
Nadtipoperacija
Podtipoperacija
Podtipoperacija
Podtipoperacija
metod
metod1 metod2 metod3
operacija klase metod klase
Primer polimorfizma
deklaracija procedure
telo procedure
20UML 2
Aplikativni softver
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 operacijeSintaksa 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)
Obj
ašnj
enje
21UML 2
Aplikativni softver
GeneralizacijaGeneralizacija podrazumeva 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.
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.
Nadtip
Podtip 2Podtip 1
22UML 2
Aplikativni softver
Obuhvata kamionetei džipove, ali ne imotocikle
Napomene i komentari
Auto
Napomene predstavljaju 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ć.
Komentar je tekst koji se može dodati elementu dijagrama pomoću dve crtice ispred teksta (--).
Napomene i komentari se mogu pojaviti na svim vrstama dijagrama.
23UML 2
Aplikativni softver
Zavisnost (dependency)
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
Zavisnost između dva elementa postoji ako promene definicije jednog elementa, tzv. davaoca (supplier), mogu izazvati promene drugog elementa, tzv. klijenta (client).
Prozor zapregled bonusa
Zaposleni
Podaci o bonusima
Podaci ozaposlenima
klijent
zavisnost
davalac
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.
24UML 2
Aplikativni softver
Ograničenja (constraints)
Ograničenja u 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}
25UML 2
Aplikativni softver
Dijagrami sekvence (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 (activation bar) – pravougaonik na liniji života koji pokazuje kada je učesnik aktivan u interakciji
Ime klase
linija života
poruka traka aktivnosti
26UML 2
Aplikativni softver
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.
27UML 2
Aplikativni softver
Centralizovano upravljanje
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.
porudžbina stavka porudžbine proizvod kupac
računajOsnovnuCenu
računajPopuste
proizvod
uzmiProizvod
uzmiPodatkeOCeni
uzmiPodatkeOPopustima
uzmiKoličinu
primljenaporuka
učesnik
povratak
povratni poziv
računajCenu
28UML 2
Aplikativni softver
Distribuirano upravljanjeporudžbina stavka porudžbine proizvod kupac
cenaSaPopustom
računajCenu
povratak
parametar
računajCenu
uzmiCenu(količina:number)
uzmiCenuSaPopustom(porudžbina)
uzmiOsnovnuCenu
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.
29UML 2
Aplikativni softver
Pravljenje i brisanje učesnika
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.
Upravljač
Upit
Naredbabaze podataka
nov
upit nadbazompodataka
nov
izdvoj rezultate
izvrši
rezultati
zatvori
rezultati
pravljenje
brisanje iz drugog objekta
brisanje samog sebe
30UML 2
Aplikativni softver
Petlje i uslovi
Napomena: Dijagrami sekvence nisu pogodni za prikazivanje petlji i uslova, pa je za njihovo modelovanje bolje koristiti dijagrame aktivnosti ili kod.
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.
porudžbina stavka proizvod kupac
uzmiKoličinu
uzmiProizvod
proizvod
uzmiPodatkeOCeni
računajPopusteuzmiPodatkeOPopustima
računajOsnovnuCenu
loop [for each stavka]
okvir interakcije
operator
uslov
Operator Značenje
alt Alternativni izbor fragmenata – izvršava se samo onaj čiji je uslov ispunjen
loop Petlja – fragment se izvršava više puta, uslov daje osnov iteracije
opt Opcioni – fragment se izvršava samo ako je uslov ispunjen
31UML 2
Aplikativni softver
Sinhroni i asinhroni pozivi
Vrsta poziva
Sinhrona poruka
Oznaka Objašnjenje
Ako pošiljalac šalje sinhronu poruku, mora sačekati da se poruka obradi da bi nastavio dalje sa radom (kao poziv podprograma).
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.
Asinhrona poruka
32UML 2
Aplikativni softver
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 scenarija1) 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.
2) Podaci o kartici su netačni.
3) 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.
33UML 2
Aplikativni softver
Učesnici (actors)
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).
Učesnici su korisnici sistema. Oni izvode slučajeve korišćenja.
Ko može biti učesnik?
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).
Odnos učesnik – slučaj
korišćenja?
34UML 2
Aplikativni softver
Sadržaj slučaja korišćenja
Način pisanja sadržaja slučaja korišćenja nije standardizovan, pa format zavisi od slučaja.
Postupak pisanja1. Navesti osnovni uspešni scenario u vidu numerisanih koraka.2. 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:1. Kupac pregleda katalog i bira proizvode koje hoće da kupi2. Kupac završava pregled kataloga3. Kupac unosi podatke o isporuci (adresa, isporuka kroz tri
dana)4. Sistem prikazuje sve podatke o troškovima (sa
poštarinom)5. Kupac unosi podatke o platnoj kartici6. Sistem proverava podatke o načinu plaćanja7. 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
Primer uobičajenog zapisa
35UML 2
Aplikativni softver
Uključeni slučajevi korišćenjaJedan, 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.
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.
Primer Kada se koriste uključeni SK?
36UML 2
Aplikativni softver
Dodatne informacijeSluč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).
37UML 2
Aplikativni softver
Dijagrami slučajeva korišćenjaDijagram 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
Komercijalnidirektor
Komercijalista
Sistemnaplate
Prodavac
Definisanjeograničenja
Analiza rizika
Utvrđivanje cene
Utvrđivanje potražnje
Ažuriranje podataka oračunima
Utvrđivanjevrednosti
«include»
«include»
granica sistema
uključuje
učesnik
slučaj korišćenja
38UML 2
Aplikativni softver
Nivoi slučajeva korišćenjaSluč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.
39UML 2
Aplikativni softver
Dijagrami aktivnosti (Activity diagrams)
Dijagrami aktivnosti služe za opisivanje logike procedura, poslovnih postupaka i toka posla.
Struktura dijagrama aktivnosti
Početak: akcija početnog čvora (initial node)
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
Akcija
Akcija
Akcija
početni čvor
grananje
spajanje
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.
40UML 2
Aplikativni softver
Paralelno izvršavanje
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.
Primljena narudžbina
Pripremi naručeno Pošalji fakturu
Hitnaisporuka
Običnaisporuka
Naplati
Zaključi narudžbinu
početni čvor
grananje
tok/ivica
odluka
stapanje
spajanje
završni čvor
[prioritetnanarudžbina]
[else]
akcija
41UML 2
Aplikativni softver
Uslovno ponašanje
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
Pripremi naručeno Pošalji fakturu
Hitnaisporuka
Običnaisporuka
Naplati
Zaključi narudžbinu
početni čvor
grananje
odluka
stapanje
spajanje
završni čvor
[prioritetnanarudžbina]
[else]
akcija
tok/ivica
42UML 2
Aplikativni softver
Razlaganje akcijaAkcije se mogu razložiti u podaktivnosti (subactivities). Dijagram podaktivnosti se može prikazati primenom simbola račve.
Hitnaisporuka
Običnaisporuka
ulazni parametar
Narudžbina Narudžbina
[prioritetnanarudžbina]
[else]
Isporuči narudžbinu
izlazni prametar
Ime aktivnosti
Primljena narudžbina
Pripremi naručeno Pošalji fakturu
Naplati
Zaključi narudžbinu
Isporuči narudžbinu
račva ukazuje na dijagram podaktivnosti
Pomoćni dijagram aktivnosti
Poziv aktivnosti sa pomoćnog dijagrama
43UML 2
Aplikativni softver
Particije
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.
Primljena narudžbina
Pripremi naručeno Pošalji fakturu
Naplati
Zaključi narudžbinu
Isporuči narudžbinu
Magacin Korisnička služba Računovodstvo
Postoje jednodimenzionalna (često se zove plivačka staza) i dvodimenzionalna podela na particije.
44UML 2
Aplikativni softver
SignaliAkcije 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.
Pošalji planPotvrđen
planPotvrdi
putovanje
Odustani od putovanja
Čekaj 48 sati
Rezerviši mesto
slanje signala
prijem signala
Primer 2
Pakujstvari
Kreni naaerodrom
Stiže taksi
Dva sata prepoletanja
vremenski signal
prijem signala
Primer 1
45UML 2
Aplikativni softver
Tokovi ili ivice (flow or edge)
Tok ili ivica su sinonimi za opisivanje veze između dve akcije.
Primifakturu
Primifakturu
Primifakturu
Primifakturu
Plati
Plati
Plati
Plati
Narudžbina
A A
veznik
čvor objekta
nožica
Narudžbina
Narudžbina
1. Obična linija sa strelicom između dve akcije. Ivici se može dodeliti ime, ali ne mora.
2. 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.
3. Prosleđivanje objekata duž ivice crtanjem simbola klase.
4. Prosleđivanje objekata duž ivice dodavanjem nožica simbolima akcija.
Četiri ekvivalentna načina za prikazivanje ivica
46UML 2
Aplikativni softver
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.
Otkaži pregled
Obavesti pacijenta
«transformation»pregled.obaveštenjeOOtkazivanju
«transformation»pregled.pacijent
Pregled
Poruka Pacijent
nožica za parametar
Izraz za transformaciju
Primer
47UML 2
Aplikativni softver
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).
Objavi biltenPregledaj tekstNapiši tekst
«concurrent»
lista temaoblast primene
nožica u obliku liste
rezervisana reč
Primer1. Paralelna obrada (označava se rezervisnom rečju concurrent), kada se elementi obrađuju istovremeno.
2. Iterativna obrada, kada se elementi moraju obrađivati jedan za drugim.
Dva načina obrade elemenata ulazne kolekcije
48UML 2
Aplikativni softver
Završetak toka (flow final)
Završetak toka ukazuje na kraj jednog toka, bez prekidanja cele aktivnosti.
Izaberiteme
Pregledajtekst
Napišitekst
Objavi bilten
[odbijanje]
[prihvatanje]
lista tema
«concurrent»
završetak toka
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.
oblast primene
Primer
49UML 2
Aplikativni softver
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.
Izaberi piće
Ubaci novac
Sipaj piće
A
B
{joinSpec = A i B ivrednost ubačenog novca >= cena izabranog pića}
specifikacija spajanja
Primer
50UML 2
Aplikativni softver
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
51UML 2
Aplikativni softver
Naziv uzorka
Naziv uzorka se koristi da opiše projektni problem, njegova rešenja i konsekvence u par reči.
Uvođenje naziva uzorka:
omogućava projektovanje na višem nivou apstrakcije
pojednostavljuje komunikaciju u timu
olakšava dokumentovanje projekta
Ponekad se u literaturi sreće više naziva za isti uzorak.
52UML 2
Aplikativni softver
Postavka problema
Postavka problema:
objašnjava problem i njegov kontekst
opisuje u kojim situacijama se razmatrani uzorak primenjuje
daje listu uslova koji se moraju ispuniti da bi se mogao primeniti dati uzorak
opisuje strukture klasa i objekata
53UML 2
Aplikativni softver
Opis rešenja
Opis rešenja:
opisuje elemente koji predstavljaju dizajn, njihove relacije, odgovornosti i saradnje
ne opisuje konkretan dizajn ili implementaciju, jer uzorak treba da posluži kao šablon koji se može primeniti u konkretnim slučajevima
54UML 2
Aplikativni softver
KonsekvenceKonsekvence su rezultati i posledice primene projektnog uzorka. One su kritične za ispitivanje projektnih alternativa i razumevanje cene i dobiti zbog primene uzorka.
Konsekvence se obično odnose na:
prostor vreme jezik implementacione detalje
Konsekvence utiču na:
fleksibilnost sistema proširivost sistema portabilnost sistema
55UML 2
Aplikativni softver
Klasifikacija projektnih uzorakaKlasifikacija uzoraka doprinosi boljem i bržem snalaženju prilikom traženja odgovarajućeg uzorka, a istovremeno i usmerava napore ka otkrivanju novih uzoraka.
Za klasifikaciju uzoraka koriste se dva kriterijuma:
kriterijum namene, koji razvrstava uzorke u zavisnosti od toga čime se bave kreiranjem objekata (creational patterns) strukturom, tj. kompozicijom klasa i objekata (structural patterns) ponašanjem, tj načinom interakcije objekata i klasa (behavioral patterns)
kriterijum domena, koji razvrstava uzorke zavisno od toga da li se primarno primenjuju na klase ili objekte
klasni uzorci koji se fokusiraju na relacije između klasa i podklasa (class patterns) objektni uzorci koji se fokusiraju na relacije između objekata (object patterns)
56UML 2
Aplikativni softver
Prostor projektnih uzoraka
Prostor uzoraka Namena
uzorci kreiranja uzorci strukture uzorci ponašanja
Domen klasni Factory Method Adapter (class) InterpreterTemplate Method
objektni Abstract FactoryBuilderPrototypeSingleton
Adapter (object)BridgeCompositeDecoratorFacadeFlyweightProxy
Chain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor
57UML 2
Aplikativni softver
Katalog projektnih uzorakaZa svaki uzorak, katalog sadrži sledeće stavke:
Ime uzorka i klasifikacija
Namena – odgovori na pitanja "šta radi?“, “čemu služi? “ i koji problem rešava? “
Drugi nazivi – isti uzorak može imati više naziva
Motivacija – scenario koji ilustruje projektni problem
Primenljivost – situacije u kojima se uzorak može primeniti
Struktura –grafička reprezentacija klasnih i objektnih dijagrama koji opisuju uzorak
Učesnici – klase i objekti koji učestvuju u uzorku i njihove odgovornosti
Kolaboracije – kako učesnici sarađuju da bi ispunili svoje odgovornosti
Konsekvence – diskusija dobrih i loših strana primene uzorka
Implementacija – preporuke i tehnike kojih treba biti svestan pri implementaciji
Primer koda – deo koda koji pokazuje kako se uzorak može implementirati
Poznate primene – primeri primene uzorka u realnim sistemima
Korelisani uzorci – uzorci bliski sa datim, razlike među njima
UML notacija – grafički simbol za saradnju koja realizuje uzorak
58UML 2
Aplikativni softver
Prvi način: klase učesnici se crtaju u okviru saradnje
Drugi način: klase učesnici se crtaju izvan saradnje
UML 2 notacija za opis uzoraka
Uzorak
uloga1:Ucesnik1 uloga2:Ucesnik2
UzorakUcesnik1
Ucesnik2
uloga1
uloga2
59UML 2
Aplikativni softver
Primer projektnog uzorka (1)SingletonIme uzorka i klasifikacija
• Singleton – objektni uzorak kreiranja
Namena• obezbeđuje da klasa ima samo jednu instancu i daje globalni pristup toj
instanci
Motivacija• za neke klase je važno obezbediti da imaju samo po jednu instancu (pr. u
sistemu treba da postoji samo jedan dispečer štampe)• globalna promenljiva obezbeđuje da je objekat pristupačan, ali ne zabranjuje
više instanci objekta• bolje rešenje je da klasa bude sama odgovorna za jedinstvenost svoje
instance
Primenljivost • Singleton uzorak se koristi kada:
Mora postojati tačno jedna instanca klase i ona mora biti pristupačna klijentima preko svima poznate tačke pristupa
Jedina instanca treba da bude proširiva izvođenjem, a da klijenti mogu da koriste instancu izvedene klase bez potrebe da modifikuju svoj kod
60UML 2
Aplikativni softver
Struktura
Učesnici • Singleton klasa
Definiše operaciju instanca()kao operaciju klase koja daje klijentima pristup do jedinstvene instance
Može biti odgovorna za kreiranje vlastite instance
Kolaboracije• Klijenti pristupaju objektu Singleton klase isključivo kroz njenu operaciju
instanca()
Primer projektnog uzorka (2)Singleton
Singleton
-jedinstvenaInstanca: Singleton-podaci
+instanca(): Singleton+dohvatiPodatke()+nekaOperacija()
instanca():Singleton{ if (jedinstvenaInstanca==null) jedinstvenaInstanca=new Singleton; return jedinstvenaInstanca;
}
61UML 2
Aplikativni softver
Primer projektnog uzorka (3)SingletonKonsekvence – dobre strane
• Kontrolisani pristup do jedine instance pošto klasa kapsulira jedinu instancu, ona može imati striktnu kontrolu
nad tim kako i kada klijenti pristupaju instanci
• Redukovan prostor imena Singleton uzorak je bolji koncept od globalne promenljive; on izbegava
opterećivanje prostora imena globalnom promenljivom koja čuva jedinu instancu
• Dozvoljeno doterivanje operacija i reprezentacije iz Singleton klase se može izvoditi aplikaciju je lako konfigurisati instancom izvedene klase, čak i u vreme izvršenja
• Dozvoljava kontrolisano povećanje broja instanci uzorak omogućava projektantu da se po maloj ceni predomisli
i poveća broj dozvoljenih instanci
• Fleksibinost u odnosu na operacije klase drugi način za realizaciju funkcionalnosti Singleton-a je uslužna (utility) klasa sa uslužnom klasom je komplikovano promeniti broj instanci
62UML 2
Aplikativni softver
Primer projektnog uzorka (4)SingletonImplementacija C++
class Singleton {public:
static Singleton* instance();virtual void SingletonOperation();
protected:Singleton();
private:static Singleton* _instance;
}
// implementacija:Singleton* Singleton::_instance=0;Singleton* Singleton::instance(){
if (_instance == 0) _instance = new Singleton;return _instance;
}
// koriscenje:Singleton::instance()->singletonOperation();
63UML 2
Aplikativni softver
Primer projektnog uzorka (5)Singleton
Implementacija Java
class Singleton {public static Singleton instance(){
if (_instance == null) _instance = new Singleton();
return _instance;}public void singletonOperation(){/*...*/};
protected Singleton(){}private static Singleton _instance=null;
};// koriscenje:Singleton.instance().singletonOperation();
Poznate primene• u single-document aplikacijama klasa Document je Singleton• u Smalltalk jeziku svaka metaklasa (klasa čije su instance klase) ima samo
jedan objekat
Korelisani uzorci• mnogi uzorci koriste Singleton (Abstract Factory, Builder, Prototype, Facade)
64UML 2
Aplikativni softver
Primer projektnog uzorka (6)SingletonNotacija
• UML 1
• UML 2
singleton
Uzorak Singleton Documentsingleton
Singleton
singleton: DocumentUzorak Singleton Document
singletonili
