SOFTVERSKO INŽENJERSTVO Vježbe 12: Realizacija use case ...web.studenti.math.pmf.unizg.hr/~manger/si/SI-vjezbe-12.pdf · V-12 Softversko inženjerstvo 3 Općenito o use case-ovima

SOFTVERSKO INŽENJERSTVO

Vježbe 12: Realizacija use case-ovana razini oblikovanja

Robert Manger

Sveučilište u Zagrebu

PMF-Matematički odsjek

Akademska godina 2018/2019.

V-12 Softversko inženjerstvo 2

Sadržaj Vježbi 12

Općenito o use case-ovima i oblikovanju

Sequence dijagrami u oblikovanju

Modeliranje istovremenosti

Aktivni objekti i klase

Modeliranje interakcije između podsustava

Timing dijagrami


Općenito o use case-ovima i oblik (1) Tijekom analize bavili smo se realizacijom use case-

ova. Stvorili smo odgovarajuće interaction dijagrame

(obično sequence ili communication dijagrame).

Tijekom oblikovanja ponovo se vraćamo na realizaciju

use case-ova. Naime, potrebno je profiniti interaction

dijagrame iz analize ili čak dodati nove dijagrame.

Razlozi zašto je potrebno profinjavanje dijagrama su

sljedeći. Stare interaction dijagrame treba uskladiti s novim, znatno

detaljnijim, modelom klasa i njihovih operacija.

U stare interaction dijagrame treba unijeti elemente koji se tiču

implementacije: na primjer interakcija s korisničkim sučeljem,

korištenje mreže, rad s bazom podataka, istovremeni tokovi

kontrole.


Općenito o use case-ovima i oblik (2) Razlozi zašto su potrebni novi dijagrami su sljedeći.

Treba opisati interakciju između komponenti i podsustava putem

sučelja. Te elemente modela nismo još imali tijekom analize pa ih

nismo mogli stavljati na dijagrame.

Koji put treba precizno odrediti tajming pojedinih interakcija. To

nije bilo moguće učiniti s vrstama dijagrama koje se koriste u

analizi.

U oblikovanju se gotovo uvijek koriste sequence

dijagrami, dok se communication dijagrami izbjegavaju.

Osim toga, kao nova vrsta koriste se i timing dijagrami.

Razrada klasa i veza na razini oblikovanja, definiranje

sučelja, komponenti i podsustava, te realizacija use

case-ova na razini oblikovanja zapravo su iterativne

aktivnosti. Dakle svaka od tih aktivnosti ispravlja druge.


Sequence dijagrami u oblikovanju (1) Da bi vidjeli razliku

između sequence

dijagrama u

analizi odnosno

oblikovanju,

promatramo use

case AddCourse

kojim se u sustav

o studentima i

kolegijima dodaje

novi kolegij.

Specifikacija za

AddCourse izgleda

ovako.


Profinjenjem ovog

dijagrama iz analize,

u oblikovanju

dobivamo sljedeći

dijagram.

Sequence

dijagram za

use-case

AddCourse

kojeg smo

dobili u

analizi

izgleda

ovako.

Sequence dijagrami u oblikovanju (2)


Sequence dijagrami u oblikovanju (3)


Sequence dijagrami u oblikovanju (4) Glavne razlike prikazanog dijagrama na razini oblikovanja

u odnosu na odgovarajući dijagram iz analize su sljedeće. Dodan je sloj za grafičko korisničko sučelje predstavljen objektom

:RegistrationUI.

Preciznije su definirani pozivi operacija u skladu s profinjenim

modelom klasa. Na primjer, stvaranje objekta sada je ostvareno

eksplicitnim pozivom konstruktora Course().

Uveden je mehanizam kojim se postiže perzistencija objekata.

Koriste se usluge objekta :DBManager kojima se objekt iz klase

Course trajno sprema u bazu podataka.

Kad na jednom dijagramu uvedemo jedan univerzalni

