Softwaregeneratie: de lijmfabriek voor componenten

1 september 2009

Applicaties worden steeds complexer. Zonder hergebruik van componenten aan de ene kant en softwaregeneratie aan de andere kant zullen we ze niet meer kunnen ontwikkelen binnen de gestelde eisen aan budget, kwaliteit en tijd. Dit artikel beschrijft de aanpak die Sioux volgt om beide werelden succesvol te combineren.

Componentgebaseerde ontwikkeling (CBD) helpt om de ontwikkeling van met name complexe, gedistribueerde systemen beheersbaar en betaalbaar te houden. De aanpak is niet nieuw en krijgt de laatste jaren ook steeds meer aandacht in de embedded-wereld. Zo heeft de Object Management Group (OMG) specifiek op realtime embedded systemen gerichte standaarden uitgebracht, zoals Realtime Corba en, meer recentelijk, Corba for Embedded. Daarnaast heeft de OMG een Corba-gebaseerde standaard geïntroduceerd voor componentplatforms: het Corba Component Model (CCM).

Het CCM definieert hoe applicaties worden samengesteld uit componenten. Daarbij beschrijft een component zijn ‘samenwerking’ met andere componenten door zowel de geboden als de gebruikte interfaces te definiëren. Hierdoor liggen de onderlinge afhankelijkheden expliciet vast. Bij aanpassingen is daardoor beter te bepalen waar in het totale systeem die wijzigingen van invloed zijn.

In het debat rondom de voor- en nadelen van CBD zit vaak een discussie besloten over welk platform of welke technologie het best is. Dat is jammer, want de essentie en het succes van de aanpak zitten niet in de technologiekeuze, maar in het architectuurtraject waarin we de functionaliteit van een applicatie opdelen in kleinere stukken en waarin we de interfaces tussen deze onderdelen bepalen. Deze cruciale stap is onafhankelijk van de technologie.

Verder is CBD alleen succesvol als alle betrokkenen bij het softwareontwikkeltraject de werkwijze accepteren. Voor architecten en ontwikkelaars moet de aanpak duidelijk voordelen opleveren, zoals een hogere ontwikkelsnelheid. Het werk mag niet alleen maar lastiger of saaier worden. Projectleiders zijn met name geïnteresseerd in het financiële aspect. Introductie van CBD vergt initieel een extra investering, die we in de vervolgfases moeten terugverdienen.

Druk op de knop

Softwaregeneratie, oftewel model-driven software development (MDSD), blijkt een goed antwoord te zijn op deze problemen. De aanpak is de afgelopen jaren in een stroomversnelling geraakt. Inmiddels zijn er diverse generatorontwikkelomgevingen beschikbaar, zoals het Eclipse Modeling Framework (EMF), MetaEdit+, Microsoft Oslo en Openarchitectureware (OAW).

Softwaregeneratie volgt een tweetrapsaanpak. In de eerste stap bepalen we welke begrippen en concepten de generator gaat herkennen (het metamodel), definiëren we de ‘taal’ waarmee we concrete instanties van deze begrippen kunnen beschrijven (een domain-specific language, of DSL) en ontwikkelen we de generator zelf. Dat doen we eenmalig. De tweede stap is het gebruik van de generator. Dit begint met het beschrijven van de gewenste functionaliteit (het model), waarna we de generator uitvoeren en de gegenereerde producten verder integreren in de ontwikkelketen. Aan het gebruik van de generator zitten geen beperkingen.

Figuur 1: Componenten en interfaces in de Messenger-applicatie

Deze aanpak maakt het mogelijk dat architecten componenten en interfaces technologieonafhankelijk kunnen beschrijven en dat ontwikkelaars zich kunnen richten op de essentiële, functionele code. De generator neemt het saaie werk voor zijn rekening en produceert zowel de noodzakelijke lijmcode, die ervoor zorgt dat componenten kunnen samenwerken met het gekozen componentplatform, als een raamwerkimplementatie van de componenten op basis waarvan we deze zelf verder kunnen ontwikkelen, onafhankelijk van het gebruikte platform. De applicatie stellen we dan uiteindelijk samen door de handmatig ontwikkelde en automatisch gegenereerde software te koppelen aan het gekozen componentplatform.

Generatie zorgt voor een substantiële vermindering in handmatig geschreven code of tekst. Dit betekent een evenredige vermindering van de kans op fouten. Wijzigingen in interfaces zijn ook gemakkelijker door te voeren. Met een druk op de knop genereren we alle lijmcode opnieuw; alleen de handmatig geschreven code moeten we eventueel aanpassen. Het voordeel van generatie neemt verder toe naarmate we de generator vaker toepassen.

Pilots

Sioux heeft met Openarchitectureware zelf een tekstgebaseerde domeinspecifieke taal gemaakt met het oog op componentgebaseerde ontwikkeling. Er bestaan weliswaar CBD-gerelateerde DSL’s, maar deze zijn meestal toegespitst op een specifiek componentplatform en niet eenvoudig in gebruik. Voorbeelden zijn Cadena en Cosmic. Zelf een DSL ontwikkelen kan kosteneffectief gebeuren en heeft twee voordelen. Ten eerste is het gemakkelijker om de domeingerelateerde concepten (het metamodel) op te bouwen en aan te passen aan de eigen behoeftes. Ten tweede kunnen we zelf besluiten in welke mate we onafhankelijk willen zijn van specifieke componentplatforms.

De eerste generator die we hebben ontwikkeld, ondersteunt Component-Integrated Ace Orb (Ciao), een CCM-gebaseerd componentplatform. Ondersteuning van andere platforms zoals Windows Communication Framework vereist enkel dat we een additionele generator ontwikkelen; de DSL zelf verandert niet. Het ontwikkelen van een extra generator vraagt relatief weinig inspanning.

Figuur 2: Deel van de modelbeschrijving van componenten en interfaces

Het gebruik van de generator begint bij het definiëren van de componenten en interfaces. Op basis van dit model produceert de generator alle noodzakelijke Ciao/CCM-artefacten, makefile-definities en scripts om de applicatie te kunnen bouwen en draaien. Daarnaast moeten we de eigenlijke functionaliteit nog handmatig realiseren. Dit komt neer op het invullen van de operaties van geboden interfaces en het invullen van de functies die de componenten aanroepen zodra ze events ontvangen. In het eenvoudige voorbeeld dat staat beschreven in het kader zorgt generatie ervoor dat we een factor zeven minder code of tekst met de hand hoeven te schrijven (de generatorontwikkeling buiten beschouwing gelaten). De kans op fouten wordt evenredig kleiner.

Onze aanpak hebben we getoetst in kleinere pilots. De eerste resultaten zijn positief. Maar we zijn er nog niet. We zullen met name nog moeten onderzoeken welke aanpassingen nodig zijn om de werkwijze succesvol toe te passen in grotere projecten. Dit kan bijvoorbeeld betekenen dat we de bestaande generator moeten uitbreiden of nieuwe generatoren moeten ontwikkelen. Verder kan blijken dat voor grotere systemen naast een tekstuele DSL ook een grafische DSL nodig is. Een grafische DSL is in feite een andere notatiewijze voor dezelfde concepten; die concepten zelf (het metamodel) wijzigen hierbij niet. Hierdoor kunnen we bij een grafische DSL de bestaande generatoren gebruiken.

Paul Zenden is softwarearchitect bij Sioux Embedded Systems in Eindhoven. Hij heeft vijfentwintig jaar ervaring in embedded-softwareontwikkeling en is momenteel verantwoordelijk voor het toepassen van CBD en MDSD in projecten bij Sioux.

Paul Zenden

Terug naar overzicht