Transcript Razvoj aplikativnog softvera

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.
Aplikativni softver
2
UML 2
Opis problema
Nedovoljna apstraktost programskih jezika
dovela je do pojave grafičkih metoda.
Projektovanje softvera
Grafičke metode
Problemi
 Prenos znanja i ideja
 Komunikacija
OOSE
OOAD
OMT
 Razumevanje
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.
Aplikativni softver
UML 2
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.
3
Aplikativni softver
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

4
Aplikativni softver
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.
5
Aplikativni softver
6
UML 2
Postupci razvoja
Direktni razvoj (forward engineering)
UML dijagram
generisanje
Programski kod
Povratna analiza (reverse engineering)
Programski kod
tumačenje
UML dijagram
Aplikativni softver
7
UML 2
Načini korišćenja UML-a
Izrada skica
Izrada projekata
UML
Programski jezik
Aplikativni softver
UML 2
Izrada skica
Skice 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:
Skice u povratnoj analizi:
 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
 objašnjavaju kako radi neki deo
sistema (samo klase o kojima je
važno razgovarati)
8
Aplikativni softver
UML 2
Izrada UML projekata
UML 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:
Povratna analiza:
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.
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 omogućavaju crtanje
dijagrama i čuvanje informacija u
memoriji.
CASE alati čitaju izvorni kod,
tumačenja stavljaju u memoriju i
generišu dijagrame.
9
Aplikativni softver
10
UML 2
UML kao programski jezik
Parcijalno
UML modelovanje
Intenzivno
UML modelovanje
Programski kod
CASE alati
Programski kod
CASE alati
programiranje
automatizacija
UML modelovanje
celog sistema
Izvorni 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.
Aplikativni softver
11
UML 2
Dijagrami UML-a
Dijagram
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
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
Slučajeva korišćenja
Interakcija korisnika i sistema
Vremenski
interakcija između objekata-naglasak na
vremenskoj promeni
Novo u UML 2
Novo u UML 2
UML 1
Novo u UML 2
Aplikativni softver
12
UML 2
Klasifikacija dijagrama
Dijagram klasa
Dijagram komponenata
Dijagram
strukture
Dijagram složene
strukture
Dijagram raspoređivanja
Dijagram objekata
Dijagram paketa
Dijagram
Dijagram aktivnosti
Dijagram slučajeva
korišćenja
Dijagram
ponašanja
Dijagram mašine
stanja
Dijagram interakcije
Dijagram sekvence
Dijagram komunikacije
Dijagram pregleda
interakcije
Vremenski dijagram
Aplikativni softver
13
UML 2
Dijagrami klasa
(Class diagrams)
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.
Model klase
Primer klase
Ime klase
Porudžbina
Atributi klase
datumNaručivanja:Date[0..1]
plaćenoUnapred:Boolean[1]
Broj:String[1]
cena:Novac
Operacije klase
pošalji
zaključi
Aplikativni softver
14
UML 2
Svojstva klase
(properties)
Svojstva klase predstavljaju strukturne karakteristike klase.
Načini predstavljanja
na dijagramu
Atributi
Upotreba
za predstavljanje manje
važnih svojstava, kao što
su datumi ili logičke
promenljive
Svojstva klase
Asocijacije
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.
Aplikativni softver
15
UML 2
Kardinalnost
(multiplicity)
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
1
 0..1
*
(pr. U timu mogu da učestvuju 2 do 4 programera.)
(pr. Jedna porudžbina mora imati tačno jednog kupca.)
(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).
Aplikativni softver
16
UML 2
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}
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 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
Aplikativni softver
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}
17
Aplikativni softver
18
UML 2
Asocijacije
(associations)
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.
ime svojstva
Izvorna klasa
kardinalnost
Odredišna klasa
Primer asocijacije
Date
0..1
+ datumNaručivanja
Porudžbina
1
izvor
odredište
*
stavke
{ordered}
StavkaPorudžbine
+ plaćenoUnapred
1
Boolean
Aplikativni softver
19
UML 2
Operacije (1)
(operations)
Operacije su aktivnosti koje klasa može da obavi.
operacija klase
deklaracija
procedure
metod klase
telo
procedure
Primer polimorfizma
Nadtip
operacija
metod
Podtip
operacija
Podtip
operacija
Podtip
operacija
metod1
metod2
metod3
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
Aplikativni softver
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 (-)
Objašnjenje
 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)
Aplikativni softver
UML 2
Generalizacija
Generalizacija 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.
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.
21
Aplikativni softver
22
UML 2
Napomene i komentari
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ć.
Auto
Obuhvata kamionete
i džipove, ali ne i
motocikle
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.
Aplikativni softver
23
UML 2
Zavisnost
(dependency)
Zavisnost između dva elementa postoji ako promene definicije jednog
elementa, tzv. davaoca (supplier), mogu izazvati promene drugog elementa,
tzv. klijenta (client).
Razlozi zavisnosti između klasa:
 jedna klasa šalje poruku drugoj
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.
klijent
Prozor za
pregled bonusa
 jedna klasa sadrži drugu klasu
 objekat jedne klase prosleđuje
