Ontwerp
Afronden use cases

Tijdens het ontwerp worden de use cases van de huidige iteratie afgerond. Zo worden de pre- en postcondities toegevoegd aan de use cases. Deze condities zijn noodzakelijk om te kunnen starten met het opstellen van test activity diagrams. Hierbij spelen de pre- en postcondities een belangrijke rol. Ook bij het opstellen van sequence diagrammen, waarbij de samenwerking tussen de use cases aan bod komt, spelen deze condities een rol. Ze bepalen namelijk de uitgangspunten van de uitvoering van de use cases en de overdracht van informatie tussen de use cases.

Doel

De use cases van de huidige iteratie dienen voorzien te zijn van pre- en postcondities om de test activity diagrams en sequence diagrammen goed te kunnen formuleren.

Stappen

1. Toevoegen pre- en postcondities
   Voeg ontbrekende pre- en postcondities toe aan de use cases in het increment. Definieer deze concreet en kwantificeerbaar, bij voorkeur met een booleaanse uitkomst (waar of niet waar). Immers, de testscenario's controleren de uitkomst van het uitvoeren van de use case op basis van deze condities.
   Voorbeelden zijn "ID klant is bekend" en "ID hypotheek is bekend of de actie is geannuleerd".
   
   
2. Beschrijven uitzonderingen
   Het stappenplan van de meeste use cases beschrijft een aantal mogelijke manieren om tot een uitkomst te komen (scenario's), waarvan er meestal één de gewenste is. Beschrijf de afwijkende scenario's als de alternate courses van de use case indien de deviatie van het gewenste scenario minimaal een aantal stappen van het stappenplan beslaat.
   Het kan voorkomen dat de deviatie zo groot is dat er een nieuwe use case ontstaat, die met een "extends" relatie is verbonden met de originele use case.
   
   
3. Invullen ontbrekende validaties
   Voeg aan het stappenplan eventueel ontbrekende validaties toe. Veelal komen ook dergelijke validaties pas in een tweede of derde iteratie naar voren, als de in de eerste iteratie gebouwde user interface wordt geëvalueerd met de gebruikersvertegenwoordiger.
   Neem in het eerste increment bij voorkeur alleen die validaties mee, waarvan de inhoud op voorhand bekend is. Neem eventuele overige validaties op als "parkeerpunt", dat tijdens een volgende iteratie kan worden uitgezocht parallel met andere taken.
   
   

Richtlijnen

De alternate courses beschrijven alleen de afwijkingen ten opzichte van het gewenste scenario. Beschrijf dus niet de stappen uit het stappenplan die voor beiden gelijk zijn.

Gedurende de verschillende iteraties wordt informatie die in een eerdere iteratie nog onbekend was, makkelijker toegevoegd. Dit komt omdat er meer kennis over het probleemdomein is gaandeweg het project vordert.
Dit is één van de belangrijkste motieven om het opvoeren van pre- en postcondities uit te stellen tot dit moment in het proces, juist voor het moment dat deze informatie echt noodzakelijk is.

Zorg bij het toevoegen van pre- en postcondities voor zoveel mogelijk onafhankelijkheid tussen de use cases. Dit betekent dat verschillende use cases zo min mogelijk informatie met elkaar dienen uit te wisselen. Derhalve is het beter om bijvoorbeeld uit een use case waarin een selectie plaatsvindt het ID van het geselecteerde object als postconditie te gebruiken, dan om het object zelf te retourneren. De aanroepende use case hoeft nu verder de implementatie van de selecterende use case niet te kennen, nog die van het geselecteerde object.

Meestal worden in een eerste iteratie de schermen geproduceerd analoog aan het user interface model. Hierbij komen de details van de singletons en lists nog nauwelijks aan de orde, tenzij al bekend. Het volstaat meestal om de "meest verwachte" attributen van een object te tonen, zoals "naam", "woonplaats", "type ".
In volgende iteraties kan dan, nadat de gebruikersvertegenwoordiger de schermen of webpagina's heeft bekeken en feedback hierop heeft geformuleerd, sneller de precieze invulling van de singletons en lists worden gedefinieerd.

Neem attributen en validaties bij voorkeur op als sub-stap van het tonen van objecten. Voorbeeld:
2. Toon Klant en Orders*
2a. (naam, adres en woonplaats; besteldatum, bedrag, afleverdatum)
2b. (afleverdatum >= besteldatum).

Het is van belang de use cases simpel, duidelijk en gestructureerd te hebben voordat aan de interactiediagrammen wordt begonnen. De mate van detail moet in de gaten worden gehouden. Als de gebruikers de use cases niet meer begrijpen, is de uitwerking waarschijnlijk te gedetailleerd en wordt er geprobeerd de applicatie te ontwerpen in de use cases.

Indien bij het formuleren van de postcondities van een use case niet een helder doel kan worden vastgesteld - uitmondend in heldere postcondities - kan mogelijk worden geconcludeerd dat de use case geen valide, eenduidige functionaliteit verwoordt.