Labos UML Uvod Dijagrami Klasa

UML - labosi

Osnove UML-a

Dijagrami klasa

Prije UML-a

• 1960’s - 70’s– COBOL, FORTRAN, C

– Tehnike strukturne analize i oblikovanja

• 1980’s - early 1990’s– Smalltalk, Ada, C++, Visual Basic

– Rane generacije OO metoda

• Sredina i kasne 1990– Java

– UML

– Unified Process (RUP)

programiranje

modeliranje

Temelji UML-a• UML je jezik za:

– vizualizaciju

– specifikaciju

– oblikovanje (i konstruiranje)

– dokumentiranje

artefakata programske potpore.

• UML je posebice prikladan za specificiranje objektno

usmjerene arhitekture programske potpore.

• Dijelovi UML-a pogodni su u specificiranju i drugih

arhitektura.

• Uvođenje arhitekture programske potpore : to je

struktura ili strukture sustava koji sadrži elemente,

njihova izvana vidljiva obilježja i odnose između njih.

Prednosti UML-a

• Otvoren standard.

• Podupire cijeli životni ciklus oblikovanja

programske potpore.

• Podupire različite domene primjene.

• Temeljen je na iskustvu i potrebama

zajednice oblikovatelja i korisnika

programske potpore.

• Podržavaju ga mnogi alati.

Mnogo sudionika, mnogo pogleda

• Arhitekturu programske potpore različito vidi:– Korisnik-kupac– Projekt manager– Inženjer sustava– Osoba koje razvija sustav– Arhitekt– Osoba koja održava sustav (engl. Maintainer)– Drugi dionici

• Višedimenzionalna realnost

• Mnogo sudionika rezultira u

višestrukim pogledima, višestrukim

nacrtima

6 UML 2

Korisnici UML – aSistem-analitičari i krajnji korisnici: specificiraju zahtjevanu strukturu i ponašanje sustava

Voditelji projekata: voĎenje i usmeravanje kadrova i upravljanje resursima

Arhitekti: projektirauju sustav koji zadovoljava zahtjeve

Razvojni inženjeri: transformiraju arhitekturu u izvršni kod

Kontrolori kvaliteta:provjeravaju strukturu i ponašanje sustava

Evidentičari komponenata: kreiraju i vode kataloge komponenti

• Pogledi odgovaraju nekom kontekstu.

• Svi sustavi ne trebaju sve poglede:

– Jedan procesor, nije potreban nacrt razmještaja procesora.

– Jedan proces, nije potreba nacrt razmještaja procesa.

– Vrlo mali programi, nije potreban nacrt implementacije.

• Neki dodatni pogledi:

– Pogled podataka, pogled sigurnosti u sustavu

• Svaki pogled dokumentira se nacrtom – DIJAGRAMOM.

• Više pogleda (dijagrama) u okviru nekog konteksta = MODEL

• Model je apstraktan (reduciran, pojednostavljen, smanjen, ograničen) opis sustava iz određene perspektive.

Kreiranje UML-a

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

public

feedback

Final submission to OMG, Sep „97

First submission to OMG, Jan ´97

UML 1.1

OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners

Meyer

Before and after

conditions

Harel

Statecharts

Gamma, et al

Frameworks and patterns,

HP Fusion

Operation descriptions and

message numbering

Embley

Singleton classes and

high-level view

Wirfs-Brock

Responsibilities

Odell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Sudjelovanje u kreiranju UML-a

Povijesni razvoj UML-a

Fizičko modeliranje

• Detaljno projektiranje

▫Dijagrami klasa

▫Model za projektiranje b.p.

▫DDL skriptovi

▫Baze podataka

▫Dijagrami komponenti

▫Dijagrami rasporeĎivanja

Faze modeliranje - ukratko

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 poslovnih

korisničkih funkcija:

▫Modeli use case

▫Dijagrami aktivnosti

• Modeliranje poslovnih objekata

▫Modeli poslovnih objekata

▫Dijagrami sekvenci

• Modeliranje npr. baze podataka se fokusira uglavnom na opisivanje baze podataka

• Projektiranje baze podataka obuhvaća ukupan proces od definiranje i postavljanja zahtjeva, poslovnih

procesa, logičkih analiza i fizičkih ograničenja do razmeštaja baze podataka

• Npr., u projektiranju baze podataka fizičko modeliranje podataka obuhvaća ne samo modeliranje tablica i kolona,

nego i prostora za tabele, particije, HW i ukupno sastavljanje ukupnog sustava baze podataka

UML vs. Tradicionalno modelovanje

• Tradicionalno modeliranje baze podataka polazi od osnovne teorije da je baza podataka osnova sustava, meĎutim ona ne može da postoji sama za sebe i ima mnogo drugih stvari koje sačinjavaju kompaniju i njene informacije– Bez aplikacija koje zaposlenima otvaraju tu bazu, ne bi bilo

dostupnih podataka

– Bez klijenata i transakcija, ne bi bilo informacija u bazi ...

• UvoĎenje UMLa omogućava se zajednički jezik za sve uključene timove

• UML pruža mogućnost da se jednim jezikom modeluje poslovni sistem, aplikacije, baza podataka i arhitektura sistema

13 UML 2

Unificirani jezik za modeliranje

UML je skup grafičkih notacija zasnovanih na jedinstvenom metamodelu.

Notacija je skup grafičkih elemenata koji se koriste u modelima, tj. grafička

sintaksa jezika za modelovanje.

Metamodel predstavlja dijagram koji definiran koncepte jezika za modeliranje.

Iako je notacija često intuitivna, a ne formalna, vrlo se uspješno koristi u praksi.

Metamodel predstavlja pokušaj da se strože definiran notacija, bez narušavanja njene

korisnosti. Ni notacija ni metamodel se ne moraju strogo primenjivati.

UML se koristi za modeliranje i projektiranje softverskih sustava,

naročito sustava pravljenih primjenom objektno-orijentiranih tehnologija.

Čemu služi

UML?

14 UML 2

Postupci razvoja

Direktni razvoj (forward engineering)

UML dijagram Programski kod

Povratna analiza (reverse engineering)