objekat druge klase kao parametar
neke operacije
zavisnost
davalac
Zaposleni
Podaci o
zaposlenima
Podaci o
bonusima
Aplikativni softver
24
UML 2
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}
Aplikativni softver
25
UML 2
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:
Ime klase
Linije života (lifeline) – vertikalna isprekidana
linija koja predstavlja učesnika u interakciji
linija života
poruka
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
traka aktivnosti
Aplikativni softver
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.
26
Aplikativni softver
27
UML 2
Centralizovano upravljanje
porudžbina
računajCenu
primljena
poruka
stavka porudžbine
uzmiKoličinu
proizvod
kupac
učesnik
uzmiProizvod
proizvod
uzmiPodatkeOCeni
povratak
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.
Aplikativni softver
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.
Aplikativni softver
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.
nov
Upit
pravljenje
Naredba
baze podataka
izvrši
rezultati
izdvoj rezultate
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
zatvori
rezultati
brisanje samog sebe
brisanje iz
drugog objekta
Aplikativni softver
30
UML 2
Petlje i uslovi
Notacija za prikazivanje petlji
porudžbina
 Uvode se okviri interakcije
(interaction frames) koji obuhvataju deo
dijagrama sekvence (fragment).
loop
 Svaki okvir sadrži operator, a može
mu biti pridružen i uslov.
operator
Napomena: Dijagrami sekvence nisu pogodni
za prikazivanje petlji i uslova, pa je za njihovo
modelovanje bolje koristiti dijagrame aktivnosti
ili kod.
proizvod
stavka
kupac
[for each stavka]
uzmiKoličinu
uslov
uzmiProizvod
proizvod
uzmiPodatkeOCeni
računajOsnovnuCenu
računajPopuste
uzmiPodatkeOPopustima
okvir interakcije
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
Aplikativni softver
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.
Aplikativni softver
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
1) 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.
Aplikativni softver
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).
Aplikativni softver
34
UML 2
Sadržaj slučaja korišćenja
Način pisanja sadržaja slučaja
korišćenja nije standardizovan, pa
format zavisi od slučaja.
Postupak pisanja
1. 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.
Primer uobičajenog zapisa
Kupovina proizvoda
Nivo cilja: osnovni
Osnovni uspešan scenario:
1. Kupac pregleda katalog i bira proizvode koje hoće da kupi
2. Kupac završava pregled kataloga
3. 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 kartici
6. Sistem proverava podatke o načinu plaćanja
7. 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
Aplikativni softver
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.
Primer
Kupovina proizvoda
Kada se koriste
uključeni SK?
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.
Aplikativni softver
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).
36
Aplikativni softver
37
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
Ažuriranje
podataka o
računima
Definisanje
ograničenja
Komercijalni
direktor
Analiza
rizika
Utvrđivanje
cene
«include»
«include»
uključuje
Sistem
naplate
Utvrđivanje
vrednosti
Komercijalista
učesnik
Utvrđivanje
potražnje
Prodavac
slučaj korišćenja
granica sistema
Aplikativni softver
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.
38
Aplikativni softver
39
UML 2
Dijagrami aktivnosti
(Activity diagrams)
Dijagrami aktivnosti služe za opisivanje logike
procedura, poslovnih postupaka i toka posla.
početni čvor
Akcija
Struktura dijagrama aktivnosti
grananje
 Početak: akcija početnog čvora (initial node)
 Izvršavanje akcije
Akcija
 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
