Brontekst bekijken van Architectuur/oud/leerboek in wordingD. Bouwen voor principes

<noinclude>{{contents}}</noinclude>
{{kweeste|Dit hoofdstuk richt zich tot aankomende IT-architecten met een zekere achtergrond in informatica. Het is ook interessant voor belanghebbenden die met architecten moeten praten en willen weten hoe de architect zijn opdracht aanpakt. En voor informatici die willen weten waarom hun doelgerichte methoden niet altijd kunnen werken.

Hoe komen we erachter wat eigenlijk precies gebouwd moet worden?}}
{{Literatuur|
* [[Beweren en bewijzen]]
** [[Beweren en bewijzen/de zuilen/Formalisering/4. Correctheidsstelling|Correctheidsstelling]]
* [[Taxonomy/1. Quality]]
** [[Taxonomy/1. Quality/04. Correctness Theorems|Correctness Theorems]]
*{{pencast|type=college|thema=van rationaliteitsvierkant naar principes|url=http://www.livescribe.com/cgi-bin/WebObjects/LDApp.woa/wa/MLSOverviewPage?sid=DbsVRSGgQcgn}}
** De foto's bij pagina 2 van deze pencast staan [[Architectuur/2. Casuïstiek/Apostolische Nuntiatur Berlin|hier]].
* [[Gebruiker:Royce Benda/outlines/principes]]
}}

=== Construeren als tam probleem ===
Ingenieurs kunnen bruggen en Eiffeltorens ontwerpen en laten realiseren die niet instorten. Dit proces noemen we &bdquo;constructie&rdquo;. Het verloopt min of meer als volgt: De ingenieur krijgt de specificatie van de brug (waar? hoe lang en breed? welk verkeer moet eroverheen en eronderdoor?), kiest een materiaal dat hij beheerst en dat ter plaatse beschikbaar is (hout, staal, beton, lianen, baksteen), maakt conform de ene of andere methode een ontwerp, rekent dit ontwerp door, laat het door een aannemer uitvoeren en controleert de kwaliteit van de uitvoering. Het ontwerpen en doorrekenen kan hand in hand gaan. Tegenwoordig helpen computersystemen bij dit proces.



De informatica leert hoe men voor een gegeven specificatie een systeem kan ontwerpen en realiseren en hoe men hard kan maken dat het inderdaad aan deze specificatie voldoet.
Een informaticus zou vragen: Wat is de juiste specificatie? Soms, bijvoorbeeld bij {{*|embedded system}}s is dit eenvoudig te bepalen. Een fysiek artefact (voertuig, vliegtuig, fabriek o.i.d.) is gegeven. Gezocht is de specificatie voor een computerprogramma dat het artefact veilig bestuurt en ervoor zorgt dat het zijn doel bereikt.

Vaak is echter helemaal niet duidelijk wat men eigenlijk wil hebben, terwijl de opdrachtgever of bouwheer met allerlei wensen komt, misschien met een specificatie, gebaseerd op allerlei aannames in zijn hoofd die niet kloppen. Een goede architect vraagt dan door: Maar waarom zou je zoiets willen hebben?
In [[Beweren en bewijzen]], [[Introductie Informatica en Informatiekunde]] en een aantal andere cursussen is de ''{{*|Correctheidsstelling}}'' een fundamentaal uitgangspunt. De onderliggende metatheorie is uitgelegd in de eerste hoofdstukken van [[Taxonomy/1. Quality]]. Hier een samenvatting:

De eenvoudigste vorm van de correctheidsstelling is:

'''s<sub>1</sub>, ... , s<sub>n</sub> &#x22a2; S'''

Begrip van de correctheidsstelling helpt bij het oplossen van twee klassen van {{*|tam probleem|tamme problemen}}:

;Van specificatie naar ontwerp:Hier is een specificatie '''S''' gegeven, hetzij in natuurlijke taal, hetzij formeel. Ook de ontwerpruimte is bekend. Binnen die ontwerpruimte wordt een ontwerp '''s<sub>1</sub>, ... , s<sub>n</sub>''' gezocht dat aan de specificatie voldoet. Voorbeeld: &bdquo;ontwerp een kaartjesautomaat&rdquo;.

;Wat is de specificatie van een onderdeel van een artefact?: Hier wordt de specificatie '''s<sub>n</sub>''' voor een nog ontbrekend onderdeel van een groter geheel gezocht. De specificatie '''S''' van het groter geheel is gegeven, en de overige onderdelen zijn bekend. De specificaties van de omringende onderdelen '''s<sub>1</sub>, ... , s<sub>n-1</sub>''' zijn gegeven of kunnen worden gereconstrueerd omdat de onderdelen zelf er zijn. Voorbeeld: &bdquo;gegeven is een kaartjesautomaat, op het embedded computerprogramma na. Wat is de specificatie van een programma dat het geheel tot een goed functionerend kaartjesautomaat maakt?&rdquo;

Voor beide klassen van problemen heb je niet per se een breed opgeleide architect nodig. Evenmin is het nodig om te praten over &bdquo;principes&rdquo;, want de begrippen &bdquo;specificatie&rdquo; en &bdquo;correctheid&rdquo;zijn voldoende.

{{classificatie|problemen|
* We noemen een probleem '''tam''' als duidelijk is wat het probleem precies is en er duidelijke criteria zijn om te bepalen of een oplossing een correcte oplossing is. Tamme problemen kunnen overigens best moeilijk zijn.
* We noemen een probleem '''gemeen''' als niet duidelijk is wat eigenlijk het probleem is &ndash; en dus ook niet duidelijk of een voorgestelde oplossing een juiste oplossing is. Soms blijkt dat de oplossing van een gemeen probleem veel eenvoudiger is dan gedacht.
}}

=== Bouwen als gemeen probleem ===
Anders is het bij {{*|gemeen probleem|gemene problemen}} &ndash; en daarmee bij de meeste grote bouwprojecten. 


''Veel programmeurs, ontwerpers, ontwikkelaars en adviseurs hebben prima geleerd hoe ze tamme problemen kunnen oplossen, maar nooit bewust over gemene problemen nagedacht. Ze hebben dan de neiging, gemene problemen te benaderen als waren ze tam. Dit leidt dikwijls tot schijnoplossingen waarop niemand zat te wachten.''


Als een groot (fysiek of digitaal) bouwwerk moet komen, is een nauwkeurige specificatie meestal ver te zoeken. In overleg met de bouwheer en op basis van zijn kennis van theorie en materiaalkunde ontwerpt de architect in gedachten (of op papier of in de computer) een gebouw. Hij (m/v) heeft daarbij misschien een exacte specificatie ergens in zijn achterhoofd, maar deze wordt doorgaans niet expliciet opgeschreven. Wel opgeschreven wordt de {{*|blauwdruk}} '''B''' die de aannemer krijgt om het gewenste bouwwerk te kunnen realiseren. De regels  '''G''' voor gebruik en beheer, die de architect samen met '''B''' heeft ontworpen, worden helaas niet altijd opgeschreven. 

Wanneer is '''B''' samen met '''G''' &ndash; en daarmee het geplande bouwwerk &ndash; goed? En hoe moet de architect dat bereiken?

===Eisen van belanghebbenden===
{{classificatie|belanghebbenden|
 bouwheer                 aannemer
             architect
 gebruikers               omgeving
}}
Elke belanghebbende verwoordt zijn belangen in eisen of wensen aan het te bouwen artefact. In een organisatie zijn de belangen van de directie (de bouwheer) bijvoorbeeld verwoord in strategische uitgangspunten. Strategische uitgangspunten zijn uitspraken om richting te geven aan de strategie van een organisatie.

Voorbeelden van eisen zijn:

* ''De webservice moet 24/7 beschikbaar zijn.''
* ''Elke bewoner van het huis moet zijn eigen leefruimte hebben.''
* ''Wij streven naar het ontwikkelen van de beste oplossingen voor onze klanten.''

Eisen zijn gewoonlijk geformuleerd in de taal van de belanghebbende en geven een indicatie van hetgeen deze persoon of instantie met het gebouw wil. Maar ze kunnen misleidend zijn en moeten niet per se letterlijk worden genomen. Bijzonder gevaarlijk zijn eisen in termen van oplossingen. Zij kunnen de architect op het verkeerde spoor zetten. Misschien is een heel andere oplossing veel beter voor het achterliggende probleem. De architect moet daarom doorvragen.

===Principes===
Aan deze eisen liggen principes ten grondslag die het fundament voor het ontwerp vormen. Principes zijn abstract en integraal voor het hele gebouw, en eisen zijn daarvan bewust of onbewust afgeleid. Het is aan de architect om de eisen terug te vertalen naar principes. Voor de voorbeelden van eisen kunnen we nu principes vaststellen:

* ''Beschikbaarheid''
* ''Privacy''
* ''Kwaliteitsgarantie''

Principes zijn te verbijzonderen naar regels voor gebruik en ontwerpbeslissingen.

Maar dit is nog lang niet alles. Een goede architect weet dat ook principes belangrijk kunnen zijn, waar de belanghebbenden zelf niet zo gauw aan denken. De architectuurbegrippen in de volgende hoofdstukken gaan daar over. De architect zal dus de lijst van principes uitbreiden.

===Ontwerpbeslissingen===
Uit principes kan de architect ontwerpbeslissingen herleiden. Een ontwerpbeslissing is een belangrijke begrip voor de communicatie naar belanghebbende en moet dan ook aan enkele voorwaarden voldoen. Een ontwerpbeslissing laat zien welke afweging de architect maakt bij het ontwerpen van het gebouw. Door deze afweging expliciet te maken kan deze voorgelegd worden aan de betrokken belanghebbende en kan de opdrachtgever of gebruiker oordelen of dit een gewenste afweging is. Ontwerpbeslissingen zijn een middel voor de architect om aan de belanghebbenden duidelijk te maken wat de impact van een beslissing is op het gebouw. Voor het defini&euml;ren van een ontwerpprincipe gebruiken we het stramien voor principes uit Dragon1 van Mark Paauwe [http://www.paauwe.info/research/kenniscentrum/whitepapers/whitepaper-architectuurprincipes Architectuurprincipes]. Dragon1 maakt onderscheid tussen 3 delen van een principe die ideaal bruikbaar zijn voor het vastleggen van een ontwerpbeslissing:

# Hoe werkt het of hoe is het gedaan?
# Wat wordt hierdoor mogelijk of onmogelijk?
# Waar kan dit voor gebruikt worden?

Op deze manier laat men eenduidig aan bijvoorbeeld een gebruiker zien wat de gevolgen van een afweging zijn. Voor het principe beschikbaarheid zullen we een ontwerpbeslissing uitwerken:

'''Door''' een extra noodaggregaat voor de webserver te plaatsen '''wordt gezorgd dat''' de webserver toegang tot stroom heeft als de vaste stroomtoevoer wegvalt '''zodat''' de webapplicatie beschikbaar is voor klanten als de vaste stroomtoevoer uitvalt.

Door een dergelijke formulering reduceert de architect complexiteit en maakt hiermee aan de belanghebbende duidelijk wat de impact van een beslissing is. Bij het opstellen van een ontwerpbeslissing wordt gelijk de verantwoording van deze keuze duidelijk. Doordat de architect niet alleen zegt hoe hij iets gaat doen maar mede met welke reden dit gebeurt, wordt voor de belanghebbende inzichtelijk of zijn belang is behartigd.

===Regels voor gebruik===
Naast ontwerpbeslissingen, die uitspraken doen over het gebouw zelf, zijn uit principes regels af te leiden die uitspraken doen over het gebruik van een gebouw. Deze regels zeggen iets over hoe de gebruikers van het gebouw zich dienen te gedragen binnen het gebouw. Een voorbeeld van het ontbreken van communicatie over deze regels voor gebruik is een website voor een organisatie of vereniging. De informatiseringsgolf heeft tot vele voordelen geleid, maar &eacute;&eacute;n van de gevolgen is geweest dat elk bedrijf het idee heeft zich ook digitaal te moeten profileren.
Een directeur van een middelgrote onderneming wil een digitale poort naar het bedrijf en besluit het bedrijf een website aan te meten. Hij geeft een webdesign bedrijf (Is dit de architect of een aannemer?) de opdracht een website voor zijn organisatie te bouwen. De directeur maakt duidelijk wat hij op de website wilt hebben, en &eacute;&eacute;n maand later is zijn website online. Het webdesign bedrijf vermeldt niet dat het meeste werk en kosten in het onderhouden van de website zit. Gevolg: de directeur ontdekt na een maand dat de informatie op de website verouderd is, maar er blijkt geen budget te zijn om iemand aan te stellen die de website onderhoudt.
We zien dat regels voor het gebruik van het gebouw van essentieel belang zijn om te zorgen dat het gebouw voldoet aan de belangen van de verschillende partijen. Daarnaast zou je je voor dit voorbeeld kunnen afvragen of het ontbreken van deze regel te wijten is aan het ontbreken van een architect.

We kunnen hieruit afleiden dat principes het fundament vormen voor het gebouw en het ontwerpen van het gebouw. Principes zijn onderliggend aan de eisen van de bouwheer, aannemer, gebruikers en de omgeving. Uit deze principes ontstaan ontwerpbeslissingen met betrekking tot het gebouw en regels voor gebruik van het gebouw. Ontwerpbeslissingen maken aan belanghebbenden duidelijk hoe de keuze in het ontwerp werkt en wat de impact is. Regels voor het gebruik geven aan wat gewenst gedrag is van gebruikers van het gebouw.


*Een goede regel is onderdeel van een consistent stelsel van regels die met elkaar en samen met het gebouw in dienst van de heersende principes staan. Een regel waarvan niet duidelijk is in dienst van welke principes ze staat, verdient herziening.
*Regels zijn er op allerlei niveaus en voor diverse foci. Ook gelden voor verschillende belanghebbenden verschillende regels. Die kun je beter niet allemaal op &eacute;&eacute;n hoop gooien. Bijvoorbeeld:
**Regels van de overheid die gelden voor elk gebouw en waaraan de architect zich moet houden tijdens het ontwerpen (brandveiligheid, evacueerbaarheid, stabiliteit, ...). Deze zijn vooral interessant als de architect hiervoor een unieke oplossing gevonden heeft. Focus: het architectuurbureau en de omgeving van het te maken gebouw.
**Regels waaraan de architect zich houdt omdat ze in de dienst van zijn eigen principes staan (duurzaamheid? herkenbaarheid? materiaalkeuze? vormgeving?). Niet alle architecten leggen zich zulke regels op. Focus: het architectuurbureau.
**Regels die gelden voor de hele organisatie van de bouwheer, dus ook bij het gebruik van het (fysieke of digitale) gebouw waarover het gaat (alles moet zwaar beveiligd worden, op elke plek moet het logo staan, elke gast moet door een dame in mantelpak worden opgevangen, elke klant moet op elk moment een product kunnen betalen, ...). Focus: het gebouw in zijn omgeving.
**Regels die de architect ''samen met het bewuste gebouw'' heeft ontworpen omdat alleen gebouw en regels samen de nodige principes waarmaken. Die zijn voor ons bijzonder interessant. Focus: het gebouw zelf. Men kan ze weer onderverdelen in
***Regels voor de gebruikers van het gebouw (sluit de ramen als je je kamer verlaat, heb altijd een sleutel op zak, heb nooit een sleutel op zak, ...),
***Regels voor onderhoud en aanpassing van het gebouw (gebruik een bepaald wandsysteem om muren te verplaatsen).

=== Het bouwprobleem ===
Nu kunnen we formeler noteren waar het om gaat.

Het gewenste artefact moet voldoen aan de bedrijfsprincipes van de bouwheer en de principes van andere belanghebbenden (brandveiligheid, bestendigheid tegen aardbevingen, duurzaamheid enz.). De principes zijn herleid uit de eisen die verschillende belanghebbenden aan het gebouw stellen. Deze principes zijn geen specificaties; daarvoor zijn ze veel te abstract en soms ook te vaag. Bovendien zijn ze vaak tegenstrijdig, zoals ''veiligheid'' en ''doorstroming'' in het verkeer. Laten we deze verschillende principes, ook al kunnen ze niet exact opgeschreven worden, '''P''', '''Q''', '''R''', ... noemen.

Tijdens het ontwerpen van het artefact zal de architect samen met de bouwheer allerlei afwegingen maken en de principes '''P''', '''Q''', '''R''', ...  oprekken tot afgezwakte versies '''P'<!-- -->''', '''Q'<!-- -->''', '''R'<!-- -->''', ... die niet meer onverenigbaar zijn. Waarbij het zou kunnen dat een andere combinatie van andere afzwakkingen voor de bouwheer en de overige belanghebbenden even acceptabel is. Een beetje meer veiligheid of juist een beetje betere doorstroming.

Men kan niet zonder bijbehorende regels. Hoe veilig kan een brug zijn als je daar ook bij orkaan, ook met een tank en met een raceauto met 300km/u op mag rijden? Daarom is het redelijk, te verlangen dat alle belanghebbenden (ja, ook de orkaan) zich houden aan bepaalde regels.

Het ontwerp (blauwdruk van het bouwwerk en bijbehorende regels) is dan goed, als  '''B &and; G &#x22a2; P' &and; Q' &and; R' &and;...''' .

In de IT wordt vaak verzuimd, de bouwheer te doordringen van het belang van deze gebruiksregels '''G'''. Bijvoorbeeld is een website alleen goed als deze regelmatig geactualiseerd wordt. Hoeveel voorbeelden ken je waar dat niet gebeurt?

=== Principes van de architect ===
Door zijn opleiding ziet een goede architect meer dan de belanghebbenden misschien zien en weet hij hoe men dit kan bereiken: een goed bouwwerk moet degelijk in elkaar zitten en bij de mensen en de wereld passen. Bouwheren en aannemers willen dat nog eens vergeten. Deze principes worden in de volgende hoofdstukken besproken. Het is aan de architect te beslissen in hoeverre ze bij een specifiek project van toepassing zijn.