Handledning för UML-diagram

En bild säger mer än tusen ord. Det är därför Unified Modeling Language (UML) skapades: för att erbjuda ett gemensamt visuellt språk i den komplexa programvaruvärlden som även är begripligt för affärsanvändare och alla andra som vill förstå ett system. Den här guiden täcker allt du behöver veta om UML. Även om du först kom i kontakt med UML under en formell utbildning och inte har använt det så mycket sedan dess, är det fortfarande ett praktiskt sätt att hålla komplexa system begripliga – särskilt när det används som levande dokumentation snarare än ett engångsleveransobjekt.

Vad är UML?

Unified Modeling Language (UML) skapades för att forma ett gemensamt, semantiskt och syntaktiskt rikt visuellt modelleringsspråk för arkitektur, design och implementering av komplexa programvarusystem, både strukturellt och beteendemässigt.

Det liknar de ritningar som används inom andra områden och består av olika typer av diagram. Sammanlagt beskriver UML-diagram systemets gränser, struktur och beteende samt objekten i det. När du skriver kod innehåller en applikation tusentals rader, och det är svårt att hålla koll på relationer och hierarkier i ett programvarusystem. UML-diagram delar upp programvarusystemet i komponenter och underkomponenter.

Det finns fyra kategorier av problemlösningsmodeller: imperativa, funktionella, deklarativa och objektorienterade språk. I objektorienterade språk uttrycks algoritmer genom att man definierar ”objekt” och låter objekten interagera med varandra. Dessa objekt är saker som ska manipuleras och de finns i den verkliga världen. Det kan vara byggnader, widgetar på ett skrivbord eller människor.

Objektorienterade språk dominerar programmeringsvärlden eftersom they modellerar verkliga objekt. UML är en kombination av several objektorienterade notationer: objektorienterad design, objektmodelleringsteknik och objektorienterad programvaruteknik.

UML utnyttjar styrkorna i dessa tre tillvägagångssätt för att presentera en mer enhetlig metodik som är lättare att använda. UML representerar bästa praxis för att bygga och dokumentera olika aspekter av programvaru- och affärssystemmodellering. Eftersom UML är standardiserat kan det tillämpas tvärs över programmeringsspråk och utvecklingsprocesser, vilket gör det allmänt läsbart för de flesta programvaruutvecklare.

I praktiken är UML också en form av visuell dokumentation som kan minska tiden som läggs på att förklara ett system på nytt. Denna dokumentation kan hjälpa ingenjörer på flera sätt, från att introducera nya medarbetare till att ge intressenter en snabb översikt över systemet så att utvecklare slipper slösa tid på möten.

UML:s historia och ursprung

Grady Booch, James Rumbaugh och Ivar Jacobson, även kända som ”The Three Amigos” inom programvaruteknik, slog sig samman för att skapa tydlighet för programmerare genom att ta fram nya standarder.

Gruppens arbete resulterade i att dokumenten UML 0.9 och 0.91 släpptes 1996. Det stod snart klart att flera organisationer, däribland Microsoft, Oracle och IBM, såg UML som avgörande för sin egen affärsutveckling. De etablerade, tillsammans med många andra individer och företag, resurser för att utveckla ett fullfjädrat modelleringsspråk. The Three Amigos publicerade The Unified Modeling Language User Guide 1999 och en uppdatering 2005, vilken inkluderar UML 2.0.

Object Management Groups (OMG) roll i UML

Enligt deras webbplats är Object Management Group® (OMG®) ett internationellt teknikstandardkonsortium som är öppet för medlemskap och drivs utan vinstsyfte, grundat 1989. OMG-standarder drivs av leverantörer, slutanvändare, akademiska institutioner och statliga myndigheter. OMG:s arbetsgrupper utvecklar företagsintegrationsstandarder för ett brett spektrum av tekniker och en ännu bredare grupp branscher. OMG:s modelleringsstandarder, inklusive UML och Model Driven Architecture® (MDA®), möjliggör kraftfull visuell design, exekvering och underhåll av programvara och andra processer.

