Doc. dr.

Diana Kalibatienė
Dr. Jolanta Miliauskaitė

UML
UŽDUOČIŲ DIAGRAMOS
(UML Use Case Diagram)
PSI pagrindai
Literatūros šaltiniai

1. Unified Modeling Language, 2.5. Object

Management Groupe, omg.com. 2017. https://
www.omg.org/spec/UML
2. J. Sommerville. Software Engineering. 10th ed.
2016.

2
 UML užduočių diagrama
• UML užduočių diagrama modeliuoja sistemos
funkcionalumą aukštame abstrakcijos lygmenyje
iš naudotojo požiūrio taško, grindžiamo juodosios
dėžės principu.
• Nagrinėjami tik tie panaudos atvejai, kurie išoriniam
naudotojui yra suvokiami ir kurių vykdymas jiems
teikia naudą.
• Užduotys vykdomos siekiant tam tikrų tikslų.
• Kiekviena užduotis (use case) yra diskreti ir numato
išorinę sąveiką su naudotoju.
• Sistemos išorinis vaizdas.
• Reikalavimų išgavimo technika.
• Sudaro analitikas kartu su dalykinės srities
ekspertais. 3
 UML užduočių diagramos notacija
(supaprastinta)
<<Actor>>
Sistema Užduotis

Aktorius: Asmuo, sistema Užduotis nurodo pagrindines sistemos

Aktorius arba prietaisas, turintis funkcines savybes. Užduotis vykdoma
poveikį sėkmingam sistemos siekiant tam tikro tikslo.
veikimui.
Sistemos Sistemos ribos: Nustato
pavadinimas sistemos panaudojimo <<include>>
kontekstą per jos
apimti
vykdomas užduotis. <<extend>>
išplėsti
Asociacija nustato sąveiką
tarp aktoriaus ir užduoties. apibendrinti
asociacija
Nuomotis
knygą
Studentas 4
UML užduočių diagrama:
Užduotis
• Užduotis (angl. Use Case) – tai baigtinė aibė
veiksmų, aprašomų scenarijumi, ir kurie yra
vykdomi per naudotojo ir sistemos sąveiką
siekiant tam tikro tikslo, t.y. apčiuopiamos naudos
naudotojui.
• Užduočių modeliavimo teisingumas tikrinamas:
1. Kokią naudą naudotojui?
2. Ar užduotis sukuria prekę arba paslaugą?
3. Kas turi būti padaryta, o ne kaip (juodosios dėžės
principas)?
Užduočių pavyzdžiai: pirkti prekę,
registruoti klientą, parduoti, Registruoti
patikrinti sąskaitos teisingumą naudotoją
55
UML užduočių diagrama:
Aktorius
• Aktorius yra sistemos išorėje esantis naudotojas,
organizacijos padalinys, įrenginys arba kita
sistema, kuris kartu su sistema dalyvauja užduoties
vykdyme ir siekia tam tikro tikslo.
• Aktorius privalo turėti pavadinimą.
• Tai vaidmens pavadinimas, o ne konkretaus asmens
vardas.

Standartinis Aktorius-sistema:
aktoriaus <<Actor>>
Bankas,
(žmogaus) Sistema
bankomatas, ...
vaizdavimas.
Studentas 6
UML užduočių diagrama:
Asociacija
 Asociacija (association): sąveikos ryšys,
jungiantis aktorių su užduotimi.
 Parodo, kokie aktoriai sąveikauja su sistema ir ja
naudojasi jiems reikiamoms užduotims vykdyti.
 Aktorius arba inicijuoja užduotį (pirminis aktorius),
arba gauna užduoties vykdymo rezultatus (antrinis
aktorius), arba yra abiejuose vaidmenyse.

Atlikti <<Actor>>
pavedimą Banko sistema
Klientas
7
 UML užduočių diagrama:
Asociacijos kardinalumas
• Asociacija gali turėti kardinalumą:
• * – neribotas, gali būti rašoma ir 0..* arba 0..n
• n – nurodytas skaičius, pavyzdžiui, 1, 3, …
• 0..1 – neprivalomas (t.y. nei vieno arba vienas)
• 1..* – bent vienas, gali būti rašoma ir 1..n
• UML specifikacija nereglamentuoja aktoriaus darbo su
daugeliu užduočių. Tai priklauso nuo konkrečių aplinkybių.
• Aktorius gali vykdyti visas užduotis lygiagrečiai arba vieną
po kitos.
Vienas Studentas gali
vykdyti bent vieną
1 1...* arba kelias užduotis
Nuomotis „Nuomotis knygą“.
knygą

Studentas 8
 UML užduočių diagrama:
«include» ryšys tarp užduočių
• Apimti arba įtraukti – tai tarp dviejų užduočių
nukreiptas ryšys, naudojamas kai būtina elgsena,
aprašoma po-užduotimi, yra įtraukiama į pagrindinės
užduoties vykdymą. «include»
 Įgyvendinamas pakartotinio panaudojimo (re-use) principas,
kai ta pati po-užduotis naudojama kelis kartus kitų užduočių.
 Pagrindinė užduotis nėra logiškai pilna be įtraukiamos
užduoties, bet ne atvirkščiai.
Užduotis B yra išimta iš užduoties A į atskirą užduotį.

Užduotis A Užduotis A Užduotis

Užduotis B
B

Pagrindinė <<include>> Po- Išsiregistruoti <<include>> Apmokėti

užduotis užduotis iš kambario sąskaitą
99
 UML užduočių diagrama:
«include» ryšio esmė
• Stambios užduotys gali turėti tam tikrų elgesio fragmentų,
kurie gali būti išskirti į atskiras mažesnes užduotis ir
įtraukti į pagrindines užduotis, naudojant UML «include»
ryšį.
• Tikslas – palengvinti modeliavimą, taikant moduliškumo principą.
Užduotys B ir C yra išimtos iš užduoties A į atskiras užduotis.

Užduotis A Užduotis A Užduotis B

Užduotis Užduotis
C B
Užduotis
10 C
Užduotis „Išregistruoti
Išregistruoti <<include>>
Paruošti sąskaitą
svečią iš kambario“
svečią iš
apima taip pat užduotis
kambario
„Paruošti sąskaitą“ ir
<<include>> Užsakyti kambario „Užsakyti kambario
tvarkymą tvarkymą“. 10
UML užduočių diagrama:
«include» ryšio esmė
Užduotis B yra išimta iš užduočių A ir C į atskirą užduotį,
kuri pakartotinai panaudojama per «include» ryšį.

Užduotis A Užduotis A
Užduotis B

Užduotis B

Užduotis C Užduotis C
Užduotis B

Įnešti <<include>>
pinigus Abi užduotys „Įnešti pinigus“ ir
Autorizuotis „Išimti pinigus“ apima ir užduoties
<<include>> „Autorizuotis“ vykdymą.
Išimti
pinigus
11
 UML užduočių diagrama:
«extend» ryšys tarp užduočių
• Išplėsti – tai nukreiptas ryšys tarp dviejų užduočių,
nurodantis kada sąlyginė (su sąlyga) po-užduotis
įtraukiama į pagrindinės užduoties vykdymą.
• Pagrindinės užduoties vykdymas yra papildomai
išplečiamas kitos užduoties vykdymu.
• Išplėtimas gali būti suprantamas, kaip atskiras atvejis,
išimtis.

Užduotis „Registruotis“
yra prasminga naudotojui ir
po-užduotis „Gauti
pagalbą registruojantis“ <<extend>>
yra vykdoma, jeigu Registruotis Gauti pagalbą
naudotojui kilo papildomų extension point registruojantis
klausimų. Jeigu kilo
Išplėtimo taškas
klausimų
(extension point) 12
 UML užduočių diagrama:
«extend» ryšys tarp užduočių
• Išplėtimo taškas vaizduojamas pagrindinėje užduotyje po
antrašte specialioje sekcijoje, atskirtoje linija.
• Kiekvienas išplėtimo taškas turi turėti unikalų pavadinimą
pagrindinėje užduotyje.
• Išplečiamoji užduotis nėra būtina, ji vykdoma jeigu
tenkinama sąlyga.

