UML nog niet klaar

De laatste jaren is het gebruik van UML (Unified Modelling Language) toegenomen.  UML is een potpourri van notatietechnieken voor de analyse en bouw van informatiesystemen. De OMG (Object Management Group), die ooit CORBA in de markt zette, is verantwoordelijk voor deze standaard. 

Het kunnen documenteren en specificeren in een gestandaardiseerde taal is leuk, maar het zou mooier zijn als diezelfde specificaties automatisch omgezet kunnen worden naar operationele applicaties. In de wereld van UML is dit de ultieme wens. Ivar Jacobson, een van de grondleggers van UML, noemde het recentelijk "UML all the way down". UML hoort niet te stoppen bij het ontwerp. 

Momenteel zijn er reeds diverse, commercieel beschikbare producten, zoals Borland’s JBuilder, Compuware’s OptimalJ, Interactive Objects ArcStyler, Oracle’s JDeveloper, Rational’s XDE en TogetherSoft’s Control Center. Die trachten die wens momenteel concreet gestalte te geven. Sommige zijn in staat om Java- en/of C#-code te genereren vanuit bepaalde UML-diagrammen. De een kan volledige applicaties genereren en de ander genereert raamwerken die dan met de hand uitgebreid moeten worden tot volwaardige applicaties.

De potentie van deze producten is groot. Ze zijn echter nog jong en er kan nog heel wat verbeterd worden. Enkele voorbeelden geven aan waar het nog wat schort.

UML kent geen taal om applicatielogica te specificeren. De consequentie hiervan is dat de leveranciers ook geen code voor de applicatielogica kunnen genereren. Dus datgene wat eigenlijk de essentie is van elk administratief informatiesysteem, dat moet gewoon met de hand in een taal als Java of C# geprogrammeerd worden. Dit met de hand schrijven kent enkele nadelen. Ten eerste geldt dat deze met de hand geschreven code aanroepen zal moeten doen naar code die behoort tot de frameworks van de producten. Zonder die frameworks kan de code niet ergens anders draaien en is ze dus niet overdraagbaar. Ten tweede, als de code in Java geschreven wordt, kan ze alleen nog maar op het Java-platform draaien. Een migratie naar Microsoft.NET of een ander toekomstig platform wordt dan lastig of zelfs onmogelijk.

Om schaalbare applicaties te kunnen genereren, hebben de meeste producten noodzakelijke extensies aan UML moeten toevoegen. Het lastige is dat die extensies niet overdraagbaar zijn. Het overhevelen van alle UML-specificaties naar een ander product is mogelijk omdat ze allemaal XMI (XML Metadata Interchange) ondersteunen. Het ene product zal echter de extensies van het andere product niet begrijpen. De hoop is dat de OMG dit gemis snel onderkent en deze broodnodige concepten gaat standaardiseren. Maar momenteel is het zo dat de meeste leveranciers hun eigen varianten van UML ondersteunen. Dat herinnert eraan dat ook veel databaseleveranciers SQL geïmplementeerd hebben, maar wel allemaal hun eigen dialect.

EJB, een van de belangrijke fundamenten van het Java-platform, ondersteunt geen overerving. Voor verscheidene producten is dit de reden waarom ze overerving niet ondersteunen in de UML-diagrammen waaruit de applicatie gegenereerd wordt. Dit beperkt de modelleringsmogelijkheden voor de bouwer. Ook als met een ander product een model gecreëerd is waarin overerving gebruikt is, dan zal dit model niet geïmporteerd kunnen worden.

Ondanks de bovenstaande kritieken dient herhaald te worden dat deze nieuwe generatie producten veel potentie heeft. Ze staan toe dat er niet in een gedetailleerde programmeertaal ontwikkeld hoeft te worden, maar in UML. Dit verhoogt zeer zeker de productiviteit van ontwikkelaars. Tevens schermen ze vele technische details af. Ontwikkelaars hoeven dus geen EJB-experts te zijn om EJB-applicaties te kunnen genereren. Hierdoor wordt het voor meer bedrijven mogelijk naar platformen als J2EE en .NET te migreren. We kunnen het de leveranciers van de producten ook niet kwalijk nemen dat UML niet klaar is. Het is aan de OMG om snel UML uit te breiden waardoor we de beschreven kritieken snel kunnen vergeten.