OMG övervakar definitionen och underhållet av UML-specifikationer. Denna tillsyn ger ingenjörer och programmerare möjlighet att använda ett enda språk för många syften under alla faser av programvarans livscykel för alla systemstorlekar.

OMG definierar syftet med UML enligt följande:

• Att förse systemarkitekter, programvaruingenjörer och programvaruutvecklare med verktyg för analys, design och implementering av programvarubaserade system samt för modellering av affärsprocesser och liknande processer.

• Att föra branschen framåt genom att möjliggöra interoperabilitet mellan verktyg för visuell objektmodellering. Men för att möjliggöra ett meningsfullt utbyte av modellinformation mellan verktyg krävs enighet om semantik och notation.

UML uppfyller följande krav:

• Fastställa en formell definition av en gemensam Meta-Object Facility (MOF)-baserad metamodell som specificerar UML:s abstrakta syntax. Den abstrakta syntaxen definierar uppsättningen av UML-modelleringskoncept, deras attribut och relationer, samt reglerna för att kombinera dessa koncept för att bygga partiella eller fullständiga UML modeller.

• Tillhandahålla en detaljerad förklaring av semantiken för varje UML-modelleringskoncept. Semantiken definierar, på ett teknikoberoende sätt, hur UML-koncepten ska realiseras av datorer.

• Specificera de läsbara notationselementen för att representera de enskilda UML-modelleringskoncepten, samt regler för att kombinera dem till en mängd olika diagramtyper som motsvarar olika aspekter av de modellerade systemen.

• Definiera sätt på vilka UML-verktyg kan göras kompatibla med denna specifikation. Detta stöds (i en separat specifikation) med en XML-baserad specifikation av motsvarande modellutbytesformat (XMI) som måste realiseras av kompatibla verktyg.

Typer av UML-diagram

UML använder element och associerar dem på olika sätt för att skapa statiska diagram (som representerar strukturella aspekter av ett system) och beteendediagram (som representerar dynamiska aspekter av ett system). För den oinvigde kan det verka som om det finns ett oändligt antal UML-diagram, men i själva verket identifierar UML-standarder 14 typer av diagram som är uppdelade i två grupper enligt definitionen nedan.

Strukturella UML-diagram

• Klassdiagram: Detta är det vanligaste UML-diagrammet och den huvudsakliga grunden för alla objektorienterade lösningar. Det visar klasser i ett system, attribut och operationer samt relationen mellan varje klass. Klasser grupperas tillsammans för att skapa klassdiagram när man diagramför stora system. En klass representeras av en rektangel som innehåller tre vertikalt staplade fack: Det översta facket innehåller klassens namn och är obligatoriskt, medan de två nedre facken ger detaljer om klassattribut och klassoperationer eller beteenden.

• Komponentdiagram: Ett komponentdiagram är i grunden en mer specialiserad version av klassdiagrammet – samma notationsregler gäller för båda. Ett komponentdiagram bryter ner ett komplext system i mindre komponenter och visualiserar relationen mellan dessa komponenter.

• Sammansatt strukturdiagram: Dessa typer av diagram är i grunden ritningarna för den interna strukturen hos en klassificerare. De kan också användas för att visa beteendet hos ett samarbete eller klassificerarens interaktioner med sin omgivning via portar. De kan enkelt visa de interna komponenterna i valfri maskinvara för att ge en djupare förståelse för det inre arbetet.

• Driftsättningsdiagram: Dessa diagram är mest användbara för systemingenjörer och visar vanligtvis prestanda, skalbarhet, underhållsmässighet och portabilitet. När maskinvarukomponenter visas i förhållande till varandra är det lättare att hålla koll på hela ditt maskinvarunätverk och se till att alla element tas med i beräkningen vid en driftsättning.

• Objektdiagram: Objektdiagram visar exempel på datastrukturer vid en viss tidpunkt. Du kan använda ett klassdiagram för att visar en struktur och sedan använda objektdiagram som testfall för att verifiera att ditt klassdiagram är fullständigt. Eller så kan du skapa ett objektdiagram för att upptäcka information om modellelement och deras länkar.

