Vad är Unified Modeling Language?

Unified Modeling Language (UML) skapades för att bilda ett gemensamt, semantiskt och syntaktiskt rikt visuellt modelleringsspråk för arkitektur, design och implementering av komplexa programvarusystem, både ur ett strukturellt perspektiv och ett användarbeteendeperspektiv. UML är användbart även inom andra områden än programvaruutveckling, exempelvis processflöden i tillverkningsindustrin.

Det är analogt med ritningarna som används inom andra områden och består av olika typer av diagram. Tillsammans beskriver UML-diagrammen avgränsningarna, strukturen och beteendet hos systemet och de objekt som finns inom systemet.

UML är inget programmeringsspråk, men det finns verktyg som kan användas för att generera programkod på olika språk med hjälp av UML-diagram. UML har ett direkt samband med objektorienterad analys och design.

Det finns många paradigm eller modeller för problemlösning inom datavetenskapliga studier av algoritmer och data. Det finns fyra kategorier av problemlösningsmodeller: imperativa, funktionella, deklarativa och objektorienterade språk (OOP). I objektorienterade språk uttrycks algoritmer genom att definiera ”objekt” och låta objekten interagera med varandra. Dessa objekt är saker som kan manipuleras, och de finns i den verkliga världen. Det kan exempelvis vara byggnader, människor eller widgets på en datorskärm.

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

UML använder styrkorna i dessa tre tillvägagångssätt för att presentera en mer konsekvent metodik som är enklare att använda. UML är bästa praxis för att bygga och dokumentera olika aspekter av programvaru- och affärssystemsmodellering.

”The Three Amigos” inom programvaruteknik, som de kallades, hade utvecklat andra metoder. De började samarbeta i syfte att skapa tydlighet för programmerare genom att ta fram nya standarder. Samarbetet mellan Booch, Rumbaugh och Jacobson gjorde alla tre metoderna starkare och förbättrade slutprodukten.

Det resulterade i att dokumenten UML 0.9 och 0.91 presenterades 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, tillsammans med många andra individer och företag, etablerade resurser som kunde utvecklas till ett fullfjädrat modellspråk. ”The Three Amigos” publicerade The Unified Modeling Language User Guide 1999 och en uppdatering som innehåller information om UML 2.0 kom i den andra upplagan 2005.

Enligt webbplatsen är Object Management Group® (OMG®) ett internationellt, icke vinstdrivande konsortium för tekniska standarder med öppet medlemskap som grundades 1989. OMG-standarder tas fram av leverantörer, slutanvändare, akademiska institutioner och statliga myndigheter. OMG Task Forces utvecklar standarder för företagsintegration för ett brett utbud av tekniker och ett ännu bredare utbud av branscher. OMG:s modelleringsstandarder, däribland 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 språk som passar för många ändamål under alla faser av mjukvarans livscykel och för alla systemstorlekar.

OMG definierar syftet med UML som:

• 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.
• Förbättra nuläget i branschen genom att möjliggöra interoperabilitet mellan verktyg för visuell modellering av objekt. För att möjliggöra ett meningsfullt utbyte av modellinformation mellan verktyg krävs dock standardisering av semantik och notation.

UML uppfyller följande krav:

• Uppfyller den formella definitionen av en gemensam MOF-baserad (Meta-Object Facility) meta-modell som anger den abstrakta syntaxen för UML. Den abstrakta syntaxen definierar uppsättningen av UML-modelleringskoncept, deras attribut och relationer, samt reglerna för att kombinera dessa koncept för att konstruera partiella eller kompletta UML-modeller.
• Ger 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.
• Specificerar de mänskligt läsbara delarna i notationen så att de representerar de individuella UML-modelleringskoncepten samt regler för att kombinera dem till en mängd olika diagramtyper som motsvarar olika aspekter av modellerade system.
• Definierar sätt som 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.

UML är populärt bland programmerare, men används vanligtvis inte av databasutvecklare. En anledning är helt enkelt att UML-skaparna inte fokuserade på databaser. Trots detta är UML effektivt för konceptuell datamodellering på hög nivå och kan användas i olika typer av UML-diagram. Mer information om att överlagra en objektorienterad klassmodell på en relationsdatabas finns i den här artikeln om databasmodellering i UML.

UML förfinas ständigt. UML 2.0 utökar UML-specifikationerna för att täcka fler aspekter av programvaruutveckling, inklusive agil utveckling. Målet var att omstrukturera och förfina UML så att användbarhet, implementering och anpassning förenklas. Här är några av uppdateringarna av UML-diagram:

