PROTOTYPE VOOR EEN LOKETSYSTEEM VIA HET WWW EENLOKETSYSTEEM. Eindverslag Jaarproject Programmeren. Studenten :! Pieter Janssens!

Transcriptie

1 1 Studenten :! Pieter Janssens! Pieter Van Gorp Promotor! Prof. Dr. Serge Demeyer Vertegenwoordiger van de klant! Peter Keil 02/ PROTOTYPE VOOR EEN LOKETSYSTEEM VIA HET WWW EENLOKETSYSTEEM

2 2 SAMENVATTING CONTEXT Bij de besluitvorming ter erkenning of subsidiëring van een museum hebben verscheidene partijen recht op inspraak of inzage in het dossier. Het bevoegde gezag doet een aanvraag, de minister van cultuur neemt het definitieve besluit. Partijen met adviesrecht zijn de administratie, de beoordelingscommissie, de provincie van het museum, de Vlaamse Gemeenschapscommissie en de bezwaarcommissie. Het bevoegde gezag en de conservator tenslotte hebben recht op inzage van de documenten die tot een besluit geleid hebben. PROBLEEM Het probleem dat zich hierbij stelt is het stroomlijnen en vereenvoudigen van de documentleverantie. Hierbij zou automatische besluitvorming mogelijk gemaakt moeten worden. OPLOSSING Het Eenloketsysteem is een webapplicatie die alle gegevens en documenten stapsgewijs verzamelt en opvraagbaar maakt. Ook de status waarin een dossier zich bevindt, is on line volgbaar. Wanneer er infomatie beschikbaar komt, worden de betrokken instanties via aangeschreven en indien nodig verzocht hun advies te geven. STATUS Zoals vooropgesteld hebben wij een prototype van dergelijke webapplicatie ontwikkeld. Dit prototype ondersteunt de erkenningsprocedure. Het systeem kan operationeel gemaakt worden voor demonstraties. Afspraak met de klant is dat wij na onze examens een presentatie geven aan leden van de administratie, zodat zij het nut en de mogelijkheden van een eenloketsysteem kunnen inschatten. BEHOEFTES Om de behoeften te concretiseren zijn wij uitgegaan van twee documenten: een nota over deze probleemstelling van Wim Lockefeer, coördinator Cel Beeld- en Media-educatie van de Provincie Limburg, en een document met richtlijnen over de procedures, dat gebruikt wordt door de administratie. Aangezien de reële manier van werken reeds afweek van deze theoretische beschrijvingen en op het punt stond nog verder te wijzigen 1, hebben we veel gesprekken gevoerd met de klant. We gebruikten Use Cases om het systeem af te bakenen en om de klant een overzicht te geven van de beschikbare transacties. De complexe procedure modelleerden we met een State Diagram. Door deze diagram herhaaldelijk met de klant te evalueren konden we de wijzigende context op de voet volgen. Van zodra we een werkend systeem hadden, hebben we met de klant het prototype aan de hand van een echte erkenningsaanvraag gevalideerd. ONTWERP We hebben het systeem bottom-up ontworpen. DATABANKLAAG We specifieerden de databankschema s met een ER-diagram en valideerden deze door na te gaan of de bestaande formulieren met dit schema konden verwerkt worden. De ERnotatie bleek te abstract om bij een evaluatie met de klant alle scenario s voorstelbaar te 1 Op het moment van de analyse werkte de administratie aan nieuwe uitvoeringsbesluiten en aan de Personeel & Procedure (PIP/PEP) analyse.