Vykdant užduotį
„Apmokėti sąskaitą“,
jeigu nepakanka pinigų Apmokėti
sąskaitai apmokėti gali <<extend>>
būti vykdoma po-
sąskaitą Iškviesti policiją
užduotis „Iškviesti extension point
policiją“. Pateikti sąskaitą

condition: {gauta suma < kaina}

extension point: Pateikti sąskaitą13
13
 UML užduočių diagrama:
Apibendrinimo ryšys
• Apibendrinimo ryšys (generalization) – tai binarinis
nukreiptas ryšys tarp bendresnio elemento (t.y.
užduoties, aktoriaus, klasės, ...) ir konkretesnio
elemento (t.y. po-užduoties, sub-aktoriaus,
poklasio, ...).
• Tai būdas pavaizduoti, kad viena užduotis yra panaši į kitą,
bet, funkcionalumo požiūriu, yra už ją šiek tiek bendresnė.
• Konkretesnė užduotis paveldi bendresnės užduoties funkcionalumą
ir jį kuo nors šiek tiek papildo.

14
UML UŽDUOTIES
SCENARIJAI
(Scenarios)
 UML užduoties scenarijai
(Scenarios)
• UML užduočių diagramoje pateikiamas ribotas kiekis
informacijos apie jos sąveiką su naudotojais, todėl
būtina pateikti užduočių aprašus, kurie sudaryti iš:
• struktūrizuoto aprašymo lentelėje ir
• scenarijaus aprašymo (UML sekų arba komunikavimo
diagrama).
• Scenarijus – tai seka žingsnių, aprašančių aktorių
ir sistemos sąveiką.
• Skiriami užduoties pagrindinis scenarijus ir
alternatyvūs scenarijai.
• Scenarijus aprašo vieną ar keletą galimų sąveikų.
• Scenarijaus detalumas priklauso nuo užduoties
abstrakcijos lygmens. 16
UML užduoties scenarijai
Pagrindinis ir alternatyvūs scenarijai

• Pagrindinis scenarijus – tai scenarijus, kurį

vykdant sėkmingai pasiekiamas tikslas,
nesusiduriant su jokiomis ypatingomis
situacijomis, t.y. visos žemesnio lygmens po-
užduotys pabaigiamos sėkmingai.
• Alternatyvūs scenarijai yra:
• Atkuriamieji (recovery) scenarijai – tai alternatyvūs
sėkmės scenarijai, kuriuos vykdant pasitaiko ypatingų
situacijų, bet tikslas yra pasiekiamas.
• Nesėkmės scenarijai – tai alternatyvūs nesėkmės
scenarijai, kuriuos vykdant pasitaiko ypatingų situacijų
ir tikslo nepavyksta pasiekti.
17
 Užduočių modeliavimas
Scenarijaus sprogimas
• Užduočių modeliavimo problema yra scenarijaus
sprogimas (atsiranda per daug užduočių modeliavimo
abstrakcijos lygmenų).
• Jam išvengti yra naudojamos technikos:
• po-užduotys («include» priklausomybė),
• plėtiniai («extend» priklausomybė),
• Variantai – tai pusiau formalus užduoties struktūrizavimas.
• Aukšto lygmens užduotis turi vieną arba kelias įeigas ir išeigas, kurių
skirtumai aprašomi žemesnio lygmens po-užduotyse.
• Pvz.: Užduotis „Apmokėti paslaugą“ yra detalizuojama žemesnio
lygmens po-užduotimis: „Mokėti grynaisiais“, „Mokėti čekiu“, „Mokėti
kreditine kortele“ arba „Mokėti elektroniniu pavedimu“.
• Aukštesnio lygmens scenarijus nagrinėja tik tam tikras
situacijas, ignoruodamas kitas, nagrinėjamas žemesnio lygmens
18
scenarijuose.
 Užduočių modeliavimas
