Factureringsproces - TU Delft

IN3405 - Bachelorproject

Factureringsproces

Hidde Boomsma1174371

Elger Lambert1154273

18 juli 2008

Technische Universiteit DelftFaculteit EWI

Technische Informatica

Examen CommissieYom Schutte

Arjen SchwarzBernard Sodoyer

Hans-Gerhard Gross

3

Voorwoord

Studenten die Technische Informatica aan de Technische Universiteit Delftstuderen moeten ter afronding van hun Bachelor zelfstandig een opdracht vooreen extern bedrijf of organisatie uitvoeren.

Dit document bevat een verslag van ons Bachelor-eindproject. De opdrachtis uitgevoerd bij het bedrijf Hostnet in Amsterdam in een periode van tienweken tussen april en juni 2008. Wij willen graag Yom Schutte en ArjenSchwarz hartelijk danken voor hun begeleiding binnen het bedrijf. Ook BernardSodoyer en Hans-Gerhard Gross van de Technische Universiteit Delft zijn wijzeer dankbaar voor hun begeleiding voor het gehele project.

Amsterdam, juni 2008

Elger Lambert en Hidde Boomsma

5

Samenvatting

De opdracht bestond uit het koppelen van het factureringsproces aan eennieuwe productenindeling. Alle andere interne applicaties maakten al gebruikvan de nieuwe structuur.

Om uniformiteit, platformonafhankelijkheid en onderhoudbaarheid te bew-erkstelligen hebben we er voor gekozen het factureringsproces opnieuw te on-twerpen en implementeren. We hebben het in dezelfde taal geprogrammeerd alsde andere applicaties binnen Hostnet, het bestaande proces was geschreven ineen andere taal.

Voor het verkrijgen van de requirements hebben we voornamelijk gebruikge-maakt van interviews met medewerkers binnen Hostnet. Dit was ook de enigemogelijkheid omdat er nauwelijks technische informatie over het oude syteembeschikbaar was.

Alle requirements hebben we ingedeeld volgens de MoSCoW methode. Wehebben uiteindelijk alle Musts en Shoulds kunnen verwezenlijken.

Om het ontwerp duidelijk te presenteren naar Hostnet hebben we gekozenom hun stijl te gebruiken en de processen in flowcharts weer te geven. Voordatwe aan de implementatie begonnen, hebben we ook nog klassen en volgordedi-agrammen en een dataflow-diagram gemaakt.

De implementatie zelf verliep redelijk voorspoedig. Wel hebben we ongeveerveertig procent van deze tijd gebruikt voor het vergelijken van de uitvoer vanhet nieuwe en oude systeem.

We kunnen concluderen dat we in korte tijd veel werk hebben verzet. Deextra motivatie die we kregen doordat het eindresultaat van onze opdracht daad-werkelijk in gebruik genomen gaat worden en de vriendelijke medewerkers vanHostnet heeft hier zeker bij geholpen.

Inhoudsopgave

1 Inleiding 9

2 Probleemstelling en analyse 112.1 Vooronderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Functionele requirements factureringsproces . . . . . . . . 122.3.2 Kortingen correct verwerken . . . . . . . . . . . . . . . . . 132.3.3 Opmaak van de Factuur . . . . . . . . . . . . . . . . . . . 132.3.4 Niet-functionele eis . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Werkomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1 Voorgenomen planning . . . . . . . . . . . . . . . . . . . . 162.5.2 Werkelijke planning . . . . . . . . . . . . . . . . . . . . . 17

2.6 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Ontwerp 193.1 Gobaal ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Contracten ophalen . . . . . . . . . . . . . . . . . . . . . 193.1.2 Factuur aanmaken . . . . . . . . . . . . . . . . . . . . . . 203.1.3 Factuurregels . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.4 Factuuropmaak . . . . . . . . . . . . . . . . . . . . . . . . 203.1.5 Facturen versturen . . . . . . . . . . . . . . . . . . . . . . 213.1.6 Contracten aanpassen . . . . . . . . . . . . . . . . . . . . 213.1.7 Renewal run . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.8 Kortingen . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Gedetailleerd ontwerp . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Implementatie 234.1 Problemen en de oplossingen . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Unit-tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.2 Implementeren losse functies . . . . . . . . . . . . . . . . 254.1.3 Regressie testen . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Integration en Operational testing . . . . . . . . . . . . . . . . . 274.2.1 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . 27

7

8 INHOUDSOPGAVE

5 Evaluatie 295.1 Behaalde resultaat . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Tijdsplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4 Opdracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.5 Kennis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.6 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Aanbevelingen 336.1 Korting koppelen aan basisproducten . . . . . . . . . . . . . . . . 336.2 Contractendatabases synchroniseren . . . . . . . . . . . . . . . . 336.3 Samenvoegen van alle Contractendatabases . . . . . . . . . . . . 336.4 Laatste functionaliteit van het oude systeem herontwerpen . . . . 34

7 Bijlagen 377.1 Bijlagen A: Plan van Aanpak . . . . . . . . . . . . . . . . . . . . 387.2 Bijlagen B: Onderzoeksverslag . . . . . . . . . . . . . . . . . . . 427.3 Bijlagen C: Flowcharts . . . . . . . . . . . . . . . . . . . . . . . 517.4 Bijlagen D: Entity-relationship Diagram . . . . . . . . . . . . . . 617.5 Bijlagen E: Klassendiagram . . . . . . . . . . . . . . . . . . . . . 627.6 Bijlagen F: Volgorde diagram . . . . . . . . . . . . . . . . . . . . 637.7 Bijlagen G: Notulen flowcharts-presentatie . . . . . . . . . . . . 657.8 Bijlagen H: Notulen kortingen vergadering . . . . . . . . . . . . 677.9 Bijlagen I: Managing Hierarchical Data in MySQL . . . . . . . . 69

Hoofdstuk 1

Inleiding

Hostnet biedt alle benodigdheden voor het hosten van een website aan; vandomeinnamen en webhosting tot dedicated servers. Zo’n tien jaar geleden toenHostnet begon, werden de klanten- en productgegevens opgeslagen in excel-sheets. Sindsdien is het bedrijf, de hoeveelheid klanten en producten, flinkgegroeid. De excel-sheets zijn vervangen door datastructuren en er werd eensysteem ontwikkeld binnen Microsoft Access om administratie te assisteren.Dit systeem, geschreven met procedurele code, is over de jaren uitgebreid enaangepast om met het bedrijf mee te groeien. Hierdoor is de code moeilijk tebegrijpen, waardoor de betrouwbaarheid en onderhoudbaarheid van het helesysteem gedaald is.

Tegenwoordig ontwikkelt Hostnet haar software met een object-georienteerdetaal binnen een framework met genormaliseerde databases. Hostnet is echternog steeds afhankelijk van de oude processen waarvan niet meer goed begrepenwordt hoe ze werken. In 2006 is er besloten dat de structuur van de producten-database uitgebreid moest worden. Inmiddels is dit gebeurd, echter weten deoude processen de nieuwe functionaliteiten niet te benutten. Het voornaamsteprobleem is dat er geen facturen automatisch gegenereerd kunnen worden voorde nieuwe producten. Het huidige systeem moet dus herontworpen worden. Ermoet zowel rekening gehouden worden met het systeem als met de werknemersen er mag geen functionaliteit verloren gaan, gezien het bedrijf hier afhankelijkvan is.

Veel meer dan dit was ons niet bekend toen wij bij Hostnet begonnen.Gedurende het gehele ontwikkelproces hebben we ons laten begeleiden door hetV-model [11] om gestructureerd te achterhalen wat er precies van ons gevraagdwerd, dit vervolgens te realiseren en het hele ontwikkelproces goed te testen.

In Figuur 1.1 is het V-model te zien. Het ontwikkelproces verloopt vanlinksboven naar beneden en dan terug omhoog langs de rechterzijde van de ’V’.De requirements-analyse wordt behandeld in hoofdstuk 2, Probleemstelling enAnalyse. Zowel high level design als detailed specifications komen aan de ordein hoofdstuk 3, ontwerp. Hoofdstuk 4, implementatie, komt overeen met coding.In dit hoofdstuk word ook testing besproken. We eindigen met een evaluatie,conclusie en aanbevelingen.

9

10 HOOFDSTUK 1. INLEIDING

Figuur 1.1: Het V-Model

Hoofdstuk 2

Probleemstelling en analyse

In dit hoofdstuk zullen we onze probleemstelling en de aan ons vereiste re-quirements presenteren. Ook zullen we de omgeving waarbinnen we het projecthebben ontwikkeld omschrijven en onze planning laten zien.

2.1 Vooronderzoek

Voordat we konden beginnen met het ontwerpen van een nieuw systeem, moesthet duidelijk zijn wat er van ons gevraagd werd, wat onze opties waren om ditte realiseren, of dit haalbaar was binnen de beschikbare tijd en wat de eventuelekosten zouden zijn. Moet er een heel nieuw systeem ontwikkeld worden of is hetmogelijk het huidige systeem verder aan te passen en uit te breiden zodat hetvoldoet aan de eisen? Wat zijn de voordelen die gerealiseerd kunnen worden?

De eerste twee weken hebben we de tijd genomen om onderzoek te plegen omde kennis op te doen om deze vragen te kunnen beantwoorden. Voor een verslagvan deze periode verwijzen we naar bijlage B. Hierin is uitgebreid te lezen wat deoverwegingen zijn geweest. We hebben onderzocht wat de invloed zou zijn voorde gebruikers van het systeem, zoals de interface, platformonafhankelijkheid, debegrijpbaarheid en uitbreidbaarheid van de code. Wat de implicaties voor onszelf zouden zijn, zoals het wel of niet gebruik kunnen maken van ondersteunendesoftware en de hoeveelheid werk. Ook hebben we rekening gehouden met hethuidige systeem, uniformiteit, limitaties en welke voordelen het nieuwe systeemzou kunnen bieden. Hier wordt enkel de gekozen richting verder uitgewerkt.Deze richting is bepaald tijdens een vergadering met onze opdrachtgever enbegeleiders waar wij de verschillende mogelijkheden en onze aanbeveling hebbengepresenteerd.

We hebben aanbevolen het facturatieproces volledig te herontwerpen. Hi-erbij konden wij garantie geven van een robuust en goed getest systeem. Ookgaf het ons de vrijheid om zelf te beslissen welke programmeertaal we willengebruiken. Hostnet is akkoord gegaan met onze aanbeveling. Onze probleem-stelling was hiermee concreet gemaakt.

11

12 HOOFDSTUK 2. PROBLEEMSTELLING EN ANALYSE

2.2 Probleemstelling

Aan ons is gevraagd om een volledig nieuw systeem te ontwerpen en imple-menteren. Het is een herontwerp van het bestaande facturatie proces. Hetverschil is dat de gegevens uit de nieuwe productenstructuur gehaald moetenworden en de begrijpbaarheid van het systeem significant moet verbeteren. Allefunctionaliteiten die in het huidige systeem zitten, moeten ook in het nieuwesysteem aanwezig zijn. De facturen voor klanten van Hostnet moeten vrijwelhetzelfde blijven.

2.3 Requirements

In deze paragraaf presenteren we de aan ons gestelde eisen. Deze eisen hebbenwij aan de hand van ons onderzoek en interviews opgesteld. Met behulp van dezeinterviews hebben wij proberen te achterhalen wat de functionaliteit van hethuidige facturatieproces is. Ons systeem zou deze functionaliteit op zijn minstmoeten evenaren. Ook als er wensen aan het licht kwamen tijdens vergaderingenwerden deze door ons genoteerd. We hebben de eisen prioriteiten gegeven metde hulp van MoSCoW. Hierbij staat de M voor Must, de S voor Should en deC voor Could. De prioriteit gaat van hoog, lager, laagst. Deze lijst hebben wevervolgens geverifieerd met onze begeleiders.

2.3.1 Functionele requirements factureringsproces

M Factureringsproces moet de nieuwe productenstructuur benutten.

M Geen functionaliteit verloren gaan ten opzichten van huidige systeem.

M Contracten die status ’verwijdert’ hebben, mogen niet gefactureerd wor-den.

S Rekening houden met verschillende betalingswijzen.

M Rekening houden met buitenlandse klanten. Deze facturen moeten pere-mail verstuurd worden.

S Rekening houden met de verschillende btw-percentages voor klanten bin-nen en buiten de EU en bedrijven met een btw-nummer.

M Contracten die verlopen zijn moeten automatisch verlengd worden.

C Verlengde contracten moeten pas verstuurd worden als de einddatumdaadwerkelijk verstreken is.

C Het verlengen van contracten moet een paar keer per maand uitgevoerdkunnen worden.

S Wenselijk zou zijn als het systeem in een keer zowel alle nieuwe als peri-odieke facturen kan aanmaken.

S Ook wenselijk is als zowel producten met als zonder logingegevens tegeli-jkertijd gefactureerd kunnen worden.

2.3. REQUIREMENTS 13

C Als de klant niet op tijd betaalt, moet er automatisch opnieuw een factuurgestuurd worden.

C Factuuropmaak makkelijker kunnen aanpassen.

C Factuur per post of per e-mail versturen aan de hand van de voorkeur vande klant.

C Zichtbaar maken voor administratie hoe een factuur is ontvangen, per e-mail, of per post.

S Facturen die meer dan een pagina lang zijn apart versturen naar DMDR.

C Herinnerings facturen mogen de originele niet overschrijven.

2.3.2 Kortingen correct verwerken

M Er mag nooit een creditfactuur verstuurd worden door het systeem.

C Creditfacturen opvangen en doorsturen naar administratie ter controle.

C Handmatig gemaakte creditfacturen moeten wel geaccepteerd worden.

S Naast periodieke korting moet het ook mogelijk zijn om een eenmaligekorting op een periodiek bedrag te plaatsen.

S Het moet mogelijk zijn om absolute dan wel procentuele kortingen tegeven.

M Korting op Contract-, Product- en Klantniveau.

S Korting op Soortniveau.

M Korting op Contractniveau sluit andere kortingen uit.

M Anders hoogste korting andere niveaus.

S Combinatie van een eenmalige korting en een periodieke korting alleenmogelijk als deze kortingen allebei van hetzelfde niveau zijn.

2.3.3 Opmaak van de Factuur

S Overeenkomen met huidige factuur.

C Engelse facturen voor buitenlandse klanten.

C Meerdere talen voor verschillende buitenlandse klanten.


2.3.4 Niet-functionele eis

M Bij het eindproduct is het van belang dat het duidelijk is hoe de kortingengeımplementeerd zijn, zodat zowel administratie, sales en de program-meurs begrijpen waarom welke korting op de factuur komt te staan.

M Minimaal 200 facturen per 15 minuten verwerken.

M Binnen de beschikbare geheugenlimiet van 1 gigabyte blijven.

M Het systeem moet op laag niveau goed begrijpbaar zijn. Van belang is dathet in de toekomst goed onderhouden en eventueel aangepast kan worden.

2.4 Werkomgeving

Nu het duidelijk is wat er gedaan moet worden, is de volgende stap beslissenhoe we dit gaan doen. Welke hardware en software is er tot onze beschikkingen is dit geschikt voor onze probleemstelling?

Hostnet had twee werkplekken naast elkaar beschikbaar gemaakt op de Ap-plication Managment (AM) afdeling. We bevonden ons dus te midden van deandere programmeurs binnen Hostnet. Hierdoor konden we, als we vragen had-den, snel de antwoorden krijgen. Beide computers draaiden Linux, Ubuntu. Wewaren allebei vertrouwd genoeg met Linux dat dit geen probleem voor ons was.

Het oude factureringsproces is geschreven binnen een Access-applicatie datbinnen Hostnet bekendstaat als Hostbase. Het merendeel van de applicaties zijnechter geschreven in PHP5 binnen een framework genaamd Symfony. PHP5 iseen objectgeorienteerde taal zonder types en met veel standaard functies. Hetis een veel gebruikte taal voor webapplicaties en bovendien gratis beschikbaarvoor commercieel gebruik. Een goede handleiding en voorbeelden zijn te vindenop www.php.net. PHP draait als module in de veel gebruikte Apache Web-server. Ook is er een document beschikbaar genaamd coden bij hostnet.odt,hierin wordt duidelijk uitgelegd wat de vereisten zijn om te voldoen aan decodestyle van Hostnet. Hierin zijn ook alle constructies en veel voorkomendecodeblokken uitgewerkt. [5, 6]

Symfony is een framework voor PHP5 en is ontwikkeld door het Franse Sen-siolabs. Het framework biedt een splitsing in Model, View en Control. Hiernaastbevat het ook ondersteuning voor zowel unit- als functionele tests. In het modelgedeelte van de MVC-structuur zit de object-relationeel mapping en de databaseabstractie. In de View-laag komt alle opmaak op basis van templates. In dezelaag zijn ook veel hulpfuncties te vinden die het leven gemakkelijker maken enveel voorkomende taken wat betreft opmaak en Javascript, maar ook Ajax tevereenvoudigen. Symfony wordt onder andere gebruikt door Askeet en YahooBookmarks. [2, 9]

