icafe Een digitaal bestelsysteem voor de horeca

Transcriptie

1 icafe Een digitaal bestelsysteem voor de horeca Joeri Verdeyen Stefaan De Spiegeleer Naim Ben Tanfous Promotor: Philippe Van Laethem Toegepaste Informatica 3e Bachelor

2 blanco pagina 1

3 Synopsis Een bestelsysteem voor de horeca is de beknopte beschrijving en titel van het eindwerk icafe. De gedachtegang was een systeem waarmee klanten in een horecazaak bestellingen ingeven via een computerscherm, door middel van een touchscreen. Het touchscreen werd gebruikt als vervanging van de muis en is hiermee ook gebruiksvriendelijker. De bestelling zal verwerkt worden door een systeem dat verbonden is met de computer waarop de klant zijn bestelling ingeeft. Dit systeem geeft op zijn beurt de gegevens van de bestelling door naar de computer van een barman. Op deze computer is de bestelling af te lezen. Concreet zou deze gang van zaken ervoor zorgen dat obers geen bestellingen aan tafel meer moeten opnemen. Het gehele systeem werd gerealiseerd door een groep van drie informatica studenten. Het geheel ging van start door een brainstorm van ideeën op tafel te gooien. Deze ideeën werden in schema s omgezet en uiteindelijk in een applicatieontwerp gestoken. Na verscheidene meetings om de verschillende gedachtegangen samen te voegen werd het programmeerwerk verdeeld. De programmeertaal die werd gebruikt is PHP5, om gegevens permanent op te slaan werd gebruik gemaakt van een MySQL database. Deze combinatie zorgt er voor dat het systeem web-based is en dus kan werken op alle besturingsystemen die een internet browser hebben. Er werden ook drie verschillende applicaties ontworpen. Een applicatie voor de administratie, een applicatie voor de klant en een applicatie voor de barman. Zowel klant als barman werden gemaakt in Flash, om de interface zo gebruiksvriendelijk te maken. De administratie werd geschreven met behulp van HTML, CSS, en Smarty Templates. Er werd een basis geschreven die uit klassen bestond. Uit deze klassen kunnen dan objecten voortvloeien zoals producten en bestellingen. Deze basis wordt gebruikt door de drie applicaties waardoor de communicatie vlekkeloos verloopt. Na vele uren programmeren, debuggen en aanpassen werkt het systeem met het gewenste resultaat. Echter bleef het systeem bij een basisontwerp zonder echt verbluffende uitbreidingen. Er mag wel verondersteld worden dat er veel bijgeleerd is en er een goede band ontstaan is tussen de drie leden. 2

4 Inhoudsopgave 1 Inleiding 8 2 icafe Het probleem Het concept Voordelen Werking Droom Project Verdeling van de taken Klassen Applicaties Communicatie Chat Meetings SVN Forum Fases Brainstormen Scenario s

5 Inhoudsopgave 4.3 Diagrammen Database Ontwerp Klassen Applicaties Admin Client - Barman Client - Klant Testfase Afwerking Verslag icafe engineering Programmeertaal PHP MySQL database Adobe Flash Smarty Template Engine Web templates Onze aanpak Smarty Software Eclipse IDE XAMPP Tortoise SVN Problemen Samenwerking Engineering Verwijderen van producten Gepriviligeerde woorden

6 Inhoudsopgave 6.3 Computers Tortoise SVN Apache / MySQL Besluit 44 8 Eigen Beoordeling Naim Zelfreflectie Stef Joeri Stef Zelfreflectie Naim Joeri Joeri Zelfreflectie Naim Stef Tweede Zittijd Opdracht Verbetering Uitbreiding Database Klassen Barman Client Testen

7 Inhoudsopgave 10 Bronvermelding 55 A Ingediend voorstel 57 B Scenario s 61 B.1 Administrator Joeri B.1.1 Voorstelling B.1.2 Situatie B.1.3 De kassa B.1.4 Voorraad B.1.5 Wijzigingen van het menu B.1.6 Preview B.1.7 De mogelijkheden B.2 Client Stef B.3 Administrator Stef B.4 Barman Stef B.5 Client Naim B.6 Barman Naim B.7 Administrator Naïm C Diagrammen 74 C.1 Database ontwerp D Verslagen van vergaderingen 76 D.1 Vergadering D.2 Vergadering D.3 Vergadering D.4 Vergadering D.5 Vergadering D.6 Vergadering met promotor

8 Inhoudsopgave E Diverse bestanden 98 E.1 Toelichting relaties tussen objecten E.2 Toelichting stockbeheer

9 Hoofdstuk 1 Inleiding Op een donderdagavond diep in het jaar 2006 ging Stef iets drinken met de vrienden. Zoals vaak op donderdag was er aan volk geen gebrek. Zo was het telkens er besteld moest worden een hele onderneming om een barman te vinden die je bestelling kon opnemen, en was het nog een grotere onderneming om door al het volk naar de toog te stappen om daar te bestellen. Ook bij de vrienden vormde dit bij elke bestelling tot kleine irritaties. Deze irritaties vormden een abstract idee: Wat als je de bestelling kon plaatsen vanop de plaats waar je je bevond? Gedaan met wachten op een ober, gedaan met de krachtmeting tussen jezelf en de massa mensen onderweg naar de toog. De volgende dag werd het probleem besproken met Joeri en Naim en ook zij zagen hier graten in. Uit deze gesprekken bleek al snel dat dit project een enorm potentieel had. Het abstract idee was geëvolueerd naar een realiteit en icafe was geboren. Verderop in dit verslag kan je lezen wat de concrete oplossing is die er voor het probleem gevonden is. Ook vind je er onder andere informatie over de aanpak van het project aangepakt, de taken onderling verdeeld zijn en welke fasen er doorlopen zijn om tot ons eindproduct te kunnen komen. Aangezien we met 3 leden zijn was naast de takenverdeling eveneens de coördinatie belangrijk, en dus ook dit is in het verslag terug te vinden. 8

