UML-diagram tutorial

UML-begrippenlijst

Maak jezelf vertrouwd met het UML-vocabulaire met deze lijst, overgenomen uit het UML 2.4.1-document, bedoeld om niet-OMG-leden te helpen veelgebruikte termen te begrijpen.

• Abstracte syntaxis-conformiteit: Gebruikers kunnen modellen tussen verschillende tools verplaatsen, zelfs als ze verschillende notaties gebruiken.

• Common Warehouse Metamodel (CWM): Standaardinterfaces die worden gebruikt om de uitwischling van warehouse- en business intelligence-metadata mogelijk te maken tussen warehouse-tools, warehouse-platforms en metadata-opslagplaatsen voor warehouses in distributed heterogeneous environments.

• Concrete syntaxis-conformiteit: Gebruikers kunnen een notatie waarmee ze vertrouwd zijn, blijven gebruiken in verschillende tools.

• Kern: In de context van UML verwijst de kern meestal naar het "kernpakket", een compleet metamodel dat speciaal is ontworpen voor een hoge herbruikbaarheid.

• Taaleenheid: Bestaat uit een verzameling nauw gekoppelde modelleerconcepten die gebruikers de mogelijkheid bieden om aspecten van het onderzochte systeem te vertegenwoordigen volgens een bepaald paradigma of formalisme.

• Niveau 0 (L0): Het laagste conformiteitsniveau voor de UML-infrastructuur, een enkele taaleenheid die voorziet in het modelleren van het soort op klassen gebaseerde structuren dat in de meeste populaire objectgeoriënteerde programmeertalen voorkomt.

• Meta Object Facility (MOF): Een OMG-modelleerspecificatie die de basis vormt voor metamodeldefinities in de OMG-familie van MDA-talen.

• Metamodel: Definieert de taal en processen waaruit een model gevormd moet worden.

• Metamodel Constructs (LM): Het tweede conformiteitsniveau in de UML-infrastructuur, een extra taaleenheid voor geavanceerdere op klassen gebaseerde structuren die worden gebruikt voor het bouwen van metamodels (met behulp van CMOF), zoals UML zelf. UML heeft slechts twee conformiteitsniveaus.

• Model Driven Architecture (MDA): Een benadering en een plan om een samenhangende reeks modelgedreven technologiespecificaties te bereiken.

• Object Constraint Language (OCL): Een declaratieve taal voor het beschrijven van regels die van toepassing zijn op de Unified Modeling Language. OCL vult UML aan door termen en stroomdiagramsymbolen te bieden die nauwkeuriger zijn dan natuurlijke taal, maar minder moeilijk te beheersen dan wiskunde.

• Object Management Group (OMG): Een non-profit consortium voor specificaties in de computerindustrie wiens leden de UML-specificatie definiëren en onderhouden.

• UML 1: De eerste versie van de Unified Modeling Language.

• Unified Modeling Language (UML): Een visuele taal voor het specificeren, construeren en documenteren van de artefacten van systemen.

• XMI: Een op XML gebaseerde specificatie van bijbehorende modeluitwisselingsformaten.

Modelleerconcepten gespecificeerd door UML

Systeemontwikkeling richt zich over het algemeen op drie verschillende systeemmodellen:

• Functioneel: Dit zijn use-case diagrammen, die de systeemfunctionaliteit beschrijven vanuit het oogpunt van de gebruiker.
• Object: Dit zijn klassendiagrammen, die de structuur van het systeem beschrijven in termen van objecten, attributen, associaties en bewerkingen.
• Dynamisch: Interactiediagrammen, toestandsmachinediagrammen en activiteitendiagrammen worden gebruikt om het interne gedrag van het systeem te beschrijven.

Deze systeemmodellen worden gevisualiseerd via twee verschillende soorten diagrammen: structureel en gedragsmatig.

Objectgeoriënteerde concepten in UML

