voor de restliefhebbers

Dit verhaal van Bill de hÒra (daar heb ik dus het character palette bij nodig). En ook deze.

Zijn punt: REST is niet makkelijk, maar het kan in ieder geval de vereiste complexiteit aan. Dit in tegenstelling tot SOAP etc.

Dat laatste punt is wel waar: SOAP is inderdaad heel erg simpel, maar het lsot ook vrijwel niets op.

UML + DSL

Dit is een interessante ontwikkeling. Microsoft gaat toch iets met UML doen, en zelfs op een hoger abstractie-nivo dan de DSLs. 

Ik kan me daar wel iets bij voorstellen (itt Steven Kelly), maar ik moet toch eerst even zien hoe dit werkt.

(via Jacob den Haan)

MDE en de silver bullit

Johan den Haan heeft de moeite genomen op mijn vorige post te reageren, en daar ben ik blij mee.
Hij schrijft:
"Ik denk zeker dat MDE de toekomst is. Waar ik voor pleit, wat ook in het InfoQ artikel naar voren komt, is een bredere aanpak dan alleen MDA of alleen DSLs. MDE , met DSLs als basis, heeft meer potentie. "

Ik ben het met hem eens. Wellicht zie ik meer in archtype domein modellen dan Johan, en Johan weer wat meer in "echte" DSLs, maar dat zijn minieme verschillen van inzicht. Dat gaat vooral over welke vorm een DSL moet of kan hebben, en hoe een DSL in MDE kan worden gebruikt.

Johan verder:
"Waar ik sceptisch over ben is alles wat model-driven in de naam heeft te zien als 'silver bullet'. Daarnaast denk ik dat het opzetten van een model gedreven ontwikkelstraat om enorm veel expertise vraagt, zowel op het gebied van software engineering als op het gebied van language engineering."

Inderdaad, silver bullets bestaan niet. En wat betreft die model driven ontwikkelstraat (ik ben wat minder scrupuleus als het gaat om het mengen van nederlands en engels, geloof ik :) ): inderdaad, dat is een probleem. Misschien is het zelfs wel een onmogelijke opgave.

Want om MDE (in ieder geval zoals ik dat zie) goed aan de praat te krijgen, moet aan een aantal voorwaarden zijn voldaan:
1. de generatie van executables (al of niet met leesbare code als tussenstation) moet 100% zijn. Zodra een aspect van een domein of architectuur op twee plaatsen in de stroom (bijvoorbeeld in een model en in programmacode) moet worden bewerkt, zal na verloop van tijd de bewerking alleen nog op de tweede plaats (stroomafwaarts dus) worden onderhouden. Het model wordt waardeloos en de model driven straat ook.
2. de MDE straat moet complexe domeinen aankunnen, en ook voldoende vrijheidsgraden bieden om hybride architcturen, verscheidene platforms, etc, etc aan te kunnen.

Deze twee punten vereisen dus een grote en ingewikkelde ontwikkelstraat, hoogstwaarschijnlijk slechts te bedienen door lieden die buitengewoon goed weten hoe het werkt, hoet zou moeten werken, enzovoort. Experts dus.

Maar om een aanpak als MDE (of welke nieuwe aanpak of tool voor software-ontwikkeling dan ook) met succes geïntroduceerd en geaccepteerd te krijgen, zijn er nog een paar voorwaarden:
3. de aanpak en de tooling moet redelijk bestand zijn tegen onoordeelkundig gebruik. Met andere woorden: een "foute" aanpak moet òf onmogelijk zijn, òf niet tot desastreuze resultaten leiden.
4. aanpak en werkwijze moeten te leren zijn door "gewone" software-ontwikkelaars. Liefst in een training van maximaal 5 dagen.

Vernieuwingen die een enorme expertise, training en discipline vereisen hebben de neiging te mislukken, zeker als de betrokkenen menen een simpeler alternatief (i.c. de conventionele werkwijze) te hebben. Dat laat de geschiedenis van de software-ontwikkeling volgens mij zien.

Het is duidelijk: voorwaarde 1 en 2 staan op zeer gespannen voet met 3 en 4. Ze zijn nauwelijks te combineren.

