labos uml uvod dijagrami klasa
DESCRIPTION
driTRANSCRIPT
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