3 3 maken binnen haalbare tijd. Via een vast procédé vertaalden we de ER-diagram naar databankschema s. INTEGRATIELAAG Tussen de databank en de applicatielaag hebben we een logische integratielaag gebouwd die toelaat om het DBMS te wijzigen zonder de rest van het systeem te beïnvloeden. We veronderstelden wel dat alle data van het systeem in één en dezelfde databank mochten opgeslagen worden. APPLICATIELAAG De entiteiten uit onze ER-diagram projecteerden we naar objecten voor de applicatielaag. Hiervan hebben we geen extra UML diagrammen gemaakt aangezien het ons ontwikkelingsproces zou vertragen en we geacht werden zo snel mogelijk een draaiend systeem op te leveren. Bij het implementeren streefden we er wel naar voor een zo rijk mogelijke JavaDoc te zorgen. Om een robuust systeem te bouwen vulden we deze objecten aan met enkele klassen (Actie, Status, ActorType) die het ons mogelijk maakten éénzelfde implementatie te gebruiken voor de terugkerende handelingen uit een procedure. Bovendien maakten deze klassen het mogelijk om op een eenvoudige manier voor de verschillende stappen uit een procedure aan te geven welke actoren welke acties mogen ondernemen. Uit onze gesprekken met de klant bleek dat de procedure zou kunnen aangepast worden aan de gewijzigde uitvoeringsbesluiten. We hebben dan ook getracht het prototype reeds zo sterk mogelijk te doen overeenkomen met de nieuwe manier van werken. Via een finale bespreking van het State Diagram legden we met de klant de huidige machtigingen (wie wat wanneer mag/moet doen) vast. PRESENTATIELAAG De presentatielaag kon rechtstreeks geïmplementeerd worden. De Use Cases beschreven de transacties reeds, zij het met een hoog abstactiegehalte. IMPLEMENTATIE Het systeem werd geschreven met de Java 2 SDK, aanvankelijk met versie 1.2.2, later met versie 1.3.0_02. Deze upgrade had geen betrekking tot het systeem en heeft het systeem ook niet beïnvloed. Daarbij maakten we gebruik van Java Servlets 2.2 en JavaServer Pages 1.1. We gebruikten het Junit Framework om onze tests te implementeren en design by contract te gebruiken. DATABANKLAAG Om zoveel mogelijk inzage te hebben in onze data we bij het ontwerpen en het testen, maakten we elk gebruik van een locale MS Acces databank. INTEGRATIELAAG De communicatie met de databank verloopt via JDBC. De package eenloketsysteem.database encapsuleert dit proces. Via de klasse ConnectionPool worden overheen het volledige systeem steeds een instelbaar aantal connecties naar de databank onderhouden die gedeeld worden door de bovenliggende componenten. APPLICATIELAAG De objecten die uit de entiteiten van de databanklaag groeiden volgen de JavaBeans standaard. Dit laat toe ze als session beans te delen in de presentatielaag. Naast deze objecten uit de package eenloketsysteem.beans implementeerden we in de package eenloketsysteem de objecten die gegroeid waren uit de State Diagram. De verwantschap tussen de State Diagram voor de erkenningsprocedure en de klasse Status is een beetje zoals de kip en het ei. Hoe het ook zij, we menen dat deze klasse het sterkste deel van het systeem vertegenwoordigt.

4 4 PRESENTATIELAAG De presentatielaag bestaat uit een HTML-interface waarvan de views door JavaServer Pages gegenereerd worden en de controllers aan de hand van Servlets geïmplementeerd zijn. Als webserver hebben we zowel de JSWDK (versie 1.0.1) gebruikt als Resin (versie 1.2.b2). Hierbij merken we op dat de Resin server als voordeel ten opzichte van de JavaServer Web Development Kit heeft dat de Servlets automatisch gecompileerd worden, wat de ontwikkelingstijd aanzienlijk verlaagt. OPMERKING Merk op dat we voor de bovenste 3 lagen niet spreken over fysisch gedistribueerde lagen omdat ze zich alle 3 op dezelfde machine moeten bevinden. We hadden RMI of Sockets tussen de lagen kunnen inschakelen, maar aangezien het systeem slechts een prototype is, meenden we de beschikbare tijd beter te investeerden in het duurzame gedeelte: het model van de applicatielaag en het ontwerp van de databankschema s. Installatie van het model op een applicatieserver zou het systeem gedistribueerd maken. TESTS We hebben ons in onze tests vooral geconcentreerd op de cruciale delen van ons systeem. Een geheel van regression tests controleert of de beans uit de appicatielaag op een correcte manier naar de databank worden weggeschreven en eruit worden ingelezen. Bij een overgang naar een ander DBMS kan bovendien uit het al dan niet slagen van deze tests afgeleid worden of de nieuwe databank voldoet voor het systeem in zijn huidige vorm. De cruciale klasse Status testten we ook in een regression test door de State Diagram volgens Basis Path Testing onder de loupe te nemen. Deze techniek, die bekend is uit het testen van programmastructuren aan de hand van hun flow graph, garandeert dat elk gescheiden pad minimum één maal doorlopen wordt. De eerste versie van de Status klasse testten we strenger door de State Diagram uit te breiden met errorstates waar nodig. De laatste versie van de klasse Status valideerden we aanvullend met een aantal dynamische pagina s die de huidige configuratie van het systeem weergeven enerzijds qua toegangsrechten en anderzijds qua transitiefunctie van de State Diagram. Deze pagina s lieten ons toe de klant bij de validatie te betrekken. Eens we vertrouwd waren met het Junit Framework, pasten we het ook toe voor design by contract. Of onze interface voldoende gebruiksvriendelijk was, zijn we via enkele acceptance tests met de klant nagegaan. TIJDSCHEMA OPSTELLEN PLANNING (PLAN THE WORK) Bij het opstellen van de planning probeerden we zoveel mogelijk werk zo vroeg mogelijk in het jaar te plaatsen. Dit kwam simpelweg het beste uit met de spreiding van het studieprogramma in 1 ste licentie informatica. We waren ons er dan ook van bewust dat de tijd om de eerste delen van het systeem te voltooien vrij optimistisch geschat was. GEBRUIK PLANNING (WORK THE PLAN) Halverwege het 1 ste semester liepen we achter op schema. Aangezien we in het 2 de semester nog een grote bufferzone voorzien hadden, konden we probleemloos de planning aanpassen. Sindsdien hebben we ons vrij goed aan de planning kunnen houden. Bij het afronden van het 2 de semester plukten we de vruchten van deze aanvankelijk stresserende planning en konden we meer tijd aan andere tijdrovende vakken besteden.

5 5 PROBLEMEN Laat ons even terugkomen op de State Diagram en diens implementatie in de klasse Status. Deze heeft 2 problemen opgelost. 1. GROOTTE VAN HET PROJECT In eerste instantie bespaarde deze benadering ons enorm veel werk bij het implementeren. 2. WIJZIGINGEN IN DE BESLUITVORMING De grootste verdienste van het concept is echter dat het de impact van een wijziging in de besluitvorming, één van de grootste risicofactoren, sterk reduceert. In het begin van het 2 de semester, deed zich daadwerkelijk een dergelijke wijziging voor: bij een evaluatie van de State Diagram merkte de klant op dat de administratie haar werking wenste te verbeteren door de erkenningsprocedure uit te breiden. De uitbreiding omhelsde dat de minister alvorens een erkenning definitief af te keuren, zijn intentie tot verwerpen kon kenbaar maken aan het bevoegde gezag, zodat deze alsnog de kans had om de bezwaarpunten in orde te brengen. We dienden toen slechts 1 methode in de klasse Status aan te passen. De Acties Beslissing Nemen en Advies Toevoegen dienden op dat moment immers sowieso geïmplementeerd te worden, maar hadden in feite niet de minste wijziging moeten ondergaan. De laatste verdienste van het concept was dat we in overleg met de klant een bepaalde fase in de besluitvorming (namelijk het toezicht na een toegekende erkenning) toch hebben kunnen implementeren, hoewel we bij de afbakening van de projectscope overeengekomen waren dit deel te laten vallen.