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.

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.

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 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, die men tussen accolades zet, bijvoorbeeld {leeftijd >= 18}.

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

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

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

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.

Het gebruiksdiagram toont het gebruik van de hardwarecomponenten binnen een systeemconfiguratie.

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

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

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

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), ...

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

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

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

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.

• Business Process Modeling
• Rational Unified Process
• UMLet

• Website van Unified Modeling Language

Zie de categorie UML van Wikimedia Commons voor mediabestanden over dit onderwerp.