Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 3 minutes
Op het web, op Twitter, in nieuwsbrieven, in reclame en ook in bladen als Bits&Chips komen we de laatste jaren steeds meer en steeds betere ontwikkelomgevingen tegen voor modelgebaseerde ontwikkeling, steeds vaker aangeduid als language workbenches. Blijkbaar slaat het concept aan, zowel bij ontwikkelorganisaties als bij softwareontwikkelaars zelf. Nadeel is wel – zoals altijd – dat veel aanbod veel variatie betekent in functionaliteit en andere kwaliteiten. Dat maakt de keuze voor de juiste workbench minder triviaal.
Het begint al met de keuze voor de definitie van de modelleertalen: gaan we voor grafisch, voor tekstueel of voor een mengvorm? En gaan we voor een zelfgedefinieerde domeinspecifieke taal, voor een standaard als UML of voor uitbreidingen op een programmeertaal? En wat gaan we vervolgens doen met de modellen? Documentatie schrijven bij de plaatjes of code genereren – het ultieme doel van modelgebaseerd ontwikkelen? Allemaal vragen die afhankelijk zijn van de omgeving waarin we werken en de doelen die we willen bereiken.
De keuze voor de juiste workbench was ook een veelbesproken onderwerp tijdens de Code Generation-conferentie in Cambridge vorig jaar juni. Zodanig veelbesproken dat een groep met daarin onder andere Markus Völter, Steven Kelly, Eelco Visser, Jos Warmer en ondergetekende tot de conclusie kwam dat er een vergelijking moest komen op een aantal belangrijke kenmerken van language workbenches. Medio juli lag er een conceptopdracht voor een zogeheten Language Workbench Competition. Wie daaraan wil deelnemen, moet op basis van een gegeven generieke casus op drie niveaus van complexiteit laten zien wat met een language workbench naar keuze mogelijk is.
Waar moet een workbench dan zoal aan voldoen? Allereerst moet het mogelijk zijn om structurele talen te definiëren, met daarbij ondersteuning voor correct gebruik, zeg maar ingebouwde grammaticacontrole. Met deze talen moeten modellen worden gemaakt, waaruit zonder al te veel problemen code in een gangbare programmeertaal kan worden gegenereerd – daar was het tenslotte om begonnen. Daarnaast moet het mogelijk zijn modellen op te delen in kleinere stukken die onafhankelijk van elkaar kunnen worden aangepast zonder dat de samenhang verloren gaat. Ook in modelgebaseerde ontwikkeling is de omvang van projecten en daarmee van teams en modellen groter dan de standaard ’Hello world‘-demonstratie.
In het verlengde van dat laatste kan het ook zinvol zijn om meerdere talen te ondersteunen, evenals meerdere codegeneratoren. De meeste softwaresystemen zijn nu eenmaal gevarieerd van aard – data, gedrag en onderhoud vragen elk om hun eigen taal en werkwijze. Ook integratie met bestaande programmeertalen mag niet ontbreken. Wie met modelgebaseerde ontwikkeling aan de slag gaat, begint zelden met volledig nieuwe software en wil ook niet al zijn bestaande code weggooien.
Ten slotte speelt ook continuïteit in ontwikkeling een rol. Dat betekent dat een workbench evolutie van modelleertalen en generatoren moet ondersteunen, al dan niet in combinatie met een configuratiemanagementsysteem. Ook schaalbaarheid speelt een rol: net zoals de hoeveelheid code in een systeem toeneemt van release op release, zal dat ook met modellen gebeuren – wat vervolgens weer de noodzaak introduceert om werken in teams te ondersteunen.
Of de ideale workbench bestaat, die dit allemaal ondersteunt? Ik betwijfel het, maar de Language Workbench Competition heeft inmiddels tien deelnemers die de komende weken keihard aan het werk gaan om te laten zien wat mogelijk is. Wat begon als een losse flodder bij een barbecuelunch in Cambridge heeft geresulteerd in een eendaagse workshop, een jaar na dato – op 24 mei 2011. Over de resultaten zal hopelijk nog veel worden gecorrespondeerd.
