FAKULTET AKULTET ELEKTROTEHN EL EKTROTEHNIKE IKE I RAČUNARSTVA RAČUNARSTVA – ZAGREB ZAGRE B Zavod za primijenjenu matematiku
Predmet: ZPM19D2 Strukturirane tehnike programiranja Smjer: Jezgra računarstva/primijenjeno računarstvo Šk. god. 2000/2001 Nastavnik: prof. dr. sc. Marijan Đurek
VIZUALNO MODELIRANJE OBJEKTNO ORIJENTIRANIH SUSTAVA KORIŠTENJEM UML-A seminarski rad
Darije Ramljak
Zagreb, listopad 2001
Kazalo: 1.UVOD....................... ............................................... ............................................... .............................................. ....................................................... ........................................ ........ 2 1.1.Povijest razvoja UML-a..................... ............................................ .............................................. ..................................................... .................................... ...... 2 2.Objektnoo orijenti 2.Objektn orijentirano rano modeliran modeliranje je......... ................. ................ ................ ................ ................ ................ ................ ............. ......... ........ ........ ........ ........ .... 4 2.1.Modeliranje........................................................... .................................................................................. ....................................................... ........................................ ........ 4 3.Unified modeling language (UML) ...................... ............................................. .............................................. ........................................... .................... 6 3.1.Pregled UML-a...................................................... ............................................................................. .............................................. ........................................ ................. 6 3.1.1.UML je jezik....................... .............................................. .............................................. ................................................................... ................................................ .... 6 3.1.2.UML 3.1.2.UM L je jezik za vizualizi vizualiziranje ranje ........ ................ ................ ................ ................ ................ ................ ................. ................. ............ ........ ......... ......... .... 6 3.1.3.UML 3.1.3.UM L je jezik za specifici specificiranje ranje ........ ................ ................ ................. ................. ................ ................ ................ ............ ........ ......... ......... ........ ........ .... 7 3.1.4.UML je jezik za konstruiranje..................... ............................................ .............................................. ............................................... ........................ 7 3.1.5.UML je jezik za dokumentiranje..................... ............................................ .............................................. ........................................... .................... 8 3.1.6.Gdje se sve UML može koristiti....................... .............................................. .................................................. ........................................ ...............8 4.Konceptualann model UML-a...................... 4.Konceptuala ............................................. .............................................. .............................................. ............................... ........ 9 4.1.Građevni blokovi UML-a....................... .............................................. .............................................. ....................................................... ................................ 9 4.1.1.Stvari 4.1.1.Stv ari u UML-u ......... ................. ................ ................ ................ ................ ................ ................ ................ ................. ................. .............. .......... ......... ......... ........ .... 9 4.1.2.Strukturalne stvari........................... .................................................. .............................................. ..................................................... .................................... ......9 4.1.3.Stvari sa ponašanjem...................... ............................................. .............................................. .......................................................... ................................... 12 4.1.4.Grupirajuće stvari.......................................... ................................................................. .............................................. ........................................... .................... 13 4.1.5.Opisne stvari........................................................... .................................................................................. .............................................. .................................. ........... 13 4.1.6.Relacijske stvari u UML-u....................... .............................................. .............................................. ......................................... ......................... ....... 14 4.1.7.Dijagrami u UML-u....................... .............................................. .............................................. ......................................... .............................. ................. ..... 15 15 4.2.Pravila UML-a........................................................ ............................................................................... .............................................. ..................................... .............. 16 4.3.Standardni mehanizmi u UML-u..................... ............................................ .............................................. ............................................ ..................... 17 4.3.1.Specifikacije 4.3.1.Specifika cije...................... ............................................. .............................................. .............................................. ............................................... .......................... 17 4.3.2.Ukrasi....................... .............................................. .............................................. .............................................. .................................................. .................................. ....... 17 4.3.3.Podjele..................... ............................................ .............................................. .............................................. .......................................................... ................................... 18 4.3.4.Mehanizmi 4.3.4.Mehaniz mi proširivosti...................... ............................................. .............................................. .................................. ........................ .................... ....... 19 5.Zaključak....................... .............................................. .............................................. .............................................. .......................................................... ................................... 21 Literatura..................... ............................................ .............................................. .............................................. ............................................................... ........................................ 22
1. UVOD
Unified Modeling Language (UML) je grafički jezik za vizualiziranje, specificiranje, konstruiranje i dokumentiranje sustava programske podrške. UML pruža standardiziran način planiranja sustava, pokrivajući konceptualne stvari, kao što su poslovni procesi i funkcije sustava, kao i konkretne stvari, među koje spadaju klase pisane u nekom programskom jeziku, sheme baza podataka i ponovno iskoristive (eng. reusable) programske komponente. U ovom radu bit će predstavljen UML i prikazani njegovi osnovni principi. 1.1. Povijest razvoja UML-a
Objektno-orijentirano programiranje pojavilo se negdje između sredine '70-ih i kraja '80-ih kada su metodolozi, suočeni sa novom vrstom objektno-orijentiranih programskih jezika i povećanom kompleksnošću aplikacija, počeli eksperimentirati sa alternativnim pristupima analizi i dizajnu. Broj objektno-orijentiranih metoda povećao se sa nešto manje od 10 na više od 50 u periodu između 1989 i 1994. Veliki broj korisnika tih metoda imao je puno problema u traženju onog jezika za modeliranje koji bi u potpunosti pokrivao njihove potrebe. Na osnovu tog iskustva počele su se pojavljivati nove generacije metoda, od kojih je nekolicina bila vrlo napredna, posebno Booch-ova, Jacobson-ova OOSE (Object-Oriented Software Engineering) i Rumbaugh-ova OMT (Object Modeling Technique) . Ostale važnije metode bile su Fusion, Shlaer-Mellor i Coad-Yourdon. Svaka od njih bila je kompletna metoda i svaka je imala svoje prednosti i mane. Npr. Booch-ova metoda bila je vrlo ekspresivna za vrijeme dizajna i faze konstrukcije projekta, OOSE davala je izvrsnu podršku za "slučajeve korištenja" (eng. use-cases) kao način prolaska kroz postavljanje zahtjeva na sustav (eng. requirements), analize i dizajna na visokoj razini ( eng. high-level design ), a OMT-2 bila je najkorisnija kod analize informacijskih sustava sa velikim zahtjevima na obradu podataka. Kritična masa ideja počela se formirati sredinom '90-ih kada su Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) i James Rumbaugh (General Electric) počeli međusobno usvajati ideje. Htjela se napraviti konverzija njihovih ideja što bi donijelo stabilnost objektno-orijentiranom tržištu i omogućilo projektima korištenje jednog zrelog jezika za modeliranje. Također, konverzijom tih triju metoda željela sa napraviti nova naprednija metoda. Službeni početak razvoja UML-a počeo je u listopadu 1994, kada se Rumbaugh udružio sa Booch-em u Rational Software Corporation. Projekt se u početku sastojao od unifikacije Booch-eve i OMT metode. Verzija 0.8 Unified Method (kako se u to vrijeme zvala) izašla je u listopadu 1995. U to vrijeme je i Jacobson prešao u Rational i opseg UML-a se proširio i od tada je obuhvaćao i OOSE. U lipnju 1996. izašla je verzija 0.9. U to se već vrijeme vidjelo da velika većina organizacija koje proizvode programsku podršku vidi UML kao strategiju za svoj posao. Tada je osnovan UML konzorcij sa nekoliko organizacija koje su bile voljne upregnuti svoje resurse kako bi se došlo do stabilne i kompletne definicije UML-a. Ti partneri, koji su pridonijeli UML 1.0 definiciji, bili su DEC, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI, Microsoft, Oracle, Rational, Texas Instruments i Unisys. Ta suradnja rezultirala je sa UML 1.0, jeziku za modeliranje koji je bio dobro
2
formiran, ekspresivan, snažan i primjenjiv u širokom spektru domena problema. UML 1.0 je ponuđen na standardizaciju OMG-u (Object Management Group) u siječnju 1997., kao odgovor na njihov zahtjev za prijedlog standardnog jezika za modeliranje. Između siječnja i srpnja 1997., originalna grupa se proširila i obuhvatila je sve koji su poslali svoje prijedloge OMG-u, uključujući Andersen Consulting, Ericsson, Platinum Technology, Softeam, itd. Osnovana je grupa za semantiku, koju je vodio Cris Kobryn, kako bi se formalizirala UML specifikacija i kako bi se UML integriralo sa drugim standardima. Revidirana verzija UML-a (verzija 1.1) je predana na pregled OMG-u u srpnju 1997. i OMG ADTS (Analysis and Design Task Force) je u rujnu 1997. prihvatio tu verziju i dao ju na glasovanje. Na kraju je UML 1.1 prihvaćen od strane OMG-a u prosincu 1994. Zadnja verzija UML-a koja je izašla je 1.3 (jesen 1998).
3
2. OBJEKTNO ORIJENTIRANO MODELIRANJE
Primarni produkt nekog razvojnog tima je dobra programska aplikacija koja zadovoljava rastuće potrebe korisnika i njihovog poslovanja. Sve ostalo je manje važno. Nažalost, velik broj organizacija koje proizvode programsku podršku ono "manje važno" zamjenjuje sa "potpuno nevažno". Kako bi se izgradila programska podrška dugotrajne kvalitete, potrebno je složiti solidnu baznu arhitekturu. Za brz i efikasan razvoj programske podrške, potrebno je imati prave ljude, dobar alat i dobar fokus. Kako bi se to sve napravilo konzistentno i sa uzimanjem u obzir same cijene razvojnog ciklusa, potrebno je imati dobar razvojni proces koji se može vrlo lako prilagoditi stalnim promjenama tehnologije i poslovanja. 2.1. Modeliranje
Modeliranje je glavni dio svih tih aktivnosti koje vode produkciji dobre programske podrške. Modeliranjem se vizualizira i kontrolira arhitektura sustava. Modelira se kako bi se bolje shvatio sustav koji se izgrađuje i često se koristi radi pojednostavljenja i mogućnosti ponovne iskoristivosti dijelova tog istog sustava. Modeliranje je dokazana i široko prihvaćena inžinjerska tehnika. Npr. arhitekti rabe modeliranje kako bi olakšali projektiranje neke kuće ili zgrade. Koriste razne matematičke modele kako bi analizirali utjecaje vjetra i potresa na stambene objekte. Naravno, modeliranje nije vezano samo za građevinsku industriju. Bilo bi gotovo nemoguće proizvesti novi avion ili auto bez prethodne izrade modela – od računalnih modela, fizičkih modela, koji se testiraju u zračnim tunelima, pa sve do pravih prototipova. U stvarnom životu moguće je naći mnogo primjera gdje se modeliranje koristi kao jedan od glavnih procesa. Model pruža na uvid nacrte za izgradnju određenog sustava. Modeli mogu sadržavati vrlo detaljne nacrte, kao i one generalne koji daju samo prikaz većih cjelina. Dobar model uključuje one elemente koji imaju širok utjecaj, a zanemaruje one manje elemente koji nisu relevatni za promatranu razinu apstrakcije. Svaki sustav može se opisati sa više aspekata koristeći više modela pa je samim time svaki model semantički zatvorena apstrakcija sustava. Kroz modeliranje, postižu se četiri cilja: 1. Modeli pomažu pri vizualizaciji sustava koji se promatra ili koji se želi izgraditi. 2. Modeli omogućuju specifikaciju strukture ili ponašanja sustava. 3. Modeli pružaju predloške koji služe kao vodiči pri izgradnji sustava. 4. Modeli dokumentiraju odluke koje su donesene. Modeliranje se ne koristi isključivo u izradi velikih sustava jer čak i mali sustavi imaju koristi od njega. Ipak, istina je da što je veći i kompleksniji sustav koji se radi to je i veća važnost modeliranja. U razvoju programske podrške postoji nekoliko načina pristupa modelu. Dva najčešća pristupa su pristup sa strane algoritma i objektno-orijentirani pristup.
4
Tradicionalan pogled na razvoj programske podrške uzima pristup sa strane algoritma. U ovom pristupu, glavni građevni elementi programa su procedure ili funkcije, a glavni fokus se daje na stvari vezane uz kontrolu i dekompoziciju većih algoritama na manje. Ovaj način razvoja nije loš, ali pokazuje svoje velike nedostatke pri promjenama zahtjeva na sustav. Iz toga proizlazi da su sustavi koji su razvijani sa fokusom na algoritme vrlo teški za održavanje. Moderan pogled na razvoj sustava za programsku podršku koristi objektno-orijentirani pristup. Ovdje je glavni građevni blok sustava objekt ili klasa. To je stvar koja je izvedena iz rječnika domene problema ili rješenja; klasa je opis kolekcije objekata sa istim zajedničkim svojstvima. Svaki objekt ima identitet (može se imenovati ili nekako drugačije razlikovati od ostalih objekata), stanje (obično su tu pridruženi nekakvi podaci) i ponašanje (mogu se vršiti nekakve operacije nad objektom ili on može vršiti operacije nad drugim objektima). Objektno-orijentirani pristup zauzima centralno mjesto među pristupima razvoju programske podrške jednostavno zato što je dokazao svoju vrijednost u razvoju sustava u raznim domenama problema i u obuhvaćanju svih razina kompleksnosti. Nadalje, većina modernih jezika, operativnih sustava i alata su u neku ruku objektno-orijentirani, dajući veći doprinos objetno-orijentiranom pogledu na svijet. Objektno-orijentirani razvoj daje i konceptualne temelje razvoju sustava kroz slaganje komponenata koristeći tehnologije poput Java Beans ili COM+. Iz svega ovoga proizlazi da je svrha UML-a upravo vizualiziranje, specificiranje, konstruiranje i dokumentiranje objektno-orijentiranih sustava.
5
3. UNIFIED MODELING LANGUAGE (UML)
Unified Modeling Language (UML) je standardiziran jezik za pisanje nacrta za razvoj sustava programske podrške. UML se koristi za vizualiziranje, specificiranje, konstruiranje i dokumentiranje komponenata koje sačinjavaju taj sustav. UML se može koristiti za modeliranje sustava od ranga poslovnih informacijskih sustava pa sve do distribuiranih mrežnih aplikacija pa čak i za sustave koji rade u realnom vremenu (eng. real time embedded systems). To je vrlo ekspresivan jezik koji se bavi svim pogledima na sustav koji su potrebni za njihov razvoj i pokretanje. UML je samo jezik i samim time je samo dio metode razvoja programske podrške. Neovisan je o procesu, iako bi, optimalno, trebao biti korišten u procesu koji se temelji na slučajevima korištenja te koji je iterativan i inkrementalan. 3.1. Pregled UML-a
Unified Modeling Language je jezik za: •
Vizualiziranje
•
Specificiranje
•
Konstruiranje
Dokumentiranje dijelova sustava programske podrške. •
3.1.1.
UML je jezik
Jezik pruža rječnik i pravila za kombiniranje riječi u svrhu komunikacije. Jezik za modeliranje je jezik čiji se rječnik i pravila fokusiraju na konceptualnu i fizičku reprezentaciju sustava. Jezik za modeliranje kao što je UML je stoga standardan jezik za nacrte sustava programske podrške. Modeliranje pruža razumijevanje sustava. Niti jedan model nije, sam po sebi, dovoljan, već je često potrebno više povezanih modela kako bi se razumio i najjednostavniji sustav. Sustavi programske podrške zahtijevaju jezik koji se bavi različitim pogledima na arhitekturu sustava, kako se sustav razvija kroz razvojni ciklus. Rječnik 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 odlučivanju 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. 3.1.2.
UML je jezik za vizualiziranje
Za mnoge programere, glavni način programiranja sastoji se u tome da se malo razmisli o problemu i odmah počne pisati programski kod. Na ovaj način programer ipak malo
6
modelira, ali to sve drži u glavi. Također, ponekad se te ideje malo i skiciraju na ploči ili papiru. Međutim, tu se javljaju neki problemi. Prvo, prenošenje tih konceptualnih ideja nekome drugome je podložno greškama osim ako svi ne govore istim jezikom. Projekti i organizacije najčešće rabe i razvijaju nekakav svoj jezik i nekome drugome je to možda teško razumjeti. Drugo, neke se stvari ne mogu na jednostavan način razumjeti ako prije samog pisanja programskog koda nije izgrađen model. Npr. hijerarhije klasa će se teško razumjeti iz samog koda. Treće, ako programer koji je napisao neki programski kod nije svoju ideju iz glave prenio na papir, ta bi se ideja mogla nepovratno izgubiti. U najboljem slučaju, ideja bi se mogla djelomično iskonstruirati iz postojećeg koda. Pisanje modela u UML-u dotiče treću stavku: Eksplicitan model poboljšava komunikaciju. Neke se stvari najbolje modeliraju tekstualno, a neke grafički. U gotovo svim interesantnim sustavima postoje strukture koje nadilaze ono što se može prikazati programskim jezikom. UML je grafički jezik i time dotiče, prije spomenuti, prvi problem. UML nije samo skup grafičkih simbola, već iza svakog simbola stoji dobro definirana semantika. Na taj način, model koji je napravio jedan programer može jednoznačno pročitati i razumjeti drugi programer i time se dotiče, prije spomenuti, drugi problem. 3.1.3.
UML je jezik za specificiranje
U ovom kontekstu, specificiranje znači izgradnju modela koji su precizni, jednoznačni i kompletni. UML se bavi specifikacijom svih važnih odluka analize, dizajna i implementacije koje se moraju donijeti u razvoju i pokretanju sustava programske podrške. 3.1.4.
UML je jezik za konstruiranje
UML nije vizualan programski jezik, ali njegovi modeli mogu biti direktno povezani sa raznim programskim jezicima. To znači da je moguće mapiranje između 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 način su stvari, koje se najbolje predstavljaju grafički, napravljene u UML-u, a stvari koje se najbolje predstavaljaju u tekstualnom obliku, u programskom jeziku. Ovo mapiranje dozvoljava tzv. inžinjerstvo unaprijed (eng. forward engineering) : Generaciju koda iz UML modela u programski jezik. Unatrag je također moguće: Moguće je rekonstruirati UML model iz već postojećeg koda. Inžinjerstvo unatrag (eng. reverse engineering) nije svemoguće i ako se informacija ne ukodira u implementaciju, ta informacija je izgubljena kada se ponovno generira kod iz modela. Iz toga se može zaključiti da inžinjerstvo unatrag zahtijeva ljudsku intervenciju. Kombiniranjem ta dva načina generacije koda i modela dobiva se tzv. inžinjerstvo u krug (eng. roud-trip engineering) , što daje mogućnost rada i u grafičkom i u tekstualnom načinu dok se alat brine za konzistentnost podataka. Uz direktno mapiranje, UML je dovoljno ekspresivan i jednoznačan da dozvoljava direktno izvođenje modela, simulacije sustava i instrumentaciju sustava u radu.
7
3.1.5.
UML je jezik za dokumentiranje
Iz prave programerske organizacije, uz sam izvršni kod, na tržište izlaze i razne dodatne stvari kao što su: •
Zahtjevi na sustav
•
Arhitektura
•
Dizajn
•
Programski kod
•
Projektni planovi
•
Testovi
Prototipovi Ovisno o samoj kulturi razvoja programske podrške, neke od tih stvari tretirane su manje ili više formalno od drugih. Takve stvari nisu samo popratne stvari uz sam sustav, već su one, također, vrlo važne u kontroli, mjerenju i komunikaciji o sustavu u toku njegovog razvoja i nakon pokretanja. UML se bavi dokumentacijom arhitekture sustava i svim njenim detaljima. UML, također, pruža jezik za artikuliranje zahtjeva na sustav i testove. Na kraju, UML pruža jezik za modeliranje aktivnosti planiranja projekta i upravljanja načinima puštanja u rad. •
3.1.6.
Gdje se sve UML može koristiti
UML je prvenstveno namijenjen sustavima koji se oslanjaju na programsku podršku. Vrlo se efikasno koristi u slijedećim domenama: •
Poslovni informacijski sustavi
•
Bankarske i financijske usluge
•
Telekomunikacije
•
Transport
•
Obrana/avionautika
•
Prodaja
•
Medicinska elektronika
•
Znanost
Distribuirane mrežne usluge UML nije ograničen samo na modeliranje programske podrške. Ustvari, dovoljno je ekspresivan i za modeliranje ostalih sustava, kao što su tok podataka i dokumenata u pravnom sustavu, struktura i ponašanje zdravstvenog sustava pacijenta, i dizajn sklopovlja. •
8
4. KONCEPTUALAN MODEL UML-A
Za razumijevanje UML-a, potrebno je formirati konceptualan model jezika i to zahtijeva učenje tri glavna elementa: osnovne građevne blokove UML-a, pravila koja diktiraju kako koristiti i slagati te blokove i neke osnovne mehanizme koji se primjenjuju kroz UML. 4.1. Građevni blokovi UML-a
Rječnik UML-a obuhvaća tri tipa građevnih blokova: 1. Stvari 2. Relacije 3. Dijagrame Stvari su apstrakcije i one su glavni dijelovi UML-a. Relacije povezuju te iste stvari, a dijagrami grupiraju interesantne kolekcije tih stvari. 4.1.1.
Stvari u UML-u
Postoje četiri vrste stvari u UML-u: 1. Strukturalne stvari (eng. structural things) 2. Stvari sa ponašanjem (eng. behavioral things) 3. Grupirajuće stvari (eng. grouping things) 4. Označavajuće stvari (eng. annotational things) Te stvari su osnovni objektno-orijentirani građevni blokovi UML-a i koriste se za pisanje dobro formiranih modela. 4.1.2.
Strukturalne stvari
su imenice u UML modelima. To su najčešće statički dijelovi modela i oni predstavljaju elemente koji su ili konceptualni ili fizički. U UML-u postoji sedam tipova strukturalnih stvari. Prvi od njih je klasa koja predstavlja opis skupa objekata koji dijele iste atribute, operacije, relacije i semantiku. Klasa može implementirati jedno ili više sučelja (eng. interface) . Grafički, klasa je prikazana kao pravokutnik koji obično sadrži ime, atribute i operacije kao na slici Slika 1. Strukturalne stvari
9
Slika 1: Klasa Drugi tip je sučelje . To je je kolekcija operacija koja specificira usluge neke klase ili komponente. Sučelje stoga predstavlja izvana vidljivo ponašanje tog elementa i može predstavljati kompletno ponašanje klase ili komponente ili samo djelomično. Sučelje definira skup operacijskih specifikacija (tj. njihovih potpisa), ali nikada skup njihovih implementacija. Grafički, sučelje je predstavljeno krugom zajdeno sa njegovim imenom (Slika 2.). Sučelje, prema svojoj namjeni, nikada neće stajati samo, već će obično biti vezano za određenu klasu ili komponentu koja ga realizira.
Slika 2: Sučelje Treći tip je suradnja (eng. collaboration) . Ono definira interakciju te je skup uloga (eng. roles) i ostalih elemenata koji zajednički rade i pružaju nekakvo kooperativno ponašanje koje je veće nego suma svih elemenata zajedno. Stoga, suradnja ima strukturalnu dimenziju kao i dimenziju ponašanja. Neka klasa može participirati u više suradnji odjednom i suradnje time reprezentiraju implementaciju predložaka (eng. patterns) koji čine sustav. Grafički, suradnja je predstavljena elipsom sa isprekidanim linijama i obično se u njoj nalazi njeno ime, kao na Slici 3.
Slika 3: Surađivanje Četvrti tip je slučaj korištenja (eng. use case) . On opisuje skup slijednih događaja koje sustav izvodi kako bi dobio neki rezultat i koristi se za strukturiranje stvari sa ponašanjem u samom modelu. Slučaj korištenja se u modelu realizira već spomenutim tipom: suradnjom. Grafički, slučaj korištenja je predstavljen elipsom kao na Slici 4.
10
Slika 4: Slučaj korištenja Preostala tri tipa – aktivne klase, komponente i čvorovi – slični su klasama jer opisuju skup objekata koji dijele iste atribute, operacije, relacije i semantiku. Ipak, ova tri tipa su dovoljno različita i neophodna za modeliranje određenih aspekata objektno-orijentiranih sustava da se ne smiju zaobići u opisu. Peti tip je aktivna klasa (eng. active class) . To je klasa čiji objekti posjeduju jedan ili više procesa ili niti i time mogu inicirati neku kontrolnu aktivnost. Slična je samoj klasi osim što njeni objekti predstavljaju elemente čije ponašanje je konkurentno sa ostalim elementima. Grafički, predstavlja se kao i normalna klasa, ali sa podebljanim linijama, kao na Slici 5.
Slika 5: Aktivna klasa Preostala dva tipa predstavljaju fizičke stvari, za razliku od prethodnih pet koji su predstavljali konceptualne ili logičke stvari. Šesti tip je komponenta (eng. component) i predstavlja fizički i zamjenjivi dio sustava koji se prilagođava skupu sučelja i pruža njihovu realizaciju. U sustavu se mogu sresti mnoge razne komponente kao što su COM+ komponente, zatim JavaBeans komponente kao i ostale komponente koje su dio razvojnog procesa, kao datoteke programskog koda. Komponenta tipično predstavlja fizičko pakiranje inače logičkih elemenata kao što su klase, sučelja i surađivanja. Grafički, komponenta se prikazuje kao pravokutnik sa hvataljkama, kao na Slici 6.
Slika 6: Komponenta Sedmi tip je čvor (eng. node) . To je fizički element koji postoji pri radu sustava i predstavlja računalni resurs i obično ima neku memoriju i procesne mogućnosti. Unutar čvora može se smjestiti skup komponenata, a komponente mogu, također, seliti se sa čvora na čvor. Grafički, čvor je predstavljen kockom, kao na Slici 7.
11
Slika 7: Čvor Ovih sedam tipova elemenata – klase, sučelja, suradnje, slučajevi korištenja, aktivne klase, komponente i čvorovi – su osnovne strukturalne stvari koje se mogu uključiti unutar UML modela. Uz ove osnovne, postoje također i njihove varijacije, kao što su glumci (eng. actors), signali, procesi i niti (oblici aktivnih klasa), aplikacije, dokumenti, datoteke, biblioteke, stranice i tablice (oblici komponenti). 4.1.3.
Stvari sa ponašanjem
Stvari sa ponašanjem su dinamički diojelovi UML modela. To su glagoli modela i predstavljaju ponašanje kroz prostor i vrijeme. Postoje, sve skupa, samo dva primarna tipa stvari sa ponašanjem. Prvi od njih je interakcija . Interakcija je ponašanje koje obuhvaća skup poruka koji se izmjenjuje u skupu objekata unutar nekog određenog konteksta s određenom svrhom. Ponašanje skupa objekata ili individualne operacije može se specificirati interakcijom. Interakcija uključuje i brojne druge elemente kao što su poruke, slijedovi akcija (ponašanje pokrenuto porukom) i veze između objekata. Grafički, poruka je predstavljena kao linija sa strelicom u jednom smjeru i najčešće uključuje i ime operacije, kao na Slici 8.
Slika 8: Interakcija Drugi je automat stanja (eng. state machine). Automat stanja je ponašanje koje specificira slijed stanja objekta ili interakcije kroz koje prolazi za vrijeme svog života kao odgovor na neki događaj, zajedno sa odgovorom na taj događaj. Ponašanje pojedine klase ili suradnje klasa može biti specificirana automatom stanja. Automat stanja uključuje i brojne druge elemente, kao što su stanja, tranzicije (prijelazi između dva stanja), događaje (stvari koje okidaju tranziciju) i aktivnosti (odgovori na tanziciju). Grafički, stanje je predstavljeno pravokutnikom zaobljenih rubova (kao na Slici 9.) i obično uključuje ime stanja i njegova podstanja.
Slika 9: Stanje
12
Ova dva elementa – interakcije i automati stanja – su osnovne stvari sa ponašanjem koje se mogu uključiti unutar UML modela. Semantički gledano, ti elementi su obično povezani sa različitim strukturalnim elementima, prvenstveno klasama, suradnjama i objektima. 4.1.4.
Grupiraju ć e stvari
su organizacijski dio UML modela. To su "kutije" u koje se može razložiti UML model i postoji samo jedan tip grupirajućih stvari, a to su paketi (eng. packages). Paket je mehanizam opće namjene za organiziranje elemenata u grupe. Strukturalne stvari, stvari sa ponašanjem pa čak i druge grupirajuće stvari mogu se smjestiti u paket. Za razliku od komponenata (koje postoje za vrijeme izvođenja), paket je čisto konceptuale prirode (što znači da postoji samo za vrijeme razvoja). Grafički, paket je prikazan kao pravokutnik sa hvataljkom (eng. tabbed folder) kako je prikazano na Slici 10. i obično sadrži ime i, ponekad, svoj sadržaj. Grupirajuće stvari
Slika 10: Paket Paketi su osnovne grupirajuće stvari kojima je moguće organizirati UML model. Također, postoje i varijacije, kao kosturi (eng. frameworks), modeli i podsustavi (tip paketa). 4.1.5.
Opisne stvari
su dijelovi UML modela koji daju neku vrstu objašnjenja. To su komentari koji se mogu primijeniti kako bi se opisalo, naglasilo ili dalo primjedbu na neki element unutar UML modela. Postoji samo jedan glavni tip opisnih stvari, a to je cedulja (eng. note). Cedulja je, jednostavno, simbol za pisanje ograničenja i komentara i vezana je za neki element ili kolekciju elemenata u UML modelu. Grafički, cedulja se predstavlja kao pravokutnik sa zavrnutim rubom, zajedno sa tekstualnim ili grafičkim komentarom, kao na slici 11. Opisne stvari
Slika 11: Cedulja Ovaj element je osnovna opisna stvar koju je moguće koristiti u UML modelu. Cedulje se tipiđno koriste za pisanje ograničenja uz dijagrame ili za pisanje tekstualnih komentara. Postoje, također, i varijecije ovog elementa, kao što su zahtjevi na sustav (oni specificiraju neko željeno ponašanje iz vanjske ili korisničke perpektive).
13
4.1.6.
Relacijske stvari u UML-u
Postoje četiri tipa relacija unutar UML modela: 1. Ovisnosti (eng. dependency) 2. Asocijacije (eng. association) 3. Generalizacije (eng. generalization) 4. Realizacije (eng. realization) Ove su relacije osnovni relacijski građevni blokovi u UML-u i koriste se za pisanje dobro formiranih UML modela. Prvi tip, ovisnost , je semantička relacija između dvije stvari u kojoj promjena u jednoj (neovisnoj stvari) može utjecati na semantiku druge (ovisne stvari). Grafički, ovisnost se prikazuje kao isprekidana linija, sa mogućom oznakom direkcije (strelica) i imenom, kao na Slici 12.
Slika 12: Ovisnost Drugi tip, asocijacija , je strukturalna relacija koja opisuje skup veza između objekata. Kombinacija (eng. aggregation) je specijalan oblik asocijacije i reprezentira strukturalnu relaciju između cjeline i njenih dijelova. Grafički, asocijacija se predstavlja kao puna linija, uz mogućnost određivanja smjera, i ponekad sadrži i dodatne stvari kao n-arnost i ime. Prikazana je na Slici 13.
Slika 13: Asocijacija Treći tip, generalizacija (eng. generalization) , je relacija specijalizacije/generalizacije u kojoj objekti specijaliziranih elemenata (djeca) se mogu zamijeniti objektima generaliziranih elemenata (roditelja). Na ovaj način, djeca dijele strukturu i ponašanje roditelja. Grafički, relacija generalizacije se prikazuje kao puna linija sa šupljom strelicom koja pokazuje prema roditelju, kao na Slici 14.
Slika 14: Generalizacija
14
Četvrti tip, realizacija (eng. realization) , je semantička relacija između klasifikatora, gdje jedan klasifikator specificira ugovor koji drugi klasifikator garantira izvršiti. Realizacija se susreće na dva mjesta: između sučelja i klasa ili komponenata koje ih realiziraju, i između slučajeva korištenja i suradnji koje ih realiziraju. Grafički, realizacija se prikazuje kao prijelaz između generalizacije i relacije ovisnosti, kao na Slici 15.
Slika 15: Realizacija Ova četiri elementa su osnovne relacijske stvari koje se mogu uključiti u UML model. Postoje, također, i njihove varijacije, kao što su uključivanje (eng. include) , proširenje (eng. extend) , rafiniranje (eng. refinement) , i praćenje (eng. trace) . 4.1.7.
Dijagrami u UML-u
Dijagram je grafička prezentacija skupa
elemenata, najčešće prikazanih kao povezani grafovi vertikala (stvari) i lukova (relacije). Dijagrami se crtaju kako bi se vizualizirao sustav iz različitih perspektiva, pa to čini dijagram nekom vrstom projekcije u sustav. Za gotovo sve sustave, osim onih vrlo jednostavnih, dijagrami predstavljaju poboljšani prikaz elemenata koji čine sustav. Isti elementi mogu se pojaviti u svim dijagramima, nekim dijagramima (najčešći slučaj) ili se uopće ne pojaviti (jako rijetko). Teoretski, dijagram može sadržavati bilo koju kombinaciju stvari i relacija u modelu. U praksi, međutim, samo se mali broj kombinacija pojavljuje, i one su konzistentne sa pet najkorisnijih pogleda na sustav koji čine arhitekturu sustava koji se oslanjaju na programsku podršku. Stoga, UML uključuje devet takvih dijagrama: 1. Dijagram klasa 2. Dijagram objekata 3. Dijagram slučajeva korištenja 4. Dijagram toka 5. Dijagram suradnji 6. Dijagram stanja 7. Dijagram aktivnosti 8. Dijagram komponenata 9. Dijagram pokretanja Dijagram klasa prikazuje skup klasa, sučelja i suradnji i njihove međusobne relacije. Ti dijagrami su najčešći u objektno-orijentiranim sustavima. Dijagrami klasa bave se statičkim pogledom na dizajn sustava, a oni koji uključuju i aktivne klase, bave se i statičkim pogledom na procese u sustavu. Dijagram objekata prikazuje skup objekata i nihove relacije u sustavu. Dijagrami objekata predstavljaju statičku snimku instanci stvari koje se nalaze u dijagramu klasa. Oni se bave statičkim pogledom na dizajn i procese sustava, kao i dijagrami klasa, ali iz perspektive pravih prototipova, tj. pravih objekata u sustavu.
15
Dijagram slučajeva korištenja prikazuje skup slučajeva korištenja i glumaca (eng. actors – specijalan tip klase) i njihovih relacija. Dijagrami slučajeva korištenja bave se statičkim
pogledom na slučajeve korištenja u sustavu i vrlo su važni kod organiziranja i modeliranja ponašanja 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 između njih. Interakcijski dijagram bavi se dinamičkim 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 znači da se svaki od njih može lako transformirati u drugi. Dijagam stanja prikazuje automat stanja, koji se sastoji od stanja, prijelaza, događaja i aktivnosti i bavi se dinamičkim pogledom na sustav. Dijagrami stanja su vrlo važni u modeliranju ponašanja sučelja, klasa ili suradnji i daju naglasak na ponašanje objekta određeno slijedom događaja, š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 dinamičkim pogledom na sustav. Vrlo su važni u modeliranju funkcija sustava i daju naglasak na tok kontrole između objekata. Dijagram komponenata prikazuje organizacije i ovisnosti između skupa komponenata. Dijagrami komponenata bave se statičkim pogledom na implementaciju sustava. Povezani su sa dijagramima klasa tako da su komponente tipično mapirane na jednu ili više klasa, sučelja ili suradnji. Dijagram pokretanja prikazuje konfiguraciju izvršnih procesnih čvorova i komponenata koje se izvode na njima. Dijagrami pokretanja bave se statičkim pogledom na pokretanje arhitekture sustava. Povezani su sa dijagramima komponenata tako da čvor tipično obuhvaća jednu ili više komponenata. 4.2. Pravila UML-a
Građevni 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 semantički konzistentan i u skladu je sa svim drugim modelima sa kojima je povezan. UML ima semantička pravila za: •
Imena
Kako se mogu nazivati stvari, relacije i dijagrami
•
Doseg
Kontekst koji daje specifično značenje imenu
•
Vidljivost
Kako ta imena mogu vidjeti i koristiti drugi korisnici
•
Integritet
Kako stvari na pravi način i konzistentno povezati sa drugima
Izvođenje Što znači pokrenuti ili simulirati dinamički model Modeli koji se grade za vrijeme razvoja sustava koji se oslanja na programsku podršku teže ka povećanju i mogu ih vidjeti razni korisnici u različito vrijeme i na različit način. Stoga razvojni timovi ne grade samo dobro formirane modele već i modele koji su: •
16
•
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 neizbježni u toku razvoja dok se mnogi detalji sustava tek otkrivaju. Pravila UML-a potiču, ali ne prisiljavaju na bavljenje najvažnijim pitanjima analize, dizajna i implementacije koji usmjeravaju model da, kroz vrijeme, postane dobro formiran. •
4.3. Standardni mehanizmi u UML-u
Izgrađivanje modela je jednostavnije ako postoji konformizam prema nekim predlošcima koji imaju standardna zajednička svojstva. Tako je i sa UML-om jer u njemu postoje četiri standardna mehanizma čijom primjenom se dobiva konzistentnost kroz sam jezik. 1. Specifikacije (eng. specifications) 2. Ukrasi (eng. adornments) 3. Podjele (eng. common divisions) 4. Mehanizmi proširivosti (eng. extensibility mechanisms) 4.3.1.
Specifikacije
UML je puno više od samog grafičkog jezika jer iza svake grafičke notacije stoji specifikacija koja daje tekstualan opis sintakse i semantike tog građevnog bloka. Npr. iza ikone klase stoji specifikacija koja pruža cijeli skup atributa, operacija i ponašanja koja ta klasa sadržava; vizualno, ta klasa može prikazati samo manji dio te specifikacije. Grafička notacija UML-a koristi se za vizualizaciju sustava, a specifikacija UML-a koristi se za opis detalja tog sustava. S obzirom na ovu podjelu, moguće je graditi model inkrementalno, crtajući dijagrame i nakon toga dodavati semantiku specifikaciji modela, ili direktno kreirajući specifikaciju (možda čak i korištenjem inžinjerstvom unatrag već postojećeg sustava) i nakon toga kreirati dijagrame koji su projekcija u te specifikacije. Specifikacije UML-a pružaju semantičku pozadinu koja sadržava sve dijelove modela sustava i gdje je su svi dijelovi na konzistentan način povezani. UML dijagrami su stoga samo vizualne projekcije na tu pozadinu, gdje svaki dijagram otkriva specifičan aspekt sustava. 4.3.2.
Ukrasi
Većina elemenata u UML-u ima jednoznačnu i izravnu grafičku notaciju koja pruža vizualnu reprezentaciju najvažnijih aspekata tog elementa. Npr. notacija za klasu je namjerno dizajnirana jednostavnom za crtanje jer su klase najčešči elementi koji se nalaze u modeliranju objektno orijentiranih sustava. Notacija za klasu također daje na uvid i najvažnije aspekte klase, a to su ime, atributi i operacije. Specifikacija klase može uključivati 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 grafički ili tekstualni ukrasi samoj notaciji klase (pravokutnik). Npr. Slika 16 prikazuje klasu koja je
17
ukrašena kako bi se naglasilo da je klasa apstraktna i da sadrži dvije javne (eng. public), jednu zaštićenu (eng. protected) i jednu privatnu (eng. private) operaciju.
Slika 16: Ukrasi Svaki element u UML notaciji počinje sa osnovnim simbolom, kojem se mogu dodati razni ukrasi specifični za taj simbol. 4.3.3.
Podjele
Pri modeliranju objektno orijentiranih sustava, sve se često dijeli na više načina. 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.
Slika 17: Klase i objekti 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). Gotovo svi građevni blokovi UML-a imaju sličnu razliku kao klase i objekti. Npr. postoje slučajevi korištenja i njihove instance, komponente i njihove instance, čvorovi i njihove instance, itd. Grafički, UML razlikuje objekte koristeći iste simbole kao i za klase i potcrtavajući samo ime objekta. Drugo, postoji separacija sučelja od implementacije. Sučelje deklarira ugovor, a implementacija predstavlja konkretnu realizaciju tog ugovora i odgovorna je za točno
18
izvršavanje kompletne semantike sučelja. U UML-u mogu se modelirati i sučelja i implementacije, kao na Slici 18.
Slika 18: Sučelja i implementacije Na ovoj slici je jedna komponenta, nazvana spellingwizard.dll koja implementira dva sučelja, IUnknown i ISpelling . Gotovo svi građevni blokovi u UML-u imaju sličnu razliku kao sučelja i implementacije. Npr. postoje slučajevi korištenja i suradnje koje ih realiziraju, kao i operacije i metode koje ih implementiraju. 4.3.4.
Mehanizmi proširivosti
UML pruža standardan jezik za pisanje nacrta za sustave programske podrške, ali nemoguće je, za jedan jezik, da ikada bude dovoljan kako bi izrazio sve moguće dijelove modela u svim mogućim domenama u vremenu. Iz tog razloga, UML je otvoren i lako ga je kontrolirano proširiti. UML-ovi mehanizmi proširivosti uključuju: •
Stereotipe (eng. stereotypes)
•
Označene vrijednosti (eng. tagged values)
Ograničenja (eng. constaints) Stereotip proširuje rječnik UML-a, omogućavajući kreiranje novih vrsta građevnih blokova koji su izvedeni iz već postojećih, ali su specifični 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 način. Tipično, želi se samo mogućnost bacanja i hvatanja iznimaka, ništa više. Stereotipovi ovdje dolaze u pomoć dajući mogućnost pretvaranja iznimke (kao klase) u poseban građevni blok. Klasa koja se želi tako unaprijediti označi se sa određenim stereotipom, kao klasa Overflow na Slici 19. Označene vrijednosti proširuju svojstva građevnih blokova UML-a, omogućavajući kreiranje novih informacija u specifikaciji tog elementa. Npr. pri izradi nekog programa za kojeg postoji velik broj izmjena javlja se potreba za označavanjem verzija i autora nekih kritičnih apstrakcija u tom programu. Verzije i autori ne postoje kao primitivi u konceptu UML-a. Moguće ih je dodati svakom građevnom bloku, kao klasi, uvodeći nove označene vrijednosti tom bloku. Na Slici 19, klasa EventQueue je proširena eksplicitnim označavanjem autora i verzije. •
19
proširuju semantiku građevnih blokova UML-a, omogućavajući dodavanje novih pravila ili mijenjanje već postojećih. Npr. ograničavanje klase EvenQueue na taj način da sve što se doda u nju mora biti poredano. Na Slici 19, prikazano je eksplicitno dodavanje ograničenja na operaciju add(). Ograničenja
Slika 19: Mehanizmi proširivosti Sva tri navedena mehanizma proširivosti omogućuju oblikovanje UML-a kako bi zadovoljavao potrebe projekta. Oni, također, daju UML-u sposobnost adaptiranja na nove tehnologije izrade programske podrške, kao što je pojava novih i moćnijih distribuiranih programskih jezika. Moguće je dodavanje novih građevnih blokova, modificiranje specifikacije već postojećih, pa čak i mijenjanje njihove semantike. Naravno, sva proširenja UML-a moraju biti strogo kontrolirana kako se na bi mijenjala osnovna namjena UML-a, a to je - komunikacija informacija.
20
5. ZAKLJUČAK
U ovom seminarskom radu prikazane su osnove UML-a, jezika za vizualno modeliranje, i opisani su njegovi principi i semantika. Dan je i pregled njegove povijesti razvoja kako bi se vidjelo da je nastao kao evolucija raznih objektno orijentiranih metoda. Iz svega što je do sad napisano može se zaključiti da je UML trenutno najbolji jezik za vizualno modeliranje i moglo bi se reći da niti nema neku dostojnu konkurenciju. Ne postoji jezik koji je toliko kompletan kao UML, a istovremeno i neovisan o razvojnom procesu. To znači da je UML vrlo prilagodljiv jezik i moguće je koristiti samo neke njegove dijelove u razvojnom procesu, a da se ne reduciraju njegove velike mogućnosti. Neovisnost o razvojnom procesu daje veliku fleksibilnost razvojnim timovima koji mogu zadržati svoje dosadašnje procese prilagođavajući UML svojim potrebama, istovremeno ih poboljšavajući i modernizirajući. UML svoju najveću snagu pokazuje na velikim projektima u kojima sudjeluje velik broj ljudi jer je komunikacija o sustavu koji se gradi gotovo dovedena do savršenstva i nije teško uključiti nove ljude na taj projekt ako razumiju UML. Proširivost UML-a i njegove semantike omogućuje mu prilagodljivost novim programskim jezicima čime se osigurava njegova budućnost i time se razvojnim timovima daje alat za koji znaju da će ga moći koristiti dugi niz godina. Sve to čini UML vrlo korisnim i prilagodljivim alatom za vizualno modeliranje sustava programske podrške i danas postaje gotovo neizbježan pomoćnik svakom programeru i dizajneru sustava.
21
LITERATURA
I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard: Object–Oriented Software Engineering – A Use Case Driven Approach, Addison-Wesley, Reading, Massachusetts, 1992. Rational Software Team: Using Rose – Rational Rose 2000e , Rational Software Corporation, 2000. T. Quatrani: Visual Modeling with Rational Rose 2000 and UML , Addison-Wesley, Reading, Massachusetts, 2000. G. Booch, I. Jacobson, J. Rumbaugh: The Unified Modeling Language User Guide , AddisonWesley, Reading, Massachusetts, 1998. D. Rosenberg, K. Scott: Use Case Driven Object Modeling with UML , Addison-Wesley, Reading, Massachusetts, 1999.
22
23