1. No category

KPS-UML diagrami
Smisel modeliranja
Najprej model
Takoj kodiranje
UML,
The Unified Modeling Language
ALI



Majhen projekt
Veliko predznanja o problemu
Izkušeni razvijalci
2
Vizualni model
Zakaj model?
 Bolje razumemo kompleksne sisteme
 Primarni produkt razvoja je DOBER PROGRAM
 Vizualizacija in pregled nad arhitekturo
 Model je drugoten, a ne nepomemben za
 Komunikacija – o strukturi in obnašanju
 Razvoj dobrega SW ...
 Preprost prikaz, možnosti ponovne uporabe
 …ki ustreza zahtevam uporabnika ...
 Dokumentiranje načrtovalskih odločitev
 …ki je predvidljiv in pravočasen ...
 … ter preprost za vzdrževanje in dopolnjevanje.
3
4
Zgodovina UML
Kaj je torej UML?
 2005: UML 2.0
 The Unified Modeling Language (UML):
 2001: UML 1.4
 Grafični jezik
 1997: UML 1.1 “posvojil” OMG
 za vizualizacijo, specifikacijo, konstruiranje in
dokumentiranje dejstev o programsko-intenzivnem
sistemu
(Grady Booch)
5
6
1
KPS-UML diagrami
Torej
UML omogoča
 Grafični jezik – grafične “besede”
 standard zapisa sistemskega načrta
 Vizualizacija – skica mentalnega modela
 Specifikacija – preciznost, nedvoumnost, popolnost
 Konceptualno: poslovni proces in funkcije sistema
 Konstruiranje – 1:1 s prog. jezikom, DDL SQL
 Konkretno: razredi, shema PB, komponente …
ANALIZA
 Dokumentiranje – architekture, zahtev...
KAJ?
KAKO?
problemski
prostor
analysis-to-design gap
NAČRT
prostor rešitve
7
Metodologija
Jezik modeliranja + proces
8
Pogledi na sistem
 Model je abstrakcija sistema.
metoda
= (metodologija)
 Diagram je vizualni model
 predstavlja pogled na določenem nivoju abstrakcije.
 Jezik modeliranja je grafični.
 Dva tipa pogledov:
 Proces so napotki, kako razvijati SW
 struktura (statični)
 UML je neodvisen od procesa!
 obnašanje (dinamični)
9
10
UML diagrami
Diagrami primerov uporabe (use case)
 Struktura:
 Zunanji pogled na sistem
 Razredni in objektni diagram (class and object diagram)
 Opisuje interakcijo sistema z uporabniki
 Komponentni diagram (component diagram)
 Tehnika
 Diagram namestitve (deployment diagram)
 modeliranje konteksta sistema (določitev meja)
 Obnašanje
 modeliranje zahtev
 Diagrami primerov uporabe (use case diagram)
 Koristen za komuniciranje z uporabniki!
 Sekvenca, sodelovanje (sequence, communication
(collaboration) diagram)
 Diagram stanj (statechart diagram)
 Diagram aktivnosti (activity diagram)
11
12
2
KPS-UML diagrami
Akter (igralec, actor)
Primer uporabe (use case)
 Akter je del okolja:
 Scenarij (aktivnost) = zaporedje korakov, ki pomenijo
interakcijo uporabnika s sistemom
 Posameznik, drug sistem, druga naprava
 use case (primer uporabe) = značilna skupina scenarijev, ki
so potrebni, da uporabnik doseže svoj cilj
 Akter = vloga, ki jo igra uporabnik
 Akter izvaja primer uporabe in ima od njega neko korist.
 Scenarij predstavlja eno od možnih poti čez primer uporabe
 Akter ni nujno človek
13
Primer uporabe: bankomat
generalizacija
Primer uporabe
Primer
uporabe
Authenticate client
<<include>>
 Puščice označujejo tok dogodkov z vidika akterja.
 Opisuje enovit kos funkcionalnosti sistema
<<include>>
Scan retina
komunikacija
14
 Vsebina:
Check password
stereotip
razmerje vsebovanosti
Withdraw money
akter
<<extend>>
 Začetek in konec primera uporabe
 Normalen tok dogodkov
 Alternativne in izjemne tokove dogodkov
Production SW
Client
<<extend>>
Razmerje
razširitve
Deposit money
Print receipt
15
16
Primer scenarija
Praksa (primer uporabe)
Dvig na bankomatu (vključuje avtentikacijo stranke)

Glavni scenarij:
1. Stranka vstavi kartico
2. Bankomat preveri veljavnost kartice
3. Bankomat zahteva PIN (geslo)
 Uporaba v začetnih fazah
4.
5.
6.
7.
8.

 Opis uporabniških zahtev – KAJ naj bi delal sistem
 Meje sistema – kaj je noter in kaj ne
Stranka vpiše PIN, PIN je pravilen
Stranka vpiše znesek dviga, znesek je znotraj limita
Bankomat vrne kartico
Bankomat izplača denar
Bankomat izpiše potrdilo
 Ni korelacije s strukturo in implementacijo!
 Komunikacija z uporabniki
 Testiranje: scenariji postanejo testni scenariji
Alternative:
2.a Kartica neveljavna; bankomat zadrži kartico
4.a Pin ni pravilen (trikrat); bankomat zadrži kartico
5.a Znesek ni znotraj limita, pojdi nazaj na 5
8.a Bankomat ne izpiše potrdila
17
18
3
KPS-UML diagrami
Razredni diagram
Primer: razredni diagram
razred
 Ključen v OO razvoju
atribut
 Statična struktura razredov sistema
posplošitev
 Zelo bogata notacija (navadni, konceptualni, specifikacijski,
podatkovni model…)
kardinalnost
operacija
 Razred je množica objektov z enako strukturo, obnašanjem,
razmerji in pomenom.
navigacija
vloga
agregacija
asociacija
19
Razredni diagram – vidnost, povezave
20
Primer – podatkovni model
<<AssociationClass>>
Storitev_Operacija
<<stereotip>>
Razred
+ javni atribut
- privatni atribut
# zasciteni
(protected) atribut
+ javnaMetoda()
- privatnaMetoda()
# zascitenaMetoda()
Povezave:
Operacija
Asociacija
sestavlja
+dodatna operacija
0..*
<<Assoc iationCl ass>>
Vloga_Operacija
Uporabnik_Operacija
dovoljuje
Odvisnost
0..*
0..*
Dodatni razdelki (npr.
vloge razreda, itd.)
0..*
<<Associa ti onClass>>
Generalizacija
Realizacija (pri implementaciji
vmesnikov)
Storitev
avtoriz iran z a
igra
Uporabnik
0..*
<<AssociationClass>>
Uporabnik_storitev
Vloga
0..*
< <Assoc iationCl ass> >
Uporabnik_Vloga
21
22
Praksa
Objektni diagram
 Ne uporabljaj vseh notacij!
 Pojasnjuje kompleksne razrede
 problemski ekspert, analitik  konceptualni
 designer, programer  specifikacijski
 integrator  podatkovni (logične PB sheme)
23
24
4
KPS-UML diagrami
Razredni diagram…
Bančni račun
ima veliko
asociacij in
pomeni niso
čisto jasni
Podjetje
je v lasti
+prejemnik
Bančni Račun
Elektro LJ:
Podjetje
Zaslon: Podjetje
... ustrezni
objektni diagram
je v lasti
je v lasti
:Krovni račun:
:Krovni račun:
Nivo = 0
Valuta = EUR
Nivo = 0
Valuta = EUR
pripada
+prejemnik pripada
pripada
Izpisek
Račun SIT 1: Bančni račun
Račun DEM: Bančni račun
Račun USD: Bančni račun
Nivo = 1
Valuta = SIT
Nivo = 1
Valuta = DEM
Nivo = 1
Valuta = USD
+krovni
+nalogodajalec
Račun SIT 2: Bančni račun
Nivo = 1
Valuta = SIT
pripada
Paket
se nahaja na
pripada
+ prejemnik
Žiro: Bančni račun
pripada
Nivo = 2
Valuta = SIT
vključeno v
+ nalogodajalec
Splošno plačilo
osnovana na
VrsticaIzpiska
: Paket
Izpisek prejemnika:
Izpisek
vključeno v
Plačilo v tujino
pripada
Domače plačilo
T estno plačilo:
Domače plačilo
Izpisek nalogodajalca:
Izpisek
se nahaja na
se nahaja na
Vrstica prejemnika:
Vrstica Izpiska
Vrstica nalogodajalca:
Vrstica izpiska
osnovana na
25
26
Diagram zaporedja (sequence)
Diagrami interakcije
objekt
: CorporateUser
: SmartCardReader
: SmartCard
: Authorization
: BAP+Client
create( )
 Diagrami zaporedja (sequence diagram) in sodelovanja