mehanizam, tada taj isti mehanizam treba konzistentno

koristiti i na drugim dijagramima. Na primjer, svugdje gdje je potrebno osigurati trajno postojanje

nekog objekta morali bi koristiti istu klasu DBManager.


Modeliranje istovremenosti Tijekom analize nismo se puno opterećivali s tokovima

kontrole, no u oblikovanju se moramo s time pozabaviti.

Jedna od najvažnijih odluka koju moramo donijeti tijekom

oblikovanja je odluka da li će se pojedine interakcije

izvršavati istovremeno, ili sekvencijalno jedna iza druge.

U UML-u postoji dobra podrška za modeliranje

istovremenosti. Naime moguće je koristiti: aktivne klase,

čvorove za grananje i spajanje (fork and join) u activity dijagr,

operator par u sequence dijagramu,

prefikse uz redne brojeve poruka na communication dijagramu,

više životnih tokova na timing dijagramu,

“ortogonalna” složena stanja u state machine dijagramu.

Neke od ovih elemenata UML-a već smo upoznali, a neke

ćemo proučiti u nastavku ovih vježbi.


Aktivni objekti i klase Aktivni objekt je objekt koji u sebi enkapsulira svoj

vlastiti tok kontrole. Aktivna klasa je klasa čije instance

su aktivni objekti.

Aktivni objekti i klase crtaju se kao obični objekti i klase,

no s dvostrukim lijevim i desnim rubom pravokutnika.

Aktivni objekti i klase predstavljaju temelj za

modeliranje istovremenosti u sustavu. Naime, da bi

stvorili mogućnost za istovremenost, postupamo ovako.

U model klasa uvrstimo aktivne klase.

Svaki tok kontrole predstavimo jednim aktivnim objektom.

Ako se aktivni objekti pojavljuju na sequence ili timing

dijagramu, tada njihovi životni tokovi predstavljaju

paralelne procese.


Korištenje aktivnih klasa (1) Sustav zaštite od požara i provale nadgleda skup senzora

koji mogu otkriti požar ili provalu. Kad se senzor aktivira,

sustav uključuje zvučni alarm pomoću sirene.

Use case

dijagram za

sustav zaštite

izgleda

ovako.

Slijede

detaljne

specifikacije

za neke od

use case-ova.


Korištenje aktivnih klasa (2)


Korištenje aktivnih klasa (3) Na osnovi use case-ova dolazimo do sljedećeg class

dijagrama u kojem su neke od klasa aktivne. Nužno je

osigurati više tokova kontrole, jer sustav mora stalno i

istovremeno nadgledati više senzora.


Istovremenost na sequence dijag (1) Ponovo gledamo sustav zaštite. Na osnovi

prethodnih specifikacija use case-ova i class

dijagrama s aktivnim klasama, dolazimo do

sljedećeg sequence dijagrama na razini

oblikovanja koji odgovara use case-u ActivateAll.

Istovremenost na tom sequence dijagramu

ostvaruje se time što se pojavljuju aktivni objekti i

time što se služimo operatorom par. Taj operator

smo spomenuli još u analizi, no on se obično

koristi tek u oblikovanju.


Istovremenost na sequence dijag (2)


Istovremenost na sequence dijag (3) Interakcija na prethodnom dijagramu teče ovako.

Akter :SecurityGuard šalje poruku activate() objektu :ControlBox. :ControlBox

šalje poruku soundActivatedAlarm() prema objektu :Siren.

:ControlBox slanjem poruka monitor() objektima :FireSensorMonitor i

:SecuritySensorMonitor pokreće dva istovremena toka kontrole koji su

predočeni kao dva operanda operatora par.

U prvom toku kontrole :FireSensorMonitor ulazi u petlju i stalno ispituje

:FireSensor. Petlja u svom prvom koraku postavlja polaznu vrijednost za

varijablu fire, a zatim se ponavlja dok god je fire false.

