Unified Modeling Language (UML) er en standard for udseende af diagrammer til beskrivelse af strukturer og forløb i objekt-orienterede softwaresystemer, udviklet af Object Management Group (OMG). UML har grafiske notationer for de fleste begreber og mulige sammenhænge mellem begreber indenfor objekt-orienteret softwareudvikling. Til det formål er UML blevet en de facto standard.

Det er ikke kun en standard for udseende af diagrammer men også for dataformatet som værktøjer, til at lave UML diagrammer, kan bruge til at gemme og udveksle UML diagrammer mellem forskellige leverandørers værktøjer. Dataformatet hedder XMI og er et XML-dokument.

Fædrene til UML (særligt Grady Booch, Ivar Jacobson og James Rumbaugh, også kendt som "the three Amigos"), som i 1990-erne var kendte fortalere for objekt-orienteret programmering, havde allerede udviklet deres egne (mere eller mindre ens) systemer. Mens de arbejdede sammen i Rational software begyndte de at forene deres forskellige systemer.

Den 19 november 1997 blev UML accepteret af OMG som en standard og er siden blevet videreudviklet af OMG.

I juni 2003 blev udkast til ny version af UML, Unified Modeling Language 2.0 eller UML2, offentligtgjort af OMG. Den blev færdig i marts 2005.

Diagramtyperne i UML kan deles op i to grupper: strukturdiagrammer og adfærdsdiagrammer.

Strukturdiagrammerne beskriver, som navnet siger, strukturen i et system. Til gengæld viser de ikke noget om systemets adfærd.

Den mest kendte UML-diagramtype er klassediagrammet, som definerer en måde at beskrive alle eller udvalgte dele af et objektorienteret systems klasser. Diagrammet viser strukturen mellem de udvalgte klasser, f.eks.

• Arv: Hvis en klasse er subklasse af en anden klasse eller implementerer et interface (grænseflade-klasse).
• Associering: Hvis der er en sammenhæng mellem to klasser, så en klasse har en anden klasse som medlemsvariabel (kan også være gensidigt). Ved associeringer angives også kardinaliteten, dvs. hvor mange objekter af en given klasse, den anden har en sammenhæng til.
• Aggregering: Er egentlig et specialtilfælde af en associering, der viser et "består af"-forhold. Viser, at et objekt eksisterer på grund af et andet objekt. Hvis det overordnede objekt slettes, slettes de underordnede objekter også. Ved "almindelige" associeringer kan sammenhængen til et andet objekt derimod skiftes ud.
• Afhængighed: Andre tilfælde, hvor en klasse er afhængig af kendskabet til en anden klasse, i praksis ved at den anden klasse optræder som parameter i en metode eller en lokal variabel.

I et klassediagram vises klassens navn, dens medlemsvariable (hvis de ikke fremgår af en associering) og medlemsmetoder eller et udvalg af dem.

I forbindelse med objektorienteret analyse og design bruges UML både i analyse- og designfasen. I analysefasen har et klassediagram stort set samme rolle, som et ER-diagram (eng: Entity-Relationship Diagram) har i forbindelse med databasemodellering, et spørgsmål om at modellere den del af omverdenen, som systemet skal afspejle. Heri kortlægges, hvilke klasser omverdenen giver anledning til samt deres medlemsvariable. Medlemsmetoderne fremkommer, efterhånden som systemets adfærd afdækkes i analyse- og designfasen.

Klassediagrammer bruges ofte som designdokumenter, systemdokumentation, der kan bruges til at skabe et hurtigt overblik over sammenhængen i et system. I praksis vil man opleve, at et 'designet' UML sjældent stemmer overens med et endeligt UML, beskrivende det færdige system. Der findes i dag en række programmer, der automatisk kan generere UML-klassediagrammer ud fra eksisterende kode.

I designfasen og under kodningen laver man som regel en opdeling af systemets klasser i pakker (eng. packages) bestående af klasser med stort samspil imellem og fællesskab om at udføre bestemte slags opgaver. I et pakkediagram viser man disse pakker som "mapper" evt. med pakkernes indhold af klasser, og med stiplede pile mellem pakkerne viser man afhængigheden mellem pakkerne. Afhængigheden er her et udtryk for, at klasser i én mappe er afhængig af kendskabet til klassernes grænseflade i en anden mappe. Ofte vælger man netop i designet at definere interfacer (grænseflade-klasser) i en pakke for at vise, hvad pakken tilbyder udadtil for andre pakker, og en sådan grænseflade illustreres ved boller, der stritter ud af pakken som et håndtag.

