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.