UML - labosi

Osnove UML-a Dijagrami klasa

Prije UML-a
1960s - 70s

programiranje

COBOL, FORTRAN, C Tehnike strukturne analize i oblikovanja

1980s - early 1990s

Smalltalk, Ada, C++, Visual Basic Rane generacije OO metoda

Sredina i kasne 1990

Java UML Unified Process (RUP)
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. Uvoenje arhitekture programske potpore : to je struktura ili strukture sustava koji sadri elemente, njihova izvana vidljiva obiljeja i odnose izmeu njih.

Prednosti UML-a
Otvoren standard. Podupire cijeli ivotni ciklus oblikovanja programske potpore. Podupire razliite domene primjene. Temeljen je na iskustvu i potrebama zajednice oblikovatelja i korisnika programske potpore. Podravaju ga mnogi alati.

Mnogo sudionika, mnogo pogleda

Arhitekturu programske potpore razliito vidi:
Korisnik-kupac Projekt manager Inenjer sustava Osoba koje razvija sustav Arhitekt Osoba koja odrava sustav (engl. Maintainer) Drugi dionici

Viedimenzionalna realnost Mnogo sudionika rezultira u

viestrukim pogledima, viestrukim nacrtima

Korisnici UML a
Sistem-analitiari i krajnji korisnici: specificiraju zahtjevanu strukturu i ponaanje sustava Voditelji projekata: voenje i usmeravanje kadrova i upravljanje resursima Arhitekti: projektirauju sustav koji zadovoljava zahtjeve Razvojni inenjeri: transformiraju arhitekturu u izvrni kod Kontrolori kvaliteta: provjeravaju strukturu i ponaanje sustava Evidentiari komponenata: kreiraju i vode kataloge komponenti
6 UML 2

 Pogledi odgovaraju nekom kontekstu.

Svi sustavi ne trebaju sve poglede: Jedan procesor, nije potreban nacrt razmjetaja procesora.

Jedan proces, nije potreba nacrt razmjetaja procesa.

Vrlo mali programi, nije potreban nacrt implementacije. Neki dodatni pogledi: Pogled podataka, pogled sigurnosti u sustavu Svaki pogled dokumentira se nacrtom DIJAGRAMOM. Vie pogleda (dijagrama) u okviru nekog konteksta = MODEL Model je apstraktan (reduciran, pojednostavljen, smanjen, ogranien) opis sustava iz odreene perspektive.

Kreiranje UML-a
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sep 97 public feedback First submission to OMG, Jan 97 UML partners Web - June 96

UML 1.1 UML 1.0 UML 0.9

OOPSLA 95

Unified Method 0.8

Other methods

Booch method

OMT

OOSE

Sudjelovanje u kreiranju UML-a

Meyer
Before and after conditions

Harel
Statecharts

Gamma, et al
Frameworks and patterns,

Booch
Booch method

HP Fusion
Operation descriptions and message numbering

Rumbaugh
OMT

Embley
Singleton classes and high-level view

Jacobson
OOSE

Wirfs-Brock
Responsibilities

Shlaer - Mellor
Object lifecycles

Odell
Classification

Povijesni razvoj UML-a

Faze modeliranje - ukratko

Konceptualno modeliranje
Modeliranje poslovnih korisnikih funkcija: Modeli use case Dijagrami aktivnosti Modeliranje poslovnih objekata Modeli poslovnih objekata Dijagrami sekvenci

Logiko modeliranje

Fiziko modeliranje

Definiranje zahteva Detaljno projektiranje modeli korisn. funkcija Dijagrami klasa sistema Model za projektiranje b.p. Opisi korisn. funkcija sistema DDL skriptovi Analiza i preliminarno projektiranje Baze podataka Dijagrami klasa Dijagrami komponenti Dijagrami sekvenci Dijagrami rasporeivanja Dijagrami stanja

Modeliranje npr. baze podataka se fokusira uglavnom na opisivanje baze podataka Projektiranje baze podataka obuhvaa ukupan proces od definiranje i postavljanja zahtjeva, poslovnih procesa, logikih analiza i fizikih ogranienja do razmetaja baze podataka
Npr., u projektiranju baze podataka fiziko modeliranje podataka obuhvaa 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, meutim ona ne moe da postoji sama za sebe i ima mnogo drugih stvari koje sainjavaju 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 ...

Uvoenje UMLa omoguava se zajedniki jezik za sve ukljuene timove UML prua mogunost da se jednim jezikom modeluje poslovni sistem, aplikacije, baza podataka i arhitektura sistema

Unificirani jezik za modeliranje

emu slui UML?

UML se koristi za modeliranje i projektiranje softverskih sustava, naroito sustava pravljenih primjenom objektno-orijentiranih tehnologija.
UML je skup grafikih notacija zasnovanih na jedinstvenom metamodelu. Notacija je skup grafikih elemenata koji se koriste u modelima, tj. grafika sintaksa jezika za modelovanje. Metamodel predstavlja dijagram koji definiran koncepte jezika za modeliranje.
Iako je notacija esto intuitivna, a ne formalna, vrlo se uspjeno koristi u praksi. Metamodel predstavlja pokuaj da se stroe definiran notacija, bez naruavanja njene korisnosti. Ni notacija ni metamodel se ne moraju strogo primenjivati.
13 UML 2