Met oog op de vereiste om de begrijpbaarheid van ons systeem te max-imaliseren was het een voor de hand liggende keuze om ons systeem ook inPHP5 binnen het Symfony-framework te ontwikkelen. Hiermee versterken wede uniformiteit en ontwikkelde we ons systeem in een, voor Hostnet en haarwerknemers, vertrouwde omgeving. Nog een voordeel is dat we ons systeemmakkelijker kunnen integreren en zelfs waar mogelijk bestaande code kunnengebruiken.

2.4. WERKOMGEVING 15

Omdat Hidde al een jaar parttime voor Hostnet werkte, was hij ook zeervertrouwd om software binnen deze omgeving te ontwikkelen. Gedurende onzestudie op de TU Delft werken en leren we echter vooral omgaan met Java, eenobject georienteerde taal net als PHP5. Met deze kennis en Hidde’s ervaringwas het mogelijk de nog ontbrekende basiskennis snel over te dragen aan Elger,waardoor we relatief weinig tijd nodig hebben gehad om de benodigde kennisop te doen.

De database maakt gebruik van MySQL4. MySQL4 is een relationeel databasemanagement systeem (DBMS). MySQL is vrij verkrijgbaar onder de GPL-licentie. MySQL is vanuit PHP gemakkelijk te benaderen door de library dieal jaren wordt meegeleverd met PHP. Ook is er in Symfony ondersteuning voorMySQL. Mocht de database, of data in de database, aangepast moeten wordendan is dit mogenlijk via PHPMyAdmin. Dankzij de kennis opgedaan tijdensonze studie zijn we bekend met MySQL-databases en is het voor ons geen prob-leem om hiermee te werken.

Alles wat we produceren, wordt in een subversion repository opgeslagen.Subversion (SVN) [8] is een versiebeheersysteem afgeleid van concurrent versionssystem (CVS) [1]. Alle bestanden worden centraal op een server opgeslagen.Eenieder kan wijzigingen doorvoeren. Als er gelijktijdig gewijzigd wordt, wordende twee documenten automatisch samengevoegd. Mocht een sectie tegelijkertijdzijn bewerkt, treedt er een conflict op en is handmatig ingrijpen vereist. Doorhet gebruik van subversion hebben we altijd een back-up en kunnen we ookterugbladeren naar eerdere versies als er toch iets overboord is gezet wat laternuttig blijkt.

Hostnet ontwikkelt al jaren haar eigen software voor intern gebruik. Aan-passingen maken en nieuwe applicaties integreren met het bestaande systeemgebeurt regelmatig. Om dit elke keer met zo min mogelijk problemen te doenverlopen, is hier het volgende voor verzonnen. Het daadwerkelijke systeem waarHostnet afhankelijk van is, draait op de productieserver. Daarnaast is er ookeen acceptatie- en een ontwikkelserver waar aangepaste versies van het systeem,dat op de productieserver draait, op draaien. De namen van de servers sprekeneigenlijk al voor zich. Elke programmeur binnen Hostnet heeft een eigen serverwaar een kopie van de ontwikkelserver op draait. Op deze manier is het mogelijkdat alle programmeurs onafhankelijk van elkaar software ontwikkelen. Met be-hulp van SVN kunnen aanpassingen en toevoegingen aangebracht worden opde ontwikkelserver zodat deze dan weer beschikbaar zijn voor anderen. Alseen hele applicatie ontwikkeld is, kan deze overgeplaatst worden naar de accep-tatieserver. Deze server dient om te testen of er problemen gaan ontstaan alsde huidige versie van de applicatie daadwerkelijk in gebruik wordt genomen.Omdat er zoveel verschillende mensen invloed hebben op de ontwikkelserver ishet mogelijk iets over het hoofd te zien bij het overzetten.

Voor het schrijven van lange stukken code wordt gebruikgemaakt van Eclipse.Voor kleine aanpassingen gebruiken we Vim [10]. Een bekende tekst-editor inLinux. Hiermee is het mogelijk om snel de gevolgen van aanpassingen te zienzonder tussenkomst van versiebeheer.

Alle documenten voor Hostnet moeten beschikbaar zijn in OpenOffice-formaat.Een groot deel van de verslagen zullen wij schrijven in Latex. Latex is eenopmaaktaal die bestanden in platte tekst opslaat. Ook kunnen documentengemakkelijk gesplitst worden en is er een goed systeem om referenties bij tehouden. De editor die we hierbij gebruiken is Kile (KDE Integrated Latex Edi-


tor). Aangezien de documenten uit platte tekst bestaat, kunnen ze gemakkelijkin een versiebeheer, zoals SVN, worden opgenomen en is gelijktijdig bewerkenmogelijk. [3, 7]

Voor de gemakkelijke stroomdiagrammen is OpenOffice toereikend, maarvoor het maken van echte UML-diagrammen is het toch wenselijk een pro-gramma te hebben dat meer functionaliteit biedt. Umbrello is hiervoor beschik-baar. Een simpel programma voor Ubuntu. Umbrello bevat niet erg veel mogeli-jkheden, maar ruim voldoende voor het maken van de basisdiagrammen. Um-brello kan ook exporteren naar PHP5-code. Het maken van UML-diagrammenis geen vereiste van Hostnet, maar deze hebben we gemaakt om onszelf te as-sisteren.

2.5 Planning

Het allereerste wat we deden, nog voor het onderzoek was, een Plan van Aanpakschrijven. Het volledige document is te zien in bijlage A. Deel hiervan was hetvastleggen van een planning.

2.5.1 Voorgenomen planning

Het ontwikkelproces hebben we globaal verdeeld in drie onderdelen, onderzoek,ontwerp en implementatie. Daarbij hadden we ook een planning gemaakt voorhet eind verslag.

Onderzoek

Een orienterende fase, zowel wennen aan onze nieuwe werkomgeving als infor-matie verwerven waren van belang. Deze informatie zal ons assisteren in hetmaken van ontwerp beslissingen, .

Ontwerp

Nadat er voldoende onderzoek gedaan is, kunnen we met die kennis een ontwerpmaken.

Implementatie

Met het ontwerp in handen kunnen de functies, gespecificeerd in de ontwerp-documenten, daadwerkelijk geschreven worden.

Eindverslag

Het schrijven van korte stukjes voor het eindverslag gedurende het ontwikkel-proces scheelt een hoop tijd en stress aan het einde. Om die reden hebben wegepland elke vrijdagmiddag aan het eindverslag te werken.

Zie Figuur 2.1 voor onze planning. Ook hebben we aangegeven welke wekenwij bij Hostnet aanwezig zullen zijn.

2.6. SAMENVATTING 17

Figuur 2.1: Grafische overzicht van de planning

2.5.2 Werkelijke planning

Het werkelijke gebruik van tijd verschilde niet erg veel van de geplande hoeveel-heid tijd. Ook de data waarop we bepaalde aspecten af wouden hebben, kwamredelijk overeen. Wat wel een flinke strop was, is dat Hostnet getroffen werddoor een grote storing waardoor Hidde bijna een week is kwijtgeraakt aan hetoplossen van andere problemen.

Doordat Hidde al bij Hostnet werkte, was de eerste stap om informatiete verzamelen en ons te orienteren eigenlijk veel korter dan de twee geplandeweken. Dit heeft ons later weer ruimte opgeleverd in de planning waardoor wedeze grotendeels gehaald hebben.

Later bleek ook dat het zo mooi op schema blijven ten koste was gegaan vande tijd waarin we het eindverslag zouden schrijven. Dit heeft dus achteraf ookmeer tijd gekost dan gepland.

2.6 Samenvatting

In de eerste twee weken orienteerden we ons op de opdracht en verzameldewe voldoende kennis om deze opdracht aan te kunnen. Vervolgens is er tijdingeroosterd voor de requirements, ontwerp, implementatietests, implementatiecode en acceptance testing.

De planning is hier en daar verstoord maar uiteindelijk hebben we ons ertoch grotendeels aan kunnen houden. Met name omdat we door de al aanwezigekennis erg snel op gang konden komen.

Hoofdstuk 3

Ontwerp

Nu het duidelijk is wat de vereisten zijn, kunnen we een ontwerp maken die dezeeisen vervult. We zullen laten zien welke componenten het systeem bevat en derelaties ertussen beschrijven.

3.1 Gobaal ontwerp

Een belangrijke gebruiker van het facturatieproces is administratie. Om diereden vonden wij het belangrijk hen te betrekken bij het ontwerpproces. Daarzij geen programmeurs zijn, hebben wij ons ontwerp met behulp van flowchartsgepresenteerd, zodat het ook voor hen duidelijk is. Deze flowcharts zijn tevinden in bijlage C. Ook hebben we een entity-relationship diagram (ERD) [4]geconstrueerd om inzicht te krijgen waar in de databases de relevante data staat(Bijlage D).

Een groot voordeel vergeleken met het oude proces is dat we het nu in eenobjectgeorienteerde taal, in plaats van een procedurele taal schrijven. Dit geeftons de mogelijkheid verschillende componenten duidelijke, zowel op hoog alslaag niveau, te onderscheiden. In de flowchart is te zien dat we vijf verschil-lende componenten onderscheiden, tevens wordt er ook al aangegeven waar dedata vandaan moet komen. De flowcharts laten zien welke acties en beslissingener per onderdeel genomen worden. De vijf componenten van het facturatiepro-ces die we onderscheiden zijn: contracten ophalen, factuur aanmaken, factuurregels, factuur opmaak, facturen versturen. Daarnaast is er nog een los procesgenaamd de renewal run, we zullen deze en elk component van het facturatiepro-ces apart beschrijven. Omdat het bepalen welke kortingen er op de factuurmoeten komen staan redelijk complex is, zal deze, ook al maakt het deel uit vanhet factuurregel-component, apart uitgelegd worden.

3.1.1 Contracten ophalen

Elk contract heeft een begin-, een eind- en een factuurdatum. Bij het makenvan een nieuw contract wordt er geen datum ingevuld voor de eind- en factu-urdatum. Hieraan zijn nieuwe contracten makkelijk te herkennen, deze moetenmeegenomen worden voor facturatie. Deze data worden door het facturatiepro-ces ingevuld, hierover straks meer (zie 3.1.6 Contract aanpassen). De andere

19

20 HOOFDSTUK 3. ONTWERP

contracten die ook meegenomen moeten worden voor facturatie zijn contractenwaarbij de factuurdatum overeenkomt met de huidige datum en deze kleineris dan de einddatum. Dit zijn contracten die periodiek gefactureerd wordenen waarvan een periode net verstreken is. Op het moment dat de einddatumverstreken is, moet dit contract uiteraard niet gefactureerd worden. Hetzelfdegeldt voor als de begindatum nog niet geweest is. Alle contracten die opgehaaldzijn voor facturatie, worden per persoon bij elkaar verzameld.

3.1.2 Factuur aanmaken

Het is de bedoeling dat als een klant meerdere contracten heeft die op dezelfdedag worden gefactureerd dat deze allemaal op een factuur komen te staan. Hetis natuurlijk niet de bedoeling dat een klant een aparte factuur opgestuurd krijgtvoor elke domeinnaam die hij op een dag heeft geregistreerd bijvoorbeeld. Hierwordt dus gecontroleerd of er al een factuur aanwezig is voor een klant, als dithet geval is moet het contract er aan toegevoegd worden, anders moet er eennieuwe factuur gemaakt worden.

3.1.3 Factuurregels

Met factuurregels wordt bedoeld: de tekst die aangeeft welk product er isgekocht, van wanneer tot wanneer het contract loopt en wat het kost. Ookde kortingsregels worden hier aangemaakt. Voor de overzichtelijkheid is ditproces losgekoppeld van de rest van de factuuropmaak. Het is van groot belangdat dit proces zonder fouten verloopt. Mocht dit wel gebeuren dan krijgt deklant een factuur opgestuurd met verkeerde bedragen of zelfs voor verkeerdeproducten.Er word gecontroleerd of dit de eerste factuur is, mocht dit zo zijn en er zijneenmalige kosten en of kortingen aan het contract verbonden, wordt voor elkeen aparte regel aangemaakt. Vervolgens worden er regels aangemaakt voor deperiodieke kosten en eventuele kortingen. Bij het bepalen welke korting op defactuur komt te staan, komt het een en ander bij te kijken, we zullen hier lateruitgebreid op terugkomen (zie 3.1.8).

3.1.4 Factuuropmaak

Dit proces creeert daadwerkelijk de factuur, in pdf-formaat. Er zijn verschillendefactoren die invloed hebben wat er precies op een factuur komt te staan. Degegevens die er altijd opgezet moeten worden, is de naam, adres en plaats vande contactpersoon. En uiteraard ook de factuurregels die aangemaakt warenin het vorige proces. Als de factuur voor een bedrijf is, moet de naam vanhet bedrijf ook vermeld worden. Daarnaast moet er gekeken worden naar debetaalwijze. Er zijn drie mogelijkheden: acceptgiro, automatische incasso eniDeal. Elk heeft zijn eigen tekst onderaan de factuur. Als de factuur bestemdis voor een buitenlandse klant, worden deze teksten in het Engels geschreven.Ook wordt er gekeken hoeveel btw de klant moet betalen, om tot slot de totalekosten te berekenen.

3.1. GOBAAL ONTWERP 21

3.1.5 Facturen versturen

Nu de facturen gemaakt zijn, moeten ze nog bezorgd worden. Dit gebeurt ofvia een e-mail naar een extern bedrijf, DMDR, die er vervolgens voor zorgtdat de factuur per post bezorgd wordt. Het alternatief is dat de factuur di-rect per e-mail naar de klant wordt gestuurd. De laatste optie geldt altijd voorbuitenlandse klanten en herinneringsfacturen. De rest gaat in het algemeen viaDMDR en dan via de post. DMDR ontvangt een e-mail met daarin als bijlageeen paar pdf-bestanden. In elk staat een lijst van facturen. Nieuwe contractenstaan in een apart bestand, omdat hier een brief aan toegevoegd moet wordendoor DMDR. Ook facturen die meer dan een pagina lang zijn, staan in een apartbestand, dit voor het gemak voor DMDR.

Er is nog een component, maar deze was niet in de flowcharts meegenomen.Namelijk, het aanpassen van de contracten nadat de facturen zijn gemaakt.

3.1.6 Contracten aanpassen

Voor de contracten waar nu een factuur voor is aangemaakt, moet voorkomenworden dat er niet nog een factuur wordt aangemaakt voor dezelfde periode.Daarom wordt de factuurdatum gewijzigd en opgeslagen in de database. Mochter nog geen factuurdatum en einddatum aanwezig zijn, zoals het geval is bijnieuwe contracten, dan moeten deze ingevuld worden. Dit gebeurt aan de handvan de looptijd van het contract en de facturatieperiode, beiden zijn afhankelijkvan het product.

3.1.7 Renewal run

Als een contract verlopen is, in andere woorden de einddatum is verstreken,wordt deze stilzwijgend verlengd. Tenzij de klant heeft aangegeven het contractte willen beeindigen. Voor het verlengen van contracten hebben we een pro-ces ontwikkeld die los van het normale facturatieproces gestart moet worden.Dit proces is te zien op de zesde pagina van de flowcharts in bijlage C. Water gedaan wordt, is simpel. Als het contract verlopen is en niet opgezegd isdoor de klant dan wordt de einddatum verschoven aan de hand van de looptijdvan het vorige contract. Als het gewijzigde contract wordt opgeslagen zal dezeweer in aanmerking komen om opgehaald te worden door het factureringsproces.

De eerste keer dat we de flowcharts presenteerden kwamen er een aantalpunten aan de orde waar we rekening mee moesten houden. De notulen hiervanstaan in bijlagen G. Het meest interessant was echter de discussie die ontstondrond om de door de klanten te ontvangen korting. Er werd besloten om nogeen keer te vergaderen alleen dan ook met mensen van de sales en marketingafdeling erbij. De notulen van deze vergadering staan in bijlage H. Wat er toenbesloten is, is als volgt.

3.1.8 Kortingen

Het was al bekend dat er vier verschillende niveaus moesten komen voor kortin-gen. Voorheen waren dit er overigens slechts drie. Kortingen op dit niveau is

22 HOOFDSTUK 3. ONTWERP

er nieuw bijgekomen. De discussie ontstond echter over de prioriteiten van deverschillende niveaus en welke combinaties mogelijk mochten zijn. Voorkomenmoest worden dat het systeem regelmatig creditfacturen aan zou maken. Devier niveaus zijn: contract, product, klant en soort.

