Vision

De wereld van Morgen
Hans Goedvolk
 

4.4 ObjectoriŽntatie

vorigevolgende

In de praktijk bestaat vaak onduidelijkheid over het begrip objectoriŽntatie (OO). De oorzaak hiervan is dat de term objectoriŽntatie op twee zaken betrekking heeft, namelijk het objectparadigma en objecttechnologie.

Het objectparadigma
ObjectoriŽntatie is in de eerste plaats een denkwijze of paradigma voor het ontwerpen en bouwen van IT-toepassingen. Dit objectparadigma gebruikt objecten als bouwstenen voor de toepassingen. Het paradigma heeft grote consequenties, zowel voor de architectuur van toepassingen als voor de werkwijze van de ontwikkelaars.

Objecttechnologie
In de tweede plaats gebruikt men de term objectoriŽntatie voor diverse vormen van informatietechnologie die op het objectparadigma zijn gebaseerd. Met behulp van objecttechnologie kunnen we toepassingen conform het objectparadigma realiseren. Objecttechnologie is begonnen met objectgeoriŽnteerde programmeertalen, die vooral gebruikt werden om simulatieprogramma's en GUI's te ondersteunen. Inmiddels heeft objecttechnologie zich uitgebreid tot multimediatoepassingen en objectgeoriŽnteerde databases en zijn er ook objectgeoriŽnteerde methoden voor analyse en ontwerp van eigen maatwerktoepassingen.

4.4.1 Het objectparadigma

In het objectparadigma staat het object centraal. Bij het ontwikkelen van toepassingen op basis van het objectparadigma komen we het begrip 'object' op drie manieren tegen.

Het objectparadigma gaat uit van reŽle objecten in de werkelijkheid. Deze beelden we af in de vorm van gegevensobjecten in IT-toepassingen. Deze gegevensobjecten realiseren we technisch door objecten te definiŽren in een objectgeoriŽnteerde programmeertaal. Een definitie van een object heet een class.

Objecten in de werkelijkheid
Uitgangspunt van het objectparadigma is, dat we de wereld om ons heen kunnen beschouwen als een verzameling objecten die met elkaar interacties en relaties hebben. Mensen zijn gewend over de wereld om hen heen te denken in objecten. Objecten zijn bijvoorbeeld de mensen zelf, de produkten en diensten die ze leveren en de documenten die ze gebruiken. Deze 'objecten' zijn betrokken bij processen. De medewerkers van een verzekeringsmaatschappij behandelen bijvoorbeeld een schadegeval aan een auto van een verzekerde. Aangezien mensen moeite hebben een proces te 'zien', gebruiken ze in de praktijk een object, zoals een schadedossier, om het proces te ondersteunen en als ťťn geheel bij elkaar te houden. Met behulp van een schadedossier 'objectiveert' men het proces.

Objecten in toepassingen
In toepassingen kunnen we objecten en processen uit de werkelijkheid afbeelden als gegevensobject. Als we bij het ontwerp van een informatiesysteem van een bedrijf de werking ervan willen specificeren, doen we dit door te bepalen welke bedrijfsobjecten en bedrijfsprocessen uit de reŽle wereld relevant zijn. Van ieder van deze bedrijfsobjecten en bedrijfsprocessen uit de werkelijkheid maken we een afbeelding in de vorm van een gegevensobject. Per gegevensobject specificeren we de gegevens, de functies en de interface

 

Afbeelding 4.4 Object 'Spaarrekening'.

De gegevens
Dit zijn de gegevens die we over het object of proces uit de werkelijkheid willen vastleggen. In OO-terminologie is de waarde die de gegevens op een bepaald moment hebben, de toestand (state) van het object.

De functies
Dit zijn de functies waarmee we de gegevens van het gegevensobject vastleggen, bewerken en opvragen. Iedere functie is te beschouwen als een procedure of programma. In OO-terminologie is dit een methode (method) van het gegevensobject.

