Met JDeveloper van UML naar Java

Het ontwikkelen van een administratieve applicatie met Java is complex. Het is niet zozeer de taal die daarvoor verantwoordelijk is, maar APIs, zoals EJB (Enterprise JavaBeans) en RMI (Remote Method Invocation). Ontwikkelaars dienen bekend te zijn met een wirwar aan concepten, zoals entitiy versus session versus message beans en container versus bean managed persistence. 

Deze complexiteit lijdt tot een matige productiviteit. Vandaar dat leveranciers van ontwikkelproducten op zoek zijn gegaan naar manieren om die productiviteit te verhogen. Voorlopig schijnt de oplossing gevonden te zijn in het genereren van Java-code vanuit UML-diagrammen.(Unified Modelling Language). JDeveloper van Oracle is een dergelijk product.

JDeveloper is aanvankelijk gekocht van Borland. De eerste versie was niet veel meer dan een OEM-versie van jBuilder. Een IDE (Integrated Development Environment) voor het ontwikkelen van Java-applicaties. Omdat jBuilder een van de populairste Java-IDE’s was en is, was het begrijpelijk dat Oracle dit product als uitgangspunt nam. In de meest recente versie is er echter niet veel meer van de Borland-code over, want het product is geheel herschreven in Java. De Amerikanen zouden dit beschrijven als “eat your own dog food”. Het is uitgegroeid van een IDE tot een krachtige generator van Java-applicaties. 

Recentelijk is, in samenwerking met het blad Software Release Magazine, door mij een onderzoek uitgevoerd naar de kwaliteit van de vanuit UML Java-code genererende producten. Aan acht leveranciers werd gevraagd een dummy-applicatie te creëren waardoor globaal de aanpak en de (on)mogelijkheden van elk product zichtbaar werden. Omdat JDeveloper tot deze categorie behoort, werd ook zij geëvalueerd. Het vonnis over Oracle was positief.

Met JDeveloper kunnen complete Java-applicaties gegenereerd worden. Deze applicaties gebruiken een SQL-databaseserver voor de opslag van gegevens, een EJB-gebaseerde applicatieserver voor het draaien van de applicatielogica en er kan een user-interface gebouwd worden met gebruikmaking van JSP. Kortom, er wordt een applicatie met een 3-lagen architectuur gegenereerd. De meeste code wordt afgeleid vanuit een UML enkel klassediagram. Wel dient gesteld te worden dat de gegenereerde interface slechts bedoeld is om de applicatie te testen. De uiteindelijke interface dient met de hand ontworpen te worden.

Het product maakt stevig gebruik van BC4J (Business Components for Java). Deze verzameling Java-klassen zorgt ervoor dat het product meer kan dan een gemiddeld product uit deze categorie. Zo is het mogelijk diverse integriteitregels, zoals de maximum waarde van een attribuut in JDeveloper te declareren. Deze worden dan in de uiteindelijke applicatie door een BC4J-klasse gecontroleerd. 

Ook de interface naar de databaseserver wordt goed ondersteund. In sommige producten is dit een zwakke plek. Maar wil een applicatie schalen, dan dient een efficiënte interface gegenereerd te worden. Van een databaseleverancier kan men niet anders verwachten dan dat zij deze kunst beheerst.

Zwakke plekken van het product waren onder andere het genereren van de applicatielogica en integriteitregels. Hiervoor dient helaas met de hand Java-code geschreven te worden. Dit betekent dat deze code alleen nog maar op een Java-platform gedraaid kan worden. Of met andere woorden, de applicatielogica is niet overdraagbaar naar een andere omgeving, zoals bijvoorbeeld Microsoft.NET. Tevens roept de zelfgeschreven code Java-code aan die niet universeel, maar specifiek van Oracle is. Ook dit vermindert de overdraagbaarheid.

Wel dienen twee zaken opgemerkt te worden. Ten eerste: ook bij de meeste andere producten in de test moet applicatielogica met de hand geprogrammeerd worden. Ten tweede: in UML ontbreekt een diagramtype waarmee we die applicatielogica op technologie-onafhankelijke wijze kunnen specificeren. 

Ongetwijfeld zal de aandacht voor JDeveloper bij veel bestaande Oracle Forms-klanten vragen oproepen. Moeten ze migreren naar JDeveloper? Zal Oracle beide ontwikkelproducten nog lang blijven ondersteunen, of maken ze op een gegeven moment een keuze? Als het aan Larry Ellison alleen zou liggen, met zijn weinig gemaskeerde liefde voor Java, dan zou hij ongetwijfeld voor JDeveloper kiezen. Maar tot nu toe meldt Oracle gelukkig dat beide producten nog ondersteund zullen blijven. 

Afgezien van deze twijfels dient vermeld te worden dat JDeveloper in korte tijd uitgegroeid is tot een krachtige Java-generator. Bedrijven die van plan zijn Java als ontwikkeltaal te gaan gebruiken, doen zichzelf te kort als ze JDeveloper niet bestuderen.