Het heeft toch nog zo’n vijftien jaar geduurd voordat een van de vreemdste afkortingen uit de ict-wereld gemeengoed is geworden, maar nu is oo werkelijk overal. Niet alleen overal waar C++ en Java zijn, of UML; nu ook in het overgangsgebied tussen modelleren en programmeren. Hans van Thiel interviewt oo-deskundige en entrepreneur Peter Coad: "In de begintijd van object-oriëntatie dacht iedereen dat overerving het belangrijkste was, maar het is compositie."
Peter Coad heeft alle ontwikkelingen niet alleen meegemaakt maar er richting aan gegeven. In 1991 schreef hij samen met Edward Yourdon het klassieke ‘Object Oriented Analysis’. Nu is hij ceo van een producent van software-ontwikkeltools: Togethersoft. Onder meer, want de methodoloog Peter Coad blijft, zoals de Amerikanen het noemen, een evangelist.
Het is geen man van terugkijken, Peter Coad. De co-auteur van zes boeken over object-oriëntatie, wiens naam al tien jaar verbonden is aan de Coad/Yourdon-methode, was dit voorjaar een paar dagen in Eindhoven. Hij is hier niet om het meest recente: ‘Java Modeling in Color with UML: Enterprise Components and Process’, uit 1999, of: ‘Java Design: Building Better Apps and Applets’, te promoten maar om de overname te vieren van de Nederlandse distributeur van Togethersoft. Peter Coad is chief executive officer van dit bedrijf dat geïntegreerde modellerings-tools en ondersteuning levert. Een maand of wat eerder is de Duitse distributeur ook al opgekocht. Coad vertelt met duidelijk plezier dat hij kort geleden nog enkele aanbieders van ondernemingskapitaal heeft afgewezen – hij had bij andere al zo’n twintig miljoen dollar binnengehaald. Geen enkel probleem. Ook de daling van aandelenbeurzen in het eerste kwartaal van 2001 heeft geen ernstige gevolgen gehad. De producten verkopen uitstekend.
Volgens de website http://www.togethersoft.com zou van Peter Coad begin 2001 een nieuw boek uitkomen met de intrigerende titel: ‘Managers and Objects: Why Bother?’. Dat is niet doorgegaan, vertelt Coad. Okay, maar waarom moeten managers zich met objecten bezig houden? Wij zitten vlak naast elkaar aan het lange einde van een conferentietafel, in een gloednieuw kantoor in het al even nieuwe Science Park aan de rand van Eindhoven. Het uitzicht door de ramen biedt alleen donkere wolken. Coad probeert zich even te concentreren op de vraag naar de relevantie van objecten voor managers maar geeft het dan op. Hij is duidelijk niet in de stemming voor deze initialisatie van het interview. We komen er later op terug maar springen nu over naar de betekenis van objecten voor programmeurs. De eerste doorbraak van object-oriëntatie kwam immers begin jaren negentig, met de verspreiding van het door Stroustrup bij het toenmalige AT&T Bell Laboratories ontwikkelde C++.
Objectgeoriënteerd programmeren
Vóór C++ had je Smalltalk, en oop-veteranen die inmiddels op Java zijn overgegaan vertellen graag dat Smalltalk nog steeds de enige echt objectgeoriënteerde programmeertaal is. Maar ja, vervolgen zij dan, met enige spijt, de markt heeft anders beslist. C++ is in elk geval een hybride taal waarmee zowel procedureel als objectmatig geprogrammeerd kan worden. In een artikel uit 1991: ‘What is Object Oriented Programming?’, legt Bjarne Stroustrup het verschil uit tussen die twee technieken (zie http://www.research.att.com/~bs).
Een procedure is een proces dat een invoer (van een bepaald type) transformeert naar een uitvoer (van een bepaald type). Zoals bekend is een algoritme een proces met een eindige serie stappen dat bewijsbaar tot een correct resultaat leidt. Een procedurele programmeertaal is dus bij uitstek geschikt voor het implementeren van algoritmen. De ondersteuning die zo’n taal geeft aan dit programmeermodel bestaat uit de mogelijkheid om functies te beschrijven die argumenten kunnen aannemen en waarden teruggeven.
In een modulair programmeermodel ligt de nadruk op de organisatie van gegevens. Stroustrup noemt een stapel (stack) als voorbeeld. Die is volledig bepaald door push en pop procedures en de grootte van die stapel. Een wachtrij is een vergelijkbaar voorbeeld. De manier waarop de gegevens intern gerepresenteerd worden is niet belangrijk voor de algemene werking van een stapel of een wachtrij. Het zou voor de overzichtelijkheid en de flexibiliteit, bijvoorbeeld een verandering in implementatie, dus beter zijn die interne representatie apart te houden dan wel af te schermen. Deze data hiding wordt door Stroustrup gekenmerkt als modulair programmeren. Om nu meerdere stapels of rijen in hetzelfde programma te kunnen gebruiken ligt het voor de hand die als typen te definiëren die als variabelen (objecten) gedeclareerd en gebruikt kunnen worden. Dat is dan de zogenaamde data abstraction en het eigenlijke begin van objectgeoriënteerd programmeren. Stroustrup benadrukt dat gegevensabstractie niet zo’n goede term is; het gaat eigenlijk om de mogelijkheid gebruikerstypen te definiëren. De programmeur bepaalt welke typen er nodig zijn en levert vervolgens een complete verzameling operaties voor elk type. Als een taal dergelijke gebruikerstypen echt ondersteunt (support), en niet alleen maar mogelijk maakt (enable), zoals Stroustrup ook elders benadrukt, zou men misschien al van object-oriëntatie kunnen spreken, maar daar komt nog overerving bij (inheritance).
Als je eenmaal een gebruikerstype hebt gedefinieerd zul je immers meestal ook verschillende subtypen willen maken. Je zou bijvoorbeeld een rij kunnen definiëren als een geordende verzameling elementen met een bepaalde grootte. Een stapel en een wachtrij, een Lifo- en een Fifo-buffer, zouden dan subtypen zijn van het algemenere rij-type. Je hoeft dan niet meer aan te geven dat én een stapel én een wachtrij een lengte hebben. Dat is al voor het supertype gebeurd en de subtypen erven die eigenschap.
Ondersteuning van gebruikerstypen en subtypen is dus de essentie van objectgeoriënteerd programmeren. Uiteraard begint het dan pas, maar alle kenmerken van ‘oop’ ondersteunende talen zijn vanuit deze essentie te begrijpen. Ook polymorfisme, dat vaak genoemd wordt als wezenlijk voor oop, staat in dienst van dit principe. Je zal operaties van een supertype willen aanpassen voor verschillende subtypen zonder de naam te hoeven veranderen (polymorfisme).
Doorgaand op het bovenstaande voorbeeld: definieer een methode get om een element uit een rij te halen en herschrijf die operatie voor een wachtrij en een stapel. De implementatie van de programmeertaal kiest aan de hand van het subtype, in oo-terminologie de klasse, de code die bedoeld is. De methode put, die hetzelfde is voor stapel en wachtrij, is al gedefinieerd in de basisklasse rij en kan zonder meer door beide onderklassen gebruikt worden.
Het is duidelijk dat oop op allerlei manieren hergebruik van code kan bevorderen. Kán bevorderen, want als een ontwerp niet goed is, of niet goed begrepen, krijgen programmeurs de neiging voor elke functionaliteit een nieuw objecttype te maken. Ook met oo kun je spaghetti schrijven, bevestigt Peter Coad.
Compositie
In de begintijd van object-oriëntatie, vertelt hij verder, lag de nadruk inderdaad op overerving. Maar compositie, de opbouw van klassen uit objecten van andere klassen, blijkt in de praktijk eigenlijk nog belangrijker te zijn. In zijn boek ‘Java Design: Building Better Apps and Applets’ (met Mark Mayfield en Jon Kern) wordt een heel hoofdstuk hieraan gewijd, vervolgt hij.
Compositie is in zekere zin de tegengestelde kant van overerving. Bovendien, tien jaar later en voor wat hemzelf betreft een honderdtal projecten verder, wordt steeds duidelijker dat overerving te beperkt is. De werkelijkheid laat zich niet zo makkelijk vatten in een boomstructuur; in de praktijk werkt het beter als klassen uit verschillende bronnen kunnen putten. Volgens Peter Coad is die benadering vooral toegankelijk geworden door de opkomst van Java. "We moeten naar een interface-gecentreerd ontwerp toe!" zegt hij stellig.
Met de doorbraak van Java in de tweede helft van de jaren negentig is ongetwijfeld de tweede golf in oop gekarakteriseerd. Java als programmeertaal, dus afgezien van de implementatie op diverse machines en platforms, lijkt veel op C/C++ maar is niet, of in elk geval minder, hybride. De ontwerpers van Java hebben ook geprobeerd om wat zij als nadelen van C++ beschouwden te vermijden. Zo kan in C++ de strakke klassehiërarchie van de boomstructuur versoepeld worden door meervoudige overerving. Een van de nadelen hiervan is dat polymorfisme moeilijker wordt, niet alleen om te implementeren maar vooral ook voor de programmeur. Java kent dan ook geen meervoudige overerving.
Zelfs enkelvoudige overerving heeft in bepaalde gevallen iets onnatuurlijks. In het genoemde voorbeeld van de rij is de get-methode eigenlijk niet gedefinieerd voor het algemene geval. Dat een methode pas betekenis krijgt voor een nader te definiëren subtype moet je dus apart aangeven. In Java kunnen nu met een zogenaamd interface de namen en parameters van methoden (de signaturen) worden beschreven. Om die methoden ook te kunnen gebruiken moet een klasse worden gedefinieerd die dat interface implementeert, dat wil zeggen de code voor de methoden bevat. Een klasse kan wel meerdere interfaces implementeren maar er kunnen dus geen methoden en variabelen geërfd worden. Interfaces kunnen wel constanten bevatten. De programmeur wordt nog verder geholpen, of beperkt, zou een aanhanger van C++ waarschijnlijk zeggen, doordat een bestand slechts één public interface mag hebben. Wat Peter Coad interface-gecentreerd ontwerpen noemt biedt dus een tweede spoor naast ontwerp met overerving.
Altijd object-oriëntatie
Volgens Bjarne Stroustrup, en hij benadrukte dat nog eens toen hij in 1999 in Nederland was op uitnodiging van het Centrum voor Wiskunde en Informatica (CWI), is er een plaats voor objectgeoriënteerd én procedureel programmeren. Niet alles in een object! John Lakos, die voor Mentor Graphics aan een project met 10 miljoen regels code heeft gewerkt en in 1996 ‘Large Scale C++ Software Design’ publiceerde, relativeert al evenzeer. "Wil je objectgeoriënteerd zijn, of wil je succesvol zijn?," vroeg hij retorisch tijdens een interview in 2000.
Ook Peter Coad heeft aan industriële projecten gewerkt, onder meer bij Hughes Aircraft, maar volgens hem leidt oo wel degelijk altijd tot betere overzichtelijkheid en veranderbaarheid. Juist in softwareonderhoud – al valt die term niet – zou de stabiliteit en het parallellisme van oo dus zijn waarde bewijzen. Bovendien, en nu komen we dan toch op de zin van objecten voor managers, sluit oo veel beter aan op de werkelijkheid. De analyse en ontwerpfasen van softwareontwikkeling kunnen soepeler verlopen omdat bedrijfsmatige regels en structuren beter uit te drukken zijn in objecten. Het geldt niet alleen voor zakelijke automatisering. Peter Coad vertelt met zichtbaar genoegen hoe research-chemici in een van zijn workshops de constructie van objectklassen inpasten in hun wetenschappelijke redeneringen. "Ze hadden het eigenlijk alleen maar over scheikunde," zegt hij.
Als we de termen ‘data abstractie’ en ‘object-oriëntatie’ vervangen door de karakterisering ‘gebruikerstypen’ wordt het gelijk van Peter Coad zeer aannemelijk. "Goed, als je maar met één type gegevens te maken hebt, dan heb je aan procedures genoeg," wil hij vervolgens wel toegeven.
Maar Coad is van huis uit methodoloog en houdt zich naast het modelleren bezig met modelleringstools. Deze gereedschappen, en dan vooral de daarin geïmplementeerde integratie van modelleren en programmeren, bepalen de nu rijp wordende derde oogst in oo.
Maar natuurlijk is er de afgelopen tien jaar meer gebeurd dan de opkomst van C++ en Java. Halverwege de jaren negentig introduceerde Borland het op Object-Pascal gebaseerde Delphi en daarmee het zogenaamde visueel programmeren. Het concept is uitgebreid naar andere talen en door diverse producenten, met name Microsoft, overgenomen. Delphi is als Kylix in het voorjaar van 2001 onder Linux beschikbaar gekomen. Visueel programmeren berust in hoge mate op oo en wordt wereldwijd door tienduizenden programmeurs toegepast, ook in grote organisaties.
Nieuwe huistaal
De nieuwe huistaal C# van Microsoft, die de basistaal van het .Net-project moet worden, is objectgeoriënteerd. Python, de door de Nederlander Guido van Rossum uitgevonden programmeertaal (publiek domein, zie http://www.python.org) is niet alleen als scripttaal sterk in opkomst maar ook in ingebedde toepassingen. Zo is het in februari 2001 beschikbaar gekomen voor Palm OS. Het interpretatieve Python heeft object-oriëntatie.
Objectoriëntatie is natuurlijk te vinden in de Corba (Common Object Brokerage Architecture) specificatie van de Object Management Group (OMG) en het Common Object Model (Com) van Microsoft. Samenwerking tussen applicaties past goed in het model van objecten die elkaar op gestandaardiseerde manier boodschappen doorgeven.
Hoewel de meeste databases nog altijd relationeel zijn wordt ook hier toch steeds meer objectachtige functionaliteit toegevoegd. Dat Microsoft het ADO (Active Data Object)-concept almaar verder evolueert ligt in de lijn van deze ontwikkeling.
En dan is er voor modellering de Unified Modeling Language (UML) gekomen met de uitwisselingsstandaard XMI (XML Metadata Interchange). UML is geen taal in de gebruikelijke betekenis, maar, zeer globaal, een verzameling conventies voor het bouwen en interpreteren van diagrammen. In 1999 is UML 1.3 OMG standaard geworden, versie 2.0 komt er aan. Er zijn zo’n zeven soorten diagrammen gedefinieerd en de meest gebruikte zijn het klassendiagram en het volgordediagram.
"Als je nu eens diagrammen aan code zou kunnen koppelen, en omgekeerd, zou dat niet geweldig zijn?" zo dachten de Amerikaan Peter Coad en zijn huidige chief technical officer, de Duitser Dietrich Charisius, in 1999.
Modelleren
In een klassendiagram wordt elke klasse gerepresenteerd door een rechthoek met de eigenschappen en methoden. Verbanden tussen klassen worden aangegeven door lijnen. Compositie, overerving en andere kenmerken zijn af te lezen uit de aard van de lijnen. Een onderklasse krijgt bijvoorbeeld een pijl naar zijn basisklasse. Omdat de objectstructuur van het programma in het klassendiagram zit valt daaruit in principe ook (partieel) programmacode te genereren.
In een volgordediagram krijgt elk object een eigen tijdlijn waarop (als een balk) de levensduur is geïndiceerd. Pijlen tussen tijdlijnen representeren aangeroepen methoden. Een volgordediagram modelleert dus de procesmatige structuur van een programma. Het is te koppelen aan het klassendiagram en ook aan de programmacode.
Dit idee van koppelingen – vanzelfsprekend verder uitgewerkt en uitgebreid, en aangevuld met allerlei functionaliteit – levert een combinatie van modelleringstool, ontwikkelomgeving en deployering. Ook een cvs (code version system) en zelfs geavanceerde softwaremetriek kan deel uitmaken van een dergelijke integratie.
Met de opkomst en verdere ontwikkeling van deze tools die door bedrijven als Rational, Computer Associates, Togethersoft en anderen worden geproduceerd is de derde doorbraak van oo gekenmerkt.
"In de begintijd werden de principes die in de boeken beschreven werden min of meer ter kennisgeving aangenomen," zegt Peter Coad. "Maar nu kan ik echt laten zien dat het werkt."
Om een indruk te geven van de markt: ‘Together Control Center’, de meest uitgebreide versie van het pakket, kost momenteel 6000 dollar en Peter Coad heeft zojuist een licentie voor 250 exemplaren verkocht aan Nokia in Finland. Aan een andere grote klant zijn zelfs in één klap duizend exemplaren geleverd. Daarbij moet men bedenken dat zijn bedrijf niet eens de marktleider is; dat is Rational Software. Togethersoft heeft thans driehonderd medewerkers, verspreid over Raleigh in de VS, Stuttgart, Praag en St. Petersburg. "Object-oriëntatie is heel geschikt om gedistribueerd te ontwerpen," zegt Coad. "We hebben in St. Petersburg ruim honderd medewerkers. We ontwikkelen eigenlijk de klok rond en dat gaat heel goed."
Archetypen
In zijn laatste boek (met Eric Lefebvre en Jeff De Luca) : ‘Java Modeling in Color with UML: Enterprise Components and Process’, introduceert Coad vier hoofdcategorieën waar eigenlijk alle denkbare klassen onder vallen. Dit zijn: moment-interval, rol, ding en beschrijving. Coad noemt deze categorieën ‘archetypen’ en elk archetype heeft een aantal daarbijbehorende karakteristieken. In een klassendiagram krijgt elk archetype een eigen kleur, vandaar de naam van het boek. In de hoofdmoot van het werk worden vervolgens bijna vijftig verschillende belangrijke domeinen met hun abstracte eigenschappen behandeld. Dit mondt uit in het laatste hoofdstuk waarin een lans wordt gebroken voor het ontwerpen aan de hand van overzichtelijke, door het gebruik bepaalde, kenmerken. Coad noemt dit feature driven development (fdd) en hij benadrukt dat een implementatie van één zo’n kenmerk (feature) niet meer dan ongeveer twee weken mag vergen.
Gebruik van archetypen past binnen het interface-gecentreerd ontwerpen dat eerder al aan de orde kwam. Met fdd wordt modelleren gekoppeld aan de projectorganisatie. Is Peter Coad misschien een voorstander van eXtreme Programming? "Het past wel binnen de XP-filosofie," zegt hij glimlachend.
Met aanstekelijk enthousiasme laat hij op een notebook nog eens zien hoe het pakket zijn inzichten over archetypen ondersteunt.
Hans Van Thiel Freelance Medewerker