De interface
Iedere functie van het gegevensobject kent een boodschap (message) in de vorm van een vraag die de functie opstart, en een boodschap in de vorm van een antwoord waarmee het object het resultaat van de uitvoering van de functie teruggeeft. Alle vragen en antwoorden samen vormen de interface van het object. Zowel gebruikers als andere objecten kunnen vragen stellen aan een object. De gebruiker stelt zijn vragen aan een object via het beeldscherm en het object zal zijn antwoorden op het scherm tonen. In dat geval is de functie een programma in de vorm van een gereedschap dat de gebruiker gebruikt om het object te bewerken. Een object kan ook een vraag stellen aan een ander object. In dat geval is de functie een programma in de vorm van een subroutine die na uitvoering van de functie een antwoord aan het vragende object teruggeeft. In dit geval is er dus sprake van een soort 'subroutine-aanroep' tussen de objecten, waarbij het vragende object de rol heeft van client en het antwoordende object de rol van server.

Een gegevensobject in het informatiesysteem is een abstractie van een reŽel object uit de werkelijkheid. In afbeelding 4.4 is als voorbeeld een object 'spaarrekening' weergegeven. Het object bestaat uit de gegevens die we over een spaarrekening willen vastleggen. Functies zijn bijvoorbeeld 'openen rekening', 'bereken rente' en 'schrijf 25 gulden bij'.

Om 'spaarrekening' als gegevensobject te ontwerpen, gaan we uit van de levenscyclus van een spaarrekening als bancaire produktovereenkomst. Deze levenscyclus van de spaarrekening bestaat globaal uit adviseren, offreren, afsluiten, beheren gedurende looptijd en beŽindigen.

Het gegevensobject bestaat nu uit:

  • de gegevens die nodig zijn om alle toestanden te kunnen vastleggen die de spaarrekening gedurende zijn levenscyclus kan hebben;
  • de functies die we nodig hebben om de toestand van het gegevensobject gedurende zijn levenscyclus te veranderen en alle functies om de toestand te kunnen opvragen;<
  • de interface van het gegevensobject in de vorm van alle vragen en antwoorden van de functies.

Objecten in technische realisatie
De gegevensobjecten zijn feitelijk de toepassingen die we gaan realiseren. Dit kan het beste door gebruik te maken van objectgeoriŽnteerde programmeertalen zoals Smalltalk en C++. Een bepaald type object in een objectgeoriŽnteerde programmeertaal realiseren we door een class te definiŽren die de gegevens, methoden en messages van het type object specificeert. In objectgeoriŽnteerde talen zijn getallen, codes, teksten en ook onderdelen van interfaces, zoals knoppen en schuifbalken, allemaal als class gedefinieerd. Dit betekent dat de ontwikkelaar een gegevensobject dat correspondeert met een object of proces uit de werkelijkheid, kan specificeren als een class die weer via messages gebruik maakt van kleinere objecten. We realiseren een gegevensobject op deze manier als een cluster van samenwerkende objecten van verschillende classes.

Real World Modelling
Met objectgeoriŽnteerde talen is het mogelijk de gegevensobjecten te realiseren als documenten die zich via een GUI presenteren aan de gebruiker. Bij gebruik van multimedia kunnen de objecten zich presenteren in de vorm van teksten, tekeningen, formulieren, bewegend beeld en geluid. Hierdoor kunnen we de gegevensobjecten in het geautomatiseerde systeem hetzelfde uiterlijk geven als de dossiers, documenten en formulieren in bestaande handmatige administratieve processen.

Het objectparadigma maakt 'Real World Modelling' mogelijk. De gebruiker werkt dan op zijn werkstation met gegevensobjecten die er net zo uitzien en zich net zo gedragen als objecten uit de reŽle wereld. Een object als een formulier of een dossier ziet er op het beeldscherm net zo uit als de papieren versie. Een gegevensobject over een vliegtuig of een auto bevat het complete ontwerp van het object inclusief mogelijkheden voor de simulatie van het gedrag van het object.

Ook voor de ontwikkelaar heeft Real World Modelling grote voordelen. Hij kan bedrijfsprocessen en bedrijfsobjecten uit de werkelijkheid eerst vertalen naar gegevensobjecten en deze vervolgens realiseren als classes in de gebruikte objectgeoriŽnteerde taal.

