Samenvatting

 

In onderstaande figuur is een overzicht gegeven van de Black Box Dialog Method.

 

 

Het verhaal begin met een idee over het systeem dat een klant wil bouwen.

In een eerste brainstorm sessie wordt bepaald welke functionaliteiten erin moeten zitten: de Use Cases worden heel high-level beschreven.

 

 

 

Vervolgens wordt per user case nagedacht wat voor dialogen er mogelijk moeten zijn. Dit geeft al een stuk meer duidelijkheid over de omvang van de verschillende Use Cases.

Daarna worden de Black Box Dialogs in een workshop gespeeld en uitgewerkt. Ook het parameter sheet wordt samengesteld.

Dit wordt eerst voor de meest eenvoudige dialogen gedaan, dan de meer complexere.

 

De uitgewerkte BBDs gaan de IT in waar er System Dialogs en een System Dialog Collection van worden gemaakt per Use Case.

Ook de parametersheets worden systeem breed gemaakt.

 

 

Nadat de inhoud van de iteraties zijn vastgesteld, gaan de bouwers aan het werk en bouwen zij hun 0.1 versie van de applicatie.

Merk op dat de pseudo-code van de System Dialogs één op één terugkomt in de Use Case control class. Voor elke Use Case komt er een control class in de control layer van de applicatie. Ook het parameter sheet wordt zonder aanpassingen overgenomen in een ParameterSheet Class in dezelfde control layer.

De control layer (ook wel regie-laag genoemd) zit tussen de GUI en Business laag van een goed opgedeelde applicatie.

 

De Black Box Dialog Methode geeft structuur aan het ontwikkelproces vanaf specificatie tot aan de bouw.

 

 

Tot slot wordt hieronder het plaatje van de development iteratie getoond. In de workshop wordt de inhoud van een iteratie bepaald en eventueel een aantal dialogen uitgewerkt tot BBDs. De bouwers maken een volgende versie van de applicatie die vervolgens getest wordt. Daarna gaat de volgende iteratie in.