P10 Uml

MODELIRANJE I IMPLEMENTACIJA INFORMACIJSKIH SUSTAVA
Objektno orjentirani pristup modeliranju i UML

Prof.dr.sc. Josip Mesari
J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08
Objektno modeliranje i UML
Napomena
Materijali u ovoj prezentaciji predstavljaju pomoni radni materijal za svladavanje gradiva na predmetu Modeliranje i izgradnja IS-a. Sadre dijelove koji se moraju revidirati i nadopuniti uz dozvole citiranih autora i izvora.
Objektno orijentirano modeliranje

Zato objektno orijentirano modeliranje ? Problemi strukturiranog modeliranja i programiranja: programska procedura za neku akciju (koja moe biti zajednika za vie kompleksnih aplikacija) se programira jedamput u jednoj aplikaciji i kopiranjem se prenosi u druge aplikacije. Ako se programska struktura za tu akciju mora promijeniti onda se izmjene moraju raditi u svim aplikacijama Strukturno programiranje je orijentirano podatcima podatcima i informacijama prilagoavaju se dijelovi koda; problem se javlja kada se mijenjaju poslovna pravila
J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08 Objektno modeliranje i UML
Objektno orijentirano modeliranje

U objektno orijentiranom pristupu kreiraju se blokovi koda koji se zovu objekti i koji se koriste od strane razliitih aplikacija; promjene u kodu ako je to potrebno izvode se na samo jednom mjestu Ideja: definirajte sve mogue zajednike objekte, skoncentrirajte se na specifinosti pojedinih aplikacija i zajednike objekte ugraujte po potrebi u njihovu strukturu U objektno orijentiranom pristupu fokusiramo se i na podatke ali i na ponaanje sustava- rezultat je elastian i fleksibilan sustav
Principi objektno orijentirane paradigme

ENKAPSULACIJA I SKRIVANJE Aplikacija se dijeli na manje dijelove koji su meusobno funkcionalno povezani: Primjer: Raun u banci ima podatke broj rauna, saldo, ime klijenta, adresa,tip rauna, kamate, datum otvaranja; Ponaanje (operacije) uz raun: otvaranje, zatvaranje, depozit, isplata, promjena tipa, promjena adrese; Izvodi se enkapsulacija (uahurivanje) podataka i ponaanja u objekt koji se zove raun Sve promjene u bankarskom sustavu koje se tiu rauna korisnika i naina njegova koritenja putem razliitih aplikacija (u banci, ATM-u, putem interneta) bit e implementirane u objekt raun.

NASLJEIVANJE Dvije vrste objekata: roditelj i dijete Dijete ima nasljeene karakteristike roditelja; to znai ako se moraju mijenjati karakteristike djece dovoljno je tu promjenu nainiti na objektu roditelj i promjene na objektima (programima) koji su nasljednici (djeca) e se izvriti automatski Primjer: vie tipova bankarskih rauna raun oroene tenje, tekui raun, kreditna kartica... Imaju neke zajednike podatke a neki su specifini; zajedniki podatci i zajednika ponaanja pojedinanih tipova rauna kreirat e se u objektu roditelj - raun

POLIMORFIZAM Upotreba jedne te iste funkcionalnosti u razliitim aplikacijama; Primjer: crtanje razliitih oblika: linije, kruga, poligona... Pozivom zajednike funkcije za objekt
UML unified modelling language

Jezik za: Vizualiziranje - skup grafikih simbola iza kojih stoji dobro definirana semantika. Na taj nain, model koji je napravio jedan programer moe jednoznano proitati i razumjeti drugi programer. Specificiranje - specificiranje znai izgradnju modela koji su precizni, jednoznani i kompletni. UML se bavi specifikacijom svih vanih odluka analize, dizajna i implementacije koje se moraju donijeti u razvoju i pokretanju sustava programske podrke. Konstruiranje - mogue mapiranje izmeu modela u UML-u i programskih jezika kao to su Java, C++,Visual Basic ili tablica u relacijskoj bazi ili spremnika u objektno-orijentiranoj bazi. Na taj nain su stvari, koje se najbolje predstavljaju grafiki, napravljene u UML-u, a stvari koje se najbolje predstavaljaju u tekstualnom obliku, u programskom jeziku. Dokumentiranje dijelova sustava programske podrke -Iz prave programerske organizacije, uz sam izvrni kod, na trite izlaze i razne dodatne stvari kao to su:
Zahtjevi na sustav Arhitektura Dizajn Programski kod Projektni planovi Testovi Prototipovi
UML unified modelling language