4.4.2 Objecttechnologie

Om objectgeoriŽnteerde toepassingen te kunnen ontwikkelen, is informatietechnologie nodig die het objectparadigma ondersteunt. Er is behoefte aan objectgeoriŽnteerde programmeertalen, aan methoden en ontwikkelplatformen voor objectgeoriŽnteerde analyse, ontwerp en programmering van toepassingen, aan objectgeoriŽnteerde besturingssystemen en aan objectgeoriŽnteerde database-managementsystemen.

Al deze objecttechnologie is nog in ontwikkeling. Pas de laatste jaren is er een duidelijke groei in het gebruik van objecttechnologie. De oorzaak van de toenemende belangstelling is dat veel nieuwe IT-ontwikkelingen zoals GUI's, multimedia en simulatietoepassingen, zich het beste laten realiseren met op objectoriŽntatie gebaseerde technologie.

Ook ontwikkelaars van bedrijfstoepassingen beginnen meer belangstelling voor objectoriŽntatie te krijgen. Zij verwachten voordelen zoals :

  • een betere aansluiting tussen de bedrijfsvoering en de toepassingen door de Real World Modelling van objectoriŽntatie;
  • hergebruik van bestaande componenten in nieuwe toepassingen;
  • grotere flexibiliteit van de toepassingen, waardoor sneller aanpassen op veranderingen in de bedrijfsvoering mogelijk is.

Hieronder volgt een overzicht van de actuele ontwikkelingen op het gebied van objecttechnologie.

ObjectgeoriŽnteerde programmering
De ontwikkeling van objectoriŽntatie is in het begin van de jaren zestig begonnen met objectgeoriŽnteerde programmeertalen. Velen zien de taal Simula van de Noren Kristen Nygaard en Ole-Johan Dahl als de eerste objectgeoriŽnteerde taal. Simula is bedoeld voor het ontwikkelen van simulatietoepassingen. Anderen beschouwen Smalltalk als de eerste echte objectgeoriŽnteerde taal. Onderzoekers van het Xerox Palo Alto Research Centre hebben Smalltalk eind jaren zestig ontwikkeld als programmeertaal waarmee zij de eerste GUI met muis konden realiseren. Dit GUI van Xerox is de basis voor alle latere GUI's zoals Apple Macintosh en Microsoft Windows, terwijl Smalltalk het uitgangspunt is voor de latere ontwikkelingen op het gebied van objectoriŽntatie.

De huidige beschikbare objectgeoriŽnteerde talen zijn te verdelen in twee groepen. De eerste groep bestaat uit de zuivere objectgeoriŽnteerde talen, die volledig gebaseerd zijn op het objectparadigma. De belangrijkste hiervan is Smalltalk.

De tweede groep objectgeoriŽnteerde talen bestaat uit extensies van andere talen. De belangrijkste hiervan is C++, een extensie van de taal C, die ontwikkeld is door Bjarne Stroustrup. C++ ligt duidelijk als een schil rond C, waardoor de programmeur naast C++ nog steeds C-code in zijn programma's kan opnemen. Bij een taal als Smalltalk is dit overschakelen tussen objectgeoriŽnteerd programmeren en conventioneel programmeren niet mogelijk. Dit is de reden dat men C++ niet beschouwt als een zuiver objectgeoriŽnteerde taal. Op dit moment is C++ de meest gebruikte objectgeoriŽnteerde taal.

Het meest aantrekkelijke van objectgeoriŽnteerde talen is de hoge mate van hergebruik van bestaande objectdefinities (classes) in nieuwe toepassingen. De basiscomponent voor de constructie van een toepassing is niet langer een regel van een programmeertaal, maar een class die een object definieert. De classes staan in een zogenaamde class library. De programmeur is dus voornamelijk bezig de class library te doorzoeken en uit bestaande classes zijn toepassingen samen te stellen. Alleen wanneer een object nodig is met een nog niet bestaande functionaliteit, zal de programmeur een nieuwe class moeten specificeren.

