Sveučilište J.J.Strossmayera u Osijeku

Odjel za matematiku

Sveučilišni diplomski studij matematike i računarstva

UML Seminarski rad iz predmeta

Softversko inženjerstvo

Student: Dino Turopoli

Osijek, lipanj 2017.

Sadržaj

Uvod 1

Povijest UML-a 2

Analiza UML-a 2

UML konceptualni model 3

UML pogledi 3

Strukturalna klasifikacija 6

Statički pogleda 6

Pogled dizajna 9

Slučaj korištenja 12

Dinamičko ponašanje 13

Automat stanja 13

Pogled aktivnosti 13

Interakcija 14

Fizički raspored 17

Razvojni pogled 17

Upravljanje modelom 18

Pogled upravljanja modelom 18

Profili 19

Pravila UML-a 20

Literatura 21

1

Uvod

„Unifed Modeling Language“ (UML) je grafički jezik za modeliranje koji se koristi za vizualiziranje, specificiranje, konstrukciju i dokumentiranje softverskog sustava. Nastao je s namjerom standardiziranja način planiranja razvoja softverskog sustava. Sadrži informacije od strukturi i dinamičkom ponašanju sustava. Sustav se modelira kao kolekcija objekata koji su međusobno povezani. Statička struktura definira vrste objekata, njihovu implementaciju te odnose među njima. Dinamika sustava definira komunikaciju među objekatima kako bi se ostavrio neki cilj. UML također sadrži i organizacijsku strukturu koja služi za organiziranje modela u pakete.

Povijest UML-a

Pojavom objektno-orijentiranog programiranja krajem 1970.-ih dolazi do povećanja kompleksnosti aplikacija i stoga dolazi do pojave novog pristupa analizi i dizajnu softvera. Pojavljuje se velik broj objektno orijentiranih metoda. Neke od najbitnijih metoda, koje će kasnije postati i osnova za UML, su Booch-ova metoda, Jacobson-ova metoda OOSE (Object-oriented software engineering) i Rumbaugh-ova OMT (Object-modeling technique). Službeni početak razvoja UML-a je počeo 1994. kada su se u Rational Software Corporation-u ujedinili James Rumbaugh i Grady Booch, 1995. pridužio im se i Ivar Jacobson. Pod njihovim vodstvom 1996. je osnovana je organizacija UML Partners koja je završila specifikaciju za UML i predložila ga Object Management Group-i (OMG) za standardizaciju. U sklopu UML partnera nalazali su se i drugi poput HP-a, DEC-a, IBM-a i Microsoft-a. Ubrzo nakon sto je prihvaćena verzija 1.0 osnovana je grupa za semantiku koju je vodio Cris Kobryn kako bi se formalizirala UML specifikacija i kako bi se UML integriralo s drugim standardima. Godine 1997. prihvaćena je verzija 1.1. Kroz idućih par godina došlo je do manjim promjena u verzijama 1.2, 1.3, 1.4, 1.5.

Godina 2005. verziju 1.5 zamjenila je verzija 2.0. Specifikacija verzije 2.x sastoji se od 4 dijela:

Superstruktura – definira notaciju i sematiku za dijagrame i elemente modela

Infrastruktura - definira osnovne metamodele na kojima je bazirama superstruktura

2

OCL (Object Constraint Language) – definira pravila za elemente modela

UML Diagram Interchange - definira izgleda UML 2.x dijagrama

Analiza UML-a

UML je standardizirani jezik koji se koristi za pisanje nacrta za softver. Koristi se za vizualiziranje, specificiranje, konstruiranje i dokumentiranje komponenti nekog softverskog sustava.

UML je jezik za specificiranje što znači da služi za konstruiranje modela koji su precizni, kompletni i jednoznačni. Služi za specificiranje svih odluka vezanih za dizajn i implementaciju.

UML je jezik za vizualiziranje što znači da se koristi za vizualni prikaz komponenti softverskog sustava kako bi programeri bolje razumjeli odnose komponenti i kako bi grafički prikazali sustav prije nego što ga krenu programirati u nekom programskom jeziku.

UML je jezik za konstruiranje što znači da je moguće stvoriti direktnu poveznicu između modela u UML-u i programskih jezika kao što su Java, C++ i slični. Omogućava nam da stvari koje se najbolje predstavljaju grafički napravimo u UML-u, a stvari koje se najbolje predstavaljaju tekstualno napravimo u programskom jeziku. Ovaj način mapiranja omogućuje forward engineering : generiranje programskog koda iz UML modela, obratni proces je također moguć, tj. moguće je rekonstruirati UML model iz programskog koda.

UML je jezik za dokumentiranje što znači da pomoću UML-a možemo dokumentirati arhitekturu softverskog sustava sa svim njemim detaljima, zahjevima na sustav i testovima. Također UML omgućava i modeliranje aktivnosti planiranja projekta i upravljanja načinima puštanja projekta u rad.