10 Hoofdstuk 2 icafe 2.1 Het probleem Bij drukke cafés is het vaak een probleem dat de klanten lang moeten wachten om hun bestelling te plaatsen. De barmensen zijn vaak druk bezig met het verwerken van bestellingen en kunnen maar sporadisch kijken of er mensen willen bestellen. Als het café vol zit is het een belemmering voor de barman om een bestelling op te nemen en voor de klant om een bestelling te plaatsen. Een oplossing voor dit probleem zou een applicatie kunnen zijn waarmee de klant zijn bestelling kan plaatsen zonder tussenkomst van de barman. icafe is deze applicatie. Een digitaal bestelsyteem afgestemd op de horeca, en cafés in het bijzonder. 2.2 Het concept Eens een klant heeft plaatsgenomen aan een tafel, kan deze zijn bestelling doorgeven via een touchscreen dat zich in het midden van de tafel bevindt. Zolang hij zijn bestelling niet bevestigd heeft kan hij producten toevoegen, verwijderen of het aantal hiervan wijzigen. Bij het touchscreen van de barman komen de bestellingen binnen en worden deze weergegeven volgens tafel. Hij maakt deze bestellingen klaar en bezorgt deze aan de klant. Wanneer de klant betaald heeft, zet hij de bestelling op 9

11 Hoofdstuk 2. icafe afgehandeld en begint hij aan de volgende bestelling. Een admin zorgt voor de algemene configuratie zoals het toevoegen van producten, prijzen, overzicht van bestellingen, overzicht per datum, overzicht per product, voorraad, verdeling van clients, positionering van clients. 2.3 Voordelen Het voordeel voor de klant bestaat erin dat hij niet meer afhankelijk is van de barman die de bestelling moet komen opnemen, wat bij drukke etablissementen wel enige tijd kan aanslepen. Dus ook bij een café waar je je bestellingen zelf moet doorgeven/halen aan de bar brengt icafe voordelen, aangezien je niet meer naar de bar moet gaan. De barman haalt zijn voordeel uit het feit dat hij maar één keer per bestelling naar de klant moet lopen. Hij moet nu enkel de producten aan de klant leveren, terwijl hij zonder icafe de bestelling moest opnemen én leveren. Voor de eigenaar van het café is dit uiteraard een investering, maar we zijn ervan overtuigd dat dit niet enkel als een Gadget kan gezien worden, maar dat het in een druk cafés een rendabele investering is. Via icafe is hij ondermeer in staat om zijn voorraad te beheren, makkelijk de opbrengst per avond te bekijken enz. 2.4 Werking Er zijn 3 delen die hardwarematig van elkaar gescheiden zijn, nl. de server, de barmancomputer en één of meerdere klantcomputers (zie figuur). Op de server worden de apache-server, de database en de PHP bestanden gehost. De barman- en klantcomputer surfen via een draadloze connectie naar het IP adres van de server met het gewenste pad achter. De applicaties worden afgebeeld in een internetbrowser met Flash plugin. 10

12 Hoofdstuk 2. icafe 2.5 Droom Onze droom eens de code op punt stond bestond erin om icafe te commercialiseren. Ook zouden er nog enkele leuke functies toegevoegd worden, zoals de connectie met muziekapplicatie. Dit zou het mogelijk maken om af te beelden welk nummer er momenteel aan het afspelen is, en dit eventueel te beoordelen. Dit maakt het ook mogelijk om de volledige muziekdatabase te bekijken, evenals dat de klant zelf kan bepalen welk nummer hij wil horen. 11

13 Hoofdstuk 3 Project 3.1 Verdeling van de taken Voor alle opdrachten die er gemaakt zijn is er een taakverdeling opgesteld. Deze taakverdeling werd soms bepaald door factoren als kennis, ervaring en dergelijke. Maar de meeste verdelingen gebeurden louter door de opdrachten in drie te delen. Zo werden er bepaalde personen verantwoordelijk voor bepaalde klassen en werden de drie applicaties in het systeem toegekend aan iedere persoon Klassen De klassen werden ingedeeld aan de hand van het opgestelde klassendiagram. Op dit klassendiagram waren duidelijk drie groepen te zien die dicht bij elkaar lagen, en waar dus bepaalde klassen in de andere gebruikt werden. Het was ook vanzelfsprekend dat er bij iedere klasse die geschreven werd een duidelijk commentaar aanwezig was. Naderhand moest iedereen van deze klassen gebruik kunnen maken zonder de gehele functies opnieuw te moeten nalezen. Er werd in het begin van het project ook gebruik gemaakt van PHPdoc. PHPdoc is een open-source tool die net hetzelfde doet als JavaDoc. Het is een soort commando waar aan de hand van de code HTML pagina s aangemaakt worden die een API-documentatie bevatten. Deze API-documentatie geeft aan welke variabelen en methodes er zijn in een klasse en wat deze doen. 12

14 Hoofdstuk 3. Project De documentatie wordt uitgelezen aan de hand van bepaalde commentaartekens in de code. De volgende personen namen volgende verantwoordelijkheid van de klassen op zich. (Meer informatie over deze klassen is te vinden onder 4.4 ) Joeri Klassen die te maken hebben met producten, menustructuur en mysqlverbinding Stef Klassen die te maken hebben met de gebruikers en de verificatie van gebruikers Naim Klassen die te maken hebben met bestellingen en wachtrijen Applicaties De verdeling van de applicaties werd meer gekozen aan de hand van kennis van zaken. Zo moest er een gedeelte geschreven worden aan de hand van HTML, CSS, Javascript, PHP en Smarty Templates en twee applicaties moesten gemaakt worden in Flash met behulp van ActionScript en achterliggende PHP code om gegevens op te halen. Het administratie gedeelte werd volledig geschreven in HTML, CSS, Javascript, PHP en met behulp van Smarty Templates. De twee clients, barman en klant werden gemaakt in Flash. De verdeling was duidelijk en door het gebruik van dezelfde klassen kon er weinig foutlopen met de afstemming op elkaar. Volgende verdeling werd toegepast: Joeri : Administratie Stef : Client applicatie voor de klant Naim : Client applicatie voor de barman 13

15 Hoofdstuk 3. Project 3.2 Communicatie Chat Voor de dagelijkse en minder omvangrijke communicatie werd gebruik gemaakt van chat. Het was te omslachtig om voor kleine vragen en opmerkingen te mailen of een meeting te organiseren. Een voorbeeld hiervan is het vragen van een kleine aanpassing aan een klasse. Indien het over algemene dingen ging over het project was het niet uitzonderlijk dat er een chat conference aangegaan werd om zo met 3 te overleggen Meetings De grotere onderwerpen van het project werden besproken tijdens meetings 1. Op deze meetings werden bijvoorbeeld allerhande dingen besproken die moesten uitgedacht worden. Zo werd er bv. gediscussieerd over de aanpak van de voorraadbeheer, het database ontwerp,...). Ook prangende en/of complexe vragen werden hier besproken, zoals het opzetten van de tortoise SVN client. Er werd dan ook getracht om de 2 weken eens samen te zitten. Op het einde van de meetings werd steeds een todo list gemaakt tegen de volgende meeting en werd de plaats en tijd van de volgende meeting vastgelegd SVN Voor de het delen van bestanden werd gebruik gemaakt van Subversion. Subversion is een versie beheersysteem dat toelaat om makkelijk en overzichtelijk met meerdere gebruikers aan dezelfde code te werken. Voor iemand aan een bestand werkt haalt deze de laatste versie van repository 2 af. Wanneer er aan bestanden gewerkt is wordt dit vervolgens geüpload naar een repository. 1 Voor de verslagen van de meetings zie bijlage D 2 Een repository is een online opslagplaats voor data 14

