UML

UML

1                    Introductie

Unified Modeling Language (UML)3 wordt meestal beschouwd in de context van softwareontwikkeling. UML wordt vaak gebruikt om bijvoorbeeld procesmodellen en gegevensmodellen ten behoeve van applicaties of informatiesystemen op te leveren. Er is echter een trend om UML ook in een bredere context toe te passen, waaronder enterprise-architectuur. Daarom wordt in deze paragraaf ingegaan op zowel de UML-standaard als de toepassing ervan bij enterprise-architectuur.

Geschiedenis

Modellen spelen hebben altijd al een belangrijke rol gespeeld in IT-ontwikkeling. Door het toenemende IT-gebruik en het steeds complexer worden van IT-systemen is het gebruik van modellen alleen maar belangrijker geworden. In eerste instantie heeft dit – ruwweg sinds midden jaren zeventig – geleid tot een wirwar aan modelleeraanpakken. Er werden diverse ‘smaken’ van entity relationship models (ERD), object role modeling (ORM), petri-netten, flowcharts enzovoorts, ontwikkeld. Hoewel al deze aanpakken hun sterke en minder sterke punten hadden, bleek er ook een flinke uitdaging te bestaan op het gebied van communicatie, uitwisseling van modellen et cetera. Dit was de ideale voedingsbodem voor het ontstaan van UML.

Aan de basis van UML staan Grady Booch, James Rumbaugh en Ivar Jacobson, later bekend geworden als de drie amigos. Alle drie hadden ze een eigen methode ontwikkeld: Booch had Booch 95, Rumbaugh had Object Modelling Technique (OMT) en Jacobson had Object Oriented Software Engineering (OOSE). Hun doel was door samenwerking een methode te formuleren die zo breed mogelijk gedragen kon worden. Deze samenwerking is een mooi voorbeeld van de totstandkoming van een open standaard en heeft uiteindelijk geleid tot het ontstaan van RUP en UML

2                    Beschrijving

UML is een verzameling grafische modelleringstechnieken en is geïnspireerd op best practices uit disciplines als datamodellering, procesmodellering, objectmodellering en dergelijke. De kracht van UML ligt in de mogelijkheid van hergebruik van concepten tussen de verschillende diagramtypen. Daarmee ontstaat een consistente beschrijving van een (software-intensief) systeem vanuit verschillende gezichtspunten.

De diagramtypen kunnen we in drie soorten onderverdelen: structuurdiagrammen, gedragsdiagrammen en interactiediagrammen. Deze diagrammen worden hieronder kort beschreven in hun pure vorm.

Structuurdiagrammen

Structuurdiagrammen leggen de nadruk op de elementen die in het systeem aanwezig moeten zijn, alsmede de relaties tussen deze elementen. Er zijn zeven verschillende typen structuurdiagrammen. Het verschil zit vooral in het abstractieniveau en de toepassing van het diagramtype:

• Class diagram: beschrijft het systeem in termen van de typen objecten, attributen en methoden van deze klassentypen alsmede de relaties tussen de
• Object diagram: kan gezien worden als een ‘instantiatie’ van het class diagram, aangezien objecten instanties zijn van klassen. Elk object (instantie) krijgt een waarde voor de attributen van de klasse (type).
• Component diagram: laat zien hoe een systeem gedecomponeerd wordt in steeds kleinere delen ofwel
• Composite Structure Diagram: beschrijft de structuur van een enkele klasse in termen van functies, variabelen et Middels dit diagramtype kan de werking van een enkele klasse beschreven worden.
• Deployment diagram: geeft inzicht in de manier waarop software-artefacten op de infrastructuur, bestaande uit hardware en executieomgevingen, wordt geïnstalleerd.
• Package diagram: laat zien hoe klassen gegroepeerd worden in packages (op het niveau van softwarecode) en wat de afhankelijkheden tussen deze packages
• Profile diagram: is een diagramtype op het metaniveau, en laat zien hoe klassen verbijzonderd worden door het gebruik van stereotypen, en hoe packages worden verbijzonderd middels het gebruik van

Gedragsdiagrammen

Gedragsdiagrammen leggen de nadruk op het gedrag en de functionaliteit van het systeem en beschrijven de dingen die gebeuren in een systeem. Er zijn drie verschillende typen gedragsdiagrammen:

• Activity diagram: beschrijft de activiteiten die in een systeem worden uitgevoerd alsmede de volgorde waarin dat kan Hierbij wordt gebruikgemaakt van concepten als activiteiten, keuzemomenten en het iteratief dan wel parallel uitvoeren van activiteiten.
• State diagram: geeft inzicht in de toestanden en toestandsovergangen van het systeem. Dit diagramtype kan zowel gemaakt worden op het niveau van een individuele klasse, als op het niveau van het systeem als
• Use case diagram: beschrijft de requirements van een systeem in termen van actoren, hun doelen – gerepresenteerd door use cases – en afhankelijkheden daartussen.

Interactiediagrammen

Interactiediagrammen vormen een subset van de gedragsdiagrammen, waarbij de nadruk ligt op controlflow en dataflow in een systeem. We onderscheiden vier soorten interactiediagrammen:

• Sequence diagram: geeft inzicht in de manier waarop objecten berichten uitwisselen, waarbij tevens wordt aangegeven wat de relatieve levensduur is van objecten in relatie tot de uitgewisselde
• Communication diagram: representeert de combinatie tussen modelelementen (klassen, ‘parts’) in de vorm van berichten die in een bepaalde volgorde worden uitgewisseld. Dit diagramtype combineert informatie van het klassendiagram, use case diagram en sequence
• Interaction overview diagram: is vergelijkbaar met het activiteitendiagram, maar op een hoger abstractieniveau. Individuele activiteiten worden in een ‘frame’ gerepresenteerd, waardoor ook de control tussen de verschillende activiteiten kan worden In essentie wordt hier gebruikgemaakt van een nestingmechanisme waarbij het interaction overview diagram de hoofdstructuur aangeeft en activiteitendiagrammen de verdieping representeren.
• Timing diagram: geeft inzicht in beperkingen op gedrag in relatie tot de tijd. Dit diagramtype wordt zelden

3                    UML in een EA-context

Enterprise-architectuurmodellen worden voor verschillende zaken gebruikt, van ontwerp tot (high-level) communicatie met verschillende soorten belanghebbenden. Communicatie met business-stakeholders vereist een ander soort visualisatie dan een abstract ontwerp of een gedetailleerde blauwdruk voor implementatie. Met andere woorden, er zijn verschillende viewpoints nodig, afhankelijk van wat de architect wil communiceren. Enerzijds is dit ingebouwd in de taal middels viewpoints, anderzijds wordt dit ondersteund met toolsupport.

Een viewpoint schrijft voor hoe een view moet worden geconstrueerd in termen van toegestane concepten en relaties. Essentieel voor het gebruik van UML in een EA- context is het hergebruik van concepten tussen verschillende views: in een managementview zal een element zonder al te veel details worden gerepresenteerd, terwijl een constructieview een nadere uitwerking zal laten zien. Toolsupport is hierbij essentieel omdat consistentie tussen views bewaakt en afgedwongen kan worden. Veel tools gaan echter een stap verder en maken het mogelijk om aan de ene kant verschillende visualisaties van modelelementen te maken en aan de andere kant bepaalde aspecten van modelelementen (zoals de attributen van een klasse) weg te laten in een view. Zodoende kunnen complexe diagrammen toch begrijpelijk gerepresenteerd worden.

Een tweede aspect van het gebruik van UML in een EA-context betreft het toevoegen van semantiek aan de taal. Ten opzichte van modellen in de context van softwareontwikkeling valt op dat UML-modellen in een enterprise-context vaak minder details bevatten, maar dat er aan modelelementen wel vaak extra betekenis wordt gegeven. Een voorbeeld hiervan is een class diagram waarbij geen attributen of methoden zijn weergegeven, maar waarbij wel onderscheid wordt gemaakt tussen verschillende typen objecten zoals informatieobjecten, actoren, en systemen. Hierbij wordt gebruikgemaakt van de uitbreidingsmogelijkheden van UML middels profielen en stereotypen. Met moderne tooling is het vaak mogelijk om ook visueel onderscheid te maken tussen de verschillende typen modelelementen. In het genoemde voorbeeld zouden alle informatieobjecten geel gekleurd kunnen worden, terwijl systemen bijvoorbeeld in blauw worden afgebeeld.