De objecten in UML zijn entiteiten uit de echte wereld die om ons heen bestaan. In softwareontwikkeling kunnen objecten worden gebruikt om het systeem dat wordt gemaakt te beschrijven of te modelleren in termen die relevant zijn voor het domein. Objecten maken het ook mogelijk om complexe systemen op te splitsen in begrijpelijke componenten, zodat er één stuk tegelijk gebouwd kan worden.

Hier zijn enkele fundamentele concepten van een objectgeoriënteerde wereld:

• Objecten: Vertegenwoordigen een entiteit en de basisbouwsteen.
• Klasse: Blauwdruk van een object.
• Abstractie: Gedrag van een entiteit uit de echte wereld.
• Inkapseling: Mechanisme om gegevens samen te binden en te verbergen voor de buitenwereld.
• Overerving: Mechanisme om nieuwe klassen te maken op basis van een bestaande klasse.
• Polymorfisme: Definieert het mechanisme om in verschillende vormen te bestaan.

Binnen moderne teams — vooral teams die Agile werken — zijn deze objectgeoriënteerde concepten vaak het gemakkelijkst te communiceren wanneer diagrammen worden behandeld als "kerndocumentatie" en samen met de code worden bijgewerkt, in plaats van eenmalig te worden gemaakt van vervolgens te verouderen.

Waarom teams nog steeds UML-diagrammen gebruiken (vooral in Agile)

Als je een formele code-opleiding hebt gevolgd, ben je waarschijnlijk op school geïntroduceerd in UML-diagrammen. Maar hoeveel heb je ze daarna nog gebruikt? Omdat het maken van UML-diagrammen wat tijd kost en ze in een Agile-omgeving vrij snel verouderen, zijn veel softwareontwikkelaars ze vergeten.

Die zorg is terecht: diagrammen die niet meegroeien met een project verliezen snel hun waarde. Maar als ze actueel worden gehouden, kan UML de ontwikkeling versnellen en de communicatie duidelijker maken. Hoewel veel engineers een hekel hebben aan diagrammen, zijn ze juist nuttig in een Agile-ontwikkelomgeving. Ze houden de ontwikkeling productief en gefocust. In plaats van ze te zien als een leuke extra, zou je UML-diagrammen moeten behandelen als een essentieel onderdeel van je documentatie.

UML-diagrammen kunnen engineeringteams helpen om:

• Nieuwe teamleden of ontwikkelaars die van team wisselen snel in te werken.

• Door de broncode te navigeren.

• Nieuwe functies te plannen voordat er wordt geprogrammeerd.

• Gemakkelijker te communiceren met zowel een technisch als niet-technisch publiek.

Diagrammen die niet meegroeien met een project zijn echter nutteloos. Daarom is het noodzakelijk om constant evoluerende diagrammen te hebben. Een manier waarop teams de onderhoudslast verminderen, is door diagrammen te genereren op basis van lichtere inputs (bijvoorbeeld definities op basis van tekst), zodat de documentatie flexibel blijft als het systeem verandert. Lucidchart kan UML-volgordediagrammen genereren op basis van tekstmarkeringen, wat het maken van diagrammen automatisch en flexibel maakt.

Hoe maak je een UML-diagram

UML-diagrammen volgen een specifieke set regels en vormen, en je zou veel tijd kunnen besteden aan het leren bouwen van elk type. Gelukkig hebben we het je gemakkelijk gemaakt met eenvoudige handleidingen, te beginnen met klassendiagrammen, die je stap voor stap door het proces leiden.

Ongeacht de tooling is de praktische workflow consistent: kies het diagramtype dat past bij je vraag (structuur vs. gedrag), modelleer alleen wat je nodig hebt voor het huidige publiek en herzie het diagram zodra de code en vereisten veranderen. Of je nu de statische architectuur van een nieuw softwaresysteem in kaart brengt of dynamische gebruikersinteracties visualiseert, volg deze stappen om een effectief model te bouwen:

1. Bepaal je doel

