Wat is Unified Modeling Language?

Met de Unified Modeling Language (UML) wilde men een gemeenschappelijke, semantisch en syntactisch rijke visuele modelleertaal creëren voor de bouw, het ontwerp en implementatie van complexe softwaresystemen, op zowel structureel als gedragsmatig gebied. UML kan ook buiten de softwareontwikkeling worden toegepast, bijvoorbeeld op het gebied van productiestromen.

Het is vergelijkbaar met de blauwdrukken die op andere gebieden worden gebruikt en bestaat uit verschillende soorten diagrammen. Globaal gesproken, beschrijft een UML-diagram de grens, de structuur en het gedrag van een systeem en de daarin vervatte objecten.

UML is geen programmeertaal maar er zijn wel tools waarmee het, binnen een UML-diagram, code in verschillende talen mee kan genereren. UML staat in direct verband met objectgeoriënteerde analyse en ontwerp.

De computerwetenschap, oftewel de studie van algoritmen en gegevens, kent vele probleemoplossende paradigma's en modellen. Er zijn vier categorieën van probleemoplossende modellen: imperatieve, functionele, declaratieve en objectgeoriënteerde talen (OOP - objectgeoriënteerd programmeren). In een objectgeoriënteerde taal worden algoritmen uitgedrukt in de vorm van ‘objecten’ en de interacties tussen objecten. Objecten in deze zin zijn dingen die gemanipuleerd kunnen worden en in de echte wereld bestaan. Het kunnen gebouwen zijn, widgets op een desktop, of mensen.  

Objectgeoriënteerde talen zijn vrij dominant in de programmeerwereld omdat ze objecten uit de echte wereld modelleren. UML is een combinatie van diverse objectgeoriënteerde notatiesystemen: objectgeoriënteerd ontwerpen, objectmodelleertechniek en objectgeoriënteerde softwaretechniek.

UML gebruikt de sterke punten van deze drie benaderingen en introduceert een consequentere methodologie die gemakkelijker in het gebruik is. UML biedt een optimale werkmethode voor het bouwen en documenteren van diverse aspecten op het gebied van software- en bedrijfssysteemmodellering.

‘De Drie Amigos’ van de softwaretechniek, zoals ze ook wel werden genoemd, hadden al andere methodologieën ontwikkeld. Ze probeerden duidelijkheid te scheppen voor programmeurs door samen nieuwe standaarden te ontwikkelen. Het resultaat was dat alle drie methoden van deze samenwerking tussen Grady, Booch en Rumbaugh profiteerden en het uiteindelijke product nog beter werd.

De inspanningen van deze drie denkers resulteerden in de publicatie van de UML 0.9 en 0.91 documenten in 1996. Het werd al spoedig duidelijk dat diverse organisaties, waaronder Microsoft, Oracle en IBM, UML als cruciaal beschouwden voor de ontwikkeling van hun bedrijf. Deze bedrijven en personen stelden middelen beschikbaar waarmee een volwaardige modelleertaal kon worden ontwikkeld. De Drie Amigos publiceerden The Unified Modeling Language User Guide in 1999 en een bijgewerkte versie in de tweede editie van 2005 met meer informatie over UML 2.0.

Volgens hun website is The Object Management Group® (OMG®) een internationaal consortium zonder winstoogmerk, en met een open lidmaatschap, ter bevordering van  technologische standaarden , opgericht in 1989. OMG-standaarden worden aangestuurd door fabrikanten, eindgebruikers, wetenschappelijke instellingen en overheidsinstanties. OMG-taakgroepen ontwikkelen zakelijke integratiestandaarden voor een brede verscheidenheid aan technologieën en een nog bredere verscheidenheid aan sectoren. De modelleringstandaarden van OMG, inclusief  UML en  Model Driven Architecture ® (MDA®), zorgen ervoor dat software en andere processen op een krachtige, visuele wijze ontworpen, uitgevoerd en onderhouden kunnen worden.