Zato je UML jezik: ima rjenik i pravila za kombiniranje rijei u svrhu komunikacije. Jezik za modeliranje je jezik iji se rjenik i pravila fokusiraju na konceptualnu i fiziku reprezentaciju sustava. Sustavi programske podrke zahtijevaju jezik koji se bavi razliitim pogledima na arhitekturu sustava, kako se sustav razvija kroz razvojni ciklus. Rjenik i pravila jezika kao to je UML govore kako treba kreirati i itati dobro formirane modele, ali ne govore koje modele treba kreirati i kada ih treba kreirati. To je uloga razvojnog procesa. Dobro definiran proces vodi korisnika u odluivanju koje komponente sustava treba kreirati, kada ih treba kreirati, koje aktivnosti koristiti za njihovo kreiranje i kako koristiti te komponente u mjerenju i kontroli projekta kao cjeline. (Izvor:Darije
Ramljak, VIZUALNO MODELIRANJE OBJEKTNO ORIJENTIRANIH SUSTAVA KORITENJEM UML-A, FER ZAGREB, Zavod za primijenjenu matematiku, 2001)
Zato unificirani
UML unifikacija obuhvaa slijedee:
Razvitak ivotnog ciklusa; UML se moe koristiti za analizu i ininjerstvo korisnikih zahtjeva do implementacije cjelokupnog sustava Primjenskih domena:Application domains: UML se koristi u fuzioniranju aplikacija razliitog tipa Implemementaciju jezika i platformi : UML je jezino i platformski neovisan Razvojnih procesa: UML podrava unifikacije procesa Vlastitog internog koncepta: UML se bazira na skupu koncepata koji se primjenjuju konzistentno kroz razvoj notifikaciji
Pretpostavke za koritenje UML-a

Osnovna premisa za upotrebu UML-a je da se softverski sustav moe modelirati kao kolekcija kolaborativnih objekata Dva su glavna komplementarna dijela UMLmodela:
Statike strukture: konstitutivni objekti + njihovi odnosi Dinamiko ponaanje = funkcionalnost sustava osigurana pomou kolaboracijskih objekata
UML- strukture
Tri glavna dijela u UML strukturi: Gradivni blokovi Zajedniki mehanizmi Arhitektura
[Arlow & Neustadt 2002]
UML gradbeni blokovi modelski elementi

Rjenik UML-a obuhvaa tri tipa graevnih blokova: Stvari Relacije Dijagrame Stvari su apstrakcije i one su glavni dijelovi UML-a. Relacije povezuju te iste stvari, a dijagrami grupiraju interesantne kolekcije tih stvari u bilo kojem modelskom elementu
UML gradbeni blokovi Stvari

Stvari (things)
UML stvari ili modelski elementi mogu biti

Strukturalne stvari (structural things) tj. klase, suelja, sluajevi koritenja, komponentni vorovi (openito: imenice u UML modelu) Stvari s ponaanjem (Behavioural things), kao to su interakcije i automati stanja (state machines) (openito glagoli u UML modelu) Grupirajue stvari (Grouping things), kao to su paketi koji prikupljaju odreene modelske elemente Oznaavajue stvari (Annotational things), tj. oznake koje se mogu dodavati bilo kojem modelskom elementu
UML gradbeni blokovi Strukturalne stvari

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.

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
Klasa

