Transcript parsisiųsti skaidrę

UML pagrindai
T120B171
UML pradžia
 8-ojo dešimtmečio viduryje atsirado technologijos,
pritaikytos objektinei analizei ir projektavimui:




Coad & Yourdon;
Booch;
Rumbaugh (the OMT technique);
Coleman (FUSION).
 Nudojama panaši metodika, tačiau skirtinga notacija.
 9-ojo dešimtmečio viduryje pereita prie standarto,
sukurto OMG (Object Management Group
www.uml.org).

The Unified Modelling Language (UML).
2
Kas tai yra UML?
 UML – standartinė kalba, skirta specifikuoti,
vizualizuoti ir dokumentuoti programinės
įrangos sistemas, taip pat naudojama ir
verslo modeliavimui ir kitokioms ne
programinėms sistemoms.
3
Pagrindiniai UML tikslai
 Suteikti vartotojams paruoštą vartojimui, išraiškingą
vizualinę modeliavimo kalbą, kad būtų galima kurti ir
keistis prasmingais modeliais.
 Projektavimo procese būti nepriklausomiems nuo
konkrečios programavimo kalbos.
 Suteikti formalų pagrindą modeliavimo kalbos
supratimui.
 Palaikyti aukštesnio lygio projektavimo sąvokas,
tokias kaip benradarbiavimas (collaborations),
frameworks, šablonai ir komponentai.
4
UML privalumai
 Kuriama sistema yra profesionaliai suprojektuojama ir






dokumentuojama dar prieš realizaciją. Tiksliai žinoma ką reikia
pasiekti.
Kadangi sistema pradžioje suprojektuojama, galima nustatyti,
kurios vietos bus perpanaudotos – mažėja kūrimo kaina.
Lengva nustatyti projektavimo klaidas.
Geras sistemos projektas užtikrina teisingą ir efektyvų
realizavimą – mažėja kūrimo kaina.
UML leidžia aprašyti sistemą norimu detalumu ir norimais
pjūviais.
Atlikti sistemos modifikacijas yra žymiai lengviau turint sistemos
UML dokumentaciją – mažėja palaikymo kaina.
UML leidžia kitiems kūrėjams greitai suvokti jūsų sistemą. Tai
visuotinai pripažintas standartas.
5
Kas yra gera sistema? (1)
 Gera (aukštos kokybės) sistema – patenkina
vartotojo poreikius.
 Naudinga ir naudojama:

gera programinė įranga palengvina žmonių
gyvenimą.
 Patikima:
 gera programinė įranga turi nedaug klaidų.
 Lanksti:
 vartotojų poreikia keičiasi laikui bėgant ir net
kuriant sistemas (palaikymas).
6
Kas yra gera sistema? (2)
 Įperkama:

darbo išlaidos yra esminė programinės
įrangos kainos dalis.
 Prieinama:

turi veikti su turima technine įranga, su
prieinama operacine sistema ir t.t.
7
Kaip kurti gera sistemą?
 Naudojamas apibrėžtas kūrimo procesas, su
aiškiomis fazėmis, kurios kiekviena turi
galutinį produktą.
 Procesas turi atitikti aiškius reikalavimus,
kurie turėtų būti apibrėžti kiek įmanoma
anksčiau.
 Procesas turi atsižvelgti į verifikavimo ir
validavimo formas, tokios kaip testavimas.
 Naudoti susijusių žinių, architektūrų ir
komponentų bazę.
8
Sistemų kūrimo etapai





Reikalavimų išgavimas;
Analizė;
Projektavimas;
Kūrimas;
Diegimas.
9
Reikalavimų išgavimas
 Ko iš mūsų nori užsakovas???
 Verslo procesų identifikavimas:
 Scenarijų diagramos (angl. activity)
 Dalykinės srities analizė:
 Aukšto lygio klasių diagrama
 Sąveikaujančių sistemų išskyrimas:
 Realizacijos (angl. deployment)
 Rezultatų pristatymas užsakovui
10
Analizė
 Panaudojimo atvejų identifikavimas:

Panaudojimo atvejų diagrama (-os) (angl. use case)
 Panaudojimo atvejai detalizuojami:

Veiksmų sekų aprašymai
 Detalizuojamos klasių diagramos:

Detalizuota klasių diagrama
 Analizuojamos sistemos galimos būsenos:

Būsenų diagrama (angl. state)
 Nustatomos objektų tarpusavio sąveikos:

Sekų ir bendradarbiavimo diagramos (angl. sequence,
collaboration)
 Analizuojama sąveika su kitomis sistemomis:

