UML labosi

dijagrami slučajeva korištenja, dijagrami komponenti i dijagrami

razmještaja

Use case dijagram• Koristimo termin: use case dijagram (može i samo

use case ili kratko: UC)– engl. use case diagram

• Hrvatski termini:– Dijagram korištenja sustava– Dijagram obrazaca uporabe– Dijagram slučaja uporabe

• Dva značenja riječi use case dijagram:– Pojedini dio funkcionalnosti sustava

• (pojedini use case)- grafički oblik:

• Više funkcionalnosti + aktori:

Use case dijagram

• Use case dijagram opisuje ponašanje sustava iz perspektive vanjskog korisnika, tj.

Tko može činiti što u sustavu, ili

Što sistem (podsistem, klasa, interface) radi a ne kako radi

• Pritom se na sustav gleda kao na crnu kutiju određene razine apstrakcije

Use case namjena

• Slučajevi korištenja (eng. use cases)

predstavljaju tehniku modeliranja koja

se koristi za opisivanje što bi to novi

sistem trebao da radi ili što postojeći

sistem radi, sa aspekta interakcije između sistema i korisnika.

Use case dijagram

• Modeliraju se zahtjevi korisnika i scenariji ispitivanja sustava

• Ne koristi se nijedan implementacijsko-specifičan jezik i uvijek se izrađuje na određenoj razini detalja, razine se ne miješaju na istom dijagramu

• Služe za opis funkcionalnih zahtjeva projekta i to:• Svih sudionika, bili oni inicijatori (aktivni sudionici) ili obični

sudionici (pasivni sudionici)• Svih načina rada sustava - scenariji

• Prema potrebi, crta se više use case dijagrama da se obuhvate svi dijelovi sustava

Business system

Use case

Use case

Use case

Actor

Actor

Actor

Communication

As a rule, actors onthe left side representpeople, while actorson the right siderepresent systems.

Use case dijagram -aktori

• Korisnici sustava se u dijagramu nazivaju aktori ili sudionici i mogu biti:

– ljudi (klijenti sustava),

– vanjski računalni sustavi, unutarnji računalni sustavi i sl.

• Aktori su u use caseu prikazani svojom ulogom (engl. role):

Use case opis

Ponašanje slučaja korištenja se opisuje tokom dogaĎaja:

1. kada slučaj korištenja počinje i kada završava2. kada je slučaj korištenja u interakciji sa sudionicima3. kada se razmenjuju objekti/podaci…4. postoje primarni (osnovni) i alternativni tokovi dogaĎaja

Tok dogaĎaja se može opisati/dokumentirati na više načina:

– neformalan strukturirani tekst

– formalni strukturirani tekst (sa pred- i post-uslovima)

– Pseudokod

– dijagramima interakcije

– (jedan za primarni i dodatni za alternativne tokove)

Use case dijagram

• Hijerarhijska organizacija:• Dozvoljeno slaganje dijagrama u pakete (engl. packages) –

nije podržano ArgoUML-om i Visio-om• Određivanje odnosa među dijagramima (engl. relations) –

podržano ArgoUML-om, Visio(?)

Povezanost slučajeva upotrebe

• Odnosi/relacija među use case dijagramima:• association (pridruživanje) – podržan u ArgoUML-u• extend (proširivanje mogudnosti) – podržan...• include (uključivanje podaktivnosti) – podržan…• generalization (poopdenje, generalizacija) – podržan• Ostali: requires, resembles, equivalent (nede se obrađivati)

<<include>>

• Veza od baznog use casea prema uključenom use caseu

• Bazni use case NUŽNO obavlja cijeli uključeni use case

• Primjer ispravne uporabe odnosa include:

<<extend>>

• Opcionalno, specifično proširenje baznog use casea s nekom funkcionalnošdu

• Veza od proširujudeg use casea prema baznom use caseu (proširenom)

• Zadaje se uvjet proširenja na relaciji extend kao i točka proširenja (extension point) na baznom use caseu

«include» vs. «extend»