• Paketdiagram: Paketdiagram används för att visa beroenden mellan olika paket i ett system. Ett paket, som visas som en arkivmapp, organiserar modellelement, som användningsfall eller klasser, i grupper. Det finns två speciella typer av beroenden definierade mellan paket: paketimport och paketsammanslagning.

• Profildiagram: Profildiagram är också en part av UML-standarden och används främst när du behöver skräddarsy UML för en specifik domän. Profildiagram har nyligen lagts till i UML 2.0 och är unika och används sällan i specifikationer. Ett profildiagram förstås bäst som en utökningsmekanism för att anpassa UML-modeller för specifika domäner och plattformar.

Beteendebaserade UML-diagram

• Aktivitetsdiagram: Aktivitetsdiagram används som ett alternativ till tillståndsmaskinsdiagram. Aktivitetsdiagram visualiserar de steg som utförs i ett användningsfall – aktiviteterna kan vara sekventiella, förgrenade eller samtidiga. Den här typen av UML-diagram används för att visa ett systems dynamiska beteende, men kan också vara användbart vid affärsprocessmodellering.

• Kommunikationsdiagram: Kommunikationsdiagram, som tidigare kallades samarbetsdiagram, visar hur objekt förhåller sig till varandra. De modellerar hur objekt associeras och ansluts via meddelanden inom den arkitektoniska designen av ett system. De kan också visa alternativa scenarier inom användningsfall eller operationer som kräver samarbete mellan olika objekt och interaktioner.

• Interaktionsöversiktsdiagram: Detta diagram ger en översikt över kontrollflödet mellan interagerande noder. De inkluderar startnoder, flödesslutnoder, aktivitetsslutnoder, beslutsnoder, sammanslagningsnoder, förgreningsnoder och samlingsnoder.

• Sekvensdiagram: Ett sekvensdiagram, som ibland kallas händelsediagram eller händendelsescenario, visar i vilken ordning objekt interagerar. På så sätt kan du visuellt representera enkla körtidsscenarier.

• Tillståndsdiagram: Tillståndsdiagram visar helt enkelt tillstånd och övergångar. Ett tillstånd avser de olika kombinationer av information som ett objekt kan innehålla, och detta UML-diagram kan visualisera alla möjliga tillstånd och hur objektet övergår från ett tillstånd till nästa.

• Tidsdiagram: Ett tidsdiagram beskrivs ofta som ett omvänt sekvensdiagram och visar hur objekt interagerar med varandra inom en given tidsram. Använd dessa diagram för att se hur lång tid varje steg i en process tar och hitta områden som kan förbättras.

• Användningsfallsdiagram: Användningsfallsdiagram modellerar hur användare, som visas som streckgubbar och kallas ”aktörer”, interagerar med systemet. Den här typen av UML-diagram bör vara en övergripande översikt över relationerna mellan aktörer och system, så det kan vara ett utmärkt verktyg för att förklara ditt system för en icke-teknisk målgrupp.

UML-ordlista

Bekanta dig med UML-vokabulären med den här listan hämtad från UML 2.4.1-dokumentet, avsedd att hjälpa de som inte är OMG-medlemmar att förstå vanliga termer.

• Efterlevnad av abstrakt syntax: Användare kan flytta modeller mellan olika verktyg, även om de använder olika notationer.

• Common Warehouse Metamodel (CWM): Standardgränssnitt som används för att möjliggöra utbyte av metadata om lager och affärsinformation mellan lagerverktyg, lagerplattformar och lagermetadatadepåer i distribuerade, heterogena miljöer.

• Efterlevnad av konkret syntax: Användare kan fortsätta att använda en notation de är bekanta med i olika verktyg.

• Kärna: I UML-sammanhang syftar kärnan vanligtvis på ”kärnpaketet”, vilket är en komplett metamodell särskilt utformad för hög återanvändbarhet.

• Språkenhet: Består av en samling tätt sammankopplade modelleringskoncept som ger användarna möjlighet att representera aspekter av det studerade systemet enligt ett specifikt paradigm eller en specifik formalism.

