UML. Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN Åbo, Finland url:

Transkript

1 UML Tomas Czarnecki Institutionen för Informationsbehandling Åbo Akademi,FIN Åbo, Finland url: Abstrakt The Unified Modeling Language, UML, är ett visuellt modelleringsspråk för designande och planerande av mjukvara och databaser. UML är ett bra hjälpmedel och verktyg för programmerare att förstå hela systemets uppbyggnad och struktur. UML består av flere diagram o modeller. De vanligaste och mest använda diagram och modeller är Use Case diagram, Class diagram, Interaction diagram, State diagram, Activity diagram samt Implementation diagram. Dessa har alla sin egen funktion i beskrivningen av ett system. Jag kommer också att titta på två olika UML verktyg. Jag har valt att studera ett verktyg som är kommersiellt och ett som är gratis. Verktygen har en mycket centrala roll inom användningen av UML och därför har jag valt att även gå in på den biten. Klassificering D.2.2 Design Tools and Techniques ACM-SIG: SIGSOFT 1. Inledning Kraven på ett bra datorsystem är idag mycket höga och kraven på dem som producerar systemen ännu högre. Mjukvaran måste vara säker och ha så lite fel som möjligt. Systemet måste vara lätt att bygga vidare och förbättra på, även av andra programmerare än de som skrivit den ursprungliga koden. För att hålla dagens kunder nöjda måste också systemen bli färdiga i tid.

2 UML, The Unified Modeling Language, är ett objektorienterat standard för designande och dokumenterande av ett projekt. Med hjälp av diagram och modeller kan sedan programmeraren lätt komma igång med själva skrivandet av programkoden. För att få färdigt ett bra och pålitligt system krävs inte enbart ett bra team med skickliga programmerare utan det behövs också ett bra och lättförståeligt sätt att dokumentera hela projektet på. Med dokumentering menar jag då inte bara en beskrivning av det slutliga systemet utan en beskrivning av hela programvaruprocessen, specifikationer, användare o.s.v. Detta är ett mycket intressant och viktigt område och därför tycker jag att det hör till en av dom viktigaste delarna inom hela systemets produktionscykel. 2. De viktigaste diagrammen och komponenterna i UML UML är ett hjälpmedel eller redskap för att planera och dokumentera ett system. UML lämpar sig för vilket programmeringsspråk som helst men är bäst lämpad för objektorienterade språk så som t.ex. Java, C++, Python. Med hjälp av UML kan man visuellt med diagram och modeller designa och dokumentera alla skeden i ett projekt. T.ex. specifikationen kan göras med ett s.k. Use Case diagram där man visar vilka funktioner en användare kan göra med hela systemet eller med bara en liten del av systemet. UML består av 12 olika diagram som man kan indela i tre olika kategorier, en som beskriver systemets struktur, en som beskriver beteendet av systemet och en som beskriver hur man kan organisera systemets olika modeller och komponenter. Jag kommer härnäst att förklara kort hur de olika diagrammen ser ut och till vad de används. Jag kommer däremot inte att gå igenom precis alla diagram, utan endast de viktigaste och mest använda. 2.1 Use case diagram Ett use case diagram är enligt UML specifikationerna [OMG01] ett diagram som visar relationer mellan användare eller aktörer och en use case inom ett system.

3 Use case diagrammet består i huvudsak av aktörer, use cases samt relationer mellan dem. Utöver de tre delar som jag nämnde ovan kan man också nämna system gräns (System boundary), relationer mellan use cases samt generalisationer mellan två aktörer eller två use cases. [SP00] En use case förklarar en handling som ger en användare eller aktör ett mätbart resultat. [SWA02] En use case ritas som en horisontell oval med namnet i mitten. En aktör kan vara en person, en organisation eller ett annat externt system, som har växelspel med systemet. En aktör ritas ofta som en stickgubbe med namnet under. Relationerna mellan aktörer och use cases ritas som ett vanligt streck mellan dem och visar vilken aktör som får/kan använda sig av uppgiften som use casen gör. Allmänt kan man säga att use case diagram används för att få fram vad systemet skall kunna göra och klara av. En av de goda egenskaperna som use case diagrammet har är att även icke-tekniska människor lätt kan förstå den. 2.2 Class diagram Ett use case diagram som visar ett filmuthyrningssystem. Class diagram, eller klassdiagram översatt till svenska, är det vanligaste och mest använda digrammet i UML. Klassdiagram används för att designa och dokumentera systemet. Diagrammet visar vilka klasser systemet är uppbyggt av och hur de är relaterade till varandra. I diagrammet kan man också ha vissa andra komponenter så som paket och interface. Jag kommer att berätta hur ett klassdiagram ser ut och vilka

