UML-diagram

 [verbergen] 

• 1 Geschiedenis
• 1.1 Vóór UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Ontwerp
• 2.1 Softwareontwikkelingsmethoden
• 2.2 Modellering
• 3 Diagrammen
• 3.1 Structuurdiagrammen
• 3.2 Gedragsdiagrammen
• 3.2.1 Interactiediagrammen
• 4 Meta modellering
• 5 Aanneming
• 6 Kritiek
• 6.1 Kritiek op UML 1.x

Geschiedenis van objectgeoriënteerde methoden en notatie

UML heeft zich ontwikkeld sinds de tweede helft van de jaren negentig en heeft zijn wortels in de objectgeoriënteerde methoden die eind jaren tachtig, begin jaren negentig werden ontwikkeld. De tijdlijn (zie afbeelding) toont de hoogtepunten van de geschiedenis van objectgeoriënteerde modelleermethoden en notatie.

Het is oorspronkelijk gebaseerd op de notaties van de Booch-methode, de Object-modelleringstechniek (OMT) en Object-georiënteerde software engineering (OOSE), die het heeft geïntegreerd in één enkele taal. ^[5]

Vóór UML 1.x[bewerken bron | bewerken]

Rational Software Corporation nam in 1994 James Rumbaugh van General Electric in dienst en daarna werd het bedrijf de bron voor twee van de populairste object-georiënteerde modelleerbenaderingen van dat moment:^[6] Rumbaugh's Object-modeling techniek (OMT) en Grady Booch's methode. Zij werden al snel in hun inspanningen bijgestaan door Ivar Jacobson, de bedenker van deobject-oriented software engineering (OOSE) methode, die zich in 1995 bij hen voegde bij Rational.^[1]

Onder de technische leiding van deze drie (Rumbaugh, Jacobson en Booch) werd in 1996 een consortium opgericht, de UML Partners, om de specificatie van de Unified Modeling Language (UML) te voltooien en aan de Object Management Group (OMG) voor te stellen voor standaardisatie. Het samenwerkingsverband omvatte ook andere belanghebbende partijen (bijvoorbeeld HP, DEC, IBM en Microsoft). De UML 1.0 draft van de UML Partners werd in januari 1997 door het consortium aan de OMG voorgesteld. In dezelfde maand vormden de UML Partners een groep die de exacte betekenis van taalconstructies moest definiëren, onder voorzitterschap van Cris Kobryn en onder leiding van Ed Eykholt, om de specificatie af te ronden en deze te integreren met andere normalisatie-inspanningen. Het resultaat van deze werkzaamheden, UML 1.1, werd in augustus 1997 ingediend bij de OMG en in november 1997 door de OMG aangenomen.^[1][7]

UML 1.x[edit source | edit]

Na de eerste release werd een task force gevormd^[1] om de taal te verbeteren, die verschillende kleine revisies uitbracht, 1.3, 1.4, en 1.5.^[8]

De door haar opgestelde normen (evenals de oorspronkelijke norm) zijn als dubbelzinnig en inconsistent aangemerkt. ^[9][10]

UML 2.x[edit source | edit]

De grote herziening van UML 2.0 verving versie 1.5 in 2005, die werd ontwikkeld met een uitgebreid consortium om de taal verder te verbeteren en nieuwe ervaringen met het gebruik van de functies weer te geven. ^[11]

Hoewel UML 2.1 nooit als formele specificatie werd vrijgegeven, verschenen de versies 2.1.1 en 2.1.2 in 2007, gevolgd door UML 2.2 in februari 2009. UML 2.3 werd formeel vrijgegeven in mei 2010.^[12] UML 2.4.1 werd formeel vrijgegeven in augustus 2011.^[12] UML 2.5 werd vrijgegeven in oktober 2012 als een "In process" versie en werd officieel vrijgegeven in juni 2015.^[12]

Er zijn vier delen in de UML 2.x-specificatie:

1. De superstructuur die de notatie en semantiek definieert voor diagrammen en hun modelelementen
2. De infrastructuur die het kernmetamodel definieert waarop de superstructuur is gebaseerd
3. De Object Constraint Language (OCL) voor het vastleggen van regels voor modelelementen
4. De UML Diagram Interchange die definieert hoe UML 2 diagram layouts worden uitgewisseld

