De afgelopen maanden heb ik samen met een aantal collega’s een vacatureportaal op het Liferay portal framework geïmplementeerd. Daarbij hebben we veelvuldig gebruik gemaakt van het genereren van Java code vanuit UML diagrammen en visa versa. Deze ervaring wil ik graag met jullie delen.
De opdracht was simpel: neem een bestaande webservice met vacatures, bedrijfsprofielen, zoekprofielen, etc.. Ontwikkel op basis daarvan de portlets die tesamen de portal gaan vormen. De webservice was deels gedocumenteerd en er was een functioneel ontwerp gemaakt. Een goed startpunt voor een project.
Technisch ontwerp
We zijn begonnen met het maken van een technisch ontwerp omdat we de webservice eerst goed wilde begrijpen en omdat we de volgende zaken goed gescheiden wilden houden:
- De portlets
- De webservice client implementatie
We hebben het technisch ontwerp gemaakt met behulp van UML interactie-, klasse- en sequentiediagrammen. Dit hebben we gedaan in Sparkx Enterprise Architect, naar mijn mening een van de beste UML tools.
Lagen
Voor het opdelen van de applicatie in verschillende lagen was onze belangrijkste doel om de webservice aanroepen uit de presentatie laag te houden. Om dit te realiseren zijn we tot een betrekkelijk eenvoudig 3 lagen model gekomen om de code functioneel op te delen:
- Service laag, deze laag is verantwoordelijk voor het aanroepen van de webservice.
- Model laag, deze laag bevat het domein model van de applicatie.
- Portlet/Presentatie laag, deze laag verzorgt de presentatie en de afhandeling van de gebruikers acties.
Elke laag heeft een specifieke functie. Ik zal in de volgende secties de drie lagen bespreken.
Model laag
Deze laag bevat de domeinklassen welke bepaald werden door het domein model van de webservice. De klassen in deze laag zijn POJOs (Plain Old Java Objects) met de nodige mapping attributen om van XML (resultaat van een webservice aanroep) naar object de deserialiseren.
Daarnaast hebben we zelf een aantal klassen toegevoegd die fungeerden als aggregate. Een aggregate is bedoel om het aantal relaties tussen objecten te beperken. Je kunt zeggen dat een aggregate als groep fungeert.
Voorbeeld
Om alle gegevens van een vacature op te halen moesten we een handvol webservice methoden aanroepen, dit is niet wat je in je presentatie code wilt terugzien. Dus hebben we een aggregate ontworpen die de resultaten van de diverse aanroepen bundelt.
Door elke klasse te modeleren in UML en direct te voorzien van de juiste mapping attributen en documentatie hebben we veel tijd bespaard: een druk op de knop en de Java klassen in deze laag waren gegenereerd.
Service laag
We hebben de service laag in UML uitgedrukt in de vorm van een klassendiagram met daarin alleen de interfaces. We hebben er voor gekozen om de interfaces functioneel op te delen: De vacature service is verantwoordelijk voor het zoeken en ophalen van vacatures en de bedrijfsprofielenservice is verantwoordelijk voor het ophalen van de bedrijfsprofielen.
De belangrijkste taak van de service laag is het groeperen van de diverse webservice aanroepen en het bundelen van de resultaten in aggregate objecten, lees: het abstraheren van de webservice.
Bij het ontwerpen van de service interfaces hebben we uitgezocht welke webservice aanroepen elke methode moet gaan doen. De namen van de webservice aanroepen hebben we vastgelegd in de documentatie van de desbetreffende methode.
Nadat we de interface gemaakt hadden hebben we de implementatieklassen gedefinieerd puur ter generatie van de code.
Portlet/Presentatie laag
Deze laag is verantwoordelijk voor het presenteren van de informatie en het afhandelen van gebruikershandelingen. We hebben bij het maken van het technisch ontwerp vooral gelet op de gebruikershandelingen die plaats kunnen vinden, de verschillende states waarin een portlet zich kan bevinden en de aanroepen naar de service laag. Dit hebben we gedaan met behulp van state- en interactiediagrammen.
Codegeneratie
Zoals eerder aangegeven hebben we intensief gebruik gemaakt van code generatie van UML diagrammen naar Java code. Dit heeft ons tijdswinst opgeleverd omdat we niet meer handmatig alle klassen over hoefden te zetten, wat saai en foutgevoelig werk is.
Gedurende het project zijn we op een aantal punten afgeweken van het technisch ontwerp. Gelukkig ondersteund Sparkx Enterprise Architect de mogelijkheid om van de gegenereerde code te synchroniseren met de UML diagrammen waardoor het technisch ontwerp gemakkelijk bijgewerkt kon worden.
Conclusie
Door slim gebruikt te maken van codegeneratie en code synchronisatie is het mogelijk om een van een statisch document een meegroeiend ontwerp te maken. Daarnaast kun je door slim gebruik te maken van aggregates complexiteit verbergen.
Ik hoop dat dit artikel je geholpen heeft bij nadenken over de architectuur van je eigen applicaties. Heb je een andere visie of ben je het ergens mee oneens? Plaats dan een reactie!