ANALIZA I MODELIRANJE PROMETNIH SUSTAVA · • Informacije o predmetu se nalaze na web stranicama e‐student.fpz.hr Analiza i modeliranje prometnih sustava ‐HG ‐FPZ 2009‐2010

ANALIZA I MODELIRANJE PROMETNIH SUSTAVA

HG/FPZ – 2009/2010

Sveučilište u ZagrebuFakultet prometnih znanosti

1Analiza i modeliranje prometnih sustava ‐ HG ‐ FPZ 2009‐2010

Informacije o predmetu ...

• Nastavnici– prof. dr. sc. Hrvoje Gold, [email protected], 2380‐225

– doc. dr. sc. Štefica Mrvelj, [email protected]

– Marko Matulin, dipl.ing., [email protected]

• Raspred predavanja:

• Raspored vježbi:


Informacije o predmetu

• Bodovna vrijednost

• Za dobivanje potpisa treba prisustvovati na najmanje 70% predavanja i 70% vježbi, te izraditi dvije domaće zadaće

• Pismena provjera znanja provodi se u dva dijela preko kolokvija i u jednom dijelu preko pismenog ispita• Oslobađanje pismenog ispita preko kolokvija• Informacije o predmetu se nalaze na web stranicama e‐student.fpz.hr


Literatura

• Prezentacije s predavanja “Analiza i modeliranje prometnih sustava”, pdf, FPZ, 2009/2010– Simon Bennet, John Skelton, Ken Lunn, UML, Schaum’s Outline, McGraw Hill, 2001.

– Object‐Oriented Design with Applications ‐ GradyBooch (1993)

– Object‐Modeling Technique (OMT) (1990) i Object‐Oriented Modeling and Design ‐ Jim Rumbaugh(1991)

– Object‐Oriented Software Engineering (OOSE) ‐ IvarJacobson (1992)


Sadržaj predmeta ...

• Sustav i model sustava• Modeliranje i UML• UML i proces razvoja sustava

– Objektu usmjereni jezik za ujedinjeno modeliranje– Ujedinjeni proces razvoja programskog sustava

• Prepoznavanje elemenata područja problema– Statički opis sustava, objekti, klase, dijagram klasa, dijagram

objekata• Prikupljanje zahtjeva na sustav

– Slučajevi uporabe, dijagram slučaja uporabe• Opis zajedničkog rada elemenata

– Dinamički opis sustava, dijagram međudjelovanja, dijagram suradnje


Sadržaj predmeta

• Detaljan opis strukture elemenata– Apstraktne klase, stereotipi, sučelja

• Opis tijekova podataka– Dijagram aktivnosti

• Praćenje života elemenata – Dijagram stanja

• Prikaz zajedničkog rada skupine elemenata– Predlošci, mehanizmi, okviri

• Opis izgradnje elemenata– Dijagram komponenata, dijagram rasporeda

• Primjeri modeliranja sustava


SUSTAV I MODEL SUSTAVA


Sustav i model sustava

• Sustav je zbir elemenata složenih na određeni način i usmjerenih nekom cilju ili svrsi

• Model je prikaz bitnih značajki nekog stvarnog (ili zamišljenog) sustava koji predstavlja obilježja sustava u upotrebljivom obliku

SUSTAV MODEL SUSTAVA


Razlozi modeliranja

• Modeli se izgrađuju radi boljeg razumijevanje sustava:– pomažu kod vizualizacije stvarnog ili zamišljenog sustava

– opisuju strukturu i ponašanje sustava

– predstavljaju predložak za izgradnju sustava

– dokumentiraju postupke izgradnje sustava


Osnovna načela modeliranja

• Izbor vrste modela utječe na pristup problemu i način oblikovanja rješenja

• Svaki model je moguće izraziti na različitim razinama apstrakcije

• Najbolji modeli su povezani sa stvarnošću

• Ne postoji jedan zadovoljavajući model– Strukturu i ponašanje sustava treba promatrati i modelirati sa više raznih gledišta


MODELIRANJE I UML


Zašto modelirati programe?

• Razvoj programske podrške– zahtjevan i složen postupak– pojednostavljivanjem stvarnosti ‐modeliranjem

• Raznovrsnost modela u inženjerstvu– zrakoplovstvo

• modeli koji opisuju djelovanje sila na zrakoplov

– građevinarstvo• modeliranje statike građevinskog objekta

– telekomunikacije• modeli rada komutacijskog sustava


Jezik za modeliranje sustava

• Jezik za ujedinjeno modeliranje ‐ Unified Modeling Language (UML)

• Pomagalo, alat za vizualizaciju, opis, izgradnju i dokumentiranje programske podrške kod analize i izrade prvenstveno programskog sustava


Modeliranje ...

• Koristi se za vizualno modeliranje sustava

• Raznovrsni pogledi na strukturu i ponašanje sustava

• Rječnik i pravila za izražavanje znanja o modeliranom sustavu

Jezik ...


Ujedinjeno...

• Obuhvaća prethodno razvijene opise i tehnike analize i konstrukcije, u prvom redu programskih sustava, zasnovane na objektu usmjerenoj metodologiji– Object‐Oriented Design with Applications ‐ GradyBooch (1993)

– Object‐Modeling Technique (OMT) (1990) i Object‐Oriented Modeling and Design ‐ Jim Rumbaugh(1991)

– Object‐Oriented Software Engineering (OOSE) ‐ IvarJacobson (1992)


Gledište razvoja sustava

• Objektu usmjereno programsko inženjerstvo (OOSE)– proces razvoja sustava– sustav promatran sa gledišta korisnika i zahtjeva na sustav– proces primijenjen na razvoj programske podrške telekomunikacijskog sustava – Ericsson/Objectory proces

– uvode se slučajevi uporabe i podloga za ujedinjeni proces razvoja programskog sustava (Unified Software Development Process)

Razvoj sustava

Novi i izmjenjeni zahtjevi Izmjenjeni sustav


Gledište analize sustava

• Tehnike modeliranja objekata (OMT) za bolje razumijevanje problemskog područja – modeliranje sustava prije njegovog ostvarenja

• model statičke strukture sustava – preslikavanje objekata u relacijsku bazu podataka• model upravljačke strukture sustava• model računske strukture sustava

KorisniciRazvoj

Upravljanje projektom

Postavljanje zahtjevaPostavljanje problema

Razvoj sustava

Izgradnja modela

Intervjuiranje korisnikaPodručno znanjeStvarno iskustvo

Model objektaDinamički model

Funkcionalni model


Gledište detaljno plana izvedbe

• Booch‐ova metoda– detaljni plan izvedbe i kodiranje– npr. SQL transakcija


Porijeklo UML‐a

Odziv stručnjakalipanj –listopad 1996

Ostali

Dijelovi

Ujedinjenje

Standardizacija

Industralizacija

lip. – list. 1996

Odziv partnera

sij. 1997

lis. 1997

Partneri: Hewlett‐Packard, IBM, Microsoft, Oracle, ...OMT: Object Modeling Technique ‐ James RumbaughBooch: Grady BoochOOSE: Object‐Oriented Software Engineering ‐ Ivar Jacobson

UML 0.8


2002

4K 2001

1K 2001

1999

1998

1997*

* prihvaćeno od tijela za standardizaciju ‐ Object Management Group (OMG)

Preradba bez značajnijih tehničkih izmjena

Relacija zavisnosti

UML 2.0 infrastruktura

UML 2.0 OCL

UML 2.0 nadstruktura

Relacija slaganja(cijelina – dio)

Daljnja evolucija UML‐a

OCL: Object Constraint Language


Pojava jezika za modeliranje

• Iz potrebe za potporom projektnom timu pri razvoju programske podrške s ciljem– vizualizacije modeliranog sustava,

– tehničkog opisa strukture i ponašanja sustava,

– izgradnje sustava i

– dokumentiranja odluka u tijeku razvoja sustava


Vizualizacija sustava

• Pomoć projektnom timu u prikazu sustava koji se izgrađuje, a treba zadovoljiti raznovrsna ograničenja na sustav

• UML – olakšava razmjenu informacija među sudionicima projekta

budući je usmjeren na višestruke komunikacije, npr. između• korisnika i razvojnog tima• konstruktora sustava i projektanata baze podataka• članova razvojnog tima koji rade na različitim dijelovima sustava

– nudi skup • dobro određenih grafičkih prikaza, dijagrama• precizno označenih načina korištenja dijagrama

– omogućava razumijevanje strukture i ponašanja sustava uz smanjeni rizik krivog tumačenja


Tehnički opis sustava

• Tehnički opis UML‐om– precizan

– nedvosmislen

– potpun

• Različita gledišta UML‐a odnose se na opise odluka koje se donose pri razvoju sustava


Tehnički opis u razvoju sustava ...

• Modeli u ranim fazama izgradnje sustava– projektantima olakšavaju opisivanje strukture i ponašanja sustava

• izražavanjem osnovnih mogućnosti sustava uz niske rizike i cijene

• Nastavkom izgradnje– početni modeli se upotpunjavaju

• povećanjem znanja• zahtjevima za detaljnijim opisima

– modeli su usmjereni na • ključne elemente sustava i• postupke kojima će se oni ostvariti


Tehnički opis u razvoju sustava

• Modeli detaljno opisani UML‐om– obuhvaćaju najznačajnije značajke konačnog sustava

– uz pažljivo modeliranja• moguće je pratiti elemente, koji se javljaju u modelima kasnijeg stupnja modeliranja, do njihovih početnih grubih skica

• Modele je moguće – izgraditi iz postojećih sustava čime se

• održava i proširuje funkcionalnost sustava


Izrada sustava ...

• Cilj modeliranja je izrada– programskog kôda