De huidige versies van deze standaarden volgen: UML Superstructure versie 2.4.1, UML Infrastructure versie 2.4.1, OCL versie 2.3.1, en UML Diagram Interchange versie 1.0.^[13] De taal wordt nog steeds bijgewerkt en verbeterd door de revision task force, die eventuele problemen met de taal oplossen. ^[14]

De Unified Modeling Language (UML) biedt een manier om de architectonische blauwdrukken van een systeem te visualiseren in een diagram (zie afbeelding), inclusief elementen zoals:^[5]

• Alle activiteiten (banen)
• Afzonderlijke onderdelen van het systeem
• En hoe ze kunnen samenwerken met andere softwarecomponenten.
• Hoe het systeem zal werken
• Hoe entiteiten interageren met anderen (componenten en interfaces)
• Externe gebruikersinterface

Hoewel oorspronkelijk uitsluitend bedoeld voor objectgeoriënteerde ontwerpdocumentatie, is de Unified Modeling Language (UML) uitgebreid tot een groter geheel van ontwerpdocumentatie (zoals hierboven opgesomd),^[15] en in vele contexten nuttig bevonden. ^[16]

Softwareontwikkelingsmethoden[bewerken bron | bewerken]

UML is op zichzelf geen ontwikkelingsmethode; ^[17] zij werd echter ontworpen om compatibel te zijn met de toonaangevende objectgeoriënteerde softwareontwikkelingsmethoden van haar tijd (bijvoorbeeldOMT, Booch-methode, Objectory) en vooral met RUP, waarvoor zij oorspronkelijk bedoeld was toen het werk bij Rational Software Inc. begon.

Modelleren[bewerken bron | bewerken]

Het is belangrijk onderscheid te maken tussen het UML-model en de reeks diagrammen van een systeem. Een diagram is een gedeeltelijke grafische weergave van het model van een systeem. De verzameling diagrammen hoeft het model niet volledig te omvatten en het verwijderen van een diagram verandert het model niet. Het model kan ook documentatie bevatten die de modelelementen en -diagrammen aanstuurt (zoals geschreven use cases).

UML-diagrammen geven twee verschillende weergaven van een systeemmodel weer:^[18]

• Statische (of structurele) visie: benadrukt de statische structuur van het systeem met behulp van objecten, attributen, operaties en relaties. De structurele visie omvat klassendiagrammen en samengestelde structuurdiagrammen.
• Dynamische (of gedrags)view: benadrukt het dynamische gedrag van het systeem door samenwerkingsverbanden tussen objecten en veranderingen in de interne toestand van objecten te laten zien. Deze view omvat sequentiediagrammen, activiteitendiagrammen en toestandsmachinediagrammen.

UML-modellen kunnen tussen UML-tools worden uitgewisseld met behulp van het uitwisselingsformaat XML Metadata Interchange (XMI).

UML 2 kent vele typen diagrammen die in twee categorieën zijn verdeeld. ^[5] Sommige typen geven structurele informatie weer, en de rest geeft algemene gedragstypen weer, waaronder een paar die verschillende aspecten van interacties weergeven. Deze diagrammen kunnen hiërarchisch worden gecategoriseerd zoals weergegeven in het volgende klassendiagram:^[5]

Deze diagrammen kunnen allemaal commentaar of notities bevatten waarin het gebruik, de beperking of de bedoeling wordt uitgelegd.

Structuurdiagrammen[bewerken bron | bewerken]

Structuurdiagrammen benadrukken de zaken die aanwezig moeten zijn in het gemodelleerde systeem. Aangezien structuurdiagrammen de structuur weergeven, worden zij veel gebruikt bij het documenteren van de software-architectuur van softwaresystemen. Bijvoorbeeld het component diagram dat beschrijft hoe een software systeem is opgedeeld in componenten en de afhankelijkheden tussen deze componenten toont.

• Onderdelendiagram
• Klassendiagram

Gedragsdiagrammen[bewerken bron | bewerken]

Gedragsdiagrammen benadrukken wat er in het gemodelleerde systeem moet gebeuren. Aangezien gedragsdiagrammen het gedrag van een systeem illustreren, worden zij veel gebruikt om de functionaliteit van softwaresystemen te beschrijven. Als voorbeeld beschrijft het activiteitendiagram de zakelijke en operationele stap-voor-stap activiteiten van de componenten in een systeem.

• Activiteitendiagram
• Gebruikssituatie diagram

Interactiediagrammen[bewerken bron | bewerken]