Korting op contractniveau is een korting die gegeven wordt voor een speci-fiek contract, een overeenkomst tussen Hostnet en een klant voor een specifiekproduct. Korting op productniveau is een actiekorting voor een bepaald prod-uct. Deze geldt voor iedereen die dat product koopt. Korting op klantniveaumaakt het mogelijk om producten, alle of een selectie, altijd met korting aan tebieden voor een individu. Soortniveau is vergelijkbaar, echter is de korting nietvoor een individu, maar voor een groep klanten die in een bepaalde categorievallen, zoals resellers.

Uiteindelijk is er besloten dat als er korting op contractniveau gespecificeerdis, dat deze gekozen moet worden. Contractniveau overschrijft alle andereniveaus. De reden waarom hiervoor gekozen is, is omdat het de salesafdelingvolledige controle geeft over de kosten van een contract zonder dat zij rekeninghoeven te houden met de andere niveaus. Als er geen korting gespecificeerdis op contractniveau, moet het kortingsniveau geselecteerd worden die voor diefacturatieperiode de meeste korting voor de klant opbrengt. Dit heeft bijvoor-beeld als gevolg, wanneer een reseller een product koopt waar een eenmaligeactiekorting op zit, hij in eerste instantie deze eenmalige actiekorting ontvangt,ervan uitgaande dat deze korting hoger is. De volgende keer dat het contractgefactureerd wordt, ontvangt hij zijn periodieke resellers, soort niveau, kort-ing. Voorheen ontvingen resellers slechts hun eigen korting en konden dus nietprofiteren van speciale aanbiedingen op producten. Er is ook besloten dat deenige kortingen combinatie die is toegestaan, is zowel eenmalige als periodiekekorting, maar slechts als deze beiden van het zelfde niveau zijn.

Een andere verbetering die ons systeem biedt ten opzichte van het vorigeis dat volgens de nieuwe wetgeving klanten binnen de EU en bedrijven zonderbtw-nummer ook btw moeten betalen. Vroeger moesten slechts klanten binnenNederland btw betalen. Het oude systeem onderscheidt binnen- en buitenlandseklanten en bepaalt aan de hand daarvan of ze btw moesten betalen. Dit is eengoed voorbeeld dat demonstreert dat het oude systeem moeilijk te onderhoudenen aan te passen is. Het schrijven van een functie die de btw bepaalt zoalsgespecificeerd in de nieuwe wetgeving was voor ons niet moeilijk. Het oudesysteem was echter nog steeds niet aangepast, omdat het te veel tijd zou kosten,gezien er geen werknemers meer zijn die vertrouwd zijn met het systeem.

3.2 Gedetailleerd ontwerp

Nu dat ons ontwerp geverifieerd was, konden we hiermee voortzetten. Voordatwe begonnen aan de implementatie hebben we voor eigen gebruik een gede-tailleerd ontwerp uitgewerkt. In bijlage E zijn het klassendiagram en in bijlageF de volgorde diagrammen die we gemaakt hebben, terug te vinden. Hiermeewas de ontwerpfase afgerond.

Hoofdstuk 4

Implementatie

Bij de implementatie wordt het eindproduct daadwerkelijk gemaakt, dit gebeurtaan de hand van het ontwerp. Tijdens de implementatiefase zijn we een beetjeafgeweken van het V-model. Bij het V-model wordt de code pas getest nadatdeze volledig geımplementeerd is. Onze voorkeur ging ernaar uit om ’test-driven’te werk te gaan. Dit wil zeggen dat de test geschreven wordt voordat de func-tionaliteit word toegevoegd. Dit heeft het voordeel dat fouten in de code snelonderschept worden, waardoor de oorzaak relatief makkelijk terug te vindenen te verbeteren is. Zodoende zijn we telkens begonnen met het schrijven vanunit-tests voordat we functionaliteiten toevoegden. In dit hoofdstuk zullen webespreken welke problemen we zijn tegengekomen en de oplossingen die we hi-ervoor bedacht hebben.

4.1 Problemen en de oplossingen

4.1.1 Unit-tests

Symfony maakt gebruik van het Lime testing framework voor PHP [9]. Hierdooris het erg gemakkelijk om tests geautomatiseerd uit te voeren. De tests moetenwel eerst zelf geschreven worden. Deze testing framework biedt echter niet demogelijkheid om primary-keys van databaserecords rechtstreeks in te vullen. Ditheeft zo zijn voordelen, data kan gerelateerd worden aan elkaar en het systeemzoekt dan zelf beschikbare sleutels op. Dit is echter onhandig als je records metspecifieke eigenschappen wilt opvragen. Gelukkig is het mogelijk Symfony aante passen. Het overerven van een klasse was voldoende om het gewenste gedragtoe te voegen.

Het schrijven van de unit-tests hielp ons met twee aspecten. Het gaf onsinzicht van de gewenste functionaliteit voordat we deze probeerde te imple-menteren. Als de unit-test eenmaal geschreven zijn, is het heel makkelijk ensnel om te testen of alles nog naar verwachting functioneert. Soms heeft hetwijzigen van code een negatieve invloed op een ander deel waarvan je dat nietdirect van verwacht of stomweg over het hoofd had gezien. Het controleren vande unit-tests na een wijziging maakte dit meteen duidelijk.

De testmethodes die we gebruikt hebben, zijn doorgaans niet erg complex.Veel unit-tests controleren slechts of objecten goed opgeslagen en opgehaaldkunnen worden uit de database. Echter de complexiteit die de verschillende

23

24 HOOFDSTUK 4. IMPLEMENTATIE

Figuur 4.1: Unit-test van de kortingen

kortingniveaus met zich meebracht, maakte deze tests echt onmisbaar. Doorde unit-test konden we duidelijk zien of de functionaliteit die bepaalt welkekorting er op de factuur komt te staan, voldeed aan de eisen. In Figuur 4.1is de uitvoer van die unit-tests van de kortigen te zien. Er zijn zoveel plekkenwaar het mis kan zijn gegaan als de korting niet correct wordt weergeven op eenfactuur, dat het niet practisch is om slechts naar de uitvoer te kijken. Het zegterg weinig waar de fout is opgetreden, waardoor het lang zou duren om de foutte localiseren en te verhelpen.

Het ophalen van contracten uit de database die gefactureerd moeten wordenis in theorie niet heel lastig. Dit viel echter erg tegen. De oorzaak is het data-model van de contracten. De contracten zijn verdeeld over drie databases diesynchroon gehouden worden door een proces genaamd ImportExport. Verderzijn er voorheen velden uit het contractentabel misbruikt. Wat een simpel queriezou zijn bij een schone database neemt nu een half a4tje aan code in beslag.Met zoveel afhankelijkheden kan een fout snel optreden, een goede en grondigetest was hier van belang. Alle mogelijke permutaties van contracten moestengegenereerd worden. Al deze mogelijkheden zijn van een actie voorzien doorzowel ons als administratie. Daarna zijn deze gegevens gebruikt in de test omte controleren of we niet te veel en ook niet te weinig contracten selecteren voorfacturatie.

Door ons systeem zo in te delen dat het wegschrijven van data op de on-twikkeldatabase gebeurde en het de data inlas van de productiedatabase kondenwe ons systeem parallel draaien aan het huidige systeem. Dit gaf ons de mo-gelijkheid de uitvoer en de facturen met elkaar te vergelijken en zo eventueleverschillen te identificeren. Door de contracten te analyseren die afweken, kon-den we inzicht krijgen wat hiervoor de verklaring was. Om vervolgens de nodigeaanpassingen te maken zodat deze fouten niet weer zouden optreden.

4.1. PROBLEMEN EN DE OPLOSSINGEN 25

4.1.2 Implementeren losse functies

Na de tests hebben we eerst de kleinere functies geımplementeerd. Te beginnenmet alle get- en set-methodes. Normaal gesproken worden deze automatischgegenereerd door Symfony. De naamgeving van het oude model was echtersoms dusdanig inconsistent of onduidelijk dat we een aantal methodes hebbengeschreven om dit te verhelpen. De oude methodes zijn hiermee deprecated.

Vervolgens hebben we de functionaliteit voor het berekenen van de kortin-gen gemaakt en de selectie van contracten waarvoor een factuur gemaakt moestworden. De code om pdf-facturen te maken van databaserecords bestond gro-tendeels al. Hierdoor konden we al vrij snel facturen genereren met ons systeem.In eerste instantie bevatte deze nog geen kortingen en de omschrijvingen warenook nog niet helemaal in orde, maar hierdoor konden we wel duidelijk laten zienaan andere wat het systeem allemaal kon en wat nog moest gebeuren.

Nadat de kortingen geımplementeerd waren, zijn we aan de interface be-gonnen. De interface hoefde slechts een knop te bevatten, om de facturatie testarten, om de functionaliteit van het oude systeem te evenaren. Om de ge-bruiker enig inzicht te geven in de voortgang van een facturatie-run hebben weook een simpele voortgangsindicator toegevoegd. Dit zorgde echter wel voor eenonverwachts probleem. De indicator wordt door middel van Ajax bijgewerkt.Er wordt dus om de aantal seconden een aanvraag naar de webserver gestuurdom de indicator van nieuwe informatie te voorzien. Omdat de facturatie-paginaveel processorkracht van de server vroeg, gaf de webserver pas weer antwoordnadat het hele facturatieproces klaar was. Hierdoor gaf de indicator niets weer.

Door van het factureringsproces een batch-job te maken, wordt het alslosstaand proces gestart op de server. Hierdoor kan de webserver blijven antwo-orden aan de client die het factureringsproces gestart heeft.

Het factureringsproces schrijft zijn voortgang naar een gemakkelijk leesbaarbestand op de harde schijf. Hierdoor kan door alle sessies gelijktijdig dezelfdevoortgangsindicator worden weergegeven. Zie Figuur 4.2 voor het eindresultaat.

In het huidige systeem word er slechts korting verbonden aan een specifiekproduct. Voor klanten soortniveau hoefde we dus slechts een verband te leggentussen een individu of groep met een specifiek product om te voldoen aan deeisen. Producten worden echter redelijk regelmatig beeindigd. Bijvoorbeeldals er een prijswijziging voor een product plaatsvindt wordt het product nietaangepast in de database, maar wordt het beeindigd en een identiek productaangemaakt met de nieuwe prijs. Dit geldt voor elke wijziging, de rede dat er eennieuw product word aangemaakt in plaats van het huidige product te wijzigingheeft te maken met de statistieken die Hostnet bijhoudt. Om die reden hebbenwe ook onderzocht of we kortingen aan een basisproduct konden koppelen.

De verschillende producten staan in een boomstructuur, momenteel zijn deverschillende producten aan elkaar geknoopt door middel van kind objecten meteen ouder id. Om te controleren of er korting verbonden is aan een basis prod-uct, waaronder het product in kwestie valt, moet de boom stapsgewijs afgegaanworden. Een inefficient proces, gezien er per stap opnieuw een verbinding methet database moet worden gelegd.

We hebben onderzocht of wij hierin verbetering konden brengen en hebbenhet volgende gevonden. De boom moet volledig doorlopen worden en op eenslimme wijze een getal als linker en rechter grens aan elk product toegevoegdworden. Met behulp van deze grenzen kan een hele tak gemakkelijk opgevraagd


Figuur 4.2: Interface van ons facturatie proces

worden. Deze tak bestaat uit basisproducten, er kan nu met gemak gekekenworden of er korting aan een of meerdere van deze producten verbonden is. Wehebben het artikel waarin uitgelegd wordt hoe deze alternatieve boomstructuurprecies werkt en geımplementeerd moet worden, toegevoegd (zie Bijlage I). Laterbleek dat er ook al een plugin voor Symfony bestond, compleet met unit-tests.De plugin is geımplementeerd aan de hand van hetzelfde artikel.

Voor het verlengen van nog niet opgezegde contracten wordt de eindda-tum verzet zodat deze weer door het facturatieproces meegenomen wordt. Nor-maal gesproken zou dit met een SQL-querie kunnen, maar doordat we met driedatabases te maken hebben die synchroon gehouden moeten worden, wordt erdoor middel van drie transacties voor gezorgd dat de wijzigingen in elke databasewordt doorgevoerd.

Bij nieuwe en verlengde contracten moet een begeleidende brief toegevoegdworden. Dit is een standaard brief en wordt door DMDR toegevoegd voordatde factuur naar de klant verstuurd wordt. Het moet dus duidelijk zijn welkefacturen nieuw zijn en welke verlengd. Onze oplossing was om de batch jobuit te breiden. In plaats van een bestand, met alle facturen onder elkaar, wer-den de verschillende soorten: nieuw, verlengd en normaal, in aparte bestandenopgeslagen die vervolgens als bijlagen per e-mail naar DMDR verstuurd worden.

4.1.3 Regressie testen

Vanaf het begin, al tijdens het maken van de ontwerp beslissingen, was hetvoor ons een belangrijk criterium of we de uitvoer van het huidige en ons nieuwsysteem goed met elkaar konden vergelijken. Vanaf de derde week hadden weal de benodigde aanpassingen gemaakt zodat we ons systeem parallel aan, met

4.2. INTEGRATION EN OPERATIONAL TESTING 27

dezelfde invoer als, het huidige systeem konden draaien. Vanaf toen hebben wede facturen handmatig met elkaar kunnen vergelijken, zowel de opmaak als deinhoud van de facturen werden door ons vergeleken.

In eerste instantie waren de verschillen veelal te verwijten aan fouten inons systeem, maar na verloop van tijd waren de fouten voornamelijk te wijtenaan synchronisatie problemen of corrupte data. Deze corrupte data hebben wetelkens met de hand verbeterd. Ons systeem werkte op een gegeven moment zogoed dat onze uitvoer gebruikt werd als controle van het huidige systeem. Zohaalde ons systeem een aantal contracten boven water die in het verleden nietmeegenomen waren voor facturatie. Deze klanten hebben indien het redelijkwas alsnog een factuur ontvangen.

4.2 Integration en Operational testing

Dit zijn de laatste twee onderdelen van het V-model. De manier waarop Host-net haar software ontwikkelt zorgt ervoor dat dit tijdens de implementatie gro-tendeels al getest wordt. De ontwikkelserver draait een kopie van het echtesysteem. Dus ondanks ons systeem nog niet overgezet is naar de acceptatie-nog de productieserver is ons systeem wel al echt deel van het gehele systeemop de ontwikkelserver. De echte test komt weliswaar pas als ons systeem omde acceptatieserver wordt gezet, maar als het werkt op de ontwikkelserver danmoet het ook mogelijk zijn om alles werkend te krijgen op de acceptatieserver.

Tijdens het regressie testen, hebben we regelmatig de uitvoer van ons sys-teem bekeken met anderen van Hostnet. Op die manier konden we verifierenof een onderdeel van ons systeem volledig aan de vereisten voldeed. Zo nodigwerden er aanpassingen gemaakt todat het hele systeem naar wens was.

4.2.1 Samenvatting

Al met al ging vooral het begin van de implementatie fase erg voorspoedig. Laterliepen we tegen verschillende problemen aan waarvan slecht gesynchroniseerdedatabases en corrupte data de meeste problemen gaven. Maar al twee wekenvoor het einde van de stage hadden we een product in handen dat voor dedagelijkse facturatie minder fouten maakte dan het huidige systeem.

Hoofdstuk 5

Evaluatie

Hier zullen we een evaluatie geven van onze stage. We evalueren wat we berijkthebben, welke requirements nog niet gerealiseerd zijn, in hoeverre we ons aande tijdsplanning hebben gehouden, wat we van de opdracht vonden en wat wegeleerd hebben.

5.1 Behaalde resultaat

We hebben nu een platformonafhankelijke applicatie gemaakt die geschrevenis in PHP5, de taal die door de ontwikkelaars binnen Hostnet wordt gebruikt.Daarnaast is alles in veel kleinere stukken opgedeeld. Dit komt de onderhoud-baarheid sterk ten goede. Het nieuwe systeem geeft voor alle bestaande con-tracten dezelfde uitvoer als het huidige systeem. De facturen zijn nu in het alomondersteunde pdf-formaat en niet meer in het Microsoft snapshot formaat. Hetnieuwe systeem kan nu overweg met de nieuwe productenstructuur en maaktook meteen gebruik van een genormaliseerde database in plaats van de oudekaartenbak waar het huidige facturatieproces nog gebruik van maakt.

Er is geen functionaliteit verloren gegaan. Maar nog niet alle aanverwantetaken zijn meteen overgenomen. Zo is bijvoorbeeld het sturen van een herinner-ing of een laatste betalingsverzoek nog niet herontworpen. Hier is echter nietde contractentabel uit de database voor nodig en zal dit onderdeel van het oudesysteem nog steeds werken naast ons nieuw systeem wanneer het in gebruikgenomen wordt.

5.2 Requirements

