Vad är Unified Modeling Language?

Varför använda ett UML-diagram?

Jag vill veta mer om användningsfallsdiagram eftersom de är nya för mig.

Jag vill skapa mitt eget användningsfallsdiagram i Lucidchart.

Jag vill skapa ett användningsfallsdiagram med en Lucidchart-mall.


En bild säger mer än tusen ord. Det var anledningen till att Unified Modeling Language (UML) skapades: för att bilda ett gemensamt visuellt språk i den komplexa världen av programvaruutveckling som också skulle vara begripligt för icke-tekniska användare och alla andra som vill förstå ett system. Lär dig grunderna i UML-diagram, till exempel deras ursprung, hur de används, koncept, typer och riktlinjer för hur du ritar dem med vårt verktyg för UML-diagram.

16 minutläsning

Vill du göra ditt eget UML-diagram? Prova Lucidchart. Det är snabbt, enkelt och helt gratis.

Skapa ett UML-diagram

Vad är UML?

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.

UML och objektorienterad modellering 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.

Historien och ursprunget till UML

”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.

OMG: det betyder något mer

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.

Syftet med UML enligt OMG

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 och datamodellering

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.

Vill du göra ditt eget UML-diagram? Prova Lucidchart. Det är snabbt, enkelt och helt gratis.

Skapa ett UML-diagram

Uppdateringar i UML 2.0

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.

Ordlista över UML-termer

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.

Modelleringskoncept specificerade av UML

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.

Objektorienterade koncept i UML

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.

Typer av UML-diagram

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.

Hur man skapar ett UML-diagram: handledningar och exempel

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.

 

Exempel på UML-komponentdiagram

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.

 

Exempel på UML-distributionsdiagram

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.

 

Exempel på UML-aktivitetsdiagram

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.

 

Exempel på UML-användningsfallsdiagram

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.
Exempel på UML-sekvensdiagram

Med Lucidchart blir det enkelt att rita UML-diagram

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.

Fler resurser

Vill du göra ditt eget UML-diagram? Prova Lucidchart. Det är snabbt, enkelt och helt gratis.

Komma igång

  • Priser
  • Individ
  • Team
  • Större företag
  • Kontakta säljare
SekretessRättsligSekretessval för cookiesCookiepolicy
  • linkedin
  • twitter
  • instagram
  • facebook
  • youtube
  • glassdoor
  • tiktok

© 2024 Lucid Software Inc.