P R O B L E E M O P L O S S E N E N O N T W E R P E N , D E E L 3

TEAM CWA 1

Chuptys SimonClaeys Niels

Beckaert Nathande Potter de ten Broeck Philippe

Dewit MaximeGielis Inge

ASASApplication for Stock And Sales

EINDVERSLAG

Co-titularisDuval Erik

Begeleider(s)Claes Rutger

Vandeputte BramVannieuwenhoven Nick

A C A D E M I E J A A R 2 0 1 0 - 2 0 1 1

1

InhoudInleiding..................................................................................................................................................4

1 Brainstorm......................................................................................................................................4

2 Productomschrijving.......................................................................................................................4

2.1 Use Cases................................................................................................................................5

2.1.1 Drank of eten verkopen..................................................................................................5

2.1.2 Kassa telling begin/eind avond.......................................................................................7

2.1.3 Hoeveelheden van de stock aanpassen..........................................................................8

2.2 Domein model........................................................................................................................9

2.3 Ervaring..................................................................................................................................9

3 Technologie: Android, MySQL, REST based web service..........................................................10

3.1 Android.................................................................................................................................10

3.2 MySQL..................................................................................................................................10

3.3 REST Based Web Service.......................................................................................................10

4 Ontwerp.......................................................................................................................................11

4.1 Architectuur..........................................................................................................................11

4.2 Klasse-diagram.....................................................................................................................11

4.2.1 View..............................................................................................................................11

4.2.2 Controller......................................................................................................................12

4.2.3 Model...........................................................................................................................12

4.3 Database structuur...............................................................................................................13

4.4 Ervaring.................................................................................................................................15

5 Implementatie..............................................................................................................................15

5.1 Problemen............................................................................................................................15

6 Planning........................................................................................................................................16

7 Zelfevaluatie.................................................................................................................................16

8 Vakintegratie................................................................................................................................17

9 Besluit...........................................................................................................................................17

10 Appendix......................................................................................................................................19

10.1 BrainStorm............................................................................................................................19

10.2 Domeinmodel.......................................................................................................................19

10.3 Overzicht Use Cases..............................................................................................................20

10.4 Programma-Architectuur......................................................................................................21

2

10.5 View-Layer............................................................................................................................22

10.6 Controller-Layer....................................................................................................................25

10.7 Model-Layer.........................................................................................................................27

10.8 DataBase...............................................................................................................................30

10.9 Gannt-Chart & Tijdsbesteding van de eerste vier weken......................................................33

3

InleidingEén van de opdrachten van P&O3 is het ontwerpen van een systeem voor de fakbar van VTK. Dit houdt in dat het programma in staat moet zijn om de verkoop van producten bij te houden en hierover gegevens weer te geven en te analyseren. Verder moet het systeem ook bijhouden wat er in de stock zit en waarschuwen als er een tekort is. Bij de uitwerking van het systeem moet gebruiksvriendelijkheid centraal staan, want het zou kunnen dat dit ontwerp echt in gebruik wordt genomen.

1 BrainstormTijdens de brainstormsessie kwam het idee naar voren om met twee verschillende programma’s te werken: één voor het verkopen in de fakbar zelf en een ander voor het analyseren van data en het updaten van de stock. Uiteindelijk bleek het helemaal niet nodig te zijn om het programma op te splitsen. In plaats daarvan werd het project opgedeeld in verschillende packages en kreeg de gebruiker toegang tot bepaalde packages naargelang zijn functie.

In de bijlage staat een afbeelding van het resultaat van de brainstorm (p19). Deze afbeelding geeft de functies weer die ons programma moet bevatten. Bij sommige functies staat een uitroepteken, dit betekent dat het onderdeel belangrijk is.

De eisen van de opdrachtgever vallen samen te vatten in 3 kernbegrippen: verkoop, stock en data-analyse. Daarom komen deze begrippen ook voor als sleutelwoorden in de afbeelding van de brainstorm. Verder leek het ook belangrijk na te denken over de interface en het gebruik van het systeem.

De brainstorm verliep vlot en was van groot belang bij het doorgronden van het systeem. Het gaf een duidelijk zicht op de functionaliteiten die in het systeem moeten zitten. Er zijn enkele ambitieuze ideeën naar boven gekomen die later niet echt realistisch bleken.Zo is het niet werkbaar om bij elke betaling in te geven hoeveel munten van 1 euro, hoeveel van 2 euro, ... er werden gegeven. Dit zou te veel tijd vergen en heeft ook geen toegevoegde waarde. Ook de mogelijkheid om tegelijk 2 bestellingen in te geven leek na de brainstorm niet haalbaar om te implementeren.

Achteraf gezien was het nuttig geweest om meer vragen te stellen i.v.m de eisen van de opdrachtgever (vb: welke informatie ze willen analyseren). Hierdoor zou de brainstorm doelgerichter zijn geweest en zou het programma beter afgestemd zijn op de noden van de fakbar.

2 ProductomschrijvingHet systeem bestaat uit 3 grote componenten die elk een deel van het probleem oplossen:

de verkoop de stock de data-analyse

Het verkoopsonderdeel heeft als doel de verkoop van producten in de fakbar te registreren en zo de virtuele stock en de inhoud van de kassa up to date te houden. Dit is het systeem dat de tappers in de fakbar gaan gebruiken om bestellingen in te geven. Het stockonderdeel omvat het bijhouden van de gegevens over de voorraad van producten en het

4

aanpassen hiervan. Uiteraard is er ook een link nodig met het verkoopsonderdeel zodat verkochte items uit de stock verdwijnen.Het data-analyse-onderdeel draait rond het weergeven van de gegevens van de verkoop en de stock in tabellen en/of grafieken. Het voordeel hiervan is dat de gegevens van de database op een overzichtelijke manier kunnen weergegeven worden.Vermits het totale systeem in 3 modules is opgesplitst, is het mogelijk bepaalde gebruikers slechts tot bepaalde modules toegang te verlenen. Een belangrijke beslissing was het afbakenen van de functionaliteiten van het systeem. Het systeem biedt de mogelijkheid om de verkoop bij te houden. Dit houdt in dat na elke transactie met een klant de virtuele stock en de kassa in het systeem wordt aangepast. Hierbij wordt er ook rekening gehouden met speciale acties die eventueel op dat moment actief zijn. Wanneer zo’n actie (vb: happy hour) plaatsvindt, kunnen de prijzen van de producten veranderen. Ook biedt het de mogelijkheid om met bonnetjes te betalen. Het systeem kan de prijs dus op twee manieren berekenen: ten eerste om gewoon cash te betalen en ten tweede op basis van de medewerkersbonnetjes die door VTK gebruikt worden. Een volgende beslissing was welke statistieken het programma moet kunnen tonen. Dit wordt beperkt tot grafieken over de cash-flow en de product-flow.De cash-flow omvat de inkomsten en uitgaven en ook de delta (het verschil tussen de inkomsten volgens het systeem en de werkelijke inkomsten).De product-flow geeft weer hoeveel er van elke drank verkocht is. Aan de hand van de product-flow kan een overzicht opgesteld worden van wat er wanneer verkocht werd. We hebben hier iets minder aandacht aan besteed omdat we vonden dat de andere functies meer van belang waren. De gegevens kunnen immers reeds bekeken worden in de database. De statistieken die momenteel in het project staan dienen vooral om weer te geven dat het mogelijk is om ze te tonen in Android. Dit kan perfect verder uitgewerkt worden.

