Er komt een nieuwe versie van UML aan. Niet iets om naar uit te kijken, vindt Patrcik Savalle. "UML is slecht: de ontwerper maakt er onlogische modellen mee en zal belangrijke aspecten van het systeem niet zien of kunnen aangeven."
De introductie van de nieuwe versie van UML staat op stapel. Nog zonder de nieuwe versie te hebben gezien, durf ik te stellen dat de UML er niet beter op gaat worden. Tussen alle wijzigingsvoorstellen heb ik namelijk niets gezien dat er op duidt dat de fundamentele, zelfs naïeve ontwerpfouten die er van het begin af aan al in zitten, zullen worden verbeterd. De reden dat UML nooit een goede taal (notatie) zal worden, is eenvoudig, en is trouwens dezelfde waardoor de meeste objectmetamodellen van de huidige generatie, van Booch tot aan OMT, dezelfde defecten vertonen.
De UML is bedoeld om bouwtekeningen van een softwaresysteem te maken. Een bouwtekening is een model en een model is een vereenvoudigde weergave van een systeem. Het onderwerp van een model is daarom ‘het systeem’. Zonder een goede definitie van wat nu precies ‘het systeem’ is, lijkt het me dan ook onmogelijk te bepalen hoe het model eruit moet zien. De UML is echter niet duidelijk over wat als systeem wordt gezien. ‘Systeem’ is het belangrijkste basisbegrip van de semantische onderbouwing, maar is onbepaald gebleven. Is het systeem de broncode, een ‘executable’ of iets anders?
UML is gebaseerd op objectoriëntatie en volgens objectoriëntatie is een softwaresysteem het proces dat draait op een computer: het systeem is ‘broncode in uitvoering’. Objectoriëntatie stelt het systeem voor als een ‘levende’ structuur van objecten: een objectmodel. Objecten zijn metaforen om een schijnbaar chaotische verzameling van bits en bytes te kunnen begrijpen. Het objectmodel is veranderlijk: objecten en hun onderlinge relaties veranderen door hun interactie voortdurend en dat is lastig tekenen. Daarom moet het objectmodel zelf ook worden gemodelleerd. Hieruit ontstaat een klassemodel (class-model) en de bijbehorende klassediagrammen. Het klassediagram is de werkelijke bouwtekening van het softwaresysteem en daarmee het belangrijkste soort UML-diagram. Het onderwerp van een klassediagram is een objectmodel, en daarom hadden de ontwerpers van de UML er verstandig aan gedaan om eerst een nauwkeurige beschrijving van zo’n objectmodel te maken. Immers, als je niet goed weet hoe het onderwerp eruit ziet, kun je er ook geen diagram van maken. Ook dat hebben ze nagelaten. Nergens is beschreven hoe een objectmodel er exact uitziet. Dat kan ook niet, want er is ook nergens beschreven hoe het onderwerp van een objectmodel (het systeem) er uitziet.
Ontbrekende elementen
Door een softwaresysteem te abstraheren ontstaat dus een objectmodel en door dat objectmodel te typeren ontstaat het klassemodel. In twee stappen kan van een bestaand softwaresysteem een klassemodel worden opgesteld. Dit is de analyserichting. Er is in deze richting een duidelijke, bijna wiskundige relatie tussen het systeem en de twee genoemde soorten modellen. Abstraheren is een transformatie die nauwkeurig kan worden beschreven. Informeel komt abstraheren neer op het weglaten van irrelevante eigenschappen. Net als abstraheren is ook typeren een transformatie die exact te beschrijven is. Typeren komt neer op het samennemen van gelijksoortige dingen en het cumuleren van hun mogelijkheden.
Abstractie en typering hebben beide ook een tegengestelde ‘richting’, dat is natuurlijk de richting die tijdens het ontwerpen van het systeem wordt gevolgd, de syntheserichting. De tegengestelde richting van typering is instantiatie en de tegengestelde richting van abstractie zou realisatie kunnen worden genoemd.
Tussen systeem, objectmodel en klassemodel bestaat in beide richtingen van modelleren (analyse en synthese) een duidelijk beschrijfbaar verband. Dit essentiële en in principe natuurlijk aanwezige verband ontbreekt in de UML volledig. In een klassemodel komen elementen voor die geen enkel verband hebben met de elementen in een objectmodel (‘collaboration’-diagrammen) en in het objectmodel komen elementen voor die geen enkel verband hebben met de elementen van het systeem.
Dit mankement blijkt goed uit de samenhang van elementen van de verschillende UML-modellen. Neem als voorbeeld de diverse soorten relaties. In de UML-klassediagrammen bestaan een heleboel soorten relaties: de aggregatie-, de generalisatie-, de associatierelaties enzovoort. Door een klassemodel te instantiëren ontstaat een objectmodel. In een UML-objectmodel bestaat maar één soort relatie: de link. De klasserelaties hebben dus geen ‘evenredige’ tegenhanger in het objectmodel. Alle relaties die UML-klassen kunnen hebben, zouden na instantiatie ook tussen UML-objecten moeten kunnen bestaan. Niet in de UML.
Door deze onzorgvuldigheid bij het ontwerpen van de UML ontbreken belangrijke elementen (berichtrelaties in klassediagrammen), bestaan ongeldige elementen (‘dependency’, realisatie) en is het geheel onhandig, inconsistent en onduidelijk. De UML is slecht: de ontwerper maakt er onlogische modellen mee en zal belangrijke aspecten van het systeem niet zien of kunnen aangeven. De UML is ook niet geschikt voor hoogwaardige codegeneratie, daarvoor is evenredigheid in beide richtingen van modellering nodig. Verbeteren van de UML is trouwens zo goed als onmogelijk: de UML is gebouwd als een slecht ontworpen softwaresysteem: een star, verweven, ongelaagd en complex ding.
Patrick Savalle Consultant Turnkiek Technical Systems