De conclusie:
MDE is alleen goed te gebruiken in situaties waarin de complexiteit van de opdracht, de vereiste snelheid van ontwikkeling, etc een aanpak als MDE noodzakelijk maakt. En de organisatie moet de consequenties (kosten tooling, eisen aan de experts, etc) dan voor lief nemen en niet toch een ogenschijnlijk goedkopere combinatie met een conventionele aanpak na te streven (met kletspraat over win-win-situaties enzo).

"Gewone" systeemontwikkeling voldoet hier maar zelden aan, dat is duidelijk. Grootschalige systeemontwikkeling, speciaal bij produktontwikkeling (product line engineering), daarentegen bieden wel mogelijkheden. En een van de effecten van SaaS en cloud computing zal zijn dat meer software op die manier gemaakt en onderhouden zal worden. Maar in de gewone systeemontwikkeling zie ik niet veel ruimte voor MDE.

Ben ik nou te cynisch?

Waarom MDE zal falen volgens Johan den Haan

Op InfoQ trof ik dit artikel aan: 8 redenen waarom MDE zal falen. MDE falen? 8 redenen maar liefst?! Hoog te paard ging ik het stuk lezen, maar het is eigenlijk een vrij goed verhaal. De schrijver, Johan den Haan, weet waarover hij praat, en zijn opmerkingen zijn blijkbaar (mede) ingegeven door praktische ervaring.

De 8 redenen zijn ook meer 8 grote risico's, en in zijn schets daarvan heeft hij wel gelijk. Ik zal ze even nalopen.

1. De gangbare MDE-aanpakken en -tools zijn vrijwel uitsluitend gericht op het korte termijn doel van verhoging van produktiviteit voor developers: meer functiepunten per uur, en verder niks.

Ja, dat is zo, en dat is inderdaad een van de grote tekortkomingen van de gebruikelijke aanpakken. Links laten liggen dus, en richten op waar het in MDE echt over gaat (vorige week blogde ik daarover ook al).

2. in MDE concentreert men zich meestal op slechts één modelleringsdimensie. Architectuur bijvoorbeeld wordt er bij de MDA aanpak een beetje bijgefrommeld in de PSM.

Inderdaad, dat lijkt nergens op. Den Haan is hier nog veel te voorzichtig: je hebt zowel binnen het domein als binnen de weergave van de technische architectuur en implementatie verscheidene modelleringsdimensies nodig.

Naar mijn idee is dat te doen met een goede modeltransformatieaanpak, maar simpel is het niet. Bovendien: hoeveel modeldimensies moeten we aankunnen?

3. de gangbare tools richten zich op het maken van nieuwe artefacten (stukken code, getransformeerde modellen, etc) en laten de problemen van aanpassing van bestaande artefacten links liggen.

Den Haan heeft hier ongetwijfeld gelijk, maar ik denk dat hij hier de zaak wat complexer maakt dan strikt nodig is. Immers, als je afgeleide artefacten 100% kunt genereren, kun je ook zelfs voor een kleine wijziging de hele zwik van (tussen)modellen, code, enzovoort gewoon opnieuw maken. Daar zitten nadelen en beperkingen aan (zoals de veteranen uit de CBD-hoek weten), maar je komt er wel een eind mee.

4. MDE richt zich teveel op General Purpose Languages zoals UML. Dat is niet voldoende: je hebt voor deelterreinen specifieke talen nodig. Het bekende DSL-lied.

Ja, dat is zo, maar ik denk wel dat in ieder geval als het gaat om business domeinen de combinatie van "gewoon" UML, analyse patronen (archetypes) en een abstractiemechanisme waarmee specifieke modellen van meer generieke patronen kunnen worden afgeleid heel veel helpt. Je kunt dan natuurlijk zo'n analyse-patroon of een bepaalde afleiding als een DSL zien.

Zie ook hier en hier en hier.

5. Zelf ontworpen DSL's zullen een chaos creëren.

Ja, dat ben ik helemaal met Den Haan eens. Voor mij is dat ook een reden om meer van archetypes gebruik te maken. Die zijn geschreven in UML, en dus veel makkelijker te begrijpen en te integreren.

6. Niet volledig executeerbare modeltransformaties zijn een bedreiging. Ja, dat is zeker zo. He treurige gehannes met PIM en PSM in veel MDA tools is daarvan trouwens een voorbeeld (Den Haan noemt het niet).

