SOFTVERSKO INŽENJERSTVO Vježbe 7: Realizacija use case-ovaweb.studenti.math.pmf.unizg.hr/~manger/si/SI-vjezbe-07.pdf · podataka znači da je riječ o određenom primjerku klasifikatora,

SOFTVERSKO INŽENJERSTVO

Vježbe 7: Realizacija use case-ova

Robert Manger

Sveučilište u Zagrebu

PMF-Matematički odsjek

Akademska godina 2019/2020.

Sadržaj Vježbi 7

Općenito o realizaciji use case-ova

Životni tokovi sudionika u interakciji

Poruke između životnih tokova

Vrste interakcijskih dijagrama

Sequence dijagrami

Operatori, kombinirani fragmenti

Opetovane pojave iste interakcije

Communication dijagrami

2Softversko inženjerstvoV-07

Općenito o realizaciji use case-ova Realizacija use case-ova zajedno s pronalaženjem klasa

predstavlja glavni rezultat kojeg analiza treba stvoriti.

Dok klase modeliraju statičku strukturu sustava, realizacija

use case-ova prikazuje dinamiku sustava.

Da bi realizirali pojedini use case, moramo pokazati da se

njegova funkcionalnost može postići interakcijom objekata

iz pronađenih klasa.

Pronalaženje klasa i realizacija use case-ova zapravo su

iterativne aktivnosti, to jest jedna aktivnost ispravlja drugu.

Realizacija pojedinog use case-a dokumentira se pomoću

nekog od interaction dijagrama, na primjer sequence ili

communication dijagrama.

Osnovni elementi koji se pojavljuju na tim dijagramima su

životni tokovi i poruke.


Životni tokovi sudionika u interakciji Životni tok (lifeline) pokazuje kako jedan primjerak

određenog klasifikatora (obično klase ili aktera)

sudjeluje u određenoj interakciji.

Životni tok može imati ime, tip i selektor.

Ime je neobavezno i ono se odnosi na uočeni primjerak

klasifikatora.

Tip je obavezan i on se odnosi na klasifikator.

Selektor je neobavezan, sastoji se od logičkog uvjeta kojim

se bira primjerak klasifikatora.

Životni tok može se odnositi na:

sasvim određeni primjerak klasifikatora (instance form

interaction diagram),

na proizvoljni primjerak klasifikatora (generic form

interaction diagram).


Prikazivanje životnog toka na dijagramu Osnovni podaci životnog toka zapisuju se u sintaksi:

ime [ selektor ] : tip . Na primjer:

Podvlačenje osnovnih

podataka znači da je

riječ o određenom

primjerku klasifikatora,

inače je riječ o

generičkom primjerku.

Za sam životni tok

koristi se ista ikona kao

za odgovarajući tip

klasifikatora. Primjerice:


Poruke između životnih tokova Poruka je oblik komunikacije između dva životna toka

koji su u interakciji. Primjerice, može se raditi o: pozivanju operacije (pozivna poruka),

stvaranju ili uništavanju primjerka klasifikatora,

slanju signala.

Kad životni tok primi pozivnu poruku, on mora izvršiti

operaciju koja ima istu signaturu kao poruka.

Dok životni tok izvršava operaciju, kažemo da on ima

žarište kontrole (focus of control) ili aktivaciju

(activation).

Tijekom vremena, aktivacija se premješta iz jednog

životnog toka u drugi – to se zove tok kontrole.

Pozivna poruka može biti sinkrona ili asinkrona, ovisno

o tome da li pošiljatelj čeka da primatelj do kraja izvrši

operaciju ili ne čeka.


Vrste poruka i njihovo prikazivanje Sinkrona pozivna poruka

Asinkrona pozivna poruka

Povratna poruka kojom primatelj

ranije pozivne poruke vraća rezultat i

aktivaciju pošiljatelju.

Stvaranje primjerka klasifikatora koji

je naveden kao primatelj

Uništavanje primatelja

Poruka čiji pošiljatelj je izvan dosega

interakcije (found message)

Poruka koja nikad ne stiže do svog

