Inhoud. Gelaagde Architecturen (4): Voorbeelden. Gelaagde Architecturen (4): Voorbeelden

Gelaagde Architecturen (4): Voorbeelden

Gelaagde Architecturen (4): Voorbeelden Voorbeelden bij de artikelen ‘Gelaagde architecturen’ 1-3 van Leo Pruijt en Wiebe Wiersema, Hogeschool Utrecht. De artikelen beschrijven het ‘Logica In Lagen’-referentiemodel en de stappen om tot een Logisch en Fysiek Lagenmodel te komen. De artikelen zijn gepubliceerd in Release - Vakblad voor de Software Architect, vanaf december 2010. En in Optimize – Onafhankelijk vakblad voor de Oracle professional, vanaf februari 2011.

Inhoud 1.

CASUS: AANWEZIGHEIDSREGISTRATIESYSTEEM ........................................................................................ 2

2.

LOGISCH LAGENMODEL ...................................................................................................................................... 3 STAP 1: BEPAAL DE KWALITEITSDOELEN........................................................................................................................... 3 STAP 2: ONDERKEN LOGISCHE LAGEN.............................................................................................................................. 4 STAP 3: BEPAAL DE COMMUNICATIEREGELS TUSSEN DE LAGEN ........................................................................................ 5 STAP 4: TOETS DE GESCHIKTHEID VAN HET LAGENMODEL ................................................................................................ 6 STAP 5: DOCUMENTEER HET LAGENMODEL ...................................................................................................................... 7

3.

FYSIEK LAGENMODEL: PHP IMPLEMENTATIE ................................................................................................ 8 STAP 6: EVALUEER DE KWALITEITSDOELEN EN KIES DE TECHNOLOGIE .............................................................................. 8 STAP 7: ONDERKEN EN ONTWERP DE FYSIEKE LAGEN ...................................................................................................... 9 STAP 8: ONTWERP DE COMMUNICATIE TUSSEN DE LAGEN .............................................................................................. 10 STAP 9: TOETS DE GESCHIKTHEID VAN HET LAGENMODEL .............................................................................................. 11 STAP 10: DOCUMENTEER HET LAGENMODEL .................................................................................................................. 11

4.

FYSIEKLAGENMODEL: RUBY ON RAILS IMPLEMENTATIE ......................................................................... 12 STAP 6: EVALUEER DE KWALITEITSDOELEN EN KIES DE TECHNOLOGIE ............................................................................ 12 STAP 7: ONDERKEN EN ONTWERP DE FYSIEKE LAGEN .................................................................................................... 13 STAP 8: ONTWERP DE COMMUNICATIE TUSSEN DE LAGEN .............................................................................................. 15 STAP 9: TOETS DE GESCHIKTHEID VAN HET LAGENMODEL .............................................................................................. 16 STAP 10: DOCUMENTEER HET LAGENMODEL .................................................................................................................. 16

© Hogeschool Utrecht/Leo Pruijt en Wiebe Wiersema

1


1. Casus: Aanwezigheidsregistratiesysteem Een Regionaal Opleiding Centrum is wettelijk verplicht de aan- en afwezigheid van een deelnemer aan een van de (vele) opleidingen te registreren. Het betreffende ROC is voortgekomen uit fusies van verschillende instituten die zeer verschillend omgingen met de aanwezigheidsregistratie. Eén uniform bedrijfsproces, ondersteunt door een nieuw informatiesysteem, moet eenheid brengen en een aanzet geven tot een goede registratie van de aan- en afwezigheid.

Significante use cases (onder de 26 use cases) Aanwezigheid registreren per klas

Overzicht aanwezigheid per student

Docent

Ziekmelding deelnemer registreren

Activiteiten beheren

Administratief medewerker

Belangrijke domeinklassen *

Location

*

0..*

Education

1

Department

0..*

1

Institute

1 1

*

0..*

*

Classroom

1 0..*

0..* Course

Participant

Class 0..*

1

1

1

0..*

1

1 0..*

0..* 0..*

Activity *

0..*

-startTime -endTime

0..*

Teacher

0..1

0..*

Presence -presence : bool -reason : string

1