spajanje
Akcija
 Kraj: završni čvor
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 .
Aplikativni softver
40
UML 2
Paralelno izvršavanje
početni čvor
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
grananje
akcija
Pripremi naručeno
[prioritetna
narudžbina]
Pošalji fakturu
odluka
[else]
Hitna
isporuka
tok/ivica
Obična
isporuka
Naplati
stapanje
spajanje
Zaključi narudžbinu
završni čvor
Aplikativni softver
41
UML 2
Uslovno ponašanje
početni čvor
U dijagramu aktivnosti uslovno ponašanje
se opisuje odlukama i stapanjima.
Primljena narudžbina
grananje
akcija
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
Pripremi naručeno
[prioritetna
narudžbina]
Pošalji fakturu
odluka
[else]
Hitna
isporuka
tok/ivica
Obična
isporuka
Naplati
stapanje
spajanje
jedan izlazni. Označava kraj uslovnog
ponašanja započetog odlukom.
Zaključi narudžbinu
završni čvor
Aplikativni softver
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]
Narudžbina
[prioritetna
narudžbina]
Narudžbina
Hitna
isporuka
Pomoćni dijagram aktivnosti
Pošalji fakturu
Isporuči narudžbinu
izlazni
prametar
ulazni
parametar
Pripremi naručeno
račva ukazuje
na dijagram
podaktivnosti
Naplati
Zaključi narudžbinu
Poziv aktivnosti sa pomoćnog dijagrama
Aplikativni softver
43
UML 2
Particije
Magacin
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.
Korisnička služba
Računovodstvo
Primljena narudžbina
Pripremi naručeno
Pošalji
fakturu
Isporuči narudžbinu
Naplati
Zaključi narudžbinu
Postoje jednodimenzionalna (često se zove
plivačka staza) i dvodimenzionalna podela na
particije.
Aplikativni softver
44
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
Dva sata pre
poletanja
Rezerviši mesto
Pakuj
stvari
Kreni na
aerodrom
Pošalji plan
prijem signala
Potvrđen
plan
Stiže taksi
prijem signala
slanje signala
Čekaj 48 sati
Potvrdi
putovanje
Odustani od
putovanja
Aplikativni softver
45
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
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.
Primi
fakturu
Plati
veznik
Primi
fakturu
A
A
Plati
čvor objekta
3. Prosleđivanje objekata duž ivice crtanjem
simbola klase.
4. Prosleđivanje objekata duž ivice
dodavanjem nožica simbolima akcija.
Primi
fakturu
Narudžbina
nožica
Primi
fakturu
Narudžbina
Narudžbina
Plati
Plati
Aplikativni softver
46
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
«transformation»
pregled.obaveštenjeOOtkazivanju
Poruka
«transformation»
pregled.pacijent
Pacijent
Obavesti pacijenta
Izraz za transformaciju
Aplikativni softver
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
1. Paralelna obrada (označava
se rezervisnom rečju
concurrent), kada se elementi
obrađuju istovremeno.
Primer
rezervisana reč
oblast primene
lista tema
«concurrent»
Napiši tekst
2. Iterativna obrada, kada se
elementi moraju obrađivati
jedan za drugim.
Pregledaj tekst
Objavi bilten
nožica u obliku liste
Aplikativni softver
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»
Napiši
tekst
Pregledaj
tekst
[prihvatanje]
[odbijanje]
završetak toka
Objavi
bilten
Aplikativni softver
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
Ubaci novac
specifikacija spajanja
B
{joinSpec = A i B i
vrednost ubačenog novca >= cena izabranog pića}
Aplikativni softver
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
Aplikativni softver
UML 2
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.
51
Aplikativni softver
UML 2
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
52
Aplikativni softver
UML 2
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
53
Aplikativni softver
UML 2
Konsekvence
Konsekvence 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
54
Aplikativni softver
UML 2
Klasifikacija projektnih uzoraka
Klasifikacija 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)
55
Aplikativni softver
56
UML 2
Prostor projektnih uzoraka
Prostor uzoraka
Domen
Namena
uzorci ponašanja
uzorci kreiranja
uzorci strukture
klasni
Factory Method
Adapter (class)
Interpreter
Template Method
objektni
Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Aplikativni softver
57
UML 2
Katalog projektnih uzoraka
Za 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
Aplikativni softver
58
UML 2
UML 2 notacija za opis uzoraka

Prvi način: klase učesnici se crtaju u okviru
saradnje
Uzorak
uloga1:Ucesnik1

uloga2:Ucesnik2
Drugi način: klase učesnici se crtaju izvan
saradnje
uloga1
Ucesnik1
Uzorak
uloga2
Ucesnik2
Aplikativni softver
59
UML 2
Primer projektnog uzorka (1)
Ime uzorka i klasifikacija
•
Singleton – objektni uzorak kreiranja
Singleton
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
Aplikativni softver
60
UML 2
Primer projektnog uzorka (2)
Singleton
Struktura
Singleton
-jedinstvenaInstanca: Singleton
-podaci
+instanca(): Singleton
+dohvatiPodatke()
+nekaOperacija()
instanca():Singleton{
if (jedinstvenaInstanca==null)
jedinstvenaInstanca=new Singleton;
return jedinstvenaInstanca;
}
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()
Aplikativni softver
61
UML 2
Primer projektnog uzorka (3)
Konsekvence – dobre strane
•
Kontrolisani pristup do jedine instance

•
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

•
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


•
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 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
Aplikativni softver
62
UML 2
Primer projektnog uzorka (4)
Implementacija C++
Singleton
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();
Aplikativni softver
63
UML 2
Primer projektnog uzorka (5)
Implementacija Java
Singleton
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)
Aplikativni softver
64
UML 2
Primer projektnog uzorka (6)
Singleton
Notacija
•
UML 1
singleton
singleton
Document
Uzorak Singleton
•
UML 2
Singleton
singleton: Document
ili
Uzorak Singleton
singleton
Document