Follow Us on Twitter

De use case in de applicatie architectuur

Gepubliceerd in

Juli 2014 - Al jaren worden use cases gebruikt om de requirements van een applicatie te omschrijven. Door een set van requirements als een geheel te zien in een use case, is het mogelijk om de requirements te verduidelijken. Zeker naar klanten die niet gewend zijn om met requirements om te gaan.

Als logische set van requirements zijn use cases ook geschikt als bouwsteen voor een applicatie-architectuur. Door te werken op basis van use cases kunnen ontwikkelaars een applicatie use case voor use case bouwen. En testers hoeven maar naar een enkele use case tegelijk te kijken. Dit geeft een grotere mate van separation of concerns, maar introduceert wel het risico van duplicatie van code.

In dit Whitebook kijken we naar de mogelijkheden van het ontwikkelen op basis van use cases en hoe die mogelijkheden in de praktijk werken. Er wordt gekeken naar de gevolgen van het ontwikkelen op basis van use cases op de verschillende facetten van de applicatie. Ook wordt er kritisch gekeken in welke gevallen deze manier van ontwikkelen toegevoegde waarde biedt.

Use cases

Als beschrijving van de functionaliteit van een applicatie hebben use cases hun nut al lang bewezen. Door de functionaliteit van een applicatie op te delen in verschillende use cases, en die use cases als geheel te omschrijven, wordt duidelijk gemaakt wat de applicatie moet kunnen en in welke situaties.

Een use case beschrijving van een systeem bestaat uit twee belangrijke onderdelen. De individuele use cases en de samenhang van deze use cases.

Als voorbeeld voor dit Whitebook gebruiken we het onderstaande systeem:

 Use case overzicht

Figuur 1: Use case overzicht

In het use case overzicht worden drie use cases benoemd:
- Login: Het inloggen door een gebruiker (klant of beheerder).
- Beheer data: Het beheren van de applicatiedata door de beheerder.
- Raadpleeg data: Het raadplegen van data door een klant.

Zowel het raadplegen als beheren van data is afhankelijk van het aanloggen van de gebruiker. Alhoewel zowel de klant als beheerder werken met dezelfde dataset zijn de handelingen die daarmee gedaan kunnen worden verschillend. Een klant mag alleen raadplegen, terwijl de beheerder data moet kunnen aanpassen.

Afhankelijk van de applicatie zijn de verschillende use cases meer en minder met elkaar verweven. De mate van koppeling is een belangrijke maatstaf om te bepalen of het een optie is om de applicatie per use case op te bouwen. In ons geval zijn de eisen van de verschillende use cases verschillend genoeg om een opbouw per use case mogelijk te maken.

Applicatiearchitectuur

Applicaties worden tegenwoordig meestal ontworpen op basis van een lagenstructuur. Elke laag communiceert met de bovenliggende en onderliggende lagen voor zover deze aanwezig zijn. De meeste applicaties bestaan in ieder geval uit de volgende lagen:

  • Presentatie laag: Regelt hoe de applicatie er uitziet.
  • Business laag: Bevat alle bussiness logica.
  • Data laag: Regelt de communicatie met databronnen (database of webservice).

De applicatie in lagen

Figuur 2: De applicatie in lagen

In veel gevallen bestaan de lagen steeds uit een interface en een implementatie. Waarbij de interface laag de mogelijkheden van de bovenliggende laag definieert, en de implementatie de daadwerkelijke uitwerking. Deze strikte scheiding tussen lagen wordt separation of concerns genoemd. Elk deel van de applicatie doet alleen dat waar het voor bedoeld is.

Door het scheiden van de lagen worden grote voordelen behaald in de ontwikkeling en het onderhoud van applicaties. Doordat elke laag zijn eigen interface heeft kunnen de lagen apart van elkaar ontwikkeld en getest worden. Zelfs het vervangen van de implementatie is goed mogelijk.

Applicatie opbouw met usecases

Bij een applicatiearchitectuur op basis van use cases worden er verticaal door de applicatie complete sets functionaliteit gebouwd, welke beperkt zijn tot die functionaliteit die relevant is voor die use case. Door deze scheiding tussen de verschillende use cases kan een applicatie makkelijk gefaseerd gebouwd en getest worden. Door de strikte scheiding tussen de use cases is het effect van wijzigingen aan een use case op andere use cases zeer beperkt. In plaats van een scheiding tussen presentatie, business logica en data opslag is er nu dus een scheiding tussen complete groepen functionaliteit.

Use case architectuur

Figuur 3: Use case architectuur

In het eerder genoemde voorbeeld waren er echter wel afhankelijkheden tussen use cases. Het aanbrengen van deze afhankelijkheden in de applicatiearchitectuur haalt het voordeel van de opbouw op basis van use cases weer gedeeltelijk weg. Ook de scheiding van presentatie, business logica en data opslag, die grote voordelen voor de onderhoud van applicaties geeft, is verdwenen.

