Metapatroon voor variëteitsborging in modelgedreven ontwikkeling

Pieter Wisse

prioriteit: opheffing van valse start

Met Specificaties komen vaak te laat geven T. Van Velzen en T. Schoots een inleiding tot zgn. modelgedreven (computer)programmatuurontwikkeling.1 Ik vermeld maar direct mijn vrees dat een redacteur van het populaire vakblad — want kan dat wel samen, professioneel en populair? — waarin hun artikel verscheen, die titel bepaalde. Na op z’n gunstigst  een oppervlakkige beoordeling heeft zij of hij het dan toch slecht begrepen.

Ja, de auteurs wijten beperkte toepassing van modelgedreven programmatuurontwikkeling mede aan valse haast. Zij stellen dat programmering (lees ook: implementatie) vaak reeds gaande is, terwijl de modellen (ofwel, specificatie) nog niet beschikbaar zijn. Dat gat valt inderdaad niet meer netjes te dichten. Mijn eerste eigen vraag — klopt, een retorische — is even wat voor nut modellering überhaupt heeft, wanneer voor programmering ruimte bestaat voor dergelijk ònafhankelijk verloop. Dan let iemand erg slecht op, maar goed. Ik kom er verderop onder de noemer van cyclus nog op terug.

Het is natuurlijk ook niet zo dat programmeurs helemaal niet ontwerpen. Het punt van Van Velzen en Schoots — ik (be)noem ze verder kortweg als V&S — is dat programmeurs dat vaak in isolement doen, dus

vanuit één dominant perspectief, en wel dat van derdegeneratieprogrammeertalen.

Daar gebeurt het tevens grotendeels impliciet, wat natuurlijk ook niet helpt. Programmatuurontwikkeling kan echter per definitie pas modelgedreven zijn, zodra expliciete modellen opgesteld zijn. Want één of meer modellen drijven ontwikkeling van programmatuur in de zin dat, zo luidt de aanzet van V&S,

delen van de implementatie uit de specificatie door een automatisme worden afgeleid.

Nogmaals, in dat verband vormt een model dus blijkbaar — een gedeelte van — de specificatie; de resulterende programmatuur geldt als de implementatie ervan.

In dit opstel besteed ik verder geen aandacht aan de eventuele praktijk van stagnerende modellering in wanrelatie tot overhaaste programmering. Dat heeft pas later (weer) nut. Want waarop (ook) het artikel door V&S wijst, is hoezeer allereerst praktische theorie nog ontbreekt juist voor — wat zij volgens mij bedoelen met — conceptuele modellering.
Via commentaar op enkele passages uit hun artikel probeer ik te verduidelijken dat de gangbare voorstelling van modelgedreven programmatuurontwikkeling nog, nota bene, fundamenteel mank gaat aan een overmaat aan versimpeling. Vanuit overdreven reductionistische aannames is het ook logisch dat conceptuele modellen een serieus gebrek vertonen aan zgn. passende variëteit. V&S vatten wat mij betreft het primaire vraagstuk treffend samen:

[D]e uitdrukkingskracht en de hulpmiddelen ontbreken om abstract en toch volledig precies te specificeren.

Met zo’n valse start is tevens geen enkel automatisme denkbaar, laat staan reeds operationeel beschikbaar, dat programmatuur kan afleiden (lees ook: zonder menselijke tussenkomst volgens regels opstellen) die passend werkt in de feitelijk complexer-dan-veronderstelde werkelijkheid. Tenslotte leidt daarom mijn opbouwende bedoeling met zulke kritiek, dus niet zozeer op het artikel door V&S, maar algemeen, tot een verwijzing naar metapatroon.2 Dat is een methode voor conceptuele modellering die uitgaat van enkele principieel gewijzigde aannames over werkelijkheid èn — als onlosmakelijk onderdeel — het gedragspotentieel van digitale technologie. Het is dus gelukkig niet langer zo, dat gevarieerde uitdrukkingskracht ontbreekt. Het kost echter wel moeite met metapatroon vertrouwd te raken. Dat komt omdat wijzigingen, zoals gezegd, principieel zijn. Extra moeilijk is vooral àfleren; het kan (ook) vaak enige tijd duren voordat iemand de oorzaak van mislukking terecht zoekt in belemmerende aannames.

 

 