3

UML konceptualni model

Da bi bolje razumjeli UML, potrebno je formirati koncepturalni model jezika, a to zahtjeva razumjevanje tri glavna elementa: osnovni građevni dijelovi UML-a, pravila koja određuju odnose između građevnih blokova i osnovni mehanizmi koji se primjenjuju kroz UML. Uvest ćemo UML poglede pomoću kojih ćemo podijeliti glavne elemente u četiri područja i detaljno ih opisati.

UML pogledi (eng. View)

Pogled predstavlja jedan dio softverskog sustava. Pogledi se mogu podijeliti u četiri područja:

Strukturalana klasifikacija Dinamičko ponašanje Fizički raspored Upravljanje modelom

U tablici 1. prikazani su pogledi i dijagrami koji se koriste u njima kao i glavni koncepti koji su vezani za određeni pogled. Tablicu ne treba shvatiti kao skup strogih pravila kojih se treba pridržavati nego kao skup natuknica.

4

Tablica 1. UML pogledi i dijagrami

5

6

Strukturalna klasifikacija (eng. Structural classification)

Strukturalna klasifikacija opisuje stvari unutar sustava i njihove međusobne odnose. Ona uključuje statičke dijelove modela kao što su klasa, suradnja (eng. Collaboration), slučaj korištenja (eng. Use case), komponenta, čvor, aktivna klasa. Strukturalna klasifikacija sadrži tri pogleda: statički, pogled dizajna i slučaj korištenja.

Statički pogled (eng. Static view)

Statički pogled modelira koncepte u domeni aplikacije i unutarnje koncepte koji su dio implementacije aplikacije, tj. statički pogled modelira aplikaciju s logičkog aspekta. Statički pogled je osnova UML-a. Naziva se statički pogled jer ne opisuje ovisnost ponašnja sustava o vremenu, za to služi dinamički pogled. Glavne komponente statičkog sustava su klase i njihovi odnosi. Klasa predstavlja skup objekata koji dijele iste operacije, relacicje, atribute i semantiku. Unutar UML klase se prikazuju kao pravokutnici koji se satoje od atributa, imena i opearcija ( vidi sliku 1.).

Slika 1. Klasa u UML-u

7

Odnosi među klasama mogu se podijeliti u nekoliko kategorija:

Asocijacije (eng. Association) – strukturalna relacija koja opisuje skup veza između objekata. U UML-u se predstavlja kao puna linija uz mogućnost određivanja smjera, ponekad sadrži i dodatne stvari kao n-arnost i ime (vidi slika 2.)

Slika 2. Asocijacija

Generalizacija (eng. Generalization) – relacija generalizacije u kojoj objekti specijaliziranih elemenata (djeca) mogu zamjeniti objektom generaliziranih elemenata (roditelj) te na taj način djeca dijele strukturu i ponašanje roditalje. Relacija generalizacije se grafički prikazuje kao puna linija sa šupljom strijelicom koja pokazuje prema roditelju (vidi Slika 3.)

Slika 3. Generalizacija

Ovisnosti (eng. Dependency) - semantička relacija između dviju stvari. Promjena u jednoj ( neovisnoj stvari) može utjecati na semantiku druge (ovisna stvar). Ovisnost se u UML-u prikazuje koa isprekidana linija, sa mogućom strijelicom i imenom (vidi slika 4.)

Slika 4. Ovisnost

8

Realizacija (eng. Realization) – semantička relacija između klasifikatora, gdje jedan klasifikator specifira ugovor koji drugi klasifikator mora izvršiti. U UML-u realizacija se prikazuje kao prijelaz između generalizacije i relacije ovisnosti (vidi slika 5.)

Slika 5. Realizacija

Statički pogled se prikazuje dijagramom klasa. ( vidi slika 6.)

9

Slika 6. Dijagram klasa

Pogled dizajna (eng. Design view)

Pogled dizajna modelira strukturu dizajna aplikacija što uključuje ekspanziju aplikacije u struktuirane klasifikatore, suradnju među njima koja pruža funkcionalnost i kreiranje dobro definiranih sučelja iz komponenti. U pogledu dizajna koristom dijagram unutarnje strukture, dijagram suradnje i dijagram komponenti.

Dijagram unutarnje strukture (eng. Internal structure diagram)

Dijagram unutarnje strukture prikazuje rastavljanje klasa na manje dijelove. Na slici 7. prikazan je primjer dijagrama unutarnje strukture. Na slici je primjer rastavljanja klase „sellTickets“ na tri dijela: sučelje prodavača karata ( ticket

10

seller), a bazu podataka izvođača i vodič (performace guide) koji prikazuje nastupe određenog izvođača s obzirom na datu i druge kriterije.