(collaboration diagram)
create( )
sporočilo
create( )
Get settings
from registry
 Semantično sta enakovredna: opisujeta sodelovanje skupine
objektov
komentar
pogoj
getStatus( )
Inserted
* [3 times] PIN: string
 Diag. zaporedja: zaporedje sporočil
iteracija
 Diag. sodelovanja: organizacija objektov
kreiranje
vrnitev
aktivnost
checkPIN(PIN)
checkPIN(PIN)
 Tipična uporaba: realizacija primerov uporabe
Klic sebi
PinOK?(pin)
PINOK
PINOK
Življenjska črta
27
Diagram sodelovanja
zap. št.
Iz prakse:
7: checkPIN(PIN)
ponovitve pogoj
klic
sebe
9: pinOK(PIN)
 Tipična uporaba:
4: getStatus()
 Realizacije primerov uporabe
3: create()
8: checkPIN(PIN)
 Implementacija obnašanja razredov
6: * [< 3 times] PIN
1: create()
28
5: Inserted
10: pinOK
: SmartCardReader
: Authorization
 Sekvenčni: zaporedje sporočil.
: SmartCard
11: pinOK
2: create()
: CorporateUser
 Sodelovanje: poudarek na organizaciji.
 Nariši več diagramov, ki bodo prikazovali različne scenarije ali
različne poti skozi nek proces.
sporočilo
objekt
: BAP+Client
29
30
5
KPS-UML diagrami
Diagram stanj
Primer: diagram stanj
spremenjen
/ ustvari paket
spremenjen
Zač. stanje
 Prikazuje življenjski cikel objekta.
akcija
 Dogodki povzročajo spremembe stanj objekta.
sopodpisi
dogodek
Odprt
 Prikazuje vsa stanja, v katerih je lahko nek objekt.
pogoj
/ odpri
podpisan[ vsi podpisi ] / preveri potrebne podpise
/ zapri
podpisan[ manjkajoci podpisi ]
 Stanje: pretekle “izkušnje”, množica podatkov. Obnašanje
objekta je odvisno od stanja.
Delno
podpisan
stanje
spremenjen
podpisan[ vsi podpisi ]
Zaprt
Podpisan
/ izbrisi
izrocen
prehod
preklican
spremenjen
končno stanje
Izbrisan
Izrocen
/ izbrisi
V arhivu
[ OK ] / arhiviraj
poslan v obdelavo Zavrnjen
V
obdelavi
/ izbrisi
[ nepravilnosti ] / Zavrni
31
32
Iz prakse:
Diagram aktivnosti
 Kako se stanje objekta spreminja – prek različnih primerov
uporabe
 Opisuje zaporedje aktivnosti.
 aktivnost iz resničnega sveta (npr. podpis)
 Le za objekte z zanimivimi stanji oz. prehodi.
 Izvajanje metode nekega razreda
 Dovoljena je paralelnost
 Ni objektno usmerjen (analogija s klasičnim diagramom
poteka)
33
Primer: diagram aktivnosti
Vejitev in
združitev
Uporabnik : CorporateUser
start
Uradni list RS, št. 32/94; zadnji
popravek 6/97.
Navodilo o opravljanju plačilnega
prometa s tujino
opomba
[ nalog za izvršitev nakazila v tujino ]
Izpolni obrazec
1450
Izpolni obrazec
1451
[ ni OK ]
[ ne obstaja ]
[ OK ]
vejitev
Uradni list RS, št.
1/9.1.1999 str. 66
Pošlji v banko
 Prikaz toka dogajanja
 Analiza primera uporabe
