Haalbaarheidsstudie
Identificeren herbruikbare services

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.

Veel organisaties kennen een domeinarchitectuur of businessarchitectuur voor de verschillende domeinen in de organisatie. Zo'n architectuur beschrijft meestal de logische concepten (of componenten) die een rol spelen in de organisatie. Indien een project niet het eerste is in een bepaald domein, bestaat de kans dat de domeinarchitectuur componenten onderscheidt waar het project gebruik van dient te maken. Soms zijn er reeds services van componenten beschikbaar die gerealiseerd zijn tijdens eerdere projecten. Deze services dienen zo snel mogelijk geïdentificeerd te worden.

Daarnaast is het mogelijk dat het huidige project ook services voor componenten ontwikkelt. Ook deze componenten moeten worden geïdentificeerd. Ook deze componenten maken mogelijk deel uit van de business- of domeinarchitectuur. Het vaststellen van de implementatie van deze services gebeurt overigens pas tijdens het ontwerp.

Doel

Aan de hand van een beschikbare business- of domeinarchitectuur kan snel worden opgemaakt of het project kan profiteren van reeds in eerdere projecten gerealiseerde services van componenten.

Stappen

1. Onderzoeken businessarchitectuur
   Ga na of de organisatie een business- of domeinarchitectuur kent voor het domein van de applicatie. Maak aan de hand van de zelfstandige naamwoorden in de namen van de use cases een opsomming van componenten in deze businessarchitectuur zijn die aansluiten op de applicatie. Deze activiteit kent een tweeledig doel. Enerzijds kan het duiden op mogelijke hergebruik van services en componenten, anderzijds draagt het project mogelijk bij aan de ontwikkeling van dergelijke services en componenten.
   
   
2. Vaststellen hergebruik van componenten
   Stel vast of er reeds services voor deze componenten zijn geïmplementeerd, bijvoorbeeld tijdens eerdere projecten. Indien dit het geval is, bepaal dan de technische eisen waaraan moet worden voldaan om deze componenten her te gebruiken. Denk bijvoorbeeld aan ontwikkelomgevingen, programmeertalen, middleware of persistentie. Leg dit mogelijk hergebruik vast in de haalbaarheidsstudie.
   
   
3. Vaststellen hergebruik van services
   Onderzoek nu of het mogelijk is om services van de geïdentificeerde componenten op redelijke wijze te hergebruiken. Zelfs als aan alle technische eisen rond hergebruik van een component of service wordt voldaan, is het nog niet zeker dat de service functioneel een passend oplossing biedt.
   Pas tijdens het ontwerpen van de sequence diagrammen voor de applicatie worden de precieze vragen aan de services van componenten duidelijk. Het volstaat hier een indicatie te geven van mogelijk hergebruik, bijvoorbeeld uitgedrukt in een percentage. Deze indicatie wordt gebruikt bij het opstellen van schattingen.
   
   
4. Vaststellen te ontwikkelen services
   Onderzoek nu welke componenten in de businessarchitectuur zijn gedefinieerd waarvoor het huidige project services zou kunnen opleveren. Aan deze services worden wellicht door de organisatie andere eisen gesteld dan aan de rest van de applicatie.
   
   
5. Opzetten component class diagram
   Het ontwerp van een component bestaat uit het component class diagram en uit een verzameling service sequence diagrammen voor de (nieuwe) services van het component. Het beste kan voor ieder component een nieuw model worden ingericht dat plaats biedt aan deze diagrammen. Creëer in het component class diagram alvast de geïdentificeerde interfaces, voorzien van een naam, zoals IRekening of IOverboeking.
   
   

Richtlijnen

Services en applicatiearchitectuur
In omgevingen waar component based development wordt ingezet, is het waarschijnlijker dat er herbruikbare componenten of services zijn gedefinieerd. Deze services dienen echter wel in te passen te zijn in de applicatiearchitectuur. Als hergebruik erg belangrijk is, moet mogelijk de applicatiearchitectuur van het project hiervoor worden aangepast.

Technisch hergebruik
Naast de identificatie van services en componenten in de businessarchitectuur, komt hergebruik van technische services eveneens veelvuldig voor. In tegenstelling tot de bedrijfsfunctionaliteit zijn dergelijke services vaak minder makkelijk te vinden bij projecten. Omdat ook technische services (in de vorm van utility classes) veel besparing kunnen opleveren verdient het aanbeveling ook hier naar op zoek te gaan. Naarmate er meerdere projecten zijn uitgevoerd in eenzelfde ontwikkelomgeving ontstaat vaak een groepering van dergelijke utility classes in de vorm van een class library of framework.

Levenscyclus van services
De levenscyclus van een service van een component kan zich in een aantal stadia bevinden. Zo kan de service deel reeds geidentificeerd zijn in de businessarchitectuur, maar nog niet zijn gerealiseerd. In het algemeen is het project nu vrij om de signature van deze service zelf te definieren. De service kan ook zijn ontwikkeld tijdens een eerder project en inmiddels zijn opgeleverd. Nu kent de service een bestaande signature, waarvan tijdens het ontwerp gaat blijken of deze bruikbaar is, uiteraard voorzien van een adapter. Tenslotte kan de gewenste service gelijktijdig met een project worden ontwikkeld door een ander project. Hergebruik wordt in dit stadium bemoeilijkt, doordat de signature van de service nog aan verandering onderhevig zal zijn.

Architect en businessarchitectuur
Het bewaken van de businessarchitectuur is veelal de verantwoordelijkheid van de architect. Deze architect kan naast de componentenbeheerder als specialist worden geraadpleegd.

Use cases en componenten
Voor het vergelijken van de use case diagrammen met de businessarchitectuur wordt gekeken naar de zelfstandige naamwoorden in de namen van de beschreven use cases. Deze komen vaak overeen met componenten in de businessarchitectuur. Soms wordt echter aan eenzelfde concept verschillende namen gegeven door architectuur en use case. Stem de naamgeving van het project nu zoveel mogelijk af op de businessarchitectuur, mits dit in overeenstemming is met de gebruikersvertegenwoordigers.

Hergebruik en schatten
Indien het project services kan hergebruiken of verantwoordelijk wordt voor het opleveren van services voor componenten, heeft dit invloed op het opstellen van schattingen voor het project. Waar hergebruik mogelijk is vermindert de complexiteit mogelijk. Indien nieuwe services voor componenten worden ontwikkeld, kost het herbruikbaar opleveren in het algemeen extra tijd. Hou hiermee rekening.