0..*

0..*

0..*

ActivityType 1


2


2. Logisch Lagenmodel Leo Pruijt

Stap 1: Bepaal de kwaliteitsdoelen Kwaliteitsdoel De informatie die wordt vastgelegd moet absoluut betrouwbaar zijn. Vereiste kwaliteiten: 1. Alle gegevens die worden vastgelegd, moeten gecontroleerd zijn. Het systeem moet eenvoudig en tegen lage kosten aangepast en uitgebreid kunnen worden, omdat het een lange tijd gebruikt zal gaan worden. Vereiste kwaliteiten: 2. Goede analyseerbaarheid van het systeem. 3. Domeingenerieke logica wordt slechts op één plek vastgelegd en van daaruit hergebruikt. 4. De applicaties zijn zoveel mogelijk onafhankelijkheid van wijzigingen in de database-structuur. 5. DBMS, applicatieserver, randapparatuur, et cetera moeten eenvoudig vervangen kunnen worden. De mogelijkheid tot fraude met de aanwezigheidsregistratie moet voorkomen worden. Vereiste kwaliteiten: 6. Het systeem moet op alle toegangsniveaus beveiligd zijn. De beheerkosten van het systeem moeten laag zijn en ook bij groeiend gebruik (meer opleidingen, ook toegang voor studenten) zal een hoge responsiesnelheid gegarandeerd moeten worden. 7. Goede schaalbaarheid. 8. Responsiesnelheid gemiddeld max 1 sec (rapportages uitgezonderd). Het systeem moet eenvoudig met andere applicaties (zoals Schoolplan) en hun opvolgers/vervangers kunnen communiceren. 9. Open standaard voor communicatie.


ISO 91 26 Quality Attribute Accuracy

Maintainability: Analysability, Changeability, Stability Portability: Adaptability

Security

Efficiency: Resource utilasation, Time behaviour

Interoperability

3


Stap 2: Onderken logische lagen 2.1 Bepaal welke lagen nodig zijn om de kwaliteitsdoelen te realiseren In onderstaande tabel staat aangegeven welke lagen (uit het LIL-referentiemodel) onderscheiden zijn om de kwaliteitsdoelen uit de vorige stap te behalen. Kwaliteitsdoel 1. Alle gegevens die worden vastgelegd, moeten gecontroleerd zijn. 2. Goede analyseerbaarheid van het systeem.

3. Domeingenerieke logica wordt slechts op één plek vastgelegd en van daaruit hergebruikt. 4. De applicaties zijn zoveel mogelijk onafhankelijkheid van wijzigingen in de database-structuur. 5. DBMS, applicatieserver, randapparatuur, et cetera moeten eenvoudig vervangen kunnen worden. 6. Het systeem moet op alle toegangsniveaus beveiligd zijn. 7. Goede schaalbaarheid. 8. Responsiesnelheid gemiddeld max 1 sec (rapportages uitgezonderd). 9. Open standaard voor communicatie.

Benodigde lagen Domeingeneriek Presentatie Taakspecifiek, Domeingeneriek Infrastructuur abstractie Presentatie/Taakspecifiek, Domeingeneriek Infrastructuur abstractie, Infrastructuur Infrastructuur abstractie, Infrastructuur Infrastructuur -

2.2 Orden de lagen en definieer ze

Taak

Domein

InfrastructuurAbstractie

Infrastructuur

Laag

Bevat de logica (conform het LIL-referentiemodel)

Taak

Presentatie en Taakspecifieke logica

Domein

Domeingenerieke logica

Infrastructuurabstractie

Infrastructuurabstractie

Infrastructuur

Infrastructuur


4


Stap 3: Bepaal de communicatieregels tussen de lagen 3.1 Bepaal welke standaardregels gelden en waarom De regels 1, 2, 3 en 5 in de onderstaande tabel zijn afgeleid van de standaardregels. Het gerelateerde kwaliteitsdoel vormt de motivatie voor de regel. 3.2 Bepaal welke uitzonderingsregels gelden en waarom Regel 4 en 6 vormen uitzonderingsregels. Regel 7 ondervangt een nadeel van regel 6. Regel

