Dit document beschrijft de architectuur van het Bachelor Master Schakelsysteem (BaMaS). Het BaMaS systeem biedt een student de mogelijkheid om de overstapmogelijkheden tussen Bachelor en Master opleidingen te bekijken en zorgt er voor dat een student een optimale (overstap)keuze kan maken. De aangesloten opleidingsinstituten kunnen zich via BaMaS presenteren aan potentiële studenten, voorlichters decanen en iedere geïnteresseerde.

1.1 Document historie

Versie: 1.0 Datum: 24-Mei-2009
Historie
Versie	Auteur	Datum	Beschrijving
1.0	Ad van den Elshout	24-05-09	Creatie

1.2 Doel en scope

Dit document beschrijft de architectuur van het Bachelor Master Schakelsysteem (BaMaS), het geeft een abstracte beschrijving van de belangrijkste deelsystemen, de gebruikte standaarden en belanghebbenden. Dit document is de basis voor het ontwerp van het BAMAS systeem.

De architectuur diagrammen en opbouw van dit document zijn gebaseerd op de 4+1 Kruchten model view. Er wordt losjes gebruik gemaakt van UML diagrammen om inzicht te geven in het BaMaS Systeem, waar dit niet mogelijk of niet praktisch is worden ‘eigen’ diagrammen gebruikt. Doel is hier om zoveel mogelijk diagrammen en taal te gebruiken die inzichtelijk en leesbaar zijn voor de doelgroep van een bepaalde view.

1.3 Introductie

Het BaMaS systeem wordt opgezet als een web based systeem waarbij gebruik gemaakt wordt van open standaarden. De architectuur wordt gekarakteriseerd door het gebruik van de volgende patterns:

3-tier client/server pattern
Model-view-controller pattern
Front controller pattern

Het zijn voornamelijk deze patterns welke de architectuur op de hoofdlijnen vastleggen. Naast deze patterns wordt er nog gebruik gemaakt van het data mapper pattern (om de entiteiten op de database tabellen te mappen) en het layers pattern voor de module structuur.

1.4 SAD overzicht

Het SAD document beschrijft eerst de stakeholders en hun concerns, vervolgens worden de viewpoints uit de 4+1 Modelview beschreven waarna deze viewpoints uitgewerkt worden met verschillende views. Scenario’s worden vervolgens gebruikt om de architectuur op volledigheid en consistentie te toetsen.

1.5 Stakeholders

1.5.1 Stakeholders en Concerns

De doelgroepen (stakeholders) van deze architectuur beschrijving zijn de eigenaars, gebruikers en beheerders van het BaMaS Systeem. De volgende stakeholders worden onderscheiden:

Eindgebruiker

De eindgebruiker is geïnteresseerd in de overstapmogelijkheden tussen Bachelor en Master programma’s. De eindgebruiker wil eenvoudig een Bachelor of Master programma kunnen kiezen en daarbij zien welke overstap mogelijkheden er zijn, eventueel met bijbehorend schakelprogramma. Deze eindgebruiker is een student of een potentiële student, maar kan ook een geïnteresseerde docent zijn, een studiebegeleider of de ouders van een potentiële student. Het systeem zal voor de eindgebruiker eenvoudig te gebruiken moeten zijn, direct de gewenst gegevens op moeten leveren en te gebruiken zijn in zijn eigen taal.

BAMAS Accounthouder

De BAMAS accounthouder gebruikt het systeem voor de invoer en onderhoud van gegevens over instelling en opleidingen. De accounthouder wil direct over de gegevens beschikken, de accounthouder wil online help en online documentatie.

De volgende types accounthouders worden onderscheiden:

Bachelor Accounthouder
Master Accounthouder
Instellings Accounthouder

De accounthouder is een medewerker van een onderwijsinstelling.

BaMaS beheerder

De beheerder maakt en onderhoudt gebruikersaccounts. Is geïnteresseerd in hoe accounts aan te maken en te beheren en hoe de gegevens beveiligd zijn.

Software ontwikkelaars

Applicatie ontwerpers, programmeurs, database designers en documentalisten.

Deze moeten weten wat er precies opgeleverd moet worden, hoe het werk verdeeld gaat worden, de ontwikkelaars willen een opdeling in modules met hoge cohesie zodat de werkzaamheden zo afzonderlijk mogelijk kunnen gebeuren.

