Transfer Solutions
Alternatief op het CDM-RuleFrame Scriptie
Jeroen Eissens, Mark van de Haar, Henze Berkheij 19-1-2010
Hogeschool Utrecht Alternatief op het CDM-RuleFrame Versie: 2.0 Auteurs en opleidingen Jeroen Eissens – Information Engineering Mark van de Haar – Informatica Henze Berkheij – Informatica Faculteit Natuur en techniek Onderzoeksteam Groep 8 Datum van opleveren 19-01-2010 Begeleidende docent Leo Pruijt Klant Transfer Solutions Klant vertegenwoordiger Leo van der Meer
2
Voorwoord Deze scriptie is geschreven voor ter afsluiting van het onderzoek dat wij uitvoerde voor ons onderzoekssemester. Wij hebben dit onderzoekssemester gekozen in plaats van een minor als onderdeel voor ons derde schooljaar van de opleidingen I (Informatica) & IE (Information Engineering). Deze opleidingen worden gevolgd aan de faculteit Natuur & Techniek aan de Hogeschool Utrecht. Dit onderzoek is uitgevoerd voor Transfer Solutions en het Lectoraat van de Hogeschool Utrecht. Het onderzoek behandeld een alternatief op het huidige CDM-RuleFrame. Deze scriptie mag geraadpleegd worden door mensen die geïnteresseerd zijn in zo’n alternatief. Wij willen hier iedereen bedanken die ons heeft geadviseerd of gesteund tijdens ons onderzoekssemester. Omdat een onderzoekssemester een half jaar duurt zijn er ook veel mensen betrokken bij zo’n onderzoek en deze worden hieronder gespecificeerd en bedankt. Omdat wij een onderzoek deden waar meerdere partijen bij betrokken waren, hebben wij veel hulp gekregen vanuit het Lectoraat en vanuit Transfer Solutions zelf. Wij willen Leo Pruijt bedanken voor het advies en ondersteuning. Ook willen wij Leo van der Meer bedanken voor het vrijmaken van tijd wanneer wij vragen hadden en het ondersteunen van onze ideeën en deze te bekritiseren. Dhr. Leo van der Meer – Transfer Solutions - opdrachtgever Dhr. Leo Pruijt – Lectoraat - begeleider De onderstaande docenten hebben ons geholpen en wij willen deze mensen bedanken voor het vrijmaken van tijd om ons advies te geven. Dhr. Leo van Moergestel – Hogeschool Utrecht Dhr. Peter van Rooijen – Hogeschool Utrecht Drs. Esther Moet – Hogeschool Utrecht Dhr. Eric Gelofsma – Hogeschool Utrecht Dhr. Christian Köppe – Hogeschool Utrecht Jeroen Eissens Mark van der Haar Henze Berkheij
3
Management Samenvatting Het bedrijf Transfer Solutions is een dienstverlenend bedrijf dat gespecificeerd is in Oracle en Java Technologieën .Het bedrijf biedt cursussen aan op beide technologieën. Binnen ondernemingen gelden naast werk instructies (procedures) ook regels. Deze regels worden overgenomen in de automatisering van het bedrijf. Zulke regels worden ook wel bedrijfsregels genoemd. Een voorbeeld van een bedrijfsregel is; enkel particulieren die ouder zijn dan 16 jaar mogen zich registreren. De bedrijfsregel zorgt er dan voor dat bij het registreren en wijzigen van de particulier er een controle uitgevoerd wordt op de geboortedatum. Transfer Solutions maakt gebruik van een mechanisme waarbij het vastleggen en genereren van bedrijfsregels mogelijk is. Het genereren bestaat uit het ophalen van de vastgelegde gegevens vervolgens worden alle variabelen (zoals de bedrijfsregel specificatie) wordt ingevuld en weggeschreven naar een uitvoerbaar script. Deze generatie wordt gedaan door het CDM-RuleFrame. Dit mechanisme maakt gebruik van een tweetal ‘tools’ namelijk Headstart Utilities en Oracle Designer. Echter is er aangegeven dat er geen nieuwe versies meer worden uitgegeven. Er zal enkel nog ondersteuning aangeboden worden voor een korte periode. Transfer Solutions is op zoek naar een alternatief voor het CDM-RuleFrame. Het huidige product voldoet aan de functionele eisen, echter niet aan de niet functionele eisen. Namelijk dat er geen nieuwe versies meer gemaakt worden en er beperkte ondersteuning is. Hier zijn een aantal eisen bij gekomen namelijk Open Source, Leerbaarheid en Koppelbaarheid. Het plan bestaat uit een aantal stappen: 1. Onderzoeken of er al producten op de markt aangeboden worden en of deze voldoen aan de gestelde eisen. 2. Onderzoeken of er producten zijn waaruit delen herbruikbaar zijn. 3. Onderzoek welke moderne mechanismen van code generatie er zijn en welke buikbaar zouden kunnen zijn voor dit onderzoek. Ook is er onderzoek uitgevoerd naar de verschillende manieren om bedrijfsregel op te delen in categorieën. Het alternatief bestaat uit drie delen namelijk: JDeveloper, voor het vastleggen van het database diagram en de database gerelateerde bedrijfsregels. Oracle Apex, voor het vastleggen van de bedrijfsregels. Java Applet, voor het generen van de bedrijfsregels naar script. De applet is beschikbaar in een pagina binnen Apex, zodat er geen extra handelingen verricht hoeven te worden. De handleidingen voor de diverse producten zijn onder andere; prototype handleidingen en installatie handleidingen. Het prototype ondersteund de mogelijkheid om bedrijfsregels vast te leggen en te genereren. Er is dus een werkend prototype. Echter worden nog niet alle typen bedrijfsregels ondersteund. Dit omdat er bepaalde functionaliteit(en) benodigd zijn voor deze typen. Tevens is er ook een tekort aan tijd om alle typen in het prototype op te nemen. Om alle typen te laten werken is er transactie management nodig. Er zijn namelijk typen die over meerdere transacties (records) gaan. Nu kunnen deze regels niet gecontroleerd worden, dit is het bekende ‘tabel lock’ probleem. Voor de Autorisatie regels moet er nog een implementatie ontworpen worden. Deze bedrijfsregels worden ook niet in de huidige oplossing (CDM-RuleFrame) ondersteund, dit omdat deze bedrijfsregels te complex zijn voor enkel alle Oracle producten.
4
Inhoudsopgave Hogeschool Utrecht ................................................................................................................................. 2 Alternatief op het CDM-RuleFrame......................................................................................................... 2 Voorwoord .............................................................................................................................................. 3 Management Samenvatting .................................................................................................................... 4 1
Opdrachtgevers en de Probleemstelling ......................................................................................... 7 1.1
2
3
4
Transfer Solutions.................................................................................................................... 7
1.1.1
Onze plek binnen de opdrachtgevers.............................................................................. 8
1.1.2
Context ............................................................................................................................ 8
1.2
Probleem ................................................................................................................................. 9
1.3
Opdracht Transfer Solutions ................................................................................................... 9
Lectoraat........................................................................................................................................ 10 2.1
Het lectoraat.......................................................................................................................... 10
2.2
Opdracht Lectoraat ............................................................................................................... 10
Het Plan ......................................................................................................................................... 11 3.1
Het plan (eerste versie) ......................................................................................................... 11
3.2
De versmalling ....................................................................................................................... 11
3.3
Planning ................................................................................................................................. 12
3.4
Fasering binnen het onderzoek ............................................................................................. 12
3.5
Scope onderzoek ................................................................................................................... 13
3.6
Methoden en werkwijze........................................................................................................ 13
3.6.1
Project Management Methodiek .................................................................................. 13
3.6.2
Ontwikkelmethodiek ..................................................................................................... 14
Uitvoering ...................................................................................................................................... 15 4.1
Inceptie fase .......................................................................................................................... 15
4.2
Elaboratie fase ....................................................................................................................... 18
4.3
Constructie fase ..................................................................................................................... 23
4.4
Transitie fase ......................................................................................................................... 26
5
Resultaten...................................................................................................................................... 27
6
Evaluatie ........................................................................................................................................ 28 6.1
Evaluatie over het onderzoek semester ................................................................................ 28
6.2
Aanbevelingen ....................................................................................................................... 29
6.2.1
Oracle Apex ................................................................................................................... 29
6.2.2
Transactie management ................................................................................................ 30 5
7
6.2.3
Data dictionary .............................................................................................................. 30
6.2.4
Generator (Java Applet) aanbevelingen ........................................................................ 30
Zelf evaluatie ................................................................................................................................. 31 7.1
Jeroen Eissens........................................................................................................................ 31
7.2
Henze Berkheij....................................................................................................................... 33
7.3
Mark van de Haar .................................................................................................................. 36
8
Verklarende woordenlijst .............................................................................................................. 39
9
Literatuurlijst ................................................................................................................................. 40
10
Bijlagen ...................................................................................................................................... 41
6
1
Opdrachtgevers en de Probleemstelling
1.1 Transfer Solutions Het bedrijf Transfer Solutions, dat gelokaliseerd is in Leerdam, heeft zich gespecialiseerd in Oracle en Java omgevingen. Ze bieden hierop toegespitst verschillende diensten, namelijk [1]:
Consulting Managed Services Education
De verschillende diensten zullen kort toegelicht worden. Consulting “Uitvoering van complete ICT-projecten in Oracle- en JEE-technologie en advisering over het gebruik van ICT.”[1] Consulting bestaat bij Transfer Solutions uit twee gedeelten, enerzijds het adviseren, anderzijds het uitvoeren van een ICT project. Beide toegespitst op de Oracle en de Java technologieën. De ICT projecten kunnen bestaan uit verschillende technologieën en wensen van klanten. Als basis voor bedrijfsregel implementatie kan als oplossing het CDM-RuleFrame genomen worden, zodat de bedrijfsregels gecontroleerd en uitgevoerd worden op de database. Gezien de bedrijfsregels gecontroleerd en uitgevoegd worden op de database. De foutmeldingen van de database worden aangeboden in de doeltechnologie zodat de gebruiker te zien krijgt wat er fout heeft kunnen gaan. Een aantal ondersteunde technologieën door Transfer Solutions zijn: Oracle Forms Oracle Apex Java Enterprise Managed Services “Het beheer van Oracle-infrastructuren en applicaties van kleine tot zeer grote organisaties. Op afstand of op locatie.”[1] Het beheer van Oracle-infrastructuren en applicaties is een dienst dat Transfer Solutions aanbied. Deze dienst kan zowel op afstand als op locatie aangeboden worden. Aantal beheer mogelijkheden zijn: Oracle Databases Oracle Apex Oracle Forms Java Enterprise applicatie Education “Het uitvoeren van technische opleidingstrajecten, gericht op Oracle- en JEE-technologie. Zowel klassikaal als individueel begeleide opleidingen.”[1] Er worden een aantal cursussen aangeboden waarin Transfer een groot marktaandeel heeft of de enige hierin zijn. Een voorbeeld hiervan is het CDM-RuleFrame. Doordat de mensen uit de praktijk of 7
mensen met veel kennis de cursus verzorgen, kan men praktische uitleg geven waardoor de (complexe) situatie voor de cursist sneller gaat leven en daardoor beter te begrijpen is.
1.1.1 Onze plek binnen de opdrachtgevers Bij Transfer Solutions staan we bekend als onderzoeksteam dat onder Leo van der Meer valt, we hebben periodiek een vergadering met hem. We maken geen deel uit van zijn team. Binnen Transfer Solutions valt onze begeleider (Leo van der Meer) onder Managed Services, de beheerafdeling van Transfer Solutions. Hij wordt ook regelmatig ingehuurd door Education. Bij Managed Services is hij een afdelingsleider van een team dat onderhoud doet aan applicaties van verschillende klanten.
1.1.2 Context Een onderdeel van binnen Consulting (binnen Transfer Solutions) is het realiseren dan wel het beheren van systemen van klanten. Binnen een systeem gelden een of meerdere bedrijfsregels. Deze bedrijfsregels zijn specifieke bedrijfsregels die gelden binnen dat specifieke bedrijf. Dat betekend dat die bedrijfregels meestal niet overdraagbaar zijn. Wat zijn nu eigenlijk bedrijfsregels? Het geheel van voorschriften die in een bedrijf opgevolgd moeten volgen[10]. Een voorbeeld: enkel particulieren die ouder zijn dan 16 jaar mogen zich registreren. Hierbij wordt dan bij het registreren en wijzigen van de geboortedatum van de klant een controle uitgevoerd of de geboortedatum inderdaad hieraan voldoet. Het CDM-RuleFrame is een veelzijdig mechanisme. Het kan bedrijfsregels vastleggen en deze genereren op basis van de eerder vastgelegde informatie. De uitkomst van de generatie slag is een script dat uitgevoerd kan worden op de database. Zodra er een mutatie plaatsvindt gaat de eerder genoemde bedrijfsregel af en wordt de controle uitgevoerd. Als er een fout optreed wordt dit aan de hand van een foutmelding aan de eind gebruiker gemeld. Voordelen van CDM-RuleFrame: Om meerdere bedrijfsregels van het zelfde type te implementeren, treed er vaak herhaling op (zelfde stukken code). Dit heeft als nadeel dat er snel fouten gemaakt kunnen worden en het slecht onderhoudbaar is. Dit kan verholpen worden met generatie. De code die vaak herhaalt moet worden kan dan gegenereerd worden en de variabele stukken kunnen dan tijdens het genereren ingevuld worden. Het CDM-RuleFrame genereert al een hoop standaard bedrijfsregels op basis van het database schema (dit betekend dat het vastgelegde analyse model gelijk gebruikt kan worden voor diverse typen bedrijfsregels). Het CDM-RuleFrame genereert al een hoop standaard code voor een regel, de programmeur hoeft enkel de bedrijfsregel te specificeren. De onderhoudbaarheid van de bedrijfsregels op hoog niveau is. Dit is omdat de regel dan snel aangepast kan worden en eenvoudig opnieuw gegenereerd en geïmplementeerd kan worden.
8
1.2 Probleem Oracle heeft bekend gemaakt dat er geen nieuwe versies meer komen van Oracle Designer. Oracle zal alleen nog maar (voor een bepaalde tijd) ondersteuning bieden op dit product. Dit heeft als gevolg dat Transfer Solutions niet zeker is hoe lang deze oplossing nog een goede oplossing is. Het controleren van bedrijfsregels kan op verschillende niveaus in software. Dit kan namelijk op database niveau of direct aan de gebruikerskant, tevens is het mogelijk om op tussenliggende niveaus deze controle te laten plaatsvinden. Meer informatie hierover is terug te vinden binnen het hoofdstuk “uitvoering”. Het niveau waar de controle bij het CDM-RuleFrame plaatsvindt is op database niveau. Dit heeft als voordeel, dat elke applicatie (die gebruik maakt van die database) automatisch beschikt over de bedrijfsregels. Als er een bedrijfsregel aangepast moet worden hoeft dit maar eenmaal op een centrale locatie plaats te vinden. Het alternatief moet voldoen aan: Dat de controle op database niveau plaatsvindt. Dat het alternatief licentie vrij zijn. Dit omdat licenties grote kosten met zich meebrengen.
1.3 Opdracht Transfer Solutions De opdracht van Transfer Solutions zoals afgesproken met het Lectoraat: Business Rule Implementation Framework Probleem: Oracle biedt een Business Rule Framework (CDM-RuleFrame), maar dat dwingt het gebruik van Oracle Designer ic.m. Headstart af. Gezien de licentiekosten en de toekomstverwachting van Designer moet er voor het CDM-RuleFrame een alternatief komen. Dit alternatief zou gebruikt kunnen worden bij zowel de technologieën die direct op het datamodel aansluiten (Forms en ApEx) als bij MVC-technologieën (EJB, ADF). Doel: Ontwikkel een Business Rule implementatie framework. Vergelijkbaar met CDM-RuleFrame, maar dan als een Open Source implementatie. Organisatie: Transfer Solutions. Gewenst: Basiskennis van de Oracle database, Designer en PLSQL. Opleiding: Informatica, Information Engineering.
9
2 Lectoraat 2.1 Het lectoraat De Hogeschool Utrecht heeft kenniscentra waarin meerdere lectoraten actief zijn. Deze lectoraten zijn onderverdeeld in thema’s. Binnen deze thema’s worden onderzoeken behandeld die direct te maken hebben met zo’n thema. De personen die hier werken worden lectoren genoemd. Een lector is een persoon met kennis op een bepaald vakgebied (expert). Deze lector gebruikt zijn kennis en ervaring die hij/zij opdoet in tijdens verschillende onderzoeken binnen het onderwijs en beroepspraktijk. [5] Het lectoraat ontwikkelt praktisch toepasbare kennis door middel van een wisselwerking met de praktijk. Een voorbeeld: het onderzoek dat wij (studenten) uitvoeren voor Transfer Solutions
2.2 Opdracht Lectoraat Het Lectoraat geeft bij elk onderzoek een aantal kennisdoelen mee. Tijdens een onderzoek moeten deze doelen/vragen onderzocht worden en beantwoord worden. Deze kennis wordt dan opgenomen in het kenniscentrum. De kennisdoelen zoals ze meegegeven zijn:
Bestudeer OpenUP, wat software architectuur is conform OpenUP en pas dit toe. Stel, naast de standaard analyse en ontwerpproducten een SRS (Software Requirements Specification) en een SAD (Software Architecture Document) op. Verdiep je in business rules en de manieren om ze te implementeren. Onderzoek de manieren (architectuurstijlen) om ze te implementeren. Onderzoek welke producten er zijn op dit gebied. Ook open source! Onderzoek welke moderne mechanismen van code generatie er zijn en welke bruikbaar zouden kunnen zijn voor dit project. Onderzoek welke oplossingen hiervoor zijn.
De kennisdoelen worden behandeld in een apart document, genaamd Kennisvragen. De doelen zullen waar mogelijk ook in het scriptie behandeld worden. Niet als kennisvraag maar verweven in het onderwerp. Het kennisvragen document is bijgevoegd in de bijlagen.
10
3 Het Plan 3.1 Het plan (eerste versie) In de begin fase van het onderzoek is er een plan opgesteld. Dit bevatte onder andere; scope, afbakening en planning. Na een lange oriëntatie periode waarin onder andere verschillende ideeën waren over de inhoud van de fasen en de inhoud van de documenten is er meer richting de deadlines gewerkt. Omdat de oriëntatiefase te lang duurde is er door de begeleiders ingegrepen en heeft er een versmalling plaatsgevonden. In de versmalling zijn er een aantal keuzes gemaakt. Deze keuzes werden op dat moment nog onderzocht, maar dit zou te lang duren en een prototype in gevaar stellen. Dit was een van de doelen. Met een prototype kan er bewezen worden dat het uitgedachte concept daadwerkelijk kan werken. Deze versmalling is ten goede gekomen voor het onderzoek, gezien er te veel doelstellingen waren voor de beperkte tijd. Hier wordt op teruggekomen in de evaluatie.
3.2 De versmalling De versmalling zoals de opdracht is waarvan uit er gewerkt is (beknopt):
Gebruik JDeveloper voor het vastleggen van het Entiteiten Relatie Diagram (database schema van de klant). Tevens kunnen hier een beperkt aantal regels in worden vastgelegd Inventariseer welke typen regels er zijn en waarmee deze vastgelegd kunnen worden Stel een Functioneel Ontwerp op Stel een incrementenplan op Stel een technisch ontwerp op (Software Architecture Document) Bouwen en Testen van de incrementen Gebruikers en Systeem documentatie maken dan wel bijwerken
In de versmalling zijn een aantal technologische keuzes gemaakt, namelijk:
Oracle JDeveloper (vastleggen database schema) Oracle Apex (vastleggen van de bedrijfsregels) Architectuur van de applicatie
Voor het genereren van bedrijfsregels zijn er ook voorstellen gedaan. Hiervoor moest nog wel onderzoek voor verricht worden, wat binnen het tijdsbestek een goede keuze zou zijn. De versmalling is bijgevoegd als bijlage[9].
11
3.3 Planning Om een volledig beeld te geven over de eerder genoemde oriëntatie periode is die periode volledig inzichtbaar in onderstaande planningsoverzicht. De planning past niet op één bladzijde, vandaar dat deze meegeleverd wordt als bijlage. De planning bestaat uit taken en een zogenoemde stroken planning. De planning geeft een idee van de inhoud van het onderzoek.
Figuur 1 Planning - na versmalling - beknopt
In dit onderzoek hebben we een groot aantal producten opgeleverd. De kenmerkendste producten hiervan zijn een werkend prototype met bijbehorende handleidingen.
3.4 Fasering binnen het onderzoek De fasen die gebruikt zijn komen uit de systeem ontwikkelmethodiek Open Up (basis versie). Meer informatie over dit onderwerp in paragraaf “Ontwikkelmethodiek”. Bij elke fase zijn er een aantal kenmerken die centraal staan, deze worden per fase behandeld. In de Inceptie fase wordt: De vraag van de klant vastgelegd en een plan opgesteld. Dit resulteert in een Project Mandaat en Project Initiatie Document De wens van de klant vastgelegd. Dit resulteert in een Software Requirements Specification In de Elaboratie fase wordt: De wens van de klant omgezet naar een Functioneel Ontwerp De wens van de klant omgezet naar een Software Architectuur De ontwerpen omgezet naar een MoSCoW lijst1 In de Constructie fase staat ook bekend als de bouw fase. Hierin worden de ontwerpen gerealiseerd en de diverse testen (zowel met gebruiker als eigen testen) uitgevoerd. Dit om de kwaliteit van het systeem te kunnen waarborgen. In de Transitie fase wordt het onderzoek afgerond. Het product wordt dan gepresenteerd en opgeleverd.
1
In een MoSCoW lijst (incrementen plan) wordt functionaliteit ingedeeld in incrementen met een bepaalde prioriteit. De functionaliteiten die een hoge prioriteit krijgen, zijn essentieel voor het systeem. De functionaliteit die niet noodzakelijk is voor de werking van het systeem kan bij tegenslag achterwege gelaten worden.
12
Kort samengevat zijn de belangrijkste producten: In Inceptie fase; Project Mandaat, Plan van Aanpak (PID), Software Requirement Specification (SRS). In Elaboratie fase; Functioneel Ontwerp, Software Architectuur Document (SAD). In Constructie fase; Test rapporten, Handleidingen van prototype en het prototype zelf. In Transitie fase; Presenteren en opleveren van het product. Voor een volledig overzicht van de producten verwijzen we u door naar de bijlage het Project Initiatie Document, en dan specifiek de paragraaf Product Breakdown Structure.
3.5 Scope onderzoek We hebben twee opdrachten ontvangen en moeten hier dus een scope en afbakening voor opstellen. Dit is in zowel in Project Mandaat en Project Initiatie Document (Plan van Aanpak) gedaan. De scope: Wij moeten een alternatief voor het CDM-RuleFrame (wat momenteel gebruikt wordt) onderzoeken en realiseren. Dit alternatief moet gebruik maken van de volgende producten: JDeveloper, Oracle Apex en een genereer tool. We moeten uiteindelijk een oplossing opleveren die geen licentiekosten met zich meedraagt. Onze oplossing moet scripts kunnen genereren voor een Oracle database, echter moet er ook rekening gehouden worden met andere databases (MS SQL). Randvoorwaarden: Enkele randvoorwaarden in dit onderzoek zijn: Er mogen geen licentiekosten aan verbonden zijn Het product moet snel zijn (seconden werk) Toekomstverwachting Zowel de scope als de randvoorwaarden zijn een referentie naar het Project Initiatie Document [6].
3.6 Methoden en werkwijze Tijdens dit onderzoek maken wij gebruik van verschillende methoden. Deze methoden worden gebruikt voor het sturen van het onderzoek en de werkwijze waarop gewerkt wordt.
3.6.1 Project Management Methodiek Prince 2 We hebben voor het project management gedeelte Prince2 gekozen, voornamelijk de volgende documenten: Project Mandaat Project Initiatie Document Faseplan(nen) (verwerkt in PID) Voortgangsverslag en uren registratie en planning (per week). Dit is gebaseerd op de ontwikkel methodiek DSDM, en valt hiermee niet direct onder de prince2 methodiek. Prince2 heeft wel een soortgelijke manier van week evaluatie, namelijk een “end stage repport”.
13
3.6.2 Ontwikkelmethodiek Als ontwikkelmethodiek werd er als advies RUP opgegeven, we mochten hier een variant voor kiezen. Er werden twee keuzes opgenomen; Rup op maat en OpenUp. Gezien de niet functionele eis Open Source is willen we dat ook de ontwikkelmethodiek hieraan voldoet, zodat ons onderzoek hier beter op aansluit. We zijn gestart met OpenUp, dat bleek niet te functioneren en hebben we ervoor gekozen om alleen de onderdelen eruit te doen die voor ons van toepassing zijn. Naderhand is er besloten om OpenUp basis definitief aan te houden. OpenUp basis is voor kleinere ontwikkelteams (vier tot vijf leden) en sluit hiermee beter aan. Wel behandelen we alleen de onderdelen die voor ons onderzoek beter aansluit en sneller tot producten leiden.
14
4 Uitvoering Alle documenten die gemaakt zijn tijdens de uitvoering, zijn besproken met de belanghebbende. Dit om vroegtijdig feedback te krijgen. Dit maakt het voor ons mogelijk om vroegtijdig te anticiperen en bij te sturen. Dit geldt voor alle fasen.
4.1 Inceptie fase In de Inceptie fase moet de opdracht ingelezen worden. De kennis over het onderwerp op gehaald worden. Dit is gedaan door een les te volgen gegeven door de opdrachtgever (Transfer Solutions). Vervolgens zijn we begonnen met het project management vorm te geven, dit door middel van een Project Mandaat en een Project Initiatie Document (Plan van Aanpak). In het Project Mandaat wordt het project (achtergrond, doelstelling, scope voorwaarden dan wel beperkingen, de betrokken partijen en projectorganisatie) toegelicht. Dit is een weergave van de informatie die in de inceptie fase bekend is. Het Project Initiatie Document is het Plan van Aanpak dat bijgesteld wordt door de fases heen. Dit omdat er dynamische onderdelen in zitten zoals de planning. In het Project Initiatie Document staan een aantal belangrijke onderdelen, namelijk scope, afbakening, planning, kwaliteitscriteria et cetera. Het Software Requirements Specification (SRS) is een globale opzet om de op dat moment bekende wensen van de klant in op te slaan. Dit is volgens een aantal standaarden uitgevoerd namelijk UML en ISO Norm 91262. In het SRS vindt men een overzicht van alle taken die het systeem moet bevatten voor de programmeur (de gebruiker). Dit wordt ook wel een Use case diagram genoemd.
Figuur 2 - SRS - Use Case Diagram 2
Iso Norm 9126, hierin worden software kwaliteits attributen vastgelegd.
15
Vervolgens wordt er een beschrijving gemaakt van de taken, dit wordt ook wel Use case beschrijving genoemd. We behandelen hier de taak van het invoeren van bedrijfsregels. In de Inceptie fase worden de beschrijvingen nog niet volledig opgeleverd, enkel met wat er op dat moment bekend is. De Hoofd Scenario is dus nog niet bekend, dit wordt bekend in de volgende fase. Naam Doel Aanname Hoofd scenario
Excepties
Resultaat Gebruikte entiteiten Bedrijfsregel
Invoeren bedrijfsregels. Het vastleggen van bedrijfsregels in het systeem. De gebruiker heeft op de knop “Invoeren bedrijfsregels” gedrukt in het hoofdmenu. Gebruiker Actie Systeem Actie Nog niet van toepassing in deze fase. Excepties treden op als: Niet alle verplichte velden zijn ingevuld. De database niet beschikbaar is om de bedrijfsregel in op te slaan. Er geen rechten zijn, voor de opgegeven database. De naam van de bedrijfsregel niet uniek is. De bedrijfsregel is opgeslagen in de database. Bedrijfsregel, Categorie, Trigger, Tabel, Kolom. Alle velden zijn verplicht, en dienen volledig en correct ingevuld te zijn.
Zoals te zien is worden er een hoop onderdelen die in een systeem zitten hierin vastgelegd. Namelijk; de uitzonderingen waarin het goed moet gaan, het resultaat van de Use case, de gebruikte database tabellen en de eventuele regels die er gelden.
16
Het Software Architecture Document (SAD) is een globale opzet om de op dat moment bekende wens (met betrekking tot software architectuur) vast te leggen. Hier valt onder het database model3, tier model4, technologische keuzes en het deployment model5. Bij het onderdeel SAD per fase het ERD toegelicht. Dit om het niveau van het aantal wijzigingen die er door de fasen heen hebben plaats gevonden te kunnen laten zien. Onderstaande ERD is van de eerste versie SAD, namelijk de conceptversie van het ERD.
Figuur 3 SAD – Concept versie, 5 november 2009
De kennisdoelen die meegegeven zijn is een start mee gemaakt. We hebben getracht om waar mogelijk een literatuuronderzoek te doen6. Echter zijn er een aantal doelen waarbij dit niet mogelijk is. In deze fase is er enkel onderzoek gedaan en er zijn bronnen verzameld.
3
Database Schema (Entiteiten Relatie Diagram) is een representatie van de database bestaande uit tabellen, relaties en kolommen. 4 Tier model zijn een aantal ‘tieren’ (lagen) waarover de software verspreid kan worden. 5 Deployment Model is een model dat representeert hoe de software oplossing ‘uitgerold’ moet worden. 6 Literatuuronderzoek houdt in dat er onafhankelijke wetenschappelijke stukken gebruikt worden en hier een samenvatting van gemaakt wordt. Dat wat hier uit komt kan weer verder gebruikt worden.
17
4.2 Elaboratie fase Het Project Initiatie Document is uitbereid en bijgesteld naar de fase. Tevens zijn de planning, scope en afbakening veranderd mede door de versmalling. De onderzoekgegevens van het onderzoek naar de kennisdoelen zijn verzameld en er is een samenvatting van gemaakt (zie bijlage kennisvragen). Uit een aantal van deze doelen moest een beslissing uit voortkomen. Deze doelen waren namelijk verantwoordelijk voor keuzes, zoals bijvoorbeeld de te gebruiken code mechanisme. De wens van de klant is verder onderzocht en vastgelegd in het Software Requirements Specification. Dit is tevens ook de definitieve versie. Een beknopt overzicht van de wens van de klant: Identificator
Naam
Omschrijving
NFE-3
Koppelbaarheid
Het systeem koppelbaar is met andere systemen. Zodra de gegevens vastgelegd zijn, heb je de mogelijkheid om alles te genereren naar een Oracle database, dat het ook mogelijk is met aanpassingen voor andere databases. Een voorbeeld hierin is voor de MS SQL database server.
NFE-4
Gebruikersvriendelijkheid
Er moeten zo min mogelijk handelingen verricht worden om tot een resultaat te komen, in ieder geval minder dan het huidige systeem. Het systeem moet voorkomen dat er fouten gemaakt worden en het moet goede feedback geven als er iets niet in orde is.
NFE-5
Leerbaarheid
Het een snellere inwerktijd heeft als Designer in samenwerking met Headstart Utility (2 dagen).
NFE-6
Bedienbaarheid
Snelheid en gebruikersgemak voor de gebruikers. Hier zal zoveel mogelijk rekening mee gehouden worden.
NFE-8
Aanpasbaarheid
Het systeem is zeer platform onafhankelijk, dit maakt het mogelijk om het systeem ook te laten werken op andere hardware. Afhangende van het onderdeel van het systeem zal het van zeer gemakkelijk naar zeer arbeid intensief gaan. Gezien er voor de front end een applicatie server ingericht zal moeten worden.
NFE-9
Wijzigbaarheid
Het systeem zal niet geoptimaliseerd worden. Dit heeft als gevolg dat het gemakkelijk is om wijzigingen door te voeren.
NFE-11
Onderhoudbaarheid
Er wordt gebruik gemaakt van het MVC model. Dit model deelt de complexe oplossingen op in drie eenheden. Hierdoor wordt de applicatie overzichtelijker, makkelijker te lezen en wordt het herbruikbaar. Het MVC model wordt geïmplementeerd door Apex.
De wensen zijn gekoppeld aan de ISO standaard 9126, de namen zijn vertaald naar het Nederlands. Voor meer informatie hierover is te vinden in de bijlage, Software Requirements Specification.
18
De beschrijving zoals die is in de definitieve vorm, met hoofd scenario: Naam Doel Aanname Hoofd scenario
Invoeren van bedrijfsregels. Het vastleggen van bedrijfsregels in het systeem. De gebruiker heeft op de knop “Invoeren bedrijfsregels” gedrukt in het hoofdmenu. Gebruiker Actie Systeem Actie De gebruiker voert alle gegevens Het systeem controleert of alle over de bedrijfsregels in. En drukt verplichte velden ingevuld zijn en of op de knop ‘Verwerken’. de regel identificator uniek is. ‘Commit’ de bedrijfsregel(s) en Voert alle gegevens van de wordt opgeslagen in de database. bedrijfsregel door in het systeem Alle opgestelde bedrijfsregel(s) worden gecontroleerd. Het ID wordt doormiddel van automatische verhoging aangevraagd. Wijzigingen worden doorgevoerd in het systeem. Het systeem (javascript) maakt het systeem leeg. Draai alle wijzigingen terug.
Excepties
Resultaat Gebruikte entiteiten Bedrijfsregel
Maak het scherm leeg door op de knop ‘ Leegmaken’ te drukken. Draai alle wijzigingen terug. Excepties treden op als: Niet alle verplichte velden zijn ingevuld. De database niet beschikbaar is om de bedrijfsregel in op te slaan. Er geen rechten zijn, voor de opgegeven database. De naam van de bedrijfsregel niet uniek is. De bedrijfsregel is opgeslagen in de database. Bedrijfsregel, Categorie, Trigger, Tabel, Kolom. Alle velden zijn verplicht, en dienen volledig en correct ingevuld te zijn, met uitzondering van ‘fout melding’.
De Use cases zoals ze bekend zijn, zijn niet exact zo verwerkt in het alternatief. Het zoeken is een onderdeel dat gebruikt zou worden door de andere taken, dit is nu binnen de oplossing al verzorgt door het systeem zelf. Dit hoefde dus niet meer geïmplementeerd worden. Het invoeren van een bedrijfsregel is verwerkt in een wizard waarin de gegevens van een bedrijfsregel ingevuld worden, gekoppeld aan de juiste tabel(len) en kolom(men), vervolgens wordt de regel gedefinieerd (met pl-sql code). Het beheren van de bedrijfsregels geschiedt met dezelfde wizard, met het verschil dat er een overzicht beschikbaar is van de bedrijfsregels, waarin opgegeven moet worden welke bedrijfsregel bewerkt moet worden. Op stack zetten gebeurd door middel van een pagina waarin een bedrijfsregel geselecteerd kan worden en op stack (stapel) gezet kan worden, die vervolgens klaar staat om gegenereerd te worden. 19
Het genereren is een gescheiden taak binnen het systeem (Java Applet). Het Software Architecture Document is uitbereid aan de wens van de klant, naar aanleiding van de specificaties.
Figuur 4 - SAD - ERD Final 1.0
Het bovenstaande ERD is geplaatst om een idee te geven van de omvang. We hebben voor de volledigheid dit ERD ook bijgevoegd als bijlage, dit om eventuele belangrijke details niet te ontnemen. Voor elke type regel is er een aparte tabel, dit omdat elk type zijn specifieke gegevens heeft. Dit vindt u terug aan de bovenzijde en de rechterzijde. Het overige stuk is voor het registreren van de bedrijfsregel zelf met de eigenschappen van een bedrijfsregel. Er is een concept versie van het Testplan opgesteld voor het invoer gedeelte van het alternatief. Hierin zijn de testen beschreven hoe ze worden uitgevoerd en of ze worden uitgevoerd, een voorbeeld hiervan is de acceptatietest. Acceptatietest Onder acceptatie test wordt er verstaan dat de gebruiker(s) van het systeem zelf aan de slag gaan om de regels in te voeren en te genereren (van begint tot eind). Wij zullen de feedback van deze test verzamelen, doorbespreken en in overleg met de klant wordt bepaald wat de actie hierop is. De acceptatie test zal plaatsvinden na increment drie. Hierna is er ruimte om de feedback te werken en in overleg met de klant eventueel door te voeren. De handleiding van JDeveloper is geschreven om de gebruikers te ondersteunen bij het maken dan wel beheren van een database schema. De handleiding is specifiek geschreven voor het alternatief en behandeld enkel de onderwerpen die hieraan gerelateerd zijn.
20
Het Functioneel Ontwerp bevat een overzicht van alle typen en categorieën die er zijn binnen de categorisering. Ook is hierin aangegeven in welk increment deze types geïmplementeerd worden en met welke omgeving deze vastgelegd en gegenereerd moeten worden. Dit is tevens ook gelijk de definitieve versie. Een beknopt overzicht van de typen: Categorie
Non-DML change event
Beschrijving
Voorbeeld
Tool
Increment
Non DML change event rule (CEW)
Is een automatische DML actie welke wordt uitgevoerd na manipulatie. Wijzigt zelf geen data
Wanneer een einddatum van een project gewijzigd is, verstuur een email naar de betrokken personen
Alt
*
Other DML change event rule (CEV)
Is een automatische DML actie welke wordt uitgevoerd na manipulatie. Wijzigt zelf ook data
Wanneer de gegevens van een medewerkers zijn gewijzigd moet dit in een audit tabel toegevoegd worden
Alt
*
Simple default rule (NP)
De standaard waarde van een kolom
De maximum limiet van een nieuwe klant is standaard 1000
Alt
*
Attribute transition rule (TRS)
Beschrijft de wijziging van een waarde van een attribuut en is alleen te valideren bij een Update
Toegestane overgangen voor een getrouwd status Alleenstaand>getrouwd> Gescheiden/weduwe
Alt
*
Other update rule (UPD)
Kan alleen gevalideerd worden bij een Update
Wijzigingen op een levering anders dan de status zijn niet toegestaan als de status van de levering niet gelijk is aan REG
Alt
3
Is van toepassing op toegestane waarden
Het geslacht van een medewerker is mannelijk of vrouwelijk
Alt
1
Deze regel kan gevalideerd worden door alleen gebruik te maken van één attribuut in één rij van één entiteit
Bestaat onder andere uit: Range validator, Compare validator, Reguliere expressie
Alt
1
Simple attribute rule (NP)
Betreft Datatype, lengte decimaliteit en optionaliteit en uppercase
Postcode van een locatie moet in hoofdletters
JDev
J
Horizontal authorization rule (AUT)
Beperkt het gebruik van data
Een kok mag alleen zijn eigen diensten bekijken
Alt
*
Type
DML change event
Dynamic data constraint rules
Domain rule (NP)
Static data constraint rules
Authorization
Other attribute rule (ATT)
21
De beschrijving van een type ziet er als volgt uit: Simple Default rule (NP) De simple default rule kan opgelost worden in JDeveloper, echter is ervoor gekozen om in onze applicatie ondersteuning voor te gaan bieden, omdat een programmeur kan besluiten dat een standaardwaarde aangepast moet worden. De regel beschrijft een standaard waarde van een kolom. Categorie: DML Change Event. Voorbeelden - De standaard maximum limiet van een nieuwe klant is 1000 - Wanneer er niet is opgegeven of een maaltijd vegetarisch is, word er standaard “N” opgegeven Eigenschappen en Attributen - Categorie.Naam - Categorie.Omschrijving - Type.Naam - Type.Omschrijving - Bedrijfsregel.Naam - Bedrijfsregel.Omschrijving - Tabel.Naam - Kolom.Naam - Kolom.Standaard waarde (bevat een waarde die ingevuld moet worden als een kolom niet word ingevuld) - Triggermoment o Create o Update Beperkingen - De standaardwaarde is toegestaan in de datatype van de opgegeven kolom
22
4.3 Constructie fase Het ontwerpen is nu afgerond. Nu kan er begonnen worden met de implementatie. Het Software Architecture Document wordt afgerond en het laatste ERD wordt eraan toegevoegd. Dit document is in deze fase ook definitief.
Figuur 5 - SAD - ERD Final 9.0
Het invoeren van bedrijfsregels heeft een wijziging ondergaan. Deze wijziging heeft grote gevolgen voor het ERD. Er is aangegeven van de klant af om niet op detail niveau de regel geheel in te vullen maar het detail in te laten vullen door de programmeur. Dat betekend nu niet dat de eindwaarden vastgelegd moeten worden maar enkel de specifieke pl/sql code. Het Functioneel Ontwerp is bijgesteld voor deze fase, tevens zijn de validaties toegevoegd en het overzicht compleet gemaakt. Dit is ook het definitieve document.
23
Het Testplan is uitgebreid na de incrementen en is na het laatste increment tevens de definitieve versie. Van alle uitgevoerde tests (door het onderzoeksteam) worden testrapporten gemaakt. Dit is een verzameling van de testresultaten. Deze resultaten worden weer gebruikt om de verbeteringen voor dat increment te verwerken. Gebruikershandleiding van ons alternatief concept versie. Installatiehandleiding van ons alternatief, hier wordt een concept van opgesteld. De handleiding dekt zo wel de Apex applicatie als de generator. In de Constructie fase is er gewerkt aan de implementatie van het prototype. Voor Oracle Apex zijn er een aantal aanpassingen gedaan na het eerste increment. De gebruiksvriendelijkheid van de applicatie was niet van een goed niveau. Dit is opgelost door meer vanuit de gebruiker te denken. We hebben ervoor gekozen om een aantal stappen te maken waarin een bedrijfsregels vastgelegd wordt. Deze stappen worden doorlopen bij zowel het aanpassen als het invoeren van een bedrijfsregel. We hebben ervoor gekozen om geen beheer schermen te maken voor; categorie, type, triggermoment_set, hiervoor is gekozen omdat wij ervan uit zijn gegaan dat deze niet aangepast hoeven te worden, er zijn namelijk geen extra categorieën en triggermomenten. Vandaar dat hiervoor gekozen is. De generator is een Java Applet, dit zodat het programma zelf niet geïnstalleerd hoeft te worden op de cliëntmachine en geïntegreerd kan worden binnen Oracle Apex en werkt op diverse besturingssystemen. De generator maakt gebruik van certificaten. Hierdoor is het mogelijk om toegang te verkrijgen tot het cliëntsysteem, mits er toestemming gegeven is door de gebruiker. Dit wordt gedaan door middel van het accepteren van het certificaat. Zodra de gebruiker het certificaat accepteert, krijgt de Applet toegang op de user home voor het wegschrijven van het script. De generator is ontwikkelt volgens het MVC Model7. Ook is er gekozen om gebruik te maken van JApplet. Dit bied een hoop extra mogelijkheden (die nog niet gebruikt worden). Wegens tijdbestek is er gekozen om geen ‘database schil’ te gebruiken, zoals bijvoorbeeld JPA. De generator maakt gebruik van templates als code mechanisme. De template taal die gekozen is, is Stringtemplate. Dit vanwege de korte inwerktijd en voldoet aan de functionele eisen. Stringtemplate legt de verplichting op om variabelen binnen de template aan te geven met dollar tekens. Een voorbeeld: $kolom$ om de kolom waarde toe te kennen. Verdere toelichting over de generator op de volgende bladzijde. Het alternatief heeft geen transactie management, dat benodigd is voor bedrijfsregels die over meer dan een tabel gaan. Een transactie management kan er voor zorgen dat het mogelijk is om de bedrijfsregels te kunnen controleren en de foutmeldingen te verzamelen.
7
MVC Model, staat voor Model, View, Controller. Als dit correct geïmplementeerd wordt, leidt dit tot betere onderhoudbaarheid en scheiding van de code.
24
Figuur 6 - UML - Klassendiagram
De generator is gerealiseerd als een Applet (zoals al eerder verteld is). De applet is gemaakt als een JApplet, dit vanwege de mogelijke extra functionaliteit als bijvoorbeeld ‘glassPane’. Werking van de applet: 1. De Main wordt gestart (door het aanroepen van de applet en het accepteren van het certificaat) 2. Main instantieert het genereer scherm (GenView) 3. Main instantieert GenController 4. De applet laat nu een scherm zien met een knop (genereer bedrijfsregels) 5. Bij een action performed (druk op de knop genereer bedrijfsregels, wordt GenController aangeroepen 6. GenController instantieert de Database 7. GenController maakt verbinding met de Database 8. GenController vraagt aan Database of er bedrijfsregels op de stack staan. a. Als er bedrijfsregel op stack staan wordt er een nieuwe Bedrijfsregel aangemaakt, Database geinstantieerd en worden de bijbehorende gegevens opgehaald b. Bedrijfsregel haalt vervolgens het template (karkas) op c. Bedrijfsregel vult de variabelen binnen het template i. Als hierop fouten optreden, wordt er een mededeling aan de gebruiker gedaan dat er een fout opgetreden is, en blijft de regel op de stack staan ii. Als hierop geen fouten zijn wordt de bedrijfsregels van de stack af gehaald en wordt het gevulde template op het scherm geprint d. MyFileWriter wordt geinstantieerd e. MyFileWirter controleert het bestaan van de map “Alternatief - CDMRuleFrame” i. Als deze niet bestaat wordt deze aangemaakt f. MyFileWriter maakt een bestand aan binnen de map “Alternatief - CDMRuleFrame” met de naam script_<systeem tijd in milliseconden>.sql 25
g. MyFileWriter zet de gegenereerde bedrijfsregels in het eerder gecreerde bestand h. MyFileWriter saved het bestand op schijf 9. GenController geeft door of het maken van het script goed gegaan is 10. GenController geeft door hoe lang het geduurd heeft om die bedrijfsregel te genereren.
4.4 Transitie fase In de transitie fase wordt alles afgerond en opgeleverd. Een overzicht hiervan: Gebruikershandleiding CDM-RuleFrame Alternatief afronden Gebruikershandleiding JDeveloper afronden Installatiehandleiding CDM-RuleFrame Alternatief afronden Ook vindt in deze fase de acceptatie test met de klant plaats. Deze test zal bepalen of en welke aanpassingen er nog gedaan moeten worden voordat de klant het alternatief accepteert en het alternatief naar wens is. Echter mag er niet afgeweken worden van het ontwerp en de gestelde eisen.
26
5 Resultaten De behaalde resultaten van het onderzoek. Het belangrijkste resultaat wat behaald is met het onderzoek bestaat uit een werkend concept. We hebben namelijk een werkend prototype met daarin ondersteuning voor de volgende typen bedrijfsregels: Other Attribute Domain Rule Tevens ondersteund het prototype een aantal bedrijfsregel wel, maar is het template nog niet volledig. Dat template moeten nog verwerkt worden door Transfer Solutions. Het betreft de volgende typen: Other update rule Create rule Other delete rule Other entity rule Tuple rule Uppercase rule Simple Default rule Het prototype bestaat uit twee onderdelen: Invoeren van bedrijfsregel, door middel van Oracle Apex Generen van bedrijfsregels, door middel van de Java Applet Het prototype is zodanig ingericht dat de nog niet ondersteunde typen ook geïmplementeerd kunnen worden. Voor zowel het invoeren als het genereren van bedrijfsregels kan gebruik worden gemaakt van dezelfde database. Dit is tijdens het ontwikkelen van het prototype gescheiden gebeurd, dit omdat er geen toegang te verkrijgen is tot de Apex omgeving (wegens afscherming door http://apex.oracle.com).
27
6 Evaluatie Dit is een totaal evaluatie van het onderzoek als onderzoeksteam. Ook worden er op basis van de ervaring aanbevelingen gedaan.
6.1 Evaluatie over het onderzoek semester We hebben met zijn drieën een onderzoek gedaan om een alternatief te bedenken en realiseren op het CDM-RuleFrame. Dit onderzoek is gedaan voor Transfer Solutions. Wij hebben hier samengewerkt met mensen uit verschillende opleidingen twee leden zijn afkomstig van de opleiding Informatica en één is afkomstig van de opleiding Information Engineering. De verschillen in opleiding hebben voor een goede samenwerking gezorgd omdat we op specialiteiten konden verdelen. Natuurlijk hebben wij niet alleen maar aan onze beste punten gewerkt, maar ook aan onze slechte punten. Dit om ervoor te zorgen dat wij deze konden verbeteren. Wij zijn tot de conclusie gekomen dat de opdracht voor één semester in het begin te groot is. Er moest (te) veel onderzocht worden. De reden dat er zoveel onderzocht moet worden was omdat wij geen conclusies wilden trekken uit ervaring, maar wij wilden de conclusie trekken aan de hand van feiten, wat beste is voor ons onderzoek. Hier ging (te) veel tijd in zitten en daardoor zijn wij in de eerste fase het doel een beetje kwijt geraakt. De begeleiders (Leo Pruijt & Leo van der Meer) hebben toen een versmalling doorgevoerd. Deze versmalling zorgde ervoor dat de opdracht kleiner werd en er meer doelgericht gewerkt kon worden. Zo waren een aantal keuzes al gemaakt voor ons en dit heeft ons op het juiste pad gezet richting een prototype. De versmalling zorgde in het begin voor wat onenigheid in het onderzoekteam, want het idee ontstond dat wij nu niks meer te onderzoeken hadden. Na een lang weekend hebben wij besloten hard aan de slag te gaan en ons beste beentje voor te zetten om er zo voor te zorgen dat wij aan het eind van het semester ook daadwerkelijk een goed onderzoeksrapport en product kunnen opleveren. Tijdens de versmalling is er een voorstel gedaan om voor Oracle Apex te kiezen. Hier hadden wij in het begin geen bezwaar tegen, dit omdat er nog geen ervaring was met de ontwikkelomgeving. Naderhand is er gebleken, dat met de ontwikkelomgeving tegen problemen aangelopen is. Dit zijn de volgende punten: Door gebrek aan inwerkt tijd is er geen ervaring met de ontwikkelomgeving Veel acties vinden plaats op de achtergrond en hebben daar is er geen controle op Debug faciliteiten niet op niveau van waaraan gewend is De keuze om voor Apex te kiezen stond niet vast, maar wij hadden het idee (door de hele versmalling) dat deze keuze ook vast stond. Wij zouden achteraf gezien liever ergens anders voor gekozen hebben. Bijvoorbeeld een Java cliënt met de volgende technieken EJB, JSF, JAAS, JPA. Wel zijn wij tevreden met het eindresultaat dat wij hebben opgeleverd. Het heeft ons een hoop tijd gekost om dit voor elkaar te krijgen, maar in overleg met de begeleiders hebben wij steeds een verbeter slag opgeleverd en zijn de prototype en de generator een goede basis voor een goed programma.
28
Wij hebben naast het onderzoek ondersteunende lessen gehad. Deze lessen waren Statistiek en Logica. Wij vonden het jammer dat deze lessen niet aansloten bij ons onderzoek. Het was dan ook lastig om altijd gefocust te blijven tijdens een les. Naast deze lessen kregen wij ook gastcolleges. Deze gastcolleges waren gebaseerd op onderzoek ervaringen van uit de praktijk. Er waren twee gastcolleges die voor ons echt handig waren, maar deze kwamen helaas te laat en hierdoor hadden wij er niks meer aan tijdens ons onderzoek. De gastcolleges waren wel interessant ook al waren ze niet altijd even relevant voor ons onderzoek. Dit komt omdat je informatie krijgt vanuit de praktijk. Dit vormt een beeld van hoe een onderzoek in de praktijk nu echt uitgevoerd wordt. Informatie hieruit kan vergeleken worden met je eigen aanpak. Niet dat het altijd slim is om deze manieren met je eigen onderzoek te vergelijken, want het gaat tenslotte om verschillende bedrijven en verschillende onderzoeken. Zo worden pluspunten uit deze onderzoeken gebruikt indien mogelijk. Wij drieën zijn erg tevreden over de gekozen onderzoeksonderwerp. Het was een erg interessant onderwerp, omdat het vaak aanbod komt, maar meestal weet je niet precies hoe het gehanteerd moet worden. Ook wisten wij niet dat sommige bedrijfsregels bestonden en kenden wij het begrip bedrijfsregels niet aan het begin van dit onderzoek. Wij hebben een hoop geleerd over bedrijfsregels, onderzoek doen en werken met mensen uit verschillende opleidingen.
6.2 Aanbevelingen Tijdens ons onderzoek zijn er een aantal punten naar voren gekomen waar verbetering in mogelijk is. Deze verbeteringen zullen hierin besproken worden.
6.2.1 Oracle Apex Wij hebben Oracle Apex 3.2 gebruikt (meest recente versie op dat moment). Deze versie heeft een aantal beperkingen die in Oracle Apex 4.0 opgelost zijn Bestaande uit:
8
8
Verbeterde tabel formulieren: bevat declaratieve ondersteuning voor validatie en het bevat meerdere eenheid types.
Programmeren met meerdere personen - vereenvoudigt het managen van de applicatie ontwikkel processen, bevat eigenschappen als, to-do, bugs, mijlpalen
Gemoderniseerde applicatie bouwen - gebruikersvriendelijkheid verbeterd, bevat geïntegreerde applicatie zoekfunctie, adviseur, huidige actie , dashboards - highlighting en verbeterde administratie schermen
Declaratieve, staat voor niet procedurele taal.
29
6.2.2 Transactie management In onze huidige oplossingen kunnen bedrijfsregels die gebruik maken van een tweede tabel (relaties) niet gecontroleerd worden. Voorbeeld: Een order (bestelling) moet ten minste een order detail (bestel regel) hebben, om dit te controleren zijn er twee transacties nodig, ons controle mechanisme gaat af bij elke transactie, dat betekend dat de controle niet gedaan kan worden, omdat de controle pas kan plaatsvinden als eerst de twee transacties geweest zijn. De transacties bestaan uit: 1. Order aanmaken 2. Order detail (regel) aanmaken Na de eerste transactie kan dus nog niet gecontroleerd worden, omdat beide transacties uitgevoerd moet worden. Dit geldt voor een groot aantal situaties. Om deze regel wel te kunnen implementeren is er een transactie management nodig die eerst beide transacties uitvoert daarna de controle pas gedaan wordt.
6.2.3 Data dictionary Binnen Oracle Apex is er functionaliteit dat een weergave biedt van alle tabellen en kolommen binnen de database. In verband met het beheren van alle tabellen en kolommen van de klant database, zou het wenselijk zijn dat ook dit gegenereerd wordt. Hiermee kan een hoop arbeidsuren per project mee bespaard worden.
6.2.4 Generator (Java Applet) aanbevelingen De aanbevelingen die er zijn voor de Applet: Gebruik maken van een database wrapper bijvoorbeeld JPA. Gebruik maken van de JApplet glassPane. Dit is een laag die over de andere lagen komt te liggen. Op die laag kan je bijvoorbeeld de foutmeldingen representeren en hiermee een betere grafische vormgeving maken. Gebruik maken van zogeheten Policy files, dan hoeft de applet geen gebruik meer te maken van certificaten. Bedrijfsregel Management klasse opnemen, dit omdat de gencontroller klasse te veel verantwoordelijkheid heeft en dat gedelegeerd moet worden.
30
7 Zelf evaluatie Zelf evaluatie wordt per persoon geschreven, dit is een evaluatie over het gehele onderzoek en onderzoek semester. Elk lid schrijft zijn eigen evaluatie.
7.1 Jeroen Eissens Dit semester is een leerzaam semester geweest. Ik heb dit semester met twee studenten van de opleiding Informatica een onderzoek gedaan. Wij hebben hiervoor gekozen om alvast te kijken hoe het samenwerken tussen een Informaticus en een Information Engineer gaat. Ik ben tot de conclusie gekomen dat dit goed gaat als het voor beide partijen duidelijk is. Dit zorgt voor minder wrijving omdat niet alles herhaald hoeft te worden. Hier is ook rekening mee gehouden tijdens het verdelen van de taken. Zo is Henze bijvoorbeeld wat minder in het schrijven van documenten (op spelling controleren na dan) en ben ik wat minder in programmeren. Wel hebben wij beide aan onze slechte punten gewerkt om deze te verbeteren. Ik vind dat wij begin dit semester nogal slecht begonnen zijn. We waren de ene week heel goed bezig en de week erna ging dan heel slecht. Dit komt mede omdat de opdracht in het begin te groot was voor één semester. Hierdoor moest er te veel kleine aandachtspunten onderzocht worden, omdat deze wel van belang waren voor het grotere geheel. Er is toen een versmalling van de opdracht gekomen. Hierdoor konden wij ons meer richten op het uiteindelijke prototype en hadden wij zo een richter punt waar wij naar toe konden werken. Hierdoor zakte in het begin de moed er een beetje in bij ons, maar na een lang weekend zijn wij weer keihard aan de slag gegaan. Deze versmalling is ten goede gekomen van ons onderzoek. Nu kunnen wij een product laten zien naast alle documentatie. Wel hadden wij sommige dingen anders aangepakt, bijvoorbeeld het gebruik van Oracle Apex. Dit hadden wij graag vervangen door een andere programmeertaal. Wel zou het programmeren meer tijd kosten, maar wij hadden het idee dat wij hiermee een beter eindproduct konden opleveren. Ik ben erg tevreden met het resultaat en ben blij dat ik dit onderzoek gekozen heb. Dit onderzoek bood namelijk iets van beide opleidingen en dat maakt het ook leuk. Ook zorgt het ervoor dat je wat extra’s leert. Wij hebben in mijn ogen een goede basis opgeleverd (prototype) waarop een eventueel vervolg onderzoek verder zou kunnen gaan. Wij moeten voor een project en voor SLO (Studie Loopbaan Begeleiding) altijd een aantal competenties kiezen. Deze competenties kies je op basis van wat je tijdens een semester wil of denkt te kunnen verbeteren. Hieronder staan mijn gekozen competenties: A3. Toepassing. Kan relevante informatie verzamelen uit diverse bronnen. A9. Basiskwalificering voor management functies. Kan werk verdelen en delegeren binnen een project. B3. Ontwerpen. Ontwerpt een ICT-systeem op basis van een architectuurbeschrijving en specificaties, in samenhang met een analyse en binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. B4. Realiseren. Bouwt en implementeert een ICT-systeem op basis van een functioneel en technisch ontwerp en binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. Dit zijn de competenties waar ik aan gewerkt heb. De competentie A3. heb ik grotendeels behandeld tijdens het onderzoeken en uitwerken van de kennisvragen. Deze kennisvragen waren direct van toepassing op de onderzoeksvraag. Voor beide kennisvragen die ik behandeld heb moest ik informatie opzoeken uit verschillende bronnen. Het
31
resultaat hiervan kunt u terug zien in het document “Kennisvragen”. Hieronder staan de kennisvragen die ik behandeld heb: 1. Verdiep je in de business rules en de manieren om ze te categoriseren. 2. Onderzoek de manieren (architectuurstylen) om ze te implementeren. De competentie A9. Is terug gekomen tijdens het gehele semester. Ik was hiervoor projectleider. Wel is dit gebeurt in afspraak met de andere projectleden. Hierdoor zorg je ervoor dat iedereen akkoord gaat met de taken die deze persoon krijgt. Natuurlijk komt het ook voor dat iemand niet blij is met een taak, maar ik kan niet altijd iedereen tevreden houden. De competenties B3. & B4. Zijn behandeld met de gehele projectgroep. Iedereen heeft hier zijn steentje aan bijgedragen. Hiervoor is gekozen zodat iedereen overal in ieder geval wat vanaf weet en zodat iedereen aan zijn competentie kan werken. Voorbeelden hiervan zijn: Software Requirements Specification Software Architecture Document Functioneel Ontwerp Prototype Dit zijn de meest belangrijke documenten voor deze competenties.
32
7.2 Henze Berkheij Het afgelopen semester heb ik samen met Mark van de Haar (Informatica) en Jeroen Eissens (Information Engineering) samengewerkt aan een onderzoeksproject. Het bedrijf Transfer Solutions uit Leerdam had een vraag neergelegd bij het lectoraat. Het was de bedoeling om een alternatief te ontwerpen voor het huidige Oracle Designer en Headstart waarmee bedrijfsregels worden gegenereerd. Dit had te maken met het feit dat Oracle geen nieuwe versies meer zou uitbrengen en de ondersteuning in de toekomst gestopt zou kunnen worden. In het begin een zeer brede opdracht. Daarnaast kregen we elke week Statistieken van Peter van Rooijen en daar direct aansluitend gastsprekers van verschillende vakgebieden binnen de ICT. De lessen over statistiek waren niet bepaald interessant. Oké, handig voor later, maar toch. Ik probeerde toch steeds weer op te letten, maar kon het soms niet meer volgen waardoor ik de draad kwijt was en zo iets had van: “Laat maar”. Soms zelfs moest ik wel even bezig met iets voor het project zelf, omdat we soms ons eigen planning niet bij konden houden of omdat we tegen problemen aanliepen waardoor we minder tijd hadden voor andere onderdelen van het project. Dat deed ik niet bij de gastsprekers. Die waren vaak een stuk interessanter. Niet alle onderwerpen spraken mij aan, maar toch wel een aantal. Na een aantal weken zwoegen op de vele documenten die we moesten schrijven kregen Leo van der Meer van Transfer Solutions en Leo Pruijt het gevoel dat we meer op de documenten gericht waren dan op de doelstelling. Meningsverschillen op gebied van project methoden en zaken daarom heen zorgden voor enige spanning tussen ons groepje en Pruijt. Die periode voelde voor mij erg ongemakkelijk aan. Gelukkig ging het een tijdje daarna snel beter. Er is toen een projectversmalling gegeven waarbij veel punten al ingevuld waren. Aanvankelijk waren we het er niet mee eens. Wat we gedaan hadden was met één veeg van tafel. Protesteren had eigenlijk niet zoveel zin en dus zijn we verder gaan borduren op basis van het projectversmalling document. In de periode daarna is er veel werk verzet in een (zeer) korte periode. In een gesprek met Wiebe Wiersema wees ons op een tool die later een belangrijke rol zou gaan spelen in ons project; StringTemplate. In de projectversmalling stond namelijk dat de oplossing moest bestaan uit JDeveloper, een Oracle Apex applicatie en een generator tool. Mijn taak was om uit te zoeken welke generator tool het meest geschikt was voor ons project. Ik was direct te spreken over StringTemplate. Deze tool kan namelijk een template met gaten opvullen met waarden door middel van Java C# en Python. Simpel, en daar houd ik van. Daar de kennis van een connectie tussen Java en een Oracle database toch hoger lag dan tussen een andere taal en de genoemde database is uiteindelijk gekozen voor een Java oplossing in combinatie met StringTemplate. In het begin dachten we veel te groot. Dat had gevolgen voor het einde. We wilden elke bedrijfsregel een eigen invoerschermpje geven en elke net even iets anders laten genereren (ander template, andere invoerwaarden et cetera). Op het eind bleek duidelijk dat Leo van der Meer iets veel simpeler in gedachten had. Hij zou de expressie schrijven die de daadwerkelijke controle zou uitvoeren, en wij genereerden dan het template waarbij de we de expressie in een If/Else statement zetten. De Java Applicatie schrijven ging redelijk makkelijk en snel. In overleg is er gekozen voor het MVC model. En was dus bij iedere “Change of plan” in no time klaar met wijzigen. In het begin was het heel simpel om nieuwe ondersteuning toe te voegen voor nieuwe bedrijfsregels. Later, toen duidelijk was hoe Transfer Solutions te werk wilden gaan, had ik hem weer heel snel aangepast op de nieuwe situatie. Terwijl ik vroeger een rommelboeltje bij elkaar harkte, schrijf ik nu toch redelijk goed onderhoudbare programma’s. Mede dankzij school, maar ook dankzij Mark die daar zeer kritisch over kan zijn.
33
Oracle Application Express, is geen goed product, maar ook geen slecht product. Ik ben er in de laatste weken veel mee bezig geweest en had regelmatig botsingen met de logica van Apex. Ik wilde iets, en dan kon dat weer niet omdat er geen simpele functies voor handen waren waarmee dat zou moeten kunnen. Het kan ook liggen aan het feit dat mijn kennis begin dit project 0,0 was en nu nog steeds niet echt hoog is. Daarbij is het erg lastig om goede voorbeelden te vinden of het vinden van manieren door lukraak op steekwoorden te zoeken met wat je voor elkaar wil krijgen. Sommige dingen in Apex spreken mij wel aan, anderen weer niet. Bijvoorbeeld de benaming van verschillende onderdelen vind ik niet bepaald duidelijk. Nu heb ik hier zelf ook wel eens last van, want het blijkt wel dat het lastig is om een goede naam te verzinnen, maar Apex heeft een heel team van ontwikkelaars die benamingen kunnen verzinnen en ik moet het met twee andere teamleden doen waarbij één minder kaas heeft gegeten van programmeren. Gelukkig maakt hem dat geen minder waardig teamlid want hij was de projectleider en ook heeft hij veel werk verzet in Apex. Documentatie is het meest verschrikkelijke onderdeel in een project vind ik, maar zal toch moeten gebeuren. Daarbij kwam ook nog eens het scriptie. Hierop veel goede kritiek gehad waar we wat mee konden. Leo Pruijt is wat dat betreft een goede begeleider. We waren het in het begin vaak niet met hem eens. Dit schrijf ik toe aan het feit dat we waarschijnlijk in het begin het verkeerd aanpakten. En dus eigenlijk geen schot in zat. Ik heb in het begin dan ook minder uren gedraaid dan later in het project. Op een gegeven moment lag ik rond de 10 uur achter op Mark en Jeroen. Die heb ik later in het project ruimschoots ingehaald met het programmeren van de generator en ontwikkeling van de Apex applicatie. Toch zou ik de volgende keer toch wat meer aandacht moeten besteden aan de documentatie, daar heb ik nog niet echt veel kaas van gegeten. Met Mark werk ik al samen sinds het MBO, dus weten we af en toe hoe we kunnen zijn. Dat kan handig zijn maar soms ook niet. Kleine meningsverschillen waar hij zich soms flink kan over opwinden met hem ben ik dus wel gewend. Maar verder gewoon iemand die weet wat hij moet doen als het gaat om documentatie. Jeroen kende ik eigenlijk alleen van af en toe tegenkomen in de trein wanneer Mark en ik weer eens op weg waren naar school. Met hem als projectleider had ik eigenlijk geen problemen. Het project was voor mij een echter project dan zo’n project gebaseerd op een vak. Niet alleen omdat er ook iemand bij zat die Information Engineering doet, maar ook omdat het bijvoorbeeld een opdracht was waarbij een heus bedrijf bij betrokken was. Geen simulaties meer maar “The Real Deal”. Competenties Voor dit project heb ik 4 competenties gekozen. A4. Transfer en brede inzetbaarheid. Kan kennis, inzichten en vaardigheden overdragen aan ICTprofessionals en aan andere professionals binnen een organisatie. In dit project heb ik kennisvragen moeten maken. Een kennisvraag van mij was het uitzoeken van een generatortool waarmee we de bedrijfsregels zouden kunnen genereren. Hier kwamen een aantal producten uit die iets dergelijks konden, maar er kwam er een uit waar ik dus over te spreken was: StringTemplate. Ook heb ik toen de anderen uitgelegd hoe het werkte. Later, toen ik de generator gebouwd had, had ik voor Leo Pruijt de technische kant van het programma uitgelegd (MVC-Model, hoe heb ik de link gelegd naar de database, Hoe gebruik ik in dit verhaal StringTemplate). Voor dat laatste heb ik even voor een (onzichtbare) spiegel geoefend. Tijdens dat oefenen kwam ik dan vaak ook nog veel schoonheidsfoutjes of andere zaken die niet klopten tegen. Het uitleggen ging aardig goed. Zolang ik weet en snap wat ik wil vertellen, lukt het mij dus om een goed verhaal te vertellen. Belangrijk is voor mij dus van te voren regelmatig even oefenen.
34
A8. Kan een verslag of rapport opstellen conform de richtlijnen. Ik was verantwoordelijk voor het Software Architecture Document. Dit ging veel lastiger dan gedacht. Ook door gebrek aan tijd heb ik delen overgelaten aan Mark. Verder heb ik regelmatig gezamenlijk met de anderen de verschillende documenten doorgelopen en gecontroleerd. Ook heb ik in het begin een aantal keer het weekverslag samengesteld. Zelf vind ik dat nog niet genoeg met de documenten ben bezig geweest en wil ik in volgende projecten daar toch weer proberen meer aandacht aan te besteden. B3. Ontwerpen. Ontwerpt een ICT-systeem op basis van een architectuurbeschrijving en specificaties, in samenhang met een analyse en binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. Ik heb op basis van het Software Architecture Document en het Software Requirements Specification het Functioneel Ontwerp opgesteld. Best een lastig document met al die verschillende soorten bedrijfsregels. De fundering waarop het Functioneel Ontwerp op gebaseerd was niet goed afgestemd, waardoor het Functioneel Ontwerp eigenlijk ook niet helemaal goed was. Dit document is later nog regelmatig aangepast omdat er dingen niet meer klopten volgens de visie op het te bouwen systeem en moet nu dus aardig kloppen. B4. Realiseren. Bouwt en implementeert een ICT-systeem op basis van een functioneel en technisch ontwerp en binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. Ik heb de generator tool gebouwd. Ook heb ik in Apex de huidige wizard in elkaar gezet. Doordat de visie op het te bouwen systeem telkens niet goed was hebben we drie incrementen lang iets gebouwd dat niet goed was. We begrepen daardoor wel steeds meer iets over die verschillende soorten bedrijfsregels naar mijn gevoel.
35
7.3 Mark van de Haar Om mijn reflectie te behandelen wil ik proberen chronologisch door het onderzoek heen te lopen en bij elke fase een ‘reflectie’ te geven. Zoals er eerder aangegeven is, heeft onze ‘oriëntatie’ periode langer geduurd door diverse factoren. Dit bestaat uit veel leer momenten mede daardoor ben ik achteraf blij dat alles ook op die manier gelopen is. In de eerste weken wordt er gestart met inlezen en een plan opstellen. Hierin is het diverse malen voorgekomen dat er andere ideeën waren over de invulling van de fase of het document. Zoals misschien bekend is, is een lid van een andere opleiding (IE), dat lid heeft veel met Prince2 gewerkt. Daarmee wilde ik als informatica student graag ervaring mee opdoen. Dit is in overleg ook gelijk ingevoerd. We zijn in het begin veel praktijkervaring gaan gebruiken, door al vroeg met schermontwerpen te komen. Dit om het idee bespreekbaar te maken zodat het ook tastbaar is, enkel volgens de fasering waren wij daar nog niet aan toe. Zo werd ook het idee gewekt, dat we al verder waren dan dat we daadwerkelijk waren (bleek achteraf). Dit had als gevolg, dat het nog vrij lang duurde voordat we met een concreet product konden komen. We waren namelijk bezig met diverse onderzoeken, zo ook voor de kennisvragen die we mee gekregen hebben. Dit zijn volgens mijn de belangrijkste oorzaken, van de lange duur (en dus de versmalling): 1. Dat er te veel onderzocht werd, we wilden niet keuzes maken op basis van onze kennis. We wilden gegrond kunnen aantonen dat, die keuze de beste keuze voor ons onderzoek waren en nog steeds zijn 2. De verschillende ideeën over de fase en over inhoud van bijvoorbeeld het PID 3. Te grote scope of te weinig afbakening dan wel aannamen gedaan waren Dit heeft geleid tot de versmalling zoals die opgesteld is door de begeleiders. Zij kijken met een ander beeld naar het onderzoek en konden inzien dat we te lang bezig waren met de eerste fase. Zij zagen in, dat als we op die manier verder zouden gegaan zijn, geen tijd hadden om een prototype te realiseren. Wat ook de juiste beslissing was en nog steeds is. De versmalling was meer concreet. We hebben vervolgens de opdrachten van de versmalling afgewerkt (als het opstellen van een FO, SRS, SAD, JDeveloper handleiding et cetera). Zodra de Elaboratie fase afgerond was konden we beginnen met realiseren van het prototype. De taal keuze die gemaakt was voor de applet betrof Java en de Ontwikkelomgeving voor de invoer betrof Oracle Apex. Op dat moment leek dat inderdaad wel een verstandige keuze, want met Oracle Apex zou er een hoge productiviteit moeten zijn met maken van functionaliteit. Dit klopt ook deels, als er nog geen kennis is kost het veel tijd om de functionaliteit gebruikersvriendelijk op te leveren. Terugkijkend op de bouw fase zie ik twee resultaten. Een, het snelle opleveren van de Generator met de gestelde wensen van de klant. En Oracle Apex waar erg veel tijd in gezeten heeft, wat erg zonde is. Want die tijd was niet inzetbaar voor bijvoorbeeld meer bedrijfsregels implementeren. Mijn idee hierover is waar mogelijk geen nieuwe technologieën inzetten als er geen tijd is om hier kennis over op te doen. We zijn namelijk gelijk begonnen met realiseren wegens de krappe tijdsbestek. Een beter alternatief (ipv Oracle Apex) is bijvoorbeeld Oracle ADF en JSF te gebruiken, of geheel zelf implementeren (MVC Model met JAAS, EJB, JSF). Voordelen, het team kent de techniek. Je heb alles zelf in de hand. Bij Oracle Apex gebeurd een groot deel achter de schermen en is niet gemakkelijk in te zien en maakt het ontwikkelen lastig. 36
De samenwerking onderling; de samenwerking verliep soms wat roestig, ook door de verschillende opleidingen en de verschillende ideeën. Het duurde soms even voordat we op een lijn zaten. Hoe verder het vorderde werd het steeds duidelijker wie waar goed in is, hier werd ook gebruik van gemaakt. Ook de bespreking van de documenten verliep steeds beter. Ben zeer tevreden over het verloop van de samenwerking en zijn geen enkel ‘probleem’ tegen gekomen. Het theorie gedeelte van het onderzoeksemester We hebben een zeer diverse theorie gedeelte gehad binnen het onderzoeksemester. Echter was er geen onderdeel dat aansloot op ons onderzoek. Dat is toch erg jammer, vind ik persoonlijk. Dat is zeker een gemiste kans en naar mijn idee waren er wel gegadigden die een gast college hadden willen geven op dit onderwerp. De theorielessen van Logica en Statistiek hebben we binnen ons onderzoek niets aan gehad. We hadden namelijk een heel ander type onderzoek en konden dit dus niet toepassen. Mochten we het nodig hebben later op school of bij het bedrijf, weten we er het een en ander van en weten we waar we moeten zijn voor meer informatie. De gastcolleges die er waren, waren ook zeer divers van niveau en onderwerp. Een gastcollege sprong er echt uit, namelijk over database load van docent van de vrije universiteit in Amsterdam. De college werd ook gegeven in het Engels, dat is toch een hele aparte ervaring en leuk om mee gemaakt te hebben. De gastcollege over onderzoek en literatuuronderzoek, kwamen erg laat. Deze vonden plaats in het tweede deel. Hier hadden we veel aan gehad kunnen hebben voor het onderzoek, maar deze thema’s kwamen helaas te laat aan bod. De volgende Competenties heb ik gekozen om aan te werken: A1. Brede professionalisering. Kan (recente wetenschappelijke) kennis en inzichten toepassen in verschillende beroepssituaties. A4. Transfer en brede inzetbaarheid. Kan kennis, inzichten en vaardigheden overdragen aan ICTprofessionals en aan andere professionals binnen een organisatie. B3. Ontwerpen. Ontwerpt een ICT-systeem op basis van een architectuurbeschrijving en specificaties, in samenhang met een analyse en binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. B4. Realiseren. Bouwt en implementeert een ICT-systeem op basis van een functioneel en technisch ontwerp en binnen de gestelde kaders voor kwaliteit, testen, beveiliging, doorlooptijd, budget en exploitatie en beheer. Toelichting per competentie: A1; De onderzoeken die ik gedaan heb waren gericht op: 1. Codemechanismen en generatoren (zoals Drools van Jboss) 2. Tier modellen Het tier model was al besloten in de versmalling, namelijk een twee tieren model. Heb voornamelijk onderzoek gedaan naar complete producten (vastleggen en generen) de meest opvallende resultaat hieruit was Drools, maar voldeed niet aan de wens. Welke producten ik verder onderzocht heb zijn niet geïmplementeerd. Wel de type producten die ik onderzocht heb. A4; Tijdens de implementatie fase en er iets daarvoor, had ik de gelegenheid om kennis op te doen van Apex, deze kennis heb ik overgedragen aan Jeroen tijdens realisatie van increment een. Vervolgens is 37
het zelfde plaatsgevonden bij Henze. Henze had concept generator uitgezet en die hebben we samen voortgezet. Erg leuk om op die manier kennis te delen en te verkrijgen. B3 en B4; Onze implementatie voldoet aan bijvoorbeeld de wens van de klant (specificatie) en de uitgezette Architectuur. Onze implementatie is diverse testen ondergaan (die ook gepland waren). Hier hebben we dus veel aan gedaan en is dus ook zeker behaald. We hebben ook waar mogelijk onze ontwerpen volledig gevolgd. De schermontwerpen en de use cases zijn niet gevolgd. Dit is gebeurd in overleg met de klant.
38
8 Verklarende woordenlijst In de verklarende woordenlijst worden moeilijke woorden en begrippen toegelicht. SQL staat voor Structured Query Language, dit is een taal die gebruikt wordt om de database mee aan te spreken. PL/SQL staat voor Procedurele Structured Query Language, dit is een taal die wordt gebruikt om procedures op de database af te laten handelen. (Database) Triggers is een procedurele code dat automatisch uitgevoerd wordt bij een bepaalde actie of gebeurtenis. Dit kan plaatsvinden op; tabel, view of database niveau. SRS staat voor Software Requirements Specification, dit document beschrijft de wens van de klant aan de hand van een aantal standaarden ISO Norm (niet functionele eisen) en UML. FO staat voor Functioneel Ontwerp, dit document beschrijft het ontwerp. Hierin staan de typen en categorieën waarin een bedrijfsregel kan vallen. SAD staat voor Software Architecture Document, dit document beschrijft de software architectuur. Hierin staat onder andere het ERD, uitrol model en andere software architectuur gerelateerde documenten. ERD staat voor Entiteiten Relatie Diagram, dit diagram is een representatie van de database schema. Dit bevat onder andere de tabellen, sleutels en de relaties. UML staat voor Unified Modelling Language, het is een modelleringstaal. Dit maakt het mogelijk om gewenste functionaliteit vast te leggen en bespreekbaar te maken. Use case diagram, dit is een overzicht van de taken die de gebruiker(s) met het systeem moeten kunnen. Ook kan je hierin zien of er taken van elkaar afhankelijk zijn of gebruik maken van elkaar. Use case beschrijving, dit is een beschrijving van de taak die de gebruik met het systeem moet uitvoeren. ISO Norm, zijn vastgelegde standaarden die door iedereen erkent worden.
39
9 Literatuurlijst 1. Diensten aangeboden door Transfer Solutions . 28 november 2009. http://transfersolutions.nl/index.php?option=com_content&task=section&id=16&Itemid=157&mpar ent=157 2. Koppelaars, Toon. RuleGen. RuleGen Framework. 28 november 2009. http://www.rulegen.com 3. Pruijt, Leo. Lesmateriaal JDSA2 Les 5Layered Architecture. 1 december 2009. www.sharepoint.hu.nl 4. Pruijt, Leo. Lesmateriaal JDSA2 Les 4RUP and Architecture. 1 december 2009. www.sharepoint.hu.nl 5. Kenniscentrum Hogeschool Utrecht. 4 januari 2010. http://www.natuurentechniek.hu.nl/Lectoraten.aspx 6. Scope van ons onderzoek. Project Initiatie Document Final 4.0. 11 januari 2010. 7. Categorie indeling van bedrijfsregels met bijbehorende ontwerp. Functioneel Ontwerp Final 2.0. 11 januari 2010. 8. Software Architectuur Document Final 1.0. 11 januari 2010. 9. Versmalling van het onderzoek. Onderzoek Versmalling. 11 januari 2010. 10. Definitie van het begrip bedrijfsregels. http://www.encyclo.nl/begrip/bedrijfsregels 18 januari 2010.
40
10 Bijlagen De bijlagen worden digitaal meegeleverd. De bijlagen bestaan uit de volgende documenten: Project Mandaat Project Initiatie Document (Plan van Aanpak) Planning CDM Onderzoek Onderzoek Versmalling Functioneel Ontwerp Software Architecture Document Entiteiten Relatie Diagram (diverse versies) System Requirements Specifications Kennisvragen Issue list Handleidingen o Gebruikershandleiding JDeveloper o Gebruikershandleiding Alternatief CDM RuleFrame o Installatiehandleiding Alternatief CDM RuleFrame
41