2.1 Use CasesUse cases geven een verloop van zaken weer voor de verschillende functies die het programma moet uitvoeren. Ze beschrijven ook de interactie van gebruikers met het systeem. Voor een overzicht van alle use cases en bijhorende actoren zie bijlage p20. De 3 belangrijkste use cases zijn het verkopen van drank en eten, de stock aanpassen en de kassatelling. De sterretjes achter elke subtitel geven het belang van de use case aan.

2.1.1 Drank of eten verkopen *****Doel: Alles wat verkocht wordt, moet worden opgeslagen in het systeem.

Primary Actor:Tappers van de fakbar

Stakeholders and Interests:Beheerder: Wil weten welke producten verkocht worden in de fakbar en wil weten of de zaken goed gaan.Klant: Wil dat zijn bestelling vlot en correct verloopt.Tappers: Het uiteindelijke bedrag wordt voor hen uitgerekend.Stockverantwoordelijke: Wil dat de virtuele stock ten alle tijden up to date is.

Preconditions:Systeem werkt en de hoofdtapper (de verantwoordelijke) is ingelogd.

5

6

Success Guarantee (Postconditions):De bestelling wordt geregistreerd en verwerkt.Er zijn items verdwenen uit de reële stock.De virtuele stock in het systeem is aangepast.De kassa van het systeem is aangepast.De klant krijgt zijn bestelling.

Main Success Scenario (or Basic Flow):

1. Het verkoopscherm van het systeem wordt getoond op het scherm.2. De klant bestelt iets.3. De tapper geeft de correcte bestelling (drank/eten) in.

a) De tapper duidt éénmaal het item aan.b) De tapper duidt meerdere malen achtereen hetzelfde item aan.c) De tapper kiest een van de voorgegeven aantallen.

4. Het systeem geeft de ingevoerde bestelling weer in een lijst op het scherm.5. Het systeem biedt de mogelijkheid om nog een ander product te selecteren. (stappen 3 en 4

worden herhaald)

6. Het systeem rekent de prijs uit en geeft deze weer.

7. De tapper heeft de volledige bestelling ingevoerd en geeft aan dat hij wil afrekenen.

8. Het systeem geeft de totale prijs van de transactie weer.

9. De klant betaalt (en krijgt eventueel wisselgeld van de tapper) en krijgt zijn bestelling.

10. De tapper geeft aan dat de transactie afgerond is.

11. Het systeem past de virtuele stock aan.

12. Het systeem past de virtuele kassa aan.

13. Het systeem keert terug naar het verkoopscherm.

Extensions (of Alternative Flows)

3a. De tapper geeft een foutieve bestelling in.

1. De tapper geeft aan dat hij een bepaald item uit de lijst met ingevoerde bestellingen wil verwijderen.

2. Het systeem haalt het item uit de lijst met bestellingen en rekent dit niet meer mee bij het totaal.

3b. De tapper heeft 1 item te veel ingevoerd (bijvoorbeeld 4 ipv 3 cola’s).

1. De tapper geeft aan dat hij slechts 1 element van de bestelling wil verwijderen.

7

2. Het systeem haalt het item uit de lijst met bestellingen en rekent dit niet meer mee bij de totaalprijs.

6a. De tapper selecteert per vergissing “betalen met medewerkersbon” ipv “cash betalen”.

1. Wanneer men het type betaling selecteert komt er een scherm om te bevestigen.2. De tapper kiest ervoor niet te bevestigen en krijgt terug het verkoopsscherm (met de

bestelling te zien) waar hij nu de juiste vorm van betaling kan selecteren.

7a. De tapper drinkt iets.

3. De tapper geeft in stap 7 aan dat de bestelling medewerkersdrank is ipv aan te geven dat hij wil afrekenen

2.1.2 Kassa telling begin/eind avond *****Doel:Aan het begin en het einde van de avond (wanneer na het opstarten van het programma voor de eerste keer het verkoopsscherm wordt geopend en voor het afsluiten van het programma) moet er een kassatelling gebeuren.

Primary Actor:Hoofdtappers van de fakbar.

Stakeholders and Interests:Beheerder: Kan controleren wie er op dat moment verantwoordelijk was.Neventappers: Zolang de kassa niet geteld is kan het verkoopsscherm niet worden geopend en kunnen er geen bestellingen worden ingegeven.Boekhouder: Aan de hand van kassatellingen kan men de delta berekenen. (Delta duidt het verschil aan tussen hoeveel geld er in de reële kassa zit en hoeveel er in de virtuele kassa zit.)

Preconditions:Het systeem werkt en de hoofdtapper is ingelogd en het is het begin/einde van de avond.

Success Guarantee (Postconditions):De hoofdtapper kan beginnen verkopen. Het systeem weet hoeveel er in de kassa zit.

Main Success Scenario (or Basic Flow):

1. Het syteem geeft het startmenu weer. (met onder andere de opties “Kassatelling”, “Verkoop” en “Programma beëindigen”)

2. De hoofdtapper kiest voor "Kassatelling"3. De hoofdtapper telt het geld in de kassa.4. Het systeem vraagt hoeveel geld in de kassa zit.5. De hoofdtapper geeft de gegevens in en geeft aan dat hij klaar is met invoeren.6. Het systeem vraagt een bevestiging.7. De hoofdtapper bevestigd.8. De gegevens worden opgeslagen.9. De hoofdtapper gaat terug naar het startmenu.10. De hoofdtapper kan nu de optie “Verkoop” of “Programma beëindigen” selecteren.

8

Extensions (or Alternative Flows)5a Onmogelijke ingave (negatief, geen getal, ..)

1. Het systeem geeft een foutmelding.2. Het systeem geeft het venster weer om het bedrag opnieuw in te geven (stap 4)

wordt opnieuw weergegeven.

9

5b Foutieve ingave (verkeerd aantal)

1. Bij stap 7 geeft de hoofdtapper aan dat hij nog iets wil veranderen.2. Het systeem geeft het vorige scherm terug weer.3. Er wordt verder gegaan vanaf stap 5.

2.1.3 Hoeveelheden van de stock aanpassen *****Doel:De stock in het systeem moet aangepast worden wanneer een nieuwe levering is toegekomen.

Primary Actor:Stockverantwoordelijke: zorgt ervoor dat de stock altijd up to date is.

Stakeholders and Interests:Tappers: Het systeem kan geen producten verkopen die niet in stock staan.

