Toen de Object Management Group (OMG) in 2001 de Model Driven Architecture (MDA) introduceerde, veroorzaakte dat een golf van optimisme onder de relatief weinigen die zich nog met code-generatie bezig hielden. Eindelijk een standaard modelleertaal(UML), en dus uitwisseling van modellen tussen tools van verschillende leveranciers. Inmiddels is het enthousiasme voor het pure MDA vrijwel helemaal weggeëbt. Voornamelijk doordat UML nou niet ideaal bleek om behalve als modelleertaal, tegelijkertijd ook te dienen als basis voor het genereren van code. Te ingewikkeld, te groot, niet precies genoeg. En die standaardisatie bleek ook meer theorie dan praktijk. Om bruikbare code uit UML te kunnen genereren moest er nogal wat aan UML gesleuteld worden, dan deed iedere leverancier weer anders. Dus zeg maar dag tegen overdraagbare modellen!

Maar de laatste twee jaar komen de ideeën in een net even andere gedaante weer terug: nu op basis van Domain-Specific Languages (DSL’s). DSL’s zijn bezig in snel tempo enorm populair te worden. Overal wordt er mee geëxperimenteerd, en de conferenties over MDD schieten als paddestoelen uit de grond.  Hiervoor zijn verschillende oorzaken: (1)  DSL’s zijn veel kleiner en hanteerbaarder dan UML. (2) Het opkomen van tools als Microsoft DSL Tools, openArchitectureWare(oAW), en vooral xText, die het zelf maken van DSL’s binnen het bereik van “gewone” ontwikkelaars hebben gebracht. Grappig genoeg zijn al deze tools uiteindelijk in gebaseerd op één of andere gedaante van de Meta Object Facility (MOF), de kern van de MDA. Dit meta-metamodel standaardiseert het ontwikkelen van nieuwe metamodellen, en daarmee van nieuwe (modelleer)talen.  (3) DSL’s komen als geroepen. De complexiteit van de gemiddelde JEE applicatie neemt zo snel toe dat weinig ontwikkelaars het kunnen bijhouden. Aan de achterkant van een applicatie – de kant het dichtst bij de database – valt het nog wel mee: Hibernate is een blijvertje gebleken, al of niet in de incarnatie als JPA-implementatie. En ook het Spring-framework blijft een rots in de branding. Alhoewel, wat is nou beter: configuratie met XML bestanden of met annotaties? En Spring groeit ook als kool: wat moeten we met OSGi en Spring Integration. Maar aan de voorkant – de kant het dichtst bij de gebruiker – is de grote lijn helemaal zoek. Een jaar of acht geleden was Struts éénoog koning, maar nu moet je voor iedere applicatie kiezen tussen JSF, Wicket, GWT, Spring MVC of Webflow, of toch maar weer een Rich Client. En dan vergeten we voor het gemak even de technologieën die tussendoor nog even populair zijn geweest, zoals XML/XSLT. Het valt niet meer te behappen voor een gewoon mens, die ’s-avonds ook nog wel eens een film wil zien in plaats van een tutorial (als dat er is tenminste) van weer een nieuw framework door te werken.

Model-driven Development op basis van DSL’s belooft een oplossing voor deze chaos. We ontwerpen een DSL voor het domein waarvoor we een applicatie maken, en een generator waar we de complexiteit in kunnen verstoppen. Daarvoor heb je dus nog wel een nerd nodig die al die ontwikkelingen wèl heeft kunnen bijbenen, maar de rest hoeft alleen maar de DSL te leren. En de nerd kan zich helemaal uitleven in de codegenerator, dus iedereen tevreden. Zou je zeggen.

Nou hebben we natuurlijk al vaker nieuwe ontwikkelingen meegemaakt die veel beloofden maar uiteindelijk teleurstelden. Object-oriëntatie, aspect-oriëntatie, agile development, test-driven development, whatever-driven-development, frameworks. Dus zo zal het met MDD ook wel weer gaan.  Toch hebben die nieuwe ontwikkelingen wel blijvende vooruitgang gebracht, alleen minder revolutionair dat we hadden gehoopt. Dus is de vraag, waarin ligt de echte verbetering van MDD, en waarin zal het tegenvallen.

Het ontwerpen van een DSL is moeilijk. Niet alleen de taal zelf, maar ook de benodigde tools om er een beetje lekker mee te kunnen werken. Dus zou het prettig zijn ‘m te kunnen hergebruiken. Daarom wordt vaak de applicatie architectuur als domein gekozen wordt in plaats van het domein van de gebruiker van de applicatie. Bij mod4j (http://www.mod4j.org/projectsite) bijvoorbeeld is dat gedaan. Maar de visie van de OMG – scheiden van pure business functionaliteit van implementatiedetails – wordt maar gedeeltelijk bereikt.  Want we moeten de applicatie specificeren in termen van de applicatie architectuur in plaats van concepten die betekenis hebben voor de klant. We maken wel modellen, maar sinds het verschijnen van tekst-gebaseerde tools als xText kunnen we die net zo goed maken in tekstuele vorm als in diagram vorm.  Wat is dan nog het verschil tussen een model en een programma?  Eigenlijk geen.  Vandaar dat Anneke Kleppe in haar nieuwe boek “Software Language Engineering: Creating Domain-Specific Languages Using Metamodels” de term “mogram” introduceert.

Wat is dan eigenlijk nieuw? Eenvoudig dit: met een DSL werkt een programmeur op een hoger abstractieniveau. Hij heeft met minder concepten te maken dan met puur Java. Dat resulteert in veel compactere code. Bij mod4j bijvoorbeeld worden er per regel DSL-code bijna 25 regels Java- en XML-code gegenereerd. Volgens Frederick Brooke in zijn boek “The Mythical Man Month” is de productiviteit van een programmeur constant in termen van het aantal statements per tijdseenheid. Mod4j is nog niet in de praktijk beproefd, dus wat de winst echt is moet nog blijken. Hoopgevend is het in elk geval wel.