Software test en integratie

Het software test team en software integrators. Deze willen weten hoe er getest kan worden en hoe het systeem geïntegreerd wordt, en hoe nieuwe versies worden geïnstalleerd.

Kwaliteitsbewaking

Deze willen weten hoe de diverse kwaliteitsattributen beoordeeld kunnen worden en hoe de kwaliteit bewaakt kan worden.

Maintenance

Deze verzorgen het onderhoud en de uitbreidingen van het systeem. Deze zijn geïnteresseerd in een systeem wat goed te begrijpen is, eenvoudig uit te breiden en goed gedocumenteerd.

IT afdeling

Netwerk specialisten, database administrators, applicatiebeheerders ofwel de verantwoordelijken voor de infrastructuur. Deze zijn geïnteresseerd in welke hardware er gebruikt wordt, welke processen waar draaien, welke standaard software er aangeschaft moet worden, licenties, database omvang, netwerk topologie, welke tools er zijn om het systeem te monitoren, welke applicaties er opgeleverd worden maar ook de verwachte CPU belasting, memory sizes etc. Hoe het systeem 24/7 in de lucht te houden terwijl er backup’s gemaakt worden. Hoe het BaMaS systeem te migreren naar andere hardware en software platforms. Kan BaMaS met elke willekeurige browser overweg?

Financiële afdeling

Deze wil het systeem kunnen gebruiken om facturen te kunnen maken voor de deelnemende onderwijs instellingen. De gegevens moeten eenvoudig op te vragen zijn, de gegevens mogen alleen zichtbaar zijn voor een medewerker van de financiële afdeling.

Helpdesk/Support

Deze willen weten wat voor vragen en problemen verwacht kunnen worden, wat de online help mogelijkheden zijn, wat voor documentatie er opgeleverd wordt en waar alles te vinden is.

Project management

Deze zijn geïnteresseerd in een inschatting van de project omvang, de doorloop tijd, de benodigde mensen.

Bestuur universiteiten en hogescholen

Deze zijn geïnteresseerd in hoe potentiële studenten te werven voor hun instelling.

Bestuur digitale universiteit

Deze zijn geïnteresseerd in de verwachte ontwikkel- en onderhoudskosten en de risico’s van het project. Het bestuur wil bovenal een systeem dat toekomstvast is en grote aantallen gebruikers kan ondersteunen, het systeem moet daarom eenvoudig schaalbaar en uitbreidbaar zijn.

1.5.2 Prioritering concerns

Naast de gewenste functionaliteit komen uit bovenstaande lijst met stakeholders komen de volgende niet-functionele eisen (kwaliteitsattributen) naar voren:

Eenvoud in gebruik (Usability, Taalonafhankelijk)
Schaalbaar
Uitbreidbaar
Snelle responsetijden (Performance)
Security
Beschikbaarheid
Portabiliteit

De architectuur zal zich richten op deze lijst met kwaliteitsattributen en de bijbehorende prioriteit.

1.6 Viewpoint en View definities

De volgende viewpoints worden gebruikt:

Logical viewpoint
Development viewpoint
Process viewpoint
Physical viewpoint

Binnen deze vier viewpoints worden de views opgesteld.

De samenhang tussen de viewpoints word met een aantal typische cases aangetoond, dit is de +1 view uit de 4+1 model view.

1.6.1 Logical Viewpoint

1.6.1.1 Omschrijving

Beschrijft de functionaliteit van het BaMaS systeem, het geeft een functionele decompositie op een hoog abstractie niveau.

1.6.1.2 Stakeholders en Concerns

Dit viewpoint is vooral van belang voor de eindgebruikers en software ontwikkelaars. Dit viewpoint beschrijft gegevens, data flows, transacties, maar ook economische en business aspecten als return on investment

1.6.1.3 Elementen, Relaties, Eigenschappen en beperkingen

Dit viewpoint omvat de belangrijkste entiteiten, elementen, interfaces, relaties.

UML Use cases, klassen, state en sequence diagrammen worden gebruikt om dit viewpoint te beschrijven.

1.6.1.4 Kwaliteitscriteria

Belangrijkste kwaliteitsattributen hier zijn:

Functionaliteit en Gebruiksvriendelijkheid

