Open standaarden broodnodig bij modelgebaseerde aanpak

23 juli 2010

Modelgebaseerd ontwikkelen is hot, maar anders dan bij IDE’s en compilers zijn er weinig opensource tools. Bovendien kunnen de gereedschappen die er wel zijn doorgaans niet goed met elkaar overweg. Bits&Chips vroeg verschillende softwarebouwers of dit een bezwaar is. De meningen zijn verdeeld, maar een open standaard is iets dat iedereen wil.

Modelgebaseerd ontwikkelen is ontegenzeggelijk een trend in de softwarewereld. Naarmate kennis en gereedschappen beginnen te rijpen en steeds meer ontwikkelaars met de methodes in aanraking komen, begint de aanpak in toenemende mate door te sijpelen naar het bedrijfsleven. Jonge bedrijven zoals Verum beginnen voet aan grond te krijgen, terwijl gevestigde toolleveranciers steeds meer inzetten op de modelgedreven aanpak. Vanuit de engineeringhoek positioneert onder meer Mathworks zijn gereedschappen steeds vaker als manier om software te ontwikkelen.

Modelgebaseerde of modelgedreven ontwikkeling, vaak afgekort met MDE (model-driven engineering), is eigenlijk een wat vaag begrip dat een grote verscheidenheid aan aanpakken, tools en niveaus beslaat: architectuur of algoritmes, domeinspecifiek of algemeen, visueel, tekstueel of anders en al dan niet formeel, executeerbaar of met codegeneratie. Evenzo zijn er verschillende redenen om op modelgebaseerd over te stappen, variërend van een handig hulpmiddel bij het uittekenen van de architectuur tot aan het wiskundig kunnen bewijzen dat de applicatie zich volgens de specificaties gedraagt. Wat ze echter allemaal gemeen hebben, is dat de ontwikkeling van de software naar een hoger abstractieniveau wordt getild.

De (her)ontdekking van modelgebaseerd ontwikkelen levert hier en daar wat spraakverwarring op. Stephen Mellor, een van de grondleggers van MDE, merkte ooit op dat de gedachten rond de invoer van MDE vandaag de dag veel overeenkomsten vertonen met die bij de invoering van de compiler toen assembly nog de standaard was. Een veelgehoord bezwaar is dat gebruikers nog wel controle willen houden over de geproduceerde broncode, die derhalve goed leesbaar moet zijn. Op vergelijkbare manier waren ontwikkelaars argwanend bij de invoering van de compilers die uit een hoogniveautaal genereren wat toen als code werd beschouwd.

Voortrekkers van MDE vinden dat dezelfde omslag nodig is. Programmeurs moeten niet meer denken in termen van C, C++ of Java, de modellen zijn de code. De tools compileren de modellen naar C of een vergelijkbare taal en de ontwikkelaar hoeft er vervolgens nooit meer aan te komen. Vandaag maalt ook bijna niemand nog om het bewerken van de assembly die een compiler produceert.

Het argument dat de methode interessant is, maar ‘dat mijn project te groot of niet geschikt is’, snijdt op dit moment misschien nog meer hout. Afhankelijk van het domein en toepassing staat MDE nog grotendeels in de kinderschoenen. Toch experimenteren bedrijven er driftig mee. Meestal kiezen ze voor tools van commerciële leveranciers, maar er zijn ook opensource tools beschikbaar, vooral uit de academische hoek. Bits&Chips vroeg zich af wat de beste aanpak is en ging te rade bij zijn lezers, onder meer via Linkedin.

Europese Commissie

Als we het hebben over opensource versus gesloten, kunnen we een aantal voor- en nadelen van beide aanpakken onderscheiden. Dit zijn slechts grove generalisaties; waarschijnlijk is er op elk van onderstaande argumenten wel een uitzondering te verzinnen. Omdat MDE zo’n breed gebied is, zullen we ons hier ook beperken tot algemene trends.

Ten eerste opensource. Het meest in het oog springende voordeel is logischerwijs dat de broncode open is. Gebruikers kunnen zelf de software aanpassen aan hun wensen en eisen. Missende features of bugs zijn zelf op te lossen en als de modellen niet op de gewenste wijze in code worden omgezet, kunnen zij de codegenerator aanpassen in plaats van dat ze aan het model moeten schaven. René van Hees van Thales Nederland noemt dat als een belangrijk mogelijk voordeel: ‘In onze ervaring is het moeilijk te doorgronden wat het (realtime) gedrag is van de gegenereerde code, wat resulteert in aanpassingen in het model om de juiste code er maar uit te laten komen.’ Ook maakt open broncode het mogelijk om de code voor een ander platform te genereren.

Andere algemene voordelen van opensource tooling zijn de lage kosten en de neiging van opensource om met open standaarden te werken, waardoor het gereedschap goed is op te nemen in toolketens.

Wellicht het grootste bezwaar van opensource tools is dat ze vaak nogal wat scherpe kantjes hebben en niet altijd even gebruiksvriendelijk zijn. Bugs worden doorgaans alleen opgelost als een vrijwilliger daar zin in heeft en degenen die aan de software sleutelen, zijn vaak meer geïnteresseerd in de kernfunctionaliteit dat in de gebruiksvriendelijkheid. In het verlengde daarvan is documentatie vaak schaars goed in opensource programmatuur. Alleen bij enkele projecten met voldoende kritische massa zijn kwaliteit, gebruiksvriendelijkheid en documentatie concurrerend met gesloten tools.