OMG houdt toezicht op de definitie en het onderhoud van de UML-specificaties. Dit toezicht biedt ingenieurs en programmeurs de gelegenheid om één taal voor vele doeleinden te gebruiken, tijdens alle fasen van de software-levenscyclus voor systemen in alle soorten en maten.

Het OMG definieert het doel van de UML als volgt:

• Systeemarchitecten, software-ingenieurs en software-ontwikkelaars de tools te leveren waarmee ze software-gebaseerde systemen kunnen analyseren, ontwerpen en implementeren, en bovendien zakelijke en gelijkaardige processen kunnen modelleren.
• De toestand in de softwaresector te verbeteren door interoperabiliteit van objectgeoriënteerde en visuele modelleertools mogelijk te maken. Om een betekenisvolle uitwisseling van modelinformatie tussen tools mogelijk te maken, moet men het echter eens worden over de te gebruiken semantiek en notatie.

UML voldoet aan de volgende vereisten:

• Het legt een formele definitie vast voor een gemeenschappelijk Meta-Object Facility (MOF)-gebaseerd metamodel dat de abstracte syntax van de UML specificeert. Deze abstracte syntax bepaalt de reeks UML-modelleerconcepten, hun eigenschappen en hun relaties, en bovendien de regels waarmee deze concepten gecombineerd kunnen worden om er gedeeltelijke of complete UML-modellen mee op te bouwen.
• Het biedt een gedetailleerde uitleg van de semantiek binnen elk UML-modelleerconcept. De semantiek bepaalt op een technologisch onafhankelijke manier hoe de UML-concepten door computers moeten worden gerealiseerd.
• Het specificeert de voor mensen leesbare notatie-elementen waarin de afzonderlijke UML-modelleerconcepten worden afgebeeld maar ook de regels die worden toegepast om deze concepten in diverse verschillende diagramsoorten te combineren, in overeenkomstig met de verschillende aspecten van gemodelleerde systemen.
• Het definieert verschillende manieren waarop UML-tools aan deze specificatie kunnen voldoen. Dit wordt ondersteund (in een afzonderlijke specificatie) met een XML-gebaseerde specificatie voor corresponderende model uitwisselingsformaten (XMI) die door de conforme tools gerealiseerd moeten worden.

De UML is zeer geliefd onder programmeurs maar wordt doorgaans niet door database-ontwikkelaars gebruikt. Een van de redenen hiervoor is dat de makers van de UML zich gewoon niet op databases hebben gericht. De UML is desondanks effectief voor conceptuele gegevensmodellering op hoog niveau en kan in verschillende soorten UML-diagrammen worden gebruikt. Meer informatie over het stapelen van een objectgeoriënteerd klassendiagram op een relationele database kunt u vinden in dit artikel over Database Modeling in UML.

UML wordt voortdurend verfijnd. UML 2.0 breidt de UML-specificaties uit naar andere ontwikkelingsaspecten, zoals bijvoorbeeld Agile. Het doel is UML te herstructureren en te verfijnen zodat bruikbaarheid, implementatie en adaptatie eenvoudiger worden. Hier zijn een paar updates voor UML-diagrammen:

• Meer integratie tussen structurele en gedragsmodellen.
• Mogelijkheid om hiërarchie te bepalen en een software-systeem in componenten en subcomponenten op te delen.
• UML 2.0 verhoogt het aantal diagrammen van 9 tot 13.

Maak uzelf vertrouwd met de UML-woordenschat, aan de hand van deze lijst uit het UML 2.4.1-document, oorspronkelijk bedoeld om niet-leden van de OMG te helpen enkele veelgebruikte termen te begrijpen.

• Abstract syntax compliance

  Gebruikers kunnen modellen verplaatsen tussen verschillende tools, zelfs als deze tools een andere notatie gebruiken.