Postupci razvoja
Direktni razvoj (forward engineering)
UML dijagram
generiranje

Programski kod

Povratna analiza (reverse engineering) Programski kod

tumaenje

UML dijagram

14

UML 2

Naini koritenja UML-a

Izrada dijagrama
Izrada projekata

UML

Programski jezik
15 UML 2

Izrada dijagrama
Dijagram opisuju pojedine aspekte sustava koritenjem UML-a kao pomonog sredstva. Osobine dijagrama: predstavljaju najei nain upotrebe UML-a obino se generiraju neformalno i dinamiki, tako da se rade brzo i na tabli nepotpune su (?) omoguavaju jednostavno ispitivanje vie alternativnih reenja mogu se koristiti u dokumentaciji Skice u direktnom razvoju: sadre samo nekoliko znaajnih problema koji e se javiti u kodu predstavljaju ideje i alternative predstojeeg posla vizualiziraju dijelove projekta prije programiranja

Skice u povratnoj analizi:

objanjavaju kako radi neki dio sustava (samo klase o kojima je vano razgovarati)

16

UML 2

Izrada UML projekata

UML projekti opisuju sustav sveobuhvatno, kako bi se programiranje koje predstoji svelo uglavnom na mehaniku aktivnost. Osobine UML projekata: za izradu projekata koriste se sloeni, tzv. CASE alati za raunarsko projektiranje softvera projekti se moraju dosljedno pratiti i sprovoditi Direktni razvoj: Projekti sadre detaljan opis sustava, obino do nivoa IF-a - interfejsa podsustava (dalje se razrada realizacije se preputa programerima), na osnovu koga se pie kod. CASE alati omoguavaju crtanje dijagrama i uvanje informacija u memoriji. Povratna analiza: Projekti sadre detaljne informacije o kodu u obliku papirne ili elektronske dokumentacije. Mogu prikazati svaki detalj neke klase u grafikom obliku koji programer razumije. CASE alati itaju izvorni kod, tumaenja stavljaju u memoriju i generiraju dijagrame.

17

UML 2

UML kao programski jezik

Djelomino UML modeliranje programiranje Intenzivno UML modeliranje UML modeliranje cijelog sustava
Izvorni kod

CASE alati

CASE alati

automatizacija

Programski kod

Programski kod

Programski kod

UML postaje programski jezik u sluaju kada se cijeli sustav modelira UML . dijagramima, a zatim se ti dijagrami primjenom CASE alata neposredno prevode u izvrni kod. Tada UML postaje izvorni kod, to odgovara programskom jeziku. Ovaj nain upotrebe UML-a jo nije doivjeo potpunu primjenu u praksi .
18 UML 2

UML gradbeni blokovi

U UML-u postoji sedam tipova strukturalnih stvari. Strukturalne stvari su imenice u UML modelima. To su najee statiki dijelovi modela i oni predstavljaju elemente koji su ili konceptualni ili fiziki. 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 moe implementirati jedno ili vie suelja (eng. interface). Grafiki,klasa je prikazana kao pravokutnik koji obino sadri ime, atribute i operacije

2. UML gradbeni blokovi - Suelja

Suelje - kolekcija operacija kojaspecificira usluge neke klase ili komponente. Suelje stoga predstavlja izvana vidljivo ponaanje tog elementa i moe predstavljati kompletno ponaanje klase ili komponente ili samo djelomino. Suelje definira skup operacijskihspecifikacija (tj. njihovih potpisa), ali nikada skup njihovih implementacija. Grafiki, suelje je predstavljeno krugom zajdeno sa njegovim imenom. Suelje, prema svojoj namjeni, nikada nee stajati samo, vee obino biti vezano za odreenu 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 zajedniki rade i pruaju nekakvo kooperativno ponaanje koje je vee nego suma svih elemenata zajedno. Stoga, suradnja ima strukturalnu dimenziju kao i dimenziju ponaanja. Neka klasa moe participirati u vie suradnji odjednom i suradnje time reprezentiraju implementaciju predloaka (eng. patterns) koji ine sustav. Grafiki, suradnja je predstavljena elipsom sa isprekidanim linijama i obino se u njoj nalazi njeno ime

4. UML gradbeni blokovi Sluaj koritenja

Sluaj koritenja (eng. Use case). On opisuje skup slijednih dogaaja koje sustav izvodi kako bi dobio neki rezultat i koristi se za strukturiranje stvari sa ponaanjem u samom modelu. Sluaj koritenja se u modelu realizira ve spomenutim tipom: suradnjom. Grafiki, sluaj koritenja je predstavljen elipsom.

5. UML gradbeni blokovi Komponenta

Komponenta (eng. component) i predstavlja fiziki i zamjenjivi dio sustava koji se prilagoava skupu suelja i prua 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 tipino predstavlja fiziko pakiranje inae logikih elemenata kao to su klase, suelja i suraivanja. Grafiki, komponenta se prikazuje kao pravokutnik sa hvataljkama

6. UML gradbeni blokovi vor