• Use Case X includes Use Case Y:

– X has a multi-step subtask Y. In the course of doing X or a subtask of X, Y will always be completed.

• Use Case X extends Use Case Y:

– Y performs a sub-task and X is a similar but more specialized way of accomplishing that subtask (e.g. closing the door is a sub-task of Y; X provides a means for closing a blocked door with a few extra steps). X only happens in an exception situation. Y can complete without X ever happening

Točka proširenja u ArgoUML-u

• Da bi se vidjela točka proširenja, potrebno je na određenom use caseu dolje pod “Presentation”, pa na “Display” čekirati kudicu “Extension points”

• Naziv točke proširenja bit de tada također vidljiv na dijagramu

Točka proširenja u Visio-u

• Da bi se vidjela točka proširenja, potrebno je …

Generalization– Generalizacija prikazuje hijerarhijski odnos između više opdenitog

use casea i više detaljnog use casea, a moguda je i među aktorima

– Obično se koristi kad se ne zna ništa detaljnije o međusobnom odnosu osim toga da je jedan use case specijalan slučaj drugog

– Prikazuje se punom linijom sa trokutastom strelicom

– Preporuča se koristiti extend relaciju kod use caseova kad god je prikladno

Association (pridruživanje)

• Koristi se za komunikaciju između aktora i use casea

• Po defaultu, komunikacija aktor-use case je dvosmjerna

• Aktivni aktori (inicijatori): smjer je od aktora prema use caseu• npr. klijent, administrator

• Pasivni aktori (sudionici) smjer je od use casea prema aktoru• npr. arhiva podataka, pisač

Primjer aktivnih i pasivnih aktora

Višestrukost (multiplicity)

• Određuje broj aktora i use caseova za koje je zadano pridruživanje

• Postoje sljedede mogudnosti (na bilo kojoj strani pridruživanja):

1 - točno jedan (ako ništa ne piše na pridruživanju onda se 1 podrazumijeva)

* - više (nedefinirano koliko mnogo)n - bilo koji točno određen broj, npr. 0, 1, 3, 15n1..n2 - između jednog i drugog broja, npr. 1..3n1.. * - između jednog broja i neodređenog broja, npr.

0..*

1. primjer use case i sekvencijskog dijagrama

• Klijent može zatražiti otvaranje jednog računa, podidi novac s računa te zatražiti zatvaranje računa. Osobni bankar mu ove akcije mora omoguditi ako su dokumenti u redu, a kao dodatnu mogudnost, osobni bankar može podnijeti upravitelju zahtjev za povedanje svoje plade. Dvojica upravitelja razmatraju povišenja plada osobnih bankara i eventualno im podižu pladu. Upravitelj može podidi pladu i drugim zaposlenicima.

• Modelirati otvaranje računa klijenta sekvencijskim dijagramom. Osobnom bankaru su za akciju otvaranja računa potrebni JMBG te ime i prezime klijenta (dostupni na identifikacijskom dokumentu). Klijent treba uplatiti 50 kn za otvaranje računa.

Specifikacija slučaja korištenja

Mogude rješenje

Komentari na primjer

• Baza podataka o klijentima može se dodati kao pasivni aktor

• Mogu biti i dvije baze, jedna s potencijalno opasnim ljudima i jedna s internim klijentima banke

• Zaposlenici se mogu modelirati kao generalizacija osobnog bankara

2. primjer use case i sekvencijskog dijagrama

Modelirati use case dijagramom:

• Brigadir ima ovlasti unaprijediti svakog brigadnog časnika ako je dotični ispunio određene uvjete. Svaki časnik može pregledati stanje svojih podređenih, ili zatražiti odlazak u vojnu mirovinu. Dodatno, svaki brigadni časnik (osim brigadira) može zatražiti unapređenje. Ako časnik odluči otidi u vojnu mirovinu, računalni sustav mu izračunava mirovinu na temelju niza podataka u vojnoj bazi podataka. Brigadir ima ovlasti pregleda čitave vojne baze podataka.