4 som är de viktigaste och vanligaste komponenterna. Ett klassdiagram kan vara mycket komplext med många klasser och andra komponenter. Den vanligaste och viktigaste komponenten är förståss klassen. Klassen ritas som en rektangel med namnet på. För att man skall kunna beskriva ett objekt av en klass beteende och tillstånd behövs attribut och operationer. Operationerna, som skrivs längst nere i klassfiguren, definierar på vilka sätt ett objekt kan funktionera eller påverkas. Attributen, som skrivs mellan klassnamnet och operationerna i klassfiguren, beskriver datan som som finns i ett objekt av en klass. En simpel klass. De två viktigaste typerna av relationer mellan komponenter i klassdiagrammet är association och generalisation. Association som är den vanligaste formen av relationer mellan klasser, ritas som ett streck mellan klasserna. Association används t.ex. mellan två klasser då en klass skickar ett meddelnade till en annan klass. Ett annat fall då association används är då ett objekt av en klass skapar ett objekt av en annan klass. Med andra ord så används association då ett objekt av en klass behöver veta om ett annat objekt. [SP00] Det finns flera olika specialfall av associationer så som aggregation och composition som berättar mera om hurudan association det är frågan om. Generalisation, som ritas som en pil mellan två klasser, är den andra av de vanligaste relationstyperna mellan två klasser. Generalisation används då det är fråga om arv. Som ett exempel antar vi att vi har två klasser, Fordon och Bil. Förutom egna egenskaper har också Bil alla de egenskaper som Fordon har. För alla objekt av klass Bil är ju en sorts Fordon. Då är Fordon en generalisation av Buss. Av de andra komponenterna som inte används lika ofta kan man nämna paket. Paket är en samling av andra komponenter eller modeller. [SP00]

5 Ett enkelt exempel på ett klass diagram. 2.3 Interaction diagrams Ovan har jag förklarat de två viktigaste och mest använda diagrammen i UML kort. Nu ska jag ännu visa några använbara diagram. Interaction diagrams bygger vidare på use case diagrammet och klassdiagrammet. Avsikten med interaction diagrams är att visa hur objekten samspelar för att få en uppgift gjord. I praktiken tar man från use case diagrammet en use case och visar hur systemet förverkligar det. Med hjälp av interaction diagram kan man enkelt se precis hur objekten samspelar. Detta är till en stor hjälp då flera utvecklare jobbar på samma funktion. Det är dock inte meningen att man skall göra interaction diagram av alla use cases som vi har i vårt system utan enbart av de som kan vara svåra att förstå eller av dem som vållar problem. Det är ju ingen idé att göra ett diagram bara för att sen aldrig använda det för att det är så självklart, då har vi bara ödat tid och resurser. UML har två olika typer av interaction diagram, sequence och collaboration diagram. Båda diagrammen visar så gott som samma information och vissa UML verktyg kan t.o.m. generera den ena från den andra. Diagrammen har dock små skillnader och valet av vilketdera diagram man skall använda beror just på dessa skillnader. Jag kommer härnäst att kort berätta och ge små exempel på dessa diagram samt visa skillnaden på dem. Collaboration diagram består av tre huvudkomponenter objekt, länkar och aktörer. Objekten visas som en rektangel med objekt- och klassnamn. Länkarna som visar växelverkan mellan objekten fungerar som associationer i klassdiagrammen.

6 Länkarna ritas som streck mellan objekten. För att diagrammet skall bli förståeligt skrivs växelverkans funktion ut bredvid länken och en pil som visar åt vilket håll meddelandet går samt en numrering. Numreringen finns för att man skall kunna se i vilken ordning meddelandena går. Ett collaboration diagram av ett scenario av ett lyckat köp från en läskautomat. Sequence diagrammet har samma huvudkomponenter som collaboration diagrammet men de ställs upp på ett lite annorlunda sätt. Objekten och aktörerna är uppställda i en rad med en streckad linje under dem. Linjen representerar objektets livstid. Att sequence diagrammet fokuserar mera på objektets livstid och funktionens tid är den största skillnaden gentemot collaboration diagrammet. Tiden framskrider i diagrammet uppifrån ner. När ett objekt är aktivt märks det ut med en avlång rektangel på objektets tidsstreck. Länkarna sätts ut mellan tidsstrecken på den nivå då växelspelet sker. Länkarna är numrerade och namngivna på samma sätt som i collaboration diagrammet.[sp00]

