UML Prvi Dio

8/12/2019 UML Prvi Dio

1/39

1

Jedinstveni jezik modeliranja (Unified Modeling

Language) UML

1.1 Modeliranje u razvoju informacijskih sistema i UML evolucija

U procesu razvoja informacijskog sistema jednu od presudnih faza

predstavlja modeliranje sistema. Objektno-orjentirani razvoj softvera postaje

sve popularniji a razvojni proces kompjuterski podranih informatikih

sistema zahtijeva odgovarajui efikasan proces modeliranja. Tokom

posljednje tri dekade softver ininjeri su postajali svjesni da razvojobjektno-orjentiranih informacijskih sistema zahtijeva izgradnjuodgovarajue metodologije modeliranja sistema. Objektno orjentirana

paradigma, sama po sebi, pokazala se pogodna za postizanje cilja

dobrog konceptualnog modeliranja jer je objekt, kao osnovni konstrukt,obeavao mnogo direktniji pristup i prirodniju korespodenciju saentitetima iz realnog svijeta nego to su to strukture podataka. Sa drugestrane, instrumenti nasljeivanja i enkapsulacije podraavaju reusability

koncepata i komponenti softverskog proizvoda.

U tenji za ostvarenjem tog cilja, posljednjih godina, pojavili su se mnogi

specijalni pristupi i metodologije modeliranja sistema. Mnogo je napisa,

referenci i osvrta koje daju osnovne poglede na te metodologije i nude okvir

koji omoguava njhovo uporeivanja sa razliitih aspekata. Neke od tih

metodologija privukle su znaajnu panju a bile su i dobro dokumentirane.

Moe se rei da jasnoa predstavljanja i opisa neke metodologije najvie

ovisi o kvalitetu prikaza (posebno grafikog) koji obezbjeuje.To vrijedi za

osnovne konstrukte modeliranja kao i pravila njihovog komponiranja u vee

Modeliranje predstavlja jedan od osnovnih procesa ljudskoga uma.

Ono je usko vezano za nain ljudskog razmiljanja i rjeavanja problema.

Kao rezultat procesa koji nazivamo inteligentno ljudsko ponaanje,modeliranje predstavlja svakodnevnu aktivnost i veliki dio onoga to nas ini

ljudskim (inteligentnim) biima. Modeliranje izraava nau sposobnost da

mislimo i zamiljamo, da koristimo simbole i jezike, da komuniciramo, da

vrimo generalizacije na osnovu iskustva, da se suoavamo sa neoekivanim.

Ono nam omoguava da uoavamo obrasce, da procjenjujemo i predviamo,

da upravljamo procesima i objektima, da izlaemo znaenje i svrhu. Upravozato, modeliranje se najee posmatra kao najznaajnije konceptualno

sredstvo koje ovjeku stoji na raspolaganju (Rothenberg, 1989).


2/39

2

cjeline. Poeljno je da konstrukti kao i modeli komponovani od tih

konstrukata direktno i prirodno korespondiraju naoj vlastitoj

konceptualizaciji... (Mylopoulos/ Levesque 1984, p. 11).

Svaka metodologija ima svoju vlastitu notaciju. Problem je to razliitiljudi koriste razliitu notaciju pa je neophodno njihovo prevoenje i

usaglaavanje. esto, jedan simbol u jednoj notaciji ima potpuno razliito

znaenje od znaenja tog istog simbola u nekoj drugoj notaciji.

Grady Booch je, jo 1991 godine, predstavio prvo izdanje knjige sa OOmetodologijom. Ova metodologija se pokazala kao veoma pogodna za fazudizajna softverskog proizvoda a manje pogodna za fazu analize. Ivar

Jacobson pojavio se sa knjigom u kojoj je predstavio Objectorymetodologiju koja je bila veoma dobra za predstavljanje korisnikih zahtjeva

i iskustava a Jim Rumbaughpredstavlja OMTmetodologiju vrlo primjerenuza modeliranje u fazi analize a manje dobru za fazu dizajna. Dakle, svaka od

ovih istaknutih metodologija ima svoje prednosti i nedostatke.

Tokom mnogih godina ovo su bile tri primarne i kompetetivne OOmetodologije.

Unified Modeling Language UML pojavio se kada se James Rumbaugh

pridruio Grady Booch u Rational Software kompaniji. Njihova intencija je

bila da kombinuju svoje metodologije. Semantiki, one su bile veoma sline

pa je uglavnom trebalo prilagoditi simbole i unificirati ih. Rezultat je bio

UML 1.0. On je predstavljao veoma znaajan korak u udruivanju i

unifikaciji njihovih iskustava sa drugim, najboljim iskustvima i praksom

softver ininjeringa. Kasnije, kada im se pridruio i Ivar Jacobson, dodata je