gedestilleerd referentiekader

Voordat ik verder aanknoop bij passages uit het artikel door V&S, doe ik een poging hun referentiekader te destilleren. Mijn indruk is dat ze twee dimensies opgespannen hebben. De ene dimensie, hier in mijn schets is dat de horizontale as, vertegenwoordigt het proces van programmatuurontwikkeling. Langs die dimensie plaats ik wat zij

verschillende activiteiten en disciplines van software-ontwikkeling

noemen. De tweede dimensie, hier dus de verticale as, bezet ik dan met hun

toepassingsgebieden.

De auteurs laten zich niet uit over de, zeg maar, configuratie van ontwikkelactiviteiten en –disciplines. In hun populaire inleiding is dat ook zeker geen gemis. Maar zo’n schema zou als het ware overzicht over de al dan niet automatische transformaties bieden, vanaf het allerabstractste model tot en met de allerconcreetste programmamodule. Daaruit zou ook blijken welke paden herhaalbaar zijn, wat dus aangeeft in hoeverre bepaalde activiteiten cyclisch aan bod — kunnen — komen. Een dergelijk configuratieschema zou ook moeten laten zien welke alternatieve paden van activiteiten bestaan. Bijvoorbeeld, is het mogelijk een activiteit over te slaan? Is er dus ook een automatisme dat activiteiten combineert? Trouwens, als het toch allemaal volgens een automatisme verloopt, waarom is er niet gewoon een ènkele startactiviteit waarop, inderdaad, automatisch, direct het bijbehorende (eind)resultaat volgt?

Dergelijke vragen zijn wezenlijk, maar graag vermeld ik in diplomatieke termen dat ik in navolging van V&S abstraheer van details. Dat levert langs de ontwikkeldimensie, horizontaal dus in mijn gedestilleerd referentiekader, een nader te bepalen verzameling activiteiten op in een nader te bepalen samenhang, ongetwijfeld à la netwerkplanning.

De toepassingsdimensie (hier: verticaal) is er om te laten zien dat er weliswaar gebieden annex domeinen zijn met intern overheersende overeenkomsten, maar dat toepassingen binnen één enkel domein desondanks nog apart tot stand komen. In figuur 1 zijn zulke gescheiden ontwikkeltrajecten/-projecten aangeduid met aparte lijnen pèr domein.

Figuur 1: Referentiekader voor hergebruik (mijn interpretatie van Van Velzen en Schoots).

 

 

 

ànders: het ding als verzameling van situationele gedragingen

Langs de horizontale as staat dus de verzameling ontwikkelactiviteiten {a1, …, ar} opgesteld, nota bene (ook hier) abstraherend van veranderlijke samenstelling (welke activiteiten precies) èn structuur (hoe hangen ze precies samen). De stelling van V&S luidt, hier enigszins vertaald opgenomen, dat zulke activiteiten vergaand autonoom door bijbehorende disciplines ondernomen worden. Zij noemen dat

het probleem van interdisciplinair hergebruik.

De aparte disciplines (h)erkennen niet

de overeenkomsten tussen ontwerp en code,

zeg maar weer tussen model (specificatie) en programmatuur (implementatie). V&S poneren dat elke discipline voor elke activiteit

telkens opnieuw, maar vanuit een iets andere invalshoek, uit[drukt] uit welke logische delen het systeem bestaat, en hoe het systeem zich gedraagt.

Daardoor, met andere woorden,

worden in wezen dezelfde dingen telkens vanuit een ander perspectief opnieuw beschreven.

Met verwijzing naar een ding met zijn wezen belijden V&S nogal impliciet hun ken- annex werkelijkheidsprincipes. Het lijkt aanvankelijk een Platoonse zienswijze. Zo maakt elke discipline voor een bepaalde activiteit blijkbaar ‘slechts’ een eigen projectie van dat zgn. absolute ding.