Een meer praktische invulling kan in het onderstaande plaatje gevonden worden. Hier wordt de applicatie opgebouwd per use case, maar worden ook een presentatie, business logica en data opslaglagen in de architectuur gebruikt. De login die gebruikt wordt door de andere twee use cases kan nu wel op een nette manier in de applicatiestructuur geplaatst worden.

Meerlaagse architectuur met use cases

Figuur 4: Meerlaagse architectuur met use cases

Door het gebruik van de scheiding die een meerlaagse architectuur biedt kunnen grote voordelen behaald worden wat betreft de beheersbaarheid en onderhoudbaarheid van een applicatie.

Zoals figuur 4 wel laat zien maakt het de architectuur van de applicatie niet minder complex. In plaats van de standaard 3 lagen zijn er nu 8 modules. Deze modules zijn echter steeds minder complex dan de lagen die er eerst waren.

Wel is de kans groot dat er duplicatie van code voorkomt. De business en datalagen zijn strikt gescheiden per use case terwijl er wel gezamenlijke elementen zullen zijn. Het beheren en raadplegen van data gaat wel over dezelfde data met eenzelfde structuur. In dit geval zal er in de datalagen waarschijnlijk veel duplicatie voorkomen.

Use cases in een SOA architectuur

Een meer specifieke uitwerking van deze architectuur kan in de Service Oriented Architecture (SOA) gevonden worden. De business laag wordt aangeboden als een Service, waarbij de presentatie laag gebruikmaakt van verschillende services. In het onderstaande plaatje is een dergelijke architectuur te zien. Twee applicaties gebruiken een set van 3 services. In dit geval is er een service bus gebruikt voor een verdere ontkoppeling, al hoeft dat natuurlijk niet.

SOA architectuur gebaseerd op use cases.

Figuur 5: SOA architectuur gebaseerd op use cases.

Door gebruik te maken van de voordelen van een SOA architectuur kan een applicatie geheel ontkoppeld worden van de onderliggende services. Dit betekent dat bij de ontwikkeling van elk element van de applicatie de andere delen buiten beschouwing kunnen worden gelaten, of door een tijdelijke nep service verzorgd worden. Als de echte service dan af is, kan de service bus naar de goede service gewezen worden zonder dat de andere delen van de applicatie er weet van hebben.

Toepasbaarheid

Een complete compartimentalisering van een applicatie zoals hierboven getoond, is niet voor elke applicatie geschikt. Er zijn een aantal voorwaarden waaraan voldaan moet worden voordat het introduceren van de use case in de applicatiearchitectuur zin heeft.

Complexiteit van de applicatie: Voor een zeer simpele applicatie zullen er weinig voordelen zitten aan het scheiden van de verschillende use cases. Bij een extreem complexe applicatie kan een scheiding in delen vaak veel meer voordeel bieden.

Overlap van de use cases: De scheiding op basis van use cases betekent dat er weinig tot geen mogelijkheid is tot hergebruik van code (tenzij het om een complete sub-use case gaat). Bij een use case die (vrijwel geheel) op zichzelf staat, zijn de voordelen van een scheiding groter.

Ontwikkelmethodiek: Een scheiding op basis van use cases past voornamelijk goed bij agile in iteratieve ontwikkelmethoden. Bij deze methoden wordt al gewerkt op basis van het bouwen van een bepaalde functionaliteit vanaf de database tot de presentatie aan de gebruiker. Dit heeft een grote overlap met de use cases. Bij een watervalmodel waarbij de gehele applicatie in een fase gebouwd wordt, vervalt het voordeel van per use case kunnen bouwen.

Conclusie

In dit Whitebook is een scheiding van een applicatie beschreven bovenop de standaard lagenstructuur. Door een applicatie ook te scheiden per use case kunnen er voordelen behaald worden in de beheersbaarheid van de applicatie. Door de opdeling in veel relatief simpele componenten wordt het wijzigen van een functionaliteit in de applicatie overzichtelijker. Ook tijdens de bouw kan er steeds een enkele use case gebouwd worden waarbij er door de scheiding veel minder (potentiële) impact is op de eerder opgeleverde use cases.

De scheiding is helemaal goed zichtbaar in een SOA architectuur waar elke service als een use case gezien wordt. Wijzigingen in een service hebben alleen impact op applicaties die van die services gebruikmaken. Maak je geen gebruik van de service dan zou er ook geen impact op de functionaliteit van de applicatie moeten zijn.

Het is echter niet in alle gevallen nuttig om een applicatie op te delen per use case. Bij het bepalen van de architectuur van de applicatie zal er dus gekeken moeten worden naar wat voor applicatie gebouwd moet worden, en wat een geschikte architectuur daarbij is. Dit is een van de vele mogelijkheden daarbij.

Referenties

Waardering:
 
Tags:

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.