sintaksa za use cases u verziji UML 1.1.

Sl. 1 Kako je nastao UML


3/39

3

Object Management Group prihvatio je UML1.1 specifikaciju u novembru

1997 i predstavio ga kao nezavisan industrijski standard. Neke manje izmjene

izvrene su u verzijama 1.3 i 1.4. Sada je u upotrebi verzija 2.0.

Sl. 2 razvoj UML-a

Od 1995. godine, UML pripada Object Management Group (OMG). (Naweb stranici www.omg.org, mogu se nai PDF verzije UML referenci).

1.2 Osnovni aspekti UML-a

jedan od bitnih razloga da je UML postao standardnijezik modeliranja je

njegova neovisnost o programskim jezicima.Skup notacija UML-a je jezik a

ne metodologija.


4/39

4

UML je definiran kao easy-to-learn ali semantiki vrlo bogat vizualni jezik

modeliranja (uz pripadajui pratei tekstualni jezik) koji inkorporira ideje

drugih jezika modeliranja i najbolju industrijsku praksu u razvoju softverskih

proizvoda. Jedna vana injenica je to da je UML baziran na iskustvuprimjene objektno-orjentiranih metoda u razvoju sistema. Glavni ciljkorienja UML-a je kreiranje modela aplikacije koji je kompletan,

konzistentan i precizan.

Raspoloivost razliitih alata za modeliranje omoguava ljudima koji se bave

razvojem softvera da odaberu onaj alat koji naglaava aspekt koji im je

vaan.

Najkrae reeno, UML je grafiki jezik za: specifikaciju, vizualizaciju,

konstrukciju i dokumentiranje.

1.3 osnovni gradivni blokovi UML su:

- elementimodela (things),- relacije(relationships) i

- dijagrami.

Jednostavni gradivni blokovi (konstrukti) koriste se za kreiranje velikih,

kompleksnih struktura.

Detaljniji pregled gradivnih blokova UML-a dat je na slici 3.

Sl. 3 UML gradivni blokovi


5/39

5

1.3.1 Elementi modela (things)

1.3.1.1 Klase

Znamo da klasa predstavlja skup objekata sline strukture, ponaanja i

relacija. U vremenu izvravanja aplikacije nastaju ekstenzije klase koje su

njene instance.

Za deklaraciju klase i specifikaciju njenih svojstava UML ima relativno

jednostavnu i jedinstvenu grafiku i simboliku notaciju i omoguava nam da

predstavimo upotrebu klasa na razliite naine. Neki elementi modeliranja,

sline forme kao klase (kao to su interfejsi, signali i korisnike funkcije)

notiraju se korienjem kljunih rijei uz simbol klase. Uglavnom, dijagram

klasa je mjesto gdje su klase deklarisane ali se koriste i u mnogim drugim

dijagramima.

U okviru modeliranja sistema, njegov koncept predstavljen je klasama. Klase

sadre strukturu podataka, ponaanje i relacije sa drugim elementima.

Grafika reprezentacija klase je pravokutnik, podijeljen horizontalnim

linijama na tri pravokutnika. Gornji pravokutnik sadri ime klase i drugaopa svojstva klase (ukljuujui stereotipe), srednji sadri listu atributa i

donji pravokutnik sadri listu operacija.

Grafika notacija klasa (deklariranje i korienje) i tekstualna notacija za

refernciranje klasa prikazana je na slici 4.

Atribut je prikazan kao tekst string. Sintaksa (default) je:

vidljivost ime : tip/izraz [ red multiplikativnosti ] = inicijalna-vrijednost {svojstvo-string }gdje je vidljivostjedna od:

+ javna# zatiena

- privatna~ pakovanje (package visibility)

Operacija (funkcija)je prikazana kao tekst string.Ponaanje objekta zavisi od njegove klase (svaki objekt zna svoju klasu).

Operacije (funkcije) uzimaju parametre nekog tipa i vraaju rezultat nekog

tipa.


6/39

6

Sl. 4 UML notacija klase i primjeri klasa Vrijeme i Tacka

Default sintaksa je:

vidljivost ime ( parametar-lista ) : vraeni-tip-izraz { svojstvo-string }

gdje je vidljivost jedna od:

+ javna

# zatiena- privatna

~ pakovanje (package visibility)


7/39

7

Apstraktna klasaje klasa koja nema svoje instance. UML notacijaapstraktne

klase prikazana je na slici 5.

Sl. 5 UML notacija apstraktne klase

Ugnjeena klasaje klasa koja je, u cjelini, smjetena unutar deklaracije

druge klase. Ako je klasa dodana drugoj klasi sa linijom i sidro simbolom

tada je ona deklarirana unutar imenskog prostora te klase. One su pogodne za