Bij gesloten gereedschappen zijn de software en eventuele ondersteuning direct verantwoordelijk voor de inkomsten en is er een fulltime ontwikkelteam beschikbaar om aan de tools te schaven. Dat resulteert - in relatief kleine markten als modelleergereedschap - doorgaans in hogere kwaliteit, betere documentatie en makkelijker te bedienen software. En ook belangrijk: bij het commerciële aanbod kunnen gebruikers rekenen op ondersteuning van een leverancier. Klanten kunnen de software dan wel niet zelf aanpassen, maar ze kunnen wel de leverancier vragen om dat voor hen te doen. ‘De meeste serieuze leveranciers van modelgedreven tools, zowel in het DSL- als in het OMG-domein (UML en MDA), adviseren daarom ook om zelf de codegeneratoren te schrijven en deze de code te laten genereren ‘die uw beste ontwikkelaar anders met de hand zou schrijven’’, aldus Angelo Hulshout op Linkedin. Jaap Mol, eveneens van Thales, benadrukt dat toolleveranciers best willen luisteren naar hun klanten, maar signaleert dat de afzetmarkt wel groot genoeg moet zijn om de investering van een wijziging te rechtvaardigen. Als dat niet het geval is, kan de klant alleen maar hopen dat zijn wensen op tijd worden ingewilligd.

Martin Keessen van Logica merkt ook op dat commerciële leveranciers certificering van hun codegeneratoren door instanties als de FDA kunnen verzorgen. Bij opensource is dat minder snel het geval, met als grote uitzondering het door de Europese Commissie betaalde Gene-Auto-project.  Overigens kunnen ook commerciële gesloten gereedschappen wel degelijk de mogelijkheid bieden om de codegeneratie of modeltransformatie in het algemeen te beïnvloeden - met dezelfde vragen rond certificatie. In de tools zijn bijvoorbeeld opties in te stellen rond de gegenereerde code. Maar juist bij de modelgebaseerde aanpak is er nog een optie. ‘Waar wij naar zoeken zijn tools die het metamodel beschikbaar maken en het mogelijk maken om eigen transformators te ontwikkelen’, schrijft Van Hees. ‘Deze transformatoren zijn niet erg arbeidsintensief en sluiten aan bij de eigen omgeving of architectuur.’

Consensus

Wellicht het grootste gevaar van gesloten tools schuilt in vendor lock-in, als de geproduceerde modellen specifiek zijn voor de tools van een leverancier en niet bruikbaar in andere omgevingen. Een overstap naar andere tools is daarmee welhaast onmogelijk en de klant raakt afhankelijk van de grillen van de leverancier. Dat is geen probleem zolang deze zich netjes blijft gedragen, maar als hij de prijzen omhoog gooit of bijvoorbeeld de ontwikkeling op een laag pitje zet, kan de klant in problemen komen. Ook bij een faillissement van de leverancier ontstaat een probleem, zeker als de tools een internetverbinding met de leverancier vereisen. Bij opensource gereedschappen is er in ieder geval de garantie dat ze in de nabije toekomst beschikbaar blijven - hoewel het voor kleine bedrijven flink pijn zal doen als ze zelf de ontwikkeling moeten overnemen. Het Eclipse-project voor grafisch modelleren (GMF) heeft op dit moment bijvoorbeeld geen ontwikkelaars, terwijl het de basis is voor een veelheid aan opensource grafische modelleeromgevingen.

Niet iedereen tilt zwaar aan dit gevaar van leverancierafhankelijkheid. Voor sommigen weegt het belang van formele methodes zo zwaar dat ze geslotenheid accepteren. Over het algemeen wordt het probleem echter wel onderschreven. ‘Contract weg, tool weg, geen nieuwe wegen meer van model naar code. En wat er dan gebeurt, heb ik helaas al bij diverse klanten gezien: dan maar de code met de hand gaan veranderen. Aangezien die code vaak niet wordt gegenereerd om uitgebreid door mensen gewijzigd te worden, wens ik de betreffende engineer veel succes’, schrijft Klaas van Gend van Montavista op Linkedin.

Een terugkerend thema is echter dat vendor lock-in niet een probleem van gesloten tools is maar van gesloten standaarden. Albert Mietus trekt de vergelijking naar compilers. Er is weliswaar een groot aanbod aan zowel opensource als commerciële C-compilers, maar ze kunnen allemaal Iso C aan. Waarop ze differentiëren, zijn zaken als kwaliteit van de gegenereerde code,  snelheid of ondersteunde platforms.

Op vergelijkbare manier zouden er standaard talen kunnen komen voor modelgebaseerde ontwikkeling, waar toolleveranciers dan op inhaken. Als de metamodellen, gereedschappen om de modellen op te stellen, om ze te transformeren en om ze te compileren naar een programmeertaal allemaal dezelfde taal zouden lezen en schrijven, kunnen ze ook tegen elkaar worden ingewisseld naar gelang de vraag. Al dan niet opensource. Waarschijnlijk zouden er dan meerdere talen moeten komen voor de verschillende domeinen waarvoor MDE wordt ingezet, omdat de doelen te ver uit elkaar liggen.

Die standaarden zijn er echter nog niet. Alleen voor architectuur en systeemgedrag zijn er traditioneel UML en zijn afgeleide dialecten, maar de modellen zijn slecht uitwisselbaar tussen tools. ‘Ik denk dat er nog een lange weg te gaan is voordat enige echte standaardisatie op MD-gebied zal optreden’, schrijft Mol. Mietus beaamt dat: ‘Zeker op dit moment is er nog geen sprake van een echte, open, standaard MD-taal.’ De enige manier om dat wel te krijgen, is dan ook om daar bij de leveranciers om te zeuren, zo is de consensus. Mietus: ‘Zeker door de spelers waarvoor de langere termijn belangrijk is. Vendors doen dat niet vanzelf.’

Pieter Edelman

Terug naar overzicht