Sterker nog, het projectieve karakter is onvermijdelijk. Het wezen, althans volgens diezelfde Plato, moet onbereikbaar blijven voor inherent beperkt kenvermogen. Het is dus de vraag of V&S onderweg niet smokkelen met hun uitgangspunt. Het lijkt er toch sterk op, dat zij de oplossing voor

het probleem van interdisciplinair hergebruik

zoeken in de vaste greep op het dingige wezen. Wie dat immers te pakken krijgt, kan afleiden tot ongeacht welke verschijningsvorm. Dat is echter tegelijk ontkenning van Plato’s kennisleer.

De oplossing volgens metapatroon bestaat eruit om niet louter eenzijdig te hameren op wat intuïtief wordt ervaren als

dezelfde dingen.

Het is doorgaans inderdaad pragmatisch optimaal om diverse verschijningsvormen tot één en hetzelfde ding te herleiden. Dat betekent echter allerminst dat er een wezen bestaat dat zulke verschijningsvormen, en méér, praktisch inkapselt. Nota bene, het is precies àndersom.

De sleutel tot gewijzigde aannames is het nemen van afstand tot de term verschijning (of, thans gemeengoed voor objectgerichtheid, rol). Van verschijningsvorm gaat immers sterk de suggestie uit, dat het slechts een oppervlakkig resultaat betreft van een allesbepalende kern. Dat is dan het veronderstelde wezen van het ding.

Het beeld verandert, als ik me een woordspeling veroorloof, wezenlijk door niet langer over verschijning/rol te spreken, maar over gedrag. Inderdaad, voor allerlei dingen — wanneer zoiets als het ene ding toch als brandpunt van continuïteit in veranderlijkheid gehandhaafd blijft — geldt dat ze soms uiterst gevarieerd gedrag vertonen. Stel dat het ding <X> het aantal van <n> verschillende gedragingen heeft. Nu dringt de vraag zich duidelijker op, wat een specifieke gedraging, dus één uit die verzameling van <n> elementen, veroorzaakt. Is dat helemaal een zaak van ding <X> zèlf, dus volkomen autonoom?

De sociale psychologie heeft inmiddels het inzicht opgeleverd dat een bepaald ding tot specifiek gedrag komt overeenkomstig de specifieke situatie die het ervaart op enig moment. Dat verband is zelfs onlosmakelijk evenredig. Ding <X> heeft nu eenmaal <n> verschillend gedragingen, omdàt het <n> verschillende situaties kan ervaren, vice versa. Wat volgens deze aannames wezenlijk is, betreft daarom niet zozeer de tot één ding gebundelde gelijkheid, maar de ontlede gedragsverschillen. Kortom, voor het ene ding is zijn variëteit aan gedragingen wezenlijk. Tot dat wezenlijke behoort tevens dat situaties differentiëren in ruimte-tijd. Of, om het in relatie tot de aanzet door V&S te verduidelijken, het gedrag in de ene situatie is principieel ònafleidbaar uit — lees hier ook: is nooit vollédig bepaald door — het gedrag dat geldt voor enig andere situatie. Dit is volstrekt in tegenstelling met afleiding zònder extra aanwijzingen, in het bijzonder door een automatisme. Want alweer per definitie geldt voor de mogelijkheid van compleet ‘gesloten’ afleiding dat onderscheid naar afwijkende situaties òngeldig is.

Is hiermee modelgedreven programmatuurontwikkeling finaal onderuit gehaald? Allerminst, maar het is wel zo dat modelgedreven verband anders opgevat moet worden. Situaties hebben via gedifferentieerd objectgedrag wel degelijk relaties. Maar voordat ik daaraan toekom, onderwerp ik eveneens de andere beschouwingdimensie van V&S, die van de toepassingsgebieden annex bedrijfsdomeinen, aan een analyse.

 

 

ook ànders: universeel bereik voor (her)gebruik

Voor de verhouding tussen toepassingsgebieden geldt hetzelfde als wat V&S — niet — in hun inleidend artikel opnemen over ontwikkelactiviteiten en –disciplines. Zij maken opnieuw geen opmerkingen over onderlinge relaties. Als ik erin meega me hier voorlopig tot dat algemene niveau te beperken, meen ik op te maken dat V&S zo’n domein opvatten als een, zeg maar, uniformiteitpotentieel. Ze maken melding van

