'Bij product line engineering liefst zo veel mogelijk modelleren'

4 september 2009

Als consultant helpt Markus Völter veel bedrijven bij de invoering van product line engineering (PLE). In een gesprek met Bits&Chips vertelt hij hoe modellen deze tak van sport naar een hoger niveau tillen. ‘Als mensen die PLE willen gaan doen eenmaal hebben geroken aan modelgedreven ontwikkeling en domeinspecifieke talen, willen ze niks anders meer.’

‘Het komt zelden voor dat bedrijven producten ontwikkelen die elke keer volkomen verschillend zijn. Als een autofabrikant elk model totaal anders zou bouwen, zou dat een lieve duit kosten. In plaats daarvan combineert hij massaproductie met enige vorm van voorgedefinieerd maatwerk. Hetzelfde geldt voor makers van mobiele telefoons. Ook zij hebben te maken met productfamilies die onderlinge overeenkomsten hebben, bijvoorbeeld in het gebruikte besturingssysteem of display, maar die tegelijk ook variëren.’

Deze wereld van gemeenschappelijkheid en variabiliteit is het domein van product line engineering (PLE), verklaart Markus Völter. De 35-jarige Duitser is een goeroe op het gebied van softwarearchitectuur, modelgedreven softwareontwikkeling en domeinspecifieke talen, drie disciplines die samenkomen in PLE. ‘PLE is het creëren van softwaresysteemfamilies die gelijkenissen vertonen maar ook welgedefinieerde verschillen. Hierbij gaat het erom een gemeenschappelijk platform te ontwerpen voor de producten en vervolgens hun onderlinge variabiliteit systematisch te managen. Doel is om daarmee de time-to-market te verkorten en de ontwikkelkosten te verlagen.’

Markus Völter

Niks anders meer

Völter onderscheidt twee vormen van variabiliteit: configuration variability en customization variability. ‘Bij configuratie is er een beperkt aantal parameters die een beperkt aantal waardes kunnen hebben en het is aan de ontwikkelaar om de juiste waarde te selecteren. Een veelgebruikte configuratiemethode is featuremodellering, waarbij de variatie wordt uitgedrukt in features die een product wel of niet kan hebben. Bij customization is het aantal mogelijkheden onbegrensd en moet de ontwikkelaar een algoritmische beschrijving creëren om de variatie te vatten. Dat gebeurt typisch in een domeinspecifieke taal, waarmee dan bijvoorbeeld een toestandsdiagram wordt gemaakt.’

‘Als je je product kunt opbouwen door ja-neevragen te beantwoorden, dan is het configuratie. Als je gedrag moet specificeren, dan is het customization’, simplificeert Völter. ‘Bij een auto zijn de keuzes voor een kleine of een grote motor, wel of geen sportstoelen, wel of geen brede banden bijvoorbeeld gevallen van configuratie, terwijl de keuze voor de lak een geval is van customization. Door een domeinanalyse te doen en na te denken over hoe je de variabiliteit van een product beschrijft, dus hoe het zich verhoudt tot de hele productlijn, kom je er snel genoeg achter of je te maken hebt met configuratie of customization.’

De twee sluiten elkaar echter niet uit, zoals ook het autovoorbeeld laat zien. ‘Historisch zijn het twee verschillende werelden: de PLE-gemeenschap denkt typisch in termen van selectie, configuratie dus; de modelgedreven gemeenschap denkt typisch in termen van creatie, customization dus. Er zou echter geen verschil moeten zijn. Wat ik wil duidelijk maken, is dat beide werelden heel goed zijn te combineren. Sommige variabiliteit is te vatten in configuratie, andere variabiliteit in customization. Sommige dingen zijn het best uit te drukken met featuremodellering, andere zijn het best te representeren met domeinspecifieke talen.’

De combinatie is nog verder door te voeren. ‘Configuratie is niet alleen te gebruiken om parameters in te stellen, maar ook om modellen te veranderen’, licht Völter toe. ‘Voor elke feature die je niet selecteert, vervalt er een aantal toestanden in je toestandsdiagram. Zo komen configuratie en customization samen, wat alles een stuk simpeler maakt. Een domeinspecifieke taal is beknopt, exact en high-level.’