stvaranje objekata koje zahtijeva neka klasa da bi funkcionirala ali nema

vlastitu samostalnu funkcionalnost.

Sl. 6 UML notacija ugnjeene klase

1.3.1.2 Objekt

Kao to nam je poznato, objekt predstavlja instancu klase. Notacija objekta

izvedena je iz notacije klase tako to je ime objekta (i njegove klase)

podvueno u gornjem pravokutniku grafike reprezentacije.

Sintaksa:

objektime :klasaimeObjekt je prikazan sa imenom objekta, imenom klase (opcija) i vrijednostima

atributa(opcija).

Prisustvo nekog objekta u nekom specifinom stanju klase prikazuje se

korienjem sljedee sintakse:

objektime :klasaime [stanjeime-lista ]


8/39

8

Lista je, zarezom odvojen, popis imena stanja koja se mogu desiti

istovremeno.

Drugi dio grafike reprezentacije sadri atribute objekta i njihove vrijednosti

kao liste.

Svaka linija sa vrijednosti ima sljedeu sintaksu:

atributime :tip = vrijednost

Sl. 7 UML notacija za objekteRucakVrijemeklase Vrijeme ,startTacka

ikrajTackaklase Tacka

1.3.1.3 Interfejs

Interfejs je skup operacija (funkcija) koje svojom upotrebom odreuju servis

klase ili komponente (Booch, 1999). On predstavlja ugovor za te servise i

skup uslova koji se moraju ispuniti da bi taj ugovor bio zadovoljen.

Sl. 8 UML notacija interfejsa


9/39

9

1.3.1.4 Komponente

Komponenta je fiziki i zamjenjivi dio sistema koji omoguava i obezbjeuje

realizaciju skupa interfejsa (Booch, 1999).

Komponenta moe da bude: izvorni kod (shell scripts, data files, *.cpp), run

time komponenta (Java Beans, ActiveC kontrole, COM objekti, CORBA

objekti, DLL i OCX iz VB), izvrne komponente (*.exe fajlovi) itd.

Sl. 9 UML notacija komponente

1.3.1.5 Pakovanje (package)

Pakovanje je mehanizam ope namjene za organiziranje elemenata u grupe(Booch,1999).To je model element koji moe da sadri druge model

elemente. To je mehanizam grupiranja i nema definiranu semantiku. Jedan

element moe da pripada samo jednom pakovanju. Pakovanje moe da bude

veoma pogodno da bi se predstavila modularnost.

Sl. 10 UML notacija pakovanja

Neki od ostalih brojnih elemenata modela i njihove notacije bie

predstavljeni kroz UML dijagrame.


10/39

10

1.4. Relacije

UML definira brojne relacije razliitih vrsta. Relacija je veza meu

elementima modela. Najvanije relacije UML-a su asocijacija, generalizacija

i zavisnost (dependency).

1.4.1. Asocijacija je jedna od baznih relacija definiranih u UML. UMLnotacija asocijacije je puna linija koja spaja dva elementa (oba kraja mogu

biti spojena na isti element ali dva kraja imaju razliito znaenje).

Asocijacija, ustvari, predstavlja relaciju meu konceptima (klasama).

Link asocijacije ima dva kraja koji se nazivaju uloge (roles). Uloga kojaidentificira jedan kraj jedne asocijacije sadri ime, kardinalitet

(multiplikativnost), navigabilnost i tip .

a) asocijacija

b) asocijacija sa nazivom

c) asocijacija na istoj klasi (rekurzivna asocijacija)

Sl. 11 Primjeri UML notacije za asocijaciju

Klase igraju specifinu ulogu u asocijaciji.

Kardinalitet (multiplikativnost) indicira broj objekata koji su ukljueni u

asocijaciju (fakultet ima mnogo studenata a svaki student pohaa samo jedan

fakultet) . Specifikacije kardinaliteta mogu biti u skladu sa ulogama u

asocijaciji, dio unutar kompozicije, ponavljanje i druge namjene. Njenu

specifikaciju ini otvoreni skup pozitivnih brojeva. prikazuje se kao tekst


11/39

11

string sa, zarezom odvojenim, nizom cjelobrojnih intervala, gdje interval

predstavlja (mogue beskonaan) opseg cijelih brojeva u sljedeem formatu:

donja-granica ..gornja-granica

Sl. 12 Primjer za UML notaciju kardinaliteta

Uloga (role) moe imati strelicu koja pokazuje njenu navigabilnost

pokazuje koja klasa ima odgovornost za odravanje relacije izmeu klasa

(klasa School ima odgovornost za saznanje koji student pohaa...)

Sl. 13 Primjer navigabilnosti

* bilo koji broj, pie se i kao 0..*, or 0..n

n taan broj, npr. 1, 3, 0..1 nula ili jedan