vor (eng. node). To je fiziki element koji postoji pri radu sustava i redstavlja raunalni resurs i obino ima neku memoriju i procesne mogunosti. Unutar vora moe se smjestiti skup komponenata, a komponente mogu, takoer, seliti se sa vora na vor. Grafiki, vor je predstavljen kockom

7a. UML gradbeni blokovi Stvari sa ponaanjem

Stvari sa ponaanjem su dinamiki dijelovi UML modela. To su glagoli modela i predstavljaju ponaanje kroz prostor i vrijeme. Postoje, sve skupa, samo dva primarna tipa stvari sa ponaanjem. Prvi od njih je interakcija. Interakcija je ponaanje koje obuhvaa skup poruka koji se izmjenjuje u skupu objekata unutar nekog odreenog konteksta s odreenom svrhom. Ponaanje skupa objekata ili individualne operacije moe se specificirati interakcijom. Interakcija ukljuuje i brojne druge elemente kao to su poruke, slijedovi akcija (ponaanje pokrenuto porukom) i veze izmeu objekata. Grafiki, poruka je predstavljena kao linija sa strelicom u jednom smjeru i najee ukljuuje i ime operacije

7b. UML gradbeni blokovi Stvari s ponaanjem

Automat stanja (eng. State machine). Automat stanja je ponaanje koje specificira slijed stanja objekta ili interakcije kroz koje prolazi za vrijeme svog ivota kao odgovor na neki dogaaj, zajedno sa odgovorom na taj dogaaj. Ponaanje pojedine klase ili suradnje klasa moe biti specificirana automatom stanja. Automat stanja ukljuuje i brojne druge elemente, kao to su stanja, tranzicije (prijelazi izmeu dva stanja), dogaaje (stvari koje okidaju tranziciju) i aktivnosti (odgovori na tanziciju). Grafiki, stanje je predstavljeno pravokutnikom zaobljenih rubova i obino ukljuuje ime stanja i njegova podstanja.

8a. UML gradbeni blokovi Grupirajue stvari

Grupirajue stvari su organizacijski dio UML modela. To su "kutije" u koje se moe razloiti UML model i postoji samo jedan tip grupirajuih stvari, a to su paketi (eng. packages). Paket je mehanizam ope namjene za organiziranje elemenata u grupe. Strukturalne stvari, stvari sa ponaanjem pa ak i druge grupirajue stvari mogu se smjestiti u paket. Za razliku od komponenata (koje postoje za vrijeme izvoenja), paket je isto konceptuale prirode (to znai da postoji samo za vrijeme razvoja). Grafiki, paket je prikazan kao pravokutnik sa hvataljkom (eng. tabbed folder) kako je prikazano na Slici 10. i obino sadri ime i, ponekad, svoj sadraj.

9a. UML gradbeni blokovi Opisne stvari

Opisne stvari su dijelovi UML modela koji daju neku vrstu objanjenja. 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 ogranienja i komentara i vezana je za neki element ili kolekciju elemenata u UML modelu. Grafiki, cedulja se predstavlja kao pravokutnik sa zavrnutim rubom, zajedno sa tekstualnim ili grafikim 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 semantika relacija izmeu dvije stvari u kojoj promjena u jednoj (neovisnoj stvari) moe utjecati na semantiku druge (ovisne stvari). Grafiki, ovisnost se prikazuje kao isprekidana linija, sa moguom oznakom direkcije (strelica) i imenom realization)

UML gradbeni blokovi asocijacija

Asocijacija, je strukturalna relacija koja opisuje skup veza izmeu objekata. Kombinacija (eng. aggregation) je pecijalan oblik asocijacije i reprezentira strukturalnu relaciju izmeu cjeline i njenih dijelova. Grafiki, asocijacija se predstavlja kao puna linija, uz mogunost odreivanja smjera, i ponekad sadri i dodatne stvari kao n-arnost i ime.

UML gradbeni blokovi generalizacija

Generalizacija (eng. generalization), je relacija specijalizacije/generalizacije u kojoj objekti specijaliziranih elemenata (djeca) se mogu zamijeniti objektima generaliziranih elemenata (roditelja). Na ovaj nain, djeca dijele strukturu i ponaanje roditelja. Grafiki, relacija generalizacije se prikazuje kao puna linija sa upljom strelicom koja pokazuje prema roditelju

UML gradbeni blokovi realizacija

