Ontwerp
Opstellen service sequence diagrammen

Component based development Wanneer projecten gebruik maken van componenten en services vergroot dit de behoefte van het project om hierover te kunnen communiceren. Dit introduceert additionele werkproducten en eindproducten als service sequence diagrammen en een bedrijfsarchitectuur.

In veel organisaties wordt component based development toegepast. In Smart worden twee typen sequence diagrammen gebruikt. Het eerste type beschrijft de applicatie, van user interface tot en met de aanroep van de eventuele service op een component. Het tweede type, het service sequence diagram, beschrijft de implementatie van de service in de component, inclusief interface classes, en business- en factory classes.

Ieder service sequence diagram modelleert de aanroep van precies één van de services van een component, vanaf de aanroep op de business- of factory class tot en met de implementatie in de component door interface class en organisatiegenerieke business- en factory classes. Bestaande componenten bieden overigens reeds geïmplementeerde services, waarvan gebruik kan worden gemaakt. Binnen een project vindt het modelleren van de service sequence diagrammen alleen plaats als de services nog moeten worden ontwikkeld, vaak in hetzelfde project.

Doel

Het opstellen van service sequence diagrammen voor alle services die worden ontwikkeld voor een component. Hiermee wordt inzicht verkregen in de structuur van een component.

Stappen

1. Creëeren service sequence diagram
   Creëer een service sequence diagram voor iedere methode van een business class in de application services die gebruikt maakt van één of meerdere componenten. Geef het object service sequence diagram dezelfde naam als de methode.
   
   
2. Invoegen aanroep service
   De eerste stap in het service sequence diagram voor de methode is de aanroep van de methode op de business class (vanuit een task).
   
   
3. Invoegen benaderen interface
   De tweede stap is ofwel het benaderen van de interface van een component ofwel het benaderen van een andere business class die deze functionaliteit vervult.
   
   
4. Modelleren stappenplan
   Modelleer de stappen van het stappenplan van de use case in het service sequence diagram. Of, indien dit niet dergelijke gedetailleerde informatie bevat, gebruik de workshop om te komen tot de definitie van de uitwerking van de methode. Modelleer hierbij alle functionele klassen die de component implementeert om de methode te realiseren. Voeg geen details ten behoeve van implementatie toe. De aansluiting van deze logische diagrammen op de applicatiearchitectuur komt later aan bod.
   Neem interfaces die bij deze taak voor het eerst aan het licht komen direct op in het componentenmodel (inclusief een package).
   
   
5. Modelleren mapping business class en component
   Indien de te benaderen interface reeds zijn geïmplementeerd (in een component dat al in productie is), modelleer dan vooral de mapping tussen de functionaliteit die van de business class wordt gevraagd en de mogelijkheden van de interface van het component. Meestal is het hier nodig om vertaalslagen aan te brengen die worden gerealiseerd door een of meerdere business classes in de application services.
   
   
6. Waarmaken postconidities service
   Zorg ervoor dat het service sequence diagram uiteindelijk het te verwachten resultaat retourneert. Dit resultaat is terug te vinden in het stappenplan van de use case, en wordt meestal in de eerstvolgende stap na uitvoering van de beschreven methode gebruikt.
   
   

Richtlijnen

Het is een goed streven om de communicatie tussen componenten zo minimaal mogelijk te houden. Dit betekent dat indien voor het uitvoeren van een methode de application service over meerdere componenten dient te beschikken, de application service hiervoor de regie voert. Alhoewel deze keuze een lichte overhead veroorzaakt, wegen de voordelen van onafhankelijkheid van de verschillende componenten ten opzichte van elkaar doorgaans hier ruimschoots tegen op.

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.