Kwaliteitsdoel

1. Alle gegevens die worden vastgelegd, 1. Bij verwijdering, wijziging of invoer (DUC-acties) van gegevens mag de domeinlaag niet worden overgeslagen. moeten gecontroleerd zijn.

2. Geen aanroepen van de Domeinlaag naar de Taaklaag die ten koste gaan van de herbruikbaarheid.

2. Goede analyseerbaarheid van het systeem. 3. Domeingenerieke logica wordt slechts op één plek vastgelegd en van daaruit hergebruikt.

4. De applicaties zijn zoveel mogelijk onafhankelijkheid van wijzigingen in de database-structuur. 5. DBMS, applicatieserver, randapparatuur, 3. De infrastructuurabstractielaag mag nooit worden et cetera moeten eenvoudig vervangen overgeslagen. kunnen worden. 4. Aanroep vanuit alle lagen naar de security component in 6. Het systeem moet op alle toegangsniveaus beveiligd zijn. de Infrastructuurlaag is toegestaan (via de infrastructuurabstractielaag). 7. Goede schaalbaarheid. 5. Dit wordt bereikt met regel 3 en 7.

6. Bij read-only acties mag de domeinlaag worden overgeslagen 7. Read-only acties, waarbij de domeinlaag wordt overgeslagen moeten via een databasestructuurabstractie mechanisme werken. 8.

8. Responsiesnelheid gemiddeld max 1 sec (rapportages uitgezonderd).

9. Open standaard voor communicatie.

Grafische weergave van het lagenmodel op hoofdlijnen NB De details van de regels zijn niet zichtbaar! Taak

Domein

InfrastructuurAbstractie

Infrastructuur


5


Stap 4: Toets de geschiktheid van het lagenmodel De significante use case “Aanwezigheid registreren” is hiervoor uitgekozen, omdat die de kern van de systeemfunctionaliteit representeert. In het sequence diagram op analyseniveau is te zien welke functionaliteit nodig is om de use case af te handelen. In het sequence diagram op designniveau is te zien hoe de use case kan worden afgehandeld, rekening houdend met het lagenmodel. Ook is te zien waar de functionaliteit dan (logisch) terecht komt, zonder dat er al voor een specifieke implementatietechniek gekozen is.

Aanwezigheid registreren

Docent

Sequence diagram op analyse-niveau voor de use case: Aanwezigheid registreren

:Class

:Activity

:Participant

:Presence

Teacher getAllClasses()

getActivities()

getDetails()

getParticipants()

createPresence()

getDetails()

create()


6

Gelaagde Architecturen (4): Voorbeelden Sequence diagram op design-niveau voor de use case: Aanwezigheid registreren

Taaklaag

:RegPresenceUI

Infrastructuur Abstractielaag

Domeinlaag

:RegPresenceController

:Class

:Activity

:Participant

:Presence

DbFacade

Teacher initialise()

initialise()

getAllClasses()

selectClass()

selectClass()

getActivities()

selectActivity()

selectActivity()

getParticipants()

setPresence()

setPresence()

getAllClassData()

getDetails()

createPresence()

getActivityData()

getDetails()

getParticipantData()

create()

InsertPresenceData()

Stap 5: Documenteer het lagenmodel De resultaten van de stappen 1-3 vormen de kern van de documentatie. In het artikel ‘Gelaagde architecturen(1): Introductie’ wordt behandeld wat in de documentatie van een lagenmodel duidelijk gemaakt moet worden, zodat de systeemontwikkelaars er goed mee aan het werk kunnen gaan.


7


3. Fysiek Lagenmodel: PHP implementatie Leo Pruijt Met dank aan de studententeams van de Informatica-opleiding van de Hogeschool Utrecht voor hun inbreng, onderzoek en toepassingen op het gebied van PHP: • Ruben Mijwaart, Onno Dijkstra, Bili Xiahilil, Ismaël sadkaoui; • Martijn Gastkemper, Redmar Stienstra, Tom Zitter.

