...
Voor de applicatie is ook een deployment diagram opgesteld met daarin alle servers waar de applicatie op komt te draaien. Hierbij zijn een aantal design keuzes gemaakt die in het kopje eronder staan verantwoord.
...
Design Sub-System Vue.js frontend:
<Do not really name the section “Sub-System A”, use a name that describes the responsibility of the sub-system, instead. Provide a section for each sub-system. These sections are iteratively added and refined during the sprints. Examples of sub-systems include Persistent Storage, Business Tier, Web Application, Webservice API. The sub-sections below may be extended if you think this is useful for describing the software design. The sub-sections below are only required for object-oriented sub-systems. Use other means to describe non-OO sub-systems (for instance Javascript modules).>
Design Class Diagram
<Object-oriented sub-systems should be described using a class diagram. If classes or interfaces are used across sub-systems, make sure you mention this in the description of the class diagrams. If your system entails layers, make sure you indicate this in the class diagram, e.g. by means of packages. For each class diagram, make sure you also mention the deployment artifact (from the deployment diagram) it is part of.>
Sequence Diagrams
<Provide sequence diagrams for major object interactions within the sub-system. It is ok if sequence diagrams cross sub-system boundaries. Make sure you explain this in the description of the diagram. Sequence diagrams must be consistent with the class diagrams described above. Also, if sequence diagrams cover interaction with users, make sure the diagrams are consistent with SDDs you may have documented as part of the SRS.>
Activity and State Diagrams
<This section is optional. If useful, provide activity and/or state diagrams to describe complex work flows and system state transitions>
Design decisions made for the sub-system
Keuze front-end framework
...
Decision
...
Description
...
Problem/Issue
...
Er moest een front-end framework worden gekozen.
...
Decision
...
Voor het front-end is er voor Vue.js gekozen.
...
Alternatives
...
Er bestaan andere front-end frameworks zoals React en Angular.
...
Arguments
...
Vanuit de opdracht was er al een voorkeur voor Vue.js. Verder zijn er voor- en nadelen van Vue.js onderzocht in het bijbehorende onderzoek.
Losse componenten
...
Decision
...
Description
...
Decision
...
Er is een duidelijk onderscheid aangebracht tussen enerzijds de pagina’s, en anderzijds de tools & componenten. Op deze manier kunnen tools en componenten geïmporteerd & hergebruikt worden.
...
Alternatives
...
In plaats van losse componenten hadden we ook kunnen kiezen om de code te herhalen.
...
Arguments
...
Het grote voordeel van losse componenten schrijven is dat ze maar op 1 plek hoeven te worden aangepast, wat efficiënter en minder foutgevoelig is dan dubbele code. Ook zijn de losse componenten een belangrijke onderdeel van het zogenaamde Declarative Rendering, wat inhoudt dat de componenten alleen updaten als hun data veranderd. Dit maakt het laden en navigeren binnen het HR Portaal efficiënter dan als de hele pagina herladen zou worden.
Design Class Diagram
Op basis van de ontwerpkeuze router is er een diagram opgesteld dat inzicht geeft in de paginastructuur uit de router.
Sequence diagrams
Dit onderdeel is niet van toepassing op het front end gedeelte. Er staan sequence diagrammen in het volgende onderdeel over subsystemen.
Design decisions made for the sub-system
Keuze front-end framework
Decision | Description |
|---|---|
Problem/Issue | Er moest een front-end framework worden gekozen. |
Decision | Voor het front-end is er voor Vue.js gekozen. |
Alternatives | Er bestaan andere front-end frameworks zoals React en Angular. |
Arguments | Vanuit de opdracht was er al een voorkeur voor Vue.js. Verder zijn er voor- en nadelen van Vue.js onderzocht in het bijbehorende onderzoek. |
Losse componentenFront-end schetsen
Decision | Description |
|---|---|
Problem/Issue | Omdat pagina’s vaak vergelijkbare onderdelen bevatten, zou er snel dubbele code ontstaan. |
Decision | Er is een duidelijk onderscheid aangebracht tussen enerzijds de pagina’s, en anderzijds de tools & componenten. Op deze manier kunnen tools en componenten geïmporteerd & hergebruikt worden. |
Alternatives | In plaats van losse componenten hadden we ook kunnen kiezen om de code te herhalen. |
Arguments | Het grote voordeel van losse componenten schrijven is dat ze maar op 1 plek hoeven te worden aangepast, wat efficiënter en minder foutgevoelig is dan dubbele code. Ook zijn de losse componenten een belangrijke onderdeel van het zogenaamde Declarative Rendering, wat inhoudt dat de componenten alleen updaten als hun data veranderd. Dit maakt het laden en navigeren binnen het HR Portaal efficiënter dan als de hele pagina herladen zou worden. |
Front-end schetsen
Decision | Description |
|---|---|
Problem/Issue | Alle developers moesten een duidelijk beeld hebben van hoe het front-end eruit zou gaan zien, zodat de stijl voor de verschillende onderdelen matched en het er als een geheel uit komt te zien. |
Decision | Er is besloten om al vroeg schetsen op te stellen voor alle interfaces die in de front-end te zien zijn. Dit bevatte dingen als de pagina-layout, kleurkeuzes, fontstijl, etc. Hierbij is vooral gekeken naar de bestaande JDI website, zodat het HR Portaal bij de bestaande pagina’s past. |
Alternatives | Het alternatief was om direct van start te gaan met de front-end code, zonder eerst schetsen te maken. |
Arguments | Het voordeel van de schetsen is dat alle front-end developers in het Perlman ontwikkelteam op dezelfde lijn zaten. Ook konden deze ontwerpen alvast richting de opdrachtgever gestuurd worden, zodat het voor de opdrachtgever duidelijk is wat ze konden verwachten (en eventueel kon er nog feedback op de ontwerpen komen vanuit de opdrachtgever). |
...
Design Sub-System Spring boot backend:
De backend voor het HR Portaal is geschreven in Spring Boot. De backend is een belangrijk onderdeel van het eindproduct, en in dit hoofdstuk zullen de structuur en ontwerpbeslissingen van de backend worden toegelicht.
Design Class Diagram
Onderstaand is het class diagram voor de gehele backend van het HR Portaal. In dit diagram is gekozen om relaties aan te geven tussen klasses, als deze klasses een variable hebben voor de andere klasse. De DTO's worden veelal gebruikt binnen methodes in de resource klasses; dit wordt niet als relatie weergegeven, maar de DTO's staan wel in de buurt van de resources waar ze worden gebruikt.
...
De backend voor het HR Portaal is geschreven in Spring Boot. De backend is een belangrijk onderdeel van het eindproduct, en in dit hoofdstuk zullen de structuur en ontwerpbeslissingen van de backend worden toegelicht.
Design Class Diagram
Onderstaand is het class diagram voor de gehele backend van het HR Portaal. In dit diagram is gekozen om relaties aan te geven tussen klasses, als deze klasses een variable hebben voor de andere klasse. De DTO's worden veelal gebruikt binnen methodes in de resource klasses; dit wordt niet als relatie weergegeven, maar de DTO's staan wel in de buurt van de resources waar ze worden gebruikt.
Sequence Diagrams
De volgende GRASP principes zijn van toepassing op de sequence diagrammen:
- Controller - Alle endpoints zijn aangemaakt in de resource classen. Deze laag handelt de UI interactie af.
- High cohesion & low coupling - Door een hoge samenhang en lage afhankelijkheid zijn de classen minder afhankelijk van elkaar en is het makkelijker om de code uit te breiden
- Information expert - De verantwoordelijkheden zijn toegekend aan de classen die de meeste informatie hebben om de verantwoordelijkheid te dragen.
Sequence diagram reserveren werkplek
...