Slika 7. Dijagram unutarnje strukture

Dijagram suradnji

Suradnja je kontekstualni odnos među objektim koji služi kako bi se ispunio neki cilj. Sadrži kolekciju uloga koje su vezane za određeni objekt. Dijagram suradnji je interakcijski dijagram koji daje naglasak na strukturalnu organizaciju objekata koji primaju i šalju poruke. Na slici 8. nalazi se dijagram suradnji. Prikazuje kako tri zasebne komponente djeluju međusobno kako bi pridonjele funkcionalnosti sustava. Te tri komponente nisu dio jedne klase, nego su potpuno zasebne.

11

Slika 8. Dijagram suradnji

Dijagram komponenti

Komponenta je struktuirani klasifikator. Svaka komponenta ima dva sučelja

Provided interface – skup servisa koji ss omogućeni tom komponentom Required interface – skup servisa koje ta komponenta treba kako bi mogla

odraditi svoju zadaću

Dijagram komponenti prikazuje organzaciju i ovisnost između skupa komponenata. Bavi se statičkim pogledom na implemnatciju sustava i povezan je s dijagramom klasa tako da su komponente tipično mapirane na jednu ili vise klasa, suradnji ili sučelja. (vidi slika 9.)

12

Slika 9. Dijagram komponenti

Slučaj korištenja ( eng. Use case view)

Slučaj korištenja modelira funkcionalnost subjekta na osnovu interakcije vanjskih korisnika sa subjektom. Za prikaz ovog pogleda koristom dijagram slučaja korištenja. Dijagram slučajeva korištenja prikazuje skup slučajeva korištenja i vanjskih korisnika te njihove relacije. Dijagram se bavi statičkim pogledom na slučajeve korištenja i vrlo se je bitan kod organizacije i modeliranja ponšanja sustava.

Slika 10. Dijagram slučajeva korištenja

13

Dinamičko ponašanje

Dinamičko ponašanje opisuje ponašanje sustava kroz vrijeme i prostor. Uključuje tri pogleda: automat stanja, interakciju i aktivnost.

Automat stanja ( eng. State machine view)

Automat stanja sastoji se od stanja povezanih s prijelazim između stanja. Svako stanje modelira jedan period aktivnosti objekta tijekom kojeg je zadovoljen određeni uvjet. Kada se zadovolji uvjet prijalaza objekt prelazi iz jednog stanja u drugo stanje i efekt koji je vezan za prijelaz između stanja se izvršava.

Dijagram stanja se bavi dinamičkim pogledom na sustav i prikazuje automat stanja. Vrlo je bitan u modeliranju ponašanja klasa, sučelja ili suradnji i daje naglasak na ponašanje objekta određeno slijedom događanja. Na slici 11. prikzan je primjer dijagrama stanja.

Slika 11. Dijagram stanja

Pogled aktivnosti ( eng. Activity view)

Aktivnost prikazuje tok kontrole između računalnih aktivnosti koje su uključene u rad neke komponente. Akcija je primitivni računalni korak u aktivnosti. Čvor aktivnosti je grupa akcija i podakcija. Aktivnosti se prikazuju dijagramom aktivnosti. Slika 12. prikazuje dijagram aktivnosti koji opisuje proces organizacije predstave. Strijelice pokazuju sekvencijalne ovisnosti. Zatamnjene linije prikazuju račvanja i skupljanja kontrole. Na primjer tek nakon što se zakaže termin predstave kino može početi tražiti glumce i praviti kostime.

14

Slika 12. Dijagram aktivnosti

Interakcija (eng. Interaction view)

Interakcija opisuje niz poruka koje se izmjenjuju među dijelovima sustava. Bazira se na struktuiranim klasifikatorima i/ili suradnji. Uloga je atribut koji se dodjeljuje objektu. Interakcija se prikazuje dijagramom toka i dijagramom komunikacije.

15

Dijagram toka (eng. Sequence diagram)

Dijagram toka prikazuje skup poruka uređenih u niz. Svaka uloga prikzuje se kao „lifeline“ – vertikalna linija koja predstavlja ulogu tokom trajanja cijele interakcije. Poruke se prikazuju linijama između lifeline-ova. Dijagram toka može prikazi scenarij – pojedinačnu povijest transakcije. Petlje i paralelne aktivnosti se prikazuju kao ugnježđeni pravokutnici. (vidi slika 13.). Dijagram toka koristi se kako bi se pokazalo sekvencijalno ponašanje slučaja korištenja. Kada je ponašanje implementirano svaka poruka dijagrama toka odgovara operaciji na klasi ili uvjetu na prijelazu u dijagramu stanja.

Slika 13. Dijagram toka