Scenarijaus sprogimo išvengimas per plėtinius
Pavyzdys
Išmokėti draudimą
extension points
Duomenų išsamumas
Aktoriaus užimtumas
Išimties draudimo sąlygos
Pretendentas Negaliojantis polisas
«extend»
«extend»
Nemokėti
«extend» «extend»
draudimo
Laukti laisvo
Kita draudimo
aktoriaus
bendrovė
Fizinis asmuo
Pateikti Taikyti išimties
trūkstamus sąlygas
duomenis
Vyriausybinė
įstaiga Plėtiniai reikalingi tam, kad būtų galima
apdoroti ypatingas situacijas, kurių neapdoroja
pagrindinis sėkmės scenarijus 19
19
 Užduočių modeliavimas
Užduoties aprašas lentele
užduoties numeris
užduoties pavadinimas
siekiamas tikslas
užduoties vykdymą inicijuojantis
(trigeris)
užduoties prioritetas
užduoties vykdymo sritis
užduoties lygmuo
pirminis aktorius
antriniai aktoriai
"prieš" sąlygos
sėkmingos baigties “po” sąlygos
pagrindinis sėkmės scenarijus
nesėkmingos baigties “po” sąlygos
bendresnioji užduotis
použduotys («include» priklausomybė)
plėtiniai («extend» priklausomybė)
variantai
 
 
 
įvykis Išorinis įvykis, inicijuojantis užduoties vykdymo pradžią
Svarba, lyginant ją su kitomis užduotimis.
Visa verslo sistema arba kokia nors tos sistemos dalis.
sumarinis tikslas, naudotojo tikslas, funkcija.
Inicijuoja sąveiką su sistema tam, kad pasiektų savo
tikslus.
be kurio pagalbos sistema negali įvykdyti jos vykdomų
užduočių
Sistemos arba aktorių būsenos, kurioms esant
pradedama vykdyti užduotis.
Sistemos arba aktorių būsenos, baigus vykdyti užduotį.
Sistemos arba aktorių būsenos, nepavykus įvykdyti
užduotį.
Užduotis, kurios po-užduotimi yra nagrinėjama
užduotis.
Siauresnės (dalinės) užduotys.
Po-užduotys, susidarius ypatingoms situacijoms.
Skirtingos ko nors versijos.
20
 Užduočių modeliavimas
Užduoties aprašas
Užduoties lygmuo
• Sumarinis tikslas – naudotojo tikslų rinkinys.
• Pvz.: apima visus naudotojo lygmens tikslus, susijusius su gaminio
gamyba arba paslaugos teikimu.
• Jeigu yra daug naudotojo lygmens tikslų, jie yra grupuojami pagal
sumarinius tikslus ir naudojami kaip strateginių tikslų indeksai.
• Naudotojo tikslas – pirminio aktoriaus tikslas.
• Šie tikslai domina sisteminius analitikus.
• Atitinka “vartotojo užduotis" arba “elementarius verslo procesus“.
• Funkcija – po-tikslis arba scenarijaus žingsnis,
pagalbiniai techninio pobūdžio veiksmai.
• Pvz.: „prisijungimas prie sistemos“, „prekės suieškojimas
sandėlyje“.
21
21
Užduočių modeliavimas

Projekto tikslas

Reklama Užsakymai Invoisai

Parengti Pateikti Vertinti Priimti Parengti Išsiųsti

pasiūlymą pasiūlymą sėkmę užsakymą sąskaitą sąskaitą

Nustatyti Registruoti Nustatyti Nustatyti kliento

pasiūlymo kodą klientą paslaugos kodą duomenis

Strateginiai tikslai Naudotojo tikslai Funkcijos

(užduotys)
22
UML
UŽDUOČIŲ DIAGRAMOS
MODELIAVIMO TAISYKLĖS
Bendros modeliavimo taisyklės

1. Galvok, koks naudotojo tikslas (užduotys), o ne