• Mnogobrojne konstrukcije UML‐a odgovaraju– izravno i neizravno konstrukcijama programskih jezika (C#, Java, C++)

– modeliranju baza podataka

– predlošcima za umrežavanje


Izrada sustava

• Izrada sustava– unaprijed (forward engineering)

• iz modela se generira programski kôd– alati za vizualno modeliranje

» MS Visio – UML Model Diagram– i generiranje kôda iz modela

» IBM Rational Rose

– unazad (reverse engineering)• izrada (ili obnova) modela iz programskog kôda

– primjena postupka unaprijed i unazad (round‐trip engineering)


Dokumentiranje

• Projektna dokumentacija slijedi iz UML modela– npr. skup svih opisa slučajeva uporabe sustava služi za izradu priručnika za korisnike i učenje

– npr. plan izvedbe sustava iz opisa slučajeva uporabe sustava omogućava provjeru kakvoće i izradu testova na osnovi unutarnje strukture sustava

• Pravilno izvedeni modeli i odgovarajući dokumenti– često su puta ponovno upotrebljivi u području drugih projekata


Kakvoća modela

• Dobar model – se prilagođava pristupu koji projektni tim slijedi kod rješavanje dijela ili cjelokupnog problema

• model koji obuhvaća bitne apstrakcije i zanemaruje nebitne– omogućava različite poglede na različitim razinama detaljnosti u različitim trenucima

• projektanti promatraju sustav s različitih gledišta– povezan je sa stvarnošću

• strog razvoj i stalno poboljšanje modela doprinosi ostvarenju ponašanja sustava kakvo je bilo zamišljeno na početku razvoja

– dobro surađuje s ostalim modelima u prikupljanju ključnih elemenata sustava

• omogućuje tvorbu različitih vrsta, većinom nezavisnih, modela koji pružaju dovoljno prilika opisa tijeka podataka i tijeka nadzora


Arhitektura sustava

• Arhitektura sustava– osnovni ustroj sustava kao cjeline

• statički elementi

• dinamički elementi

• povezanost navedenih elemenata i njihov zajednički rad

• način pristupa ustroju

– uključuje načine• izvedbe, rasta, ponovne uporabe, ekonomska i tehnološka ograničenja


Pogledi na sustav

• Korisnici i projektanti projekta razvoja programa– postavljaju različite zahtjeve– gledaju na sustav sa raznih gledišta– gledišta se mijenjaju razvojem sustava

• UML obuhvaća gledišta preko pet povezanih pogleda (view)– svaki pogled

• naglašava određeni skup značajki sustava• prikriva značajke koje se ne odnose na promatrača


Pogled na sustav sa gledišta ...

• Pogled na sustav sa gledišta – slučaja uporabe (use case view)

• usmjeren je na situacije u kojima sudjeluju korisnici i sustavi izvan promatranog sustava

– sadržaj pogleda izražava što novi sustav treba raditi, ali ne opisuje kako to treba izvesti

– plana izvedbe (design view)• usmjeren je na predmete koji čine rječnik problema koje sustav treba riješiti i elemente rješenja problema

• obuhvaća statičke, strukturalne i dinamičke, funkcionalne (ponašanje) izglede sustava


Pogled na sustav sa gledišta

• Pogled na sustav sa gledišta – procesa (process view)

• usmjeren je na izgled sustava koji uključuje vrijeme i upravljanje tijekom rada i značajke izvođenja, rasta i propusnosti

– ostvarenja (implementation view)• usmjeren je na elemente kojima se sustav fizički ostvaruje• izvorni kôd, izvršni kôd, fizičke baze podataka, pridružena dokumentacija

– rasporeda (deployment view)• usmjeren je na prostornu raspodjelu razvijene programske i sklopovske opreme koja čini sustav


Pet pogleda na sustav

Plana izvedbe

Procesa

Ostvarenja

Rasporeda

Slučaj uporabe


UML dijagrami

Elementi modelaStanja

Slučaj uporabe

Slijeda poruka

Komponente

Ostvarenja

Rasporeda

Klase

Statičke strukture

Objekta

Aktivnosti

UML dijagrami

Međudjelovanja Suradnje


UML I PROCES RAZVOJA SUSTAVA


UML i proces razvoja sustava

• UML je nezavisan o procesu koji se koristi u razvoju programskog sustava, aplikacije

• Ipak promatrajući životni ciklus aplikacije korištenje UML‐a je najprikladnije u procesima koji su– pokretani slučajevima uporabe

– usmjereni arhitekturi sustava

– ponovljivi (iterativni) i dodavajući (inkrementalni)

• Proces koji obuhvaća navedene elemente je– Ujedinjeni proces razvoja programske podrške


Ujedinjeni proces

• Ujedinjeni proces razvoja programskog sustava (Unified Software Development Process, Rational Unified Process, Unified Process)– zasnovan na ujedinjenoj metodi razvoja programske podrške

• 1994. ‐ Rumbaugh, Booch, Jacobson – tvrtka Rational– dokumentacija ujedinjene metode

• 1997. – UML 1.1 – jezik za objektu usmjereno modeliranje

– prihvaćen od tijela za standardizaciju


Životni ciklus sustava

• Uloga UML‐a u životnom vijeku razvoja aplikacije• Životni vijek programskog sustava se može prikazati nizom ciklusa– ciklus završava predajom nove verzije sustava korisniku

• Ujedinjeni proces razvoja– svaki ciklus ima četiri faze– faza je vremensko razdoblje između prekretnica

– prekretnica (milestone) je trenutak projektnog vremena u kojem voditelj porjekta donosi odluke o nastavku ili prekidu rada na projektu na temelju izvedenog i preostalog opsega posla, raspoloživih financijskih sredstava i predviđenog plana rada


X+1. iteracija

. . .

y. iteracija

Početne operativne sposobnosti

Faze i prekretnice razvoja

Svaka faza ima jednu ili više iteracija

1. iteracija

Ciljevi životnog ciklusa

Početna faza Faza razrade Faza izrade Faza prijelaza

2. iteracija

. . .

x. iteracija

Arhitektura životnog ciklusa

y+1. iteracija

. . .

z. iteracija

Predaja aplikacije


Početna faza ...

• Glavni cilj početne faze (inception)– uspostava slučajeva održivosti predloženog sustava

• Poslovi projektnog tima u početnoj fazi– odrediti doseg sustava

• što je u sustavu, a što nije– skicirati prijedlog početne arhitekture prema pogledima

• početna arhitektura (candidate architecture) je sastavljena od početnih inačica šest različitih modela

– prepoznati elemente rizika (risk) projekta i utvrditi načine izbjegavanja rizika

– na osnovi početne procjene troškova, opsega posla, plana rada i kakvoće proizvoda započeti planirati poslovanje


Početna faza

• Glavna prekretnica pridružena početnoj fazi– dosegnuti ciljevi životnog ciklusa

• Pokazatelji postignuća prekretnice– sudionici su suglasni sa dosegom predloženog sustava

– početna arhitektura jasno ukazuje na skup kritičnih zahtjeva visoke razine

– razvoj slijedi poslovni plan projekta koji dozvoljava nastavak projekta


Faza razrade ...

• Glavni cilj faze razrade (elaboration)– uspostava mogućnosti izgradnje novog sustava uz ograničenja zadana

financijskim planom, plana rada i ostalim• Poslovi projektnog tima u fazi razrade

– prikupiti većinu preostalih funkcionalnih zahtjeva– proširiti početnu arhitekturu u osnovnu punu arhitekturu

(architectural baseline)– uočiti mogućnosti pojave rizika tijekom rada– završiti poslovni plan projekta i pripremiti plan nastavka rada na

projektu• Osnovna puna arhitektura

– sadrži proširenu inačicu šest modela izrađenu u početnoj fazi– UML usmjeren arhitekturi sustava radi naglašenog mjesta arhitekture

u razvoju sustava


Faza razrade

• Glavna prekretnica pridružena fazi razrade– dosegnuta arhitektura životnog ciklusa

• Pokazatelji postignuća prekretnice– većina funkcionalnih zahtjeva na novi sustav je obuhvaćena modelima slučaja uporabe

– osnovna arhitektura predstavlja mali puni sustav koji će biti dobar temelj daljnjeg razvoja sustava

– poslovni plan je opravdan i projektni tim ima početni projektni plan koji opisuje kako nastaviti fazu izrade


Faza izrade

• Glavni cilj faze razrade (construction)– izgradnja sustava koji je sposoban uspješno raditi u testnoj okolini korisnika

• Poslovi projektnog tima u fazi izrade– iterativna i inkrementalna izgradnja sustava uz očiglednu održivost sustava u izvedbenom obliku

• Glavna prekretnica pridružena fazi izrade– uspostava početne operativne sposobnosti

• Pokazatelji postignuća prekretnice– rad korisnika s manje ili više potpuno operativnom inačicom sustava


Faza prijelaza

• Glavni cilj faze prijelaza (transition)– predaja potpuno funkcionalnog sustava korisniku

• Poslovi projektnog tima u fazi prijelaza– ispravci pogrešaka i promjene u sustavu da bi se ispravili prethodno ne primjećeni problemi

• Glavna prekretnica pridružena fazi prijelaza– predaja novog izdanja sustava korisniku


Radni tijekovi

• Ujedinjeni proces razvoja aplikacija se sastoji od– četiri faze razvoja koje prolaze kroz pet radnih tijekova

• Radni tijek (workflow)– predstavlja skupinu aktivnosti koje izvode suradnici rada na projektu

• Opisuju se – značajke radnih tijekova preko vrsta UML modela pridruženih pojedinom tijeku

– odnosi radnih tijekova prema fazama razvoja


Osnovni modeli ujedinjenog procesa

Model slučaja uporabe

Model plana izvedbe

Model ostvarenja

Model analize

Model rasporeda

Model provjere

raščlanjen

raspodijeljen opisan

ostvaren provjeren


Radni tijek prikupljanja zahtjeva ...

• Osnovna aktivnost radnog tijeka prikupljanja zahtjeva (requirements workflow)– izrada modela slučajeva uporabe

• obuhvaća funkcionalne zahtjeve modeliranog sustava• omogućava sudionicima projekta usaglašavanje o sposobnostima sustava i uvjetima koje mora poštivati

• Model slučajeva uporabe – služi kao osnova cjelokupnog razvoja– u arhitekturi sustava smješten je u središte pogleda slučaja uporabe


Radni tijek prikupljanja zahtjeva

• Dijelovi jesu – aktivnosti izrade prototipa

• od skiciranja do radnog prototipa

• Radni tijek prikupljanja zahtjeva uključen je u faze ujedinjenog procesa razvoja na sljedeći način– model slučaja uporabe se razvija u početnoj fazi s ciljem prikupljanja ključnih zahtjeva visoke razine

– većina (približno 80%) modela slučaja uporabe se izgrađuje u fazi razrade kada se funkcionalni zahtjevi razmatraju na širokoj osnovi

– faza izrade povlači izradu ostatka modela slučaja uporabe budući se svi zahtjevi ne prikupe u početnoj fazi i fazi razrade

– model se fino ugađa u fazi prijelaza


Radni tijek analize sustava ...

• Osnovna aktivnost radnog tijeka analize sustava (analysis workflow)– usmjerena je na izradu modela analize koji

• pomaže u usavršavanju i strukturiranju funkcionalnih zahtjeva obuhvaćenih modelom slučaja uporabe

• ostvaruje slučajeve uporabe i približava ih planu izvedbe i ostvarenju

• Model analize je u arhitekturi sustava smješten – u pogled izrade i – pogled procesa


Radni tijek analize sustava

• Radni tijek analize sustava uključen je u faze ujedinjenog procesa na sljedeći način– model analize se započinje graditi u početnoj fazi kao dio napora da se prikažu zahtjevi visoke razine

– model analize se izgrađuje u fazi razrade kada se funkcionalni zahtjevi raščlanjuju, usavršavaju i strukturiraju

– u fazi izrade izgrađuje se ostatak modela analize u dijelovima koji se nisu analizirali u fazi razrade

– model se fino ugađa u fazi prijelaza


Radni tijek izrade sustava ...

• Osnovna aktivnost radnog tijeka izvedbe sustava (design workflow)– usmjerena je na izgradnju modela plana izvedbe koji opisuje način fizičke izvedbe

• slučajeva uporabe iz modela slučaja uporabe• sadržaja modela analize

• Radni tijek izrade sustava– služi kao apstrakcija modela ostvarenja– usmjeren je na model rasporeda koji utvrđuje fizički ustroj sustava putem računalnih čvorova


Radni tijek izrade sustava ...

• U arhitekturi sustava model plana izvedbe je smješten u središte pogleda izvedbe, značajan je i za pogled procesa

• Model rasporeda se smješta u pogled rasporeda


Radni tijek izrade sustava

• Radni tijek izrade sustava uključen je u faze ujedinjenog procesa razvoja na sljedeći način– model plana izvedbe se započinje razvijati u početnoj fazi kao dio

napora u ostvarenju zahtjeva visoke razine• model rasporeda sastoji se od nekoliko skica

– slučajevi uporabe koji utječu na arhitekturu sustava se uvode u model plana izvedbe u fazi razrade

• ako će se sustav značajno rasporediti, izrada modela rasporeda započinje ovdje

– faza izrade uključuje glavninu izrade modela plana izvedbe i modela rasporeda, kada se određuje koji programi će biti smješteni na koju sklopovsku opremu

– modeli plana izvedbe i rasporeda se dodatno usklađuju u fazi prijelaza


Radni tijek ostvarenja sustava ...

• Osnovna aktivnost radnog tijeka ostvarenja sustava (implementation workflow)– usmjerena je na izgradnju modela ostvarenja

• koji opisuje na koji način se elementi modela plan aizvedbe pakiraju u programske komponente kao što su

– datoteke izvornih kôdova, biblioteke dinamičkih veza (DLL) i sl.

• U arhitekturi sustava model ostvarenja je osnovni element pogleda ostvarenja


Radni tijek ostvarenja sustava

• Radni tijek ostvarenja sustava uključen je u faze ujedinjenog procesa razvoja na sljedeći način– u početnoj fazi ako postoji model ostvarenja sustava ima oblik izvedbenog prototipa

– u fazi razrade model ostvarenja se odnosi na za arhitekturu sustava značajne slučajeve uporabe

– faza izrade je usmjerena na izradu brojnih modela ostvarenja

– model ostvarenja se fino ugađa u fazi prijelaza


Radni tijek provjere sustava ...

• Osnovna aktivnost radnog tijeka provjere sustava (test workflow)– usmjerena je na izgradnju modela provjere

• opisuje način integracije i provjere sustava izvršnim komponentama modela ostvarenja

• Model provjere opisuje kako će se i na koji način izvesti provjera proizvedenog sustava– model provjere sadrži primjere za provjeru često puta izravno

izvedene iz slučajeva uporabe – izvodi se provjera

• ulazno‐izlaznih odnosa, metoda crne kutije (black‐box), korištenjem izvornih tekstova opisa slučajeva uporabe

• strukture, metodom bijele kutije (white‐box), uspješnošću ostvarenja slučajeva uporabe opisanih modelom analize


Radni tijek provjere sustava

• Radni tijek izrade sustava uključen je faze ujedinjenog procesa razvoja na sljedeći način– u početnoj fazi model provjere je usmjeren na provjeru rada prototipa ako on postoji

– u fazi razrade model ostvarenja se odnosi na provjeru za arhitekturu sustava značajnih slučajeve uporabe

– faza izrade je usmjerena na izradu brojnih modela provjere i provjeru komponenata, integracije i sustava

– model provjere se fino ugađa u fazi prijelaza, budući stalna provjera pomaže u otklanjanju pogrešaka


Razvoj ponavljanjem i dodavanjem ...

• Faze ujedinjenog procesa razvoja podijeljene su u iteracije– iteracija predstavlja dio radnog tijeka

• Iteracija presijeca svih pet radnih tijekova– u fazi razrade iteracija može biti usmjerena na aktivnosti radnih tijekova prikupljanja zahtjeva i analize sustava

– u fazi izrade iteracija je vezana uz aktivnosti izrade, ostvarenja i provjere



• Iteracija ima za posljedicu dodavanje– to je inačica sustava koje u odnosu na prethodnu inačicu sadrži dodane i/ili poboljšane funkcionalnosti

• Iterativnim i inkrementalnim pristupom proces razvoj sustava započinje– procjenom rizika pridruženih zahtjevima, vještinama, tehnologiji

– određivanjem prihvatljivog dosega projekta



• Nastavak razvoja– prvu iteraciju usmjeriti na rješavanje najkritičnijih rizika– razraditi plan ponavljanja dovoljne razine detaljnosti– izvesti potrebne aktivnosti

• u ujedinjenom procesu razvoja aktivnosti su pridružene radnim tijekovima– prikupljanja zahtjeva, analiza, planiranje izvedbe, ostvarenja i provjere

– isključiti rizik koji je dovoljno obuhvaćen inkrementom i obnoviti tekući popis rizika

– preispitati cjelokupni plan projekta u odnosu na uspjeh ili neuspjeh iteracije

– nastaviti sa sljedećom iteracijom• Iteracije izgrađuju šest navedenih modela korak po korak

– na kraju svake iteracije potpuni skup modela, koji predstavlja sustav, se nalazi u odgovarajućem stanju ‐ stanje osnovne arhitekture za iteraciju


Razvoj ponavljanjem i dodavanjem

N‐ta iteracija

Početni rizikPočetni doseg projekta

Odrediti iteraciju za rizik najviše razine

Planiranje i razvoj iteracije

Ocjena iteracije

Uklanjanje rizika

Preispitivanje plana projekta

Preispitivanjeocjene rizika


PREPOZNAVANJE ELEMENATA PODRUČJA PROBLEMA


Modeliranje predmeta, osoba i događaja

• Objekt je predmet, osoba ili događaj iz problemskog područja

• Primjer: Bankomat– mjerodavni objekti

• kartica• račun sa kojega se uzima novac• isplata novca koji se uzima iz bankomata

– i bankomat se može promatrati kao složeni objekt


http://images.google.hr/imgres?imgurl=http://www.freewebs.com/ballbustersrus/atm.jpg&imgrefurl=http://www.freewebs.com/ballbustersrus/&usg=__aahO57H3eq9GkhODH4k6S2yrC4o=&h=480&w=392&sz=49&hl=hr&start=3&tbnid=RxJLT6tOT3XpZM:&tbnh=129&tbnw=105&prev=/images?q=atm&gbv=2&hl=hr&sa=G

Osnovne značajke objekta

• Oznaka/Identitet objekta– naziv, ime objekta– ili neimenovani objekt

• Stanje objekta– nazivi obilježja (atributa) koja opisuju objekt– vrijednosti obilježja u promatranom trenutku

• Ponašanje objekta– metode (funkcije i procedure) koje koriste ili mijenjaju vrijednosti atributa objekta


Prikrivanje podataka

• Temeljno načelo objektu usmjerenog pristupa– omatanjem (enkapsulira) objekt prikriva svoje podatke od ostalog dijela sustava

– ostali dijelovi sustava mogu pristupiti i koristiti podatke samo putem poziva metoda


Objekti, atributi i vrijednosti

• Bankomatu pridruženi atributi i njihove vrijednosti

• Dogovor pisanja naziva atributa i metoda: mala slova, ako je više riječi prvo slovo druge riječi je veliko– kratica se označava velikim slovima, npr. osobni identifikacijski broj

PIN (personal identification number)• Uz objekte važan element kod objektu usmjerenog opisa

sustava je pojam klase

Objekt Atribut Vrijednost

Kartica PIN 4321

RačunID

granicaPrekoračenja230‐212‐3218

1000

Isplata serijskiBroj 34521345


Klase ...

• Klasa je skup objekata istih značajki– obuhvaća statičko ponašanje objekta

• Usporedba klase i objekta:– Klasa ima jedinstveni naziv

• eKartica ‐ elektronička kartica

– Naziv objekta može sadržavati naziv klase kojoj pripada

– Klasa nema stanja kao objekt, ali definira atribute koji pripadaju svakom objektu klase


Klase ...

• Klasa definira svoje ponašanje korištenjem operacija– operacija predstavlja uslugu koju s ciljem promjene ponašanja može zatražiti objekt

– metoda predstavlja ostvarenje usluge– operacija unutar klase je predstavljena najmanje jednom metodom unutar svakog objekta koji pripada dotičnoj klasi

• Objekt koji pripada klasi je primjer (instanca) klase– objekt je dinamična zasebna jedinka, entitet koji nastaje i postoji za vrijeme izvođenja

• Klasa je apstraktni prikaz (predmeta, osobe, događaja), dok je objekt stvarni prikaz apstrakcije


Grafički prikaz klaseKlasa

atributi

operacije

Klasa

operacije

Klasa

Klasa

atributi

Korisnički račun

emailAdresaIDlozinka

provjeraLozinke()

Knjiga

naslov: string

Korisnik

Recenzija

dodijelitiOcjenu(ocjena: int)izračunatiSredOcjenu(): double

Prikaz primjera klasa


Obveze klase

• Izričita obveza jedne klase prema drugoj klasi

• Razvojem modela sustava obveze prelaze u operacije klase

• Dozvoljeno dodavanje redaka i sadržaja po potrebi

Recenzent

ime

Obveza‐napisati recenziju‐ocijeniti postojeću recenziju


Relacije među klasama

• Klase same za sebe nisu posebno upotrebljive

• Relacije (odnosi, veze) između klasa čine osnovu strukture modela– relacija udruživanja (asocijacije, association)

– relacija sastavljanja (agregacije, aggregation)

– relacija poopćavanja (generalizacije, generalization)


• Udruživanje (asocijacija) predstavlja strukturalnu povezanost između klasa

• Udruživanje između dvije klase se označava crtom

• Slijede primjeri udruživanja klasa modela Internet knjižare

Relacija udruživanja

Klasa Klasa

Klasa

operacije

Klasa

atributi


Primjer relacija udruživanjaKnjiga

naslov: string

Izdavač

Recenzija

dodijelaOcjene(ocjena: int)izračunSredOcjene(): double

Otpremnik

naziv

Info_o_otpremi


Usmjerenost odnosa

• Relacija udruživanja pretpostavlja dvosmjernost odnosa– klase znaju jedna o drugoj

• Usmjerenost odnosa se označava strelicom

Kupac Lozinka


• Udruživanje tri ili više klase– koristi se kod modeliranja podataka

N‐arno udruživanje


Proširenje opisa odnosa ‐ nazivom

• Naziv relacije, najčešće glagol, označava prirodu odnosa– trokut označava smjer čitanja relacije

Knjiga

naslov: string

Autorje_napisao


Proširenje opisa odnosa ‐ ulogom

• Relacija se predstavlja drugoj klasi ulogom– uloge se pojavljuju u parovima

– klasa između različitih udruživanja može imati istu ili različite uloge

Recenzent Recenzijapiše

ocjenjuje


Proširenje opisa odnosa ‐ višestrukost

• Višestrukost udruživanja označava– koliko objekata jedne klase se može udružiti

• Najčešći oblici višestrukosti:– stalna vrijednost (npr. 1 ili 3)

– zvjezdica (*) označava mnogo

– područje vrijednosti (npr. 0..1, 3..*)

– skup vrijednosti (npr. 1, 3, 5, 7)


• Relaciju čitati u smjeru od vrijednosti jedne klase prema vrijednosti druge klase i obratno– objekt Korisnički računa se povezuje s mnogo objekata Stavka_računa, – objekt Stavka_računa se povezuje samo s jednim objektom Korisničkog

računa

Primjer višestrukog udruživanja

Korisniči račun


provjeraLozinke()

Korisnik

Stavka_računa

1

1

1

*


Relacija sastavljanja ...

• Relacija sastavljanja (agregacije) stavlja u odnos cjelinu i dio ili dijelove cjeline– jedna ili više klasa predstavljaju dijelove klase koja čini cjelinu

– relacija sastavljanja se označava crtom koja na svome kraju do klase cjeline ima (ispunjeni ili neispunjeni) četverokut, klasa na suprotnom kraju je klasa dijela

Klasa dijela cjeline

atributi

operacije

Klasa cjeline


Relacija sastavljanja

• Prikaz strukture klase cjeline sastavljene od više klasa dijelova– posebnim vezama

– zajedničkom vezomKlasa cjeline

Klasa dijela 1 Klasa dijela 2

Klasa cjeline

Klasa dijela 1 Klasa dijela 2


Relacija vlastitog sastavljanja

• Koristi se u situacijama kada se klasa upućuje (reflektira) na samu sebe

Klasa sastavljanja

atributi

operacije


Primjer relacije cjelina‐dijelovi

• Višestrukost je pridružena svakoj relaciji• Ako relaciji nije pridružena vrijednost višestrukosti pretpostavlja se mnogo dijelova (*) i jedna cjelina

Narudžba

Info o otpremi

Knjiga

naslov: string

Info o naplati

*

1

1

1 1

1


Relacija poopćavanja

• Relacija poopćavanja (generalizacije) stavlja u odnos opću klasu (višu klasu, superklasu ili roditelja) i prema njoj posebnu/podređenu klasu (nižu klasu, subklasu ili dijete)

• Niža klasa nasljeđuje atribute i operacije– jedne više klase (jednostruko nasljeđivanje) ili

– većeg broja viših klasa (višestruko nasljeđivanje)


Nasljeđivanje

• Nasljeđivanje je ključna značajka objektu‐usmjerenog modeliranja

• Dva najznačajnija načela poopćavanja– načelo zamjenjivosti objekta

• objekt niže klase može biti zamijenjen objektom pridružene više klase

– načelo višeobličnosti (polimorfizma) objekta• objekt niže klase može redefinirati operacije koje nasljeđuje od pridružene više klase

• Objekt koji pripada nižoj klasi može nasljeđenim atributima i operacijama dodati nove atribute i/ili operacije


Označavanje relacije poopćavanja

• Relacija poopćavanja se označuje crtom • koja na svome kraju do više klase ima (ispunjeni ili

neispunjeni) trokut, klasa na suprotnom kraju je niža klasa– ako viša klasa ima veći broj nižih klasa mogu se prikazati posebnim

ili zajedničkim vezama

Niža klasa

atributi

operacije

Viša klasa

Viša klasa

Niža klasa 1 Niža klasa 2

Viša klasa

Niža klasa 1 Niža klasa 2


Primjer primjene relacije poopćavanja

• Operacije koje su pripadale klasi Recenzija su prenesene u klasu Recenzija korisnika jer ne odgovaraju ponašanju nove klase Recenzija uredništva

• Niža klasa Recenzija korisnika je posebni slučaj opće klase Recenzija

Recenzija

Recenzija korisnikaRecenzija uredništva

dodijelaOcjene(ocjena: int)izračunSredOcjene(): double


Udružena klasa

• Modelira udruženost koja ima korisne značajke izvan korisnih značajki pojedinačnih klasa

• Koristi se kada se relacija višestrukosti mnogo‐mnogo želi rastaviti na relacije višestrukosti 1‐mnogo

• Udružena klasa se prikazuje crtanom vezom na vezu klasa koje se udružuju

Udružena klasa

Klasa 1 Klasa 2


Primjer primjene udružene klase

• Između autora i knjiga postoji relacija mnogo‐mnogo – autor može napisati više knjiga, a knjigu može napisati više autora

• Udružena klasa Knjiga_i_Autor omogućava povezivanje jednog autora s jednom knjigom

• Atribut uloga označava da li je autor– autor– koautor– urednik

Knjiga_i_Autor

uloga

Autor Knjiga

naslov: string


Dijagram klasa

• Osnovno sredstvo prikaza strukture sustava koji se modelira ili analizira

• Dijagram klasa prikazuje klase i relacije koje postoje između klasa

• Slijedi prikaz povezanosti do sada korištenih klasa modela Internet knjižare


Prikaz dijagrama klasa

• Nepotpuna povezanost klasa– Korisnik i Narudžba

– Korisnik i Recenzent

– Povezanost preko ostalih klasa


Dijagram objekata ...

• Prikaz objekta je sličan prikazu klase

• Razlike:– ispred naziva klase i znaka dvotočke se zapisuje naziv objekta – objekt može biti

• imenovan ili• neimenovan (anoniman)

– naziv objekta i klase se podvlači– kod objekta atributi klase poprimaju vrijednosti

Objekt : Klasa

atribut1 = vrijednost1atribut2 = vrijednost2

: Klasa

atribut = vrijednost


Dijagram objekata

• Dijagram objekata predstavlja trenutne vrijednosti strukture modeliranog sustava

• Sličan je dijagramu klasa, međutim:– prikazuje objekte

– stvarne vrijednosti atributa


Prikaz dijagrama objekata

• Objekti često puta nisu imenovani

: Knjiga_i_Autor

uloga = “koautor”

: Autor

ime = “Ivan Horvat”

: Knjiga

naslov = “UML priručnik”

FPZ : Izdavač

naziv = “Fakultet prometnih znanosti”


• Uz dijagrame informiraju o posebnostima klasa ili objekata, skupina klasa i objekata ili cijelim dijagramima

• Ne utječu na izradu modela

• Mogu se pojaviti u bilo kojem UML dijagramu

Napomene

Klasa


Primjeri primjene napomena

Recenzent

Korisnički račun


provjeraLozinke()

Korisnik1

1


Paketi ...

• Paket– je sastavljen od srodnih dijelova sustava– prikladan oblik za

• gospodarenje modelima• dodjelu dijelova za izradu suradnicima projekta

– može sadržavati više elemenata modela• npr. samo klase, klase i dijagrame klasa, različite konstrukcije i dijagrame

– osnovno pravilo paketiranja• pojedini element modela može pripadati samo jednom paketu

– omogućava pojmovno grupiranje, izrada sustava se ne ograničava unutar granica paketa


Paketi ...

• U terminologiji UML‐a – model je paket koji sadrži druge pakete

• npr. model analize sadrži brojne pakete klasa– mnoge klase predstavljene unutar modela klasa su povezane s klasama otkrivenim u početku razvoja projekta

• Označavanje paketa kao mape s oznakom– naziv paketa se zapisuje uz oznaku mape

• sadržaj paketa se zapisuje u tijelu mape

– naziv paketa se zapisuje u tijelu mape• sadržaj paketa se ne zapisuje


Označavanje i prikaz primjera paketa ...

Paket 2element 1element 2element 3

Paket 1

NarudžbaInfo o naplatiInfo o otpremiOtpremnik

Narudžba

Korisnički račun

Korisnik


Označavanje i prikaz primjera paketa

• Naziv putanje klase (path name)– nazivu klase prethodi naziv paketa kojem klasa pripada

– nazivu paketa u putanji mogu prethoditi nazivi paketa kojemu pripada paket klase

Paket :: Klasa

atributi

operacije

Paket :: Klasa Narudžba :: Info o otpremi

Korisnik :: Korisniči račun


provjeraLozinke()102Analiza i modeliranje prometnih sustava ‐ HG ‐ FPZ 2009‐2010

PRIKUPLJANJE ZAHTJEVA NA SUSTAV


Prikupljanje zahtjeva

• Model problemskog područja (domain modela)– opis skupa klasa u početku razvoja sustava

• Za prikupljanje potreba i zahtjeva korisnika u odnosu na sustav koji se modelira ili analizira služe opisi odnosa korisnika i sustava– slučajevi/primjeri uporabe (use‐case)

• Često puta dugotrajni i složeni postupak• UML potiče korištenje metoda zasnovanih na slučajevima uporabe

• Model slučaja uporabe je sredstvo za određenje očekivanih funkcionalnosti rada sustava


Sudionici i opisi slučajeva uporabe

• Sudionici (akteri, agenti) predstavljaju:– uloge korisnika u odnosu na modelirani sustav– zasebne jedinke (entitete) izvan modeliranog sustav, npr. druge sustave ili baze podataka

• Prikaz sudionika:– simbolom osobe– kratki naziv

• ne označava određenu osobu• označava ulogu ili skup uloga koju korisnik, vanjski sustav ili dio sustava koji se modelira, ima u odnosu na opise uporabe

• korisnik može imati više uloga, npr., korisnik može kupovati knjigu i biti recenzent


Slučaj uporabe

• Slučaj uporabe– skup scenarija koji opisuju očekivano ponašanje sustava– opisuje slijed aktivnosti sustava koji ispunjava ciljeve korisnika

• Slučaj uporabe se opisuje sa strane sudionika– opisuje mogući način uporabe sustava– izražava se

• u naredbodavnom obliku • u sadašnjem vremenu

– ne predlaže način modeliranja ili ostvarenja sustava


Prikaz slučaja uporabe

• Prikazuje se elipsom u kojoj ili uz koju je kratki opis zahtjeva na modelirani sustav

Opisuporabe

Opis uporabe Potražiti autora

Sastaviti otpremnicu

Tiskati izvješće


Prikaz funkcionalnosti sustava

• Slučaj uporabe opisuje ponašanje sustava, štosustav treba raditi, ali ne opisuje način kakopostići to ponašanje

• Unutar modela slučaja uporabe– skup sudionika mora uključivati sve sudionike koji razmjenjuju informacije sa sustavom

• Skup svih slučajeva uporabe– mora uključivati sve funkcionalne zahtjeve postavljene na sustav


Dijagrami slučaja uporabe

• Prikazuju odnose sudionika i slučaja uporabe– sudionik koji izravno sudjeluje ili izvodi slučaj uporabe smješta se s lijeve strane prikaza

– slučaj uporabe se smješta u središte

– ostali sudionici uključeni u slučaj uporabe smještaju se s desne strane

– strelice pokazuju koji sudionici su uključeni u koje slučajeve uporabe


Prikaz dijagrama slučaja uporabe

• Sudionik 1 je uključen u izvođenje sva tri slučaja uporabe• Sudionik 3 je aktivno uključen Slučaj uporabe 3• Sudionik 2 je samo primatelj onoga što je pridruženo Slučaju uporabe 2


Dijagrami slučaja uporabe sustava

• Odnos sudionika i slučaja uporabe


Ponašanje sustava

• Ponašanje sustava se opisuje korištenjem– neformalno strukturiranog teksta– formalno strukturiranim tekstom u kojem su navedeni uvjeti usmjeravanja tijeka

– pseudokôdom

• U tekstu se opisuju– akcije koje izvodi sudionik – pozivi sustava– odzivi sustava na akcije sudionika– pozivi i odzivi obuhvaćaju tijek događaja nužnih za ostvarenje ponašanja sustava


Podjela tijeka događaja ...

• Osnovni/tipični tijek događaja– sudionik i sustav prolaze u normalnim okolnostima rada sustava

– od početka do kraja se izvodi kako je opisano

– pretpostavka je da ključni sudionik i sustav ne prave pogreške

– opis uporabe uvijek sadrži osnovni tijek događaja

– predstavlja poželjan tijek događaja


Podjela tijeka događaja ...

• Zamjenski, alternativni tijek događaja– prolazi se u rjeđem broju slučajeva– opisuje dodatna ponašanja sustava

• Iznimni tijek događaja– izvodi se u slučaju pojave pogreške ili neispunjavanja zadanih uvjeta

– slučaj uporabe uvijek sadrži najmanje jedan iznimni tijek događaja

– predstavlja poželjan tijek događaja


Tekstualni opis tijeka događaja

• Osnovni tijek se opisuje sa jednim do tri odjeljka teksta

• Zamjenski tijekovi se opisuju sa jednom ili dvije rečenice

• Iz teksta se očitavaju zahtjevi na rad sustava

• Uz pojedini slučaj uporabe vezuje se nekoliko zahtjeva, odnosno moguće je da se i više slučajeva uporabe vezuje uz jedan zahtjev


Primjer slučaja uporabe ...

• Promatraju se slučajevi uporabe sustava Internet knjižare– primjer modeliranja slučaja uporabe ‘Prijava u sustav’

• Utvrđivanje sudionika– što sudionik poduzima za pokretanje slučaja uporabe

• Korisnik pritisne tipku Prijava na Polaznoj stranici.

– slučaj uporabe opisuje odziv sustava• Sustav prikaže Stranicu prijave.



• Daljnji osnovni tijek događaja je opisan akcijama koje izvodi – sudionik kod prijave – sustav kao odzive

• Korisnik unosi svoju korisničku oznaku (ID) i lozinku, te pritisne tipku OK. Sustav provjerava ispravnost unesenih informacija u odnosu na spremljene podatke Korisničkog računa. Sustav Korisnika vraća na Polaznu stranicu.

• Poželjno je izričito povezati tekst koji opisuje slučaj uporabe s modelom klasa– klasa Korisničkog računa sadrži atribute ID i lozinka



• Uz osnovni tijek događaja poželjno je navesti moguće zamjenske tijekove događaja i uvjete koji dovode do iznimaka u radu sustava– Moguće akcije korisnika i odzivi sustava prije prijave Korisnika u sustav dovode do sljedećih tijekova

• Ako Korisnik pritisne tipku Novi korisnički račun, sustav prikaže stranicu Otvaranje novog korisničkog računa

• Ako Korisnik pritisne tipku Zapamćena riječ, sustav prikaže zapamćenu riječ pohranjenu za tog korisnika. Kada korisnik pritisne tipku OK, sustav Korisnika vraća na Polaznu stranicu.



• Sustav nije u mogućnosti utvrditi valjanost korisnikovih informacija i ne može ostvariti prijavu– Ako Korisnik unese korisničku oznaku koju sustav ne može prepoznati, sustav prikaže stranicu Otvaranje novog korisničkog računa.

– Ako Korisnik unese neispravnu lozinku, sustav upozori Korisnika da ponovo unese lozinku.

– Ako Korisnik tri puta unese neispravnu lozinku, sustav prikazuje stranicu koja Korisnika uputi na službu za korisnike.



• Iz teksta slučaja uporabe treba biti vidljivo mjesto grananja zamjenskih tijekova i tijekova iznimki– prikladno je numerirati korake osnovnog i ostalih tijekova

• Jedno od osnovnih načela slučaja uporabe– slučaj uporabe na kraju izvođenja treba dostaviti korisniku vrijedan rezultat

• na kraju osnovnog tijeka korisnik je prijavljen u sustav• na kraju zamjenskih tijekova, korisnik je također prijavljen u sustav, ali sa drugim ishodima

– sustav dovodi korisnika na stranicu otvaranja računa i pretpostavka je da nastavlja s osnovnim slijedom

• na kraju iznimnih tijekova– sustav upućuje korisnika na stranicu za pomoć



• Primjer modeliranja slučaja uporabe ‘Pisanje recenzije korisnika’– opis slučaja uporabe

• s gledišta sudionika

• izvršni oblik rečenica

• u sadašnjem vremenu

• ishod je vrijedan rezultat

• zamjenski tijekovi



• Osnovni tijek– Na stranici Knjiga, korisnik pritisne tipku Recenzija knjige. Sustav prikaže stranicu Napisati recenziju.

– Korisnik adabere ocjenu za knjigu, upisuje naslov recenzije i samu recenziju. Zatim korisnik odabere da li će uz recenziju biti prikazano ime i/ili adresa elektroničke pošte korisnika.

– Kada korisnik završi odabir i unese informacije pritisne tipku Pregled moje recenzije. Sustav prikaže stranicu Pregled vaše recenzije s unesenim informacijama. Korisnik pritisne tipku Spremi. Sustav spremi informacije pridružene recenziji i vraća Korisnika na stranicu Knjiga.



• Zamjenski tijek– Ako Korisnik na stranici Knjiga pritisne tipku Upute za recenziranje, sustav prikaže stranicu Upute za recenziranje. Kada korisnik pritisne tipku OK , sustav vraća Korisnika na stranicu Knjiga.

– Ako Korisnik na stranici Pregled vaše recenzije pritisne tipku Uredi, sustav Korisniku omogućava izmjenu informacija koje je unio na stranici Napisati recenziju. Kada korisnik pritisne tipku Spremi, sustav spremi recenziju i korisnika vraća na stranicu Knjiga.


Ustrojavanje slučaja uporabe

• Olakšati razumijevanje ponašanja sustava izdvajanjem i povezivanjem zajedničkog ponašanja

• Koriste se relacije– obuhvaćanja (include)

– proširenja (extend)

– poopćavanja (generalization)


Relacija obuhvaćanja

• Način povezivanja slučaja uporabe– kada osnovni slučaj uporabe izričito obuhvaća funkcionalnosti drugog slučaja na određenim mjestima tijeka događaja

– obuhvaćeni slučaj uporabe ne postoji samostalno već je povezan s jednim ili više osnovnih slučajeva uporabe

• Relacijom se izdvajaju funkcionalnosti koje su zajedničke za više slučajeva uporabe


Primjeri relacije obuhvaćanja

• Slučajevi uporabe Napisati recenziju i Dodati knjigu za kupnju obuhvaćaju Prijavu


Relacija proširenja

• Način povezivanja slučajeva uporabe– kada osnovni slučaj uporabe neizričito obuhvaća funkcionalnosti drugog slučaja uporabe na određenim mjestima tijeka događaja

– mjesta se nazivaju mjesta proširenja• Relacijom se izdvajaju funkcionalnosti koje se

• slobodno odabiru ili• pojavljuju u određenim uvjetima

• Primjer: – tvorba novog slučaja uporabe za potrebe zamjenskog tijeka događaja koji uz sebe povezuje nekoliko koraka


Primjeri relacije proširenja

• Kod prekida obrade Narudžbe, Korisnik ima izbor provjere stanja narudžbe


Relacija poopćavanja ...

• Određenje poopćavanja slučaja uporabe slično poopćavanju klasa– ponašanje višeg slučaja uporabe (roditelj) nasljeđuje podslučaj uporabe (dijete)

– podslučaj može dodati novo ponašanje ili preko postojećeg ponašanja prepisati novo

• Prikaz relacije poopćavanja slučaja uporabe kao kod poopćavanja klasa


Označavanje poopćavanja slučajeva uporabe


Prikaz poopćavanja slučajeva uporabe

• Slučajevi uporabe različitih pretraga omogućenih korisniku– sve pretrage koriste osnovne tehnike pretrage i u slučaja uporabe Pretraga


Paketi i slučajevi uporabe

• Paketi srodnih slučajeva uporabe– omogućavaju podjelu poslova između projektnih timova

• Model slučaja uporabe– paket paketa slučajeva uporabe

Paket


Prikaz primjera paketa slučaja uporabe

• Srodnost slučajeva uporabe u paketu Kupnja

• Ostali paketi slučajeva uporabe– paket Recenzija sadrži

• slučajeve uporabe: – pisanje korisničke recenzije– korisnikova ocjena recenzije drugih

korisnika– pisanje uredničke recenzije

– paket Održavanje korisničkog računa sadrži

• slučajeve uporabe– uređivanje korisničkog računa– prijava u sustav

Kupnja


Model slučaja uporabe i ostali modeli

• Model slučaja uporabe– utječe na sve ostale osnovne modele razvoja programske podrške ujedinjenim procesom

• model analize– opisuje moguće realizacije slučaja uporabe– detaljnije izražava slučajeve uporabe jezikom projektanta– početni prikaz realizacije slučaja uporabe pridjeljuje ponašanje opisano slučajem uporabe konkretnim objektima

• model plana izvedbe– model slučaja uporabe i model analize su osnova izgradnje modela plana izvedbe

• model ostvarenja i model rasporeda– uvjetovani slučajevima uporabe


Značaj slučajeva uporabe ...

• Brza izrada prototipa– korisnik i projektant zajedno izrađuju prototip kojim se dokazuje izvedivost sustava (proof of concept)

– jednostavna izrada osnovnog tijeka događaja slučaja uporabe, unapređenje prototipa usavršavanjem modela

• Izrada sustava na temelju postojećeg (reverzno)– izraditi slučajeve iz raspoložive korisničke dokumentacije

• poglavlje priručnika može predstavljati paket slučaja uporabe

• proceduralni način priručnika izravno je vezan s redoslijedom slučajeva uporabe


Značaj slučajeva uporabe

• Primjena kod provjere rada sustava– osiguranje kakvoće izvedenog sustava

• provjera metodom crne kutije– izravno se koristi tekst opisa normalnog i iznimnog slijeda događaja slučaja uporabe

– rad sustava se provjerava sa strane korisnika• ne provjerava se kako sustav radi već da li daje ispravne rezultate


OPIS ZAJEDNIČKOG RADA ELEMENATA


Opis zajedničkog rada predmeta

• Klasama, objektima i njihovim odnosima opisuje se– struktura sustava (statika)

• Slučajevima uporabe i tijekom događaja opisuje se– ponašanje sustava (dinamika)

• Izrada početnog modela– zajednički rad objekata

– preciziranje statičkih i dinamičkih značajki modeliranog sustava

• Analiza sustava


Analiza sustava

• Analiza sustava ostvaruje se – raščlambom teksta koji opisuje slučajeve uporabe

– određivanjem objekata u slučaju uporabe

– razvrstavanjem objekata u klase na temelju zajedničkih obilježja

• Povezana s radnim tijekom analize (analysis workflow) u ujedinjenom procesu izgradnje programskog sustava


Klase analize

• Analizom se postavlja početni model sustava– dodjelom postupaka sustava klasama analize

• rubne klase

• klase jedinki (entiteta)

• upravljačke klase

• Klase se opisuju objektima koji predstavljaju instance navedenih klasa


Rubni objekt

• Rubni objekt je pristupni objekt u slučaju uporabe– sudionik pristupa sustavu preko rubnog objekta– kada je sudionik čovjek rubni objekt je

• prozor, zaslon, dijaloški okvir, izbornik

– kada je sudionik program rubni objekt je• sučelje aplikacijskog programa (Application Program Interface – API)

• Rubni objekt odgovara imenicama u tekstu opisa slučaja uporabe

• Simbol za rubni objekt


Objekti jedinki

• Objekt jedinke sadrži informacije– trajnije, manje promjenljive

• povezanost s bazama podataka

– privremene, promjenljive• rezultati pretrage, sadržaj popisa u prozoru

• Objekt zasebnih jedinki odgovara imenicama u tekstu opisa slučaja uporabe

• Simbol za objekat jedinke


Upravljački objekti

• Upravljački objekt – obuhvaća logiku aplikacije– vezan je uz aktivnosti sustava, a ne sudionika– koordinira i upravlja redoslijedom izvođenja – izvodi računanja s objektima jedinke– povezuje rubne objekte i objekte jedinke

• Upravljači objekt odgovara glagolima u tekstu opisa slučaja uporabe

• Simbol upravljačkog objekta


Primjer modela analize ...

• Analiza slučaja uporabe Prijava u sustav– Korisnik pritisne tipku Prijava na Polaznoj stranici. Sustav prikaže Stranicu prijave. Korisnik unosi svoju korisničku oznaku (ID) i lozinku, te pritisne tipku OK. Sustav provjerava ispravnost unesenih informacija u odnosu na spremljene podatke Korisničkog računa. Sustav Korisnika vraća na Polaznu stranicu.



• Izrada dijagrama analize za osnovni tijek– za potrebe opisa ponašanja slučaja uporabe

• iz rečenica teksta opisa slučaja uporabe izdvojiti– rubne, zasebne i upravljačke objekte

– vizualizirati izvedene objekte i njihove odnose

– kao sudionik slučaja izdvaja se Korisnik



• “Korisnik pritisne tipku Prijava na Polaznoj stranici”

– uz korisnika dva rubna objekta tipka i stranica• tipka Prijava je dio Polazne stranice

– prikaz relacijom sastavljanja

– pritisak (tipke) se ne prikazuje upravljačkim objektom• implicitno uključen u vezu korisnika i tipke Prijava

• upravljački objek je vezan uz akcije sustava, a ne akcije sudionika

Korisnik

Tipka prijave Polazna stranicaPolazna stranica

Korisnik Drugi mogući prikazDijagram analize 1



• “Sustav prikaže Stranicu prijave.”– uvode se

• za ‘prikaže’ upravljački objekt

• rubni objekt za Stranicu prijave

– na ovoj razini razvoja prikladno reći ‘sustav’ jer se još ne zna kjom klasom će se prikazati

Polazna stranica

Stranica prijave

Prikaz

Dijagram analize 2



• Postoje pravila dozvoljene komunikacije između objekata analize – rubni objekti ne smiju međusobno komunicirati

• zato je uveden upravljački objekt Prikaz

• u kasnijim fazama modeliranja upravljački objekt se prevodi u metodu drugog objekta



• “Korisnik unosi svoju korisničku oznaku (ID) i lozinku, te pritisne tipku OK.”– uvodi se četvrti rubni objekt, tipka OK, koji je dio Stranice prijave

– oznaka na vezi KorisnikStranica prijave nijeobvezna

KorisnikStranica prijave

Tipka OK

unos ID/lozinka

Dijagram analize 3



• “Sustav provjerava ispravnost unesenih informacija u odnosu na spremljene podatke Korisničkog računa.”– uvode se dva nova objekta

• upravljački objekt za ‘provjeru’• objekt jedinke za Korisnički račun

– pravilo dozvoljene komunikacije između objekata analize

• rubni objekti ne smiju izravno komunicirati s objektom jedinke

– novi upravljački objekt se smješta između tike OK i Korisničkog računa

– koristi se ‘postojeći’ upravljački objekt Prikaz



• Dvostruka strelica u vezi Provjeriti prijavu i Korisnički račun – označava da upravljački objekt očekuje odziv objekta jedinke

• Ako postoje zamjenski tijekovi prikladno je označiti tijekove koji pripadaju osnovnom tijeku i zamjenskim tijekovima– oznaka prijava OK označava da na zamjenskom putu može postojati oznaka

neuspjele prijave

Korisnik

Tipka OK

Polazna stranicaPrikaz

Prijava OK

Provjera unosa

Korisnički račun

Dijagram analize 4


Primjer modela analize

• Završni dijagram analize koji uključuje i rečenicu “Sustav Korisnika vraća na Polaznu stranicu.”

Polazna stranica PrikazPrijava OK

Korisnički račun

Stranica prijave

Tipka OK

Korisnik

Tipka prijave

unos ID/lozinka

Provjera unosa


Modeliranje dinamičkog ponašanja

• Modeliranje međudjelovanja između objekata– porukama i akcijama

• Poruka– razmijenjena informacija

• između dva objekta• unutar objekta

– koja rezultira akcijom– uzrokuje jednu ili više akcija

• Akcija– izvršna naredba koja rezultira

• promjenom vrijednosti jednog ili više atributa objekta• povratom vrijednosti objektu koji je uputio poruku• promjenom i povratom vrijednosti• UML izričito podržava pet vrsta akcija


Akcije poziva i povrata

• Akcija poziva (call action)– priziv metode odredišnog objekta– sinkrona akcija

• pošiljatelj pretpostavlja spremnost primatelja da primi poruku i

• pošiljatelj čeka odziv primatelja prije nastavka daljnjih aktivnosti

• Objekt poziva– drugi objekt– samoga sebe


Označavanje akcije poziva

• Puna linija sa strelicom usmjerenom od pošiljatelja poruke prema primatelju poruke

• Crtkana linija označava– crtu života objekta

• iz dijagrama međudjelovanja


Akcija povrata

• Akcija povrata (return action)– vraća se vrijednost kao odziv na akciju poziva

• Označavanje • crtkana strelica usmjerena od objekta koji vraća vrijednost prema objektu koji prima vrijednost

– od izvornog primatelja prema izvornom pošiljatelju


Prikaz primjera akcije povrata

• Ako je povratna vrijednost očita iz konteksta poslanoj poruci se ne pridružuje povratna poruka


Akcije tvorbe i dokidanja

• Akcija tvorbe (create action)– kreira objekt, tj. klasa proizvodi svoju instancu

– označavanje akcije tvorbe• generirani objekt se može nacrtati na kraju strelice i crtu života započinje iz generiranog objekta


Akcija dokidanja

• Akcija dokidanja (destroy action)– uništava objekt

• objekt se dokida• prekida se crta života

– objekt može izvesti akciju dokidanja• drugog objekta• dokidanja samog sebe

• Navodnici <<>> označavaju da riječi tvori i dokini ulaze ulaze u istu vrstu ključnih riječi UML‐a kao i riječi uključi i proširi


Akcija odašiljanja

• Akcija pošalji (send action)– odašilje signal objektu

• Signal– ostvaruje asinkronu komunikaciju između objekata

• prvi objekt ‘dobacuje’ (throw) signal drugom objektu koji ‘hvata’ (catch) signal, ali

• pošiljatelj signala ne očekuje odziv od primatelja, kao što je to slučaj kod akcije poziva

– iznimke predstavljaju najčešći tip signala– označuje se punom linijom s prepolovljenom strelicom u smjeru crte života objekta primatelja


Označavanje akcije odašiljanja

• Označavanje akcije odašiljanja UML‐om

• U ovom slučaju stranica prijave se može sama dokinuti kada preda signal iznimke


Signali

• Označavanje signala– atributi signala služe kao parametri signala kojeg objekt odašilje drugom objektu

• Označavanje signala na koje objekti klase mogu odgovoriti– dodatni odjeljak klase sadrži nazive signala na koje objekt klase može odgovoriti

<<signal>>Signal

atribut : tip

Klasa

SignaliSignal


Primjer označavanja signala

• Prikaz signala neispravne lozinke prethodno prikazanog akcijom odašiljanja

<<signal>>NeispravnaLozinka

korisničkiID: string

RukovanjeIznimkama

SignaliNeispravnaLozinka


Dijagram međudjelovanja

• Dijagram međudjelovanja (interaction sequence diagram)– usmjeren na vremenski redoslijed razmjene poruka između objekata

• Povezan s radnim tijekom plana izvedbe (design workflow) u ujedinjenom procesu razvoja programskog sustava

• Koristi ga projektni tim pri– dodjeli operacija klasama na temelju dodjele metoda objektima u dijagramu


Označavanje dijagrama međudjelovanja

• Dijagram međudjelovanja je sastavljen od četiri elementa– oznake objekta

• smještene na vrhu dijagrama– kao kod dijagrama objekata– kao simbol u dijagramu analize

– crte života objekta koja označava• trajanje, život objekta• dokinuće, smrt objekta

– ako se na crti života ne nalazi oznaka dokinuća objekta X, pretpostavlja se trajnost objekta

– težišta nadzora (focus of control)• dugački i široki pravokutnik na crti života objekta

– pravokutnik označava vremenski tijek za koji objekt nadzire tijek događanja» npr. kada objekt izvodi metodu ili kreira novi objekt

• ne mora se nužno prikazati na dijagramu međudjelovanja– poruke

• prikazuju aktivnosti između objekata ili objekta na sebi samome


Izrada dijagrama međudjelovanja

• Izrada dijagrama međudjelovanja– za osnovni slijed događanja u slučaju prijave u sustav

• koristeći slučaj uporabe “Prijava u sustav (Log In)”, a

• na osnovu dijagrama analize

• Postupak odražava korak ujedinjenog procesa– kada projektni tim

• na temelju modela analize (analysis model) dobivenog analizom slučaja uporabe sustava

– čiji je osnovni sadržaj dijagram analize

• izgrađuje početni model plana izvedbe (design model)


Primjer izrade dijagrama međudjelovanja ...

• Osnova je dijagram analize dobiven raščlambom opisa slučaja uporabe

• Prvi dio dijagrama međudjelovanja– tipke s dijagrama analize su ugrađene u stranice i ne prikazuju se u

dijagramu međudjelovanja– pritisak korisnika na tipku prijave se prikazuje kao poruka

Dijagram analize 1 Dijagram međudjelovanja 1

Korisnik pritisne tipku Prijava na

Polaznoj stranici.



• Upravljanje na Polaznoj stranici započinje gdje je žarište upravljanja Korisnika završilo– izraziti prikaz prijelaza upravljanja s objekta na objekt

– rečenica uz dijagram razvoj sustava, naglašava razvoj pokretan slučajevima uporabe



• Drugi dio dijagrama međudjelovanja– objekti su Polazna stranica i Stranica prijave

– upravljački objekt se prevodi u metodu drugog objekta• pretpostavka je da se HTML stranice znaju prikazati pa se upravljački objekt Prikaz

prevodi u metodu Stranice prijave– Polazna stranica poziva metodu prikaza Stranice prijave pozivom akcije

Sustav prikaže Stranicu prijave.

Polazna stranica

Stranica prijave

Prikaz




• Treći dio dijagrama međudjelovanja– objekti su Korisnik, Stranica prijave i tipka OK na stranici

• tipka se prevodi u poruku

• uvodi se i prijava korisnika

Stranica prijave

Tipka OK

unos ID/lozinka


Korisnik unosi svoju korisničku oznaku (ID) i lozinku, te

pritisne tipku OK.



• Četvrti dio dijagrama međudjelovanja– objekti su sudionik (Korisnik), dva rubna objekta (Polazna stranica i tipka OK),

objekt jedinke (Obračun) i dva upravljačka objekta (Provjera unosa i Obračun)

Korisnik

Tipka OK

Polazna stranicaPrikazPrijava OK

Provjera unosa

Korisnički račun

Dijagram analize 4

Dijagram međudjelovanja 4

Sustav provjerava ispravnost unesenih informacija u odnosu na spremljene

podatke Korisničkog računa.



• Pretpostavlja se da trajni objekt Obračun zna provjeriti vrijednosti svojih atributa– provodi logiku upravljačkog objekta ze Provjera unosa iz dijagrama analize

– korisnička oznaka (ID) i lozinka, koje unosi Korisnik, prevode se u parametre poruke koja poziva metodu provjere objekta Obračun

• Promatra se osnovni tijek slučaja uporabe– pozitivan ishod

• Obračun pronalazi ID i lozinku i upravljanje se vraća na Polaznu stranicu i do Korisnika

• upravljanje se moglo vratiti i na Polaznu stranicu gdje upravljanje čeka akciju Korisnika


Primjer izrade dijagrama međudjelovanja

Potpuni dijagram međudjelovanja

Korisnik pritisne tipku Prijava na Polaznoj stranici.

Sustav prikaže Stranicu prijave.

Korisnik unosi svoju korisničku oznaku (ID) i lozinku, te pritisne tipku OK.

Sustav provjerava ispravnost unesenih informacija u odnosu na spremljene podatke Korisničkog računa.

Sustav Korisnika vraća na Polaznu stranicu.


Dijagram suradnje ...

• Dijagram suradnje– je usmjeren na prikaz ustroja objekata koji razmjenjuju poruke

– i dijagram međudjelovanja• prikazuju istu informaciju

• pridruženi su radnom tijeku plana izvedbe (design workflow)


Dijagram suradnje ...

• Dijagram suradnje– prikazuje objekte i poruke– ne prikazuje crtu života i težište nadzora– poruke imaju brojčane oznake kako bi se pratio redoslijed njihove primjene

• npr. označavanje poruka u slučaju kada jedan objekt šalje poruku drugom objektu koji je šalje trećem objektu glasi 1., 1.1, 1.1.1

– jednostavan zapis ponavljanja (iteracije)• npr. ako se izraz *[i = 1 .. n] ili samo *, pojavi ispred niza brojeva to znači da se poruka ponavlja

• teže se prikazuje u dijagramu međudjelovanja


Dijagram suradnje i dijagram međudjelovanja

• Razlike između dijagrama suradnje i i dijagrama međudjelovanja– dijagram suradnje

• usmjeren je na strukturalnu povezanost objekata

– dijagram međudjelovanja• usmjeren je na vremenski slijed razmjene poruka između objekata

• Primjena jednog ili drugog zavisi o– sustavu koji se modelira i– vlastitim sklonostima

• Dijagram analize predstavlja oblik dijagrama suradnje bez brojčanih oznaka


Grafički prikaz dijagrama suradnje

Slučaj uporabe “Prijava u sustav”

Korisnički račun

Polazna stranica

Stranica prijave

1 : pritisnutiPrijava()

2 : prikaz()

3 : unos ID i lozinke2 : pritisnutiOK()

5 : provjeraPrijave(korisničkiID, lozinka)

6 : prikaz()


Dijagrami međudjelovanja

• Dijagrami međudjelovanja (interakcije)– dijagram međudjelovanja svojim prikazom i

– dijagram suradnje označenim porukama

– pokazuju što se tijekom vremena događa između skupine objekata

– prikladan prikaz vremenski vezanih zahtjeva• modelirani sustav sadrži operacije koje se odvijaju u stvarnom vremenu ili

• prostorno raspodijeljeni sustavi


UML izrazi vezani uz vrijeme

• Vremenski izraz– razvojem izraza razlučuje da li se radi o relativnoj ili apsolutnoj vrijednosti vremena

• Vremenska oznaka– uz poruku vremenom vezan naziv ili oznaka

• Vremensko ograničenje– uvjet koji treba biti ispunjen u odnosu na vrijeme

– sadrži vremenski izraz ili oznaku vremena


• Slučaj uporabe “Prijava u sustav”– koristi se vremenska oznaka (p) i vremenski izraz (vrijemeIzvođenja < 3 sec)– vremenska oznaka uz poruku (provjeraPrijave) olakšava upućivanje na ovu

poruku na drugim mjestima u dijagramu međudjelovanja (ili odgovarajućem dijagramu suradnje)

Vremensko ograničenje u dijagramu međudjelovanja

: StranicaPrijave : Računp: provjeraPrijave(korisničkiID, lozinka)

{p.vrijemeIzvođenja < 3 sec}


Vremenska ograničenja

• Modeliranje dvije posebne vrste poruka vremenskim ograničenjima– zadržana poruka

• sinhrona poruka• pošiljatelj odustaje od slanja poruke ako prijemni objekt nije spreman za prijem poruke

• prikaz vremenskim ograničenjem – {čekanje = 0}

– poruka isteka vremena• sinhrona poruka• pošiljatelj čeka prijemni objekt odeđeni vremenski interval da se pripremi za prijem poruke

• prikaz vremenskim ograničenjem– {čekanje = 50 ms}


Paketi analize i plana izvedbe ...

• Model analize ujedinjenog procesa razvoja sadrži– klase analize dobivene iz dijagrama analize

• Paket analize– sadrži klase analize i dijagrame analize koji prikazuju njihova međudjelovanja

Analiza korisnika

Polazna stranica Stranica prijaveKorisnički račun

Analiza prijave


• Dijagrami međudjelovanja i dijagrami suradnje pripadaju modelu plana izvedbe– unose se u paket plana izvedbe

– postoji povezanost (traceability) izmđu paketa plana izvedbe i paketa analize

• Početak izrade paketa plana izvedbe

Paketi analize i plana izvedbe

Plan izvedbe


DETALJAN OPIS STRUKTURE ELEMENATA


Detaljan opis strukture elemenata

• Posljednja dva poglavlja usmjerena na– modeliranje korisnika i ponašanja sustava UML‐om

• Ovo poglavlje usmjereno na– modeliranje strukture elemenata

• korištenje UML‐a za detaljan opis i proširenje modela sustava


Apstraktne klase

• Apstraktna klasa – je klasa bez instance objekta

– obuhvaća operacije koje nasljeđuju niže klase• operacije apstraktne klase su razmjerno općenite

• klasa koja nasljeđuje te operacije će se njihovim korištenjem unaprijediti i proširiti

• Naziv apstraktne klase se u UML‐u piše kosim slovima Apstraktna klasa

atributi

operacije

Apstrakta klasa


Primjer apstraktne klase

• Klasi Recenzija je dodana apstraktna operacija (bilježiti) • Klase Recenzija korisnika i recenzija urednika

– nasljeđuju dodanu operaciju– u pojedinoj klasi operacija se ponaša različito

Recenzija

bilježiti()



Zavisnosti

• Zavisnost predstavlja odnos korištenja– promjena u jednoj klasi utječe na drugu klasu

• primjeri zavisnosti kod slučaja uporabe– <<include>> i <<extend>>

• Označavanje zavisnosti operacije jedne klase o drugoj klasi

Zavisna klasa

operacija Nezavisna klasa


Primjer zavisnosti klasa

• Ako se određenje klase Knjiga promjeni promijeniti će se i način rada funkcije provjeritiRaspoloživost

Narudžba

provjeritiRaspoloživost(k: Knjiga) Knjiga


Detaljniji opis atributa i operacija

• Jezične konstrukcije za detaljniji opis atributa i operacija– vidljivost atributa i operacija (tri razine)

• javna (public)

• zaštićena (protected)

• osobna (private)


Vidljivost atributa i operacija ...

• Vidljivost elemenata (atributa/operacija) klase– vidljivost atributa i operacija klase iz druge klase

– mogućnost pristupa atributima i operacijama promatrane klase objektima iz druge klase

– vezano uz omatanje (enkapsulaciju)• stupanj omotanosti elemenata klase zavisi o pridruženoj vidljivosti tim elementima


Vidljivost atributa i operacija ...

• Javna vidljivost (+)– pristup i korištenje atributa i operacija klase

• dozvoljeno objektima bilo koje vanjske klase

• Zaštićena vidljivost (#)– pristup i korištenje atributa i operacija klase

• dozvoljeno samo objektima niže klase dotične klase

• Osobna vidljivost (‐)– pristup i korištenje atributa i operacija klase

• dozvoljena samo objektima te klase


Primjer označavanja vidljivosti

• Klasa Korisnički račun– atributi klase su osobni

• pristup je dozvoljen samo objektima te klase

• Klasa Recenzija– operacija zabilježiti je zaštićena

• objekti klasa Recenzija korisnika i Recenzija urednika, kao i niže klase tih klasa mogu je koristiti, ali objekti klasa izvan te hijerarhije ne mogu je koristiti

• Klasa Recenzija korisnika– operacija pridružitiOcjenu je javna

• mogu je koristiti objekti bilo koje klase– operacija izračunatiProsječnuOcjenu je osobna

• mogu je koristiti samo objekti te klase

Korisnički račun

‐ emailAdresa

‐ ID

‐ lozinka

Recenzija

# zabilježiti()

Korisnički račun

+ pridružitiOcjenu‐ izračunatiProsječnuOcjenu


Format iskazivanja atributa

• Puni format iskazivanja atributa

[vidljivost] naziv [višestrukost] [: tip] [= početna vrijednost] {svojstvo atributa}

– obvezan samo naziv• detalji se popunjavaju tijekom razvoja sustava

– početna vrijednost atributa klase • svaki objekt te klase ima tu početnu vrijednost atributa

– višestrukost atributa klase• koliko je tog atributa prisutno u svakoj instanci te klase

– upisuje se u uglate zagrade iza naziva atributa


Svojstva atributa

• Svojstvo promjenljivosti (changeable)– dozvoljava mijenjanje postojećih i dodavanje novih vrijednosti

• uporaba kod lista pretpostavljenih vrijednosti

– promjenljivost je pretpostavljeno svojstvo atributa

• Svojstvo izričitog dodavanja (addOnly)– dozvoljava dodavanje novih vrijednosti – zabranjuje mijenjanje postojećih vrijednosti

• Svojstvo zamrznutosti (frozen)– zabranjuje dodavanje novih ili promjenu postojećih vrijednosti

• uporaba kod atributa koji predstavljaju jedinstvene oznake


Primjer prikaza svojstava atributa

• Objekt klase Korisnički račun može imati od 1 do 3 email adrese

• ID korisničkog računa se ne smije izbrisati• Atribut lozinka ima početnu vrijednost koja se može

mijenjati, ali je poželjno da postoji ako je korisnik zaboravi zadati kod uspostave korisničkog računa

Korisnički račun

emailAdresa[1..3]ID: string {frozen}lozinka = 1234


Format iskazivanja operacije

• Puni format iskazivanja operacije

[vidljivost] naziv [popis parametara] [: tip povratne vrijednosti] {svojstvo operacije}

– obavezan je samo naziv

– vidljivost i tip povratne vrijednosti već razmatrani

– popis parametara• podaci koje predaje pozivatelj operacije

• podaci koje operacija vraća pozivatelju operacije

• primljeni i vraćeni podaci


Popis parametara[smjer] naziv : tip [= pretpostavljena vrijednost]

• smjerovi parametara– unutra (in)

• unutar operacije nije dozvoljena izmjena vrijednosti parametra• pozivatelju ne treba vratiti vrijednost parametra

– van (out)• unutar operacije se postavlja ili mijenja vrijednost parametra• operacija vraća vrijednost pozivatelju operacije

– unutra i van (inout)• operacija koristi vrijednost parametra i dozvoljena je promjena vrijednosti

• pozivatelj očekuje pristup vrijednosti parametra


Svojstva operacije

• Svojstvo slijeda (sequential)– samo jedan poziv metode može izvoditi objekt klase

• operaciji kod klase odgovara metoda kod objekta

• Svojstvo istodobnosti (concurrent)– više poziva metode može izvoditi objekt klase

• Svojstvo čuvanja (guard)– može postojati više istovremenih poziva metode, ali objekt izvodi samo jedan poziv

• Svojstvo provjere promjene (isQuery)– operacija ne mijenjati vrijednost niti jednog atributa

• Svojstva slijeda, istodobnosti i čuvanja vezana su uz programske niti (thread)


Primjer prikaza detalja operacije

• Operacija provjeritiRaspoloživost prima objekt Knjiga i vraća vrijednost Status tip koje je odredio korisnik

• Operacija ispitatiPopunjenost vraća vrijednost istinito ako su sve naručene knjige raspoložive, odnosno vrijednost laž u protivnom slučaju

Narudžba

...

provjeritiRaspoloživost(in k: Knjiga) : StatusispitatiPopunjenost(): bool {isQuery}


Proširenja UML‐a

• Proširenja označavanja modela UML‐om– stereotipovi (stereotypes)

– ograničenja (constraints)

– označene vrijednosti (tagged values)


Stereotipi

• Određenje stereotipa– proširuje osnovni rječnik UML‐a

• izgradnja konstrukcija za modeliranje koje se ne nalaze u osnovnom skupu UML konstrukcija, ali su slične dijelovima koji se nalaze u osnovnom skupu

– UML raspolaže s više od četrdeset stereotipova primjenjivih na elemente modela, npr. klase, veze i pakete

• postoji mogućnost izrade vlastitih stereotipova– elementi modela jedinstveni za projekt

• Prikaz stereotipa– nazivom između kosih zagrada (<<nazivStereotipa>>)– po volji odabranim simbolom


Primjeri prikaza stereotipa

• Označeni stereotipovi su ugrađeni u UML• Stereotip <<become>> (postaje) označava da vremenom objekt klase Narudžba

prelazi u objekt klase Otpremnica• Stereotip Stranica prijave izražen je simbolom rubnog elementa

– klasa kojoj pripada rubni objekt se može označiti kao <<rubna klasa>>– ostali tipovi klase analize se mogu označiti kao <<klasa entiteta>> i <<klasa nadzora>>

<<signal>>NeispravnaLozinka

korisničkiID : string Odjava iz sustava Prijava u sustav

<<include>>

<<become>>

Narudžba Otpremnica

Stranica prijave


Ograničenja

• Ograničenje– proširuje značenje elementa modela– opis uvjeta kojeg treba ispuniti element modela

• npr. atribut, pridruženost ili najduže dozvoljeno vrijeme izvođenja metode

– UML raspolaže s desetak ograničenja• većina se odnosi na pridruživanje i poopćavanje• postoji mogućnost izrade vlastitih ograničenja

• Prikaz ograničenja– nazivom ili izrazom unutar vitičastih zagrada, {nazivOgraničenja} ili {izraz}, uz element koji se ograničava


Primjeri prikaza ograničenja

• Ograničenje {kodirano} je odredio korisnik– lozinke uz objekte klase Korisnički račun su kodirane kako bi se zaštitila njihova cjelovitost

• Ograničenja {or} (ili) i {ordered} (uređeno) sadrži UML– recenzija može biti recenzija korisnika ili urednika– recenzije pridružene knjizi se obrađuju u posebno redu

Korisnički račun

emailAdresa[1..3]

ID: string

lozinka = 1234 {kodirano}Recenzija

zabilježiti()


Knjiga

naslov : string

Recenzija<<or>>

<<ordered>>


Označene vrijednosti

• Određenje označenih vrijednosti– proširuje svojstva elementa modela, ali ne instance tog elementa

• npr. označena vrijednost primijenjena na klasu pruža informaciju o klasi, ali se ne primjenjuje na objekte koji pripadaju toj klasi

– UML raspolaže s nekoliko označenih vrijednosti koje su primjenjive na elemente modela

• postoji mogućnost izrade vlastitih označenih vrijednosti

• Prikaz označenih vrijednosti– parom naziv i vrijednost unutar vitičastih zagrada

• {nazivOznake = vrijednost}

– samo vrijednošću {vrijednostOznake}


Primjeri prikaza označenih vrijednosti

• Označena vrijednost u klasi Recenzija urednika– označava koje buduće izdanje (release) sustava će sadržavati određeni

element, klasa Recenzija urednika će se pojaviti u izdanju 2.1• Označena vrijednost u klasi RezultatPretrage

– UML raspolaže označenom vrijednošću ‘persistence’ (trajnost) s vrijednostima• ‘transient’ (prijelazno)‐ životni vijek elementa je kratak• persistent (trajno) ‐ životni vijek elementa je dug

– rezultati pretrage će se poništiti kada Korisnik napusti stranicu koja prikazuje rezultate

{release= 2.1}

Recenzija urednika{transient}

: RezultatiPretrage


Sučelja i klase ...

• Sučelje– skup operacija usluga koje nudi klasa ili komponenta

• Podržano osnovno pravilo objektu usmjerenog pristupa– razdvajanje sučelja od detalja ostvarenja izloženih operacija

– sučelje predstavlja ugovor kojeg se klasa mora pridržavati

• klasa ostvaruje ili nudi ostvarenje jednog ili više sučelja


Označavanje sučelja

• Prikazi sučelja UML‐om– sučelje prikazano krugom pridruženim klasi crtom

– određenjem sučelja simbolom klase i stereotipom {interface} (sučelje) i crtkanom crtom s otvorenim trokutom na strani sučelja

Klasa

Sučelje

Klasa<<interface>>

Sučelje

operacije


Primjeri prikaza sučelja

• Sučelje Rukovanje lozinkom uz klasu Korisničkog računa– osigurava prilagodljivost korištenja različitih algoritama kodiranja lozinke

kod operacije koja sprema lozinku korisnika• Sučelje Rukovanje popisom uz klasu Popis

– osigurava elementima sustava međudjelovanje s objektima klase Popis ne brinući o načinu rada sustava inventure, npr. FIFO, LIFO i sl.

Korisnički račun

Rukovanje lozinkom

Inventura

<<interface>>Rukovanje inventurom

spremiti()dohvatiti()


Klasa obrasca

• Klasa obrasca (template)– prikaz porodice potencijalnih klasa

– ima skup formalnih parametara

– tvori novu klasu povezivanjem stvarnih parametara s obrascem

• Povezan sa objektu usmjerenim jezicima C++/STL (Standard Template Library)


Označavanje obrasca• Duži zapis

– u gornjem desnom kutu okvira klase u crtkanom pravokutniku navode se formalni parametri

– klasa koja će se povezati s obrascem se prikazuje uobičajenim simbolom klase

– relacija (strelica) zavisnosti je usmjerena od povezane klase na klasu obrasca, strelica je označena ugrađenim stereotipom <<bind>> (povezuje)

• uz stereotip se navodi popis stvarnih parametara

• Kraći zapis– okvir klase s jednim odjeljkom

• upisuje se naziv povezane klase i unutar izlomljenih zagrada popis stvarnih parametara odvojenih zarezima

Klasa obrasca

atributi

operacije

parametar 1parametar 2parametar 3

Povezana klasa

<<bind>> (parametri)

Povezana klasa<parametri>


• TipKupca i TipPredmeta su formalni parametri klase obrasca Popis želja

• Zavisnost ima za posljedicu tvorbe nove klase Popis želja koja prihvaća kupce koji CD kupuju praznikom

Primjer klase obrasca

Popis želja

dodaj(in k : TipKupca, in t : TipPredmeta)obriši(in p : Predmet)

TipKupcaTipPredmeta

Želja

<<bind>> (Praznični, CD)

Lista želja <Programer, CD>


Klase i paketi plana izvedbe

• Određenje klasa započinje na visokoj razini apstrakcije– kasnije u razvoju modela klase se nadopunjuju posebnostima

• analiza robusnosti proizvodi klase analize (analysis class)

• daljnjom razradom ujedinjenog procesa proizlaze klase izvedbe (design class) koje pripadaju modelu plana izvedbe

• Paket plana izvedbe sadrži klase plana izvedbe– model plana izvedbe je paket paketa planova izvedbe


• Klase sadrže operacije koje pripadaju različitim klasama– istraživanjem zahtijevanog ponašanja sustava unapređuje se model plana izvedbe

• slučaj uporabe dovodi do dijagrama međudjelovanja koji služi za pridjeljivanje ponašanja objektima navedenim u slučajevima uporabe

– ponašanje prelazi u metode koje postaju operacije klasa kojima objekti pripadaju– ponašanja pokretana slučajevima uporabe (use case driven)

Prikaz paketa plana izvedbePlan izvedbe korisnika

Dijagram međudjelovanja

Dijagram suradnje

Korisnički račun

emailAdresa[1..3]ID: string {frozen}lozinka = 1234

provjeritiPrijavu(IDkorisnika, lozinka) : boole

Polazna stranica

+ pritisnutiPrijavu()+ prikazati()

Stranica prijave

+ pritisnutiOK()+ prikazati()


OPIS TIJEKOVA PODATAKA


Dinamičko ponašanje objekata

• Modeliranje detalja – unutarnjeg rada objekata

– rada objekata prema drugim objektima

– računskih procesa


Aktivnosti i akcije

• Aktivnost– radnja koju objekt neprekidno izvodi– izvođenje aktivnosti se može prekinuti– može se rastaviti u druge aktivnosti

• Akcija– skupina izvršnih računanja– rezultira u

• promjeni vrijednosti jednog ili više atributa• vraćanju izračunate vrijednosti • ili oboje• izvođenje akcije se ne može prekinuti

– akcija je aktivnost koja se ne može rastaviti

• Aktivnost ima svoje vrijeme trajanja, akcija je radnja kraćeg trajanja


Označavanje aktivnosti i akcije

• Ista oznaka izdužene elipse i za aktivnost i za akciju

• Značenje se spoznaje iz konteksta

Aktivnost Akcija

Izračunati cijenu otpreme

cijenaOtpreme = oznakaDržave * podZbroj

Obnoviti sklonosti korisnika

Otpremiti narudžbu

jeIspunjen = True

Akcije

Aktivnosti (zahtjevaju višerazličitih akcija)


Grananje i stapanje

• Aktivnosti i akcije se općenito izvode slijedno jedna iza druge

• Postoji potreba za razdvajanjem slijeda– mjesto grananja (branch)

• razdvajanje slijeda– daljnje izvođenje u dvije ili više grana

– mjesto stapanja (merge)• povezivanje dvije ili više grane

– daljnje izvođenje u jednoj grani

• Označavanje grananja i stapanja rombom– kao kod dijagrama toka (osim što se ovdje i stapanje prikazuje rombom)


Uvjeti grananja

• Grananje iz mjesta grananja čuvaju uvjeti (guard)– uvjeti su boole‐ovi izrazi s binarnim ishodom

• istina (True) ili laž (False)– grana se slijedi samo ako je uvjet ispunjen– skup svih grana iz mjesta grananja mora obuhvatiti sve mogućnosti slijeda

– uvjeti se međusobno ne smiju preklapati• Uvjeti se zapisuju u uglatim zagradama uz granu na koju se odnose

• Strelice koje ulaze u i izlaze iz aktivnosti pokazuju prijelaze (transition)– pokazuju tijek kontrole izvođenja


Primjer grananja i stapanja

• Prva aktivnost u narudžbi je – izračunavanje početnog podzbroja koji predstavlja cijenu naručenih knjiga

• Dolazi do grananja– budući se troškovi otpreme računaju različito za unutarnji i vanjski promet

• Nakon izračuna cijene otpreme– putanje se stapaju i izračunava se novi podzbroj dodavanjem cijene otpreme


Račvanje i spajanje

• Račvanje (fork)– razdvajanje tijeka izvođenja u dva ili više

• nezavisna i istodobna tijeka

• Spajanje (join)– usklađivanje dva ili više tijeka izvođenja u jedan

• Koriste se kod modeliranja – procesa i niti programa

• Označavanje mjesta račvanja i mjesta spajanja dugim uskim crnim pravokutnikom – sinkronizacijska crta (synchronization bar)


Označavanje račvanja i spajanja

• Do račvanja dolazi nakon izvođenja prve aktivnosti/akcije• Aktivnosti/akcije na paralelnim putanjama izvode

– različite metode– istu metodu ako je operacija u klasi objekta označena svojstvom istodobnosti

(concurrent)• Završetkom svih paralelnih aktivnosti/akcija putanje se spajaju i objekt

nastavlja slijednom obradom


Primjer račvanja i spajanja

• Nakon što sustav zaprimi narudžbu– prve tri aktivnosti nakon račvanja se izvode istodobno

• izvode se na odvojenim dijelovima sustava

• Nakon završetka odvojenih aktivnosti nastavljaju se poslovi otpreme


Dijagrami aktivnosti

• Dijagram aktivnosti– prikazuje redoslijed izvođenja aktivnosti pridruženih promatranom objektu

– obuhvaća prijelaze, grananja i stapanja te račvanja i spajanja

• Koristi se kod– modeliranja radnog tijeka– opisa rada algoritma ili detalja računanja

• Označavanje početnog i konačnog stanja– crni krug odnosno koncentrični krugovi sa crnom ispunom

• Prijelazi su bezuvjetni


Primjer dijagrama aktivnosti


Grupiranje aktivnosti i akcija

• Grupiranje aktivnosti i akcija na dijagramu aktivnosti za njihovo lakše praćenje– vezano npr. uz dijelove organizacije

– označavanje unutar uspravnih crta • plivačkih staza (swimline)

• Granice između staza su pojmovne– u stvarnosti postoje mnogobrojne komunikacije između staza


Primjer grupiranja


Tijek objekta

• Tijek objekta (object flow)– predstavlja zavisnost u dijagramu aktivnosti– detaljno prikazuje utjecaj aktivnosti i akcija u kojima sudjeluje objekt(i) na sami objekt(e)

• Prikaz objekata unutar tijeka objekata– prikazom nove vrijednosti za jedan ili više atributa

• koristi se standardno označavanje – atribut = vrijednost

– prikazom vrijednosti stanja u uglatim zagradama• [stanje]• stanje objekta predstavlja skup vrijednosti atributa u zadanom trenutku


Primjer tijeka objekta

• Prikaz promjena vrijednosti atributa objekta

• Obnovljene su sklonosti korisnika– početna vrijednost atributa je bila

laž– poželjno je istaknuti promjene

vrijednosti atributa na dijagramu• Objekt narudžba ima i atribut koji

označava da li je narudžba unesena u glavnu knjigu– početno je vrijednost laž, nakon

aktivnosti unosa vrijednost se mijenja u istinu


Procesi, niti, aktivni objekti i klase

• Proces upravlja tijekom izvođenja aktivnosti– svakom procesu je pridružena jedinstvena oznaka– program koji se izvodi pod operacijskim sustavom nalazi se unutar procesa

• Nit upravlja tijekom izvođenja aktivnosti– unutar procesa

• Proces se može sastojati od jedne ili više niti• Aktivni objekt je objekt koji raspolaže procesom ili niti

• Aktivna klasa je klasa čije su instance aktivni objekti


• Aktivna klasa ili objekt se prikazuju podebljanim rubom

• Objekt narudžbe upravlja procesom i pojedina putanja potpunog dijagrama aktivnosti predstavlja nit kojoj je pridružen aktivni objekt

Primjeri prikaza aktivnih klasa/objekata

Narudžba

ID : stringjeUnesena : boolestatus : statusNarudžbe

: Narudžba

ID = 1234jeUnesena = Truestatus : uObradi


• Označavanje aktivnih klasa i objekata ugrađenim stereotipima UML‐a – za procese i niti

Stereotipi procesa i niti

<<process>>Klasa

<<thread>>Objekt : Klasa

atributi

metode


Paket plana izvedbe s dijagramima aktivnosti

• Dijagrami aktivnosti prikazuju detalje izvedbe sustava te se stavljaju u paket plana izvedbe

Plan izvedba narudžbe

Međudjelovanje kod dohvata knjiga

Narudžba


izračunatiCijenuOtpreme()dohvatitiKnjige()

Suradnja kod dohvata knjiga

Obrada aktivnosti naručivanja


PRAĆENJE ŽIVOTA ELEMENATA


Događaji

• Promatra se unutarnji rad objekata– kroz što prolazi objekt za vrijeme života unutar sustava

• Događaj predstavlja– pojavu od značaja za objekt


Podjela događaja• Signal

– asinkroni način komunikacije između objekata• Događaj poziva (event call)

– sinkroni način komunikacije između• objekta koji poziva metodu drugog objekta• objekta koji poziva vlastitu metodu• Jednakog učinka kao i poziv akcije

• Vremenski događaj (time event)– do njega dolazi poslije naznačenog proteka vremena

• izražava se pomoću riječi ‘poslije’ iz ako je slijedi oznaka vremena– npr. poslije 5 sekundi ili poslije 15 minuta (15 minuta poslije pristiska tipke ili miša)

• Događaj promjene (change event)– događaj koji se javlja nakon ispunjenja postavljenog uvjeta

• izražava se pomoću riječi ‘kada’ iz ako je slijedi Boole‐ov izraz– npr. kada je ponoć ili kada je najveći broj ponavljanja = 100

• Odziv objekta na djelomično događaj zavisi i o stanju u kojem se objekt nalazi u trenutku pojave događaja


Stanja, prijelazi i uvjeti čuvanja

• Objekt se može nalaziti u raznim uvjetima i može prelaziti iz jednog uvjeta u drugi

• Stanje– je uvjet u kojem se, u svom životnom vijeku, objekt nalazi određeno konačno vrijeme

• U pojedinom stanju objekt može– biti aktivan– čekati na pojavu događaja– ispunjavati jedan ili više uvjeta


Označavanje i primjeri stanja objekta

• Pravokutnik zaobljenih vrhova

• Narudžba u stanju unosa– ostvaruje se aktivnost s drugim objektom

• objektima koji pripadaju obračunskom dijelu sustava

• Stanje otpreme– stanje u kojem je objekt ispunio postavljene uvjete

Stanje

Dohvaćanje knjiga OtpremaUnos


Prijelazi ...

• Prijelaz– prolaženje objekta iz jednog (izvornog) stanja u drugo (odredišno) stanje

• započinje uvjetno kada se pojavi događaj od značaja za objekt (događaj ‘okida’ prijelaz)

• započinje bezuvjetno kada je događaj spreman za prolaženje u sljedeće stanje (prijelaz ‘bez okidanja’)

– budući je završila aktivnost pridružena izvornom stanju

Stanje 1 Stanje 2događaj

Stanje 1 Stanje 2

Označavanje uvjetnog prijelaza Označavanje bezuvjetnog prijelaza241Analiza i modeliranje prometnih sustava ‐ HG ‐ FPZ 2009‐2010

Prijelazi

• Uvjetnom prijelazu može biti pridružena i akcija– ako nema zaštitnih uvjeta

• akcija se provodi bezuvjetno prije nego što objekt uđe u odredišno stanje

• Valstiti prijelaz– prijelaz kod kojeg su izvorno i odredišno stanje jednaki

Stanje 1 Stanje 2događaj/akcija

Stanje


Primjeri prijelaza

• Prijelaz iz pakiranja u otpremu je bezuvjetan• Prijelaz iz otpreme u otpremljeno se izvodi

– pojavom događaja potvrdaOtpreme• objekt narudžbe bilježi promjenu stanja akcijom poziva metode

• Stanje dohvaćanja knjiga ima vlastiti prijelaz

Pakiranje Otprema

Otprema Otpremljeno

potvrdaOtpreme /postavitiOznakuPotvrde()

Dohvaćanje knjiga


Čuvani uvjeti

• Čuvani uvjet– Boole‐ov izraz koji prije početka prijelaza mora biti ispunjen

• Uvjet se zapisuje unutar uglatih zagrada strelice– ako je uvjet pridružen događaju, koristi se oblik

nazivDogađaja [čuvani uvjet]• ako je ishod razvoja Boole‐ovog izraza laž, objekt zanemaruje događaj i ne mijenja stanje

– ako je uz uvjet događaju pridružena i akcija, koristi se obliknazivDogađaja [čuvani uvjet] / akcija

– ako je ishod razvoja Boole‐ovog izraza laž, objekt zanemaruje događaj i ne mijenja stanje

– ako je uvjet pridružen vlastitom prijelazu, koristi se oblik[čuvani uvjet]


Primjeri čuvanih uvjeta

• Prijelaz između Pakiranja i Otpreme se izvodi kada se pojavi događaj paketSpreman i kada se ispuni uvjet da je pridružena Narudžba unesena u glavnu knjigu

• Objekt narudžbe ostaje u stanju Dohvaćanja knjiga sve dok Narudžba ne utvrdi da su dohvaćene sve knjige koje je tražio kupac

Pakiranje Otprema

paketSpreman[unesenGlavnaknjiga]

Dohvaćanje knjiga

[sveKnjigeNisuDohvaćene]


Dijagrami stanja

• Dijagram stanja promatranog objekta je skup– stanja objekta u njegovom životnom vijeku

– događaja na koje objekt daje odziv

– odziva objekta na događaje

– prijelaza između stanja objekta

• Dijagram stanja prikazuje– stanje objekta i prijelaze između stanja


Primjer dijagrama stanja

• Početno i završno stanje– početno stanje u dijagramu– završno stanje u dijagramu

• Dijagram stanja bez završnog stanja – objekt trajno živi


Stanja i prijelazi ...

• Stanje u dijagramu stanja može sadržavati– ulaznu akciju (entry action)

• akcija koju objekt uvijek izvodi po ulasku u stanje prijelazom ili vlastitim prijelazom

• označava se kao ulaz / nazivAkcije

– izlaznu akciju (exit action)• akcija koju objekt uvijek izvodi pri izlasku iz stanja prijelazom ili vlastitim prijelazom

• označava se kao izlaz / nazivAkcije


Stanja i prijelazi ...

– često puta objekt u pojedinom stanju čeka

– aktivnost koju objekt izvodi u stanju prikazuje se kao radi / nazivAktivnosti

• aktivnost se može prekinuti što znači da se pojavom događaja izvođenje aktivnosti zaustavlja i objekt reagira na događaj

– unutarnji prijelaz (internal transition)• objekt poslužuje događaj izvodeći akcije

– pri tome ostaje u zatečenom stanju nazivDogađaja / nazivAkcije

• kod izvođenja unutarnjeg prijelaza objekt ne izvodi ulaznu ili izlaznu akciju

– u slučaju vlastitog prijelaza izvodi se izlazna, a onda ulazna akcija


Stanja i prijelazi

– odgođeni događaj (deferred event)• pojava događaja od značaja za objekt, ali čije posluživanje objekt odgađa dok ne postigne drugo stanje nazivDogađaja / odgođeno

• odgođeni događaji se smještaju u red čekanja– kada objekt promjeni stanje provjerava postojanje događaja u redu čekanja i ako događaji postoje na njih reagira


Spregnuta stanja

• Do sada razmatrana jednostavna stanja

• U nastavku se razmatraju složena stanja– stanja koja imaju višestruko umetnuta (ugniježđena) stanja, tzv. podstanja

• Podjela složenih stanja – uzastopno podstanje (sequential substate)

– povijesno stanje (history state)

– istodobno podstanje (concurrent substate)


Uzastopna podstanja

• Uzastopna podstanja– pod stanje kada se objekt nalazi u složenom stanju i istovemeno samo u jednom od podstanja složenog stanja

– postoje prijelazi između pod stanja kao što postoje prijelazi između stanja


Označavanje složenog stanja

• Složeno stanje s uzastopnim pod stanjima

Stanje

ulaz / akcijaizlaz / akcijaradi / aktivnostdogađaj / akcijadogađaj / odgodi


Primjer uzastopnih podstanja

• Ulaskom u stanje Dohvaćanja knjiga objekt Narudžba ulazi u pod stanje prikupljanja knjiga iz skladišta

– ako se u skladištu nalaze sve naručene knjige napušta se pod stanje Prikupljanje knjiga iz skladišta i stanje Dohvaćanja knjiga i ulazi u stanje pakiranja

– ako se u skladištu ne nalaze naručene knjige ulazi se u stanje Čekanje dodatno naručenih knjiga, gdje se ostaje dok dodatno naručene knjige iz drugog skladišta ne stignu

• objekt ulazi u stanje Sakupljanje dodatno naručenih knjiga i nakon toga napušta to podstanje i stanje Dohvaćanje knjiga i ulazi u stanje Pakiranje

– nezavisno u kojem se stanju objekt nalazi kod napuštanja stanja Dohvaćanje knjiga, prije izlaza se izvodi akcija unosuGkavnuKnjigu

Dohvaćanje knjiga

izlaz / unosuGlavnuKnjigu


Napomene o podstanjima

• Pod stanje unutar složenog stanja može imati sve što ima i redovito stanje– ulazne i izlazne akcije, aktivnosti i odgođene događaje

• Izvorno stanje izvan složenog stanja kao odredišno stanje može imati– cjelokupno složeno stanje ili

– bilo koje pod stanje složenog stanja

• Pprijelaz može izaći iz podstanja i napustiti složeno stanje bez prolaza kroz ostala pod stanja


Povijesno stanje

• Pretpostavlja se da kada objekt prelazi u složeno stanje početak izvođenja je od početnog podstanja

• U povijesnom stanju je moguće zapamtiti posljednje podstanje u kojem se je objekt nalazio prije napuštanja složenog stanja– događaj može prekinuti aktivnosti objekta, a poslije posluživanja događaja objekt nastavlja izvođenje od mjesta prekida


• Objekt narudžba je u stanju Dohvaćanja knjiga– pojavljuje se događaj upita

• zaustavlja se izvođenje tekuće aktivnosti i objekt se postavlja u stanje Provjera statusa– završetkom aktivnosti u stanju Provjera statusa sustav vraća Narudžbu u stanje Dohvaćanje knjiga i pod

stanje u kojem se Narudžba nalazila kod pojave prekida od kuda se nastavlja izvođenje

Primjer povijesnog stanja

Dohvaćanje knjiga

izlaz / unosuGlavnuKnjigu

Provjera statusa

upit

H * = povijesno stanje


Istodobna podstanja

• Istodobna pod stanja– dva ili više pod stanja složenog stanja u kojima se istovremeno nalazi objekt

– skupine podstanja predstavljaju paralelni način izvođenja– kod ulaza u složeno stanje s istodobnim pod stanjima objekt ulazi u početna stanja svake skupine podstanja

• paralelne tijekove je moguće ponovo sinkronizirati korištenjem konačnog stanja svakog pojedinog paralelnog skupa istodobnih pod stanja

– prijelazi u i iz složenog stanja s istodobnim pod stanjima se izvode kao i kod složenog stanja s uzastopnim pod stanjima

– moguće je i korištenje povijesnog stanja


Prikaz istodobnih stanja

• Kada Narudžba uđe u stanje Otpreme – ulazi istovremeno u podstanja Ispunjavanje otpremnice i Bilježenje

završnog zbroja u glavnu knjigu– izvođenje se nastavlja paralelno, nema zavisnosti između fizičkih i

financijskih aktivnosti – kada narudžba dostigne konačna stanja obada tijeka napušta stanje

Otprema

Otprema

Fizička

Financijska


Dijagrami stanja i paketi

• Budući se dijagrami stanja odnose na detaljniji prikaz ponašanja sustava smještaju se u izvedbeni paket

Plan izvedbe narudžbe

Međudjelovanje kod dohvata knjiga

Narudžba


izračunatiCijenuOtpreme()dohvatitiKnjige()

Suradnja kod dohvata knjiga

Obrada aktivnosti naručivanja

Stanje narudžbe


PRIKAZ ZAJEDNIČKOG RADA SKUPINE ELEMENATA


Suradnja elemenata ...

• Promatra se suradnja klasa, sučelja i ostalih elemenata koji zajedničkim radom ostvaruju određeno ponašanje sustava

• Suradnja se označava crtkanom elipsom

Promjenanarudžbe

Računanje cijene

otpreme



• Suradnja sastavljena od strukture i ponašanja– struktura suradnje slična odnosima među klasama, npr. pridruživanja i zavisnosti, u dijagramu klasa

• suradnja za razliku od dijagrama klasa, koji povezuje klase i sučelja iste razine, povezuje elemente različitih razina

– dijagrami suradnje i dijagrami međudjelovanja obuhvaćaju suradnju s gledišta ponašanja

• Ostvarenje (realization) suradnje– povezanost suradnje i slučaja uporabe ili operacije– pomak od apstrakcija više razine prema fizičkoj razini



• Dijagram suradnje predstavlja i dijagram analize– prema ujedinjenom procesu

• dijagram analize prikazuje ostvarenje slučaja uporabe objektima izvedenim analizom sustava

• Označavanje ostvarenja– crtkana crta od oznake suradnje do elementa koji se ostvaruje i trokuta na vrhu crte koji završava na elementu koji se ostvaruje

Suradnja

Slučaj uporabe

Klasa

atributi

operacija 1operacija 2

Suradnja


Označavanje i primjer ostvarenja

• Prikaz suradnje na primjerima koji za ostvarenje zahtijevaju više klasa– promjena narudžbe– računanje cijene otpreme

Promjena narudžbe

Promijeniti narudžbu

Narudžba


izračunatiCijenuOtpreme()

Računanje cijene otprema


Predlošci, mehanizmi i okviri

• Elementi na razini apstrakcije iznad razine suradnje– predlošci, uzorci (patterns)

– mehanizmi (mechanisms)

– okviri (frames)


Predlošci

• Predložak– rješenja problema zajedničkog različitim problemskim područjima

• predlošci analize (analysis patterns)– npr. predložak Opažanje, koristi se kod mjerenja vrijednosti

nenumeričkih, kvalitativnih atributa• predlošci poslovanja (business pattern)

– npr. predložak Zaposlenje, opisuje ugovor između poslodavca i zaposlenika

• predlošci ustroja (organizational patterns)– npr. predlošci stalnog usavršavanja

• predlošci procesa (process patterns)– npr. Vrijeme do kupca, skraćenje vremena ispunjavanja narudžbe

• predlošci plana izvedbe (design pattern)• predlošci arhitekture (framework)


Mehanizmi

• Predložak plana izvedbe– u projektu razvoja programske podrške koristi se u fazi planiranja izvedbe sustava

– razumljiv i višestruko korišten predložak

• Mehanizam– predložak plana izvedbe koji se primjenjuje na skupine klasa– poprima dva oblika

• jednostavna suradnja• parametrizirana suradnja

– za razliku od klase obrasca, gdje ulogu formalnih parametara imaju atributi ili tipovi podataka, ovdje tu ulogu ima parametrizirana suradnja


Označavanje parametrizirane suradnje

• Formalni parametri predloška se prikazuju u pravokutniku u gornjem desnom kutu elipse koja označava suradnju

Suradnja

Uloga 1Uloga 2Uloga 3

Klasa 1

Klasa 2 Klasa 3

Uloga 1

Uloga 2

Uloga 3


Predložak plana izvedbe

• Predložak plana izvedbe: Zastupnik (proxy)– koristi se u izvedbi sustava kada se strogo razdvajaju sučelja i izvršenja

– međudjelovanje korisnika i sustava se odvija preko sučelja

– stvarno međudjelovanje se odvija preko zastupnika


Zastupnik

• U modelu knjižare na Internetu– Korisnik je Kupac– Korisnik je u vezi narudžbe sa sustavom u međudjelovanju preko Sučelja narudžbe koje je opće

namjene– Korisnik radi preko Zastupnika narudžbe, budući je stvarna narudžba najčešće raspodijeljena na

• razne klase i • različite dijelove sklopovske opreme

Zastupnik

KupacPredmetPraviPredmetZastupnik

Korisnik

Sučelje narudžbe

Narudžba

Kupac

PraviPredmet

ZastupnikPredmet

Zastupnik narudžbe


Strukturalni prikaz zastupnika

• Dodana je operacija promjeni slučaja uporabe Promijeniti narudžbu– operacija je određena kao apstraktna operacija klase Sučelje narudžbe

• budući Zastupnik narudžbe i Narudžba, koji nasljeđuju operaciju, stvarno određuju kako će se operacija izvesti

– Zastupnik narudžbe poziva operaciju promjeni u klasi Narudžba– uloga pravaNarudžba između Zastupnika narudžbe i Narudžbe upotpunjuje statički prikaz

Sučelje narudžbe

promjeni()

Korisnik

Narudžba

promjeni()

Zastupnik narudžbe

promjeni()

pravaNarudžba


• Korisnik preko Sučelja narudžbe provodi slučaj uporabe Promijeniti narudžbu– Kada je korisnik spreman pokrenuti promjenu

• Sučelje narudžbe poziva operaciju promjeni odgovarajućeg objekta Zastupnika narudžbe– koji poziva operaciju promjeni objekta Narudžba

• kada Narudžba završi svoju promjenu nadzor izvođenja se opet predaje Korisniku

• Izvođenje operacije promjene u Narudžbi moguće izvesti bez promjene Sučelja narudžbe

Dinamički prikaz zastupnika


Okviri

• Okvir – predložak arhitekture

• osigurava obrazac za proširenje aplikacije

– opsegom mala arhitektura koja sadrži mehanizme– može uključivati

• jednostavne suradnje• parametrizirane suradnje• ili oboje

– cjelokupni okvir sustava tvori sveukupnu arhitekturu sustava


Predložak arhitekture

• Predložak arhitekture: Model‐Prikaz‐Upravljač (Model‐View‐Controller MVC)– dolazi iz programskog jezika Smalltalk– korištenje okvira kod razdvajanja osnovnih objekata modela (model) od njihovog prikaza (prikaz) i elemenata koji ih usklađuju (upravljač)

– označavanje blisko označavanju kod analize• model predstavlja objekte zasebnih jedinki• prikaz predstavlja rubne objekte• upravljač predstavlja upravljačke objekte


Prikaz okvira MVC

• Okvir se prikazuje stereotipom paketa suradnje

• Baza obračunskih podataka, koja trajno čuva pohranjene podatke, se nalazi na razini modela

• Korisničko sučelje se nalazi na razini pogleda• Obrada narudžbe i Skladište se nalaze na razini upravljanja

Korisničko sučelje

Obrada narudžbe

Baza podataka

Skladište

<<framework>>ModelViewController


Sustavi i podsustavi

• Sustav se prikazuje stereotipom paketa koji sadrži sve proizvedene modele

• Podsustav predstavlja skupinu srodnih elemenata koji čine dio sustava– sadrži skupine elemenata koji se nalaze unutar različitih modela

• element može biti dio samo jednog podsustava

– omogućava projektnom timu jednostavan način podjele dijelova sustava

• Paket sustava posjeduje sve podsustave


Prikaz sustava i podsustava

• Sustav je sastavljen od podsustava– sastavljanje je jaki oblik združivanja

• podsustav ne može živjeti osim kao dio sustava


OPIS IZGRADNJE ELEMENATA


Komponente ...

• Sastavni dio, komponenta (component)– fizički i zamjenjivi dio sustava koji prilagođuje i ostvaruje skup sučelja

– jedan od dva mehanizma grupiranja, drugi je paket• paket predstavlja pojmovno grupiranje elemenata modela• komponenta predstavlja fizičko grupiranje elemenata modela

– sučelja komponenti su usporediva sučeljima pridruženim klasama

• komponenta realizira sučelja kao i klasa


Komponente ...

• Razlike između komponenata i klasa– komponenta je fizički element smješten na dijelu sklopovske opreme

• klasa je pojmovni element

– preko sučelja je načelno moguće pristupiti samo operacijama komponente, a izravno nikako ne i atributima komponente

• klasa može izložiti svoje atribute nižim klasama (zaštićena vidljivost atributa) kao i svim vanjskim objektima (javna vidljivost atributa)


• Komponenta se označava većim pravokutnikom s dva manja pravokutnika na lijevoj strani velikoga pravokutnika

• Komponentu je moguće prikazati i simbolom

Označavanje komponente


Označavanje odnosa komponente i sučelja

• Kao i kod označavanja klasa i sučelja postoje dva načina označavanja odnosa između komponenata i sučelja

– sučelje prikazano kao krug povezan na komponentu crtom

– sučelje prikazano stereotipom klase, a povezanost ostvarena crtkanom strelicom od komponente, a čiji vrh oblika trokuta završava na sučelju


Prikaz komponente i njezinog sučelja

• Komponenta Obračuna ostvaruje sučelje glavne knjige– komponente koje žele upisati podatke u glavnu knjigu, koja je dio Obračuna, to mogu učiniti jedino preko sučelja


Podjela komponenata

• Komponenta rasporeda (deployment component)– izvršni dio sustava

• postoje dva stereotipa– <<executable>> (izvršni) označava binarnu (EXE) datoteku– <<library>> (knjižnica) označava biblioteku statičnih ili dinamičnih objekata, npr.

biblioteka dinamičkog povezivanja objekata (dynamic link library DLL)

• Komponenta radnog proizvoda (work product library) – komponenta koja je dio sustava, ali nije izvršna– postoje tri stereotipa

• <<table>> (tablica) za tablicu baze podataka• <<file>> (datoteka) za datoteku koja sadrži izvorni kôd• <<document>> za dokument

• Komponenta izvršenja (executable component)– nastaje kao rezultat rada sustava– primjer je objekt COM+ kojeg za vrijeme izvođenja stvara sustav kao

instancu DLL‐a


Prikaz komponenata simbolima

• GKRačuna.tbl – tablica pohranjenih računa glavne knjige• GK.exe – izvršni program glavne knjige• GKRačuna.h – datoteka izvornog programa pridruženog tablici

GKRačuna.tbl

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

GKRačuna.h

GK.exe


http://jobs.utah.gov/ui/es/contrib/efileing/disk-35.gif

Dijagram komponenata

• Dijagram komponenata – označava zbirku srodnih komponenata

– kao i dijagram klasa samo umjesto klasa prikazuje komponente i njihove odnosa koji su jednaki odnosima kod dijagrama klasa

– načelno je ovdje naglasak na • sučeljima koja komponente izlažu i koriste

• zavisnostima između različitih komponenata– strelice zavisnosti ukazuju kako pojedina komponenta koristi sučelja koje je izložila druga komponenta


Prikaz dijagrama komponenata ...

• Prikazane ključne komponente pridružene postupku pretrage od strane korisnika– korisnik prolazi od početne stranice do stranice pretrage– zadaje kriterije pretraživanja i pokreće pretraživanje– daljnji postupak pretrage preuzima program koji zavisno o

postavljenim kriterijima pretražuje tablicu knjiga, autora ili obadvije

Standardno označavanje


Prikaz dijagrama komponenata

• Tablice su s bazom podataka povezane relacijom sastavljanja– ako baza podataka prestane postojati, prestaju postojati i tablice

Označavanje simbolima

GKRačuna.tblUpisa.tbl UpisnaPravila.tbl

Obračun.db


Čvorovi

• Čvor– dio računske sklopovske opreme

– načelno ima memoriju i sposobnost obrade podataka

– fizički raspored komponenata

– komponente žive na čvorovima

– čvorovi na kojima su smještene izvršne komponente izvode te komponente

– označavanje kockom


Prikaz čvorova

• U dijagramu komponenata čvor na koji se postavlja komponenta može se označiti ugrađenom vrijednošću oznake lokacija (location)– npr. {lokacija = Poslužitelj obračuna}

Način prikaza komponenata postavljenih na čvoru


Dijagrami rasporeda

• Dijagram rasporeda– prikazuje zbirku čvorova, njihovih zavisnosti i udruživanja

– udruživanje između čvorova označava njihovu fizičku povezanost

– veze su označene stereotipima postavlja ih projektant• npr. <<RS232>> ili <<Ethernet>> označavaju način veze


Primjer dijagrama rasporeda

• Dijagram rasporeda pokazuje da fizički elementi sustava Internet knjižare ostvaruju model korisnik/poslužitelj (client/server) pri čemu instance web preglednika predstavljaju korisnike

: prijenosno računalo: prijenosno računalo

: poslužitelj obračuna

: poslužitelj skladišta

: poslužitelj web aplikacije

: Internet

: web preglednik

: web preglednik

: web preglednik


Fizički dijagrami i paketi

• Fizički dijagram– uključuje dijagram komponenata i dijagram rasporeda

• U ujedinjenom procesu razvoja sustava– model ostvarenja sadrži dijagrame komponenata

– model ostvarenja sadrži dijagrame rasporeda


Primjeri fizičkih dijagrama i paketa

Ostvarenje

Komponenta pretrage Komponenta obračuna

Komponenta skladišta

Raspored

Raspored poslužitelja web aplikacije

Raspored poslužitelja obračuna

Raspored poslužitelja skladišta


PRIMJERI MODELIRANJA SUSTAVA


Documents

ANALIZA I MODELIRANJE PROMETNIH SUSTAVA · • Informacije o predmetu se nalaze na web stranicama e‐student.fpz.hr Analiza i modeliranje prometnih sustava ‐HG ‐FPZ 2009‐2010