Realizacija (eng. realization), je semantika relacija izmeu klasifikatora,gdje jedan klasifikator specificira ugovor koji drugi klasifikator garantira izvriti. Realizacija se susree na dva mjesta: izmeu suelja i klasa ili komponenata koje ih realiziraju, i izmeu sluajeva koritenja i suradnji koje ih realiziraju. Grafiki, realizacija se prikazuje kao prijelaz izmeu generalizacije i relacije ovisnosti (Ova etiri elementa su osnovne relacijske stvari koje se mogu ukljuiti u UML model. Postoje, takoer, i varijacije relacijskih stvari kao to su ukljuivanje (eng. include), proirenje (eng. extend), rafiniranje (eng. refinement), i praenje (eng. trace).

Modeli i dijagrami
Model je pojednostavljeni opis sustava Iz odreene perspektive. Dokumentira se dijagramima. Pojedini dijagram je pogled u model. Obiljeja dijagrama: Dijagram je pogled u model predstavljen s aspekta odreenog dionika. Daje odreeno predstavljanje sustava Dijagram je djelomian opis sustava. Dijagram mora biti semantiki konzistentan s ostalim pogledima.

Dijagrami
Dijagram je grafika prezentacija skupa elemenata, najee prikazanih kao povezani grafovi vertikala (stvari) i lukova (relacije). Dijagrami se crtaju kako bi se vizualizirao sustav iz razliitih perspektiva, pa to ini dijagram nekom vrstom projekcije u sustav. Za gotovo sve sustave, osim onih vrlo jednostavnih, dijagrami predstavljaju poboljani prikaz elemenata koji ine sustav. Isti elementi mogu se pojaviti u svim dijagramima, nekim dijagramima (najei sluaj) ili se uope ne pojaviti (jako rijetko). Teoretski, dijagram moe sadravati bilo koju kombinaciju stvari i relacija u modelu. U praksi, meutim, 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 podrku.

Tipovi UML dijagrama

Dijagrami razmatrani u sklopu analize i dokumentiranja zahtjeva

Use Case Use Case Dijagrami Diagrams Diagrams obrazaca uporabe (use case)

Dijagrami specifini za objektno usmjerenu programsku potporu

State State Diagrams Dijagrami Diagrams razreda

Use Case Use Case Diagrams Sekvencijski Diagrams dijagrami

State State Diagrams Dijagrami Diagrams objekata

Scenario Scenario Diagrams Komunikacijski Diagrams dijagrami

Modeli

State State Diagrams Dijagrami Diagrams komponenata

Scenario Scenario Statechart Diagrams Diagrams Dijagrami stanja

Component Component Diagrams Dijagrami Diagrams

Dijagrami aktivnosti

razmjetaja

Dijagrami UML-a
Dijagram Aktivnosti Klasa
klase, odlike i veze struktura i veze komponenata interakcija izmeu objekata-naglasak na vezama kako dogaaji mijenjaju objekat tijekom njegovog postojanja primjeri konfiguracije instanci hijerarhijska struktura tijeko prevoenja kombinacija dijagrama sekvence i aktivnosti rasporeivanje artefakata po vorovima interakcija izmeu objekata-naglasak na sekvenci razlaganje klasa tijekom izvravanja Interakcija korisnika i sustava interakcija izmeu objekata-naglasak na vremenskoj promeni
40

Namena
proceduralno i paralelno ponaanje

Uvedeno u verziji
UML 1 UML 1 UML 1 UML 1 UML 1 Nezvanino u UML 1 Nezvanino u UML 1 Novo u UML 2 UML 1 UML 1 Novo u UML 2 UML 1 Novo u UML 2
UML 2

Komponenata
Komunikacije Maine stanja Objekata

Paketa
Pregleda interakcije Rasporeivanja Sekvence Sloene strukture Sluajeva korienja Vremenski

Klasifikacija dijagrama
Dijagram klasa Dijagram komponenata Dijagram strukture Dijagram sloene strukture Dijagram rasporeivanja Dijagram objekata Dijagram paketa

Dijagram
Dijagram aktivnosti Dijagram sluajeva korienja Dijagram ponaanja Dijagram stanja Dijagram sekvence

Dijagram komunikacije
Dijagram interakcije Dijagram pregleda interakcije Vremenski dijagram
41 UML 2

Podjela dijagrama
U okviru UML-a postoji devet standardnih dijagrama koji su grupirani u 2 skupine:
Statiki pogledi (5 dijagrama):
Opisuje stanje sustava vrijednosti izabranih varijabli sustava nekim skupom podataka dijagram obrazaca uporabe, dijagram razreda/klasa, dijagram objekata, dijagram komponenti, dijagram razmjetaja
Dinamiki pogledi (4 dijagrama):

Uvodi se dimenzija vremena; dogaaj (u sustavu ili van njega) mijenja stanje sustava u pogledu neke njegove varijable sekvencijski dijagram, komunikacijski (kolaboracijski) dijagram, dijagram stanja (statechart), dijagram aktivnosti

Modeliranje sustava
Sluaj koritenja je niz akcija koje sustav izvrava i koje daju opipljivi rezultat odreenom sudioniku.

sudionik

sluaj koritenja

Dijagram slijeda opisuje dinamiku sluaja koritenja

dijagrami slijeda

Dijagram klasa daje statiki prikaz sluaja koritenja

specifikacija sluaja koritenja dijagrami klasa Ak.god. 2008/2009

43

Primjer: Modeliranje organizacije fakulteta

Neki fakultet sastoji se od jednog ili vie zavoda, a svaki zavod od jedne ili vie zavodskih grupa. Zavodsku grupu ine zaposlenici. Zaposlenici mogu raditi i u nekoliko zavodskih grupa, ali ne mogu raditi na vie zavoda. Postoje dva konkretna tipa zaposlenika: predavai i asistenti. Svaki predava ima barem jedan kolegij koji predaje, a svaki asistent dri laboratorijske vjebe iz barem jednog kolegija. Svaki kolegij moe imati jednog ili vie predavaa i asistenata. Asistent ima jednog predavaa u funkciji mentora, a predava moe imati vie asistenata. Svaki kolegij se sastoji od vie predavanja i vie laboratorijskih vjebi i ima svoj naziv sastoji od vie redavanja i vie laboratorijskih vjebi i ima svoj naziv (String). Ukidanjem kolegija ukidaju se predavanja i laboratorijske vjebe, ali naravno, ne otputaju se zaposlenici koji kolegij dre. Student je zasebna kategorija u organizaciji fakulteta i u ovom modelu pretpostavite samo da slua jedan ili vie kolegija. I student i zaposlenik su osobe. Svaka osoba ima svoje ime i prezime. Dodatno, svaki zaposlenik ima svoj matini broj zaposlenika (String), a svaki student svoj JMBAG (String). Fakultet ima svoj matini broj (String) i naziv (String). Zavod ima svoj naziv (String) i broj rauna (String). Naziv i broj rauna zavoda nasljeuju i zavodske grupe, s tim da one osim toga imaju i svoj naziv grupe te dodatno, naziv glavnog laboratorija (String).

Modeliranje s razredima UML dijagrami razreda i objekata (eng. Class Diagram)

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

46

Naziv i izgled
Najei termin koji se koristi je:
Class dijagram

Hrvatski termin:
Dijagram razreda Dijagram klasa

hrv. razred, klasa = engl. class

Statini 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 meusobne statine odnose
Jednostavno reeno: class dijagram opisuje razrede (klase) i njihove meusobne veze

Dva osnovna tipa odnosa izmeu razreda:

Pridruivanje (veza ili asocijacija) Podtip

Takoer, class dijagrami mogu prikazati atribute i operacije razreda, njihova svojstva, ogranienja nad njima, pakete,
Dozvoljeni su komentari i dokumentacija
6/50

Temelji UML dijagrama klasa

Osnovni simboli prikazani na dijagramima razreda su:
Razredi
predstavljanju tip podataka (podatkovne apstrakcije koje sadre procedure).

Pridruivanja (engl. Associations)

predstavljaju vezu izmeu instanci razreda.

Atributi
jednostavni podaci sadrani u razredima i njihovim instancama.

Operacije
predstavljaju funkcije koje izvode instance razreda (objekti).

Generalizacije
grupiranje razreda u hijerarhiju nasljeivanja.
49

Razred
Razred ili klasa (engl. class) je osnovni tvorbeni element UML class dijagrama 1. Objekt
Predstavlja entitet iz stvarnog svijeta ili neki koncept Apstrakcija neega to ima dobro definirane granice i smisao u sustavu

2. Razred
Opis grupe objekata sa slinim svojstvima Svaki objekt je pojedinac (instanca) jedne klase

10/50

Dijagrami klasa

(Class diagrams)

Dijagram klasa opisuje tipove objekata u sustavu i razliite vrste statikih veza koje postoje meu njima, kao i ogranienja u nainu njihovog povezivanja. Dijagrami klasa su najee korieni dijagrami UML-a. Najbogatiji skup tehnika za modelovanje u UML-u imaju upravo dijagrami klasa. Model klase Ime klase

Primer klase
Porudbina
datumNaruivanja:Date[0..1] plaenoUnapred:Boolean[1] Broj:String[1] cena:Novac
poalji zakljui
51 UML 2

Atributi klase

Operacije klase

Svojstva klase
Svojstva klase predstavljaju strukturne karakteristike klase.
Naini predstavljanja na dijagramu

(properties)

Upotreba

Atributi
Svojstva klase Asocijacije

za predstavljanje manje vanih svojstava, kao to su datumi ili logike promenljive

za eksplicitno isticanje vanih klasa u sistemu

Veina informacija se moe prikazati ravnopravno na oba navedena naina, mada postoje i neke razlike meu njima. Izbor naina prikazivanja se ne zasniva na znaenju pojmova, ve na tome ta elimo da naglasimo na dijagramu.
52 UML 2

Primjer klase/razreda u ArgoUML alatu

generalizacija naziv razreda lista atributa lista operacija pridruivanje odmah se generira novi razred generalizacija donji razred proiruje NazivRazreda pridruivanje sam sa sobom (atribut tipa razreda)

11/50

Paket
UML paket (engl. package) je skup razliitih objekata Svrha paketa je omoguiti hijerarhijsku organizaciju elemenata u UML dijagramu Moe sadravati druge pakete, objekte, razrede, komponente, UC-ove, itd. U programskom kodu interpretira se kao namespace u C++, package u Javi,
12/50

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 proiriti i provjeriti njegovu ispravnost u nekom od jezinih procesora.

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 */ Java package com.util.MojPaket; public class A {} Java package com.util.MojPaket.DrugiPaket; public class B {}
13/50

Klase/razredi grafika prezentacija

Razred je predstavljen pravokutnikom s imenom. Grafiki simbol razreda moe 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)