[a]lgemene domeinmodellen

op een manier waaraan ik hun suggestie overhoud dat zulke modellen in hun algemeenheid wel degelijk geldig zijn. Het zal dus wel zijn dat zij betreuren, dat

[a]lgemene domeinmodellen […] maar zelden gebruikt [worden], hoewel er binnen een familie van toepassingen toch veel overeenkomsten en raakvlakken zijn.

De aldus gemiste kans van

conceptuele overeenkomst […] kan gekarakteriseerd worden als het probleem van intra-domein hergebruik.

Wat ik hierboven aan commentaar gaf op afleidingsverband tussen ontwikkelactiviteiten, past ook hier. In dit geval wijkt slechts de schaal af, waarop ik gedrag als verbijzonderd beschouw. Wanneer V&S hun begrip van domein zelfs hetzelfde bereik toedichten als wat ik in navolging van sociale psychologie over een aparte situatie vind, zie ik eigenlijk geen relevant verschil. Het is dan echter wel zo dat, met domein vervangen door situatie, het probleem van intrasituationeel hergebruik simpelweg verdampt. De verklaring is dat er binnen één enkele situatie weer per definitie geen gedragsvariatie bestáát. Want als die er wèl zou zijn, tellen volgens diezelfde definitie blijkbaar niet één, maar twee of méér relevante situaties.

Voor (her)gebruik is de maatvoering volgens een toepassingsgebeid annex bedrijfsdomein veel te ruim. Als ik in filosofisch oogpunt daarvoor een bron aanwijs, kom ik uit bij het idee van een taalspel dat Wittgenstein opperde. Tegenwoordig wordt op z’n Engels met een community of practice hetzelfde bedoeld. Dergelijke domeinen benadrukken juist weer te véél het verschil, dat wil zeggen te grofmazig. Ja, er liggen verschillen ten grondslag aan het aanwijzen van afwijkende taalspelen. Maar op die schaal blijft gedetailleerd gedrag meestal talloze overeenkomsten vertonen. Met een praktijk uit de rekenkunde als metafoor geldt voor dat stadium dat de ontbinding in (gedrags)factoren nog niet de limiet van eenduidigheid bereikte. Het komt erop neer dat binnen zowel domein <A>, als domein <B> het gedrag kan spelen van ding <X> volgens situatie <n>. Het beperkt daarom nodeloos om

conceptuele overeenkomst

slechts pèr domein te benutten. Op ruimere schaal zijn er vaak verassende kansen voor hergebruik. Zo wijst analogie op gelijke structuur. En via abstractie is specifiek gedrag mede het resultaat van variabele aansturing.

De paradox lost gemakkelijker op door juist op ruimst dènkbare schaal te speuren naar eenduidige (gedrags)situaties en die zijn naar hun aard doorgaans juist sterk beperkt van reikwijdte. Zo lost de paradox van klein- in combinatie met grootschaligheid op in relevante éénduidigheid.

V&S hikken er nog tegenaan in hun analyse van obstakels voor modelgedreven programmatuurontwikkeling. Zo stellen zij:

Het generieke karakter van een component is vaak verweven met de toepassing in een concrete situatie.

Wat zij nog als probleem ervaren, blijkt dankzij radicale gedragsverbijzondering volgens situaties nu net … de oplossing. Een bepaalde component verschaft voorschrift voor actief (dynamiek: instructies) en/of passief (statiek: eigenschappen) gedrag. Als zo’n voorschrift geldt een component pas werkelijk generiek vanwege, nota bene, bepèrking tot een bepaalde situatie. Met andere woorden, eenduidige verbijzondering tot een specifieke situatie is zelfs voorwaarde voor generiekheid! Daardoor is zo’n component generiek beschikbaar ter eventuele aanvulling e.d. van gedrag elders, dus van enig ‘ding’ in een àndere situatie. Daarom kan metapatroon bijvoorbeeld (ook) worden opgevat als synthese van object- en aspectgerichtheid.