16

Dijagram komunikacije

Dijagram komunikacije prikazuje interakciju između objekata pomoću niza poruka. Komunikacijski dijagram predstavlja kombinaciju informacija iz dijagrama klasa, dijagrama toka i dijagrama slučaja korištenja. Svaki pravokutnik prikazuje ulogu, tj. lifeline. Poruke između objekata prikazuju se kao strijelice pripisane linijama koje povezuju pravokutnike. Svaka poruka označena je redni brojem iz niza poruka. (vidi slika 14.).

Slika 14. Komunikacijski dijagram

17

Fizički raspored (eng. Physical layout)

Fizički raposred opisuje računale resurse u sutavu i razvoj komponenti na njima. Uključuje razvojni pogled.

Razvojni pogled ( eng. Deployment view)

Razvojni pogled predstavlja razvoj čvorova i artefakata. Artefakt je jedinica fizičke implementacije, npr. mapa, datoteka. Čvor je resur poput memorije računala. Artefakt može biti manifestacija jedne ili više komponenti. Razvojni pogled prikazuje se razvojnim dijagramom. Slika 16. prikazuje razvojni dijagram koji prikazuje tipove čvorova u sustavu i tipove artefkata koje oni sadrže. Čvor se prikazuje kvadrom, a artefakti se prikazuju pravokutnicima sa ključnom riječi.

Slika 16. Razvojni dijagram

18

Upravljanje modelom ( eng. Model management)

Upravljanje modelom opisuje organizaciju modela u hijerarhijskoj listi. Paketi su osnovna organizacijska jedinica modela. Postoje joši profili, a to su ekstenzije UML-a. Upravljanje modelom uključuje dva pogleda: upravljanje modelom i profil.

Pogled upravljanja modelom ( eng. Model management view)

Pogled upravljanja modelom modelira organizaciju samog modela. Model se sastoji od skupa paketa koji sadrže elemente modela, kao što su klase, automat stanja i slučaj korištenja. Paket mogu sadržavati i druge pakete, stoga model započinje sa startnim paketom koji indirektno sadrži sav sadržaj modela. Model je potpuni opis sustava. Upravljanje modelom se prikazuje dijagramom paketa koji je sličan dijagramu klasa. (vidi slika 17.)

Slika 17. Dijagram paketa

19

Na prethodnoj slici se nalazi dijagram paketa koji prikazuje potpuni rastav sustava za predstavu, koji se spominjao u prijašnjim primjerima, na pakete i njihove ovisone odnose.

Profili

UML je definiran korištenjem metamodela. Metamodel je model jezika za modeliranje. Metamodel je kompliciran i nebi se trebao mijenjati, stoga se mnogi alati prave na standardnim metamodelima i nemogu pravilno funkcionirati na drugim metamodelima. Mehanizam profila omogućava određene promjene na UML-u bez modificiranja metamodela. Profili i ograničenja omogućuju prilagodbu UML-a određenoj platformi i domeni.

UML uključuje tri konstruktora proširivosti:

Ograničenja – tekstualne izjave o semantičkim odnosim napisane na formalnom jeziku

Stereotipovi – nova vrsta elementa modela smišljena od strane korisnika i bazirana na postojecem tipu elmenta modela

Označene vrijednosti – imenovnim dio informacije pricvšćen na bilo koji element modela

Profil je koherentni skup ograničenja, stereotipova i označenih vrijednosti

Slika 18. Konstruktori proširivosti

20

Pravila za pisanje UML-a

Građevni blokovi UML nemogu se samo nabacati kada pravimo model. UML ima određena pravila koja određuju kako bi trebao izgledati model. Dobro definiran model je semantički konzistentan.

UML ima semantička pravila za:

Imena – kako nazivamo stvari, odnose i dijagrame Opseg – kontekst koji daje specifično značenje imenu Vidljivost – kako imena mogu vidjeti i koristi drugi korisnici Integritet – kako stvari pravilno i konzistentno međusobno povezati Izvodljivost – što znači simulirati i pokrenuti dinamički model

Kako modeli tijekom razvoju rastu i sve više korisnika ih može vidjeti u različito vrijeme i na različit način razvojni timovi ne prave samo dobro formirane modele već i modele koji su :

Neotkriveni – neki elementi su skriveni kako bi se pojednostavio pogled Nekompletni – neki elemnti mogu nedostajati Nekonzistentni – integritet modela nije garantiran

Ovi modeli su neizostavni u razvoju dok se mnogi dijelovi sustava tek otkrivaju.

21

Literatura [1] G. Booch, I. Jacobson, J. Rumbaugh: The Unified Modeling Language User Guide, Addison-Wesley, Reading, Massachusetts, 1998.

[2] http://en.wikipedia.org/wiki/Unified Modeling Language