Een objectgeoriŽnteerde taal geeft de mogelijkheid toepassingen met een hogere orde van bouwstenen te creŽren. Dit is te vergelijken met het gebruiken van bouwelementen voor een huis. Een toepassing bouwen met een conventionele taal werkt als het bouwen van een huis uit losse onderdelen zoals stenen en dakpannen. In een objectgeoriŽnteerde taal kun je de classes zodanig definiŽren dat het bouwen van een toepassing werkt als het bouwen van een huis uit kant-en-klare elementen. In de class library neem je als het ware de kant-en-klare muren, vloerdelen en daken op, waaruit je de toepassing als een prefab-huis kunt bouwen.

Een objectgeoriŽnteerde taal vereenvoudigt het definiŽren van classes door overerving (inheritance). De definitie van classes is hiŽrarchisch. Classes lager in de hiŽrarchie erven eigenschappen over van de classes hoger in de hiŽrarchie. Dit betekent dat een class in principe dezelfde methoden heeft als de direct bovenliggende class in de hiŽrarchie. De ontwikkelaar kan dit veranderen door de lagere class een eigen definitie te geven voor een bepaalde methode of door de class de methode niet te laten gebruiken. Verder voegt hij aan de class extra methoden toe.

Een voorbeeld is dat alle classes een methode moeten hebben voor printen. De hoogste class in de hiŽrarchie heeft de methode 'print'. De lagere classes erven alle deze methode over, maar zullen vaak hun eigen invulling ervan hebben.

Een belangrijke toepassing van overerving is generalisatie en specialisatie. Dit houdt in dat een hiŽrarchie wordt gedefinieerd van aan elkaar verwante objecten, bijvoorbeeld 'vloerdelen' ten behoeve van een CAD-toepassing voor huizen. Eerst definieert men een class met de generieke eigenschappen van vloerdelen. Daaronder definieert men classes van speciale vloerdelen. Deze lagere classes erven de generieke eigenschappen over en de ontwikkelaar voegt er extra methoden en gegevens aan toe voor de specifieke eigenschappen van het speciale vloerdeel. Het resultaat is een hiŽrarchie van classes voor vloerdelen. Bij iedere objectgeoriŽnteerde taal zijn gespecialiseerde class libraries te koop voor specifieke toepassingsgebieden. De benaming hiervoor is een framework. Er bestaan bijvoorbeeld frameworks voor GUI's.

De ontwikkelaar moet beschikken over voldoende kennis van het toepassingsgebied waarvoor hij toepassingen bouwt. Alleen dan kan hij van tevoren een framework met de juiste classes definiŽren, waaruit hij de toepassingen kan samenstellen. Classes in een framework definiŽren doorgaans complexe objecten die zelf weer gebruik maken van meer elementaire objecten uit de class library van de objectgeoriŽnteerde taal. De relatie tussen het complexe object en de elementaire objecten is als die tussen een muur en de samenstellende stenen.

Beschikt de ontwikkelaar over een goed framework met classes voor een bepaald toepassingsgebied, dan heeft hij niet alleen het voordeel van hergebruik van classes maar ook van flexibiliteit van toepassingen. De toepassingen zijn immers samengesteld uit met elkaar en met de gebruiker communicerende objecten van diverse classes. Iedere toepassing is dus een netwerkorganisatie van objecten. Een toepassing wijzigen betekent dan ook het wijzigen, toevoegen of verwijderen van classes waarvan objecten aan de toepassing deelnemen. Dit betekent zowel een wijziging van de deelnemende objecten aan de toepassing, als een wijziging in de organisatie van de interactie tussen de objecten.

De hiervoor beschreven eigenschappen maken objectgeoriŽnteerd programmeren bijzonder geschikt voor bepaalde toepassingsgebieden. De huidige toepassingen richten zich vooral op besturingssystemen, grafische gebruikersinterfaces, simulatieprogramma's, tekenpakketten, Computer Aided Design (CAD) met zowel ontwerpen als simuleren van produkten, Computer Aided Software Engineering (CASE), geografische informatiesystemen en multimediatoepassingen.

Op dit moment past men objectgeoriŽnteerd programmeren vooral toe voor PC's, werkstations en kleine servers en nog nauwelijks voor bedrijfstoepassingen op mainframes.

