EWI. BSc- project EASY REST API EN DEMONSTRATOR IN3405. Data Archiving and Networked Services

Maat: px
Weergave met pagina beginnen:

Download "EWI. BSc- project EASY REST API EN DEMONSTRATOR IN3405. Data Archiving and Networked Services"

Transcriptie

1 BSc- project EASY REST API EN DEMONSTRATOR IN3405 Data Archiving and Networked Services EWI MSc Maarten Hoogerwerf (DANS) dr. Arjan van Genderen (TU Delft) dr. Hans- Gerhard Gross (TU Delft) Georgi Khomeriki Roshan Timal

2 1 Voorwoord Ter afsluiting van onze Bachelor opleiding aan de TU Delft wordt van ons verwacht om zelfstandig een project uit te voeren en deze tot een goed eind te brengen. In dit verslag beschrijven wij hetgeen we hebben gedaan en geleerd. Graag willen wij alle medewerkers van DANS bedanken voor de gezellige en leerzame tijd gedurende onze stage. Tevens willen wij onze begeleiders vanuit de TU, dr. Arjan van Genderen en dr. Hans- Gerhard Gross hartelijk bedanken voor hun inzet en feedback. Graag willen wij onze begeleider vanuit DANS, MSc Maarten Hoogerwerf, uitzonderlijk bedanken voor zijn zeer nuttige begeleiding gedurende het project. Hij heeft ons goed gestuurd om de zaken te bekijken vanuit een echt ingenieurs perspectief. 2

3 Inhoudsopgave 1 VOORWOORD SAMENVATTING INLEIDING DANS EASY DE OPDRACHT PROBLEEMSTELLING EN ANALYSE ONTWERP AANPAK REQUIREMENTS WAAROM REST? WAAROM ROA? KOPPELING MET HET HUIDIGE SYSTEEM ONTWERP VAN DE REST LAAG WAAROM ANDROID? ONTWERP VAN DE DEMONSTRATOR APP KWALITEITSWAARBORGING IMPLEMENTATIE PLANNING VS. REALITEIT Requirements Frameworks Design keuzes REFLECTIE OP DE IMPLEMENTATIE FASE Technische aspecten Security aspecten Juridische aspecten Test suite Feedback SIG CONCLUSIE AANBEVELINGEN LITERATUUR APPENDIX A OPDRACHTOMSCHRIJVING APPENDIX B PLAN VAN AANPAK INTRODUCTIE PROJECTOPDRACHT AANPAK EN TIJDSPLANNING PROJECTINRICHTING KWALITEITSWAARBORGING (PVA) BIJLAGE A TECHNISCHE ARCHITECTUUR EASY APPENDIX C ORIËNTATIEVERSLAG INLEIDING EASY REST

4 12.4 ROA RESTFUL FRAMEWORKS OVERIGE FRAMEWORKS ANDROID CONCLUSIE (OV) APPENDIX A - KEUZEMODEL GEBRUIKERSRECHTEN EASY APPENDIX D REQUIREMENTS ANALYSIS DOCUMENT API INTRODUCTIE Doel van het systeem Scope van het systeem Doelen en succes-criteria van het project Overzicht HUIDIG SYSTEEM VOORGESTELD SYSTEEM Overzicht Functionele requirements Non-functionele requirements Systeem modellen WOORDENLIJST (RAD- API) APPENDIX A HTTP RESPONS CODES APPENDIX E REQUIREMENTS ANALYSIS DOCUMENT - CLIENT VOORWOORD INTRODUCTIE Doel van de demonstrator Scope van de demonstrator Doelen en succes- criteria van het project Overzicht HUIDIGE IMPLEMENTATIES Grafisch weergeven van datasets op een kaart Grafisch weergeven van datasets op een tijdlijn VOORGESTELD SYSTEEM Grafisch weergeven van datasets op een kaart Grafisch weergeven van datasets op een tijdslijn SYSTEEM MODELLEN Scenarios Use case model Analysis object model Dynamic model APPENDIX F WEB APPLICATION DESCRIPTION LANGUAGE (WADL) BESCHRIJVING API

5 2 Samenvatting Data Archiving and Networked Services (DANS) is een instituut dat zich voornamelijk bezighoudt met het bevorderen van duurzame toegang tot digitale onderzoeksgegevens. EASY (Electronic Archiving SYstem) is het online archiveringssysteem dat hiertoe dient. EASY bevat veel datasets met data en metadata die op dit moment alleen toegankelijk zijn via de web interface. De opdracht voor deze BSc- stage was om een API te ontwikkelen (op basis van REST principes) die het voor externe applicaties mogelijk maakt te communiceren met EASY. Tevens moest een demonstrator app gebouwd worden die de mogelijkheden van API demonstreert. We begonnen het project met een oriëntatie fase, waarin we onderzochten wat mogelijke oplossingen konden zijn en welke tools we het beste konden gebruiken. Hierna volgde het ontwerp proces. De eerste stap in het ontwerp proces was het verzamelen en prioriteren van de requirements. Hiertoe hebben we verschillende stakeholders van het project benaderd en Requirements Analysis Documents (voor de server en voor de demonstrator) opgesteld. We hebben tevens gekeken of een op REST (Representational State Transfer) gebaseerde oplossing inderdaad de meest efficiënte was, dit bleek het geval te zijn. We hebben het REST principe verder geëxtrapoleerd en ons gecommiteerd aan het ROA (Resource Oriented Architecture) principe. We hebben de API als een zelfstandige module geimplementeerd die slechts communiceert met de business laag van EASY. De demonstrator is in staat te communiceren met de API en (meta)data daaruit op te vragen. Wij hebben veel tijd besteed aan het onderhoudbaar houden van het systeem. Dit deden we onder andere door veel tests te schrijven, gebruik te maken van standaarden en veel gebruikte frameworks/tools. Gedurende het project zijn er een aantal tegenslagen geweest die wij moesten overwinnen. Sommige tegenslagen waren van technische aard, zoals het configureren van de Spring context en de Maven dependencies of security overwegingen die ons parten speelden. Andere tegenslagen waren van juridische aard en slechts te verhelpen door toezeggingen van de jurist van DANS. Wij hebben naar ons gevoel het doel van de opdracht bereikt. De API is in staat om applicaties en toepassingen van derden te serveren met data uit EASY en de demonstrator is in staat om de potentie van een dergelijke API aan te tonen en de functies de valideren. DANS zou op de ingeslagen weg door moeten gaan en de API verder valideren en uitbouwen. Hiertoe hebben we een aantal aanbevelingen in dit verslag opgenomen. 5

6 3 Inleiding 3.1 DANS Data Archiving and Networked Services 1 (DANS) is een instituut van KNAW 2 en NWO 3. De voornaamste bezigheid van DANS is het bevorderen van duurzame toegang tot digitale onderzoeksgegevens. Een belangrijke doelstelling van DANS is het stimuleren van wetenschappelijke onderzoekers om gegevens duurzaam te archiveren en hergebruiken. Een voorbeeld van een dienst dat hiertoe dient is het online archiveringssysteem EASY 4. Tevens faciliteert DANS met het NARCIS 5 project toegang tot vele wetenschappelijke datasets, e- publicaties en andere onderzoeksinformatie in Nederland. DANS hanteert het principe Open als het kan, beschermd als het moet. Hiermee wordt bedoeld dat er getracht wordt data onder het Open Access principe te publiceren. DANS zorgt er met zijn dienstverlening en deelname in (inter)nationale projecten en netwerken voor dat de toegang tot digitale onderzoeksgegevens verder verbetert. 3.2 EASY Zoals eerder genoemd, is EASY (Electronic Archiving SYstem) het online archiveringssysteem van DANS. EASY bevat duizenden datasets op het gebied van sociale- en geesteswetenschappen. Sinds kort ondersteunt EASY ook andere disciplines. EASY faciliteert het online deponeren en beschikbaar maken van onderzoeksgegevens. Gebruikers van EASY kunnen op een gemakkelijke wijze zoeken naar bepaalde datasets en browsen door het archief. Naast de onderzoeksgegevens archiveert EASY tevens de metadata van deze gegevens. Deze metadata beschrijft de inhoud van de datasets. DANS gebruikt een gestandaardiseerd formaat voor de metadata genaamd Dublin Core 6. Voor een uitgebreidere uitleg van EASY verwijzen we de lezer naar het oriëntatieverslag (zie appendix C). 3.3 De opdracht De opdracht van DANS die wij voor deze BSc- stage hebben gekregen bestond uit twee globale delen. Het eerste deel bestond uit het ontwikkelen van een server (gebaseerd op REST architectuur principes) die machine- machine interactie mogelijk maakt met het EASY archief. Het tweede gedeelte van de opdracht bestond uit het implementeren van een Android 7 app die de mogelijkheden van de REST server demonstreert https://easy.dans.knaw.nl/