varovalka
[ ni OK ]
“join”
 Slabo: ni jasne povezave med aktivnostmi in objekti
 Opis kompleksne metode
[ obstaja dogovor o hranjenju fakture v podjetju ]
Preglej
obrazec
 Dobro: Opis paralelnega dogajanja
 Uporaba
konec
Podpiši
obrazec
“fork”
Preglej fakturo
“swimlane”
Preglej
obrazec
activity
Dodaj fakturo
Iz prakse:
Bančni uradnik
Podpisnik : Signer
[ nalog za odprtje akreditiva ]
34
Pošlji obvestilo v
podjetje
Zavrni pošiljko
Preglej
obrazec
35
36
6
KPS-UML diagrami
Fizični diagrami
Primerjava diagramov
 Komponentni in diagrami namestitve (deployment)
 Interakcija – več objektov v enem primeru uporabe
 Diagram stanj - en objekt z več stanji prek več primerov
uporabe
 Diagram komponent prikazuje
 fizične module (prevedeno enoto, DLL, exe, html stran…)
 Diagram aktivnosti – dogajanje prek več primerov uporabe
 Komponenta je fizični paket razredov.

Diagram namestitve prikazuje:
 fizične HW enote (vozlišča, povezave…)
 Povezave med SW in HW komponentami
37
Primer: komponentni diagram
GWm
38
Primer: diagrami namestitve
komponenta
GW1
HTTP
HTTP
<<ASP page>>
vb-BAP.asp
stereotip
HTTP
<<ASP Page>>
VB-BAO.asp
vozlišče
<<ISAPI function>>
GetSebState
stereotip
SEB2
GW2
read
read
SEB1
<<HTTP>>
<<file>>
sebStatus.dat
Router
odvisnost
read
R/W
<<HTTPS, XML>>
ZVB
Firewall DMZ
<<Application>>
SetSebState
<<HTTP>>
povezava
<<file>>
vb.cer
<<NT service>>
InnerMonitor
HTTP
HTTP
COM
<<DLL>>
InnerTesting
<<DLL>>
SEBTesting
Outer Virtual
Client
COM
<<COM>>
SEB
opomba
GWm
<<HTTP>>
SEBn
HTTP
<<ASP>>
BAO
<<ASP>>
BAP
<<ISAPI>>
BAPPlus
Gateway
39
Inner Virtual
Client
40
<<IE certificate>>
vb.pfx
GWm
HTTPS, XML
<<DLL>>
OuterTesting
COM
outerMonitor
Iz prakse:
UML
 Uporaba: za testiranje in podporo razumevanje arhitekture
sistema)
 Nekaj modeliranja koristi
 Porazdeljeni sistemi – diagrami namestitve so skoraj
obvezni.
 Ne pretiravaj s količino in podrobnostmi!
 Izberi problemu primerne diagrame
 Poudari pomembne stvari
 Neformalne skice – tudi zelo uporabne.
 Standardna notacija
 Lahko si dovoliš nekaj svobode pri sintaksi
41
42
7
KPS-UML diagrami
Povzetek
Prednosti in slabosti
 Komuniciranje s problemskimi strokovnjaki:
 Prednosti:
 enoten standard, razširljiv (stereotipi), prilagodljiv
 Primeri uporabe (izgled)
 Razredni (koncepti)
 Slabosti
 Prepad med analizo in načrtovanjem
 Aktivnost (tok dogodkov)
 Podatkovna baza: razredni
 Bogata notacija
 Analiza in načrtovanje programa:
”You can model 80 percent of most problems by using
about 20 percent of the UML." Grady Booch
 Vmesniki, razredi, sodelovanje
 Povratni inženiring (reverse engineering)
 Vzorci (design patterns)
43
44
8