odredišta (lost message)

aMessage (aParameter)

aMessage (aParameter)

<<create>>aMessage (aParameter)

<<destroy>>


Vrste interakcijskih dijagrama Sequence dijagram (koristi se u analizi i oblikovanju).

Naglašava vremenski slijed slanja poruka između životnih

tokova.

Communication dijagram (koristi se u analizi i oblikovanju).

Naglašava strukturu veza između objekata koji stupaju u

interakciju.

Interaction overview dijagram (rijetko se koristi).

Prikazuje odnose između drugih interakcija, služi za

modeliranje cjelokupnog toka kontrole u sustavu.

Timing dijagram (koristi se samo u oblikovanju).

Naglašava aspekte realnog vremena (preciznog tajminga)

unutar interakcije.


Općenito o sequence dijagramu Vrijeme teče od vrha prema dnu.

Životni tokovi su poredani s lijeva na desno. Redoslijed tokova bira se tako da se smanje presjecanja crta.

Svaki tok ima crtkani vertikalni rep koji označava njegovo trajanje.

Aktivacija je označena duguljastim vertikalnim pravokutnikom

preko repa.

Na repu se mogu označiti i promjene stanja dotičnog klasifikatora.

Te promjene su obično uzrokovane prijemom poruke. Novo stanje

crta se kao zaobljeni pravokutnik.

Poruke su prikazane vodoravnim strelicama koje spajaju

repove životnih tokova i poredane su u vremenskom

redoslijedu.

Uz lijevi rub dijagrama smještaju se objašnjenja (scripts).

Mogu se pojaviti i oznake (labele) , te ograničenja (logički

uvjeti) pisani u vitičastim zagradama.


Primjer sequence dijagrama (1)


U sklopu

sustava za

praćenje

studenata i

kolegija treba

realizirati use

case AddCourse

kojim se uvodi

novi kolegij.

Detaljna

specifikacija

use case-a

izgleda ovako.



U početnom dijelu analize stvoren je ovakav class

dijagram koji prikazuje klase na razini analize i veze

među njima.



Na osnovi prethodne detaljne specifikacije i class

dijagrama stvaramo sljedeći sequence dijagram koji

predstavlja realizaciju use case-a AddCourse.

Primjer sa samo-delegacijom (1)


U sklopu istog

sustava za

praćenje

studenata i

kolegija

promatramo

use case

DeleteCourse

kojim se briše

kolegij.

Detaljna

specifikacija

tog use case-a

izgleda ovako.

Primjer sa samo-delegacijom (2)


Sequence dijagram kojim se realizira DeleteCourse izgleda

ovako. Ovdje

životni tok

šalje poruku

samom sebi

– to se zove

samo-

delegacija

(self-

delegation),

i njome se

stvara

ugniježđena

aktivacija.

Primjer s promjenama stanja (1)


U sustavu za naručivanje robe preko Interneta gledamo

use case ProcessAnOrder. Specifikacija izgleda ovako.

Primjer s promjenama stanja (2)


Vidimo kako

objekt :Order

mijenja

stanja.

Također

vidimo

primjer

ograničenja

(constraint).

U tom use case-u vrijede sljedeća poslovna pravila. Narudžba treba biti u cijelosti plaćena jednom uplatom.

Roba navedena u narudžbi isporučuje se nakon plaćanja.

Roba mora biti isporučena kupcu unutar 28 dana od dana plaćanja.

Sequence dijagram koji realizira ProcessAnOrder izgleda

ovako.

Operatori i operandi Kod složenijih use case-ova potrebno je osigurati:

uvjetno slanje poruka,

iterativno slanje poruka.

Odgovarajuća tvorevina u UML-u naziva se operator.

Postoji nekoliko vrsta operatora, svaki od njih određuje

jedan način uvjetnog ili iterativnog komuniciranja.

Operatore možemo smatrati analogonima naredbi za

grananje ili petlje iz programskih jezika.

Poruke na koje se određeni operator odnosi zovu se

operandi tog operatora.

Uz operand ili uz operator može biti zadan logički uvjet