• Modelirati sekvencijskim dijagramom odlazak brigadira u mirovinu. Nakon zahtjeva, brigadni general mu dozvoljava odlazak u mirovinu ako ima prikladnu zamjenu. Brigadiru se u tom slučaju izračunava iznos mirovine, a istovremeno general unaprijeđuje nekog pukovnika u brigadira. Ako nema zamjene, zahtjev za mirovinom se odbija.

Mogude rješenje

Komentari na primjer

• Brigadni general se mogao naknadno uvesti u use case diagram kao aktor koji odobrava vojnu mirovinu

• Druga povratna veza u sekvencijskom dijagramu nije nužna (*!postoji+), ali ju je bolje eksplicitno navesti

Specifikacija Use case-a

• Prikazani predložak za specifikaciju slučaja uporabe sadrži sljedede informacije: 1. ime slučaja uporabe

2. identifikator (ID)

3. kratki opis

4. aktere

5. preduvjete

6. osnovni tijek

7. posljedice

8. alternativne tijekove

Ak.god. 2008/2009 29

2. Specifikacija slučaja korištenja

•u nekoliko linija teksta opisuje ulogu i svrhu slučaja korištenja.Kratki opis

•ukazuje što se postiglo interakcijom sa sudionikomIme

•tekstualni opis onoga što sustav radi •mogu postojati višestruki tokovi događaja, na primjer, osnovni tok i alternativni tokovi.

Tok događaja

•tekstualni opis svih zahtjeve slučajeva korištenja, koji nisu uzeti u obzir kod modela slučajeva korištenja•oni se moraju razmotriti tokom oblikovanja ili implementacije

Specijalni zahtjevi

•definiraju ograničenja na sustav koji uvjetuju pokretanje odnosno završetak slučaja korištenja

Pred-uvjetiPoslije-uvjeti

•koriste prilikom ilustriranja slučaja korištenja•to su razne skice ili prototip korisničkog sučelja

Dodatni dokumenti

Ak.god. 2008/2009 30

2. Specifikacija slučaja korištenja

Prijava kolegija

Ime

Ovaj slučaj korištenja omoguduje studentu prijavljivanje kolegija koje želi slušati u sljededem semestru. Studentu se moraju prikazati svi dostupni kolegiji koje može prijaviti u tom semestru. Svaki kolegij nosi određeni broj bodova. Student mora izabrati one kolegije čiji ukupan broj bodova prelazi njemu zadani prag bodova.

Kratki opis

student prijava kolegija

Ak.god. 2008/2009 31

2. Specifikacija slučaja korištenja

1. Ovaj slučaj korištenja kada student izabere "Prijava kolegija" opciju s glavne web stranice.

2. Sustav daje studentu spisak kolegija koje može prijaviti i spisak ved prijavljenih kolegija.

3. Student može izabrati sljedede opcije:

a. potvrda prijave kolegija za sljededi semestar

b. odustajanje prijave kolegija za sljededi semestar

c. prijavljivanje kolegija

d. odjavljivanje kolegija

4. Ako je student izabrao:

a. potvrdu prijave kolegija, tok se nastavlja u točki 5. osnovnog toka

b. odustajanje prijave kolegija, tok se nastavlja u točki 7. osnovnog toka

c. prijavljivanje kolegija, tok se nastavlja u točki 1.1 alternativnog toka

d. odjavljivanje kolegija, tok se nastavlja u točki 2.1 alternativnog toka

5. Ako ukupan broj bodova prijavljenih ispita ne prelazi prag, tada sustav prikazuje poruku upozorenja i slučaj toka se nastavlja u točki 2 osnovnog toga.

6. Sustav zapisuje informacije o prijavljenim kolegijima za sljededi semestar

7. Završava slučaj korištenja

Osnovni tok

Ak.god. 2008/2009 32

2. Specifikacija slučaja korištenja

1. Prijavljivanje kolegija

1. Student bira kolegije iz spiska dostupnih kolegija i prijavljuje ih