Stap 6: Evalueer de kwaliteitsdoelen en kies de technologie 6.1 Evalueer de kwaliteitsdoelen De in stap 1 geïnventariseerde kwaliteitsdoelen dekken ook de gangbare technologische risico’s af. Er worden geen nieuwe kwaliteitsdoelen onderkend. Wel wordt als extra, technische maatregel vastgesteld dat het MVC-pattern zal worden toegepast in verband met het kwaliteitsdoel ‘Goede analyseerbaarheid van het systeem’. 6.2 Kies de technologie die bij die doelen past Met Doctrine 1.2 kunnen de kwaliteitsdoelen 1, 2, 3, 4, 5, 6 en 7 gehaald worden. Met Zend en Smarty kan met name kwaliteitsdoel 2 gehaald worden. Met Zend-ACL kan kwaliteitsdoel 6 (deels) gehaald worden, met de beperking dat de beveiliging alleen op controllerniveau geïmplementeerd wordt. Met XML/SOAP voor externe communicatie kan kwaliteitsdoel 8 gehaald worden. Met JQuery kan de interactie dynamisch gemaakt worden. NB Een meer complete verantwoording van de technologie keuzen vormt onderdeel van het Architecture Notebook/SAD.


8


Stap 7: Onderken en ontwerp de fysieke lagen 7.1 Onderken de fysieke lagen 7.1.1 Tier model Een 3-tier deployment model combineert een goede performance met een (voor dit systeem) afdoend niveau van beveiliging.

Client Tier

Web Tier

EIS Tier

Apache/PHP server : Browser

Smarty

Oracle Database

HTML Zend Framework JavaScript ondersteund door jQuery

Doctrine

7.1.2 Lagenmodel Het logische lagenmodel en het technische raamwerk uit stap 5 moeten gecombineerd worden tot een fysiek lagenmodel, waardoor goed werkende applicaties kunnen worden ontwikkeld die voldoen aan de gestelde kwaliteitseisen.

Taak (View & Controller: Zend, Smarty, JQuery)

Domein (Model: Doctrine)

InfrastructuurAbstractie (Doctrine)

Infrastructuur

7.2 Ontwerp de fysieke implementatie van de lagen Onder 7.1 is al aangegeven welke technologie per laag gebruikt zal worden. © Hogeschool Utrecht/Leo Pruijt en Wiebe Wiersema

9

Gelaagde Architecturen (4): Voorbeelden Als aanvulling daarop worden de volgende implementatiekeuzen gemaakt: Taak-laag • View-functionaliteit en Controller functionaliteit (conform het MVC pattern) worden gescheiden in aparte klassen. • View en Controller klassen worden niet gescheiden in aparte packages of directories, maar samenhangende combinaties van view- en controllerklassen worden juist bij elkaar geplaatst. Domein-laag: • Alle domeingenerieke logica (validaties, berekeningen, …) wordt herbruikbaar gemaakt door deze in (OO)entities op te nemen. Daarmee wordt het Domain Model pattern [Fowler03] gevolgd voor DUC-acties. • De domeinfunctionaliteit zal in logische componenten worden ingedeeld. Infrastructuurabstractie-laag • Doctrine bevat een Object Relational Mapper (ORM) die de vertaalslag tussen de objectgeörienteerde klassen (entities) en de database tabellen regelt. Daarmee wordt het Data Mapper pattern [Fowler03] gevolgd. • Er zal gebruik gemaakt worden (juist ook voor de R- en zoekacties) van de Doctrine Query language (DQL), die Doctrine automatisch vertaald naar DBMS-specifieke SQL. Daarmee wordt het Data Mapper pattern [Fowler03] gevolgd.