ką sistema daro (sistemos funkcijos):
• Užduotys – ko nori naudotojas. Pvz.: Naudotojas
išsinuomoja filmą, tvarko savo sąskaitą ir t.t.
• Funkcijos – ką daro sistema. Pvz.: Sistema įrašo
įrašą, sugeneruoja ataskaitą ir t.t.
2. Išskirk esmines (bazines) ir jas papildančias
užduotis. T.y. turi būti hierarchija tarp užduočių.
• Esminių užduočių gali būti ne daugiau 8.
• Papildančios užduotys prijungiamos prie esminių
užduočių naudojant «include» ir «extend» ryšius.

24
 Užduočių ir funkcijų skirtumai
Pradedantieji dažnai sutapatina užduotis ir funkcijas
 Tai yra klaidinga
 Užduotis aprašo naudotojo tikslus (kažką naudingo),
jai realizuoti gali prireikti kelių sistemos funkcijų.
 Funkcijos savaime nėra naudingos, naudingas jų rinkinys.
 Funkcijos pasirodo žemesniuose hierarchijos lygmenyse,
detalizuojant viršutiniame lygmenyje parodytas užduotis.

Trinti Blogas užduočių modeliavimas, nes

užsakymą pateikiamos funkcijos, ne užduotys.
Kurti Keisti
užsakymą užsakymą
Tinkamas užduočių
modeliavimas.
Pateikti
Klien užsakymą
tas
Patvirtinti Perduoti
užsakymą Klientas
užsakymą 25
Aktorių modeliavimo taisyklės
1. Aktoriams suteik prasmingus pavadinimus, atitinkančius
vaidmenį, o ne vardus arba pareigas:
• Aktorius-žmogus: Klientas, Sandėlininkas, Mokytojas, ...
• Aktorius-įmonė: Skrydžių bendrovė, Bankas, ...
2. Pirminius aktorius vaizduok diagramos kairėje pusėje, o
antrinius aktorius – dešinėje.
3. Aktorių sąveiką junk per užduotis, o ne tiesiogiai. Aktoriai
gali būti jungiami apibendrinimo ryšiu į hierarchijas.

Atlikti
pavedimą Klientas
Klientas Klientas

Atlikti
pavedimą
Petras VIP Klientas 26
VIP Klientas
Užduočių modeliavimo taisyklės
1. Užduotys įvardink veiksmažodžiais informatyviai.
• “Spausdinti sąskaitą”, o ne “Spausdinti”.
2. Užduotis grupuok pagal panašius tikslus.
3. Po-užduotis, siejamas «include» ir «extend»
ryšiais, išdėstyk iš dešinės pusės arba po
pagrindine užduotimi.
4. Po-užduotis, jungiamas apibendrinimo ryšiu su
pagrindine užduotimi, išdėstyk po pagrindine
užduotimi.

Pavyzdžiai pateikiami ankstesnėse skaidrėse.

27
„Naudok pavyzdžius iš interneto – jie geresni, nei tavo sukurtas
pirmas pavyzdys.
Bet aklai nekopijuok!

UML užduočių modeliavimo

PAVYZDYS
Restorano užduočių
modeliavimas pažingsniui
1. Apsibrėžk modeliuojamos sistemos ribas,
įvardink sistemos pavadinimą ir nustatyk
pirminius aktorius.

29
Restorano užduočių
modeliavimas pažingsniui
2. Nustatyk esmines užduotis ir ryšius.

30
 Restorano užduočių
modeliavimas pažingsniui
3. Nustatyk po-užduotis («include») ir plėtinius («extend»).

31
Restorano užduočių
modeliavimas pažingsniui
4. Nustatyk užduočių ir aktorių hierarchijas.

32
Restorano užduočių
modeliavimas pažingsniui
5. Nustatyk ryšių kardinalumą.

33
Restorano užduočių
modeliavimas pažingsniui
6. Aprašyk visas
esmines užduotis,
naudojantis
užduočių aprašų
lentele.
• MagicDraw įrankyje
paleisti užduočių
aprašymo profilį (angl.
the Use Case
Description Profile),
kad atsirastų užduočių
aprašo laukai.

34
Restorano užduočių
modeliavimas pažingsniui

Pasirink savybes pagal 20 skaidrę