4                    Positionering

Figuur 1 brengt het scoringsresultaat van UML in beeld op basis van het vergelijkingsmodel.

Figuur 1: UML gepositioneerd op het vergelijkingsmodel.

Denkwijze

De kracht van UML zit ‘m in de pure focus op een universeel toepasbare modelleertaal. Er is geen voorgeschreven werkwijze. Ongeacht de aanpak kan UML gebruikt worden om visualisaties te maken afgestemd op de wensen van de modelleur en de stakeholders van modellen.

Beheer- en exploitatiewijze eigenaar

De eigenaar van de UML-standaard is de Object Management Group (OMG), waarin de meeste grote softwarehuizen zijn vertegenwoordigd. De consequentie hiervan is dat verschillende partijen uit de praktijk hun invloed uit kunnen oefenen op de ontwikkeling van de taal.

UML kan beschouwd worden als de facto standaard voor modellering in de software-industrie. UML is inmiddels aangekomen bij versie 2.4.1 en wordt wereldwijd gebruikt. Er is een actieve community die door leveranciers volop wordt bediend met tools (commerciële en communityversies) en een breed scala aan opleidingen.

Beheer- en exploitatiewijze gebruiker

Er bestaat geen voorgeschreven beheer- en exploitatiewijze voor de gebruikers van UML.

Werkwijze

UML is bovenal een modelleertaal, ofwel een verzameling diagramtechnieken. In die zin is er geen sprake van een voorgeschreven werkwijze. In de wereld van de software- engineering wordt UML vaak gebruikt in combinatie met RUP, vergelijkbaar met de

combinatie van ArchiMate en TOGAF die veel wordt toegepast. Ook in de context van enterprise-architectuur is er niet één voorschreven werkwijze die gevolgd wordt.

Representatie en modelleerwijze

UML kent verschillende diagramtypen. In paragraaf 5.10.2 zijn deze beschreven. Elk diagramtype heeft een standaardnotatie die aangepast kan worden al naar gelang de specifieke wensen van de gebruiker.

Ondersteuningswijze

UML is een open standaard in de zin dat de volledige specificatie online beschikbaar is en leden van de OMG dragen bij aan de ontwikkeling van deze standaard. Er zijn diverse tools in omloop die (delen van) UML implementeren. Er is een grote inspanning gedaan om de modellen in al die hulpmiddelen onderling uitwisselbaar te maken. Zo kan een UML-model via XMI in een ander hulpmiddel worden ingeladen en kunnen diagrammen naar elkaar worden omgezet en geëxporteerd naar diverse andere talen, zoals XML en ArchiMate.

Bruikbaarheid

UML is bruikbaar in een brede context. De taal wordt in Nederland erg veel toegepast en onderwezen (zowel binnen vakopleidingen als academische opleidingen).

5                    Conclusies

Eén van de belangrijkste drijfveren achter UML is de ontwikkeling van een modelleertaal die universeel toepasbaar is. Uit de positionering (figuur 1) valt af te lezen dat het inderdaad gaat om een taal, het aspect ‘werkwijze’ krijgt een nulscore. Hoewel in eerste instantie ontwikkeld in de context van softwareontwikkeling, blijkt UML ook uitermate bruikbaar als architectuurmodelleertaal in een enterprise-context.

Het feit dat de taal wereldwijd wordt gebruikt is één van de meest aansprekende punten van UML. Het vergroot de communiceerbaarheid en uitwisselbaarheid van modellen tussen professionals. De veelheid aan beschikbare diagramtypen en de mogelijkheden om de taal aan te passen middels profielen en stereotypen dragen bij aan de flexibiliteit van de taal. Wel moeten we opmerken dat door de uitbreidingen van de taal het voor buitenstaanders lastiger wordt om de diagrammen correct te interpreteren.

Tot slot moet er een kritische noot geplaatst worden bij het detailniveau van de UML- diagramtypen. Hoewel professionals (vooral in de community van de software-engineering) gewend zijn aan formele diagrammen met veel detail, zijn veel business- stakeholders dat juist niet. Juist hiervoor kan tooling belangrijke ondersteuning bieden om een model effectief te communiceren met de doelgroep.