16 Hoofdstuk 3. Project Forum In hebt begin van dit project werd het forum 3 gebruikt om bestanden, handige links en allerhande informatie te delen (zoals inlog gegevens FTP). Het gebruik hiervan is geleidelijk aan afgenomen. Zo werden de bestanden bijvoorbeeld al via Subversion gedeeld en was het dubbel werk om dit ook nog eens via het forum te doen. 3 Het forum is te vinden op 15

17 Hoofdstuk 4 Fases 4.1 Brainstormen Bij het brainstormen werden allerhande ideeën op tafel gegooid. Veel ideeën die bij het tekenen van diagrammen en bij het programmeren niet meer gebruikt werden. Eén van de eerste ideeën was een digitaal jukebox systeem dat in het bestelsysteem zou worden opgenomen. Zo zou een klant een liedje kunnen aanvragen en zou de muziek in het café grotendeels door de klanten worden bepaald. Een digitaal bestelsysteem zoals bij Kinepolis, waarbij een klant gemakkelijk met een bankkaart zijn bestellingen zou kunnen betalen. Een systeem om bij netwerksleutels te verkopen om toegang te krijgen tot het draadloos netwerk van het café waardoor klanten op het internet kunnen surfen met hun laptop. Ook om het werken efficiënt te maken werd het gebruik van timesheets besproken. Aanvankelijk leek dit nuttig om te zien hoeveel tijd elk lid daadwerkelijk in het project steekt, maar na verloop van tijd werd dit opgegeven, omdat het toch niet zo nuttig leek. Allemaal ideeën die in het begin met het nodige enthousiasme werden onthaald, maar die niet in het systeem zijn geïmplementeerd omdat er vooral een tijdsgebrek was en het ons nuttiger leek om zeker een stevige basisapplicatie te hebben. 16

18 Hoofdstuk 4. Fases 4.2 Scenario s Voordat er diagrammen gemaakt werden, besliste de groep om uitgebreide scenario s 1 te schrijven. Elk groepslid zou een uitgebreid scenario schrijven zodat alle zaken zeker aan bod zouden komen. Met drie scenario s was de groep relatief zeker dat het niets over het hoofd had gezien. Scenario s bewijzen vooral hun nut in latere fases. Zo kan er al een grof overzicht worden bekomen over mogelijke problemen. Bij het opmaken van diagrammen kunnen de scenario s dan dienen als basis omdat alle mogelijkheden en problemen al in de scenario s werden besproken. 4.3 Diagrammen Gebaseerd op de geschreven scenario s werden er diagrammen 2 opgemaakt. De groep besloot om de belangrijkste diagrammen te maken die nodig zijn voor een project. Zo werd een databaseontwerp gemaakt, een klassendiagram, use cases, enkele flow charts, sequentiediagrammen en een menustructuur. De diagrammen werden gemaakt volgens de standaarden. Aan de hand van deze diagrammen kon de groep gemakkelijk de klassen en de database aanmaken. Naarmate het project vorderde bleek dat er soms zaken waren die ontbraken of die bij het opmaken van de diagrammen nog niet nodig waren. Het team probeerde altijd deze diagrammen toch aan te passen zodat ze altijd volledig waren Database Ontwerp Voor het database ontwerp werd er besloten om zoveel mogelijk op te splitsen in tabellen. Dit werd beslist op basis van de argumenten die enkele groepsleden aanhaalden betreffende snelheid en veiligheid. category Producten worden verdeeld in categorieën. Een product kan behoren tot één categorie. Een categorie heeft een parameter parent id die aangeeft of de categorie een subcategorie is van een andere categorie. Wanneer een categorie subcategorieën heeft kan hieraan geen 1 Voor scenario s zie bijlage B 2 Voor diagrammen zie bijlage C 17

19 Hoofdstuk 4. Fases product toegevoegd worden, om te voorkomen dat een product zweeft tussen een lijst van categorieën. Een categorie heeft een naam en beschrijving voor meer informatie. menu Een menu heeft een parent id. Dit houdt bij of het een hoofdmenu (parent id=0) of een submenu (parent id = id van het hoofdmenu) is. Verder wordt er bijgehouden op welke pagina de bezoeker zich bevindt en welke actie hij onderneemt op die pagina. orders Een order bevat producten die besteld zijn. Een order heeft verschillende statussen. Deze wordt bepaald aan de hand van 2 booleans, payement (bestelling betaald?) en delivered (bestelling geleverd?). Een order bevat ook een start tijd om aan te geven wanneer deze doorgestuurd werd. order product Een bestelling bestaat uit producten. Er moet dus een link zijn tussen producten en bestellingen. Deze bestellingen zullen hier gelinkt worden aan producten. product Een product heeft een naam en een id. Alle verdere informatie over de producten werd opgesplitst in de volgende tabellen. product category Dit is de tabel die een product aan een bepaalde categorie hangt. Beide kolommen zijn primary keys omdat elke combinatie van de 2 uniek is. product content De inhoud van een bepaald product kan ook meegegeven worden. Deze is niet verplicht in te vullen. Met inhoud wordt een maateenheid bedoeld. (bv. bij cocktails) product description Een product kan een beschrijving omvatten van één of meerdere lijnen. Dit veld is niet verplicht omdat niet elk product een beschrijving of informatie nodig heeft. product image Om een product aantrekkelijk te maken kan men een afbeelding toevoegen. Dit veld is niet verplicht in te vullen. product purchase price De aankoopprijs van een product. De prijs voor een eenheid die de administrator zelf betaalt. product sale price Aan elk product is een prijs gekoppeld. Deze wordt in een afzonderlijke tabel bijgehouden. Dit maakt het mo- 18