1.6.2 Development Viewpoint

1.6.2.1 Omschrijving

Beschrijft de implementatie van het BaMaS systeem, dit viewpoint beschrijft de modules of subsystemen en lagenstructuur van het te bouwen systeem. Het BaMaS systeem wordt in dit viewpoint opgedeeld in kleinere delen welke door ontwikkelaars of teams aangevat kunnen worden.,

1.6.2.2 Stakeholders en Concerns

Dit viewpoint is vooral van belang voor de software ontwikkelaars en ontwerpers. Dit viewpoint verdeelt het systeem in modules welke door ontwikkelaars min of meer afzonderlijk kunnen worden gebouwd.

1.6.2.3 Elementen, Relaties, Eigenschappen en beperkingen

Dit viewpoint omvat de modules en packages welke het systeem opdelen in brokken ‘werk’.

Package diagrammen worden gebruikt om dit viewpoint te beschrijven.

1.6.2.4 Kwaliteitscriteria

Belangrijkste kwaliteitsattributen hier zijn:

Modificeerbaarheid en Portability

1.6.3 Process Viewpoint

1.6.3.1 Omschrijving

Beschrijft de dynamische aspecten van het systeem, de processen en hun onderlinge samenhang en hoe de verwerking plaatsvindt. Zaken als performance, betrouwbaarheid, robuustheid en concurrency komen in dit viewpoint aan bod.

1.6.3.2 Stakeholders en Concerns

Dit viewpoint is vooral van belang voor de software ontwikkelaars, testers, software integrators en maintenance.

1.6.3.3 Elementen, Relaties, Eigenschappen en beperkingen

Process diagrammen worden gebruikt om dit viewpoint te beschrijven.

1.6.3.4 Kwaliteitscriteria

Belangrijkste kwaliteitsattributen hier zijn:

Performance, Security

1.6.4 Deployment Viewpoint

1.6.4.1 Omschrijving

Beschrijft de inbedrijfstelling en onderhoud van het BaMaS systeem. Dit viewpoint beschrijft o.a. de gebruikte hardware systemen, de netwerk topologie, proces deployment maar ook procedures voor exploitatie zoals installatie en backup / restore en (periodiek) onderhoud. Ook security aspecten (bijv routers en firewalls) worden hier gedeeltelijk beschreven en performance en reliability aspecten worden in dit viewpoint bekeken.

1.6.4.2 Stakeholders en Concerns

Dit viewpoint is vooral van belang voor systeem engineers, maintenance, netwerk engineers en IT afdeling.

1.6.4.3 Elementen, Relaties, Eigenschappen en beperkingen

Security diagrammen met LAN, firewalls, routers etc.

1.6.4.4 Kwaliteitscriteria

Belangrijkste kwaliteitsattributen hier zijn:

Beschikbaarheid, Betrouwbaarheid, Schaalbaarheid en Performance

1.6.5 Scenario’s

Er wordt met een aantal scenario’s aangetoond hoe de 4 viewpoints onderling verbonden zijn. Deze scenario’s geven inzicht in het te bouwen systeem en geven een indruk van de consistentie en volledigheid van de architectuur. Ook geven ze een indruk van de robuustheid van de architectuur in de verschillende scenario’s.

Met het doorlopen van de scenario’s wordt een indruk gegeven van hoe de architectuur keuzen uitpakken voor de verschillende kwaliteitsattributen en worden de belangrijkste potentiële risico’s geïdentificeerd. Hiernaast worden de verschillende stakeholders sterk bij het project betrokken. Er zijn scenario’s geselecteerd welke kritiek zijn voor het functioneren omdat ze of de kern van het systeem vormen (het opvragen van een schakelprogramma bijvoorbeeld) of een risico vormen (is het systeem eenvoudig aan te passen).
Scenario’s worden toegevoegd en uitgevoerd tot er geen ernstige tekortkomingen in de architectuur meer gevonden worden.

De volgende scenario’s worden doorlopen:

Als een student de gegevens opvraagt van een Bachelor programma dan moeten deze binnen 0.5 sec beschikbaar zijn.
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Performance

Stakeholders en hun concerns:
Eindgebruiker
Levert het systeem de gewenste gegevens snel op.