1..* jedna ili vie , pie se i kao 1..n


12/39

12

Klasa asocijacija je element koji posjeduje svojstva asocijacije i klase. To je

est sluaj za mnogo preme mnogo asocijacije jer je teko pridati svojstva

bilo kojem kraju asocijacije.

a) Klasa asocijacijab)

b) Klasa asocijacija sa asocijacijom na samu sebe

Sl. 12 Primjeri klasa asocijacija

1.4.1.1. Agregacija(sadravanje)je asocijacija koja predstavlja part of(ili has-a) relaciju meu objektima odreene klase.

Pojam agregacija se esto koristi da bi se opisala struktura klase ili objekta

koji ukljuuju instance (objekte) drugih korisniki definiranih klasa. Postoje

dva tipa agregacije: kompozitna i dijeljena agregacija (sl. 13).


13/39

13

a) kompozitni tip agregacije

b) dijeljena agregacija

Sl. 13 Dva tipa agregacije

Primjedba: Student moe biti u

vie od jednog departmenta i

kurs moe biti palniran u vie

od jednog departmenta


14/39

14

1.4.1.2 Kompozicijaindicira da jedna klasa pripada drugoj klasi. Kompozicija

je tip agregacije koji povezuje ivotni vijek cjeline i njenih dijelova. To znai

da dijelovi ne mogu postojati ako vie ne postoji cjelina koju ine i da entitet

moe postojati kao dio samo jedne cjeline (agregata) (npr: Unitenjem baze

podataka unitavaju se i njene tabele ali unitavanjem tabela ne unitava se

baza podataka)

Kompozitna agregacija je stroga forma sadravanja, koja zahtijeva da

instanca dio bude, u odreenom vremenu, ukljuen u makar jednu

kompoziciju (cjelina) i da kompozitni objekat ima samoodgovornost za

raspored svojih dijelova.

Kao to smo vidjeli kompozicija je prikazana popunjenim romboidom na

kraju asocijativne relacije. Primjer kompozicije prikazan je i na slici 14.

Sl. 14 primjer kompozicije

Kao alternativu, UML nudi i grafiki-ugnjeenu formu koja je, u mnogim

sluajevima, pogodnija za predstavljanje kompozicije.

Sl. 15 Grafiki-ugnjeena forma kompozicije

Window

scrollbar : Slider2

title : Header

body : Panel

1

1


15/39

15

1.4.1.3 Generalizacija

Generalizacija, kao relacija, je drugo ime za nasljeivanje ili "is a" relaciju.

To je relacija izmeu dvije klase gdje je jedna klasa specijalna verzija druge

klase. Moemo rei da je to relacija izmeu vie opeg elementa (roditelj)

i vie specifinog elementa (dijete). Ovaj specifini element je u potpunosti

konzistentan sa opim i, dodatno, sadri potrebne informacije.

Na primjer, igra je vrsta osobe to znai da e klasa igra biti u relaciji

generalizacije sa klasom osoba.

Ponekad, u primjerima koda, postoje konfuzije izmeu nasljeivanja i

agregacije. U relaciji agregacija, agregat (cjelina) moe da pristupa samo

javnim funkcijama klase dio, dok nasljeivanje dozvoljava nasljeenoj

(izvedenoj) klasi da pristupajavnimizatienimfunkcijama osnovne klase.

Generalizacija je veoma vana u procesu modeliranja jer prepoznaje i

inkorporira slinosti to je direktna podrka principu ponovnog korienja

(reuseability). Koristi se za klase, pakovanja, sluajeve upotrebe (use case) i

druge elemente

Notacija za generalizaciju je puna linija koja ide od specifinog elementa kao

to je izvedena klasa (dijete) prema opem elementu osnovna klasa

(roditelj) i zavrava trouglastom strelicom na kraju prema osnovnoj klasi.

Sl. 16 primjer UML notacije za generalizaciju


16/39

16

1.4.1.4 Zavisnost

Relacija zavisnost pokazuje da promjena definicije jednog elementa (ili

pakovanja) moe uzrokovati promjenama u drugim elementima

(pakovanjima). To je relacija izmeu dva elementa modela koja povezuje

same te elemente modela i ne zahtijeva skup instanci za svoje znaenje. Ona

pokazuje da promjena ciljnog elementa, najee, zahtijeva promjenu

polaznog elementa koji su u relaciji zavisnosti.

Notacija zavisnosti je isprekidana linija sa strelicom, izmeu dva elementa

modela. Element na strani linije bez strelice (klijent) zavisi od elementa na

kraju sa strelicom (server). Opciono, moe da stoji stereotip i pojedinano

naziv.

Na slici 17 prikazane su razliite zavisnosti meu klasama.