De praktische behoefte aan ‘open’ schaalbaarheid van eenduidige gedragsbepaling is overigens pas recent manifest geworden. Dat gebeurt door technologische ontwikkeling, waardoor voorheen aparte hulpmiddelen voor informatievoorziening voortaan wereldwijd geschakeld kunnen gaan werken. Het aanvankelijke conceptuele modelleringparadigma, dat wil zeggen voor gescheiden informatiesystemen zonder semantische complicaties,3 blijkt voor het onvermijdelijk gemengde informatiestelsel onvoldoende variëteit te waarborgen. In het mengsel vergt eenduidige beheersing van variabele betekenissen annex gedragingen domweg extra maatregelen. Dat komt neer op toevoeging van situationele aanduiding.

Voor wie gewend is aan — modellering van — een object met zijn rollen (Engelstalig: object/role modeling), zit het primaire verschil in erkenning van gedragsbepalende factoren buiten, herhaal, buiten het object. Onder de noemer van specifieke situaties moeten voortaan zulke externe factoren eveneens eenduidig in het informatiestelsel opgenomen zijn. Zolang ze daar ontbreken, kan in het totale mengsel ònmogelijk een gerichte selectie van een ‘component’ gebeuren.

 

 

situationele drijfveer

Toon mij uw situatie en ik vertel u uw gedrag. Wat daarom telt voor modeldrift, is de eenduidigheid met precisie die de — beperking tot een — specifieke situatie afdwingt. Het doet er dan niet toe, of het in retrospectief gaat om een gedragbèschrijving danwel proactief om een vóórschrift voor gedrag. Situationeel gedreven stáát er dan een ondubbelzinnig gedragsmodel.

Nota bene, wat zo’n model voorschrijft is gedrag door gereedschap(pen) voor informatievoorziening. (Pas) wanneer het modelleerformalisme het gedragspotentieel van gereedschap(pen) niet overstijgt, kan feitelijk gereedschap volgens een passend automatisme afgeleid worden van feitelijk model. Onder deze voorwaarde is afleiding natuurlijk direct mogelijk, dus zònder tussenstap(pen) voor nadere gedragsspecificatie.

Nu is het doorgaans zo dat gedrag in de ene situatie geënt is op gedrag in één of meer andere situaties, eventueel vice versa. Dat is eigenlijk óók een soort afleiding, maar naar de aard van de situationele verbijzondering strikt beperkt tot voorwaarden (soms ook regels genoemd; bijvoorbeeld, de voorwaarde voor de levering van een product is de bestelling ervan). Zodra het lukt om dergelijke afleidingsmanoeuvres netzo eenduidig te bepalen (lees ook: ontwerpen), maar dan met intersituationele relaties, is de ‘voorwaarde’ voor integratie tot stelselmatigheid gevestigd.

Ik herhaal met nadruk dat — ontwikkeling van — gedrag door gereedschap aan de orde is. Zulk gereedschap ondersteunt op zijn beurt menselijk gedrag. Het is dan ook bijna onvermijdelijk dat een mens het onmiddellijke gereedschapsgedrag verwart met de, zeg maar, functies die hijzelf ermee verricht. In zijn eigen ervaring gaat het immers om verschillende functies; het ligt zo voor de hand om daarvoor meteen evenzovele aparte (deel)gereedschappen te veronderstellen. Dus, een bijzondere voorziening voor autorisatie, nog een bijzondere voorziening voor audit trails enzovoort.

Inmiddels is voor — toenemend bereik van — dergelijke functies grotendeels dezelfde, te weten digitale technologie in gebruik. Daardoor ontstaat de concrete kans om verschillen veel fijnmaziger te behandelen dan onder de grove noemer van traditionele functie. Neem autorisatie. Daarvoor volstaan incrementele situaties, want autorisatie betreft steevast een combinatie van actor, taak, onderwerp. Stel dat via afzonderlijke elementen ook reeds in die trits met situationele specificaties is voorzien. Daarop kan autorisatie vervolgens weer geënt zijn, wat dus slechts — overigens nog altijd ingewikkeld genoeg — aanvullingen behoeft. En met ditzelfde principe kan in audit trails voorzien zijn dankzij verdere aanvullingen op ondermeer de toevoegingen onder de noemer van autorisatie, enzovoort.

