Unified Modeling Language

De Unified Modeling Language, afgekort UML, is een modelmatige taal om objectgeoriënteerde analyses en ontwerpen voor een informatiesysteem te kunnen maken. UML is ontworpen door Grady Booch, James Rumbaugh en Ivar Jacobson in de jaren negentig en het is sinds 1997 een standaard. Kenmerkend is dat de UML-modellen een grafische weergave zijn van bepaalde aspecten van het informatiesysteem.

Algemeen 
UML is een modelleertaal die breed gedragen wordt, wat te zien is aan het feit dat in de jaren negentig van de twintigste eeuw er een UML-consortium werd opgericht met als deelnemers onder andere de volgende bekende organisaties: Rational, DEC, IBM, ObjectTime, Oracle, HP en Texas Instruments. Dit consortium heeft de UML opgesteld die binnen de Object Management Group (OMG) als standaard aangenomen is.

Met UML kunnen niet alleen beschrijvingen worden gemaakt van statische verschijnselen, maar ook van dynamische processen. UML is een veelzijdig instrument dat in verschillende fasen van de systeembouw kan worden toegepast. Een van de krachtige aspecten van UML is dat er op relatief eenvoudige wijze meta-beschrijvingen kunnen worden gemaakt.

In tegenstelling tot wat vaak wordt gedacht, is UML zelf geen methode, maar een notatiewijze die bij verschillende methodes kan worden gebruikt. Een methode die gebruikmaakt van UML is RUP (Rational Unified Proces).

Object Constraint Language (OCL) is een declaratieve taal waarmee in UML diverse regels, condities en beperkingen kunnen worden aangegeven.
Er bestaan allerlei programma's om UML-diagrammen te modelleren. Voorbeelden hiervan zijn Rational Software, Microsoft Visio, Visual Paradigm, Software Ideas Modeler, StarUML, CannonSketch en TaskSketch.

Geschiedenis 
De auteurs van de UML Grady Booch, James Rumbaugh en Ivar Jacobson worden ook wel de three amigo's genoemd. Ze hadden elk hun taal maar hebben deze gestandaardiseerd in UML. Booch had Booch 95, Rumbaugh had Object Modelling Technique (OMT) en Jacobson had Object Oriented Software Engineering (OOSE).

Sinds 1997 bestaat er een standaard voor UML. Kenmerkend is dat de UML-modellen een grafische weergave zijn van bepaalde aspecten van het informatiesysteem. Er zijn verschillende versies UML. De eerste versie was 1.0. Vervolgens waren er verschillende subversies. 1.1, 1.2 tot 1.5 . Vervolgens kwam versie 2.0. Versie 2.5.1 is formeel uitgebracht op 5 december 2017.

UML-diagrammen 
UML biedt een verzameling van structuur- en gedragsdiagrammen, die zoals hier ook wel statische en dynamische diagrammen genoemd worden:

Alle diagrammen kunnen nota's bevatten. Nota's worden voorgesteld door een rechthoek met een ezelsoortje aan de rechterkant. Alle elementen kunnen een stereotype (speciale betekenis) hebben, bijvoorbeeld <<include>>.
Er kunnen tags gebruikt worden. Tags zijn elementen met een speciale waarde, bijvoorbeeld {auteur="Den Ikke"}.
Een element kan een beperking hebben, welke men tussen accolades zet, bijvoorbeeld {leeftijd >= 18}.

Statische diagrammen

Klassendiagram (class diagram) 

Een klasse bestaat uit 3 delen:
 het bovenste deel bevat de naam van de klasse
De naam van de klasse is erg belangrijk omdat het zal bepalen over welk object men het hier heeft.
De naam is uniek in het diagram.
De naam is altijd in enkelvoud
Bijv: Persoon, Voertuig, Factuur, ...

 het middelste deel bevat de attributen