Welke vorm de variabiliteit ook heeft, modellen spelen een cruciale rol bij PLE, vindt Völter. ‘De beste manier om aan product line engineering te doen, is zo veel mogelijk modelleren. Dat kan met featuremodellering of andere configuratiebenaderingen, en als die niet expressief genoeg zijn, met domeinspecifieke talen. Daarmee kun je elke variant maken die je maar wilt. Als mensen die PLE willen doen eenmaal hebben geroken aan modelgedreven ontwikkeling en domeinspecifieke talen, willen ze niks anders meer. Het is een natural fit.’

Dat grafische spul

Als de variabiliteit eenmaal op een hoog niveau staat beschreven, is de volgende stap om tot low-level code te komen. Daar zijn verschillende manieren voor. Völter: ‘Een mogelijkheid is om in het compilatieproces alleen die stukken code mee te nemen die horen bij een geselecteerde feature. De preprocessor van C en C++ biedt hiervoor bijvoorbeeld de ifdef-constructie. Met methodes als designpatronen, objectoriëntatie of reflectie zijn features runtime te configureren in een product. Dat kan dynamisch of statisch. In bedrijfsomgevingen is dynamisch oké, omdat codeomvang en performance er daar minder toedoen. In embedded systemen doe je het doorgaans statisch, omdat je het efficiënt en klein wilt houden.’

Bij het gebruik van modellen ligt automatische codegeneratie voor de hand. Volgens Völter zijn de twee zelfs onlosmakelijk met elkaar verbonden. ‘Modellering zonder codegeneratie is zinloos. Waarom zou je een model maken als je geen geautomatiseerde methode hebt om te garanderen dat de implementatie in je systeem overeenkomt met dat model? Een handmatige implementatie kan allerhande fouten introduceren. Dan heb je weliswaar een correct model, maar wat je wilt, is een correct systeem.’

‘Zeker voor embedded systemen is het zinnig en haalbaar om grote delen van de code automatisch te genereren, bijvoorbeeld alle hardwarespecifieke stukken, de busprotocolafhandeling en de componentstructuur. De relatief simpele business logic kun je vervolgens handmatig implementeren tegen de gegenereerde Api’s. Ideaal zou zijn als je alles automatisch kunt genereren. Maar geen man overboord als dat niet gaat. Dan genereer je bijvoorbeeld een basisklasse en implementeer je de rest handmatig in abstracte methodes in een subklasse.’

Als belangrijkste ontwikkelomgeving gebruikt Völter zelf het modelgebaseerde opensource pakket Openarchitectureware (OAW). ‘Ik probeer geen toolconsultant te zijn’, benadrukt hij. ‘Ik pin mij dan ook niet vast op één tool of benadering, maar houd mijn ogen open. Op dit moment werk ik met OAW, een geïntegreerde omgeving die alle aspecten van modelgedreven ontwikkeling bestrijkt. Je kunt modellen bouwen en transformeren, metamodellen definiëren, je eigen talen maken, constraints checken, code genereren – allemaal met een verzameling van gereedschappen die heel goed op elkaar zijn afgestemd.’

Een van de OAW-tools is XText. ‘Dat is een framework om gemakkelijk tekstuele domeinspecifieke talen te bouwen, met goede editors die bijvoorbeeld code completion en syntax highlighting bieden. Ik modelleer voornamelijk in tekst, omdat dat grafische spul in veel gevallen te weinig uitdrukkingskracht heeft. De tekstuele tools worden steeds beter, zodat het ook steeds haalbaarder wordt om grote delen van je systeem te ontwikkelen in een domeinspecifieke modelleeromgeving.’

Echte projecten