• Nivå 0 (L0): Den lägsta efterlevnadsnivån för UML-infrastrukturen, en enskild språkenhet som möjliggör modellering av de typer av klassbaserade strukturer som finns i de flesta populära objektorienterade programmeringsspråk.

• Meta Object Facility (MOF): En OMG-modelleringsspecifikation som utgör grunden för metamodellbelysningar i OMG:s familj av MDA-språk.

• Metamodell: Definierar det språk och de processer utifrån vilka en modell ska formas.

• Metamodellkonstruktioner (LM): Den andra efterlevnadsnivån i UML-infrastrukturen, en extra språkenhet för mer avancerade klassbaserade strukturer som används för att bygga metamodeller (med CMOF), till exempel UML självt. UML har endast två efterlevnadsnivåer.

• Model Driven Architecture (MDA): Ett tillvägagångssätt och en plan för att uppnå en sammanhängande uppsättning modelldrivna teknikspecifikationer.

• Object Constraint Language (OCL): Ett deklarativt språk för att beskriva regler som gäller för Unified Modeling Language. OCL kompletterar UML genom att tillhandahålla termer och flödesschemasymboler som är mer exakta än naturligt språk, men mindre svåra att bemästra än matematik.

• Object Management Group (OMG): Ett konsortium för specifikationer inom datorindustrin som drivs utan vinstsyfte och vars medlemmar definierar och underhåller UML-specifikationen.

• UML 1: Den första versionen av Unified Modeling Language.

• Unified Modeling Language (UML): Ett visuellt språk för att specificera, bygga och dokumentera artefakter i system.

• XMI: En XML-baserad specifikation av motsvarande modellutbytesformat.

Modelleringskoncept specificerade av UML

Systemutveckling fokuserar på tre olika övergripande systemmodeller:

• Funktionella: Dessa är användningsfallsdiagram som beskriver systemets funktionalitet ur användarens perspektiv.
• Objektbaserade: Dessa är klassdiagram som beskriver systemets struktur i form av objekt, attribut, associationer och operationer.
• Dynamiska: Interaktionsdiagram, tillståndsmaskinsdiagram och aktivitetsdiagram används för att beskriva systemets interna beteende.

Dessa systemmodeller visualiseras genom två olika typer av diagram: strukturella och beteendebaserade.

Objektorienterade koncept i UML

Objekten i UML är verkliga enheter som finns runt omkring oss. Inom programvaruutveckling kan objekt användas för att beskriva, eller modellera, det system som skapas i termer som är relevanta för domänen. Objekt gör det också möjligt att dela upp komplexa system i begripliga komponenter så att man kan bygga en del i taget.

Här är några grundläggande koncept i en objektorienterad värld:

• Objekt: Representerar en enhet och den grundläggande byggstenen
• Klass: Ritning av ett objekt.
• Abstraktion: Beteende hos en verklig enhet
• Inkapsling: Mekanism för att binda samman data och dölja dem från omvärlden
• Arv: Mekanism för att skapa nya klasser från en befintlig
• Polymorfism: Definierar mekanismen för att existera i olika former

I moderna team – särskilt de som arbetar med Agile – är dessa objektorienterade koncept ofta lättast att kommunicera när diagram behandlas som ”kärndokumentation” och uppdateras tillsammans med koden, snarare än att skapas en gång och sedan lämnas att bli inaktuella.

Varför team fortfarande använder UML-diagram (särskilt inom Agile)

Om du har gått någon form av formell kodutbildning introducerades du förmodligen till UML-diagram i skolan. Men hur mycket har du använt dem efter det? Eftersom UML-diagram tar lite tid att bygga och blir inaktuella ganska snabbt i en Agile-miljö har många programvaruutvecklare glömt bort dem.

Den oron är befogad: diagram som inte utvecklas i takt med ett projekt tappar snabbt sitt värde. Men när de hålls uppdaterade kan UML göra utvecklingen snabbare och kommunikationen tydligare. Även om många ingenjörer drar sig för diagram är de användbara i en Agile-utvecklingsmiljö. De håller utvecklingen produktiv och fokuserad. Istället för att se dem som något som bara är ”bra att ha”, bör du behandla dina UML-diagram som centrala delar av dokumentationen.

