iCafe Erasmushogeschool Brussel

Presentatie over: "iCafe Erasmushogeschool Brussel"— Transcript van de presentatie:

1 iCafe Erasmushogeschool Brussel 2006-2007
Een digitaal bestelsysteem voor de horeca. Erasmushogeschool Brussel Naim Ben Tanfous Stef De Spiegeleer Joeri Verdeyen 1

2 Overzicht presentatie
Wat is iCafe ontstaan concept voordelen werking droom 2

3 Overzicht presentatie
Project Verdeling van taken Communicatie Fases Brainstormen Scenario's Diagrammen Database ontwerp Klassen 3

4 Overzicht presentatie
Fases Applicaties Testfase Afwerking Verslag 4

5 Overzicht presentatie
Engineering Programmeertaal PHP5 mySQL database Adobe Flash Smarty Template Engine Software Problemen Besluit 5

6 Inleiding Anekdote De anekdote die in de inleiding staat ( door Stef ) // Stef 6

7 Overzicht Wat is iCafe? Project Fases Engineering Problemen Besluit

8 Wat is iCafe ? Het concept Applicatie Touchscreen Draadloos
Klant -> bestellen via touchscrene bv in midden tafel -> mooi overzicht van eet/drank menu > draadloos verzonden naar barman barman ->overzciht bestellingen per tafel -> kan afgehandeld zetten admin -> Instellingen van het systeem -> voorraadbeheer ed 8

9 Wat is iCafe ? Voordelen Barman Klant Administratie Tijdbesparing
Bestellingmoment Administratie Voorraadbeheer Bestelling overzicht // stef uitleggen adh slildes 9

10 Wat is iCafe? Werking // stef uitleggen adhv schema 10

11 Wat is iCafe ? Droom Commercialiseren Uitbreidingen // ste
fVerkopen aan horeca zaken. met eerste café samenwerken en de kost delen van Harware ed, en zo het product proberen gestsaag naambekendheid te geven Uitbreidingen Connectie met muziek programma (DJ matic) wirelessacces voor laptops electronisch betalen .. 11

12 Overzicht Wat is iCafe? Project Fases Engineering Problemen Besluit

13 Project Verdeling van taken A.d.h.v kennis en ervaring Meestal 3 delen
Klassen Opdeling via klassendiagram Opdeling in 3 groepen Gebruik van PHPdoc // joeri Taak verdeling aan de hand van kennis en ervaring, personen die meer ervaring hadden met bepaalde onderdelen zouden deze dingen ook maken tijdens het project. Meestal werden de opdrachten in 3 verdeelt, zodanig dat iedereen zijn verantwoordelijk deel heeft. De klassen werden ingedeeld volgens het klassendiagram dat opgesteld werd Zo werd dit in 3 groepen opgedeeld, waarvoor de 3 leden dan verantwoordelijk waren PHPdoc werd gebruikt om een documentatie op te stellen van de klassen, zo konden alle leden kennis hebben van de klassen van de andere leden 13

14 Project Verdeling van taken Applicaties Klant Barman Administratie
// joeri Er moesten 3 applicaties gemaakt worden, barman, klant en administratie, Ieder lid van de groep nam zijn verantwoordelijkheid om deze tot een goed einde te brengen Aangezien er gebruik gemaakt werd van de zelfde ondergrond (klassen), zou compatibiliteit geen probleem zijn Klant en barman zouden in flash gemaakt worden Administratie zou gemaakt worden in html en css 14

15 Project Verdeling van taken Klant Barman Flash Administratie Klassen
Applicaties Klant Barman Flash Administratie // joeri Er moesten 3 applicaties gemaakt worden, barman, klant en administratie, Ieder lid van de groep nam zijn verantwoordelijkheid om deze tot een goed einde te brengen Aangezien er gebruik gemaakt werd van de zelfde ondergrond (klassen), zou compatibiliteit geen probleem zijn Klant en barman zouden in flash gemaakt worden Administratie zou gemaakt worden in html en css HTML/CSS Klassen 15