Deze attributen zijn meestal private attributen en kunnen enkel worden aangeroepen en aangepast door de methoden van deze klasse. Dit is wat men inkapseling noemt of met andere woorden het afschermen van gegevens.
schrijfwijze: zichtbaarheid naam: type = startwaarde
(private aangeraden voor attributen)
zichtbaarheden
+: publiek
-: privaat
#: protected
Bijvoorbeeld naam, leeftijd, omschrijving
vb. + naam: String = "een naam"

 het onderste deel bevat de methoden
Methoden zijn functies of handelingen die men kan uitvoeren op deze objecten.
Deze kunnen bewerkingen uitvoeren op de attributen en zo de nodige gegevens ophalen of wijzigen.
schrijfwijze: zichtbaarheid naam(parameter:type): teruggeeftype
(zo veel mogelijk protected aangeraden)
Bijvoorbeeld LeesNaam()
WijzigNaam("Nieuwe naam")
+ maakTekst(naam:String):String

 optioneel kan een vak met de uitzonderingen (exceptions) worden toegevoegd
 Wat kan men zien:
 klassen
 attributen
 methoden
 associatie (object) tussen klassen
 aggregatie van klassen
 compositie van klassen
 afhankelijkheden (dependencies) van klassen

Het verschil tussen associaties, aggregaties en composities 

 Associaties geven aan welke objecten kunnen 'praten' met elkaar. Een associatie verbindt 2 klassen. Elk van beide uiteinden van de associatie heeft een multipliciteit: n objecten (aan het ene uiteinde) verbonden met 1 object (aan het andere uiteinde). Associaties zijn:
 uni-directioneel: slechts 1 klasse kan berichten sturen naar de andere klassen;
 bi-directioneel: beide klassen kunnen heen-en-weer berichten sturen naar elkaar.
 Een aggregatie is een speciaal type associatie tussen 2 ongelijkwaardige klassen. Ze vormen een “geheel-deel” relatie. Een aggregatie beschrijft hoe 1 “geheel-klasse” wordt samengesteld uit 1 “deel-klasse” of meer dan 1 “deel-klassen”. Een aggregatie heeft altijd 1 “geheel-klasse” met multipliciteit = 1. Een aggregatie kan n objecten van 1 “deel-klasse” hebben of meer dan 1 “deel-klassen” met verschillende multipliciteiten.
 Een compositie is een zeer sterke aggregatie. Het is ook een “geheel-deel” relatie, maar de “deel-klassen” kunnen niet bestaan zonder de “geheel-klasse”. Als de "geheel-klasse" verdwijnt, dan verdwijnen de "deel-klassen" ook.

Een voorbeeld: bekijk de figuur hiernaast. Stel dat we 4 klassen hebben: Schip, Vloot, Motor en Land. Een Vloot heeft enkel maar zin om te bestaan wanneer er Schepen in zitten. Een Vloot heeft daarom een aggregatie met Schip. Wanneer een Vloot opgeheven wordt hoeft dit immers niet te betekenen dat de Schepen mee moeten verdwijnen. Een vloot heeft verder een bi-directionele associatie met Land. Elk Land kan meer dan 1 Vloot hebben, een Vloot behoort slechts tot één land. Vandaar de respectievelijke multipliciteiten * en 1. Een Schip heeft een Motor. Hier wordt een compositie gebruikt. Dit betekent dat er geen Motor kan bestaan, zonder dat deze in context van een Schip moet bekeken worden. Wanneer het Schip weg is, is de bijbehorende Motor dat ook.

Objectendiagram (object diagram) 
Het objectdiagram geeft de objecten binnen een applicatie of systeem in een soort verzameling weer. Objecten zijn instanties van klassen. In een object hebben de attributen een bepaalde waarde op een bepaald tijdstip. Een object heeft een unieke identiteit. De naam van een object wordt onderlijnd.
 wat kan men zien:
 objecten
 attributen met hun waarde op bepaald ogenblik
 link tussen objecten