35
Restorano užduočių
modeliavimas pažingsniui

Užpildykite visus įmanomus aprašus

(Description, Documentation, ...) 36
 Restorano užduočių
modeliavimas pažingsniui
Pagrindinis
vykdymo
scenarijus

Atkuriamasis
(alternatyvus)
vykdymo
scenarijus

Nesėkmės
scenarijus
37
Restorano užduočių
modeliavimas pažingsniui

38
Restorano užduočių
modeliavimas pažingsniui
7. Detalizuok kiekvieną
esminę užduotį į
žemesnio abstrakcijos
lygmens po-užduotis.
• Kaip pagalba, naudokis
kiekvienos esminės
užduoties vykdymo
scenarijumi.

• Toliau kiekviena po-

užduotis aprašoma
užduočių aprašų lentele (žr.
6 žingsnis).

39
 Restorano užduočių
modeliavimas pažingsniui
8. Aprašyk kiekvieną po-užduotį užduočių aprašų
lentele ir scenarijumi.
• Kiekviena po-užduotis aprašoma užduočių aprašų lentele (žr. 6
žingsnis).

40
 Restorano užduočių
modeliavimas pažingsniui
8. Aprašyk kiekvieną po-užduotį užduočių aprašų lentele ir
scenarijumi.
• Kiekviena po-užduotis aprašoma užduočių aprašų lentele (žr. 6 žingsnis).

41
 Restorano užduočių
modeliavimas pažingsniui
9. Sugeneruok dvi modelio ataskaitas:
1. Tools  Report Wizard  Default Template  Use
Case (Modern).
2. Tools  Report Wizard  Architecture Template 
Use Case Report.
10. Peržiūrėk ir sutvarkyk ataskaitas, jas apjunk į vieną:
• Atnaujink nuorodas (turinys, užduočių puslapių numeriai, ...)
• Apkirpk ir padidink paveikslus.
• Ištrink nereikalingus laukus.
• Papildyk tuščius laukus.
• Pridėk prie užduočių aprašų juos realizuojančių scenarijų
veiklų diagramas.
42
 Restorano užduočių modeliavimas
pažingsniui (Pirmos ataskaitos dalis)
Use Case Name: Užsakyti pasirinktą patiekalą ID: 1.4
Primary Actor:  Padavėjas
 Svečias
Goal: Patvirtinti užsakymą
Relations
Association:  Actor Padavėjas
 Actor Svečias
Pre Condition: Svečias perskaitė Valgiaraštį ir suprato, kas ten parašyta.
Post Condition: Yra patvirtintas Patiekalo užsakymas.
Scenarios
Basic Flow of 1. Rinktis Patiekalą (A3)
Events: 2. Patvirtinti Patiekalo pasirinkimą (E1)
Alternative Flow 1.1. Yra alergija
of Events: 1.1.1. Teirautis Padavėjo dėl Patiekale esančių alergenų
1.2. Yra vegetaras
1.2.1. Teirautis Padavėjo dėl vegetariškų Patiekalų
1.3. Yra mažai laiko
1.3.1. Teirautis Padavėjo dėl Patiekalo gaminimo trukmės
Exceptional Flow 2.1. Užsakymo nutraukimas
of Events: 2.1.1. Atsisakyti užsakymo
43
Klausimai?
Klausimai
10. Išvardinkite užduočių diagramos elementus paaiškinkite kaip jie
vaizduojami ir ką jie reiškia. (5)
11. Kokia užduočių diagramų paskirtis? (3)
12. Koks sistemos aspektas aprašomas užduočių diagramomis ? (1)
13. Ką užduočių diagramose vaizduoja užduotis? (1)
14. Kas užduočių diagramose gali būti vaizduojama kaip agentas? (1)
15. Kokiems tikslams užduočių diagramose agentas naudoja užduotį?
(1)
16. Kokias asociacijų rūšis galima naudoti užduočių diagramose? (2)
17. Kas užduočių diagramose vaizduojama «include» ryšiu? (1)
18. Kas užduočių diagramose vaizduojama «extend» ryšiu? Kas
vadinama išplėtimo tašku? (3)
19. Kas užduočių diagramose vaizduojama apibendrinimo ryšiu?(1)

