Fundamenteel kijken naar Dialogen

Dat laten we zien door fundamenteel te gaan kijken naar de dialogen tussen een gebruiker en een systeem, waarbij we langzaam meer beperkingen opleggen aan de deelnemers van de dialoog.

Zie de figuur hieronder. We hebben daar een kantoorsetting met drie personen. Wendy is de persoon die iets wil van het kantoor. Bob doet zijn best het verzoek van Wendy in te willigen en Alice beheert de archiefkast. Alles wat Bob wil weten of opgeslagen wil hebben regelt hij via Alice.

Stel dat Wendy iets wil kopen. Ze vraag Bob wat hij allemaal verkoopt. Bob is nogal kort van memorie, dus hij stelt de vraag aan Alice.

Zij vertelt hem dat ze de volgende dingen verkopen:

-          Kaartensets

-          Kado’s

-          Bedrijfskaarten

-          Kerstkaarten

-          … en nog wat meer dingen …

 

Bob vertelt dit alles aan Wendy, die op haar beurt aangeeft dat ze geïnteresseerd is in de kaartensets. Welke soorten kaartensets heeft Bob allemaal, is haar volgende vraag. De rest van de dialoog tussen Bob, Wendy en Alice laat zich raden als je goed naar de screenshots van de Unicef website op de vorige webpagina kijkt.

 

Maar Wendy krijgt natuurlijk ook door dat Bob nogal kort van memorie is en al zijn informatie bij Alice vandaan haalt. In de praktijk zal je dan ook zien dat efficiënte Wendy zo af en toe de vrijheid zal nemen om Bob te passeren en Alice rechtstreeks dingen zal vragen.

 

Wat heeft dit alles met softwareontwikkeling te maken? Wel, je kunt in de hierboven geschetste kantoorsetting een applicatiearchitectuur zien. Wendy representeert hier de gebruiker van het systeem die de User Interface van het systeem gebruikt om met Bob te praten. Bob stelt de business laag van de applicatie voor en Alice de data laag.

 

Ook in softwarebouw zien we dat als er geen duidelijke beperkingen aan de architectuur worden gelegd, dat er programmeurs zullen zijn die niet altijd even netjes met de businesslaag communiceren. Er zijn de nodige programmeurs die, als het zo uitkomt, rechtstreeks vanuit een scherm een query in de database doen om wat gegevens te tonen. En het werkt ook wel, maar je krijgt uiteindelijk wel spaghetticode met bijbehorende hoge aantallen bugs en hoge onderhoudskosten.

 

Hoe kunnen we nu zorgen dat Wendy altijd netjes via Bob communiceert?

Dat dwingen we af door beperkingen op te leggen aan de dialoog. Bijvoorbeeld door alle communicatie alleen nog maar schriftelijk te laten verlopen. Dit kan afgedwongen worden door Bob in een afgesloten kantoor (Black Box) te stoppen met enkel brievenbus voor de briefjes van en voor Wendy en een brievenbus voor de communicatie met Alice. Zie figuur hieronder.

 

 

Op deze wijze is het voor Wendy onmogelijk geworden rechtstreeks met Alice te communiceren. Tegelijkertijd is er meer controle doordat alle communicatie gelogd kan worden. We hebben zo een beter gecontroleerd proces.

 

Toch zijn we er nog niet. Iedereen heeft nog volledige vrijheid om vragen op een eigen manier te stellen. Dit leidt tot onduidelijkheden.

 

Om dat op te lossen moeten we nog een stap verdergaan en een extra restrictie toevoegen aan de dialoog. We gaan eisen dat er alleen nog maar stencils over en weer gaan met data erop. De stappen in de dialoog die Bob en Wendy moeten doen zijn van te voren al bij hen bekend. Deze staan in hun draaiboeken die in de figuur hieronder naast Wendy en Bob zijn getekend.

 

De kern van Black Box Dialogs

En hier hebben we de kern van Black Box Dialogs te pakken: Het scheiden van parameters en instructies.

 

In de softwareontwikkeling heeft dit de volgende gevolgen:

-          Communicatie tussen de systeemdelen gaat op basis van Use Case parameter sheets.

-          Applicatie intelligentie wordt belegd per systeemdeel:

o        De User Interface reduceert tot een soort intelligente xml-editor. Het boeit Bob niet hoe Wendy het parametersheet invult, zolang hij maar de data erop kan vinden voor zijn volgende stap in het script

o        De business laag wordt de natuurlijke plek voor de business rules.

-          Minimale afhankelijkheden tussen de systeemdelen

o        Omdat de UI gereduceerd is tot een soort xml-editor, kan je het type applicatie met minimale moeite veranderen: Van een desktop applicatie een webapplicatie maken vereist alleen aanpassingen in de GUI laag. Immers, Bob boeit alleen het parameter sheet dat bij hem binnenkomt, niet hoe het gevuld is.