16 Project Communicatie Chat Meeting SVN Forum Dagelijks 2 wekelijks
Uitwisselen van bestanden Forum Algemene communicatie // joeri Over het algemeen maakten we gebruik van 4 communicatie middelen, hieronder chat, meetings, svn systeem en een forum. De chat werd gebruikt voor de minder belangrijke dingen, bepaalde (kleine) opmerkingen, of wijzigingen die nodig waren, Het afspreken van de meetings. De meetings werden gebruikt om omvangerijke beslissengen samen voor te leggen en te nemen. De meetings vonden Ongeveer om de weken plaats, en alle leden waren hier op aanwezig. Er werd ook steeds een TODO list opgesteld op het einde van elke meeting, zodanig dat er eens streefdoel was naar de volgende meeting die ook op het einde van elke meeting werd vastgelegd. Er werd ook een verslag geschreven zodanig dat de punten die aangehaald werden achteraf herzien konden worden. Voor de bestandsuitwisseling maakten we gebruik van een subversion systeem, afgekort SVN. Zo kon iedereen over de laatste revisies van de bestanden beschikken. Het forum werd voornamelijk aan de start van het project gebruikt, om bestanden, links en informatie uit te wisselen. Deze plaats werd na enige tijd echter volledige ingenomen door de SVN, waardoor het forum niet meer gebruikt werd. 16

17 Overzicht Wat is iCafe? Project Fases Engineering Problemen Besluit

18 Fases Brainstormen Scenario’s Diagrammen Database ontwerp Klassen
Applicaties Testfase Afwerking Verslag 18

19 Brainstormen Jukebox MySQL PHP Wireless Touchscreen Plugins
Open-source Toekomst HTML Actionscript // joeri We zijn het gehele project begonnen met samen aan tafel te gaan zitten, en eens onze ideeën op tafel te gooien. We gingen dus brainstormen over de dingen die we zouden/kunnen implementeren en hoe we deze zouden realiseren. Allerhande ideeën die tijdens het brainstormen voorgesteld zijn zouden niet geimplementeerd worden, maar dit nam niet weg dat het later niet zou mogelijk zijn deze ideeen in het project te werken. Ook de programmeertaal, de database en dergelijke kwamen aan bod. We begonnen met het idee om een stevige basisapplicatie te maken. OO Flash Web-based 19

20 Brainstormen Ideeën Mogelijkheden Programmeertaal
Stevige basisapplicatie // joeri 20

21 Scenario’s Verhaal Overzicht Simulatie // naim
De scenario’s werden geschreven om meer duidelijkheid te geven omtrent verschillende zaken. Een scenario vertelt een verhaal, die echt in detail gaat. Dit geeft een zicht op mogelijke problemen die kunnen voorkomen en mogelijke fases waarbij speciale aandacht nodig is. Het geeft eveneens een overzicht over de functionaliteiten en de mogelijkheden. En tenslotte biedt het een eerste simulatie, van allerhande mogelijkheden en functionaliteiten die we graag zouden bereiken. 21

22 Diagrammen Database ontwerp Klasse diagram Use Case Flow Chart
Opsplitsing van tabellen Klasse diagram Use Case Flow Chart Sequentiediagram Menustructuur De gemaakte scenario’s konden op dat moment ook dienen om diagrammen te ontwerpen. We hebben de diagrammen eruit genomen die het belangrijkste voor ons waren. Zoals de diagrammen die hier afgebeeld staan. Een database ontwerp die zoveel mogelijk tabellen zou opsplitsen om … //TODO. Dit database ontwerp zou het ons zeer gemakkelijk maken om de database aan te maken. Een klasse diagram die een zicht gaf in een eerste stadium op de nodige klasses en functies. We wisten dat deze klasses een basis waren en dat ze tijdens het programmeren nog zouden worden aangepast of aangevuld. De use cases zijn onze scenario’s die omgezet zijn in een schema, waarbij een actor verschillende zaken ‘kan’ uitvoeren. Ook de flow charts geven een schematisch overzicht op verschillende mogelijkheden en verschillende gebeurtenissen. Sequentiediagram geeft een overzicht van de verschillende acteurs in het systeem die verschillende taken op zich nemen. De menustructuur geeft een zicht op een menustructuur die later zou kunnen gebruikt worden. //Opsplitsing -> veiligheid en performantie (opzoeken om te verklaren) // niam 22