Sl 17. razliite zavisnosti meu klasama

Neki od mnogih stereotipa zavisnosti prikazani su u sljedeoj tabeli:


17/39

17

Kljunarije

Naziv Opis

access Access Daje pravo jednom pakovanju da referencira

javne elemente drugog pakovanja (dodjela

prava vidljivosti)

bind Binding Vezivanje template parametara za aktulne

vrijednosti radi kreiranja neparametriziranih

elemenata

import Import Dodjela prava jednom pakovanju da

referencira javne elemente drugog pakovanja

sa dodavanjem imena javnih elemenata server

pakovanja klijent pakovanju.

use Usage Jedan element zahtijeva prisutnost drugog

elementa radi korektne implementacije ili

funkcionalnosti. Moe se dalje specificirati u

cilju pokazivanja prave prirode zavisnosti, kaonaprimjer, poziv operacije koja pripada drugoj

klasi, dodjela prava za access, stvaranje

objekta kao instance druge klase, itd.

Ako je kljuna rijejedan od stereotipa Usage

(call, create,instantiate, send), onda spada u a

Usagesa datim streotipom..

Sl. 18 Neki od stereotipa zavisnosti


18/39

18

1.5UML dijagrami

UML dijagrami su osnovni, veoma moni alati modeliranja koji se koriste u

svakoj fazi realizacije sistema.

Iako svaki od devet UML dijagrama prua pojedincu i razvojnom timu

razliite perspektive pristupa i vienja sistema, moemo ih, sa aspekata

modeliranja grupirati u pet grupa.

Tih pet grupa su: use-case model dijagrami, dijagrami statike strukture

sistema, interakcijski dijagrami, dijagrami stanja i dijagrami implementacije.

Sl. 19 UML dijagrami

1.5.1 Use-Case Model Dijagramisu UML alati neophodni, prije svega, da

dokumentuju sistemske zahtjeve kao kritini faktor od koga zavisi uspjena

realizacija razvoja projekta informacijskog sistema. Glavni alat je use case

dijagram.Ukratko, moemo rei da use-case dijagrami grafiki opisuju ko e koristiti

sistem i oekivanu interakciju korisnika sa sistemom. Djelii te interakcijske

funkcionalnosti su sluajevi upotrebe (use cases).


19/39

19

Da bi konstruirali use-case model dijagram moramo biti u stanju definirati

aktore i sluajeve upotrebe (use cases), identificirati ih iz dijagrama konteksta

i drugih izvora i opisati relacije koje se mogu pojaviti na use-case model

dijagramu.

Use case je opis skupa nizova akcija koje sistem izvrava i tako proizvodi

neki uoljiv rezultat vrijednost za aktora.

Aktor predstavlja koherentni skup uloga koje korisnik sluajeva upotrebe

(use cases) igra u interakciji sa ovim sluajevima upotreba (use cases).

Use case model je sainjen od skupa sluajeva upotrebe (use cases) koji

opisuju ta sistem treba da radi (sa namjerom da predstavi sve aspekte

funkcionalnosti koje sistem treba da obezbijedi).

Use case modelira dijalog izmeu aktora i sistema a sluajevi upotrebe (use

cases) se pokreu (okidaju) od strane aktora u cilju poziva odreene funkcije

u sistemu.

Sl. 20 Use case dijagram za jednostavni e-learning

Aktor: Uloga koju korisnik ima u odnosu na sistem (student, registrar,

nastavnik ...).

Aktori ne moraju biti ljudi. Aktori mogu dobiti vrijednosti od use case ili

uestvovati u njima.

Neophodno je napraviti opis use-case : generiki, korak-po-korak opisan

tok dogaanja sluajeva upotrebe ukljuujui interakcije izmeu aktora i

use case. Aktor je izvan granica sistema dok su sluajevi upotrebe (use cases)

unutar granica sistema.


20/39

20

Opis (specifikacija) use case (pisan prirodnim jezikom) sadri sljedee

elemente :

1. Use case ime

2. Aktori koji uestvuju

3. Ulazni uslovi

4. Tok dogaanja

5. Izlazni uslovi

6. Specijalni zahtjevi

Kada opisujemo kompleksan sistem, njegov use case model moe postati

prilino sloen i moe sadravati zalihost (redundancija). Tu sloenost

modela moemo reducirati tako da identificiramo slinosti razliitih

sluajeva upotrebe (use cases). U fazi objektno orjentirane analize svaki,

prethodno definiran, use case mora biti detaljnije finije definiran

ukljuujui sve vie detalja koji proizilaze iz naeg otkrivanja injenica

(naprimjer: definiranje zahtijeva za korisniki interfejs). Na sl. 21 prikazan je

use case dijagram za jednostavni sistem kataloke prodaje i na sl. 22