We hebben zowel alle musts en zelfs alle shoulds kunnen verwezelijken. Devolgende punten zijn uiteindelijk niet geımplementeerd:

C Verlengde contracten moeten pas verstuurd worden als de

einddatum daadwerkelijk verstreken is.

C Het verlengen van contracten moet een paar keer per maand uitgevoerd

kunnen worden.

29

30 HOOFDSTUK 5. EVALUATIE

C Als de klant niet op tijd betaalt, moet er automatisch opnieuw een factuur

gestuurd worden.

C Factuuropmaak makkelijker kunnen aanpassen.

C Factuur per post of per e-mail versturen aan de hand van de voorkeur van

de klant.

C Zichtbaar maken voor administratie hoe een factuur is ontvangen, per

e-mail, of per post.

C Herinnerings facturen mogen de originele niet overschrijven.

C Meerdere talen voor verschillende buitenlandse klanten

Het makkelijker kunnen wijzigen van de opmaak is nog een zeer omvangrijkpunt maar zeker de moeite waard om naar te kijken. Dit omdat de code voorhet creeren van een pdf hergebruikte code is. Deze code is nog erg rommelig enverbruikt heel erg veel geheugen omdat alle objecten in het geheugen wordengeladen en deze ruimte niet meer wordt vrijggegeven tot het einde van het script.

Voor het verwerken van een grote hoeveelheid facturen kan het dus vanbelang zijn deze code te verbeteren.

5.3 Tijdsplanning

Tijdens onze stage heeft Hostnet last gehad van een ernstige storing. De storingheeft ervoor gezorgd dat het een aantal dagen niet mogelijk was om software teontwikkelen. Ook nadat het ergste verholpen was, had beheer Hidde nodig omhun bijstaan. In de nasleep van de storing werd er ook nog regelmatig beroep ophem gedaan om te helpen. Hierdoor is er behoorlijk wat tijd verloren gegaan.

Ondanks dat wisten we, wat betreft het ontwikkelen van ons systeem, tochredelijk op schema te blijven. Het ging echter wel ten koste van de hoeveelheidtijd die we wekelijks aan ons eindverslag hebben besteed. Na dat we klaar warenin Amsterdam was er nog een aanzienlijke hoeveelheid werk te doen voordat hetverslag af was.

5.4 Opdracht

Door de grote hoeveelheid werk die de opdracht omhelste, was het een behoor-lijke uitdaging. Het integreren van een nieuwe applicatie met een bestaandsysteem brengt vaak ook complicaties met zich mee die moeilijk van te vorenzijn te voorspellen. Mede dankzij Hiddes werkervaring bij Hostnet konden wesnel van start gaan. Dit heeft ons zeker geholpen de hoeveelheid werk die vanons vereist was te leveren. De opdracht was extra boeiend voor ons omdathet vanaf het begin al duidelijk was dat Hostnet onze software werkelijk wougaan gebruiken. Met de kennis dat we een echt product moesten leveren, is demotivatie snel al hoger en de inzet groter.

De betrouwbaarheid van het facturatiesysteem is van groot belang. Alser allerlei verkeerde facturen naar klanten verzonden worden, schaadt dit het

5.5. KENNIS 31

imago van het bedrijf. Vandaar dat het goed testen van ons nieuwe systeemerg belangrijk was en een significant onderdeel van ons ontwikkelproces was.Doordat we met ons systeem uiteindelijk zelfs fouten wisten te vinden in hethuidige systeem hebben we de vertrouwen van Hostnet alvast weten te winnen.

5.5 Kennis

Bij aanvang van het project hadden we natuurlijk al basiskennis op het gebiedvan software ontwikkelen en de bijbehorende processen. Over de specifieke soft-ware, omgevingen en de gebruikte programmeertaal binnen Hostnet bezat alleenHidde al kennis. Ondanks Elger bij aanvang geen ervaring had bij Hostnet hadhij de kennis achterstand snel ingehaald.

Het doorlopen van het volledige ontwikkelproces van het begin tot het eindewas een zeer waardevolle ervaring. Het heeft ons inzicht gegeven hoe lastig hetis om vooraf daadwerkelijk alle requirements te achterhalen. De vergaderingendie we met alle betrokkenen hebben gehad om door te spreken wat er preciesmoest komen en waarin we onze voorstellen presenteerden hebben ons ook meerinzicht gegeven hoe niet-technici tegen een ontwikkeltraject aan kijken en watzij verlangen.

Binnen Hostnet wordt veel gebruikgemaakt van flowcharts in plaats vanUnified Modeling Language (UML) diagrammen om processen inzichtelijk temaken. Er zijn ook nog een aantal diagrammen die op Data Flow Diagrams(DFD) lijken. Tijdens vergaderingen hebben we ervoor gekozen om de presen-taties op de voor hen vertrouwde mannier te doen. Voor onze eigen ontwikkelinghebben we klassen- en volgordediagrammen gemaakt. We hebben ook voorzienin een DFD om duidelijk te krijgen welke databases in welke stap van het procesnodig zouden zijn. Klassen diagrammen zijn redelijk bekend binnen het bedrijf.Volgorde diagrammen, dataflow diagrammen, use cases en state charts kwamenalleen voor in documentatie van andere stageopdrachten die bij Hostnet uitgevo-erd waren. Onze interface was dusdaanig beperkt dat het maken van use caseszwaar overbodig zouden zijn. Hostnet maakt steeds meer gebruik van UML, erzijn zelfs medewerkers gesponsord om hiervoor cursussen te volgen.

Voor de grotere nieuwe projecten gebruikt Hostnet normaal de waterfallmethodiek. Bij de kleinere dingen ontbreekt echter al snel de structuur. Wijwaren vrij te kiezen welke methodiek we wilden gebruiken. Het V-model lijkteigenlijk ook best wel op de waterfall methode.

5.6 Conclusie

Al met al was het een geslaagde stage met een goede samenwerking met Hostnet.Wij hebben het heel erg naar ons zin gehad bij Hostnet. Het was een waardevolleervaring. Uiteindelijk gaan we deze zomer nog verder met het project om hetnieuwe systeem in gebruik te kunnen nemen. Het was een prettige samenwerkingmet Sales, Administratie, Productontwikkeling, Beheer en natuurlijk ApplicatieManagement.

32 HOOFDSTUK 5. EVALUATIE

Hoofdstuk 6

Aanbevelingen

Nadat een product is opgeleverd, zijn er vaak nog dingen waar geen tijd voor wasof die netter of mooier gemaakt kunnen worden. Ook kunnen er nog obstakelsovergebleven zijn die overkomen moeten worden voor het product succesvol ingebruik genomen kan worden. Soms kan het nodig zijn nog extra onderzoek tedoen. Hieronder staan onze aanbevelingen ten aanzien van het door ons herzienefacturatieproces.

6.1 Korting koppelen aan basisproducten

Op dit moment wordt de korting op klanten soortniveau nog gegeven op eenspecifiek product. Het zou zeker toegevoegde functionaliteit zijn om het mogelijkte maken om de korting aan een basisproduct te koppelen. Om dit efficient tekunnen doen moet het mogelijk zijn om met een database-querie een hele tak uitde productenboom te halen. Dit zou mogelijk zijn met behulp van een symfonyplugin.

6.2 Contractendatabases synchroniseren

Het bestaan van drie verschillende databases, waarvan een genormaliseerd ende andere twee niet, leidt onherroepelijk tot verschillen. Op dit moment wordtgefactuureerd aan de hand van de niet-genormaliseerde Hostnet database. Hetnieuwe factureringsproces factureert aan de hand van de wel genormaliseerdedatabase. Bij de overgang is het echter van belang dat er geen verschillen meertussen de databases zijn.

6.3 Samenvoegen van alle Contractendatabases

Een verderstrekkende aanbeveling dan de vorige is om de contractendatabasessamen te voegen tot een. Dan kunnen er geen inconsistenties tussen de ver-schillende versies optreden en zijn veel synchronisatie fouten verleden tijd. Ditkan nadat de contracttabel in Hostbase niet meer wordt gebruikt gemakkelijkgedaan worden. De twee overgebleven MySQL-databases zouden gesynchro-

33

34 HOOFDSTUK 6. AANBEVELINGEN

niseerd kunnen worden d.m.v stored procedures. Dit heeft als grote voordeel desnelheid en het kunnen uitschakelen van de ImportExport.

6.4 Laatste functionaliteit van het oude systeemherontwerpen

Uiteindelijk zou het goed zijn om de laatste overgebleven functionaliteiten uitHostbase over te nemen in Aurora zodat alle systemen binnen Hostnet in dezelfdetaal zijn geschreven en gemakkelijk door alle ontwikkelaars onderhouden kunnenworden. Alle functionaliteiten zijn dan ook vanaf niet Windows pcs beschikbaar.Bovendien zal deze ook blijven werken als er een nieuwe versie van Access uitkomt. Dit is met Hostbase helaas niet het geval.

Bibliografie

[1] CVS. http://en.wikipedia.org/wiki/concurrent versions system, 2008.

[2] Francois Zaninotto en Fabien Potencier. The Definitive Guide to Symfony.Springer-Verslag, New York, 1st, edition, 2007.

[3] Tobias Oetiker en Hubert Partl en Irene Hyna en E. Schlegl. The Not SoShort Introduction to Latex, 2008. http://tobi.oetiker.ch/lshort/lshort.pdf.

[4] ERD. http://nl.wikipedia.org/wiki/erd, 2008.

[5] Harry Fuecks. The PHP Anthology. Object Oriented PHP Solutions VolumeI. Sitepoint, Collingwood, Australia, 1st, edition, 2003.

[6] Harry Fuecks. The PHP Anthology. Object Oriented PHP Solutions VolumeII. Sitepoint, Collingwood, Australia, 1st, edition, 2003.

[7] Kile. http://kile.sourceforge.net/, 2008.

[8] SVN. http://en.wikipedia.org/wiki/subversion %28software%29, 2008.

[9] Symfony. http://www.symfony-project.org/, 2008.

[10] Vim. http://www.vim.org/docs.php, 2008.

[11] vmodel. http://nl.wikipedia.org/wiki/v-model, 2008.

35

36 BIBLIOGRAFIE

38 HOOFDSTUK 7. BIJLAGEN

Hoofdstuk 7

Bijlagen

7.1 Bijlagen A: Plan van Aanpak

Plan van aanpak

IntroductieHostnet is een bedrijf, gevestigd in Amsterdam, dat online producten en diensten verkoopt. Zij bieden alles aan wat je nodig hebt voor het hosten van een website. Van domeinnamen en webhosting tot dedicated servers. Het bedrijf heeft een eigen software ontwikkelteam, beheer, webdesign, helpdesk- en sales afdeling. Gedurende de afgelopen tien jaar zijn de hoeveelheid klanten en producten van het bedrijf toegenomen. Het bestaande software werd telkens aangepast om de groei bij te benen. Recent zijn de productentabellen volledig vernieuwd, de structuur is volledig herdacht en geïmplementeerd in MySQL. Het oude systeem, dat nog met MsSQL werkt, kan nog niet alle voordelen van de nieuwe productenstructuur benutten. Momenteel worden de product gegevens telkens omgezet, dit proces wordt omschreven als het maken van een cirkel van een vierkant door er met een hamer op te slaan. Zoals deze omschrijving al aantoont, het is een grof proces dat niet altijd goed gaat.

OpdrachtMet begeleiding van het bestaande software ontwikkelteam waar wij tevens zelf deel uit zullen maken, is het onze opdracht om ervoor te zorgen dat de nieuwe productenstructuur volledig benut kan worden en het omzetten van verschillende datatabellen niet meer nodig zal zijn. Het is een bestaand en werkend systeem waar veranderingen in aangebracht moeten worden. Met het beslissen hoe we deze verandering tot stand gaan brengen, zullen we dus rekening moeten houden met het huidige systeem. Van essentieel belang is dat er geen functionaliteit verloren gaat gezien het bedrijf hier afhankelijk van is.

AanpakGedurende het project zullen wij fulltime aanwezig zijn bij Hostnet. Dit houd in vijf dagen in de week van negen tot half zes.De eerste twee weken wordt besteed aan onderzoek. Het huidige systeem moet geanalyseerd worden voordat beslist kan worden hoe de benodigde aanpassingen gerealiseerd kunnen worden. Tevens moet er besloten worden welke werkomgeving, programmeertaal en methodiek geschikt zijn. Deze informatie zal gedocumenteerd worden in een onderzoeksverslag. In deze periode zal ook door middel van interviews en vergaderingen vastgesteld worden wat de verwachtingen en eisen zijn van de verschillende afdelingen binnen Hostnet.Na het onderzoek zal er een ontwerp gemaakt worden. Zowel flowcharts als klassediagrammen zullen hiervoor gebruikt worden. Op deze manier is het mogelijk om met zowel programmeurs als niet-programmeurs goed te valideren of het ontwerp voldoet aan hun eisen.Als deze goedgekeurd is, zal er begonnen worden aan de implementatie. Tijdens en na afloop zal het systeem uitgebreid getest worden om te verifiëren of onze implementatie overeen komt met ons ontwerp. Ook zal er d.m.v prototypes feedback verworven worden. Na verloop van de stage zal ons software een periode parallel lopen met het huidige systeem om feedback te verzamelen en te analyseren om te garanderen dat onze software het huidige proces kan vervangen zonder problemen op te leveren.

7.1. BIJLAGEN A: PLAN VAN AANPAK 39

Requirements (MoSCoW)Must:

Aanpassingen mogen niet ten koste gaan van de huidige functionaliteitHet oude systeem moet de nieuwe productenstructuur volledig kunnen benuttenHet factureringsproces is het belangrijkste proces dat gebruikmaakt van de productentabel en zou dus aangepast moeten worden. Het proces moet:

Kortingen correct verwerkenRekening houden met buitenlandse klanten (factuur wordt per e-mail gestuurd)Contracten die verlopen, automatisch verlengen.

Should:In een run alle eenmalige en periodieke facturen opsturenRekening houden met verschillende betalingswijzenRekening houden met de verschillende btw-percentages (binnen/buiten Nederland/Europa)

Could:Als de klant niet op tijd betaalt moet er automatisch opnieuw een factuur gestuurd wordenEngelse facturen voor buitenlandse klantenMeerdere talen voor verschillende buitenlandse klantenFactuuropmaak makkelijker kunnen aanpassenPer post of mail aan de hand van de voorkeur van de klant

ProjectinrichtingDe volgende OPAFIT aspecten komen aan de orde:

• Organisatieo Harold Douwes

Opdrachtgevero David Dijkstra

Opdrachtgevero Yom Schutte

Projectbegeleidero Arjen Schwarz

Projectbegeleider• Personeel

De door ons ontwikkelde software zal voor intern gebruik zijn. We zullen dus rekening moeten houden met alle medewerkers van Hostnet.

• Administratieve proceduresAl onze ondervindingen en beslissingen zullen gedocumenteerd worden in verschillende documenten gedurende het project. Er zal in ieder geval een plan van aanpak, een onderzoeken een eindverslag geschreven worden

• FinancieringDe meeste hardware en software is al aanwezig en tot onze beschikking. Mochten wij echter gebruik willen maken van een werkomgeving die nog niet beschikbaar is, dan moet er rekening gehouden worden met eventuele licenties die hieraan verbonden zijn. In overleg is het mogelijk om deze aan te schaffen, maar de voorkeur is om de software te ontwikkelen binnen de beschikbare werkomgevingen.

• InformatieEr zullen tussentijdse voortgangbesprekingen gehouden worden, de belangrijkste hiervan is de midterm evaluation wanneer we besluiten om verder te gaan in de huidige richting of om hiervan af te wijken. Hostnet is een redelijk klein bedrijf, hierdoor is het makkelijk om anderen


te benaderen om informatie te verwerven. • Techniek

We hebben onze eigen werkplekken bij Hostnet. We hebben beschikking tot dezelfde software en informatie als alle andere medewerkers en kunnen onze eigen programma's installeren mocht het nodig zijn.

VoorwaardenDe voorwaarden die gesteld zijn aan de opdrachtnemer zijn:

• Het project moet binnen 10 weken afgerond zijn.• De door ons ontwikkelde software moet overzichtelijk gecodeerd zijn en goed gedocumenteerd worden. • Het project moet afgerond worden met een eindverslag en een presentatie.

De voorwaarden die gesteld zijn aan de opdrachtgever zijn:• De mogelijkheid bieden aan de opdrachtnemers om het huidige systeem te analyseren.• De bestaande programmacode ter beschikking stellen voor gebruik.• Verdere informatie verstrekken indien dit nodig blijkt te zijn.

PlanningWeek Gepland

1.14 t/m 18 april

MoSCoWPlan van aanpak

2.21 t/m 25 april

Onderzoeks rapport (5-10 A4)Requirements analyse / functioneel ontwerp