Stap 8: Ontwerp de communicatie tussen de lagen 8.1 Evalueer de communicatieregels gedefinieerd op logisch niveau. De regels van logisch model kunnen gehandhaafd blijven, met de volgende beperkingen: • Regel 4 is overbodig, omdat er geen aparte security component komen. Voor deze applicatie wordt een afdoende niveau van beveiliging bereikt met Zend-ACL, maar daarbij wordt de beveiliging alleen op controllerniveau geïmplementeerd. • Doctrine is een framework dat een deel van de infrastructuurabstractielaag invult m.b.t. database benadering. Maar Doctrine wordt ook gebruikt voor de implementatie van de domein functionaliteit. Dit gebeurt op zo’n manier dat Doctrine niet eenvoudige manier vervangen kan worden door een ander framework of ORM-mapper. 8.2 Ontwerp de fysieke communicatie tussen de lagen De koppeling tussen taaklaag en domeinlaag wordt op de volgende wijze geminimaliseerd. • De domeinfunctionaliteit (verdeeld over logische componenten zal alleen via een Facade benaderbaar zijn. • Aanroepen vanuit de Taaklaag naar de Infrastructuurabstractielaag mag alleen Read-acties betreffen en mogen alleen in DQL. • Aanroepen vanuit de Domeinlaag naar de Infrastructuurabstractielaag mag alle soorten acties betreffen, maar mag alleen in DQL. • Er worden geen domeinobjecten geretourneerd van domein- naar taaklaag, maar er wordt gebruik gemaakt van het Data Transfer Objects pattern [Fowler03] of van arrays. In dit specifieke geval zullen de facade methodes van de domeinlaag multidimensionale PHP arrays retourneren.


10


Stap 9: Toets de geschiktheid van het lagenmodel Op fysiek niveau ziet de afhandeling van een use case er modelmatig als volgt uit:

Taaklaag

:View

Domeinlaag

:Controller

:Facade

:Domain1

:Domain2

Infrastr. abstr.laag

:Doctrine-ORM

Infrastruct. laag

:DBMS

Teacher read()

update()

Verder verdient het aanbeveling om door middel van een prototype aan te tonen dat de gemaakte keuzen leiden tot een werkende applicatie die aan de diverse niet-functionele eisen voldoet.

Stap 10: Documenteer het lagenmodel De resultaten van de stappen 1-3 en 6-8 vormen de kern van de documentatie. In het eerste artikel over de Gelaagde Architecturen wordt behandeld wat in de documentatie van een lagenmodel duidelijk gemaakt moet worden, zodat de systeemontwikkelaars er goed mee aan het werk kunnen gaan.


11


4. FysiekLagenmodel: Ruby on Rails Implementatie Wiebe Wiersema

Stap 6: Evalueer de kwaliteitsdoelen en kies de technologie Het gekozen raamwerk is Ruby on Rails (RoR), Rails is een open-source framework dat is bedoeld om webapplicaties in korte tijd te bouwen met behoud van goed onderhoudbare applicatie code. http://rubyonrails.org/ RoRvolgt het MVC principe voor de indeling van de applicatielogica en is technologie onafhankelijk opgezet. RoR kan zowel op Windows als op de Unix familie van operating systemen ontwikkeld en gehost worden en kan gebruik maken van de meeste populaire databases zoals Oracle, MySql, SqlServer etc. Daarnaast heeft RoR het “convention over configuration” principe waardoor heel veel zaken standaard ingevuld zijn zonder dat daarvoor extra instellingen nodig zijn. Evalueer de kwaliteitsdoelen De kwaliteitsdoelen zijn haalbaar, met als kanttekening dat de doelen 5,6,7 zorgvuldig met de opdrachtgever afgestemd moeten worden of ze door de te kiezen technologie afgedekt zijn. Kies de technologie die bij die doelen past Kwaliteitsdoel 10. Alle gegevens die worden vastgelegd, moeten gecontroleerd zijn.

11. Goede analyseerbaarheid van het systeem. 12. Domeingenerieke logica wordt slechts op één plek vastgelegd en van daaruit hergebruikt. 13. De applicaties zijnzoveel mogelijk onafhankelijkheid van wijzigingen in de database-structuur. 14. DBMS, applicatieserver, randapparatuur, et cetera moeten eenvoudig vervangen kunnen worden. 6. Het systeem moet op alle toegangsniveaus beveiligd zijn.

7. Goede schaalbaarheid. 8. Responsiesnelheid gemiddeld max 1 sec (rapportages uitgezonderd).

9. Open standaard voor communicatie.

Invulling 1. Dit doel wordt ingevuld door alle domein generieke logica in de Model classes onder te brengen en in de overige classes (View, Controller) geen gegevens logica onder te brengen. 2. Door een indeling van de applicatie in model, view en controller classes is de opbouw overzichtelijk 3. De model classes dwingen dit af 4. Wijzigingen in de database structuur werken door in de Model classes. De view classes wijzigen alleen als dit nodig is vanwege wijzigingen in de te tonen informatie. 5. RoR is technologie onafhankelijk opgezet. Wijzigingen in infrastructuur worden verborgen door de configuratie en de infrastructuur abstractie logica. 6. Functie beveiliging in Ruby vindt plaats in de controller classes. Hiervoor dient een zogenaamd filter ingesteld te worden die valideert of de toegang tot een functie geautoriseerd is (bijv. met behulp van de gem declarative_authorization). Het beperken van gegevens toegang is geen standaard ondersteuning voor, hiervoor dient in de model classes extra logica geprogrammeerd te worden.Toegang naar de database is met een wachtwoord beveiligd. 7. RoR is een stateless applicatie. Dit type applicaties kenmerkt zich door een goede schaalbaarheid. RoR is op dit vak geen uitzondering maar vraagt wel meer resources (RAM en CPU) dan een bijvoorbeeld een Java, PHP of .Net applicatie. Door gebruik te maken van software zoals Passenger wordt het gebruik van RAM beperkt. 8. Lijkt realistisch gegeven de performance van RoR websites op dit moment. Is wel een punt van aandacht. 10. RoR communiceert met XML en REST webservices door middel van de ActiveResource component en kan XML/SOAP gebruiken middels het SOAP4R component.


12


Stap 7: Onderken en ontwerp de fysieke lagen

7.1

Onderken de fysieke lagen

7.1.1Tier model Een 3-tier deployment model combineert een goede performance met een (voor dit systeem) afdoend niveau van beveiliging.

Rails is een stateless architectuur. Dit betekent dat deze heel goed horizontaal te schalen is, mits de database snel genoeg kan blijven reageren gedurende piekbelasting. Het product Phusion Passenger werkt als loadbalancer door verscheidene Rails instances op te starten en aanvragen over deze instances te verdelen. 7.1.2 Lagenmodel Het logische lagenmodel en het technische raamwerk uit stap 5 moeten gecombineerd worden tot een fysiek lagenmodel, waardoor goed werkende applicaties kunnen worden ontwikkeld die voldoen aan de gestelde kwaliteitseisen.


13

Gelaagde Architecturen (4): Voorbeelden 7.2 Ontwerp de fysieke implementatie van de lagen Onder 7.1 is al aangegeven welke technologie per laag gebruikt zal worden. Het onderstaande figuur gaat dieper in op de componenten die een Ruby on Rails applicatie bevat. Browser or Web Enabled Application

HTTP, RSS, ATOM

Apache, Nginx

Webserver

Requests

Forwards XML

XHTML, XML, CSS, JS, Images

Passenger

Responds

Responds

Runs forked rails instances

Loadbalances

RAILS Action Webservice

Action View

Dispatcher

Starts

Renders

Delegates

Action Controller Action

Redirects

View

Instantiates

Models

Active Record

Queries

Data

Delivers

Action Mailer

Mails Mail Server

Instantiates

Models

Active Resource

Requests

Replies

HTTP, XHTML

RESTfull Service

Database

Elementen van de Ruby on Rails architectuur: 1. Dispatcher De webserver (bijv. apache) geeft aanroepen door aan de Dispatcher. De Dispatcher start de afhandeling van de aanroep door een controller class (kind van Action Controller) te instantierenen een eenmethod aan te roepen op basis van de routing regels die ingesteld zijn in de routing configuratie. Hiermee worden aanroepen gekoppeld aan de logica die de aanroep kan afhandelen. 2. Controller De controller class bevat de logica rondom het verloop en de afhandeling van een aanroep. De meeste methods in een controller class zijn de volgende twee smaken: a. Presentatie voorbereidend Als een gebruiker een object opvraagt met een zogenaamde get, dan instantieert de controller de juiste model classes en geeft deze door aan de view die gebruikt wordt om het gevraagde object te tonen. b. Actie verwerkend Als een gebruiker een bewerking van een object wil uitvoeren (bijv. post of delete) dan instantieert de controller de juiste model classes, verwerkt de gevraagde verandering en vraagt de model classes om zichzelf te valideren en op te slaan. 3. Active Record Alle model classes erven van Activerecord. De logica om de database te benaderen is veilig geabstraheerd achter de methods van ActiveRecord. In een model class wordt gegevens specifieke logica, berekeningen en veld validaties opgenomen.


14

Gelaagde Architecturen (4): Voorbeelden 4. Action View Action laadt templates op basis van de aangeroepen method op de controller en converteert deze naar html, xml etc. naar gelang de behoefte van de aanroeper. 5. Action Webservice Deze class is bedoeld om op makkelijke wijze SOAP XML Services en de bijbehorende WSDL te publiceren. Door deze class te overerven met een zogenaamde api class en in deze api class de interface te specificeren kan vrij eenvoudig een webservice worden opgebouwd en gepubliceerd. 6. Action Mailer Actionmailer wordt gebruikt om mails vanuit de Rails applicatie te versturen. Het opbouwen van de inhoud van de mail gebeurt op dezelfde wijze als de inhoud van webpagina’s alleen worden nu templates gebruikt die mailinhoud genereren. 7. Active Resource Activeresource is bedoeld om eenvoudig restfull services aan te roepen en het resultaat van de aanroep als een model class terug te geven. Het stelt wel specifieke eisen aan hoe gegevens worden opengesteld door de leverende partij. Een alternatief hiervoor is het gebruik van SOAP4R.

Door het volgen van de standaard Ruby on Rails architectuur zijn de volgende implementatiekeuzen gemaakt: Taak-laag • View-functionaliteit en Controller functionaliteit (conform het MVC pattern)worden gescheiden in aparte klassen Controllers en Views. Models worden geïnstantieerd als kinderen van Active Resource of Active Record. • Model, View en Controller klassen worden gescheiden in aparte directories geplaatst conform de rails conventies. Domein-laag: • Alle domeingenerieke logica (validaties, berekeningen, …) wordt herbruikbaar gemaakt door deze in de model classes op te nemen. Daarmee wordt het Domain Model pattern [Fowler03] gevolgd. Alle benadering van de database gaan via een Model class die erft van ActiveRecord. Infrastructuurabstractie-laag • ActiveRecord verzorgt de vertaalslag tussen de objectgeörienteerde klassen (entities) en de database tabellen. Daarmee wordt het Data Mapperpattern[Fowler03] gevolgd. • Het systeem gebruikt (juist ook voor de R- en zoekacties) de ActiveRecordQuery interface, die ActiveRecordautomatisch vertaald naar DBMS-specifieke SQL. Daarmee wordt het Data Mapperpattern[Fowler03] gevolgd. • Het systeem volgt voor het benaderen van externe webservices dezelfde aanpak de externe services worden achter modellen verborgen en daarmee zijn deze op het juiste abstractie niveau vanuit de de controller classes te gebruiken.

Stap 8: Ontwerp de communicatie tussen de lagen 8.1

Evalueer de communicatieregels gedefinieerd op logisch niveau.

De regels van logisch model kunnen gehandhaafd blijven zonder beperkingen. 8.2

Ontwerp de fysieke communicatie tussen de lagen

Dekoppeling tussen taaklaag en domeinlaag wordt op de volgende wijze geminimaliseerd. • De taaklaag maakt alleen gebruik van de interfaces zoals aangeboden door de methods en getters/setters van de Model classes.


15


Stap 9: Toets de geschiktheid van het lagenmodel Op fysiek niveau ziet de afhandeling van een use case er modelmatig als volgt uit:

Stap 10: Documenteer het lagenmodel De resultaten van de stappen 1-3 en 6-8 vormen de kern van de documentatie. In het artikel ‘Gelaagde architecturen(1): Introductie’ wordt behandeld wat in de documentatie van een lagenmodel duidelijk gemaakt moet worden, zodat de systeemontwikkelaars er goed mee aan het werk kunnen gaan.


16

Inhoud. Gelaagde Architecturen (4): Voorbeelden. Gelaagde Architecturen (4): Voorbeelden

Recommend Documents