In zijn dagelijkse werk als consultant stuit Völter echter nog regelmatig op vooroordelen over het gebruik van modellen. ‘UML is niks, hoor ik dan, dus modelgedreven engineering kan ook niks zijn. Mensen denken dat je alleen modelgedreven kunt werken met UML. UML is goed om softwarestructuren mee te beschrijven - daar is de taal ook voor bedacht -, maar niet geschikt voor softwarearchitecturen, businessprocessen of domeinspecifieke entiteiten. En het hele punt van een modelleertaal is toch dat je wilt dat je modellen nauw aansluiten op je businessdomein. In plaats van UML in een keurslijf proberen te persen, is het veel productiever om je eigen domeinspecifieke taal te bouwen. Met de moderne tools is dat ook stukken makkelijker. Ik gebruik UML alleen nog om objectgeoriënteerde softwarestructuren te communiceren, waar het voor is gemaakt, en om toestandsdiagrammen te modelleren, want de taal heeft goede state charts.’

Een volgend vooroordeel duikt op als Völter bij ontwikkelaars begint over tekstuele modelleertalen. ‘Grafisch is toch veel eenvoudiger te begrijpen, zeggen ze dan. Ook klinkklare onzin. Een taal is gemakkelijker te begrijpen als hij nauw aansluit op je domein. Dan maakt het niet uit of hij grafisch of tekstueel is. Natuurlijk, sommige dingen zijn beter grafisch te representeren, maar dat is de minderheid. De meeste dingen zijn beter tekstueel uit te drukken.’

Een ander veelgehoord bezwaar tegen modelgedreven ontwikkeling is dat de code gegenereerd uit modellen onleesbaar, onbegrijpelijk en opgeblazen is. ‘Als je je eigen codegenerator bouwt, heb je dat helemaal in eigen hand. Met een taal die nauw aansluit op jouw domein en een generator die je volledig onder controle hebt, is het je eigen schuld als je code lelijk, langzaam en te groot is.’

Modelgedreven engineering is de initiële hype voorbij, stelt Völter. ‘Sommigen zijn teleurgesteld afgehaakt, maar de modellenaanpak zit nu op een punt waar de ontwikkelingen serieuze vormen aannemen. De laatste twee, drie jaar is er veel veranderd: de tools zijn schaalbaar geworden, je kunt er echte projecten mee doen.’

Dat maakt de benadering beter te verkopen. ‘Technisch gezien is het sneller. Een tijdje terug heb ik een project gedaan met een Nederlandse verzekeraar, waarbij we geavanceerd domeinspecifiek gereedschap hebben gebruikt om pensioencontracten te modelleren en automatisch Java-code te genereren voor calculatieprogrammatuur. Wat het bedrijf anders een maand had gekost, hebben wij in drie dagen gedaan. Zo ken ik tal van voorbeelden. De technici in een organisatie heb ik doorgaans in een dag overtuigd.’

Extreem productgericht

Desondanks strandt de invoering van (modelgedreven) PLE nog te vaak, tot frustratie van Völter. ‘Met verschillende klanten heb ik een echt zinnig technisch prototype gemaakt. Zelf zijn ze ook enthousiast over hoe goed en snel het werkt, maar vervolgens lukt het dan niet om de benadering te integreren in hun dagelijkse manier van werken. Het brengt toch wel wat veranderingen met zich mee: je moet standaardiseren op modelgebaseerde tools en de bijbehorende documenten en methodes, en je moet bijvoorbeeld formeler gaan denken om een taal te kunnen definiëren. Dus hoewel PLE technisch heel veel voordelen biedt, staat de organisatorische omgeving een succesvolle introductie nogal eens in de weg.’

‘Het probleem speelt vooral bij bedrijven die extreem productgericht zijn. Daar ontbreken vaak het budget en de organisatiestructuur om zoiets als frameworks of generatoren te bouwen die bruikbaar zijn in meerdere producten en projecten. Dan is PLE heel moeilijk in te voeren omdat iedereen alleen naar zijn eigen directe omgeving kijkt. Als je PLE efficiënt wilt doen, dan moet je een organisatie opzetten die kan denken en handelen over producten en projecten heen.’

Nieke Roos

Terug naar overzicht