Bepaal precies wat je moet visualiseren. Vraag jezelf af of je de statische structuur van een systeem in kaart moet brengen (structureel) of wilt laten zien hoe componenten in de loop van de tijd communiceren en veranderen (gedragsmatig).

2. Kies het juiste diagramtype

Selecteer het juiste UML-diagram op basis van je systeemvereisten. Gebruik bijvoorbeeld een klassendiagram voor een objectgeoriënteerde systeemstructuur, een volgordediagram voor interacties in chronologische volgorde, of een use-case diagram om de functionaliteit voor gebruikers te illustreren. (Tip: beginnen met een van de vooraf gemaakte UML-sjablonen van Lucidchart is de snelste manier om aan de slag te gaan.)

3. Schakel UML-vormenbibliotheken in

Omdat UML een strikt visueel vocabulaire gebruikt, heb je de juiste symbolen nodig. Klik in Lucidchart op "Meer vormen" onderaan het linkermenu, zoek naar "UML" en vink de vakjes aan voor de specifieke vormenbibliotheken die je nodig hebt (bijv. UML-klasse, UML-status, UML-volgorde).

4. Voeg je vormen toe en definieer ze

Sleep entiteiten, objecten, knooppunten of actoren naar je canvas en zet ze daar neer. Rangschik ze logisch en dubbelklik in de vormen om aangepaste tekst, specifieke attributen en bewerkingen aan je objecten toe te voegen.

5. Verbind je componenten

Leg relaties tussen je entiteiten door lijnen tussen hen te trekken. Pas de eindpunten van de lijnen aan (pijlen, ruiten, enz.) om specifieke UML-relaties nauwkeurig weer te geven, zoals overerving, compositie, afhankelijkheden of basisassociaties.

6. Beoordeel en werk samen

UML is ontworpen om te dienen als een gedeelde taal tussen ontwikkelaars, engineers en zakelijke stakeholders. Zodra je diagram is geschetst, gebruik je de real-time samenwerkingsfuncties van Lucidchart om je team uit te nodigen de architectuur te beoordelen, opmerkingen achter te laten en de blauwdruk te voltooien.

Word een UML-evangelist

Soms is het niet genoeg als jij alleen overtuigd bent van het nut van UML-diagrammen. Als softwareontwikkelaar werk je immers meestal in teams, en het is belangrijk om iedereen mee te krijgen.

Als je team terughoudend is om UML-diagrammen in het ontwikkelproces op te nemen, stel dan voor om ze eerst voor slechts één project te gebruiken. Zodra je team ziet hoe waardevol UML-diagrammen zijn voor de documentatie, zullen ze sneller bereid zijn om dit als een noodzakelijke stap te zien.

Bovendien zijn UML-diagrammen met Lucidchart geen verplicht nummer, maar een waardevolle aanwinst.

Een beeld zegt meer dan duizend woorden. Daarom is de Unified Modeling Language (UML) ontwikkeld: om een gedeelde visuele taal te bieden in de complexe wereld van softwareontwikkeling, die ook begrijpelijk is voor zakelijke gebruikers en iedereen die een systeem wil doorgronden. Deze gids bevat alles wat je moet weten over UML. Zelfs als je UML voor het eerst bent tegengekomen tijdens een formele training en het sindsdien niet veel meer hebt gebruikt, blijft het een praktische manier om complexe systemen overzichtelijk te houden — vooral wanneer je het gebruikt als levende documentatie in plaats van een eenmalig opleverproduct.

Soorten UML-diagrammen

UML gebruikt elementen en koppelt ze op verschillende manieren om statische diagrammen (die structurele aspecten van een systeem vertegenwoordigen) en gedragsdiagrammen (die dynamische aspecten van een systeem vertegenwoordigen) te vormen. Voor buitenstaanders lijkt het misschien alsof er een oneindig aantal UML-diagrammen bestaat, maar in werkelijkheid identificeren de UML-standaarden 14 soorten diagrammen die zijn onderverdeeld in twee groepen, die hieronder worden gedefinieerd.