7 Ett sequence diagram av ett scenario av ett lyckat köp från en läskautomat. 2.4 State diagram State diagram, eller tillståndsdiagram på svenska, används för att modellera objekts reaktioner till meddelanden och andra händelser. Alltså vad ett objekt gör till näst eller hurudant meddelande det skickar vidare efter att det fått ett meddelande beror på objektets attribut och länkar. Jag skall visa hur diagrammet fungerar med ett litet exempel. Vi har ett objekt av klassen HyrFilm som har en boolesk variabel uthyrd. Variabeln uhyrd har värdet falsk som initialvärde och betyder att en viss film finns i hyllan. När variabeln uthyrd är falsk så är objektet villigt att ta emot meddelandet hyrut(). Då objektet tar emot meddelandet hyrut() sätter den variabeln uthyrd till sann vilket betyder att nu är filmen uthyrd och filmen finns inte i hyllan. Nu är returnera() det ända meddelande som objektet är villigt att ta emot. Då detta meddelande kommer sätts variabeln uthyrd igen till falsk och objektets tillstånd är att filmen finns på hyllan. Ett enkelt tillståndsdiagram av HyrFilm klassen.

8 Tillståndsdiagrammets komponenter består av tillstånd (state), övergång (transition), händelse (event) och startpunkt. Tillstånd ritas som en rektangel med runda hörn, övergångar ritas som pilar mellan tillstånden, händelser (som i exemplet ovan är meddelanden) skrivs ovanför övergångarna och startpunkten, som markerar objektets skapande, ritas som en svart punkt. [SP00] 2.5 Activity diagram Activity diagram, på svenska aktivitetsdiagram, används för att visa hur en operation kan implementeras. Om en operation har flere uppgifter att utföra är det lätt att med hjälp av aktivitetsdiagram bestämma i vilken ordning det lönar sig att implementera dem. Man kan också med hjälp av activity diagram bestämma i vilken ordning olika use cases skall implementeras. T.ex. kan det hända att data som hör till en viss use case måste uppdateras före en annan use case läser samma data. Aktivitetsdiagram visar sammanhållningen mellan dessa aktiviteter och därför är det lätt att bestämma ordningen. Notationen är nästan likadan som i state diagram men med några extra element. Några av de extra elementen är aktivitet, synkroniseringsribba, beslutsromb och start samt stoppunkt. En aktivitet skiljer sig från ett tillstånd i state diagram på det sättet att den lämnar aktiviteten när den är färdig med sin uppgift och inte när den får ett meddelande som i ett tillstånd. Synkroniseringsribban, ritas ut som en tjock horisontell ribba, låter alla aktiviteter som kommer till ribban vänta tills alla aktiviteter som har en övergång till ribban nått den. Beslutsromben (decision diamond) används för att visa att ett beslut måste ske vid den, t.ex. en if-sats. [SP00]

9 Ett aktivitetsdiagram som visar ett vanlig drag i ett schackspel. 3. Verktyg Det finns en stor mängd av olika UML verktyg tillgängliga. Många är mycket bra med fina och många egenskaper men det finns åtminstone lika många som är rent ut sagt usla. När man ställs inför valet vilket verktyg man skall använda sig av skall man tänka på till vilket ändamål verktyget ska användas. Vill man bara rita ett diagram för att sen spara det som en bild kan man använda ett enkelt program. Men vill man igen kunna dokumentera och designa ett helt system och kunna upprätthålla sina modeller under ett helt projekt skall man välja ett större och komplexare verktyg. Det finns verktyg allt från kommersiella, vars licenser är mycket dyra till helt sådana som är helt gratis. Jag kommer nu att ta upp två olika verktyg, Rational rose som är ett kommersiellt program och SMW som är ett gratis program. Jag kommer i korthet att berätta vad man kan utföra med dessa program och vad som skiljer dem åt. 3.1 Rational Rose Rational Rose är en produktfamilj utgiven av IBM. IBM har varit med från första början och utvecklat UML standarden och därför har de också en mycket seriös produkt. Rational Rose hör till de UML verktyg som är mest fullständiga av dem alla. Man kan t.o.m. tänka sig att Rational Rose mera är ett systemutvecklingsverktyg än ett UML verktyg.