Programski kod UML dijagram

generiranje

tumačenje

15 UML 2

Načini korištenja UML-a

UML

Izrada projekataIzrada dijagrama

Programski jezik

16 UML 2

Izrada dijagrama

Dijagram opisuju pojedine aspekte sustava korištenjem UML-a kao pomoćnog

sredstva.

Osobine dijagrama:

predstavljaju najčešći način upotrebe UML-a

obično se generiraju neformalno i dinamički, tako da se rade brzo i na tabli

nepotpune su (?)

omogućavaju jednostavno ispitivanje više alternativnih rešenja

mogu se koristiti u dokumentaciji

Skice u direktnom razvoju:

sadrže samo nekoliko značajnih

problema koji će se javiti u kodu

predstavljaju ideje i alternative

predstojećeg posla

vizualiziraju dijelove projekta prije

programiranja

Skice u povratnoj analizi:

objašnjavaju kako radi neki dio

sustava (samo klase o kojima je

važno razgovarati)

17 UML 2

Izrada UML projekata

UML projekti opisuju sustav sveobuhvatno, kako bi se programiranje koje

predstoji svelo uglavnom na mehaničku aktivnost.

Osobine UML projekata:

za izradu projekata koriste se složeni, tzv. CASE alati za računarsko

projektiranje softvera

projekti se moraju dosljedno pratiti i sprovoditi

Direktni razvoj:

Projekti sadrže detaljan opis sustava,

obično do nivoa IF-a - interfejsa

podsustava (dalje se razrada

realizacije se prepušta

programerima), na osnovu koga se

piše kod.

CASE alati omogućavaju crtanje

dijagrama i čuvanje informacija u

memoriji.

Povratna analiza:

Projekti sadrže detaljne informacije o

kodu u obliku papirne ili elektronske

dokumentacije. Mogu prikazati svaki

detalj neke klase u grafičkom obliku

koji programer razumije.

CASE alati čitaju izvorni kod,

tumačenja stavljaju u memoriju i

generiraju dijagrame.

18 UML 2

UML kao programski jezik

.

UML postaje programski jezik u slučaju kada se cijeli sustav modelira UML

dijagramima, a zatim se ti dijagrami primjenom CASE alata neposredno

prevode u izvršni kod. Tada UML postaje izvorni kod, što odgovara

programskom jeziku.

Ovaj način upotrebe UML-a još nije doživjeo potpunu primjenu u praksi .

Djelomično

UML modeliranje

Programski kod

pro

gra

mira

nje

Intenzivno

UML modeliranje

CA

SE

ala

ti

UML modeliranje

cijelog sustavaC

AS

E a

lati

automatizacija

Programski kod Programski kod

Izvorni kod

UML gradbeni blokovi

• U UML-u postoji sedam tipova

strukturalnih stvari. Strukturalne stvari su

imenice u UML modelima. To su najčešće

statički dijelovi modela i oni predstavljaju

elemente koji su ili konceptualni ili fizički.

U UML-u postoji sedam tipova

strukturalnih stvari:

1. UML gradbeni blokovi - Klasa

• Klasa – predstavlja opis skupa objekata koji dijele iste atribute, operacije, relacije i semantiku. Klasa može implementirati jedno ili više sučelja (eng. interface).

• Grafički,klasa je prikazana kao pravokutnik koji obično sadrži ime, atribute i operacije

2. UML gradbeni blokovi - Sučelja

• Sučelje - kolekcija operacija kojaspecificira usluge neke klase ili komponente. Sučelje stogapredstavlja izvana vidljivo ponašanje tog elementa i može predstavljati kompletno ponašanje klase ili komponente ili samo djelomično.

• Sučelje definira skup operacijskihspecifikacija (tj. njihovih potpisa), ali nikada skup njihovih implementacija.

• Grafički, sučelje je predstavljeno krugom zajdeno sa njegovim imenom. Sučelje, prema svojoj namjeni, nikada neće stajatisamo, većće obično biti vezano za odreĎenu klasu ili komponentu kojaga realizira.

3. UML gradbeni blokovi - Suradnja

• Suradnja (eng. collaboration). Ono definira interakciju te je skup uloga (eng. roles) i ostalih elemenata koji zajednički rade i pružaju nekakvo kooperativno ponašanje koje je veće nego suma svih elemenata zajedno. Stoga, suradnja ima strukturalnu dimenziju kao i dimenziju ponašanja. Neka klasa može participirati u više suradnji odjednom i suradnje time reprezentiraju implementaciju predložaka (eng. patterns) koji čine sustav.

• Grafički, suradnja je predstavljena elipsom sa isprekidanim linijama i obično se u njoj nalazi njeno ime

4. UML gradbeni blokovi – Slučaj

korištenja• Slučaj korištenja (eng.

Use case). On opisuje skup slijednih dogaĎaja koje sustav izvodi kako bi dobio neki rezultat i koristi se za strukturiranje stvari sa ponašanjem u samom modelu. Slučaj korištenja se u modelu realizira većspomenutim tipom: suradnjom.

• Grafički, slučaj korištenja je predstavljen elipsom.

5. UML gradbeni blokovi –

Komponenta• Komponenta (eng. component) i

predstavlja fizički i zamjenjivi dio sustava koji se prilagoĎava skupu sučelja i pruža njihovu realizaciju. U sustavu se mogu sresti mnoge razne komponente kao što su COM+ komponente, zatim JavaBeans komponente kao i ostale komponente koje su dio razvojnog procesa, kao datoteke programskog koda. Komponenta tipično predstavlja fizičko pakiranje inače logičkih elemenata kao što su klase, sučelja i suraĎivanja.

• Grafički, komponenta se prikazuje kao pravokutnik sa hvataljkama

6. UML gradbeni blokovi – Čvor

• Čvor (eng. node). To je fizički element koji postoji pri radu sustava i redstavlja računalni resurs i obično ima neku memoriju i procesne mogućnosti.

• Unutar čvora može se smjestiti skup komponenata, a komponente mogu, takoĎer,seliti se sa čvora na čvor.

• Grafički, čvor je predstavljen kockom

