Bovenstaande voorbeelden geven aan hoe belangrijk het
is dat alle constraints expliciet in het gegevensbank
schema worden vermeld en dat zij worden gecontroleerd
bij de invoer van gegevens. Alleen door in programma's
rekening te houden met alle formeel toegelaten waarden
(ook de meest onwaarschijnlijke), kan worden gegaran
deerd dat alle programma's altijd correct zullen werken.
Alleen door bij invoer van gegevens op alle constraints te
controleren, kan worden gegarandeerd dat de inhoud van
de gegevensbank altijd integer zal zijn.
Gevaar voor flexibiliteit
Behoefte aan flexibiliteit
In het begin van de tachtiger jaren werd aanbevolen om
bij ontwikkeling van een informatiesysteem te beginnen
met het vaststellen van de gegevensstructuur, omdat die
vrijwel niet zou veranderen. In de negentiger jaren geldt
dat argument niet meer. De samenleving wordt steeds
dynamischer. Van bedrijven en overheidsinstellingen
wordt steeds meer een klantgerichte benadering geëist.
Autofabrikanten bieden een steeds grotere keuze aan
modellen en uitvoering. Verzekeringsmaatschappijen
bieden gepersonaliseerde polissen voor steeds meer bij
zondere risico's. De overheid wordt steeds gemakkelijker
in het veranderen van de regels waarop de uitvoering van
allerlei (geautomatiseerde) diensten is gebaseerd. Geo
grafische systemen dienen vaak ter ondersteuning van
zulke diensten en zijn dus ook vaak aan veranderingen
onderhevig.
Het gevolg van deze ontwikkeling is dat de structuur van
de gegevens die de produkten en de levering daarvan be
schrijven, steeds complexer en veranderlijker wordt. Niet
alleen de structuur wordt complexer, ook het aantal
constraints neemt toe en ze veranderen vaker. De
constraints leggen vast welke produkten met welke com
binaties van opties en uitzonderingen wanneer aan wie
mogen worden geleverd en voor welke prijs.
De informatiesystemen die de ontwikkeling en levering
van deze produkten ondersteunen, moeten dus steeds
frequenter worden aangepast. Dat is vaak een groot
probleem, want informatiesystemen zijn van nature niet
erg aanpasbaar. Toch is flexibiliteit een kwestie van leven
of dood. Bedrijven kunnen achterop raken op de concur
rentie als zij hun produkt niet snel genoeg aan de wensen
van de klant kunnen aanpassen. Zij kunnen grote bedra
gen verliezen als gevolg van fouten door niet tijdig of niet
correct aangepaste informatiesystemen. Overheidsinstel
lingen kunnen in grote politieke en financiële problemen
raken als zij hun informatiesystemen niet op tijd aan
nieuwe regels krijgen aangepast.
Gevolg van wijzigen constraints
Het toevoegen of verwijderen van entiteittypen en attribu
ten levert doorgaans niet veel problemen op. De gevol
gen van het toevoegen, verwijderen of wijzigen van een
constraint worden echter gemakkelijk onderschat. Het
toevoegen of sterker maken van een constraint betekent
dat alle programma's die een gegeven kunnen wijzigen
waarnaar die constraint verwijst, moeten worden opge
spoord en aangepast. Het opheffen of verzwakken van
een constraint betekent dat alle programma's die een ge
geven gebruiken waarvan de waarde door die constraint
wordt bepaald, moeten worden opgespoord en zorgvuldig
gecontroleerd op operaties die mogelijk fouten kunnen
veroorzaken.
Vooral het verzwakken van constraints is, merkwaardig
genoeg, bijzonder gevaarlijk. Dit komt doordat con
straints ketens kunnen vormen, waarin de waarde van het
ene gegeven afhankelijk is van het andere. Zo kunnen
verbanden bestaan tussen delen van de gegevensbank
die schijnbaar niets met elkaar gemeen hebben. Het
wijzigen van een constraint in het ene deel kan dan
fouten veroorzaken in programma's die uitsluitend opere
ren op het andere deel. Het volgende voorbeeld moge dit
verduidelijken (zie kader).
Voorbeeld
De hoofdbewoner van een huis moet onroerend-goedbelasting
betalen. Aangezien iemand ook onroerend-goedbelasting ver
schuldigd kan zijn voor een pand dat hij niet meer bewoont, is
er een entiteittype „Bewoning", dat een persoon als hoofd
bewoner voor een bepaalde periode koppelt aan een huis. De
aanslagen worden aan dit entiteittype gekoppeld, en de beta
lingen op hun beurt weer aan de aanslagen. Er is een statistiek
die de ontwikkeling van de gemiddelde betalingsachterstand
per wijk bijhoudt. De wijk waarin een huis staat, kan daarbij
worden afgeleid uit de eerste drie cijfers van het woning
nummer.
De programmeur van het statistiekprogramma heeft het nodig
geacht in een bepaalde bewerking het quotiënt van het be
taalde bedrag en het wijknummer te bepalen. Dat kon hij doen,
omdat bij het entiteittype woning een constraint was opgeno
men, die bepaalde dat het tweede cijfer van het woning
nummer oneven moest zijn. Na een aantal jaren is het aantal
wijken zo toegenomen, dat men voor de keuze staat het
woningnummer uit te breiden of de betreffende constraint op te
heffen. Men besluit tot het laatste. Alle programma's die
toegang hebben tot het entiteittype woning, worden gecontro
leerd. Het betreffende statistiekprogramma haalt het woning
nummer echter uit het entiteittype „Betaling", dat via „Aan
slag" en „Bewoning" aan „Huis" refereert. Men meent dat het
daarom niet behoeft te worden gecontroleerd. Een jaar later
treedt een storing op in het statistiekprogramma.
Kwadratische toename onderhoudsinspanning
De mogelijkheid van bovengenoemd soort fouten maakt
het noodzakelijk om bij elke schemawijziging in principe
alle programma's te controleren. Als men bedenkt dat bij
het toenemen van de omvang van een systeem niet al
leen het aantal programma's, maar ook het aantal wijzi
gingen zal toenemen, is het niet moeilijk in te zien dat de
onderhoudsinspanning toeneemt met het kwadraat van
de omvang. Als die samenhang niet wordt doorbroken,
zou dat betekenen dat er een bovengrens is aan de om
vang, die een systeem kan bereiken. Op een gegeven
moment wordt het namelijk aantrekkelijker om een nieuw
systeem los van het bestaande te ontwikkelen, in plaats
van het bestaande uit te breiden. Dit verschijnsel treedt
veel op. Het leidt echter tot eiland-automatisering, dus
tot een verminderde gebruikswaarde van het systeem.
Modulair ontwerpen biedt een mogelijkheid om dit pro
bleem op te lossen.
Principes van modulariteit
Modu la rite it in programma 's
Een dergelijk probleem deed zich eerder voor in de infor
matica, toen de omvang van programma's steeds groter
werd. Ook toen leek men tegen een soort natuurlijke
bovengrens aan te lopen, omdat het ontwikkelen en
onderhouden van programma's steeds duurder werd.
Modulair ontwerpen werd toen geïntroduceerd als een
methode om delen van programma's afzonderlijk te kun
nen ontwikkelen en testen, en vervolgens tot grote pro
gramma's samen te voegen. Wijzigingen in het grote
programma konden dan worden gerealiseerd door het uit-
320
NGT GEODESIA 93 - 7
