Tim Diels Feed Additive Report Publishing

Handelswetenschappen en Bedrijfskunde
Bachelor in de toegepaste informatica
Applicatieontwikkeling
Feed Additive Report Publishing
CAMPUS
Geel
Tim Diels
Academiejaar 2010-2011
3
VOORWOORD
Mijn stage en eindwerk zouden nooit zo vlot zijn gegaan zonder de hulp die ik gekregen
heb.
Allereerst wil ik het IRMM bedanken voor de stageplaats en –opdracht. Bedankt aan
San Pauwels, mijn stagebeleider die mij gedurende de stage begeleid heeft. En bedankt
aan Peter Lambert wie mij op weg heeft geholpen met de ontwikkelomgeving. Ook
bedankt aan alle andere mensen die ik heb leren kennen op het IRMM, om mijn stage
nog leuker te maken.
Bedankt aan mijn medestudenten van de KHK, Jasper Van Mensel en Sen Verleysen;
aan Tomas Van Mechelen, oud-student van de KHK die vorig jaar ook bij het IRMM
stage heeft gedaan, aan wie ik altijd vragen kon stellen.
Graag wil ik ook mijn begeleidende docent bedanken, Johan Smeuninx, voor al het
advies over het eindwerk en de stage zelf.
En als laatste dank aan mijn ouders en vrienden voor de steun doorheen de hele
stageperiode.
4
SAMENVATTING
Dit eindwerk gaat over mijn stage bij het Institute for Reference Materials and
Measurements (IRMM), een onderdeel van het Joint Research Centre (JRC).
Tijdens mijn stage heb ik voor de European Union Reference Laboratories (EURL) een
probleem geanalyseerd en de oplossing geïmplementeerd. De Food Safety and Quality
(FSQ) unit van het EURL publiceren maandelijks Feed Additive Authorisation (FAA)
rapporten en zouden dit graag automatiseren.
In de analysefase heb ik onder andere het doel en de scope van het project vastgelegd
en de uren geraamd met een vision document. Vervolgens heb ik de use cases
beschreven en een datamodel gemaakt van de nodige wijzigingen aan de bestaande
database. Elk document wordt opgestuurd naar de opdrachtgever en goedgekeurd.
In de ontwikkelfase heb ik:

De nodige wijzigingen gedaan in de bestaande database.

De interne administratie web applicatie van de FSQ unit aangepast zodat
meerdere additieven aan een product toegevoegd kunnen worden en er een
rapport kan gekoppeld worden aan een dossier.

Twee andere EURL web applicaties aangepast zodat deze werken met de nieuwe
database.

Een nieuwe web applicatie gemaakt die een lijst van rapporten kan genereren.
Deze zal weergegeven worden op de website van het IRMM in plaats van de
huidige statische lijst.
Op het einde van mijn stage heb ik de nieuwe functies kunnen afleveren, demonstreren
en heb ik hier positieve feedback op gekregen.
5
INHOUDSTAFEL
VOORWOORD ..................................................................................................... 2
SAMENVATTING ................................................................................................. 4
INHOUDSTAFEL .................................................................................................. 5
INLEIDING ......................................................................................................... 7
1
STAGEPLAATS ...................................................................................... 8
1.1
1.2
1.3
Joint Research Center .......................................................................... 8
Institute for Reference Materials and Measurements........................... 8
Informatics Unit................................................................................... 9
2
STAGEOPDRACHT ............................................................................... 10
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Aanleiding en achtergrond van het project ........................................ 10
Verwacht resultaat............................................................................. 10
Business Case .................................................................................... 10
Fasering ............................................................................................. 11
Projectafbakening.............................................................................. 11
Omschrijving van de primaire doelgroep............................................ 11
Andere stakeholders .......................................................................... 11
Informatie en rapportering ................................................................ 11
3
ANALYSE ............................................................................................ 12
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.3
Vision document ................................................................................ 12
Introduction ..........................................................................................12
Positioning ............................................................................................12
Proposed approach.................................................................................13
Stakeholder and user descriptions............................................................14
Information system overview ..................................................................14
Features ...............................................................................................14
Planned resources..................................................................................14
Constraints ...........................................................................................15
Use case specifications ...................................................................... 15
Use case description...............................................................................16
Flow of events .......................................................................................16
Preconditions.........................................................................................17
Postconditions .......................................................................................17
Screenshots ..........................................................................................17
Datamodel ............................................................................................17
Datamodel ......................................................................................... 17
4
ONTWIKKELOMGEVING...................................................................... 20
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.7.1
Oracle SQL Developer ........................................................................ 20
Java en Java EE.................................................................................. 20
Spring ................................................................................................ 21
Eclipse ............................................................................................... 21
Subversion ......................................................................................... 22
JIRA ................................................................................................... 23
RefApp ............................................................................................... 24
RefApp 1.2 ............................................................................................24
4.7.1.1
4.7.1.2
4.7.1.3
4.7.1.4
Hibernate.......................................................................................................................... 25
Spring configuraties ........................................................................................................... 25
Ant................................................................................................................................... 28
Tomcat ............................................................................................................................. 28
6
4.7.1.5
Hoe uitvoeren.................................................................................................................... 29
4.7.2
RefApp 3.2 ............................................................................................29
4.7.2.1
4.7.2.2
4.7.2.3
4.7.2.4
JPA .................................................................................................................................. 29
Maven .............................................................................................................................. 29
WebLogic .......................................................................................................................... 29
Hoe uitvoeren.................................................................................................................... 29
5
IMPLEMENTATIE VAN DE APPLICATIE................................................ 30
5.1
5.2
5.2.1
5.2.2
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
Migratiescript..................................................................................... 31
crlfaacatadmin ................................................................................... 31
Meerdere additives.................................................................................32
Published report.....................................................................................33
eurlreportlist...................................................................................... 33
RefApp 3.2 structuur genereren ...............................................................34
Report en Product data classes ................................................................35
ReportDao interface ...............................................................................37
ReportDaoImpl ......................................................................................38
ReportService........................................................................................41
ReportServiceImpl .................................................................................41
MVC Front-End ......................................................................................42
5.3.7.1
5.3.7.2
Controller (+model) ........................................................................................................... 42
JSP pagina (het view)......................................................................................................... 43
5.3.8
5.4
5.5
Deployment documentatie.......................................................................45
crlForms............................................................................................. 46
crlApplication..................................................................................... 47
BESLUIT 49
LITERATUURLIJST ............................................................................................ 50
7
INLEIDING
Dit eindwerk is het resultaat van dertien weken stage bij het Institute for Reference
Materials and Measurements (IRMM), een onderdeel van het Joint Research Centre
(JRC).
Mijn opdracht was het publiceren van rapporten te automatiseren voor de Food Safety
and Quality (FSQ) unit van de European Union Reference Laboratories (EURL). Hiermee
zal de FSQ unit sneller rapporten kunnen publiceren en zo meer tijd kunnen besteden
aan andere taken die meer business value opleveren.
In het eerste hoofdstuk stel ik mijn stageplaats voor. In hoofdstuk twee beschrijf ik
mijn opdracht. In het derde hoofdstuk leg ik de analyse van mijn project uit.
Vervolgens overloop ik de ontwikkelomgeving waarin ik gewerkt heb. In het laatste
hoofdstuk vertel ik hoe ik de implementatie zelf aangepakt heb.
8
1
STAGEPLAATS
In dit deel stel ik de plaats voor waar ik de voorbije dertien weken gewerkt heb.
1.1
Joint Research Center
Het Joint Research Center (JRC) is een Directoraatgeneraal van de Europese commissie. Het voorziet de
Europese Unie (EU) van wetenschappelijk en technisch
advies.
Figure 1-1 Logo JRC
Het JRC bestaat uit zeven instituten verspreid over vijf locaties in Europa:







1.2
Institute
Institute
Institute
Institute
Institute
Institute
Institute
for
for
for
for
for
for
for
Reference Materials and Measurements (IRMM) – Geel (BE)
Energy (IE) – Petten (NL) en Ispra (IT)
the Protection and Security of the Citizen (IPSC) – Ispra (IT)
Transuranium Elements (ITU) – Karlsruhe (DE)
Environment and Sustainability (IES) – Ispra (IT)
Health and Consumer Protection (IHCP) – Ispra (IT)
Prospective Technological Studies (IPTS) – Seville (ES)
Institute for Reference Materials and Measurements
Ik heb mijn stage gedaan bij het IRMM. Het IRMM is een van de
zeven instellingen van het JRC.
Figure 1-1 Logo IRMM
Het IRMM startte zijn werkzaamheden in 1960 en in Geel. De
oorspronkelijke naam van het IRMM was het Central Bureau for
Nuclear Measurements (CBNM). In de loop der tijd begon het
CBNM zowel nucleair als niet-nucleair onderzoek te doen. In
1993 werd de naam veranderd van CBNM naar IRMM om dit te
weerspiegelen.
De hoofdcompetenties van het IRMM zijn uitgegroeid tot:






Referentiematerialen produceren
Voedselanalyse
Bioanalyse
Chemische referentiemetingen
Radionuclidemetrologie
Neutronenfysica
Het IRMM bestaat uit 7 units:







Food Safety and Quality (FSQ)
Infrastructure and Site Management (ISM)
Isotope Measurements (IM)
Management Support (MSU)
Nuclear Physics (NP)
Reference Materials (RM)
Safety, Health, Environment & Security (SHES)
9
1.3
Informatics Unit
De unit waar ik werk, heet de Informatics Unit. Deze unit maakt deel uit van de
Resource Management Directorate. De Informatics unit is verspreid over Geel, Ispra en
Petten. Het hoofd van Informatics is de heer Bartel Meersman. De Informatics Unit op
het IRMM zorgt voor development en hosting van applicaties gebruikt door het IRMM.
Binnen deze unit werk ik in het IS Development team, dat geleid wordt door mevrouw
San Pauwels. Zij is ook mijn stagebegeleider.
Elke week vergaderen alle developers met elkaar. In deze vergadering vertellen we
elkaar wat we hebben gedaan, waar we nu mee bezig zijn en waar we op het moment
problemen of moeite mee hebben. Zo blijft iedereen op de hoogte van alle projecten
zodat we elkaar kunnen helpen als iemand ergens mee vast zit.
10
2
STAGEOPDRACHT
In dit hoofdstuk beschrijf ik de nood en verdere details van mijn project
2.1
Aanleiding en achtergrond van het project
De Food Safety and Quality (FSQ) unit van het IRMM heeft onder andere de taak om
aanvragen van feed additives goed te keuren. Wanneer een aanvraag binnenkomt,
wordt een dossier geopend. Een dossier kan meerdere producten bevatten om te
onderzoeken en elk product kan meerdere actieve bestandsdelen bevatten. Na
aanvraag, wordt onderzocht of de producten veilig zijn. Eens dit onderzoek voltooid is
wordt een rapport goedgekeurd en dan gepubliceerd.
Het publiceren van de rapporten gebeurt momenteel manueel. De rapporten worden na
goedkeuring deels toegevoegd aan Ares. Ares is een document management systeem
dat bij het IRMM gebruikt wordt om alle officiële definitieve documenten te registreren,
publiceren en bewaren. Op het einde van elke maand publiceert een FSQ medewerker
al de rapporten van de afgelopen maand. Hiervoor moet de user in een Excel document
pseudo-HTML code schrijven van de table rows van de rapporten die toegevoegd
moeten worden aan de pagina. Die lijst wordt dan doorgegeven aan iemand met
toegang tot de SharePoint server van de IRMM website, en die voegt dan de <tr>'s aan
de <table> toe. Dit is een heel karwei en de FSQ zou dit graag geautomatiseerd zien.
Er bestaat al een webapplicatie voor de administratie van de dossiers. Deze zou
uitgebreid kunnen worden om een automatisch gegenereerde pagina van rapporten
mogelijk te maken.
2.2
Verwacht resultaat
Het European Union Reference Laboratories (EURL) Feed Additives Authorisation (FAA)
Reports project heeft als einddoel het publiceren en omgaan met rapporten binnen de
FSQ unit te verbeteren en te automatiseren.
FSQ users zullen in staat zijn om via de bestaande webapplicatie meerdere actieve
substanties op te geven per product, en geuploade rapporten te koppelen aan dossiers.
Normaal wordt de tekst weergegeven op de pagina automatisch gegenereerd met de
namen van de producten en actieve substanties. De user kan ook zelf een alternatieve
tekst opgeven voor de product en actieve substanties, per rapport.
Op basis van de data van de webapplicatie zal een pagina met een lijst van rapporten
gegenereerd worden.
2.3
Business Case
De voordelen van dit project voor de business zijn:

De automatisering bespaart de FSQ unit werk, zo hebben ze meer tijd voor hun
hoofdtaken.

Doordat de webapplicatie alle input valideert, is het moeilijker om fouten te
hebben in de lijst van rapporten.
11

2.4
Rapporten publiceren wordt momenteel uitgesteld tot het einde van de maand
omdat dit zo veel werk is. Eens dit geautomatiseerd is zullen de rapporten
onmiddellijk na goedkeuring gepubliceerd worden omdat het makkelijker zal zijn
om dit meteen te doen dan het uit te stellen tot later.
Fasering
In de analysefase wordt er een vision document opgesteld en de use case specifications
gemaakt. Eens deze goedgekeurd zijn door de opdrachtgever (FSQ unit), wordt er
begonnen aan de ontwikkeling.
In de ontwikkelingsfase wordt eerst een development environment in orde gemaakt,
daarna worden functies toegevoegd om rapporten te associëren met dossiers,
meerdere actieve substanties per product op te geven, en uiteindelijk een pagina te
maken die met de gegevens een lijst van gepubliceerde rapporten genereert. Nadat
deze functies zijn geïmplementeerd, wordt het project getest en wordt een demo
gegeven aan de opdrachtgever.
Als laatste fase wordt het project gedeployed op de productieserver. Hierbij worden
bestaande rapporten geassocieerd met dossiers en actieve substanties toegevoegd
waar nodig.
2.5
Projectafbakening
Het project moet uitgewerkt worden volgens de RUP methodologie. Het uiteindelijke
resultaat is een pagina om makkelijk rapporten te koppelen aan een dossier en een
pagina op de website van het IRMM die een lijst van gepubliceerde rapporten toont op
basis van de data uit de database.
2.6
Omschrijving van de primaire doelgroep
De FSQ unit hebben het meeste baat bij dit project. Het bespaart hun werk bij het
publiceren van rapporten. Verder kunnen ze minder fouten maken bij het publiceren.
2.7
Andere stakeholders
Het general public, de IRMM website bezoeker, krijgt meer up to date informatie te
zien. Waar nu de rapporten pas op het einde van de maand geüpload worden, zal met
deze applicatie het rapport beschikbaar zijn kort nadat het rapport goedgekeurd is.
2.8
Informatie en rapportering
Ik zal de voortgang van het project aan mijn stagebegeleider meedelen in elke
Developers Meeting. Ik zal elke week een stageverslag sturen naar mijn begeleidende
docent.
12
3
ANALYSE
Om een goed beeld te krijgen van de opdracht, ben ik begonnen met een analyse van
het project.
Door regelmatig samen te zitten met de opdrachtgever, ben ik tot een vision document,
use case specifications en een datamodel gekomen. Deze documenten vormen een
leiddraad voor de latere ontwikkeling en geven de opdrachtgever een idee van wat
gemaakt zal worden.
Ook tijdens de ontwikkelingsfase worden de analysedocumenten terug aangepast
omdat deze ook dienen als documentatie voor later.
3.1
Vision document
Om de noden van de gebruiker te achterhalen, te begrijpen waar deze vandaan komen,
en het algemeen doel van het project te beschrijven, wordt een vision document
opgesteld. Het vision document beschrijft de noden op een hoog niveau, de use case
specifications (zie verder) gaan in op de details van deze noden.
Eens het document af is, wordt het aan de opdrachtgever getoond ter goedkeuring.
Daarna worden de use cases verder uitgediept.
Een vision document bestaat uit volgende delen:

Introduction

Positioning

Proposed approach

Stakeholder and user descriptions

Information system overview

Features

Planned resources

Constraints
In de volgende onderdelen ga ik dieper in op de delen van het vision document.
3.1.1
Introduction
In de introductie wordt de scope bepaald en vindt men een lijst van termen en nuttige
links. De scope geeft aan wat bij dit project kan horen en wat niet. Zo was de scope
van dit project het publiceren van rapporten van feed additives.
3.1.2
Positioning
Het 'Positioning' onderdeel beschrijft wat het probleem is, wie hier last van heeft en wat
de gevolgen hiervan zijn. Hierbij wordt duidelijk gemaakt wat het doel is van het
project, namelijk het publiceren van rapporten makkelijker maken. Er wordt ook
13
DOCUMENT
MANAGEMENT
DOCUMENT
MANAGEMENT
1
Approve report
1.1
Mark approved
Mark report approved in EURL FA
administration webapp
DOCUMENT
MANAGEMENT
1.2
Print and paraph
report
Report is printed and paraphed
DOCUMENT
MANAGEMENT
DOCUMENT
MANAGEMENT
2
Publish report
2.1
Scan printed
report
Scan approved report.
DOCUMENT
MANAGEMENT
2.2
Upload report
Upload the scanned report
DOCUMENT
MANAGEMENT
2.3
Set report url
Copy the url to the report into the
dossier's report field in the EURL FA
administration webapp and save the
updated dossier.
Description (FR)
Description (EN)
Name
ID
Domain
beschreven wat een mogelijke oplossing is voor dit probleem. Als laatste wordt het
business proces beschreven zoals het zal zijn eens de oplossing geïmplementeerd is.
Hiervoor wordt volgende tabel gebruikt:
Table 3-1 Business process
Nadat het rapport opgesteld is, moet het eerst goedgekeurd worden. Na goedkeuring
wordt het gepubliceerd door het geparafeerde rapport in te scannen, te uploaden naar
een publieke locatie en in de administratie webapplicatie de link naar dit rapport in te
stellen.
3.1.3
Proposed approach
In de 'Proposed approach' wordt dieper ingegaan op hoe de oplossing geïmplementeerd
zal worden. Dit beschrijft de verschillende stappen die ondernomen moeten worden.
14
3.1.4
Stakeholder and user descriptions
Hierna worden de stakeholders en users van het project beschreven. De stakeholders
zijn de personen die baat hebben bij dit project, de users zijn de eindgebruikers. Merk
op dat users zeker ook stakeholders zijn.
Van elke stakeholder wordt beschreven wat hun verantwoordelijkheden zijn en wanneer
ze het project als succesvol beschouwen.
Verder wordt beschreven hoe lang de users momenteel nodig hebben om rapporten te
publiceren, met welk informatica systeem ze momenteel werken en hoe de nieuwe
functionaliteit in hun huidige werkomgeving zal geïntegreerd worden.
Dan volgt een opsomming van hoe aan elke nood van elke stakeholder voldaan zal
worden in de nieuwe applicatie. Als allerlaatste volgt nog een lijst van alternatieve
oplossingen waaruit de stakeholders kunnen kiezen mochten ze de voorgestelde
oplossing minder goed vinden.
3.1.5
Information system overview
In het volgende onderdeel wordt het informatiesysteem verder beschreven. Dit houdt in
dat de veronderstellingen die gemaakt zijn bij de ontwikkeling uitgeschreven worden.
Verder wordt ook een raming gemaakt van het aantal dagen werk voor elke taak:
Description
Analysis
Development
Integration &
Deployment
Total
Add report fields (link, date,
alternative product text,
alternative additives text)
10
4
5
19
Allow multiple active
substances per product in
EURL FA webapp
10
3
2
15
Show generated list of
reports on IRMM website
6
4
5
15
49
Table 3-2 Planning
Als laatste worden non-functional requirements, de license en te volgen standaarden
van het systeem vermeld.
3.1.6
Features
In het 'Features' onderdeel beschrijft men de deadline en de prioriteit van elke functie.
3.1.7
Planned resources
In dit onderdeel wordt kort beschreven hoeveel mensen hieraan zullen werken en wat
er mogelijk nog extra nodig is aan apparatuur en software dat normaal niet aanwezig
is.
15
3.1.8
Constraints
In de 'Constraints' staan beperkingen over wie toegang heeft tot de applicatie en wie
niet, welke data mag getoond worden en welke niet. De lijst van rapporten mag aan
iedereen getoond worden. De interface om rapport urls in te stellen mag enkel
toegankelijk zijn voor FSQ users.
3.2
Use case specifications
Na het vision document wordt eerst een use case diagram opgesteld om een overzicht
te geven:
Figure 3-1 Use case diagram
Hierna wordt elke use case in detail beschreven met een use case specification
document. Hierin komt te staan hoe het systeem gebruikt moet worden en hoe het
systeem reageert op de acties van de actor.
Eens de use case specifications geschreven zijn, worden ze aan de opdrachtgever
getoond ter goedkeuring.
Een use case specification document bestaat uit volgende delen:

Use case description
16

Flow of events

Preconditions

Postconditions

Screenshots

Datamodel
3.2.1
Use case description
In het eerste deel staat over welke use case het gaat, welk de actoren zijn en wat alle
gebruikte termen betekenen.
3.2.2
Flow of events
In de 'Flow of events' staan lijsten van acties en responses welke de wisselwerking
tussen actor en het systeem duidelijk maakt. Elke lijst duidt een flow aan. Men maakt
onderscheid tussen een basic flow en enkele alternative flows. De basic flow beschrijft
het meest voor de hand liggende successcenario, de alternative flows beschrijven de
andere scenario’s.
De 'Manage active substances' use case bijvoorbeeld, heeft deze flows:

Publisher adds an active substance to product

Publisher removes an active substance from product

Publisher removes last active substance from product

Publisher edits active substance

