Panaudojimo atvejų modeliavimas

(„use case“ modelio sudarymas)

 USE CASE paskirtis

• Panaudojimo atvejų modelis pirmiausia pradėtas

naudoti kaip objektiškai orientuotos (OO) kalbos
UML (Unified Modelling Language) naudojamas
grafinis modelis (naudojama santrumpa – UCM)

• Pastaruoju metu UCM naudojamas įvairiose sistemų

kūrimo metodologijose (apimant ir „agile“
(lanksčiuosius) metodus)

• Apibrėžia, ką sistema turi daryti, nenusakant, kaip

tai turi būti padaryta (tai loginis sistemos modelis)
R.Butleris KTU ISK 2
 USE CASE paskirtis

• Nusako sistemos funkcionalumą išorinio sistemos

naudotojo požiūriu (reikalavimai sistemai)

• Sistemos analitikas formuoja UCM kartu su DS

ekspertais, nusakančiais reikalavimus sistemai

• UCM yra efektyvi priemonė komunikuojant IS

kūrėjams ir sistemos užsakovo (būsimojo naudotojo)
atstovams

R.Butleris KTU ISK 3

 USE CASE paskirtis

• UCM padalina sistemos veikimą į veiksmų, paslaugų

ir atsakymų elementus, kurie svarbūs (reikalingi)
sistemos naudotojams

• Žvelgiant iš naudotojo perspektyvos, UCM turi

apibrėžti tai, kas naudotojui yra reikalinga. Todėl
analitikas privalo nustatyti, kas svarbu naudotojui, ir
įtraukti tai į UCM

• UCM neaprašo techninių realizavimo ir sistemos

diegimo aspektų
R.Butleris KTU ISK 4
 USE CASE apibrėžimas

APIBRĖŽIMAS. Sistemų inžinerijoje panaudojimo

atvejų modelis (UCM) yra aktoriaus ir sistemos sąveiką
apibrėžiantis sąrašas žingsnių, atliekamų siekiant tam
tikro tikslo (aktorius gali būti asmuo arba išorinė
sistema).

•UCM nusako tris dalykinės srities aspektus:

– Aktorius, kurie inicijuoja įvykius;
– Įvykius, kurie įvykdo (sužadina) panaudojimo atvejį;
– Panaudojimo atvejus, kurie atlieka įvykio inicijuotus
veiksmus

R.Butleris KTU ISK 5

 USE CASE apibrėžimas

• UCM modelyje aktorius, naudojantis sistemą,

inicijuoja įvykį, kuris pradeda (inicijuoja) susietą
rinkinį sistemos veiksmų;

• Vienas panaudojimo atvejis pavaizduoja

(dokumentuoja) vieną transakciją ar įvykį;

• Įvykis – tai tam tikras impulsas (sužadinimas) į

sistemą, kuris įvyksta tam tikru laiku tam tikroje
vietoje ir priverčia sistemą atlikti tam tikrus
veiksmus
R.Butleris KTU ISK 6
 USE CASE modelyje naudojami žymėjimai
• Aktorius - žmogaus figūra su aktoriaus pavadinimu
apačioje;

• Panaudojimo atvejis – ovalas su įrašytu veiksmo

pavadinimu;

• Ryšiai – jungia modelį sudarančius objektus.

Naudojami šie ryšių tipai:

– Asociacija (ryšys be krypties (be rodyklių), vaizduojamas

ištisine linija) – jungia aktorių ir panaudojimo atvejį;

R.Butleris KTU ISK 7

 USE CASE modelyje naudojami žymėjimai

– Ryšys <<Include>> (ryšys su rodykle, linija punktyrinė) -