Detali realizacijos diagrama (angl. deployment)
11
Projektavimas
 Objektų diagramų kūrimas ir detalizavimas:
 Scenarijų diagramos (angl. activity)
 Komponentų diagramų kūrimas
 Diegimo (angl. deployment) plano sudarymas
 Vartotojo sąsajos projektavimas ir prototipai
 Testų kūrimas
 Dokumentacijos kūrimas:
 Dokumentacijos struktūros sudarymas
12
Kūrimas
 Kodo rašymas
 Kodo testavimas
 Vartotojo sąsajų kūrimas ir testavimas
 Pilna sistemos dokumentacija
13
Diegimas
 Sistemos atstatymo plano sudarymas
 Sistemos įdiegimas aparatūrinėje įrangoje
 Integruotos sistemos testavimas
14
UML komponentai
 UML susideda iš įvairių grafinių elementų apjungiamų
į diagramas.
 UML yra kalba, todėl egzistuoja griežtos grafinių
elementų panaudojimo taisyklės.
 Diagramų tikslas – įvairiais pjūviais aprašyti kuriamą
sistemą, t.y. sudaryti sistemos modelį.
 UML modelis aprašo ką sistema turi daryti, bet jis
nepasako kaip realizuoti tą sistemą.
15
UML diagramų tipai (1)
 Klasių diagramos (angl. class):

Skirsto daiktus į kategorijas. Klasė aprašo daiktų grupę,
kurie turi panašius atributus ir vienodą elgseną.
 Sekų (angl. sequence) diagramos:

Aprašo objektų sąveiką laike.
 Panaudojimo atvejų (angl. usecase) diagramos:

Aprašo sistemos elgseną iš vartotojo pozicijų.
 Veiklos arba Scenarijų (angl. activity) diagramos:

Aprašo veiksmų sekas.
16
UML diagramų tipai (2)
 Būsenų (angl. state) diagramos:
 Nusako objektų būsenas ir jų pasikeitimus laike.
 Bendradarbiavimo (angl. collaboration) diagramos:
 Aprašo objektų sąveiką.
 Realizacijos (angl. component, deployment)
diagramos:

Nusako sistemos komponentus ir parodo fizinę
sistemos struktūrą.
17
Panaudojimo atvejų diagramos
(Use Case)
 Aprašo sistemos funkcionalumą iš vartotojo
požiūrio taško.

vartotojas – bet koks išorinis kuriamos
sistemos naudotojas (žmogus, kita sistema,
techninė įranga ir pan.).
 Vartojimo atvejų modeliavimas padeda trims
kurimo aspektams:



reikalavimų surinkimui;
kūrimo iteracijų planavimui;
sistemos validavimui (patvirtinimui).
18
Panaudojimo atvejų diagramos
elementai
 Aktoriai (angl. Actor)
 Panaudojimo atvejai (angl. Usecase)
 Ryšiai (angl. Relationships)
 Sistemos ribos (angl. System boundary)
19
Aktoriai
 Aktoriai aprašo sistemos vartotojus
 Kiekvienas aktorius aprašo skirtingą vartotojo
rolę
 Žymima:
20
Panaudojimo atvejis
 Aprašo vieną vartotojui matomą sistemos funkciją
 Vykdant pasiekiamas konkretus vartotojo iškeltas
tikslas
 Aprašo pilną funkcionalumą
21
Detalus panaudojimo atvejo aprašymas
Taisyklės pašalinimas iš panaudojimo atvejo
Panaudojimo atvejis
UC202
Aprašymas
Tinklo valdytojas iškviečia panaudojimo atvejį atitinkančio grafinės sąsajos
komponento kontekstinį meniu, kuriame pasirenka taisyklių pašalinimo punktą.
Dialoginiame lange iš panaudojimo atvejo pašalinamos pasirinktos priskirtos taisyklės.
Aktoriai
Administratorius
Prieš-sąlyga
Panaudojimo atvejui turi būti priskirta nors viena taisyklė.
Po-sąlyga
Pasirinktos taisyklės pašalinamos iš konkretaus panaudojimo atvejo. Panaudojimo
atvejo metu vykdant konkrečias DIM užklausas, pašalintos taisyklės nebebus
tikrinamos, nors ir liks saugomos duomenų bazėje.
Grafinė sąsaja:
22
Panaudojimo atvejų modelis
 Inicijuojantis (angl. initiating) aktorius yra kairėje
panaudojimo atvejo pusėje, o priimantis (angl.
receiving) aktorius yra dešinėje pusėje.
23
Panaudojimo atvejų diagramos pavyzdys
Asociacija
Panaudojimo
atvejis
Aktorius
24
Kardinalumai
25
Quake II panaudojimo atvejų diagrama
26
Ryšiai
 <<include>>
 <<extend>>
 Aktorių hierarchija