Voor afleiding van gereedschap maakt het allemaal principieel niets uit. Voor optimale inrichting van machines moet de mens — proberen te — abstraheren van verschillen die achteraf ontstaan door … zijn menselijke interpretaties. Het situatiebegrip — of dat van perspectief, aspect en dergelijke — bevordert zulke abstractie. Er is als specificatie dus een geïntegreerde verzameling situationele modellen. Dankzij gewaarborgde eenduidigheid voor de modellen, valt gereedschap met herhaalbare precisie te ontwikkelen. Indien reeds modelmatig in passende variëteit voorzien is, bestaat er in elk geval theoretisch geen obstakel voor de geautomatiseerde slag van specificatie naar implementatie.

Wat het doorlopen van cycli betreft, merk ik op dat ontwikkeling altijd zo’n beetje in het midden begint. Dat klinkt als een paradox, maar is het bij nader inzien niet. Want dikwijls blijkt een bepaalde situatie toch minder oorspronkelijk dan eerder gedacht. Dan moet er een situatie als het ware worden vóórgeschakeld, zodat het aanvankelijke begin — dat nu dus meer naar het conceptuele midden verschuift — dáárop geënt kan zijn. Zo’n lokale wijziging werkt met intersituationele relaties onmiddellijk stelselbreed door.

 

 

enkele consequenties van het multisituationele paradigma

Ik leef in het volle besef hier met de bovenstaande paragraaf allesbehalve een populaire inleiding tot de ‘nieuwe’ modelgedreven programmatuurontwikkeling te bieden. Dat kan ook onmogelijk in zulk kort bestek. Mijn bedoeling ermee is daarentegen vooral om op z’n minst een poging gewaagd te hebben mijn achtergrond te schetsen voor enkele nadere opmerkingen over het artikel door V&S. Langs die weg met ongetwijfeld bekendere oriëntatiepunten hoop ik belangstelling aan te wakkeren.

Zo zie ik geen

probleem van consistentie tussen abstracte en concrete modellen.

Voor mij bieden situaties secure aanknopingspunten. Er zijn ruim en krap bemeten situaties, met alles daartussenin. De aanduiding van elke situatie is echter per definitie concreet. Netzo concreet is — daardoor — het specifieke objectgedrag bepaald in/door de situatie in kwestie.

Mijn opvatting over

hergebruik van deelmodellen

beschouw ik vanuit hetzelfde situationele perspectief als géén probleem. Er is gewoon geen hergebruik meer, althans niet voor één hetzelfde informatiestelsel. Want voor een bepaalde extra functie vormt zoiets als een kloon van zoiets als het informatiesysteem niet langer het optimale begin. Alles is incrementeel en krijgt gestalte via eventuele aanvullende situaties met daarin verbijzonderd objectgedrag.

Natuurlijk heeft elk stelsel ergens zijn basis. Die loopt echter ook mee in de incrementele opzet door de veronderstelling dat hij op zoiets als de nihil-situatie is geënt. Daardoor blijft het formalisme sluitend, wat helpt bij geautomatiseerde ontwikkeling van gereedschap. Het zit er trouwens dik in dat het afleidingsautomatisme op zijn beurt ook prima werkt volgens situationele verbijzondering.