7 4 Probleemstelling en analyse De voornaamste motivatie voor het ontwikkelen van een API voor EASY is de vraag van vele mensen binnen en buiten DANS om applicaties te ontwikkelen die gebruik kunnen maken van de data die in het EASY archief zit. Momenteel is EASY eigenlijk alleen bereikbaar via de web- interface. Er zijn wel een aantal API s gekoppeld aan EASY die bijvoorbeeld harvesting van metadata mogelijk maken (via het OAI- PMH 8 protocol) en onlangs is er ook een service bijgekomen die het mogelijk maakt om data automatisch te deponeren in EASY (via het SWORD 9 interface). Echter heeft EASY geen uniforme manier om resources die in EASY zitten beschikbaar te maken voor applicaties buiten EASY. EASY is een duurzaam archief dat voor de lange termijn beschikbaar moet zijn. Het is dus belangrijk dat EASY qua functionaliteit en code goed onderhoudbaar is. Men moet dus goed oppassen dat de omvang van het systeem niet uit de hand loopt. Er lopen binnen DANS veel projecten die toegevoegde functionaliteit vereisen van EASY. Tegenwoordig is het vaak zo dat deze dan ook daadwerkelijk in EASY worden geimplementeerd. Door een consistente API ter beschikking te stellen hoeft EASY niet belast te worden met specifieke functionaliteiten voor andere projecten maar kunnen deze buiten EASY worden geimplementeerd. Dit bevordert de modulariteit en zelfstandigheid van de systemen die gebouwd worden. De API moet het ook mogelijk maken om resources uit te wisselen met andere systemen. Resources moeten aangeboden kunnen worden via nieuwe kanalen zodat deze bijvoorbeeld gecombineerd kunnen worden met resources uit andere databronnen. Op dergelijke wijze kunnen nieuwe toepassingen worden ontwikkeld en kan er meerwaarde worden gecreëerd met de bestaande (meta)data. Om bovengenoemde redenen is bij DANS de wil ontstaan om een API te bouwen bovenop EASY die machine- machine interactie mogelijk maakt et- al 7

8 5 Ontwerp 5.1 Aanpak We begonnen dit project met het bepalen van wat er nou precies moest gebeuren, dit deden we in eerste instantie aan de hand van de opdrachtomschrijving. Eventuele onduidelijkheden over de opdracht werden besproken met onze bedrijfsbegeleider. Vervolgens construeerden we een plan van aanpak (zie appendix B). In dat document werd beschreven hoe we het project zouden inrichten en wat we in globale lijnen gingen doen. Daarop volgend gingen we op zoek naar reeds bestaande software frameworks en tools die project ten goede zouden komen. Onze bevindingen hierover werden gedocumenteerd in het oriëntatieverslag. Voordat we konden beginnen met het daadwerkelijk implementeren van zowel de API als de demonstrator werden voor beide implementaties een RAD- document opgesteld. De inhoud van deze documenten werd gebruikt als leidraad tijdens de implementatie fase. Onze bevindingen over het algehele proces worden in dit document besproken en toegelicht. 5.2 Requirements De eerste stap in het ontwerp proces was het verzamelen en prioriteren van de requirements. Hiertoe hebben we verschillende stakeholders van het project benaderd. In eerste instantie was dat onze begeleider Maarten Hoogerwerf. Tevens hebben we veel gesprekken gevoerd met andere medewerkers van DANS. Ook hebben we een e- mail gestuurd naar alle medewerkers waarin we onze plannen kort toelichtten en een oproep deden tot het kenbaar maken van wensen betreffende de requirements en toepassingen van de API. We hebben vele ideeen en reacties ontvangen waaruit enkele toegevoegde requirements zijn voortgevloeid. Het belangrijkste doel van de API bleek de wens te zijn om de resources en functionaliteiten die voor gebruikers beschikbaar zijn via de web interface tevens beschikbaar te maken via de API maar dan voor machines/applicaties. De overige voornaamste requirements van de API zijn: security, uniformiteit en onderhoudbaarheid. De API moet bijvoorbeeld kunnen garanderen dat de data niet kwetsbaarder wordt ten gevolge van het gebruik van de API. Tevens moet de communicatie met de API op een uniforme (preferabel gestandaardiseerde) wijze verlopen. Uiteraard moet de API goed onderhoudbaar en testbaar zijn, aangezien deze API slechts een opzet is voor toekomstige implementaties en/of uitbreidingen. We hebben in eerste instantie de requirements opgesteld voor de API en daarna zijn we pas de requirements gaan analyzeren van de demonstrator aangezien deze sterk afhangen van hetgeen de API mogelijk maakt. Het doel van de demonstrator is om de mogelijkheden van de API goed te demonstreren en zoveel mogelijk van de functionaliteiten van de API gebruiken. De demonstrator moet dus aantonen dat degelijke functionaliteiten gebouwd kunnen worden. We hebben dus uiteindelijk twee Requirements Analysis Documents opgesteld, één voor de API en één voor de client (zie appendix D en E). 8

9 5.3 Waarom REST? Het ontwikkelen van een API voor EASY was gemakkelijk te verantwoorden. Echter was het de vraag waarom er per se voor een op REST gebaseerde aanpak gekozen moest worden. We hebben in de oriëntatie fase ons verdiept in de principes van REST en vooral gekeken naar wat de onderscheidende factoren zijn ten opzichte van overige architecturele inrichingen voor web services. In het boek RESTful Web Services (Richardson et al.) wordt gesteld dat web services globaal opgedeeld kunnen worden in drie categorieën op basis van architectuur, namelijk: RESTful resource oriented, RPC- style en REST- RPC hybrid. De RESTful resource oriented architectuur hebben we uitgebreid besproken in ons oriëntatieverslag (zie appendix C). Heel kort samengevat komt het erop neer dat REST het HTTP protocol benut op de manier zoals het oorspronkelijk door de bedenkers bedoeld was. Het gebruik van HTTP methoden, headers en respons codes staat centraal. REST biedt dus geen protocol overhead bovenop de huidige structuur van het web maar gebruikt hetgeen al jaren beschikbaar is en zichzelf al talloze malen heeft bewezen (waarvan het wereld wijde web het beste voorbeeld is). Het vaak (onbewust) gebruikte alternatief is de RPC- style van service architectuur. RPC staat voor remote procedure call, dit symboliseert de gedachtegang dat clients communiceren met servers door bepaalde procedures (van afstand) aan te roepen en de server het resultaat terug te laten sturen. Elk op RPC gebaseerde web service heeft behoefte aan nadere afspraken over de manier van communiceren. Contrasterend, hebben op REST gebaseerde services altijd dezelfde vocabulaire en manier van communiceren, namelijk HTTP. Vaak gebruiken op RPC gebaseerde services HTTP wel als onderliggend protocol voor de protocol maar wordt slechts een subset van de mogelijke aspecten gebruikt. Tevens wordt daar dan een eigen communicatie protocol bovenop geimplementeerd. Een dergelijke aanpak zorgt dus voor overhead in het communicatie protocol. Het derde alternatief van architectuur voor web services is een hybride variant van de twee overige varianten genaamd REST- RPC hybrid. Zoals de naam als suggereert combineert deze vorm van architectuur REST en RPC met elkaar. De daadwerkelijke invulling van de combinatie is aan de ontwikkelaars zelf. Een REST- RPC architectuur is vaak het resultaat van mensen die goede kennis hebben van web applicaties maar niet van de REST principes. Bij dergelijke systemen wordt vaak HTTP als communicatie medium gebruikt maar wordt nog steeds een RPC manier gebruikt om de server bepaalde taken uit te laten voeren. Ook dit alternatief leidt tot overhead (weliswaar minder dan RPC) in het communicatie aspect. De communicatie is wel enigzins uniform aangzien HTTP wordt gebruikt maar niet op het niveau dat bereikt zou kunnen worden. Voor daadwerkelijk uniforme communicatie zal men REST als enige van de drie mogelijkheden kunnen gebruiken. Dankzij het feit dat RESTful web services geen eigen manier van communiceren is er ook minder overhead in de code en documentatie nodig. Het principe bouwt echt op de oorspronkelijke gedachtegang van HTTP en gebruikt hetgeen al jaren voor handen is. We kunnen concluderen dat de op REST gebaseerde architectuur de meest degelijke oplossing is voor web services, met name voor services die machine- 9

10 machine interactie als doel hebben. De ontwikkelaars die de service willen gebruiken vanuit hun eigen applicatie kunnen dat doen door middel van HTTP communicatie en hoeven daarvoor niet een ander nieuw protocol uit te zoeken. 5.4 Waarom ROA? Nadat we voor onszelf verantwoord hadden waarom REST inderdaad de geschikte manier is om de web service in te richten besloten we de lat nog iets hoger te leggen en ons te commiteren aan de principes van ROA (Resource Oriented Architecture). We hebben ROA reeds uitgebreid besproken in het oriëntatieverslag (zie appendix C). Samenvattend kan gesteld worden dat REST (als beschreven in de dissertatie van R.T. Fielding) veel ruimte open laat als het gaat om daadwerkelijke implementatie en uitvoering. Dat is waar ROA om de hoek komt kijken en de open gelaten gebieden probeert in te vullen. Naast de reeds bestaande REST principes en constraints voegt ROA daar zijn eigen constraints aan toe. De toegevoegde constraints zijn: addressability, statelessness, connectedness en uniform interface. Deze constraints zijn tevens besproken in het oriëntatieverslag, dus we zullen er hier niet te diep op ingaan. Kort gezegd stelt de constraint van addressability dat elke resource addresseerbaar moet zijn via een eigen URI. Statelessness stelt dat elke request die een server ontvangt alle informatie moet bevatten om die request af te handelen. Het resultaat van een vorige request mag dus geen invloed hebben op het resultaat. Connectedness stelt dat resources gezien moeten worden als hypermedia die relaties hebben met andere resources en representaties. Deze relaties zijn een wezenlijk onderdeel van de resource zelf. De laatste constraint is de uniform interface. Deze stelt dat de communicatie met de server op een uniforme manier moet verlopen. In de praktijk komt het erop neer dat de HTTP methode stelt wat voor actie er uitgevoerd moet worden. Het adres van de HTTP request zegt op welke resource de betreffende actie uitgevoerd moet worden. Tevens kunnen de HTTP headers worden gebruikt om meta informatie over de uit te voeren actie mee te sturen. Om het ROA principe in perspectief te plaatsen naast de overige manieren van het ontwerpen van web services hebben we de onderstaande illustratie opgenomen. Figuur 1: Eén service op drie verschillende manieren. (RESTful web services) Alle drie de services uit het vorige figuur bieden dezelfde functionaliteiten, echter verbetert de usability naar rechts toe. Service A is een typische RPC- style service, alles wordt beschikbaar gesteld via een enkele URI. Deze service is niet addressable noch connected. Service B is addressable maar niet connected, er zijn geen relaties tussen de resources. Dit duidt waarschijnlijk op een REST- RPC 10

11 hybrid service. Service C is addressable en well- connected, resources hebben dus relaties met elkaar. Dit duidt op een RESTful service gebaseerd op ROA principes. Vanwege de concrete invulling van ROA op het REST principe en de heldere constraints hebben we gekozen om het ROA principe als leidraad te kiezen bij de inrichting van de server. Tevens passen de constraints goed bij de resources die in EASY zitten. Het kunnen addresseren van resources speelt bij veel projecten binnen DANS een rol, ook is connectedness van belang voor het linken van resources (dit is tevens iets wat heel erg speelt bij DANS). 5.5 Koppeling met het huidige systeem Nadat we de keuze hadden gemaakt voor een op ROA gebaseerde architectuur moesten we kijken hoe we de server zouden opzetten (met welke reeds bestaande technieken) en met name hoe we de koppeling zouden maken met het huidige systeem (EASY). We moesten ook verifiëren dat de keuze voor een op ROA gebaseerd systeem goed aansluit bij EASY. Dit bleek inderdaad het geval aangezien EASY in essentie gezien kan worden als een pool van resources (data, metadata, etc.). Het feit dat EASY gemoduleerd (three- tier) is opgezet heeft ons veel tijd bespaard. EASY is zo opgesteld dat elke module zijn eigen verantwoordelijkheid heeft. Aangezien wij een API moesten ontwikkelen hadden wij alleen een dependency nodig op de business laag van EASY. Via de business laag konden wij alle resources en informatie opvragen en eventueel bewerken. De business laag vroeg die resources dan weer op bij onderliggende modules. Ondanks het feit dat EASY veel modules bevat en heel veel code hebben wij ons alleen hoeven te beperken tot het communiceren met de services die de business laag biedt. Om zo veel mogelijk in lijn te blijven met de opzet van EASY hebben we besloten om veel dezelfde libraries, tools en API s te gebruiken. Wij hebben dus gekozen voor Maven 10 als build tool, eclipse 11 als ontwikkelomgeving, Spring 12 als koppel/configuratie systeem etc. Ook voor de ontwikkeling van de demonstrator hebben we gekozen voor de bovengenoemde systemen om ook die in lijn te houden met hetgeen binnen DANS gebruikt wordt. 5.6 Ontwerp van de REST laag Zoals we hadden beschreven in ons Plan van Aanpak (zie appendix B) hebben we de RESTful API als een alleenstaande module geimplementeerd die schematisch naast de huidige web UI staat en slechts gebruik maakt van de services uit de business laag en het domein model. Een klein deel van het totale architectuur plaatje is hieronder weergeven. Een volledige weergave van het architecturele ontwerp van EASY met de REST API daaraan toegevoegd is te zien in het Plan van Aanpak

12 Figuur 2: Een gedeelte van het ontwerp van EASY met daaraan toegevoegd de relatie met de RESTful API module (voor het volledige diagram zie Plan van Aanpak, Appendix B). Er moet hier wel bijgezegd worden dat het domein model gevisualiseerd is als zijnde losstaand van de business laag. Echter is de implementatie zo dat het domein model in de business laag zit op dit moment. Dit zou eigenlijk uitgesplitst moeten worden. Een belangrijke randvoorwaarde van onze API was dat we de functionaliteiten moesten realiseren op basis van hetgeen de business laag op dit moment te bieden heeft. Het was dus niet de bedoeling om speciale/nieuwe functies toe te voegen aan de business laag om de API te implementeren. We zijn er echter niet aan ontkomen om een paar kleine bugs te moeten opsporen en oplossen in EASY. Voor een overzicht van de methodes en resources die de REST API aanbiedt verwijzen we naar het Web Application Description Language 13 (WADL) document (zie appendix F). Dit is een op XML gebaseerd document dat de web service beschrijft op een manier die tevens interpreteerbaar is door machines. 5.7 Waarom Android? De voornaamste reden om de demonstrator te ontwikkelen voor het Android platform was omdat dit demonstreert dat de REST API platform onafhankelijk is. Bijna alle projecten van DANS hebben een (ouderwetse) website als front- end. De mogelijkheden van de API op een mobiel platform demonstreren leek ons

13 geschikt aangezien dat voor meer impact zal zorgen dan wederom een website die intern anders in elkaar zit. Een belangrijk technische factor bij de keuze voor Android was het feit dat we dan konden ontwikkelen in Java 14. De API is natuurlijk onafhankelijk van de taal waarin de client wordt geschreven, het zou dus passend zijn voor de demonstrator om een andere taal te kiezen voor deze. Echter, aangezien EASY in Java is ontwikkeld zal de API ook in Java ontwikkeld moeten worden, om dan in dezelfde lijn te blijven is het handig om de demonstrator tevens met dezelfde taal te ontwikkelen. Tevens is het zo dat wij goed bekend zijn met Java, dat scheelt dus ook weer in de tijd. 5.8 Ontwerp van de demonstrator app Een van de doelen van de demonstrator, was het valideren van de functies die de RESTful API aanbood. Om dit doel te verwezenlijken wordt er in de demonstrator via de API de data en metadata van datasets opgehaald. Tevens wordt er gebruik gemaakt van de search en advanced search algoritmes. De twee laatstgenoemde algoritmes zijn tevens beschikbaar gemaakt door de API. De demonstrator werd ook ontworpen om te laten zien dat door middel van de API het mogelijk werd om in andere omgevingen dan de web interface de data van EASY te gebruiken. Deze andere omgeving (zoals in de vorige paragraaf duidelijk is geworden) is in ons geval het Android platform. De werking van de demonstrator is als volgt: de demonstrator begint met het tonen van een inlogscherm. Met de gegeven gebruikersnaam en wachtwoord wordt bij elke request naar de API deze in de header gestopt en verstuurd. Vervolgens krijgt de gebruiker een zoekscherm te zien waar de keuze gemaakt kan worden ofwel de search ofwel de advanced search te gebruiken Als er een argument in het search veld wordt ingevoerd en daarop volgend op de knop view on map wordt gedrukt resulteert dit in een GET request op de URI: https://[host]/api/search?q=scheme=rd argument Bij de advanced search daarentegen wordt er een GET request uitgevoerd op de URI: https://[host]/api/advsearch?coverage=scheme=rd&attr=attrvalue&attr2=attrva lue &attrn=attrnvalue Waarbij attr een attribuut is waarop gezocht kan worden (bijvoorbeeld op titel) en attrvalue de waarde is behorend bij het attribuut. Bij zowel de search als de advanced search wordt er in de uri de argument scheme=rd toegevoegd, dit doen we omdat we willen forceren dat de datasets die we terugkrijgen als gevolg van een zoekquery daadwerkelijk coördinaten bevatten. Voor de werking van de demonstrator is het essentieel dat de datasets coördinaten bevatten aangezien deze in de Google Maps layer zullen worden weergeven. De zoekresultaten worden door middel van een markering weergeven op de kaart (zie figuur 3). Als de gebruiker op een markering klikt, wordt er een nieuwe activiteit gestart. Deze

14 activiteit bevat drie tabs: respectievelijk de Overview, Description en Images tabs (zie figuur 4). Figuur 3: Locaties van datasets weergeven in Google Maps. In de Overview tab wordt een korte beschrijving van de dataset getoond. De inhoud van de Overview tab wordt gegenereerd met de response van de search, aangezien alle benodigde informatie te vinden is in de body van de response. De inhoud van de Description tab wordt bepaald door de metadata van een betreffende dataset. De metadata van een dataset kan worden opgevraagd door het versturen van een GET- request naar de RESTful- API op de volgende URI: https://[host]/api/{store-id}/metadata De body van de response wordt vervolgens geconverteerd naar een menselijk prettig ogend formaat. Bij de Images tab wordt de daadwerkelijke data van een dataset opgevraagd, echter willen we alleen de afbeeldingen van een dataset ophalen. Het ophalen en weergeven is dan ook tweedelig. In eerste instantie worden alle images van een dataset opgehaald door een GET- request uit te voeren op de URI: https://[host]/api/{store-id}/thumbnails Hierdoor krijgen we de namen van bestanden zoals die zijn opgeslagen in EASY. Vervolgens wordt de daadwerkelijke inhoud van een individueel bestand opgehaald, door een GET- request uit te voeren op: https://host/api/{store-id}/thumbnails/{thumbnail-id} De body van de response wordt geïnterpreteerd door de demonstator en vervolgens getoond in de Images tab. Dit proces wordt herhaald voor elk gevonden bestand. 14

15 Figuur 4: Tab activiteit waarbij de description tab is geselecteerd. 5.9 Kwaliteitswaarborging Gedurende het project hebben we getracht de op te leveren code zo kwalitatief en onderhoudbaar mogelijk op te zetten. Een aantal principes en design patterns die aan het licht kwamen bij het vak software engineering konden hier goed voor worden gebruikt. Tevens hadden we de keuze gemaakt om test- driven te ontwikkelen. We hebben dus veel tijd besteed aan het schrijven van unit tests. Gedurende de implementatie fase merkten we echter dat we te weinig tijd hadden om de test suites zodanig te schrijven als we van te voren hadden gepland. We hebben besloten om de server te voorzien van een goede test suite omdat deze de basis zal vormen voor toekomstige implementaties. De demonstrator daarentegen is precies hetgeen de naam al suggereert, slechts een demonstratie voor de mogelijkheden van de server. We hebben dus geen geautomatiseerde test suite geschreven voor de demonstrator. Hierdoor hadden we dus meer tijd voor de tests van de server en hebben we 99% line en branch coverage gerealiseerd. Om de code coverage te meten hebben we gebruik gemaakt van de Cobertura 15 plugin voor Maven. Het resultaat van de Cobertura meting is te zien in onderstaand figuur

16 Figuur 5: De test-coverage gemeten met de Cobertura plugin voor Maven. Een belangrijk onderdeel van het onderhoudbaar houden van de code is het schrijven van Javadoc 16 documentatie. We hebben Javadoc dus de nodige aandacht gegeven en ervoor gezorgd dat alle methoden degelijke Javadoc documentatie bevatten. Er moet hier wel bijgezegd worden dat Javadoc slechts een documentatie is van de implementatie en niet moet worden gezien als een handleiding voor het gebruik van de API. Om de leesbaarheid van de code te bevorderen hebben we gebruik gemaakt van een Maven plugin genaamd Checkstyle 17. Dit is een plugin die men via een XML configuratie de code kan laten checken op stijl fouten. In de configuratie wordt opgegeven welke stijl aspecten gecheckt moeten worden. We hebben bij het vak software kwaliteit & testen al een dergelijke configuratie gebruikt, vanwege de beperkte tijd is besloten om die ook voor dit project te gebruiken. Deze configuratie checkt de meest gangbare code practices. We hebben er uiteindelijk voor gezorgd dat de Checkstyle reports geen warnings en errors meer bevatten. Onderstaande illustratie bevat een klein deel van het Checkstyle resultaat. Figuur 6: Het resultaat van de Checkstyle plugin voor Maven. Wij hebben het gevoel dat de code goed onderhoudbaar is en van degelijke kwaliteit. Dit werd ook bevestigd door de eerste code review van SIG, hier zullen we later nog op terug komen checkstyle- plugin/ 16

17 6 Implementatie 6.1 Planning vs. realiteit Hetgeen we met de opdrachtgever zijn overeengekomen bij aanvang van het project bleek ambitieuzer te zijn dan gedacht. Ondanks het feit dat de opdracht voor drie personen was geformuleerd en wij slechts met zijn tweeën waren konden we niet goed inschatten wat realiseerbaar was. Zoals wel gewoonlijk is bij IT- projecten verkeken wij ons op de verhouding van hoeveelheid werk en beschikbare tijd. Tevens hebben we veel onvoorziene problemen moeten oplossen. Jammer genoeg hebben we dus bepaalde aspecten die we wel hadden ingepland niet uit kunnen voeren. In dit hoofdstuk zullen we daar wat verder over uitwijden. Ook zullen we ingaan op de keuzes die we hebben gemaakt betreffende bepaalde tools/frameworks/libraries die wij hebben gebruikt om het project te realiseren. Bij deze keuzes zijn we uitgegaan van onze eigen kennis/ervaring en hetgeen DANS reeds gebruikt Requirements Om binnen de gegeven tijd het project af te ronden moesten er concessies gedaan worden over welke functionele requirements geïmplementeerd werden en welke niet. Het MoSCoW document dat was opgesteld (naar aanleiding van de behoeftes van de klant) in het RAD document (zie appendix D) hielp bij het maken van een selectie van requirements die uiteindelijk wel in ons tijdsbestek pastten. Elk van de requirements opgedeeld in Must have zijn geïmplementeerd behalve de requirement De server moet expliciet in de respons headers meesturen of een resource cacheable is en wanneer de resource voor het laatst is gewijzigd. Deze requirement is niet geïmplementeerd omdat in EASY niet kan worden bepaald wanneer een resource voor het laatst is gewijzigd. Dit is uiteraard essentieel voor het bepalen of een resource cacheable is of niet. De requirements betreffende het sturen van PUT en POST- requests in Should have zijn niet geïmplementeerd, de reden hiervoor wordt nader toegelicht in de paragraaf Security aspecten. Andere requirements in Should have die niet zijn geïmplementeerd, zijn de requirements gerelateerd aan de zogenaamde permission requests, dit was voornamelijk te wijten aan tijdgebrek. De resterende requirements in Should have zijn wel geïmplementeerd, deze omvatten onder andere het intact houden van de lucene zoek- syntax en de adresseerbaarheid van elementen van een dataset. De requirements betreffende gebruikersovereenkomsten zijn niet geïmplementeerd. De voornaamste reden van het niet implementeren van deze requirements was het gebrek aan tijd. De laatsgenoemde requirements vielen onder Could have. Een requirement van Could have die echter wel is geïmplementeerd is het opvragen van resources in meerdere formaten. De requirements die zijn opgedeeld in Won t have zijn niet geïmplementeerd. De opdrachtgever achtte deze requirements niet van dermate belang (immers, deze waren ingedeeld in Won t have ). Voor de requirements van de demonstrator, beschreven in desbetreffende Requirements Analysis Document (appendix E), is de voornaamste requirement 17

18 dat niet is geïmplementeerd het combineren van verschillende databronnen met de data die beschikbaar is gesteld door de RESTful API. Elk ander requirement opgelegd door de opdrachtgever betreffende de demonstrator is wel geïmplementeerd. Wat betreft de non- functionele requirements, is het schrijven van een handleiding voor de API in verband met de resterende tijd niet gelukt. Er is echter wel een WADL document die de API beschrijft. Tevens is om de bovenstaande reden het niet gelukt om de API en eventueel de demonstrator te stresstesten. Voor zover mogelijk hebben we wel het ROA- principe aangehouden (het implementeren van de cacheability nagelaten) Frameworks Alvorens te beginnen aan de implementatie fase hadden we ons georiënteerd op de reeds bestaande frameworks die we zouden kunnen gebruiken voor het project. Frameworks zijn vaak goed getest en van goede kwaliteit, deze kunnen dus veel tijd en werk besparen. Een aantal framework keuzes zijn zeer productief gebleken maar een aantal bleken gedurende de implementatie fase onbruikbaar. Voor die frameworks hebben we dus alternatieven moeten gebruiken of, in een enkel geval, de functionaliteit zelf moeten schrijven. De keuze voor de op JAX- RS 18 (zie oriëntatieverslag, appendix C) specificatie gebaseerde Jersey 19 framework heeft ons veel tijd bespaard. Het stelde ons in staat om de server in te richten door gebruik van annotaties. Echter hadden we gepland om de bijbehorende Jersey client te gebruiken voor de demonstrator. Dit is niet strikt noodzakelijk aangezien elke client (met HTTP voorzieningen) dienst zou kunnen doen, echter leek het ons tijd besparender om ook hiervoor Jersey te gebruiken. Met deze Jersey client zou de communicatie opgezet worden met de server. Jammer genoeg bleek deze client niet compatible te zijn met de virtuele machine (genaamd Dalvik VM 20 ) die draait op Android. We hebben vervolgens moeten kiezen om Spring- Android 21 te gebruiken voor de Android app. Ook hadden we initieel de keuze gemaakt om geen gebruik te maken van de Jersey- Test- Framework aangezien we wilden dat de unit tests onafhankelijk zouden zijn van de gebruikte REST framework. Vooral vanwege de JAX- RS ondersteuning zou DANS in de toekomst zeer gemakkelijk kunnen overstappen op een alternatieve implementatie. We wilden zekerheid hebben dat in een dergelijke situatie de test suite nog steeds zou functioneren. Daarom hadden we de keuze gemaakt om de onafhankelijke REST- assured 22 framework te gebruiken. Echter kwamen we tijdens het schrijven van unit tests erachter dat deze zeer weinig faciliteiten had voor het schrijven van unit tests en vooral gespits was op het ontwikkelen van integratie tests. Bij test- driven ontwikkeling zijn unit- tests cruciaal dus hebben we besloten om alsnog Jersey- Test- Framework te gebruiken. Ondanks alles zijn we er alsnog in geslaagd om de tests framework onafhankelijk te houden android/ 22 assured/ 18

19 Nog een belangrijke keuze die we bij aanvang hadden gemaakt was het gebruik van de PowerMock 23 framework met als onderliggend framework EasyMock 24. Deze keuze hadden we gemaakt omdat we al bekend waren met deze frameworks en dit ook de frameworks zijn die gebruikt worden in de test- suite van EASY. Echter bleek tijdens het schrijven van de tests dat de Jersey- Test- Framework niet compatible is met deze mocking frameworks. We moesten dus overstappen naar het (minder krachtige) mockito 25 framework om objecten te mocken in onze unit tests. De laatste framework keuze die uiteindelijk niet de implementatie heeft bereikt was om JiBX 26 te gebruiken voor het omzetten van java objecten naar XML structuren. EASY maakt tevens gebruik van JiBX. Echter bleek deze veel te complex te zijn voor de simpele doeleinden waarvoor wij het nodig hadden. We hebben dus om tijd te besparen besloten om JiBX niet te gebruiken. DANS had slechte ervaringen met JiBX dus we vonden het weglaten van deze niet heel erg. Als alternatief hebben we zelf een (uiterst) simpele XML converter geschreven. We hebben het zo opgezet dat het relatief gemakkelijk is om deze in de toekomst te vervangen door een alternatieve implementatie of framework Design keuzes Zoals gewoonlijk bij IT projecten is het ontwerp van de applicaties gedurende de implementatie fase een aantal keer bijgesteld. Dit is inherent aan een agile manier van werken. Verrassend genoeg zijn de ontwerp keuzes die we voor de implementatie fase hadden gemaakt wel in grote lijnen intact gebleven. De grootste verschillen zitten echt op het detail/implementatie niveau. We hebben de complexiteit van bepaalde functionaliteiten onderschat waardoor een aantal klassen iets ingewikkelder zijn geworden dan gepland. Echter hebben we de complexiteit enigzins vereenvoudigd door goed gebruik te maken van objectgeoriënteerde principes. In het Requirements Analysis Document van de API hebben we een klassediagram opgenomen die het globale ontwerp weergeeft. Onderstaand figuur illustreert de uiteindelijke implementatie van dat ontwerp

20 Figuur 7: Een gedeelte van het klassediagram van de uiteindelijke API. Bovenstaand klassediagram toont het belangrijste deel van de API implementatie. Dit zijn de daadwerkelijke resource klassen die een request binnenkrijgen en daarvoor een respons genereren. Om dat te doen gebruiken ze tevens allerlei utility klassen die wij hebben geschreven, echter hebben we deze niet opgenomen in het diagram om het overzicht te bevorderen. Een opvallende ontwerp keuze waar uiteindelijk van zijn afgestapt is het gebruik van Persistent Identifiers 27 voor het identificeren van resources. Om de URI s die wijzen naar resources zo consistent mogelijk te houden leek ons het gebruik van Persistent Identifiers een goed idee. Echter bleek dat de business laag van EASY niet op basis van dergelijke identifiers de bijbehorende resources kan vinden. Daarvoor zouden we dus functionaliteit in de business laag moeten bijbouwen, hetgeen we wilden voorkomen. Tevens bleek het zo te zijn dat sommige datasets deze Persistent Identifiers nog niet hebben, die zouden dus niet adresseerbaar zijn met een dergelijke aanpak. Na rondvraag bij de beheerders en ontwikkelaars van EASY begrepen we dat de interne store ID s van objecten tevens een redelijk permanent karakter hebben. We hebben dus de store ID s gebruikt voor het adresseren van resources. 27 identifier 20

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

januari TTNWW Handleiding TST tools voor het Nederlands als Web services in een Workflow Meertens Instituut, Joan Muyskensweg 25, 1096 CJ Amsterdam

januari TTNWW Handleiding TST tools voor het Nederlands als Web services in een Workflow Meertens Instituut, Joan Muyskensweg 25, 1096 CJ Amsterdam januari 2013 TTNWW Handleiding TST tools voor het Nederlands als Web services in een Workflow Meertens Instituut, Joan Muyskensweg 25, 1096 CJ Amsterdam Table of Contents Inleiding... 3 Gebruik van de

Nadere informatie

Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0

Technisch ontwerp. Projectteam 6. Project Web Essentials 02 april 2009. Versie 2.1.0 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin

Nadere informatie

Zelftest Java EE Architectuur

Zelftest Java EE Architectuur Zelftest Java EE Architectuur Document: n1218test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA EE ARCHITECTUUR Nota:

Nadere informatie

Connect Social Business

Connect Social Business Connect Social Business Joey Kaan September 2014 Inhoudsopgave 1 Achtergronden 4 2 Probleemstelling & Doelstelling 5 2.1 Leren Professioneel Functioneren.................. 5 2.2 Facebook API leren door

Nadere informatie

Projectdocument Airport Suite. The Wright Company: Zehna van den Berg Steven Both Reinier Maas Adolfo Ochagavía Bas Ouwerkerk Thijs van der Zaan

Projectdocument Airport Suite. The Wright Company: Zehna van den Berg Steven Both Reinier Maas Adolfo Ochagavía Bas Ouwerkerk Thijs van der Zaan Projectdocument Airport Suite The Wright Company: Zehna van den Berg Steven Both Reinier Maas Adolfo Ochagavía Bas Ouwerkerk Thijs van der Zaan December 2013 Contents 1. Overzicht... 4 2. Planning... 5

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 29, 2014 Inhoudsopgave 1 Achtergronden 1 2 Probleemstelling & Doelstelling 2 2.1 Leren Professioneel Functioneren..................

Nadere informatie

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 21, 2014 Inhoudsopgave 1 Achtergronden 4 2 Probleemstelling & Doelstelling 5 2.1 Leren Professioneel Functioneren..................

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 28, 2014 Inhoudsopgave 1 Achtergronden 1 2 Probleemstelling & Doelstelling 2 2.1 Leren Professioneel Functioneren..................

Nadere informatie

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Inhoudsopgave Inhoudsopgave... 2 1. Beheer helpdesk... 3 1.1. Settings... 3 1.2. Applicaties... 4 1.3. Prioriteiten... 5 1.4. Gebruik mailtemplates...

Nadere informatie

Outlook koppeling ChainWise

Outlook koppeling ChainWise Outlook koppeling ChainWise Product ChainWise Bedrijfssoftware Datum 04-08-2016 Alle rechten voorbehouden aan ChainWise Niets in deze uitgave mag worden gebruikt in welke vorm dan ook zonder schriftelijke

Nadere informatie

Opdrachtformulering (pagina 3 van 7)

Opdrachtformulering (pagina 3 van 7) Afstudeerovereenkomst van Tim Wils Bijlage 1 Opdrachtformulering (pagina 3 van 7) Dit project betreft een eigen framework (soort API) waarmee relatief gemakkelijk en in korte tijd eindproducten opgezet

Nadere informatie

Technologieverkenning

Technologieverkenning Technologieverkenning Videocontent in the cloud door de koppeling van MediaMosa installaties Versie 1.0 14 oktober 2010 Auteur: Herman van Dompseler SURFnet/Kennisnet Innovatieprogramma Het SURFnet/ Kennisnet

Nadere informatie

Algemene gebruiksvoorwaarden

Algemene gebruiksvoorwaarden Algemene gebruiksvoorwaarden >>> Algemene gebruiksvoorwaarden Data Archiving and Networked Services (DANS) Postbus 93067 2509 AB Den Haag Anna van Saksenlaan 51 2593 HW Den Haag +31 70 349 44 50 info@dans.knaw.nl

Nadere informatie

Handleiding. Z factuur Archief

Handleiding. Z factuur Archief Handleiding Z factuur Archief INHOUDSOPGAVE 1. DASHBOARD... 3 1.1. Inloggen... 3 Inloggegevens vergeten... 3 1.2. Mogelijkheden Dashboard... 3 Instellingen, Abonnement Info en Adressenboek... 3 Facturen

Nadere informatie

GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE

GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE versie 2.0, 14 april 2010 SURFNET BV, R ADBOUDKWARTIER 273, POSTBUS 19035, 3501 DA U TRECHT T +31 302 305 305, F +31 302 305 329, WWW.SURFNET. NL INHOUD 1.

Nadere informatie

Zest Application Professionals Training &Workshops

Zest Application Professionals Training &Workshops Het in kaart krijgen van kwetsbaarheden in Websites & Applicaties en hoe deze eenvoudig te voorkomen zijn, wordt in Applicatie Assessments aangetoond en in een praktische Workshop behandelt. U doet hands-on

Nadere informatie

Security web services

Security web services Security web services Inleiding Tegenwoordig zijn er allerlei applicaties te benaderen via het internet. Voor bedrijven zorgt dit dat zei de klanten snel kunnen benaderen en aanpassingen voor iedereen

Nadere informatie

OpenIMS 4.2 Portaal Server

OpenIMS 4.2 Portaal Server OpenIMS 4.2 Portaal Server Inhoudsopgave 1 WAT IS EEN ENTERPRISE INFORMATIE PORTAAL?...3 1.1 BESPARINGEN...3 1.2 GERICHT OP EEN SPECIFIEKE DOELGROEP...3 2 OPENIMS PORTAAL SERVER (PS)...4 2.1 CENTRAAL BEHEER...4

Nadere informatie

Gebruikershandleiding GO search 2.0

Gebruikershandleiding GO search 2.0 Gebruikershandleiding GO search 2.0 1 Gebruikershandleiding Product: GO search 2.0 Documentversie: 1.1 Datum: 2 februari 2015 Niets uit deze uitgave mag zonder toestemming van GemeenteOplossingen worden

Nadere informatie

Plan van Aanpak. Christophe Deloo, Roy Straver & Machiel Visser. Versie 4 (26-06-2010)

Plan van Aanpak. Christophe Deloo, Roy Straver & Machiel Visser. Versie 4 (26-06-2010) Plan van Aanpak Christophe Deloo, Roy Straver & Machiel Visser Versie 4 (26-06-2010) Inhoudsopgave Voorwoord... 2 1 Inleiding... 3 1.1 Aanleiding... 3 1.2 Accordering en bijstelling... 3 1.3 Toelichting

Nadere informatie

Eindverslag. Technische Universiteit Delft. TI3800 Bachelorproject. Mobiel Notificatie Systeem

Eindverslag. Technische Universiteit Delft. TI3800 Bachelorproject. Mobiel Notificatie Systeem Technische Universiteit Delft TI3800 Bachelorproject Mobiel Notificatie Systeem Eindverslag Auteurs: Edwin van den Houdt ManWai Shing Begeleiders: Cor-Paul Bezemer (TU Delft) Eugène Pattikawa (Exact) Peter

Nadere informatie

Acht stappen voor JSF

Acht stappen voor JSF Acht stappen voor JSF Inleiding In deze tutorial zullen we JSF (Java server faces) installeren. Wat we niet beschrijven is hoe te werken met JSF, over dit onderwerp zijn er genoeg boeken en internetsites

Nadere informatie

De SolidWorks QuickStart Module

De SolidWorks QuickStart Module SolidWorks 3D CAD software biedt intuïtieve oplossingen voor alle aspecten van uw designproces. De SolidWorks producten kunnen worden toegepast binnen de hele organisatie. De SolidWorks QuickStart Module

Nadere informatie

Doel is, dat dit document uiteindelijk een visie formuleert, waar de volgende partijen achter kunnen staan:

Doel is, dat dit document uiteindelijk een visie formuleert, waar de volgende partijen achter kunnen staan: User Profile Repository Art Recommender Visie document Versie 2.0 1 juli 2011 Auteurs Hennie Brugman, technisch coordator CATCHPlus hennie.brugman@meertens.knaw.nl Doel is, dat dit document uiteindelijk

Nadere informatie

Documentatie Distributed Services Enterprise Service Bus

Documentatie Distributed Services Enterprise Service Bus Documentatie Distributed Services Enterprise Service Bus Pleun Willemsen en Walter Ebbers 19 april 2012 v1.0 1 Inhoudsopgave 1 Inleiding 4 1.1 Opdracht................................ 4 2 Analyse 5 3 Ontwikkelomgeving

Nadere informatie

Documentatie. InstantModules Q42. Versie 1.1

Documentatie. InstantModules Q42. Versie 1.1 Documentatie InstantModules Q42 Versie 1.1 Inhoudsopgave Inhoudsopgave... 2 Voor gebruikers... 3 InstantComment... 3 InstantTagging... 5 Voor webmasters... 9 InstantComment... 9 InstantTagging... 11 Voor

Nadere informatie

TECHNICAL DESIGN DOCUMENT

TECHNICAL DESIGN DOCUMENT TECHNICAL DESIGN DOCUMENT BACHELORPROJECT IN3405 John Ciocoiu 1358227 Elwin Dokter 1275909 TECHNISCHE UNIVERSITEIT DELFT FACULTEIT EWI WOENSDAG 28 APRIL 2010 VERSIE 1 COMMISSIE: Ing. D.J. van Roest (opdrachtgever)

Nadere informatie

Ervaringen met het opzetten van een MDD omgeving

Ervaringen met het opzetten van een MDD omgeving Ervaringen met het opzetten van een MDD omgeving Introductie (1/3) Eric Jan Malotaux Software architect Mod4j Software architect Ordina Johan Vogelzang Developer Mod4j Projectleider Java ontwikkelstraat

Nadere informatie

Handleiding ESS na de upgrade People Inc. versie 3.5.0

Handleiding ESS na de upgrade People Inc. versie 3.5.0 Handleiding ESS na de upgrade People Inc. versie 3.5.0 I Handleiding ESS na de upgrade People Inc. versie 3.5.0 Inhoudsopgave Hoofdstuk 1 1 1.1 ESS... Iconen selecteren 1 1.2 ESS... Inlog scherm tekst

Nadere informatie

HDN DARTS WEB AUTHENTICATIE

HDN DARTS WEB AUTHENTICATIE HDN DARTS WEB AUTHENTICATIE HDN Helpdesk T: 0182 750 585 F: 0182 750 589 M: helpdesk@hdn.nl Copyright Communications Security Net B.V. Inhoudsopgave 1. INLEIDING OP HET ONTWERP... 3 1.1 HET DOEL VAN DIT

Nadere informatie

Gebruikershandleiding. StUF Testplatform Versie 1.3.0

Gebruikershandleiding. StUF Testplatform Versie 1.3.0 Gebruikershandleiding StUF Testplatform Versie 1.3.0 Documentversie: 0.7 Datum 25 november 2014 Status In gebruik Inhoudsopgave 1 INLEIDING...3 2 GEBRUIK MAKEN VAN HET STUF TESTPLATFORM...4 2.1 INLOGGEN

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

ONZE INTERPRETATIE VAN HET KNOOPPUNT PLATFORM

ONZE INTERPRETATIE VAN HET KNOOPPUNT PLATFORM MEMO: ONZE INTERPRETATIE VAN HET KNOOPPUNT PLATFORM Boek.be 1 INHOUDSTAFEL 1 INHOUDSTAFEL... 2 2 ALGEMENE INFORMATIE... 3 2.1 DOCUMENT INFO... 3 2.2 NASCOM INFO... 3 2.3 KLANT INFO... 3 3 INTERPRETATIE

Nadere informatie

Release datum: 11 juni 2012

Release datum: 11 juni 2012 Highlights 1 HSExpert versie 5.2 Begin juni is versie 5.2 van HSExpert gereleased. In versie 5.2 zijn vooral wijzigingen op het RiAxion (Arbo) dossier doorgevoerd. Daarnaast zijn er wat kleinere wijzigingen

Nadere informatie

Mywebshop Email configuratie. Versie 1.0 Februari 2010. Copyright 2010 Wikit BVBA, alle rechten voorbehouden

Mywebshop Email configuratie. Versie 1.0 Februari 2010. Copyright 2010 Wikit BVBA, alle rechten voorbehouden Mywebshop Email configuratie Copyright 2010 Wikit BVBA, alle rechten voorbehouden Deze handleiding mag gebruikt worden om met behulp van de mywebshop.net infrastructuur een webwinkel/website te bouwen.

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

HANDLEIDING EXTERNE TOEGANG CURAMARE

HANDLEIDING EXTERNE TOEGANG CURAMARE HANDLEIDING EXTERNE TOEGANG CURAMARE Via onze SonicWALL Secure Remote Access Appliance is het mogelijk om vanaf thuis in te loggen op de RDS omgeving van CuraMare. Deze handleiding beschrijft de inlogmethode

Nadere informatie

Handleiding Mooy Logistics Servicedesk

Handleiding Mooy Logistics Servicedesk Handleiding Mooy Logistics Servicedesk Handleiding Mooy Logistics Servicedesk... 1 1. Inloggen... 2 2. Zoeken naar documenten.... 3 3. Downloaden van alle documenten op factuurnummer.... 5 4. Order regels

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Handleiding Magento - Yuki

Handleiding Magento - Yuki Handleiding Magento - Yuki www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van Magento naar Yuki. De koppeling zorgt dat voor facturen in Magento automatisch een factuur of

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

Nadere informatie

SURFconext Cookbook. Het koppelen van Alfresco aan SURFconext. Versie: 1.0. Datum: 8 december 2013. 030-2 305 305 admin@surfnet.nl www.surfnet.

SURFconext Cookbook. Het koppelen van Alfresco aan SURFconext. Versie: 1.0. Datum: 8 december 2013. 030-2 305 305 admin@surfnet.nl www.surfnet. SURFconext Cookbook Het koppelen van Alfresco aan SURFconext Auteur(s): Frank Niesten Versie: 1.0 Datum: 8 december 2013 Radboudkwartier 273 3511 CK Utrecht Postbus 19035 3501 DA Utrecht 030-2 305 305

Nadere informatie

Externe toegang met ESET Secure Authentication. Daxis helpdesk@daxis.nl Versie 2.0

Externe toegang met ESET Secure Authentication. Daxis helpdesk@daxis.nl Versie 2.0 Externe toegang met ESET Secure Authentication Daxis helpdesk@daxis.nl Versie 2.0 Inhoudsopgave: Inhoudsopgave:... 1 Inleiding:... 2 Stap 1: Download eenmalig Eset Secure Authentication op uw smartphone...

Nadere informatie

Software Design Document

Software Design Document Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Zeon PDF Driver Trial

Zeon PDF Driver Trial Zakelijke software voor verkoop, dienstverlening en administratie Handleiding module Document Uitgaande correspondentie genereren Uitgaande correspondentie terugvinden Persoonlijk geadresseerde mailings

Nadere informatie

Enabling Mobile. Een whitepaper over het ontsluiten van data en systemen voor gebruik met en door mobiele applicaties

Enabling Mobile. Een whitepaper over het ontsluiten van data en systemen voor gebruik met en door mobiele applicaties Enabling Mobile Een whitepaper over het ontsluiten van data en systemen voor gebruik met en door mobiele applicaties Door Rutger van Iperen Mobile Developer bij AMIS Services Introductie Het gebruik van

Nadere informatie

Agile Testen in de praktijk

Agile Testen in de praktijk 1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile

Nadere informatie

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag.

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Voorbeeldproject Een Haagse SOA Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Aanleiding Vanuit de visie

Nadere informatie

WordPress in het Kort

WordPress in het Kort WordPress in het Kort Een website maken met Wordpress. In minder dan één uur online! Inclusief installatie van een thema en plugins Alle rechten 2013, Rudy Brinkman, BrinkhostDotCom, http://www.brinkhost.nl

Nadere informatie

Kwaliteitsbeleid metadata ontsloten in het NGR

Kwaliteitsbeleid metadata ontsloten in het NGR Kwaliteitsbeleid metadata ontsloten in het NGR In het overleg van het GI-beraad van juni 2014 is het verbeterplan metadata besproken. De voorzitter concludeert dat het belang van metadata door iedereen

Nadere informatie

Digikoppeling adapter

Digikoppeling adapter Digikoppeling adapter Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555

Nadere informatie

Base24 database suite

Base24 database suite Base24 database suite Introductie De Base24 database suite is een zeer geavanceerde database oplossing die ontworpen is voor de management, opslag, inzage en uitwisseling van medische informatie zoals

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous 2006-2007 Inhoudsopgave 1 2 1.1 Programmeertaal PHP5..................... 2 1.2 MySQL database......................... 3 1.3 Adobe Flash...........................

Nadere informatie

DOCUMENTATIE DONATIEMODULE KOPPELING

DOCUMENTATIE DONATIEMODULE KOPPELING DOCUMENTATIE DONATIEMODULE KOPPELING Stichting GeefGratis GeefSamen via Geef.nl Documentatie koppeling GeefGratis donatiemodule v1.06 Pagina 1 INHOUDSOPGAVE INHOUDSOPGAVE... 2 Inleiding... 3 Versiebeheer...

Nadere informatie

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van VPN s

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van VPN s Beknopte dienstbeschrijving Beveiligen van VPN's m.b.v. digitale certificaten en PKI Document: Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van VPN s Inhoudsopgave 1. Inleiding 2 2. Snel te

Nadere informatie

SolidWorks QuickStart Algemene informatie

SolidWorks QuickStart Algemene informatie SolidWorks QuickStart Algemene informatie SolidWorks 3D CAD software biedt intuïtieve oplossingen voor alle aspecten van uw designproces. De SolidWorks producten kunnen worden toegepast binnen de hele

Nadere informatie

Samengaan van Geo-informatie en Service Oriëntatie

Samengaan van Geo-informatie en Service Oriëntatie Samengaan van Geo-informatie en Service Oriëntatie Waterbodem Applicatie (WAB*info) 10 juli 2008 Gaston Lamaitre Data-ICT-Dienst, Delft Inhoud Wat doet Rijkswaterstaat? Doel van WAB*info De randvoorwaarden

Nadere informatie

Implementatiekosten en baten van SURFconext. Versie: 0.5 Datum: 06/06/2013 Door: Peter Clijsters

Implementatiekosten en baten van SURFconext. Versie: 0.5 Datum: 06/06/2013 Door: Peter Clijsters Implementatiekosten en baten van SURFconext Versie: 0.5 Datum: 06/06/2013 Door: Peter Clijsters Dit document geeft een antwoord op de vraag hoeveel een aansluiting op SURFconext kost. Introductie... 1

Nadere informatie

Handleiding Magento - Asperion

Handleiding Magento - Asperion Handleiding Magento - Asperion www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van Magento naar Asperion. De koppeling zorgt dat voor facturen in Magento automatisch een factuur

Nadere informatie

15 July 2014. Betaalopdrachten web applicatie gebruikers handleiding

15 July 2014. Betaalopdrachten web applicatie gebruikers handleiding Betaalopdrachten web applicatie gebruikers handleiding 1 Overzicht Steeds vaker komen we de term web applicatie tegen bij software ontwikkeling. Een web applicatie is een programma dat online op een webserver

Nadere informatie

Gebruik van cryptografie voor veilige jquery/rest webapplicaties. Frans van Buul Inter Access

Gebruik van cryptografie voor veilige jquery/rest webapplicaties. Frans van Buul Inter Access Gebruik van cryptografie voor veilige jquery/rest webapplicaties Frans van Buul Inter Access 1 Frans van Buul frans.van.buul@interaccess.nl 2 De Uitdaging Rijke en veilige webapplicaties Een onveilig en

Nadere informatie

Rapport. i-bridge FleetBroker en LocationBroker. Versie 1.0. Datum 22 December 2010

Rapport. i-bridge FleetBroker en LocationBroker. Versie 1.0. Datum 22 December 2010 Rapport i-bridge FleetBroker en LocationBroker Versie 1.0 Datum 22 December 2010 Status Final Colofon IVENT A&A CDC Madame Curielaan 4-6 Postbus 20703 2289 CA Rijswijk Contactpersoon Patrick Brooijmans

Nadere informatie

Leones. Business Case Service Management Tool

Leones. Business Case Service Management Tool Leones Business Case Service Management Tool Inhoudsopgave 1. AFBAKENING... 3 1.1 DOEL... 3 1.2 AANNAMES... 3 1.3 HUIDIGE SITUATIE... 3 1.4 PROBLEEMSTELLING... 3 1.5 WAT ALS ER NIETS GEBEURT?... 3 2. OPTIES...

Nadere informatie

Web Handleiding. semper vigilant Fall 2014 LOCALBOX 1.1.3

Web Handleiding. semper vigilant Fall 2014 LOCALBOX 1.1.3 Web Handleiding semper vigilant Fall 2014 Functionaliteiten web-based 2 Inloggen 2 Home 3 Uploaden: 4 Opties: 6 Map Delen: 6 Beheer Links 8 Functionaliteiten App-based 12 Hoger niveau 16 Acties op bestanden

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

HANDLEIDING. onderzoekaccount. serviceapotheek.tevreden.nl handleiding onderzoekaccount 2013 pagina 1 van 23

HANDLEIDING. onderzoekaccount. serviceapotheek.tevreden.nl handleiding onderzoekaccount 2013 pagina 1 van 23 HANDLEIDING onderzoekaccount serviceapotheek.tevreden.nl handleiding onderzoekaccount 2013 pagina 1 van 23 Inhoudsopgave Inloggen serviceapotheek.tevreden.nl... 3 Dashboard... 3 Rapportcijfers... 4 Toon...

Nadere informatie

Using Google Maps Engine Connector for QGIS

Using Google Maps Engine Connector for QGIS Using Google Maps Engine Connector for QGIS QGIS Tutorials and Tips Author Ujaval Gandhi http://google.com/+ujavalgandhi Translations by Dick Groskamp This work is licensed under a Creative Commons Attribution

Nadere informatie

Technologie en Interactie 3.2: software architectuur

Technologie en Interactie 3.2: software architectuur Technologie en Interactie 3.2: software architectuur Manual IAM-TDI-V2-Technologie en Interactie. Jaar 0809 blok 2 Oktober 2008 Fons van Kesteren 1/8 Inhoud Technologie en Interactie 3.2: software architectuur...

Nadere informatie

MyDPD Pro. De handleiding voor je online programma Snel van start

MyDPD Pro. De handleiding voor je online programma Snel van start MyDPD Pro De handleiding voor je online programma Snel van start Inhoudsopgave 1. Welkom bij MyDPD Pro 3 2. Aan de slag met MyDPD Pro 4 2.1. Startpagina 4 2.2. MyDPD Pro-profiel 6 2.2.1. Wachtwoordinstellingen

Nadere informatie

Roadmap. RIE Manager

Roadmap. RIE Manager Roadmap RIE Manager Look & Feel Rapportage/ Documentatie Uploaden Documenten Major Release 3 Lokaal beheer Major Release 2 Regie in eigen hand Submodules Major Release 1 Introductie In deze roadmap geeft

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

SportCTM 2.0 Sporter

SportCTM 2.0 Sporter SportCTM 2.0 Sporter APP Inloggen Dotcomsport heeft ter ondersteuning van de dagelijkse praktijk ook een APP ontwikkeld, om data invoer te vereenvoudigen. Deze APP ondersteunt de onderdelen; Agenda (invoer

Nadere informatie

PILNAR web applicatie. Handleiding

PILNAR web applicatie. Handleiding PILNAR web applicatie Handleiding Table of Contents De PILNAR editor...3 Toegang tot de omgeving...3 De PILNAR omgeving...3 Hoofdmenu...4 Navigatie...5 Zoeken...6 Detailoverzichten...6 Collectie... 7 Inzending...

Nadere informatie

Werken zonder zorgen met uw ICT bij u op locatie

Werken zonder zorgen met uw ICT bij u op locatie Werken zonder zorgen met uw ICT bij u op locatie Naast de mogelijkheden om uw programmatuur en gegevens bij Drie-O via Evy 2.0 in de cloud te hosten hebt u ook de mogelijkheid om uw ICT omgeving bij u

Nadere informatie

SMS Webservice Implementatie handleiding

SMS Webservice Implementatie handleiding SMS Webservice Implementatie handleiding Versie 1.2 Inhoudspagina Versiebeheer... 2 Overzicht webservice... 2 Begrippenlijst... 2 Starten met de straightxs webservice... 3 Algemene beschrijving van de

Nadere informatie

Feature checklist NeMO 5 Android

Feature checklist NeMO 5 Android Feature checklist NeMO 5 Android PCA Mobile 2014 Feature Omschrijving Opmerkingen Algemene kenmerken Mobile Only NeMO5 voor Android is een Native Android Applicatie (app) Cloud Vereist geen lokale of gehoste

Nadere informatie

IC Mail Gateway Gebruikershandleiding

IC Mail Gateway Gebruikershandleiding IC Mail Gateway Gebruikershandleiding Versiebeheer Versie Datum Naam Wijziging 1.0 27 oktober 2008 ICA Initieel document 1.1 18 juni 2010 ICA Document geheel herzien 2.0 30 januari 2013 ICA Aanpassing

Nadere informatie

Remote Back-up Personal

Remote Back-up Personal handleiding Remote Back-up Personal Versie 4 1 INLEIDING... 3 1.1 SYSTEEMEISEN... 3 1.2 BELANGRIJKSTE FUNCTIES... 3 2 INSTALLATIE BACK-UP MANAGER... 4 2.1 VOLLEDIGE DATA BESCHIKBAARHEID IN 3 STAPPEN...

Nadere informatie

Beginnen met de Agenda & planning module

Beginnen met de Agenda & planning module Auteur : Reint Endendijk Versie : 1.0 Datum : 22 juni 2010 2 Minimale stappen om te beginnen Introductie Hieronder wordt het minimum aantal stappen om te beginnen met de module Agenda & Planning kort beschreven.

Nadere informatie

Informatica 2 Studiehandleiding

Informatica 2 Studiehandleiding Informatica 2 Studiehandleiding Embedded Systems Engineering Groep: ES1D ir drs E.J Boks 25-02-2010 Inhoud 1 Inleiding... 2 2 Doelstelling... 3 3 Beoordeling... 4 4 Eisen aan het verslag... 6 Voorbeeld

Nadere informatie

Alfresco's Simple Records Management

Alfresco's Simple Records Management Alfresco's Simple Records Management Het e erste open source dossie r beh eersysteem Ee nvoudig beheer van dossiers Nieuwe wetten, regelgeving en normen hebben voor veel verandering gezorgd in hoe verslagen

Nadere informatie

Datanotitie Meertens Instituut

Datanotitie Meertens Instituut Datanotitie Meertens Instituut februari 2012 Hans Bennis (directeur) Marc Kemps Snijders (hoofd Technische Ontwikkeling) Douwe Zeldenrust (coördinator onderzoekscollecties) I Onderzoeksdata Inleiding Binnen

Nadere informatie

Whitepaper. Connected Android Apps. Inleiding

Whitepaper. Connected Android Apps. Inleiding Whitepaper Connected Android Apps Inleiding Dit jaar zou wel eens het jaar van de tablet kunnen worden. De mobiele markt heeft met de komst van de tablet al laten zien dat mobiliteit niet stopt bij het

Nadere informatie

Nederlands Normalisatie Instituut

Nederlands Normalisatie Instituut Nederlands Normalisatie Instituut CITRIX / SSL VPN Helpdesk NEN kmc@nen.nl T: 0152690268 http://portal.nen.nl Versie 2.0.1 VPN hoe en wat Bij NEN kan er vanaf extern worden ingelogd op het netwerk. Dit

Nadere informatie

VERENIGINGSWIJZER.NL FINAL DOCUMENT

VERENIGINGSWIJZER.NL FINAL DOCUMENT Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen Project Multimedia Peter van Ulden Studentnr. 1494759 VERENIGINGSWIJZER.NL FINAL DOCUMENT INHOUDSOPGAVE 1 Inleiding...3 2 Aanpak & Techniek...4

Nadere informatie

Elektronisch factureren

Elektronisch factureren Elektronisch factureren Inleiding Elektronisch Factureren in RADAR is mogelijk vanaf versie 4.0. Deze module wordt niet standaard meegeleverd met de RADAR Update maar is te bestellen via de afdeling verkoop

Nadere informatie

Handleiding ADAS bij kwaliteitsvisitatie

Handleiding ADAS bij kwaliteitsvisitatie bij kwaliteitsvisitatie Dit document is een handleiding voor het gebruik van het online auditsysteem ADAS, gebruikt voorkwaliteitsvisitaties georganiseerd door de NVvP. Inhoudelijke informatie over de

Nadere informatie

Handleiding: Whitelabel Customersite

Handleiding: Whitelabel Customersite ARGEWEB B.V. Handleiding: Whitelabel Customersite Controlportal.nl Argeweb Support 8-1-2009 Handleiding voor het gebruik maken van de Whitelabel Customersite op controlportal.nl, door Resellers van Argeweb.

Nadere informatie

Handleiding Magento - Factuursturen

Handleiding Magento - Factuursturen Handleiding Magento - Factuursturen www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van Magento naar Factuursturen. De koppeling zorgt dat voor facturen in Magento automatisch

Nadere informatie