Suelje - kolekcija operacija koja specificira 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 operacijskih specifikacija (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, ve e obino biti vezano za odreenu klasu ili komponentu koja ga realizira.
Suelje

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
Suradnja

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
Sluaj koritenja

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
Komponenta

vor (eng. node). To je fiziki element koji postoji pri radu sustava i predstavlja 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
vor
UML gradbeni blokovi Stvari s ponaanjem

Stvari sa ponaanjem su dinamiki diojelovi 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
Interakcija
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.
Automat stanja
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.
Paket
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
Cedulja (note)
UML gradbeni blokovi Relacijske stvari u UML-u

Postoje etiri tipa relacija unutar UML modela: Ovisnosti (eng. dependency) Asocijacije (eng. association) Generalizacije (eng. generalization) Realizacije (eng. realization)
UML Building Blocks: Relationships.

UML relationships indicate how two or more things are interconnected. Relationships apply to structural and grouping things and are of four kinds [Fig. 1.5, Arlow 2002]:

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)
Ovisnost

asocijacija, je strukturalna relacija koja opisuje skup veza izmeu objekata. Kombinacija (eng. aggregation) je specijalan 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.
Asocijacija

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
Generalizacija

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).
Realizacija
UML gradbeni blokovi 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.
UML Building Blocks: Diagrams.

Dijagrami osiguravaju pogled (prozor) na modele Osiguravaju mehanizme za unos informacija u model Dvije su grupe dijagrama: 1. opisuju statike strukture (modele) 2. opisuju dinamike strukture
Izvor: CS 426, Senior Projects, Chapter 1: What is UML? Chapter 2: What is UP?, [Arlow and Neustadt, 2002], January 26, 2006, http://www.cse.unr.edu/~dascalus/
UML Building Blocks: .Diagrams

The nine types of UML diagram [Fig. 1.6, Arlow & Neustadt, 2002]

UML v.1.5 ukljuuje devet takvih dijagrama: Dijagram klasa Dijagram objekata Dijagram sluajeva koritenja Dijagram toka Dijagram suradnje Dijagram stanja Dijagram aktivnosti Dijagram komponenata Dijagram pokretanja

