Modellering: structure-first vs behavior-first

 
15 maart 2009

Softwarebouw start vaak met een vertaling van klantspecifieke omschrijvingen naar een meer ‘algemeen leesbaar’ model. Vaak wordt voor deze modellen gekozen voor één of meerdere onderdelen van UML. 

UML heeft een indeling in structuurbeschrijvende modelsoorten en gedragsbeschrijvende modelsoorten. Software engineers (waaronder ikzelf) neigen ernaar om samen met klanten te discussieren over structurele modellen. Vaak wordt hier het UML class diagram voor gebruikt. Dit levert vaak wel abstracte modellen op die door niet-OO mensen (waar er toch meer van zijn dan wel-OO mensen) niet of nauwelijks geverifieerd kunnen worden.

Een manier van verifieren van deze modellen kan gedaan worden door er een gedragsmodel ‘overheen’ te leggen. Na de structuur in kaart gebracht te hebben kan je samen met een domeindeskundige een bepaald proces (vaak een ‘use-case’) omschrijven en vervolgens deze als sequence loslaten op je structurele model. Hoe dat gedaan wordt, en hoe je andersom kunt werken (dus eerst de gedragselementen benoemen en daar vervolgens de structuur uit destilleren) zullen Rick van der Arend en ondergetekende dinsdag a.s. tijdens ons seminar kort aanstippen.

Moet je altijd deze keuze maken als je een model maakt voor een klant? Collega Rob Vens heeft meermalen een methode gepresenteerd (eXploratory Modelling) waarin je beide tegelijk samensteld. Ik denk dat deze manier van werken een groot voordeel kan bieden, echter moderne modelleringstools lijken hier nog niet klaar voor…


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development