• Större integration mellan strukturmodeller och beteendemodeller.
• Möjlighet att definiera hierarki och dela upp ett programvarusystem i komponenter och underkomponenter.
• I UML 2.0 ökar antalet diagramtyper från 9 till 13.

Bekanta dig med de olika UML-begreppen med denna lista hämtad från UML 2.4.1-dokumentet, avsett att hjälpa icke-medlemmar i OMG att förstå vanliga termer.

• Abstrakt syntax-kompabilitet

  Nu kan användare 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 datalager och affärsinformation mellan verktyg, plattformar och arkiv för datalager i distribuerade, heterogena miljöer

• Konkret syntax-kompabilitet

  Användare kan fortsätta att använda den notation som de är bekanta med, i olika verktyg

• Core

  Inom UML-sammanhang brukar ”core” oftast avse ”Core package” – en fullständig metamodell som är speciellt utformad för att stora delar ska kunna återanvändas

• Språkenhet

  Består av en samling tätt förbundna modelleringskoncept som ger användare möjlighet att representera olika aspekter av det system som studeras i enlighet med en viss paradigm eller form

• Level 0 (L0)

  Lägsta överensstämmelsenivå för UML-infrastruktur – en enda språkenhet som tillhandahåller modellering av de typer av klassbaserade strukturer som påträffas i de flesta populära objektorienterade programmeringsspråk

• Meta Object Facility (MOF)

  En modelleringsspecifikation från OMG som utgör grunden för definitioner av metamodeller i OMG:s familj av MDA-språk

• Metamodell

  Definierar det språk och de processer som används för att bilda en modell

• Metamodellkonstruktioner (LM)

   Den andra efterlevnadsnivån inom UML-infrastrukturen – en extra språkenhet för mer avancerade klassbaserade strukturer som används för att bygga metamodeller (med CMOF) som själva UML. UML har endast två efterlevnadsnivåer