Preconditions:De stockverantwoordelijke is ingelogd. De verantwoordelijke heeft de reële stock reeds geteld.

Success Guarantee (Postconditions):De virtuele stock komt overeen met de reële stock.

Main Success Scenario (or Basic Flow):

1. De stockverantwoordelijke kiest de optie “Stock Aanpassen”.2. Het systeem laat zien hoeveel flessen/vaten van het product in de stock aanwezig zijn.3. De stockverantwoordelijke zoekt in de lijst naar het product.4. De stockverantwoordelijke geeft in hoeveel producten moeten worden toegevoegd. 5. De stockverantwoordelijke herhaalt stap 3 en 4 totdat alle hoeveelheden zijn ingevuld.6. De stockverantwoordelijke geeft aan dat het systeem de stock mag aanpassen aan de hand

van de invoer.7. Het systeem controleert de invoer en vindt geen problemen (zie extensions 7a en 7b).8. Het systeem geeft een overzicht van de invoer weer (lijst met producten en ingevoerde

cijfer).9. De stockverantwoordelijke kijkt de lijst na en bevestigt.10. De gegevens in het systeem worden aangepast.11. Het systeem geeft de nieuwe stocklijst weer.

Extensions (or Alternative Flows)3a. Het product staat niet in de lijst.

1. De verantwoordelijke moet het nieuwe product ingeven. Ga naar Use Case H (nieuw product invoeren).

7a. Het systeem controleert de invoer en vindt problemen. De verantwoordelijke gaf foutieve input (bijvoorbeeld letters in ipv cijfers).

1. Het systeem geeft aan dat er foutieve invoer is ingegeven. 2. Het systeem vraagt de foutief ingegeven invoer opnieuw in te geven.

10

3. Als de nieuwe invoer wel juist is, wordt de use case verder uitgevoerd(stap 8). Indien dit niet het geval is, dan wordt 7a herhaald.

7b. Het systeem controleert of de productaantallen in de stock niet negatief worden.

1. Het systeem geeft aan dat de aantallen negatief zouden worden en dat dit onmogelijk is. 2. Het systeem geeft een invoervakje weer waarin de juiste invoer kan ingegeven worden.3. Als deze invoer juist is, wordt de use case verder uitgevoerd (stap8).

9a. De verantwoordelijke ziet een fout in de invoer.

1. De verantwoordelijke geeft aan dat hij nog iets wil aanpassen.2. Stap 6 wordt weergegeven. (Hierin kunnen de aantallen nog aangepast worden.)

2.2 Domein model (p19)

Als uitgangspunt voor het domein model werd gebruik gemaakt van de brainstorm en de producteisen van de opdrachtgever. Dit was één van de moeilijkste taken aangezien het concept van een domein model nog onbekend terrein was. Enerzijds bevat het model de belangrijkste actoren van het systeem, anderzijds geeft het ook de multipliciteiten weer. (Deze geven weer hoeveel instanties van de ene klasse kunnen geassocieerd worden met een instantie van een andere klasse tijdens de interactie.). In het domein model bevinden zich twee soorten klassen; enerzijds vind je daar de klassen van het programma terug, anderzijds ook de actoren die gebruik maken van die klasse.Centraal in het model staat verkoopswaar. Tijdens een transactie verkoopt de tapper verkoopswaren aan de klant. De hoofdtapper die ingelogd is, is verantwoordelijk voor de transactie. Een transactie heeft een bepaalde prijs. Deze prijs komt in de fakkas terecht na betaling. Ook een verkoopswaar heeft een verkoopsprijs. Deze is afhankelijk van de acties die op dat moment gelden. Een verkoopswaar bevat ook een link naar de producten: deze bevatten het type en het volume.De aankoopprijs is ook gelinkt aan een verkoopswaar. Deze prijs wordt bepaald door de leverancier tijdens een bestelling. Een stockverantwoordelijke heeft de bestelling gemaakt en zet deze op een rekening. De boekhouder en de beheerder hebben toegang tot deze rekening waar alle facturen in staan.Een tweede centraal aspect is de stock. De stockverantwoordelijke past de stock aan als er een levering is geweest. De stock wordt ook aangepast als er door een transactie koopswaar verdwenen is. Tot slot zijn er nog de statistieken. De statistieken bevatten de productflow en de cashflow. Zowel de beheerder als de boekhouder en de stockverantwoordelijke hebben toegang tot de statistieken. De overgang van het domein model naar het klassendiagram verliep niet altijd even vlot. Het domeinmodel was wel praktisch om de grote lijnen van het systeem te uit te werken.

2.3 ErvaringDe productomschrijving had als voornaamste nut het doel van het project in beeld te brengen .Enerzijds gaf het de aanzet om zeer grondig na te denken over de functionaliteiten waarover het programma zou moeten beschikken. Hierbij denken we vooral aan de Use Cases. Anderzijds moesten we ook voor het eerst een beeld maken van hoe deze functionaliteiten concreet gerealiseerd zouden moeten worden. Ook bracht het verschillende visies van teamleden aan het licht en konden hier al afspraken rond gemaakt worden.Aangezien deze stap in het ontwerpen van een project zeer belangrijk is, werd hieraan veel tijd besteed. Misschien zelfs te veel aangezien voor velen het nut en doel van de productomschrijving

11

niet helemaal duidelijk was. Voornamelijk het domein model leverde veel vraagtekens op. Daarmee dat deze bij het uitwerken van de klassendiagrammen grondig herzien moest worden. Daarentegen kwamen de Use Cases later in het ontwerpproces zeer goed van pas.

3 Technologie: Android, MySQL, REST based web service

3.1 AndroidAndroid is een open source platform dat ontworpen is om te draaien op mobiele toestellen. Het is open source wat betekent dat iedereen vrije toegang heeft tot de broncode.De voordelen zijn:

- De portabiliteit van Android: Het kan draaien op smartphones, tablets, netbooks... - Android biedt ons een raamwerk(framework) waarin we kunnen programmeren. Het geeft

ons een duidelijk structuur met zijn eigen syntax (bv : het gebruik van activities die elkaar oproepen via intents, de grafische weergave apart van de eigenlijke code...).

- Android is open source waardoor iedereen er programma’s voor kan schrijven die de andere gebruikers kunnen helpen.

De nadelen zijn: - De lay-out is vooral gericht op smartphones. Je kan de resolutie vergroten maar dan is de

kwaliteit toch minder aangezien de resolutie wordt geëxtrapoleerd tot de grootte van het beeldscherm.

- Het is nog een relatief nieuw platform met het gevolg dat bepaalde features nog niet volledig op punt staan (de beveiliging en layout bv).

Aangezien bij de verkoop gebruik zal gemaakt worden van een touchscreen tablet of pc, is het gebruik van Android voor het uitwerken van de view-Layer van dit programma een goede keuze.