20 Hoofdstuk 4. Fases gelijk om eventueel een 2de soort prijs in te geven (bv. Aankoopprijs). Hier wordt de verkoopprijs gebruikt. product subtitle Elk product bevat een ondertitel die een kleine beschrijving omvat. Deze is niet verplicht in te vullen maar wel aan te raden voor producten die niet bij iedereen gekend zijn. product tax De tabel die een bepaalde tax rate aan een product hangt. session Een sessie bevat orders die op zich dan weer producten bevat. Een sessie heeft een start en eind tijd en een tafel nummer. session order De tabel die bepaalt welke bestelling(en) bij welke sessie horen. stock Elk product heeft een bepaalde voorraad, het beschikt over het soort stock, in dit soort stock wordt bepaald of het automatisch wordt verminderd bij verkoop van een eenheid of het handmatig moet gebeuren. stock type Het type stock dat gemaakt kan worden. Bv Vat, Fles, Glas, enz. Aan de hand van de type parameter wordt de naam bepaald. De autostock geeft aan of het verrekend wordt bij de verkoop van een product. Content geeft de inhoud aan. Dit is een louter informatieve indicator. (bv. Vat 30L, Vat 50L) tablelist Een tabel met de id s, namen en ip-adressen van tafels. tax Verschillende BTW-tarieven die een bepaalde waarde kunnen hebben en een naam. user Elke gebruiker wordt in de database bijgehouden, deze kan verschillende rechten hebben. Hierbij worden gebruikers gezien als admin, barman,... user data De gegevens die aan een gebruiker gekoppeld zijn. user order Geef weer welke orders door welke gebruiker verwerkt zijn (optie). user password Het password dat aan user account gekoppeld is om in bepaalde systemen in te loggen. Deze kan eventueel geëncrypteerd worden. user type Het type dat bepaalt welke rechten de gebruiker heeft. 19

21 Hoofdstuk 4. Fases 4.4 Klassen Na het maken van de diagrammen en het implementeren van de database, kon de groep beginnen aan het programmeren van de PHP klassen. Deze klassen zouden de grondlaag vormen van het project. Daarom werd er besloten om goede afspraken te maken omtrent deze klassen. Zo moest de benaming strikt gevolgd worden en moesten enkele functies zeker opgenomen worden. Elke klasse moest zijn naam hebben gevolgd door.class.php. Category Om producten op te delen werd er gebruik gemaakt van een hiërarchie van categorieën. Deze categorieën hebben een unieke naam en beschrijving als verduidelijking. De categorie klasse is in staat na te gaan of de categorie wel of niet subcategorieën bevat. Verder kan het al zijn subcategorieën ophalen. Aan de hand van deze methoden is het mogelijk een volledig schema op te bouwen. Product De product klasse zorgt voor de aanmaak van producten. Producten kunnen opgehaald worden volgens hun categorie, en zo kunnen hele lijsten opgesteld worden. Aan de hand van verschillende methoden kunnen de prijzen inclusief en exclusief BTW berekend worden. Met een product object is het ook mogelijk om de huidige voorraad van een product bij te werken indien nodig. Er zijn ook methodes geïmplementeerd die nakijken of de naam van het product uniek is wanneer er een nieuw product wordt aangemaakt. Menu De menu klasse is alleen van toepassing op het administratie gedeelte van het systeem. Deze applicatie heeft een uitgebreide menustructuur, met hoofdmenu s die nadien onderverdeeld worden in submenu s. Deze items vragen verschillende pagina s op met verschillende variabelen. Aan de hand van een menu object kan er dus nagegaan worden welke pagina er moet weergegeven worden en welke functie de pagina moet tonen. Verder is het aan de hand van menu-object zeer makkelijk om het menu aan te passen. Een menu object is in staat om na te kijken of het submenu s bevat en deze nadien ook op te halen. Error De error klasse is een kleine klasse die geschreven werd voor het debuggen. Er kon simpelweg een object van de error klasse aangemaakt worden, hierin geeft men een foutmelding mee en deze wordt 20

22 Hoofdstuk 4. Fases getoond op het scherm. Aan de hand van deze boodschap was het dan makkelijk om na te gaan waar de fout zich bevindt. MySQL Aangezien er steeds een verbinding met de database gemaakt moest worden, werd hiervoor een klasse geschreven. Wanneer een object werd aangemaakt, werd er een verbinding gemaakt met de database. Bij het afbreken (destructor) van het object werd de verbinding gesloten. Dit is makkelijker dan steeds opnieuw manueel een verbinding aan de hand van de hiervoor geschreven in PHP geschreven functies te maken. De klasse gebruikt deze functies, maar op een efficiëntere manier. Stock De stock klasse houdt zich voornamelijk bezig met de voorraadtypen. Elk stock object is een voorraad type waaraan bepaalde parameters worden meegegeven. Dit kan bijvoorbeeld de unieke id van een product zijn, er kan dan opgehaald worden hoeveel voorraad er aanwezig is en wat het voorraadtype is. Tax De tax klasse wordt gebruikt om de Btw-tarieven bij te houden. Er kan een Btw-tarief object aangemaakt worden en nadien weggeschreven worden naar de database. Deze tarieven kunnen naderhand gebruikt worden om aan een product toe te kennen. Session Een sessie bestaat wanneer klanten plaatsnemen aan een tafel en bestellen. Er wordt een sessie geopend wanneer klanten aankomen en voor de eerste keer bestellen. Bij elke betaling wordt de sessie afgesloten en wordt er bij de volgende bestelling van deze tafel een nieuwe sessie gestart. In de database worden de starttijd, eindtijd en tafel van de sessie bijgehouden, alsook de id s van de bestellingen die bij deze sessie horen. Order Een order is de bestelling die door klanten wordt geplaatst. Een bestelling bestaat uit één of meerdere producten. Daarnaast krijgt een bestelling een starttijd om een idee te hebben hoe lang het al geleden is dat een klant heeft besteld. Een order heeft een prijs, die berekend wordt aan de hand van de prijs van de producten. Verder wordt er bijgehouden of een order betaald geweest is en of een order geleverd geweest is. Tenslotte houdt een order het id van de tafel bij dat wordt opgehaald aan de hand van de sessie. 21