Kad fire postane true, tada :FireSensorMonitor ulazi u kritičnu sekciju.

Unutar te sekcije :FireSensorMonitor šalje poruku fire() :ControlBox-u, a

:ControlBox šalje poruku soundFireAlarm() :Siren-u.

U drugom toku kontrole :SecuritySensorMonitor ulazi u petlju i stalno

ispituje :SecuritySensor. Petlja najprije postavlja polaznu vrijednost za

varijablu intruder, a zatim se ponavlja dok god su i intruder i fire false.

Ako intruder postane true, tada (ali samo ako je istovremeno fire false)

:SecuritySensorMonitor šalje poruku intruder() :ControlBox-u. Nakon toga

:ControlBox šalje poruku soundIntruderAlarm() :Siren-u.


Istovremenost na sequence dijag (4) Na prethodnom sequence dijagramu treba uočiti još

nekoliko zanimljivih detalja.

Zapravo postoje četiri toka kontrole, svako od njih odgovara

jednom aktivnom objektu. No dva od tih tokova su uglavnom

pasivni, a dva zaista rade istovremeno.

Kritična sekcija predstavlja atomarno ponašanje koje se ne može

prekinuti. Aktiviranje požarnog alarma je od kritične važnosti za

sigurnost i zato je ono stavljeno u kritičnu sekciju.

Požarni alarm ima prednost pred provalnim alarmom. Aktiviranje

provalnog alarma nije u kritičnoj sekciji, tako da ono može biti

prekinuto zbog aktiviranja požarnog alarma. Provalni alarm će se

čuti samo ako se već ne čuje požarni alarm.

Pretpostavljeno je da postoji samo po jedan senzor za požar

odnosno provalu. U slučaju više senzora morali bi proširiti

dijagram tako da u petlju svakog od istovremenih tokova dodamo

još po jednu ugniježđenu petlju.


Interakcije između podsustava (1) Ako smo veliki sustav podijelili u podsustave i odredili

njihova sučelja, tada je korisno modelirati interakcije

između podsustava preko tih sučelja.

Naime, takve interakcije daju sliku na višoj razini o tome kako

zamišljena arhitektura realizira zadane use case-ove.

Pritom ne ulazimo u detalje na nižoj razini o interakciji pojedinih

objekata.

Dijagram koji opisuje interakciju podsustava može

izgledati slično kao na primjer sequence dijagram, no:

umjesto životnih tokova objekata on sadrži životne tokove instanci

podsustava;

svaki podsustav promatra se kao crna kutija koja nudi i traži servise

opisane njegovim sučeljima;

ne brinemo se o unutrašnjoj interakciji objekata unutar podsustava.


Interakcije između podsustava (2) Sljedeća slika prikazuje podsustav Customer koji nudi

sučelje s imenom CustomerManager.

Daljnja slika predstavlja dio sequence dijagrama gdje

akter :SalesAgent stupa u interakciju s instancom

podsustava Customer.


Interakcije između podsustava (3) Sučelje CustomerManager sad je prikazano kao kućica koja visi ispod

ikone podsustava i iz koje izlazi životni tok.

Poruke su prikazane kao strelice koje se spajaju na životni tok iz

sučelja – time se simbolički označava da poruke poštuju protokol

određen sučeljem.


Timing dijagrami (1) Timing dijagrami su još jedna (četvrta) vrsta interaction

dijagrama.

Nikad se ne koriste u analizi, a samo koji put se koriste u

oblikovanju, i to za modeliranje real-time ili embedded sustava.

Omogućuju da se opišu i kvantificiraju precizna vremenska

ograničenja.

Pojavili su se tek u verziju UML 2, po ugledu na dijagrame koji

se u elektrotehnici koriste za modeliranje elektroničkih

sklopova.

Timing dijagram je organiziran na sljedeći način.

Horizontalna os predstavlja vrijeme.

Na vertikalnoj osi prikazani su životni tokovi i njihova stanja.