prikazane su neke od relacija izme

u sluajeva upotrebe u sistemu.

Sl. 21 Use case dijagram za sistem kataloke prodaje


21/39

21

Sl. 22 neke od relacija u sistemu kataloke prodaje

Na slici 23 prikazan je use case dijagram modela svemirske letjelice za

snimanje planeta odravanje visine.

Sl. 23 use case model za dio upravljanja svemirskom letjelicom

Podesavanje visine

Komunikacija

Kriptiranje

Snimanje planeta

Provjera visineKorekcija visine

Komandant navigacije

Senzor visine

Reakcioni kotacEtalon (Thruster)

sa Etalonom

sa reakcionim

kotacima

Extension point:

Sigurnost

Object-Oriented Model

Model: OO M odel UC01

Package:

Diagram: UseCaseDiagram_1

Author: max Date : 11. 08. 05

Version :


22/39

22

Normalno je da se ovi use case dijagrami, u kasnijim fazama, detaljnije

definiraju i razlau. Tako bi use case snimanje planetasa slike 23 mogao da

izgleda ovako (sl. 34):

Sl. 24 use case dijagram- detaljniji

snimanje planeta

snimanje slika

prenos slika

napajanje sistema

usmjeravanje kamere

Navigacija ka planeti

Naucnik

Inzenjer leta


Model: OO M odel UC01_1

Package:Diagram: UseCaseDiagram_2


Version :

prijem komandi


23/39

23

1.5.2 Dijagrami statikih strukturaDva dijagrama koja modeluju statike strukture sistema su dijagram klasa i

dijagram objekata.

1.5.2.1 Dijagrami klasa

Dijagrami klasa su centralna taka gotovo svakog objektno orjentiranog

metoda ukljuujui i UML. Oni pokazuju objekte klasa sistema i relacije

meu tim objektima klasa. Klase i objekti su, u UML, prikazani kao

pravougaonici sa tri dijela u kojima se nalaze: naziv, atributi i operacije. Ime

objekta je napisano podvueno to indicira da je to instanca klase.

U prethodnim poglavljima obradili smo nekoliko vrsta relacija. Relacija

agregacije je vrlo esto najradije primjenjena jer je pogodna da naglasi aspekt

hijerarhije relacije.

Generalizcija je relacija izmeu ope klase (osnovne) i jedne ili vie

specijaliziranih klasa. Generalizacija nam omoguava da opiemo sve

atribute i operacije koje su zajednike za vie klasa.Notacija apstraktne klase razlikuje se po tome to je ime klase napisano u

italik formatu.

Na slikama 25 i 26 dati su primjeri dijagrama klasa.


24/39

24

Sl. 25 Primjer dijagrama klasa


25/39

25

Sl. 26 Primjer dijagrama klasa

1.5.2.2 Dijagrami objekata

Dijagrami objekata su veoma slini dijagramima klasa, u uskoj su vezi sa

njima i opisuju statiku strukturu sistema u odreenom trenutku vremena.

Mogu se koristiti i da testiraju preciznost dijagrama klasa.

Budui da je objekt instanca klase, dijagram objekata moe se posmatrati kao

instanca dijagrama klasa. On modelira aktualne objekte (instance) i pokazuje

tekue vrijednosti atributa objekta. Koristei dijagrame objekata osoba koja

razvija softver moe da vidi sliku objekata sistema u nekom naroitom

vremenskom trenutku.


26/39

26

Sl. 27 Primjer dijagrama objekata

1.5.3 Dijagrami interakcijeModeliranje interakcije u sistemu znai posmatranje i predstavljanje skupa

objekata, relacija meu objektima i poruka koje objekti razmjenjuju.

U ovu grupu UML dijagrama spadaju dijagrami sekvenci i kolaboracijski

dijagrami. Ovi dijagrami se koriste za modeliranje dinamikog ponaanja

sistema.

1.5.3.1 Dijagrami sekvenci

Dijagrami sekvenci prezentiraju interakcije meu klasama u smislu razmjene

poruka u vremenu.

Nain ponaanja jednog objekta, posmatrano sa naroitog aspekta, opisan je

ulogama klase.

Preporuivo je koristiti simbole objekata za ilustraciju uloga klase ali, pri

tome, ne navoditi listu atributa objekta.


27/39

27

Vertikalne, isprekidane linije predstavljaju linije ivota objekata a boksovi u

obliku pravougaonika na tim linijama predstavljaju vremena kada objekti

izvravaju svoje zadatke.

Linije sa strelicama predstavljaju poruke u komunikaciji meu objektima.

Dijagrami sekvenci se koriste da formalizuju ponaanje sistema i da vizualno

pokau komunikaciju. Veoma su korisni za identifikaciju dodatnih objekata