10 Rational Rose är i första hand ämnat för utveckling av system skrivna i Java men den förstår sig också på bl.a. C++ och Visual Studio. Själva UML har inte några språkbegränsningar men en av Rational Rose egenskaper är att den klarar av att generera programkod av en UML modell. Den klarar också av att generara en UML modell från programkod. Detta är en mycket bra egenskap när man skall försöka hitta fel eller för att se att koden faktiskt gör det man vill att den skall göra. Förutom att man givetvis kan modellera alla diagram som UML har kan man också designa logiska och fysiska databaser. En skärmdump av Rational Rose. Rational Rose har ett bra och enkelt interface och det är mycket enkelt att komma igång med jobbet. Om man vill kan man få färdigt inbakat Java s bibliotek vilket underlättar en hel del att modellera fullständiga Java program. Ett par mindre bra lösningar har förstås Rational Rose också men de är främst kosmetiska. En sak som jag inte hittade var möjligheten att exportera ett diagram som en bild. Detta är en mycket användbar funktion då man bara vill göra ett diagram och inte designa ett helt system.[irs]

11 3.2 SMW Software Modeling Workbench, SMW, är ett gratis alternativ i UML verktygens värld. SMW är skriven i Python och baserar sig på OMG MOF (Meta-Object Facility) och UML1.4 standarden. SMW är ett resultat av ett UML project på TUCS (Turku Centre for Computer Science) Software Construction Laboratory. SMW är menad för designandet av program skrivna i Python, vilket betyder att den klarar av att generera Python programkod av UML modeller samt generara UML modeller till Python kod. Med SMW kan man modellera alla diagram. SMW är mycket lätt använt och man lär sig de flesta funktionerna snabbt. Programmet ger alltid felmeddelanden ifall man försöker göra fel när man designar diagram, vilket lättar modellerandet avsevärt. En skärmdump av SMW. [SMW] Verktyget är ganska långsamt och har en del buggar. Uvecklingen av programmet har mer eller mindre upphört så detta betyder att felen som finns inte kommer att repareras. [SMW]

12 3.3 Slutsatser om Rational Rose och SMW Skillnaderna är ganska stora mellan Rational Rose och SMW. Programmeringsspråken som verktygen är ämnade för är en ganska viktig aspekt och där talar nog Java, C++ plus en del andra språk sitt för Rational Rose. Åtminstone ifall det är en privatperson som skall använda verktyget kan det bli dyrt ifall man måste inhandla ett nytt verktyg varje gång man skall designa ett system i ett annat programmeringsspråk än det man använt först. SMW är kanske lite lättare att använda på grund av att den är mindre komplex än Rational Rose. Men SMW är enligt SMWs hemsida bara ett substitut till andra verktyg och ingen ersättare [SMW], vilket kanske är en orsak till att man inte har velat göra så stora kraftansträngningar för att få ett konkurrenskraftigt verktyg. Aspekter som talar för SMW är att det är ett gratis verktyg och om man vill designa ett system som man planerat skriva i Python är det ett mycket bra alternativ. Rational Rose är en hel systemutvecklingsfamilj som är mycket komplex och har det mesta man behöver då man vill utveckla ett system. Det är enkelt att komma igång med Rational Rose och på grund av att verktyget är så komplett behöver man inte ha några ytterligare utvecklingsverktyg. Helhetsintrycket gav en mycket bra bild av ett relativt snabbt och fungerande verktyg [IRS] 4. Sammanfattning I denna artikel har jag berättat vad UML, The Unified Modeling Language, är och vad det består av. Vilka diagram som är de viktigaste och mest använda samt till vad man anväder dem till. Dessutom har jag kort berättat om två olika UML verktyg, Rational Rose som är ett Kommersiellt verktyg och SMW, Software Modeling Workbench, som är ett gratis verktyg. SMW är ett bra verktyg för Python baserade projekt men men också tack vare det ganska begränsat. Rational Rose är ett mångsidigt utvecklingsverktyg med stöd för flere programmeringsspråk, vilket är ett stort plus. UML är till en stor nytta under hela systemutvecklingsprocessen. UML är lätt förståeligt och gör det lättare för alla parter, kunder, designare och kodare, att förstå varandra. Detta kan minimera misstag och fel i ett tidigt skede.

13 Referenser [SP00] P.Stevens, R.Pooley: Using UML, software engineering with objects and components, 2000 [OMG01] OMG, Object management group, [SWA02] Scott W. Ambler: UML Use Case Diagram Guidelines, online tips and techniques for creating better software diagrams, [IRS] IBM Rational software, [SMW] Software Modeling Workbench,