De objectgeoriënteerde aanpak zou theoretisch vele voordelen bieden in vergelijking met traditionele ontwikkelmethoden. En mogen we de verkondigers van deze boodschap geloven, dan is het een zegening voor de branche. Wordt object-oriëntatie ooit de dominante software-ontwikkelmethode, vragen Carlo Vermeulen en Jos Hillegersberg, respectievelijk student en docent Bedrijfskunde, zich af.
Wanneer je deze vraag voorlegt aan een voorstander van object-oriëntatie, dan zal deze wijzen op de reeks succesvolle projecten die met behulp hiervan zijn uitgevoerd. Stel je de vraag aan mensen die sceptisch tegenover deze aanpak staan, dan krijg je te horen dat object-oriëntatie al vanaf eind jaren zestig bestaat, maar dat nog steeds geen overeenstemming is bereikt over de manier waarop deze methode moet worden gebruikt. Over één ding is men het wel eens: object-oriëntatie vervult op dit moment nog géén dominante rol in de software-ontwikkeling.
Toch heeft object-oriëntatie (OO) de potentie een dominante ontwikkelmethode te worden. Daarvoor moeten eerst enkele hindernissen worden genomen. Men moet zich realiseren dat het ontwikkelen met behulp van OO fundamenteel anders is dan het ontwikkelen met behulp van traditionele methoden. Het kost tijd om de objectgeoriënteerde werkwijze goed onder de knie te krijgen. Zeker in het begin zal OO weinig zichtbare voordelen met zich meebrengen. Succesvol objectgeoriënteerd ontwikkelen is een zaak van lange adem en niet van een enkel experiment. Naarmate meer ervaring wordt opgedaan en het aantal ontwikkelaars die zich met object-oriëntatie bezighouden toeneemt, zullen softwarehuizen steeds meer voordeel hebben van deze nieuwe manier van ontwikkelen.
Vier fundamentele vragen
Dat de objectgeoriënteerde aanpak theoretisch vele voordelen biedt in vergelijking met traditionele ontwikkelmethoden blijkt uit artikelen die regelmatig in de IT-vakbladen verschijnen. Als we de auteurs van deze artikelen mogen geloven dan is de laatste jaren veel vooruitgang geboekt op dit gebied. Het werken met deze nieuwe ontwikkelaanpak zou resulteren in een verbetering van grafische gebruikersinterfaces, een kortere ’time-to-market’, beter aanpasbare software, hergebruik van software enzovoort. Maar zijn die positieve berichten representatief voor alle objectgeoriënteerde ontwikkelprojecten? Bij het lezen van succesverhalen over objectgeoriënteerde projecten moet men zich het volgende afvragen:
In hoeverre is het ontwikkelen echt objectgeoriënteerd? Ontwikkelaars zijn snel geneigd het label ‘object-oriëntatie’ op hun ontwikkelproces te plakken, ook al is slechts één fase uit het traject objectgeoriënteerd uitgevoerd.
Wie heeft er objectgeoriënteerd ontwikkeld? Resultaten afkomstig van onderzoeksinstellingen zijn niet altijd representatief voor alle softwareproducenten. Dit geldt ook voor resultaten die betrekking hebben op pilot-projecten.
Wat is er objectgeoriënteerd ontwikkeld? Een ‘stand alone’-applicatie in een scherp afgebakend domein is evenmin representatief.
Is object-oriëntatie geïntegreerd in een standaard ontwikkelwerkwijze? Het succes moet niet alleen betrekking hebben op dat ene pilot-project, maar ook op alle objectgeoriënteerde ontwikkelprojecten die daarna zijn opgestart.
Vijf adoptiefactoren
Uit de schaarse empirische studies blijkt dat object-oriëntatie slechts langzaam wordt geadopteerd door de softwarebranche. Nog steeds wordt de meerderheid van de projecten op traditionele wijze uitgevoerd. Wat is de reden van deze langzame adoptie? Voor een verklaring kan het in de managementliteratuur bekende werk van Rogers worden gebruikt. Rogers stelt dat technologisch superioriteit van een innovatie ten opzichte van de huidige werkwijze op zich onvoldoende is voor een snelle en succesvolle adoptie. Vijf factoren bepalen de snelheid waarmee een adoptie wordt ingevoerd.
Dit zijn: relatief voordeel, compatibiliteit, complexiteit, experimenteerbaarheid en waarneembaarheid. We zullen nu nagaan welke rol deze factoren bij de adoptie van object-oriëntatie spelen.
Relatief voordeel is de mate waarin men OO beschouwt als een betere ontwikkelmethode dan traditionele ontwikkelmethoden. Hoe groter dit voordeel, hoe eerder OO wordt geadopteerd. Dit voordeel kan worden uitgedrukt in verhoging van de productiviteit, vermindering van het aantal fouten in de software enzovoort.
Voor softwarehuizen zijn meer hergebruik van software, meer flexibiliteit in software-ontwikkeling en beter onderhoudbare software de drie belangrijkste redenen om voor OO te kiezen. Het hergebruik valt in de praktijk nog tegen door de beperkte beschikbaarheid van herbruikbare componenten. Deze herbruikbare componenten komen normaal gesproken voort uit ontwikkelprojecten die men al eerder heeft uitgevoerd. Organisaties die nog maar net zijn begonnen met objectgeoriënteerd ontwikkelen moeten het vaak doen zonder herbruikbare componenten. Het gebrek aan herbruikbare componenten wordt beschouwd als één van de belangrijkste oorzaken van het mislukken van objectgeoriënteerde ontwikkelprojecten. Opmerkelijk is dat in de praktijk blijkt dat het gebruik van object-oriëntatie niet direct leidt tot sneller of goedkoper ontwikkelen van software.
Compatibel en complex
Compatibiliteit slaat op de mate waarin object-oriëntatie aansluit bij bestaande methoden, technieken, hulpmiddelen en vaardigheden. Sommige softwarehuizen kiezen ervoor niet alle fasen (analyse, ontwerp en bouw) objectgeoriënteerd uit te voeren. Het blijkt echter dat de compatibiliteit met de huidige methoden gering is. Het toepassen van OO in alle fasen van het project wordt dan ook gezien als een belangrijke succesfactor. De kans op een snelle adoptie van OO wordt aanzienlijk vergroot wanneer de gebouwde systemen makkelijk zijn aan te sluiten op de bestaande. De compatibiliteit laat nog te wensen over.
De meeste softwarehuizen werken met bestaande niet-objectgeoriënteerde softwarecomponenten en databases. Het koppelen van objectgeoriënteerde software met niet-objectgeoriënteerde software is niet onmogelijk, maar wel ingewikkeld. Veel softwarehuizen hanteren daarom een bepaalde standaard om objectgebaseerde communicatie tussen softwarecomponenten in een open omgeving mogelijk te maken. Hiervoor worden steeds vaker zogenaamde ‘object request brokers’ (orb’s) gebruikt.
Complexiteit betreft de mate waarin object-oriëntatie wordt beschouwd als ingewikkeld en moeilijk te begrijpen. Hoe lastiger het wordt om een nieuwe ontwikkelaanpak onder de knie te krijgen, hoe kleiner de kans dat deze aanpak wordt geadopteerd. Softwarehuizen moeten veel aandacht besteden aan de opleiding en begeleiding van ontwikkelaars. Om complexe objectmodellen te kunnen ontwerpen en beheren moet men beschikken over een aanzienlijk abstractievermogen. Het denken in objecten en componenten is daarom niet voor iedereen even makkelijk, zeker niet voor de mensen die zich voorheen met uitsluitend procesmodellering of met datamodellering hebben beziggehouden. Een andere reden voor de complexiteit vormen de vele verschillende programmeertalen en methoden die alle objectgeoriënteerde begrippen op een andere wijze implementeren.
De acceptatie van de ‘Unified Modeling Language’ (UML) door de Object Management Group in november vorig jaar brengt mogelijk enige helderheid. De UML is een nieuwe analyse- en ontwerpmethode die is bedacht door Booch, Rumbaugh en Jacobson, drie ‘zwaargewichten’ op het gebied van object-oriëntatie. Zelf waren Booch, Rumbaugh en Jacobson al redelijk succesvol met hun eigen ontwikkelmethoden, maar nu hebben ze de sterke kanten van hun methoden in de UML gebracht. Door gezamenlijk een nieuwe methode te introduceren hopen ze dat de UML een de facto standaard wordt. Natuurlijk moeten dan wel voldoende softwareproducenten en toolleveranciers de UML ondersteunen.
Zien doet geloven
Experimenteerbaarheid is de mate waarin het werken met object-oriëntatie op beperkte schaal kan worden uitgeprobeerd. Softwarehuizen voeren inderdaad pilotprojecten uit voordat zij serieus met OO aan de slag gaan. De vraag is echter of de voordelen van OO hiermee voldoende duidelijk worden. Hergebruik treedt pas op na meerdere projecten. De steile leercurve zorgt er ook voor dat in een pilotproject niet alle voordelen direct duidelijk worden.
Waarneembaarheid heeft betrekking op de mate waarin de resultaten van het objectgeoriënteerd ontwikkelen zichtbaar zijn voor anderen. Het mag duidelijk zijn dat innovaties in hardware beter zichtbaar zijn dan innovaties in software. Vernieuwingen die niet direct waarneembaar zijn worden moeilijker geadopteerd. Object-oriëntatie zorgt niet of nauwelijks voor grote waarneembare verbeteringen in functionele en technische prestaties. Vanaf de buitenkant is het niet direct mogelijk om objectgeoriënteerde software van traditioneel ontwikkelde software te onderscheiden. Een mogelijk waarneembaar voordeel is een betere prestatie, bijvoorbeeld bij multimedia-software (met complexe datastructuren zoals video en geluid).
Deze analyse van de vijf factoren verklaart waarom object-oriëntatie geen stormachtige groei heeft beleefd. Slechts twee van de vijf factoren scoren onverdeeld positief: Relatieve voordelen waren aanwezig en ook kon er op kleine schaal met de innovatie worden geëxperimenteerd. Bij de overige drie factoren die de adoptiesnelheid bepalen ziet het er minder gunstig uit: lage waarneembaarheid, grote complexiteit en geringe compatibiliteit verhinderden tot nu toe een snelle groei. Enkele nieuwe technologieën (ORB’s, UML) brengen op deze gebieden verbetering, waardoor de adoptiesnelheid van object-oriëntatie de komende jaren naar verwachting zal toenemen.
Carlo Vermeulen,student Bedrijfskunde
Jos van Hillegersberg, universitair docent Bedrijfskunde
Erasmus Universiteit Rotterdam