koji uestvuju u use case. Naziv objekata koji uestvuju u use case je

participating objects.

Ukratko, moemo rei da dijagrami sekvenci predstavljaju interakciju koja se

dogaa meu objektima. Dijagrami sekvenci, takoe, uoavaju servise kao

vezu meu ponaanjem use case i objekata Aktori se prikazuju u krajnjoj

lijevoj koloni dijagrama.

Primjer dijagrama sekvence prikazan je na slici 28.

Sl. 28 primjer dijagrama sekvenci

1.5.3.2 Kolaboracijski dijagrami

Kao to smo vidjeli, dijagrami sekvenci fokusiraju se na prikaz poruka u

vremenu. Kolaboracijski dijagram je, u nekim aspektima slian dijagramu

sekvenci ali se on fokusira na saradnju objekata. On predstavlja interakciju


28/39

28

izmeu objekata kao niza sekvencnih poruka. Kolaboracijski dijagrami

opisuju statiku strukturu i dinamiko ponaanje sistema.

Ponaanje objekata opisano je ulogama klase. Kada se koristi UML simbol za

objekat, radi ilustracije uloga klase, ne izlistavaju se atributi objekta.

Za razliku od dijagrama sekvenci, kolaboracijski dijagrami nemaju

eksplicitnog naina da oznae vrijeme nego numeriu poruke po redu

izvravanja.

a) dijagram kolaboracije bacanje dvije kocke

b) dijagram kolaboracije - Narudba

Sl. 29 Primjeri dijagrama kolaboracije


29/39

29

1.5.4 Modeliranje stanja

1.5.3.3 Dijagrami stanja

Dijagrami stanja opisuju dinamiko ponaanje sistema kao odgovor na

spoljne stimulacije. Oni su, posebno, korisni u modeliranju reaktivnih

objekata ije stanje je okidano odreenim dogaajima.

Stanje predstavlja situaciju u toku ivotnog vijeka objekta a ilustruje se

pravougaonikom sa zaobljenim kutovima.

1.5.3.4Dijagrami aktivnosti

Dijagrami aktivnosti ilustruju dinamiku prirodu sistema modeliranjem toka

kontrole od jedne aktivnosti do druge aktivnosti. Aktivnost predstavlja jednu

operaciju na nekoj klasi u sistemu koja rezultira promjenom stanja sistema.

Tipino, dijagrami aktivnosti se koriste za modelovanje toka rada ili biznis

procesa i interne operacije.

1.5.4 Dijagrami implementacijeU ovu posljednju grupu UML dijagrama spadaju dijagrami komponenti i

dijagrami rasporeda (deployment).

1.5.4.1 Dijagrami komponenti

Dijagrami komponenti opisuju organizaciju fizikih komponenti softvera,

ukljuujui i izvorni kod, run-time (binarni) kod, i izvrne module.

Kao to smo ranije napomenuli, komponenta je fiziki gradivni blok sistema

ija je UML notacija data na slici 9.

Interfejs opisuje grupu operacija koje komponenta koristi ili kreira.

Sl. 30 primjer dijagrama

komponenti


30/39

30

Sl. 31 Dijagram komponenti Learning Content Mangment Sistema (LCMS)

Na dijagramu su vidljive komponente, pakovanja, user interfejsi i relacije.

1.5.4.2 Dijagrami rasporeda

Dijagrami rasporeda pokazuju fizike resurse sistema, vorova, komponenti i

veza i ilustrira relaciju izmeu run-time komponenti i hardverskih vorova.

Komponente su self-contained entiteti koji pruaju servis drugim

komponentama ili aktorima (naprimjer: Web server je komponenta koja

obezbjeuje servise Web pretraivaima a pretraiva, kao Netscape,

komponenta koja prua servise korisniku). Distribuirani sistemi mogu da se

sastoje od mnogo interaktivnih run-time komponenti.


31/39

31

Error!

Sl. 32 primjer dijagrama rasporeda


32/39

32

Prilog: primjer korienja use case dijagrama i dijagrama sekvenciza modeliranje sistema on-line prodaje knjiga.

Osnovni use case dijagram sl. 33:

Sl. 33 use case dijagram sistema on-line prodaja knjiga

Ovaj dijagram se moe prikazati i upotrebom pakovanja sl. 34.

Sl. 34 dijagram

sistema on-line

prodaja knjiga

sa korienjem

pakovanja.


33/39

33

Ovaj dijagram prikazuje pogled na korisnikove (kupac) raspoloive

aktivnosti u predloenom sistemu logiranje, pretraivnje skladita knjiga,

izbor stavki i obavljanje kupovine.

detaljniji use case dijagrami (sl. 35, 37, 39 i 41):

UC01-1:Mng korisnika (kupca)