koji određuje hoće li se taj operator odnosno operand

zaista izvršiti. Takav logički uvjet naziva se stražar

(guard condition).


Kombinirani fragmenti Operator, operandi i stražari prikazuju se na sequence dija-

gramu unutar posebnog okvira – to je kombinirani fragment.


Operator i njegov

stražar zapisuju se

u “uhu” okvira.

Operandi su sve

poruke koje su se

našle unutar okvira.

Stražar pojedinog

operanda piše se

uz odgovarajuću

strelicu.

Stražari se pišu u

pseudokodu i

stavljaju u uglate

zagrade.

Popis važnijih operatora opt … postoji samo jedan operand i on se izvršava samo

ako je stražar uz opt istinit (analogon od if-then).

alt … izvršit će se samo jedan operand, i to onaj čiji

stražar je istinit (analogon od switch-case).

loop … operandi će se izvršiti više puta (analogon za for,

while ili repeat-until).

break … ako je stražar istinit, izvršava se operand, te se

napušta cijeli kombinirani fragment (analogon za

break).

par … svi operandi se izvršavaju paralelno.


Razne varijante operatora loop loop ili loop * … beskonačna petlja.

loop min, max [uvjet] … ponavljaj min puta bezuvjetno, zatim

ponavljaj najviše (max-min) puta dok god je uvjet

istinit.

loop [uvjet] … ponavljaj dok je uvjet istinit (analogon za

while).

loop 1, * [uvjet] … ponovi jednom, zatim ponavljaj dok god je

uvjet istinit (analogon za repeat-until).

loop [for each object in collectionOfObjects] … izvrši cijeli

fragment jednom za svaki objekt iz zadanog skupa

objekata.

loop [for each object in ClassName] … izvrši cijeli fragment

jednom za svaki objekt iz zadane klase.


U sustavu za

prodaju preko

Interneta

promatrajmo

use case

ManageBasket,

koji opisuje

ažuriranje

količine nekog

predmeta u

korisnikovoj

“košarici” ili

izbacivanje

predmeta iz

košarice.


Primjer grananja s opt i alt (1)

Primjer grananja s opt i alt (2) Odgovarajući class dijagram

izgleda ovako.


Realizacija use case-a ManageBasket opisana je

sljedećim sequence dijagramom.


Primjer grananja s opt i alt (3)

Primjer iteracije s loop i break (1) Promatrajmo opet class dijagram sustava za praćenje

studenata i kolegija.


Sljedeći sequence dijagram prikazuje jednu od

mogućih realizacija operacije findCourse() iz klase

RegistrationManager.


Primjer iteracije s loop i break (2)

Ime (uloga) jednog kraja asocijacije s multiplicitetom

većim od 1 koristi se kao ime kolekcije objekata.

Opetovane pojave iste interakcije Dešava se da se isti niz poruka ponavlja na raznim

sequence dijagramima. Tada se taj niz poruka može izdvojiti u zasebnu interakciju koja se

može uključiti u druge interakcije.

Izdvojenu interakciju možemo smatrati analogonom potprograma

iz programskog jezika.

Kao i potprogram, takva interakcija može imati svoje parametre, te

može vraćati vrijednost.

Korištenje izdvojene interakcije unutar druge interakcije

zove se pojava interakcije (interaction occurence).

Pojava interakcije prikazuje se na sequence dijagramu

slično kao operator, dakle kao kombinirani fragment. Ključna riječ ref piše se u “uhu” okvira.

Ime izdvojene interakcije s listom parametara može se pojavljivati

ili u uhu ili u tijelu okvira.


Primjer pojave interakcije bez par (1) Opet se bavimo sustavom za praćenje studenata i kolegija.


Zamislimo da se

osoba koja

upisuje studente

i kolegije najprije

mora “logirati” u

sustav. Tada na

class dijagram

moramo dodati

novu klasu

SecurityManager

koja služi za

provjeru imena i

lozinke.

Postupak

logiranja

opisan je

use case-

om LogOn

Registrar.