3.2 MySQLMySQL is een veelgebruikt open source datamanagementsysteem. SQL staat voor Structured Query Language. SQL kan nog worden opgedeeld in 2 delen: Data Manipulation Language (DML) en Data Definition Language (DDL). Voor het project moeten geen nieuwe database tabellen aangemaakt worden, DDL wordt dus niet gebruikt. Er wordt dus enkel gebruik gemaakt van de DML om gegevens in de tabellen te manipuleren. Zo kunnen gegevens worden toegevoegd aan databasetabellen, de gegevens kunnen worden opgevraagd, verwijderd of vernieuwd (slechts enkele gegevens uit een rij van de database worden veranderd). Het voordeel was dat de statements die hiervoor in SQL gebruikt worden (INSERT, SELECT, DELETE, UPDATE) zeer duidelijk zijn. Het is in een MySQL-database ook eenvoudig doelgerichte informatie op te vragen uit tabellen aan de hand van allerlei commando-woorden zoals bijvoorbeeld WHERE en logische operatoren zoals AND en OR. Een laatste voordeel was dat het beheer van de database enorm makkelijk en duidelijk was via phpmyadmin.

3.3 REST Based Web ServiceRESTful service draait rond de interactie van clients en servers. Clients stellen een vraag aan de servers; servers verwerken de vraag en geven het gepaste antwoord terug. De webserivce geeft resultaten terug in het JSON formaat. Dit formaat kan makkelijk worden omgezet naar java-objecten en omgekeerd omdat hiervoor reeds methodes zijn. Er moest dus geen aparte parser geschreven worden.

Een van de voordelen van client-server is dat de clientsoftware kan werken zonder de hele tijd het netwerk te belasten. Enkel wanneer de client informatie van de server nodig heeft wordt een verbinding gemaakt. Ook worden de verantwoordelijkheden opgesplitst door met twee

12

programma’s te werken. De client heeft niets te maken met de opslag van data en de server heeft niets te maken met de gebruikersinterface of de toestand van de client.

4 Ontwerp

4.1 ArchitectuurDe architectuur van ons programma is te vinden in de bijlage p21.Het software gedeelte dat op de computer van de gebruiker moet geïnstalleerd worden, bevat de model-, controller-, view laag. Deze structuur staat bekend als het MVC design patroon. Elke laag staat in voor een bepaald aspect van het programma. De view-laag staat in voor de connectie tussen de gebruiker en het programma en is geïmplementeerd aan de hand van Android. Dit is met andere woorden de grafische weergave van het programma. De controller-laag is de connectie tussen de view-laag en het eigenlijke logisch gedeelte van het programma.Dit laatste is de model-laag. Het model bevat de uiteindelijke implementatie van het programma. Zowel de controller als de model-laag zijn in java geschreven. Hieraan wordt een vierde laag verbonden. Dat is de data-laag. Hiermee wordt de database waarmee het programma verbonden is, bedoeld. Deze staat echter apart van het MVC patroon aangezien deze zal draaien op een andere locatie, namelijk de servers van computerwetenschappen. De gebruiker moet zich hierover geen zorgen maken als hij het programma gebruikt. Dit werkt op zich onafhankelijk van het programma, je kan met een minimale aanpassing aan het systeem een andere database gebruiken.De webservice zorgt voor de link tussen ons programma en de database. De webservice is in http geschreven en zorgt voor de omzetting naar strings die in de database opgeslagen moeten worden.Het programma zo opdelen heeft als voordeel dat het logisch gedeelte van ons programma volledig onafhankelijk is van de weergave.

4.2 Klasse-diagramZoals reeds uitgelegd bestaat het programma uit vier lagen: model-, controller-, view- en data laag. De eerste drie van deze lagen zijn echter op hun beurt grondig onderverdeeld in verschillende aspecten, die hetzelfde zijn voor de drie lagen. Deze aspecten, of packages genaamd, zijn: Sales-, Product-, Management- en Statistics package. Elk zo’n package bevat de eigenlijke klassen-structuren. De uiteindelijke algemene structuur (zonder op het niveau van afzonderlijke klassen te kijken) is terug te vinden in de bijlagep21 (onderaan). Vervolgens zullen we elke laag van naderbij bekijken.

4.2.1 ViewDe view-laag zorgt concreet voor de interactiemogelijkheden tussen de gebruiker en het programma. Enerzijds betekent dit het weergeven van de grafische uitvoer van het programma met behulp van Activities. Anderzijds wilt dit zeggen het registreren en doorgeven van acties van de gebruiker. Dit gebeurt met behulp van Listeners die gekoppeld worden aan knoppen, velden en andere grafische uitvoer van de Activities.De Activities staan alleen in verbinding met de rest van het programma via de controllers. Dit zorgt voor een grote, en zeer voordelige, onafhankelijkheid van het programma ten opzichte van de visuele weergave.De belangrijkste methode die in elke activity geïmplementeerd staat, is de ‘onCreate’-methode. Deze wordt aanroepen wanneer de activity voor het eerst sinds zijn levenscyclus opgestart wordt.

13

Ook de view-laag wordt opgedeeld in de vier grote packages: Sales, Product, Management en Statistics. Zie bijlagen p22-24 voor de concrete klassendiagrammen van de view-laag. Hierbij zijn de Listeners wel weggelaten. Deze worden meestal als inwendige klassen gedefinieerd binnen de klasse waar ze nodig zijn. Dit beperkt de hoeveelheid te implementeren code en bewaart de overzichtelijkheid. Elke Listener zal immers andere reacties teweegbrengen na een actie van de gebruiker. Bovendien verschilt elke Listener slechts in één methode van de klasse die hij implementeert (vanuit de Android-library).

4.2.2 ControllerDe controller-laag staat in voor de communicatie tussen de view-laag en de model-laag.Een controller speelt gegevens over één welbepaald aspect, die komen van de model-laag, door naar de Activities. Daarnaast geeft ze ook veranderingen, die gebeuren in de Activities door aan de model-laag. Elke controller is geïmplementeerd volgens het Singleton-pattern. Elke controller staat in verbinding met een gelijknamige manager-klasse uit de model-laag. Dit benadrukt dat elke controller voor één en slechts één aspect van het logisch gedeelte instaat. Alleen de controller van Statistics doet beroep op meerdere Managers. Dit komt doordat voor het maken van grafieken de informatie van verschillende plaatsen afkomstig is . Desalniettemin blijft de controller voor exact één aspect instaan, namelijk het vergaren van de juiste informatie voor de weergave van de grafieken.De controller-laag moet bovendien volledig onafhankelijk zijn van de technologie waarmee de view-laag is geïmplementeerd. Dit zorgt voor een grote, en zeer voordelige, onafhankelijkheid van het programma ten opzichte van de visuele weergave.Ook voor de controllers maken we onderscheid tussen de vier grote packages: Sales, Product, Management en Statistics. Zie bijlagen p25-26 voor de concrete klassendiagrammen van de controllers.

