stond dat paste in de beschikbare geheugen
ruimte. Structuur en architectuur stonden niet
voorop bij de ontwikkeling van software; veel
eer werden homogene, praktisch structuurloze
programma's gebouwd die de voorradige ge
heugencellen op optimale wijze benutten: opti
maal in computertechnische zin. Toen veel
grotere geheugens en snellere elektronika be
schikbaar kwamen, beproefden de systeemana-
lysten steeds omvangrijker systemen te ontwik
kelen. Men ging ertoe over om een dergelijk
groot systeem op te knippen in kleinere delen
modules) die op zichzelf gerealiseerd wer
den; achteraf werden deze delen aaneenge
voegd met inachtneming van de door het op
knippen tijdelijk verbroken relatie.
In een roemrucht artikel*) werd de vinger ge
legd op enige fundamentele problemen die op
traden bij pogingen om omvangrijke systemen
te realiseren. Grote zorgen deden zich voor bij
de introductie van de „derde generatie"-com-
puters, en wel praktisch over de gehele linie
zowel bij computerindustrieën als bij software
houses: elk hunner had wel te kampen met een
groot programmatuur-project dat steeds verder
op het schema ten achter raakte. Als voornaam
ste oorzaak valt aan te wijzen de logheid van
een groot systeem: door de vele interrelaties
is het moeilijk later nog veranderingen aan te
brengen. Iedere verandering, al is deze klein,
kan via de interrelaties vele nevenveranderin
gen vergen.
5. Wiskunde van de structuur
Om te illustreren hoe de delen van een groot
systeem via de interrelaties op elkaar inwerken
nemen wij een voorbeeld:
laat de waarschijnlijkheid dat een verande
ring in één module een verandering in een
andere module vergt gesteld worden op '01
laten er 10 modules zijn
Iedere verandering zal dan gemiddeld in het
totaal 1*11111... veranderingen vergen.
Indien we binnen een module kijken en veron
derstellen dat een verandering in de module
met de waarschijnlijk p een tweede verandering
nodig maakt, dan zal de waarschijnlijkheid dat
we nog een derde verandering moeten maken
p-> bedragen, dat we nog een vierde verande
ring moeten maken p3, etc.
Het totale te verwachten aantal wijzigingen zal
dan worden: 1
l p p2 p3 in
Indien we binnen een systeem met n modules
kijken, dan moeten ook alle interrelaties tussen
de modules gehonoreerd worden; het blijkt dat
de totale hoeveelheid wijzigingen, die men aan
zal moeten brengen als men met één begint
1
1 np n2p2 n3p3 bedraagt.
In ons eerste voorbeeld met n=10 en p="01
is het totale aantal wijzigingen derhalve
rum...
Als tweede voorbeeld nemen we n=100 en
p *01het totale aantal wijzigingen komt dan
wederom op -deze uitdrukking wordt
1np
bij substitutie „opgeblazen". Praktisch wil dit
zeggen dat als men met één wijziging begint
steeds weer een volgende nodig wordt, zodat
men nimmer klaar komt.
Alhoewel het gebruikte systeemmodel vrij grof
is, laat het reeds toe een „feeling" te krijgen
voor de problematiek: zodra een systeem een
kritische omvang overstijgt kan men het sy
steem niet meer wijzigen, ofwel men veroor
zaakt meer ellende dan men heeft kunnen op
heffen! De les die uit het bovenstaande ge
trokken kan worden is dat een terugbrengen
van het aantal interrelaties tussen modules van
een groot systeem van uiterst belang is.
6. Structuurwetenschap
Ruim tien jaren terug is in de hoek van de
bouwarchitectuur een belangrijke bijdrage ver
schenen van de hand van Christopher Alex
ander. Deze gaat in op de interrelaties van
subsystemen bij een bouwwerk. Hij toont aan
dat het eerste doel van het ontwerpproces dient
te zijn het uiteenleggen in een aantal onderling
zo min mogelijk afhankelijke deelsystemen.
Alexander beschrijft een computerprogramma
dat in staat is voor een ingewikkeld ontwerp
proces een dergelijke opsplitsing in deelsyste
men te verzorgen.
Het doel van het opsplitsen in deelsystemen is
volgens Alexander niet slechts het meer han
teerbaar maken van het totale systeem, doch
ook het vervaardigen van een product dat vlot
ter kan worden aangepast. En zulks is belang
rijk in de wereld van vandaag waarin enerzijds
steeds nieuwe eisen gesteld worden en ander
zijds steeds nieuwe materialen geboden worden.
Het primaire doel van modulaire opbouw is
derhalve niet zozeer het verkrijgen van kleine
modules, doch het creëren van mogelijkheden
tot tussentijdse aanpassing: beoogd wordt om
de neveneffecten bij de uitvoering van een
verandering te minimaliseren.
Grosch, H.R.J., „Why MAC, MIS, and ABM won't
fly", Datamation 17 (Nov. 1,1971) pp. 71-72.
280