56

Viestrukost pridruivanja
Vrh moe odreivati viestrukost veze (engl. multiplicity)
Govori nam koliko objekata moe sudjelovati u odreenom odnosu

Dozvoljene vrijednosti na bilo kojoj strani pridruivanja:

1 n1 n1.. n2 n1..* ili n1..n 0..* ili * ili n

= tono 1 pojedinac (podrazumijevana vrijednost) = bilo koji tono odreen broj, npr. 0, 1, 3, 5, 15 = izmeu n1 i n2 = izmeu n1 i vie pojedinaca, neogranieno = vie pojedinaca, neogranieno
17/50

Pridruivanje i brojnost (viestrukost)

Pridruivanje ili asocijacija pokazuje odnos izmeu dviju klasa/razreda. Brojnost pokazuje broj instanci klasa/razreda. Simboli koji pokazuju brojnost smjeteni su na svakom kraju pridruivanja. 0 ili vie
1 ili vie

0 ili izmeu 3 i 8
58

Primjeri viestrukosti 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

Oznaavanje pridruivanja
Svako pridruivanje moe se oznaiti kako bi se ekspliciralo njegovo znaenje.

60

Analiza i validacija pridruivanja

Vie (mnogo) - jedan
Jedna kompanija ima vie zaposlenika. Jedan zaposlenik moe raditi samo za jednu kompaniju.
Ta kompanija nema podataka o radu u fuu (engl. moonlighting).

