Bedrijfsstudie
Bepalen applicatiearchitectuur

In Smart speelt de applicatiearchitectuur een belangrijke rol als hulpmiddel bij het vertalen van ontwerp naar code. Requirements en ontwerp van functionaliteit worden gemodelleerd aan de hand van de Smart applicatiearchitectuur. Dit is het best zichtbaar in de sequence diagrammen en de service sequence diagrammen. Voordat de verschillende iteraties van ontwerp en bouw worden gestart, dienen de verschillende typen klassen in de Smart applicatiearchitectuur, zoals tasks, business- en factory classes, te worden vertaald naar de gebruikte ontwikkelomgeving en architectuur, als J2EE of .NET. Maar wellicht ook naar een gebruikte class library die in een organisatie wordt gebruikt, of die voor of door het project wordt ontwikkeld. Indien in een organisatie al vaker gebruik is gemaakt van Smart is het waarschijnlijk dat de technische applicatiearchitectuur al eerder beschreven is.

Doel

De applicatiearchitectuur van Smart wordt gehanteerd als katalysator in de vertaling van ontwerp naar code. Hiervoor moet eenmalig worden onderzocht hoe de typen klassen uit de applicatiearchitectuur van Smart passen in de gekozen ontwikkelomgeving en architectuur.

Stappen

1. Vaststellen uitgangspunten applicatiearchitectuur
   Stel vast welke ontwikkelomgeving in het project wordt gebruikt, en welke architectuur in deze ontwikkelomgeving geldt, zoals Java/J2EE of .NET. Ga ook na of er eerdere projecten zijn uitgevoerd in de organisatie met de gekozen ontwikkelomgeving. Indien dit het geval is, zijn er wellicht al beslissingen inzake de applicatiearchitectuur genomen. Ga na of deze bruikbaar zijn in het project. Indien er eerder projecten zijn uitgevoerd volgens Smart zal er een eerdere, gebruikte versie van de applicatiearchitectuur gelden in de organisatie. Neem zo'n document als uitgangspunt voor de applicatiearchitectuur van het project.
   
   
2. Vaststellen implementatie tasks
   De verantwoordelijkheden van tasks in een applicatie zijn divers. Iedere task implementeert het stappenplan van een use case. Voor het realiseren van deze verantwoordelijkheden initieert de task forms en gebruikt de functionaliteit die applicatiespecifieke business- en factory classes bieden. Bovendien dient de task vaak als eenheid van transacties, als interface met een workflow engine of als elementaire taak in een batch.
   Leg de specifieke verantwoordelijkheden van de task vast. Ga na waar de task in de architectuur van de ontwikkelomgeving past. Bedenk voor welk type class een task wordt geïmplementeerd in de gekozen ontwikkelomgeving.
   
   
3. Vaststellen implementatie business- en factory classes
   Ga ook na hoe business- en factory classes worden geïmplementeerd in de architectuur van de ontwikkelomgeving. Hierbij is het vaak van belang dat vooral het benaderen van databases of componenten wordt ingericht.
   In webapplicaties dient bijvoorbeeld een uitspraak te worden gedaan waar de applicatiespecifieke bedrijfslogica draait, en hoe deze klassen omgaan met state en caching. Wellicht dat hiervoor een spike wordt uitgevoerd.
   
   
4. Vaststellen implementatie componenten en interface
   Onderzoek hoe de organisatie de organisatiegenerieke bedrijfslogica wenst te implementeren. Dit heeft effect op de inrichting van de nieuw te ontwikkelen componenten en interface en op het gebruik hiervan in de applicaties. De applicatiearchitectuur van Smart onderscheidt voor de implementatie van componenten interfaces, interface classes en organisatiegenerieke business- en factory classes, al dan niet ondersteund door utility classes. Hanteer de applicatiearchitectuur van Smart bij voorkeur als uitgangspunt voor de realisatie van nieuwe componenten, interfaces en services. Voer eventueel een spike uit met een klein, nog te realiseren component. Denk ook na over de uiteindelijke locatie waar dergelijke functionaliteit draait.
   Stel ook vast hoe de applicatiespecifieke business- en factory classes als adapter voor deze componenten kunnen fungeren.
   
   
5. Inrichten connecties met databases
   Vrijwel alle moderne applicaties maken gebruik van de databases. De connecties met deze databases worden gerealiseerd door utility classes. Indien de applicatiearchitectuur nog geen patronen bevat voor ontsluiting van de database en het benaderen en wegschrijven van data, voer dan een spike uit om dit te proberen. Ontwikkel op basis van de spike de interactiepatronen (in sequence diagrammen) en het mechanisme voor het benaderen van database, ofwel vanuit de applicatiespecifieke bedrijfslogica, ofwel vanuit de organisatiegenerieke componenten. Ontwikkel ook de bijbehorende utility classes. Leg het resultaat vast in de applicatiearchitectuur.
   
   
6. Inventariseren patronen
   Probeer in een zo vroeg mogelijk stadium te inventariseren welke (technische) functionaliteit regelmatig voor komt in de applicatie. Denk hierbij bijvoorbeeld aan standaard foutafhandeling, afdrukken en het benaderen van bestanden. Leg patronen vast voor het implementeren van dergelijke functionaliteit. Deze worden bij voorkeur vastgelegd in zogenaamde interactiepatronen (in een sequence diagram), waarbij de rollen van de betrokken klassen worden gemodelleerd. Probeer deze patronen eventueel uit in een spike en ontwikkel eventueel de bijbehorende utility classes tijdens deze spike. De uiteindelijke definitieve uitwerking van het patroon vindt pas plaats op het moment dat tijdens een iteratie de functionaliteit ook daadwerkelijk nodig is.
   
   

Richtlijnen

Parallelle eerste iteratie voor applicatiearchitectuur
Indien gewenst kan het invullen van de vertaling van de applicatiearchitectuur van Smart naar de ontwikkelomgeving worden uitgevoerd in één of meerdere iteraties. Het best kan een dergelijke onderzoek plaatsvinden parallel aan de eerste iteratie.

Generiek!
De applicatiearchitectuur is generiek. De beschrijving groeit tijdens projecten doordat er meer ervaring wordt opgedaan in de implementatie van ervan. Meer en meer zal het de applicatiearchitectuur van de organisatie beslaan voor projecten in de gekozen ontwikkelomgeving. Als gevolg van dit proces ontstaat vaak ook een framework of class library voor implementatie van de applicatiearchitectuur in de gekozen ontwikkelomgeving.

Niet-functioneel
De meeste beslissingen die worden genomen met betrekking tot de implementatie van de applicatiearchitectuur hebben betrekking op niet-functionele aspecten van applicaties. Dit wordt veroorzaakt doordat de applicatiearchitectuur bedoeld is om her te gebruiken in het project en door projecten door de hele organisatie heen.

Rol architecten organisatie
Het is verstandig bij het uitvoeren van deze taak architecten uit de organisatie te betrekken. Zo ontstaat draagkracht voor de genomen beslissingen. Gezien deze architecten vaak in meerdere projecten een bijdrage leveren, draagt dit bovendien bij aan het gebruik van een referentiearchitectuur voor de hele organisatie.