Software ontwikkelaars
Is het duidelijk wat er precies gebouwd moet worden: hoe verloopt precies de interactie tussen gebruiker en BaMaS systeem.

IT afdeling
Zijn is de dataload optimaal verdeeld over de servers, is processors en memory capaciteit voldoende? Voldoet de netwerk structuur?
Een Spaanstalige student wil de schakelmogelijkheden bekijken tussen een bachelor programma van een Spaanse universiteit en een Master programma van een Franse universiteit
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Meertaligheid, Gebruiksvriendelijkheid

Stakeholders en hun concerns:
Eindgebruiker
Is het systeem eenvoudig en intuïtief te gebruiken en levert het de gewenste gegevens snel op.

Software ontwikkelaars
Is het duidelijk wat er precies gebouwd moet worden en is de interactie tussen gebruiker en systeem duidelijk

Helpdesk/Support
Is de online hulp voldoende duidelijk, is de terugkoppeling welke het systeem bij invoer fouten geeft duidelijk.
Instellingen willen de schakelprogramma’s in hun portal opnemen
Hiervoor wordt het systeem met webservices uitgebreid
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Modificeerbaarheid
....
Visueel gehandicapten willen het systeem kunnen gebruiken
Hiervoor wordt het systeem uitgebreid met een spraakcomputer
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Modificeerbaarheid, Gebruiksvriendelijkheid
Een master account houder voegt een nieuw schakelprogramma toe
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Security, Gebruiksvriendelijkheid
Na een systeemcrash moet er een backup worden teruggezet
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Beschikbaarheid
Er wordt een overload gesimuleerd
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Betrouwbaarheid
De door een accounthouder ingegeven datum voor een herinneringsmail is bereikt.
Dit scenario geeft inzicht in de volgende kwaliteitsattributen:
Gebruiksvriendelijkheid
.........

2 Architectuur doel & constraints

2.1 Beschrijving

Het BaMaS systeem moet gebruikers in staat te zijn om op eenvoudige wijze gegevens op te vragen over opleidingen en schakelmogelijkheden. Het systeem moet grote aantallen transacties kunnen verwerken, taal en locatie onafhankelijk zijn en gebaseerd zijn op internet technologie. Om met instituten in geheel europa te kunnen samenwerken moet er gebruik gemaakt worden van open standaarden.

2.1.1 System Overview

De architectuur is voor de belangrijkste hoofdlijnen op het 3-tier architectuur pattern gebaseerd waarbij de BaMaS code volledig in Java geschreven wordt, BaMaS wordt geïmplementeerd op een J2EE platform.

Rationale:

De 3-tier architectuur biedt een modulaire aanpak met duidelijke interfaces tussen de verschillende lagen, elk van de lagen kan afzonderlijk worden gemodificeerd zonder aanpassingen in de andere tiers. Met de 3-tier architectuur kan de dataload eenvoudig over meerder applicatie en database servers worden verdeeld.

Portabiliteit levert met een taal als Java relatief weinig problemen op. Voor een Java platform zijn bovendien alle benodigde drivers en connectors zonder meer beschikbaar.

2.1.2 Belangrijkste Kwaliteitsattributen

Uit de lijst met concerns komen de volgende kwaliteitsattributen naar voren welke in belangrijke mate de architectuur sturen:

Usability

Gebruiksvriendelijkheid

Het systeem moet door eindgebruikers en accounthouders intuïtief te gebruiken zijn. Help functionaliteit moet aanwezig zijn.

Meertaligheid

Het systeem moet in de toekomst te gebruiken zijn door alle Europese instellingen en het systeem moet in meerdere talen te gebruiken zijn.

Maintainability

Modificeerbaarheid

Nieuwe functionaliteit moet eenvoudig kunnen worden toegevoegd (bijvoorbeeld de mogelijkheid om de informatie op een mobiele telefoon op te vragen of de mogelijkheid om met een spraakcomputer te werken voor visueel gehandicapten)

Schaalbaarheid

Het systeem moet uitbreidbaar zijn tot minstens 50 transacties per seconde, wat ongeveer overeenkomt met 100 actieve gebruikers.

Efficiency

Performance

Het systeem moet, ook bij grote aantallen gebruikers, de gevraagde gegevens snel op kunnen leveren, de maximale response tijd is 0.5 seconden. Verwacht wordt dat dit met pieken gaat bijvoorbeeld bij het einde van een schooljaar of trimester. Er moeten tenminste 100 gebruikers tegelijkertijd actief kunnen zijn.