Als het klopt dat V&S zich primair oriënteren op volgtijdelijkheid van (hoofd)activiteiten tijdens ontwikkeling, ding ik daarop nog wat meer af. Fundamenteel meen ik dat informatievoorziening in hoog tempo onder stelselmatige noemer valt. Daarbij hoort onherroepelijk infrastructuur voor het informatieverkeer op maatschappelijke schaal. Waarin infrastructuur reeds voorziet, kan bijgevolg in nieuwe componenten achterwege blijven. Dienovereenkomstige ontwikkelactiviteiten vervallen dus, of beperken zich tot aansluiting op de nutsvoorzieningen zoals gewaarmerkte authenticatie van persoonsidentiteit. Verder vind ik dat voor resterende ontwikkeling het cyclische karakter overheerst. Dankzij de versterkte waarborg voor eenduidigheid — alweer, natuurlijk, door beperking van gedragsspecificatie pèr situatie — staat bijna elke modellenverzameling toe dat er iets werkends van afgeleid wordt. Het hangt dan maar af van het zwaartepunt voor het — aanvullende — gereedschap wat prioriteit tijdens ontwikkeling verdient. Er is veel minder behoefte aan dwingende volgorde van activiteiten, of wel inzet van disciplines. De integratie in het vlak van werkend gereedschap suggereert zelfs intensieve iteratie, zoals ik me voorstel bijvoorbeeld voor autorisatie waarbij de gebruikers tevens onderwerp van registratie zijn (grootschalig voorbeeld: burgers in hun elektronische overheid).

V&S noemen nog allemaal disciplines waarvan ik vermoed dat ze opgaan in die voor het ontwerp (lees ook: specificatie). Nee, dat is méér dan een vermoeden. Het is domweg de ijzeren consequentie van geslaagde modelgedreven programmatuurontwikkeling.

Algemene domeinmodellen

heb ik hierboven al van enig commentaar voorzien. Vanuit situationele maatvoering is het volstrekt begrijpelijk dat ze

maar zelden gebruikt

worden. Verder oordelen V&S daar volgens mij zelfs te gunstig.

Integratie komt vaak zelfs als een gedachte achteraf,

beweren zij. Ik heb helaas de sterke indruk dat zo’n gedachte überhaupt niet opkomt. Ter verdediging van praktijkmensen poneer ik wel dat nooit doorslaggevend is, hoeveel

conceptuele overeenkomst bij voorbaat aanwezig was.

In relatie tot de opdrachtgever gaat het daarentegen om falsificatie. Het geringste verschil haalt onderuit wat verder allemaal overeenstemt. Nu is het zo dat een miniem verschil waaraan de argeloze opdrachtgever hecht, leidt tot compleet nieuw gereedschap. Dat is ook precies de reden waarom ik de werkingssfeer van falsificatie zo smal mogelijk wil krijgen, te weten pèr situatie. Want met erkenning van reële verschillen ben ik het grondig eens. Wanneer verschillen dan per definitie tot kleinschalige situaties geïsoleerd zijn, blijven kosten voor noodzakelijk aanvullende voorzieningen overzichtelijk en beheersbaar. De kwaliteitsborging is eveneens eenvoudiger door de beperkte schaal van wijziging.

Nog een ijzeren consequentie van radicaal modelgedreven programmatuurontwikkeling is dat het nooit kan gebeuren dat

delen van de specificaties te laat zijn om de implementatie fysiek uit af te leiden.

Want met iets anders dan een modellenverzameling werkt het niet, punt. Het is daarbij een psychologisch voordeel, wanneer de allereerste cyclus met een concreet resultaat razendsnel gedraaid wordt. Voorts helpt het om gedurende de gehele ontwikkeling kortcyclisch te — blijven — werken.

Hoe V&S de huidige praktijk van modelgedreven programmatuurontwikkeling schetsen, illustreert maar weer eens hoe onvolwassen informatiekunde nog is. Het is hopeloos gemodder, dat de naam in de verste verte niet verdient. Sterker nog, uit onbegrip resulteren vaak minstens twee aparte ontwikkeltrajecten, dat van de modelleurs en dat van de programmeurs. Het kan zelfs erger, wanneer zij elkaar volgens een

vicieuze cirkel

bezighouden. De gebruikers en overige betrokkenen zijn de huilende derde.

Uit de praktijk rapporteren V&S tevens dat

hergebruik […] vaak neerkomt op het uitbreiden in plaats van het versimpelen van generieke componenten.