Structurele UML-diagrammen

• Klassendiagram: Dit is het meest gebruikte UML-diagram en de belangrijkste basis van elke objectgeoriënteerde oplossing. Het toont klassen binnen een systeem, attributen en bewerkingen, en de relatie tussen elke klasse. Klassen worden samengevoegd om klassendiagrammen te maken bij het diagrammen van grote systemen. Een klasse wordt vertegenwoordigd door een rechthoek die drie verticaal gestapelde compartimenten bevat: Het bovenste compartiment bevat de naam van de klasse en is verplicht, maar de onderste twee compartimenten geven details over de klasse-attributen en klasse-bewerkingen of -gedragingen.

• Componentendiagram: Een componentendiagram is in feite een meer gespecialiseerde versie van het klassendiagram — dezelfde notatieregels zijn van toepassing op beide. Een componentendiagram breekt een complex systeem af in kleinere componenten en visualiseert de relatie tussen die componenten.

• Samengestelde structuurdiagram: Dit soort diagrammen zijn in feite de blauwdrukken voor de interne structuur van een classifier. Ze kunnen ook worden gebruikt om het gedrag van een samenwerking te tonen of de interacties van de classifier met zijn omgeving via poorten. Ze kunnen gemakkelijk de interne componenten van hardware weergeven om de interne werking grondiger te begrijpen.

• Gebruiksdiagram: Deze diagrammen zijn het meest nuttig voor systems engineers en tonen doorgaans prestaties, schaalbaarheid, onderhoudbaarheid en portabiliteit. Wanneer hardwarecomponenten in relatie tot elkaar worden weergegeven, is het gemakkelijker om je hele hardware-mesh bij te houden en ervoor te zorgen dat er bij een implementatie rekening wordt gehouden met alle elementen.

• Objectdiagram: Objectdiagrammen tonen voorbeelden van datastructuren op een specifiek tijdstip. Je zou een klassendiagram kunnen gebruiken om een structuur te tonen en vervolgens objectdiagrammen als testcases gebruiken om de volledigheid van je klassendiagram te verifiëren. Of je kunt een objectdiagram maken om informatie te ontdekken over modelelementen en hun koppelingen.

• Pakketdiagram: Pakketdiagrammen worden gebruikt om afhankelijkheden tussen verschillende pakketten in een systeem te tonen. Een pakket, weergegeven als een map, organiseert modelelementen, zoals use-cases of klassen, in groepen. Er zijn twee speciale typen afhankelijkheden gedefinieerd tussen pakketten: pakket-import en pakket-merge.

• Profieldiagrammen: Profieldiagrammen maken ook deel uit van de UML-standaard en worden voornamelijk gebruikt wanneer je UML moet aanpassen aan een specifiek domein. Onlangs toegevoegd aan UML 2.0, zijn profieldiagrammen uniek en worden ze zelden gebruikt in specificaties. Een profieldiagram kan het beste worden begrepen als een uitbreidingsmechanisme om UML-modellen aan te passen aan specifieke domeinen en platforms.

Gedrags-UML-diagrammen

• Activiteitendiagrammen: Activiteitendiagrammen worden gebruikt als alternatief voor toestandsmachinediagrammen. Activiteitendiagrammen visualiseren de stappen die in een use-case worden uitgevoerd — de activiteiten kunnen sequentieel, vertakt of gelijktijdig zijn. Dit type UML-diagram wordt gebruikt om het dynamische gedrag van een systeem te tonen, maar kan ook nuttig zijn bij het modelleren van bedrijfsprocessen.

• Communicatiediagrammen: Communicatiediagrammen, die voorheen samenwerkingsdiagrammen werden genoemd, tonen hoe objecten zich tot elkaar verhouden. Ze modelleren de manier waarop objecten zich associëren en verbinden via berichten binnen het architectonische ontwerp van een systeem. Ze kunnen ook alternatieve scenario's tonen binnen use-cases of bewerkingen die de samenwerking tussen verschillende objecten en interacties vereisen.