Kompanija ima nula zaposlenika.

Npr. poetna registracija, ili krovna kompanija.

Nije mogue biti zaposlenik ako ne radi za neku kompaniju.

Employee
*
worksFor

Company

zaposlenik
61

Analiza i validacija pridruivanja

Vie - vie
Jedan asistent moe raditi za vie menadera. Jedan menader moe imati vie asistenata. Asistenti mogu biti organizirani u skupove (engl. pool). Menaderi mogu imati grupu asistenata. Neki menaderi mogu imati nula asistenata.

(0..* i * je ekvivalentno)
Assistant
*

(najmanje 1)
1..**
supervisor

Manager

62

Analiza i validacija pridruivanja

Jedan - jedan
U svakoj kompaniji postoji tono 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

BoardOfDire ctors

63

Analiza i validacija pridruivanja

Izbjegavaj nepotrebno jedan jedan pridruivanje.

Izbjegavaj ovo

Uini ovo

64

Sloeniji primjer pridruivanja (rezervacija leta)

Rezervacija je uvijek samo za jednog putnika. Nema rezervacije za nula putnika. Rezervacija nikada ne ukljuuje vie od jednog putnika.. Putnik moe imati bilo koji broj rezervacija. Putnik uope ne mora imati neku rezervaciju. Putnik moe imati vie od jednu rezervaciju.

Okvir oko ovoga dijagrama je opcija koju predvia UML 2.0. (nebitno za ova predavanja)
65

Pridrueni razredi
Ponekad se atribut koji se tie vie razreda ne moe smjestiti niti u jedan od navedenih razreda. Postoje dva ekvivalentna oznaavanja pridruenih razreda:: Ako grade ovdje Ako grade
ovdje nije mogue imati jedan po predmetu (ve samo jedan po studentu) Pridrueni razred, moe imati podrazrede nije mogue imati jedan po studentu (ve samo jedan po grupi za predmet) Sementiki jasnije Jednostavnije se ita

66

Refleksivno pridruivanje
Mogue je da se pridruivanje spaja na isti razred.

vrlo slini predmeti se ne mogu upisivati predmet moe imati druge predmete kao prerekvizite

67

Smjer pridruivanja
Pridruivanja su u osnovici bidirekcijska (u oba smjera) . Mogue je ograniiti smjer pridruivanja dodavanjem strelice na jednom kraju (unidirekcijska).

(za odabrani dan pogledaj biljeku, ali ne i obratno)

68

Jo jedan primjer pridruivanja

C++ Razred Sveuilite class Fakultet; class Sveuilite { public: Fakultet *Pripadnost sveuilitu; }; Razred Fakultet class Student; class Fakultet { public: Student *Pripadnost fakultetu; }; Razred Student class Fakultet; class Student { public: Fakultet *Pripadnost fakultetu; };
16/50

Java Razred Sveuilite public class Sveuilite { public Fakultet Pripadnost sveuilitu; } Razred Fakultet public class Fakultet { public Student Pripadnost fakultetu; } Razred Student public class Student { public Fakultet Pripadnost fakultetu; }

Agregacija
Vrsta pridruivanja koja pokazuje da jedan razred sadri druge, tj. da je dio drugog razreda
Razred je agregiran (sadran) u drugom razredu oblik odnosa podskup/nadskup
C++ #ifndef Fakultet_h #define Fakultet_h #include <vector> #include "Student.h" Java import java.util.Vector; public class Fakultet { public Vector myStudent; }

class Fakultet { public:

std::vector< Student* > myStudent; };

#endif // Fakultet_h

Kompozicija
Vrsta pridruivanja slina agregaciji, ali kod unitavanja objekta (tj. pojedinca) unitavaju se i pojedinci razreda koji su dio tog objekta
C++ #ifndef Fakultet_h #define Fakultet_h #include <vector> #include "Student.h" Java import java.util.Vector; public class Fakultet { public Vector myStudent; }