• Common Warehouse Metamodel (CWM)

  Een standaard-interface die een uitwisseling van warehouse- en bedrijfsinformatiemetadata mogelijk maakt tussen warehousetools, warehouseplatformen en opslagplaatsen van warehousemetadata in verspreide en heterogene omgevingen.

• Concrete syntax compliance

  Gebruikers kunnen een notatie die hen vertrouwd is gewoon door blijven gebruiken in andere tools.

• Core

  In een UML-context wordt er met de 'core', of kern, meestal het 'core package' (kernpakket) bedoeld. Dit is een compleet metamodel dat vooral ontworpen is om vaak opnieuw te worden gebruikt.

• Language Unit

  De taaleenheid is een verzameling nauw gekoppelde modelleerconcepten waarmee gebruikers aspecten van het bestudeerde systeem volgens een bepaald paradigma of formalisme weer kunnen geven.

• Level 0 (L0)

  Dit is het laagste conformiteitsniveau voor een UML-infrastructuur - een enkele taaleenheid waarmee de verschillende soorten klassenstructuren gemodelleerd kunnen worden die men in de meeste populaire objectgeoriënteerde programmeertalen tegenkomt.

• Meta Object Facility (MOF)

  Een OMG-modelleerspecificatie die de basis vormt voor definities van metamodellen in de OMG-familie van MDA-talen.

• Metamodel

  Bepaalt de taal en de processen waarmee een model wordt opgebouwd.

• Metamodel Constructs (LM)

   Tweede conformiteitsniveau in de UML-infrastructuur - een extra taaleenheid voor geavanceerdere klassenstructuren die gebruikt worden voor het bouwen van metamodellen (met behulp van CMOF) zoals UML zelf. UML beschikt slechts over twee conformiteitsniveaus.

• Model Driven Architecture (MDA)

  Een benadering en een schema om een samenhangende reeks modelgedreven technologiespecificaties te verwezenlijken.

• Object Constraint Language (OCL)

  Een declaratieve taal waarin de regels worden beschreven die op de Unified Modeling Language van toepassing zijn. OCL vult UML aan door termen en symbolen voor stroomdiagrammen te leveren die nauwkeuriger zijn dan natuurlijke taal maar minder moeilijk te leren zijn dan wiskundige taal.

• Object Management Group (OMG)

  is een consortium zonder winstoogmerk dat specificaties voor de computersector opstelt. De UML-specificatie wordt door leden van dit consortium bepaald en onderhouden.

• UML 1

  Eerste versie van de Unified Modeling Language.

• Unified Modeling Language (UML)

  Een visuele taal die wordt gebruikt om de artefacten van een systeem te specificeren, bouwen en documenteren.

• XMI

  Een op XML-gebaseerde specificatie voor corresponderende modeluitwisselingsformaten.

Bekijk het volledige MOF- document

Download het volledige UML 2.4.1-infrastructuurdocument.

Voor de ontwikkeling van een systeem worden meestal drie verschillende systeemmodellen gebruikt:

• Functioneel:

  Dit zijn Use Case-diagrammen die de functionaliteit van het systeem vanuit het gezichtspunt van de gebruiker beschrijven.

• Object:

  Dit zijn klassendiagrammen die de structuur van het systeem beschrijven op het gebied van objecten, eigenschappen, associaties en handelingen.

• Dynamisch:

  Interactie-diagrammen, toestandmachine-diagrammen en activiteitendiagrammen die het interne gedrag van het systeem beschrijven.

Deze systeemmodellen worden gevisualiseerd aan de hand van twee verschillende soorten diagrammen: structurele en gedragsdiagrammen.

De objecten in UML zijn levensechte entiteiten die in de wereld om ons heen voorkomen. In de software-ontwikkeling kunnen objecten gebruikt worden om het systeem dat men aan het bouwen is te beschrijven of te modelleren in termen die relevant zijn voor het domein. Objecten maken het ook mogelijk om complexe systemen in begrijpelijke onderdelen op te breken waardoor stuk per stuk opgebouwd kan worden.