23 Hoofdstuk 4. Fases Queue Een Queue houdt een array van orders bij die niet betaald geweest zijn en een array van orders die niet geleverd geweest zijn. Table Een tafel bestaat uit een id, een ip-adres en een naam. Zo is elke tafel uniek in het systeem. Er kan een lijst van alle tafels in het systeem worden opgevraagd. 4.5 Applicaties Admin Het administrateur gedeelte van de applicatie zal ervoor zorgen dat de hoofdeigenaar over de mogelijkheden beschikt om de nodige gegevens te wijzigen. Dit zijn gegevens gaande van producten tot gebruikers van het systeem. Er kan gebruik gemaakt worden van dit systeem door in te loggen met een passende gebruikersnaam en wachtwoord. De gebruikersnaam en wachtwoord kunnen verkregen worden bij de algemene beheerder van het systeem. Wanneer men succesvol inlogt, wordt er een korte inleidende tekst weergegeven met enkele gegevens uit het systeem. Zo wordt er weergegeven hoeveel producten er totaal aanwezig zijn in de database van het systeem. Ook het aantal categorieën, de producten die weinig of geen voorraad hebben. Het totaal aantal orders worden gebruikt om de inleidende tekst zo volledig mogelijk te maken. De administratie zou geen administratie zijn als er geen beheer aan te pas komt. Zo wordt de applicatie opgesplitst in verschillende modules. Onder de modules kan men volgend onderscheid maken: Product beheer Het algemeen beheer van producten. Dit gedeelte beperkt zich tot de aanmaak van producten. Categorie beheer Het beheer van categorieën, dat verantwoordelijk is voor de opsplitsing van producten. BTW beheer Het beheer van de BTW tariefgroepen. Voorraad beheer Het beheer van de voorraad types en voorraad aantal. 22

24 Hoofdstuk 4. Fases Gebruiker beheer Het beheer voor de gebruikers van het systeem, wijziging van wachtwoord. Order beheer Overzicht van de orders. Configuratie Het beheer van de tafels en database back-up. In volgende punten zal er dieper ingegaan worden op deze modules. Product beheer Het gehele systeem draait rond verkoop van producten. Hierbij zijn de producten nagenoeg het belangrijkste onderwerp. Hiervoor is er dus het product beheer voorzien, dat ervoor zorgt dat producten kunnen toegevoegd, gewijzigd of verwijderd worden. Een product beschikt natuurlijk over verschillende eigenschappen zoals naam, prijs en dergelijke. Deze gegevens zijn dan ook in te voeren bij het aanmaken van een nieuw product. Een product beschikt over volgende gegevens: Naam De algemene naam van het product dat gebruikt wordt als referentie. Deze naam wordt het meest gebruikt als herkenningspunt voor het betreffende product. In feite zou een product aan de hand van deze naam volledig duidelijk moeten zijn. Product categorie Om de producten op te splitsen werd er gebruik gemaakt van categorieën, welke het overzichtelijk maken om de producten weer te geven. Zie pagina 24 voor meer informatie over categorieën. BTW-tarief Omdat er in België verschillende BTW-tarieven zijn kunnen deze afzonderlijk gekozen worden voor elk product. Een BTW-tarief wordt toegekend aan een product, hiermee wordt het verkoopbedrag berekend. Zie pagina 26 voor meer informatie over BTW-tarieven. Verkoopprijs De verkoopprijs van een product is de prijs die er aan de klant gevraagd zal worden. Bij deze prijs moet de BTW nog toegevoegd worden. Aankoopprijs De aankoopprijs van één eenheid van het product dat betaald werd aan de leverancier. Deze prijs is louter indicatief en wordt gebruikt als hulpmiddel voor de gebruikers. 23

25 Hoofdstuk 4. Fases Ondertitel De ondertitel van een product bevat een korte beschrijving. Er kunnen bepaalde gegevens of eigenschappen van het product inzitten die meer duidelijkheid scheppen. Zo kan er bijvoorbeeld bij een fles Champagne meegegeven worden van welk jaar deze is. De ondertitel is optioneel en kan gebruikt worden voor verduidelijking. Beschrijving De volledige beschrijving van het product bevat uitgebreide informatie, gaande van inhoud tot geschiedenis van een product. De beschrijving is optioneel. Inhoud De inhoud van het product bevat informatie aangaande de effectieve inhoud. Bijvoorbeeld het aantal liters aanwezig in een vat bier. Dit gegeven is optioneel en kan gebruikt worden ter verduidelijking. Voorraad-type Een product beschikt over een voorraad, maar niet elk product wordt in hetzelfde medium verkocht, hiervoor kunnen verschillend voorraadtypen aangemaakt worden. Zie op pagina 26 voor meer informatie over BTW-tarieven. Voorraad aantal De effectieve voorraad van een product uitgedrukt in een getal. Afbeelding Een afbeelding van het betreffende product. De afbeelding is optioneel en kan gebruikt worden ter verduidelijking. Deze gegevens zijn in te voeren bij het aanmaken van een nieuw product, en kunnen naderhand herzien worden. Er zijn twee verschillende methodes aanwezig om een product te selecteren om te bewerken of te verwijderen. Er is een methode aanwezig waarbij de categorie van het gewenste product geselecteerd wordt en nadien het gewenste product. En er is ook een methode die een volledig overzicht geeft in een soort lijst waarbij men het gewenste product kan aanklikken. De producten worden in deze lijst gesorteerd volgens hun categorie. Categorie beheer Aangezien er een ongelimiteerd aantal producten toegevoegd kan worden, kan dit voor een onduidelijk overzicht zorgen. Hierdoor zijn er product 24

26 Hoofdstuk 4. Fases categorieën, die ervoor zorgen dat elk product thuis zal horen onder een bijpassende categorie. Er zijn twee soorten categorieën, de hoofdcategorie en de subcategorie. Een hoofdcategorie is een categorie die een of meerdere subcategorieën kan bevatten. Hieronder kan men verstaan dat er een soort hiërarchie onstaat tussen deze categorieën. Een subcategorie wordt steeds geplaatst onder een hoofdcategorie. Door het gebruik van deze hiërarchie zijn er ook enkele beperkingen opgesteld. Zo kunnen er geen drijvende producten toegevoegd worden. Drijvende producten zijn producten die onder een hoofdcategorie staan waarbij deze hoofdcategorie ook subcategorieën heeft. Dit zou er voor zorgen dat er producten op hetzelfde niveau staan als categorieën, wat voor onduidelijkheden kan zorgen. Verder zijn er maar twee niveaus van categorieën, respectievelijk hoofd -en subcategorie. Een categorie bevat enkele gegevens: Naam De naam die als referentie wordt gebruikt voor de categorie. Deze naam moet zorgvuldig gekozen worden om de juiste producten terug te vinden. Beschrijving Om een categorie te verduidelijken kan een beschrijving toegevoegd worden. Dit is optioneel en kan gebruikt worden ter verduidelijking. Bovenliggende categorie Hier wordt bepaald of de categorie een hoofdof subcategorie zal worden. Wanneer men hier geen als bovenliggende categorie aangeeft, is het duidelijk dat het om een hoofdcategorie gaat. Alsnog heeft men de keuze uit alle andere hoofdcategorieën om hieronder de categorie als subcategorie aan te maken. Deze gegevens zijn in te voeren bij het aanmaken van een nieuwe categorie, en kunnen naderhand herzien worden. Door de categorie te selecteren kan men deze volledig bewerken of verwijderen. Aangezien de hoofdcategorieën over één of meerdere subcategorieën kan beschikken zijn er bepaalde restricties bij het verwijderen. Wanneer er een hoofdcategorie verwijderd wordt die één of meerdere subcategorieën bevat 25