Interactiediagrammen, een subset van gedragsdiagrammen, benadrukken de stroom van controle en gegevens tussen de dingen in het systeem dat gemodelleerd wordt. Bijvoorbeeld, het sequentiediagram, dat laat zien hoe objecten met elkaar communiceren in termen van een opeenvolging van berichten.

• Opeenvolgingsdiagram
• Communicatiediagram

Hoofdartikel: Meta-Object Faciliteit

Illustratie van de Meta-Object-faciliteit

De Object Management Group (OMG) heeft een metamodelleringsarchitectuur ontwikkeld om de Unified Modeling Language (UML) te definiëren, genaamd de Meta-Object Facility (MOF). ^[19] De Meta-Object Facility is ontworpen als een architectuur met vier lagen, zoals te zien is in de afbeelding rechts. Het voorziet in een metamodel op de bovenste laag, de M3-laag genoemd. Dit M3-model is de taal die door Meta-Object Facility wordt gebruikt om metamodellen te bouwen, M2-modellen genoemd.

Het meest prominente voorbeeld van een Meta-Object Facility-model van laag 2 is het UML-metamodel, het model dat de UML zelf beschrijft. Deze M2-modellen beschrijven elementen van de M1-laag, en dus M1-modellen. Dit zijn bijvoorbeeld modellen die in UML zijn geschreven. De laatste laag is de M0-laag of gegevenslaag. Deze wordt gebruikt om runtime-instanties van het systeem te beschrijven. ^[20]

Het meta-model kan worden uitgebreid met behulp van een mechanisme dat stereotyping wordt genoemd. Dit is door Brian Henderson-Sellers en Cesar Gonzalez-Perez bekritiseerd als zijnde ontoereikend/onbruikbaar in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

UML is nuttig gebleken in vele ontwerpcontexten,^[16] zozeer zelfs dat het alomtegenwoordig is geworden in de IT-gemeenschap. ^[22]

Het is soms behandeld als een wondermiddel voor ontwerp, wat heeft geleid tot problemen in het gebruik ervan. Verkeerd gebruik ervan omvat overmatig gebruik ervan (elk klein onderdeel van de systeemscode ermee ontwerpen, wat onnodig is) en de aanname dat iedereen er iets mee kan ontwerpen (zelfs degenen die niet geprogrammeerd hebben). ^[23]

Het wordt gezien als een grote taal, met veel constructies erin. Sommigen (waaronder Jacobson) vinden dat het er te veel zijn en dat dit het leren (en dus het gebruik) ervan belemmert. ^[24]

Veel gehoorde kritiek vanuit de industrie op UML is onder meer:^[4]

• niet nuttig: "[biedt] hen geen voordelen ten opzichte van hun huidige, geëvolueerde praktijken en voorstellingen"
• te complex, vooral voor communicatie met klanten: "onnodig complex" en "de beste reden om UML niet te gebruiken is dat het niet 'leesbaar' is voor alle belanghebbenden. Wat is UML waard als een zakelijke gebruiker (de klant) het resultaat van je modelleerinspanning niet kan begrijpen?"
• UML en code moeten synchroon lopen, zoals met documentatie in het algemeen

Kritiek op UML 1.x[bewerken bron | bewerken]

Kardinaliteitsnotatie

Net als bij database Chen, Bachman en ISO ER-diagrammen worden klassemodellen gespecificeerd om "look-across" cardinaliteiten te gebruiken, ook al geven verschillende auteurs (Merise,^[25] Elmasri & Navathe[26] e.a.[27]⁾ de voorkeur aan "same-side" of "look-here" voor rollen en zowel minimale als maximale cardinaliteiten. Recente onderzoekers (Feinerer,^[28] Dullea e.a.^[29]) hebben aangetoond dat de "look-across" techniek die door UML en ER diagrammen wordt gebruikt, minder effectief en minder coherent is wanneer deze wordt toegepast op n-ary relaties van orde >2.

Feinerer zegt: "Er ontstaan problemen als we werken volgens de look-across semantiek zoals gebruikt voor UML associaties. Hartmann^[30] onderzoekt deze situatie en laat zien hoe en waarom verschillende transformaties falen." (Hoewel de genoemde "reductie" vals is omdat de twee diagrammen 3.4 en 3.5 in feite hetzelfde zijn) en ook "Zoals we op de volgende bladzijden zullen zien, introduceert de look-across interpretatie verschillende moeilijkheden die de uitbreiding van eenvoudige mechanismen van binaire naar n-ary associaties verhinderen."