• Interactieoverzichtsdiagrammen: Dit diagram geeft een overzicht van de controlestroom tussen interagerende knooppunten. Ze bevatten initiële knooppunten, eindknooppunten voor stromen, eindknooppunten voor activiteiten, beslissingsknooppunten, samenvoegknooppunten, splitsingsknooppunten en samenvoegingsknooppunten.

• Volgordediagrammen: Een volgordediagram, soms een gebeurtenisdiagram of een gebeurtenisscenario genoemd, toont de volgorde waarin objecten met elkaar communiceren. Op deze manier kun je eenvoudige runtime-scenario's visueel weergeven.

• Toestandsdiagrammen: Toestandsdiagrammen tonen, simpel gezegd, toestanden en overgangen. Een toestand verwijst naar de verschillende combinaties van informatie die een object kan bevatten, en dit UML-diagram kan alle mogelijke toestanden visualiseren, evenals de manier waarop het object van de ene toestand naar de volgende overgaat.

• Timingdiagrammen: Vaak beschreven als een omgekeerd volgordediagram, tonen timingdiagrammen hoe objecten met elkaar communiceren binnen een bepaald tijdsbestek. Gebruik deze diagrammen om te zien hoe lang elke stap van een proces duurt en om verbeterpunten te identificeren.

• Use-case diagrammen: Use-case diagrammen modelleren hoe gebruikers, weergegeven als stickfiguren genaamd "actoren", met het systeem communiceren. Dit type UML-diagram moet een hoogwaardig overzicht zijn van de relaties tussen actoren en systemen, waardoor het een geweldige tool is om je systeem uit te leggen aan een niet-technisch publiek.

Wat is UML?

De Unified Modeling Language (UML) is ontworpen om een gemeenschappelijke, semantisch en syntactisch rijke visuele modelleertaal te vormen voor de architectuur, het ontwerp en de implementatie van complexe softwaresystemen, zowel structureel als qua gedrag.

Het is analoog aan de blauwdrukken die in andere vakgebieden worden gebruikt en bestaat uit verschillende soorten diagrammen. Samen beschrijven UML-diagrammen de grenzen, de structuur en het gedrag van systemen en de objecten daarin. Wanneer je code schrijft, bevat een applicatie al snel duizenden regels, waardoor het lastig is om het overzicht te bewaren van de relaties en hiërarchieën binnen een softwaresysteem. UML-diagrammen verdelen dat softwaresysteem in componenten en subcomponenten.

Er zijn vier categorieën probleemoplossende modellen: imperatieve, functionele, declaratieve en objectgeoriënteerde talen. In objectgeoriënteerde talen worden algoritmen uitgedrukt door 'objecten' te definiëren en deze objecten met elkaar te laten communiceren. De objecten zijn zaken die gemanipuleerd kunnen worden en die in de echte wereld bestaan. Het kunnen gebouwen zijn, widgets op een bureaublad of menselijke wezens.

Objectgeoriënteerde talen domineren de programmeerwereld omdat ze objecten uit de echte wereld modelleren. UML is een combinatie van verschillende objectgeoriënteerde notaties: objectgeoriënteerd ontwerp, objectmodelleringstechniek en objectgeoriënteerde software engineering.

UML gebruikt de sterke punten van deze drie benaderingen om een consistentere methodologie te presenteren die makkelijker te gebruiken is. UML vertegenwoordigt best practices voor het bouwen en documenteren van verschillende aspecten van software- en bedrijfssysteemmodellering. Omdat UML gestandaardiseerd is, kan het worden toegepast op verschillende programmeertalen en ontwikkelingsprocessen, waardoor het voor de meeste softwareontwikkelaars breed leesbaar is.

