SUPER-SAX - EINDRAPPORT

23 januari 2009

SAXION HOGESCHOLEN ENSCHEDE

SUPER-SAX - EINDRAPPORT

Alexander Game Mark Geurtsen Patrick Slamp Jeroen van Tongeren Sjoerd van der Vis Heiko Ye

| Een winkelbeheersysteem | EIN1g | | Opdrachtgever: H.B. Beverdam |

Voorwoord De afgelopen vier weken zijn wij allen druk geweest voor onze projectgroep. 4 weken lang werd er gewerkt aan een winkelbeheersysteem; een systeem waar nog flink wat haken en ogen aan zaten. Dingen als BTW, voorraadbeheer en loginsystemen kwamen voorbij. Ook was het nog niet eenvoudig te bedenken hoe we nu gingen testen of alle geschreven code ook daadwerkelijk functioneel was. Uiteindelijk zijn al deze vragen, mede dankzij de goede hulp van onze projectbegeleider Ruud Greven, opgelost en is hier het uiteindelijke product uitgekomen, evenals het eindrapport dat voor u ligt. Wij zijn allen zeer trots op het eindresultaat en hopen dat u dit ook bent.

Inhoudsopgave

Voorwoord .......................................................................................................................................... 2 Inhoudsopgave .................................................................................................................................... 3 Eindrapport.............................................................................................................................................. 4 Inleiding ............................................................................................................................................... 4 Uitwerking van het project, aanpak en resultaten.............................................................................. 5 Opstarten project ........................................................................................................................ 5 Beschikbaarheid code.................................................................................................................. 5 Conclusie en aanbevelingen ................................................................................................................ 6 Nawoord .............................................................................................................................................. 6 Bijlage I: Testrapport ............................................................................................................................... 7 Sprint 0: ............................................................................................................................................... 8 Sprint 1: ............................................................................................................................................. 10 Sprint 2: ............................................................................................................................................. 14 Sprint 3: ............................................................................................................................................. 15 Bijlage II: Implementatierapport ........................................................................................................... 17 Werken in een team .......................................................................................................................... 17 Diepere blik in de code ...................................................................................................................... 17 Meest voorkomende fouten ............................................................................................................. 18 Bijlage III: Ontwerprapport.................................................................................................................... 19 Bijlagen: UML 09-01-2009; ............................................................................................................... 21 UML 16-01-2009; .............................................................................................................................. 22 UML 22 – 01 -2009 ............................................................................................................................ 23

Eindrapport Inleiding 4 weken geleden werden wij gevraagd door de opdrachtgever om een winkelbeheersysteem te ontwikkelen, waarmee relatief eenvoudig de voorraden van een winkel beheerd kunnen worden. Hierin moest worden opgenomen welke artikelen voorradig waren, welke besteld dienden te worden, producten moesten kunnen worden afgerekend en er moest worden gekeken welke producten nagevuld dienden te worden. Met deze boodschap kwam de opdrachtgever onze kant op. Nadat deze opdracht was geanalyseerd, werd bij de opdrachtgever nagegaan wat de verwachtingen van dit systeem waren. De doelstelling voor onze projectgroep werd vastgesteld; dit was het ontwikkelen van de door de opdrachtgever aangeleverde userstories binnen 4 weken. Op 26 november begonnen wij met 4 weken lang iedere woensdag de software te ontwikkelen. Hierna begon voor ons team de kerstvakantie; even een rustperiode waarna we weer verder gingen met de ontwikkelingen op maandag 5 januari. Vanaf deze dag werd 3 weken lang fulltime gewerkt aan het project. Alle functionaliteiten worden besproken in het testrapport, hierin wordt ook duidelijk of er nog bepaalde functies niet werkend zijn. In het implementatierapport wordt beschreven hoe we er voor gezorgd hebben dat de opmaak constant was; ook is hierin te lezen wat de kritieke punten in het project waren betreffende de implementatie en eventuele tekortkomingen vanuit Java. In het ontwerprapport wordt beschreven hoe we tot het ontwerp gekomen zijn en hoe dit is veranderd in de loop van het project. Hierbij worden ook overzichtschema’s gepresenteerd met daarin het verband tussen verschillende onderdelen van de software.