4.2.3 ModelHieronder wordt steeds een korte beschrijving gegeven van de flow van de verschillende programma-onderdelen. Een specifieke beschrijving per klasse staat in de bijlage p27-29.

Sales(p27)

Wanneer een Transaction wordt aangemaakt, kunnen daar TransactionItems aan toegevoegd worden. Deze items stellen een Merchandise in een bepaalde hoeveelheid voor. Beschikbare Merchandises kunnen verkregen worden dmv de MerchandiseManager. Deze synchroniseert namelijk met de database en weet dus welke Merchandise er bestaan. Ook het aanmaken van nieuwe Merchandise moet via deze manager gaan.

Een Merchandise is opgebouwd uit MerchandiseItems. Deze items stellen een Product voor met een bepaalde hoeveelheid waarin dit product in de Merchandise gebruikt wordt.

Wanneer een Transaction voltooid wordt, wordt deze via de TransactionManager toegevoegd aan de database. Ook de stock wordt aangepast. Dit gebeurt via ProductManagement.

Het voltooien van een transactie gebeurt door de TransactionManager. Deze zorgt ervoor dat de transactie wordt opgeslagen in de database en dat de stock wordt aangepast, zodat deze steeds up to date blijft.

14

PricingSystem (p28)

Wanneer de totale prijs van een transactie bepaald moet worden, wordt er aan een PriceCalculator deze transactie samen met het gewenste PaymentType (de eenheid waarin je wil betalen: cash, medewerkersbonnen, …) doorgegeven. De PriceCalculator bevat een lijst met links tussen PaymentTypes en PriceStrategies. Op basis van deze lijst wordt een strategy gekozen waarmee de totaalprijs van de transactie in het juiste PaymentType wordt berekend. PriceStrategies bevatten een lijst van toepasbare acties. Op basis van deze acties wordt dan de totaalprijs van de transactie berekend.

Acties bestaan uit één of meerdere Rules. Deze rules kunnen door de gebruiker toegevoegd worden. De verschillende rules die momenteel beschikbaar zijn in het systeem zijn de PercentRule, de ChangeMerchandisePriceRule en de BuyXGetYRule.

Product (p29)

Wanneer er een wijziging aan de stock moet aangebracht worden gebeurt dit via PoductManagement. De verschillende mogelijke functies zijn het toevoegen en verwijderen van producten uit de stock en het aanmaken van nieuwe producten. De stock wordt opgeslagen met behulp van StockItems. Deze items bevatten een Product en hoeveel hiervan in de stock aanwezig is.

De communicatie met de database gebeurt via de StockDAO om de virtuele stock aan te passen. De ProductDAO dient om de verschillende soorten Products op te slaan en op te vragen.

Waneer de stock moet aangepast worden op basis van een transactie, moeten de hoeveelheden van Merchandise (zoals deze in een Transaction zitten) omgezet worden naar Product-hoeveelheden (bv 1,5 liter voor een fles cola). Dit omrekenen gebeurt ook in ProductManagement.

Management (p29)

Het aanmaken, verwijderen, aanpassen en opvragen van een User gebeurt via de UserManager. Deze communiceert via de UserDAO met de database. Bij het inloggen wordt via deze weg gecheckt of de ingegeven informatie correct is.

De UserManager houdt ook steeds een ‘activeUser’ bij. Dit is de User die momenteel actief en dus verantwoordelijk is voor bijvoorbeeld de verricht transacties.

Het management controleert ook welke delen beschikbaar zijn voor de gebruikers. Dit wordt bepaald gecontroleerd op basis van de functie van de gebruikers(tapper, beheerder...).

15

4.3 Database structuurEen volledig overzicht van de gehele database structuur wordt weergegeven door tabel 1 in de bijlage p32. De MySQL database die gebruikt wordt in het programma, is opgedeeld in 10 tabellen. Elke tabel representeert een Java-klasse uit de modellaag (Stock komt overeen met de klasse StockItem). De enige uitzonderingen hierop zijn de tabellen DeltaCash en DeltaStock. Deze twee komen niet voor als objecten in het programma.

Enkele tabellen zijn rechtstreeks verbonden met objecten uit de modellaag. Dat wil zeggen dat de velden en types van deze tabellen in de database volledig overeen komen met de velden en de statische types bij de declaratie van deze velden in de Java-objecten. Dit is het geval voor de volgende tabellen: Product, User en Till.

Daarnaast zijn er ook tabellen die gelinkt zijn met andere tabellen. Dit komt voor bij tabellen waarvan het overeenkomstig Java-object een ander object opslaat in één van zijn velden. De tabellen waarop dit van toepassing is, zijn MerchandiseItem, Stock, Transaction en TransactionItem. De overeenkomstige objecten in het programma slaan respectievelijk een Product-, Product-, User- en Merchandise-object op in één van hun velden. In de database wordt deze link gelegd aan de hand van de unieke id die in elke tabel aanwezig is. Aangezien de tabellen op deze manier gelinkt zijn, mogen er geen rijen verwijderd worden uit de tabellen Product, User en Merchandise. Anders zou het kunnen voorvallen dat er in één van de velden van een tabel een id wordt bijgehouden die linkt naar een niet-bestaande rij uit een ander tabel. In dit geval zou de omzetting van de tabellen naar de objecten niet meer correct verlopen. Om dan toch deze objecten te kunnen verwijderen, wordt in de tabellen Product, User en Merchandise gebruik gemaakt van een veld activated dat bijhoudt of het object nog actief moet voorkomen in het programma. Wanneer dit veld de waarde false krijgt dan is het object voor het programma als het ware verwijderd.Als voorbeeld van deze relatie geldt het veld user_id in de tabel Transaction. Dit veld slaat de id op van de rij in de tabel User die overeen komt met de gebruiker die was aangemeld tijdens het voltooien van de transactie. Dit veld maakt het dus mogelijk om de juiste gebruikersgegevens op te halen bij het omzetten van een rij uit de Transaction-tabel naar een Transaction-object.

Er bestaat nog een laatste link tussen enkele tabellen. Dit gebeurt bij tabellen waarvan het overeenkomstig Java-object een lijst van objecten opslaat in één van zijn velden. Dit komt voor in twee objecten die in de database worden opgeslagen: Merchandise en Transaction. Daarom zijn de tabellen Merchandise en Transaction op een speciale manier gelinkt met respectievelijk MerchandiseItem en TransactionItem. Het zijn de velden merchandiseId en transactionId in respectievelijk de tabellen Merchandise en Transaction die zorgen voor de relatie. Deze velden slaan immers de unieke id van een rij uit de Merchandise- of Transaction-tabel op als waarde. Op die manier onthoudt een MerchandiseItem dus bij welke Merchandise hij behoort. De lijst van een Merchandise -object wordt dus op volgende manier opgeslagen in de database. Elk van de MerchandiseItems in de lijst wordt als een rij opgeslagen in de tabel TransactionItem en onthoudt in het veld merchandiseId de id van de Merchandise uit de tabel Merchandise waar het bij hoort. Analoog geldt dit ook voor Transaction en TransactionItem.

