Ontwerp
Opstellen sequence diagrammen

Om de vertaling van business requirements naar functionaliteit (methoden van klassen) te maken, biedt het opstellen van interactiediagrammen een nauw sluitende oplossing. In een interactiediagram wordt het stappenplan van een use case vertaald naar aanroepen van methoden van task-, business- en factory classes. Deze vertaling is zo de basis voor de implementatie van deze klassen.

Een van de belangrijkste aspecten van deze taak is dat de vertaling "onder architectuur" dient plaats te vinden. Bij het opstellen van de sequence diagrammen wordt standaard naar de referentiearchitectuur van Smart toe gemodelleerd. Dit is herkenbaar aan het inzetten van klassen uit de verschillende delen van deze applicatiearchitectuur.

Deze taak is door al deze facetten een van de meest cruciale uit het proces en wordt dan ook uitvoerig besproken.

Doel

Voor iedere use case wordt een interactiediagram opgesteld. Hiermee wordt de vertaling van business requirements (wat) naar functionaliteit (hoe) bewerkstelligd.

Stappen

1. Initieren sequence diagram
   Creëer een sequence diagram bij iedere use case die wordt geïmplementeerd in het huidige increment. Geef het sequence diagram dezelfde naam (en eventueel hetzelfde nummer) als de use case.
   
   
2. Invoegen task
   Voeg als eerste een klasse (of object) toe aan het object sequence diagram met als stereotype "task". Deze klasse is verantwoordelijk voor de flow van het proces binnen de use case en implementeert als het ware direct het stappenplan van de use case.
   Voeg als eerste stap in het object sequence diagram een event toe dat de "task" klasse "opstart" en zo dus het uitvoeren van het proces vuurt.
   
   
3. Omzetten stappenplan in activiteiten
   Een van de belangrijkste activiteiten uit het gehele proces volgt nu. Het omzetten van het stappenplan van de use cases van het increment naar stappen in object sequence diagrammen. Hou hierbij aan dat iedere stap in het stappenplan van de use case, minimaal een stap oplevert in het object sequence diagram, maar mogelijk meerdere stappen.
   Vermijd al te veel detaillering - zeker in de eerste iteratie - zoals het afhandelen van fouten of het tonen van allerhande boodschappen en het stellen van vragen aan de gebruiker. Dergelijke stappen kunnen door pro-actieve ontwikkelaars makkelijk zelf worden ingevuld.
   
   
4. Opnemen uitzonderingen
   Neem de alternate courses van de use case op in het object sequence diagram. In het algemeen volgen uit de alternate courses diverse "als ... dan ..." constructies. De structuur van het gewenste scenario en de overige scenario moet duidelijk herkenbaar zijn in het interactiemodel.
   
   
5. Modelleren methoden business classes
   Indien bij het beschrijven van een stap business functionaliteit wordt aangeroepen, modelleer dit dan door een methode aan te roepen op de desbetreffende business class. Indien de business class nog niet is opgenomen in het business class model, dient dit nu te gebeuren.
   Let op: in de meeste CASE tools wordt een klasse automatisch aangemaakt, als deze wordt toegevoegd aan een object sequence diagram. Nu hoeft de klasse nog slechts aan het business class model te worden toegevoegd.
   
   
6. Inpassen factory classes
   In het sequence diagram komen stappen voor die (het retourneren van) een object van een bepaalde klasse implementeren. Hiervoor is het nodig om een klasse in het model te introduceren die de beschikking heeft over alle objecten van een bepaalde klasse. Zo'n klasse wordt een "factory" genoemd. In de meeste gevallen betreft dit de "overkoepelende" klasse (zoals Order dit voor Orderregel is). In sommige gevallen - vooral aan de top van de hiërarchie aan business classes - bestaat een dergelijke factory nog niet. Neem deze op in het object sequence diagram, met als methode het retourneren van één of meerdere specifieke instanties van een klasse. Bijvoorbeeld: een factory Relaties voor de klasse Relatie.
   
   
7. Waarmaken postcondities
   Zorg ervoor dat duidelijk is hoe de pre- en postcondities van de use case worden gebruikt en waargemaakt. Voor de postcondities geldt dat bij afsluiting van het proces de task verantwoordelijk is voor het doorgeven van informatie aan de aanroepende use case (meestal ook weer een task).
   
   

Richtlijnen

Zorg ervoor dat alle tasks erven van een algemene task (bijvoorbeeld klass Task). Veel van de functionaliteit van tasks kan namelijk eenmalig en eenduidig worden ontwikkeld, zoals een eventuele interface met workflow services.

Voorzie alle klassen van een duidelijke prefix die heel goed het type van de klasse weergeeft. Tasks krijgen de prefix "t" (voorbeeld tSelecterenMedewerker), business classes krijgen de prefix "bc" (zoals bcRelatie en bcKredietnemer), overige services en ook factories krijgen de prefix "sc" (zoals scMedewerkers of scWorkflow) en interface van services en componenten de prefix "i" (iProject en iAutorisatie).

Deze hier opgestelde object sequence diagrammen beschrijven het proces van user interface tot en met application services. Bij projecten waarbij component based development een rol speelt wordt de interactie vanaf de application services tot en met de componenten altijd in afzonderlijke object sequence diagrammen geregistreerd.

De task blijft altijd in controle over het proces!

Een belangrijke refactoring om op te letten bij het opstellen van de interactiediagrammen is 'Hide Delegate'. Dit geldt vooral voor het aanroepen van diverse methoden op business classes. Een factory Klanten bijvoorbeeld die een Klant retourneert, waarvan vervolgens slechts een methode wordt aangeroepen, komt hiervoor in aanmerking.