In de praktijk is UML ook een vorm van visuele documentatie die de tijd die besteed wordt aan het opnieuw uitleggen van een systeem kan besparen. Deze documentatie kan engineers op tal van manieren helpen, van het inwerken van nieuwe medewerkers tot het geven van een snel overzicht van het systeem aan stakeholders, zodat ontwikkelaars geen tijd verliezen in vergaderingen.

De geschiedenis en oorsprong van UML

Grady Booch, James Rumbaugh en Ivar Jacobson, ook wel bekend als “De Drie Amigo's” van software engineering, sloegen de handen ineen om programmeurs duidelijkheid te bieden door nieuwe standaarden te creëren.

De inspanningen van deze groep leidden in 1996 tot de publicatie van de UML 0.9- en 0.91-documenten. Het werd al snel duidelijk dat verschillende organisaties, waaronder Microsoft, Oracle en IBM, UML als essentieel zagen voor hun eigen zakelijke ontwikkeling. Samen met vele andere individuen en bedrijven brachten zij middelen bijeen om een volwaardige modelleertaal te ontwikkelen. De Drie Amigo's publiceerden The Unified Modeling Language User Guide in 1999 en een update in 2005, inclusief UML 2.0.

De rol van de Object Management Group (OMG) in UML

Volgens hun website is de Object Management Group® (OMG®) een internationaal, open en non-profit consortium voor technologiestandaarden, opgericht in 1989. OMG-standaarden worden gedreven door leveranciers, eindgebruikers, academische instellingen en overheidsinstanties. OMG Task Forces ontwikkelen standaarden voor enterprise-integratie voor een breed scala aan technologieën en een nog bredere reeks industrieën. De modelleerstandaarden van de OMG, waaronder UML en Model Driven Architecture® (MDA®), maken krachtig visueel ontwerp, uitvoering en onderhoud van software en andere processen mogelijk.

OMG houdt toezicht op de definitie en het onderhoud van UML-specificaties. Dit toezicht biedt engineers en programmeurs de mogelijkheid om één taal te gebruiken voor veel doeleinden tijdens alle fasen van de softwarelevenscyclus, voor systemen van alle grootten.

De OMG definieert het doel van UML als volgt:

• Het bieden van tools aan systeemarchitecten, software engineers en softwareontwikkelaars voor de analyse, het ontwerp en de implementatie van op software gebaseerde systemen, evenals voor het modelleren van bedrijfsprocessen en soortgelijke processen.

• Het stimuleren van de sector door interoperabiliteit tussen visuele modelleertools voor objecten mogelijk te maken. Om een zinvolle uitwisseling van modelinformatie tussen tools mogelijk te maken, is er echter overeenstemming over de semantiek en notatie nodig.

UML voldoet aan de volgende vereisten:

• Het vaststellen van een formele definitie van een gemeenschappelijk op Meta-Object Facility (MOF) gebaseerd metamodel dat de abstracte syntaxis van UML specificeert. De abstracte syntaxis definieert de reeks UML-modelleerconcepten, hun attributen en relaties, evenals de regels voor het combineren van deze concepten om gedeeltelijke of volledige UML-modellen te construeren.

• Het bieden van een gedetailleerde uitleg over de semantiek van elk UML-modelleerconcept. De semantiek definieert op een technologie-onafhankelijke manier hoe de UML-concepten door computers moeten worden gerealiseerd.

• Het specificeren van de voor mensen leesbare notatie-elementen voor het vertegenwoordigen van de individuele UML-modelleerconcepten, evenals regels voor het combineren ervan in een verscheidenheid aan diagramtypen die overeenkomen met verschillende aspecten van gemodelleerde systemen.

• Het definiëren van manieren waarop UML-tools conform kunnen worden gemaakt aan deze specificatie. Dit wordt ondersteund (in een afzonderlijke specificatie) met een op XML gebaseerde specificatie van bijbehorende modeluitwisselingsformaten (XMI) die door conforme tools moeten worden gerealiseerd.