Hier zijn enkele basisconcepten die u in de objectgeoriënteerde wereld kunt tegenkomen:

• Objecten

  Geven een entiteit weer en zijn basis bouwblokken.

• Klasse

  Blauwdruk van een object

• Abstractie

  Gedrag van een entiteit in de echte wereld

• Inkapseling

  Mechanisme waarmee gegevens worden samengebundeld en uit het zicht van de buitenwereld worden gehouden.

• Erfenis

  Mechanisme waarmee een nieuwe klasse uit een bestaande klasse gecreëerd kan worden.

• Polyformisme

  Dit bepaalt of het mechanisme in verschillende vormen kan bestaan.

UML gebruikt elementen en associeert hen op verschillende manieren om er diagrammen mee te maken die de statische of structurele aspecten van een systeem weergeven, en gedragsdiagrammen die de dynamische aspecten van een systeem vastleggen.

Structurele UML-diagrammen

• Klassendiagram Het meest gebruikte UML-diagram en de voornaamste basis voor objectgeoriënteerde oplossingen. Toont klassen binnen een systeem, eigenschappen en handelingen, en het verband tussen klassen. Klassen worden samengebundeld in een klassendiagram om diagrammen van grote systemen te maken.

• Onderdeeldiagram

  Geeft
  de structurele relatie tussen de verschillende elementen van een softwaresysteem weer, en wordt meestal gebruikt om complexe systemen die uit meerdere onderdelen bestaan uit te leggen. Onderdelen communiceren met elkaar door middel van interfaces.

• Samengesteld structuurdiagram

  Dit soort diagrammen wordt gebruikt om de interne structuur van een klasse weer te geven.

• Inzetdiagram

  Illustreert de hardware en software van een systeem. Vooral nuttig als een sofware-oplossing wordt gebruikt op meerdere machines met unieke configuraties.
• Objectdiagram Toont de relatie tussen objecten door middel van voorbeelden uit de echte wereld en laat zien hoe een systeem er op een bepaald moment uitziet. Omdat objecten gegevens bevatten kunnen ze worden gebruikt om relaties tussen objecten duidelijk te maken.

• Pakketdiagram

  Er bestaan twee speciale soorten afhankelijkheid tussen pakketten: pakketten importeren en pakketten samenvoegen. Pakketten kunnen de verschillende niveaus van een systeem weergeven om de architectuur ervan te onthullen. Pakketafhankelijkheden kunnen gemarkeerd worden om het communicatiemechanisme tussen niveaus weer te geven.

Gedragsdiagrammen (UML)

• Activiteitendiagram Grafisch weergegeven zakelijke of operationele werkstromen om bepaalde activiteiten binnen een systeem af te beelden. Een activiteitendiagram kan als alternatief gebruikt worden voor een toestandmachinediagram.
• Communicatiediagram Vergelijkbaar met een sequentiediagram maar meer gericht op de berichten die tussen objecten worden uitgewisseld. Dezelfde informatie kan met een sequentiediagram en andere objecten worden weergegeven.

• Interactie-overzichtdiagram

  Er zijn zeven soorten interactiediagrammen en dit diagram toont de volgorde waarin zij handelen.

• Sequentiediagram

  Laat zien hoe objecten op elkaar reageren en de volgorde waarin activiteiten worden uitgevoerd. Ze geven de interacties voor een bepaald scenario weer.
• Toestandmachinediagram Vergelijkbaar met een activiteitendiagram. Ze beschrijven het gedrag van objecten die zich in hun huidige toestand op diverse manieren kunnen gedragen.
• Timing diagram Net als bij een sequentiediagram wordt in dit diagram het gedrag van objecten binnen een bepaald tijdschema weergegeven. Als het slechts één object bevat, is het een simpel schema. Als het diagram uit meer dan een object bestaat, geeft het de interacties tussen objecten gedurende het betreffende tijdskader weer.
• Use case-diagram Geeft een bepaalde functionaliteit van een systeem weer, om aan te tonen hoe deze functionaliteiten zich tot elkaar en hun interne/externe controllers (actoren) verhouden.