ObjectoriŽntatie en de systeemontwikkeling
ObjectoriŽntatie heeft grote gevolgen voor de gehele systeemontwikkeling. Ontwikkelaars moeten hun methoden en manier van werken wijzigen. Ook de overige faciliteiten, zoals ontwikkelplatformen, databases, programmeertalen en besturingssystemen, dienen geschikt te zijn om objectoriŽntatie te ondersteunen.

Bovendien betekent overstappen naar objectoriŽntatie een duidelijke breuk met de conventionele aanpak van systeemontwikkeling. Dat komt omdat bij objectoriŽntatie een toepassing een object is dat bestaat uit gegevens en functies. Objecten zijn vooral geschikt voor het nabootsen, ontwerpen en simuleren van bedrijfsobjecten en bedrijfsprocessen. Met objecten kunnen we eenvoudiger 'levensechte' gegevens over het gedrag van bedrijfsobjecten en bedrijfsprocessen vastleggen. Ook zijn objecten geschikt voor de geautomatiseerde besturing en uitvoering van bedrijfsprocessen.

In de conventionele werkwijze is een toepassing een programma. Programma's zijn globaal te verdelen in batch-programma's met als interface invoerbestanden en uitvoerbestanden, en on line-programma's die een interface hebben met de gebruiker via een beeldscherm. Kenmerkend voor de conventionele werkwijze is de scheiding tussen programma's en gegevens. De gegevens die de programma's raadplegen en bewerken staan apart opgeslagen in een gemeenschappelijke database. Dit betekent dat de programma's vooral geschikt zijn voor het opslaan en bewerken van gegevens in databases en voor geautomatiseerde gegevensverwerking zoals salarisberekeningen en het printen van overzichten. Conventionele toepassingen ondersteunen daarom voornamelijk de automatisering van gegevensverwerkende processen en het bewaren van gegevens en maar zelden het nabootsen, simuleren en besturen van de bedrijfsobjecten en bedrijfsprocessen.

De aard van de toepassingen is ook bepalend voor de methoden van analyse en ontwerp die de systeemontwikkelaars gebruiken. Bij de conventionele toepassingen is er historisch gezien een verschuiving naar gegevensgericht ontwerpen.

Aanvankelijk stonden bij het ontwerpen van batch-systemen de bedrijfsprocessen centraal. Bij dit procesgerichte ontwerp vormen de gegevensverwerkende bedrijfsprocessen die men wil automatiseren het uitgangspunt. Primair ontwerpt men het geautomatiseerde proces in de vorm van programma's en secundair ontwerpt men de gegevens in de vorm van bestanden.

Met de opkomst van databases en on line-toepassingen gaat men gegevensgericht ontwerpen. Hierbij zijn de bedrijfsgegevens die men wil vastleggen in het informatiesysteem het uitgangspunt. Het doel van dit soort systemen is het verbeteren van wat men in Nederland de informatievoorziening van het bedrijf noemt. Beter is te spreken van het gegevensbeheer (datamanagement). Primair modelleren we de bedrijfsgegevens in een gegevensmodel. Het gegevensmodel bestaat uit entiteiten die betrekking hebben op bedrijfsobjecten en bedrijfsprocessen waarover we gegevens willen vastleggen. Op basis van het gegevensmodel ontwerpt men de database, waarin deze gegevens worden opgeslagen. Secundair ontwerpt men de toepassingen in de vorm van on line-programma's waarmee de gebruiker de gegevens kan bewerken en raadplegen. Ook bestaande en nieuwe batch-programma's gaan gebruik maken van gegevens in de database.

De objectoriŽntatie betekent andere uitgangspunten voor de ontwikkelaars. Uitgangspunt voor de analyse zijn nu de bedrijfsobjecten en de bedrijfsprocessen, die beide gemodelleerd worden als gegevensobjecten voor het informatiesysteem. Het gegevensobject omvat de gegevens die men wil vastleggen, de functies die men wil uitvoeren en de interfaces met andere gegevensobjecten en met de gebruiker. Heeft het object een interface met de gebruiker, dan ontwerpt men ook de presentatie aan de gebruiker en de functies in de vorm van gereedschappen waarmee de gebruiker het object kan bewerken.

