(Dit artikel is voor het eerst verschenen in Software Release Magazine / jaar: 1997 / nummer: 4 / 6 Juni 1997) onder de titel Waarom software terugbijt.
De wraak van systemen
Wat zijn de problemen waar software ontwikkelaars tegenaan lopen? Op welke manieren kunnen wij verwachten dat onze huisdiertjes terugbijten? Op welke wijze kunnen wij systemen bouwen die dat voorkomen?
Edward Tenner [i] onderscheidt verschillende soorten van terugbijten, die hij categoriseert als wraakeffecten. Wraak is niet hetzelfde als een neveneffect (zoals chemotherapie die kaalheid veroorzaakt) of een trade-off (veiligheidsmaatregelen die prijzen verhogen).
- Rearranging
airco die nog verstikkender is wanneer hij uitvalt, omdat de ramen niet open kunnen - Repeating
hetzelfde ding vaker doen i.p.v. vrije tijd om andere dingen te doen - Recomplicating
druktoetsen maken opbellen eenvoudiger – totdat alle bedrijven je in wachtrijen zetten - Regenerating
inzetten Patriots tegen Scuds in de Golf oorlog waardoor de schade groter werd i.p.v. kleiner – de brokstukken bestreken een veel groter gebied - Recongesting
radiokanalen die vol zitten, zee-afval en nu internet - Reverse revenge
zeldzame planten in vervuilde streken, oude typemachines tegen CTS – hier is sprake van een onbedoeld positief effect
Deze wraakeffecten komen vooral voort uit te nauwe koppeling van (sub-) systemen [ii] , evenals te rigide aanpak van wetten en gewoonten.
Dit leidt tot een definitie van een systeem: een samenwerkende hoeveelheid dingen die een zekere onderlinge koppeling hebben.
Een oud vliegtuig, met kleppen en wielen die allemaal door de piloot werden bediend met hendels e.d. was een systeem met een lossere koppeling en gaf ook de gelegenheid beter te zien wat er eigenlijk gebeurde. Neem debuggers: deze zouden de ontwikkelaar in staat moeten stellen om beter te begrijpen wat er gebeurd, verondersteld om een fout op te lossen. De complexiteit van interacties is echter zo toegenomen dat dit niet meer werkt.
Het bekendste voorbeeld van een systeem dat los gekoppeld is, maar maximale cohesie vertoond is het ecologische systeem. Deze analogie zien we steeds vaker opduiken als een voorbeeld voor software ontwikkeling. Kunnen wij onze systemen op deze wijze bouwen? Waarop moeten wij dan letten? Wat zijn de ontwikkelingen op dit gebied?
Sleuteltechnieken
Het begint met een boek. Ik pak het boek van het bureau, het tastbare, real-world boek. Is dit een object? En als het dat is, hoe zou ik dit object vertalen naar een representatie in een model? [iii]
Met opzet heb ik in dit class diagram geen attributen vermeld, omdat ik me wil concentreren op het gedrag van het object, oftewel de verantwoordelijkheden. [iv]
Wat zouden nu de voordelen zijn van een dergelijke representatie van dit ding in een objectgeoriënteerd model? Toegegeven, het is een aardig beperkt model, maar toch… De representatie van het boek in het model is conventioneel OO en toch mankeert er iets wezenlijks aan dit model. Het klopt namelijk niet.
Objectoriëntatie wil een handvat bieden om een naadloze afbeelding van een “werkelijke” wereld naar een model te realiseren. Alles goed en wel, maar dat boek dat ik in mijn handen heb, hoe fraai ook, is absoluut niet in staat zichzelf af te drukken. Sterker nog, het is al afgedrukt. In werkelijkheid is dit boek niet in staat tot het vertonen van enig zinvol gedrag. Alles wat het boek misschien doet is passief reageren op wat iemand, een actief object zo u wilt, met dit ding doet.
Het gaat hierbij over de afbeelding van de “werkelijkheid” op modellen, de problemen die daarbij optreden, en de beperkingen van deze manier van afbeelden. Het doel zal zijn de problemen die bij die afbeelding ontstaan beter te categoriseren en het proces van afbeelden effectiever in te vullen. Mijn ervaring is dat technieken niet een inherente kwaliteit bezitten waardoor ze effectief zijn, maar dat er alleen sprake kan zijn van effectief gebruik. Objectoriëntatie is hier geen uitzondering op. Wellicht dat we daarbij en passant vage kreten als “objectoriëntatie is een manier van denken”, of: “het is zo moeilijk om de objecten te vinden” wat duidelijker krijgen.
De wereld van Roger Rabbit
Het boek is inderdaad niet in staat om zichzelf af te drukken. Misschien een boek of een document in de zin van een softwaredocument maar daar gaat het hier juist niet om. Immers, wij willen een afbeelding van de werkelijkheid maken die ons een aantal voordelen zal bieden als minder fouten, uitbreidbaarheid en flexibiliteit.
Welnu, de wereld die objectoriëntatie afbeeldt is niet de werkelijke wereld, maar een wereld die ik de wereld van Roger Rabbit zal noemen. Het is een afbeelding van een abstractie. Objecten die in onze werkelijke wereld passief zijn worden als het ware geanimeerd, tot leven gewekt door een tik met de staf van de toverfee. Heeft dat voordelen?
Het doel van de gehele exercitie is te komen tot wat ik zal noemen lokalisatie van complexiteit, en ik zal pogen aan te tonen dat hierin, naar mijn overtuiging, de essentie en de kracht ligt van objectoriëntatie.
Technieken voor objectoriëntatie
Software wordt geschreven door mensen. Mensen maken fouten. Het is een truïsme in de cognitieve psychologie dat mensen slecht zijn in het bevatten van complexiteit. De wet van Miller [v] zegt dat we slechts in staat zijn tot het tegelijkertijd bevatten van 7 eenheden van informatie (seven plus or minus 2). Hoe kunnen we dan voorkomen dat onze software fouten bevat? Hoe kunnen we bewerkstelligen dat onze modellen een correcte weergave zijn van de werkelijkheid? Hoe kunnen we modellen ontwikkelen die gebruikt kunnen worden niet alleen om de werkelijkheid te modelleren maar ook om de werkelijkheid te vormen [vi] met bedrijfsmodellen die executeerbaar zijn en gebruikt kunnen worden om bedrijven te engineeren.[vii]
- ecologische systemen te modelleren om scenario’s uit te testen om te komen tot minimale vervuiling
- sociologische modellen
Misschien moeten we niet zoeken naar technieken waardoor we foutloze software ontwikkelen (formele methodes e.d.) maar een manier bedenken waardoor we systemen fault-resilient maken (fout-ongevoelig).
De enige manier waarop wij dat voor elkaar kunnen krijgen is door gebruik te maken van eigenschappen van het menselijk denken. Mensen zijn tot veel in staat, maar om dat voor elkaar te krijgen moeten we wel gebruik maken van de juiste hulpmiddelen. Veel van die hulpmiddelen zijn al eens geformuleerd in de cognitieve wetenschappen, en mijn stelling zal zijn dat opmerkelijk veel daarvan toegepast is of toe te passen valt in objectoriëntatie.
Lokalisatie
Eén hulpmiddel is lokalisatie waarop de van oorsprong oud-Griekse rhetorica is gebaseerd. De oude Grieken gebruikten deze techniek om niet alleen gehele redevoeringen te onthouden, maar ook alle mogelijke antwoorden op vragen te memoriseren, evenals alle behandelde onderwerpen. Vóór de uitvinding van de boekdrukkunst was deze techniek algemeen bekend.[viii] In de middeleeuwen bijvoorbeeld reisden monniken soms honderden kilometers naar een ander klooster om een belangrijk boek te kopiëren. Omdat de wegen niet veilig waren was het vaak niet aan te raden kostbare werken te vervoeren, dus wat deden deze monniken: ze leerden deze boekwerken, inclusief illustraties, geheel uit het hoofd. Ook nu nog horen wij soms van mensen die bijvoorbeeld de gehele Koran uit het hoofd kennen. Je zou de techniek kunnen vergelijken met onze ezelsbruggetjes. Wat deden deze monniken? De techniek bestond eruit dat de te onthouden elementen werden verbonden met loci, bepaalde plaatsen die voor de betreffende monniken zeer bekend waren, bijvoorbeeld een kerkgebouw, een kathedraal, of ook wel genoemd het magische theater. Door zich imaginair door deze ruimte te bewegen, legt bijvoorbeeld de monnik een verbinding tussen de drempel en de eerste passage in het boekwerk. Door zo het gehele gebouw door te gaan en alle elementen te binden aan de loci, de stenen, iconen, afbeeldingen enzovoorts, is hij in staat het gehele boekwerk te memoriseren.
Door lokalisatie is een mens dus in staat complexe informatie te binden aan abstracties. Door alle dynamische en statische informatie te binden aan objecten, maakt objectoriëntatie dus gebruik van het ver ontwikkelde vermogen van de menselijke cognitie om met complexiteit om te gaan. Het object, het atomaire in de statische component van objectoriëntatie, is die steen, dat icoon, dat uitermate geschikt is om als locus te dienen voor wat ik zal noemen kritische informatiedragers, namelijk gedragslabels (boodschappen) en relaties (associaties). Dit leidt niet alleen tot verwerking in het model van de informatie-elementen uit de “werkelijke wereld” maar ook tot aangrijpingspunten voor het begripsvermogen van de ontwikkelaars. Dat laatste aspect is minstens even belangrijk als de correctheid van onze modellen! Pennen die kunnen schrijven, documenten die zich kunnen verplaatsen, zijn allemaal normale verschijnselen in de Roger Rabbit wereld. Dat er meer of minder semantische betekenis kleeft aan de beelden an-sich is niet zo belangrijk. Waar ik gebruik van maak (ook bij het vinden van objecten) is het menselijke vermogen om semantische links te leggen ook waar deze niet voor de hand liggen. Een voorbeeld van een link, ook al is deze wellicht verkeerd, is vrouwen en een gevaar in het verkeer, of zwarte mensen en muzikaliteit.
Vorm versus proces
Binnen objectoriëntatie is er voortdurend sprake van een onbesliste strijd tussen twee kampen: de procesbenadering en de domeinbenadering.
De eerste benadering, waarvan Jacobsons Objectory [ix] een exponent is, probeert vanuit de processen te komen tot de objecten die in die (bedrijfs-) processen een rol spelen. Deze processen zijn beschreven uitgaande van de requirements. De tweede benadering probeert juist in het domein te beginnen met het in kaart brengen van de globale structuur, de concepten en hun relaties. Dit is een statische benadering.
Een derde, hybride benadering probeert in een eerste fase parallel aan domein modelleren en use case modelleren te doen zodat ook in een vroeg stadium de resultaten van de domein analyse benut kunnen worden voor de use cases, zonder dat potentiële problemen kunnen ontstaan door een model dat te zeer gestuurd is door requirements, die mogelijk te beperkt en niet generiek genoeg zijn. Voor het ontwikkelen van componenten en frameworks zijn requirements bovendien vaak niet beschikbaar of zeer moeilijk te formuleren.
Dit dilemma tussen vorm en proces is niet nieuw.
(…) this paradigm is not limited to a personal narrative of how a particular piece of theory came to be built, but that it recurs again and again wherever mental process (…) predominates in the organization of the phenomena. In other words, when we take the notion of logical typing out of the field of abstract logic and start to map real biological events onto the hierarchies of this paradigm, we shall immediately encounter the fact that in the world of mental and biological systems, the hierarchy is not only a list of classes, classes of classes, and classes of classes of classes but has also become a zigzag ladder of dialectic between form and process.[x]
Gregory Bateson
Een techniek die juist dit zigzag proces ondersteund zijn CRC sessies. [xi] Hierin wordt gebruik gemaakt van lokalisatie en delegatie van verantwoordelijkheden. Wat benadrukt moet worden is de noodzaak om niet alleen technieken te gebruiken, maar deze door ontwikkelaars te laten gebruiken op de meest effectieve wijze. Door tijdens het ontwikkelproces voortdurend heen en weer te springen tussen vorm (een gevonden class) en proces (het realiseren van een bepaalde verantwoordelijkheid) in een interactief rollenspel wordt deze effectiviteit bevorderd. Het is belangrijk onderscheid te maken tussen CRC sessies en requirements analyse. Bij CRC sessies staan lokale objecten centraal. De ontwikkelaar gaat als het ware zitten op een object en wordt ondersteund bij het zich verplaatsen in dat object. Bij requirements analyse gaat het om wat het systeem geacht wordt te doen. De waarde van requirements-analyse in het offertetraject zal ik niet aanvechten, echter wel de rol ervan in het modelleren.
Het proces van inzicht krijgen in objecten en hun interacties is iets wat ondersteund kan worden door dit zigzag proces expliciet toe te passen. Hierover hoop ik in een volgend artikel een aantal handvaten aan te dragen.
[i] Edward Tenner: Why Things bite back – Predicting the Problems of Progress. Fourth Estate. London 1996.
[ii] Charles Perrow: Normal Accidents: Living with High-Risk Technologies. Basic Books 1984.
[iii] In dit artikel zal gebruik gemaakt worden van de UML notatie en terminologie.
[iv] Met name OMT en UML (www.rational.com) maken gebruik van notaties die minstens evenveel de nadruk leggen op de state als het gedrag van objecten, terwijl in de meeste gevallen de beschrijving van de state onderdeel uitmaakt van de private parts van een object. COMN is een voorbeeld van een notatie die de beschrijving van private parts uitstelt tot in de design fasen (www.csse.swin.edu.au/cotar/OPEN/OML.html).
[v] G.A. Miller: The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63. Pp. 81-97. Later herformuleerde hij dit tot “twee of drie chunks van twee”
[vi] Ook wel CAS genoemd, complexe adaptieve systemen. Zie ook het artikel van Philip Brey in de Automatiseringsgids van 2 mei 1997: Simulaties verdringen de werkelijkheid
[vii] Executeerbaarheid is een onontgonnen gebied in OO methodes. IBM en Platinum hebben voorstellen daaromtrent ingediend bij OMG (www.platinum.com/clearlake). Een door mij ontwikkeld systeem, SmallSim, is een voorbeeld van een executeerbaar object model.
[viii] H. Hadju: Das Mnemotechnischen Schriftum des Mittelalters. Wenen, 1936
[ix] I. Jacobson et. al.: Object-Oriented Software Engineering – A Use Case Driven Approach. Addison-Wesley 1992.
[x] Gregory Bateson: Mind and Nature – a necessary unity. Fontana 1980. Pagina 210.
Pingback: Why it does not work » From the Mist