Wat is er nieuw aan Model-Driven Development?
By: Eric Jan Malotaux, 13 February 2009Toen 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.
16 February 2009 om 8:02 pm
Het is lastig om aan te geven hoeveel voordeel je kunt halen uit MDD, net als bij alle andere vormen van code generatie.
Zolang het te bouwen systeem voldoet aan de eisen van de generator, kun je veel voordeel halen (denk aan CRUD op een database), maar naar mate het systeem meer gaat afwijken op punten die niet voorzien zijn, wordt het voordeel steeds kleiner en gaan er tegelijk ook meer nadelen optreden omdat je om de gegenereerde code moet heenwerken.
Ik denk dat het heel erg verschilt per systeem, maar één ding is zeker, je hebt bij MDD veel baat bij een consistent (functioneel/grafisch) ontwerp.
Ps. Ik ben erg benieuwd naar de weblaag DSL. Het lijkt me super om simpelweg wat pagina’s en flows te definiëren zonder te hoeven denken aan irritante zeikpuntjes zoals back buttons, state management, security, REST-ful URL’s… Hoewel, aan de andere kant wil ik de generator wel schrijven, lijkt me dope.
17 February 2009 om 10:44 am
Je zorgen over de toepasbaarheid van zo’n generator deel ik. Wat dat betreft hebben we nog een hele lange weg te gaan. Denk maar aan het kunnen verwisselen van de persistentielaag (van Hibernate naar db4o) of de servicelaag (van local calls naar web services). Of het kunnen transformeren tussen domein objecten en een gegeven canonical datamodel in WSDL’s/XSD’s.
De presentatielaag DSL gaat naar mijn vaste overtuiging de grootste winst opleveren. Die kon noodzakelijkerwijs pas als laatste ontwikkeld worden, omdat die afhankelijk is van de andere drie. Ik heb grote verwachtingen van de bestaande DSL (StUIML) van Jim van Dam. Ik heb al gezien dat die heel rijk is en heel ver uitontwikkeld. Daar heeft Jim dan ook al zo’n tien jaar (denk)werk inzitten! Geweldig dat we met hem kunnen samenwerken, en dat hij StUIML nu ook echt open source gaat maken! (als Presentation Modelling Framework, PMF, geloof ik).
19 February 2009 om 5:24 pm
Je hebt niet zozeer baat bij een consistent ontwerp als je DSL’s wilt gebruiken. Het is andersom, als je DSL’s gebruikt krijg je een consistent ontwerp en dat heeft weer juist weer grote voordelen.
Ssuccesvol MDD staat of valt bij de flexibiliteit van de MDD omgeving. Vandaar dat we in Mod4j daar juist alle aandacht aan hebben gegeven. De omgeving moet mee kunnen bewegen met het project. Dat geldt zowel voor de DSL’s alsook voor de generatoren. Ook hebben we veel moeite gestopt in mogelijkheden om handgeschreven code te combineren met gegenereerde code op een wijze die hergeneratie altijd mogelijk maakt en de ontwikkelaar in staat stelt om de gegenereerde code zelfs te overschrijven. Tevens is de gegenereerde code in Mod4j zo netjes opgezet dat je op ieder moment in de tijd kunt besluiten om Mod4j te laten voor wat het is en verder met de hand te gaan werken met de gegenereerde code. Dat voorkomt dat je vastloopt in de beperkingen van MDD. Kortom je gebruikt het zolang het toegevoegde waarde heeft en stopt ermee als dat er niet meer is. Intussen heb je alleen maar winst behaald. Lijkt me een no-risk strategie.
Als je een project architectuur om wilt gooien ben je met handgeschreven code toch een stuk minder af dan met de modellen waaruit je de nieuw gewenste code kunt generen. Je moet natuurlijk wel de codegenerator aanpassen. maar dat zal meestal minder werk zijn dan alle code met de hand aanpassen.
19 February 2009 om 9:11 pm
Het loslaten van de code generatie en overgaan op het handmatig aanpassen van de code vind ik een zwaktebod. Zodra je verder met de hand moet knutselen in oorspronkelijk gegenereerde code, is het onmogelijk geworden die code nogmaals te genereren. Natuurlijk, voor het ‘eerste stuk’ heb je tijdswinst behaald, maar daarna kun je de generatoren wel weggooien. Een desinvestering dus. Dan is het nog maar de vraag of je eerder behaalde tijdwinst dat goedmaakt. Dat is alleen het geval als dat eerste stuk groot genoeg was en de generatoren weinig kosten en/of herbruikbaar zijn. Noem dat maar no-risk!
Verder ben ik het absoluut oneens met de stelling dat het aanpassen van de codegenerator om naar een nieuwe architectuur over te gaan minder werk kost dan het handmatig aanpassen van de code. In de eerste plaats zul je toch eerst heel goed moeten weten hoe de nieuwe architectuur eruit ziet. Lukraak de generator aanpassen in de hoop dat de nieuwe code daaraan voldoet lijkt me een dure bezigheid. In plaats daarvan pas je daarom eerst je referentie architectuur handmatig aan en vervolgens de generatoren. Dubbel werk dus. Het is veel goedkoper als je het in 1 keer op de code doet. Die code is dan gelijk de referentie architectuur.
Een uitgangspunt dat MDD lijkt te hebben is dat er zoiets bestaat als een referentie architectuur. Is dat wel zo? Hoe complexer het te bouwen systeem, hoe minder kans daarop, lijkt me.
En wat is nou nog ‘handmatig aanpassen’ tegenwoordig? Met een moderne IDE is het zeer goed mogelijk om code te migreren van de ene architectuur naar de andere, in gecontroleerde, geautomatiseerde stappen waarbij de IDE op ieder moment garandeert dat de code blijft werken. Flauw gezegd: met een moderne IDE ben je continu code aan het genereren. Met als voordeel dat het altijd compileert. Dat moet je van de generator nog maar afwachten…
De tot nu toe gebruikte argumenten voor MDD vind ik niet overtuigend. Diezelfde argumenten hoorden we namelijk ook al toen het helemaal fantastisch was om code uit UML te genereren. En van dat geloof is nu zo’n beetje iedereen wel afgevallen…
“Ja, maar nu is het echt zo!”
Eric Jan geeft aan grote verwachtingen te hebben in de DSL voor de user interface. Ik niet. De reden daarvoor is simpel: in de markt zie ik alleen maar het belang van de user interface toenemen. User interfaces die heel specifiek zijn toegesneden op een bepaald soort gebruiker. Dat zijn user interfaces bedacht door mensen die daar speciaal voor hebben doorgeleerd. Bekijk eens een iPhone en je begrijpt wat ik bedoel. Dergelijke specialistische interfaces zijn volgens mij niet te genereren. Helemaal niet omdat de mensen die de generatoren schrijven typisch technisch zeer goed onderlegde mensen zijn, maar vaak niks van user interfaces begrijpen. Beroepsdeformatie.
Een groot manco van MDD voor mij op dit moment is dat het zwaar is gekoppeld aan tools. Tools waarmee je moet werken. Je kunt bijvoorbeeld niet zeggen dat je Mod4J gaat gebruiken, maar dan in combinatie met een goeie IDE. Om maar een voorbeeld te geven.
Dit alles neemt niet weg dat ik best in MDD geloof. Mijn goede vrienden van JetBrains (Jos kent ze wel als ik de MPS blog mag geloven
) zijn al jaren druk bezig met hun ‘Meta Programming System’ (MPS) en hebben daarmee inmiddels ook twee van hun eigen producten ontwikkeld: TeamCity en de JetBrains Tracker. En als ik die producten bekijk dan ben ik zwaar onder de indruk.
19 February 2009 om 10:14 pm
Een zogenaamde “horizontale” DSL zoals Mod4j, waarvan het domein de architectuur is, is meer herbruikbaar dan een “vertikale” DSL, die gericht is op het domein van de eindgebruiker. Zodra de DSL en de generator gebouwd zijn, kosten ze niet veel meer. Het eerste doel is: altijd blijven hergenereren. Maar als de generator te erg zou gaan knellen, heb je een ontsnappingsmogelijkheid, omdat de gegenereerde code handmatig kan worden onderhouden als dat moet.
Mod4j is gebaseerd op een referentiearchitectuur. Die heeft z’n beperkingen, maar tegelijk ook een aantal lagen die – in principe – pluggable zijn, zodat er ook variabiliteit is. Het moet nog blijken hoever we daarmee kunnen komen. En waarschijnlijk hebben we straks een generator gebouwd voor de architectuur van vorig jaar. Dat is moeilijk te vermijden, omdat we de techniek van het maken van DSL’s en generatoren eerst onder de knie moeten krijgen. Daarna zullen we wel een inhaalslag moeten maken, omdat de referentiearchitectuur zich verder ontwikkeld heeft. De kosten daarvan zijn makkelijker terug te verdienen naarmate ze over meer projecten verdeeld kunnen worden. Voor één project is het voordeel er misschien niet of niet zo groot. Terzijde: Mod4j is tot nu toe niet duur geweest: er zit nog maar ongeveer één manjaar werk in.
Niet alle applicaties hebben een even sophisticated user interface nodig. En zelfs degenen die dat wel vereisen hebben vaak ook een aantal minder belangrijke schermen die dan weer wèl gegenereerd zouden kunnen worden.
De koppeling tussen Mod4j en Eclipse vind ik zelf jammer, maar voorlopig onvermijdelijk.
Ik denk dat MDD op basis van DSL’s alleen voordeel zullen opleveren, als we de ontwikkeling steeds goed blijven sturen. Vanzelf zal het niet gaan. Maar de kansen zijn er!
20 March 2009 om 3:34 pm
[...] Ook deze aanpak, hoewel vrij recent, is inmiddels weer uit de gratie. Zie mijn eerdere post “Wat is er nieuw aan Model-Driven Development?“. Het gebruik van DSL’s in plaats van UML helpt wel een beetje, omdat een DSL nu [...]