Publisher nearly edits active substance (user klikt cancel tijdens edit)
De ' Publisher adds an active substance to product' flow heeft volgende lijst van acties
en responses:
a) Publisher surfs to system homepage
b) System shows log in form
c) Publisher logs in
d) System shows system home page
e) Publisher clicks "Dossier Administration"
f) System shows search form
g) Publisher enters search data
h) System shows list of dossier results
i)
Publisher clicks update of desired dossier
j)
System shows dossier edit form
k) Publisher clicks update of desired product
l)
System shows product edit form
17
m) Publisher clicks Additives > Add
n) System shows Additive add form with text field for name, Update and Cancel button
o) Publisher fills in name
p) Publisher clicks "Update"
q) System saves changes and returns to the "Update dossier" page
r) Publisher clicks "Update" or "Reject"
s) System returns to the search page, additive was already added
De structuur van elke regel is telkens 'Actor/System doet iets'.
3.2.3
Preconditions
In de preconditions staan de condities waaraan voldaan moet zijn opdat bovenstaande
flows zich kunnen gedragen zoals hierboven beschreven staat. Een voorbeeld is dat het
single sign-on ECAS systeem moet werken, anders kan men niet inloggen en daar is in
bovenstaande flows geen rekening mee gehouden.
3.2.4
Postconditions
In de postconditions staat hoe het systeem eruit zou moeten zien na uitvoering van een
van de mogelijke flows. Als we er in de precondities van uitgingen dat de user al
ingelogd is, dan is het logisch dat we na uitvoering nog steeds ingelogd zijn; dit is dan
een postconditie.
3.2.5
Screenshots
Omdat de flows in praktijk te technisch blijken om aan users te tonen, worden er mockups toegevoegd aan de use case specificatie die de user een onmiddellijk beeld geven
van hoe het ongeveer zal werken.
3.2.6
Datamodel
In dit deel wordt uitgelegd welke wijzigingen gemaakt moeten worden aan het datamodel om aan deze use case te kunnen voldoen.
3.3
Datamodel
Het datamodel toont de gewenste structuur van de database.
Volgend model toont het nieuwe model van de database. In het geval van dit project,
bestond er al een database, de aangepaste tabellen hebben een gele achtergrond.
18
Figure 3-2 Datamodel
Een dossier (FAA_DOSSIER) heeft een FAD nummer (DSR_FAD_NUMBER) en een CRL
nummer (DSR_NUMBER_CRL_DECL). Het FAD nummer wordt toegekend door een
externe organisatie, het CRL nummer is een intern nummer van de FSQ unit.
Om urls van rapporten naar Ares of SharePoint bij te houden, heb ik het
DSR_REPORT_LINK veld toegevoegd aan FAA_DOSSIER.
19
DSR_REPORT_DATE houdt bij wanneer het rapport gepubliceerd is.
DSR_REPORT_PRODUCT en DSR_REPORT_ADDITIVES bevatten een alternatieve tekst
om te tonen als product en additives op de lijst pagina. Als deze NULL zijn wordt er een
standaard tekst gegenereerd op basis van de product trade name en de additive
names.
Een dossier heeft meerdere products (FAA_PRODUCT), een product heeft exact 1
dossier. Een product heeft mogelijk een trade name (FAA_TRADE_NAMES).
Oorspronkelijk had een product een additive, en een additive kon meerdere products
hebben, maar een additive werd altijd maar aan 1 product gekoppeld. Om meerdere
additives per product toe te staan heb ik het ADD_ID veld van FAA_PRODUCT
verwijderd en de FAA_PRD_ADDITIVES tabel toegevoegd. De oude waarden in het
ADD_ID veld worden gemigreerd naar de FAA_PRD_ADDITIVES tabel. Dit staat een
meer op meer koppeling toe in de toekomst, momenteel wordt het nog gebruikt als een
1 op meer koppeling waarbij 1 product meerdere additives kan hebben.
20
4
ONTWIKKELOMGEVING
Tijdens mijn stage heb ik in verschillende projecten gewerkt, met verschillende
technologieën en structuren. In dit onderdeel bespreek ik de belangrijkste onderdelen
van de ontwikkelomgevingen die ik heb aangetroffen.
4.1
Oracle SQL Developer
Oracle SQL Developer is een grafische tool gemaakt in Java om databases mee te
beheren. Je kan er queries en scripts in runnen, of gebruik maken van de grafische
menu's en knoppen. Oracle SQL Developer ondersteunt niet alleen connecties naar
Oracle databases, maar ook ODBC connecties, …
Figure 4-1 Oracle SQL Developer
4.2
Java en Java EE
De applicaties zijn geschreven in Java Enterprise Edition.
Java is een imperatieve programmeertaal ontwikkeld door James Gosling van Sun
Microsystems. Java laat makkelijk object georiënteerd programmeren toe. De syntax is
gebaseerd op die van C en C++ zodat men makkelijker kan overstappen van C en C++
door geen volledig nieuwe syntax te hoeven leren. Java code wordt gecompileerd tot
bytecode welke uitgevoerd kan worden door implementaties van de Java Virtual
21
Machine (JVM). Er zijn implementaties te vinden van de JVM voor Windows, Linux, Mac,
… Java is dus cross-platform.
Er zijn verschillende Java platforms te verkrijgen:




Java Card: Java applicaties voor smart cards.
Java Micro Edition: Een meer light weight versie van het Java platform, bedoelt
voor devices met beperkt geheugen.
Java Standard Edition: Java applicaties voor general-purpose gebruik op
desktops en servers.
Java Enterprise Edition: Java SE plus verschillende API's voor client-server
applicaties.
Het IRMM gebruikt Java EE om web applicaties te maken.
4.3
Spring
Spring is een software platform dat bovenop Java EE kan gebruikt worden. Het biedt
support classes voor Model View Controller (MVC), dependency injection via Spring
bindings via xml bean configurations en Java annotations, …
Dependency injection kan gebruikt worden om via xml configuraties en/of Java
annotations instances in als waarden van attributen van een andere instance te
'injecten' via getters en setters. Voor meer uitleg hierover, zie verder onder RefApp.
4.4
Eclipse
Eclipse is een integrated development environment (IDE), voornamelijk geschreven in
Java. Eclipse is crossplatform, vrije software. Met Eclipse kan men software schrijven in
Java, Ada, C, C++, COBOL, Perl, PHP, Python, Ruby, … Eclipse bevat tools om te helpen
refactoren en vele andere functies die helpen bij het coderen. Op het IRMM wordt Java
code geschreven in Eclipse.
22
Figure 4-2 Eclipse
4.5
Subversion
Apache Subversion (svn) is een code versioning systeem. Met Subversion kunnen
verschillende versies bijgehouden worden van de code van een project die later terug
opgevraagd kunnen worden. Subversion staat ook toe om met meerdere mensen aan
eenzelfde project te werken zonder te riskeren elkaars wijzigingen te verliezen, doordat
Subversion deze conflicten detecteert en de ontwikkelaar vraagt om deze op te lossen.
Subversion wordt in veel open-source projecten gebruikt. Subversion is bedoeld als
opvolger van Concurrent Versions System (CVS).
Alle projecten waar ik mee gewerkt heb, stonden op een centrale Subversion
repository. Na elke nieuwe toevoeging heb ik mijn wijzigingen naar de trunk gecommit.
Aan het begin van het project heb ik een tag genomen van de huidige versie als die nog
niet bestond. Zo kan men makkelijk oudere releases terugvinden.
23
Figure 4-3 Subversion
4.6
JIRA
JIRA is een issue tracker gemaakt door Atlassian. Deze project management tool
ondersteunt bug tracking, feature en enhancements request tracking.
Op de stageplaats vormde een lijst van issues van de afgelopen week de basis voor de
agenda van de wekelijkse developer meeting. Al het werk dat wordt gedaan, wordt
ingegeven in JIRA en de Subversion commits worden via een keyword in de commit
comments gekoppeld aan de juiste issues.
24
Figure 4-4 JIRA
4.7
RefApp
Binnen het IRMM wordt de RefApp structuur gebruikt als basis voor web applicaties. Er
zijn verschillende versies van de RefApp structuur. Ik heb gewerkt in projecten in een
oude versie van de RefApp (versie 1.2) en heb een nieuw project aangemaakt in de
huidige versie (versie 3.2). In de komende delen bespreek ik beide versies die ik
gebruikt heb.
De RefApp structuur wordt gegenereerd door een script, men kan instellen van welke
functies men code gegenereerd wil hebben. Men kan kiezen voor support voor Spring,
Selenium tests, een persistence API of JDBC, …
Men is vrijwel verplicht om de RefApp structuur te gebruiken in projecten omdat deze
voorziet in de ergonomics library welke ervoor zorgt dat alles dezelfde look and feel
heeft. RefApp heeft ook ondersteuning voor Ecas authenticatie. Men kan hier echter
van afwijken als men wil, maar dan moet de alternatieve structuur zeer goed
gedocumenteerd zijn. Het grootste voordeel van RefApp is dat het alle features heeft
die meestal nodig zijn in web applicaties binnen het JRC. Een ander voordeel van een
project met de RefApp structuur te schrijven, is dat de andere developers deze
structuur al kennen. Een nadeel van de RefApp structuur is dat deze vrij complex is.
4.7.1
RefApp 1.2
RefApp 1.2 maakt gebruik van Hibernate voor persistence, Tomcat als application
server en Ant als build tool. Er wordt een MVC architectuur gebruikt met behulp van
Spring. De meeste configuratie gebeurt met XML files.
25
4.7.1.1
Hibernate
Hibernate is een open-source persistence API voor Java. Hiermee kunnen Java POJO's
persistable gemaakt worden door ze te koppelen aan een relationele database via
Object/Relational mappings en ze zo op te slaan in de database.
In RefApp 1.2 worden OR mappings uit Hibernate xml files gehaald, een voorbeeld van
zo'n file is:
Code 4-1 Hibernate OR mapping
Hierin wordt de GeneralMethod bean gekoppeld aan de CRL_GENERAL_METHOD tabel.
4.7.1.2
Spring configuraties
Dit deel beschrijft de belangrijkste spring en web-app configuraties en hoe deze aan
elkaar gerelateerd zijn.
26
In de hoofdconfiguratie van de web-app wordt opgesomd waar Spring zijn bean
configuration files kan vinden. De hoofdconfiguratie bevindt zich in web/WEBINF/web.xml. De XML voor de Spring configuratie ziet er als volgt uit:
Code 4-2 Controller xml configuratie
De dataAccessContext.xml file beschrijft waar de Hibernate files gevonden moeten
worden. De servicesContext.xml file beschrijft waar service classes gevonden kunnen
worden.
De xml files in WEB-INF/controllers definiëren beans van Controller classes uit het MVC
patroon. Een voorbeeld van hoe een controller bean gemaakt wordt:
27
Code 4-3 Controller Spring bean configuratie
De properties duiden aan wat waarin geinject moet worden bij het maken van deze
bean. De values van de view variabelen zijn de namen van Views welke in src/views
bijgehouden worden in properties files. Een view definitie ziet er als volgt uit:
Code 4-4 View configuratie
De parent templateView geeft aan dat de jsp pagina uit contentUrl in het body van de
template pagina weergegeven moet worden.
Om te weten welke view uiteindelijk getoond moet worden, wordt gekeken naar de
return van de handleRequest method van de Controller. Deze geeft een ModelAndView
instance terug waarin de naam van het view als string gegeven wordt samen met een
model met daarin data om te tonen op het view (dus op de jsp pagina), bijvoorbeeld:
Code 4-5 Controller handleRequest
RefApp 1.2 biedt 3 soorten controllers die als base class gebruikt kunnen worden om
controllers te maken:


ViewController: een controller met een view attribuut dat een waarde gegeven
kan worden vanuit de bean configuratie.
FormController: een controller van een pagina met een form voor CRUD
operaties op
28

ListController: een controller van een lijst van items
Wanneer naar een url gesurft wordt, bijvoorbeeld '/feedacamAdmin.do', wordt in WEBINF/feedacam-servlet.xml deze url vertaald naar de controller bean die deze request zal
afhandelen met handleRequest. Deze mapping ziet er als volgt uit:
Code 4-6 URL mapping configuratie
4.7.1.3
Ant
Apache Ant is een build tool geschreven in Java om vaak gebruikte operaties op een
project te automatiseren. Zo kan men er build, deploy, clean, test tasks mee schrijven.
Ant hoeft niet enkel voor Java projecten gebruikt te worden; elk proces dat kan
uitgeschreven worden als targets en tasks om tot het target te komen, kan met Ant
geautomatiseerd worden. Deze targets en tasks worden beschreven in de build.xml van
het project.
Zo is er in RefApp 1.2 projecten een script om het project te cleanen waarbij onder
andere alle build files verwijderd worden, en er is een script om een war file te generen
die later kan gedeployed worden op Tomcat. Een war file bevat alle bytecode en
resources die nodig zijn om de web applicatie te runnen op een Java application server,
zoals Tomcat.
4.7.1.4
Tomcat
Apache Tomcat is een open-source implementatie van de Java Servlet en JavaServer
Pages technologieën. Op de Tomcat server wordt de web applicatie uitgevoerd.
29
4.7.1.5
Hoe uitvoeren
Om een RefApp 1.2 applicatie uit te voeren moet men eerst Ant clean uitvoeren en
daarna Ant distWar. Dit compileert de source en packaget ze tot een war file. Daarna
moet Tomcat gestart worden, en moet de war file gedeployed worden op de Tomcat
server via de Tomcat manager webinterface. Van zodra de war gedeployed is, kan men
naar de juiste locatie op de Tomcat server surfen en de web applicatie gebruiken.
4.7.2
RefApp 3.2
RefApp 3.2 is de nieuwste versie van RefApp. Deze gebruikt JPA voor persistence met
Hibernate als backend, WebLogic als application server en Maven als build tool. Er
wordt een MVC structuur gebruikt met Spring op de achtergrond. De meeste
configuratie wordt gedaan met annotations in plaats van xml configuraties.
4.7.2.1
JPA
De Java Persistence API is een abstraction layer bovenop de verschillende persistence
libraries. Door deze abstractie kan code onafhankelijk van de gebruikte persistence API
implementatie geschreven worden waardoor men later makkelijk van implementatie
kan wisselen.
JPA gebruikt annotations voor OR mappings in plaats van een xml configuratie.
4.7.2.2
Maven
Apache Maven is een tool om project management en build te ondersteunen en te
automatiseren. Het heeft een gelijkaardig doel aan dat van Ant, met het verschil dat
Maven gebruik maakt van een project object model (POM) in plaats van een build.xml
file. De POM bevat al de configuratie van het project waaronder dependencies als jar
files.
4.7.2.3
WebLogic
Oracle WebLogic is een cross-platform Java application server zoals Tomcat, waarop de
RefApp web applicatie uitgevoerd kan worden.
4.7.2.4
Hoe uitvoeren
Om het project te cleanen, compileren en lokaal te deployen, kan men dankzij Maven
een Maven script uitvoeren dat al deze taken uitvoert.
30
5
IMPLEMENTATIE VAN DE APPLICATIE
Na de analyse is het tijd om het plan in werking te zetten en ben ik begonnen met de
implementatie van de applicatie(s). In dit deel beschrijf ik hoe ik de requirements
geïmplementeerd heb, welke stappen ik hiervoor gevolgd heb en wat het uiteindelijke
resultaat is.
In de loop van het project heb ik JIRA issues gemaakt naarmate ik meer te weten
kwam over de tasks en subtasks die nodig waren om het project tot een goed eind te
brengen. Dit heeft mij geholpen om bij te houden welke taken afhankelijk zijn van
elkaar, en de rest van het team kan zo ook goed zien waar ik op dat moment mee
bezig ben.
Mijn project maakt deel uit van het overkoepelende EURL project. Dat project heeft als
doel de ondersteuning van de business van de European Union Reference Laboratories
te verbeteren. De Feed Additive Authorisation maakt daar deel van uit.
Om op de hoogte te blijven van het overkoepelende EURL project, heb ik gedurende
enkele weken wekelijks deelgenomen aan vergaderingen hierover, bovenop de gewone
wekelijkse developer meetings. In die vergaderingen konden de FSQ users feedback
geven over de EURL applicaties.
Omdat alle EURL projecten gebruik maken van dezelfde database, heb ik goed rekening
gehouden met die projecten om zeker te zijn dat de andere applicaties blijven werken
met mijn wijzigingen. Daarom geef ik eerst een korte opsomming van deze projecten
met een korte beschrijving:

crlfaacatadmin: Interne interface van EURL FAA, kan enkel gebruikt worden door
FSQ werknemers.

crlForms: Publieke interface waarlangs men nieuwe authorisation requests kan
maken voor feed additives.

crlApplication: Wordt gebruikt om externe dossiers met interne CRL dossiers te
vergelijken.

eurlreportlist: De lijst met rapporten, getoond op de IRMM website. Dit is een
nieuw project dat ik heb aangemaakt. Dit project gebruikt RefApp 3.2, de
andere projecten gebruiken RefApp 1.2.
Om tot een goed eindresultaat te komen, heb ik er eerst voor gezorgd dat men
meerdere additives aan 1 product kan koppelen in crlfaacatadmin. Dit was
oorspronkelijk een 1 op 1 koppeling. Dit vereiste aanpassingen in de database
waardoor ik ook code in crlForms en crlApplication moest aanpassen.
Hierna heb ik het mogelijk gemaakt om een rapport te koppelen aan een dossier in
crlfaacatadmin met een URL.
Eens men meerdere additives aan een product kon koppelen en rapporten kon
instellen, kon ik beginnen aan een lijst van rapporten en heb ik het eurlreportlist
project gemaakt.
Als laatste stap heb ik de deployment documentatie geschreven van eurlreportlist en
heb ik een demo gegeven aan de user van mijn werk zodat ik feedback kon krijgen en
nog aanpassingen kon aanbrengen met behulp van de feedback.
In de volgende onderdelen bespreek ik de stappen die ik ondernomen heb tijdens de
ontwikkeling en de resultaten daarvan.
31
5.1
Migratiescript
Ik heb een migratiescript geschreven om de huidige database structuur en data te
wijzigen naar de nieuwe vereiste structuur.
Code 5-1 Migratiescript
Eerst maak ik de FAA_PRD_ADDITIVES tabel met de nodige foreign keys voor de 1 op
meer koppeling. Oracle DB ondersteunt geen auto numbering op primary keys, in de
plaats daarvan moeten we een sequence aanmaken die we vervolgens in onze inserts
kunnen gebruiken voor nieuwe ids door SEQ_FAA_PRD_ADDITIVES.nextval te
gebruiken, zoals ook te zien is in de daaropvolgende INSERT.
Vervolgens zet ik oude koppelingen over door alle niet NULL ADD_ID's uit
FAA_PRODUCT toe te voegen aan FAA_PRD_ADDITIVES.
Nu dat alles van ADD_ID overgezet is naar FAA_PRD_ADDITIVES, kan deze kolom
verwijderd worden.
Als laatste voeg ik nieuwe velden toe aan de dossier tabel om de url naar het rapport,
… in bij te houden.
5.2
crlfaacatadmin
In het crlfaacatadmin project heb ik functies toegevoegd om meerdere additives te
koppelen aan een product en de URL van een report in te stellen op een dossier. In de
komende delen ga ik dieper in op wat ik in de bestaande crlfaacatadmin interface
aangepast heb.
32
5.2.1
Meerdere additives
De gebruiker kon al een enkel additive opgeven voor een product. Dit kon bij het
aanmaken van een nieuw product en bij het wijzigen van een bestaand product.
Ik heb de 'Update Product' en 'Insert Product' pagina gewijzigd zodat de gebruiker
additieven aan het product toevoegen, verwijderen en wijzigen met de voorziene
icoontjes op de 'Additives' tabel.
Figure 5-1 Additive management
Als de gebruiker klikt op het vuilbak icoontje, wordt eerst gevraagd of de gebruiker
zeker is. Hierbij wordt getoond wat er zal gebeuren. Pas na confirmatie wordt het
additief verwijderd.
Figure 5-2 Additive delete
Als de gebruiker klikt op het 'update' icoon of het 'insert' icoon (links boven in de
tabel), krijgt hij/zij volgend formulier te zien.
Figure 5-3 Additive update
Deze functionaliteiten zien er hetzelfde uit op zowel de 'Insert product' als de 'Update
product' pagina
33
5.2.2
Published report
Na men meerdere additives kon toevoegen, ben ik begonnen aan een url van een
rapport te kunnen koppelen aan een dossier. Dit gebeurt enkel op de 'Update dossier'
pagina; nieuwe dossiers hebben nooit een rapport.
De gebruiker kan op de 'Update Dossier' pagina in het 'Published report' gedeelte, de
URL naar het rapport ingeven met het 'Report link' veld (links onderaan op de
afbeelding). Als de gebruiker later een lege waarde in het veld ingeeft, wordt het
rapport ontkoppeld en heeft het dossier geen rapport meer. De gebruiker moet ook de
'Date of publishing' invullen, welke de datum is waarop het rapport gepubliceerd werd.
Optioneel, kan de gebruiker een alternatieve tekst opgeven voor de 'Product' en
'Additives' kolom op de report list pagina.
Figure 5-4 Published report fields
5.3
eurlreportlist
Met het eurlreportlist project wordt de lijst van rapporten getoond op de IRMM website.
Een product heeft niet altijd een naam, in dat geval wordt er een leeg veld getoond. De
'Active substances' die te zien zijn, zijn de additives van het product. De tabel is
gesorteerd op 'Date of report' en de FAD links linken naar de url die eerder als 'Report
link' was ingegeven in de crlfaacatadmin applicatie.
34
Figure 5-5 Report list
In de volgende onderdelen leg ik uit hoe ik dit project gemaakt heb en hoe de code
werkt.
5.3.1
RefApp 3.2 structuur genereren
Omdat eurlreportlist een nieuw project was, heb ik eerst een RefApp structuur moeten
genereren. Om de structuur te genereren heb ik eerst de laatste versie van refapp
lokaal uitgepakt. Daarna moeten de preferences ingesteld worden met een properties
file:
Code 5-2 RefApp configuratie
Hierin heb ik geconfigureerd om JDBC te gebruiken in plaats van Hibernate of JPA,
Maven in plaats van Ant, …
35
Nu dat de preferences ingesteld zijn, kan ik met een Ant script mijn nieuw project laten
aanmaken. Het gegenereerde project bevat code voor de MVC structuur, bevat Spring
bean configuraties, een template voor jsp pagina's, …
De volgende stap is om een Data Access Object (DAO) te schrijven met queries om de
data op te halen. Daarna heb ik een Service klasse geschreven welke DAO's gebruikt
om zaken in de business layer te wijzigen. De Service classes bevatten de business
logic. De Controller bevat de UI logica. Met UI logica bedoel ik datgene wat moet
gebeuren als de user op een bepaalde knop klikt (het domain wijzigen door een
bepaalde service methode aan te roepen), en welke view daarna getoond moet worden
(de jsp pagina), en met welke data (het model). De bedoeling hiervan is om data
access, business logic en presentation logic te scheiden in 3 lagen. De volgende delen
gaan in op de details hiervan.
5.3.2
Report en Product data classes
Voor we beginnen aan de DAO, moeten er eerst data classes geschreven worden om de
data in op te slaan. Dit zijn simpele beans met getters, setters en wat velden en geen
behaviour. De DAO vult instances hiervan op met data uit de database, service classes
voegen hier mogelijk nog wat aan toe en in de front-end worden ze gebruikt om de
data weer te geven aan de gebruiker.
36
37
Code 5-3 Report domain class
Code 5-4 Product domain class
5.3.3
ReportDao interface
Om de implementatie volledig te scheiden van de interface van de DAO klasse, maken
we een interface. Als we dit niet deden zouden nieuwe implementaties van deze DAO
verplicht zijn om over te erven van ReportDaoImpl (zie verder) of ReportDaoImpl zelf
aan te passen. In het geval van DAO klassen is het meestal voldoende om
ReportDaoImpl zelf aan te passen.
De ReportDao heeft 1 methode om de rapporten mee op te halen en geeft de rapporten
terug als Report objecten.
38
Code 5-5 ReportDAO
5.3.4
ReportDaoImpl
Na de interface gemaakt te hebben, maak ik een implementatie ervan. De DAO
methodes zijn de enige die sql, Hibernate sql, … mogen bevatten, aangezien dat data
access is.
Op lijn 23 wordt een annotation gebruikt om een Spring bean te maken van
ReportDaoImpl. Deze wordt later in services gebruikt om aan de methodes van de DAO
te kunnen. De naam van de bean is 'reportDao'. Deze annotation markeert de class ook
als een Repository. Deze markeringen worden gebruikt in de achterliggende Spring xml
configuraties van RefApp.
Omdat ik rechtsreeks met JDBC en JNDI werk, moet ik een DataSource object hebben
om een connectie te openen met de database. RefApp heeft al een Spring bean van een
DataSource met de juiste JNDI gemaakt. De naam van die bean is 'dataSource'. Op
regel 28 geef ik aan dat Spring de 'dataSource' bean moet injecten in mijn
ReportDaoImpl instance door setDataSource erop aan te roepen met het juiste
argument. Spring leidt 'dataSource' als naam af door te kijken naar de naam van de
setter (of getter).
Met getPublishedReports worden alle geldige rapporten opgehaald, welke we later
zullen tonen in een lijst.
Op regel 39 maken we met de connection verkregen met de DataSource een
PreparedStatement. De query haalt volgende gegevens op:

het id van het dossier

de FAD nummer van het dossier

de URL naar het report

een optionele alternatieve tekst voor het product veld

een optionele alternatieve tekst voor het additives veld

de datum van het rapport

het ID van het product van het dossier,

de trade name van het product

de additive name van het product
Er wordt gesorteerd op (in die volgorde):

datum
39

dossier id

product id

additive name
Enkel dossiers met volgende criteria worden opgehaald:

geldige report link

geldig FAD nummer

geldig date of publishing

dossier heeft 'completed' state heeft
Op regel 53 wordt de query uitgevoerd, het resultaat hiervan is een ResultSet.
Op regels 54-83 wordt de ResultSet omgezet tot een List<Report>. Dankzij de
sortering op dossier id en dan product id kunnen we door de ResultSet loopen en een
nieuw Report beginnen bij een nieuw dossier id, een nieuw Product beginnen bij een
nieuw product id, en verder gewoon products aan het huidige report toevoegen en
additives aan het huidige product.
De hele query staat in een try Block omdat er fouten kunnen zijn bij het uitlezen van de
data uit de database. Dit wordt opgevangen door een trace van de exception te geven
en te returnen.
Door het finally block zal de connectie altijd gesloten worden, anders loopt men het
risico om onnodig connecties open te laten staan en zo de pool van vrije connecties van
de database uit te putten.
40
41
Code 5-6 ReportDaoImpl
5.3.5
ReportService
Net als bij de DAO wordt bij de service klassen de implementatie gescheiden van de
interface. Omdat er weinig business logic te vinden is in het ophalen van rapporten
krijgt de ReportService ook gewoon een getPublishedReports methode.
Code 5-7 ReportService
5.3.6
ReportServiceImpl
Op regel 13 wordt een Spring bean gemaakt van deze service implementatie, met als
naam 'reportService'. Controllers kunnen dan van deze bean gebruik maken.
Op regels 16-21 wordt via Spring de 'reportDAO' bean (zie boven) geinject in
ReportServiceImpl.
Er is geen extra business logic toe te voegen aan getPublishedReports, op regel 24
wordt dan gewoon de getPublishedReports van de DAO aangeroepen.
42
Code 5-8 ReportServiceImpl
5.3.7
MVC Front-End
5.3.7.1
Controller (+model)
Op regel 17 markeren we ReportListController als een Controller. De achterliggende
Spring configuraties maken hier gebruik van om jsp pages en urls te koppelen aan de
classes gemarkeerd als Controller.
Op regels 20-25 wordt via Spring de 'reportService' bean (zie boven) geinject in de
ReportListController.
Op regel 27 wordt een RequestMapping gebruikt om te markeren dat http GET requests
afgehandeld moeten worden met de showList methode.
In regels 29 en 30 worden de rapporten opgehaald met de ReportService en daarna in
het model gestopt. Het model van RefApp is een manier om data door te geven aan de
jsp pagina (het view).
43
Code 5-9 ReportListController
5.3.7.2
JSP pagina (het view)
In de JSP pagina kunnen we waarden uit het model (zie boven) gebruiken door ${key}
te schrijven. Al wat tussen ${} wordt een EL expression genoemd. EL is de afkorting
van Expression Language. We kunnen met EL expressions makkelijk beans gebruiken,
zoals in onderstaande code duidelijk zal worden.
Op regel 21 wordt een forEach loop gestart van alle rapporten. Binnen deze loop
kunnen we naar het huidig rapport verwijzen met EL expressions als ${report}. De 'c'
prefix van de forEach tag slaagt terug op de taglib import op regel 5. Een tag library is
een verzameling van custom jsp tags en EL functions (zie bv fn verderop).
De choose-when-otherwise op regels 22-76 zorgt voor een keuze tussen een rapport
met alternatieve tekst (regels 24-39) en een rapport met standaard gegenereerde
product en additives tekst (regels 42-74).
Op regel 42 wordt een forEach loop gestart over alle producten van het huidige rapport.
${report.products} wordt ruwweg vertaald naar report.getProducts().
Regels 44-50 en 68-72 worden enkel getoond als ${report.products[0] == product}
waar is, dus enkel bij het eerste product.
Op regel 45 wordt de rowspan op het aantal producten van het huidige report gezet.
Merk op dat deze pagina geen head, body of html tags bevat. Dit komt doordat de
pagina naam eindigt op Body.jsp. Hierdoor wordt de inhoud van de pagina geïntegreerd
in het body van de jsp template gegenereerd door RefApp.
44
45
Code 5-10 reportListBody.jsp
5.3.8
Deployment documentatie
Nadat de code uitgeschreven is en lokaal getest, wordt de deployment documentatie
geschreven. Deze documentatie beschrijft hoe de applicatie in productie gebracht moet
worden. Dit document beschrijft wat gedaan moet worden op de server en de clients
om de applicatie werkende te krijgen.
46
5.4
crlForms
crlForms wordt gebruikt door externe aanvragers om nieuwe aanvragen voor feed
additive authorisations te maken. Hieronder is een formulier te zien van zo een
aanvraag.
47
Figure 5-6 crlForms submit form
De aanvrager/applicant moet na het invullen van het formulier eerst op 'Preview'
drukken en daarna op 'Submit'. Eens een aanvraag gesubmit wordt, kan de aanvraag
niet meer gewijzigd worden via de applicatie.
Door gebruik te maken van de refactoring methodes van eclipse, en de 'Find
references' functies heb ik de code van deze applicatie kunnen aanpassen aan de
wijzigingen in de database. De interface zelf is ongewijzigd gebleven, enkel de backend code moest aangepast worden.
5.5
crlApplication
crlApplication wordt gebruikt om een intern/CRL dossier, een dossier van de FSQ unit,
te vergelijken met het overeenkomstige extern/SANCO dossier. Dit zijn dezelfde
dossiers, maar ze worden op twee plaatsen bijgehouden en beheerd.
Op het beginscherm wordt gevraagd naar het 'submission number' van het extern
dossier en het CRL nummer van het intern dossier.
Figure 5-7 submission selection form
Op de volgende pagina kan men de eigenschappen van de dossiers vergelijken en de
eigenschappen afzonderlijk markeren als geaccepteerd.
48
Figure 5-8 Comparison form
Na alles geaccepteerd te hebben en op update te klikken, krijgen we volgend scherm te
zien:
Figure 5-9 Success message
Door gebruik te maken van de refactoring methodes van eclipse, en de 'Find
references' functies heb ik de code van deze applicatie kunnen aanpassen aan de
wijzigingen in de database. De interface zelf is ongewijzigd gebleven, enkel de backend code moest aangepast worden.
49
BESLUIT
In de afgelopen weken heb ik in vele projecten gewerkt en heb ik geleerd hoe ik snel
mijn weg kan vinden in bestaande code en er aanpassingen in kan maken zonder voor
regressie te zorgen. Het was soms lastig om de RefApp structuur te begrijpen en te
ontleden, dit ook omdat er niet veel centrale documentatie te vinden is over de huidige
versie en in zekere mate ook over oudere versies. Maar de RefApp structuur zorgt voor
een scheiding van database en front-end code, dus ik zie het nut er wel van in.
Ik heb ook RUP in werking kunnen zien van analyse tot ontwikkeling. Verder heb ik
leren werken met een aantal tools die ik voordien nog niet gebruikt had zoals Eclipse,
JIRA en SQL Developer.
Graag zou ik ook nog enkele suggesties meegeven om het development proces te
verbeteren.
Er wordt veel tijd besteed aan analyse, hoewel analyse belangrijk is kan deze tijd
teruggedreven worden door gebruik te maken van de Agile methodologie. Zo wordt
nieuwe functionaliteit sneller afgeleverd en worden fouten sneller ontdekt. Bijvoorbeeld,
incremental design zou kunnen helpen om code simpel te houden waar het kan en
complex te maken waar het nodig is. Hierdoor wordt het makkelijker en sneller om
nieuwe features te implementeren. Incremental design houdt in dat er geen design van
het hele project gemaakt wordt voor men begint te programmeren. Men implementeert
feature per feature en voegt zo dingen toe naargelang nodig is. Als de code moeilijk
leesbaar dreigt te worden, wordt er aan refactoring gedaan. Refactoren houdt in dat
code geherstructureerd wordt, om dit goed te kunnen doen zonder voor regressie te
zorgen moeten er geautomatiseerde tests zijn van de applicatie.
Met de huidige RefApp structuur zou data access code in de DAO classes moeten
komen, business logic code in de Service classes en code die te maken heeft met hoe
gereageerd moet worden op input in de Controller classes. In de praktijk echter, blijven
de Service classes vaak leeg en komt alle business logic bij in de Controller's terecht.
Dit zorgt voor extra clutter, complexiteit, decentralisatie en verminderde leesbaarheid
in de Controller's.
Verder heeft de huidige business layer (de Service classes) een vrij proceduraal
karakter. Wat ik bedoel met een proceduraal karakter is dat de business layer een
verzameling van functies is in plaats van een verzameling van slimme domain objects
die samenwerken, messages sturen naar elkaar, hun data en implementation details
verbergen, en behaviour hebben. Merk op dat de DAO classes ook een proceduraal
karakter hebben, maar dit is normaal aangezien DAO classes werken met een niet-OO
database. Als een voorbeeld van zo'n soort business layer verwijs ik naar een project
van mij, geschreven in PHP:
http://limyreth.sin.khk.be/files/eindwerk/sincontrol2domain.html
Ik raad ook aan om te kijken naar het volgende document waarin ik een nieuwe manier
bespreek om web applicaties te maken en structureren. Deze manier maakt
development veel makkelijker, maar het vereist andere technologieën dan die nu
gebruikt zijn (zoals bijvoorbeeld Java Swing of SWT in plaats van de Java web
technologieën). Het document is te vinden op deze web locatie:
http://limyreth.sin.khk.be/files/eindwerk/webapp2.html.
Ik vond het een geslaagde stage. Ik heb veel bijgeleerd en heb een resultaat kunnen
afleveren aan de FSQ unit waar de users zeer tevreden over waren. Het publiceren van
rapporten gaat nu sneller en makkelijker, en het general public krijgt sneller de nieuwe
rapporten te zien. Het doet me een groot plezier om te zien dat ik mijn project tot een
goed einde heb kunnen brengen en zo heb kunnen bijdragen tot de business.
50
LITERATUURLIJST
Apache Ant. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Apache_Ant
Apache Maven. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Apache_Maven
Apache Tomcat. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Apache_Tomcat
Eclipse (Software). (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Eclipse_%28software%29
European Commision. (2010). Structure. Opgeroepen op 25 mei 2011, op het internet:
http://ec.europa.eu/dgs/jrc/index.cfm?id=1440
Hibernate (Software). (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Hibernate_%28software%29
Institute for Reference Materials and Measurements. (2008). Key competences.
Opgeroepen op 25 mei 2011, op het internet:
https://irmm.jrc.ec.europa.eu/about_IRMM/key_competences/Pages/index.aspx
Institute for Reference Materials and Measurements. (2010). European Union Reference
Laboratories. Opgeroepen op 25 mei 2011, op het internet:
https://irmm.jrc.ec.europa.eu/EURLs/Pages/index.aspx
Institute for Reference Materials and Measurements. (2010). European Union Reference
Laboratory for Feed Additives, EURL-FA. Opgeroepen op 25 mei 2011, op het internet:
https://irmm.jrc.ec.europa.eu/EURLs/EURL_feed_additives/Pages/index.aspx
Java Persistence API. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Java_Persistence_API
Java (programming language). (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Java_%28programming_language%29
Java (software platform). (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Java_%28software_platform%29
JIRA. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/JIRA
Oracle. (s.a.). Oracle SQL Developer. Opgeroepen op 25 mei 2011, op het internet:
http://www.oracle.com/technetwork/developer-tools/sqldeveloper/overview/index.html
Oracle WebLogic Server. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Weblogic
Red Hat, Inc. (2004). Hibernate Reference Documentation. Opgeroepen op 25 mei
2011, op het internet:
http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/
RefApp Wiki. (s.a.). Opgeroepen op 25 mei 2011, op het internet:
https://webgate.ec.europa.eu/CITnet/confluence/display/RefApp/Home
51
Spring Framework. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Spring_Framework
SpringSource. (s.a.). Spring API. Opgeroepen op 25 mei 2011, op het internet:
http://static.springsource.org/spring/docs/3.1.0.M1/javadoc-api/
Subversion. (s.a.). Gevonden op 25 mei 2009 op Wikipedia:
http://en.wikipedia.org/wiki/Subversion