(Meta-)modellering

 
17 augustus 2008

In de software engineering zijn we veel bezig met modelleren. Laat ik beginnen met de definitie van een model:

“Een (vereenvoudigde) voorstelling, beschrijving of nabootsing van (een deel van) de werkelijkheid”.

Zoals je ziet, veel haakjes. Dat betekent meerdere mogelijkheden, en in dit geval talloze definities. Modellen worden vaak gezien als vereenvoudiging of abstractie van de werkelijkheid. Anderen beweren dat het wel degelijk mogelijk is om te modelleren zonder te versimpelen. Ik ga er voor nu vanuit dat modellen een bepaalde (al dan niet vereenvoudigde) representatie zijn van een bepaalde domein-specifieke werkelijkheid.

Dan wellicht interessanter dan wat een model is, wat is het doel van een model? En meer specifiek, wat is het doel van modellen in de software engineering? In mijn optiek tweeledig:

1. Communicatiemiddel tussen partijen – een ‘intermediate’ taal om requirements van een bepaald systeem vast te kunnen leggen

2. Startpunt voor de implementatie van een systeem – correcte modellen kunnen vrij direct vertaald worden naar (executeerbare) code.

Tot zover weinig schokkends – dit zijn zaken waar software-engineers zich vrijwel dagelijks mee bezig houden. Overigens wel het noemen waard: deze twee doelen zijn wel tot op zekere hoogte tegenstrijdig. Het formeler en correcter maken van je model (nodig voor doel 2.) kan zeer tegenstrijdig zijn met het communiceerbaar houden van dit model (doel 1.). Hoe je tot een bepaald model komt en hoe je deze tegenstrijdigheden oplost is een discussie die ik hier niet aanhaal – daar heb ik eerder al eens over geschreven en kom ik later nog uitgebreid op terug.

De defacto modelleringsstandaard waar we tegenwoordig mee te maken hebben is UML, en dan met name UML class diagrams, use-case diagrams en sequence diagrams. Lezen van UML diagrammen is een vaardigheid die we van elke software engineer in elk geval wel vereisen, het maken ervan is vaak nog een uitdaging.
We gaan echter meer en meer naar een wereld waarin software engineers niet alleen modellen moeten kunnen maken, maar tevens modelsoorten moeten kunnen gaan definieren. Onder de term Domain Specific Languages of kortwel DSL’s wordt de modelleur geacht klassen van modellen te kunnen gaan definieren. Dit vakgebied wordt ook wel aangeduid als meta-modellering en was tot voor kort een vrij exclusief vakgebied, voornamelijk uitgeoefend door bijvoorbeeld de makers van modelleertalen als bijvoorbeeld UML (Unified Modeling Language), OWL (Ontology Web Language) of ORM (Object Role Modeling).

In feite ga je voor een specifiek vakgebied de daadwerkelijke kern vatten in een tevens meer specifieke soort van modellen. Een hiervoor uit de filosofie afkomstige veel gebezigde term is Ontologie. In feite hou je je bij metamodellering voor DSL’s dus bezig met het zodanig vatten van de kern van een bepaald domein specifiek gebied zodat je in staat bent in de gecreeerde taal valide omschrijvingen te maken van problemen in dit gebied.

Richting praktisch voorbeeld dan maar. Je kunt als je bezig bent met modelleren van een bepaald probleemdomein gaan tekenen in UML modellen, maar met de beschikbare tools die je hebt kan je al snel aan de gang door je eerste domeinspecifieke taal te gaan ontwerpen. Een eerder gebruikt voorbeeld hiervan is de snackbar DSL. Bedenk maar eens wat voor domeincode je moet schrijven om de volgende statements in scenario tests te kunnen gebruiken:

new Bestelling().
     Bestel(Patat.Groot().Speciaal()).
     Bestel(Frikandel.Gebakken().Met());

Nu is dit nog niet het mooiste voorbeeld (bezoek binnenkort ons seminar!), maar wat je met deze techniek voor elkaar krijgt is een zgn. ‘Fluent Interface’. In mijn optiek een eerste stap richting toegepaste metamodellering in de software engineering…


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags: , , , , ,


Reacties (2)

  • Jasper Stein schreef:

    Het directe verband tussen DSL’s en Fluent interfaces ontgaat me een beetje. M.i. is een Fluent Interface een handig trucje waarbij je, in plaats van een methode te schrijven die void als “resultaattype” heeft, het object zelf teruggeeft. Dus niet:
    Class Patat {
    int mayo = 0; // in centiliters
    void addMayo() { this.mayo++; return;}
    }
    maar
    Class Patat {
    Patat addMayo() {this.mayo++; return this;}
    }
    zodat je method chaining kan toepassen en dus inderdaad kan zeggen
    new Patat().addMayo().addMayo().addMayo();

    Ik zou denken dat DSL’s hier vrijwel los staan, maar het verschil tussen een DSL en een domein-georienteerde API is me niet duidelijk. Kan je daar je licht eens nader over laten schijnen?

    Geplaatst op 28 augustus 2008 om 23:49 Permalink

  • Jasper Floor schreef:

    Dit doet me denken aan iets wat men vroeger zij over programeurs:

    “Ask a programmer to solve a problem and he will give you a language perfect for solving your problem in”

    Dus meta-modeleren is mischien wel iets dat we al langere tijd doen. We missen daar gewoon wat formalismes in denk ik.

    Geplaatst op 26 augustus 2008 om 11:33 Permalink