Het bouwen van een huis met objectgeoriënteerde bouwblokken is allemaal mooi en aardig. Maar het aanbrengen van aanpassingen, rekening houdend met afwijkingen en uitzonderingen, dat is en blijft het werk van vaklieden, meent Marcel Pennock.
Laten we het bouwen van software vergelijken met het bouwen van een huis. Het zou dan fantastisch zijn een concept op te stellen en op basis van dit concept een kant en klaar product te bouwen. Het daadwerkelijke bouwen geschiedt met een generator, die daarvoor vervaardigd is. De parameters, afwijkingen, uitzonderingen en onderlinge verbanden zijn de input van de generator die het huis daadwerkelijk
bouwt. Om een goed concept neer te leggen, is een team van specialisten
nodig, ieder met zijn eigen expertise.
Ook voor het bouwen van software is dit conceptuele principe geldig. De
interpretatie van de concepten en onderliggende verbanden leidt uiteindelijk tot een model dat wordt uitgebouwd tot een voor de computer te begrijpen taal. In dat opzicht kan ik mij prima vinden in de stelling van Rob Ronda (‘Een andere manier van software ontwikkelen, Computable 14 maart).
Brug geslagen
De centrale vraag is niet hoe deze concepten te ontdekken. Een goed
afgebakende beschrijving van het eindproduct waarvoor het concept de leidraad
vormt, staat de vervaardiging van het eindproduct niet in de weg. Zolang maar vast staat wat de beoogde specificaties en doelstellingen zijn van het eindproduct, dat gegenereerd moet worden. Voor het bouwen van software op basis van zo’n conceptuele gedachte is belangrijker hoe een brug geslagen wordt tussen een voor de mens te begrijpen verhaal en de computertaal, die daar de vertaling van is.
Een software ontwikkelaar moet altijd in staat zijn de gegenereerde broncode en het model daarvan aan te passen. Dat is noodzakelijk om de nodige flexibiliteit in het ontwikkelproces te behouden. Hoe kan anders een commercieel aspect in het conceptuele ontwikkelproces worden meegenomen? Denk bijvoorbeeld aan de gui
(graphical user interface). Een fraai ogend software product verkoopt allicht beter dan een oplossing met een conventioneel uiterlijk als de saaie grijze schermen, waarmee we vaak dagelijks te maken hebben. Het is vervelend, maar ook 4gl-talen bieden in dit opzicht vaak te weinig mogelijkheden. Het aanpassen van de software tot op
het grootste detailniveau moet daarom altijd mogelijk blijven.
Technische omzetting
Natuurlijk kan het concept-team het uiterlijk van de nieuwe applicatie tot in detail beschrijven. De technische omzetting, ofwel het genereren van computertaal zal echter altijd de taak blijven van de specialist op het vakgebied. Dit geldt niet alleen voor vormgeving. Wat maakt een computerprogramma bijvoorbeeld toegankelijk, of wellicht nog belangrijker: begrijpelijk? Daarmee ben ik terug op de brug tussen concept en kant en klare syntaxis. Hoe diepgaand en specialistisch het concept ook mag
zijn, hoe kan daaruit code worden vervaardigd?
Neem bijvoorbeeld het volgende concept: ‘Het systeem moet er goed uitzien, bevat
veel lichte kleuren, werkt platform- en browser-onafhankelijk en valt eenvoudig te begrijpen voor de eindgebruiker.’ Het begrip ‘begrijpelijk’ kan niet simpel worden omgezet in computercode.
Ook de context van het concept speelt een belangrijke rol in het conceptueel georienteerd ontwikkelen. Een generator houdt bijvoorbeeld geen rekening met een veranderende organisatie, waarin sociale en politieke factoren bepalend zijn voor het welslagen van een nieuwe technische oplossing. Het succes van het ontwerpen, bouwen, realiseren en implementeren van de oplossing is puur afhankelijk van de mensen die er bij zijn betrokken. Een kleine aanpassing, aangedragen door een toekomstige sleutelgebruiker van een nieuwe bedrijfsapplicatie leidt – zo leert mijn ervaring- vaak tot een breder draagvlak voor acceptatie, ook al is de aanpassing nog zo klein. Zo’n aanpassing zou ook middenin het generatieproces aangedragen kunnen worden.
‘Automatische’ aanpassing
De objecten uit de moderne ontwikkeltalen vormen daarom de brug tussen
concept en broncode. Een aanpassing in de software kan zoals gezegd, klein
lijken. Bezien vanuit een technische invalshoek kunnen kleine aanpassingen in de broncode echter ook leiden tot het geheel herzien of zelfs herschrijven van de eerder
vervaardigde broncode. De belangrijkste vraag is hoe snel de ontwikkelaar het ontwerp kan aanpassen. De meest ideale oplossing is het ontwerp aan te passen, waardoor ‘automatisch’ de overige onderdelen of eigenschappen worden aangepast. Dit past prima in het straatje van het objectgeoriënteerd ontwikkelen: het aanpassen van de eigenschappen van een object beïnvloedt immers de rest van het objectmodel. Objecten met eigenschappen, methoden en de onderlinge samenhang zijn hapklare
technische brokken voor de ontwikkelspecialist, die altijd noodzakelijk blijft. Het is reeds vele malen bewezen dat objectgeoriënteerde applicaties snel aan te passen zijn.
Tenslotte kom ik terug op de metafoor van het ‘genereren’ van een huis. Daarbij komt immers het samenspel tot zijn recht van objecten waar iedere objecteigenschap invloed kan hebben op een ander. Mocht er later een extra verdieping op het huis geplaatst worden, waarschuwt object Benedenvloer met eigenschap Maxdraaggewicht ons dat dit niet ongestraft kan. Het fundament zal verzwaard moet worden en bovendien zijn er draagmuren nodig. Iedere objectgeoriënteerde ontwikkelaar zal zich in dit voorbeeld kunnen vinden. Het aanbrengen van de noodzakelijke
aanpassingen, rekening houdend met afwijkingen en uitzonderingen, is en blijft het werk van echte vaklieden.
Marcel Pennock, Delft