Er zijn diverse handleidingen beschikbaar met meer informatie over het maken van verschillende soorten UML-diagrammen. In deze handleidingen leert u hoe u structurele zowel als gedragsdiagrammen kunt tekenen.

Handleiding voor het maken van structurele diagrammen, met voorbeelden

KLASSENDIAGRAMMEN

Klassendiagrammen geven de statische structuren van een systeem weer, inclusief klassen, eigenschappen, handelingen en objecten. Een klassendiagram kan rekenkundige gegevens of organisatorische gegevens weergeven in de vorm van respectievelijk implementatieklassen en logische klassen. Deze twee groepen kunnen elkaar overlappen.

1. Klassen worden weergegeven door middel van een rechthoekige vorm die in drieën is opgedeeld. Het bovenste deel toont de naam van de klasse, terwijl het middelste deel de klasse-eigenschappen bevat. Het onderste deel bevat de handelingen voor elke klasse (ook wel methoden genoemd).
2. Voeg klassenvormen aan uw klassendiagram toe om de relatie tussen deze objecten te modelleren. U kunt hier waar nodig ook subklassen aan toe voegen.
3. Gebruik lijnen om associaties, erfenissen, veelsoortigheid en andere relaties tussen klassen en subklassen weer te geven. De notatie van de lijnen wordt bepaald door de notatiestijl waar u gebruik van maakt.

 

ONDERDEELDIAGRAMMEN

Onderdeeldiagrammen laten zien hoe onderdelen gecombineerd worden om samen grotere onderdelen of softwaresystemen te vormen. Deze diagrammen zijn bedoeld om de afhankelijkheden van elk onderdeel in het systeem te modelleren. Een onderdeel is nodig om een stereotype functie uit te kunnen voeren. Het stereotype van een onderdeel kan bestaan uit uitvoerbare gegevens, documenten, database-tabellen, bestanden of bibliotheekbestanden.

1. Geef een onderdeel weer door middel van een rechthoek. Er moeten twee kleine rechthoeken aan één kant zitten, of een icoon in de vorm van een rechthoek.
2. Breng lijnen tussen de onderdeelvormen aan om de relevante relaties weer te geven.

 

INZETDIAGRAMMEN

Een inzetdiagram modelleert het fysieke gebruik en de structuur van hardware-onderdelen. Gebruiksdiagrammen laten zien waar en hoe de onderdelen van een systeem precies met elkaar samenwerken.

1. Gebruik, bij het tekenen van een inzetdiagram, dezelfde notatie als die van een onderdeeldiagram.
2. Gebruik een driedimensionele kubus om een knooppunt (dat een fysieke of virtuele machine moet voorstellen) te modelleren.
3. Label het knooppunt in dezelfde stijl als in een sequentiediagram. Voeg waar nodig meer knooppunten toe, en verbindt deze vervolgens met lijnen.

 

Handleiding voor het maken van gedragsdiagrammen, met voorbeelden

Activiteitendiagram

Activiteitendiagrammen geven de procedurele controlestroom weer tussen klassenobjecten, naast organisatorische processen zoals bedrijfswerkstromen. Deze diagrammen zijn gemaakt met gespecialiseerde vormen die vervolgens verbonden worden door pijlen. Het gebruikte notatiesysteem in een activiteitendiagram is vergelijkbaar met de notatie in een toestandsdiagram.