23 Klassen Objectgeoriënteerd Communicatie met database Centralisatie
Uitbreiden Bewerken Communicatie met database Centralisatie Overal bruikbaar // naim We hebben ervoor gekozen om objectgeoriënteerd omdat dit de mogelijkheid biedt om gemakkelijk uitbreidingen uit te voeren en zaken te bewerken. Het is ook gemakkelijker om zoveel mogelijk zaken als objecten te zien zodat elk object een bepaalde functionaliteit kan uitvoeren. Ook kan de communicatie met de database vlotter verlopen door gewoon objecten aan te maken en daarop verschillende functionaliteiten op toe te passen. De klassen staan centraal in het project en vormen de grondlaag van de ganse applicatie en ze zullen in elk verder stadium gebruikt worden. 23

24 Applicaties Administratie Hoofdeigenaar Gegevens beheren
Toegang: inloggen Verschillende modules // joeri De administratie applicatie is voornamelijk geschreven door de hoofdeigenaar van het systeem. Het is mogelijk om hier de gewenste gegevens te wijzigen. Hij krijgt toegang tot de administratie door een gebruikersnaam en wachtwoord in te geven dat aan hem toegekend werd. Er zijn verschillende modules in het administratie gedeelte, een kleine voorstelling… 24

25 Applicaties Administratie Productbeheer Categoriebeheer Btw-beheer
Vorraadbeheer Gebruikerbeheer Orderbeheer Algemene configuratie // joeri 25

26 Algemene configuratie
Applicaties Administratie Productbeheer Categoriebeheer Btw-beheer Voorraadbeheer Gebruikersbeheer Orderbeheer // joeri Het productbeheer maakt het mogelijk om producten toe te voegen, indien gewenst kan men deze achteraf wijzigen. Een product heeft allerhande instellingen, gaande van naam tot ondertitel, verkoopprijs en afbeelding. Het categoriebeheer werd gemaakt om producten sneller terug te vinden, zo kan men producten onder bepaalde categoriën steken. Deze categorieën gaan tot 2 niveaus diep. Er is echter wel een restrictie waarbij het niet mogelijk is om zwevende producten toe te voegen. Eenmaal een categorie een subcategorie heeft, kan men onder deze hoofdcategorie geen product toevoegen. Producten moeten dus steeds onder een categorie staan en niet naast een categorie. Het btwbeheer maakt het mogelijk om met verschillende belastingstarrieven te werken. Deze tarrieven kunnen toegekend worden aan de producten. Het voorraadbeheer beschikt over de mogelijkheid om producttypen aan te maken. Deze producttype kan bijvoorbeeld een flesje zijn, dit type kan nadien toegekend worden aan een product. Zo weet het systeem dat het betwiste product zich in een flesje bevind. Men kan dan in het voorraadbeheer ook nakijken hoeveel flesjes er nog op voorraad zijn, en eventueel een wijziging aanbrengen. Gebruikersbeheer laat toe om gebriukers aan te maken die in het systeem kunnen inloggen, allerhande gegevens zoals naam en woonplaats worden in gegeven, door de gebruikersnaam en het wachwoord dat men ingeeft, heeft men toegang tot het systeem. Het orderbeheer beschikt over een overzicht van de orders die geplaatst zijn. Het is mogelijk deze op te vragen, volgens jaar, maand en dag. Er wordt een totaal van de verkopen aangegeven, en het totaalbedrag. Er is ook een algemene configuratie, zo kan men een tafel toevoegen aan de hand van het ip adres, en kan men een backup nemen van de database die naar de schijf wordt weggeschreven. Algemene configuratie Administratie applicatie 26

