Introduktion UML står för Unified Modeling Language. Det är tänkt att fungera som hjälpmedel vid modellering av alla tänkbara typer av utvecklingsarbeten, inte bara inom dataomdrådet. Det största värdet av modellering är som dokumentation och som hjälpmedel att bena ut sammanhang. Eftersom människan har en väldigt väl utvecklad förmåga att bearbeta information visuellt vill man givetvis dra nytta av detta då det är möjligt. Väldigt ofta kan det räcka med att klottra ned kända fakta på ett papper för att man skall kunna reda ut problem. Hjärnan kan på något sätt bearbeta informationen lättare när man kan se på det. När det inte räcker med att intuitivt klottra ned figurer och text så kan det vara till hjälp med standardiserade figurer. Inte bara kan man få tillgång till genomtänkta figurer och regler utan man kan dessutom underlätta informationsutbyte mellan personer då man har ett gemensamt språk. UML är alltså tänkt att vara ett visuellt språk för att beskriva modeller av olika slag. (i vårt fall objektorienterade program). UML är inte en metod, dvs det är inte ett verktyg för att beskriva hur man utvecklar system. För detta ändamål finns det metoder och processer som är framtagna, där vissa av dem är baserade på UML (exempel på detta är Unified Process, UP, eller dess vidareutvecklade Rational Unified Process, RUP) Byggstenar Mycket av UML är skapat med tanke på objektorienterad modellering. UML är väl förberett för att vara utbyggbart och flexibelt för att passa i olika modelleringssammanhang. Därför baserar man alla element i en modell på stereotyper, där exempelvis en klass är en stereotyp av namn class. Olika stereotyper kan visas visuellt på olika sätt och man har därför försökt att gruppera in skilda begrepp och standardisera stereotyper för dessa. Ibland kan man vilja ha olika utseenden på en och samma stereotyp i olika sammanhang och ibland vill man ha ett enhetligt utseende på flera olika stereotyper. Därför kan man förtydliga ett elements stereotyp genom att skriva stereotypnamnet vid elementet inom "chevrons" ('«' och '»', ett tecken med två vinklar), på vardera sidan av stereotypnamnet. Detta skrivs ofta som två mindre än-tecken och två större än-tecken i brist på tillgång till det korrekta tecknet. 1(7)
Klassdiagram Klassdiagram används för att gruppera information och belysa vissa delar av en modell på ett enkelt och överskådligt sätt. Det är inte bara en möjlighet utan även en rekommendation att belysa olika delar av systemet i olika klassdiagram. Det kan ibland till och med vara rekommenderat att visa olika aspekter av samma delar i ett system i olika klassdiagram som fokuserar på sitt speciella område. Ett klassdiagram innehåller vanligtvis anteckningar, klasser, interface, associationer, aggregat, kompositioner, generaliseringar, genomföranden och beroenden. Exempel 1.Enkelt klassdiagram för en bank. Anteckningar I ett klassdiagram är det nyttigt att kunna lägga till lite kommentarer eller annan information som inte ryms inom UMLs vanliga vokabulär. Anteckningar kan läggas till och om man vill associeras till enskilda element i diagrammet. Figuren visar en anteckning med texten "Skapar cyklar" som är knuten till en klass "Factory". Anteckningar kan vara kopplade till alla element i ett klassdiagram. Exempel 2.Anteckning kopplad till klass. 2(7)
Klasser Standardutseende för en klass är en box med sektioner (i nämnd ordning): 1. titel som beskriver klassnamn 2. lista av attribut 3. lista av operationer Exempel 3.Grundutseende för klass. Attribut kan skrivas på formatet attributnamn : typ, där typen beskriver attributets typ. Typinformationen kan utlämnas om det inte tillför något. Synlighet för attribut och operationer kan visas genom att specificera '+', '-' och '#' framför attribut/operationnamnet, där synligheten är public, private respektive protected. (Rational Rose använder sig av ikoner för att beskriva synligheten) public + private - protected # Exempel 4.Synlighet för attribut och operationer. 3(7)
Interface Ett interface kan representeras på två olika sätt. I ett klassdiagram är den vanligaste notationen väldigt lik utseendet för en klass. Dock är stereotypen «Interface» specificerad vid namnet. Stereotyper skrivs inom "chevrons", ett tecken med två vinklar på vardera sidan. Detta skrivs ofta som två mindre än-tecken och två större än-tecken. Exempel 5.Interfaceutseende. Relationer Relationer mellan objekt kan ta form på många olika sätt, bl.a. via enkla associationer, generaliseringar, aggregat och beroenden. Innebörden är att två element har någon sorts koppling till varandra. Man kan tänka sig många fler typer av relationer, men vid skapandet av UMLstandarden har man försökt att identifiera de mest utmärkande och vanliga typerna och därefter standardiserat stereotyper för dessa. Association En association är en koppling mellan två olika objekt (vanligtvis klasser). Dessa representeras oftast i programkod som pekare eller referenser. En association kan vara enkelriktad eller dubbelriktad (utan pilspets). Oftast använder man dubbelriktade associationer, men om man vill minimera kopplingen mellan klasser så kan enkelriktade associationer passa bra. Associationer kan även specificera multiplicitet, dvs hur många kopplingar det finns på vardera sidan om en association. I figuren visas att banken har en association som heter accountlist till noll eller flera konton, samt att Kontot har en icke-namngiven association till banken. Figuren visar även att associationen är protected genom att minus (-) är tillsatt framför associationsnamnet. Exempel 6.Association mellan två klasser, där associationen har multiplicitet specificerat. Dessutom har associationen ett roll-namn på ena änden. 4(7)
Aggregate Aggregat är ungefär samma sak som en association, men den visar lite tydligare att två klasser har ett "har ett" - "är del av" förhållande. (Exempel: En skola har studenter. Studenterna är en del av skolan, mellan klasserna råder då ett aggregatförhållande.) Ett aggregat visas med hjälp av en liten romb i den ändan där "har ett"-förhållandet gäller. I figuren visas att förhållandet en bank består av sina kunder. Ett aggregat kan vara enkelriktat precis som en association. Exempel 7.Aggregat. Mer specialicerad variant av association Composition Komposition är ytterligare en variant av association som är i stort sett identisk med aggregat men innefattar begränsningen att det bara finns en enda ägare till delarna i "har ett"-förhållandet. (Exempel: En bank består (delvis) av sina konton, och dessa konton finns bara i den aktuella banken.). Som vi tidigare såg i ett exempel med aggregat så kan exempelvis förhållandet mellan studenter och skola vara så att studenterna även är del av andra skolor. Komposition visas genom att associationen har en fylld romb vid "har ett"-förhållandets sida. I figuren visas samma exempel som för association förutom att associationen har ersatts med en komposition, vilket gör diagrammet mer uttrycksfullt. Betraktaren av diagrammet får en bättre uppfattning hur förhållandet mellan banken och kontot är tänkt att vara. Exempel 8.Komposition. Mer specialiserad variant av aggregat 5(7)
Generalization (Arv) Generalisering av klasser innebär vanligtvis att en klass har ärvt implementation från en överklass. Detta representeras i UML genom en generaliseringsassociation. Generaliseringen representeras av en pil som pekar ut överklassen. Exempel 9.Två varianter av arv. Realization Skillnaden mellan generalisering och genomförande är hårfin när det gäller klassdiagram. I andra sammanhang är skillnaden något mer beskrivande. Men i praktiken används genomföranderelation i klassdiagram när man visar att en klass implementerar ett interface. Relationen påminner mycket om generaliseringsrelationen, men har streckade linjer. Exempel 10.Realization. 6(7)
Dependency Ibland kan det vara viktigt att visa att två element i ett diagram har någon sorts beroende mellan sig. Beroendeassociationer används vanligtvis i klassdiagram för att visa att en klass använder sig av eller skapar ett objekt av en annan klass. Figuren visar att Factory och Bicycle har ett beroende på varandra. Factory skapar cyklar, men den äger inte, har inte eller är på annat sätt associerad till cyklarna den skapar. Exempel 11.Factory har ett beroende till Bicycle eftersom Factory måste känna till Bicycle för att kunna skapa cyklar. Referenser James Rumbaugh, Ivar Jacobsen, and Grday Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999 Martin Fowler, UML Destilled, 3 rd Ed. A brief Guide to the Standard Object Modeling Language, Addison-Wesley, 2004 Med tillstånd från Martin Skogevall Ins. för Datavetenskap och Elektronik Mälardalens högskola 7(7)