Componentendiagram (component diagram) 
Het componentendiagram laat de verdeling van het systeem in componenten zien alsook en vooral hun onderlinge relaties of samenwerking. Elke component vormt één of meerdere klassen.

Gebruiksdiagram (deployment diagram) 
Het gebruiksdiagram toont het gebruik van de hardwarecomponenten binnen een systeemconfiguratie.

Dynamische diagrammen

Usecasediagram 
Het usecasediagram toont de actoren en de gebruikersfunctie van het systeem. Een algemeen usecasediagram is een tekening. Een gedetailleerde usecase is een tekst die een vaste structuur heeft. Het is een dynamisch diagram.

 Wat kan je zien op het diagram:
 systeemgrens,
 systeemnaam (optioneel)
 actoren (externe systemen of gebruikers),
 usecase
 associatie (object) tussen actor en usecase
 dependecies tussen usecases
 generalisatie van actoren
 generalisatie van usecases

Werkwijze
 bepaal naam systeem
 bepaal actoren
 welke behoeften hebben actoren (usecase)
 schrijf de usecase uit in een gedetailleerde usecase
 leg de associatie tussen de actoren en usecases vast
 bepaal de onderlinge relatie tussen usecases (stereotype <<include>> en <<extend>>)
 controle
 elke actor moet minstens 1 usecase-associatie hebben
 elke usecase moet minstens 1 actor-associatie hebben

Collaboratiediagram (collaboration diagram/ communicatiediagram) 
Het toepassingsdiagram toont hoe het systeem gebruikt gaat worden, welke handelingen ermee moeten worden verricht. Er wordt getoond welke verantwoordelijkheden (berichten/ methoden) worden verstuurd over de associatie.
 wat kan men zien op het diagram:
 klassen
 berichten (methoden)
 associatie (object)s
 actoren

Volgordediagram/sequentiediagram (sequence diagram) 

Het volgordediagram geeft de interacties weer tussen verschillende objecten die een bepaalde functionaliteit (of een deel ervan) implementeren. De tijdsvolgorde staat centraal in het volgordediagram. Ook wel bekend als een sequentiediagram.
Wat kan men zien op het diagram:
 objecten
 actoren
 levenslijn (lifeline)
 activeringsblok (execution bar)
 berichten
 creatie en verwijderen (creation en destroy)
 fragment (UML 2.0) (fragments) vb. loop (lus) , alt (alternatieven), opt (optioneel), par (parallel), ...

Activiteitendiagram (activity diagram) 
Het activiteitendiagram laat de toestanden van het systeem zien gedurende het gebruik ervan en hoe de verschillende toestanden in elkaar overlopen.
 Wat kan je zien op het diagram:
 start en eind activiteit
 activiteit
 transitie
 zwembaan (swimlane): baan waarvoor een bepaalde actor verantwoordelijk is
 keuzeknoop (decision node) en samenvoegknoop (merge node)
 vork (fork) en samenkomst (join) voor parallelle verwerking

Werkwijze
 bepaal welke gedetailleerde usecase je wil uitwerken
 teken de actoren en het systeem van de usecase bovenaan en teken verticale stippellijnen tussen deze (zwembanen)
 teken per interactie tussen de actoren en systeem de activiteit in zwembaan van wie de activiteit doet
 plaats keuzeknopen, fork en joins
 teken de pijlen tussen alle elementen (transities)

Correlatiediagram 
Het correlatiediagram stelt de samenwerking centraal tussen objecten en hun gestructureerde organisatie.

Toestanddiagram (state diagram) 
Het toestand- of statechartdiagram laat de toestand zien waarin een object zich kan bevinden tijdens zijn bestaan in het systeem.
Ook de overgangen naar toestanden, de events en activiteiten die veranderingen teweegbrengen in de toestanden komen worden weergegeven.

Zie ook 
 Business Process Modeling
 Rational Unified Process
 UMLet

Externe link 
 Website van Unified Modeling Language

Modelvorming
Diagram
Software engineering