Omdat ik eerder het generieke gedragskarakter van een component verbond met een specifieke situatie, concludeer ik nu dat uitbreiding noch versimpeling aan de orde mag zijn. Als generieke component is hij per definitie optimaal, dus voor specifiek situationeel gedrag (en ander gedrag bestáát niet, punt). Als dat gedrag (nog) niet past, moet er kennelijk principieel wat aan specificatie tot en met implementatie van situaties veranderen. Voor èlke situatie in de gewijzigde configuratie geldt onverminderd per definitie dat dáárvoor de bijbehorende (gedrags)component weer generiek is. V&S wijzen er mijns inziens op dat gepruts aan componenten desastreus kan uitpakken. Ik leg er graag extra nadruk op. Ook daarom bestaat vooral behoefte aan — daadwerkelijke toepassing van — een ontwerp- annex modelleermethode die overzicht helpt te verwerven en behouden.

Heel voorzichtig stellen V&S voorts:

Het lijkt erop dat een brede inzet van herbruikbare componenten in de praktijk samengaat met een eenvoudige interface.

Nee, dat lijkt er niet op. Dat is zo.

[H]erbruikbare componenten

vind ik overigens een pleonasme. Dankzij stelselmatig overzicht is een situationeel verbijzonderde component per definitie stelselmatig inzetbaar. Dat is accurater uitgedrukt dan

een brede inzet.

Wat V&S onvermeld laten, zijn de strikte voorwaarden voor

een eenvoudige interface.

Met verwijzing naar een formeel situatiebegrip heb ik daarin voorzien.

Ik kom ook even terug op de passage die V&S aan

verweving

wijden. Terecht hameren zij op

expliciete conceptuele modellering.

Algemeen geldt dat verweving op gespannen voet staat met eenduidigheid. Metapatroon als synthese van object- en aspectgerichtheid bedoelt ‘precies’ verweving uit te bannen. Dat lukt met toegespitste situaties en intersituationele relaties ertussen.

De aanbeveling

specificeer hetzelfde ding één keer en slechts één keer

is nog te grofmazig. Aspecten, bijvoorbeeld, gaan objecten vroeg of laat dwarszitten. De uniciteit ken ik daarom aan situationeel gedrag toe. Dat maakt één ding tot een verzameling van situationele gedragingen: zie figuur 2. Voor (veel) meer documentatie over metapatroon, bijvoorbeeld het recursieve karakter van het situatie- annex contextbegrip, zie elders.4

Figuur 2: De conceptuele samenhang tussen situatie, (object)identiteit en gedrag.

 

Ja,

modellen zijn een […] precieze formulering […] van […] werking.

V&S schrijven erbij dat het om een

complete […] formulering

gaat. Mijn idee is dat het ontwikkelproces via cycli streeft naar nodige en voldoende — dus in relatie tot een behoefte — volledigheid in modellering. Voorts stellen V&S dat het een

formulering op een bepaald abstractieniveau

betreft. Na hun terechte nadruk op precisie raak ik daardoor in verwarring. Het is alsof ze bij nader inzien een slag om de arm houden. Houdt abstractie in, dat gereedschap niet onmiddellijk afleidbaar is? Daarvoor moet immers nog concreetheid, wat dat ook is, worden toegevoegd. Zoals ik eerder opmerkte, verdwijnt pèr situatie het nut van absoluut onderscheid naar abstract danwel concreet. De situationele gedragsspecificatie moet precies zo … precies opgesteld zijn als nodig en voldoende is. Dat geldt trouwens voor elk artefact.

 

 

 

noten

1. In: Automatisering Gids, 16 september 2005.
2. P.E. Wisse, Metapattern: context and time in Information models (Addison-Wesley, 2001). Zie www.wisse.cc voor verwijzingen naar publicaties over metapatroon die on-line beschikbaar zijn.
3. Dat zijn dan feitelijk complicaties die nog vanuit hiërarchisch gezag letterlijk behéérst zijn. Die eenzijdige gezagsvoorwaarde ontbreekt, zodra één informatiestelsel — dat dienovereenkomstig wint aan infrastructureel karakter — anderszins autonome(re) actoren door (informatie)verkeer verbindt.
4. Zie noot 2.

 

 

November 2005, webeditie 2005 © Pieter Wisse