I disse diagramtyper vises systemets adfærd, dvs. en beskrivelse af, hvordan systemets omverden og objekterne i systemet arbejder sammen. Diagrammerne vil til en vis grad have et tidsmæssigt perspektiv.

Et brugsmønsterdiagram viser, hvordan systemets omverden interagerer med systemet. Systemets omverden består af aktører (roller i form af brugere eller andre systemer) illustreret i diagrammet ved "tændstikmænd", og de interagerer med systemet gennem brugsmønstre (eng. use case), illustreret ved ovaler. Et brugsmønster er en samlet mængde handlinger mellem én eller flere aktører og systemet, der tilsammen beskriver én afsluttet måde at bruge systemet på. Pile mellem aktørerne og brugsmønstrene viser, hvem der deltager i et brugsmønster, og hvorfra initiavet kommer, dvs. om aktøren starter et brugsmønster eller systemet gør. Desuden kan der vises specielle strukturer mellem brugsmønstrene, f.eks. arv (hvis et brugsmønster har flere specialiseringer) eller inkluderinger (hvis man vil beskrive et brugsmønster som en opdeling i to eller flere brugsmønstre, der hver især er afsluttede).

Brugsmønsterdiagrammer anvendes først og fremmest under analysen, hvor man afdækker de enkelte brugsmønstre. Diagrammet følges op med en sproglig beskrivelse af de enkelte brugsmønstre med de hændelser (trin), der indgår i brugsmønsteret. Under designet forsøger man så at implementere de enkelte brugsmønstre.

I et tilstandsdiagram vises, hvilke tilstande systemet optræder i, efterhånden som et brugsmønster gennemføres, og det er derfor en uddybning af brugsmønstrene. Tilstandene vises som afrundede firkanter, og hændelserne, der får systemet til at gå fra én tilstand til en anden, vises med pile mellem tilstandene. Desuden er der særlige symboler for starten og afslutningen af et brugsmønster.

Tilstandsdiagrammer er en vigtig del af analysen, og formålet er at sikre, at alle tilstande på en eller anden måde bliver implementeret i systemet under designet. Implementeringen kan være i form af medlemsvariable hos én eller flere klasser, men et avanceret design kan dog også afbilde en tilstand ved et særligt "tilstandsobjekt", der har en adfærd, så den selv styrer systemet over i en anden tilstand. Objektet vil dog stadig optræde som en medlemsvariabel i en eller anden klasse.

I disse diagramtyper viser man, hvordan de enkelte aktører og systemets objekter arbejder sammen om at gennemføre et brugsmønster, dvs. hvilke metoder der anvendes i de enkelte objekter, og hvordan de kalder metoder i andre objekter. Diagramtyperne kan anvendes under analysen, men er især anvendelig under designet, når man skal afgøre, hvilke metoder, de enkelte klasser har behov for, samt hvilke parametrene, der skal med i et metodekald. I et UML-udviklingsprogram er disse diagramtyper ofte kædet sammen med klassediagrammerne, så en metode, der anvendes her, automatisk kommer med som medlemsmetode på en klasse.

Der er flere former for interaktionsdiagrammer, hvor der her nævnes to. I et (interaktions-)overbliksdiagram (eng. interaction overview diagram) er objekterne fordelt ud over diagrammet med forbindelser imellem, ad hvilke metodekaldene foregår. Kaldene er vist som pile langs forbindelserne, og de er nummererede hierarkisk for at vise deres tidsmæssige rækkefølge og eventuelle selektioner og iterationer. Hvis man vil have større overblik over tidsperspektivet i et brugsmønster, kan man bruge et sekvensdiagram, hvor tiden placeres som den lodrette akse i diagrammet, og objekterne står som overskrifter med hvert deres lodrette livsforløb. Metodekaldene illustreres med vandrette pile mellem objekternes livsforløb. Om man vælger at anvende den ene eller anden form for diagram, afhænger af brugsmønsterets kompleksitet og en vurdering af, hvilken diagramtype der giver det største overblik. De viser i princippet det samme.

Wikimedia Commons har medier relateret til: UML

• Specifikation