27 Hoofdstuk 4. Fases wordt er een foutmelding weergegeven. Deze actie is wel mogelijk indien duidelijk aangegeven. Voor deze actie is een selecteer knopje beschikbaar. BTW beheer In België zijn er verschillende BTW-tarieven van toepassing op verschillende producten. Hierdoor is er de mogelijkheid om deze BTW tarieven aan te maken en te bewerken. Een BTW-tarief beschikt over volgende gegevens: BTW percentage Het percentage op de prijs dat de BTW voor een bepaald product berekend. BTW naam De naam van een BTW tarief is een soort referentie. Het is dan ook aan te raden om het percentage hierin te laten voorkomen, zodanig dat er bij later gebruik geen misverstanden gebeuren. Deze gegevens zijn in te voeren bij het aanmaken van een nieuw BTWtarief en kunnen naderhand herzien worden. Door een BTW-tarief te selecteren kan men deze bewerken of verwijderen. Nagenoeg kan men geen BTW-tarief verwijderen dat reeds aan producten is toegezegd. Voorraad beheer Het voorraad beheer zorgt ervoor dat er aan producten kan meegegeven worden in welk medium deze verkocht worden. Aangezien niet elk product in hetzelfde medium verkocht wordt kunnen deze aangemaakt worden. Hierbij kan dan bepaald worden of het ook de voorraad van het product automatisch moet bewerken bij het afhandelen van een bestelling. Het medium waarin een product verkocht wordt, wordt beschreven als een voorraadtype. Een voorraadtype beschikt over volgende gegevens: Type naam De referentie van het voorraadtype. Uit deze naam zal er afgeleid worden over welk medium het gaat. Het is dan ook aan te raden dat hiervoor een zeer gebruikelijk en duidelijk naam wordt gezocht. Autostock Bij dit gegeven heeft men twee keuzes, Aan en Uit. Deze autostock waarde zal bepalen of bij het afhandelen van een bestelling de voorraad automatisch verwerkt wordt. 26

28 Hoofdstuk 4. Fases Inhoud De inhoud van het medium. Aangezien er meerdere soorten flessen bestaan met verschillende inhoud, zal er hier beschreven worden hoeveel de capaciteit van het voorraadtype is. Deze gegegevens zijn in te voeren bij het aanmaken van een nieuw voorraadtype en kunnen naderhand hezien worden. Door het voorraadtype te selecteren kan men deze volledig bewerken of verwijderen. Het is niet mogelijk om voorraadtypen te verwijderen als deze in gebruik zijn door bepaalde producten. Verder is het mogelijk om de voorraad van de producten te bekijken. Er wordt een lijst van producten weergegeven volgens categorieën. In deze lijst is het mogelijk te bekijken welke producten een specifiek voorraadtype toegekend kregen. Het is ook mogelijk om de hoeveelheid voorraad te bekijken en deze aan te passen indien nodig. Aan de hand van de icoontjes naast de producten zal er duidelijk gemaakt worden of er aandacht moet besteed worden aan de product voorraad. Gebruikersbeheer Aangezien er in het systeem ingelogd moet worden, zowel in het administratie gedeelte als in de andere applicaties, zal het mogelijk zijn om gebruikers toe te voegen die de rechten krijgen om het systeem te gebruiken. Er kunnen alleen gebruikers aangemaakt worden vanuit het administratie gedeelte. De gebruikers krijgen een gebruikersnaam en een wachtwoord die zal gebruikt worden om toegang te krijgen tot het systeem. Een gebruiker beschikt over volgende gegevens: Gebruikersnaam De unieke naam die tevens ook als referentie voor een gebruiker wordt gebruikt. De gebruikersnaam zal zorgvuldig gekozen moeten worden en kan achteraf niet gewijzigd worden. Wachtwoord Dit wachtwoord is samen met de gebruikersnaam nodig om toegang te krijgen tot het systeem. Het wachtwoord is persoonlijk en mag niet doorgegeven worden aan derden. Wanneer een gebruiker zijn wachtwoord ontgaan is, kan dit gewijzigd worden door een andere gebruiker die toegang heeft tot het administratie systeem. 27

29 Hoofdstuk 4. Fases Echte naam De voornaam van de gebruiker. Familienaam De familienaam van de gebruiker. Er wordt gebruik gemaakt van dit gegeven als eventuele verduidelijking bij identieke voornamen. Adres Het adres waar de gebruiker momenteel verblijft. Het adres wordt louter informatief bijgehouden en kan eventueel gebruikt worden als hulpmiddel. Telefoon De huistelefoon van de gebruiker. Het nummer is louter informatie bijgehouden en kan eventueel gebruikt worden als hulpmiddel wanneer men contact zoekt met deze gebruiker. GSM De GSM nummer van de gebruiker. Het gebruik van de GSM nummer loopt analoog met dat van het telefoon nummer. Geboortedatum De datum waarop de gebruiker geboren is. Dit moet aantonen dat de gebruiker een leeftijd heeft die voldoet om legaal te werken. Dit wordt niet door het systeem nagekeken maar zal door de hoofdgebruiker zelf worden gecontroleerd. Student Aan de hand van de waarden Ja of Neen zal bepaald worden of de gebruiker een (job)student is of niet. Afbeelding De afbeelding van de gebruiker wordt louter informatief gebruikt. Wanneer het systeem in een grote onderneming gebruikt wordt kan dit handig zijn om bepaalde personen te herkennen. Deze gegevens zijn in te voeren bij het aanmaken van een nieuwe gebruiker, en kunnen naderhand herzien worden. Door een gebruiker te selecteren kan men de gegevens van deze gebruiker bewerken of de gebruiker verwijderen uit het systeem. Er kan echter ook gekozen worden om het wachtwoord van de gebruiker te wijzigen. Order beheer Het order beheer zorgt voor een algemeen overzicht van de orders of bestellingen die geplaatst zijn sinds de installatie van het systeem. 28