Het ontwerp richt zich vervolgens op de realisatie van de gegevensobjecten in de vorm van classes in een objectgeoriŽnteerde taal.

Het objectgeoriŽnteerd systeem is dan ook geschikt voor meer dan alleen beheer van gegevens. Het is geschikt voor het beheer en het gebruik van objecten die samen de toepassingen vormen waar de gebruiker mee werkt. De wijze waarop objecten in een toepassing met elkaar samenwerken, sluit goed aan op de idee van netwerkorganisaties van mensen en bedrijven. In deze netwerkorganisaties hebben mensen en bedrijven een bepaalde mate van autonomie en werken zij in wisselende samenwerkingsverbanden.

In een informatiesysteem hebben objecten ook een bepaalde mate van autonomie, omdat ze een zelfstandige eenheid zijn van gegevens, functies en interfaces met andere objecten en met gebruikers. Hun autonomie is afhankelijk van de mate waarin ze hun eigen functies besturen. Iedere toepassing is te beschouwen als een samenwerking van een aantal objecten.

Er zijn nog weinig ontwikkeltools die de systeemontwikkeling van objectgeoriŽnteerde toepassingen ondersteunen. Op dit moment zijn CASE-leveranciers bezig objectgeoriŽnteerde extensies aan hun produkten toe te voegen. Dit betreft vooral ondersteuning van objectgeoriŽnteerde analyse en ontwerp. Voor de programmering maakt men gebruik van een ontwikkeltool voor een bepaalde objectgeoriŽnteerde taal. GeÔntegreerde objectgeoriŽnteerde ontwikkelplatformen die analyse, ontwerp en programmering van objectgeoriŽnteerde toepassingen ondersteunen, zijn beperkt beschikbaar.

Databases en besturingssystemen voor objecten
Er zijn slechts weinig objectgeoriŽnteerde database-managementsystemen beschikbaar om objecten te kunnen opslaan. Deze zijn dringend nodig om - net als nu gegevens in een gegevensbank - objecten in een objectbank te kunnen beheren.

De naam objectgeoriŽnteerd DBMS (OODBMS) is eigenlijk niet juist. Het is beter te spreken van een Objectbase Management System (OBMS) of Object Storage System. Een OBMS is te beschouwen als een programma (bij objectoriŽntatie dus een object) dat een parkeerplaats van objecten beheert. Het OBMS parkeert objecten die niet in het computergeheugen actief zijn op een extern opslagmedium, bijvoorbeeld een magnetische schijf.

Het OBMS slaat van ieder object de gegevens op met een verwijzing naar de functies van het object. De functies van de objecten staan apart opgeslagen als kleine programma's.

Een gebruiker kan het OBMS raadplegen en een object 'openen'. Het OBMS haalt de gegevens van het object en de functie om het object te presenteren naar het computergeheugen en start de functie. Het object verschijnt op het scherm en de gebruiker kan via zijn werkstation opdrachten geven voor andere functies van het object. Het OBMS zal dan ook deze functies ophalen en uitvoeren. Wanneer de gebruiker het object 'sluit', slaat het OBMS de gegevens van het object weer op het externe medium op.

Een object waar de gebruiker mee werkt, kan ook vragen stellen aan andere objecten. In dat geval opent het OBMS ook die objecten en voert het de gevraagde functies uit.

We zien dat het OBMS zowel de taken van een DBMS - opslaan en ophalen van gegevens uit een database - als van een besturingssysteem - laden en starten van programma's uit een programmabibliotheek - uitvoert.

Een goed OBMS is dus altijd tegelijkertijd een besturingssysteem. Een dergelijke integratie van besturingssysteem, programmabibliotheek en DBMS in de vorm van een OBMS is nog niet beschikbaar. De nu beschikbare OBMS'en zoals Gemstone en ONTOS zijn minder geschikt voor zakelijke toepassingen die moeten voldoen aan hoge eisen van beveiliging en betrouwbaarheid. Belangrijke DBMS-leveranciers zoals Oracle en IBM zijn bezig hun DBMS'en van objectgeoriŽnteerde extensies te voorzien. Dit type objectgeoriŽnteerde DBMS'en maakt gebruik van de faciliteiten voor beheer en beveiliging van het onderliggende relationele DBMS en zijn daardoor beter geschikt voor zakelijke toepassingen.