2. Tok se nastavlja u točki 3. osnovnog toka

2. Odjavljivanje kolegija

1. Student bira kolegija iz spiska prijavljenih kolegija i odjavljuje ih

2. Tok se nastavlja u točki 3. osnovnog toka

Alternativni tokovi

1. Zadovoljenje praga

Student ima određeni prag bodova. Ako ukupan broj bodova prijavljenih kolegija manji od praga tada sustav javlja poruku greške. Ako je ukupan broj bodova prijavljenih kolegija prešao prag i ako ima viška prijavljenih kolegija, tada sustav šalje poruku greške.

Specijalni zahtjevi

1. Sudionici

Jedini sudionik ovog slučaja korištenja je student.

Pred-uvjeti

Ak.god. 2008/2009 33

2. Specifikacija slučaja korištenja

Dodatni dokumenti

UML primjer –> e-restoran

• Za e-restoran na osnovu postavljenih zahtjeva naručitelja, prvi problem koji novi sistem mora riješiti je da omogudi naručivanje i pladanje u elektronskom obliku.

• Iz toga dobijemo prvu verziju dijagrama slučaja upotrebe prikazan na slici koja ujedno ilustrira novo uvedene elemente i notaciju aktera, slučaja upotrebe i granica sistema.

UML primjer –> e-restoran

UML primjer –> e-restoran

• Drugi zahtjev koji se postavlja pred sustav je da omogudi naručivanje putem Interneta i dostavu naručene hrane, pri čemu je dostavljač zaposlenik restorana pa se za početak, dok se na sustav gleda sa najvišeg nivoa apstrakcije, i ne predstavlja na dijagramu.

UML primjer –> e-restoran

UML primjer relacije

• <<include>> relacija

UML primjer relacije 2

• <<extend>> relacija

Primjer genaralizacije

Zadatak 1

• Modelirati e-restoran za naručivanje jela. Jela se mogu naručiti u restoranu ili naručiti i dostaviti. Naručioci jela tj. kupci mogu biti gosti restorana ili Internet naručioci.

• Naručivanje jela se izvršava putem sustav azautorizaciju kartica.

• Nacrtati use case dijagram za gore navedeni slučaj.

Rješenje ?

UML

Dijagrami aktivnosti

Ak.god. 2008/2009 44

Specifikacija slučaja korištenja – dijagram aktivnosti

početak i završetak niza aktivnostiPočetno i završno stanje

predstavlja provođenje aktivnosti ili korak unutar radnog toka

Stanje aktivnosti

govori koje stanje aktivnosti slijedi iz trenutnog stanja aktivnosti

Tranzicija

prikazuje paralelne podtokoveSinkronizacijska crta

služi za definiranje uvjetaOdluka

Ak.god. 2008/2009 45

Specifikacija slučaja korištenja –dijagram aktivnosti

Sustav daje spisak prijavljenih

i neprijavljenih kolegija

Potvrda prijave kolegija

[potvrda prijave]

[kraj]

Student nije izabrao

dovoljan broj kolegija

[pogreška]

Prijava kolegijaOdjava kolegija

[prijava kolegija] [odjava kolegija]

[odustajanje]

Faza 3

Fizičko modeliranje

•Detaljno projektiranje▫Dijagrami klasa▫Model za projektiranje b.p.▫DDL skriptovi▫Baze podataka▫Dijagrami komponenti▫Dijagrami raspoređivanja

Logičko modeliranje

•Definiranje zahteva▫modeli korisn. funkcija

sistema▫Opisi korisn. funkcija sistema

•Analiza i preliminarno projektiranje▫Dijagrami klasa▫Dijagrami sekvenci▫Dijagrami stanja

Konceptualno modeliranje

•Modeliranje poslovnihkorisničkih funkcija:▫Modeli use case▫Dijagrami aktivnosti

•Modeliranje poslovnih objekata▫Modeli poslovnih objekata▫Dijagrami sekvenci

Fizičko modeliranje -realiziranje fizičkih aspekata sustava