7a. UML gradbeni blokovi – Stvari

sa ponašanjem • Stvari sa ponašanjem su dinamički

dijelovi UML modela. To su glagoli

modela i predstavljaju ponašanje kroz

prostor i vrijeme. Postoje, sve skupa,

samo dva primarna tipa stvari sa

ponašanjem.

• Prvi od njih je interakcija. Interakcija je

ponašanje koje obuhvaća skup poruka

koji se izmjenjuje u skupu objekata

unutar nekog odreĎenog konteksta s

odreĎenom svrhom. Ponašanje skupa

objekata ili individualne operacije može

se specificirati interakcijom.

• Interakcija uključuje i brojne druge

elemente kao što su poruke, slijedovi

akcija (ponašanje pokrenuto porukom) i

veze izmeĎu objekata.

• Grafički, poruka je predstavljena kao

linija sa strelicom u jednom smjeru i

najčešće uključuje i ime operacije

7b. UML gradbeni blokovi – Stvari s

ponašanjem• Automat stanja (eng. State machine).

Automat stanja je ponašanje koje

specificira slijed stanja objekta ili

interakcije kroz koje prolazi za vrijeme

svog života kao odgovor na neki

dogaĎaj, zajedno sa odgovorom na taj

dogaĎaj.

• Ponašanje pojedine klase ili suradnje

klasa može biti specificirana

automatom stanja. Automat stanja

uključuje i brojne druge elemente, kao

što su stanja, tranzicije (prijelazi

izmeĎu dva stanja), dogaĎaje (stvari

koje okidaju tranziciju) i aktivnosti

(odgovori na tanziciju).

• Grafički, stanje je predstavljeno

pravokutnikom zaobljenih rubova i

obično uključuje ime stanja i njegova

podstanja.

8a. UML gradbeni blokovi –

Grupirajuće stvari• Grupirajuće stvari su organizacijski dio

UML modela. To su "kutije" u koje se

može razložiti UML model i postoji

samo jedan tip grupirajućih stvari, a to

su paketi (eng. packages).

• Paket je mehanizam opće namjene za

organiziranje elemenata u grupe.

Strukturalne stvari, stvari sa

ponašanjem pa čak i druge grupirajuće

stvari mogu se smjestiti u paket. Za

razliku od komponenata (koje postoje

za vrijeme izvoĎenja), paket je čisto

konceptuale prirode (što znači da

postoji samo za vrijeme razvoja).

• Grafički, paket je prikazan kao

pravokutnik sa hvataljkom (eng.

tabbed folder) kako je prikazano na

Slici 10. i obično sadrži ime i, ponekad,

svoj sadržaj.

9a. UML gradbeni blokovi – Opisne

stvari• Opisne stvari su dijelovi UML

modela koji daju neku vrstu objašnjenja. To su komentari koji se mogu primijeniti kako bi se opisalo, naglasilo ili dalo primjedbu na neki element unutar UML modela.

• Postoji samo jedan glavni tip opisnih stvari, a to je cedulja (eng. note).

• Cedulja je, jednostavno, simbol za pisanje ograničenja i komentara i vezana je za neki element ili kolekciju elemenata u UML modelu.

• Grafički, cedulja se predstavlja kao pravokutnik sa zavrnutim rubom, zajedno sa tekstualnim ili grafičkim komentarom

UML – gradbeni blokovi –

Relacijske stvari u UML-u

• Postoje četiri tipa relacija unutar UML modela:

– Asocijacije (eng. association)

– Ovisnosti (eng. dependency)

– Generalizacije (eng. generalization)

– Realizacije (eng. realization)

UML – gradbeni blokovi –

asocijacija

• Postoje četiri tipa relacija unutar UML modela:

– Asocijacije (eng. association)

– Ovisnosti (eng. dependency)

– Generalizacije (eng. generalization)

– Realizacije (eng. realization)

UML – gradbeni blokovi –

ovisnost• Ovisnost, je semantička

relacija izmeĎu dvije stvari u kojoj promjena u jednoj (neovisnoj stvari) može utjecati na semantiku druge (ovisne stvari).

• Grafički, ovisnost se prikazuje kao isprekidana linija, sa mogućom oznakom direkcije (strelica) i imenom realization)

UML – gradbeni blokovi –

asocijacija• Asocijacija, je strukturalna

relacija koja opisuje skup veza izmeĎu objekata. Kombinacija (eng. aggregation) je pecijalan

• oblik asocijacije i reprezentira strukturalnu relaciju izmeĎu cjeline i njenih dijelova.

• Grafički, asocijacija se predstavlja kao puna linija, uz mogućnost odreĎivanja smjera, i ponekad sadrži i dodatne stvari kao n-arnost i ime.

UML – gradbeni blokovi –

generalizacija• Generalizacija (eng.

generalization), je relacija specijalizacije/generalizacijeu kojoj objekti specijaliziranih elemenata (djeca) se mogu zamijeniti objektima generaliziranih elemenata (roditelja). Na ovaj način, djeca dijele strukturu i ponašanje roditelja.

• Grafički, relacija generalizacije se prikazuje kao puna linija sa šupljom strelicom koja pokazuje prema roditelju

UML – gradbeni blokovi –

realizacija• Realizacija (eng. realization), je semantička

relacija izmeĎu klasifikatora,gdje jedan

klasifikator specificira ugovor koji drugi

klasifikator garantira izvršiti.

• Realizacija se susreće na dva mjesta: izmeĎu

sučelja i klasa ili komponenata koje ih

realiziraju, i izmeĎu slučajeva korištenja i

suradnji koje ih realiziraju.

• Grafički, realizacija se prikazuje kao prijelaz