16

De database access objects (DAO) voorzien essentiële methodes om objecten op te halen uit, weg te schrijven naar, te verwijderen uit en aan te passen in de database. Al de communicatie tussen het programma en de database verloopt via deze klassen. Er wordt een onderscheid gemaakt tussen de client- en server-DAO's. De client-DAO's communiceren rechtstreeks met de modellaag en zetten informatie, geleverd door de server-DAO's, om in objecten voor het programma. Ze staan ook in voor het omgekeerde verkeer: objecten die moeten worden opgeslagen in de database worden door de clientDAO's onder de juiste vorm doorgegeven aan de server-DAO's. De server-DAO's staan in voor de communicatie met de database. De server-DAO's gaan de verzoeken van de client-DAO's vertalen naar de juiste MySQL-queries en deze dan uitvoeren op de database. De ontvangen resultaten uit de database worden dan onder gepaste vorm doorgestuurd naar de client-DAO's. Een klassendiagram van de verschillende client-DAO's wordt weergegeven in bijlage p30. Een algemeen overzicht van de relaties tussen de clientDAO’s, serverDAO’s en database tabellen is te bekijken in de bijlagep31.

4.4 ErvaringHet domeinmodel vereistte reeds dat de concepten werden uitgedacht. Het uitwerken van het ontwerp via klassendiagramma ging vrij vlot. De architectuur begrijpen vergde wel meer moeite. In het begin was het moeilijk om de links tussen de database en het model en de view te zien. De idee hoe deze met elkaar moeten interageren was aanvankelijk moeilijk om in de praktijk om te zetten. Dit kwam grotendeels doordat er nog geen voorkennis was van android en de database. De uitgewerkte structuur voor deze onderdelen liet dan ook te wensen over. De methodes en klassen van het model konden direct geschreven en uitgewerkt worden in ons programma. Dit zorgde voor een goed startpunt van waaruit we konden vertrekken; en zorgde er ook voor dat we de algemene structuur niet uit het oog verloren. Het ingeven van deze modellen duurde vaak langer dan het uitdenken ervan.

5 Implementatie

5.1 ProblemenEen eerste probleem bestond eruit om met meerdere mensen aan één programma te werken. Objectgericht programmeren wordt echter gekenmerkt door het principe dat elk onderdeel van het programma slechts beperkte kennis heeft van de rest. Dit principe werd dan ook toegepast om dit probleem op te lossen. Elk teamlid hield zich dus bezig met een deel van de eigenlijke implementatie. De belangrijkste onderdelen waren de grafische userinterface, de database en het model. Elk van deze onderdelen kende zijn eigen problemen die hier aan bod zullen komen.

De moeilijkheden die naar voren kwamen bij het opbouwen van de grafische interface kwamen vooral neer op het feit dat er nog niet veel kennis vergaard was over hoe dit in Android moest gebeuren: Werken met activities, intents, oncliklisteners, adapters en dergelijke om zo tot een werkende interface te komen had veel opzoekwerk, trial and error nodig vooraleer hiermee vlot kon gewerkt worden. Ook het schrijven in xml en het aanpassen van het Android Manifest waren vaak de oorzaak van veel gemaakte fouten.De database was ongetwijfeld meest tijdsrovende deel om te implementeren. Dit werd niet bevorderd door de late beschikbaarheid aan informatie en de zeer beperkte voorkennis over dit onderwerp. Een voorbeeldcode werd beschikbaar gesteld, maar deze ontleden en vervolgens zelf implementeren was ook geen gemakkelijke taak. Het grootste probleem was dat de database slechts beperkt bereikbaar was om aan te werken. Zo was het niet mogelijk om van thuis code te testen.

17

Zolang dit deel niet werkte kon ook de rest van het programma niet communiceren met de database en kon de doorstroom van view naar database weinig getest worden. Dit kwam doordat er geregeld een .war-file moest aangepast worden en dit altijd via een assistent moest gebeuren. Het zou eenvoudiger geweest zijn als dit aanpassen rechtstreeks zou kunnen gebeuren.

Het moeilijkste item bij het implementeren van het model was het ontwerpen van een PricingSystem op basis van een aantal design-patterns. Zo moest onder andere een strategy-pattern geïmplementeerd worden om een flexibel systeem te garanderen. Eénmaal het ontwerp hiervan af was, waren de grootste moeilijkheden wel voorbij.

Een ander algemeen probleem was het structureren van het programma. Zoals uit de brainstorm blijkt, werd er eerst geöpteerd om een tweetal verschillend programma’s te ontwerpen die op verschillende devices werkten (een verkoopsapplicate voor op touchscreens, een stockbeheer en een data-analyse deel). Deze structuur is dan ook verschillende keren aangepast. Deze aanpassingen komen aan bod in volgend topic.

De tijdsbesteding was ook niet ideaal. Er heerste het gevoel dat er in verhouding met het ontwerpen weinig geprogrammeerd is. Dit ontwerpen bestond uit het maken van use cases, domeinmodel en klassendiagramma. De tijd die hierin gestoken bleek later niet zo nuttig tijdens het programmeren. Het ontwerpen is zeker een belangrijk onderdeel (al dan niet het belangrijkste), maar wanneer er niet genoeg tijd is om het hele ontwerp vervolgens te implementeren, lijkt het achteraf beter om iets minder tijd hierin gestoken te hebben.

6.2 Aanpassingen

De belangrijkste aanpassing die is doorgevoerd is het veranderen van de globale structuur van het programma. In een eerste ontwerp bestond dit dus uit twee verschillende programma’s. Later werd geöpteerd voor één programma dat bestaat uit verschillende packages. Om toch een vorm van afscherming te hebben, werden er userFunctions toegevoegd. Deze laten toe om op basis van de functie van de gebruiker een ander deel van het programma beschikbaar te maken.

Een tweede aanpassing bestond uit het minimaliseren van de tijd die in het onderdeel statistiek werd gestoken. Dit deel werd als het minst belangrijke voor een verkoopssysteem bevonden en is daarom dus ook als laatste en beperkt geïmplementeerd. De meest relevante gegevens zijn echter wel allemaal beschikbaar via de database. Indien er meer tijd geweest was, zou het uitgebreider implementeren van deze data niet al te veel tijd meer in beslag nemen.