Kupac treba imati mogunost logiranja u sistem. Ako nije veregistriran

kupac e dobiti prompt za registraciju.

Sl. 35 use case dijagram UC01_1

Osnovni elementi opisa:

Login

Registracija u Book Shop

Korisnik (kupac)


Model: OOM UC01_1

Package:

Diagram: UseCaseDiagram

Author: max te : 12. 08. 05

Version :


34/39

34

Login

Use Case: Korisnik on-line sistema za prodaju knjiga treba da ima

mogunost logiranja u sistema. Konekcija sa sistemom je preko sigurnog

HTTP (SSL)

Zahtjevi: Predloeni: Login u sistem. Predloeni: Kriptiranje detalja o korisniku preko HTTPS. Predloeni: Odjava iz sistema. Predloeni: Idi na ekran registracije za neregistrovanog korisnika.

Veze:

Koristi aktor Kupac. Kupac koristi login use case za pristup sistemu. Extends (proiruje) link od use caseRegistracija u Book Shop. Ovaj use

case proiruje Loginuse case u situacijama kada korisnik nema

"account" u on-line knjiari.

Realizacija link po zahtjevu 1.01 Logiraj se na Web stranicu Realizacija link komponentaBusiness Logic Realizacija link komponentaASP Stranica Realizacija link ekranLogin

Scenario:Login {Osnovna staza}.

1. Korisnik pristupaLoginstranici;

2. Korisnik unosi korisniko ime i lozinku;

3. Sistem provjerava uneene podatke;

4. Ako je provjera uredu korisnik pristupa sistemu book store;

5. Ako provjera nije uredu korisnik moe pokuati ponovo;

Registracija u Book ShopUse Case: Korisnik koji nije registriran unosi podatke i dobija account u

sistemu knjiare. Ovo ukljuuje detalje kao to su ime. email, adresa, telefon,

preference itd.

Zahtjevi:

Predloeni: Registrar knjiare. Korisnik moe da se registruje u sistemknjiare.

Predloeni: Pohrana preferenci. Predloeni: Uzeti email i podatke za kontakt.

Ograni

enja: Predloeni Post-uslov : Korisnik registriran.


35/39

35

Predloeni Pred-uslov : Korisnik nije registriran.

Veze:

Koristi aktor Korisnik. Korisnik e koristiti Registar use case da seregistrira u sistem knjiare ako venije lan.

Extends (proireni) link na use caseLogin. Registrar use case proirujeLogin use case u situacijama kada korisnik nema account u sistemu

knjiare. Kada je jednom registriran moe izvriti login use case.

Realizacija link zahtjev 1.02 Registracija novih korisnika u sistem Realizacija link od pakovanjaLM01-1: Korisnik Domena Realizacija link od ekranRegistriraj se kao novi korisnik

Scenario:Registrar {Osnovna staza}.

1. Korisnik unosi eljeno korisniko ime, osobne detalje i lozinku

2. Sistem provjerava da se ime vene koristi

3. Ako je uredu korisnik je registriran u sistem knjiare

4. Ako nije uredu od korisnika se trai da unese novo imeJasno je da ovaj scenario treba predstaviti dijagramom sekvenci (sl. 36).

Login

Provjera korisnika

Provjera detalja korisnika

Detalji o korisniku

Provjereno

Rezultat

Korisnik (kupac)

Login screen Sigurnost Manager Korisnici


Model: OOM UC01_1

Package:

Diagram: SequenceDiagram_1


Version :

Sl. 36


36/39


37/39

37

Sl. 38 dijagram sekvenci za UC01_2

Pretrazivanje

Pretrazivanje

Pretrazivanje

Lista knjiga

Kupac

Ekran pretrazivanja Katalog Autor


Model: OOM UC01_2

Package:

Diagram: SequenceDiagram

Author: max te : 12. 08. 05Version :


38/39


39/39

39

UC01-4: Stanje narudzbe

Sl. 41 use case dijagram UC01_4

Pregledaj status narudzbe

Ponisti narudzbu

Korisnik (kupac)

Korisnik moze da pregleda i

modificira narudzbu prije


Model: OOM UC01_4

Package:Diagram: UseCaseDiagram_5

Author: maxDate : 12. 08. 05

Version :

NadjiNarudzbu

NadjiNarudzbu

GetDetalji

PonistiNarudzbu

PonistiNarudzbu

PonistiNarudzbu

NarudzbaDetalji

Rezultat

Rezultat

ObustavaProcesa

Kupac

Narudzba detalji Upravljanje narudzbom Narudzba


Model: OOM UC01_4

Package:

Diagram: S equenceDiagram_4


Version :

Sl. 42 dijagram

sekvenci za

UC01_4

UML Prvi Dio

Documents

Transcript of UML Prvi Dio