Promjene stanja životnih tokova prikazane su izlomljenom

crtom.


Timing dijagrami (2)

Sljedeći timing dijagram vezan je uz sustav zaštite od

požara i provale. Prikazane su promjene stanja sirene

:Siren, u vremenu t mjerenom u minutama, ovisno o

događajima.

Moguća stanja za sirenu su:

Resting (odmara se),

Off (isključena),

SoundingFireAlarm (svira alarm za požar),

SoundingIntruderAlarm (svira alarm za provalu).

Mogući događaji su:

intruder (otkriven je provalnik),

fire (otkriven je požar).


Timing dijagrami (3)


Timing dijagrami (4) Iz prethodnog timing dijagrama možemo pročitati sljedeće.

t=0: objekt :Siren je u stanju Off.

t=10: desio se događaj intruder, :Siren prelazi u stanje

SoundingIntruderAlarm.

t=25: alarm za provalu ne smije raditi dulje od 15 minuta zbog

lokalnih propisa. Zato :Siren prelazi u stanje Resting i mora ostati u

tom stanju barem 30 minuta.

t=35: opet se desio događaj intruder. No :Siren mora i dalje biti u

stanju Resting tako da nema zvučnog signala.

t=55: nakon 30 minuta odmaranja :Siren se prebacuje u stanje Off.

t=65: još jednom se desio događaj intruder, pa :Siren iz stanja Off

prelazi u stanje SoundingIntruderAlarm.

t=75: desio se događaj fire, pa :Siren odmah prelazi iz stanja

SoundingIntruderAlarm u stanje SoundingFireAlarm.

t=100: interakcija završava, :Siren je u stanju SoundingFireAlarm.


Kompaktni oblik timing dijagrama Postoji i oblik timing dijagrama gdje su stanja nacrtana

horizontalno. Sljedeća slika prikazuje istu interakciju kao

prethodna, no sada na kompaktniji način. Naglasak je na

stanjima i na relativnim vremenima.


Istovremenost na timing dijagramu (1) Timing dijagrami mogu se koristiti za prikazivanje

vremenskih ograničenja u interakciji između nekoliko

životnih tokova.

Ako ti životni tokovi pripadaju aktivnim objektima, tada

takav dijagram predstavlja još jedan način prikazivanja

istovremenosti.

Dijagram s više životnih tokova podijeljen je u više

vodoravnih odjeljaka, svaki za pojedini životni tok.

Istovremeni događaji u različitim životnim tokovima

nalaze se okomito jedan iznad drugog ili ispod drugog.

Sljedeći primjer opet se odnosi na sustav zaštite od

požara i provale te prikazuje interakciju između aktivnih

objekata :FireSensorMonitor, :IntruderSensorMonitor i :Siren.


Istov-reme-nost na ti-mingdija-gramu (2)


Istovremenost na timing dijagramu (3)

Na prethodnom dijagramu treba uočiti sljedeće.

Nakon što su pobuđen, :FireSensorMonitor odnosno

:IntruderSensorMonitor prelazi u stanje Triggered, šalje poruku, te

se zatim u roku od 1 sekunde (0.016 minuta) vraća u stanje

NotTriggered.

:Siren odgovara na dojavu provale samo ako je u stanju Off.

U stanju Resting ona ignorira provalu. To je opet zbog

lokalnih propisa koji kažu da protuprovalni alarmi smiju

trajati najviše 15 minuta, te da nakon toga moraju mirovati

barem 30 minuta.

:Siren uvijek odgovara na dojavu požara, čak i ako je u stanju

Resting. To je zato jer se na požar mora hitno reagirati bez

obzira na propise.

Documents

SOFTVERSKO INŽENJERSTVO Vježbe 12: Realizacija use case ...web.studenti.math.pmf.unizg.hr/~manger/si/SI-vjezbe-12.pdf · V-12 Softversko inženjerstvo 3 Općenito o use case-ovima