27 Applicaties Barman (client) Inloggen Bestellingen Betalen Uitloggen
Een barman moet op een gemakkelijke manier de bestellingen kunnen zien die door de klanten geplaast geweest zijn. Een barman logt eerst en vooral in. Eenmaal ingelogd ziet de barman de bestellingen die geplaatst geweest zijn in chronologische volgorde. Zodat klanten die het eerst besteld hebben het eerst aan bod komen. Hij kan eventueel kleine aanpassingen doorvoeren in de bestelling. De barman moet er ook voor kunnen zorgen dat de klanten hun rekening kunnen betalen. Dit kan hij doen door de rekening voor desbetreffende tafel op te vragen. Eenmaal zen shift erop zit kan hij uitloggen. // naim 27

28 Applicaties Klant (client) Bestellen Bekijken van bestelling
Wijzigen van bestelling Verwijderen van bestelling // stef uitleggen via demo 28

29 Testfase Demo situatie Compatibiliteit Dummy producten toevoegen
Bestellingen Bestellingen afhandelen Compatibiliteit Communicatie tussen applicaties // nog niet bepaald, omdat de testfase pas maandag is 29

30 Afwerking Oplossen van bugs Finetuning // idem als testfase 30

31 Verslag LaTeX Fases Opstelling inhoudsopgave
Verdeling a.d.h.v. inhoudsopgave Uitwerken van hoofdstukken // joeri Voor de verwerking van het verslag werd gebruik gemaakt van LaTeX. Latex is een markup language, dit wil zeggen dat teksten tussen tags geplaats worden, Nadien wordt deze text gecompiled en krijgt men een tekst met automatische opmaak. Het systeem is heel handig in gebruik, alleen is het soms moeilijk om te vinden hoe bepaalde dingen gedaan kunnen worden. We zijn aan het verslag begonnen door het opstellen van een inhoudsopgave, in deze inhoudsopgave zouden dan alle puntjes staan die we zullen bespreken. Ook de verdeling onder de groepsleden is gebeurd aan de hand van de inhoudsopgave, zo kon elk lid een bepaald hoofdstuk verder uitwerken. 31

32 Overzicht Wat is iCafe? Project Fases Engineering Problemen Besluit

33 iCafe engineering Programmeertaal PHP5 MySQL database Adobe Flash
Smarty Template Engine Software 33

34 Programmeertaal PHP5 Open-source Platformonafhankelijk Webservers
MySQL Ondersteuning Browseronafhankelijk Objectgeoriënteerd Toekomst // joeri 34

35 MySQL database Opensource Opslag in tabellen Samenwerking met PHP5
// niam 35

36 Adobe Flash Animatie Actionscript Ondersteuning PHP & MySQL Toekomst
// stef 36

37 Smarty Template Engine
Web Templates Scheiding van lagen Klassen Applicatie Webpagina // joeri 37

38 Smarty Template Engine
Resultaat: Webpagina in HTML (& CSS) Smarty Template Presentatielaag Applicatie Applicatielaag // joeri Klassen MySQL database Datalaag 38

39 Software Eclipse IDE XAMPP Tortoise Opensource Java
Meerdere talen via plugin XAMPP Webserver Apache MySQL PHP Tortoise SVN Google Code // naim 39

40 Overzicht Wat is iCafe? Project Fases Engineering Problemen Besluit

41 Problemen Samenwerking Verschillende karakters Verschillende agenda’s
Verschillende ideeën Verschillende werkwijzen // naim 41

42 Problemen Engineering Verwijderen van producten
Gepriviligeerde woorden // joeri en naim 42

43 Problemen Computers Tortoise SVN XAMPP svnX rapidSVN smartSVN Mamp
// stef 43

44 Zelfreflectie eventueel goed om toch te vertelle hoe we het ervanaf gebracht hebben vinde we zelf <- > saai? eventueel met foto van ons 3 naar elkaar wijzend ofzo

45 Overzicht Wat is iCafe? Project Fases Engineering Problemen Besluit

46 Besluit 46