• Projektanti baze podataka se bave:– Veličinom baze podataka– Smeštajem baze podataka

• Hardverski• Softverski

– Particioniranjem podataka– Specifičnim svojstvima izabranog DBMSa– Komuniciranjem aplikacije sa bazom podataka

• Dijagrami fizičke arhitekture– Fokus na dijagram komponenti i dijagram raspoređenosti

• Dijagram komponenti:– Komponenta je jedinica koja se koristi u generiranju koda (prostori tablica, baze

podataka, sheme)

• Dijagram razmještaja ili raspoređenosti:– Razmeštaj baze podataka tj. hardware sustava– U dijagramu raspoređenosti postoje dve vrste elemenata:

• Uređaj – predstavlja neki hardver koji nema računarskih sposobnosti, kao disk• Procesor – predstavlja neki hardver koji može da izračunava ili može da bude i sam server

Dijagram komponenti (engl. Component diagrams)

• Dijagrami komponenata predstavljaju statički pogled na sustav.

• Opisuju organizaciju i meĎuovisnost (fizičku strukturu) izmeĎu implementacijskih komponenata programske potpore.

• Dijagrami komponenata dio su specifikacije arhitekture programske potpore.

• Dijagrame komponenata oblikuju arhitekti programske potpore i programeri.

• Vrste komponenata:– Izvorni kod

– Binarni (objektni) kod

– Statičke ili dinamičke knjižnice programskih komponenata

– Izvršne (aka “also known as” exe) komponente programske potpore.

– Tablice

– Druge datoteke

– Baze podataka

49

Dijagrami komponenata

ovisnost

izvršna datoteka

Modeli, pogledi i dijagrami

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

ActivityDiagrams

Models

Dinamički poglediDijagrami interakcija

Statički pogledi

Komunikacijski

Dijagram razmještaja ( engl. Deployment diagrams)

• Dijagrami razmještaja prikazuju topologiju sustava i usredotočeni su na odnos sklopovskih i programskih dijelova.

• Dijagrami razmještaja pripadaju statičkom pogledu na sustav.

• Posebice su značajni u raspodijeljenim sustavima gdje je naročito važno prikazati razmještaj komponenata.

• Sklopovske komponente sadrže:– Čvorove (engl. nodes), koji pokazuju sklopovske naprave.

– Vezice (engl. connections), koje pokazuju kako čvorovi komuniciraju.

• Programske komponente– Predstavljaju implementacijske module

– Ovisnosti opisuju odnose izmeĎu tih komponenata

• Vezice i ovisnosti označuju se na dijagramu razmještaja različito.

53

Dijagrami razmještaja sklopovskih elemenata - primjer

čvorvezica

54

Dijagrami komponenata – sklopovlje i programske komponente

ovisnost

vezicabaza podataka

sučelje komponente

čvor

programska komponenta sklopovska komponenta: PC-a

Primjer: kupnja nekretnine

sklopovska komponenta: Real Estate Server

Dijagram razmještaja ( engl. Deployment diagrams)

WebShop - deployment diagram

Salesperson's laptop

Package 1

Client

Module

WebSales Internet Server

Package 2.1

Sales

handler

Package 2.2

Database

interface

Internet

Accountingmainframe

Inventorymainframe

Corporate Network/SQL

WebShop aplikacija Dijagram klasa podijeljena na 3 nivoa

Salesperson SalesOrder

CustInfo Accounting

CustInfo1

ItemOrdered Inventory

1 1..*Enters

CustInfoMulti

*

1..*

*

1

Accesses

Accesses

Has

Includes

Client tier Internet server tier Database andlegacy tier

Literatura

• Branko Žitko – materijali iz predmeta “Programsko inženjerstvo” – “Od slučaja korištenja do klasa”, 2008/2009

• Alan Jovid - materijali iz predmeta “Oblikovanje programske potpore - Argo UML”, 2009 / 2010

• Mario Kušek – materijali iz predmeta “Informacija , logika i jezici – UML “, travanj 2007.

• Ostalo: