GEGEVENSMANAGEMENT II
Okapi in Blijdorp. Leeft in Centraal Afrika, nauwste verwant van de
giraffe. Dit grote zoogdier is pas in 1901 beschreven.
Een paradigma verschuiving
Een gegevensmanager kijkt anders tegen de informatieverwerking aan dan een systeemontwerper/programmeur. Bij GM was het de praktijk dat nieuwe collega’s naar een cursus gingen en daarna een maand of drie door onze locale guru Ronald onder zijn hoede werden genomen om het vak te leren.
We hebben eens een neerlandica en ook een jurist als nieuwe collega gehad. De mensen met een systeemachtergrond, zoals ikzelf, moesten een paradigma shift ondergaan, wat voor de Neerlandica en de Jurist minder nodig was. Maar die hadden uiteraard op andere punten weer meer te leren.
Programmeurs kijken (keken?) vaak naar software als een soort machientje: je stopt er aan de voorkant als input gegevens in, en aan de achterkant komen er als resultaat weer gegevens uit, meestal minder; want we doen aan informatiereductie. Ze denken als het ware vanuit een computer; als de gegevens die erin gaan het gewenste resultaat opleveren dan is het goed.
Gegevensmanagers noemen dit wel “output-modellering”.
Als gm-ers een model voor een bepaald onderwerp ontwikkelen gaan ze er van uit dat de belangrijkste gegevens het resultaat zijn van waarnemingen aan dat onderwerp, samenhangend met doelstellingen die de mensen die bij dat onderwerp betrokken zijn kennelijk nastreven. Met andere woorden:
zij richten zich in eerste instantie op een stukje werkelijkheid waarvoor ze een gegevensmodel gaan ontwikkelen. De betekenis van die gegevens wordt vastgelegd met gestructureerd Nederlands.
De wereld van een jurist of taalkundige kent ook een werkelijkheid waarin ‘het gebeurt’ en een wetboek dan wel een woordenboek annex grammatica waarin normen voor die werkelijkheid gestructureerd beschreven staan. En staan daarmee wat dichter bij gm.
Volledigheidshalve moet ik zeggen dat bij het ontwikkelen van een database uit een gegevensmodel voor een bepaalde toepassing er in een later stadium ook gegevens worden toegevoegd die een afgeleide relatie, of zelfs geen relatie met de werkelijkheid hebben; maar wel een rol in de toepassing gaan spelen.
Ik noem stuurgegevens (hoeveel kopieën er geprint moeten worden), of gegevens overgenomen uit een prijslijst of de postcode-tabel die in de toepassing gebruikt gaan worden. Ook de dagomzet van een afdeling bijvoorbeeld, kan als een afgeleid gegeven, zijnde het totaal van de verkopen van die dag, opgenomen worden.
Gestructureerd Nederlands (een beknopte introductie)
In de post GM I hebben we de term Universe of Discourse (UOD) ingevoerd: een intersubjectieve talige werkelijkheid om communicatie mogelijk te maken tussen de samenwerkende gebruikers van een (beoogd) systeem of groep gerelateerde systemen. De samenwerking wordt uitgedrukt in doelstellingen die nagestreefd worden.
Een UOD kan heel goed over een bedachte werkelijkheid gaan, zoals in een sprookje of in een natuurkundige hypothese.
{Tolkien’s “In de Ban van de Ring” heeft als één na hoogste doelstelling Het in bezit krijgen van de Ring: enkele hoofdrolspelers streven dit doel na. De hoogste doelstelling is Het vernietigen van de Ring.}
En rond zo een UOD over een bedachte werkelijkheid zou je een systeem kunnen bouwen bijvoorbeeld een game; ongetwijfeld kan dat ook met de in het onderstaande geadresseerde taal Eiffel.}
Zie hier een heel summier UOD:
Ik en mezelf. Mijn doel is kennis over vogels rond mijn huis.
Als ik twee merels in de tuin zie die samen een nest aan het bouwen zijn
dan weet ik dat ze een paartje zijn. En ik ken ze individueel want ze horen bij dat nest, de een is het vrouwtje (want bruin) en de ander het mannetje (want zwart, met een gele snavel).
Ik heb te maken met drie entiteiten: merel-1, merel-2, en nest-7.
Ik ga deze kennis structureren in de vorm van beweringen over deze entiteiten.
Beweringen hebben als formele gedaante het triple (A, R, B) waarbij A en B entiteiten zijn, en R een predikaat is.
De string A+R+B vormt een zin met A als onderwerp, en stelt dat voor A geldt R+B. Bijvoorbeeld: merel-1 zit op nest-7.
{Het ‘+’ teken is een binaire operator die twee strings samen plakt tot één}
Een predikaat is typisch een string bestaand uit een paar woorden geschikt om beweringen mee te vormen, het bevat gewoonlijk de persoonsvorm van de zin.
Als we uitgaan van het Universe of Discourse UOD, dan zijn A en B objecten uit de werkelijkheid waarover het gaat. Terwijl de waarnemer ze met het predikaat verbindt en er informatie van maakt.
Essentieel aan een bewering is dat deze waar, maar ook onwaar moet kunnen zijn; falsifieerbaar is. Als hij waar is dan staat hij voor een feit met betrekking tot A in het UOD.
Het nest is ook een entiteit want ik heb de vogels in mijn buurt als Universe of Discourse, en heb een kaartje gemaakt met alle nesten in die ik daar weet. En dit nest is nummer 7 op die kaart.
Van merel-1 weet ik:
- (merel-1, is van geslacht, vrouwelijk)
- (merel-1, hoort bij nest, nest-7)
- (merel-1, vormt een paar met, merel-2)
Van merel-2 weet ik:
- (merel-2, is van geslacht, mannelijk)
- (merel-2, hoort bij nest, nest-7)
- (merel-2, vormt een paar met, merel-1)
Van nest-7 weet ik alleen zijn nummer op het kaartje en meer wil ik ook niet weten. De nesten in mijn UOD treden alleen op als waarde op de B-positie in beweringen van het type (A, hoort bij nest, B).
Een entiteit als nest waar we geen beweringen over willen registreren noemen we een secundaire entiteit.
Bij beweringen zoals (A, hoort bij nest, B), met een secundaire entiteit als B levert R+B de betekenis van een eigenschap van A.
De bewering (merel-1, vormt een paar met, merel-2) is een uitspraak over merel-1 die het feit weergeeft dat deze een paartje vormt met merel-2. Dit is een relatie tussen beide entiteiten. Deze relatie is symmetrisch zoals onder merel-2 blijkt. {Niet ieder relatie is symmetrisch: bv (A, zoon van, B)}
Bij relaties levert het predikaat de betekenis van die relatie van A, terwijl B de gerelateerde entiteit is.
In beweringen van het type (A, is van geslacht, B) is net zoals bij het predikaat hoort bij nest , B een secundaire entiteit die alleen een waarde geeft. De bewering levert de betekenis van een eigenschap van A.
Definities
Het gaat hier over de definities van OBJECTTYPEN en ENTITEITTYPEN. {zie Post Gm I }
Tussen de definities van beide zit vaak geen verschil. Immers als je objecten in het UOD aan de hand van een definitie geclassificeerd hebt als behorend tot een type. En je gaat een subset daarvan die je individueel kent als entiteiten opslaan in een registratie. En je zoekt een naam en definitie voor die subset in de registratie, dan ligt de naam en de definitie van het objecttype voor de hand.
Bij GM gebruikten we de volgende cryptische algemene gedaante om de methode van definiëren te leren kennen. Ga uit van:
“Een BLIE is een BLA die BLIEPT”
Bij voorbeeld: Een VRACHTAUTO is een AUTO die gebouwd is om goederen te vervoeren.
BLIE staat voor de naam van het type dat gedefinieerd wordt. BLA noemen we de generale verzameling waar de BLIE toe behoort. En die BLIEPT is het criterium om het subtype van BLA dat we BLIE gaan noemen te onderscheiden.
De bedoeling is dat de naam van een type voor het normale gebruik voldoet. Een definitie moet gebruikt worden om in geval van twijfel te bepalen of een object al dan niet tot het type behoort.
Wat dat betreft lijkt het veel op het opzoeken van de betekenis van een woord in het woordenboek; ook dat doe je alleen bij twijfel.
Het is van belang dat een definitie scherp is; want je wilt dat de objecten telbaar zijn. Met een vage definitie neemt de betrouwbaarheid van de uitkomst af.
Het gebruik van een generale verzameling maakt het definiëren efficient; want je doet daarmee aan hergebruik van definities.
Er geldt dat de objecten van een type, gegevens erven van de generale verzameling.
Zo hoef je bij het bovenstaande voorbeeld niet op te nemen dat een vrachtauto wielen en een stuur heeft; want dat hebben alle auto’s.
In de Biologie, maar ook bij vele andere onderwerpen, vormen de gedefinieerde zaken vaak een hiërarchie. Bijvoorbeeld een merel, is een lijsterachtige, is een zangvogel, is een vogel, is een gewerveld dier. Of een viool, is een snaarinstrument, is een strijkinstrument, is een muziekinstrument.
Wanneer de generale verzameling in een definitie algemeen bekend is, en dat is voor je doelstelling voldoende is, dan verwijs je naar het woordenboek. Je hoeft zo een hiërarchie dus niet helemaal uit te definiëren.
Goed definiëren van een type stelt hoge eisen.
Bijvoorbeeld: Is een bestelbus een vrachtwagen? Volgens bovenstaande definitie is dat zo, maar je denkt toch aan iets groters. En als de bestelbus na 5 jaar omgebouwd is tot een camper?
De betekenis van entiteiten in een registratie wordt gegeven door de definitie van hun type.
Zoals hierboven gezegd wordt de betekenis van een een eigenschap of een relatie gegeven door een triple. Dat werkt ook andersom: vanuit de registratie leert het triple welk feit zich heeft voorgedaan in (dat deel van) de werkelijkheid waar het UOD betrekking op heeft.
Ik kom op deze materie in een volgende Post uitgebreider terug.
Een uitstapje in de tijd
Samenhangend met het idee van een paradigma verschuiving, van zeg maar software-ontwikkelaar naar gegevensmanager wil ik graag over een ervaring vertellen die ik had nadat ik al een jaar of zes weg was bij de afdeling GM. Maar ik het ambacht van gegevensmanager geenszins achter me had gelaten. In de tussentijd werkte ik o.a. in een internationaal project in het kader van de samenwerking tussen Europese Telecombedrijven Unisource, aan een model voor een Customer Database meegewerkt. Dat was in het begin van de 21-ste eeuw.
{er volgt een lange inleiding tot die ervaring: hij voert langs Ordermanager, en productmodel tot in ObjectOriëntatie. We komen onderweg nog heel wat gegevensmanagement tegen}
Ten tijde van die ervaring was ik net overgeplaatst naar de subafdeling ICT-Innovatie van I&A-T zoals de automatiseringsafdeling van KPN-Telecom inmiddels heette. Dit was een groep die met moderne middelen, nogal gericht op Microsoft, aan de gang was. Er bestaat een foto van Bill Gates op bezoek bij Hans, de baas van ICT-Innovatie. Maar ze waren ook bijzonder vaardig met de database-taal SQL, en hadden onder de naam KADO een installed base van alle klanten voor alle producten van Telecom geproduceerd die je op een PC kon bekijken; maar niet muteren.
Ik werkte aan een Productmodel voor de OrderManager. Dit was een door Hans bedachte, te ontwikkelen applicatie, waarmee de meest gangbare producten voor de klant besteld zouden moeten kunnen worden. Dus niet een complexe huiscentrale of andere zaken waarbij een offerte hoort. Het was vooral ook de bedoeling om zelfbediening door de klant mogelijk te maken.
Hans presenteerde het plan voor een OrderManager op een afdelingsvergadering in Groningen. Ik had nog geen duidelijke taak bij Innovatie. Maar het model van de Customer Database van Unisource kende ik uiteraard goed, en ook veel andere modellen uit de klantbediening. Ik trok de stoute schoenen aan en kwam op de volgende afdelingsvergadering met een notitie die een schets van een OrderManager bevatte.
Ik mocht mijn ideeën verder uitwerken, en doordat het een onderwerp was dat Hans wenste, kon ik wat steun krijgen. In Den Haag zat ik met Hein: een gelouterd automatiseerder die een grote rol gespeeld had bij het realiseren van KADO. We bekeken en bespraken het nieuwe systeem PROMIS van Telecom voor het assortiment. Ook GerardF afkomstig uit het district Amsterdam, maar later collega bij GM, mocht zich bij ons aansluiten.
GerardF en ik bestudeerden uitgebreid de aanvraagformulieren, bedoeld voor klanten van Telecom om een bepaald product te bestellen. Dit gaf inzicht in de vragen die door de klant beantwoord moesten worden om een product te kunnen leveren. Zoals PROMIS een goed inzicht gaf in het aanbod: de Standaardproducten.
Ondertussen schetsten we af en toe productmodellen op een groot white board. Toen de modellen een vaste vorm kregen begon Hein prototypes voor een rudimentaire opzet van de OrderManager in SQL te maken. We presenteerden die natuurlijk af en toe in Groningen.
Toen de prototypes ergens op begonnen te lijken ging Hans, een virtuoos op de PC en een uitstekend presentator, ermee “de boer op”. Omdat de ontvangst positief was kwam de ‘echte’ bouw in zicht.
Uiteindelijk was dat Productmodel behoorlijk complex; er zouden immers allerlei mogelijke producten mee beschreven moeten kunnen worden. We wilden dit bereiken door de eigenschappen van producten flexibel te maken. Dergelijke eigenschappen zijn niet van te voren bekend omdat er regelmatig een nieuw type product bijkwam. Voor de OrderManager gebruikten we daarvoor de term contingentie. {contingent betekent “toevallig” of “niet voorzien”}.
Iets dergelijks had ik al eerder voor EFBT had gedaan zie de Post Integraalsysteem II.
Er zijn drie niveau’s in het productmodel;
- type-product. Dit beschrijft de functionaliteit en de natuur (materieel artikel of voorziening) van de producten die tot het type behoren. En het bepaalt welke eigenschappen deze zouden kunnen hebben. Dit niveau hoort bij het meta-model waarmee producten en hun eigenschappen beschreven worden.
- standaard-product. Dit zijn de zaken die de klant kan bestellen; er zit een prijs aan vast. Zolang ze nieuw zijn worden ze geacht verwisselbaar te zijn voor de klant. Een standaardproduct erft zijn eigenschappen van zijn type-product.
- product. Dit is het operationele niveau. Het gaat om de ‘echte’ producten; ze staan bij de klant, of ze staan op een offerte, of ze zijn onderweg naar de klant toe. Een product kan kapot zijn; een standaard-product niet. Het product erft zijn eigenschappen van zijn standaard-product.
Aard van het product
NATUURLIJKE AARD ABSTRACTE AARD
- Verrichting: een product dat met zijn levering verdwenen is. Bijvoorbeeld het repareren van een product.
- Artikel: een product met een blijvende economische waarde.
- Materieel artikel: die waarde zit in de materie.
- Immaterieel artikel: die waarde zit niet in de materie. Bijvoorbeeld een computerprogramma.
- Voorziening: een recht op ondersteuning/diensten/functionaliteit.
- Overig immaterieel artikel: bijvoorbeeld een advies.
- Pakket: een lege hoes bedoeld om een samenstel van artikelen en verrichtingen als één geheel aan te bieden.
Het begrip Pakket is anders dan bij EFBT {zie Post ITCIS II}. Daar stond het ruwweg voor de installed base van producten, die één klant voor één dienst had afgenomen.
In de OrderManager is het een commercieel product om een samenstel van gewoonlijk samenhangende producten -tegen aantrekkelijke voorwaarden- aan te bieden. Het is als het ware een doos met een aantal producten erin, en een ‘leuk’ prijsje erop. Denk bijvoorbeeld aan een pakket met daarin een telefoontoestel, het abonnement van een netlijn en een servicecontract.
Een Pakket is een Product en kan dus zelf ook, redelijkerwijs met een ander product, in een Pakket gestopt worden.
Functionaliteit van het product
Dit zijn de belangrijkste productfuncties van de producten van een Service Provider van Telecommunicatie. Ik hoop dat je de overeenkomst ziet met de hiërarchie van doelstellingen uit de Post Gegevensmanagement I.
Definitie van twee type-producten :
Telefoontoestel
Aard van het product: materieel artikel
Bijdragen aan productfuncties:
- Aan kunnen kiezen: invoeren van een tf-nummer
- Aan bereikbaar zijn: geven van een oproep-signaal
- Aan berichten aanbieden: realiseren van spraak
Een telefoontoestel dat je huurt heeft een extra bijdrage aan een productfunctie:
- Aan financieren: verhuren van een product
Vaste Verbinding
Aard van het product: voorziening
Bijdragen aan productfuncties:
- Aan afstand overbruggen: continu overbruggen van afstand tussen twee locaties ten behoeve van telecommunicatie
Het toewijzen van contingente eigenschappen aan Type-Producten
Een type-product krijgt een dergelijke eigenschap vanwege één van beide redenen:
- Het type-product heeft een bepaalde aard en dat brengt bepaalde eigenschappen met zich mee. Denk aan afmetingen of gewicht bij een materieel artikel.
- Het type-poduct levert een bijdrage aan een productfunctie die de eigenschap meebrengt. Denk aan afstandklasse bij de productfunctie afstand overbruggen.
Een type-product wordt door een medewerker geconstrueerd. Deze geeft het product eigenschappen binnen het bovenstaande.
De eigenschappen worden toegekend op basis van de (standaard)product zoals die binnen Telecom aangeboden, en door de klanten gebruikt worden. Of zoals Telecom van plan is het aan te gaan bieden.
De (standaard)producten worden op hun beurt ook geconstrueerd en hoeven niet alle eigenschappen van hun type te erven.
Object-Oriëntatie
Het was van het begin af aan duidelijk dat de OrderManager in een OO-taal (Java) geschreven zou worden; maar dat de databases waarin de gegevens ‘overnachten’ gewone relationele databases zouden zijn.
In termen van OO is de bovenstaande toewijzing van contingente eigenschappen een vorm van Multiple Inheritance. Want het type-product ‘erft’ contingente eigenschappen zowel op grond van zijn aard, als op grond van de productfuncties. Multiple Inheritance is een aspect dat binnen OO als moeilijk wordt beschouwd. Java had het niet.
Hoewel ik niet verwachtte mee te gaan programmeren wilde ik me toch wat verder in OO verdiepen. Hein beval me het volgende boek aan:
Object-Oriënted Software Construction, van Bertrand Meyer, de tweede editie. Een uitgave van Prentice Hall PTR, 1997.
{ik verwijs naar dat boek met OoSC}
Meyer is een belangrijke auteur over Object-Oriëntatie. Hij beschrijft zijn eigen methode uitgebreid, en besteed veel aandacht aan het garanderen dat de opgeleverde software doet wat deze moet doen, met contracten, pre- en postcondities en invarianten. Allemaal zeer degelijk werk.
Zijn OO-programmeertaal Eiffel kent Multiple Inheritance. De taal wordt veel gebruikt in omgevingen die hoge eisen aan betrouwbaarheid stellen..
In eerste instantie ben ik heel tevreden, want Meyer beschrijft een prachtige programmeeromgeving. En hij behandelt allerlei aanpalende onderwerpen zoals hergebruik van software, en geheugen management.
Multiple Inheritance voor Type-product
Ik bezit nog een rapport getiteld Analysemodel voor PIVOT en Generieke Ordermanager van de hand van mijzelf en Ernest. (PIVOT is de naam van het systeem voor het assortiment voor de Ordermanager). Dit analysemodel is geschreven toen het geheel al in productie was, maar zich nog ontwikkelde. Het doel was om de functionaliteit en de software toegankelijk te maken, voor (nieuwe) ontwikkelaars. De beschrijving zat daarom dicht tegen de implementatie in JAVA aan; dus zonder multiple inheritance.
Hieronder een schematisch plaatje rond type-product en het overerven van eigenschappen op grond van de aard van het product en de bijdrage aan productfuncties:
Links met multiple inheritance.
Rechts zonder. Dit wordt opgelost met een extra niveau ‘product classification’.
{De term ‘classification’ heeft niets met het oo-begrip ‘class’ te maken; het is een naamsdeel voor dat extra niveau}
De product-classification is een generalisatie van de aard van het product en een peoductfunctie. En daarmee het aangrijpingspunt voor één of meer eigenschappen.
Dat werkt via èèn of meer eigenschapclassificaties. Die bestaan uit: een naam voor een eigenschapstype, een predikaat en verder alles wat het eigenschapstype nog meer nodig heeft. Bijvoorbeeld voor de B van het triple: een domein als B een waarde is, en een productclassificatie als het om een relatie gaat.
Het predikaat speelt een hoofdrol: Als een product een neveneffect heeft zoals het geïdentificeerd worden door een ander product, bijvoorbeeld een telefoontoestel door zijn netlijn, dan zit de benodigde programmatuur in het predikaat. Dat is zo omdat het predikaat drager is van de betekenis.
Links erft het type-product zowel de aard van het product, als de productfuncties waaraan een bijdrage wordt gegeven. En daarmee de mogelijkheid om de type-eigenschappen die daarbij horen voor zijn standaardproducten toe te staan. Dit is niet verder uitgewerkt, maar dat zou simpeler zijn geweest dan bij rechts; geen extra niveau ‘classification’ nodig.
Rechts heeft het type product een relatie met zijn aard en geeft een bijdrage aan 1 of meer productfuncties. product-classificatie is een generalisatie van de aard van het product en van een productfunctie. Type-product erft van product-classificaties 1 aard en een of meer productfuncties, met de mogelijkheid om de type-eigenschappen die daarbij horen voor zijn standaardproducten toe te staan,
Zowel links als rechts erven de aard en de productfuncties. Maar links gebeurt het dankzij multiple inheritance direct en rechts via de omweg van de product-classificatie.
Ik betreurde het feit dat we in ons Analysemodel teneinde het ontbreken van multiple inheritance te omzeilen het extra niveau van de ‘classification’ hadden. Dit verminderde de toegankelijkheid van het model; en dit was
juist bedoeld om de Ordermanager toegankelijk te maken.
Erger is dat het het operationele productmodel in de Ordermanager zelf, ook complexer was dan met multiple inheritance.
OoSC en de werkelijkheid
Ondanks de voordelen van multiple inheritance, en de kwaliteit van het boek wordt de gegevensmanager in mij van hoofdstuk 8 ‘The run-time structure: objects’ ontevreden. Het gaat in wezen om een filosofische kwestie; maar niet de minste: de relatie met de werkelijkheid.
Want de paradigma verschuiving, waar deze Post over gaat, vind hier bepaaldelijk niet plaats; vandaar dat dit “uitstapje in de tijd”.
In paragraaf 8.2 ‘Objects as a modelling tool’ onder het kopje Reality: a cousin twice removed op pagina 230 stelt Meyer we do not need to delude ourselves with the flattering but illusory notion that we deal with the real world.
Volgens Meyer is spreken over de werkelijkheid achter een informatiesysteem misleidend.
Talking about the “reality” behind a software system is deceptive for at least four reasons.
Zijn argumenten:
1) Reality is in the eyes of the beholder
Mee eens: wat we als de ‘werkelijkheid’ beschouwen hangt van de waarnemer af. Om preciezer te zijn: als we een professionele discussie voeren met collega’s dan zijn de objecten uit onze gedeelde werkelijkheid
de onderwerpen van de conversatie.
De invloed van de intentie van de waarnemer kan heel goed zo belangrijk zijn dat hun classificatie van dezelfde objecten verschillen. Bijvoorbeeld wat voor een verkoper één klant is, kan door een monteur best als twee klanten worden beschouwd omdat hij zich voor twee klussen op verschillende locaties bij verschillende contactpersonen moet melden. Wanneer de verkoper en de monteur met elkaar overleggen, dan moeten ze hun klantbegrip verfijnen, er structuur in aanbrengen, zodat ze elkaar begrijpen. {die structuur is bijvoorbeeld een winkelier die op locatie A boven de zaak woont, maar op locatie B ook een zaak heeft}. Binnen een UOD horen dit soort zaken geregeld te worden!
Als voorbeeld noemt Meyer wiskundige problemen die worden opgelost met behulp van software zoals: differentiaalvergelijkingen, het integreren van functies, geometrische problemen in een vier-dimensionale ruimte enzovoorts. Moeten wij software-ontwikkelaars kibbelen met onze wiskundige vrienden wiens artefacts meer reëel zijn?
{De software en de wiskunde hebben ieder een eigen werkelijkheid die elkaar in deze casus raken. Geen van beiden is de ‘echte’
werkelijkheid. Stel dat de wiskunde een veronderstelde theorie is die men met software wil beproeven. Dan wordt het spannend als er getest wordt.
Als er iets niet blijkt te kloppen dan kan er een fout in de theorie zitten, óf de programmeurs hebben de theorie onjuist geïnterpreteerd.
Of de theorie nu gefalsifieerd wordt, of verkeerd begrepen is door de programmeur, er is geen aanleiding voor een discussie over wat meer reëel is; dat zijn ze op hun manier beiden. Maar geen van beiden is de ‘echte’ werkelijkheid. De gebruikte software is een tool. En de geteste wiskunde bestaat mogelijk uit meerdere toepassingen van een theorie, als een soort use cases waarvan er kennelijk één of meer niet het voorspelde resultaat geven.}
2) The notion of real world collapses in the case that software solves software problems
Bijvoorbeeld een compiler voor de taal C geschreven in Pascal.
{De onderhavige werkelijkheid is in dit geval de niet-begrensde verzameling van de syntactisch correcte, en ‘bijna’ syntactisch correcte, C-programma’s.
In het overleg met de opdrachtgever heb je, waarschijnlijk op basis van use-cases een afspraak gemaakt. De use-cases bestaan uit al dan niet correcte C-programma’s met input en verwachte output.
Pascal is de taal waarin je de compiler schrijft; en het beoogde resultaat van het project is een product in Pascal. Geen reden voor verwarring.}
3) In the early day of computers it may have been legitimate to think of software systems as being superimposed on a pre-existing independent reality. But today computers and their software are part of that reality.
Het beschrijven van de operaties van een moderne bank is het beschrijven van een mechanisme waarvan software een fundamentele component is.
{Helemaal mee eens: maar de betekenis van de operaties en de gegevens is voor bank en haar klanten niet essentieel veranderd sinds dat mechanisme werd uitgevoerd door een klerk met een telraam.
Niet onderkennen dat de administratie een afspiegeling is van een werkelijkheid die buiten de bank ligt, maakt het onmogelijk om sommige vormen van fraude vast te stellen.}
4) A software system is not a model of reality, it is at best a model of a model of some reality.
Dit is waar: ook een UOD omvat meestal een model van een model van een aspect van de werkelijkheid. Maar dat is juist de bedoeling. Een model van de volledige werkelijkheid is oneindig en daarom onbruikbaar; in de beperking toont zich de meester.
De werkelijkheid is geen illusie en de omgang ermee is niet vleiend, maar gezond en noodzakelijk (mijn mening)
Ik zie geen reden voor ruzies of verwarring. Maar achter de punten (1), (2) en (3) zit natuurlijk wel een soort werkelijkheid. Dit is in alle gevallen niet de echte werkelijkheid, maar een bepaald aspect daarvan. Waarbij van heel veel zaken geabstraheerd wordt.
{Mag ik de betrokkenen het idee van een Universe of Discourse aanbevelen? Waarbij een aantal van hen van te voren uitgebreid over de casus praten, en ook in de vakliteratuur neuzen. Teneinde elkaar te leren kennen en begrijpen. Als een soort preventieve relatietherapie?}
Waarom vindt Meyer praten over de werkelijkheid achter een informatiesysteem misleidend?
Al in Preface stelt Meyer:
The tradition of information systems modelling usually assumes “an external reality” that predates any program using it; for the object-oriented developer such a notion is meaningless, as the the reality does not exists independently of what you want to do with it. (More precisely whether it exists or not is an irrelevant question, as we only know what we can use, and what we know of something is defined entirely by how we can use it.)
Deze uitspraak staat op gespannen voet met het doen van waarnemingen volgens gm, als basis van gegevens.
Volgens Meyer kan een oo-developer helemaal geen waarnemingen doen; aangezien de werkelijkheid niet bestaat of we er althans alleen van kennen wat we kunnen gebruiken.
Maar hoe kun je weten wat je kan gebruiken als je het niet waargenomen hebt?
Na kennisgenomen te hebben van: Object-Oriented analysis Hoofdstuk 27
denk ik begrepen te hebben hoe zijn standpunt over de werkelijkheid te moeten duiden:
Wat er in hoofdstuk 27 beschreven wordt is niet wezenlijk anders dan wat gebruikelijk is in een informatie analyse. Maar het zijn vooral lijstjes van zaken die moeten gebeuren.
Er staan literatuurverwijzingen naar auteurs die wel uitgebreid aan OO-analyse doen.
Wat echter opvalt is bij Meyer, is dat er gestreefd wordt naar een eindproduct van de Analyse dat een rudimentaire eerste versie van het beoogde systeem moet zijn.
Dat betekent allerlei zaken zijn wel syntactisch aanwezig zijn “deferred” (ze doen niets; zijn void of dummy); maar wat het moet worden staat wel in commentaar.
En ongetwijfeld ingekaderd met contracten, pre- en postcondities en invarianten. {Dit soort zaken zijn bekend van E.W.Dijkstra en Hoare}
Het geheel wordt het analyse-model genoemd en daaruit wordt het doelsysteem ontwikkeld. Naar ik begrepen heb is er wel ruggespraak met de opdrachtgever over wat er precies in het systeem meegenomen wordt. Maar er is “geen ruggespraak met de externe werkelijkheid waar het systeem betrekking op heeft voor zover dat niet in het analysemodel staat”.
{ Het is een andere betekenis van de term analysemodel dan ik eerder gebruikte in verband met de Ordermanager. Dat is gemaakt nadat het systeem al deels in productie was. In OoSC wordt de term (juister) gebruikt voor een model als afsluiting van de informatie-analyse }
Het maken van het oo-analysemodel ziet OoSC, moet ik aannemen, als wezenlijk iets anders dan de object-oriented development. Want tijdens de analyse is het beoogde systeem er nog niet. Er is wel een deel van een aspect van de werkelijkheid waar het beoogde systeem betrekking op heeft; want er moet toch iets zijn wat geanalyseerd moet gaan worden. Laten we dat het analyse-domein noemen. Bij aanvang van de analyse weet je nog niet wat je ervan kunt gebruiken.
Er moet dus ruimte zijn om waarnemingen te doen aan het domein, en aan de hand van de opdracht en de waarnemingen te bepalen wat je kunt
gebruiken.
{ik denk dat een gegevensmodel volgens GM prima input zou kunnen zijn voor het oo-analysemodel.}
Het oo-analysemodel
Na afsluiting van de OO-analyse is er, begrijp ik een model dat geschikt is als startpunt voor de OO-development, hetgeen zonder meer het hoofdonderwerp is van OoSC.
Er zal een vorm van overdracht zijn van de analisten naar de developers, waarbij er nog wel eens een iteratie zal optreden.
Maar uiteindelijk gaan de developers aan de slag.
De specificaties van het beoogde systeem
Dit is een essentiële term voor Meyer: het opgeleverde systeem moet
aan de specificaties voldoen. Dit behelst naar ik begrepen heb het volgende:
- Alle classes met hun features die tezamen de functionaliteit suggereren te leveren die met de opdrachtgever overeengekomen is. (Ik gebruik de term “suggereren” omdat allerlei zaken deferred mogen zijn. Maar het commentaar dat erbij staat moet voldoende om dit geheel de basis voor contractafspraken te doen zijn)
- Alle bovenbedoelde classes en hun features, inclusief alle zaken die deferred zijn, zijn zodanig ingekaderd met pre- en postcondities, invarianten en dergelijken, dat de opdrachtnemer van mening is, dat het opgeleverde systeem de bovenbedoelde functionaliteit zal leveren.
De termen onder- en overgespecificeerd hebben betrekking op (2). Ondergespecificeerd betekent dat de verwachting is dat er in de productie met het systeem fouten kunnen optreden; omdat niet alles afgevangen wordt. Overgespecificeerd betekent dat het systeem de productie zou kunnen stoppen, omdat er zaken afgevangen worden zonder dat daar een noodzaak voor is. Beiden zijn uiteraard onwenselijk.
De ontwikkeling (development) van het beoogde systeem
Voor de developers geldt, ik volg OoSC:
“as the the reality does not exists independently of what you want to do with it. (More precisely whether it exists or not is an irrelevant question, as we only know what we can use, and what we know of something is defined entirely by how we can use it.)”.
Vrij vertaald en met inbreng van wat ik weet van het oo-analysemodel. Betekent dit:
“Er is voor jou als developer, voor je taak, geen werkelijkheid buiten wat in het analysemodel staat”.
Hoe verstandig is dit als handleiding voor de menselijke developer?
Het doet mij denken aan het ontwikkelen van een zelfsturende auto. Het benutten van de menselijk hersenen moet zoveel mogelijk geëlimineerd worden.
Als dat voor bijvoorbeeld Eiffel lukt; dan ontwikkelt deze taal zich tot een heel hoge programmeertaal. Er ligt dan een zware verantwoordelijkheid voor de maker van het oo-analysemodel. En komt er veel belangstelling voor de methoden daarvan. Dat zou een fraai resultaat zijn.
Maar hoe wijs is het om in afwachting daarvan de ontwikkelaars oogkleppen voor te houden, zodat ze niet naar de onderliggende werkelijkheid van het te ontwikkelen van het systeem kijken?
Mij lijkt dat onverstandig:
- Hoe is de correctheid van het analysemodel geborgd?
- Uitgaande van de correctheid van het analysemodel, is de juistheid van de ontwikkelde software van het systeem als een omvangrijk correctheidsbewijs van programmatuur ingekaderd met pré- en postcondities, invarianten etc, waarbij ook alle deferred zaken ingevuld moeten worden. Zo een omvangrijk bewijs is natuurlijk prachtig; maar veel te uitgebreid en complex om onfeilbaar te zijn.
- Ik zou de oo-developpers in paren willen laten werken: één met een achtergrond van de gebruikers van het domein, die betrokken was bij het analysemodel. En één heel goed ingevoerd in de systematiek van OoSC. Zij moeten tijdens hun werk aan elkaar de stappen en beslissingen die genomen worden uitleggen. En bij geconstateerde problemen escaleren.
Postscript OoSc pagina 410.
Het ongeluk met de Ariane 5 lanceerraket van de ESA op 4 Juni 1996 40 seconde na opstijgen, door een verkeerde conversie van getallen. Het ging om de horizontale afwijking bij de start, hergebruik van de software van de Ariana 4. De Ariane 4 gebruikte hiervoor 16bits floating point voor een reëel getal. De Ariane 5 gebruikte een integer, en daarvoor was 16 bits te weinig.
De betrokken software was niet geschreven in Eiffel, maar in de taal ADA, met een vergelijkbare methodiek. Er was geen bovengrens nodig geacht in Ariana 4 (kennelijk omdat heel grote waarden onwaarschijnlijk waren), maar voor de integer van Ariana 5 kon dat wel een probleem worden.
Er was dus sprake van onderspecificatie.
—————————————————————
Comments
Post a Comment