"Het is essentieel om in te zien dat een – initiële – probleembeschrijving iets totaal anders is dan een applicatie," stelt dr ir L. Bergemans. Het negeren van dit onderscheid veegt vrijwel de gehele software-engineering in één klap van de tafel.
De reactie van F. Twisk in het IT-discussiepunt van 23 februari op de artikelen van Gerald Kristen legt – onbedoeld – precies één van de vaak onbegrepen en onderschatte aspecten van object-georiënteerde software-ontwikkeling bloot.
Ter inleiding het volgende: beide voornoemde schrijvers betogen geheel terecht dat de aansluiting tussen de applicatie en gebruikers c.q. het probleemdomein een cruciale succesfactor is. De Kiss-methode van Gerald Kristen is met name op dit vlak succesvol. Hierbij concentreert hij zich op een type applicatie waarbij het implementatie-traject slechts beperkte uitdagingen biedt. Bestaande en nog te ontwikkelen tools moeten er zorg voor dragen dat het implementatie-traject inderdaad een vrijwel triviale bezigheid wordt, waardoor zonder grote problemen met iteraties en incrementele uitbreidingen kan worden omgegaan.
Deze filosofie heeft echter slechts een beperkte toepasbaarheid wat betreft methoden en tools, zeker bij de huidige gepraktiseerde stand van de techniek. Het is namelijk essentieel om in te zien dat een – initiële – probleembeschrijving iets totaal anders is dan een applicatie. Het negeren van dit onderscheid veegt vrijwel de gehele software-engineering in één klap van de tafel.
De suggestie van F. Twisk dat het bereiken van herbruikbaarheid en flexibiliteit bijna opgelost is wanneer het probleem helder in kaart is gebracht, gaat daarom zelden op.
Uitgaande van een volledig object-georiënteerd ontwikkeltraject kunnen we twee belangrijke stappen aangeven die een probleembeschrijving onderscheiden van een implementeerbaar en onderhoudbaar applicatie-model. (N.B. Object-oriëntatie is niet alleen een implementatietechniek. In tegendeel: OO implementeren zonder OO-analyse en ontwerp zal zelden leiden tot verbeterde herbruikbaarheid, uitbreidbaarhied en/of flexibliteit.) De eerste stap is dat het model van de probleemsituatie (het zogenaamde ‘real world model’) moet worden geherstructureerd tot een applicatiemodel. In essentie komt het erop neer dat men probeert om een stabiele structuur te vinden. Hiervoor gebruik ik meestal de term ‘analyse-architectuur’. De analyse-architectuur komt tot stand door abstractie en generalisatie op basis van domein-kennis. Het resultaat is een model waarin het ‘real world model’ keurig is gepresenteerd, maar in een structuur gegoten die stabiel blijft voor een zekere categorie van veranderingen en uitbreidingen.
De tweede belangrijke stap op weg naar een applicatiemodel heeft plaats aan het begin van de ontwerpfase wanneer de niet-functionele eisen – zoals technologische- en platformspecifieke eisen, prestatie en dergelijke – een rol gaan spelen. Ten einde met deze aspecten om te gaan, worden nieuwe softwarecomponenten aan het systeem toegevoegd. Het is nu van vitaal belang dat de resulterende ontwerp-architectuur dusdanig vorm krijgt dat deze ontwerp-specifieke componenten onafhankelijk en modulair zijn ten opzichte van het domein- en probleemspecifieke deel van de applicatie. Met andere woorden: de architectuur van het systeem kan een scala aan ontwerpaanpassingen aan zonder dat de structuur hoeft te veranderen en dus zonder het domein-specifieke deel van het model op te offeren aan implementatie-gerichte eisen.
Binnen de huidige state-of-the-art (object-georiënteerde) ontwikkelmethoden bestaat er helaas nog weinig aandacht voor de hierboven beschreven aspecten. Dit is één van de redenen dat veel OO-projecten nog slechts matig scoren wat betreft flexibiliteit, uitbreidbaarheid en herbruikbaarheid. Gelukkig is er een toenemende belangstelling zichtbaar voor domein-analyse, architectuurontwerp en hergebruik van ontwerpkennis (in de vorm van de zogeheten ‘design patterns’). In combinatie met een degelijke en interactieve vergaring van gebruikerseisen biedt dit perspectief voor zowel effectieve als efficiënte applicatie-ontwikkeling.
Dr ir Lodewijk Bergmans is zelfstandig adviseur object-georiënteerde software-engineering bij Stex te Hengelo.