izmeĎu generalizacije i relacije ovisnosti (Ova

četiri elementa su osnovne relacijske stvari

koje se mogu uključiti u UML model.

• Postoje, takoĎer, i varijacije relacijskih stvari

kao što su uključivanje (eng. include),

proširenje (eng. extend), rafiniranje (eng.

refinement), i praćenje (eng. trace).

Modeli i dijagrami

Model je pojednostavljeni opis sustava Iz odreĎene perspektive.

Dokumentira se dijagramima.

Pojedini dijagram je pogled u model.

Obilježja dijagrama:

• Dijagram je pogled u model predstavljen s aspekta odreĎenog

dionika.

• Daje odreĎeno predstavljanje sustava

• Dijagram je djelomičan opis sustava.

• Dijagram mora biti semantički konzistentan s ostalim

pogledima.

Dijagrami

• Dijagram je grafička prezentacija skupa elemenata, najčešće

prikazanih kao povezani grafovi vertikala (stvari) i lukova (relacije).

• Dijagrami se crtaju kako bi se vizualizirao sustav iz različitih

perspektiva, pa to čini dijagram nekom vrstom projekcije u sustav.

• Za gotovo sve sustave, osim onih vrlo jednostavnih, dijagrami

predstavljaju poboljšani prikaz elemenata koji čine sustav. Isti

elementi mogu se pojaviti u svim dijagramima, nekim dijagramima

(najčešći slučaj) ili se uopće ne pojaviti (jako rijetko).

• Teoretski, dijagram može sadržavati bilo koju kombinaciju stvari i

relacija u modelu.

• U praksi, meĎutim, samo se mali broj kombinacija pojavljuje, i one

su konzistentne sa pet najkorisnijih pogleda na sustav koji čine

arhitekturu sustava koji se oslanjaju na programsku podršku.

Tipovi UML dijagrama

Use CaseDiagramsUse Case

DiagramsDijagrami

obrazaca uporabe(use case)

ScenarioDiagramsScenario

DiagramsKomunikacijskidijagrami

StateDiagramsState

DiagramsDijagrami komponenata

ComponentDiagramsComponent

DiagramsDijagramirazmještaja

StateDiagramsState

DiagramsDijagrami objekata

ScenarioDiagramsScenario

Diagrams“Statechart”

Dijagramistanja

Use CaseDiagramsUse Case

DiagramsSekvencijski dijagrami

StateDiagramsState

DiagramsDijagramirazreda

Dijagramiaktivnosti

Modeli

Dijagrami razmatrani u

sklopu analize i

dokumentiranja zahtjeva

Dijagrami specifični za objektno

usmjerenu programsku potporu

40 UML 2

Dijagrami UML-a

Dijagram Namena Uvedeno u verziji

Aktivnosti proceduralno i paralelno ponašanje UML 1

Klasa klase, odlike i veze UML 1

Komponenata struktura i veze komponenata UML 1

Komunikacije interakcija izmeĎu objekata-naglasak na vezama UML 1

Mašine stanja kako dogaĎaji mijenjaju objekat tijekom njegovog

postojanja

UML 1

Objekata primjeri konfiguracije instanci Nezvanično u UML 1

Paketa hijerarhijska struktura tijeko prevoĎenja Nezvanično u UML 1

Pregleda interakcije kombinacija dijagrama sekvence i aktivnosti Novo u UML 2

RasporeĎivanja rasporeĎivanje artefakata po čvorovima UML 1

Sekvence interakcija izmeĎu objekata-naglasak na sekvenci UML 1

Složene strukture razlaganje klasa tijekom izvršavanja Novo u UML 2

Slučajeva korišćenja Interakcija korisnika i sustava UML 1

Vremenski interakcija izmeĎu objekata-naglasak na

vremenskoj promeni

Novo u UML 2

41 UML 2

Klasifikacija dijagrama

Dijagram

Dijagram

ponašanja

Dijagram

strukture

Dijagram stanja

Dijagram slučajeva

korišćenja

Dijagram aktivnosti

Dijagram interakcije

Dijagram objekata

Dijagram složene

strukture

Dijagram klasa

Vremenski dijagram

Dijagram pregleda

interakcije

Dijagram komunikacije

Dijagram sekvence

Dijagram paketa

Dijagram rasporeĎivanja

Dijagram komponenata

Podjela dijagrama

• U okviru UML-a postoji devet standardnih

dijagrama koji su grupirani u 2 skupine:

• Statički pogledi (5 dijagrama):

– Opisuje stanje sustava – vrijednosti izabranih varijabli sustava

nekim skupom podataka

– dijagram obrazaca uporabe, dijagram razreda/klasa, dijagram

objekata, dijagram komponenti, dijagram razmještaja

• Dinamički pogledi (4 dijagrama):

• Uvodi se dimenzija vremena; dogaĎaj (u sustavu ili van njega)

mijenja stanje sustava u pogledu neke njegove varijable

• sekvencijski dijagram, komunikacijski (kolaboracijski) dijagram,

dijagram stanja (“statechart”), dijagram aktivnosti

Ak.god. 2008/2009 43

Modeliranje sustava

dijagrami slijeda

dijagrami klasa

specifikacija

slučaja korištenja

sudionik slučaj korištenja

Slučaj korištenja je niz akcija koje

sustav izvršava i koje daju opipljivi

rezultat odreĎenom sudioniku.

Dijagram slijeda opisuje

dinamiku slučaja korištenja

Dijagram klasa daje statički

prikaz slučaja korištenja

Primjer: Modeliranje organizacije

fakultetaNeki fakultet sastoji se od jednog ili više zavoda, a svaki zavod od jedne ili više

zavodskih grupa. Zavodsku grupu čine zaposlenici. Zaposlenici mogu raditi i u nekoliko zavodskih grupa, ali ne mogu raditi na više zavoda.

Postoje dva konkretna tipa zaposlenika: predavači i asistenti. Svaki predavač ima barem jedan kolegij koji predaje, a svaki asistent drži laboratorijske vježbe iz barem jednog kolegija. Svaki kolegij može imati jednog ili više predavača i asistenata. Asistent ima jednog predavača u funkciji mentora, a predavač može imati više asistenata. Svaki kolegij se sastoji od više predavanja i više laboratorijskih vježbi i ima svoj naziv sastoji od više redavanja i više laboratorijskih vježbi i ima svoj naziv (String).

Ukidanjem kolegija ukidaju se predavanja i laboratorijske vježbe, ali naravno, ne otpuštaju se zaposlenici koji kolegij drže. Student je zasebna kategorija u organizaciji fakulteta i u ovom modelu pretpostavite samo da sluša jedan ili više kolegija. I student i zaposlenik su osobe. Svaka osoba ima svoje ime i prezime. Dodatno, svaki zaposlenik ima svoj matični broj zaposlenika (String), a svaki student svoj JMBAG (String). Fakultet ima svoj matični broj (String) i naziv (String). Zavod ima svoj naziv (String) i broj računa (String). Naziv i broj računa zavoda nasljeĎuju i zavodske grupe, s tim da one osim toga imaju i svoj naziv grupe te dodatno, naziv glavnog laboratorija (String).

46

Modeliranje s razredima

UML dijagrami razreda i

objekata (eng. Class Diagram)

Izvor: T.C.Lethbridge, R.Laganiere, 2005

Naziv i izgled

• Najčešći termin koji se koristi je: – Class dijagram

• Hrvatski termin:– Dijagram razreda

– Dijagram klasa

• hrv. razred, klasa

= engl. class

Statični dijagram. Bez vremenske domene.

Tvore ga samo definicije razreda i njihovih odnosa.

Nema aktora. 5/50

Svrha i cilj

• Class dijagram opisuje vrste objekata unutar nekog

sustava i njihove meĎusobne statične odnose

– Jednostavno rečeno: class dijagram opisuje razrede (klase) i

njihove meĎusobne veze

• Dva osnovna tipa odnosa izmeĎu razreda:

– Pridruživanje (veza ili asocijacija)

– Podtip

• Također, class dijagrami mogu prikazati atribute i

operacije razreda, njihova svojstva, ograničenja nad njima,

pakete, …

– Dozvoljeni su komentari i dokumentacija

6/50

49

Temelji UML dijagrama klasa

• Osnovni simboli prikazani na dijagramima razreda su:– Razredi

– predstavljanju tip podataka (podatkovne apstrakcije koje sadrže procedure).

– Pridruživanja (engl. Associations)

– predstavljaju vezu izmeĎu instanci razreda.

– Atributi

– jednostavni podaci sadržani u razredima i njihovim instancama.

– Operacije

– predstavljaju funkcije koje izvode instance razreda (objekti).

– Generalizacije

– grupiranje razreda u hijerarhiju nasljeĎivanja.

Razred

• Razred ili klasa (engl. class) je osnovni tvorbeni

element UML class dijagrama

1.Objekt

– Predstavlja entitet iz stvarnog svijeta ili neki koncept

– Apstrakcija nečega što ima dobro definirane granice i

smisao u sustavu

2.Razred

– Opis grupe objekata sa sličnim svojstvima

– Svaki objekt je pojedinac (instanca) jedne klase

10/50

51 UML 2

Dijagrami klasa (Class diagrams)

Model klase

Ime klase

Atributi klase

Operacije klase

Dijagram klasa opisuje tipove objekata u sustavu i različite vrste statičkih veza

koje postoje meĎu njima, kao i ograničenja u načinu njihovog povezivanja.

Dijagrami klasa su najčešće korišćeni dijagrami UML-a.

Najbogatiji skup tehnika za modelovanje u UML-u imaju upravo dijagrami

klasa.

Porudžbina

datumNaručivanja:Date[0..1]

plaćenoUnapred:Boolean[1]

Broj:String[1]

cena:Novac

pošalji

zaključi

Primer klase

52 UML 2

Svojstva klase (properties)

Svojstva klase predstavljaju strukturne karakteristike klase.

Svojstva klase

Načini predstavljanja

na dijagramu

Upotreba

Asocijacije

Atributi

za predstavljanje manje

važnih svojstava, kao što

su datumi ili logičke

promenljive

za eksplicitno isticanje

važnih klasa u sistemu

Većina informacija se može prikazati ravnopravno na oba navedena načina, mada

postoje i neke razlike meĎu njima. Izbor načina prikazivanja se ne zasniva na značenju

pojmova, već na tome šta želimo da naglasimo na dijagramu.

generalizacija – donji razred proširuje NazivRazreda

generalizacija

naziv razreda

lista atributa

lista operacija

pridruživanje – odmah se generira novi razred

Primjer klase/razreda u ArgoUML alatu

pridruživanje – sam sa sobom (atribut tipa razreda)

11/50

Paket

• UML paket (engl. package) je skup

različitih objekata

• Svrha paketa je omogućiti hijerarhijsku

organizaciju elemenata u UML dijagramu

• Može sadržavati druge pakete, objekte,

razrede, komponente, UC-ove, itd.

• U programskom kodu interpretira se kao

namespace u C++, package u Javi, …

12/50

Java

package com.util.MojPaket;

public class A {}

Java

package com.util.MojPaket.DrugiPaket;

public class B {}

C++

namespace com {

namespace util {

namespace MojPaket {

namespace DrugiPaket {

class B {};

} /* End of namespace

com.util.MojPaket::DrugiPaket */

} /* End of namespace com.util.MojPaket */

} /* End of namespace com.util */

} /* End of namespace com */

Primjer paketa Napomena: Izvorni kod svih primjera dobiven je iz ArgoUML-a (kartica

Source Code). Kod je koristan za ilustraciju dijagrama, ali potrebno ga je

proširiti i provjeriti njegovu ispravnost u nekom od jezičnih procesora.

13/50

56

Klase/razredi – grafička prezentacija

• Razred je predstavljen pravokutnikom s imenom.

– Grafički simbol razreda može prikazati atribute i operacije.

– Cjeloviti potpis operacije (metode) je::

[vidljivost] name([parameter-list]): returnType

• vidljivost je private ako nema oznake

Oznake za vidljivost

+ public (dostupni svima)

- private (dostupni unutar razreda)

# protected (dostupni od podrazreda)

Višestrukost pridruživanja

• Vrh može odreĎivati višestrukost veze (engl. multiplicity)– Govori nam koliko objekata može sudjelovati u

odreĎenom odnosu

• Dozvoljene vrijednosti na bilo kojoj strani pridruživanja:– 1 = točno 1 pojedinac (podrazumijevana vrijednost)

– n1 = bilo koji točno odreĎen broj, npr. 0, 1, 3, 5, 15

– n1.. n2 = izmeĎu n1 i n2

– n1..* ili n1..n = izmeĎu n1 i više pojedinaca, neograničeno

– 0..* ili * ili n = više pojedinaca, neograničeno

17/50

58

Pridruživanje i brojnost (višestrukost)

• Pridruživanje ili asocijacija pokazuje odnos izmeĎu dviju

klasa/razreda.

• Brojnost pokazuje broj instanci klasa/razreda.

• Simboli koji pokazuju brojnost smješteni su na svakom kraju

pridruživanja.

0 ili između 3 i 8

0 ili više

1 ili više

Primjeri višestrukosti asocijacija

public class A1 {

public B1 myB1;

}public class B1 {

}

import java.util.Vector;

public class A2 {

public Vector myB2;

}

import java.util.Vector;

public class A3 {

public Vector myB3;

}

import java.util.Vector;

public class A4 {

public Vector myB4;

} 18/50

60

Označavanje pridruživanja

– Svako pridruživanje može se označiti kako bi se

ekspliciralo njegovo značenje.

61

Analiza i validacija pridruživanja

– Više (mnogo) - jedan• Jedna kompanija ima više zaposlenika.

• Jedan zaposlenik može raditi samo za jednu kompaniju.

– Ta kompanija nema podataka o radu “u fušu” (engl.

moonlighting).

• Kompanija ima nula zaposlenika.

– Npr. početna registracija, ili krovna kompanija.

• Nije moguće biti zaposlenik ako ne radiš za neku

kompaniju.

*worksFor

Employee Company1

zaposlenik

62

Analiza i validacija pridruživanja

– Više - više• Jedan asistent može raditi za više menadžera.

• Jedan menadžer može imati više asistenata.

• Asistenti mogu biti organizirani u skupove (engl. pool).

• Menadžeri mogu imati grupu asistenata.

• Neki menadžeri mogu imati nula asistenata.

*

supervisor

*****1..*Assistant Manager

(0..* i * je ekvivalentno) (najmanje 1)

63

Analiza i validacija pridruživanja

– Jedan - jedan• U svakoj kompaniji postoji točno jedan odbor direktora.

• Odbor direktora je odbor samo jednoj kompaniji.

• Kompanija mora uvijek imati odbor direktora.

• Odbor direktora je uvijek odbor u nekoj kompaniji.

Company BoardOfDirectors11

64

Analiza i validacija pridruživanja

• Izbjegavaj nepotrebno jedan – jedan pridruživanje.

Izbjegavaj ovo Učini ovo

65

Složeniji primjer pridruživanja (rezervacija leta)

– Rezervacija je uvijek samo za jednog putnika.

• Nema rezervacije za nula putnika.

• Rezervacija nikada ne uključuje više od jednog putnika..

– Putnik može imati bilo koji broj rezervacija.

• Putnik uopće ne mora imati neku rezervaciju.

• Putnik može imati više od jednu rezervaciju.

– Okvir oko ovoga dijagrama je opcija koju predviĎa UML 2.0. (nebitno za ova predavanja)

66

Pridruženi razredi

– Ponekad se atribut koji se tiče više razreda ne može

smjestiti niti u jedan od navedenih razreda.

– Postoje dva ekvivalentna označavanja pridruženih

razreda:: Ako grade ovdje

nije moguće imati

jedan po studentu

(već samo jedan

po grupi za

predmet)

Ako grade

ovdje nije

moguće imati

jedan po

predmetu (već

samo jedan po

studentu)

Pridruženi

razred,

može imati

podrazrede

Sementički

jasnije

Jednostavnije

se čita

67

Refleksivno pridruživanje

– Moguće je da se pridruživanje spaja na isti razred.

predmet može

imati druge

predmete kao

prerekvizite

vrlo slični predmeti se

ne mogu upisivati

68

Smjer pridruživanja

• Pridruživanja su u osnovici bidirekcijska (u oba smjera) .

• Moguće je ograničiti smjer pridruživanja dodavanjem

strelice na jednom kraju (unidirekcijska).

(za odabrani dan pogledaj

bilješku, ali ne i obratno)

C++

Razred Sveučilište

class Fakultet;

class Sveučilište {

public:

Fakultet *Pripadnost sveučilištu;

};

Razred Fakultet

class Student;

class Fakultet {

public:

Student *Pripadnost fakultetu;

};

Razred Student

class Fakultet;

class Student {

public:

Fakultet *Pripadnost fakultetu;

};

Java

Razred Sveučilište

public class Sveučilište {

public Fakultet Pripadnost sveučilištu;

}

Razred Fakultet

public class Fakultet {

public Student Pripadnost fakultetu;

}

Razred Student

public class Student {

public Fakultet Pripadnost fakultetu;

}

Još jedan primjer pridruživanja

16/50

Agregacija

• Vrsta pridruživanja koja pokazuje da jedan

razred sadrži druge, tj. da je dio drugog razreda– Razred je agregiran (sadržan) u drugom razredu → oblik odnosa

podskup/nadskupC++

#ifndef Fakultet_h

#define Fakultet_h

#include <vector>

#include "Student.h"

class Fakultet {

public:

std::vector< Student* > myStudent;

};

#endif // Fakultet_h

Java

import java.util.Vector;

public class Fakultet {

public Vector myStudent;

}

Kompozicija

• Vrsta pridruživanja slična agregaciji, ali kod

uništavanja objekta (tj. pojedinca) uništavaju se i

pojedinci razreda koji su dio tog objekta

C++

#ifndef Fakultet_h

#define Fakultet_h

#include <vector>

#include "Student.h"

class Fakultet {

public:

std::vector< Student > myStudent;

};

#endif // Fakultet_h

Java

import java.util.Vector;

public class Fakultet {

public Vector myStudent;

}

Atributi

• Atributi (engl. attributes) razreda imaju sljedeća svojstva:

– Stupanj vidljivosti (engl. visibility)

– Naziv (engl. name)

– Vrsta ili tip (engl. type)

– Početnu vrijednost (engl. initial value)

• Dodatno:

– Promjenjivost (engl. changeability)

– Modifikator (engl. modifier)

19/50

Stupanj vidljivosti atributa

• Moguće su četiri vrijednosti:

– Public• Atribut je dostupan svim razredima i paketima.

– Package• Atribut je dostupan svim razredima istog paketa.

– Protected• Atribut je dostupan unutar istog razreda i izvedenih

razreda.

– Private• Atribut je dostupan samo unutar istog razreda.

20/50

Vrsta ili tip atributa

• Dozvoljeni su sljedeći UML tipovi:

– Boolean, Integer, String, UnlimitedInteger

• Dozvoljeni su i dodatni Java tipovi podataka:

– byte, char, double, float, int

– I razredi iz java.util (Collection, Date, List, Set,

SortedSet, Time, Vector …), java.lang,

java.lang.math i java.net (URL) paketa

– I vlastiti tipovi razreda i podataka u istom

dijagramu

21/50

Promjenjivost atributa (1/2)

• addOnly

– Vrijednost atributa može se samo povećavati.

• changeable

– Vrijednost atributa može se nesmetano mijenjati. Podrazumijevana (default) postavka.

• frozen

– Vrijednost atributa (ili asocijacije) ne smije se promijeniti tijekom života (engl. lifetime) pripadajućeg objekta.

22/50

Promjenjivost atributa (2/2)

• static

– Modifikator, vrijednost atributa ne mijenja se (konstanta) i ne ovisi o životu objekta.

• read-only

– Vrijednost atributa ne može se mijenjati izvan objekta kojemu pripada.

• Nije isto što i frozen.

– ArgoUML ne podržava direktno read-only, ali važno ga je spomenuti.

23/50

Primjeri rada sa atributima (ArgoUML alat)

24/50

Operacije

• Operacije (engl. operations) su procesi koje razred može izvršiti.

– Drugim riječima, to su vlastite metode i funkcije razreda

• Za njih možemo odrediti:

– Vidljivost (public,package,protected,private)

– Modifikatore (static,abstract,leaf,root,query)

– Istodobnost (sequential,guarded,concurrent)

– Parametre ili argumente

25/50

79 UML 2

Operacije (1) (operations)

Vrste operacija:

Upiti

ne mijenjaju stanje sustava, tj.

nemaju sporedne efekte

vraćaju pročitanu vrednost iz klase

redoslijed izvršavanja im se može

mijenjati, a da se ne promijeni

ponašanje sustava

Modifikatori

mijenjaju stanje sustava

obično nemaju rezultat

Operacije su aktivnosti koje klasa može da obavi.

Nadtip

operacija

Podtip

operacija

Podtip

operacija

Podtip

operacija

metod

metoda1 metoda2 metoda3

operacija klase metod klase

Primer polimorfizma

deklaracija

procedure

tijelo

procedure

80 UML 2

Operacije (2) (operations)

Sintaksa operacija na UML-u

vidljivost ime (lista-parametara) : tip-rezultata {opis-svojstva}

Primer operacije

+ stanjeNa (datum:Datum) : Novac

vidljivost označava da li je operacija javna (+) ili privatna (-)

ime je niz znakova

lista-parametara je lista parametara operacije

Sintaksa parametara operacije je: smer ime: tip = podrazumevana-vrednost

• ime, tip i podrazumevana-vrednost imaju isto značenje kao u sintaksi atributa

• smer pokazuje da li je parametar ulazni (in), izlazni (out), ili ulazno-izlazni (inout)

tip-rezultata ukazuje na tip rezultata operacije

opis-svojstva ukazuje na svojstva operacije (pr. query)

Obja

šnje

nje

Primjer rada sa

operacijama

NasljeĎivanje (1/2)

• Nasljeđivanje (engl. inheritance) je koncept

UML-a u kojemu objekt koji se nasljeĎuje je

proširen u objektu koji ga nasljeĎuje

• Oblik UML asocijacije ili veze

– Nasljedna veza izmeĎu razreda

– Jedan razred je roditelj (nadklasa) drugome

razredu (dijete ili podklasa)

NasljeĎivanje (2/2)

• Generalizacija – omogućuje stvaranje nadklase koja

objedinjuje strukturu i ponašanje zajedničko za nekoliko

klasa

• Specijalizacija – omogućuje stvaranje podklase koja

predstavlja dodavanje novih elemenata

– Podklasa uvijek ima više ili jednak broj svojstava u odnosu na

nadklasu

– Podklasa nasljeĎuje od nadklase atribute, relacije i operacije

– Podklasa može biti proširena atributima, operacijama ili

relacijama

– Podklasa može imati svoju implementaciju operacija koje je

naslijedila

public class Vozilo {

public int brojKotača;

}

public class Automobil extends Vozilo {

public int brojPutnika;

public int zapreminaPrtljažnika;

}

public class SportskiAutomobil extends Automobil {

public final int brojCilindara;

}

Primjer nasljeĎivanjaspecija

lizacija g

enera

lizacija

32/50

85

Generalizacija

• Specijalizacija superrazreda u jedan ili više podrazreda.

– Generalizacijski skup je označena grupa generalizacija s

zajedničkim superrazredom.

– Oznaka (katkad nazvana diskriminator) opisuje kriterije za

specijalizaciju.

86

Izbjegavanje nepotrebne

generalizacije (1/2)

Nepogodna hijerarhija

razreda, Trebali bi biti

instance (objekti).

Vidi slijedeću sliku.

87

Izbjegavanje nepotrebne

generalizacije (2/2)

Slika pokazuje poboljšani dijagram razreda uz pridruženi

dijagram objekata (instanci) Razredi iz prethodnog dijagrama su

ovdje objekti (instance) jednog razreda RecordingCategory

Dijagram objekata

(razmatrat će se

kasnije)

Dijagram razreda

U dijagramu

objekata nema

oznaka brojnosti

Načini zapisivanja

88

Rukovanje višestrukim diskriminatorima

– Kreiranje generalizacije više razine.Dvije generalizacije

koje dijele isti

superrazred.

(ovo je bolje rješenje

nego dvije odvojene

hijerarhije)

89

Rukovanje višestrukim diskriminatorima(višestruko nasljeđivanje)

90

Izbjegavanje da instance moraju mijenjati razred

– Instanca nikad ne treba mijenjati razred.

Studentov status se može promijeniti, pa taj objekt (instanca) mora

promijeniti razred (traži destrukciju – kreaciju novog objekta).

Jedno rješenje: uključi atribut attendanceStatus u razred

Student te ne koristiti podrazrede (ali tako se gubi mogućnost

polimorfizma - specifičnih metoda u različitim podrazredima).

Sučelje

• Sučelje (engl. interface) je kolekcija

operacija koja specificira usluge nekog

razreda

– Sučelje definira skup operacijskih specifikacija

(tj. njihovih potpisa), ali nikada skup njihovih

implementacija

• Drugim riječima, sučelje je razred, ali bez

atributa i sve operacije imaju samo

tijelo, bez implementacije

Primjer sučelja

public interface MojeSučelje {

public boolean nekaMetoda(int arg1);

public void josJednaMetoda(int arg1);

}

Realizacija

• Realizacija (engl. realisation) je veza UML-a koja označava ostvarenje sučelja

• Razred realizira ili ostvaruje sučelje– Veza realizacije (strelica) je usmjerena od razreda prema

sučelju

• Realizacija je slična nasljeĎivanju samo što se kod realizacije nasljeĎuju samo operacije s parametrima, bez implementacije

• Realizacija u ArgoUML-u ima dva svojstva:– Supplier = Sučelje

– Client = Razred koji ostvaruje sučelje

Java

public class IzvedenaKlasa implements NekoSučelje {

public int atributKlase;

public IzvedenaKlasa myIzvedenaKlasa;

public IzvedenaKlasa myIzvedenaKlasa;

public void metodaSučelja(int param) {

}

public Boolean metodaKlase(String param) {

return null;

}

}

public interface NekoSučelje {

public void metodaSučelja(int param);

}

Primjer sučelja i realizacije

38/50

Stereotipovi

• Stereotipovi (engl. stereotypes) su

najvažniji način proširenja definicije UML-a

• Definiraju sučelja i enumeracije kao

posebne vrste razreda. Mogu se primijeniti

na pridruživanja i generalizacije.

Enumeracije

• Enumeracije (engl. enumerations) su

oblik tipova podataka koji sadržavaju

ureĎene parove imenovanih identifikatora i

njima pridruženih vrijednosti

– Te vrijednosti nazivaju se enumerirani literali

•Koriste se za opis

diskretnih vrijednosti

97 2

Obuhvata kamionete

i džipove, ali ne i

motocikle

Napomene i komentari

Auto

Napomene predstavljaju objašnjenja na dijagramu. Mogu biti nezavisne od

drugih elemenata dijagrama, ali mogu biti i spojene isprekidanom linijom sa

elementima dijagrama koje objašnjavaju. Kao oznaka kraja linije može se

koristiti kružić.

Komentar je tekst koji se može dodati elementu dijagrama pomoću dve crtice

ispred teksta (--).

Napomene i komentari se mogu pojaviti na svim vrstama dijagrama.

PRIMJERI UML-A

Primjer: Modeliranje organizacije

fakultetaNeki fakultet sastoji se od jednog ili više zavoda, a svaki zavod od jedne ili više

zavodskih grupa. Zavodsku grupu čine zaposlenici. Zaposlenici mogu raditi i u nekoliko zavodskih grupa, ali ne mogu raditi na više zavoda.

Postoje dva konkretna tipa zaposlenika: predavači i asistenti. Svaki predavač ima barem jedan kolegij koji predaje, a svaki asistent drži laboratorijske vježbe iz barem jednog kolegija. Svaki kolegij može imati jednog ili više predavača i asistenata. Asistent ima jednog predavača u funkciji mentora, a predavač može imati više asistenata. Svaki kolegij se sastoji od više predavanja i više laboratorijskih vježbi i ima svoj naziv sastoji od više redavanja i više laboratorijskih vježbi i ima svoj naziv (String).

Ukidanjem kolegija ukidaju se predavanja i laboratorijske vježbe, ali naravno, ne otpuštaju se zaposlenici koji kolegij drže. Student je zasebna kategorija u organizaciji fakulteta i u ovom modelu pretpostavite samo da sluša jedan ili više kolegija. I student i zaposlenik su osobe. Svaka osoba ima svoje ime i prezime. Dodatno, svaki zaposlenik ima svoj matični broj zaposlenika (String), a svaki student svoj JMBAG (String). Fakultet ima svoj matični broj (String) i naziv (String). Zavod ima svoj naziv (String) i broj računa (String). Naziv i broj računa zavoda nasljeĎuju i zavodske grupe, s tim da one osim toga imaju i svoj naziv grupe te dodatno, naziv glavnog laboratorija (String).

Zadatak 1

• Dijagramom klasa predstaviti model

fakulteta.

• Svaki student upisuje studije na jednom i

samo jednom odsjeku, a odsjek pripada

jednom i samo jednom fakultetu.

• Detaljno opisati atribute klase student.

Zadatak 1 – rješenje

Zadatak 2.

• Dijagramom klasa predstaviti logičku arhitekturu sistema za automatsku prijavu studenata za kurseve/predmete.

• Studenti biraju 4 primarna kursa/predmeta.

• Jedan kurs može pohaĎati maksimalno 10 studenata.

• Minimalan broj studenata za predmet je 3.

• Jedan profesor može da ponudi maksimalno 4 kursa, pri čemu više profesora mogu da ponude isti kurs.

Zadatak 2. rješenje

I na kraju poglavlja…

• U izradi projekta bit će vam neophodni sljedeći dijagrami:

• Dijagram klasa

• Dijagram slučajeva korištenja/Use case

• Dijagram aktivnosti

• Dijagram razmještanja/rasporeĎivanja (opcionalno)

• Za rješavanje nekih zadataka bit će poželjno koristiti i neke od preostalih dijagrama, recimo sekvencijalni

• U ovoj prezentaciji obradit će se detaljno use case i dijagrami aktivnosti