Object-oriëntatie is in. Succesvolle toepassing in administratieve omgevingen levert in het algemeen echter grote problemen op. Dat komt deels door het feit dat organisaties er slecht mee bekend zijn, maar ook door de wijze waarop ze object-oriëntatie introduceren en ermee omgaan. Een methode op basis van natuurlijke taal biedt voordelen boven de traditionele methoden, claimt Gerald Kristen. Zo is de communicatie tussen de projectmedewerkers een stuk eenvoudiger.
In veel recente artikelen, publikaties en boeken treft men het begrip object en object-oriëntatie prominent aan. De toegevoegde waarde van object-oriëntatie en de betekenis ervan komt hierin echter zelden tot uitdrukking. Zo is de wijze waarop objecten gemodelleerd worden vaak volledig identiek aan die waarop de afgelopen vijftien jaar datamodellen en toestandsdiagrammen werden opgesteld. Daardoor concludeert de lezer dat er met object-oriëntatie niets nieuws onder de zon is en dat het geen waarde toevoegt aan de bestaande werkwijze.
Dat er wel degelijk belangrijke verbeteringen mogelijk zijn met object-oriëntatie, bewijzen praktijkprojecten bij diverse bedrijven. Bij het toepassen dient men echter wel rekening te houden met een aantal factoren, die garant staan voor een optimale invoering.
Marketingkretologie
De laatste tijd staat object-oriëntatie sterk in de belangstelling bij marketeers. Bijna elk softwareprodukt dat geëvalueerd wordt, moet object-georiënteerde voorzieningen hebben om als goed gekwalificeerd te worden. Hierdoor wordt object-oriëntatie langzaam maar zeker opgenomen in het rijtje van marketingkreten die men te pas en te onpas gebruikt voor het aanprijzen van produkten. Het gevaar hiervan is dat de inhoud van het begrip ‘object-georiënteerd’ verwatert. Zo bestaat er in de markt de stellige overtuiging dat een slecht lopend softwareprodukt weer verkoopbaar wordt door het te positioneren met de extra kenmerken ‘object georiënteerd’ en ‘client/server’. Dientengevolge ontstaat een verkeerd beeld van de onderliggende begrippen met hun mogelijkheden en vooral hun onmogelijkheden. Mislukkingen met een nieuw object-georiënteerd produkt of een nieuwe oo-methode worden dan veelal ten onrechte toegeschreven aan object-oriëntatie in het algemeen. De oorzaak is eerder te zoeken in het onveranderd toepassen van de reeds lang bekende methoden en technieken, die verborgen liggen achter de kretologie van object-oriëntatie.
Om enig inzicht te verschaffen in de wijze waarop men object-oriëntatie kan introduceren en toepassen, volgt een overzicht van de gebruikte begrippen en implementatiestrategieën. Verder komen de mogelijke valkuilen en oplossingsrichtingen van de verschillende strategieën aan de orde.
Programmeertalen
Het toepassen van object-georiënteerde begrippen is het meest bekend uit de programmeertalen. Bekende object-georiënteerde programmeertalen zijn bijvoorbeeld Smalltalk, C++ en Eiffel. Deze talen worden gekenmerkt door het feit dat zij gebruik maken van een geheel andere verzameling programmeerconcepten dan in de traditionele logische programmeertalen en 4GL- omgevingen. Begrippen uit de object-georiënteerde talen zijn bijvoorbeeld: klasse (class), instantiatie, object, overerving (inheritance), method, boodschap (message) en polymorfisme.
Klasse is één van de belangrijkste concepten van een object-georiënteerde (oo) programmeertaal. In een oo-programmeertaal is een klasse namelijk de generieke beschrijving van de kenmerken van objecten. De beschrijving van kenmerken van de klasse betreft zowel de attributen als ook het gedrag van objecten als één samenhangend geheel. Het gedrag van objecten wordt beschreven door directe toewijzing van operaties op attributen aan de klasse waarop zij betrekking hebben. De operaties worden ook wel de methods van een klasse genoemd. De klasse zelf is te vergelijken met een stempel waarmee afdrukken worden gemaakt. De afdruk is dan het object. Het maken van een afdruk met het stempel noemen we het instantiëren van objecten van een klasse. Elk object behoort hiermee tot de klasse waarvan het geïnstantieerd is, en het object heeft vervolgens alle eigenschappen die op een generieke wijze bij de klasse zijn gedefinieerd.
Tussen de beschreven klassen kunnen ook meer structurele relaties gespecificeerd worden. Overerving is een voorbeeld waarbij de gemeenschappelijke kenmerken van twee of meer klassen in een superklasse gedefinieerd zijn. Door middel van een overervingsrelatie kunnen de gemeenschappelijke kenmerken vervolgens geërfd worden van de superklasse door de oorspronkelijke klassen die intussen subklasse geworden zijn.
In een object-georiënteerde programmeertaal kunnen de geïnstantieerde objecten met elkaar communiceren door het verzenden en ontvangen van boodschappen. Deze boodschappen worden verzonden en ontvangen door objecten door middel van de methods van een klasse. Hierdoor kunnen de gegevens van een object niet direct benaderd worden, waardoor het lijkt alsof de objectgegevens ingekapseld zijn voor de buitenwereld. De methods verbergen als het ware de eigenschappen van de objecten voor de buitenwereld.
Een ander veel gehoord begrip bij object-georiënteerde programma’s is polymorfisme. Dit is de eigenschap dat objecten in een groep verschillend reageren op één en dezelfde boodschap. Dit onderscheid heeft de programmeur in de programmatuur ingebracht.
Het programmeerparadigma ziet er bij de object-georiënteerde talen dan ook volledig anders uit dan bij traditionele programmeertalen. Daar bestaat een sterke neiging tot verder uitdijen, waarbij de structuren steeds complexer worden. Bij object-georiënteerde programma’s is de programmastructuur opgebouwd uit zelfstandige klassen die relatief klein en overzichtelijk zijn. De klassen op zichzelf hebben daarnaast een structurele samenhang met bijvoorbeeld overervingsrelaties en associaties. Het voordeel van object-georiënteerd werken is dan ook de mogelijkheid om de software beter beheersbaar op te zetten. In principe kan het totale systeem klasse-gewijs worden uitgebreid, wat hergebruik impliceert van reeds geteste en voordien gebruikte klassen.
De theorie van object-georiënteerd programmeren is echter mooier dan de dagelijkse praktijk. Zo blijkt hergebruik van klassen in de praktijk niet plaats te vinden of niet mogelijk te zijn. Daarnaast blijkt dat het vermogen tot uitbreiding en onderhoud van object-georiënteerde systemen veel te wensen over laat en dat object-georiënteerde toepassingen zich hoofdzakelijk beperken tot een aantal deelgebieden zoals gui-design en real-time problemen. Het succesvol toepassen van object-oriëntatie in bijvoorbeeld administratieve omgevingen levert in het algemeen grote problemen op. De oorzaak hiervan dient gedeeltelijk gezocht te worden in de onbekendheid van organisaties met object-oriëntatie, maar ook in de wijze waarop organisaties deze introduceren en ermee omgaan. Ter illustratie wordt een aantal strategieën behandeld, die gevolgd worden bij het invoeren van object-oriëntatie in een organisatie.
Invoeren object-oriëntatie
De meest gebruikelijke weg waarop een organisatie in contact komt met object-oriëntatie is door het gebruik van een object-georiënteerde programmeertaal. De eerste stap in object-oriëntatie begint dan met het aankopen van een programmeeromgeving zoals bijvoorbeeld Visual C++, Borland C++ of een uitgebreide klasse bibliotheek. De projectmedewerkers worden vertrouwd gemaakt met de syntaxis-aspecten van de nieuwe programmeertaal, en vervolgens worden hiermee de eerste kleine projecten gerealiseerd. De criteria voor succes zijn voor deze projecten beperkt tot de vraag of een traditionele programmeur kan overschakelen naar een object-georiënteerde programmeertaal en of het gerealiseerde systeem inderdaad werkt. Aspecten die betrekking hebben op hergebruik, uitbreidbaarheid, flexibiliteit en onderhoudbaarheid moeten in vervolgprojecten worden onderzocht.
Intussen blijken in het eerste pilotproject al vaak de nodige bedenkingen naar voren te komen over de toepassing van object-oriëntatie. Een veel voorkomend probleem bij projecten onder tijdsdruk is dat de ’traditionele’ programmeur geen kans krijgt om zich de object-georiënteerde concepten op een juiste wijze eigen te maken. Hierdoor blijft hij op de traditionele manier programmeren. Een onderzoek in Engeland bevestigt dit. Bekeken werd of een met een C++-compiler gecompileerd programma inderdaad op een object-georiënteerde wijze is geprogrammeerd, door de aanwezigheid van het klasse-concept na te gaan. Uit het onderzoek kwam naar voren dat in 93 procent van de onderzochte systemen geen enkele keer ‘klasse’ gebruikt is. Deze situatie is mogelijk met de C++-taal, omdat alle programmeerconcepten van de C-taal ook door de C++-compiler ondersteund worden. Hierdoor wordt het programmeren op een object-georiënteerde wijze niet afgedwongen door C++ zelf.
Dit is trouwens niet mogelijk bij de programmeertaal Smalltalk.
Een ander aspect dat in pilotprojecten wordt miskend, is het feit dat de mogelijkheden van een object-georiënteerde programmeertaal zo hoog worden ingeschat, dat men het uitvoeren van een goede analyse van de probleemomgeving niet noodzakelijk acht. Dit baseert men op het feit dat object-georiënteerde talen uitgaan van het implementeren van klassen in bijvoorbeeld gui’s, die volgens sommige programmeurs overeenkomen met de bedrijfsobjecten van een organisatie. Hierdoor kan de programmeur het systeem makkelijker interactief met de eindgebruiker specificeren en realiseren. Het probleem met deze benadering in de praktijk is dat een eenduidig raamwerk met begrippen en afspraken ontbreekt, waarmee het systeem gerealiseerd moet worden. Als gevolg hiervan gaat dit vaak gepaard met een groot aantal ongecontroleerde iteraties. Daarnaast dicteren de beperkingen van een object-georiënteerde taal hoe het bedrijfsmodel eruit komt te zien. Het model wordt opgesteld in de structuur van de object-georiënteerde programmeertaal.
De achtergrond van de hier beschreven problematiek is dat er eigenlijk geen gemeenschappelijk communicatieplatform is tussen de programmeur en de eindgebruikersorganisatie. Bij verdergaand gebruik van de object-georiënteerde programmeertalen ontstaat er in de projectorganisatie bij de projectleider en de programmeurs een steeds grotere behoefte aan gestructureerd werken met de nieuwe hulpmiddelen. Een normale stap is dan ook het selecteren van een oo-case-tool, waarmee programmeur en analist object-georiënteerde analyses en ontwerpen kunnen opstellen. Het case-tool dient een aansluiting te hebben met de object-georiënteerde programmeertaal door het ondersteunen van de generatie van klassen.
Modelleringstechnieken
De behoefte aan het toepassen van een object-georiënteerde methode ervaart men het sterkst op het moment dat er problemen zijn ontstaan bij het beheersbaar en inzichtelijk houden van de geïmplementeerde klassen. De eerste vraag die programmeur en analist stellen is op welke wijze de bestaande klassen ingelezen kunnen worden naar een object-georiënteerde case-tool om ze vervolgens af te beelden in modellen. Omgekeerd wordt ook onderkend dat het zinvol is om eerst te modelleren, voordat men begint met programmeren. De methodeselectie vindt dan ook voornamelijk plaats vanuit de behoefte en de optiek van programmeur en analist, en richt zich op het afbeelden van de logische structuur van klassen.
Het overgrote deel van de object-georiënteerde methoden dat de afgelopen jaren is ontwikkeld, geeft dan ook een directe afbeelding van de klassen, haar attributen en methods, samen met de onderlinge relaties tussen klassen, in een apart model dat veelal de naam ‘objectmodel’ draagt. Behalve de structuur van de klassen beelden de meeste methoden het gedrag van de objecten af in een dynamisch model, hun onderlinge interactie in een object-interactiemodel en de functionaliteit van objecten in een functioneel model.
De modelleringstechnieken die bij de meeste object-georiënteerde methoden gebruikt worden, komen sterk overeen met de modellen die reeds vele jaren bekend zijn bij gestructureerd analyseren en ontwerpen. Zo vertoont het objectmodel zeer grote overeenkomst met een datamodel (extended entity relationship model, eer). Het dynamische model is identiek aan een toestandsdiagram (state transition diagram, std) en het functioneel model is gelijk aan een dataflow diagram (dfd). Het voordeel van het toepassen van de bovenstaande methoden, is dat zij snel begrepen worden door medewerkers die reeds bekend zijn met de modellen van gestructureerde analysemethoden. De gebruikte modelleringstechnieken zijn immers zeer herkenbaar.
De vraag die men hierbij dient te stellen is of je met het eer-, std- en dfd-model in staat bent om überhaupt object-georiënteerd te specificeren. Indien het antwoord hierop bevestigend is, moet men zich afvragen wat de toegevoegde waarde is van de object-georiënteerde methode ten opzicht van de traditionele methoden.
Voor een antwoord op deze vraag volgen enkele aspecten van de modelleringstechnieken meer in detail.
Diverse problemen
In het verleden is een groot aantal problemen gesignaleerd bij de traditionele methoden. Zo is er tussen de verschillende modeltypen slechts een zeer beperkte onderlinge samenhang, waardoor de kwaliteit van, en de consistentie tussen de modellen niet te bepalen is. Het is dan ook niet gemakkelijk om over te gaan tot beoordeling van de kwaliteit van de specificaties, en om met de modellen betrouwbare en consistente code te genereren. De kwaliteit van de generatie kan immers nooit beter zijn dan de kwaliteit van de ingaande modelspecificaties! Bij het toepassen van object-georiënteerde methoden die op eer-, std- en dfd-modellen gebaseerd zijn, is in de praktijk te verwachten dat zij deze nadelen zullen erven van de traditionele gestructureerde methoden.
Een ander, fundamenteler probleem treedt op doordat bij de meeste object-georiënteerde methoden zeer sterk de nadruk ligt op het modelleren van de gegevens in klasse-structuren. Het dynamische gedrag van objecten wordt gezien als een apart deel, dat los van de klasse-structuur te specificeren is in een apart modeltype. Als resultaat hiervan worden objecten gemodelleerd in de terminologie van object-georiënteerde programmeertalen, terwijl de denk- en werkwijze nog steeds gelijk is aan de traditionele gegevensgerichte benadering. Hierdoor wordt geen geïntegreerde objectspecificatie opgesteld waarin het gedrag en de gegevens als één geheel gerepresenteerd zijn, maar worden nog steeds twee losstaande modellen gemaakt voor het gedrag en de gegevens. De eerder beschreven werkwijze komt in de praktijk zeer vaak voor en leidt tot het onbenut laten van de mogelijkheden van object-oriëntatie. Het toepassen van de gegevens- of klassegerichte modelleerwijze leidt tot systemen met een lagere flexibiliteit en hogere complexiteit dan strikt noodzakelijk.
Een derde probleem bij object-georiënteerde analyse treedt op doordat de systeemanalist stelt dat hij een eenduidige probleembeschrijving van de reële wereld kan maken door het modelleren van klassen en hun onderlinge relaties. De semantische structuren van klassen en andere modellen zouden voldoende zijn om de bedrijfsobjecten in de reële wereld eenduidig te beschrijven. In de praktijk blijkt echter dat niet onderkende semantische beperkingen van object-georiënteerde programmeertalen deze benaderingswijze onmogelijk maken. Om dit toe te lichten volgt een voorbeeld met één van de semantische beperkingen van object-georiënteerde programmeertalen.
Hindoeïstische kasten
Het basisprincipe van object-georiënteerde programmeertalen is dat objecten geïnstantieerd worden door een klasse en dat de klasse-specificaties vervolgens door de geïnstantieerde objecten worden gebruikt voor het bewaken van het leven van de objecten zelf. Deze implementatievorm heeft het voordeel dat programma’s zijn opgebouwd uit klassen met afgebakende begrenzingen. Wanneer we echter de klasse gebruiken voor het modelleren van objecten in de reële wereld, lopen we tegen een situatie aan die vergelijkbaar is met het kastensysteem in India. Dat classificeert mensen in vier hoofdkasten en één kastenloze klasse, de paria’s. Volgens het hindoeïsme worden mensen geboren in één kaste en kan een persoon niet van kaste veranderen gedurende zijn leven. Het veranderen van kaste kan slechts plaatsvinden nadat een persoon is overleden en door wedergeboorte reïncarneert in een andere kaste. Tussen de kasten bestaat een duidelijke hiërarchie die bepaalt welke kaste ondergeschikt is aan welke andere kaste. Als gevolg van de classificatie van personen in verschillende kasten, ontstond een structuur met weinig ruimte voor sociale verandering van het individu. De kastenstructuur leidde tot sociale bevriezing van de maatschappij. Het opmerkelijke aan object-georiënteerd programmeren is dat de basisprincipes die ten grondslag liggen aan de klasse, volledig vergelijkbaar zijn met het Indiase kastensysteem. Dit komt omdat een object in een object-georiënteerde programmeertaal geïnstantieerd wordt door een klasse en er gedurende zijn hele verdere leven door beheerd wordt.
Wanneer we de klasse gebruiken als basis voor de modellering van objecten uit de reële wereld, kunnen we uiteindelijk ook kampen met dezelfde problemen als bij het kastensysteem. Deze worden veroorzaakt door het feit dat met het klasse-concept de instantiatie van objecten gelijk gesteld is aan de classificatie van objecten. Het wordt nu moeilijk om de objecten in een object-georiënteerd systeem anders te classificeren, omdat ze reeds tot een klasse behoren.
Natuurlijke taal
De meesten zullen zich nu afvragen of het toepassen van object-oriëntatie in de organisatie überhaupt voordelen biedt ten opzichte van de traditionele benadering. Het antwoord hierop is onverdeeld ‘ja’, onder voorwaarde dat men niet in de beschreven valkuilen moet stappen bij de introductie van object-oriëntatie. Zo zal een organisatie niet object-georiënteerd gaan werken en denken door het aanschaffen van een object-georiënteerde programmeertaal. Ook gaat men niet object-georiënteerd denken wanneer men de syntaxis en begrippen van een object-georiënteerde programmeertaal kent. En men zal niet object-georiënteerd specificeren, wanneer men gebruik maakt van eer-, std- en dfd-modellen die verpakt zijn in een object-georiënteerde terminologie.
Een organisatie die daadwerkelijk de mogelijkheden en voordelen van object-oriëntatie wil benutten, moet rekening houden met een omschakeling in zowel denkwijze als werkwijze. Deze omschakeling naar object-oriëntatie is gericht op het beschrijven van het gedrag en eigenschappen van objecten in de reële wereld. In de beschrijving zelf wordt niet uitgegaan van de concepten van een implementatietaal, zoals klasse in C++ en Smalltalk, maar wel van de wijze waarop wij als mensen met elkaar praten en communiceren over de objecten in de reële wereld. Deze intermenselijke communicatie is gebaseerd op de principes van de natuurlijke taal.
Met de natuurlijke taal zijn wij in staat om eigenschappen en veranderingen van objecten te beschrijven. Ook kunnen we aangeven wie of wat deze veranderingen uitvoert en aanstuurt. Als zodanig geeft de natuurlijke taal een gemeenschappelijk basis voor de betrokken personen. Deze taal kan echter op veel punten weinig precies en informeel worden gebruikt. Er is dan ook een formele methode noodzakelijk, die de kwaliteit van de specificaties verbetert en de volledigheid controleert.
Domino-spel
Dit gebeurt in de Kiss-methode [1, 2] – de door het gelijknamige bedrijf ontwikkelde methode voor object-oriëntatie – door het opstellen van verschillende typen modellen met een sterke onderlinge samenhang, waarbij zij elkaar controleren en aanvullen. Het opstellen van de modellen geschiedt door uit te gaan van een tekstuele beschrijving die initieel met een grammaticale analyse wordt ontleed. De hierbij gevonden ‘subjecten’, ‘acties’ en ‘objecten’ worden vervolgens in interactie met de eindgebruiker gebruikt voor het opstellen van modellen. De modellering wordt ondersteund door het ‘Kiss-Domino’ spel dat de interactie tussen de gebruikers onderling verder bevordert, zodat het begrip van de te modelleren bedrijfsobjecten toeneemt.
De kern van deze methode is het Kiss-model, dat het gedrag van een object op een generieke wijze beschrijft. Daartoe plaatst het de acties die uitgevoerd kunnen worden op een object, in een iteratie-, selectie- en sequentiestructuur. Dit model is ontwikkeld in 1990 en geïntroduceerd [3] voor het autonoom beschrijven van objecten, zonder uit te gaan van de implementatie-(on)mogelijkheden van object-georiënteerde programmeertalen [4]. Het voordeel van dit soort modellen is dat zij de autonomiteit van objecten garanderen en daarmee de mogelijkheid geven om informatiesystemen incrementeel uit te bouwen als ware het een domino-spel. Een bijkomend voordeel is dat de methode een duidelijk onderscheid maakt tussen de instantiatie van objecten door het objecttype dat beschreven is in het model, en de classificatie van objecten door zogenaamde objectklassen. Met de scheiding tussen objecttypen en objectklassen vermijdt deze methode de problemen die traditionele object-georiënteerde methoden hebben door uit te gaan van het klasse-concept van een oo-programmeertaal.
Een ander voordeel is dat de modellen gebaseerd zijn op de natuurlijke-taalconcepten waardoor de communicatie tussen de medewerkers van een project aanzienlijk verbetert. Daarnaast geeft de methode een zeer sterke invulling van de kwaliteitsprincipes, doordat de opgestelde modellen met behulp van automatische transformatie weer kunnen worden teruggebracht tot bijvoorbeeld Nederlandse zinnen die de eindgebruiker kan controleren. Het informatiesysteem blijkt niet goed te zijn, wanneer de – door de modellen gegenereerde – zinnen niet goed zijn. Op deze wijze wordt de kwaliteit van het informatiesysteem in een zeer vroegtijdig stadium gecontroleerd door de eindgebruiker.
Genereren van code
Verderop in een project komt de vraag naar voren in hoeverre de opgestelde modellen te gebruiken zijn voor het realiseren van object-georiënteerde informatiesystemen. Hierbij komen aspecten aan de orde als ondersteuning van computer aided software engineering, generatiemogelijkheden en prototyping. Het probleem bij automatische realisatie is dat de opgestelde specificaties formeel en consistent dienen te zijn. Een generator kan immers nooit consistente code genereren wanneer de specificatiemodellen onderling niet consistent zijn. Doordat de verschillende modeltypen van de methode elkaar aanvullen en valideren, kan men de kwaliteit garanderen die voor een goede generatie nodig is. Verder is de formaliteit van de opgestelde modellen gewaarborgd door een eenduidige set van symbolen en modelleringsvoorschriften. Op basis van deze twee zaken is de basis gelegd voor generatie van code.
De generatie bij de Kiss-methode is niet beperkt tot systemen die gebruik maken van een object-georiënteerde programmeertaal, maar is ook mogelijk in mainframe-omgevingen zoals Huron, vierde-generatie talen zoals Uniface en Windows SQL, oo-talen zoals C++ en Smalltalk en relationele database management systemen zoals Oracle en Sybase. Dit komt doordat de semantische inhoud van de bedrijfsobjecten veel groter is dan de semantische structuren van een implementatie-omgeving. Dit maakt het gemakkelijk om de semantische inhoud met behulp van transformatieregels te verminderen voor een programmeeromgeving. Een bijkomend aspect van deze werkwijze is dat de systeemdocumentatie gedurende het gehele ontwikkeltraject reeds is opgesteld en weinig aanvulling vraagt voor de technische realisatie.
Bovenstaande werkwijze is de afgelopen jaren reeds met succes geïmplementeerd in organisaties zoals Ohra, Shell, ECT, VBI, Vlisco, Ministerie van Defensie, DCC, Lapeyre, Banksys. De komende jaren worden hier de kwaliteit en de beheersing van de totale ontwikkelomgevingen verder vergroot.
Waardevaste modellen
De grote marketinghype rondom object-oriëntatie maakt het de manager moeilijk om de juiste methode te kiezen voor het verbeteren van de informatievoorziening. Globaal gezien kan hij kiezen uit drie benaderingswijzen die successievelijk meer mogelijkheden bieden: introductie van object-georiënteerde programmeeromgevingen (1); introductie van object-georiënteerde methoden voor logische klasse modellering (2) en introductie van bedrijfsobjectmodellering op basis van natuurlijke taal (3).
Het eerste alternatief maakt medewerkers vertrouwd met de syntaxis van een programmeertaal, maar geeft geen enkele garantie voor gestructureerd object-georiënteerd denken en werken door de projectgroep.
Het tweede alternatief biedt de programmeur en de systeemanalist de mogelijkheid tot het afbeelden van de geïmplementeerde of te implementeren klassen in een logisch klassemodel. Hiermee geeft het een basis voor het afbeelden van de implementatie in modellen. Het is echter ongeschikt om te dienen als communicatiemiddel tussen eindgebruikers en ontwikkelaars, omdat het uitgaat van de technische mogelijkheden van de programmeertaal zelf.
De tekortkomingen van de voorgaande benaderingen zijn niet aanwezig in het derde alternatief. Daarnaast is de kwaliteit van de specificaties reeds in een vroegtijdig stadium te controleren. Tevens geeft het de mogelijkheid tot hergebruik van bedrijfsobjecten en tot generatie van object-georiënteerde systemen die in een willekeurige taal geïmplementeerd kunnen worden. Als zodanig zijn de opgestelde modellen waardevast, ook wanneer men besluit om van implementatie-omgeving te veranderen.
Lagere kosten
Bij de introductie van object-oriëntatie dient een organisatie rekening te houden met een groot aantal valkuilen. Het gaat dan ook niet zonder risico’s en zal op een gedegen wijze moeten plaatsvinden. In de praktijk is aangetoond dat een juiste introductie van object-oriëntatie de integrale ontwikkeltijd en -kosten aanzienlijk kan terugbrengen. In het algemeen krijgt een projectgroep in een organisatie deze kans slechts eenmaal, en moeten de overwegingen voor de te nemen richting van introductie aan het begin van een project genomen worden. Het is absoluut onlogisch en veel duurder om eerst een object-georiënteerd programma te schrijven, vervolgens het logisch ontwerp te maken om tenslotte te starten met het opstellen van een architectuur met bedrijfsobjecten op basis van de geprogrammeerde code. De keuze van de richting zal dan ook veel meer ondersteund moeten worden door het management op basis van de doelen die het wil bereiken met informatiesystemen en met de realisatie en onderhoud ervan.
De beslissing om object-oriëntatie toe te passen is daarmee veel strategischer en reikt aanzienlijk verder dan de beslissing tot het aanschaffen van Visual C++ of Borland C++.
Gerald Kristen is directeur van Kiss b.v. te Veghel
Literatuur
1. Kristen G.J.H.M., Kiss-methode voor Object Oriëntatie. Van Informatie Architectuur naar Informatie Systeem. Academic Service, Schoonhoven, 1993.
2. Kristen G.J.H.M., Object Orientation, the Kiss method. From Information Architecture to Information System. Addison-Wesley, 1994.
3. Kristen G.J.H.M., Realiteit weergeven via objectmodellen, Computable, 18 januari 1991.
4. Kristen G.J.H.M., OO: strategie voor de jaren ’90, Data News, nr.11, 20 maart 1992