30 Hoofdstuk 4. Fases Aan de hand van order overzicht is er de keuze om een jaar aan te duiden. Deze selectie zal beperkt zijn tot de jaren waarin orders plaats vonden. Wanneer er een jaar geselecteerd is krijgt men meteen een klein overzicht. Dit overzicht omvat volgende punten: Totaal aantal bestellingen De som van alle bestellingen die dat jaar geplaatst zijn. Totaal verkoopbedrag incl. BTW Totaal verkoopbedrag excl. BTW Totaal aantal verkochte producten De som van alle producten die verkocht zijn bij al deze bestellingen. Wanneer er een jaar geselecteerd is, kan er ook een maand gekozen worden. Deze selectie zal ook beperkt zijn tot de maanden van het eerder geselecteerde jaar waarin orders plaatsvonden. Er wordt een identiek overzicht weergegeven zoals wanneer er een jaar geselecteerd werd. Ditmaal is het overzicht specifiek voor de geselecteerde maand van het geselecteerde jaar. Hierna wordt er een lijst weergegeven van de dagen waarop bestellingen plaatsvonden in de geselecteerde maand van het geselecteerde jaar. Door een dag te selecteren vormt er zich dus een unieke dag. Hierdoor wordt er voor deze dag ook een overzicht gegeven zoals hierboven beschreven. Verder worden er ook lijsten aangemaakt van alle bestellingen die die dag geplaatst zijn. Zo wordt er per bestelling een lijst met producten weergegeven, de verkoopprijs van deze producten, het totaalbedrag inclusief en exclusief BTW. Dit overzicht moet meer duidelijkheid scheppen in de bestellingen die op bepaalde dagen geregistreerd werden. Configuratie De configuratie houdt over het algemeen de instellingen van de tafels in. De tafels worden bepaald aan de hand van het IP dat ze instellen voor het netwerk. In dit gedeelte is het mogelijk om aan een bepaalde tafel (IP) een bepaalde naam te koppelen. 29

31 Hoofdstuk 4. Fases Een tafel beschikt over volgende gegevens: Naam De referentie van de tafel. Aan de hand van deze naam zal er duidelijk gemaakt worden over welke tafel gesproken wordt. De keuze van de naam is vrij. IP Het IP adres van de computer die op een bepaalde tafel staat. Deze gegevens zijn in te voeren bij het aanmaken van een nieuwe tafel en kunnen naderhand herzien worden. Door het selecteren van de tafel kan men deze volledig bewerken of verwijderen. Verder is er de mogelijkheid om een lokale back-up van de database te nemen. Dit houdt in dat alle gegevens die aanwezig zijn in de database worden opgeslagen in een enkele file. Deze file kan ervoor zorgen dat bij een crash van het database systeem een beperkt aantal gegevens verloren zal gaan. Natuurlijk is het de bedoeling dat er geen sprake is van een systeemcrash of dergelijke Client - Barman Een barman moet op een goeie manier de bestellingen kunnen bekijken die geplaatst geweest zijn. Hij moet die bestellingen kunnen wijzigen en markeren als geleverd en betaald, of geleverd en niet betaald. Hij moet ook de mogelijkheid hebben om de niet afgehandelde bestellingen van een tafel kunnen opvragen. Inloggen Voordat de barman de applicatie binnen mag, moet hij zich identificeren met een naam en wachtwoord. Deze naam en wachtwoord heeft hij gekregen van een admin. Zo herkent het systeem wie aan het werk is. Bestellingen Eenmaal ingelogd, ziet de barman alle gemaakte bestellingen. Hij kan nu de bestellingen voorbereiden. Wanneer een bestelling geleverd en betaald is, klikt hij op de bestelling. Er wordt nu in de database bijgehouden dat de bestelling en geleverd en betaald is. Als een bestelling wel geleverd is maar nog niet betaald klikt de barman op niet betaald. In de database wordt nu de waarde voor geleverd 30

32 Hoofdstuk 4. Fases gewijzigd en staat de betaling nog open. Als een bestelling gewijzigd moet worden klikt de barman op wijzigen. Hij komt nu in een scherm terecht waar hij producten kan toevoegen of verwijderen. Betalen Wanneer klanten aan een bepaalde tafel hun rekening vragen, klikt de barman op betalen. Hij moet nu kiezen in een lijst van tafels om de juiste rekening op te vragen. Hij klikt op de tafel en ziet zo de rekening van de tafel. Wanneer de klant betaalt, klikt hij op betaald en gaat hij verder met zijn bestellingen. Uitloggen Als de shift van de barman erop zit, kan hij gemakkelijk uitloggen door op de betreffende knop te klikken. De barman is nu uitgelogd en het systeem wacht nu op een barman die opnieuw inlogt Client - Klant Concept Een klant heeft de mogelijkheid om via een intuïtieve interface producten te bestellen, een order te wijzigen of producten te verwijderen. Bestellen Er kan een bestelling worden geplaatst door op de knop bestellen te klikken. Er wordt dan een overzicht getoond van de verschillende categorieen die beschikbaar zijn in de database (bijvoorbeeld cocktails ). Er kan op een categorie geklikt worden of er kan terug gegaan worden naar het menu. Indien er op een categorie geklikt wordt komen al de producten die tot deze categorie behoren tevoorschijn. Er kan een keuze gemaakt worden tussen de verschillende producten. Wordt er op een product geklikt, dan komt er een overzicht met informatie over dit product, zijnde de naam, de prijs, de beschrijving, een foto en het bestelde aantal. Het aantal producten in te geven door de klant. Wijzigen Een bestelling wijzigen is mogelijk als er op de knop wijzigen/verwijderen geklikt is. Er wordt een overzicht getoond van de bestelde producten met hiernaast 2 iconen. Wordt er op het potlood geklikt dan wordt er weer het overzicht met informatie getoond van dit product, en is het mogelijk om het aantal aan te passen. 31