3.28 t/m 2 mei

Technisch ontwerpInhoudsopgave eindverslag

4.5 t/m 9 mei

Prototype eerste runPrototype dmdr koppeling (http://www.dmdr.nl/ extern bedrijf die de facturen verstuurd)

5.12 t/m 16 mei

Test classes eerste runTests dmdr koppeling

6.19 t/m 23 mei

Eerste run klaar / dmdr klaarPrototype en test herinneringen en renewals

7.26 t/m 30 mei

Midterm evaluationAndere runs klaar

8.2 t/m 6 juni

Alle runs klaar en getest

9.9 t/m 13 mei

Uitloop ruimte

10.16 t/m 20 mei

Eindpresentatie

Grafisch overzicht

7.1. BIJLAGEN A: PLAN VAN AANPAK 41

Hostnet vraagt ook of wij gebruikmaken van project open. Een applicatie waarin wij aangeven welke taken ondernomen moeten worden. Hoeveel tijd wij hiervoor denken nodig te hebben, hoeveel tijd we er daadwerkelijk aan hebben besteed en in hoeverre de taak is voltooid. Dit is interessant voor management om te zien waar het bedrijf zijn tijd in investeert. Voor ons is het interessant omdat het ervoor zorgt dat we een gedetailleerde planning maken en we makkelijk onze voortgang kunnen bijhouden.

ProductkwaliteitHet bestaande systeem is procedurele code waar gedurende de jaren telkens code is toegevoegd, verwijderd en veranderd. Hierdoor is de betrouwbaarheid en onderhoudbaarheid afgenomen. Gewenst wordt dat dit verbetert. De betrouwbaarheid van het product is van groot belang. Als het systeem vaak problemen oplevert zal dit leiden tot ontevreden klanten waardoor het imago van Hostnet beschadigd zal worden. Ook zal dit meer werk voor de helpdesk en administratie veroorzaken. Hostnet is een groeiend bedrijf en daarom is de onderhoudbaarheid en portabiliteit ook erg belangrijk. Als onze gesuggereerde aanpassingen eenmaal in gebruik zijn, maakt het deel uit van een systeem dat dagelijks door meerdere personen aangepast en uitgebreid word. De code moet daarom goed begrijpbaar zijn zodat het mee kan groeien met het bedrijf.Hoe efficiënter de data omzet hoe langer het systeem kan groeien zonder de nood van nieuwe hardware, dus ook dit is interessant om rekening mee te houden. Belangrijker is echter dat de code begrijpbaar is dan kan het altijd nog efficiënter gemaakt worden.Ons product is alleen bedoeld voor intern gebruik. Het moet niet moeilijker worden dan het huidige systeem, anders lopen we het risico dat het niet geaccepteerd wordt en dus niet in gebruik genomen wordt.Er mag geen functionaliteit verloren gaan.

Voorgestelde maatregelen• Wekelijkse updates. Aan het einde van elke week word er een e-mail naar alle medewerkers van

Hostnet gestuurd, waarin vermeld wordt waar die week aan gewerkt is en wat de voortgang is.• Belangrijke beslissingen worden in overleg met projectbegeleiders zo nodig in een vergadering

met de opdrachtgevers en eventuele andere partijen die beïnvloed worden, zoals Administratie, genomen.

• De code en onze beslissingen moeten goed gedocumenteerd worden zodat het duidelijk is voor alle betrokkenen

• We zullen zelf onze code uitvoerig testen. Het eindproduct zal na afloop van onze stage een periode parallel lopen aan het huidige systeem om te garanderen dat er geen problemen ontstaan op het moment dat het in gebruik wordt genomen.


7.2 Bijlagen B: Onderzoeksverslag


Onderzoeksrapport



19 mei 2008

Samenvatting

De eerste twee weken van onze stage zijn aan onderzoek besteed omvertrouwd te raken met onze nieuwe werkomgeving en om belangrijke in-formatie te verwerven. Het doel van dit document is om alle verworvenkennis te documenteren en de beslissingen, die hier volgen, te onderbou-wen. De volgende stap zal het uitwerken van de door ons aanbevolenvoorstel zijn. Er zal een concept worden ontworpen in de richting die indit document wordt bepaald.


Onderzoeksrapport



19 mei 2008

Samenvatting

De eerste twee weken van onze stage zijn aan onderzoek besteed omvertrouwd te raken met onze nieuwe werkomgeving en om belangrijke in-formatie te verwerven. Het doel van dit document is om alle verworvenkennis te documenteren en de beslissingen, die hier volgen, te onderbou-wen. De volgende stap zal het uitwerken van de door ons aanbevolenvoorstel zijn. Er zal een concept worden ontworpen in de richting die indit document wordt bepaald.

7.2. BIJLAGEN B: ONDERZOEKSVERSLAG 43

1 Introductie

Dit rapport is een van de documenten voor het Bachelor-eindproject van deopleiding Technische Informatica aan de Technische Universiteit Delft. Voordit project zijn studenten gevraagd een opdracht uit te voeren voor een externbedrijf of organisatie. In dit geval gaat het om een bedrijf genaamd Hostnet,gevestigd in Amsterdam. Zij bieden alle benodigdheden voor het hosten van eenwebsite aan; van domeinnamen en webhosting tot dedicated servers. Het bedrijfheeft een eigen software ontwikkelteam, beheer, webdesign, helpdesk, sales, pro-ductmanagement en communicatie-afdeling. Er zijn ongeveer 41 medewerkers,12 medewerkers ontwikkelen software.

Ons onderzoek begon met het analyseren van de huidige situatie. Hiernahebben we ons verdiept in onze probleemstelling en onderzoeken hoe wij dezehet beste kunnen oplossen. Aan de hand van dit onderzoek hebben we eenbesluit genomen en zijn we nagegaan wat dit voor een invloed heeft op onzewerkomgeving voor dit project. Hier hebben we ook onderzoek naar gedaan.Tot slot hebben we verschillende ontwikkelmethodieken vergeleken en gedocu-menteerd waar we voor gekozen hebben en waarom. De probleemstelling isbeter te begrijpen nadat het huidige systeem duidelijk is. Om die reden staatde probleemstelling in de laatste alinea van “Analyse huidige situatie“ vermeld.

2 Analyse huidige situatie

Toen Hostnet begon, werden de klanten- en productgegevens opgeslagen in ex-cel sheets. Sindsdien is het bedrijf, de hoeveelheid klanten en producten, flinkgegroeid. De excel sheets zijn vervangen door datastructuren en er werd een sys-teem ontwikkeld binnen Microsoft Access om administratie te assisteren. Ditsysteem, geschreven met procedurele code, is over de jaren uitgebreid en aange-past om met het bedrijf mee te groeien. Hierdoor is de code moeilijk te begrij-pen, waardoor de betrouwbaarheid en onderhoudbaarheid van het hele systeemis gedaald. Een ander probleem is dat dit systeem, nu bekend als Hostbase,direct zijn benodigde gegevens uit een niet-genormaliseerde MsSQL-databasehaalt. In 2006 is de eerste stap, om hier in verandering te brengen, gezet. Deproductenstructuur is volledig herontworpen, zowel deze als de klantgegevenszijn losgekoppeld van Hostbase en staan nu in een genormaliseerde MySQL-database. Hostbase werkt echter alleen met een MsSQL-database met de oudestructuur en kan daarom de extra functionaliteit die de nieuweproducten struc-tuur biedt nog niet benutten. Een simpele illustratie van de huidige situatie iste zien in Figuur 1.

Er is een onderscheid tussen een front-, mid- en backoffice gemaakt. Het ideeis dat de frontoffice bedoeld is voor het beheren van de data en communicatiemet de klant. In de backoffice staan applicaties die gebruikmaken van deze data.De midoffice zorgt voor de communicatie tussen de front- en backoffice.

Hostbase behoort tot de backoffice. Het facturatieproces, het verwerkenvan betalingen en het bijhouden van statistieken vindt hier plaats. Hostbaseis slechts bereikbaar via Microsoft Access. Access werkt alleen onder MicrosoftWindows. Dit is nadelig daar de meeste computers bij Hostnet standaard Linuxdraaien. Nog een probleem met Hostbase is, dat het geschreven is in VBScript,een gestripte versie van Visual Basic. Er zijn weinig werknemers bij Hostnet die

1


Figuur 1: Huidige situatie

hier goed mee overweg kunnen.In de frontoffice staat een MySQL-database genaamd Mijn Hostnet. Klanten

van Hostnet hebben toegang tot deze database via een applicatie met dezelfdenaam. Werknemers van Hostnet doen dit via Aurora. Aurora is web-based endaarom vanaf alle computers beschikbaar. De frontoffice is geprogrammeerdin PHP5 binnen een framework genaamd Symfony. Dankzij dit framework ishet makkelijk om in de toekomst van database te veranderen. De databasestaat in een datacenter. In de frontoffice staat de nieuwe productenstructuur,de klantgegevens en ook de website waar klanten de mogelijkheid hebben omproducten te bestellen.

De midoffice heet Hostnet Full Throttle (HFT) en was ontworpen als tweedestap in het proces het huidige systeem te verbeteren. Het is geschreven omalle extra functionaliteit van de nieuwe productenstructuur te benutten. Debedoeling is dat de HFT wordt gebruikt om interessante data uit de frontofficete halen waar de backoffice dan weer iets mee kan doen. De HFT is klaarom in gebruik te nemen, maar omdat Hostbase nog de oude structuur en eenMsSQL-database gebruikt, is dit nog niet mogelijk. De extra functionaliteit diede nieuwe productenstructuur biedt, wordt dus nog helemaal niet gebruikt.

Daar het nog niet mogelijk was de HFT te gebruiken, was het noodzakelijkeen ondersteunend proces te ontwerpen, de Import/Export. Dit is momenteel deschakel tussen Hostbase en Mijn Hostnet. De taak van dit proces is om de datain de MySQL-database uit Mijn Hostnet en de data in het MsSQL-databasevan Hostbase synchroon te houden. Op die manier is het mogelijk om wel algebruik te maken van de nieuwe MySQL-databases in het datacenter en toch ookde applicaties in Hostbase te kunnen blijven gebruiken. Maar omdat de MsSQL-database niet genormaliseerd is en de structuren verschillen, gaat dit niet altijd

2


goed. Daarbij is het bijhouden van dezelfde data op twee verschillende plekkenen het synchroniseren hiervan niet erg efficient. Ook is het een relatief traagproces omdat de twee databases slechts met twee ADSL-verbindingen verbondenzijn. Het zou veel efficienter zijn als alle data op een plek bijgehouden werd.

Aan ons is gevraagd het huidige systeem aan te passen, zodat er eindelijk ge-bruikgemaakt wordt van de nieuwe productenstructuur en alle extra functionali-teiten die het biedt. Het belangrijkste proces, die het meest zou profiteren, is hetfacturatieproces. Deze zal dus in ieder geval aangepast of herontworpen moetenworden zodat dit proces via de HFT zijn data uit de MySQL-database haalt enniet de door de Import/Export omgezette data uit de MsSQL-database. [8,12,14]

3 Voorgestelde oplossingen

Naar onze mening waren er drie verschillende manieren waarmee een oplossingvoor de probleemstelling kon worden gerealiseerd. Van elk voorstel hebben weonderzocht wat de voor- en nadelen zouden zijn en hun invloed op de betrokke-nen.

3.1 Minimale aanpassing van Hostbase

De bestaande code zou grotendeels intact blijven. Slechts de code die informatievan de producten ophaalt en verwerkt, moet worden aangepast. Sommige versiesvan de bestaande factuurprocedure moeten worden samengevoegd, omdat denieuwe productenstructuur geen onderscheid maakt tussen pakketten en andereproducten.

Bij dit voorstel zal de code in Access blijven. In vele opzichten is dit na-delig. Het testen van code in Access is lastig, waardoor de kans op fouten inhet eindproduct erg groot is. Er zijn maar een beperkt aantal mensen binnenHostnet die hier goed mee overweg kunnen. De code is slecht uitbreidbaar. Hetdraaien van het facturatieproces blijft beperkt tot Microsoft Windows met Ac-cess 2000. Het zal niet mogelijk zijn om gebruik te maken van svn. Hierdoor ishet moeilijker om met zijn tweeen tegelijkertijd onafhankelijk van elkaar code teontwikkelen. De uniformiteit zal niet stijgen. Een ander nadeel is dat de codein Hostbase niet uit kleine delen bestaat, waardoor het testen zeer complex isen er gemakkelijk zaken over het hoofd gezien worden. Ook is het veel werk omde genormaliseerde klantengegevens uit Aurora mee te nemen. Het eindproductvolgens dit voorstel is lastig om parallel te laten lopen met het huidige systeem.

Er zijn voordelen van deze manier van aanpak, maar niet veel. Een voordeelis dat de interface in Hostbase bijna precies hetzelfde zal blijven. Administratiezal dus na de veranderingen binnen hun vertrouwde werkomgeving blijven wer-ken. Een ander voordeel is dat er relatief weinig regels code geschreven hoevente worden om deze aanpassing te realiseren.

3.2 Herontwerp van het facturatieproces

Het idee van dit voorstel is om het facturatieproces volledig opnieuw te ontwer-pen en implementeren. Andere processen van Hostbase zoals bijvoorbeeld hetverwerken van betalingen zullen onveranderd blijven.

3


Omdat het proces volledig opnieuw geschreven wordt, is het voor ons moge-lijk om het uit kleine onafhankelijke en goed testbare onderdelen op te bouwen.De kans op ernstige fouten is dus veel kleiner dan bij het eerste voorstel. Bij hetherontwerpen kan er veel beter rekening gehouden worden met toekomstige wen-sen. Het is makkelijker om extra functionaliteiten te implementeren. Door dedatabases slim te kiezen, zal het dataverkeer van het nieuwe proces veel snellerzijn dan het huidige systeem.

Een ander groot voordeel is dat het mogelijk is om het nieuwe ontwerpin PHP5 met het Symfony-framework te implementeren. Dit zal voor goedeuniformiteit met de frontoffice zorgen. Er zijn veel medewerkers bij Hostnet dieervaring hebben en vertrouwd zijn om met PHP en Symfony software te ontwik-kelen. Het eindproduct zal dus goed begrepen en onderhouden kunnen worden.Het zal mogelijk zijn bestaande code in Aurora te benutten. Het facturatie-proces wordt platformonafhankelijk. Het zal namelijk vanuit een webbrowserbenaderbaar worden. Het meenemen van de genormaliseerde klantengegevenszal relatief makkelijk zijn.

Een nadeel voor administratie is dat de huidige interface voor het factu-ratieproces in Hostbase verdwijnt. Het grootste gevaar bij dit voorstel is dathet misschien niet lukt om het hele systeem volledig te implementeren in debeschikbare tijd.

3.3 Volledig herbouwen van Hostbase functionaliteit

Hierbij zouden alle functionaliteiten van Hostbase herontworpen moeten worden;het facturatieproces, de statistieken en de binnengekomen betalingen. Naastdeze drie grotere processen wordt Hostbase ook nog voor een tal andere kleinerezaken gebruikt. Deze zouden dan geınvertariseerd en goed beschreven moetenworden voordat de grootte van dit project volledig duidelijk is.

Dit voorstel profiteert van dezelfde voordelen als het tweede voorstel. Daar-bij zou ook nog eens de Import/Export volledig kunnen verwijderen. Alle oudeprocedurele code, waarvan niet goed begrepen wordt hoe het werkt, zal vervan-gen worden. Het zou het hele systeem uniform maken.

Een nadeel voor administratie is dat het huidige interface met Hostbase ineen keer volledig zal verdwijnen. Dit voorstel omvat te veel werk om in degestelde tijd te voltooien. Slechts delen kunnen behaald worden.

4 Onze aanbevelingen

Aan de hand van ons onderzoek hebben wij het tweede voorstel, het heront-werpen van het facturatieproces, aan Hostnet aanbevolen. Hierbij kunnen wijgarantie geven van een robuust en goed getest systeem. Tegelijkertijd hebbenwe aanbevolen het nieuwe ontwerp te implementeren met PHP in het Symfony-framework. Een alternatieve keuze zou bijvoorbeeld Visual Basic zijn geweest.Hier zouden echter kosten aan verbonden zijn. Daarbij, door voor PHP enSymfony te kiezen, stijgt de uniformiteit van het systeem en is het mogelijk be-staande code te gebruiken. Het eindproduct zal ontwikkeld zijn binnen een voorHostnet zeer bekende omgeving, waardoor het in de toekomst goed begrepen enonderhouden kan worden.

4


Voorstel 1 Voorstel 2 Voorstel3

Geen verandering van de interface + - -

Hoeveelheid werk + +/- -

Uniformiteit - + +

Platform onafhankelijk - + +

Oude en nieuwe systeem parallel draaien - + +

Tegelijkertijd code kunnen ontwikkelen - + +

Gebruik van subversion (source backup) - + +

Hergebruik van bestaande code - + +

Uitbreidbaarheid van het eindproduct - + +

Begrijpbaar voor Hostnet - + +

Centralisatie van de databases +/- + +

Verdwijnen van oude onbegrijpbare code - +/- +

Import/Export omzeilen +/- +/- +

Tabel 1: De drie voorstellen met elkaar vergeleken

De hoeveelheid werk van het tweede voorstel is overzichtelijk. Als hetgeımplementeerd is, zal de nieuwe productenstructuur en alle extra functionali-teiten door het hele systeem benut worden. Ondanks dat de Import/Export nogsteeds nodig zal zijn, zal er minder gebruik van gemaakt worden dan voorheen.

Qua databases zijn er twee soorten tot onze beschikking. We kunnen vanzowel de MsSQL- als de MySQL-database gebruikmaken, of een combinatiehiervan. Wij hebben aanbevolen om alleen gebruik te maken van de MySQL-database. Dan staat alles op het databasecluster gecentraliseerd. Het voordeelhiervan is dat het mogelijk is om gegevens uit meerdere databases in een aan-vraag binnen te halen. Dit is zeer efficient en zou een grote snelheidswinstboeken ten opzichte van de andere opties.

Voor een overzicht van de sterke en zwakke aspecten van de drie voorstellenzie Tabel 1.

We zien dat voorstel 2 en 3 duidelijk meer voordelen hebben dan voorstel 1.De voornaamste reden dat we voorstel 2 hebben verkozen boven 3 is gebrek aantijd. Voorstel 2 boekt een grote verbetering van het bestaande systeem. Hetproject dat in 2006 gestart is, zal eindelijk voltooid worden. Na het voltooienvan voorstel 2 zou Hostnet nieuwe projecten kunnen starten om de rest van defunctionaliteit van Hostbase over te zetten om het gehele systeem uniform temaken en de Import/Export te kunnen verwijderen. In dat opzicht kan voorstel2 gezien worden als de eerste stap om voorstel 3 te realiseren.

5 Werkomgeving

In de huidige situatie is alle code van het facturatieproces te vinden in de Accessapplicatie Hostbase. Alle andere applicaties binnen Hostnet zijn geschreven inPHP5.

Er zal met de taal PHP5 binnen het Symfony-framework worden gewerkt.Voor de database wordt gebruikgemaakt van MySQL4. Alles draait op een ser-ver met CentOS4 (Linux distributie) en Apache2 als webserver. Hiernaast wor-den er natuurlijk ook verschillende editors gebruikt, waaronder Vim en Eclipse.Op de locale pc wordt Ubuntu (Linux) gedraaid. Alle documenten voor Hostnet

5


moeten beschikbaar zijn in OpenOffice-formaat. Een groot deel van de verslagenzullen wij schrijven in latex. Kile (KDE integrated Latex Editor) gebruiken weals applicatie om de documenten in te schrijven. Voor het maken van klassen-diagrammen staat Umbrello tot onze beschikking, een opensource UML-pakketbeschikbaar voor KDE onder Ubuntu.

PHP5 is een objectgeorienteerde taal zonder types en met veel standaardfuncties. Het is een veel gebruikte taal voor webapplicaties en bovendien gratisbeschikbaar voor commercieel gebruik. Een goede handleiding en voorbeeldenzijn te vinden op www.php.net. PHP draait als module in de veel gebruikteApache Webserver. In het document coden bij hostnet.odt is de code stylevan Hostnet te vinden. Hierbij zijn ook alle constructies en veel voorkomendecodeblokken uitgewerkt. Een erg nuttig naslagwerk. [6, 7]

Symfony is een framework voor PHP5 en is ontwikkeld door het Franse Sen-siolabs. Het framework biedt een splitsing in Model, View en Control. Hiernaastbevat het ook ondersteuning voor zowel unit- als functionele tests. In het modelgedeelte van de MVC-structuur zit de object-relationeel mapping en de data-base abstractie. In de View-laag komt alle opmaak op basis van templates. Indeze laag zijn ook veel hulpfuncties te vinden die het leven gemakkelijker makenen veel voorkomende taken wat betreft opmaak en Javascript, maar ook Ajax tevereenvoudigen. Symfony wordt onder andere gebruikt door Askeet en YahooBookmarks. [4, 15]

MySQL4 is een relationeel DBMS. MySQL is vrij verkrijgbaar onder deGPL-licentie. MySQL is vanuit PHP gemakkelijk te benaderen door de librarydie al jaren wordt meegeleverd met PHP. Ook is er in Symfony ondersteuningvoor MySQL. Als frontend om de database zelf aan te kunnen passen, wordtPHPMyAdmin gebruikt.

Apache2 is een veel gebruikte webserver die ook door Hostnet wordt gebruiktom alle websites van klanten met een standaard hostingpakket te hosten. Dezeserver is opensource met een eigen licentie. [13]

CentOS4 en Ubuntu zijn linux-distributies. Ubuntu wordt gebruikt op dewerkstations, waar iedereen gebruik van maakt en CentOS4 wordt gebruikt opde ontwikkel-, test-, acceptatie- en productie-servers. [10, 11]

Voor het schrijven van lange stukken code wordt gebruikgemaakt van Eclip-se. Voor kleine aanpassingen gebruiken we Vim [16]. Een bekende tekst editorin linux. Hiermee is het mogelijk om snel de gevolgen van aanpassing te zienzonder tussenkomst van versiebeheer.

Voor het maken van standaard documenten staat OpenOffice tot onze be-schikking. Dit wordt standaard meegeleverd met Ubuntu en kan alle gebruike-lijke office bestandsformaten lezen en schrijven.

Voor het maken van de documenten die we inleveren kan gebruik gemaaktworden van Latex. Latex is een opmaaktaal die bestanden in platte tekst op-slaat. Ook kunnen documenten gemakkelijk gesplitst worden en is er een goedsysteem om referenties bij te houden. De editor die we hierbij gebruiken is Ki-le (KDE Integrated Latex Editor). Aangezien de documenten uit platte tekstbestaat, kunnen ze gemakkelijk in een versiebeheer worden opgenomen en isgelijktijdig bewerken mogelijk. [5, 9]

Voor de gemakkelijke stroomdiagrammen is OpenOffice toereikend, maarvoor het maken van echte UML-diagrammen is het toch wenselijk een program-ma te hebben dat meer functionaliteit biedt. Umbrello is hiervoor beschikbaar.Een simpel programma voor Ubuntu. Umbrello bevat niet erg veel mogelijkhe-

6


den, maar ruim voldoende voor het maken van de basisdiagrammen. Ubrellokan ook exporteren naar PHP5-code.

Alles wat wordt geproduceerd, is opgeslagen in een subversion repository.Subversion is een versiebeheersysteem afgeleid van CVS. Alle bestanden wor-den centraal op de server opgeslagen. Een ieder kan wijzigingen doorvoeren.Als er gelijktijdig gewijzigd is, worden de twee documenten automatisch samen-gevoegd. Als er een gelijke sectie is bewerkt, treedt er een conflict op en ishandmatig ingrijpen vereist. Door het gebruik van Subversion hebben we altijdeen back-up en kunnen we ook terugbladeren naar eerdere versies als er tochiets overboord is gezet wat later nuttig blijkt.

Over al deze applicaties is op de betreffende websites veel informatie tevinden, maar vooral op de wiki van Hostnet staat voor de meeste van dezeapplicaties beschreven hoe ze gebruikt kunnen worden. [8]

6 Methodiek

Ook hebben wij onderzoek gedaan welke methodiek geschikt zou zijn voor hetontwikkelen van ons project. We zijn tot de conclusie gekomen dat eXtreme Pro-gramming (XP) voor ons project het meest geschikt zal zijn. [3] Onze motivatiehiervoor is als volgt.

Ons eindproduct zal een cruciaal deel zijn in het systeem waar Hostnet opdraait. Het is dus van belang dat de software die wij leveren robuust en betrouw-baar is. Bij de XP-methodiek wordt de code elke dag getest en fouten verwijderdvoordat er verder gegaan wordt. Het is niet ongebruikelijk dat de testcode eerstgeschreven wordt, voordat de functionaliteit word geımplementeerd. Op dezewijze worden fouten snel gedetecteerd en is het relatief makkelijk om uit tevinden waar het fout gaat. Hierdoor zijn fouten snel en makkelijk op te lossen.

Binnen Hostnet zijn er verschillende partijen die beınvloed worden door ofinvloed hebben op de software die door ons ontwikkeld gaat worden. Dezepartijen hebben regelmatig nieuwe ideeen wat het nieuwe facturatieproces zoukunnen doen. XP biedt de mogelijkheid om deze ideeen gedurende het geheleontwikkelingsproces mee te nemen in het concept.

Het idee van XP is dat er in korte tijd een prototype beschikbaar is, zodatde klant snel een idee heeft welke richting het project op gaat. Ze kunnen zienwat er op dat moment mogelijk is en door ermee te experimenteren kunnen zebeter bedenken wat ze graag nog meer of anders willen. Deze feedback wordtvervolgens in een volgende iteratie van het prototype verwerkt. Dit zorgt ervoordat het project de goede richting in blijft gaan en zoveel mogelijk aan de eisenvoldoet. Gedurende het ontwikkelproces kunnen nog eisen verzameld worden endus kan er snel gestart worden met het ontwikkelen van de software. Daaromleent de XP-methodiek zich goed voor projecten waar tijd schaars is, zoals bijons het geval.

XP eist discipline, anders is er een gevaar dat het ontwikkelingsproces cha-otisch wordt en focus verliest. XP is niet geschikt voor grote applicaties en hetadvies is om niet met meer dan twaalf programmeurs te werken. Ook wordter geadviseerd om per tweetal software te ontwikkelen. Gezien we geen groteapplicatie hoeven te ontwikkelen en omdat we met zijn tweeen zijn, precies eentweetal, zal dit geen probleem moeten zijn.

De XP-methodiek eist ook veel inbreng van de toekomstige gebruikers. Daar

7


al onze toekomstige gebruikers zich binnen Hostnet bevinden, zijn zij bijna al-tijd beschikbaar. Het is een klein bedrijf, daardoor is de communicatie goed,XP geeft ons de mogelijkheid hier maximaal van te profiteren! [1–3,17]

Referenties

[1] http://nl.wikipedia.org/wiki/extreme programming, 2007.

[2] http://en.wikipedia.org/wiki/extreme programming, 2008.

[3] Alan Dennis en Barbara Haley Wixom. Systems Analysis & Design. JohnWiley & Sons, Inc., New York, 2nd, edition, 2003.

[4] Francois Zaninotto en Fabien Potencier. The Definitive Guide to Symfony.Springer-Verslag, New York, 1st, edition, 2007.

[5] Tobias Oetiker en Hubert Partl en Irene Hyna en E. Schlegl. The Not SoShort Introduction to Latex, 2008. http://tobi.oetiker.ch/lshort/lshort.pdf.

[6] Harry Fuecks. The PHP Anthology. Object Oriented PHP Solutions VolumeI. Sitepoint, Collingwood, Australia, 1st, edition, 2003.

[7] Harry Fuecks. The PHP Anthology. Object Oriented PHP Solutions VolumeII. Sitepoint, Collingwood, Australia, 1st, edition, 2003.

[8] Hostnet. http://wiki.hostnetbv.nl/index.php/hoofdpagina, 2008. Alleenzichtbaar voor Hostnet medewerkers.

[9] Kile. http://kile.sourceforge.net/, 2008.

[10] Canonical Ltd. http://www.ubuntu.com/, 2008.

[11] CentOS Ltd. http://www.centos.org/, 2008.

[12] Marije Nijs, 2008. Interview.

[13] Apache HTTP Server Project. http://httpd.apache.org/, 2008.

[14] Yom Schutte, 2008. Interview.

[15] Symfony. http://www.symfony-project.org/, 2008.

[16] Vim. http://www.vim.org/docs.php, 2008.

[17] J. Donovan Wells. http://www.extremeprogramming.org/, 2006.

8

7.3. BIJLAGEN C: FLOWCHARTS 51

7.3 Bijlagen C: Flowcharts

1

Facturatieproces

2

Gebruikte symbolen

H Hostnet medewerker Begin Process Initalisatie process

C klant Factuur bij de klantEinde process succesvol

FactuurHB Datastore Eind niet succesvolEinde proces niet succesvol

factuurdatum=< einddatum

Contract voorfacturatie ophalen

1.

Process Keuze

Verbinding naar Datastore

contract ophalen Geautomatiseerde actie

Stuur mailnaar DMDRProcessflow Email


3

Administratie

Factureringsproces – Dataflow Diagram


1.

Factuur aanmakenindien nodig

2.

Factuurregelaanmaken

3.

Factuur opmaken

4.

Factuur versturen

5.

H

Factuur bij de klantC

FactuurHB

RelatieMHProductMHContractHFT

start facturatie

Contract

Factuur met regels Factuur in PDF

Factuur

Voor elk contract

4

Administratie



2.


3.

Factuur opmaken

4.

Factuur versturen

5.

H


FactuurHB


start facturatie

Contract


Factuur

Voor elk contract


1.


5

Factureringsproces – 1. Contracten voor facturatie ophalen

Begin Factureringsproces

Eind succesvol

contract ophalen factuurdatum=< einddatum

contract selecteren voor facturatie

factuurdatumisNULL

factuurdatumisEmpty

ja

ja

ja

nee

nee

nee

H

6

Factureringsproces – 1. Contracten voor facturatie ophalen (RENEWAL)

Begin Factureringsproces

Eind succesvol

contract ophalen factuurdatum>= einddatum

NOW >einddatum –

periode

NOW >einddatum -opzegtermijn

Status

Einddatum contractophogen met periode

Contract selecterenvoor facturatie

Ja Ja Ja Ja

Nee Nee Nee Nee

Constraint:de renewalrun moetzo vaak gedraait worden dat de tijd tussen twee keer uitvoeren

kleiner is dan de opzegtermijn en kleiner dan

de facturatieperiode

H


7

Administratie



1.


3.

Factuur opmaken

4.

Factuur versturen

5.

H


FactuurHB


start facturatie

Contract


Factuur

Voor elk contract


2.

8

Factureringsproces – 2. Factuur aanmaken indien nodig

Begin factuur aanmken Kijk of factuur al bestaat Eind succesvol

factuur record maken

ja

nee


9

Administratie


Factuur opmaken

4.

Factuur versturen

5.

H


FactuurHB


start facturatie

Contract


Factuur

Voor elk contract


1.


2.


3.

10

Factureringsproces – 3. Factuurregel aanmakenStart

volgende_factuur_datum

=< begin_datum

volgende_factuurisNull

volgende_factuurisEmpty

eenmalige kosten regeltoevoegen

periodieke kosten regeltoevoegen

korting > 0

eenmalige korting bepalen

eenmalige korting regeltoevoegen

korting > 0

periodieke korting bepalen

periodieke korting regeltoevoegen

volgende_factuur_datumophogen met defacturatie periode

Eind succesvolEerste factuur? Eenmalige kosten Periodieke kosten

nee

nee

nee

ja

ja

jaja ja

neenee


11



=< begin_datum





korting > 0


korting > 0





nee

nee

nee

ja

ja

jaja ja

neenee


12

Factureringsproces – 3.1. Bepalen eenmalige korting

Start

korting op contract niveau

neem korting op contract niveau

neem grootste kortingop klant, soort ofproduct niveau

Eind succesvol

ja

nee


13



=< begin_datum





korting > 0



korting > 0




nee

nee

nee

ja

ja

jaja ja

neenee


14

Factureringsproces – 3.2. Bepalen periodieke korting

Start

korting op contract niveau

neem korting op contract niveau

neem grootste kortingop klant, soort ofproduct niveau

Eind succesvol

ja

nee


15

Administratie



1.


2.


3.

Factuur versturen

5.

H


FactuurHB


start facturatie

Contract


Factuur

Voor elk contract

Factuur opmaken

4.

16

Factureringsproces – 4. Factuur opmaken

Start

Eind succesvol

NAW gegevens ophalen Buitenlandse klant

Soort factuur tekst plaatsen

(factuur, herinnering laatste betalingsverzoek)

Voettekst buitenlandop factuur plaatsen

Voettekst binnenlandop factuur plaatsen

Tekst herinneringop factuur plaatsen

alle facuurregelsop de factuur plaatsen Totaal bedrag plaatsen

19% BTW

0% BTW

Buitenlandsbedrijf met

BTW nummer

ja

ja

nee

nee


17

Administratie



1.


2.


3.

Factuur opmaken

4.

H


FactuurHB


start facturatie

Contract


Factuur

Voor elk contract

Factuur versturen

5.

18

Factureringsproces – 5. Factuur versturen

Start

Status Buitenlandse kalnt

Versturen per post

Versturen per email

Email naar DMDR

Email naar Klant

Eind succesvolC

herinnering

laatste betalings verzoek

factuur

ja

nee


19

Facturatieproces

7.4. BIJLAGEN D: ENTITY-RELATIONSHIP DIAGRAM 61

7.4 Bijlagen D: Entity-relationship Diagram

myh

ostn

et

has

fact

uur_

pdf

pdf

id

datu

m

fact

uur

kenm

erk

id

1

1fa

ctuu

r_re

gel

fact

uur_

rege

l_vo

lgnr

bedr

ag

id

omsc

hrijv

ing

perio

de_t

mpe

riode

_van

has

1

n

fact

uur_

stat

us

teks

tte

kst_

voet

id

te

kst_

voet

_bui

tenl

and

has

1

n

cont

ract

datu

m_b

egin

id

datu

m_e

ind

dom

einn

aam

korti

ng_e

enm

alig

_bed

rag

korti

ng_p

erio

diek

_bed

rag

korti

ng_p

erce

ntag

e_be

drag

datu

m_f

actu

ur_v

olge

nde

has

n

n

prod

uct

omsc

hrijv

ing_

fact

uur

id

eenm

alig

prijs

per_

perio

de

id

maa

nden

perio

de

naam

id

per_

perio

de

korti

ng

omsc

hrijv

ing

id

pct_

per_

perio

de

eenm

alig

pct_

eenm

alig

has

1

n

has

n

1

has

1n

fact

urat

ie

opze

g

1 1

n

n

has

n

Rel

atie

1

beta

ling_

type

naam

id

has 1

1


7.5 Bijlagen E: Klassendiagram

7.6. BIJLAGEN F: VOLGORDE DIAGRAM 63

7.6 Bijlagen F: Volgorde diagram

7.7. BIJLAGEN G: NOTULEN FLOWCHARTS-PRESENTATIE 65

7.7 Bijlagen G: Notulen flowcharts-presentatie

Notulen 21 April 2008

Aanwezigen:David Dijkstra, Marije Nijs, Yom Schutte, Hidde Boomsma, Elger Lambert

Besproken is het voorstel van het nieuwe factureringsproces aan de hand van een flowchart presentatie. Deze flowcharts zijn momenteel te zien op de wiki: http://wiki.hostnetbv.nl/index.php/FactuurrunDe rede voor deze bijeenkomst was om te valideren of alle benodigde functionaliteiten in het proces zijn opgenomen en eventueel andere extra wensen in het proces opgenomen kunnen worden.

Op of aanmerkingen waar de flowcharts niet volledig waren of waar extra op gelet moet worden zijn in deze notulen genoteerd.

• Renewals moeten pas na de einddatum van het contract verstuurd worden. Dit voorkomt extra discussie bij klanten die het toch nog willen opzeggen.

• Momenteel word de renewal run 1 keer per maand uitgevoerd. Wenselijk is om dit in de toekomst twee keer, of misschien wel vier keer per maand te doen, maar niet vaker.

• Geattendeerd werd dat contracten die de status verwijderd hebben niet gefactureerd mogen worden.

• Waar ook rekening mee gehouden moet worden is dat 'order succes' niet perse betekent dat het al geleverd is. - [Wijziging] Hoeft geen rekening mee gehouden worden, als er een contract is dan is de order afgerond.

• Bij het maken van de factuurregels moet ervoor gezorgd worden dat eenmalige korting onderaan de factuur komt te staan met de andere kortingen zoals dat nu ook gebeurt.Gesuggereerd werd om de regels verschillende types toe te kennen zodat de opmaak van de factuur makkelijk te bepalen maar ook aan te passen is. Interessant als er voor wat voor een reden dan ook in de toekomst besloten word dat de factuurregels op een andere manier geordend moeten worden.

Er ontstond een discussie toen besproken werd hoe kortingen verwerkt moeten worden. Niet alles was duidelijk en omdat bij het bedenken van de nieuwe productenstructuur hier ook al uitgebreid over na gedacht is en hier ook rekening mee gehouden is met het ontwerp is besloten om dinsdag 22 april om 14:00 uur opnieuw hierover te vergaderen. Ditmaal met Stefan Lenselink, Merijn de Brabander en Martijn Oostdam erbij. Het doel is dan om vast te stellen hoe er met kortingen overweg gegaan moet worden. Welke kortingen en combinatie van kortingen wel en niet toegestaan zijn.

Punten die vandaag tijdens de discussie naar voren zijn gekomen zijn:1. Gecontroleerd moet worden dat de kosten in combinatie met een korting nooit minder dan 0

mag worden.2. Er mag nooit een creditfactuur gemaakt worden door het systeem. 3. Het moet wel mogelijk zijn een creditfactuur handmatig aan te maken. 4. Het moet ook mogelijk zijn een normale factuur handmatig aan te maken. Interessant zou zijn

als dit in de toekomst ook vanuit Aurora gedaan kan worden. 5. Het moet mogelijk zijn om (handmatig) een eenmalig korting op een periodiek bedrag te

plaatsen. Gezegd werd dat dit eigenlijk altijd een vast bedrag is en het misschien interessant was om een procentueel bedrag te verbieden.

6. Gewaarschuwd werd dat in het huidige voorstel het mogelijk is dat een reseller zowel zijn


afgesproken periodieke korting zowel als een eenmalige korting op productniveau kan ontvangen. Dit is echter niet de bedoeling!

Opgemerkt werd dat het fijn zou zijn voor sales als zij zouden kunnen zien hoe een korting voor een product er op de factuur er uit komt te zien. -Leuk project voor iemand anders.

De discussie wat betreft kortingen is hier toen bij gelaten. Wat nog besproken moet worden is bijvoorbeeld welke verschillende korting niveaus moeten er bestaan, hoe worden ze ingevoerd, welke prioriteit hebben ze en welke combinaties zijn er wel en niet mogelijk.

• Herinneringsfacturen mogen de originele niet overschrijven. Suggestie is om met een volgnummer te werken.

• Een leuk extra zou zijn het zichtbaar maken van hoe een factuur is ontvangen (per e-mail, per post).

Gemaakte afspraken:Er word voor ons een tabel gemaakt met daarin duidelijk weergegeven hoe het zit met de verschillende btw-percentages.Morgen, dinsdag om 14:00 uur, opnieuw bespreken hoe kortingen verwerkt moeten worden.

7.8. BIJLAGEN H: NOTULEN KORTINGEN VERGADERING 67

7.8 Bijlagen H: Notulen kortingen vergadering

Notulen 22 April 2008

Aanwezigen:David Dijkstra, Marije Nijs, Yom Schutte, Martijn Oostdam, Marijn de Brabander, Stefan Lenselink Hidde Boomsma, Elger Lambert

Aan de hand van de vorige bespreking op 21 april over het gehele factureringsproces is er besloten vandaag te vergaderen over hoe kortingen verwerkt moeten worden. Het doel was om in kaart te brengen hoe ze nu verwerkt worden en hoe het in de toekomst verwerkt moet gaan worden.

Huidige situatie:• Een korting op contractniveau is een afspraak met een klant voor een specifiek product. Deze

overschrijft alle andere kortingen.• Op productniveau bestaat slechts een eenmalige absolute korting.• Momenteel is reseller hetzelfde als klantniveau, dit is een periodieke korting die eenmalige

korting (op productniveau) overschrijft.

Na deze constatering is er uitgebreid gediscussieerd wat wenselijk zou zijn voor het nieuwe systeem. Centraal in deze discussie stond de vraag hoe er omgegaan moet worden met resellers. Moeten zij automatisch profiteren van acties of niet? In het huidige systeem blijven zij het zelfde betalen ook al is er een aanbieding die goedkoper is dan hun afspraak.

Gemaakte Afspraken:-De discussie is afgerond met de afspraak dat Marketing en Sales zouden beslissen hoe zij willen hoe kortingen in het nieuwe systeem moet worden geïmplementeerd. - Zie onderaan dit document wat er besloten is!-Omdat onze code uit losse modules gaat bestaan, kunnen wij toch al de code gaan schrijven zonder te weten wat het besluit van Marketing en Sales is.-Bij het eindproduct is het van belang dat het duidelijk is hoe de kortingen geïmplementeerd zijn, zodat zowel administratie als andere programmeurs begrijpen waarom welke korting op de factuur komt te staan.-Mocht een automatisch gegenereerde factuur een bedrag kleiner dan 0 bedragen (credit), dan moet deze door het systeem worden opgevangen en administratie moet er van op de hoogte gebracht worden. Op deze manier kunnen zij uitzoeken hoe dit tot stand is gekomen en eventueel actie ondernemen mocht dit nodig zijn. In het geval er een goede verklaring voor is, kunnen zij handmatig een creditfactuur aanmaken.(In de toekomst is het misschien interessant om dit soort facturen in een lijst bij administratie te plaatsen en dat deze door middel van een vinkje en een druk op de knop alsnog verstuurd dan wel verwijderd worden. Dit is echter alleen de moeite waard als er regelmatig creditfacturen worden aangemaakt, gezien de beslissing [zie hieronder] denk ik echter dat dit niet het geval gaat zijn).

Het Besluit:Tijdens het typen van deze notulen hebben David Dijkstra, Harold Douwes, Martijn Oostdam en Marijn de Brabander overlegd en hebben het volgende besloten.Er moet in eerste instantie gekeken worden naar kortingen op contractniveau. Mocht er zowel een eenmalig als periodieke korting bestaan op contractniveau dan moet deze met elkaar vergeleken worden. De hoogste van de twee word toegekend en overschrijft alle andere kortingen. Mocht er geen korting zijn op contractniveau moet er gekeken worden naar alle andere mogelijke kortingen, dit zijn:


eenmalig en of periodieke korting op productniveau, soort klantniveau en klantniveau. Bij periodieke korting bestaan er zowel absolute als percentuele bedragen. Bij eenmalige kortingen bestaat er slechts een absolute korting. Degene die de klant de meeste korting oplevert moet gekozen worden en de rest overschreven. Er is dus besloten dat resellers in de toekomst met het nieuwe systeem automatisch zullen profiteren van acties als die goedkoper zijn dan hun resellerkorting.

7.9. BIJLAGEN I: MANAGING HIERARCHICAL DATA IN MYSQL 69

7.9 Bijlagen I: Managing Hierarchical Data inMySQL

Skip navigation links

Contact a MySQL Representative

Login | Register

Managing Hierarchical Data in MySQL

By Mike Hillyer

Introduction

Most users at one time or another have dealt with hierarchical data in a SQL database and no doubt learned that themanagement of hierarchical data is not what a relational database is intended for. The tables of a relational database are nothierarchical (like XML), but are simply a flat list. Hierarchical data has a parent-child relationship that is not naturallyrepresented in a relational database table.

For our purposes, hierarchical data is a collection of data where each item has a single parent and zero or more children (withthe exception of the root item, which has no parent). Hierarchical data can be found in a variety of database applications,including forum and mailing list threads, business organization charts, content management categories, and productcategories. For our purposes we will use the following product category hierarchy from an fictional electronics store:

These categories form a hierarchy in much the same way as the other examples cited above. In this article we will examinetwo models for dealing with hierarchical data in MySQL, starting with the traditional adjacency list model.

The Adjacency List Model

Typically the example categories shown above will be stored in a table like the following (I'm including full CREATE andINSERT statements so you can follow along):

CREATE TABLE category(category_id INT AUTO_INCREMENT PRIMARY KEY,name VARCHAR(20) NOT NULL,parent INT DEFAULT NULL);

The world's most popular open source database

MySQL :: Managing Hierarchical Data in MySQL http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

1 of 13 7/9/08 11:59 AM


INSERT INTO categoryVALUES(1,'ELECTRONICS',NULL),(2,'TELEVISIONS',1),(3,'TUBE',2),(4,'LCD',2),(5,'PLASMA',2),(6,'PORTABLE ELECTRONICS',1),(7,'MP3 PLAYERS',6),(8,'FLASH',7),(9,'CD PLAYERS',6),(10,'2 WAY RADIOS',6);

SELECT * FROM category ORDER BY category_id;

+-------------+----------------------+--------+| category_id | name | parent |+-------------+----------------------+--------+| 1 | ELECTRONICS | NULL || 2 | TELEVISIONS | 1 || 3 | TUBE | 2 || 4 | LCD | 2 || 5 | PLASMA | 2 || 6 | PORTABLE ELECTRONICS | 1 || 7 | MP3 PLAYERS | 6 || 8 | FLASH | 7 || 9 | CD PLAYERS | 6 || 10 | 2 WAY RADIOS | 6 |+-------------+----------------------+--------+10 rows in set (0.00 sec)

In the adjacency list model, each item in the table contains a pointer to its parent. The topmost element, in this caseelectronics, has a NULL value for its parent. The adjacency list model has the advantage of being quite simple, it is easy to seethat FLASH is a child of mp3 players, which is a child of portable electronics, which is a child of electronics. While theadjacency list model can be dealt with fairly easily in client-side code, working with the model can be more problematic in pureSQL.

Retrieving a Full Tree

The first common task when dealing with hierarchical data is the display of the entire tree, usually with some form ofindentation. The most common way of doing this is in pure SQL is through the use of a self-join:

SELECT t1.name AS lev1, t2.name as lev2, t3.name as lev3, t4.name as lev4FROM category AS t1LEFT JOIN category AS t2 ON t2.parent = t1.category_idLEFT JOIN category AS t3 ON t3.parent = t2.category_idLEFT JOIN category AS t4 ON t4.parent = t3.category_idWHERE t1.name = 'ELECTRONICS';

+-------------+----------------------+--------------+-------+| lev1 | lev2 | lev3 | lev4 |+-------------+----------------------+--------------+-------+| ELECTRONICS | TELEVISIONS | TUBE | NULL || ELECTRONICS | TELEVISIONS | LCD | NULL || ELECTRONICS | TELEVISIONS | PLASMA | NULL || ELECTRONICS | PORTABLE ELECTRONICS | MP3 PLAYERS | FLASH || ELECTRONICS | PORTABLE ELECTRONICS | CD PLAYERS | NULL || ELECTRONICS | PORTABLE ELECTRONICS | 2 WAY RADIOS | NULL |+-------------+----------------------+--------------+-------+6 rows in set (0.00 sec)

Finding all the Leaf Nodes

We can find all the leaf nodes in our tree (those with no children) by using a LEFT JOIN query:

SELECT t1.name FROMcategory AS t1 LEFT JOIN category as t2ON t1.category_id = t2.parentWHERE t2.category_id IS NULL;


2 of 13 7/9/08 11:59 AM


+--------------+| name |+--------------+| TUBE || LCD || PLASMA || FLASH || CD PLAYERS || 2 WAY RADIOS |+--------------+

Retrieving a Single Path

The self-join also allows us to see the full path through our hierarchies:

SELECT t1.name AS lev1, t2.name as lev2, t3.name as lev3, t4.name as lev4FROM category AS t1LEFT JOIN category AS t2 ON t2.parent = t1.category_idLEFT JOIN category AS t3 ON t3.parent = t2.category_idLEFT JOIN category AS t4 ON t4.parent = t3.category_idWHERE t1.name = 'ELECTRONICS' AND t4.name = 'FLASH';

+-------------+----------------------+-------------+-------+| lev1 | lev2 | lev3 | lev4 |+-------------+----------------------+-------------+-------+| ELECTRONICS | PORTABLE ELECTRONICS | MP3 PLAYERS | FLASH |+-------------+----------------------+-------------+-------+1 row in set (0.01 sec)

The main limitation of such an approach is that you need one self-join for every level in the hierarchy, and performance willnaturally degrade with each level added as the joining grows in complexity.

Limitations of the Adjacency List Model

Working with the adjacency list model in pure SQL can be difficult at best. Before being able to see the full path of a categorywe have to know the level at which it resides. In addition, special care must be taken when deleting nodes because of thepotential for orphaning an entire sub-tree in the process (delete the portable electronics category and all of its children areorphaned). Some of these limitations can be addressed through the use of client-side code or stored procedures. With aprocedural language we can start at the bottom of the tree and iterate upwards to return the full tree or a single path. We canalso use procedural programming to delete nodes without orphaning entire sub-trees by promoting one child element andre-ordering the remaining children to point to the new parent.

The Nested Set Model

What I would like to focus on in this article is a different approach, commonly referred to as the Nested Set Model. In theNested Set Model, we can look at our hierarchy in a new way, not as nodes and lines, but as nested containers. Try picturingour electronics categories this way:


3 of 13 7/9/08 11:59 AM


Notice how our hierarchy is still maintained, as parent categories envelop their children.We represent this form of hierarchy in atable through the use of left and right values to represent the nesting of our nodes:

CREATE TABLE nested_category ( category_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(20) NOT NULL, lft INT NOT NULL, rgt INT NOT NULL);

INSERT INTO nested_categoryVALUES(1,'ELECTRONICS',1,20),(2,'TELEVISIONS',2,9),(3,'TUBE',3,4),(4,'LCD',5,6),(5,'PLASMA',7,8),(6,'PORTABLE ELECTRONICS',10,19),(7,'MP3 PLAYERS',11,14),(8,'FLASH',12,13),(9,'CD PLAYERS',15,16),(10,'2 WAY RADIOS',17,18);

SELECT * FROM nested_category ORDER BY category_id;

+-------------+----------------------+-----+-----+| category_id | name | lft | rgt |+-------------+----------------------+-----+-----+| 1 | ELECTRONICS | 1 | 20 || 2 | TELEVISIONS | 2 | 9 || 3 | TUBE | 3 | 4 || 4 | LCD | 5 | 6 || 5 | PLASMA | 7 | 8 || 6 | PORTABLE ELECTRONICS | 10 | 19 || 7 | MP3 PLAYERS | 11 | 14 || 8 | FLASH | 12 | 13 || 9 | CD PLAYERS | 15 | 16 || 10 | 2 WAY RADIOS | 17 | 18 |+-------------+----------------------+-----+-----+

We use lft and rgt because left and right are reserved words in MySQL, see http://dev.mysql.com/doc/mysql/en/reserved-words.html for the full list of reserved words.

So how do we determine left and right values? We start numbering at the leftmost side of the outer node and continue to theright:

This design can be applied to a typical tree as well:


4 of 13 7/9/08 11:59 AM


When working with a tree, we work from left to right, one layer at a time, descending to each node's children before assigninga right-hand number and moving on to the right. This approach is called the modified preorder tree traversal algorithm.

Retrieving a Full Tree

We can retrieve the full tree through the use of a self-join that links parents with nodes on the basis that a node's lft value willalways appear between its parent's lft and rgt values:

SELECT node.nameFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtAND parent.name = 'ELECTRONICS'ORDER BY node.lft;

+----------------------+| name |+----------------------+| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || PORTABLE ELECTRONICS || MP3 PLAYERS || FLASH || CD PLAYERS || 2 WAY RADIOS |+----------------------+

Unlike our previous examples with the adjacency list model, this query will work regardless of the depth of the tree. We do notconcern ourselves with the rgt value of the node in our BETWEEN clause because the rgt value will always fall within the sameparent as the lft values.

Finding all the Leaf Nodes

Finding all leaf nodes in the nested set model even simpler than the LEFT JOIN method used in the adjacency list model. If you


5 of 13 7/9/08 11:59 AM


look at the nested_category table, you may notice that the lft and rgt values for leaf nodes are consecutive numbers. To findthe leaf nodes, we look for nodes where rgt = lft + 1:

SELECT nameFROM nested_categoryWHERE rgt = lft + 1;

+--------------+| name |+--------------+| TUBE || LCD || PLASMA || FLASH || CD PLAYERS || 2 WAY RADIOS |+--------------+

Retrieving a Single Path

With the nested set model, we can retrieve a single path without having multiple self-joins:

SELECT parent.nameFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtAND node.name = 'FLASH'ORDER BY parent.lft;

+----------------------+| name |+----------------------+| ELECTRONICS || PORTABLE ELECTRONICS || MP3 PLAYERS || FLASH |+----------------------+

Finding the Depth of the Nodes

We have already looked at how to show the entire tree, but what if we want to also show the depth of each node in the tree, tobetter identify how each node fits in the hierarchy? This can be done by adding a COUNT function and a GROUP BY clause toour existing query for showing the entire tree:

SELECT node.name, (COUNT(parent.name) - 1) AS depthFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtGROUP BY node.nameORDER BY node.lft;

+----------------------+-------+| name | depth |+----------------------+-------+| ELECTRONICS | 0 || TELEVISIONS | 1 || TUBE | 2 || LCD | 2 || PLASMA | 2 || PORTABLE ELECTRONICS | 1 || MP3 PLAYERS | 2 || FLASH | 3 || CD PLAYERS | 2 || 2 WAY RADIOS | 2 |+----------------------+-------+


6 of 13 7/9/08 11:59 AM


We can use the depth value to indent our category names with the CONCAT and REPEAT string functions:

SELECT CONCAT( REPEAT(' ', COUNT(parent.name) - 1), node.name) AS nameFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtGROUP BY node.nameORDER BY node.lft;

+-----------------------+| name |+-----------------------+| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || PORTABLE ELECTRONICS || MP3 PLAYERS || FLASH || CD PLAYERS || 2 WAY RADIOS |+-----------------------+

Of course, in a client-side application you will be more likely to use the depth value directly to display your hierarchy. Webdevelopers could loop through the tree, adding <li></li> and <ul></ul> tags as the depth number increases and decreases.

Depth of a Sub-Tree

When we need depth information for a sub-tree, we cannot limit either the node or parent tables in our self-join because it willcorrupt our results. Instead, we add a third self-join, along with a sub-query to determine the depth that will be the newstarting point for our sub-tree:

SELECT node.name, (COUNT(parent.name) - (sub_tree.depth + 1)) AS depthFROM nested_category AS node,

nested_category AS parent,nested_category AS sub_parent,(

SELECT node.name, (COUNT(parent.name) - 1) AS depthFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtAND node.name = 'PORTABLE ELECTRONICS'GROUP BY node.nameORDER BY node.lft

)AS sub_treeWHERE node.lft BETWEEN parent.lft AND parent.rgt

AND node.lft BETWEEN sub_parent.lft AND sub_parent.rgtAND sub_parent.name = sub_tree.name

GROUP BY node.nameORDER BY node.lft;

+----------------------+-------+| name | depth |+----------------------+-------+| PORTABLE ELECTRONICS | 0 || MP3 PLAYERS | 1 || FLASH | 2 || CD PLAYERS | 1 || 2 WAY RADIOS | 1 |+----------------------+-------+

This function can be used with any node name, including the root node. The depth values are always relative to the namednode.

Find the Immediate Subordinates of a Node


7 of 13 7/9/08 11:59 AM


Imagine you are showing a category of electronics products on a retailer web site. When a user clicks on a category, youwould want to show the products of that category, as well as list its immediate sub-categories, but not the entire tree ofcategories beneath it. For this, we need to show the node and its immediate sub-nodes, but no further down the tree. Forexample, when showing the PORTABLE ELECTRONICS category, we will want to show MP3 PLAYERS, CD PLAYERS, and 2WAY RADIOS, but not FLASH.

This can be easily accomplished by adding a HAVING clause to our previous query:

SELECT node.name, (COUNT(parent.name) - (sub_tree.depth + 1)) AS depthFROM nested_category AS node,

nested_category AS parent,nested_category AS sub_parent,(

SELECT node.name, (COUNT(parent.name) - 1) AS depthFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtAND node.name = 'PORTABLE ELECTRONICS'GROUP BY node.nameORDER BY node.lft

)AS sub_treeWHERE node.lft BETWEEN parent.lft AND parent.rgt

AND node.lft BETWEEN sub_parent.lft AND sub_parent.rgtAND sub_parent.name = sub_tree.name

GROUP BY node.nameHAVING depth <= 1ORDER BY node.lft;

+----------------------+-------+| name | depth |+----------------------+-------+| PORTABLE ELECTRONICS | 0 || MP3 PLAYERS | 1 || CD PLAYERS | 1 || 2 WAY RADIOS | 1 |+----------------------+-------+

If you do not wish to show the parent node, change the HAVING depth <= 1 line to HAVING depth = 1.

Aggregate Functions in a Nested Set

Let's add a table of products that we can use to demonstrate aggregate functions with:

CREATE TABLE product(product_id INT AUTO_INCREMENT PRIMARY KEY,name VARCHAR(40),category_id INT NOT NULL);

INSERT INTO product(name, category_id) VALUES('20" TV',3),('36" TV',3),('Super-LCD 42"',4),('Ultra-Plasma 62"',5),('Value Plasma 38"',5),('Power-MP3 5gb',7),('Super-Player 1gb',8),('Porta CD',9),('CD To go!',9),('Family Talk 360',10);

SELECT * FROM product;

+------------+-------------------+-------------+| product_id | name | category_id |+------------+-------------------+-------------+| 1 | 20" TV | 3 || 2 | 36" TV | 3 || 3 | Super-LCD 42" | 4 || 4 | Ultra-Plasma 62" | 5 || 5 | Value Plasma 38" | 5 || 6 | Power-MP3 128mb | 7 || 7 | Super-Shuffle 1gb | 8 |


8 of 13 7/9/08 11:59 AM


| 8 | Porta CD | 9 || 9 | CD To go! | 9 || 10 | Family Talk 360 | 10 |+------------+-------------------+-------------+

Now let's produce a query that can retrieve our category tree, along with a product count for each category:

SELECT parent.name, COUNT(product.name)FROM nested_category AS node ,nested_category AS parent,productWHERE node.lft BETWEEN parent.lft AND parent.rgtAND node.category_id = product.category_idGROUP BY parent.nameORDER BY node.lft;

+----------------------+---------------------+| name | COUNT(product.name) |+----------------------+---------------------+| ELECTRONICS | 10 || TELEVISIONS | 5 || TUBE | 2 || LCD | 1 || PLASMA | 2 || PORTABLE ELECTRONICS | 5 || MP3 PLAYERS | 2 || FLASH | 1 || CD PLAYERS | 2 || 2 WAY RADIOS | 1 |+----------------------+---------------------+

This is our typical whole tree query with a COUNT and GROUP BY added, along with a reference to the product table and ajoin between the node and product table in the WHERE clause. As you can see, there is a count for each category and thecount of subcategories is reflected in the parent categories.

Adding New Nodes

Now that we have learned how to query our tree, we should take a look at how to update our tree by adding a new node. Let'slook at our nested set diagram again:

If we wanted to add a new node between the TELEVISIONS and PORTABLE ELECTRONICS nodes, the new node would havelft and rgt values of 10 and 11, and all nodes to its right would have their lft and rgt values increased by two. We would thenadd the new node with the appropriate lft and rgt values. While this can be done with a stored procedure in MySQL 5, I willassume for the moment that most readers are using 4.1, as it is the latest stable version, and I will isolate my queries with aLOCK TABLES statement instead:

LOCK TABLE nested_category WRITE;


9 of 13 7/9/08 11:59 AM


SELECT @myRight := rgt FROM nested_categoryWHERE name = 'TELEVISIONS';

UPDATE nested_category SET rgt = rgt + 2 WHERE rgt > @myRight;UPDATE nested_category SET lft = lft + 2 WHERE lft > @myRight;

INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES', @myRight + 1, @myRight + 2);

UNLOCK TABLES;

We can then check our nesting with our indented tree query:

SELECT CONCAT( REPEAT( ' ', (COUNT(parent.name) - 1) ), node.name) AS nameFROM nested_category AS node,nested_category AS parentWHERE node.lft BETWEEN parent.lft AND parent.rgtGROUP BY node.nameORDER BY node.lft;

+-----------------------+| name |+-----------------------+| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || GAME CONSOLES || PORTABLE ELECTRONICS || MP3 PLAYERS || FLASH || CD PLAYERS || 2 WAY RADIOS |+-----------------------+

If we instead want to add a node as a child of a node that has no existing children, we need to modify our procedure slightly.Let's add a new FRS node below the 2 WAY RADIOS node:


SELECT @myLeft := lft FROM nested_category

WHERE name = '2 WAY RADIOS';

UPDATE nested_category SET rgt = rgt + 2 WHERE rgt > @myLeft;UPDATE nested_category SET lft = lft + 2 WHERE lft > @myLeft;

INSERT INTO nested_category(name, lft, rgt) VALUES('FRS', @myLeft + 1, @myLeft + 2);

UNLOCK TABLES;

In this example we expand everything to the right of the left-hand number of our proud new parent node, then place the nodeto the right of the left-hand value. As you can see, our new node is now properly nested:


+-----------------------+| name |+-----------------------+


10 of 13 7/9/08 11:59 AM


| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || GAME CONSOLES || PORTABLE ELECTRONICS || MP3 PLAYERS || FLASH || CD PLAYERS || 2 WAY RADIOS || FRS |+-----------------------+

Deleting Nodes

The last basic task involved in working with nested sets is the removal of nodes. The course of action you take when deleting anode depends on the node's position in the hierarchy; deleting leaf nodes is easier than deleting nodes with children becausewe have to handle the orphaned nodes.

When deleting a leaf node, the process if just the opposite of adding a new node, we delete the node and its width from everynode to its right:


SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1FROM nested_categoryWHERE name = 'GAME CONSOLES';

DELETE FROM nested_category WHERE lft BETWEEN @myLeft AND @myRight;

UPDATE nested_category SET rgt = rgt - @myWidth WHERE rgt > @myRight;UPDATE nested_category SET lft = lft - @myWidth WHERE lft > @myRight;

UNLOCK TABLES;

And once again, we execute our indented tree query to confirm that our node has been deleted without corrupting thehierarchy:


+-----------------------+| name |+-----------------------+| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || PORTABLE ELECTRONICS || MP3 PLAYERS || FLASH || CD PLAYERS || 2 WAY RADIOS || FRS |+-----------------------+

This approach works equally well to delete a node and all its children:


11 of 13 7/9/08 11:59 AM



SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1FROM nested_categoryWHERE name = 'MP3 PLAYERS';

DELETE FROM nested_category WHERE lft BETWEEN @myLeft AND @myRight;

UPDATE nested_category SET rgt = rgt - @myWidth WHERE rgt > @myRight;UPDATE nested_category SET lft = lft - @myWidth WHERE lft > @myRight;

UNLOCK TABLES;

And once again, we query to see that we have successfully deleted an entire sub-tree:


+-----------------------+| name |+-----------------------+| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || PORTABLE ELECTRONICS || CD PLAYERS || 2 WAY RADIOS || FRS |+-----------------------+

The other scenario we have to deal with is the deletion of a parent node but not the children. In some cases you may wish tojust change the name to a placeholder until a replacement is presented, such as when a supervisor is fired. In other cases, thechild nodes should all be moved up to the level of the deleted parent:


SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1FROM nested_categoryWHERE name = 'PORTABLE ELECTRONICS';

DELETE FROM nested_category WHERE lft = @myLeft;

UPDATE nested_category SET rgt = rgt - 1, lft = lft - 1 WHERE lft BETWEEN @myLeft AND @myRight;UPDATE nested_category SET rgt = rgt - 2 WHERE rgt > @myRight;UPDATE nested_category SET lft = lft - 2 WHERE lft > @myRight;

UNLOCK TABLES;

In this case we subtract two from all elements to the right of the node (since without children it would have a width of two), andone from the nodes that are its children (to close the gap created by the loss of the parent's left value). Once again, we canconfirm our elements have been promoted:

SELECT CONCAT( REPEAT( ' ', (COUNT(parent.name) - 1) ), node.name) AS nameFROM nested_category AS node,nested_category AS parent


12 of 13 7/9/08 11:59 AM


WHERE node.lft BETWEEN parent.lft AND parent.rgtGROUP BY node.nameORDER BY node.lft;

+---------------+| name |+---------------+| ELECTRONICS || TELEVISIONS || TUBE || LCD || PLASMA || CD PLAYERS || 2 WAY RADIOS || FRS |+---------------+

Other scenarios when deleting nodes would include promoting one of the children to the parent position and moving the childnodes under a sibling of the parent node, but for the sake of space these scenarios will not be covered in this article.

Final Thoughts

While I hope the information within this article will be of use to you, the concept of nested sets in SQL has been around forover a decade, and there is a lot of additional information available in books and on the Internet. In my opinion the mostcomprehensive source of information on managing hierarchical information is a book called Joe Celko's Trees and Hierarchiesin SQL for Smarties, written by a very respected author in the field of advanced SQL, Joe Celko. Joe Celko is often creditedwith the nested sets model and is by far the most prolific author on the subject. I have found Celko's book to be an invaluableresource in my own studies and highly recommend it. The book covers advanced topics which I have not covered in thisarticle, and provides additional methods for managing hierarchical data in addition to the Adjacency List and Nested Setmodels.

In the References / Resources section that follows I have listed some web resources that may be of use in your research ofmanaging hierarchal data, including a pair of PHP related resources that include pre-built PHP libraries for handling nestedsets in MySQL. Those of you who currently use the adjacency list model and would like to experiment with the nested setmodel will find sample code for converting between the two in the Storing Hierarchical Data in a Database resource listedbelow.

© 1995-2008 MySQL AB. All rights reserved.


13 of 13 7/9/08 11:59 AM

Factureringsproces - TU Delft

Documents

Transcript of Factureringsproces - TU Delft