UML 2.0 definira ak 13 dijagrama podijeljenih u tri kategorije:
est dijagrama predstavlja statike strukture Tri predstavljaju ope tipove ponaanja etiri predstavljaju razliite tipove interakcija
Strukturni Dijagrami ukljuuju Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. Diagrami ponaanja susustava ukljuuju Use Case Diagram (used by some methodologies during requirements gathering); Activity Diagram, and State Machine Diagram. Interakcijski dijagrami izvedeni su iz prethodne dvije grupe ili ukazuju na specifina stanja sustava: Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram (Izvor:ttp://www.omg.org/gettingstarted/what_is_uml.htm#12DiagramTypes)

Dijagram klasa prikazuje skup klasa, suelja i suradnji i njihove meusobne relacije. Ti dijagrami su najei u objektno-orijentiranim sustavima. Dijagrami klasa bave se statikim pogledom na dizajn sustava, a oni koji ukljuuju i aktivne klase, bave se i statikim pogledom na procese u sustavu. Dijagram objekata prikazuje skup objekata i nihove relacije u sustavu. Dijagrami objekata predstavljaju statiku snimku instanci stvari koje se nalaze u dijagramu klasa. Oni se bave statikim pogledom na dizajn i procese sustava, kao i dijagrami klasa, ali iz perspektive pravih prototipova, tj. pravih objekata u sustavu.
Dijagram sluajeva koritenja prikazuje skup sluajeva koritenja i glumaca (eng. actors specijalan tip klase) i njihovih relacija. Dijagrami sluajeva koritenja bave se statikim pogledom na sluajeve koritenja u sustavu i vrlo su vani kod organiziranja i modeliranja ponaanja sustava. Dijagram toka i dijagram suradnji su tipovi interakcijskih dijagrama. Interakcijski dijagram prikazuje interakciju, koja se sastoji od skupa objekata i njihovih relacija, zajedno sa porukama koje se mogu slati izmeu njih. Interakcijski dijagram bavi se dinamikim pogledom na sustav. Dijagram toka je interakcijski dijagram, koji daje naglasak na vremensku dimenziju i poredak poruka. Dijagram suradnji je interakcijski dijagram, koji daje naglasak na strukturalnu organizaciju objekata koji primaju i alju poruke. Oba dijagrama su izomorfni, to znai da se svaki od njih moe lako transformirati u drugi.

Dijagam stanja prikazuje automat stanja, koji se sastoji od stanja, prijelaza, dogaaja i aktivnosti i bavi se dinamikim pogledom na sustav. Dijagrami stanja su vrlo vani u modeliranju ponaanja suelja, klasa ili suradnji i daju naglasak na ponaanje objekta odreeno slijedom dogaaja, to je jako korisno u modeliranju reaktivnih sustava. Dijagram aktivnosti je specijalan tip dijagrama stanja koji pokazuje tok iz aktivnosti u aktivnost unutar sustava i bavi se dinamikim pogledom na sustav. Vrlo su vani u modeliranju funkcija sustava i daju naglasak na tok kontrole izmeu objekata. Dijagram komponenata prikazuje organizacije i ovisnosti izmeu skupa komponenata. Dijagrami komponenata bave se statikim pogledom na implementaciju sustava. Povezani su sa dijagramima klasa tako da su komponente tipino mapirane na jednu ili vie klasa, suelja ili suradnji. Dijagram pokretanja prikazuje konfiguraciju izvrnih procesnih vorova i komponenata koje se izvode na njima. Dijagrami pokretanja bave se statikim pogledom na pokretanje arhitekture sustava. Povezani su sa dijagramima komponenata tako da vor tipino obuhvaa jednu ili vie komponenata.
Dijagram sluajeva upotrebe: primjer bankomat
Transfer novca Deponiranje novca
Bankovni slubenik Promjena PIN-a
Klijent Odbijanje isplate Pregled bilance Uplata Kreditni sustav
Dijagram aktivnosit za otvaranje rauna

Usluge klijentima Menager kreditnog odjela Klijent
Prikupljanje podataka o klijentu
Kreiranje novog kreditnog rauna
Raun Inicijalizacija
Postavljanje kreditnog limita Provjera povjesnih podataka Izvjee povjesnih podataka
Ne udovoljava
Odbiti raun
Udovoljava
Odobriti raun
Raun odbijen
Raun odobren
Prihvaa kreditne uvjete
Raun otvoren
Potpisuje ugovor
Dijagram sekvenci za izdavanje gotovine na bankomatu

Klijent ita kartica ATM zaslon Raun klijenta Izdava gotovine
1: Prihvaa karticu 2. ita broj kartice
3: Inicijalizira zaslon 4: Otvara raun 5: Trai PIN 6: Unosi PIN 7: Provjerava PIN 8: Trai transakciju 9: Izabire transakciju (odbijanje) 10: Trai iznos 11. Unosi iznos 12: Odbija iznos 13: Provjerava iznos na raunu 14: Oduzima iznos 15 Izdaje gotovinu 16. Izdaje potvrdu
17: Izbacuje karticu
Dijagram suradnje za podizanje novca s bankomata
Dijagram klasa za primjer bankomata
Dijagram stanja rauna
Odbijanje (Bilanca <0) Otvori Depozit (Bilanca < 0) Prekoraenje DO: Poalji obavjest klijentu
Zatvaranje na zahtjev klijenta

Zatvoren
Provjera bilance (30 dana)
Dijagram komponenti
ATM-exe
ita kartica
Izdava novca
ATM-ekran
ATM-ekran
Izdava novca
Dijagram razmjetaja - vorova
Banka Server baze Oracle Server
Regionalni ATM server
Printer
ATM 1
ATM 2
Pravila UML-a
Graevni blokovi UML-a ne mogu se samo nabacati kako bi tvorili model. Kao i svaki jezik, i UML ima brojna pravila koja specificiraju kako dobro formiran model treba izgledati. Dobro formiran model je semantiki konzistentan i u skladu je sa svim drugim modelima sa kojima je povezan. UML ima semantika pravila za:
Imena - Kako se mogu nazivati stvari, relacije i dijagrami Doseg - Kontekst koji daje specifino znaenje imenu Vidljivost - Kako ta imena mogu vidjeti i koristiti drugi korisnici Integritet - Kako stvari na pravi nain i konzistentno povezati sa drugima Izvoenje - to znai pokrenuti ili simulirati dinamiki model
Modeli koji se grade za vrijeme razvoja sustava koji se oslanja na programsku podrku tee ka poveanju i mogu ih vidjeti razni korisnici u razliito vrijeme i na razliit nain. Stoga razvojni timovi ne grade samo dobro formirane modele ve i modele koji su:
Neotkriveni Neki elementi su sakriveni kako bi se pojednostavnio pogled Nekompletni Neki elementi mogu nedostajati Nekonzistentni Integritet modela nije garantiran Ovi, ne dobro formirani modeli, su neizbjeni u toku razvoja dok se mnogi detalji sustava tek otkrivaju. Pravila UML-a potiu, ali ne prisiljavaju na bavljenje najvanijim pitanjima analize, dizajna i implementacije koji usmjeravaju model da, kroz vrijeme, postane dobro formiran.
UML Common Mechanisms

UML has four common mechanisms that are applied consistently, in different contexts, throughout UML [Fig. 1.7, Arlow 2002]
Standardni mehanizmi u UML-u

Izgraivanje modela je jednostavnije ako postoji konformizam prema nekim predlocima koji imaju standardna zajednika svojstva. Tako je i sa UMLom jer u njemu postoje etiri standardna mehanizma ijom primjenom se dobiva konzistentnost kroz sam jezik.
Specifikacije (eng. specifications) Ukrasi (eng. adornments) Podjele (eng. common divisions) Mehanizmi proirivosti (eng. extensibility mechanisms)
UML Common Mechanisms: Specifications

Specifications are textual descriptions of the semantics of UML elements. Example, Fig. 1.8 [Arlow & Neustadt, 2002]
Standardni mehanizmi u UML-u - Specifikacije

UML je puno vie od samog grafikog jezika jer iza svake grafike notacije stoji specifikacija koja daje tekstualan opis sintakse i semantike tog graevnog bloka. Npr. iza ikone klase stoji specifikacija koja prua cijeli skup atributa, operacija i ponaanja koja ta klasa sadrava; vizualno, ta klasa moe prikazati samo manji dio te specifikacije. Grafika notacija UML-a koristi se za vizualizaciju sustava, a specifikacija UML-a koristi se za opis detalja tog sustava. S obzirom na ovu podjelu, mogue je graditi model inkrementalno, crtajui dijagrame i nakon toga dodavati semantiku specifikaciji modela, ili direktno kreirajui specifikaciju (moda ak i koritenjem ininjerstvom unatrag ve postojeeg sustava) i nakon toga kreirati dijagrame koji su projekcija u te specifikacije. Specifikacije UML-a pruaju semantiku pozadinu koja sadrava sve dijelove modela sustava i gdje je su svi dijelovi na konzistentan nain povezani. UML dijagrami su stoga samo vizualne projekcije na tu pozadinu, gdje svaki dijagram otkriva specifian aspekt sustava.
UML Common Mechanisms: Adornments

Adornments allow showing more information on UML elements. Example, Fig. 1.9 [Arlow & Neustadt, 2002]
Standardni mehanizmi u UML-u - Ukrasi

Veina elemenata u UML-u ima jednoznanu i izravnu grafiku notaciju koja prua vizualnu reprezentaciju najvanijih aspekata tog elementa. Npr. notacija za klasu je namjerno dizajnirana jednostavnom za crtanje jer su klase najei elementi koji se nalaze u modeliranju objektno orijentiranih sustava. Notacija za klasu takoer daje na uvid i najvanije aspekte klase, a to su ime, atributi i operacije. Specifikacija klase moe ukljuivati i ostale detalje, kao to su: da li je klasa apstraktna, ili vidljivost njenih atributa i operacija i sl. Mnogi od ovih detalja mogu se prikazati kao grafiki ili tekstualni ukrasi samoj notaciji klase (pravokutnik). Npr. Slika 16 prikazuje klasu koja je ukraena kako bi se naglasilo da je klasa apstraktna i da sadri dvije javne (eng. public), jednu zatienu (eng. protected) i jednu privatnu (eng. private) operaciju.
UML Common Mechanisms: Common Divisions

Common divisions are ways of thinking about the world (for modeling purposes) Common divisions in UML are of two types:
Classifiers and instance [see Table 1.2 in the book] Interface and implementation [see Subsection 1.8.3.2]
Standardni mehanizmi u UML-u - Podjele

Pri modeliranju objektno orijentiranih sustava, sve se esto dijeli na vie naina. Prvo, tu je podjela na klase i objekte. Klasa je apstrakcija, a objekt je konkretna manifestacija te apstrakcije. U UML-u mogu se modelirati i klase i objekti, kao to je prikazano na Slici 17.
Klase i objekti
Postoji separacija suelja od implementacije. Suelje deklarira ugovor, a implementacija predstavlja konkretnu realizaciju tog ugovora i odgovorna je za tono izvravanje kompletne semantike suelja. U UML-u mogu se modelirati i suelja i implementacije, kao na Slici 18. Slika 18: Suelja i implementacije Na ovoj slici je jedna komponenta, nazvana spellingwizard.dll koja implementira dva suelja, IUnknown i ISpelling.
Na ovoj slici je jedna klasa, nazvana Customer, zajedno sa tri objekta: John (koji je eksplicitno naveden kao Customer objekt), :Customer (anonimni Customer objekt) i Jack (za kojeg je u specifikaciji navedeno da je Customer objekt, iako to nije eksplicitno navedeno).
UML Common Mechanisms: Extensibility

There are three types of mechanisms that provide support for UML extensibility, Table 1.3 [Arlow & Neustadt, 2002]
Mehanizmi proirivosti u UMLu

UML prua standardan jezik za pisanje nacrta za sustave programske podrke, ali nemogue je, za jedan jezik, da ikada bude dovoljan kako bi izrazio sve mogue dijelove modela u svim moguim domenama u vremenu. Iz tog razloga, UML je otvoren i lako ga je kontrolirano proiriti. UML-ovi mehanizmi proirivosti ukljuuju: Stereotipe (eng. stereotypes) Oznaene vrijednosti (eng. tagged values) Ogranienja (eng. constaints) Postoji separacija suelja od implementacije. Suelje deklarira ugovor, a implementacija predstavlja konkretnu realizaciju tog ugovora i odgovorna je za tono izvravanje kompletne semantike suelja. U UML-u mogu se modelirati i suelja i implementacije, kao na Slici 18. Slika 18: Suelja i implementacije Na ovoj slici je jedna komponenta, nazvana spellingwizard.dll koja implementira dva suelja, IUnknown i ISpelling.
Mehanizmi proirivosti u UMLu

Stereotip proiruje rjenik UML-a, omoguavajui kreiranje novih vrsta graevnih blokova koji su izvedeni iz ve postojeih, ali su specifini za neki problem. Npr. ako se programira u jezicima kao to su Java i C++, esto postoji potreba za modeliranjem iznimaka (eng. exceptions). U tim jezicima, iznimke su, jednostavno, klase, iako se s njima postupa na specijalan nain. Tipino, eli se samo mogunost bacanja i hvatanja iznimaka, nita vie. Stereotipovi ovdje dolaze u pomo dajui mogunost pretvaranja iznimke (kao klase) u poseban graevni blok. Klasa koja se eli tako unaprijediti oznai se sa odreenim stereotipom, kao klasa Overflow na Slici 19. Oznaene vrijednosti proiruju svojstva graevnih blokova UML-a, omoguavajui kreiranje novih informacija u specifikaciji tog elementa. Npr. pri izradi nekog programa za kojeg postoji velik broj izmjena javlja se potreba za oznaavanjem verzija i autora nekih kritinih apstrakcija u tom programu. Verzije i autori ne postoje kao primitivi u konceptu UML-a. Mogue ih je dodati svakom graevnom bloku, kao klasi, uvodei nove oznaene vrijednosti tom bloku. Na Slici 19, klasa EventQueue je proirena eksplicitnim oznaavanjem autora i verzije. Ogranienja proiruju semantiku graevnih blokova UML-a, omoguavajui dodavanje novih pravila ili mijenjanje ve postojeih. Npr. ograniavanje klase EvenQueue na taj nain da sve to se doda u nju mora biti poredano. Na Slici 19, prikazano je eksplicitno dodavanje ogranienja na operaciju add().
Architecture.
The system architecture is the organizational structure of the system, including its decomposition into parts, their connectivity, interaction, mechanisms and the guiding principles that inform the design of a system. [Rumbaugh 1998] There is a typical 4+1 views architecture of a system defined by UML:
Logical view, captures the vocabulary of the problem domain using classes and objects Process view, depicts the threads and processes of the system as active classes Implementation view, shows the physical code base of the system in terms of components Deployment view, models the physical deployment of components onto computational nodes Use case view, captures the requirements of the system using a set of use cases. This is the view +1 to which all other views connect.
.Architecture
The 4 +1 views architecture, Fig. 1.11 [Arlow & Neustadt 2002]
What is UP?
A software development process (SDP) or software engineering process (SEP) defines the who, what, when, and how of developing software The Unified Software Development Process (USDP) or, in short, the Unified Process (UP) is an industry standard process created by the authors of UML
Fig 2.2, [Arlow 2002]
UP History
UP evolution, Fig. 2.3 [Arlow & Neustadt, 2002]
UP Axioms
Use case and risk driven Architecture centric Iterative and incremental
Each iteration contains all the elements of a regular software development project: planning, analysis, design, construction, integration, testing, internal or external release
UP Core Workflows.
Requirements: Determining what the system should do Analysis: Refining and structuring the requirements Design: Defining system architecture to satisfy requirements Implementation: Building the software Testing: Verifying that the implementation is correct
A baseline is the result of an iteration, a partially complete version of the final system. An iteration is the difference between two consecutive baselines.
.UP Core Workflows

Fig.2.5, Arlow 2002
UP Structure.
Fig.2.6, Arlow 2002
.UP Structure
Fig.2.7, Arlow 2002
UP: Details on Phases.

Each of the four phases of UP (inception, elaboration, construction, transition) has:
A goal A focus of activity One or more core workflows A milestone, with a number of conditions of satisfaction
Details of the above for Inception are given next. The remaining three phases are described in Subsection 2.9 of the textbook
UP: .Details on Phases

Inception
Goal: Get the project off the ground Tasks: Assess feasibility Create a strong business case Capture essential requirements Identify critical tasks Focus: Requirements specification and analysis Milestone: Life-cycle objectives [see conditions of satisfaction
n Table 2.1 of the book]
Literatura
http://dn.codegear.com/article/31863#usecase-diagram (ima dobar tutorial za uenje UML-a http://www.uml.org/#Links-General http://www306.ibm.com/software/rational/uml/products.h tml http://www.sparxsystems.com.au/UML_Tutori al.htm

P10 Uml

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

P10 Uml

Uploaded by

Copyright:

Available Formats

MODELIRANJE I IMPLEMENTACIJA INFORMACIJSKIH SUSTAVA

Objektno orjentirani pristup modeliranju i UML

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

Objektno orijentirano modeliranje

Objektno orijentirano modeliranje

Principi objektno orijentirane paradigme

Principi objektno orijentirane paradigme

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

Principi objektno orijentirane paradigme

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML unified modelling language

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML unified modelling language

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

Pretpostavke za koritenje UML-a

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi modelski elementi

UML gradbeni blokovi Stvari

UML stvari ili modelski elementi mogu biti

UML gradbeni blokovi Strukturalne stvari

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Strukturalne stvari

UML gradbeni blokovi Strukturalne stvari

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Strukturalne stvari

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Strukturalne stvari

UML gradbeni blokovi Strukturalne stvari

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Strukturalne stvari

UML gradbeni blokovi Stvari s ponaanjem

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Stvari s ponaanjem

UML gradbeni blokovi Grupirajue stvari

UML gradbeni blokovi Opisne stvari

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Relacijske stvari u UML-u

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML Building Blocks: Relationships.

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08

Objektno modeliranje i UML

UML gradbeni blokovi Relacijske stvari u UML-u

UML gradbeni blokovi Relacijske stvari u UML-u

UML gradbeni blokovi Relacijske stvari u UML-u

UML gradbeni blokovi Relacijske stvari u UML-u

J. Mesari, Modeliranje i izgradnja IS-a. EFOS 2007/08