UML-diagram kan hjälpa ingenjörsteam att:

• Snabbt sätta in nya teammedlemmar eller utvecklare som byter team i arbetet.

• Navigera i källkod.

• Planera nya funktioner innan någon programmering sker.

• Kommunicera enklare med både tekniska och icke-tekniska målgrupper.

Diagram som inte utvecklas i takt med ett projekt är dock till ingen nytta, så det är nödvändigt att ha diagram som ständigt utvecklas. Ett sätt för team att minska underhållsbördan är att generera diagram från mer lättviktiga indata (till exempel textbaserade definitioner) så att dokumentationen förblir elastisk när systemet ändras. Lucidchart kan generera UML-sekvensdiagram från textmarkeringar, vilket gör diagrammeringen automatisk och elastisk.

Hur man gör ett UML-diagram

UML-diagram följer en specifik uppsättning regler och former, och du kan lägga ner mycket tid på att lära dig hur du bygger varje typ på rätt sätt. Lyckligtvis har vi gjort det enkelt för dig med smidiga handledningar, med start i klassdiagram, som guidar dig genom processen steg för steg.

Oavsett verktyg är det praktiska arbetsflödet detsamma: Välj den diagramtyp som matchar din fråga (struktur vs. beteende), modellera endast det du behöver för den aktuella målgruppen och återgå till diagrammet när koden och kraven ändras. Oavsett om du kartlägger den statiska arkitekturen i ett nytt programvarusystem eller visualiserar dynamiska användarinteraktioner, följ dessa steg för att bygga en effektiv modell:

1. Definiera ditt mål

Bestäm exakt vad du behöver visualisera. Fråga dig själv om du behöver kartlägga den statiska strukturen i ett system (strukturellt) eller visa hur komponenter interagerar och förändras över tid (beteendemässigt).

2. Välj rätt diagramtyp

Välj lämpligt UML-diagram baserat på dina systemkrav. Använd till exempel ett klassdiagram för objektorienterad systemstruktur, ett sekvensdiagram för tidsordnade interaktioner eller ett användningsfallsdiagram för att illustrera användarfunktionalitet. (Tips: Att börja med en av Lucidcharts färdiga UML-mallar är det snabbaste sättet att komma igång.)

3. Aktivera UML-formbibliotek

Eftersom UML använder en strikt visuell vokabulär behöver du rätt symboler. I Lucidchart klickar du på ”Fler former” längst ner i den vänstra menyn, söker efter ”UML” och markerar kryssrutorna för de specifika formbibliotek du behöver (t.ex. UML-klass, UML-tillstånd, UML-sekvens).

4. Lägg till och definiera dina former

Dra och släpp enheter, objekt, noder eller aktörer på din rityta. Placera dem logiskt och dubbelklicka i formerna för att lägga till anpassad text, specifika attribut och operationer för dina objekt.

5. Koppla ihop dina komponenter

Upprätta relationer mellan dina enheter genom att dra linjer mellan dem. Anpassa linjernas slutpunkter (pilar, diamanter osv.) för att exakt återspegla specifika UML-relationer, till exempel arv, sammansättning, beroenden eller grundläggande associationer.

6. Granska och samarbeta

UML är utformat för att fungera som ett gemensamt språk mellan utvecklare, ingenjörer och affärsintressenter. När ditt diagram har utarbetats kan du använda Lucidcharts samarbetsfunktioner i realtid för att bjuda in ditt team att granska arkitekturen, lämna kommentarer och färdigställa ritningen.

Bli en UML-evangelist

Ibland räcker det inte med att du själv är med på UML-tåget. Som programvaruutvecklare arbetar du oftast i team, och det är viktigt att få med alla andra på resan.

Om ditt team är tveksamt till att integrera UML-diagram i utvecklingsprocessen kan du föreslå att ni använder dem i bara ett projekt till att börja med. När ditt team ser vilken tillgång UML-diagram är för dokumentationen kommer de att vara mer villiga att göra dem till ett nödvändigt steg.

Dessutom är UML-diagram inget besvär med Lucidchart – de är en tillgång.