Security

Authentication

Het systeem moet beveiligd zijn tegen ongeoorloofd gebruik, met een userid/password combinatie wordt de toegang beveiligd.

Authorization

Gegevens over opleiding en schakelprogramma’s mogen alleen door geautoriseerde personen worden gewijzigd en deze personen mogen alleen hun ‘eigen’ gegevens wijzigen.
Het moet mogelijk zijn om rechten en permissies toe te kennen aan groepen gebruikers.

Reliability

Beschikbaarheid

Het systeem moet 24/7 beschikbaar zijn om gegevens op te vragen.

Betrouwbaarheid

Bij een transactie overload moet het systeem nog betrouwbaar functioneren.
Alle database updates moeten transactie consistent uitgevoerd worden

Portability

Het systeem moet zonder software wijzigingen overgebracht kunnen worden naar een ander platform.
Een eindgebruiker moet met elke browser kunnen werken.

3 Views

3.1 Logical viewpoint

3.1.1 Context View

3.1.1.1 Beschrijving

Deze view laat het systeem zien als een black box en toont alle entiteiten welke met het systeem communiceren.

3.1.1.2 Diagram

3.1.2 Class diagram

3.1.2.1 Beschrijving

Deze view beschrijft de belangrijkste klassen en hun samenhang welke binnen het BaMaS systeem worden onderscheiden. De conceptuele informatie structuur van het BaMaS systeem is eenvoudig genoeg om hier in deze SAD in een enkel diagram opgenomen te kunnen worden.

3.1.2.2 Diagrammen

Het bovenstaande diagram toont alleen de belangrijkste klassen met de associaties tussen deze klassen, de syntax is die volgens het UML klasse diagram.

3.1.3 Use cases

3.1.3.1 Beschrijving

Deze view beschrijft de belangrijkste use cases welke het systeem typeren. Een use case legt de interactie tussen gebruiker en systeem vast, de precieze uitwerking van de use case gebeurt tijdens de ontwerp fase. Er zijn geen use cases opgenomen welke betrekking hebben op het technische beheer (bijv. Onderhoud databases, opvragen performance en transactie statistieken etc.).

3.1.3.2 Diagrammen

Het bovenstaande use-case diagram toont de actors (bijv. een student) en de acties welke het BaMaS systeem uitvoert (de use case).

De mail server is hier als actor opgenomen, deze server is geen onderdeel van het BaMaS systeem. ‘Tijd’ is ook als actor opgenomen, deze ‘actor’ initieert het versturen van de herinnering mails als de door een accounthouder opgegeven periode verstreken is.

3.2 Physical viewpoint

3.2.1 Deployment view

Deze view beschrijft de hardware configuratie en toont op welke nodes de componenten zich bevinden.

De opzet is volgens het 3-tier client / server pattern met de Client PC (de webbrowser) in de presentation tier, de web en applicatie servers in de logic tier en de database server in de data tier. Het facade pattern is toegepast op webserver en applicatie server, de Client ‘ziet’ alleen de webserver, de servlets en JSP’s zijn afgeschermd.

De verschillende nodes zijn hier:

Client PC
Webserver
Applicatie server (als het aantal gebruikers toeneemt kan er een tweede identieke applicatie server worden opgenomen, de webserver moet hiertoe berichten kunnen verdelen tussen meerdere applicatie servers)
Database server

Rationale:

Het gebruik van het 3-tier pattern geeft een overzichtelijk systeem waarbij de interfaces vastliggen en tiers aangepast of compleet kunnen worden vervangen zonder consequenties voor de andere tiers. Voor het 3-tier ontwerp kan er gebruik worden gemaakt van standaard componenten zoals de apache webserver, servlet containers en een database server welke naadloos in het 3-tier pattern passen. Door het gebruik van een aparte applicatie server is het geheel eenvoudig schaalbaar. Maintainability is eenvoudig met deze gelaagde structuur. Door de overhead in communicatie tussen de verschillende servers scoort het pattern minder op de performance en efficiency kwaliteitsattributen maar dit weegt ruimschoots op tegen het voordeel van de schaalbaarheid en onderhoud.