4.4.3 Samenvatting

Er is een duidelijke trend om bij de ontwikkeling van toepassingen steeds meer objectoriŽntatie toe te passen. Zowel leveranciers van softwarepakketten als ontwikkelaars van maatwerktoepassingen gaan steeds meer objectoriŽntatie gebruiken. De reden hiervoor is dat objectoriŽntatie duidelijke voordelen biedt boven de conventionele aanpak met gescheiden programma's en gegevens.

Het bouwen van toepassingen volgens het objectparadigma kent op dit moment ook nog een aantal beperkingen. De verwachting is dat deze beperkingen de komende vijf jaar verdwijnen, door verdere uitbreiding en daarmee vereenvoudiging van de objecttechnologie. Het toepassen van objectoriŽntatie en de ervaring van ontwikkelaars ermee zullen daardoor snel toenemen.

We noemen tenslotte in het kort nog eens de belangrijkste voordelen en beperkingen van objectoriŽntatie.

Voordelen

Nabootsen van de werkelijkheid
Met objectoriŽntatie kunnen we het uiterlijk en het gedrag van processen en objecten in de werkelijkheid nabootsen. De gebruiker krijgt zo op zijn werkstation een voor hem goed herkenbare werkelijkheid afgebeeld en hij wordt optimaal ondersteund bij al zijn werkzaamheden.

Flexibiliteit
Bij objectoriŽntatie is een toepassing in feite een verzameling met elkaar samenwerkende objecten. Voor de gebruiker levert dit grote flexibiliteit op.

Aanpasbaarheid
De relatie tussen de gegevensobjecten in het informatiesysteem en objecten en processen in de werkelijkheid vereenvoudigt het wijzigen van toepassingen.

Herbruikbaarheid
Flexibiliteit en aanpasbaarheid krijgen extra ondersteuning door de mogelijkheid van hergebruik van bestaande classes (objectdefinities) in nieuwe toepassingen.

Beperkingen

Onvoldoende beschikbaarheid objecttechnologie
Om objectoriŽntatie echt goed te kunnen toepassen, dienen ook objectgeoriŽnteerde database-managementsystemen, besturingssystemen en beheertools beschikbaar te komen, bij voorkeur geÔntegreerd in ťťn objectbase-managementsysteem.

Onvoldoende standaarden
Op het gebied van objectoriŽntatie zijn nog onvoldoende standaarden. Een belangrijke organisatie op dit terrein is de Object Management Group (OMG) die bezig is de Common Object Request Broker Architecture te definiŽren. Centraal in deze CORBA-standaard staat de Object Request Broker, een functie die de communicatie tussen objecten in gedistribueerde toepassingen ondersteunt

Aansluiting op de bestaande toepassingen
Op dit moment is er een grote hoeveelheid conventionele toepassingen die niet conform de principes van objectoriŽntatie werken. Bovendien past men objectoriŽntatie vooral toe op werkstations en PC's en niet op mainframes. Dit is reden voor het ontstaan van mengvormen van objectgeoriŽnteerd en conventioneel ontwikkelen

Gebrek aan ervaring bij ontwikkelaars
Ontwikkelaars hebben nog onvoldoende ervaring met objectoriŽntatie.

Voordelen pas op termijn
Bedrijven moeten investeren om objectoriŽntatie te kunnen toepassen. De voordelen van objectoriŽntatie, zoals flexibeler en beter aanpasbare toepassingen en lagere ontwikkelkosten door hergebruik, worden pas op termijn merkbaar. De reden hiervan is dat men eerst over voldoende herbruikbare definities van objecten moet beschikken voor nieuwe toepassingen. Ook moet men voldoende bestaande toepassingen ombouwen naar objectgeoriŽnteerde toepassingen.

vorigvolgende
website: Daan Rijsenbrij