class Fakultet { public: std::vector< Student > myStudent; }; #endif // Fakultet_h

Atributi
Atributi (engl. attributes) razreda imaju sljedea svojstva:
Stupanj vidljivosti (engl. visibility) Naziv (engl. name) Vrsta ili tip (engl. type) Poetnu vrijednost (engl. initial value)

Dodatno:
Promjenjivost (engl. changeability) Modifikator (engl. modifier)
19/50

Stupanj vidljivosti atributa

Mogue 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 sljedei 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 moe se samo poveavati.

changeable
Vrijednost atributa moe se nesmetano mijenjati. Podrazumijevana (default) postavka.

frozen
Vrijednost atributa (ili asocijacije) ne smije se promijeniti tijekom ivota (engl. lifetime) pripadajueg 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 moe se mijenjati izvan objekta kojemu pripada.
Nije isto to i frozen.

ArgoUML ne podrava direktno read-only, ali vano ga je spomenuti.

23/50

Primjeri rada sa atributima (ArgoUML alat)

24/50

Operacije
Operacije (engl. operations) su procesi koje razred moe izvriti.
Drugim rijeima, to su vlastite metode i funkcije razreda

Za njih moemo odrediti:

Vidljivost (public,package,protected,private) Modifikatore (static,abstract,leaf,root,query) Istodobnost (sequential,guarded,concurrent) Parametre ili argumente
25/50

Operacije (1)
Operacije su aktivnosti koje klasa moe da obavi. operacija klase deklaracija procedure metod klase tijelo procedure Vrste operacija: Upiti

(operations)

Primer polimorfizma Nadtip operacija

metod

ne mijenjaju stanje sustava, tj. nemaju sporedne efekte vraaju proitanu vrednost iz klase redoslijed izvravanja im se moe mijenjati, a da se ne promijeni ponaanje sustava

Podtip operacija
metoda1

Podtip operacija
metoda2

Podtip operacija
metoda3
79

Modifikatori
mijenjaju stanje sustava obino nemaju rezultat
UML 2

Operacije (2)
Sintaksa operacija na UML-u

(operations)

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

Primer operacije

+ stanjeNa (datum:Datum) : Novac

vidljivost oznaava da li je operacija javna (+) ili privatna (-)
ime je niz znakova Objanjenje lista-parametara je lista parametara operacije Sintaksa parametara operacije je: smer ime: tip = podrazumevana-vrednost
ime, tip i podrazumevana-vrednost imaju isto znaenje 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)
80 UML 2

Primjer rada sa operacijama

Nasljeivanje (1/2)
Nasljeivanje (engl. inheritance) je koncept UML-a u kojemu objekt koji se nasljeuje je proiren u objektu koji ga nasljeuje Oblik UML asocijacije ili veze
Nasljedna veza izmeu razreda Jedan razred je roditelj (nadklasa) drugome razredu (dijete ili podklasa)

Nasljeivanje (2/2)
Generalizacija omoguuje stvaranje nadklase koja objedinjuje strukturu i ponaanje zajedniko za nekoliko klasa Specijalizacija omoguuje stvaranje podklase koja predstavlja dodavanje novih elemenata
Podklasa uvijek ima vie ili jednak broj svojstava u odnosu na nadklasu Podklasa nasljeuje od nadklase atribute, relacije i operacije Podklasa moe biti proirena atributima, operacijama ili relacijama Podklasa moe imati svoju implementaciju operacija koje je naslijedila

Primjer nasljeivanja

public class Vozilo { public int brojKotaa; }

specijalizacija

public class Automobil extends Vozilo { public int brojPutnika; public int zapreminaPrtljanika;

generalizacija

}
public class SportskiAutomobil extends Automobil { public final int brojCilindara; }

32/50

Generalizacija
Specijalizacija superrazreda u jedan ili vie podrazreda. Generalizacijski skup je oznaena grupa generalizacija s zajednikim superrazredom. Oznaka (katkad nazvana diskriminator) opisuje kriterije za specijalizaciju.

85

Izbjegavanje nepotrebne generalizacije (1/2)

Nepogodna hijerarhija razreda, Trebali bi biti instance (objekti). Vidi slijedeu sliku.
86

Izbjegavanje nepotrebne generalizacije (2/2)

Naini zapisivanja

Dijagram razreda

Dijagram objekata (razmatrat e se kasnije)

U dijagramu objekata nema oznaka brojnosti Slika pokazuje poboljani dijagram razreda uz pridrueni dijagram objekata (instanci) Razredi iz prethodnog dijagrama su ovdje objekti (instance) jednog razreda RecordingCategory
87

Rukovanje viestrukim diskriminatorima

Kreiranje generalizacije vie razine.
Dvije generalizacije koje dijele isti superrazred. (ovo je bolje rjeenje nego dvije odvojene hijerarhije)

88

Rukovanje viestrukim diskriminatorima

(viestruko nasljeivanje)

89

Izbjegavanje da instance moraju mijenjati razred

Instanca nikad ne treba mijenjati razred.

