Een markt voor 4gl-generatoren is weinig realistisch – bij deze stelling van Guus van der Meulen sluit Bert Dingemans zich aan. Ook Rob Ronda slaat de spijker op de kop met zijn stelling dat een generator behoefte heeft aan formele modellen, terwijl deze ontbreken. ‘Generatoren moeten gebruikt worden tot het punt waar de inzet ervan efficiënt en realistisch is; daarna mag ontwikkelen weer mensenwerk worden’, luidt Dingemans’ slotconclusie.
Guus van der Meulen schrijft in ‘Aandacht voor programmagenerator’ (Computable, 2 mei 2003, pagina 35) dat programmageneratoren een discussie waard zijn. Ik beaam dat, generatoren zijn van alle tijden en hebben altijd veel discussie opgeleverd. Waarom geven generatoren stof tot discussie? In het artikel van Van der Meulen komen twee aspecten naar voren. Je maakt een generator op het moment dat er herhaling optreedt. Een 4gl-codegenerator (vierde-generatie taal) is niet realistisch omdat er geen markt voor is. Over beide stellingen heb ik mijn twijfels. Eerst wil ik echter kort ingaan op de voor- en nadelen van softwaregeneratoren.
Allereerst het verschil tussen een programmagenerator en een softwaregenerator. Met een programmagenerator wordt programmacode gegenereerd op basis van een definitie die opgeslagen is in een aantal gegevensbestanden (veelal een repository). Een softwaregenerator doet meer: hij genereert naast programmacode ook documentatie, delen van het ontwerp en in een aantal gevallen testplannen. Daarnaast is hij in staat modellen te valideren en verifiëren.
Complexiteit
Werken met een generator heeft een aantal expliciete voordelen boven de ’traditionele’ werkwijze. Het maken van software is moeilijk omdat programmatuur een grote mate van complexiteit bevat. Deze complexiteit wordt veroorzaakt door onder andere diversiteit en koppeling, maar grotendeels door herhaling. In deze herhaling schuilt een groot gevaar. Allereerst omdat het werk van een softwareontwikkelaar hierdoor eentonig wordt. Anderzijds omdat deze herhaling het iteratieve aspect in gevaar brengt. Een aanpassing moet op veel plaatsen doorgevoerd worden met alle problemen van dien. Een generator kan in dit soort gevallen een goed hulpmiddel zijn. De herhaling wordt door de generator gedaan, waardoor de iteratieve complexiteit geautomatiseerd wordt.
De complexiteit op basis van koppeling tussen elementen is een punt waar een generator hulp kan bieden. Software kan beschouwd worden een soort kaartenhuis. Pas je op de ene plek iets aan, dan vallen op onverwachte plekken een aantal kaarten om. Het blijkt dat er zoveel verbanden zijn dat het beheersen van de complexiteit (door koppeling) een probleem wordt. Een generator (gebaseerd op een repository) kan in zo’n geval het beheersen van deze complexiteit door koppeling eenvoudiger maken. Deze beheerstaak wordt overgenomen door de generator. Zodra een aanpassing gemaakt wordt die inconsistentie veroorzaakt, waarschuwt de generator.
Door generatoren is het mogelijk met teams te werken waarin leden deelnemen met een verschillende kennis en expertise op het gebied van softwareontwikkeling. Het is eenvoudiger een goede taakverdeling te maken. Een aantal teamleden houdt zich bezig met het onderhouden en beheren van de generator. De andere leden ontwikkelen het inhoudelijke deel van de te ontwikkelen toepassing of houden zich bezig met genereren.
Herhaling
Een belangrijk punt van een softwaregenerator is dat hij, naast programmacode, ook andere elementen, zoals documentatie of ontwerpdiagrammen, kan genereren. Met name bij iteratief werken is het bijhouden van deze elementen zonder gebruik van een generator een tijdrovende en impopulaire klus.
Een laatste punt is de standaardisatie. Een generator zal in hoge mate kunnen aansluiten op een standaardisatie, omdat hij gebaseerd is op ‘genereertemplates’ of ‘genereerscripts’.
Generatoren hebben zoals blijkt een aantal voordelen. Hiermee wil ik duidelijk maken dat generatoren interessant zijn in elk softwareontwikkeltraject. De stelling van Van der Meulen dat je een generator gaat gebruiken als je tien keer een vergelijkbaar traject gaat volgen is volgens mij niet waar. In elk softwaretraject zit een stuk herhaling. Daarnaast is iteratief werken al een vorm van herhaling. Daarom is een softwaregenerator denk ik altijd een hulpmiddel om te komen tot betere software in een kortere ontwikkelperiode met een divers ontwikkelteam. Het maakt hierbij niet uit of je één of tien trajecten volgt.
Formele modellen
Helaas hebben softwaregeneratoren ook een aantal nadelen. Het bouwen van een generator is veel werk. Vaak ontbreekt het aan tijd en wil een opdrachtgever in korte tijd resultaat zien. Het is dan niet prettig als je halverwege een ontwikkeltraject moet vertellen dat er eigenlijk nog geen applicatie is, maar dat de generator bijna klaar is. Een generator is in dit soort gevallen een risico dat maar weinig projectmanagers durven te nemen.
Een softwaregenerator is gebaseerd op één ontwikkelparadigma. Hij kan dus één soort toepassing genereren. Het zal niet mogelijk zijn een generator te bouwen die én een administratieve applicatie én een devicedriver voor je genereert. Dit terwijl dat met de huidige programmeeromgevingen wel mogelijk is.
Rob Ronda schrijft in ‘Een andere manier van software ontwikkelen’ (Computable, 14 maart 2003, pagina 25) dat een generator behoefte heeft aan formele modellen en dat deze ontbreken. Hij slaat de spijker op de kop. Het ontbreekt aan formele modellen. Nu is het zo dat niet alleen generatoren behoefte hebben aan formele modellen; ook software-engineers hebben die volgens mij nodig. Maar mensen kunnen, in tegenstelling tot generatoren, wel software maken zonder formele modellen, al laat de kwaliteit van het eindproduct door het ontbreken van de formalisering vaak te wensen over. Het vreemde is dat de formele modellen er wel zijn, maar dat ze door de softwaregemeenschap niet gebruikt worden. De standaard modelleertaal UML is een mooi voorbeeld van een slecht geformaliseerd model waar generatoren en ontwikkelaars zich helemaal in vast werken. De UML-discussie is echter van een andere orde. De formele objectgeoriënteerde modellen zij er echter wel, denk aan methoden als Merode en Synalyse.
Een negatief punt van generatoren dat meer op het organisatorische vlak ligt is de onwil om ze toe te passen. In een traject waarbij ik een generator toepaste zag ik dat een aantal ingehuurde projectmedewerkers helemaal geen zin hadden in deze generator. Vermoedelijk om twee redenen. Het werk werd eenvoudiger, waardoor zij de status van expert min of meer kwijt raakten. De tweede reden was dat het ontwikkelen veel sneller ging waardoor zij een kortere tijd inzetbaar waren, wat de factureerbaarheid niet ten goede kwam.
Weinig realistisch
Toch denk ik dat de voordelen van een generator ruimschoots opwegen tegen de nadelen. Het maakt daarbij niet uit of het voor een 3gl of een 4gl is. Van der Meulen stelt in zijn artikel dat een generator in een 4gl minder snel te verwachten is. Daar heb ik mijn twijfels over. Generatoren hebben meer te maken met hoe je het probleem van complexiteit door herhaling, koppeling en diversiteit beheersbaar wilt maken. Dat probleem speelde in een 3gl, speelt in een 4gl en zal ook nog wel spelen in een 5gl. Waar ik Van der Meulen gelijk in geef is dat het werken in een 3gl veelal een grotere component herhaling bevat. In 4gl-omgevingen is de complexiteit echter door koppeling weer groter. Daarnaast zie je dat de behoefte aan iteratief ontwikkelen in een 4gl weer iets groter is.
In de afgelopen periode ben ik bij een aantal softwaretrajecten betrokken geweest waarbij een Case-tool als generator ingezet is. De voordelen zijn in deze trajecten volgens mij groter geweest dan de nadelen. De ontwikkeltijd werd korter, er was minder expertise nodig op het gebied van softwareparadigma’s en er was meer tijd voor het modelleren van het werkelijke probleemgebied. Als laatste punt is te noemen dat het ontwikkelwerk afwisselender werd.
Van der Meulen stelt in zijn artikel dat een markt voor 4gl-generatoren weinig realistisch is. Ik ben dat met hem eens. De nadelen die ik hierboven genoemd heb zijn hier grotendeels oorzaak van. Met name het projectrisico van generatoren staat het toepassen in de weg. Managers zullen daarom voorzichtig zijn om deze weg in te slaan. Generatorenprojecten zijn lastig beheersbaar in kosten en tijd. Daar ligt een schone taak voor de mensen die generatoren bouwen. Dat zijn de mensen met een technische achtergrond. Deze mensen zullen veelal zoeken naar de perfecte generator die de 100 procent generatie bereikt. Generatoren moeten echter gebruikt worden tot het punt waar de inzet van dit hulpmiddel efficiënt en realistisch is. Daarna mag ontwikkelen weer mensenwerk worden. < BR>
Bert Dingemans, Culemborg