3.2.2 Diagrammen

De blokken zijn in dit diagram de hardware nodes, de verbindingen zijn netwerk verbindingen, de blokken binnen de nodes zijn de componenten.

3.2.3 Database View

3.2.3.1 Beschrijving

Deze view beschrijft het type database, de opzet ervan, de belangrijkste entiteiten en de verwachte omvang.

3.2.3.2 Database

Voor de database wordt een relationele database gebruikt met SQL als query taal, voor de database leverancier is gekozen voor MySql.

Rationale:

Relationele databases zijn tegenwoordig de standaard, MySql is een open source database waarvoor voordelige onderhoudscontracten kunnen worden afgesloten. De database heeft zich bovendien bewezen in een groot aantal internet toepassingen.

3.2.3.3 Database entiteiten

Entiteit	Geschatte omvang (kBytes)	Geschat aantal records
Onderwijsinstelling	100	1000
Bachelor opleiding	100	20000
Master opleiding	100	10000
Schakel programma	200	100000
Accounts	1	1000
.....

De totale gegevenscapaciteit zal in de orde grootte zijn 20 Gbyte. Omdat er in de toekomst de mogelijk is om multimedia toepassingen op te nemen in instelling en opleiding beschrijvingen moet er een grote marge worden ingebouwd.

3.2.3.4 Hardware

De database wordt in een RAID-5 configuratie gebruikt.

Rationale:

De meest voorkomende hardware fouten zijn disk fouten, RAID-5 garandeert een ononderbroken werking als er een disk defect raakt terwijl deze defecte disk online vervangen kan worden.

3.2.3.5 Backup en Restore

Backup van de gegevens moet online kunnen gebeuren, de database wordt gedurende de backup read-only, wijzigen van gegevens is dan tijdelijk niet mogelijk, backup wordt automatisch ’s nachts gescheduled, verwachtte backup tijd < 1 uur.

3.2.4 System view

3.2.4.1 Beschrijving

Deze view beschrijft het beheer van het systeem, zoals opstart/afsluiten van de verschillende servers, deployment van servlets, monitoren van het systeem, systeem administratie, firewall configuratie en upgrade procedures.

3.2.4.2 Procedures

.....

3.3 Development viewpoint

3.3.1 Package view

Deze view beschrijft de packages, een package groepeert een aantal samenhangende modules (of subpackages).

De packages worden als WAR files opgeleverd, deze kunnen op een applicatie server geïnstalleerd worden.

3.3.2 Diagrammen

Dit diagram toont de packages met daarin de groepen van klassen. De pijlen geven het gebruik aan, een paal betekent hier dus ‘maakt gebruik van services van’.

Er wordt een lagenstructuur onderscheiden, waarbij onderdelen uit een elke laag slechts onderdelen uit dezelfde of lager gelegen lagen kunnen aanroepen (met uitzondering van de generieke routines, deze kunnen door alle lagen worden gebruikt). De hoogste lagen zijn het meest domein specifiek. De volgende lagen worden onderscheiden:

Applicatie control laag

Deze laag bevat de control klassen zoals OpvragenSchakelProgramma

Applicatie klassen laag

Deze laag bevat de applicatie klassen zoals BachelorOpleiding, MasterOpleiding etc

JavaBeans laag

Deze bevat de entity java beans

Database routines

Dit zijn de database I/O routines, deze laag bevat o.a. de database mappers

Gebruikte patterns en Rationale:

Database mappers
Dit is een glue-laag tussen de Java Beans en de database, een gebruiker kan hiermee objecten in hun geheel uit de database lezen en wegschrijven. Bij wijziging van database zijn code aanpassingen beperkt tot deze mappers.
Layers pattern
Er worden een aantal lagen binnen het BaMaS systeem onderscheiden waarbij elke laag slechts onderdelen uit dezelfde of lager gelegen lagen mag gebruiken. Hiermee wordt het systeem in lagen verdeeld welke elk apart ontwikkeld kunnen worden, het biedt voor elke laag een abstractie van de onderliggende lagen.

3.4 Process viewpoint

3.4.1 Process view

Het Model-View-Controller pattern en het Front controller pattern bepalen samen de activering en samenhang van servlets, JSP en JavaBeans.

3.4.2 Diagrammen