7. Modellen kunnen meestal neit of slechts zeer moeizaam op modelnivo worden getest. Dat is natuurlijk een probleem, want de enige manier om te testen is dan; eerst alles uitgenereren (aangenomen dat dat kan), en dan testen. Maar dat maakt het natuurlijk erg onhandig om zo fouten en onvolledigheden in het model op te sporen.

8. Tooling is onvoldoende. Den Haan geeft als voorbeeld de debugger die in de modelleeromgeving meestal afwezig is. En ook hier heeft hij natuurlijk helemaal gelijk.

Den Haan's conclusie is slap:
"We’ve seen eight reasons why model-driven approaches can fail to make their promises come true. It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE."

De hamvraag is natuurlijk: als die 8 risico's er inderdaad zijn (en ik denk dat Den Haan daarin ruwweg wel gelijk heeft), heeft MDE dan eigenlijk wel kans van slagen? De titel van zijn artikel suggereert dat Den Haan daarover sceptisch is, maar hij geeft zelf geen antwoord op de vraag.

En ik doe dat ook even niet, want ik kom erop terug. :)

model driven engineering: waar gaat het om?

Waarom zou je model driven engineering (MDE) willen?

Volgens mij komt het in de kern neer op 2 dingen.

1. de Model-kant: "aspecten" (of eigenschappen, of gegevens, of "business-rules", of welk interessant kenmerk van een systeem dan ook) worden op slechts één plaats beschreven, en dus ook op slechts één plaats aangepast of toegevoegd. Onderhoudbaarheid, flexibiliteit etc zijn vervolgens uw deel.

Dit klinkt makkelijk, maar is het niet. Het gaat dan om het handig toepassen van een aantal "abstractie dimensies".
Horizontale abstractie: loskoppeling "separate concerns" in aparte modellen. Dus: loskoppeling verscheidene domeinapsecten, loskoppeling verscheidene architectuuraspecten, op een hoger nivo: loskoppeling domein en architectuur, enzovoort.

2. de Driven-kant: een aanpassing van een Model-aspect wordt op slechts één plaats in het ontwikkelproces gedaan. Dus in een model, of in de code, maar niet allebei. Als het op meer plaatsen gebeurt, zal al heel snel het laatste punt waar het moet in het proces (meestal de aanpassing in de code) ook de enige zijn waar het gebeurt. En dan wordt het zo goed bedachte model heel snel waardeloos.

Overigens betekent dit niet dat het aanpassingen altijd op dezelfde plaats in het proces dienen te gebeuren. Het is wat mij betreft acceptabel als een aanpassing van een business aspect in een domein model plaatsvindt, terwijl een bepaald architectonisch aspect in een stuk code (dat is dan blijkbaar het model) moet gebeuren.

Het probleem met heel veel model driven aanpakken en tools is dat men zich concentreert op punt 2, de Driven-kant van Model Driven, en dat daarbij ook nog eens wordt gedaan alsof beschrijving in een grafisch model veel beter is dan in code. Dat hoeft lang niet altijd het geval te zijn.

Hoe dan ook: als men de Model-kant niet goed voor elkaar heeft, wordt het niks. Je moet weten wat in welke modellen wordt beschreven, hoe die samenhangen, enzovoort. In de gangbare MDA-aanpakken wordt kennelijk nog steeds gedacht dat er slechts één domeinmodel nodig is, en dat de architectuur niet apart behoeft te worden gemodelleerd. Dat is onzin, en het leidt tot mislukte projecten.

Applicaties in de cloud

Ars Technica heeft een verslag van een presentatie van Jeffrey Birnbaum, CTO van Merril Lynch. Hij denkt dat niet alleen data, maar ook de applicaties als zodanig in de cloud kunnen verdwijnen. Met andere woorden; ze runnen op een machine waar op dat moment ruimte is, en hoeven niet meer aan een server te worden toegewezen, laat staan dat ze op de client hoeven te draaien.

Klinkt als een goed plan, en ik denk dat je nog verder kunt gaan, door de "applicaties" op te knippen in kleinere componenten, met data en functionaliteit bij elkaar. En dan hebben we reizende objecten....

Computable

Sommige van mijn stukjes zullen verschijnen in het expert-panel (over SaaS) van de Computable.
Het "Boter bij de vis"-verhaal (de vorige post op deze blog) is in iets gewijzigde vorm daar verschenen.

Compleet met foto.....