Bouw
Bouwen van tasks

De tasks worden als laatste gebouwd en vormen de rode draad door de applicatie. Een task is verantwoordelijk voor de implementatie van een enkel proces, weergegeven in een use case. Tijdens dit proces voert de task de regie over de samenwerking tussen user interface en application services (zowel de business classes als de meeste algemene services).

Omdat de task de eenheid van realisatie van business functionaliteit is, en binnen een increment altijd "hele" use cases worden geconstrueerd, zal de interactie tussen functionaliteit uit verschillende incrementen altijd verlopen doordat binnen de uitvoering van een use case een andere use case wordt aangeroepen.

Omdat er ook voor tasks die pas in een eventueel volgende increment worden gebouwd facade tasks worden gemaakt, is de integratie van functionaliteit over verschillende incrementen snel te realiseren.

Doel

De constructie van de tasks verenigt de user interface met de functionaliteit van de application services. Als hierbij bovendien andere use cases worden aangeroepen is dit eveneens het moment om de functionaliteit van dit increment te verenigen met vorige incrementen.

Stappen

1. Creëeren tasks
   Creëer voor iedere use case (en bijbehorend sequence diagram) een task. In het algemeen implementeert deze task een interface (bijvoorbeeld iTask) of erft van een class uit het gebruikte framework. Geef deze class dezelfde naam als de bijbehorende use case.
   Zo levert de use case 'Selecteren Klant' de task tcSelecterenKlant op.
   Er wordt echter geen nieuwe task gemaakt indien deze use case al wordt aangeroepen door andere, reeds gerealiseerde use cases. In dit geval is er reeds in een eerder stadium een facade task gecreëerd. Voor de implementatie van de huidige use case wordt nu gebruik gemaakt van deze task.
   
   
2. Activeren task
   Creëer de methode waar de task geactiveerd wordt. Meestal is dit een methode die wordt voorgeschreven door de interface die de task implementeert.
   
   
3. Controleren precondities use case
   Controleer in de task altijd of de precondities van de use case waar zijn. Indien dit niet het geval is, mag de functionaliteit van de task eigenlijk niet worden aangeroepen.
   Implementeer in deze methode verder de stappen uit het sequence diagram bij de use case. Gebruik hiervoor de instanties van schermen of webpagina's en van de application services die nodig zijn. Indien de gewenste instanties nog niet bestaan, zorg ervoor dat deze gecreëerd worden door de task.
   
   
4. Implementeren stappenplan
   Indien er stappen zijn die het aanroepen van een andere use case beschrijven, creëer dan een instantie van de bijbehorende task en roep de methode van deze klasse die de task activeert. Controleer na afloop van de uitvoer van deze methode altijd of de postcondities van de aangeroepen use case waar zijn. Controleer zowel op het resultaat van het gewenste scenario als op het resultaat van de faal- en herstelscenario's.
   Als de aan te roepen use case nog niet is geïmplementeerd, creëer een facade task en roep daarop de activerende methode aan. Zorg er voor dat deze facade task het verwachte gedrag vertoont, door bijvoorbeeld de retourwaarden 'hard coded' toe te voegen. Zorg er hiermee voor dat de postconditie van de aanroep geldig wordt.
   
   
5. Bijwerken sequence diagram
   Indien de realisatie van de task afwijkingen vertoont ten opzichte van het sequence diagram, voeg deze aanpassingen toe in de sequence diagrammen.
   
   

Richtlijnen

Let op: indien er meerdere projecten gebruik maken van dezelfde technische applicatiearchitectuur verdient het aanbeveling de architecten van deze projecten te raadplegen.

Het gebruik van een interface die de standaardfuncties van de tasks in de applicatie representeert heeft de voorkeur boven overerving. In het eerste geval is het namelijk mogelijk om iedere willekeurige klasse als task te laten optreden, onafhankelijk van de toegepaste applicatiearchitectuur. Niet alle programmeertalen kennen echter het begrip interface.

In de programmeertaal Eiffel wordt bij het uitvoeren van een methode van een klasse altijd standaard gecontroleerd of de precondities waar zijn. Is dit niet het geval, dan wordt de methode niet uitgevoerd.
Een dergelijk principe kan vooral bij de implementatie van tasks, waar de in- en uitvoer van groot belang is, zeker als er gebruik wordt gemaakt van een workflow engine, zeer nuttig zijn. Implementeer hiervoor helper classes waarmee tests kunnen worden uitgevoerd die als eerste in de task worden uitgevoerd. De uitvoer van het proces kan eventueel worden gestaakt als de precondities niet waar blijken te zijn. Dit vergroot de stabiliteit en kwaliteit van de applicatie.

Het verdient aanbeveling om de activerende methode van tasks altijd van een retourwaarde te voorzien. Dit kan het best een betekenisloze parameter zijn - liefst een getal - die eenvoudig kan worden gebruikt om de correcte uitvoer van het proces te controleren.

Een task kan voor het realiseren van zijn verantwoordelijkheden soms gebruik moeten maken van een andere task. Dit treedt op als een use case een andere use case gebruikt. Dit levert een uitdaging indien de aan te roepen task nog niet is ontwikkeld, maar pas in een later increment aan de orde komt.
Dit probleem is te voorkomen door voor dergelijke (facade) tasks alvast te creëeren, waarbij de enige functionaliteit van deze task het waar maken van de postcondities van de use case is. Zo kan de aanroep naar de facade task worden geïmplementeerd, zonder dat deze daadwerkelijk is ontworpen en gebouwd.