33 Hoofdstuk 4. Fases Verwijderen Als er een bestelling verwijderd moet worden, klikt men eveneens op de knop wijzigen/verwijderen. Als er op het vuilbakje geklikt wordt naast een order, wordt dit order verwijderd en de lijst met orders wordt opnieuw ingeladen. 4.6 Testfase Omdat de programmeurs dezelfde klassen gebruiken is het systeem compatibel met de drie applicaties. Elk van de drie applicaties is apart getest geweest. Doordat de basis van het systeem rust op de klassen die door het team werden gemaakt en die klassen samen kunnen werken, kunnen ook de applicaties perfect samen werken. Het is de bedoeling dat op het eind van het project het systeem volledig wordt getest. Het is van het grootste belang dat in deze fase de laatste fouten worden opgespoord en dat ze verbeterd worden. 4.7 Afwerking Nadat alles afgewerkt was bleven er nog de details over. Deze details moesten toegevoegd, bewerkt of verwijderd worden. Dit kon gaan van kleine foutjes verbeteren of stukken code gewoon weglaten. Ook de lay-out zou op het eind bewerkt worden. De barman en klant applicatie zullen berusten op dezelfde lay-out, doordat ze beiden in Flash gemaakt zijn. De admin pagina zal in ongeveer dezelfde lay-out gegoten worden. 4.8 Verslag Voor het verslag werd er gebruik gemaakt van LaTeX. Er werd eerst een inhoudsopgave opgesteld om een overzicht te hebben. De code of applicaties die gemaakt werden door elk lid zouden worden beschreven in het verslag door dat lid. De rest van het verslag werd onderling verdeeld in gelijkaardige stukken. 32

34 Hoofdstuk 5 icafe engineering 5.1 Programmeertaal PHP5 PHP is een serverside scripttaal en heeft een syntax die sterk lijkt op C. Het is mogelijk om functiegeoriënteerd of objectgeoriënteerd te programmeren. Er werd gekozen voor deze laatste optie, om de aanpasbaarheid van de code zo groot mogelijk te maken. Er waren echter nog kenmerken van PHP5 die tot de keuze van deze programmeertaal leidden. Open-Source PHP is vrij te verkrijgen, er moet geen som geld voor neergeteld worden om het te gebruiken. Ook is het volledig legaal om de broncode aan te passen. Platformonafhankelijk PHP werkt op de meest gangbare besturingsystemen, Windows, Linux en Mac OSX Webservers PHP werkt op de meeste webservers, er wordt een Apache webserver gebruikt. MySQL PHP werkt goed samen met een MySQL database en heeft hier tal van geïntegreerde functies voor aan boord. Ondersteuning Voor elk probleem is er wel een oplossing te vinden op het internet. PHP is wereldwijd bekend en heeft ook een zeer uitgebreide ondersteuning. 33

35 Hoofdstuk 5. icafe engineering Browseronafhankelijk Aangezien het een serverside scripttaal is, moet er geen speciale browser of programmatuur geïnstalleerd worden. Object georiënteerd Zoals eerder vermeld biedt PHP ondersteuning voor object georiënteerd programmeren, zo kan er gebruik gemaakt worden van verschillende klassen die later als objecten kunnen gebruikt worden. Toekomst Het ziet er niet naar uit dat PHP de eerste jaren zal uitsterven. De taal blijft evolueren en wordt steeds meer gebruikt. Momenteel is versie de recentste bekende stabiele versie. Deze werd gereleased op 8 april Wij maakten echter gebruik van versie die bij het XAMPP pakket zit. 5.2 MySQL database MySQL is een relationele database management systeem, dat werkt volgens het relationeel model. Hierbij worden alle gegevens opgeslagen in tabellen, deze bevatten op zich kolommen die bepaalde gegevens kunnen bevatten, namelijk de rijen. Deze gegevens kunnen opgevraagd, toegevoegd, verwijderd of gewijzigd worden aan de hand van SQL queries. De keuze voor het gebruik van MySQL als database werd samen met die van PHP5 gemaakt. Aangezien PHP5 perfect samenwerkt met MySQL en ook tot de open-source wereld behoort. 5.3 Adobe Flash Flash van Adobe (vroeger Macromedia) is één van de meest gebruikte programma s om video s te maken, animatie te creëren en om websites te maken. Flash is voorzien van een tijdslijn waardoor het gemakkelijk is om tijdsgebaseerde frames te maken. Er kan worden geprogrammeerd door middel van ActionScript, een programmeertaal eigen aan Flash. In de nieuwe Creative Suite 3 (CS3) is ActionScript al aan versie 3.0 toe. Voor icafé werd er gebruik gemaakt van ActionScript 2.0 omdat deze nog het meest ondersteund wordt en omdat CS3 pas in april 2007 is verschenen. 34

36 Hoofdstuk 5. icafe engineering Ondersteuning Flash wordt door de meeste webbrowsers ondersteund, al moet daarvoor een extra plug-in worden geïnstalleerd. Verder is het platformonafhankelijk waardoor het systeem kan draaien op UNIX, MAC en Windows apparatuur. Het internet staat vol met tutorials en uitleg over Flash, zodat problemen goed kunnen worden opgelost. PHP en MySQL Dankzij loadvars, is het nu mogelijk om gegevens te sturen vanuit Flash naar PHP en MySQL en om gegevens te ontvangen vanuit PHP en MySQL. Wanneer loadvars wordt aangemaakt, wordt de variabele ook een object waardoor je aan dit object meerdere waarden kan meegeven. Voor het ontvangen van gegevens worden de gegevens ook toegekend aan hetzelfde loadvars object die dan in de ActionScript verder kunnen gebruikt worden. Flash kan rekenen op veel interesse, maar niet iedereen is even enthousiast over Flash. Velen zien het meer als een overbodige luxe. Ze appreciëren de (soms) lange wachttijden niet, of de vele animaties die niet nodig zijn om informatie op te zoeken. Anderen zijn er dan weer vol lof over, ze zouden uren kunnen kijken naar gemaakte intro s en animatiefilms. De meningen zijn dus verdeeld. Er werd voor Flash gekozen omdat de creativiteit die je kunt ontwikkelen met Flash door de projectleden wel gewaardeerd wordt. Het was een uitdaging om een uitgebreide Flash applicatie te bouwen om het programma nog beter te leren kennen. Door de gekozen optie multimedia die de projectleden volgen, is het een pluspunt om een vleugje creativiteit, design en animatie te kunnen toevoegen. 5.4 Smarty Template Engine Web templates In het algemeen zorgen web templates voor een goede verdeling van het werk. Het wordt verdeeld in een reeks codeerwerk en een reeks designwerk. Hieruit mag men dus verstaan dat de gegevens worden opgehaald in het codeerwerk, meer bepaald de datalaag. Deze gegevens worden op hun beurt weergegeven op de website, ook de presentatielaag genoemd. Deze scheiding van lagen heeft zijn voordelen. 35