Uitwerking van het project, aanpak en resultaten Opstarten project Bij het beginnen van het project werd eerst vastgesteld wie welke rol had binnen de groep. Mark en Heiko zouden zorgen voor de planning; Patrick werd aangesteld als archivaris en Sjoerd is gedurende de projectweken de S4S1-Master. We hebben de afgelopen weken een aantal maal gebruik gemaakt van “pair programming”; het programmeren met z’n tweeën achter één systeem. Voordelen hiervan zijn dat twee mensen meer zien dan één; nadeel echter hiervan is dat de snelheid waarmee functionaliteiten worden geprogrammeerd achteruit loopt. Iedere ochtend werd een standup-meeting gehouden waarbij werd bekeken wat een ieder uit de groep de vorige dag had gedaan en van plan was diezelfde dag te gaan doen. Per week werd bijgehouden hoeveel storypoints hiervoor beschikbaar waren. In een burndown chart werd iedere dag weggestreept hoeveel punten hiervan waren voltooid op de desbetreffende dag. Ook werd een poster bijgehouden met alle userstories op post-it briefjes geschreven. Hierop was te zien welke userstories waren afgerond, welke nog niet aan iemand waren toegewezen en waar de projectgroep mee bezig was. Met al deze maatregelen hebben we gepoogd overzicht te houden over nog af te ronden userstories en de activiteiten die al voltooid waren. In het begin van het project was dit nog erg wennen. De standup-meeting en de burndown chart zijn geen hulpmiddelen die je dagelijks gebruikt, evenals de poster. Hoe langer je er echter gebruik van maakt, hoe meer je er het voordeel van in gaat zien. Zeker de poster was zeer handig; je ziet meteen welke userstories al verdeeld zijn en welke je kunt gaan ontwikkelen. Beschikbaarheid code Om er voor te zorgen dat iedereen constant de beschikking heeft over alle broncode, is een Google Code project aangemaakt. Zo konden 2 mensen tegelijk aan hetzelfde bestand werken, zonder dat dit veel problemen gaf. Het enige nadeel hieraan was dat het enige tijd heeft gekost voordat iedereen door had hoe dit werkte en het ingesteld had; deze ‘verloren tijd’ is echter snel weer terug gewonnen door het gebruik van deze server. Door al deze (interactieve) methoden te gebruiken kon het overzicht behouden worden en konden alle groepsleden beschikken over de code wanneer dit nodig was. Dit heeft geleid tot een eindproduct dat functioneert volgens de gestelde userstories.

Conclusie en aanbevelingen Gedurende dit project hebben wij als projectgroep veel geleerd betreffende programmeren en het werken in een groep. Ook hebben wij gebruik gemaakt van mechanismen om het groepswerk te vereenvoudigen, dingen die wij later weer zullen gebruiken bij volgende projecten of over een aantal jaren in het bedrijfsleven. “Pair Programming” is iets wat voordelen heeft, maar ook wel degelijk nadelen. Wat wij merkten tijdens het project is dat er veel wordt aangedrongen om pair programming toe te passen. Een aanbeveling t.o.v. de opleiding is om studenten hier iets meer de vrijheid in te geven; laat iedereen alles proberen en dan de beste keuze maken.

Nawoord De afgelopen vier weken hebben voor ons in het teken gestaan van voorraden, BTW-percentages, kassabonnen en inlogsystemen. Ook hebben ze in het teken gestaan van samenwerking, standupmeetingen en interactieve werkomgevingen. Hier hebben wij allen veel van geleerd, dingen die wij in latere projecten of het bedrijfsleven zeker weer zullen gebruiken. Absolute pluspunten waren: +

De samenwerking binnen de groep. Deze was goed en op de momenten dat we samen werkten aan het project was iedereen hard aan het werk en beschikbaar om elkaar te helpen.