27
<<include>>

Naudojamas nurodyti, kad atliekant vieną
panaudojimo atvejį, būtinai atliekamas ir
kitas.
28
<<extend>>

Naudojamas nurodyti, kad atliekant vieną
panaudojimo atvejį, esant tam tikrai
sąlygai, atliekamas ir kitas.
29
Aktorių hierarchija
30
Usecase projektavimo problemos (1)
 Neapibrėžtos (nenuoseklios) sistemos ribos.

Kai kurie panaudojimo atvejai aprašyti iš
verslo pusės, kiti iš sistemos.
Supainiota
sistemos sritis.
Diagrama iš
kompiuterinės
sistemos pusės
31
Usecase projektavimo problemos (2)
 Panaudojimo atvejis aprašytas iš sistemos (ne iš vartotojo)
požiūrio.
 Panaudojimo atvejo vardai apibrėžia tai, ką atlieka sistema,
vietoj tikslo, kurį aktorius nori pasiekti.
Pvz. ProcessTicket Order ir Display Schedule – tai atlieka
sistema (vardai neteisingi).
Order Tickets ir View Schedule – sistemos vartotojo tikslai
(teisingi vardai).

Panaudojimo atvejis aprašo vidinį funkcianalumą
Reikia aprašyti tai, ką sistema turi daryti, kad pasiektų
aktoriaus tikslą, o ne tai, kaip tą padaryti.
32
Usecase projektavimo problemos (3)
 Nenuoseklūs aktorių vardai.
Naudojami skirtingi aktorių vardai, apibrėžti tai
pačiai rolei.
 pvz. "Schedule Administrator", "Schedule Manager",

"Scheduler„
Ankstyvoje projekto stadijoje reikėtų sukurti terminų žodyną.
33
Usecase projektavimo problemos (4)
 Per daug panaudojimo atvejų.


Reikia įsitikinti, kad yra tinkamas panaudojimo atvejų detalumo
lygis (pav.a).
Jei sistema per didelė, reikia padalinti panaudojimo atvejus į
susijusius paketus (pav.b).
Pav. a
Pav. b
34
Usecase projektavimo problemos (5)
 Aktroriaus – panaudojimo atvejo ryšiai primena voratinklį.



Per daug ryšių tarp aktoriaus ir p.atvejo.
Aktorius sąveikauja su kiekvienu p.atveju.
P.atvejis sąveikauja su kiekvienu aktoriumi.
P.atvejų modelis su aktorių hierarchija
Aktoriai su persidengiančiomis rolėmis
35
Veiklos arba Scenarijų diagramos
(Activity)
 Verslo procesų aprašymui
 Panaudojimo atvejų detalizacijai:
 Kiekvieną panaudojimo atvejį detalizuoja viena
scenarijų diagrama.
 Būsenų diagramos plėtinys:
 Būsenų diagrama išryškina būsenas ir parodo
veiklas kaip perėjimus tarp būsenų. Veiklos
diagramos labiau koncentruojasi į pačias veiklas.
36
Elementai
 Veiksmų būsenos – aprašo sistemoje atliekamus
veiksmus.
 Perėjimas – jungia dvi veiksmų būsenas, atvaizduoja
vykdymo eigą.
 Išsišakojimas (angl. branch)
 Sinchronizavimas:


Išlygiagretinimas (angl. fork)
Apjungimas (angl. join)
 Objektai
 Signalai
37
Veiklos diagramos modelis
Pradžia (start)
Išlygiagretinimas
(fork)
Išsišakojimas
(branch)
Apjungimas (merge)
Apjungimas (join)
Pabaiga (end)
38
Veiklos diagramos pavyzdys
39
Išsišakojimas ir apjungimas
 Skirtas alternatyvioms veiksmų šakoms aprašyti.
 Nurodomos sąlygos, kurioms esant atliekama viena
arba kita veiksmų seka.
40
Išlygiagretinimas ir
sinchronizavimas
 Skirtas lygiagrečioms veiksmų šakoms aprašyti
(lygiagretiems procesams).
41
Objektai
 Veiklos metu gali būti sukurti objektai (veiklos
produktai), kurie naudojami kitose veiklose.
 Duomenys, kurie “keliauja” per veiklas.
42
Signalai
 Atliekant veiksmų sekas galima išsiųsti signalą
išoriniams procesams (objektams).
 Gautas signalas naudojamas veiksmo inicializacijai.
43
Detali veiklos diagrama
44
Pabaiga
45