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

Digitale Tijdschriftenarchief Stichting De Hollandse Cirkel en Geo Informatie Nederland

(NGT) Geodesia | 1975 | | pagina 4