6 PlanningOnze planning is te bekijken op de wiki:(http://ariadne.cs.kuleuven.be/mediawiki/index.php/CWA1-1011). De planning van de implementatie zit niet in de bijlagen omdat deze niet leesbaar kan worden weergegeven op één pagina. Een Gannt-Chart en de planning van de eerste vier weken is terug te vinden in de bijlage p33.

18

De eerste weken liep alles vlot bij het ontwerpen van ons systeem. Het was pas toen de implementatie aan bod kwam dat we tot het besef kwamen hoeveel er nog moest gebeuren. Achteraf gezien had de implementatie misschien een week vroeger mogen beginnen.Hieraan moet toegevoegd worden dat naast de voorziene tijd om aan dit project te werken, er zeer veel avonden opgeofferd zijn aan de verdere uitwerking en implementatie. Dit gebeurde voornamelijk vanaf het tussentijds verslag, wanneer er werd begonnen aan de implementatie van code. Een exact overzicht over het aantal uren en verdeling van dit werk is niet toegevoegd wegens de grootte van deze hoeveelheid extra bestede tijd.

7 ZelfevaluatieHet eindresultaat is bijna zoals verwacht. Bij het ontwerpen zag het er niet altijd even rooskleurig uit naarmate de deadline dichterbij kwam. Maar uiteindelijk zijn we in ons opzet geslaagd. Op een aantal kleine foutjes na, doet het programma wat het zou moeten doen. Er kan vanalles besteld worden, producten bijgemaakt worden, gebruikers aanmaken of verwijderen en dit alles wordt bijgehouden met een database. Enkel de statistieken zijn niet zo uitgebreid. De klant verwachtte meer informatie over voorbije transacties en dergelijke.

Een van de troeven van het programma is de gebruiksvriendelijkheid van de verkoop van verkoopswaren. Er is een duidelijk scherm met verschillende tabbladen waarin de nieuwe verkoopswaren automatisch verschijnen. Door middel van het gebruik van producten als ingrediënten voor niewe verkoopswaren, is het een eitje om bijvoorbeeld een coktail toe te voegen waar 5 verschillende dranken voor gebruikt worden. Een andere grote troef is het gebruik, toevoegen en verwijderen van acties. Op een gemakkelijke manier kan men de prijzen aanpassen voor een welbepaalde periode, of een percentje geven op de gehele bestelling. Zelfs de wekelijkse ‘happy hour’ van fakbar ‘t Elixir kan met een eenvoudige druk op de knop geactiveerd worden. Er is daarom ook veel aandacht besteed aan het ontwerp van het prijzensysteem.Daarnaast zijn de statistieken een van de mindere punten van het ontwerp. De beperkte informatie die men kan opvragen, vraagt veel tijd om te verwerken. Er zouden veel meer verschillende soorten gegevens weergegeven kunnen worden, maar bij gebrek aan tijd achterwege zijn gelaten. Dit is jammer, omdat er toch veel gegevens worden opgeslagen in de database met de bedoeling mooie statistieken te kunnen weergeven.

We zijn vrij tevreden met hoe het er allemaal uitziet en de werking en structuur van het programma zelf. Indien we opnieuw zouden moeten beginnen, zou het er vrij gelijkaardig uitzien. Hier en daar zou een aanpassing zijn qua implementatie vanwege ervaring met Android en SQL, waardoor er eventueel efficiënter gebruik gemaakt wordt van bepaalde bestaande methodes. Aangezien aan Computerwetenschappen volgend semester lessen zijn over databases, is de kans reëel dat het databasegedeelte er na die lessen heel anders zou uitzien. Efficiënter gebruik, waardoor er misschien op heel wat eenvoudigere manieren gegevens kunnen worden opgevraagd en daardoor meer statistieken om tevoorschijn te halen. Maar in verband met de layout zou er niet veel veranderen.

8 VakintegratieIn het project van computerwetenschappen voor PenO3 wordt voornamelijk het vak Methodiek van de Informatica (1ste bach) gebruikt. Dit is heel belangrijk voor al het programmeerwerk aan bod komt. Ook het ontwerpen van een klassendiagram komt goed van pas in deze PenO. De principes uit PenO 1 en 2,zoals de Gantt Chart en de 7-sprong, gebruikt men hier opnieuw. Er wordt echter weinig gebruikt van informatie uit andere vakken. Dit is in tegenstelling tot andere opdrachten van PenO3 zoals het draadloos overbrengen van data en vermogen. Tijdens het project leer je wel heel wat

19

andere zaken bij. Android, domeinmodel en databases zijn de voornaamste nieuwe domeinen van de informatica die gebruikt zijn en die we bijgeleerd hebben. Enkele van deze vakken behoren zeker tot de leerstof van het volgende semester (bij keuze van CW).

9 BesluitIn vergelijking met andere projecten van PenO3 is het project van computerwetenschappen nog vrij goed begeleid. Indien dit niet het geval zou zijn, zou er misschien al na week 3 aan de implementatie begonnen zijn. De opbouw van brainstorm via use cases naar domeinmodel en klassediagram en tenslotte de implementatie van het programma is cruciaal voor het ontwerpen van een programma van deze omvang. De meesten hebben deze aspecten voor PenO3 nog nooit gebruikt. In vergelijking met PenO uit de vorige jaren is er wel meer vrijheid om keuzes te maken. Men krijgt een project en mag zelf helemaal beslissen hoe het eindproduct er zal uitzien. De tijdsbesteding ligt ook meer in eigen handen, vooral na het tussentijdse verslag. Ondanks de goede begeleiding bij computerwetenschappen, wordt de uitspraak ‘Google is your friend’ meer en meer realiteit in PenO3. Dit is een logische evolutie naarmate we meer zelfstandigheid krijgen. De inleidingen die we kregen, zijn praktische inleidingen om de concepten te begrijpen. De begeleiders geven een aanzet om er meer informatie over op te zoeken en het zelf uit te pluizen. In dit geval gaat het vooral over informatie rond Android en MySQL/webservice.In de PenO van computerwetenschappen is het verkrijgen van informatie over bepaalde methodes van ontwerpen heel gemakkelijk. Zo goed als alles is te vinden op het internet, wat een groot gemak met zich mee brengt, maar op hetzelfde ogenblik ook een vloek vanwege de overvloed aan informatie. Dit leidt dan weer tot een efficiënter vergaren van relevante informatie.

Wat een enorme hulp zou zijn geweest doorheen het hele project is sneller informatie krijgen in verband met Android en databases. Naarmate dat er meer wordt geprogrammeerd, veranderen de use cases en bepaalde concepten. Dit fenomeen ontstaat door te weinig kennis over mogelijkheden en functies van de verschillende aspecten van het programma. Indien er vroeger informatie over gegeven wordt, zeker wanneer het gebruik van iets wordt opgelegd, kan men vaak problemen voorkomen. Dit zou ook veel frustraties vermijden en het werk sneller vooruit laten gaan.

Het project van PenO3 dit jaar was dus de veeleisende en boeiende uitdaging een volledig programma te ontwikkelen. Hierbij kwamen aspecten voor waarmee we reeds vertrouwd waren. Daarentegen moesten ook vele nieuwe aspecten zelf bekeken en begrepen worden. Dit maakte van het project een leerrijke maar zeer tijdsintensieve opdracht. Door de uitgevoerde projectontwikkeling hebben we een grote stap vooruit gezet in de wereld van het programmeren. Door hecht groepswerk, goede communicatie en intensieve arbeid hebben wij, leden van groep CWA1, deze opdracht uitgevoerd. De uiteindelijke algemene impressie is op zijn minst positief. Het harde werk resulteert tenslotte in een werkend programma met meer dan voldoende functionaliteit. Op de demodag waren de reacties op het programma geïnteresseerd en positief. Natuurlijk zijn er, achteraf bekeken, bedenkingen te formuleren. Deze zijn echter beperkt waardoor we met nog meer voldoening kunnen besluiten dat dit project, in de ogen van het hele team, geslaagd is.

20

10 Appendix

10.1 BrainStorm

10.2 Domeinmodel

21

22

10.3 Overzicht Use Cases

23

10.4 Programma-Architectuur

24

25

10.5 View-Layer

26

27

28

29

10.6 Controller-Layer

30

31

10.7 Model-Layer

TransactionManagerVerantwoordelijkheid: Transacties afhandelen.

TransactionBevat een lijst van TransactionItems, een totaalprijs, een User die de transactie opstelt en een datum.

TransactionItemStelt een Merchandise met een bepaalde hoeveelheid voor.

MerchandiseBevat een lijst met MerchandiseItems, een prijs en een naam.

MerchandiseItemStelt een Product met een bepaalde hoeveelheid voor.

ProductStelt een (basis)product voor zoals het in de stock zit.

ProductManagementVerantwoordelijkheid: Communicatie met database via een StockDAO en ProductDAO: Stock aanpassen, alle beschikbare instanties van Product bijhouden en aanpassen.

MerchandiseManagerVerantwoordelijkheid: Communicatie met de database via een MerchandiseDAO: Alle beschikbare instanties van Merchandise bijhouden en aanpassen.

TillManagerVerantwoordelijkheid: Bijhouden van kassa-inhoudverschillen met behulp van communicatie met de database via een TillDAO.

TillStelt de kassa voor. Bevat informatie over de kassa-inhoud en de datum.

32

PaymentTypeStelt een betaaleenheid voor.

PriceCalculatorVerantwoordelijkheid: Prijzen berekenen.

DefaultPriceCalculatorVerantwoordelijkheid: Op basis van een PaymentType een PriceStrategy de opdracht geven de prijs van een transactie te bepalen.* Implementatie van PriceCalculator. Bevat een lijst met links tussen PaymentTypes en PriceStrategies.

PriceStrategyVerantwoordelijkheid: Pijzen berekenen van een transactie.

StupidRulePriceStrategyVerantwoordelijkheid: Pijzen berekenen van een transactie op basis van vooraf ingestelde acties.*Implementatie van PriceStrategy.

Hanteert volgend algorithme om de ‘optimale’ prijs te bepalen:Berekent de totale prijs van een transactie zonder acties.Slechts één actie is toepasbaar (acties zijn niet cumuleerbaar). De actie die wordt toegepast is de eerste die in de lijst van beschikbare acties staat.Gaat alle rules af in de actie en laat deze ‘inwerken’ op de transactie:Is de rule toepasbaar?Zo ja, pas de totaalprijs van de transactie aan en verwijder de Merchandises die deze rule gebruikt heeft. (De Merchandises worden niet uit de oorspronkelijke transactie verwijderd, maar uit een lijst, specifiek aangemaakt om rules op in te laten werken, die deze transactie voorstelt.)Vervolgens wordt de totaalprijs van de transactie gereturned.

CouponRulePriceStrategyVerantwoordelijkheid: Prijzen berekenen van een transactie op basis van vooraf ingestelde acties, in coupon-waarde.*Implementatie van PriceStrategy. Werkt hetzelfde als StupidRulePriceStrategy, behalve dat de prijs die gereturned wordt naar boven (geheel) afgerond wordt. Omwille van het verschil op conceptueel vlak, zijn StupidRulePriceStrategy en CouponRulePriceStrategy twee verschillende strategies.

ActionBevat een lijst van Rules. Bevat een start- en einddatum die weergeven wanneer deze actie actief is.

ActionDAOVerantwoordelijkheid: Communicatie tussen een (lokale) database en klassen die info nodig hebben over lopende acties (hier: StupidRulePriceSytrategy en CouponRulePriceStrategy).

ActionRuleVerantwoordelijkheid: Inwerken op een (kopie van) een transactie. Afhankelijk van de implementatie gebeurt dit inwerken op verschillende manieren.

BuyXGetYRuleLaat toe om te bepalen dat er bij het kopen van een gekozen aantal van Merchandise type X een gekozen aantal van Merchandise type Y niet in de totaalprijs van de transactie verrekend word.PercentRuleLaat toe om de totaalprijs van een transactie te verminderen met een vast percent van de totaalprijs.ChangeMerchandisePriceRuleLaat toe om van een gekozen Merchandise een andere prijs dan de standaardprijs te hanteren in het berekenen van de totaalprijs van een transactie.

33

ProductManagementVerantwoordelijkheid: Communicatie met de database via een StockDAO en ProductDAO: Stock aanpassen, alle beschikbare instanties van Product bijhouden en aanpassen.

StockItemStelt een Product met een bepaalde hoeveelheid voor.

ProductStelt een (basis)product voor zoals het in de stock zit.

TypeStelt het Product-type voor. De verschillende mogelijkheden zijn Soda, Beer, Liquor en Food.

UserManagerVerantwoordelijkheid: Beheren van Users (aanmaken, verwijderen, aanpassen, …)

UserBevat een userName, firstName, lastName, passWord en function.

UserFunctionStelt de functie van een gebruiker voor. De verschillende mogelijkheden zijn administrator, stockmanager, boekhouder en

34

10.8 DataBase

35

36

37

Tabel DeltaStock Tabel DeltaCashVeld Type Veld Typeid int id int

date date date date

time time time time

prodtype_id int delta decimal

delta decimal

costPrice decimal

Tabel Merchandise Tabel MerchandiseItemVeld Type Veld Typeid int id int

name text prod_id int

price decimal quantityPerProduct decimal

activated enum(true, false) merchandiseId int

Tabel Stock Tabel ProductVeld Type Veld Typeid int id int

date date productName text

time time type enum(SODA, BEER, LIQUOR, FOOD)prodtype_id int quantityPerProduct decimal

amount decimal activated enum(true, false)

costPrice decimal

Tabel Transaction Tabel TransactionItemVeld Type Veld Typeid int id int

date date merch_id int

time time amount int

price decimal transactionId int

user_id int

Tabel User Tabel TillVeld Type Veld Typeid int id int

userName text date date

passWord text time time

function enum(BARTENDER, BOOKY, ADMIN,

content decimal

firstName text

lastName text

activated enum(true, false)

Tabel 1: De tabel geeft een overzicht van de databasestructuur.

38

10.9 Gannt-Chart & Tijdsbesteding van de eerste vier weken

39