• Modelldriven arkitektur (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 symboler för flödesscheman som är mer exakta än naturligt språk men mindre svåra att bemästra än matematik

• Object Management Group (OMG)

  är ett icke-vinstdrivande konsortium för branschspecifikationer vars medlemmar definierar och underhåller UML-specifikationen

• UML 1

  Första versionen av Unified Modeling Language

• Unified Modeling Language (UML)

  Ett visuellt språk för att specificera, konstruera och dokumentera artefakter i system

• XMI

  En XML-baserad specifikation av format för utbyten mellan modeller

Se det fullständiga MOF-dokumentet

Ladda ner hela infrastrukturdokumentet för UML 2.4.1.

Systemutvecklingen fokuserar på tre övergripande olika systemmodeller:

• Funktionell:

  Dessa är diagram över användarfall som beskriver systemets funktionalitet ur användarens synvinkel.

• Objektorienterad:

  Dessa är klassdiagram som beskriver systemets struktur i termer av objekt, attribut, associationer och operationer.

• Dynamisk:

  Interaktionsdiagram, tillståndsmaskindiagram och aktivitetsdiagram används för att beskriva systemets interna beteende.

Dessa systemmodeller visualiseras genom två olika typer av diagram: strukturella och beteendemässiga.

Objekten i UML motsvarar verkliga objekt som finns omkring oss. I programvaruutveckling kan objekt användas för att beskriva eller modellera det system som skapas, i termer som är relevanta för domänen. Med hjälp av objekt blir det också möjligt att bryta ner komplexa system till greppbara komponenter som gör att olika delar kan byggas var för sig.

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

• Objekt

  Representerar en enhet och är den grundläggande byggstenen.

• Klass

  Ritningen av ett objekt.

• Abstraktion

  Beteende hos en enhet i den verkliga världen.

• Inkapsling

  Mekanismen att binda samman data och dölja dem från omvärlden.

• Arv

  Mekanismen att skapa nya klasser som utgår från befintliga.

• Polymorfism

  Mekanismen att existera i olika former.

UML använder element och associerar dem på olika sätt för att bilda diagram som representerar statiska eller strukturella aspekter av ett system. Det finns även beteendediagram, som beskriver de dynamiska aspekterna av ett system.

Strukturella UML-diagram

• Klassdiagram

  Det vanligaste UML-diagrammet och den viktigaste grunden för alla objektorienterade lösningar. Klasserna i ett system, klassernas attribut och operationer samt förhållandet mellan varje klass. Klasser grupperas tillsammans i klassdiagram när stora system ska beskrivas.

• Komponentdiagram

  Visar
  det strukturella förhållandet mellan systemelement och används oftast när man arbetar med komplexa system med flera komponenter. Komponenter kommunicerar med hjälp av gränssnitt.

• Sammansatta strukturdiagram

  Sammansatta strukturdiagram används för att visa den interna strukturen hos en klass.

• Distributionsdiagram

  Illustrerar systemets maskinvara och programvara. Det är användbart när en programvarulösning distribueras över flera maskiner med olika konfigurationer.

• Objektdiagram

  Visar relationen mellan objekt med hjälp av exempel från verkligheten och illustrerar hur ett system ser ut vid varje given tidpunkt. Eftersom data är tillgängliga inom objekt kan de användas för att klargöra relationer mellan objekt.
• Paketdiagram Det finns två specialtyper av beroenden mellan paket: paketimport och paketsammanslagning. Paket kan representera de olika nivåerna i ett system för att visa arkitekturen. Paketberoenden kan markeras för att visa kommunikationsmekanismen mellan nivåer.

UML-beteendediagram

• Aktivitetsdiagram

  Grafiskt representerade arbetsflöden för företag eller verksamheter som visar aktiviteten hos någon del eller komponent i systemet. Aktivitetsdiagram används som ett alternativ till tillståndsmaskindiagram.

• Kommunikationsdiagram

  Liknar sekvensdiagram, men fokus ligger på meddelanden som skickas mellan objekt. Samma information kan representeras med hjälp av ett sekvensdiagram och olika objekt.
• Interaktionsöversiktsdiagram Det finns sju typer av interaktionsdiagram, och detta diagram visar i vilken ordning de kommer.

• Sekvensdiagram

  Visar hur och i vilken ordning objekt interagerar med varandra. Diagrammen representerar interaktioner för ett visst scenario.

• Tillståndsdiagram

  På liknande sätt som aktivitetsdiagram beskriver dessa hur objekt beter sig på olika sätt i sitt aktuella tillstånd.

• Tidsdiagram

  På samma sätt som sekvensdiagram beskriver de beteendet hos objekt under en given tidsperiod. Om det finns ett enda objekt blir diagrammet enkelt. Med fler än ett objekt visas interaktioner mellan objekt under den specifika tidsramen.

• Användningsfallsdiagram

  Representerar en viss funktionalitet i ett system. Diagrammet skapas för att illustrera hur funktioner relaterar till varandra samt deras interna/externa styrande aktörer.

För att få exempel på hur man skapar olika typer av UML-diagram kan du låta en eller flera av dessa handledningar guida dig genom processen för att rita både struktur- och beteendediagram.

Handledning för exempel på strukturdiagram

KLASSDIAGRAM

Klassdiagram beskriver de statiska strukturerna i ett system, inklusive dess klasser, attribut, operationer och objekt. Ett klassdiagram kan visa beräkningsdata i implementeringsklasser eller organisationsdata som logiska klasser. Det kan finnas överlappning mellan dessa två grupper.

1. Klasser representeras med en rektangulär form som är uppdelad i tre delar. Den översta delen innehåller klassens namn, medan mittdelen innehåller klassens attribut. Den nedersta delen innehåller klassens operationer (som även kallas metoder).
2. Lägg till klassformer i ditt klassdiagram för att modellera förhållandet mellan dessa objekt. Du kan även behöva lägga till underklasser.
3. Använd linjer för att representera association, arv, multiplicitet och andra relationer mellan klasser och underklasser. Den stil på notationen som du föredrar kommer att ange notationen för dessa rader.

 

KOMPONENTDIAGRAM

Komponentdiagram visar hur komponenter kombineras för att bilda större komponenter eller programvarusystem. Dessa diagram är avsedda att modellera beroenden för varje komponent i systemet. En komponent är något som krävs för att utföra en stereotyp funktion. En komponentstereotyp kan bestå av körbara filer, dokument, databastabeller, filer eller biblioteksfiler.

1. Representera en komponent med hjälp av en rektangelform. Den ska ha två små rektanglar på sidan, eller ha en ikon med denna form.
2. Lägg till linjer mellan komponentformer för att representera relevanta relationer.

 

DISTRIBUTIONSDIAGRAM

Ett distributionsdiagram modellerar hur maskinvarukomponenterna fysiskt är distribuerade och strukturerade. Distributionsdiagram visar var och hur komponenterna i ett system kommer att fungera tillsammans med varandra.

1. När du ritar ett distributionsdiagram använder du samma notation som du använder för ett komponentdiagram.
2. Använd en 3D-kub för att modellera en nod (som representerar en fysisk eller virtuell maskin).
3. Namnge noden i samma stil som används för sekvensdiagram. Lägg till andra noder efter behov och förbind dem sedan med linjer.

 

Handledning för exempel på beteendediagram

AKTIVITETSDIAGRAM

Aktivitetsdiagram visar det processuella kontrollflödet mellan klassobjekt, tillsammans med organisatoriska processer som affärsverksamhetens arbetsflöden. Dessa diagram är gjorda av specialiserade former som sedan förbinds med pilar. Uppsättningen av notationer för aktivitetsdiagram liknar den för tillståndsdiagram.

1. Påbörja ditt aktivitetsdiagram med en heldragen cirkel.
2. Anslut cirkeln till den första aktiviteten. Den representeras av en rektangel med rundade hörn.
3. Koppla nu varje aktivitet till andra aktiviteter med linjer som visar det stegvisa flödet i hela processen.
4. Du kan också prova att använda simbanor som representation av de objekt som utför varje aktivitet.

 

ANVÄNDNINGSFALLSDIAGRAM

Ett användningsfall är en lista över steg som definierar interaktionen mellan en aktör (en människa som interagerar med systemet eller ett externt system) och själva systemet. Användningsfallsdiagram specificerar ett användningsfall och modellerar ett systems funktionella enheter. Dessa diagram hjälper utvecklingsteamen att förstå systemkraven, inklusive hur den mänskliga interaktionen i systemet ser ut och skillnaderna mellan olika användningsfall. Ett användningsfallsdiagram kan visa alla tänkbara användningsfall för systemet, eller enbart en grupp användningsfall med liknande funktionalitet.

1. För att påbörja ett användningsfallsdiagram lägger du först till en oval form i mitten av arbetsytan.
2. Skriv namnet på användningsfallet inuti ovalen.
3. Representera aktörer med en streckgubbe i närheten av ovalen och använd sedan linjer för att symbolisera relationer mellan aktörer och användningsfall.

 

SEKVENSDIAGRAM

Sekvensdiagram, som även kallas händelsediagram eller händelsescenarier, illustrerar hur processer interagerar med varandra genom att visa anrop mellan olika objekt i en sekvens. Dessa diagram har två dimensioner: vertikal och horisontell. De vertikala linjerna visar sekvensen av meddelanden och anrop i kronologisk ordning, och de horisontella elementen visar de objektinstanser där meddelandena vidarebefordras.

1. För att skapa ett sekvensdiagram skriver du klassinstansens och klassens namn i en rektangulär ruta.
2. Dra linjer mellan klassinstanser för att representera avsändare och mottagare av meddelanden.
3. Använd fyllda pilspetsar för att symbolisera synkrona meddelanden, öppna pilspetsar för asynkrona meddelanden och streckade linjer för svarsmeddelanden.

Du kan börja skapa UML-diagram nu med Lucidchart. Vi gör det enkelt och effektivt – ja, till och med roligt!

• Enkelt att använda

  Om du ska göra ett UML-diagram så har du helt klart koll på vad du gör, men vi vill se till att det blir så enkelt som möjligt att få jobbet gjort. Du sparar tid med Lucidcharts lättanvända gränssnitt och smarta dra-och-släpp-redigerare.

• Omfattande formbibliotek

  Rita tillståndsdiagram, aktivitetsdiagram, användningsfallsdiagram och mycket mer. I det omfattande biblioteket med former och kopplingar hittar du allt du behöver.

• Helt integrerat

  Lucidchart är helt integrerat med Google Workspace. När du väl kommit igång med Lucidchart kommer du att kunna hitta oss direkt i din produktivitetssvit från Google, tillsammans med Gmail och Google Drive. Du kan dessutom använda samma inloggning som du använder för Google.

• Möjliggör samarbete

  Du kan enkelt dela ditt UML-diagram med kollegor, kunder eller din chef. Dina diagram kan bäddas in på en webbsida eller publiceras som PDF:er, och Lucidcharts presentationsläge förvandlar din skapelse till ett snyggt visuellt hjälpmedel.

• Import/export till Visio

  Det är enkelt att importera och exportera Visio-filer så du kan spara det arbete du redan har gjort. Hela upplevelsen är snabb och sömlös.