De codegenerator is een essentieel onderdeel van een geïntegreerde case-omgeving die geschikt is voor de hele levenscyclus van een systeem. Tot op heden is case echter niet zo geslaagd, zoals blijkt uit bijvoorbeeld IBM’s AD/Cycle. Volgens sommige IT-deskundigen is case een mislukking, maar dat is niet helemaal waar. Er zijn duidelijke tekenen die erop wijzen dat case-tools eindelijk volwassen worden.
Er is echter nog een lange weg te gaan. De belangrijkste succesfactor op lange termijn is de repository. Applicatie-ontwikkeling moet uitgroeien van code-ontwikkeling op laag niveau tot herbruikbare softwarecomponenten op hoog niveau. Codering op laag niveau blijft overigens altijd noodzakelijk, omdat iemand nu eenmaal de herbruikbare componenten, compilers en besturingssystemen moet ontwikkelen. Om deze transitie mogelijk te maken is het essentieel dat de ontwerpers van bedrijfsmodellen en operationele tools en de gebruikers van de componenten een gemeenschappelijk mechanisme hebben om hun activiteiten te coördineren. Een herbruikbare component is gevaarlijk en waardeloos als de ontwikkelaar niet weet wat hij doet. De repository biedt het mechanisme voor het combineren van de details van ontwerpregels en de specificaties van objecten en gegevens. Op dit moment is er geen standaard repository. In de praktijk gebruiken organisaties meerdere specifieke repositories en directories, waartussen metagegevens worden uitgewisseld. AD/Cycle heeft tenminste nog de Cdif-standaard geïnspireerd voor het importeren en exporteren van gegevens tussen case-tools – waarschijnlijk de enige blijvende bijdrage van dit product. Als de AD/Cycle Repository Manager een succes was geweest, zou het tot een de facto standaard zijn uitgegroeid en zouden we nu uit een breed scala aan producten kunnen kiezen. De behoefte aan repositories voor metagegevens bij gegevenspakhuis-applicaties is hopelijk een katalysator voor de ontwikkeling van echte repositories.
Ondanks het ontbreken van een gemeenschappelijk repository zijn de leveranciers van case-tools gewoon doorgegaan. Ze hebben producten op de markt gebracht die weliswaar niet een antwoord op elke vraag boden, maar toch redelijk succesvol waren. Helaas zijn dit leveranciersspecifieke producten, zoals Intersolv Excelerator, die invoer levert voor APS.
Er is nog geen component-infrastructuur gebaseerd op de beste gemene deler. Slechts weinig tools werken samen met andere tools. De huidige belangstelling voor bedrijfsobjecten is echter enorm. Hierbij wordt maximaal gebruik gemaakt van object-methodologieën. Dat is op ontwerpniveau natuurlijker en ook niet strijdig met conventionele technieken, wat op codeniveau wel het geval is.
Hoewel er diverse object-georiënteerde methodologieën geïntroduceerd zijn (Booch, Rumbaugh, Jacobson), is een algemene beweging richting ontwerptools als Select en Popkin waarneembaar. Dat convergeert naar een algemene modelleerstandaard, UML genaamd, die het in combinatie met Cdif mogelijk maakt dat de tools aan de front-end invoer kunnen leveren aan de ontwerptools.
Waarschijnlijk is het te laat om deze lijn voort te zetten, zodat de ontwerptools weer aan de codegeneratoren te koppelen zijn. De conversie van bedrijfsmodel naar code en databaseschema zal dus voorbehouden blijven aan specifieke tools.
Sommige tools zullen ontwerpspecificaties produceren. Geavanceerdere tools zullen code genereren. Een ideaal systeem begint met het ontwerp en zal code genereren voor elk target-systeem. Wees niet verrast dat zo’n systeem niet bestaat. De mainframewereld heeft zich met uitstekende resultaten geconcentreerd op het genereren van Cobol voor Cics/Vsam, Cics/DB2 en IMS in combinatie met de Microfocus Cobol Workbench. Intersolvs APS is het beste voorbeeld, maar Pacbase, Telon en Netron zitten ook goed in elkaar. Een vreemde eend in de bijt is IBM’s meest recente versie van CSP, Visualgen, die absoluut niet deugt. IBM lijkt voor zijn eigen omgeving geen goede codegeneratoren te kunnen ontwikkelen. Waarom schrappen ze dat product niet en nemen ze Netrons geavanceerde herbruikbare raamwerk niet over?
In theorie kunnen die producten ook Cobol voor een Unix/Tuxedo/Oracle-omgeving genereren, maar daar beschikken ze niet over de noodzakelijke ondersteuning. Ook hebben ze geen marktaandeel verworven, wellicht doordat ze te traag zijn om gepartitioneerde client/server-modellen te ondersteunen. Daarnaast is de Unix-wereld de client/server-kant opgegaan met een paar zeer merkwaardige producten, zoals Powerbuilder en Visualbasic. Hiermee zijn snel gui’s te bouwen, maar het onderhoud is een nachtmerrie. Codegeneratoren in de Unix- en NT-wereld hebben zich geconcentreerd op C++ en zullen zich binnenkort richten op Java. Helaas hebben deze talen een slechte syntaxis voor bedrijfsfuncties, zodat er niet echt een manier is om complete C-programma’s te genereren (voor het syntactisch rijkere Cobol is dat relatief eenvoudig). Voor C moet je een script genereren dat procedures uit een bibliotheek aanroept. Dynasty is een populair en belangrijk product dat dit generatieprincipe combineert met uitstekende partitioneringstools voor de ontwerpfase. De schaduwzijde van C ten opzichte van Cobol is dat de runtime-code afhankelijk is van de procedurebibliotheken zoals Dynasty en dergelijke die meeleveren. Het aantal target-systemen zal hierdoor sterk verminderen.
Het oude nadeel van de generatoren blijft bestaan: zelfs voor kleine wijzigingen is het nodig om een heleboel code te genereren. De toegenomen robuustheid van de aldus ontstane code is dat nadeel echter meer dan waard.