skirtas pateikti nuorodą į panaudojimo atvejį (elgsenos
faktą), kuris yra bendras keliems kitiems panaudojimo
atvejams; ryšio rodyklė rodo į bendrai naudojamą
panaudojimo atvejį
– (yra atskira nuomonė, kad Include ryšys sieja „tėvo“ (bendresnį)
panaudojimo atvejį su „vaiko“ (atskiru bendresniojo atveju)
panaudojimo atvejais (taip parodoma „tėvo“ panaudojimo atvejo
sudėtis).

R.Butleris KTU ISK 8

 USE CASE modelyje naudojami žymėjimai

– Ryšys <<Extend>> (ryšys su rodykle, linija punktyrinė) -

skirtas pateikti nuorodą į papildomą panaudojimo atvejį
(elgsenos faktą); ryšio rodyklė rodo į pagrindinį
panaudojimo atvejį

– Apibendrinimas - ištisinė linija (ryšys) su trikampe

rodykle; rodyklė rodo į bendresnįjį diagramos elementą.

R.Butleris KTU ISK 9

Ryšių žymėjimai USE CASE modelyje

R.Butleris KTU ISK 10

Systems analysis and design / Kenneth E. Kendall, Julie E. Kendall.
USE CASE modelio pavyzdys

R.Butleris KTU ISK 11

USE CASE modelio pavyzdys

R.Butleris KTU ISK 12

USE CASE modelio pavyzdys

R.Butleris KTU ISK 13

USE CASE modelio pavyzdys

R.Butleris KTU ISK 14

 USE CASE modelis – Aktorius I

• Aktorius yra traktuojamas išoriniu sistemos objektu, nes

neįeina į sistemą;

• Aktorius nusako tam tikrą sistemos naudotojo rolę;

Pavyzdžiui: aktorius, gali būti Darbuotojas , o taip pat ir

prekybos įmonės Klientas. O iš tikrųjų jie abu gali būti
vienas ir tas pats asmuo.
Šiuo atveju UCM diagramoje jis vaizduojamas atskirais
aktoriaus simboliais, nes abiem atvejais su sistema
komunikuoja kaip skirtingas roles atliekantis naudotojas.

R.Butleris KTU ISK 15

 USE CASE modelis – Aktorius II
• Bendru atveju aktorius yra išorinis objektas sistemos
atžvilgiu ir gali būti:
– asmuo (atliekantis tam tikras funkcijas, vykdantis tam tikras
pareigas),

– kita sistema (pvz., lizingo paslaugas teikianti sistema, su

kuria turi ryšį mūsų kuriama el. parduotuvė),

– įrenginys (pvz., automobilio numerio nuskaitymo kamera).

• Aktorius siejasi su vienu ar daugiau panaudojimo atvejų;

• Panaudojimo atvejis siejasi su vienu ar daugiau aktorių;

R.Butleris KTU ISK 16

 USE CASE modelis – Aktorius III

• Aktoriai gali būti grupuojami į dvi grupes: pirminiai

aktoriai ir antriniai aktoriai:

• Pirminiai aktoriai įveda duomenis į sistemą arba gauna informaciją

iš sistemos;
• Tipiniu atveju pirminiai aktoriai betarpiškai kontaktuoja su
sistema;
• Atskirais atvejais, pirminiai aktoriai tiesiogiai su sistema nedirba,
tačiau nustato panaudojimo atvejo tikslus, apibrėžia, ką
panaudojimo atvejis turi daryti;
• Antriniai aktoriai, tai kiti asmenys, padedantys atlikti pirminio
aktoriaus funkciją (pvz., tai gali būti studijų centro administratorė,
kuri padeda dėstytojui pakeisti egzamino įvertinimus įvykus klaidai)

R.Butleris KTU ISK 17

 USE CASE modelis – Aktorius IV
• Kai yra didelė aktorių gausa (jie atlieka skirtingas
funkcijas), tikslinga sudaryti aktorių profilių lentelę ,
kurioje išvardinami visi aktoriai, pateikiama kiekvieno jų
charakteristika, jų specifiniai įgūdžiai. Tai atskleidžia
detales apie aktoriaus bendravimo su sistema pobūdį.
Pavyzdžiui: jei turime aktorių – Užsakymų priėmimo
vadybininkas - jo profilis gali būti toks: „Eilinis sistemos
naudotojas, susipažinęs su specifinėmis užsakymų
registravimo savybėmis, užsakymų priėmimo išimtimis ir
užsakymų pritaikymu konkrečioms situacijoms“ .
• Kartu su tokiu aprašu gali būti pateikiama lentelė, kurioje
aprašomi kiekvieno aktoriaus tikslai ir prioritetai. Vėliau
kiekvienas detalus tikslas galėtų būti transformuotas į
panaudojimo atvejį.

R.Butleris KTU ISK 18

 Sistemos apimties apibrėžimas I
• Apibrėžiant sistemos apimtį (ribas) nustatoma, kas įeina į
sistemą ir kas yra jos išorėje

• Iš anksto žinomas projekto biudžetas, įgyvendinimo

terminai ir užsakovo prioritetai leidžia apibrėžti kuriamos
sistemos apimtį

• Aktoriai visada yra už sistemos ribų

• Ryšiai, siejantys aktorius ir panaudojimo atvejus, apibrėžia

sistemos ribas

R.Butleris KTU ISK 19

 Sistemos apimties apibrėžimas II
• Kadangi UCM kuriamas sistemos gyvavimo ciklo
pradžioje, todėl, keičiantis projekto apimčiai, projekto
biudžetas, projekto pradžia ir pabaiga gali keistis

• Analitikui gilinantis į sistemos sudėtį, UCM gali keistis,

todėl keičiasi ir sistemos apimtis

R.Butleris KTU ISK 20

Panaudojimo atvejų diagramos sudarymas I
• Pirminiai panaudojimo atvejai atvaizduoja standartinį
(įprastą) įvykių srautą sistemoje ir pavaizduoja standartinę
sistemos elgseną

• Pirminiai panaudojimo atvejai atvaizduoja normalų

(tikėtiną, sėkmingą, tipinį) panaudojimo atvejų įvykdymą

• Aprašant PA reikia paprašyti naudotoją (DS ekspertą)

išvardinti, ką sistema turi atlikti. Tai gali būti atliekama,
pavyzdžiui, interviu metu ar gyvo pasakojimo metu.

• Reikia aprašyti, kas susijęs su kiekvienu panaudojimo

atveju ir kokias paslaugas panaudojimo atvejis turi teikti
aktoriams ar kitoms sistemoms
R.Butleris KTU ISK 21
Panaudojimo atvejų diagramos sudarymas II
Sudarant UCM reikia naudotis tokiomis rekomendacijomis:

• Išnagrinėti veiklą (veiklos specifikaciją) ir nustatyti

(identifikuoti) aktorius

• Identifikuoti pagrindinius įvykius (aukšto lygio įvykius),

sumodeliuoti juos aprašančius PA ir nustatyti, kaip
aktoriai juos inicijuoja.

• Svarbu kruopščiai apibrėžti aktorių roles, kad nustatyti

visus jų inicijuojamus pirminius PA.

• Panaudojimo atvejai, kurie neturi sąveikos su naudotoju

(aktoriumi), neaprašomi
R.Butleris KTU ISK 22
Panaudojimo atvejų diagramos sudarymas III

• Peržiūrėti kiekvieną pirminį PA ir nustatyti galimas įvykių

srauto variacijas kiekvieno jų atžvilgiu. Šios analizės
pagrindu sudaromi alternatyvūs keliai, kuriuos nusako
skirtingi įvykių srautai. Kadangi kiekvienu atveju įvykių
srautai yra skirtingi, reikia išsiaiškinti, kurios veiklos
kiekviename alternatyviame kelyje įvykdomos ir kurios ne.

• Reikia identifikuoti PA logikos variantus, kurie duoda

skirtingus rezultatus.

R.Butleris KTU ISK 23

Panaudojimo atvejų scenarijaus sudarymas I
• Kiekvienas PA turi aprašą, kuris vadinamas scenarijumi

• Pirminis PA atvaizduoja standartinį įvykių srautą

sistemoje

• Alternatyvūs keliai (scenarijai) apibrėžia sistemos elgsenos

variacijas, kai susiklosto specifinės sąlygos ar aplinkybės
Pavyzdžiui, PA scenarijus gali aprašyti “kas turi būti
atliekama, jei perkamos prekės nėra sandėlyje, arba
kreditavimo įstaiga atsisako finansuoti užsakovą”

R.Butleris KTU ISK 24

Panaudojimo atvejų scenarijaus sudarymas II

• Neegzistuoja PA scenarijaus standartizuotas formatas

• Dažnai PA dokumentuojami prisilaikant PA dokumento

šablono, kuris priimtas atitinkamoje įmonėje. Toks
šablonas ir tarnauja kaip tam tikras standartas,
apibrėžiantis vidinę įmonėje taikomą dokumentavimo
tvarką

R.Butleris KTU ISK 25

 Panaudojimo atvejų scenarijaus šablonas I
Panaudojimo atvejis „Studento paieška“
Tikslas Surasti informaciją apie konkretų studentą
Prieš sąlyga Naudotojas turi būti prisijungęs studijų centro
darbuotojas
Aktorius Studijų centro darbuotojas
Sužadinimo sąlyga Naudotojas įeina į paieškos langą
Susiję PA -
Pagrindinis įvykių srautas Sistemos reakcija ir sprendimai
1. Naudotojas įveda Sistema suranda su tuo studentu susijusią
studento vardą, pavardę informaciją, kurios pageidauja naudotojas
arba numerį ir patvirtina
pasirinkimą <ieškoti>
2. Baigiamas PA
Po sąlyga: Išvedami paieškos rezultatai (studento duomenys)
Alternatyvūs scenarijai
1. Jei konkretus studentas Sistema pateikia pranešimą, kad studentas
nesurastas nesurastas. 26
R.Butleris KTU ISK
 Panaudojimo atvejų scenarijaus šablonas II
Panaudojimo atvejis „Pažymių įvedimas“
Tikslas Įvesti įvertinimus
Prieš sąlyga Naudotojas turi būti prisijungęs ir turi būti
dėstytojas
Aktorius Dėstytojas
Sužadinimo sąlyga Naudotojas įeina į pažymių įvedimo langą
Susiję PA -
Pagrindinis įvykių srautas Sistemos reakcija ir sprendimai
1.Naudotojas pasirenka, Sistema atidaro langą pažymiams įvesti
kuriam moduliui ir kuriai
grupei nori vesti pažymius.
2.Naudotojas įveda Sistema išsaugo įvertinimus
pažymius ir pasirenka
punktą, kad juos
<išsaugoti>
3. Baigiamas PA.
Po sąlyga: Įvertinimai išsaugoti sistemos DB-ėje
Alternatyvūs scenarijai
27
1.Neužpildyti visi laukai. Klaidos pranešimas
 Panaudojimo atvejų scenarijaus šablonas III
PA „Studento informacijos redagavimas“
Tikslas Pakeisti studento informaciją.
Prieš sąlyga Naudotojas turi būti prisijungęs studijų centro
darbuotojas.
Aktorius Studijų centro darbuotojas
Sužadinimo sąlyga Naudotojas įeina į langą studento informacijai
redaguoti.
Susiję PA Išplečia PA -
Apima PA PA „Studento paieška“
Specializuoja -
Pagrindinis įvykių srautas Sistemos reakcija ir sprendimai
1. Naudotojas pakeičia Sistema tikrina įvedamos informacijos korektiškumą
informaciją ir patvirtina ir pakeičia informaciją.
pasirinkimą <redaguoti>.
2. Baigiamas PA.
Po sąlyga: Informacija apie studentą pakeista sistemos DB-ėje
Alternatyvūs scenarijai
1.Jei informacija Klaidos pranešimas.
28
nekorektiška.
 Panaudojimo atvejų scenarijaus aprašymas
• Prieš sąlyga - sąlyga, reikalinga PA įvykdyti. Tai gali būti
kitas PA. Pavyzdžiui:
– “Naudotojas sėkmingai prisijungė prie sistemos”;
– “Sėkmingai įvykdytas ABC panaudojimo atvejis”.

• Po sąlyga – tai sistemos būsena, kai PA įvykdomas. Tai gali

būti:
– naudotojui reikalingos informacijos pateikimas (vizualizavimas);
– informacija perduota į kitą sistemą;
– sukurti atitinkami duomenys;
– pakoreguoti duomenys.

• Sužadinimo sąlyga - sąlyga, reikalinga PA “startuoti”

R.Butleris KTU ISK 29
AČIŪ UŽ DĖMESĮ

R.Butleris KTU ISK 30