iCafe Een digitaal bestelsysteem voor de horeca Joeri Verdeyen Stefaan De Spiegeleer Naim Ben Tanfous 2006-2007
Synopsis Een bestelsysteem voor de horeca is de beknopte beschrijving en titel van het eindwerk iCafe. De gedachtengang is een systeem waarmee klanten in een horeca zaak bestellingen ingeven via een computerscherm, door middel van een touchscreen. De touchscreen wordt 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 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 gedachtengangen samen te voegen werd het programmeerwerk verdeeld. De programmeertaal die word gebruikt is PHP5, om gegevens permanent op te slagen word 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 konden dan objecten voortvloeien zoals producten en bestellingen. Deze basis wordt gebruikt door de drie applicaties waardoor de communicatie vlekkenloos verloopt. Na vele uren programmeren, debuggen en aanpassen is het systeem werkende en het resultaat zoals gewenst. 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 onstaan is tussen de drie leden.
1
Voorwoord
2
Inhoudsopgave 1 Inleiding
6
2 iCafe
7
2.1
Het idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Droom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3 Project
8
3.1
Algemene aanpak . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3
Verdeling van de taken . . . . . . . . . . . . . . . . . . . . . .
8
3.3.1
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3.2
Applicaties . . . . . . . . . . . . . . . . . . . . . . . .
9
Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4.1
Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4.2
Meetings . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4.3
SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4.4
Forum . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4
4 Fases
11
4.1
11
Brainstormen . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Inhoudsopgave
4.2
Scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.3
Diagrammen . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.4
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.5
Applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.5.1
Admin . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.5.2
Client - Barman . . . . . . . . . . . . . . . . . . . . .
23
4.5.3
Client - Klant . . . . . . . . . . . . . . . . . . . . . . .
24
4.6
Testfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.7
Afwerking . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.8
Verslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5 iCafe engineering
26
5.1
Programmeertaal PHP5 . . . . . . . . . . . . . . . . . . . . .
26
5.2
MySQL database . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.3
Adobe Flash
. . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.4
Smarty Template Engine . . . . . . . . . . . . . . . . . . . . .
28
5.4.1
Web templates . . . . . . . . . . . . . . . . . . . . . .
28
5.4.2
Onze aanpak . . . . . . . . . . . . . . . . . . . . . . .
29
5.4.3
Smarty . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.5.1
Eclipse IDE . . . . . . . . . . . . . . . . . . . . . . . .
30
5.5.2
XAMPP . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.5.3
Tortoise SVN . . . . . . . . . . . . . . . . . . . . . . .
31
5.5
6 Problemen
33
6.1
Samenwerking . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.2
Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.2.1
Verwijderen van producten . . . . . . . . . . . . . . .
33
Deadlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.3
4
Inhoudsopgave
6.4
6.5
Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6.4.1
Turtoise SVN . . . . . . . . . . . . . . . . . . . . . . .
34
6.4.2
Apache / MySQL
. . . . . . . . . . . . . . . . . . . .
35
Mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
7 Besluit
37
8 Dankwoord
38
9 Eigen Beoordeling
39
9.1
9.2
9.3
Naim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
9.1.1
Zelfreflectie . . . . . . . . . . . . . . . . . . . . . . . .
39
9.1.2
Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
9.1.3
Joeri . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
9.2.1
Zelfreflectie . . . . . . . . . . . . . . . . . . . . . . . .
39
9.2.2
Naim
. . . . . . . . . . . . . . . . . . . . . . . . . . .
39
9.2.3
Joeri . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Joeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
9.3.1
Zelfreflectie . . . . . . . . . . . . . . . . . . . . . . . .
39
9.3.2
Naim
. . . . . . . . . . . . . . . . . . . . . . . . . . .
39
9.3.3
Stef . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
10 Bronvermelding
40
A Bijlagen
42
A.1 Scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
A.2 Diagrammen . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
A.3 Verslagen van vergaderingen . . . . . . . . . . . . . . . . . . .
42
5
Hoofdstuk 1
Inleiding
6
Hoofdstuk 2
iCafe 2.1
Het idee
2.2
Mogelijkheden
2.3
Werking
2.4
Droom
7
Hoofdstuk 3
Project 3.1
Algemene aanpak
3.2
Teamwork
3.3
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 gebeurde 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.3.1
Klassen
De klassen werden ingedeeld aan de hand van het opgestelde klassendiagram. Op dit klassendiagram waren duidelijk drie groepen van klassen te zien die dicht bij elkaar lagen, en waar dus bepaalde klassen in de andere klassen 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. 8
Hoofdstuk 3. Project
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. 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 ) Joeri Category, Error, Menu, MySQL, Product, Stock, Tax Stef User Naim Order, Queue, Session, Table
3.3.2
Applicaties
De verdeling van de applicaties werd meer gekozen aan de hand van kennis van zaken. Zo moesten 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
9
Hoofdstuk 3. Project
3.4 3.4.1
Communicatie Chat
Voor de dagelijkse en minder omvangrijke communicatie werd gebruikt gemaakt van chat. Het is te omslachtig om voor kleine vragen en opmerkingen te mailen of zelfs 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 hierover te overleggen.
3.4.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 turtoise SVN client. 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.4.3
SVN
3.4.4
Forum
1
Voor de verslagen van de meetings zie bijlage A.3
10
Hoofdstuk 4
Fases 4.1
Brainstormen
Bij het brainstormen werden van allerhande ide¨een op tafel gegooid. Veel ide¨een die bij het tekenen van diagrammen en bij het programmeren niet meer bovengehaald werden. E´en van de eerste ide¨een was een digitaal jukebox systeem die in het bestelsysteem zou worden opgenomen. Zo kon een klant een liedje aanvragen en zou de muziek in het caf´e grotendeels door de klanten zelf kunnen worden beslist. 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. In het begin 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 ide¨een 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 sommige zaken te ingewikkeld waren om er te veel tijd aan te besteden.
11
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 niet 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 zijn.
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 gebruikt gemaakt van een 1 2
Voor scenario’s zie bijlage A.1 Voor diagrammen zie bijlage A.2
12
Hoofdstuk 4. Fases
hierarchie van categori¨en. Deze categori¨en hebben een unieke naam en beschrijving als verduidelijking. De categorie klasse is in staat na te gaan of de categorie wel of niet subcategori¨en bevat. Verder kan het al zijn subcategori¨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 geimplementeerd die nakijken of de naam van het product uniek is waneer 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 item 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 klass is een kleine klasse die geschreven werd voor het debuggen. Er kon simpelweg een object van de error klasse aangemaakt worden, hierin geeft me een foutmelding mee en deze word getoond op het scherm. Aan de hand van deze boodschap was het dan makkelijk om na te gaan waar de fout zich bevind. MySQL Aangezien er steeds een verbinding met de database gemaakt moet 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 functies hiervoor geschreven in PHP te maken. De klasse gebruikt deze functies, maar op een effeci¨entere manier.
13
Hoofdstuk 4. Fases
Stock De stock klasse houdt zich voornamelijk bezig met de voorraadtypen. Elke stock object is een voorraad type waaraan bepaalde paramenters 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 voorraad type is. Tax De tax klasse word 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 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 berekent 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. Ten slotte houdt een order het id van de tafel bij die wordt opgehaald aan de hand van de sessie. 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.
14
Hoofdstuk 4. Fases
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 in het systeem 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 en 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. 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.
15
Hoofdstuk 4. Fases
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, deze categori¨en maken het overzichtelijk om de producten weer te geven. In kan er meer informatie gevonden worden over categorie¨en. BTW-tarief Omdat er in Belgi¨e verschillende BTW-tarieven zijn kunnen deze afzonderlijk gekozen worden voor elk product. In kan er meer informatie gevonden worden over BTW-tarieven. Een BTW-tarief wordt toegekend aan een product, hiermee wordt het verkoopbedrag berekend. 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. 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. 16
Hoofdstuk 4. Fases
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 verdeduidelijking. Voorraad-type Een product beschikt over een voorraad, maar niet elk product wordt in hetzelfde medium verkocht. Hiervoor worden voorraadtypes gebruikt, meer informatie over voorraad-types kan gevonden worden in 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 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 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 17
Hoofdstuk 4. Fases
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 verduidelijk 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 hoofdcategori¨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 een of meerdere subcategorie¨en kan beschikken zijn er bepaalde restricties bij het verwijderen. Wanneer er een hoofdcategorie verwijderd wordt die een of meerdere subcategorie¨en bevat 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 18
Hoofdstuk 4. Fases
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 beschreven als een voorraadtype. Een voorraad-type beschikt over volgende gegevens: Type naam De referentie van het voorraad-type. 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. 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 voorraad-type is.
19
Hoofdstuk 4. Fases
Deze gegegevens zijn in te voeren bij het aanmaken van een nieuw voorraadtype, en kunnen naderhand hezien worden. Door het voorraad-type te selecteren kan men deze volledig bewerken of verwijderen. Het is nagenoeg niet mogelijk om voorraad-typen 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 voorraad type tegekend kregen. Het is er 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 diene 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 gegegeven: 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 derde. Wanneer een gebruiker zijn wachtwoord ontgaan is, kan dit gewijzigd worden door een andere gebruiker die toegang heeft tot het administratie systeem. Echte naam De voornaam van de gebruiker. Familienaam De achternaam van de gebruiker. Er wordt gebruik gemaakt van dit gegeven als eventuele verduidelijking bij identieke voornamen. 20
Hoofdstuk 4. Fases
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 annaloog met dat van het telefoon nummer. Geboortedatum De datum waarop de gebruiker geboren is. Dit moet aantonen dat de gebruiker een leeftijd heeft die voeldoet 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. 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:
21
Hoofdstuk 4. Fases
Totaal aantal bestellingen De som van alle bestellingen die dat jaar geplaatsts zijn. Totaal verkoopbedrag incl BTW De som van alle verkoopprijzen van de producten die verkocht zijn, in dit geval inclusief BTW. Totaal verkoopbedrag excl BTW De som van alle verkoopprijzen van de producten die verkocht zijn, in dit geval exclusief 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 dan wanneer er een jaar geselecteerd werd. Ditmaal is het overzicht specifieek 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 worden er voor deze dag ook een overzicht gegeven als 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. 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 22
Hoofdstuk 4. Fases
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 de tafel te selecteren kan men deze volledig bewerken of verwijderen. Verder is er de mogelijkheid om een lokale back-up van het 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 betaalt, of geleverd en niet betaalt. Hij moet ook kunnen 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 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 een tafel zijn rekening vraagt, klikt de barman op betalen. Hij moet nu kiezen in een lijst van tafels om de juiste rekening 23
Hoofdstuk 4. Fases
op te vragen. Hij klikt op de tafel en ziet zo de rekening van de tafel. Wanneer de klant betaalt klikt hij op betaalt, 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. Barman is nu uitgelogd en het systeem wacht nu op een barman die opnieuw inlogt.
4.5.3
4.6
Client - Klant
Testfase
Omdat de programmeurs dezelfde klassen gebruikt 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 de applicaties perfect samen kunnen werken. Het is de bedoeling dat op het eind van het project het systeem op zen geheel 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 de 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 werden gemaakt door elk lid zouden worden beschreven in het verslag
24
Hoofdstuk 4. Fases
door dat lid. De rest van het verslag werd onderling verdeeld in gelijkaardige stukken.
25
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 van functiegeori¨enteerd te programmeren of objectgeori¨enteerd. 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 leidde. 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 bekent en heeft ook een zeer uitgebreide ondersteuning. 26
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 bied 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 stabiele versie bekend, 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 behoord.
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. 27
Hoofdstuk 5. iCafe engineering
Ondersteuning Flash wordt door de meeste webbrowsers ondersteunt, al moet daarvoor een extra plug-in worden ge¨ınstalleerd. Verder is het platformonafhankelijk waardoor het systeem kan draaien op UNIX, MAC en Windows machines. 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 waardes kan meegeven. Voor het ontvangen van gegevens worden de gegevens ook toegekend aan hetzelfde loadVars object die dan in de ActionScript verder kan 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 codeer werk en een reeks design werk. Hieruit mag men dus verstaan dat de gegevens worden opgehaald in het codeer werk, meer bepaald de data laag. Deze gegevens worden op hun beurt weergegeven op de website, ook de presentatielaag genoemd. Deze scheiding van lagen heeft zijn voordelen. 28
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 word. 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 presentatie laag, 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 nodig functies aan boord heeft om het geheel uit te voeren. Volgend voorbeeld zal voor verduidelijking zorgen.
29
Hoofdstuk 5. iCafe engineering
Voorbeeld Het doel is om de gegevens van een product in een webpagina te tonen. Er word 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 gebruikt 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 alles 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.
30
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 word er echter gebruikt 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
Om dat de code verdeeld werd onder de verschillende projectleden moest er een oplossing gezocht worden om alles steeds synchroon met elkaar te lopen. 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.
31
Hoofdstuk 5. iCafe engineering
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 naartoe 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/
32
Hoofdstuk 6
Problemen 6.1
Samenwerking
De samenwerking tussen verschillende groepsleden verliep al bij al vlot. Met drie mensen aan een project werken heeft z’n 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 werk. 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 niet altijd simpel. Verder heeft iedereen zijn eigen ide¨een 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,
33
Hoofdstuk 6. Problemen
maar wanneer er naar het archief van de bestellingen word 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. Maar wanneer een product uit het assortiment gehaald word dan 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 een parameter toe te voegen aan elk product. Deze parameter is een boolean die bepaald 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.3
Deadlines
6.4
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 opzoek gegaan worden naar substituutprogramma’s.
6.4.1
Turtoise SVN
Aangezien er van Turtoise geen versie bestaat voor Mac OSX is er naar alternatieven gezocht om lokaal te kunnen communiceren met de repository. Na wat zoekwerk op het internet bleek uit diverse user reviews dat svnX een van de beste SVN clients was. 1
Verder in dit verslag zal dit afgekort worden tot Mac OSX
34
Hoofdstuk 6. Problemen
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.
6.4.2
Apache / MySQL
xampp Er werd, zoals beschreven in paragraaf 3.3.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 ˜ ren. Dit probleem werd gepost op geslaagd werd om Aliassen te definiA 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
35
Hoofdstuk 6. Problemen
de Aliassen niet gevonden worden. mamp Mamp is de tegenhanger van Xampp, en speciaal ontwikkeld voor Mac OSX. Het initiele probleem bij het grbruik 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
6.5
Mogelijkheden
36
Hoofdstuk 7
Besluit
37
Hoofdstuk 8
Dankwoord
38
Hoofdstuk 9
Eigen Beoordeling 9.1
Naim
9.1.1
Zelfreflectie
9.1.2
Stef
9.1.3
Joeri
9.2
Stef
9.2.1
Zelfreflectie
9.2.2
Naim
9.2.3
Joeri
9.3
Joeri
9.3.1
Zelfreflectie
9.3.2
Naim
9.3.3
Stef
39
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/
40
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
41
Bijlage A
Bijlagen A.1
Scenario’s
A.2
Diagrammen
A.3
Verslagen van vergaderingen
42