Studentov status se moe promijeniti, pa taj objekt (instanca) mora promijeniti razred (trai destrukciju kreaciju novog objekta). Jedno rjeenje: ukljui atribut attendanceStatus u razred Student te ne koristiti podrazrede (ali tako se gubi mogunost polimorfizma - specifinih metoda u razliitim podrazredima).
90

Suelje
Suelje (engl. interface) je kolekcija operacija koja specificira usluge nekog razreda
Suelje definira skup operacijskih specifikacija (tj. njihovih potpisa), ali nikada skup njihovih implementacija

Drugim rijeima, suelje je razred, ali bez atributa i sve operacije imaju samo tijelo, bez implementacije

Primjer suelja

public interface MojeSuelje { public boolean nekaMetoda(int arg1); public void josJednaMetoda(int arg1); }

Realizacija
Realizacija (engl. realisation) je veza UML-a koja oznaava ostvarenje suelja Razred realizira ili ostvaruje suelje
Veza realizacije (strelica) je usmjerena od razreda prema suelju

Realizacija je slina nasljeivanju samo to se kod realizacije nasljeuju samo operacije s parametrima, bez implementacije Realizacija u ArgoUML-u ima dva svojstva:
Supplier = Suelje Client = Razred koji ostvaruje suelje

Primjer suelja i realizacije

Java public class IzvedenaKlasa implements NekoSuelje { public int atributKlase; public IzvedenaKlasa myIzvedenaKlasa; public IzvedenaKlasa myIzvedenaKlasa; public void metodaSuelja(int param) { } public Boolean metodaKlase(String param) { return null; } } public interface NekoSuelje { public void metodaSuelja(int param); }
38/50

Stereotipovi
Stereotipovi (engl. stereotypes) su najvaniji nain proirenja definicije UML-a Definiraju suelja i enumeracije kao posebne vrste razreda. Mogu se primijeniti na pridruivanja i generalizacije.

Enumeracije
Enumeracije (engl. enumerations) su oblik tipova podataka koji sadravaju ureene parove imenovanih identifikatora i njima pridruenih vrijednosti
Te vrijednosti nazivaju se enumerirani literali

Koriste se za opis diskretnih vrijednosti

Napomene i komentari
Napomene predstavljaju objanjenja na dijagramu. Mogu biti nezavisne od drugih elemenata dijagrama, ali mogu biti i spojene isprekidanom linijom sa elementima dijagrama koje objanjavaju. Kao oznaka kraja linije moe se koristiti krui. Auto
Obuhvata kamionete i dipove, ali ne i motocikle

Komentar je tekst koji se moe dodati elementu dijagrama pomou dve crtice ispred teksta (--). Napomene i komentari se mogu pojaviti na svim vrstama dijagrama.
97 2

PRIMJERI UML-A

Primjer: Modeliranje organizacije fakulteta

Neki fakultet sastoji se od jednog ili vie zavoda, a svaki zavod od jedne ili vie zavodskih grupa. Zavodsku grupu ine zaposlenici. Zaposlenici mogu raditi i u nekoliko zavodskih grupa, ali ne mogu raditi na vie zavoda. Postoje dva konkretna tipa zaposlenika: predavai i asistenti. Svaki predava ima barem jedan kolegij koji predaje, a svaki asistent dri laboratorijske vjebe iz barem jednog kolegija. Svaki kolegij moe imati jednog ili vie predavaa i asistenata. Asistent ima jednog predavaa u funkciji mentora, a predava moe imati vie asistenata. Svaki kolegij se sastoji od vie predavanja i vie laboratorijskih vjebi i ima svoj naziv sastoji od vie redavanja i vie laboratorijskih vjebi i ima svoj naziv (String). Ukidanjem kolegija ukidaju se predavanja i laboratorijske vjebe, ali naravno, ne otputaju se zaposlenici koji kolegij dre. Student je zasebna kategorija u organizaciji fakulteta i u ovom modelu pretpostavite samo da slua jedan ili vie kolegija. I student i zaposlenik su osobe. Svaka osoba ima svoje ime i prezime. Dodatno, svaki zaposlenik ima svoj matini broj zaposlenika (String), a svaki student svoj JMBAG (String). Fakultet ima svoj matini broj (String) i naziv (String). Zavod ima svoj naziv (String) i broj rauna (String). Naziv i broj rauna zavoda nasljeuju 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 rjeenje

Zadatak 2.
Dijagramom klasa predstaviti logiku arhitekturu sistema za automatsku prijavu studenata za kurseve/predmete. Studenti biraju 4 primarna kursa/predmeta. Jedan kurs moe pohaati maksimalno 10 studenata. Minimalan broj studenata za predmet je 3. Jedan profesor moe da ponudi maksimalno 4 kursa, pri emu vie profesora mogu da ponude isti kurs.

Zadatak 2. rjeenje

I na kraju poglavlja
U izradi projekta bit e vam neophodni sljedei dijagrami: Dijagram klasa Dijagram sluajeva koritenja/Use case Dijagram aktivnosti Dijagram razmjetanja/rasporeivanja (opcionalno) Za rjeavanje nekih zadataka bit e poeljno koristiti i neke od preostalih dijagrama, recimo sekvencijalni U ovoj prezentaciji obradit e se detaljno use case i dijagrami aktivnosti