iCafe Een digitaal bestelsysteem voor de horeca Joeri Verdeyen Stefaan De Spiegeleer Naim Ben Tanfous
Promotor: Philippe Van Laethem Toegepaste Informatica 3e Bachelor 2006 - 2007
blanco pagina
1
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¨en op tafel te gooien. Deze idee¨en 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
Inhoudsopgave 1 Inleiding
8
2 iCafe
9
2.1
Het probleem . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
Het concept . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.5
Droom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3 Project 3.1
3.2
12
Verdeling van de taken . . . . . . . . . . . . . . . . . . . . . .
12
3.1.1
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.2
Applicaties . . . . . . . . . . . . . . . . . . . . . . . .
13
Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.1
Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.2
Meetings . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.3
SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.4
Forum . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4 Fases
16
4.1
Brainstormen . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2
Scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3
Inhoudsopgave
4.3
Diagrammen . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.3.1
Database Ontwerp . . . . . . . . . . . . . . . . . . . .
17
4.4
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.5
Applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.5.1
Admin . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.5.2
Client - Barman . . . . . . . . . . . . . . . . . . . . .
30
4.5.3
Client - Klant . . . . . . . . . . . . . . . . . . . . . . .
31
4.6
Testfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.7
Afwerking . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.8
Verslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5 iCafe engineering
33
5.1
Programmeertaal PHP5 . . . . . . . . . . . . . . . . . . . . .
33
5.2
MySQL database . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.3
Adobe Flash
. . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.4
Smarty Template Engine . . . . . . . . . . . . . . . . . . . . .
35
5.4.1
Web templates . . . . . . . . . . . . . . . . . . . . . .
35
5.4.2
Onze aanpak . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.3
Smarty . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.5.1
Eclipse IDE . . . . . . . . . . . . . . . . . . . . . . . .
37
5.5.2
XAMPP . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.5.3
Tortoise SVN . . . . . . . . . . . . . . . . . . . . . . .
38
5.5
6 Problemen
40
6.1
Samenwerking . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.2
Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.2.1
Verwijderen van producten . . . . . . . . . . . . . . .
40
6.2.2
Gepriviligeerde woorden . . . . . . . . . . . . . . . . .
41
4
Inhoudsopgave
6.3
Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.3.1
Tortoise SVN . . . . . . . . . . . . . . . . . . . . . . .
42
6.3.2
Apache / MySQL
43
. . . . . . . . . . . . . . . . . . . .
7 Besluit
44
8 Eigen Beoordeling
46
8.1
8.2
8.3
Naim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
8.1.1
Zelfreflectie . . . . . . . . . . . . . . . . . . . . . . . .
46
8.1.2
Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
8.1.3
Joeri . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
8.2.1
Zelfreflectie . . . . . . . . . . . . . . . . . . . . . . . .
47
8.2.2
Naim
. . . . . . . . . . . . . . . . . . . . . . . . . . .
48
8.2.3
Joeri . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Joeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
8.3.1
Zelfreflectie . . . . . . . . . . . . . . . . . . . . . . . .
49
8.3.2
Naim
. . . . . . . . . . . . . . . . . . . . . . . . . . .
50
8.3.3
Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
9 Tweede Zittijd
52
9.1
Opdracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
9.2
Verbetering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
9.3
Uitbreiding . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
9.3.1
Database . . . . . . . . . . . . . . . . . . . . . . . . .
53
9.3.2
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . .
53
9.3.3
Barman . . . . . . . . . . . . . . . . . . . . . . . . . .
54
9.3.4
Client . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
9.3.5
Testen . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5
Inhoudsopgave
10 Bronvermelding
55
A Ingediend voorstel
57
B Scenario’s
61
B.1 Administrator Joeri . . . . . . . . . . . . . . . . . . . . . . .
61
B.1.1 Voorstelling . . . . . . . . . . . . . . . . . . . . . . . .
61
B.1.2 Situatie . . . . . . . . . . . . . . . . . . . . . . . . . .
61
B.1.3 De kassa . . . . . . . . . . . . . . . . . . . . . . . . . .
61
B.1.4 Voorraad . . . . . . . . . . . . . . . . . . . . . . . . .
62
B.1.5 Wijzigingen van het menu . . . . . . . . . . . . . . . .
63
B.1.6 Preview . . . . . . . . . . . . . . . . . . . . . . . . . .
64
B.1.7 De mogelijkheden . . . . . . . . . . . . . . . . . . . . .
64
B.2 Client Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
B.3 Administrator Stef . . . . . . . . . . . . . . . . . . . . . . . .
66
B.4 Barman Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
B.5 Client Naim . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
B.6 Barman Naim . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
B.7 Administrator Na¨ım . . . . . . . . . . . . . . . . . . . . . . .
73
C Diagrammen
74
C.1 Database ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . D Verslagen van vergaderingen
74 76
D.1 Vergadering 1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
D.2 Vergadering 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
D.3 Vergadering 3 . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
D.4 Vergadering 4 . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
D.5 Vergadering 5 . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
D.6 Vergadering met promotor . . . . . . . . . . . . . . . . . . . .
95
6
Inhoudsopgave
E Diverse bestanden
98
E.1 Toelichting relaties tussen objecten . . . . . . . . . . . . . . .
98
E.2 Toelichting stockbeheer . . . . . . . . . . . . . . . . . . . . . 101
7
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¨evolueerd 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¨ordinatie belangrijk, en dus ook dit is in het verslag terug te vinden.
8
Hoofdstuk 2
iCafe 2.1
Het probleem
Bij drukke caf´es 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´e 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´es 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
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´e 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 ´e´en 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 ´en leveren. Voor de eigenaar van het caf´e 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´es 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 ´e´en 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
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
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.
3.1.1
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
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
3.1.2
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
Hoofdstuk 3. Project
3.2 3.2.1
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.
3.2.2
Meetings
De grotere onderwerpen van het project werden besproken tijdens meetings1 . 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.
3.2.3
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 repository2 af. Wanneer er aan bestanden gewerkt is wordt dit vervolgens ge¨ upload naar een repository. 1 2
Voor de verslagen van de meetings zie bijlage D Een repository is een online opslagplaats voor data
14
Hoofdstuk 3. Project
3.2.4
Forum
In hebt begin van dit project werd het forum3 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 http://www.stefds.be/eindwerk/forum/index.php
15
Hoofdstuk 4
Fases 4.1
Brainstormen
Bij het brainstormen werden allerhande idee¨en op tafel gegooid. Veel idee¨en die bij het tekenen van diagrammen en bij het programmeren niet meer gebruikt werden. E´en van de eerste idee¨en 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´e 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´e waardoor klanten op het internet kunnen surfen met hun laptop. Ook om het werken effici¨ent 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¨en 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
Hoofdstuk 4. Fases
4.2
Scenario’s
Voordat er diagrammen gemaakt werden, besliste de groep om uitgebreide scenario’s1 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.
4.3.1
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¨en. Een product kan behoren tot ´e´en categorie. Een categorie heeft een parameter parent id die aangeeft of de categorie een subcategorie is van een andere categorie. Wanneer een categorie subcategorie¨en heeft kan hieraan geen 1 2
Voor scenario’s zie bijlage B Voor diagrammen zie bijlage C
17
Hoofdstuk 4. Fases
product toegevoegd worden, om te voorkomen dat een product zweeft tussen een lijst van categorie¨en. 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 ´e´en 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
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¨encrypteerd worden. user type Het type dat bepaalt welke rechten de gebruiker heeft. 19
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¨erarchie van categorie¨en. Deze categorie¨en hebben een unieke naam en beschrijving als verduidelijking. De categorie klasse is in staat na te gaan of de categorie wel of niet subcategorie¨en bevat. Verder kan het al zijn subcategorie¨en 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
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¨entere 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 ´e´en 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
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 4.5.1
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¨en, 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¨en, 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
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¨en, welke het overzichtelijk maken om de producten weer te geven. Zie pagina 24 voor meer informatie over categorie¨en. BTW-tarief Omdat er in Belgi¨e 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 ´e´en eenheid van het product dat betaald werd aan de leverancier. Deze prijs is louter indicatief en wordt gebruikt als hulpmiddel voor de gebruikers. 23
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 4.5.1 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
Hoofdstuk 4. Fases
categorie¨en, die ervoor zorgen dat elk product thuis zal horen onder een bijpassende categorie. Er zijn twee soorten categorie¨en, de hoofdcategorie en de subcategorie. Een hoofdcategorie is een categorie die een of meerdere subcategorie¨en kan bevatten. Hieronder kan men verstaan dat er een soort hi¨erarchie onstaat tussen deze categorie¨en. Een subcategorie wordt steeds geplaatst onder een hoofdcategorie. Door het gebruik van deze hi¨erarchie 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¨en heeft. Dit zou er voor zorgen dat er producten op hetzelfde niveau staan als categorie¨en, wat voor onduidelijkheden kan zorgen. Verder zijn er maar twee niveaus van categorie¨en, 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¨en 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¨en over ´e´en of meerdere subcategorie¨en kan beschikken zijn er bepaalde restricties bij het verwijderen. Wanneer er een hoofdcategorie verwijderd wordt die ´e´en of meerdere subcategorie¨en bevat
25
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¨e 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
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¨en. 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
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
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
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.
4.5.2
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
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.
4.5.3
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
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
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¨enteerd of objectgeori¨enteerd 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
Hoofdstuk 5. iCafe engineering
Browseronafhankelijk Aangezien het een serverside scripttaal is, moet er geen speciale browser of programmatuur ge¨ınstalleerd worden. Object geori¨ enteerd Zoals eerder vermeld biedt PHP ondersteuning voor object geori¨enteerd 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 5.2.1 de recentste bekende stabiele versie. Deze werd gereleased op 8 april 2006. Wij maakten echter gebruik van versie 5.0.37 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 ´e´en van de meest gebruikte programma’s om video’s te maken, animatie te cre¨eren 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´e 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
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¨eren 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 5.4.1
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
Hoofdstuk 5. iCafe engineering
• Duidelijke scheiding tussen de voorstelling (design) en het eigenlijke programmeer werk. De designer heeft niet de kennis nodig die de coder heeft en omgekeerd. • Flexibel qua aanpasbaarheid en uitbreiding. Wanneer in de datalaag wijzigingen worden aangebracht zal de presentatielaag hier geen hinder van hebben.
5.4.2
Onze aanpak
Er worden verschillende klassen geschreven aangezien er objectgeori¨enteerd gewerkt wordt. Deze klassen zijn objecten zoals een product, een bestelling, enz. . . Vanuit deze klassen worden de gegevens uit de database opgehaald. Bijvoorbeeld wanneer er gegevens van een flesje Cola nodig zijn, kunnen deze gegevens aan de hand van een nieuw product object worden opgehaald uit de database. De klassen zijn dus de datalaag van het template systeem. Het doel is deze gegevens weer te geven op een website. Dit wil zeggen dat deze moeten doorgegeven worden aan de presentatielaag, die het design van de website vertegenwoordigt. Het is niet de bedoeling om rechtstreeks vanuit een klasse gegevens door te geven aan de presentatielaag, hiervoor wordt de applicatielaag gebruikt. Wat er gebeurt in de applicatielaag is vrij simpel. In deze laag wordt een nieuw object aangemaakt en het object wordt gevuld met gegevens. Hierbij maakt de applicatielaag verbinding met de datalaag door het gebruik van de klassen. Nadien zal de applicatielaag de gegevens van het object doorgeven aan de presentatielaag, die op zijn beurt de gegevens weergeeft.
5.4.3
Smarty
Smarty is een template engine voor PHP. Wat wil zeggen dat het mogelijk is deze lagen aan te maken en door Smarty kunnen de verschillende lagen in het ontwerp met elkaar communiceren. Smarty op zich is ook een klasse die de nodige functies aan boord heeft om het geheel uit te voeren. Volgend voorbeeld zal voor verduidelijking zorgen.
36
Hoofdstuk 5. iCafe engineering
Voorbeeld Het doel is om de gegevens van een product in een webpagina te tonen. Er wordt hiervoor gebruik gemaakt van drie verschillende bestanden en de Smarty template engine. Klasse bestand Hierin wordt de connectie gelegd met de database en de gegevens opgehaald die nodig zijn of gevraagd worden. (datalaag) Applicatie bestand Dit bestand maakt een nieuw Smarty object aan. Aan dit Smarty object worden variabelen meegegeven die gegevens bevatten. Nadien wordt er aan dit object meegegeven welke template er gebruikt zal worden. (applicatielaag) Template bestand Dit is het enige bestand waarin HTML code aanwezig is. De opmaak van de pagina wordt hierin bepaald. Door het Smarty object dat in het applicatie bestand aangemaakt is, kan het template bestand de gegevens ontvangen en ook tonen in de pagina. (presentatielaag)
5.5 5.5.1
Software Eclipse IDE
Om te coderen in PHP werd er gebruik gemaakt van de open-source framework1 Eclipse. Eclipse is standaard een java ontwikkelingomgeving, maar door plug-ins kan de functionaliteit uitgebreid worden. Er werd ook gebruik gemaakt van de PHPEclipse plugin die syntax highlighting heeft voor PHP, HTML, XML, CSS en Smarty. Hierbij wordt het programmeren in PHP makkelijker, sneller en aangenamer. Ook het gebruik van Smarty werd hierdoor bevorderd. De grote voordelen die we bij deze plug-in gebruikt hebben zijn: • Overzicht van alle functies die aanwezig zijn in een bestand 1
Een framework zijn softwarecomponenten die kunnen gebruikt worden bij het programmeren van applicaties, op dit framework kan men dan verder bouwen met bepaalde libraries of plug-ins.
37
Hoofdstuk 5. iCafe engineering
• Het gebruik van de auto-complete functie • De uitgebreide syntax highlighting2 • De onmiddellijke weergave van syntax fouten • Ge¨ıntegreerde controle over XAMPP
5.5.2
XAMPP
Het gehele iCafe systeem is een webapplicatie. Hierbij hoort natuurlijk een webserver om deze applicatie op te draaien. De webserver moet ondersteuning bieden voor PHP5 en ook een MySQL server moet aanwezig zijn. Bij normale gang van zaken worden alle modules (Apache, PHP5, MySQL) afzonderlijk ge¨ınstalleerd en dan op elkaar afgestemd. Het is echter ook mogelijk een all-in-one oplossing te gebruiken, hierbij worden alle benodigdheden in ´e´en installatiebestand gestoken. De gebruikelijke naam voor deze all-in-one oplossing is AMP, de afkorting voor Apache MySQL en PHP. Aan de hand van het besturingsysteem waarvoor de AMP server gemaakt is zal er vooraan een letter toegevoegd worden (bv. WAMP voor Windows, LAMP voor Linux). Voor het iCafe Project wordt er echter gebruik gemaakt van XAMPP. Waarbij de X te verklaren is door de beschikbaarheid voor de drie grootste besturingsystemen (Windows,Mac OSX en Linux). XAMPP is een open-source project van ApacheFriends en gratis te verkrijgen op het internet. ApacheFriends is een non-profit projectgroep die het gebruik van de Apache server promoten aan de hand van hun XAMPP project. XAMPP werd op de computers van de projectleden ge¨ınstalleerd zodanig dat deze hun code en dergelijke lokaal konden testen.
5.5.3
Tortoise SVN
Omdat de code verdeeld werd onder de verschillende projectleden moest er een oplossing gezocht worden om alles steeds synchroon met elkaar te laten 2
Syntax highlighting zorgt ervoor dat de tekst van de code in bepaalde opmaak wordt weergegeven zodanig dat het herkennen van bepaalde termen, functies of variabelen makkelijker wordt.
38
Hoofdstuk 5. iCafe engineering
lopen. Een systeem dat ervoor moest zorgen dat iedereen de laatste nieuwe versies van de bestanden kon downloaden. Hiervoor is er gebruik gemaakt van een SVN systeem. Er zijn verschillende SVN3 oplossingen beschikbaar. Er werd gebruik gemaakt van Tortoise SVN. Tortoise SVN werd gekozen omdat er reeds projectleden waren die kennis hebben van dit programma. De bestanden worden centraal opgeslagen op een server. Er werd gekozen voor gratis hosting van Google Code om de bestanden naar toe te zenden. Het is namelijk mogelijk om via Google een project4 te starten. Hiervoor biedt Google dan de nodige hulpmiddelen aan, waaronder een server met SVN ondersteuning.
3
SVN is een programma waarmee het versiebeheer van een softwareproject wordt onderhouden. 4 Meer info over dit project op Google is te vinden op http://code.google.com/p/projecticafe/
39
Hoofdstuk 6
Problemen 6.1
Samenwerking
De samenwerking tussen verschillende groepsleden verliep al bij al vlot. Met drie mensen aan een project werken heeft zijn voor- en nadelen. Zo is het bijvoorbeeld handig, wanneer iemand een programmeer probleem heeft, dat er twee andere mensen zijn die hem daarbij kunnen helpen. Ook kan het project in meerdere stukken worden opgedeeld en kan iedereen zich concentreren op zijn stuk. Dankzij de vriendschap die er heerst tussen de groepsleden kon het project goed vooruit gaan en waren er geen grote problemen. De motivatie is ook groter wanneer je met drie vrienden aan een project werkt. Nadelen waren dan weer om de agenda’s op elkaar af te stemmen. Ook om compromissen te vinden tussen de verschillende karakters in de groep was het niet altijd simpel. Verder heeft iedereen zijn eigen idee¨en en interpretaties zodat het belangrijk is om alles op elkaar af te stemmen.
6.2 6.2.1
Engineering Verwijderen van producten
Tijdens het debuggen van het administrator gedeelte is er een kleine design fout opgedoken. Het gaat erom dat producten kunnen verwijderd worden en alle gegevens van deze producten ook verwijderd worden. Hierbij kan er dus geen archief aangelegd worden. Op zich is dit niet zo’n groot probleem,
40
Hoofdstuk 6. Problemen
maar wanneer er naar het archief van de bestellingen wordt gekeken is er wel iets aan de hand. In het archief van de bestellingen is het mogelijk om de prijzen van de producten en de totale omvang van de bestelling te bekijken. Hierbij moeten er gegevens opgehaald worden van de betwiste producten. Deze gegevens worden opgehaald uit de database. Wanneer een product uit het assortiment gehaald wordt worden alle gegevens van het product verwijderd. Hierbij worden dus ook de gegevens die nodig zijn voor het archief van de bestellingen verwijderd en zullen er foutmeldingen optreden. Dit probleem is opgelost door het toevoegen van een een parameter aan elk product. Deze parameter is een boolean die bepaalt of een product actief is of niet. Niet actief wil in dit geval zeggen dat het product verwijderd is, maar dat de gegevens nog steeds beschikbaar zijn in de database. Natuurlijk worden alleen actieve producten weergegeven in de client applicatie.
6.2.2
Gepriviligeerde woorden
Bij het maken van de klassen in PHP, kregen sommige mensen heel wat problemen. Er waren geen foutmeldingen maar toch wou het systeem bij sommige klassen geen verbinding maken met de juiste tabel. Na analyse bleken de namen die werden gegeven aan tafel en bestelling (nl. table en order) niet gebruikt mochten worden. Deze woorden zijn door MySQL gereserveerd. Daarom werden de oorspronkelijke benamingen table en order gewijzigd in respectievelijk tablelist en orders.
6.3
Computers
In de loop van het project is Stef overgeschakeld van een Windows laptop naar een Apple Macbook met Mac OSX Tiger v10.4.9 als besturingssysteem 1 . Dit bracht op software-matig vlak enkele problemen met zich mee. Veel van de gebruikte programma’s in dit project hebben namelijk geen MAC OSX variant, en er moest dus op zoek gegaan worden naar substituutprogramma’s. 1
Verder in dit verslag zal dit afgekort worden tot Mac OSX
41
Hoofdstuk 6. Problemen
6.3.1
Tortoise SVN
Aangezien er van Tortoise geen versie bestaat voor Mac OSX is er naar alternatieven gezocht om lokaal te kunnen communiceren met de repository. Na wat zoekwerk op Internet bleek uit diverse user reviews dat svnX een van de beste SVN clients was. svnX http://www.lachoseinteractive.net/en/community/subversion/svnx Bij de configuratie kwam ’the blue wheel of death’ te voorschijn en liep svnX keer op keer vast. Er werd getracht dit op te lossen door de herinstallatie van svnX, maar dit hielp niet. Ook het overschakelen naar vorige versies bracht geen soelaas. Dit bleek geen alleenstaand geval te zijn aangezien er op diverse fora hulp gezocht werd voor dit probleem. Er werd dus gezocht naar een ander programma. RapidSvn http://rapidsvn.tigris.org/ Na een zoektocht op google werd er voor RapidSvn gekozen omdat dit, volgens hun website, snel en eenvoudig te configureren was. Het enige probleem hierbij was net ironisch genoeg dat RapidSvn ondanks vele pogingen niet goed geconfigureerd raakte en er dus ook niet met dit programma gewerkt kon worden. SmartSVN http://www.syntevo.com/smartsvn/ Uiteindelijk bracht SmartSVN de uitkomst. De configuratie verliep zonder noemenswaardige problemen dankzij een handige wizard. Er zijn ook enkele handige extra features zoals een conflict oplosser en een functie die online en offline bestanden gaat vergelijken en samenvoegen.
42
Hoofdstuk 6. Problemen
6.3.2
Apache / MySQL
xampp Er werd, zoals beschreven in paragraaf 3.1.2, gebruik gemaakt van XAMPP voor het testen van server-side code. Hier bestaat wel een Mac OSX versie van en deze werd gebruikt. Het probleem echter was dat er niet in geslaagd werd om Aliassen te defini¨eren. Dit probleem werd gepost op www.tweakers.net en op www.intermactivity.be maar ondanks de vele pogingen van andere users kon de oorzaak van het niet goed functioneren van de Aliassen niet gevonden worden. mamp Mamp is de tegenhanger van Xampp, en speciaal ontwikkeld voor Mac OSX. Het initi¨ele probleem bij het gebruik van Mamp was dat wanneer de Aliassen gedeclareert werden de apache server niet meer wou rebooten. Dit probleem werd verholpen door Xampp volledig te verwijderen en een clean install uit te voeren van Mamp.
43
Hoofdstuk 7
Besluit Het vooropgestelde doel bij aanvang van het project, zowel een up and running frontend en backend hebben, is bereikt, en we zijn geen problemen tegen gekomen die we niet het hoofd konden bieden. De planning die we voorop gesteld hadden bij aanvang van het project hebben we gaandeweg wel regelmatig moeten wijzigen. Zo hebben we bijvoorbeeld veel meer tijd gestoken dan oorspronkelijk gebudgeteerd in het ontwerpen en schrijven van de Klassen in PHP5. Dit was mede te danken aan het feit dat Naim & Stef een langere leerperiode nodig hadden dan gepland. Dit leerproces is niet enkel bij PHP5 gebleven en gaandeweg kregen we programma’s als Flash 8, Actionscript en SMARTY goed onder de knie. Aangezien we met 3 leden waren is ook het leerproces om in teamverband naar een resultaat te streven het vermelden waard, zeker in perspectie met het professionele leven dat voor de deur staat. Bij de aanvang van het project was het al snel duidelijk dan voor de barman en klant applicaties gebruik ging gemaakt worden van Flash. Vooral omdat dit qua gebruiksvriendelijkheid (rekening houdend met het touch screen concept) het beste bij onze noden paste. De communicatie van Flash naar PHP en omgekeerd gebeurde via de ingebouwde functies in Flash. De mogelijkheden hierbij waren echter beperkt en dit zorgde aanvankelijk voor wat beperkingen. Toen het project naar het einde toeliep hebben we een PHP toolkit ontdekt die via remoting makkelijk communicatie toelaat tussen Flash en PHP, Amfphp genaamd.1 Na overleg hebben we besloten om 1
Voor meer informatie zie ook http://amfphp.sourceforge.net/
44
Hoofdstuk 7. Besluit
verder te blijven werken met Flash, en dus niet over te schakelen. Dit omdat we al te ver gevorderd waren in het project en de opbrengst die we zouden halen uit de overstap niet opweegt tegen de te herschrijven code. We kunnen dus tevreden terugblikken op het project. Het is een zeer goede leerschool geweest met een resultaat dat gezien mag worden.
45
Hoofdstuk 8
Eigen Beoordeling 8.1 8.1.1
Naim Zelfreflectie
Bij het begin van het project wist ik dat ik een technische achterstand had op de twee andere groepsleden. Wanneer de programmeertalen bekend raakten dacht ik bij mezelf dat ik echt tot het uiterste zou moeten gaan omdat PHP en Flash niet mijn sterkste punten zijn. Ik zag dit echter niet als een nadeel maar meer als een uitdaging. Het zou het ideale moment zijn om mijn niveau in PHP en Flash wat op te krikken. Ik weet van mezelf dat ik in een groep een rare manier van werken heb, zoals de andere groepsleden veel lastig vallen met vragen. In het begin lijken dit voor mezelf altijd nuttige vragen, maar hoe meer het project vordert hoe meer ik van mezelf vind dat ik teveel ’domme’ vragen heb gesteld. Dit is echter mijn manier om een materie onder de knie te krijgen. Ik wist dan ook dat het geluk me bijstond door in deze groep te mogen werken, omdat Stef en Joeri altijd klaar staan om de tijd te nemen om me vooruit te helpen. Ik had dan ook wat meer tijd nodig dan de andere twee groepsleden om alle code klaar te hebben. Al bij al vind ik van mezelf dat men PHP en Flash knowledge nu helemaal up-to-date is, en dat het vertrouwen dat de groep in mij had niet beschaamd is geweest.
46
Hoofdstuk 8. Eigen Beoordeling
8.1.2
Stef
Dit is niet het eerste project dat we samen doen. Ondertussen ken ik de werkwijze van Stef al wat, en die ligt heel dicht bij mijn werkwijze. Hij begint over het algemeen redelijk laat om deadlines te bereiken, maar slaagt er altijd wel in om de vooropgestelde data te halen. Tijdens het project gebeurt het dat je je ergert aan zijn manier van werken, maar je kan er altijd op rekenen dat zijn werk goed gedaan is. Hij komt heel vaak met originele ide¨een op de proppen waardoor het project interessanter wordt. Stef staat ook altijd klaar om te helpen waar hij kan. Wanneer andere personen vast zitten, of moeilijkheden hebben kun je altijd beroep doen op Stef.
8.1.3
Joeri
Over Joeri valt er niet veel verkeerd te zeggen. Joeri is iemand die enorm veel werkt. Overal waar hij een gaatje vindt werkt hij aan het project. Hij is ook altijd op zoek naar zaken die het project gemakkelijker maken. Zo test hij soms veel software uit (zoals Tortoise, Smarty) die iets kunnen toevoegen. Helaas is hij met Stef en mezelf in een wat andere werkomgeving gevallen. Stef en ikzelf hebben een heel andere manier van werken waardoor ik denk dat Joeri soms heel gefrusteerd moest zijn. Maar hij laat dit echter nooit merken en hij blijft klaar staan om iedereen te helpen. Ik heb Joeri enorm veel lastig gevallen om dingen te vragen of te verduidelijken en hij zette mij altijd terug op goede weg. WE vonden een enorm complimentair team en hebben elkaar goed aangevuld. Het was aangenaam werken, en er werd geen extra druk opgelegd door de andere groepsleden. We probeerden elkaar vooruit te helpen en elkaar te motiveren waardoor sommige problemen vlugger opgelost werden.
8.2 8.2.1
Stef Zelfreflectie
Het project was voor mij een uitdaging om nieuwe dingen bij te leren. Aangezien ik al redelijk wat kennis heb opgedaan in Flash (oa. op stage), zag ik er vooral naar uit om PHP beter onder de knie te krijgen. Vorig jaar hebben
47
Hoofdstuk 8. Eigen Beoordeling
we weliswaar het vak server side scripting gekregen, maar ik zag dit eerder als een inleiding tot PHP4. Aangezien in dit project geprogrammeerd werd in PHP5 en er veel gecompliceerdere code moest geschreven worden, was het een goede vorm van zelfstudie. Ik kan van mezelf zeggen dat ik mijn steentje bijgedragen heb aan het project. De opdrachten waren altijd tijdig af (met ´e´en uitzondering) en ik had een gezonde inbreng. Wat ik gedurende dit project wel gemerkt heb is dat mijn manier van werken verschilt van de manier waarop de 2 andere leden werken. Zo schuif ik het werk meer op naar de deadline, terwijl bij Naim en vooral bij joeri meer gewerkt werd op voorhand. Dit heeft wel eens voor kleine irritaties gezorgd maar heeft nooit de vriendschap onderling aangetast. Het feit dat we met drie in groep werkten om een resultaat van deze omvang te bekomen was ook nieuw voor me. Het was aangenaam werken aangezien je ook input krijgt van 2 andere personen. Buiten de manier van werken kwamen de karakters goed overeen en konden we op elkaar rekenen. Ik kan met een goed gevoel terugblikken op dit project. Ik het er zeer veel uit geleerd, zowel op technisch vlak als op menselijk vlak.
8.2.2
Naim
Vorig jaar heb ik reeds een project gemaakt met Naim, en daaruit is gebleken dat we ongeveer dezelfde manier van werken hebben. Ik wist dus dat het ook voor dit project ging klikken. Ook hij begint redelijk laat aan het werk, dit was wel altijd afgewerkt. Op dit vlak is hij mijn inziens wel veranderd gedurende dit project. Zo heb ik de indruk dat hij naar het einde van het project toe het werk niet zolang meer liet aanslepen. Naim was heel leergierig en dit liet hij blijken door veel vragen te stellen, voornamelijk met betrekking tot Flash. Hij begon met een kleine technische achterstand aan het eindwerk, maar dit heeft hij beetje bij beetje weten goed te maken naargelang het project vorderde.
8.2.3
Joeri
Het was heel aangenaam werken met joeri. Hij was steeds super gemotiveerd en hij nam meer dan eens het voortouw. Zo zocht hij bijvoorbeeld op voor-
48
Hoofdstuk 8. Eigen Beoordeling
hand al uit hoe het subversion systeem werkte en welke de beste applicaties waren om hiermee te werken. De manier waarom Joeri werkt verschilt toch enigszins van de manier waarop Naim & ik werken. Zo is hij heel ordelijk en plant hij zijn werk, zodat het ruim voor de deadline af geraakt. Joeri had een aanzienlijke voorsprong in PHP bij aanvang van het project, en deze reeds vergaarde kennis deelde hij met de glimlach met de andere 2 groepsleden. Indien ik een vraag had voelde hij zich zeker niet te beroerd om te helpen.
8.3 8.3.1
Joeri Zelfreflectie
Vanaf de start van het project tot het einde heb ik geprobeerd om mij 100 procent in te zetten. Dit is me naar eigen mening ook gelukt. Overal waar ik een gaatje vond probeerde ik al oplossingen te zoeken, taken af te werken en dergelijke. Dit resulteerde erin dat ik het gevoel kreeg alsof ik soms de beslissingen van bepaalde zaken mocht nemen. Deze beslissingen werden natuurlijk ook goedgekeurd door de andere twee groepsleden. Ook bij het werken aan zulke grote projecten verkies ik orde boven wanorde. Hiermee bedoel ik voornamelijk, een degelijke taakverdeling, een correcte mappenstructuur, zelfs het consistent zijn van bestandsnamen t.o.v elkaar. Deze afspraken zijn dan ook gemaakt, hoewel ik naar mijn gevoel soms met de idee¨en op de proppen moest komen. Hiermee bedoel ik niet dat de andere groepsleden niet inventief of alternatief genoeg waren, maar dat de gedrevenheid en het streven naar een succesvol project meer bij mij lag dan bij de andere groepsleden. Hoewel bij deze blijkt dat we het allemaal tot een goed einde hebben gebracht is het tegendeel bewezen. Tijdens het project heb ik ook veel geleerd. Zo is het object geori¨enteerd programmeren in PHP5 en Smarty Templates helemaal nieuw voor mij. Dankzij het eindwerk heb ik deze zaken onder de knie, en deze kunnen me later nog goed van pas komen. Hiermee kan ik concluderen dat ik alleen vooruit gegroeid ben tijdens het project en naar de toekomst toe een voorsprong heb gekregen. Aangezien we een groep hadden van drie leden moesten we ook leren in groep
49
Hoofdstuk 8. Eigen Beoordeling
werken. Dit is goed verlopen zonder grote problemen. Af en toe kwamen de persoonlijke karakters naar boven maar deze hebben de goede groepssfeer niet verpest. De groep hing sterk aan elkaar, en we steunden elkaar op alle vlakken, en waar mogelijk.
8.3.2
Naim
Al voor we aan het project begonnen wist ik dat Naim een eigen manier van werken heeft. Dit kan ik hem ook niet kwalijk nemen aangezien ik hier dan al van op de hoogte was. Ik weet niet meteen of ik het moet zien als uitstel, maar hij begon vaak vrij laat aan de opdrachten zodat hij soms net de deadline die we opstelde haalde of net niet. Al bij al heb ik geprobeerd me hier zo weinig mogelijk zorgen over te maken, aangezien ik ook wel ergens wist dat het voor hem ook belangrijk was dat het project tot een goed einde kwam. Gedurende het project weet ik dat Naim ook enkele tegenslagen heeft gehad. Hij heeft uren op bepaalde fouten zitten kijken, die we nadien samen op enkele minuten hadden opgelost. Dit is natuurlijk het voordeel van in groep te werken. Ik kan hem best begrijpen dat wanneer je met een probleem zit hiervoor een oorzaak gaat zoeken, deze was in zijn geval niet vaak voor de hand liggend. Toch moest hij af en toe eens wat dieper leren kijken of de alternatieve route kiezen. Ik ben tevreden dat ik met hem in de groep zat, en zal er ook een reeks goede herinneringen en een goede vriendschap uit over houden.
8.3.3
Stef
Net als Naim heeft Stef zijn eigen manier van werken. Deze valt misschien zelfs wel te vergelijken met die van Naim. Zo wist hij ook de opdrachten te laten rusten tot enkele dagen (of een dag) voor deadline en er dan pas volle vaart aan te beginnen. Dit is enkele keren in het begin van het project misgelopen, waarbij hij dan ook de volle verantwoordelijkheid van een slechte beoordeling op hem nam. Wanneer Stef weet dat het zijn fout is, zal hij dit steeds toegeven en op zijn manier verantwoorden. Dit kan ik ook zeer apprecieren in Stef dat hij zijn fouten toegeeft en de verantwoordelijheid ervoor opneemt, hoe dom de fouten of tekortkomingen ook wel mogen zijn. 50
Hoofdstuk 8. Eigen Beoordeling
In het begin van het project moest Stef werken op een laptop waar amper op te werken valt. Hier is naar het einde van het project toe verandering in gekomen, Stef kocht een Apple Macbook. Dit heeft hem ook een hele boost gegeven waardoor ik versteld stond van wat hij allemaal op het scherm kon toveren. Hij richtte de volledige Client zijde van klanten applicatie in, waarbij ik zelf soms niet zou weten hoe bepaalde problemen op te lossen. Stef is een aangenaam persoon om in groep mee te werken, al moet je zijn werkwijze accepteren en hier niet op beginnen stressen. Dit is me meestal wel gelukt. Op andere momenten kon hij me wel tot rust brengen door zijn eigen mening te geven van de gang van zaken. Dit waren meestal goede vooruitzichten en dat het project vanzelfsprekend tot een goed einde zal komen. Net als bij Naim ben ik zeer tevreden dat ik bij hem in de groep zat. De goede herinneringen van het project zullen me steeds bij blijven, en de goede band met Stef is hierdoor alleen maar sterker geworden. Ik zie het zeker zitten om later samen projecten aan te nemen en tot een goed einde te brengen.
51
Hoofdstuk 9
Tweede Zittijd 9.1
Opdracht
De opdracht in tweede zittijd bestaat uit: • Verbeteren: het eindwerkverslag dat ingeleverd is in 1ste zittijd aan de hand van de meegeleverde lijst. • Toevoegen: liedjes aan te vragen (klanten). • Toevoegen: liedjes-aanvragen goed te keuren of te weigeren (barman). • Toevoegen: goedgekeurde liedjes-aanvragen toevoegen aan playlist van muziekspeler en eventueel link met bestaande software leggen.
9.2
Verbetering
De eerste opdracht bestond erin het gemaakte verslag te verbeteren. De taalfouten werden uit het verslag gehaald en er werden leestekens geplaatst waar nodig. Om het werk te vergemakkelijken, gaf de promotor een lijst met taalfouten die gecorrigeerd moesten worden.
52
Hoofdstuk 9. Tweede Zittijd
9.3 9.3.1
Uitbreiding Database
De database zou dus uitgebreid moeten worden met enkele tabellen om de nodige informatie te kunnen bijhouden. Er werd gekozen om dezelfde denkwijze als voorheen te gebruiken. Er werden drie tabellen toegevoegd, zijnde music, requestList en playList. music De tabel music zal het id bijhouden van het desbetreffende liedje. Ook de titel en auteur zijn verplicht in te geven. Als optie is er de mogelijkheid om een album van het liedje bij te houden alsook de lengte en het genre. Album, lengte en genre zijn dus niet verplicht en kunnen dienen als bijkomende informatie. De music tabel zal dus alle informatie bijhouden over de liedjes en welke liedjes er beschikbaar zijn in het systeem. RequestList RequestList moet id’s bijhouden van liedjes die door de klanten zijn aangevraagd. Een requestList heeft een id en een song id die samen de primary key vormen. In song id wordt er het id van het aangevraagde liedje bijgehouden. PlayList De tabel playList is identiek aan requestList.
9.3.2
Klassen
Door onze gestructureerde aanpak in PHP, was het niet moeilijk om enkele klassen toe te voegen aan het systeem. Er werd net zoals de database gekozen voor de klassen music, playlist en requestlist. Music De music-klasse houdt een id, een titel, artiest, genre, lengte en een album bij. Deze klasse heeft de gebruikelijke setters en getters, alsook de database connecties om gegevens weg te schrijven, op te halen of te updaten. Als belangrijkste methode heeft deze klasse de functie getAllMusic, die de id’s van elk liedje in de database zal terugsturen. Play- en RequestList Ook hier zijn de play- en de requestList identiek. Ze bevatten een id en een array van song id’s. Omdat we gebruik
53
Hoofdstuk 9. Tweede Zittijd
maken van 1 play- en 1 requestlist zijn hun id’s altijd 1. Buiten de standaard functies, hebben de twee klassen eveneens bijkomende functies om al de muziek in de play- en requestlist tabellen op te halen.
9.3.3
Barman
Om de applicaties werkend te krijgen heeft Naim verder gewerkt op de bestaande barman applicatie. Een barman moet een lijst met aangevraagde liedjes kunnen opvragen. Het systeem stuurt hem dan een lijst met alle liederen die tot nu toe zijn aangevraagd door de klanten terug. Hieruit kan hij dan kiezen welke liedjes hij wil accepteren en wil doorsturen naar de playlist. De andere liedjes moet hij dan verwijderen van de requestlist. Hij kan ook een lijst met alle liedjes uit het systeem opvragen en zo zelf liedjes toevoegen aan de playlist. Ten slotte kan een barman een playlist opvragen en kan hij zo eventueel nog liedjes van de playlist verwijderen.
9.3.4
Client
Stef heeft de bijkomende functionaliteit eveneens ingepast in de reeds bestaande klant applicatie. Doordat er reeds aandacht besteed was in eerste zittijd aan de uitbreidbaarheid verliep dit relatief vlot. De klant kan een overzicht aanvragen van de liedjes in de database van het systeem. Door het selecteren van een titel wordt het liedje aangevraagd. Dit wordt dan in de requestlist geplaatst in afwachting van de goed- of afkeuring van de aanvraag door de barman. Eveneens is het mogelijk om al de aanvragen te bekijken die in de wachtrij staan.
9.3.5
Testen
Doordat de zelfde werkwijze gehanteerd werd zoals voorheen, verliep het testen vrij vlot. Dezelfde klassen werden gebruikt waardoor beide applicaties perfect samen werken. Eerst werden beide applicaties afzonderlijk getest om deze daarna als 1 geheel te testen. Doordat de applicaties al grondig getest waren in de eerste zittijd waren er geen fouten meer te bespeuren in de voorgaande applicatie. Door de bescheidenere omvang van de toegevoegde applicatie waren er geen noemenswaardige problemen of fouten.
54
Hoofdstuk 10
Bronvermelding Converse, T. (2004) PHP5 en MySQL. Het complete handboek. Den Haag: Sdu Uitgevers Wikipedia (2006) Programmeren in PHP/Klassen PHP5. Geraadpleegd op 10 januari 2007, http://nl.wikibooks.org/wiki/Programmeren_in_PHP/ Klassen_PHP5 gotApi.com (2007) Quick reference search for HTML, Cascading Style Sheets, JavaScript, AJAX, Oracle, Prototype.JS, PHP, MySQL, ActionScript and more. Geraadpleegd op 10 januari 2007, http://www.gotapi.com Kaap, A. Van Der (2006) Ict en geschiedenis. Geraadpleegd op 11 mei 2007, http://histoforum.digischool.nl/bibliotheek/bronvermelding.htm Carlson, L. Laura (2007) Cascading Style Sheets. Geraadpleegd op 3 maart 2007, http://www.d.umn.edu/itss/support/Training/Online/webdesign/ css.html Monte, O. en Zmievski A. (2007) Smarty - the compiling PHP template engine. Geraadpleegd op 3 maart 2007, http://smarty.php.net/manual/en/ Haryanto H. (2003) Smarty for Beginners Geraadpleegd op 3 maart 2007, http://www.codewalkers.com/c/a/Miscellaneous/Smarty-for-Beginners/
55
Hoofdstuk 10. Bronvermelding
Achour M. en Betz F. en Dovgal A. en Lopes N. en Olson P. en Richter G. en Seguy D en Vrana J. (2003) PHP Handleiding. Geraadpleegd op 10 januari 2007, http://www.php.net/manual/nl/ Romeo C. Mihalcea (2007) Tableless forms. Geraadpleegd op 14 maart 2007, http://www.roscripts.com/Tableless_forms-112.html Jelsoft Enterprises Ltd. (2007) Flash Focus. Geraadpleegd op 5 maart 2007, http://www.flashfocus.nl/ Adobe (2007) Adobe Flash Support. Geraadpleegd op 2 april 2007, http: //www.adobe.com/support/flash/ FlashFiles.nl (2003) The Flash Files. http://www.flashfiles.nl
Geraadpleegd op 12 maart 2007,
Groenendaal, H. Van (2005) Flashdesign voor vormgevers. Den Haag: Academic Service Burger, A. (2004) Leer jezelf MAKKELIJK ... PHP. Culemborg: Van Duuren Media Valade, J. (2004) PHP5 for dummies. Hoboken NJ: Wiley Publishing, Inc. Veer, E. A. Vander (2006) Flash 8: The Missing Manual. Sebastopol CA: O’Reilly Media
56
Bijlage A
Ingediend voorstel
57
iCafé Digitaal bestelsysteem voor de horeca
Voorstel Eindwerk Joeri Verdeyen Stef De Spiegeleer Naim Ben Tanfous
-1-
Probleem: Bij bepaalde horeca etablissementen (denk vooral aan drukke cafés) is het probleem van het lange wachten voor te kunnen bestellen vaak storend voor de klant. 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 voor zowel de barman als de klant een belemmering om een bestelling op te nemen/te plaatsen.
Doelstelling: Een elektronisch bestelsysteem voor in de horeca sector. De bedoeling van ons project is een systeem te ontwikkelen waarbij een klein scherm ingewerkt is in een tafel. De klant kan zo wanneer hij wil zijn bestelling makkelijk plaatsen, en dit door een intuïtieve interface in combinatie met het touchscreen concept. De barman krijgt een real-time overzicht op een monitor van de bestellingen, per tafel.
Uitwerking: Een client side applicatie waarop de klant zijn bestelling kan doorgeven, door op het touchscreen het gewenste artikel kan bestellen. Een Server side applicatie die de bestellingen ontvangt, en weergeeft per tafel. Een admin side applicatie waar de configuratie van het systeem ingesteld kan worden. Gegevens worden draadloos (Bluetooth of Wifi) verzonden tussen clients en server. De algemene configuratie gebeurd op de server. Het systeem wordt geoptimaliseerd voor gebruik in de horecasector. Er kunnen extra opties toegevoegd worden, zoals het gebruik van meerdere server side applicaties waarbij de bestellingen verdeeld worden. Het algemeen opzet en instellingen worden gedaan in de admin applicatie. Vb. Toevoegen van producten, prijzen, overzicht van bestellingen, overzicht per datum, overzicht per product, voorraad, verdeling van clients, positionering van clients.
Joeri Verdeyen Stef De Spiegeleer Naim Ben Tanfous
-2-
Extra functionaliteiten: -
Voorraadbeheer Wachtrij functie ( klant kan zien waneer zijn bestelling behandeld wordt) Aanvragen muziek. Top 5 meest bestelde producten op beginpagina van client tonen. Werkplanning (admin stelt in wie wanneer werkt, eveneens is het mogelijk van overzicht te zien van werknemers met foto) Mogelijkheid van inloggen op het systeem van op andere locatie via Internet. Zo kan de admin van op afstand gegevens opvragen, aanpassen, .. Eveneens maakt dit het mogelijk voor een werknemer om te kijken wanneer hij moet werken.
Eindresultaat: We zullen een volledig systeem afleveren, bestaande uit de 3 delen (admin, client, server). De bedoeling is dat de clients bestellingen kunnen doorsturen naar de server, en de server deze toont op een scherm. Via het admin menu is het mogelijk om de clients en server te configureren, evenals allerhande informatie op te vragen (aantal bestellingen per tafel, verkochte eenheden, …). Indien er ons tijd overblijft, zouden we extra functionaliteiten willen implementeren.
Joeri Verdeyen Stef De Spiegeleer Naim Ben Tanfous
-3-
Bijlage B
Scenario’s B.1 B.1.1
Administrator Joeri Voorstelling
Bill is 43 jaar en bezit al 11 jaar een luxe cafe/taverne. Om zijn zaak zo uniek mogelijk te houden heeft hij het laatste jaar ge¨ınvesteerd in het nieuwe iCafe systeem. Dit systeem laat hem toe orders sneller af te handelen, sneller een overzicht te krijgen van de stand van zaken, enz...
B.1.2
Situatie
Het is zaterdag morgen, en Bill heeft een zware werkdag achter de rug. Het was 5.00u toen de laatste klanten zijn zaak verlieten. Om half 6 kruipt hij nog even achter zijn administrator toestel achteraan in de zaak om de stand van zaken van die avond na te kijken, de kassa na te tellen, de voorraad te beheren en om eventuele wijzigingen aan de menu kaart door te voeren.
B.1.3
De kassa
Bill telt het volledige bedrag dat in alle kassa’s van de zaak aanwezig is. Vooraleer hij dit doet laat hij het administrator systeem de inkomsten van die dag berekenen. Hierbij krijgt hij een overzicht van alle bestellingen, prijzen en een totaal bedrag van die avond. Hij kan zelfs nakijken op welke uren de meeste bestellingen doorgevoerd werden. De stand van deze zware 61
Bijlage B. Scenario’s
avond staat op 2500EUR. Een mooi bedrag voor een zaterdag avond. Hij bedrag van de kassa’s bedraagt ongeveer 2760EUR, dit door de fooien die zijn klanten aan de obers meegaven. Aan de hand van een snelle berekening dat het systeem automatisch voor hem maakt, krijgt hij te zien dat de totale winst voor die avond om en bij de 1700EUR bedraagt. Hij geeft aan in het systeem dat alle kassa’s leeggemaakt zijn en dat er dus geen cash meer aanwezig is in de zaak zelf. Het bedrag van 2500EUR zal hij morgen voormiddag naar de geldautomaat doen, het bedrag van de fooien wordt bijgehouden om later te verdelen. Nu heeft hij concreet dus een overzicht gekregen van: • Het aantal cola’s dat die avond besteld zijn. (en natuurlijk ook andere dranken/snacks) • Het totaalbedrag dat in de kassa’s aanwezig is. (excl. Fooien) • De totale winstmarge van die avond.
B.1.4
Voorraad
Om morgen weer nieuwe klanten te bedienen moet natuurlijk nagekeken worden hoe het met de voorraad staat. Een klant erop wijzen dat er geen Limonade of dergelijke meer te verkrijgen is zou de reputatie van zijn luxe zaak kunnen schaden. Hij kijkt even het algemeen overzicht na van alle producten, hier krijgt hij een lijst van het aantal stuks (eventueel liter) dat nog aanwezig is. Bij de instellingen van het systeem kon hij aangeven waneer een waarschuwing of markering moet gegeven worden bij een bepaald niveau. Zo ziet hij dat er dringend nieuwe flessen Martini besteld moeten worden. Aangezien het aantal Martini flessen nog voldoende is voor zondagavond, schrijft hij toch neer dat maandag nieuwe flessen moeten besteld worden. Van de andere producten is er nog voldoende in voorraad. Waneer hij het menu van de voorraad afsluit denkt hij eraan dat de brouwer zaterdag voormiddag nog 10 bakken Cola Light had geleverd, maar dat hij toen de tijd niet had om deze voorraadwijziging aan het systeem door te geven. Zo gaat hij weer naar het voorraad menu en geeft aan de voorraad van Cola Light met 24x10 verhoogd moet worden. Hij geeft hierbij ook het bedrag mee dat hem dit kostte. Plots denkt hij er ook nog aan, dat er 3 flessen Champagne gesneuveld waren. Omdat deze dus niet meer 62
Bijlage B. Scenario’s
verkocht kunnen worden en dus eigenlijk verloren zijn geeft hij dit door aan het systeem. Dit houdt een voorraad wijziging in die ervoor zorgt dat de Champagne voorraad ook een waarschuwing krijgt. Er zijn nog 12 flessen op voorraad leest hij af. Aangezien het morgen een gewone zondag is zou dit voldoende moeten zijn, doch schrijft hij dit neer om door te geven aan de brouwer. Natuurlijk is dit verlies, en moet het systeem ook weten dat deze Champagne flessen geen inkomsten opleveren. Dit kan hij doen door de verkoopprijs op 0EUR te zetten.
B.1.5
Wijzigingen van het menu
Bill beschikt over de nieuwe glazen van Stella Artois, zoals bekend hebben deze een iets grotere inhoud. Dit houdt in dat hij dus minder winst gaat maken bij eenzelfde voorkoop. De meeste klanten die bij Bill iets komen drinken, kijken niet meteen op een Euro meer of minder. Bill zal deze wijziging na enkele weken/maanden wel aan zijn winstmarge voelen. Hierdoor gaat hij de prijs van een pintje verhogen van 2,50EUR naar 2,75EUR. Bill gaat naar het menu voor wijzigingen aan te brengen op zijn menukaart. Dit gaat heel simpel. Hij kan zelfs de volgende zaken doen in dit menu: • Producten toevoegen • Producten wijzigen • Producten verwijderen • Categorie¨en toevoegen / verwijderen Hij kiest dus om een bepaalde product te wijzigen, hierbij kiest hij de categorie drank, daar staat Stella Artios 25cl genoteerd op 2,50EUR. Hij klikt dit product aan en zo krijgt hij een overzicht van alles gegevens van dit product, gaande van naam, beschrijving, plaatje, prijs, inhoud, ... enz. Hij wijzigt het bedrag naar 2,75EUR en drukt op OK om de wijziging door te voeren. Ook denkt hij eraan dat hij sinds woensdag van Koffie is veranderd. Hiermee wordt bedoelt dat hij van merk wisselde. Aangezien de meeste klanten deze verandering niet meteen opmerken had hij dit nog niet gewijzigd. Hij drukt op de categorie drank, en geeft in de zoek balk de term ’koffie’ in. Nu krijgt 63
Bijlage B. Scenario’s
hij een overzicht van alle producten met het ’label’ koffie. Hij kiest diegene die gewijzigd moet worden en voert dit door.
B.1.6
Preview
Waneer hij in het start menu van zijn administrator systeem zit, klikt hij op het knopje met label ’preview’. Er gaat een nieuw venster open, en Bill krijgt net hetzelfde te zien wat de klanten op hun scherm te zien krijgen. Hij kijkt even na of de wijzigingen succesvol doorgevoerd zijn. Alles is in orde en Bill sluit zijn administrator venster af.
B.1.7
De mogelijkheden
Producten Een administrator heeft volgende mogelijkheden bij het menu van de producten: • Categorie toevoegen/bewerken/verwijderen • Producten toevoegen/bewerken/verwijderen Een Categorie beschikt over volgende gegevens: • Naam • Optionele beschrijving • Sorteervolgorde Een Product beschikt over volgende gegevens: • Naam • BTW Tarief • Prijs (incl/excl BTW) • Beschrijving • Afbeelding
64
Bijlage B. Scenario’s
• Inhoud ( liter/kilogram) • Fabrikant • Voorraad • Sorteervolgorde • ...
B.2
Client Stef
Luc gaat ’s avonds een pintje drinken in het vernieuwde hippe caf´e Penta. Hij heeft gehoord dat de nieuwe eigenaar veel ge¨ınvesteerd heeft in allerhande technologie, gaande van beamers voor projectie van de sponsors op de muur tot een digitaal bestelsysteem voor je drank en versnaperingen. Hij heeft afgesproken met 2 vrienden voor de ingang van het caf´e. Eens aangekomen zitten zijn 2 drinkbroeders hem reeds op te wachten. Als ze binnen zijn zien ze dat er veel volk aanwezig is, en er is dan ook geen plaatsje vrij aan een tafelt. Ze bestellen 3 pintjes aan een ober die net passeerde. Deze drukt op een soort van Pocket PC de bestelling in en gaat er weer vandoor om de bestelling op te nemen van het groepje naast Luc en zijn vrienden. Na deze bestelling opgenomen te hebben loopt de ober door naar de toog, waar net de laatste pint van 3 getapt word. De Ober neemt deze aan en brengt ze naar Luc, die deze gretig aanneemt. De Ober drukt op het touch screen van de Pocket Pc en zegt da is 4,5EUR alsjeblief. Luc betaald, en begint tegen zijn vrienden te vertellen hoe slecht de rode duivels niets zijn in vergelijking met de ploeg van Mexico ’86. Een vriend pikt in en de discussie is op gang getrokken. Een kwartiertje en vele woorden later ziet Luc dat de mensen aan de tafel een beetje verder vertrekken, stapt naar de tafel toe en zet zich neer, waar zijn 2 vrienden hem in volgen. Ze beslissen nog een ronde te doen en Luc test de nieuwe bestelmethode uit. Hij drukt op de touch screen, die zich in het midden van de tafel bevind en door de aanraking licht het touch screen op. Er komen 2 mooi grafisch vormgegeven icoontjes tevoorschijn. Met respectievelijk de tekst drinks en snacks onder. Hij drukt op drinks en komt in het menu terecht met al de beschikbare dranken. Hij drukt op Stella Artois 25cl, hij drukt op wijzig 65
Bijlage B. Scenario’s
aantal en veranderd dit naar 3. Hiernaa drukt hij op bestel en volgend bericht komt tevoorschijn: De bestelling is doorgegeven, u zult zo vlug mogelijk bedient worden. Wanneer wilt u afrekenen? Nu - Later. Luc drukt op later, aangezien hij nog niet van plan is naar huis te gaan. De ober komt even later ook de 3 Stella’s brengen en nootjes. Ze beginnen te discussi¨eren, deze keer over de scheiding van Justine Henin(-Hardenne). Weeral vliegt de tijd voorbij en de kelen worden droger en droger, dus beslissen ze nog een laaste consumptie te nemen. Luc drukt op het touchscreen, dit licht op en er komen weer 2 icoontjes tevoorschijn, maar deze keer staat onderaan het scherm ook icoontje van een glas bier met de text bestel: Stella Artois 25cl onder. Luc klikt hierop en komt op een scherm terecht met de text: Stella Artois 25cl 3x - wijzig aantal Voeg item toe - Bestel Luc heeft ondertussen ook best wel honger gekregen en drukt op voeg item toe, waarna hij weer op het beginmenu komt met het drinks en snack icoontje. Hij drukt op het snack icoontje om te kijken wat het aanbod is voor de lichte honger. Hij ziet een overzicht van alle items en klikt op Portie Mix (kaas en salami) en bevestigd de bestelling door op de knop bestellen te drukken. Hij drukt op Bestel en krijgt weer het scherm dat zegt dat de bestelling verzonden is en of hij nu reeds wil betalen of later. Deze keer drukt Luc op Nu. Luc drukt op betaal en er komt een bericht met de boodschap Je rekening wordt zo meteen gebracht. De ober komt even later de 3 pinten en de portie mix geven. Eveneens geeft gij een ticketje met het geconsumeerde bedrag op. Hij betaal de 13,5EUR cash aan de ober. Het zou nog 20 minuten duren voor de pinten en de portie mix verorbert zijn en Luc en zijn vrienden hun wegen scheidden om de auto in te kruipen naar huis.
B.3
Administrator Stef
Francis, Swa genoemd door de vrienden, is uitbater van cafe Penta in Dilbeek. Hij heeft recent verbouwingen aan zijn etablissement uitgevoerd. Een bijbouw met tafels, een volledig nieuwe bar inclusief apparaten, een nieuwe Bose muziek installatie en een digitaal orderdersysteem zijn de grootste kosten geweest. Hij hoopt dan ook dat deze investeringen zich zullen terug66
Bijlage B. Scenario’s
verdienen. Hij wil zich namelijk op een nieuw publiek storten, zijnde mensen tussen 25 en 40 die in alle comfort iets willen drinken, en waarbij de prijs van de consumptiegoederen ondergeschikt is aan een rustige sfeer en goede service. Vanavond is de grote heropening en hij moet nog het iCafe systeem configureren, dus begint hij hieraan. Hij krijgt een beginscherm te zien dat vraagt achter inloggegevens. Hij heeft dit samen gekregen met de aankoop van het systeem. Hij voert het standaard gebruikersgegevens in en passwoord en klikt op login. Eens ingelogd krijgt hij het admin menu te zien, bestaande uit volgende opties: • Productbeheer – Voeg product toe – Verwijder product – Bewerk product – Voeg categorie toe – Verwijder categorie – Bewerk categorie • Gebruikersbeheer – Voeg admin toe – Bewerk admin – Verwijder admin – Voeg moderator toe – Bewerk moderator – Verwijder moderator – Bewerk rechten admin/moderator • Voorraadbeheer – Kijk voorraad na – Wijzig vooraad per product (nodig indien gebroken glas oid, glas is weg maar niet aangerekend) – Wijzig voorraad per productgroep (idem) 67
Bijlage B. Scenario’s
• Sponserbeheer – Sponsors aan/uit – Voeg sponser toe – Wijzig sponser – Verwijder sponser – Wijzig layout sponsers • Configuratie – Herstel netwerk – Configureer netwerk – Stel aantal clients in (beveiliging: zodat er niet meer clients kunnen gebruikt worden als aangegeven, zodat iemand me bv PPC niet op netwerk kan) Bij de documentatie dat bij het product kwam stond er bij dat het aan te raden is de standaard login gegevens te wijzigen. Dus klikt hij op Gebruikersbeheer - voeg admin toe. Hij maakt dus nieuwe admin aan met naam Francis en geeft eveneens een paswoord. admin aangemaakt komt er tevoorschijn op het scherm. Hij logt uit en logt in met de zojuist aangemaakte admin account. Al de configuratie instellingen zijn reeds gedaan door de installateur van het systeem en hier moet hij zich dus geen zorgen meer over maken. Nu wil hij producten en prijzen invoeren en klikt op productgroep aanmaken. Er komt een invoerscherm tevoorschijn met de tekst: voeg de naam van u productgroep in. Swa voert op het toetsenbord Bieren van het vat in en drukt op bevestig. Er komt een nieuwe pagina die weergeeft dat de productgroep is aangemaakt en met hieronder de mogelijkheid om reeds producten toe te voegen. Hij voegt Jupiler 25cl, drukt op bladeren en selecteert een afbeelding van een jupiler in een 25cl glas. Vervolgens vult hij de prijs in, drukt op ok en vervolgens op voeg product toe. Een nieuw product is aangemaakt in de subcategorie Bieren van het vat. Hij doet ditzelfde voor de producten Jupiler 33cl en 50cl, Maes 25cl, 33cl en 50cl Leffe Blond 33cl en Witte van Hoegaarden 33cl. Hierna maakt hij nog een categorie Soft Drinks en hapjes aan en vult de te verkopen producten in bij de juiste productgroep.
68
Bijlage B. Scenario’s
Ook wil hij de clients voorzien van sponsoring, dus klikt hij op Sponserbeheer - Sponsers aan en vervolgens op Voeg sponsor toe. Er komt een pagina tevoorschijn met de optie om te bladeren door bestanden. Swa bladert naar de foto van Bacardi, en klikt op oke. Er komt een preview pagina tevoorschijn die toon hoe de layout van de pagina eruit ziet. De afbeelding van Bacardi staat nu links op de pagina en de content rechts. Hij zou dit willen veranderen zodat het logo van Bacardi bovenaan staan. Hij doet dit via Wijzig layout sponsers. Vanavond werken de 2 barmannen Dries en Jo en dus moeten deze aangemaakt worden in het systeem. Swa gaat naar Voeg moderator toe en typt de gegevens van Dries in. Eveneens vult hij het begin uur in waarop hij moet beginnen werken, en doet na voltooiing hiervan hetzelfde voor Jo.
B.4
Barman Stef
Barman Driens en Jo moeten deze avond werken in het cafe Penta. Dries moet openen om 16u en Jo moet inspringen rond 20u. Het is vandaag de heropening en ook de eerste maal dat er met het nieuwe ordersysteem gewerkt wordt. Om 15u42 komt Dries toe in de Penta, trekt zijn kleren op zijn bovenlichaam uit en doet een t-shirt met logo van penta op de voorkant en met het bacardi logo op de achterkant. Hij start de pc aan de bar op, en logt in met de gegevens die hij gekregen heeft van Swa. Er komt een leeg scherm tevoorschijn met 1 knop: schijf je in. Hij klikt hierop en er komt een bericht dat vermeld dat hij om 15u51 ingeschreven is om te werken. Op datzelfde ogenblik stapt de eerste klant binnen en zet hem rechtover Dries aan de bar. Stellake aub. Dries tapt de klant een pint en drukt op het ˆ tevoorschijn op het scherm. barscherm op Stella 25cl. Er komt 1,5U De klant betaalt dit contant en neemt een teug van zijn pint. Wat later komt er een koppel binnen en zetten hun aan een tafel. Ze doen rustig hun jas uit en besluiten iets te bestellen. Op het barscherm komt een bestelling binnen en word duidelijk gemaakt dmv een popup. Tafel 3 is geactiveerd Bestelling: 69
Bijlage B. Scenario’s
1x Amaretto 1x Stella 33cl 1x Lays: peper en zout Totaal:7EUR Dries schenkt de amaretto uit, tapt het pintje en neemt de zakje chips en gaat de bestelling opdienen. De uren die passeren word nog veel besteld door tafel 3 en de rekening loopt in de achtergrond op. Even later beslist het koppel om toch door te gaan en drukken op de knop betalen op het touchscreen. Op het barscherm komt een bericht dat tafel wenst te betalen. Dries klikt hierop en er wordt een overzicht gegeven van al de consumpties, en de totale prijs. Hij klikt op print en het ticket word afgeprint. Hij gaat dit geven aan tafel 3 en deze betalen direct cash het verschuldigde bedrag. Dries loopt naar het barscherm en klikt op het icoontje van tafel 3 om een overzicht te hebben. Op het overzichtscherm klikt hij op betaald. Het scherm verdwijnt en de tafel komt automatisch op de status vrij. Om 19u45 komt Jo toe, slaat even een babbel met Dries en trekt een werk t-shirt aan. Ook hij schrijft zich in om te werken. Er word gretig gebruikt gemaakt van de digitale bestelmanier en Dries en Jo hebben dan ook hun handen gedurende afmattende uren vol. Om 2u en als het grotendeel van het volk weg is besluit Dries om te stoppen met werken. Hij logt in op de computer en klikt op uitschrijven. Het systeem geeft een bericht dat hij uitgeschreven is, om vervolgens na 5 seconden automatisch over te gaan op het kassascherm. Hij kleed zicht weer aan, en vertrekt, na iedereen die nog aanwezig is dag te zeggen, huiswaarts. Betaling later Totaal voor de tafel: 7EUR
B.5
Client Naim
Jan en Paul gingen een zaterdagavondje stappen naar het nieuwe iCafe die uitgebaat wordt door Stef, Joeri en Naim. Ze nemen plaats aan een tafel waar 2 meisjes zaten. Jan wil bestellen en vraagt aan Paul wat hij wil drinken. Ze willen beiden een Bacardi Breezer. Alleen merken ze op dat de ober 70
Bijlage B. Scenario’s
niet komt vragen wat ze willen drinken en dat er een scherm in hun tafel zit, waarop staat druk op het scherm om te bestellen. Jan drukt en komt in een menu terecht. Het menu bestaat uit Menu, Muziek aanvragen, Rekening bekijken, Bestelling bekijken, Promoties, toegang tot hotspot. Hij kiest voor Menu waarop hij terecht komt in de menu kaart met alle soorten dranken. Hij klikt 2 keer op bacardi breezer en klikt daarna op volgende onderaan het scherm. Hij ziet nu dat hij 2 keer Bacardi Breezer heeft besteld en dat hij aan een totaal van 6 euro zit. Hij heeft nu de keuze direct betalen of betalen aan het einde. Hij kiest voor direct betalen. Er komt een pop-up te voorschijn met gelieve even te wacht er komt zo een ober tot bij u. Wat later op de avond wil Paul ook een glas betalen aan Jan. Hij klikt op Menu en klikt 2 keer op Jupiler 33 cl. en klikt daarna op volgende onderaan het scherm. Hij ziet nu dat hij 2 Jupilers heeft besteld en dat hij aan een totaal van 3 euro zit. Hij heeft nu de keuze direct betalen of betalen aan het einde. Hij kiest voor direct betalen. Er komt een pop-up te voorschijn met gelieve uw geld al klaar te leggen. Vijf minuten later komt een ober het geld ophalen. Na enkele pinten, zijn ze beiden al wat in de wind. Jan vraagt of Paul met hem wil dansen. Paul zegt dat hij alleen maar wil dansen op het nummer like the wind van Vanessa Chinitor. Jan reageert en had gemerkt dat je muziek kon aanvragen. Jan klikt op muziek aanvragen en hij zoekt het nummer in de lijst. Hij klikt op het nummer en ziet dat er nog 4 wachtende liedjes voor hem zijn en dat het ongeveer nog 12 minuten zal duren vooraleer ze kunnen dansen. Jan besluit dan maar zen Packard Bell boven te halen. Hij ziet dat er een wireless netwerk in het caf´e beschikbaar is. Deze is helaas beveiligd met een WEP key. Jan informeert ernaar en hoort dat je een key kunt aankopen. Hij gaat naar het menu op het scherm kiest toegang tot hotspot. Hij kan dan kiezen voor hoelang hij toegang wenst te kopen. Hij kan kopen voor 15 minuten, 30 minuten en 60 minuten. Hij kiest voor 15 minuten en betaalt hiervoor 2,5 euro. Deze worden aan het eindbedrag toegevoegd. Hij krijgt nu een WEP key via een pop up venster. Er staat ook op deze pop-up dat deze key maar 3 maanden geldig is. Na tien minuutjes horen ze
71
Bijlage B. Scenario’s
hun aangevraagde nummer en besluiten ze te gaan dansen. Na het dansen besluiten ze de zaak te verlaten, maar bij het naar buiten gaan worden ze tegen gehouden door een ober. Hij vertelt hen dat ze nog een open staand bedrag van 2,5 euro hebben. Deze waren ze compleet vergeten, en betalen cash aan de ober. De ober gaat naar de bar waar hij in het hoofdsysteem de tafel 29 markeert als betaalt.
B.6
Barman Naim
Danny, komt rond 10u de zaak binnen. Hi j start alle clients op en de pc van de barman. Er komt een welkomscherm. Hij klikt op zijn naam onder de barmannen. Het systeem ziet nu welke barman er is, en of dit wel klopt met wat in het systeem staat. Danny neemt een kijkje in de voorraad via het systeem, en ziet dat de cola en de vaten jupiler bijna op zijn. Hij klikt op bestellen. Hij komt op een scherm waar de gegevens van de leveranciers staan. Hij belt de leverancier die hem zegt dat hij deze namiddag zal leveren. De barman keert terug naar het voorraad scherm en klikt naast cola dat hij 8 bakken cola bestelt heeft. En naast Jupiler geeft hij 3 vaten in. In de loop van de namiddag heeft Interbrew geleverd. Barman Danny geeft in het systeem in dat de bestelde gegevens aangekomen zijn. In de loop van de avond in volle drukte ziet de barman dat er een bestelling binnen loopt voor tafel 23. Drie cola’s, twee pinten en ´e´en witte wijn. Rechts onderaan ziet hij 2 minuten 45 seconden. Dit wil zeggen dat hij volgens het systeem zoveel tijd nodig heeft om zijn bestelling af te handelen. Dit is ook de tijd die de klant ziet hoelang het nog duurt vooraleer zijn bestelling geleverd wordt. Daarbij moeten de voorgaande bestellingen opgeteld worden, en de tijd die nodig is door de ober om die te brengen. Al direct ziet hij dat er weer een nieuwe bestelling binnen loopt die knippert onderaan het scherm. De eerste bestelling is af en hij klikt op de bestelling in het scherm waarop 72
Bijlage B. Scenario’s
hij de nieuwe bestelling ziet. E´en cola en ´e´en biertje. De barman handelt de bestelling af en ziet nu een heel deel bestellingen knipperen onderaan het scherm. Druk dus!!! De barman handelt elke keer weer een bestelling af klikt op die bestelling, en ziet de volgende bestelling op zijn scherm. Rechts onderaan ziet hij elke keer hoeveel tijd er hem volgens het systeem nog rest om de bestelling af te handelen. Op het eind van de avond, moet het systeem afgesloten worden door de barman.
B.7
Administrator Na¨ım
Admins Joeri, Stef en Naim zitten bij het opstarten van hun nieuw caf´e samen om de werknemers in het systeem te geven. Ze geven bijvoorbeeld eerst Danny in, de eerste barman die ze hebben aangeworven. Ze geven al zen gegevens in zoals adres, geboortedatum, enz. Daarna geven ze aan welke dagen hij deze week moet werken. Dit doen ze elke keer opnieuw voor elke werknemer. De eerste keer moeten ze ook een menu kaart ingeven. Ze geven alle mogelijke consumpties in het systeem in die ze zullen aanbieden, met hun prijzen. Ook zullen ze de hostpot tarieven ingeven. Deze maand hebben ze een contract afgesloten met Jupiler om sponsering. Ze geven de opdracht aan Jupiler om een banner van 200 op 40 pixels te ontwerpen en door te sturen via mail. Ze hebben deze gisteren ontvangen, en geven deze in in het systeem. Deze banner is nu te bezichtigen op alle clients. Verder staat de wordt door iTunes een xml bestand gegenereert, met alle muziek in de iTunes van het systeem. Dit bestand word door een php scriptje gelezen en omgezet naar een Muziek aanvraagen lijstje die door de clients kan opgevraagd worden.
73
Bijlage C
Diagrammen C.1
Database ontwerp
74
username
user_id
PK,FK1 PK
user_id password
user_password
PK
start end table
user
session_id
PK
content
PK,FK1
forname surname address tel gsm dob student image
user_id
user_data
payment delivered start
order_id
order
session
PK
name
product_id
content
PK,FK1
product_id
PK
product
session_id order_id
FK2 FK1
FK2
FK1
user_id date order_id
type
user_id
user_type
product_id stock_type_id value
stock
product_id category_id
PK,FK1
FK2 FK1
PK,FK2 PK,FK1
subtitle
PK
naam beschrijving parent_id
FK1
price
product_id
PK
table_ip name
table_id
table
type autostock content
stock_type_id
stock_type
category_id
category
PK,FK1
sale_price
PK
product_id
subtitle PK,FK1
product_category
description
product_id
user_order
order_id product_id
order_products
FK1 FK2
session_orders
PK,FK1
product_desc
Database ontwerp: Products/Sessions/Orders … (versie 1.0)
image
product_id
FK1
product_id price
purchase_price
PK,FK1
image
PK
PK,FK2 PK,FK1
value name
tax_id
tax
product_id tax_id
product_tax
Bijlage D
Verslagen van vergaderingen D.1
Vergadering 1
76
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Verslag vergadering 03 januari 2007 Aanwezig Naim Ben Tanfous, Stef De Spiegeleer, Joeri Verdeyen Voorzitter Notulist Stef De Spiegeleer Joeri Verdeyen Plaats Wespelaar
Begin –en einduur 14u00 – 17u15
Onderwerpen: ‐ ‐ ‐ ‐ ‐ ‐ ‐
Communicatie Taalkeuze Materiaal Latex Documentatie Planning Volgende vergadering
Communicatie Subversion systeem Belangrijk in dit project is de communicatie en de verdeling van informatie. Ook de toegankelijk van alle informatie door alle leden is van groot belang. Om dit zo vlot mogelijk te laten verlopen zullen we voor de verdeling van de code een subversion systeem gebruiken. Zo kan iedereen aan alle code die reeds geschreven is. Het is ook noodzakelijk dat alle versies of bijgewerkte stukken zeer goed becommentarieerd worden. Bij elke code wordt er duidelijke documenten/commentaar geschreven, zodanig dat er niets ontleed moet worden waardoor er veel tijdverlies optreed. Er werd beslists om i.v.m. dit subsversion systeem toch enkele vragen aan de project promoter te stellen. Waar zal deze server staan ? Welke applicatie zullen we gaan gebruiken? Volgende vergadering zal hier meer duidelijkheid in komen. Forum Om alle informatie van links, documentatie, code, opmerkingen, verslagen en dergelijke beschikbaar te stellen voor elk lid van het project , zal er een forum aangemaakt worden. Hierbij zullen we ernaar streven om alle informatie die ook maar iets met het project te maken heeft hierop te plaatsen in verschillende categorieën. Zodanig dat ook maar elk detail hierop te vinden is.
Taalkeuze Algemeen concept Het algemeen concept is al in grote lijnen uitgetekend, hierbij zullen we gebruik maken van een server die verantwoordelijk is voor alle berekeningen. PHP De taal die alle gegevens zal verwerken en berekeningen zal maken is PHP. Alle leden stemde hiermee akkoord. We hadden ook enkele punten die deze keuze ondersteunde, hieronder: ‐ PHP is volledig gratis, omdat ons project toch enigszins commercieel gericht, moeten we opteren voor goedkopere oplossingen die toch voldoen aan onze eisen. Met commercieel gericht wordt bedoelt dat het zo realistisch mogelijk moet gehouden worden, de aankoop van enkele licenties kan de aankoop prijs van aanzienlijk verhogen. ‐ PHP is multi‐platform. Zowel op besturingssystemen als Linux, Ms Windows en Mac OSX is het mogelijk om een server te draaien die PHP ondersteuning biedt. Hierbij zijn we dus compleet onafhankelijk van het besturingsysteem en zal dit ons ook nooit uitsluiten tot het gebruik van gratis distributies van Linux en dergelijke. ‐ MySQL als database. Net als PHP is MySQL open‐source en dus gratis te gebruiken. Het werkt zeer nauw samen met PHP en vormt een perfecte combinatie.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
1
iCafe
‐
Eindwerk 2006‐2007
Erasmushogeschool Brussel
De uitbreiding van onze kennis. Omdat PHP blijft evolueren en ondertussen al uitgegroeid is tot één van de bekendste webtalen willen we hier ook in doorbreken. Een goede kennis van PHP zal nooit een negatief punt zijn.
Andere Omdat natuurlijk niet alles gedaan wordt in PHP, maar waarschijnlijk alleen het server gedeelte, zal er ook gebruik gemaakt worden van Flash in samenwerking met XML. Andere talen of frameworks kunnen nog besproken worden.
Materiaal Even werd er overgegaan tot het nodige materiaal, aangezien dit al een vrij praktisch gericht onderwerp is werd hier niet zeer ver op ingegaan. Toch werd er al voorgesteld om te zoeken achter een server voor de programma codes uit te voeren en te kunnen testen. Ook het gebruik van een touchscreen kwam aan bod. Het touchscreen wordt alleen gebruikt door de clients (in ons systeem de klanten die bestellingen opnemen en de obers die bestellingen afhandelen) Het kon eventueel mogelijk gemaakt te worden om toegang te krijgen tot het systeem doormiddel van een PocketPC.
Latex Er werd besproken dat we voor het eindverslag gebruik zullen maken van Latex. Hiervoor werd Latex Editor gekozen als programma voor de verwerking.
Documentatie Er werd nogmaals benadrukt hoe belangrijk het is om alles degelijk en verstaanbaar te documenteren. Niet alleen voor eigen gebruik maar ook voor derde en eventuele uitbreidingen.
Planning Om al een zicht te hebben op de tijd die ons rest om dit project af te werken stelden we al enkele data met buffers op om volgende zaken af te werken: Diagrammen/overzicht Alle diagrammen en overzicht tabellen om aan de code te kunnen beginnen worden opgesteld tegen week 3 van het project (week 16 van de academische kalender) . Dit is de week van maandag 15 januari. In deze week zal er ook een vergadering plaatsvinden waarbij alle diagrammen collectief besproken en gecorrigeerd worden. Code Vanaf het moment dat alle diagrammen correct opgesteld zijn kan er aan de code begonnen worden, hierbij werd voorspeld van dit ook in week 3 (week 18 AK) te kunnen doen. Algeheel concept De afwerking van het geheel staat gepland op week 17. Tussentijds zullen er deadlines voor bepaalde stukken worden opgesteld Afwerking verslag Het verslag wordt afgewerkt tegen week 19. Samenvoegen van verslag Om niet alles tot het einde te laten aansleuren, werd er beslists om vaste data te plannen om afgewerkte delen van het verslag al samen te voegen en te bespreken.
Volgende vergadering Datum De volgende vergadering zal plaatsvinden op 9/10 januari 2007. Locatie Erasmushogeschool Brussel Afspraken Volgende zaken worden verwacht tegen de volgende vergadering: ‐ Forum wordt online geplaatst door Stef
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
2
iCafe
‐ ‐ ‐ ‐
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Er wordt ftp toegang voorzien voor alle leden, Stef zorgt hiervoor. Informatie wordt opgezocht over het gebruik van een SVN server + client. Afgewerkte diagrammen worden al voorgelegd. Documentatie websites,boeken i.v.m. PHP kunnen al voorgelegd en gedeeld worden.
Agendapunten ‐ Forum ‐ FTP ‐ SVN ‐ Diagrammen ‐ Deadlines herzien ‐ Afspraak met promotor ‐ Documentatie PHP, SVN, Latex
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
3
Bijlage D. Verslagen van vergaderingen
D.2
Vergadering 2
80
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Verslag vergadering 03 januari 2007 Aanwezig Naim Ben Tanfous, Stef De Spiegeleer, Joeri Verdeyen Afwezig: Niemand Voorzitter Notulist Naim Ben Tanfous Stef De Spiegeleer Plaats Begin –en einduur Wespelaar 14u30 – 15u40
Onderwerpen: ‐ Forum ‐ SVN ‐ FTP ‐ Tijdsnotatie ‐ Volgende vergadering Er is een forum geinitialiseerd en hier te bekijken is: http://www.stefds.be/eindwerk/forum. Een structuur is aangemaakt waarmee we denken tegemoet te kunnen komen aan de verschillende onderdelen die nodig zijn om het verloop van het eindwerk vlotter te laten lopen.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
1
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Het is makkelijk om mee te kunnen delen welke bestanden er geupload zijn naar de webruimte, eventueel kunnen hier ook documentatie, opmerkingen of suggesties bijgeschreven worden. Omdat per bestand een topic aangemaakt wordt is het overzichtelijker om dit ook via een forum mede te delen ipv enkel de files op de server te zetten. Ook de commentaren op een bestand worden in het topic van het bestand zelf geschreven en ook dit draagt dus bij tot de overzichtelijkheid. Dit is zeer handig naarmate de kwantiteit van bestanden groeit. Ook informatie, zijnde ebooks en tutorials ed, zal hierop gepost kunnen worden. We hebben ons alle 3 geregistreerd en zijn alle 3 administrator (en automatisch ook moderator). Al de secties zijn enkel zichtbaar gemaakt voor moderators, en dit zodat derden geen toegang hebben tot onze files en ze de interne communicatie niet kunnen lezen. Dit lijkt wat voorbarig voor een project van deze (relatief) kleine schaal en op dit ogenblik beperkte commerciële waarde, maar toekomstgericht weten we nog niet of we verder gaan na ons eindwerk met dit project, en een beetje voorzichtigheid kan dus zeker geen kwaad.
SVN Google Code Het delen van files gerelateerd aan het project zelf zullen gedeeld worden via Google code. Het voordeel van hiermee te werken is de centralisatie van al de bestanden, evenals het feit dat het gebruik ervan gratis is. We hebben 100MB ruimte toegewezen gekregen, wat normaal ruimschoots moet voldoen. Joeri heeft dit opgezet en reeds voorzien van elke op dit moment benodigde labels, zijnde: ‐ Verslag = Een bestand ivm de meetings ‐ Applicaties = Een applicatie bestand ‐ Document = Een document met informatie ‐ Code = Een document met code (voorbeelden) ‐ Scenario= uitgeschreven scenario's ‐ Diagram = Een diagram ‐ SVN = Dit bestand heeft te maken met het subversie systeem ‐ Usecase = Een usecase diagram ‐ Sequence = Een sequentie diagram ‐ WorkFlow = Een workflow diagram ‐ Class = Een class diagram ‐ Voorbeeld = Dit is een voorbeeld, en moet nog bijgewerkt worden ‐ Final = De final versie van een werkstuk ‐ ext_pdf = pdf bestand ‐ ext_exe = een executable file ‐ ext_doc = word document ‐ ext_php = php document ‐ ext_jpg = jpg file ‐ ext_txt = txt file Joeri zal zich eveneens in turtoise verder verdiepen tegen de volgende meeting en uitleg verschaffen aan Naim en Stef over het gebruik hiervan.
FTP Er is afgesproken om de bestanden te delen via Google. De FTP toegang zal niet meer gebruikt worden en is dan ook verwijderd.
Tijdsnotatie Er werd gesproken of het nuttig was om de gepresteerde uren voor het project bij te houden. We hebben besloten om gebruik te maken van tijdsnotatie, aangezien we zo een overzicht hebben hoeveel tijd we in elk deel gestoken hebben. Zo kan vergeleken worden met de hoeveelheid tijd dat er voor dat deel gebudgetteerd werd. Indien we dan later een gelijkaardige opdracht hebben hebben we een goede referentie voor de te
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
2
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
budgetteren tijd te plannen. Bij voltooiing van het eindwerk hebben we zo ook een overzicht van de tijd dat we er elk ingestoken hebben.
Volgende vergadering Datum De volgende vergadering zal plaatsvinden op 17 januari 2007. Locatie Erasmushogeschool Brussel Afspraken Volgende zaken worden verwacht tegen de volgende vergadering: ‐ Tegen 16 januari volledige uitgebreide scenario, voor zowel de admin, de barman als voor de client ‐ Uitzoeken hoe we het best met tijdsnotatie werken en welke programma’s er gebruikt kunnen worden ed. Agendapunten ‐ Uitleg over Turtoise SVN door Joeri ‐ Gedetailleerd uitschrijven van de functionaliteiten van iCafe ‐ Bespreken van eventueel reeds gemaakte diagrammen ‐ Afspraak met promotor
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
3
Bijlage D. Verslagen van vergaderingen
D.3
Vergadering 3
84
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Verslag vergadering 17 januari 2007 Aanwezig Stef De Spiegeleer, Joeri Verdeyen Voorzitter Stef De Spiegeleer
Notulist Joeri Verdeyen
Plaats Erasmushogeschool Brussel
Begin –en einduur 13u20 – 15u25
Onderwerpen: ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐ ‐
Subversion systeem Logboek Timesheets Tags op Google Code Scenario’s Discussie: Barmannen Overzicht tafels Producten en categorieën (relaties) Database ontwerp Voorraad beheer Volgende vergadering Agenda
Subversion systeem Het was tijdens deze vergadering de bedoeling dat Joeri een korte uitleg gaf over de algemene werking van het subversion systeem dat we zullen gebruiken. Aangezien we hierin vrij van keuze zijn blijven we opteren voor de gratis versie van Google namelijk, Google Code. Op het moment dat de demo wou gestart worden bleek de server van Google offline te zijn. De service was tijdelijk onbereikbaar. Aangezien we ons dit niet kunnen veroorloven tijdens het verwerken van de code (in de nabije toekomst) zullen we eventueel betwisten om over te gaan tot de svn server van EHB zelf. Tijdens de meeting werd ons verteld dat deze ook een svn server heeft en dat we hier vrij van gebruik van mogen maken. Zoals reeds in de vorige vergaderingen afgesproken zal er gebruikt worden van de Shell extension Tortoise.
Logboek Het logboek werd aangevuld in verband met de meeting met onze project promotor Meneer Van Laethem. Deze eerste vergadering omvatte een bespreking van algemene punten zoals het communicatieplatform, technologie en planning tegen eind januari.
Timesheets Om de tijd die we gebruiken voor het afwerken van het project gaan we gebruik maken van timesheet. Dit is een manier van weergeven van taken met begin en eindtijd en de datum waarop deze taak uitgevoerd werd. De timesheets kunnen vanaf nu gebruikt worden bij eender welke taak. Voor de timesheets wordt gebruik gemaakt van een vast xml patroon, namelijk:
<entry>
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
1
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
2007/01/16 14.00 <end>16.00 <subject>Relatiediagrammen <desc>Een kort scenario over de relaties tussen objecten,... De timesheets worden zelf aangevuld. Om deze toegankelijk te maken voor alle leden worden ze in een directory ‘timesheet’ geplaatst op de svn server. Volgende vergadering word hier nog eens nadrukkelijk op toegezien hoe deze op de svn server geplaatst worden. De bestandsnamen zijn als volgt verdeeld: joeri.xml, stef.xml, naim.xml.
Tags op Google Code Zoals afgesproken worden er bij het uploaden van bestanden naar de server, tags gebruikt. Om hierbij enige duidelijkheid te maken ivm met de maker van het bestand worden de tags ‘naim’,’joeri’,’stef’ toegevoegd. Deze dienen dus gebruikt te worden door de eigenaar van de naam en het overeenkomstig document. Hierbij is er ook een overzicht over welke taken bepaalde personen wel/niet hebben gemaakt.
Scenario’s Er werd algemeen beslist dat alle scenario’s door iedereen goed doorgelezen en bestudeerd moeten worden. Het is algemeen de bedoeling dat hierop veel dieper word ingegaan en minder oppervlakkig wordt geredeneerd. Zo heeft iedereen de kennis van wat er in de scenario’s staat nodig, om niet op andere manieren bepaalde redeneringen te maken. Commentaar of wijzigingen kunnen steeds meegedeeld worden op het forum of rechtstreeks naar die persoon toe, wel moet iedereen van het project op de hoogte gehouden worden van eventuele wijziging. In de meeste scenario’s die nu geschreven zijn zal nog dieper gegraven moeten worden naar eventuele problemen of situaties die niet meteen vanzelfsprekend zijn. Foutieve redeneringen of onopgemerkte fouten kunnen ons in de toekomst erg ophouden.
Discussie: Barmannen De discussie van het switchen tussen barmannen op eenzelfde systeem kwam even aan bod. Het is een probleem situatie die zich voordoet waneer 2 barmannen van 1 systeem gebruik maken om bestellingen af te handelen. Volgende oplossingen werden voorgesteld: Oplossing 1 Het menu beschikt over een knopje waarbij tussen de barmannen geswitched kan worden, zo worden ook de tafels toegekend aan bepaalde barmannen. De barman krijgt alleen orders te zien van de voor hem ingestelde tafels. Het probleem bij deze is dat men af en toe kan vergeten om naar zijn eigen ‘profiel’ te switchen en dus orders op andere hun profiel te zetten. Ook is het niet meteen handig om elke keer opnieuw vaste tafels toe te kennen, aangezien het afhangt van de situatie of er één, twee of meerdere barmannen actief zijn. Oplossing 2 Er wordt niet geswitched tussen profielen van barmannen, maar er wordt duidelijk weergegeven voor welke tafel (via nummer of namen) een bestelling doet of wil betalen. Zo kan de barman de andere eventueel gewoon negeren en alleen zijn tafels de aandacht schenken. Indien de barman het dan ‘te druk’ heeft kan hij nog steeds de andere zijn werk ‘overnemen’. Het enige probleem bij dit systeem is dat er niet kan gelogd worden welke barman welke tafels/dranken opgediend en ontvangen heeft.
Overzicht tafels Een mogelijke optie tot het inbouwen van een visueel overzicht van alle tafels en bepaalde kleuren kwam aan bod. Hierbij worden het aantal tafels op het scherm weergegeven, aan de kleur van de tafel valt dan te zien of deze op een bestelling wacht, wil betalen enz … Een tafel selecteren geeft meer informatie hierover. Dit is momenteel nog niet voor de volgende fase van het project, maar er kan wel al aan gedacht worden hoe dit op te lossen valt en met welke technologie.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
2
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Producten en categorieën (relaties) Om het begin van de database diagram voor te stellen, werd al even gedacht hoe we de producten zullen opdelen. Producten worden verdeeld onder categorieën. Hieronder wordt verstaan dat een categorie ook een child categorie kan hebben, en dit tot oneindig. Waneer een bepaalde categorie in het systeem verwijderd worden alle producten van die categorie indien gewenst mee verwijderd of gewoon verplaatst naar een andere categorie. Bij deze werd ook gekeken naar het database ontwerp dat gebruikt werd bij het open source ecommerce systeem.
Database ontwerp Tijdens de vergadering werd er al een deel van het database ontwerp opgemaakt in Microsoft Visio 2007. Namelijk dat van de producten, categorieën, btw‐tarieven enz … Er werd ook beslist dat alle tabellen + kolommen een Engelstalige benaming zullen krijgen. Ook word er steeds het enkelvoud van een zelfstandig naamwoord gebruikt om verwarring te vermijden.
Voorraad beheer Het voorraad beheer staat los van de product/categorie wijzigingen in het administrator menu. Hierbij kan de administrator kiezen welk soort eenheid hij ingeeft, bv fles, vat, bak, doos, enz … Dit wordt dan gekoppeld aan een product. Bij dat product kan men dan volgens de gekozen eenheid aangeven hoeveel er in voorraad is. Natuurlijk moet er rekening gehouden worden dat deze aftrekbaar is aan de hand van orders. Waneer een bak ingegeven wordt moet het systeem weten dat hierin 24 flesjes aanwezig zijn. Men kan namelijk niet met bakken bestellen. Hierop wordt nog verder ingegaan.
Volgende vergadering Er werd niet meteen een vaste datum opgesteld voor de volgende vergadering, maar deze zal zeker in de week van 22 januari 2006 plaatsvinden. Daartegen moeten alle scenario’s uitgeschreven en ontleed zijn. Aan het database ontwerp wordt verder gewerkt door Joeri ook aan het voorraad systeem zal gewerkt worden door Joeri. Stef zal zeker de menu structuur proberen uit te schrijven, dit is een goede basis om uit te starten.
Agenda De agenda van volgende vergadering zal al zeker bestaan uit volgende punten ‐ Database ontwerp bekijken ‐ Werking van het voorraad beheer bekijken ‐ SVN moet gekend zijn door iedereen ‐ Timesheet worden door iedereen toegepast ‐ Bespreking voor volgende meeting met Meneer Van Laethem
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
3
Bijlage D. Verslagen van vergaderingen
D.4
Vergadering 4
88
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Verslag vergadering 05 maart 2005 Aanwezig Stef De Spiegeleer, Joeri Verdeyen
Voorzitter
Notulist
Stef De Spiegeleer
Joeri Verdeyen
Plaats
Begin –en einduur
Erasmushogeschool Brussel
09u40 – 13u00
Onderwerpen: PHPDoc XAMPP Eclipse MysqlTools Code Database Smarty Benamingen van bestanden Error Class Agenda
PHPDoc Om de code voor iedereen zo begrijpbaar mogelijk te maken, en de functies van klassen gemaakt door een ander lid van de groep goed te kunnen begrijpen zullen we gebruik maken van PHPDoc. Dit is een soort kloon van het alom bekende JavaDoc. Aan de hand van tags word er commentaar aan de code toegevoegd. Door PHPDocumentor wordt deze commentaar ontleed en word hiervan een informele documentatie opgesteld. Volgende afspraken zijn gemaakt omtrent het gebruik van PHPDoc:
Configuratie Het bestand icafe.ini wordt gebruikt. Dit bestand omvat alle instellingen. Enkele parameters moeten aangepast worden om het systeem werkende te krijgen. Dit zijn target¸voor de instelling van de map waar de documentie in gemaakt wordt en directory voor de instelling waar phpDocumentor de php files zal gaan uitlezen.
Svn Op de svn zal de PHPdoc geplaatst worden in de map phpDoc.
Eclipse Het is mogelijk PHPDoc in te voegen bij Eclipse, meer informatie hierover is te vinden op: http://www.plog4u.org/index.php/Using_PHPEclipse_:_Installation_:_Installing_the_phpDocumentor
XAMPP Xampp wordt gebruikt bij het ontwikkelen. Dit is een gratis te verkrijgen all in apache server met php en mysql aan boord.
DocumentRoot Wanneer de installatie paramaters op default zijn geïnstalleerd zijn, bevindt de root van de server zich op volgend path: C:\Program Files\xampp\htdocs Om deze te wijzigen moeten volgende parameters in C:\Program Files\xampp\apache\conf\httpd.conf gewijzigd worden: DocumentRoot (line 177): Stel hier de nieuwe root in Directory (line 204) :idem
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
1
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Aliases Er kan ook gebruik gemaakt worden van aliases, zo kan bv http://localhost/icafe verwijzen naar de localhost map op de svn. Dit kan je doen door in het bestand C:\Program Files\xampp\apache\conf\extra\httpd‐ xampp.conf volgende regel code toe te voegen: Alias /icafe "C:\Users\Joeri\School\iCafeProject\svn\localhost" AllowOverride AuthConfig Order allow,deny Allow from all
Opmerking Wanneer je een van deze instellingen gewijzigd hebt, moet je de apache server even restarten vooraleer deze tot hun recht komen.
Eclipse Om het ontwikkelen in PHP zo snel mogelijk te maken maken we gebruik van de IDE Eclipse. Hiervoor zijn er enkele plugins die we zullen gebruiken: PHPEclipse (http://www.phpeclipse.de/): PHP Aptana(http://www.aptana.com/): HTML & CSS
MysqlTools Om het managen van de database te vergemakkelijk zijn er op de officiële website van mysql enkele gratis tools te downloaden. Voornamelijk MySQL Administrator is een handige tool.
Code Basisfuncties Elke class zal 4 basisfuncties bevatten (Name = naam van de class) : ‐ selectName($id): Haalt alle gegevens van een object op uit de database ‐ updateName(): Update het huidige object met de database door zijn id ‐ insertName(): Insert een nieuw object als nieuwe entry in de database ‐ deleteName(): Verwijderd huidig object uit de database door zijn id
Getters/setters De getters en setters van een class leggen in geen geval contact met de database. Dit wordt gedaan met behulp van de basisfuncties.
Nieuwe objecten aanmaken Voor het aanmaken (vullen van de datamembers) van een nieuw object zijn 2 methoden mogelijk. ‐ Een nieuw object aanmaken en vullen met de setters ‐ Een init() functie waarbij alle datamembers als parameters worden doorgegeven en daarna geset worden.
Database Er zijn nog enkele wijzigingen gedaan aan het database ontwerp. De nieuwe create tables worden zo snel mogelijk op de svn gezet. Dit omvat voornamelijk de tables omvattende de users en menu. Een overzicht van de database kan gemaakt worden door middel van reverse engeneering. (MySQL Tools)
Smarty Om de presentatielaag te scheiden van de eigenlijke programmalaag (met code) zal waarschijnlijk gebruik gemaakt worden van Smarty. Dit is een template engine voor PHP. Als grote delen van de classes afgewerkt zijn wordt hiernaar gezocht hoe we dit gaan gebruiken en implementeren.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
2
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Benamingen van bestanden Bestanden op de localhost zullen als volgt hernoemt worden: naam.type.extensie (bv. category.class.php)
Error Class Er is een error class aanwezig op de localhost. Deze kan gebruikt worden als hulpmiddel bij het debuggen. Later kan deze zonder enig probleem uitgeschakeld worden. De bedoeling is dat fouten die zich kunnen voordoen (dit moet door de programmeur zelf onderzocht/ondervonden worden) kunnen geregistreerd en duidelijk gemaakt worden door een error weer te geven.
Gebruik $error = new error(“bericht”);
Vereisten Het bericht moet duidelijk zijn wat er net fout gelopen is. Waneer iemand een foutmelding krijgt van een class die door iemand anders gemaakt is moet hij kunnen opsporen waar het juist fout gelopen is. Zorg er dus voor dat volgende elementen aanwezig zijn in de foutmelding (indien mogelijk): ‐ Betrokken tabel ‐ Betrokken functie ‐ Betrokken data (foutieve paramter) ‐ Wat is er net fout gelopen?
Agenda ‐ ‐ ‐
Afwerken classes Smarty onderzoeken Database structuur herwerken (nieuwe tabellen)
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
3
Bijlage D. Verslagen van vergaderingen
D.5
Vergadering 5
92
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Verslag vergadering 23 maart 2007 Aanwezig Stef De Spiegeleer, Joeri Verdeyen, Naim Ben Tanfous
Voorzitter
Notulist
Stef De Spiegeleer
Joeri Verdeyen
Plaats
Begin –en einduur
Erasmushogeschool Brussel
10u40 – 12u10
Onderwerpen: Addslashes/stripslashes Bij de classes moeten de php functies addslashes en stripslashes toegevoegd worden. Deze worden gebruikt om te vermijden dat strings met enkele –en dubbele quotes in de query ingevoerd kunnen worden zonder fouten weer te geven. Hierbij werd dus afgesproken dat bij een insert naar de database eerst de functie addslashes() toegepast moet worden op alle gegevens die in de database gaan. Dit moet ook gebeuren bij een update en elke andere query die bepaalde gegevens in de database wegschrijft. Aangezien deze gegevens weer opgehaald moeten worden zonder deze slashes zal de functie stripslashes() opgeroepen worden om deze weer te verwijderen, zodanig dat bij verder gebruik van deze variabele geen onnodige slashes aanwezig zijn.
Client applicaties De volgende verdeling werd opgemaakt voor de client applicaties: Stef: Client voor obers Naim: Client voor de klanten Bij deze verdeling werd rekening gehouden dat Stef een ruimere kennis heeft van het onderwerp ‘dynamisch werken met Flash 8’. Verder zal Joeri het volledige admin center zo nauwkeurig mogelijk verder afwerken. Hierbij zal hij indien nodig beroep doen op classes gemaakt door andere groepsleden en eventueel vragen om extra functionaliteit toe te voegen (indien nodig) (vb. toevoegen van functies die bepaalde gegeven terugsturen) De client applicaties zullen gemaakt worden in Flash 8, hierbij sterven we naar een soortgelijke lay‐out of “look”. Enkele gedachten die aangehaald werden: ‐ Het ophalen van gegevens gebeurd door PHP die de gegevens haalt uit de MySQL database en deze in een XML file plaatst ‐ De XML file moet alle data bevatten die nodig is ‐ Per module wordt er een afzonderlijke XML file aangemaakt met de nodige gegeven (vb. sessions, orders, producten, ..) ‐ De gegevens moeten continue vernieuwd en ge gecheckt worden, dit kan gebeuren door een bepaalde timer met een delay in te stellen ‐ De schermresolutie zal nog beslist worden, maar we zullen ons focussen op 800x600 en 1024x786
Extra functionaliteit Om het geheel wat interessanter te maken moesten we ook eens nadenken over de extra functionaliteit die we kunnen inbouwen. Hierbij werden er nog geen suggesties gedaan.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
1
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
PHP getDate() Naim was op zoek naar een functie die de datum/tijd kan weergeven van de server. Hierbij kan getDate() gebruikt worden.
Hulp Op de svn werd een directory hulp bij aangemaakt, hierin wordt hulp code en code snippets geplaatst.
LaTeX Om het eindwerk‐verslag te schrijven word er gebruik gemaakt van LateX. Voor de paketten gebruiken we MiteX en LatexEditor om te bewerken.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
2
Bijlage D. Verslagen van vergaderingen
D.6
Vergadering met promotor
95
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Verslag vergadering Eindwerkpromotor 16 januari 2007 Eindwerkpromotor: Philippe Van Laethem Aanwezig Joeri Verdeyen, Stef De Spiegeleer, Naim Ben Tanfous Voorzitter geen
Notulist Stef De Spiegeleer
Plaats Erasmushogeschool Brussel
Begin –en einduur 13u50 – 14u55
Onderwerpen: ‐ ‐ ‐ ‐ ‐ ‐ ‐
Diagrammen Timesheets Forum Verslagen Gebruik LaTeX Svn (google code)
Programmeertaal Onderling zijn we tot de constatatie gekomen dat PHP de beste programmeer taal zou zijn. We hebben dit aan Mr. Van Laethem voorgelegd en beargumenteerd. Hij volgt deze mening, op voorwaarde dat er object georiënteerd wordt gewerkt (en dus met php5). Omdat we dit onderling reeds afgesproken hadden vormt dit geen probleem.
Diagrammen We zijn vrij de diagrammen te gebruiken waarvan we denken deze nodig te hebben voor de verdere uitwerking van het project. Het door ons voorgestelde programma was SmartDraw v7 en werd goedgekeurd.
Timesheets Aangezien Mr. Van Laethem nog geen ervaring had met het gebruik van timesheets in een eindwerk, hebben we de werking en de voordelen hiervan voorgelegd. Hij was licht positief, vooral omdat hierdoor makkelijk is om het onderling verdeelde werk op te volgen. Hij heeft ons hiervoor dan ook groen licht gegeven.
Forum We vonden het nuttig om een account aan te maken voor Mr Van Laethem. Dit omdat de subfora’s verborgen zijn. Zo kan Mr. Van Laethem indien gewenst het forum bezoeken voor allerhande informatie op te zoeken. Het aanmaken van deze account bleek niet nodig te zijn voor Mr Van Laethem aangezien dokeos de mogelijkheid bied tot het delen van bestanden en het gebruiken van een forum. Wij gaan verder met het gebruik van ons eigen forum en SVN.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
1
iCafe
Eindwerk 2006‐2007
Erasmushogeschool Brussel
Gebruik LaTeX Het gebruik van LaTex is niet verplicht maar er werd ons wel aangeraden. Mr. Van Laethem is hier een voorstander van omdat het een professioneel resultaat bied en waarbij je geen rekening moet houden met de opmaak zoals in word, omdat deze reeds voorgedefinieerd is. Je kan je dus beter concentreren op de inhoud.
Gebruik SVN (Google Code) Het verder gebruik van Google Code als SVN subversion systeem werd goedgekeurd. Er werd ons wel op attent gemaakt dat Erasmus hogeschool ook gratis SVN subversion systeem aanbied maar dit niet verplicht was.
Volgende vergadering Er werd niet meteen een vaste datum opgesteld voor de volgende vergadering, maar deze zal zeker in de week van 22 januari 2006 plaatsvinden. Daartegen moeten alle scenario’s uitgeschreven en ontleed zijn.
Agenda De volgende vergadering zal plaatsvinden in de week van 5 februari. Via verder contact via email zal het precieze tijdstip bepaald worden. ‐ Voor ca. 90% afgewerkte diagrammen, architecturaal correct en gedetailleerd.
Verslag Vergadering
Joeri Verdeyen, Naim Ben Tanfous, Stef De Spiegeleer
2
Bijlage E
Diverse bestanden E.1
Toelichting relaties tussen objecten
98
Voorstelling van Relaties bij producten/bestellingen Producten Elk product is uniek, hierdoor hebben ze een eigen identificatie. Waneer men een product kan kiezen, kiest men een naam. Als voorbeeld “Stella Artois 25cl”. Ook kan hierbij een korte lijn beschrijving onderstaan, als voorbeeld “Mijn thuis is waar mijn Stella Staat”. Deze korte lijn is slechts een optie bij producten die dit kunnen gebruiken. Bij het voorbeeldje van Stella is het niet meteen noodzakelijk, maar bij een naam die niet meteen onthuld wat het product juist is kan men deze best gebruiken “Een heerlijke mix van Gini en Gin.” Is hiervan een goed voorbeeld. Wanneer het over een product gaat dat nog enige uitleg nodig heeft kan men een (volledige) beschrijving gebruiken. In de beschrijving kan dan staan uit welke vloeistoffen een bepaald product bestaat. Zo weten de klanten welke dranken er bijvoorbeeld in een cocktail toegevoegd worden. Of enkele slagzinnen die het product kunnen promoten. Natuurlijk heeft een product ook een prijs. Hierop betaal de klant allicht btw, maar dit is niet van belang voor de klant, maar wel voor de administrator. Daarbij moet er dus een btw tarief ingegeven worden. Aangezien er meerdere tariefgroepen zijn, is het mogelijk uit deze groepen te kiezen. Een restaurant kan zowel koude als warme dranken aanbieden, zelfs snacks. Om deze niet bij elkaar te gooien en een overzicht te bewaren, wordt er gebruik gemaakt van categorieën. Een categorie bevat een titel, als voorbeeld “Koude dranken”. Hierbij is het eventueel nodig om een beschrijving in te geven, meer als slagzin “Heerlijke verfrissing”. *Later moet bekeken worden welke relatie een product met een categorie heeft. Is het mogelijk om een product bij meerdere categorieën toe te voegen, of heeft een product slechts een categorie waartoe het behoord.
Bestellingen Elke bestelling is uniek, hierdoor wordt er dus een identificatie voor elke bestelling gemaakt. Elke bestelling bestaat uit één of meerdere producten. Hierbij wordt dus een lijst van producten opgesteld die gedurende deze bestelling zijn gemaakt. Deze lijst zal aan de hand van de unieke id van de bestelling opgemaakt worden en gekoppeld worden aan één of meerdere producten. Om de bestelling te kunnen waarnemen door de obers moet er rekening gehouden worden of de bestelling al afgehandeld is, of de bestelling al afgerekend is, of de bestelling al lang geleden gedaan is. Hiervoor kunnen waar en onwaar gebruikt worden. Waneer een bestelling zijn boolean, ‘betaling’ op false staat geeft dit aan dat er (nog) niet betaald is voor deze lijst van producten. Waneer een bestelling op ‘geleverd’ false staat, is deze nog niet bij de cliënt bezorgd. Bij het maken van elke bestelling wordt er ook een sessie aangemaakt, een sessie is eigenlijk de afrekening, wordt een bestelling afgesloten dan wordt de sessie ook afgesloten (met afgesloten wordt bedoelt, geleverd en betaald). Waneer de bestelling niet is afgesloten en dus later wordt betaald aangezien er nog een bestelling wordt gedaan op een later tijdstip of omdat deze gewoon nog niet betaald is zal de sessie blijven open staan. Elke bestelling heeft dus slecht één sessie, maar één sessie kan meerdere bestellingen bevatten. 1
Een bestelling heeft ook een tijdstip van doorvoeren. Dit is het tijdstip waarop de bestelling doorgestuurd wordt, dus waneer de cliënt op ‘bestellen’ duwt en zijn bestelling niet meer wil wijzigen. Zo kan de applicatie die de bestellingen nakijkt ophalen dat er een nieuw bestelling open staat, en op welk tijdstip deze ingegeven werd. Aan de hand van deze tijd kan een wacht-rij aangemaakt worden en kan er gekeken worden wie eerst bedient moet worden. Ook beschikt een bestelling over een paramater de bepaald of de bestelling betaald is en/of de bestelling al geleverd is. Waneer in een sessie 2 bestellingen gedaan zijn en één hiervan heeft een false waarde bij betaling kan de sessie niet gesloten worden en blijft deze cliënt bij de obers verschijnen als ‘onbetaald’. Waneer de ober het geld ontvangen heeft kan hij op zijn systeem valideren dat de cliënt betaald heeft en wordt aan de parameter dus een true waarde meegegeven. Een afrekening wordt dus gemaakt aan de hand van de sessie die door een cliënt wordt gebruikt. Bij de afrekening wordt er dus nagekeken welke bestellingen gedaan zijn en hoeveel het totaal bedrag van deze bestelling(en) bevat.
2
Bijlage E. Diverse bestanden
E.2
Toelichting stockbeheer
101
Stockbeheer Hoe wordt de stock bepaald? De stock wordt bepaald door het aantal eenheden dat men van een product heeft. Dit kan bijvoorbeeld zijn 200 flesjes Cola, 2 vaten Jupiler enz…
Hoe worden de eenheden bepaald? Een eenheid wordt gedefinieerd als het medium waarin men de producten aankoopt. Enkele voorbeelden zijn 24 flesjes, 1 vat, 2 flessen. De gebruiker heeft de mogelijkheid om deze eenheden zelf te bepalen. Men kan dus zelf een vat, een flesje 25cl, een fles 0,75cl invoegen. Waneer men een eenheid invoegt moet men volgende velden ingeven: Type, dus de naam (Vat), Content, dus de inhoud van de eenheid (50L). Content omvat een string, aan de hand van deze maateenheden worden er verder geen berekeningen gedaan, deze zijn dus louter informatief.
Hoe weet het systeem waneer een eenheid verbruikt wordt? Hierbij komen enkele problemen naar boven, deze worden verderop even opgesomd. Eerst wordt het algemene principe uitgelegd. Algemene principe Stel er wordt een Cola besteld. Deze staat aangegeven met eenheid flesje van 25cl. Het systeem gaat nakijken in de stock van dit product hoeveel voorraad er nog aanwezig is, haalt dat getal op en zal dit verminderen met één. Probleem: Wat als er een product de eenheid fles (0,75L) heeft en er per glas wordt verkocht ? Aangezien het systeem niet relatief kan denken dat er x aantal glazen, uit een 0,75L fles raken zal dit manueel ingegeven moeten worden. Ook zal er een bepaalde parameter moeten aangeven dat verandering van voorraad manueel gebeurd en niet tijdens de verkoop van producten. Hiermee wordt bedoelt dat waneer er 5 glazen wijn besteld worden er niets wijzigt in het voorraad beheer van die fles wijn. Wel zal de voorraad gewijzigd kunnen worden door een barman of een administrator. Deze geeft dan de vermindering van het aantal producten in, met andere woorden, het aantal verbruikte flessen. Dit kan wel een nadeel teweeg brengen in het voorraad beheer (extra werk), alhoewel dit ook handig is waneer er flessen sneuvelen en toch niet verkocht worden.
Verrekening van de verkoopprijs – aankoopprijs Wat als er iets sneuveld ? Waneer er een flesje/fles of dergelijke niet verkocht wordt omdat het gesneuveld is tijdens het opdienen of door een ander situatie, moet het systeem weten dat deze uit de voorraad moet verdwijnen Algemene oplossing De beste en de meeste logische oplossing hiervoor is om dit afzonderlijk te zetten van de verkooprekening. Waneer men een fles laat vallen wordt de wijn niet meer verkocht, dus worden er
ook geen 5 glazen wijn verkocht (van die fles). Waneer men dan de stock verminderd met 1, door de fles die gevallen is, hoeft het systeem niet te berekenen dat stock vermindering iets met de verkoop te maken heeft. Oplossing bij automatisch voorraadbeheer Waneer men bij een product automatisch voorraadbeheer instelt wordt er bij de verkoop van het product een eenheid afgetrokken. Door een bestelling in te geven van dat product met een verkoopprijs van 0 is dit probleem ook opgelost. Dit is echter enkel mogelijk bij producten die via hun eenheid automatisch stockbeheer kunnen doen. Hiervoor wordt een diagram opgesteld om meer duidelijkheid te brengen. 1 flesje Cola wordt besteld
Y
Aantal eenheden in stock wordt verminderd
Y
Automatische voorraadberekening ?
Succesvolle levering ?
N
Automatische voorraadberekening ?
Y
N N De barman dient in te geven waneer een volledige eenheid van dit product verkocht is, of nadien wordt de stock aangepast De barman dient in te geven waneer een volledige eenheid van dit product verkocht is, of nadien wordt de stock aangepast
Barman geeft een order in met saldo 0 OF De barman dient in te geven waneer een volledige eenheid van dit product verkocht is, of nadien wordt de stock aangepast