Primjer pojave interakcije bez par (2)

Primjer pojave interakcije bez par (3)


Taj use case realiziran je istoimenim sequence

dijagramom koji ujedno predstavlja izdvojenu interakciju.

Primjer pojave interakcije bez par (4) Sljedeći sequence dijagram ChangeStudentAddress realizira

postupak promjene studentove adrese i on uključuje

prethodnu interakciju.


I dalje se bavimo

sustavom za

praćenje studenata

i kolegija. Sljedeća

dva sequence

dijagrama

prikazuju

parametrizirane

interakcije za

pronalaženje

određenog

studenta odnosno

određenog

kolegija.


Primjer pojave interakcije s param (1)

Primjer pojave interakcije s param (2) Te dvije parametrizirane interakcije pojavljuju se na

sljedećem sequence dijagramu gdje student Jim

upisuje kolegij “UML”.


Općenito o communication dijagramu

Communication dijagram predstavlja vrlo sažeti način

prikazivanja interakcije odnosno realizacije use case-a.

Naglašava se strukturni aspekt interakcije. Opet se

pojavljuju životni tokovi i poruke.

No, životni tok je prikazan samo kao ikona, bez “repa”.

Postoje veze (spojnice) između životnih tokova koje

označavaju da ti tokovi razmjenjuju poruke.

Poruke su zapisane uz spojnice. Svaka poruka ima

redni broj koji određuje redoslijed događaja. Redni broj

može biti oblikovan hijerarhijski u skladu s

gniježđenjem aktivacije.


Primjer communication dijagrama


Opet se bavimo sustavom za praćenje studenata i kolegija.

Sljedeći dijagram prikazuje realizaciju use case-a

AddCourses, kojim akter :Registrar dodaje dva nova kolegija,

dakle dva nova objekta iz klase Course. Redoslijed poruka

vidljiv je iz rednih brojeva: 1, 1.1, 2, 2.1.

Prikaz iteracije na commun dijagr (1)


Iteracija se prikazuje tako da se ispred poruke napiše

iteracijski izraz. Iteracijski izraz se sastoji od * i

(neobavezne) iteracijske kauzule.

Sljedeća dva ekvivalentna dijagrama prikazuju ispis svih

kolegija u našem sustavu za praćenje studenata i kolegija.


UML ne propisuje nikakvu sintaksu za iteracijsku klauzulu. Na prvom dijagramu služili smo se pseudokodom koji pretpostavlja

da su objekti iz klase Course nad kojima se obavlja iteracija

spremljeni u nekoj vrsti indeksirane kolekcije.

Na drugom dijagramu služili smo se imenom uloge u vezi s

multiplicitetom većim od 1. Ta veza određuje kolekciju objekata iz

klase Course nad kojima se obavlja iteracija.

Prikaz iteracije na commun dijagr (2)

Prikaz grananja na commun dijagr (1)


Grananje se modelira tako da se ispred poruke napiše

stražar (logički uvjet) - poruka će biti poslana samo ako je

stražar istinit.

Sljedeći dijagram prikazuje realizaciju use case-a

RegisterStudentForCourse, gdje se zadanom studentu upisuje

zadani kolegij. Upis se obavlja samo pod uvjetom da i

navedeni student i navedeni kolegij zaista postoje.

Prikaz grananja na commun dijagr (2)

Dijagram koristi pomoćne logičke varijable student, course

i found. Računanje found iz student i course objašnjeno je

tekstom (scriptom) u donjem lijevom uglu.

UML opet ne propisuje nikakvu određenu sintaksu za

stražare. Služimo se pseudo-kodom u stilu programskog

jezika.

Općenito govoreći, communication dijagrami nisu baš

pogodni za prikaz grananja. Ako ima mnogo grananja,

tada se treba služiti sequence dijagramom.


Documents

SOFTVERSKO INŽENJERSTVO Vježbe 7: Realizacija use case-ovaweb.studenti.math.pmf.unizg.hr/~manger/si/SI-vjezbe-07.pdf · podataka znači da je riječ o određenom primjerku klasifikatora,