1. Begin uw activiteitendiagram met een volle cirkel.
2. Verbind de cirkel met de eerste activiteit, afgebeeld als een rechthoek met afgeronde hoeken.
3. Verbind elke activiteit vervolgens met andere activiteiten door middel van lijnen die de stroom van het hele proces stapsgewijs weergeven.
4. Om de objecten die elke activiteit uitvoeren, weer te geven, kunt u ook zwembanen gebruiken.

 

Use case-diagram

Een use case is een lijst met stappen waarin de interactie wordt bepaald tussen een actor (een persoon die interageert met het systeem of een extern systeem) en het systeem zelf. Use case-diagrammen beschrijven de specificaties van een use case en geven vorm aan de functionele eenheden van een systeem. Met deze diagrammen krijgen ontwikkelingsteams een beter beeld van de vereisten van hun systeem, zoals de rol van de menselijke interactie in het systeem en de verschillen tussen diverse use cases. In een use case-diagram kunnen alle gebruikssituaties van het systeem weergegeven worden of slechts een kleine groep use cases die dezelfde functionaliteit hebben.

1. Start een use case-diagram door een ovale vorm in het midden van de tekening te plaatsen.
2. Typ de naam van de use case in dit ovaal.
3. Zet actoren in de vorm van een stokmannetje in de buurt van het diagram en trek daarna lijnen om de relaties tussen de actoren en use cases weer te geven.

 

Volgordediagram

Sequentiediagrammen, ook wel evenementsdiagrammen of evenementsscenario's genoemd, laten de verbanden tussen de verschillende processen zien door de oproepen tussen verschillende objecten in een bepaalde sequentie te tonen. Deze diagrammen hebben twee dimensies: een verticale en een horizontale dimensie. De verticale lijnen tonen de reeks berichten en oproepen in chronologische volgorde en de horizontale elementen tonen de objectinstanties waar de berichten naartoe worden gestuurd.

1. Begin een sequentiediagram door de naam van de klasse-instantie en de klasse zelf in een rechthoekig vak op te schrijven.
2. Trek lijnen tussen klasse-instanties om de verzender en de ontvanger van berichten weer te geven.
3. Gebruik volle pijlpunten om synchrone berichten weer te geven, lege pijlpunten voor niet-synchrone berichten en gestreepte lijnen voor antwoordberichten.

U kunt nu beginnen UML-diagrammen te bouwen met Lucidchart. We proberen het u zo eenvoudig, efficiënt en leuk mogelijk te maken!

• Eenvoudig in gebruik

  Als u een UML-diagram aan het maken bent, dan weet u precies waar u mee bezig bent, maar we willen het altijd zo gemakkelijk mogelijk voor u maken om goed werk af te leveren. Met de verfijnde interface van Lucidchart en onze slimme 'drag-and-drop'-editor bespaart u zeeën van tijd.

• Uitgebreide vormbibliotheek

  Teken toestanddiagrammen, activiteitendiagrammen, use case-diagrammen en nog veel meer. Met een uitgebreide vorm- en connectorenbibliotheek heeft u alles wat u maar nodig heeft bij de hand.

• Volledig geïntegreerd

  Lucidchart is volledig geïntegreerd met G Suite. Zodra u een Lucidchart-account heeft geopend, ziet u ons tussen uw Gmail en GoogleDrive in uw Google-productiviteitssuite staan. En u kunt gewoon uw Google-login gebruiken om toegang te krijgen.

• Maakt samenwerken mogelijk

  U kunt uw UML-diagram gemakkelijk met uw collega's, klanten of zelfs uw baas delen. Uw diagrammen kunnen op een webpagina worden ingesloten of als een pdf worden gepubliceerd, en met de presentatiemodus van Lucidchart kunt u uw creatie tot een prachtig visueel hulpmiddel omtoveren.

• Importeren en exporteren van Visio

  U kunt eenvoudig Visio-bestanden importeren en exporteren zodat uw eerder verrichtte werk niet verloren gaat. Het hele proces is snel en sluit naadloos op elkaar aan.