+

De beschikbaarheid van de code. Door het gebruik van de SVN-server had iedereen constant de beschikking over de code waardoor niet constant de code samengevoegd hoefde te worden.

+

Regelmatig contact met docenten. Doordat er regelmatig contact was met de projectbegeleider konden we op tijd worden bijgestuurd indien er fouten gemaakt werden en wisten wij dus waar wij aan toe waren.

Minpunten van het project waren: -

-

-

De communicatie binnen de groep. Dit betrof vooral communicatie over aanwezigheid en de communicatie naar Alexander toe. Omdat Alexander in Duitsland woont was hij soms niet bereikbaar om vragen te stellen. Meer concrete afspraken hadden de communicatie verbeterd. Deadline-werk. Af en toe waren we maar net op tijd klaar met onze opdrachten voor de deadline. Dit gaf de nodige stress; als we hier wat beter mee om waren gegaan hadden we iets meer rust gehad vlak voor deadlines. Documentatie. Binnen de geprogrammeerde code ontbrak voor de laatste week eigenlijk bijna alle documentatie. Deze hadden we beter bij moeten houden tijdens het programmeren. Gelukkig hebben we in de laatste week hier wat reparatiewerk voor kunnen uitvoeren.

Bijlage I: Testrapport In dit testrapport worden alle userstories bekeken en wordt er gekeken of deze allemaal werkzaam zijn. Voor dit testrapport zullen wij gebruik maken van een volgend schema: Beschrijving userstory: Wat moet het doen: Hoe testen we dit: Wat doet het: Oplossing (eventueel):

Eerst wordt de naam en beschrijving van de userstory genoteerd. Daarna wordt beschreven wat de userstory moet kunnen. Hoe dit getest wordt volgt hierna, waarna de verwachte uitvoer wordt gegeven. Dit kan uitvoer op het scherm zijn, maar ook een reactie van een andere methode op de gegeven invoer. De daadwerkelijke output wordt gegeven in de laatste regel. Per sprint zijn op de volgende pagina’s de userstories + de testcases gegeven.

Sprint 0: Beschrijving

:

Het toevoegen/wijzigen van een artikel

Wat moet het doen

:

Artikelen toevoegen aan de productenlijst. Hierbij moet een naam, inkoopprijs, verkoopprijs, BTW-percentage en een minimaal beschikbare voorraad worden opgegeven. Ook een productgroep wordt gekozen.

Hoe testen we dit

:

Artikelen toevoegen, kijken of er iets gebeurd met leegruimten, tekst in plaats van getallen, wijzigen van de naam, inkoopprijs, verkoopprijs en productgroep.

Wat doet het

:

Aan de hand van hierboven beschreven eisen blijkt dat deze userstory naar behoren werkt.

Uitkomst testcase

:

Goed gekeurd.

Beschrijving

:

Artikelen opzoeken op beginletter / ID

Wat moet het doen

:

Artikelen moeten kunnen worden opgezocht op een artikel-ID en op (een aantal) beginletter(s). Wanneer op ID gezocht wordt worden direct de productdetails laten zien; indien op beginletters wordt gezocht worden alle bijbehorende producten met hun ID in een lijstje laten zien en kan daarna een ID gekozen worden waarvan de productdetails worden laten zien.

Hoe testen we dit

:

Artikelen in de database toevoegen; 2 artikelen met dezelfde beginletter. Indien we bijvoorbeeld Brinta en Brood toevoegen, krijgen we dan 2 producten te zien als we zoeken op Br? Wat gebeurt er bij een niet-bestaand ID? Terugkeren naar hoofdmenu, nogmaals zoeken? Kunnen we vanuit een lijst met producten de details opvragen?

Wat doet het

:

Volgens bovenstaande criteria is getest. De tests werden goed uitgevoerd, geen problemen tegengekomen.

Uitkomst testcase

:

Goed gekeurd.

√

√

Beschrijving

:

Productinformatie raadplegen via ID

Wat moet het doen

:

Deze userstory is eigenlijk een vervolg op de vorige; wanneer een product-ID bekend is worden de gegevens(inkoopprijs, verkoopprijs, BTW, productgroep van dit product op het scherm gezet.

Hoe testen we dit

:

Artikelen in de database toevoegen; gegevens van een willekeurig artikel raadplegen; een niet bestaand artikel-ID invoeren; een negatief artikel-ID of tekst invoeren.

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

Beschrijving

:

Als magazijnmedewerker wil ik artikelen kunnen toevoegen aan de voorraad (door zoeken op beginletters)

Wat moet het doen

:

Via deze methode kan (virtueel) besteld worden. Een leverancier komt artikelen brengen en deze worden zo toegevoegd aan de voorraad.Het zoeken op beginletters gaat via het zelfde systeem als bij de vorige 2 userstories; is dus al goed getest.

Hoe testen we dit

:

Als eerste wordt bij deze userstory een product gezocht welke moet worden toegevoegd aan de voorraad. Naderhand kan worden ingevoerd hoeveel stuks van dit product worden toegevoegd. Hier kan getest worden of dit lukt, negatieve hoeveelheid, letters etc.

Wat doet het

:

Volgens bovenstaande criteria is getest. Problemen ontstonden echter bij een negatieve levering; indien een negatief getal werd ingevoerd als leveringsaantal werd dit gewoon veranderd (bijvoorbeeld -10 flessen cola).

Oplossing

:

Een beveiliging inbouwen tegen negatieve getallen; dit is direct gedaan en nu is alles correct.

Uitkomst testcase

:

Goed gekeurd.

√

√

Beschrijving

:

Als magazijnmedewerker wil ik een mededeling krijgen als de voorraad leeg of bijna leeg is.

Wat moet het doen

:

Onder het hoofdmenu moeten alle kritieke producten getoond worden. Hier is dan direct te zien of er een product is dat bijna niet meer voorradig is. Eventueel kan hier later de mogelijkheid van een verlopen houdbaarheidsdatum aan toe worden gevoegd.

Hoe testen we dit

:

Artikelen in de database invoeren maar nog geen voorraad laten hebben. Werkt dit? Komen deze in het overzicht terecht? Komen producten met een lager aantal dan de minimale voorraad hierin terecht?

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√

Sprint 1: Beschrijving userstory :

Als caissière wil ik een artikel kunnen in scannen d.m.v. een id. Daar hoort bij bon, datum + afrekenen.

Wat moet het doen

:

Doormiddel van een ID een product kunnen in scannen en aan de hand van de ingescande producten moet een bon worden opgesteld. Ook moet erop de bon ook de datum van de afrekening staan.

Hoe testen we dit

:

We testen dit door een aantal producten in te scannen. En vervolgens van de gescande producten een bon afdrukken met de datum van afrekening. Ook wordt er getest voor enige oneffenheden in de programmatuur zoals negatieve invoer en niet bestaande artikelen.

Wat doet het

:

Aan het hierboven genoemde punt(Hoe testen we dit) hebben we gekeken of we aan de userstory voldaan hebben. Uit deze test is gebleken dat deze userstory naar behoren werkt.

Uitkomst testcase

:

Goed gekeurd.

√

Beschrijving userstory :

Van magazijn naar winkel

Wat moet het doen

:

Bij deze userstory moet het mogelijk zijn om producten uit het magazijn te halen en in de winkel te stoppen.

Hoe testen we dit

:

We testen dit door een aantal producten door te verplaatsen van het magazijn naar de winkel. Ook wordt er getest voor enige oneffenheden in de programmatuur zoals een niet bestaand product verplaatsen van magazijn naar winkel en het verplaatsen van een product waar geen producten meer van zijn in het magazijn

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√


Uitbreiding class Product: uitbreiding houdbaarheidsdatum

Wat moet het doen

:

Een houdbaarheiddatum moet meegegeven worden bij het aanmaken van een product.

Hoe testen we dit

:

We testen dit door een een aantal producten aan te maken en daarvan de houdbaarheidsdatum van op te vragen . Ook wordt er getest voor enige oneffenheden in de programmatuur zoals het niet mogelijk is om de houdbaarheidsdatum toe te kennen aan het product.

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√


Als caissière wil ik een foutmelding krijgen als een product niet bekend is in het systeem

Wat moet het doen

:

Als we een product willen inscannen en als de kassiere een bon wil printen en het product bestaat niet moet er een passende foutmelding bij komen dat het product niet bekend is.

Hoe testen we dit

:

We testen dit door een een aantal producten in te scannen en op een bon te zetten. Ook wordt er getest voor enige oneffenheden in de programmatuur zoals je niet bestaande producten invoert.

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√


Als magazijn medewerker wil ik een bestel lijst kunnen afdrukken aan de hand van de voorraad

Wat moet het doen

:

Een bestel lijst afdrukken aan de van de voorraad. En als er een hoog genoeg aantal van dat product in de voorraad staat komt die er niet bij te staan.

Hoe testen we dit

:

We testen dit door een een aantal producten op te zoeken en daarvan de voorraad aan te passen zodat de producten bij de bestellijst verschijnen en visa versa.

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√


Houdbaarheidsmelding 3 dagen van te voren melden en deze melding zelf kunnen aanpassen (4 dagen, 5 dagen etc.).

Wat moet het doen

:

Een melding van kritieke producten die wordt weergegeven in het menu van de vakkenvuller waarin hij precies kan zien wat er besteld moet worden, wat over datum is en wanneer de winkel bijgevuld moet worden.

Hoe testen we dit

:

We testen dit door producten te wijzigen in houdbaarheidsdatum en het aantaldagen voordat de melding zich laat zien aan te passen en vervolgens te kijken of het product word laten zien in de melding. Als dit na behoren werkt is deze userstory afgerond.

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√


Class kassiere (omzet per caissière)

Wat moet het doen

:

De kassiere class heeft als doel dat er een kassiere achter de kassa staat en dat daarvan de omzet van berekend word, zodat te zien is hoeveel ze verkocht heeft.

Hoe testen we dit

:

We testen dit door een aantal kassieres aanmaken en daar dan de omzet van opvragen en een kassiere toevoegen aan de “Kassa”.

Wat doet het

:


Uitkomst testcase

:

Goed gekeurd.

√

Sprint 2: Beschrijving

:

Als magazijn medewerker wil ik de artikelen kunnen opdelen in productgroepen (vleeswaren/groente etc.) Artikelen moeten in een productgroep opgedeeld worden, de productgroepen worden uit een enum gehaald. Kijken of het juiste artikel toegekend is aan de juiste productgroep. Productgroepen met kleine letters en/of hoofdletter invoeren. Productgroep invullen dat niet in de enum zit. Aan de hand van hierboven beschreven eisen blijkt dat deze userstory naar behoren werkt.

Wat moet het doen

:

Hoe testen we dit

:

Wat doet het

:

Uitkomst testcase

:

Goed gekeurd.

Beschrijving

:

Wat moet het doen

:

Hoe testen we dit

:

Wat doet het

:

Als klant wil ik bepaalde producten kunnen wegen of een prijs per kilo hebben. Bij bepaalde productgroepen, zoals vlees en groente moet er gevraagd worden naar het gewicht. Een product wegen dat geen gewicht heeft, maar op aantal bepaald wordt. Afronding van getallen. Werkt zoals verwacht.

Uitkomst testcase

:

Goed gekeurd.

Beschrijving

:

Als manager wil ik de omzet kunnen berekenen.

Wat moet het doen Hoe testen we dit

: :

Wat doet het

:

De totale omzet van de winkel teruggeven. Kijken of het bedrag overeenkomt met het totaal van het omzet van Alle caissières Werkt zoals verwacht.

Uitkomst testcase

:

Goed gekeurd.

Beschrijving

:

Wat moet het doen Hoe testen we dit

: :

Wat doet het

:

Als magazijn medewerker wil ik artikelen uit de winkel de voorraad halen als het artikel over de houdbaarheidsdatum is. Artikelen kunnen verwijderen als het over de houdbaarheidsdatum is. Kijken in de winkelvoorraad of het artikel verwijdert is, nadat je het artikel uit de winkelvoorraad hebt gehaald. Er moet een bepaald aantal producten uit de voorraad worden gehaald. Werkt correct.

Uitkomst testcase

:

Goed gekeurd.

√

√

√

√

Beschrijving

:

Als magazijn medewerker wil ik artikelen uit de winkel de voorraad halen.

Wat moet het doen

:

Hoe testen we dit

:

Wat doet het

:

Artikelen uit de database verwijderen om welke reden dan ook, bijv. dat het niet meer verkocht wordt. Kijken of het product nog bestaat, nadat we het artikel uit de database hebben gehaald. Goed Gekeurd.

Uitkomst testcase

:

Is goed.

Beschrijving Wat moet het doen Hoe testen we dit

: : :

Wat doet het

:

Een inlogscherm voor manager / caissière / klant. Voor elke gebruiker wanneer deze inlogt, na het juiste menu gaan. Proberen in te loggen als manager of caissière en kijken of we het juiste menu krijgen. Brengt ons naar het juiste menu.

Uitkomst testcase

:

Akkoord!

Beschrijving Wat moet het doen Hoe testen we dit Wat doet het

: : : :

Lege flessenautomaat, niet meer in caissière menu. Lege flessenautomaat moet weg uit het caissière menu. Caissière menu openen. Kijken of het lege flessenautomaat weg is. Lege flessenautomaat is niet meer te zien.

Uitkomst testcase

:

Akkoord!

Beschrijving Wat moet het doen

: :

Hoe testen we dit

:

Wat doet het

:

Wijzigen productgroep en de naam van het artikel. Wanneer de optie wijzig product wordt aangeroepen, moet deze ook de naam van het product en de productgroep hiervan kunnen veranderen. Optie aanroepen en nieuwe gegevens invullen. Vervolgens door het product op te zoeken kijken of de gegevens gewijzigd zijn. Verandert inderdaad de gegevens van het product.

Uitkomst testcase

:

Akkoord!


: : :

Wat doet het

:

Statiegeld apart op bon. Statiegeld apart weergeven op de bon. Een statiegeld bon maken. Deze toevoegen aan een andere bon. Bon uitprinten en kijken of statiegeld apart weergegeven staat. Zet statiegeld apart op de bon.

Uitkomst testcase

:

Akkoord!

√

Sprint 3:

√

√

√

√


: : :

Wat doet het

:

Dagtotalen omzet berekenen. Van elke dag apart de omzet kunnen berekenen. Dag aanpassen op de computer, een aantal producten afrekenen en kijken of het programma van die dag en van eerdere datums de juiste omzet berekent. Geeft terug de omzet.

Uitkomst testcase

:

Akkoord!


: :

Hoe testen we dit

:

Wat doet het

:

Verschillende soorten flessen kunnen inleveren. Bij het inleveren van flessen, vragen wat voor soort fles er ingeleverd wordt. Proberen verschillende flessen in te voeren, zoals bierflessen. Vervolgens op de statiegeld bon kijken om te kijken of deze zijn toegevoegd. Werkt.

Uitkomst testcase

:

Akkoord!


: : :

Wat doet het

:

BTW apart op bon weergeven. Op de bon, apart weergeven hoeveel BTW hier over betaald is. Bon printen en kijken of er BTW apart op staat en of dit bedrag correct is. Doet het goed.

Uitkomst testcase

:

Akkoord!


: :

Hoe testen we dit Wat doet het

: :

Een zoekscherm voor klant. Als je inlogt als klant (gebruikersnaam klant, wachtwoord klant), moet er een apart menu komen. Inloggen als klant en zien wat er gebeurt. We krijgen een menu waarin we producten kunnen opzoeken.

Uitkomst testcase

:

Akkoord!

√

√

√

√

Bijlage II: Implementatierapport Werken in een team Aan het in een team werken zitten natuurlijk voordelen en nadelen. Een voordeel is, is dat je hulp van anderen krijgt en niet alles alleen hoeft te doen. Ook als er iets niet duidelijk is heb je steun aan je teamgenoten, immers, twee koppen weten meer dan één. Een nadeel is dat iedereen zijn eigen ideeën heeft over bepaalde elementen en die kunnen nog wel eens botsen. Hier moeten uiteraard strakke regels voor worden opgesteld. Zo hebben wij met de groep besloten aan de codeer standaard te voldoen zoals deze staat beschreven in de ISO documenten. Er is niet één persoon aangewezen als kwaliteit waarborger maar wel hebben verschillende teamleden er voor gezorgd dat eventuele onvolkomenheden opgelost werden, en dat de code er strak en netjes uitzag. Ook is de code voorzien van opmerkingen om het nog overzichtelijker te maken. Als je met meerdere mensen werkt, is het mogelijk dat je met meerdere mensen aan hetzelfde werkt. De user-stories zijn altijd netjes verdeeld onder de groepsleden maar het is soms mogelijk dat je voor een bepaalde user-story het een en ander aan de structuur moet veranderen. Om dit probleem enigszins te vergemakkelijken is er altijd netjes overlegt voordat er iets groots om werd gezet. Ook hebben we met heel de groep gebruik gemaakt van bepaalde software (Subversion) die de veranderingen in een bepaald bestand automatisch doorvoerd. Op deze manier is het mogelijk om met meer dan één persoon aan een bepaald bestand te werken. Dit heeft het proces absoluut versneld.

Diepere blik in de code Aangezien het product een text-based applicatie is, is het niet mogelijk om te werken met een GUI (Graphical User Interface). Hierbij is de applicatie afhankelijk puur en alleen van invoer van de gebruiker, geen mouse-clicks zijn mogelijk. Dit bemoeilijkt het gebruik en limiteert de programmeer mogelijkheden. De gebruikte al aanwezige Java class Scanner, die deze invoer opvangt, is niet ideaal. Zo is deze gevoelig voor invoer met spaties en niet verwachte invoer. Als er bijvoorbeeld om een getal (Integer) gevraagd word en er word een niet getal ingevoerd krijg je een foutmelding. Deze moet opgevangen worden door onze programmateur. Zo is het ook mogelijk om een negatief getal in te voeren, in sommige gevallen is dit wenselijk maar zeker niet altijd, ook hier moet goed op gelet worden bij het schrijven van de code.

In het begin hadden we hier grote moeite mee, maar na wat zorgvuldig testen van de mogelijkheden van de class Scanner hebben we een manier ontwikkeld om deze invoer goed op te vangen en te verwerken. Dit heeft hierna niet meer tot problemen geleid. Het opslaan van de informatie in een bestand bracht ook enige problemen met zich mee. Aanvankelijk leek dit een niet al te moeilijke opdracht te zijn maar omdat alle belangrijke informatie met bijbehorende structuur in zijn geheel word weggeschreven, en word opgebouwd bij het starten van het programma, bracht dit wat moeilijkheden met zich mee. Zo moet er niet een nieuwe instantie van de klasse Winkel aangemaakt worden maar moet het aangemaakte object, na het inlezen van het opgeslagen bestand, toegewezen worden aan de variabele winkel in de Apl klasse. Ook na het eenmaal opgelost te hebben van dit probleem bracht dit geen verdere moeilijkheden met zich mee, en kon in de onderliggende structuur verder gewerkt worden. Wel moest de database elke keer geleegd worden nadat er iets veranderd was in een opgeslagen klasse, omdat de opgeslagen objecten, met methodes en al, opgeslagen waren, en op die exact zelfde manier weer opgebouwd worden na het inlezen van de database. De veranderingen zijn uiteraard daarin nog niet doorgevoerd. Ook is er voor gezorgd dat wanneer de database geleegd word, er de minimale benodigdheden aangemaakt worden voor het functioneren van een programma. Dit zijn een admin account, om in te loggen, en de aanwezigheid van een “weegschaal”-, “flessen automaat”- en een “klant” account.

Meest voorkomende fouten

Bijlage III: Ontwerprapport In dit ontwerprapport zullen alle gemaakte UMLs nader worden toegelicht. Van de UML zullen alle relaties onder elkaar worden gezet en worden toegelicht. Klasse Winkel; Winkel heeft èèn of meerdere kassa(‘s); Winkel heeft maar èèn TUI(Textbased User Interface)(Scan); Winkel heeft èèn of meerdere werknemers; Winkel heeft èèn of meerdere kassiere(s); Winkel heeft èèn of meerdere product(en); Winkel heeft èèn of meerdere bon(nen); Winkel heeft maar èèn bestand voor de opslag van gegevens(LezenSchrijvenBestand); Winkel wordt èèn keer aangemaakt in de apl(start klasse); Klasse Scan(TUI(Textbased User Interface)); Scan heeft maar èèn winkel Scan heeft maar èèn datum Scan wordt èèn keer aangemaakt in de apl(start klasse); Klasse Werknemer; Werknemer kan een vakkenvuller zijn; Werknemer kan een manager zijn; Werknemer kan een klant zijn; Werknemer kan een kassiere zijn; Werknemer kan een weegschaal zijn; Werknemer kan een flessenautomaat zijn; Werknemer werkt bij een winkel; Klasse Product; Product kan een gewogenartikel zijn; Product kan een product met kilo’s (productprijsperkilo) zijn; Product kan een normaal product (productprijspervast) zijn; Product heeft maar èèn productgroep; Product word ingescand bij de kassa; Klasse Bon; Bon word gemaakt door de kassiere; Bon word opgeslagen in winkel; Bon kan een flessenbon zijn;

Vooruitgang De vooruitgang die we tijdens de sprints maken is goed terug te zien in de gemaakte UML’s, daarin is te zien dat er behoorlijk wat klasses bij zijn gekomen en dat de relaties ook steeds ingewikkelder werden naarmate de UML groeide. UML sprint 1(zie bijlage): In deze UML is zichtbaar dat een aantal klassen geimplementeerd zijn; deze klassen vormen echter alleen de basis. UML sprint 2: In deze UML is te zien dat er een aantal nieuwe klassen bij zijn gekomen. Verschil tussen deze UML en de UML van sprint 1 zijn: 

Kassa klasse is toegevoegd, om producten in te scannen;



Kassiere klasse is aangepast; deze klasse houdt de eigen totale omzet bij;



LezenSchrijvenBestand is toegevoegd, om de staat van de winkel weg te kunnen schrijven naar een bestand;



Productgroep enum is toegevoegd, zorgt voor een keuze uit productgroepen wanneer een nieuw product wordt toegevoegd.

UML sprint 3: In deze UML is er veel vooruitgang geboekt. Dat is vooral zichtbaar aan de hoeveelheid klassen die erbij zijn gekomen. Verschil tussen deze UML en de UML van sprint 2 zijn: 

Werknemer klasse is toegevoegd in verband met de overerving en voor het uit elkaar houden van verschillende rollen/functies;



Manager, vakkenvuller, klant, kassiere, flessenautomaat en weegschaal zijn toegevoegd/aangepast .



Gewogenartikel, productprijsperkilo en productprijsvast zijn toegevoegd en erven van de klasse product.



Bon klasse is toegevoegd.



Flessenbon klasse is toegevoegd, die is gemaakt om de klant de mogelijk te geven flessen in te leveren en hiervan het statiegeld retour te ontvangen bij de kassa.

Bijlagen: UML 09-01-2009,UML 16-01-2009,UML 22-01-2009

Bijlagen: UML 09-01-2009;

UML 16-01-2009;

UML 22 – 01 -2009

SUPER-SAX - EINDRAPPORT

Recommend Documents