Alle request komen binnen bij de front servlet (controller), deze voert de authorizatie en authenticatie uit. Indien akkoord dan bepaalt deze vervolgens welke functionele servlet (bijv. Opvragen schakelprogramma) geactiveerd, deze creëert op zijn beurt de JavaBeans (Model) en activeert de betreffende JSP (View). Er zit geen logica in de JSP, deze vult een HTTP template met de informatie uit de JavaBean en stuurt deze als HTML pagina terug naar de client.

Gebruikte patterns en rationale:

Model-View-Controller pattern
Dit pattern ontkoppeld de BaMaS logica van de user interface en maakt het mogelijk om wijzigingen aan te brengen in logica zonder de user interface aan te passen en om de scherm lay-out aan te wijzigen zonder de logica aan te passen. De extra overhead gaat ten koste van performance en efficiency maar weegt ruimschoots op tegen het voordeel van een ontkoppeling tussen lay-out en logica.
Front controller pattern
Doordat alles centraal binnenkomt kan de security betrekkelijk eenvoudig geregeld worden, de front controller is bovendien de servlet welke de applicatie servlets activeert, bij uitbreidingen van het aantal applicatie servlet hoeft alleen de front controller servlet configuratie aangepast te worden. Toepassen van het front controller pattern levert overhead op en gaat weer ten koste van performance en efficiency, het voordeel in security en eenvoud van servlet configuratie weegt hier echter weer tegen op.

3.5 Scenario’s

Tactics geven een methode om de architectuur aan te passen door aan de ‘parameter–knop’ te draaien, de impact van de parameter wordt dan ook duidelijk, aan een parameter welke slechts een geringe impact op de architectuur heeft worden geen grote inspanningen verricht.

Scenario 1

Als een student de gegevens opvraagt van een Bachelor programma dan moeten deze binnen 0.5 sec beschikbaar zijn (exclusief de internet overhead tussen Webserver en Client PC).

Opmerking: De eis van 0.5 seconden is hier een ‘soft’ limit, er ontstaat geen schade als deze incidenteel niet gehaald wordt, de eis wordt zo geïnterpreteerd dat de gemiddelde response tijd onder de 0.4 seconden blijft met een standaard deviatie van 0.1 sec.

Kwaliteitsattribuut: Performance

Sequence uitvoering:

Een gebruiker selecteert vanaf de Client PC de URL www.bamas.com met GET parameters ‘instituut=OU, opleiding=Informatica’
Bericht komt binnen op webserver
Webserver analyseert bericht en stuurt deze door naar Servlet ‘Front Controller’ op applicatie server (geschatte verwerkingstijd: xxx mSec)
Servlet ‘Front Controller’ voert authorizatie check uit en stuurt deze door naar Servlet ‘Opvragen bachelor opleiding’ (geschatte verwerkingstijd: xxx mSec)
Servlet ‘Opvragen bachelor opleiding’ instantieert de java bean ‘Bachelor opleiding’ en bijbehorende JSP (geschatte verwerkingstijd: xxx mSec)
De JSP laadt de HTML template en vult de template met de java bean gegevens in en stuurt deze gegevens naar webserver(geschatte verwerkingstijd: xxx mSec)
Op de webserver wordt de pagina volgens de style sheet aangepast (geschatte verwerkingstijd: xxx mSec)
Webserver stuurt de HTML pagina naar de gebruiker (geschatte verwerkingstijd: xxx mSec)
Client PC ontvangt de HTML pagina

Totale verwerkingstijd: xxx mSec

De volgende parameters liggen binnen dit scenario vast (parameters waarop niet gestuurd kan worden):

De frequentie waarmee gebruikers gegevens opvragen
...

Parameters waarmee de architectuur gestuurd kan worden:

Caching van database gegevens
Database configuratie
Servlets en prioriteiten
Aantal processors in server
Aantal applicatie servers
Netwerk configuratie
Executie tijd van servlets
JSP configuratie
Concurrency settings van servlets
....

De parameters welke betrekking hebben resources (bijv. CPU’s, servers en memory caching) kunnen met de volgende Tactics worden geanalyseerd en verbeterd:

Vergroot de data cache voor de database gegevens
Optimaliseer het aantal processors in een server
....

De parameters welke betrekking hebben op scheduling (bijv. concurrency settings) kunnen met de volgende Tactics worden geanalyseerd en verbeterd:

Optimaliseer de concurrency settings
Limiteer de rekentijd per servlet
…..

De parameters welke betrekking hebben op message queueing kunnen met de volgende Tactics worden geanalyseerd en verbeterd:

Toepassen van een message queuing pattern om overload te voorkomen
Toepassen van load balancing pattern
....

Scenario 2

Een Spaanstalige student wil de schakelmogelijkheden bekijken tussen een bachelor programma van een Spaanse universiteit en een Master programma van een Franse universiteit
....

3.6 Evaluatie kwaliteitsattributen

De meest kritische kwaliteitsattributen binnen het BaMaS systeem zijn de modificeerbaarheid, schaalbaarheid en Performance. Omvang en aantal transacties zullen naar verwachting in de toekomst sterk groeien, het systeem moet in de toekomst voor zeer grote aantallen gebruikers snel de gevraagde gegevens op kunnen leveren, verwacht wordt ook dat BaMaS geïntegreerd gaat worden met de portals van instellingen en dat gegevens van instellingen automatisch ingevoerd gaan worden. Ook gebruiksvriendelijkheid en Security zijn belangrijke kwaliteitsattributen. Het moet laagdrempelig zijn voor de student, anders wordt het systeem niet gebruikt en toegang voor accounthouders moet afgeschermd zijn.

De beschreven architectuur borgt deze kwaliteitsattributen:

Modificeerbaarheid: Door gebruik van het front controller pattern kunnen wijzing in beveiligingsstrategie eenvoudig doorgevoerd worden, dit is belangrijk als in de toekomst wijzigingen automatisch gedaan gaan worden. Door het 3-tier en MVC pattern kunnen er eenvoudig servlets, JSP en HTTP templates worden toegevoegd zonder dat er aanpassingen in de bestaande componenten nodig is.

Het MVC pattern geeft een eenvoudig en goed beheersbaar model waarin eenvoudig functionaliteit bijgebouwd kan worden, maintainability is goed. Door de JSP's en aparte HTMP templates is taal onafhankelijkheid ook relatief eenvoudig. Ook hier is er veel overhead tussen de verschillende componenten, maar de meertaligheid en eenvoudige uitbreidbaarheid wegen hier weer ruimschoots tegenop.

Schaalbaarheid: Dataload kan over meerdere applicatie servers worden gespreid.

Gebruiksvriendelijkheid: Door het gebruik van het MVC pattern kunnen eenvoudig de view aangepast worden voor bijvoorbeeld meertaligheid, de enige aanpassing is hier het uitbreiden van de HTTP templates. Door het gebruik van de XSL stylesheets kunnen er verschillende browser platforms ondersteunt worden (bijv. browser op een mobiele telefoon)

Security: Door het gebruik van het front controller pattern wordt de toegang en autorisatie op een centraal punt afgeschermd.

Portabiliteit: Door het gebruik van Java kan de applicatie op een willekeurig platform geïnstalleerd worden.

Betrouwbaarheid: het grootste risico is hier een data overload, vastlopen van het systeem wordt door toepassing van de message queuing en load balancing patterns voorkomen.

4 Risico’s

De belangrijkste risico’s zijn: Performance, Modificeerbaarheid en Schaalbaarheid. Door toepassing van 3-tier en MVC pattern zijn Modificeerbaarheid en Schaalbaarheid in de architectuur zoals hiervoor beschreven goed geborgd. Voor de performance is dit toch minder duidelijk, de bouw van een proto type is noodzakelijk om goed inzicht in de performance eisen en werkelijke executie tijden te krijgen.

5 Toekomstvisie

Voor ontsluiting van de functionaliteit naar externe systemen en een maximale ontkoppeling zal een overgang naar web services architectuur in de toekomst nodig zijn. Door een betrekkelijk eenvoudige glue laag kan de huidige functionaliteit zonder veel problemen als een webservice worden aangeboden.

6 Referenties

[Alb03]	Stephen T. Albin	The Art of software architecture	2003
[Gam94]	Erich Gamma et al	Design Patterns	1994
[Kru95]	Kruchten	The “4+1” View Model of Software Architecture	1995
…

7 Acroniemen

BaMaS	Bachelor Master Schakelsysteem
.....