45
Užduotys savarankiškam
darbui
Pratimai prie lentos

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją:
• "Kelionės užsakymą gali atšaukti (angl.
cancel booking) darbuotojas (angl. staff)
arba skyriaus vedėjas (angl. department
head), kuris yra taip pat darbuotojas."

47
Pratimai – galimi atsakymai

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją:
1. "Kelionės užsakymą gali atšaukti (angl. cancel
booking) darbuotojas (angl. staff) arba skyriaus
vedėjas (angl. department head), kuris yra taip pat
darbuotojas."

teisingai

48
Pratimai – galimi atsakymai

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją:
1. "Kelionės užsakymą gali atšaukti (angl. cancel
booking) darbuotojas (angl. staff) arba skyriaus
vedėjas (angl. department head), kuris yra taip pat
darbuotojas."
neteisingai

Šiuo atveju skyriaus
vedėjas (angl. department
head) nėra darbuotojas.

49
Pratimai – galimi atsakymai

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją:
1. "Kelionės užsakymą gali atšaukti (angl. cancel
booking) darbuotojas (angl. staff) arba skyriaus
vedėjas (angl. department head), kuris yra taip pat
darbuotojas."
neteisingai

Šiuo atveju darbuotojas

yra skyriaus vedėjas, bet
ne atvirkščiai.

50
Pratimai – galimi atsakymai

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją:
1. "Kelionės užsakymą gali atšaukti (angl. cancel
booking) darbuotojas (angl. staff) arba skyriaus
vedėjas (angl. department head), kuris yra taip pat
darbuotojas."
neteisingai

Šiuo atveju kelionės

užsakymą gali atšaukti
darbuotojas ir skyriaus
vedėjas kartu.

51
Pratimai savarankiškai I

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją „Bankomatas“:
• „Žinodami kaip veikia bankomatas, sudarykite jo
užduočių diagramą, kuri gali būti naudojama kaip
pagrindas reikalavimų specifikacijai. “

52
Pratimai savarankiškai II

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją „Pacientų konsultacija“ (Somerville,
2009):
• „E-Konsultacija įgalina du gydytojus, esančius
skirtingose darbo vietose, tuo pačiu metu peržiūrėti tą
patį įrašą. Vienas gydytojas inicijuoja konsultaciją,
pasirinkdamas asmenis iš išskleidžiamo gydytojų, kurie
yra tuo metu aktyvūs, meniu. Tada paciento įrašas yra
pateikiamas visiems ekrane, bet tik konsultaciją
iniciavęs gydytojas gali keisti įrašą. Be to, sukuriamas
tekstinis pokalbių langas, skirtas padėti koordinuoti
veiksmus. Daroma prielaida, kad balso konferencija
telefonu bus sukurta atskirai.“
53
Pratimai savarankiškai II

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją „Pacientų konsultacija“ (Somerville,
2009):

Galimas pradinis
variantas
Ką reikia pakeisti
pagal aprašą.
54
Pratimai savarankiškai III

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją „Pacientų konsultacija“ (Somerville,
2009):
• „Pateikite užduočių diagramą, kuri pavaizduotų
paciento konsultaciją pas gydytoją. Konsultacijos
metu gydytojas apžiūri pacientą ir, jeigu reikia, gali
išrašyti receptą vaistams.“

55
Pratimai savarankiškai IV

• Sudaryti UML užduočių diagramą pagal pateiktą

situaciją „Studento registracija į kursą“
(Somerville, 2009):
• „Pateikite užduočių diagramą, kuri pavaizduotų
studento registraciją į universiteto kursą. Į kursą
gali užsiregistruoti tik ribotas kiekis studentų, todėl
registracijos procese turi būti numatytas
patikrinimas ar registracija į kursą galima.
Įsivaizduokite, kad studentas prieina prie
elektroninio kursų katalogo, tam kad rasti galimą
kursą.“ 56