FACULTEIT INGENIEURSWETENSCHAPPEN
P R OB L E E M O P LO SSE N E N O NT WE R P E N , D EE L 3
CWA1 Geert Claeys Wesley Cotteleer Vincent De Bruyne An Geets Kristof Helsen Ulrik Hoornaert
Universitair Harmonisch Orkest TUSSENTIJDS VERSLAG
Co-titularis Prof. E.Duval Begeleider(s) Yves Frederix Nelis Boucke
AC A D E M I E J A A R
2 0 0 7 - 2 0 0 8
Probleemstelling: voorstelling van het project 1 Doel? Het Universitair Harmonieorkest (UHO) geeft jaarlijks enkele concerten in de Pieter De Somer aula. Het doel van deze opdracht is het efficiënt verkopen van tickets voor deze concerten via een internetapplicatie. Er bestaat al een besteltoepassing, maar deze toepassing heeft een aantal beperkingen, vooral op administratief vlak, en is allesbehalve uitbreidbaar. Het is de bedoeling een nieuw systeem te ontwerpen waarmee de kaartenverkoop gemakkelijk en overzichtelijk verwerkt kan worden. Ook de uitbreidbaarheid (bvb. Concerten op andere data, of in een andere zaal) is hierbij belangrijk. Er zal software ontwikkeld worden voor het bestellen van kaarten, het beheren van de kaartenverkoop en het controleren van de kaarten aan de ingang. Concreet zal vooral het beheer van de toepassing verbeterd worden. Er zal gezorgd worden dat het wijzigen van een bestelling makkelijker kan gebeuren, zonder dat dit te veel werk meebrengt voor de beheerder.
2 Voor wie? Iedereen zal gebruik moeten kunnen maken van de webtoepassing. Ook het systeem dat aan de kassa gebruikt wordt, moet voor iedereen bruikbaar zijn. De toepassing die de beheerder gebruikt, mag iets ingewikkelder zijn, maar moet nog steeds voor zichzelf spreken. De toepassingen zullen gewoon in het nederlands gemaakt worden, met eventueel uitbreidbaarheid naar andere talen.
3 Randvoorwaarden? Enkele zaken die het systeem ook zeker zal moeten kunnen doen, zijn: • • • • • •
• • • •
het onderscheid maken tussen VIPtickets en gewone tickets, en zorgen dat alleen de gewone tickets bestelbaar zijn via de besteltoepassing aanduiden op een plannetje welke plaatsen nog vrij zijn, zodat de klanten zelf hun plaats kunnen kiezen het mogelijk maken van een wijziging in de bestelling of een ticket annuleren een onderscheid maken tussen verschillende prijscategoriën (studenten, bejaarden,...) zorgen dat klanten kunnen kiezen tussen geld storten op bankrekening of aan kassa betalen wanneer de klant kiest voor een overschrijving, een tijdslimiet bijhouden voor de betaling. Wanneer de betaling niet tijdig gebeurt krijgt de klant een aanmaning tot betaling en wordt het ticket uiteindelijk terug vrijgegeven voor andere klanten. barcode afdrukken op tickets voor controle aan de ingang zorgen dat de klanten kunnen kiezen tussen de tickets zelf afdrukken, of laten klaarleggen aan de kassa. eigen account overzichtelijk weergeven, zodat de klant gemakkelijk kan zien welke tickets hij in het verleden gekocht heeft. zorgen dat er statistieken bijgehouden worden in verband met de eigen account en in verband met de bestellingen in het algemeen
Ontwerp 1 Gebruikte technologieën Voor er kan begonnen worden met het ontwerpen van de applicatie, is het noodzakelijk dat er eerst kan gewerkt worden met de programma's en technologieën die nodig zullen zijn om de nieuwe applicatie te ontwerpen. Het gaat hier over volgende programma's en technologieën: 1. GWT GWT verstrekt een in JavaGebaseerde ontwikkelomgeving die u toelaat de toepassingen te bouwen in de taal Java. Het kapselt het XMLHttpRequest object API in, en minimaliseert de dwars browserkwesties. Zo kan men toepassingen snel en efficiënt bouwen zonder zich het ongerust te houden over het aanpassen van uw code aan diverse browsers. Het staat u toe de Standaard Widget (SWT) of Swing stijl programmering te verstrekken. Dit is een goede manier om productiviteit te verbeteren en tijd te besparen aan de hand van de kennis van de programmeertaal Java en de vertrouwdheid met het op gebeurtenisgebaseerde GUI. 2. Eclipse Het gebruikte programma om onze webapplicatie te implementeren. 3. Sub Subversion is een programma voor onder andere software en projectontwikkelaars waarmee beheer en versiecontrole over data en broncode kan worden uitgevoerd. 4. MySQL MySQL is een open source relationele database management systeem (RDBMS), dat gebruik maakt van SQL. MySQL werd vroeger vooral gebruikt voor toepassingen zoals fora en gastenboeken, meestal in combinatie met PHP, tegenwoordig is het de basis van een breed scala aan internettoepassingen, maar ook standalone software. Het MySQLsoftwarepakket bestaat onder meer uit een serverprogramma, doorgaans mysqld genoemd. Hierbij staat de d voor daemon, de Unix of Linuxterm voor een proces dat netwerkconnecties aanneemt.
Verder bestaat het uit een verzameling clientprogramma 's, zoals mysql en mysqldump waarmee automatisch of interactief met de server gecommuniceerd kan worden. MySQL is een populair databasemanagementsysteem dat voor het gestructureerd opslaan van gegevens voor zeer veel toepassingen wordt gebruikt. Voorbeelden van websites die gebruikmaken van MySQL zijn de sites van Wikipedia, de vrije encyclopedie. Een bekend MySQLfronted is phpMyAdmin, een webgebaseerd MySQLadministratieprogramma geschreven in PHP. 5. Barbeque: Barbeque is een Java bibliotheek waarmee barcodes kunnen gegenereerd worden. Deze bibliotheek maakt gebruikt van de methode createCode128A uit de klasse BarcodeFactory. Deze methode kan alle
cijfers, letters( hoofdletters en kleine letters) en alle andere standaard ASCII tekens omvormen tot een barcode. Het concrete Javaprogramma dat in de UHOtoepassing zal gebruikt worden, maakt gebruikt van barbecue, en slaat de barcodes die op deze manier gegenereerd worden automatisch op in een bestand.
2 Use Cases Om een bestelapplicatie te ontwerpen is het ook belangrijk dat er wordt nagegaan welke zaken de applicatie allemaal moet kunnen. Daarom werd er bij het ontwerp eerst begonnen met het opstellen van use cases. Hierin wordt uitgelegd welke acties het systeem onderneemt bij verschillende gebeurtenissen. Er wordt meer bepaald beschreven welke interacties wanneer worden uitgevoerd en tussen welke zaken deze interacties gebruiken. Men noemt deze zaken die deelnemen aan de interacties, de actors. 1.Account maken GOAL: Account aanmaken waarin gegevens van klant worden opgeslagen. Deze account wordt op de server geplaatst ACTORS: Klant PRIMARY FLOW: 1.Klant kiest voor registreren 2.Systeem geeft formulier weer waar een aantal gegevens moeten op ingevuld worden 3.Klant vult deze gegevens in 4.Systeem controleert op bestaan (bestaat er al een klant met deze naam, adres, gebruiksnaam;zijn alle noodzakelijke gegevens ingevuld) 5.a)indien controle gefaald Terug naar stap 2 b)indien controle geslaagd Systeem geeft de gegevens nog een keer weer en vraagt klant om bevestiging 6.Klant klikt op bevestigen 7.Systeem geeft weer dat de account aangemaakt is met gebruiksnaam en wachtwoord 8.Systeem slaat gegevens op op de server 9. Systeem stuurt mail naar klant met bevestiging van registratie, gebruikersnaam en paswoord 2.Inloggen GOAL: Gegevens van klant ophalen in database zodat deze kunnen gebruikt worden bij de verdere acties van de klant ACTORS: Klant PRIMARY FLOW: 1. Klant geeft gebruikersnaam en paswoord in
2. a) gebruikersnaam bestaat en komt overeen met paswoord Systeem zoekt klant op in database en laadt de gegevens van de gebruiker b)gebruikersnaam bestaat niet Terug naar stap 1 met foutmelding c)gebruikersnaam komt niet overeen met paswoord Terug naar stap 1 met foutmelding 3.Ticket bestellen GOAL: Tickets bestellen voor een voorstelling ACTORS: Klant PRIMARY FLOW: 1.Use Case 2: Klant logt in 2.Klant bestelt tickets 3.Systeem geeft mogelijke data van concerten 4.Klant kiest datum 5.Systeem geeft prijsklassen 6.Klant duidt aan hoeveel tickets hij wil per prijsklasse 7.Systeem geeft een plannetje met de mogelijke plaatsen 8.Klant maakt keuze en bevestigt 9.Systeem berekent de prijs 10.Systeem duidt de keuze aan op het plannetje en geeft de prijs weer en vraagt bevestiging voor plaatskeuze en prijs 11.Klant bevestigt nogmaals of wijzigt de tickets 12.a) bij bevestigen Systeem geeft keuzescherm betaling b) bij wijzigen terug naar stap 4 13.Klant kiest manier van betaling 14.Systeem vraagt bevestiging 15.Systeem voegt ticket toe aan lijst van onbetaalde tickets, met vervaldatum voor betaling. Bij tickets die aan de kassa klaarliggen en daar betaald worden, staat die vervaldatum op de datum van het concert. 16.Aan het ticket wordt een barcode toegekend die gegenereerd wordt met de gegevens van het ticket 17.Systeem stuurt mail naar klant met daarin de gegevens van de bestelde tickets (nog niet de eigenlijke tickets) en een bevestiging van de bestelling
4.Ticket annuleren/wijzigen GOAL: Tickets die reeds gekocht zijn wijzigen of annuleren, alleen wannneer tickets nog niet betaald werden ACTORS: Klant PRIMARY FLOW: 1.Klant logt in 2.Systeem levert persoonlijk scherm 3.Klant klikt op “tickets wijzigen” 4.Systeem toont oorspronkelijke keuze op plannetje 5.Klant kan plaatsen wegklikken of bij aanklikken en klikt op OK 6.Systeem annuleert vorige bestelling 7.Systeem gaat naar use case 3, stap 8 5.Profiel wijzigen GOAL: De gegevens van een klant wijzigen ACTORS: Klant PRIMARY FLOW: 1.Klant logt in 2.Klant klikt op profiel wijzigen 3.Gegevens van klant worden weergegeven zodat deze gewijzigd kunnen worden 4.Klant wijzigt deze gegevens 5.Systeem gaat naar use case 1, stap 4 6.Betaling bevestigen GOAL: Ontvangen betalingen ingeven in het systeem, zodat de klant het ticket krijgt ( gebeurt alleen indien de klant het ticket niet aan de kassa wil afhalen) ACTORS: Beheerder PRIMARY FLOW: 1.Use case 2: Beheerder logt in 2.Beheerder opent het programma om betalingen in te geven 3.Beheerder duidt aan welke klanten betaald hebben 4.Ticket wordt verplaatst van lijst met verkochte tickets naar lijst met betaalde tickets. 5.Barcode wordt op een lijst geplaatst van barcodes waarmee men kan binnengaan in de zaal 6.Systeem verstuurt automatisch een mail naar klant met daarin een document met de barcode
7.Onbetaalde tickets vrijgeven GOAL: Tickets die niet betaald werden terug vrijgeven ACTORS: Beheerder PRIMARY FLOW: 1.Systeem houdt bij wanneer de tickets ten laatste betaald moeten worden 2.Wanneer deze tijdspanne verlopen is (of 5,10,.. dagen erna, om zeker te zijn), worden de tckets op een andere lijst geplaatst, en worden verwijdert uit de lijst met verkochte tickets. 3.Systeem vraagt aan de beheerder of de tickets op de lijst van onbetaalde tickets vrijgegeven mogen worden. Het kan zijn dat dit niet mag gebeuren omdat beheerder achterstaat met betalingen,... 4.Beheerder klikt op tickets vrijgeven. 5.Tickets die niet betaald werden, staan terug op de lijst met onverkochte tickets. 8. Tickets afhalen aan kassa GOAL:gereserveerde tickets afhalen aan de kassa ACTORS:Beheerder & Klant PRIMARY FLOW: 1.Beheerder print tickets af die aan kassa afgehaald worden. Beheerder voegt de barcodes van deze tickets toe aan de lijst van geldige barcodes 2. Klant haalt tickets af aan kassa a)onbetaalde tickets worden nog betaald b)Betaalde tickets worden gewoon afgehaald 9. Onverkochte tickets verkopen aan kassa GOAL:onverkochte tickets blanco verkopen aan kassa ACTORS:Beheerder & Klant & Medewerker PRIMARY FLOW: 1.Beheerder print lijst met onverkochte tickets en legt deze aan kassa Beheerder voegt de barcodes van deze tickets toe aan de lijst van geldige barcodes 2.Klant vraagt kaart(en) en betaalt 3.Medewerker geeft kaart met barcode 10. Controleren van barcode GOAL:Controleren of klant met zijn ticket binnen mag in de zaal ACTORS:Klant PRIMARY FLOW: 1.Klant scant ticket in aan barcodescanner
2.Systeem vergelijkt barcode op ticket met lijst van toegestane tickets a) Ticket staat op lijst Klant mag zaal binnen gaan b) Ticket staat niet op lijst Klant wordt geweigerd 11. Nieuw concert toevoegen GOAL:Nieuwe concerten toevoegen aan de concertagenda ACTORS:Beheerder PRIMARY FLOW: 1.Use Case 2: Beheerder logt in 2.Beheerder geeft in op welke datum en in welke zaal het nieuwe concert plaatsvindt 3.Systeem voegt concert toe aan concertagenda 12. Aanpassen zaalplan GOAL:VIPplaatsen veranderen in gewone plaatsen en visa versa ACTORS:Beheerder PRIMARY FLOW: 1. Use Case 2: Beheerder logt in 2. Beheerder vraagt zaalplan op aan systeem 3. Systeem geeft zaalplan 4. Beheerder wijzigt het zaalplan en slaat dit op 13.Statistieken opvragen voor beheerder GOAL: Inzicht krijgen in het koopgedrag van de klanten ACTORS:Beheerder PRIMARY FLOW: 1.Use Case 2: Beheerder logt in 2.Beheerder vraagt statistieken op 3. Systeem geeft statistieken weer 14.Statistieken opvragen voor klant GOAL: Bekijken welke tickets de klant in het verleden heeft gekocht ACTORS:Klant PRIMARY FLOW:
1.Use Case 2: Klant logt in 2.Klant vraagt statistieken op 3.Systeem geeft statistieken weer
3 Alternatieven Op hoog niveau was er geen alternatief mogelijk, aangezien de te gebruiken technologieën aangereikt werden. Dit verschaft ons het voordeel dat er strak en goed aan het project kan gewerkt worden. Het nadeel is dat de eigen keuze in opbouw van de applicatie wegvalt. Natuurlijk is er de volledige vrijheid binnen het implementeren, maar dit is niet echt van toepassing bij de ontwerpalternatieven aangezien de gebruikte methodes in de interface meer 'vanzelfsprekend' zijn. De onderlinge componenten moeten met elkaar interageren. Een ander voordeel is ook dat er concreet geleerd wordt met een hoop zaken te werken. Leken in informatica die aan deze opdracht zouden beginnen, zouden in een ondoordringbaar net van mogelijkheden terechtkomen en er slechts met begeleiding uit geraken.
4 Interface Interface die aangeboden wordt door de server naar de client toe Account
User logIn(String userName, String password) •
Preconditie:
beide velden ingevuld •
return User if logIn geslaagd, else do nothing (Userobject bevat alle informatie over account en kunnen vanaf dan gebruikt worden)
User createAccount(User user) •
Preconditie:
alle usergegevens (check database) zitten in het Userobject •
Postconditie:
als gebruikersnaam (= emailadres) uniek is krijg je een nieuwe account, anders gebeurt er niets nieuwe rij in database wordt aangemaakt. •
return User if createAccount goed doorlopen is (Userobject bevat alle informatie over account
en kunnen vanaf dan gebruikt worden) changeAccount(User user) •
Preconditie
ingelogd •
Postconditie
de velden worden aangepast in het Userobject, waarop het volledige Userobject wordt doorgestuurd naar de database, waar het overschreven wordt newAdmin(IDaccount idaccount) •
Preconditie
idaccount bestaat •
Postconditie
Als de user die deze methode oproept geen admin is, gebeurt er niets. Anders wordt er in de database de boolean Beheerder op true gezet.
1 Ticket Array getConcerts() •
Preconditie
•
Return Array met data van de concerten.
/ Concert getConcert(IDconcert idconcert) •
Preconditie
idconcert bestaat •
return Concert if getConcert goed doorlopen is, else do nothing
reserveTicket(coordChair) •
Preconditie
stoel moet bestaan •
Postconditie
als stoel al gereserveerd is: er gebeurt niets
stoel wordt toegevoegd in database deleteTickets(Array idtickets) •
Preconditie
bestaande tickets •
Postconditie
gereserveerd in de Ticketdatabase wordt op false gezet insertPayment(Array idtickets) •
Preconditie
tickets bestaan •
Postconditie
Status ticket: betaald (aanpassing in database > wordt true) Als de user die deze methode oproept geen admin is, gebeurt er niets
2 Concert createConcert(Concert concert) •
Postconditie
Als de user die deze methode oproept geen admin is, gebeurt er niets. in database wordt een nieuwe rij gemaakt. Deze bevat de alle informatie van het concert (check database) tickets voor het concert worden gegenereerd makeTheatre(Theatre theatre) •
Postconditie
Als de user die deze methode oproept geen admin is, gebeurt er niets. er wordt een nieuwe tabel gemaakt in de database met de juiste dimensie van de zaal. Als de naam van de tabel al bestaat gebeurt er niets. deleteConcert(IDconcert idconcert) •
Preconditie
concert bestaat •
Postconditie
heel de rij, die gelinkt is aan de idconcert, wordt uit de database verwijderd tickets van dit concert worden uit de tickettabel van de database verwijderd.
Als de user die deze methode oproept geen admin is, gebeurt er niets.
Interface die aangeboden wordt door de database naar de server toe
1 Account User getUser(String userName) •
Postconditie
gegevens van de user worden omgezet in Userobject •
return User if userName bestaat, else do nothing
User createAccount(User user) •
Preconditie:
alle usergegevens (check database) zitten in het Userobject •
Postconditie:
als gebruikersnaam (= emailadres) uniek is krijg je een nieuwe account, anders gebeurt er niets een nieuw account = gegevens uit Userobject omgezet naar array die dan in tabel gezet wordt in een nieuwe rij. •
return User if createAccount goed doorlopen is
changeAccount(User user) •
Postconditie
Userobject omgezet naar array die in tabel de vorige gegevens overschrijft Boolean checkAdmin(IDuser iduser) •
Preconditie
iduser bestaat (ingelogd) •
return
true: if admin false: no admin setNewAdmin(IDaccount idaccount) •
Preconditie
idaccount bestaat •
Postconditie
Als de user die deze methode oproept geen admin is(checkAdmin), gebeurt er niets. de boolean Beheerder wordt op true gezet.
2 Ticket Array getConcerts() •
Postconditie
gegevens van alle concerten uit tabel worden omgezet in array •
Return Array met data van de concerten.
Concert getConcert(IDconcert idconcert) •
Preconditie
idconcert bestaat •
Postconditie
gegevens worden uit de informatie van de tickets gehaald en omgezet in een Concertobject ( in de tabel met alle tickets gaan we kijken welke tickets reeds gereserveerd zijn of voorbehouden en welke niet) •
return Concert if getConcert goed doorlopen is, else do nothing
reserveTicket(coordChair) •
Preconditie
stoel moet bestaan •
Postconditie
het veld gereserveerd van het ticket, dat gelinkt is aan de stoel, wordt op true gezet deleteTickets(Array idtickets) •
Preconditie
bestaande tickets •
Postconditie
gereserveerd in de Ticketdatabase wordt op false gezet insertPayment(Array idtickets) •
Preconditie
tickets bestaan
•
Postconditie
Status ticket: betaald (aanpassing in database > wordt true) Als de user die deze methode oproept geen admin is (checkAdmin), gebeurt er niets
3 Concert createConcert(Concert concert) •
Postconditie
Als de user die deze methode oproept geen admin is (checkAdmin), gebeurt er niets. Concertobject wordt omgezet naar array die dan in een nieuwe rij van de tabel wordt gezet. In de ticketstabel wordt voor het concert alle tickets gegenereerd makeTheatre(Theatre theatre) •
Postconditie
Als de user die deze methode oproept geen admin is (checkAdmin), gebeurt er niets. er wordt een nieuwe tabel gemaakt in de database met de juiste dimensie van de zaal. Als de naam van de tabel al bestaat gebeurt er niets. deleteConcert(IDconcert idconcert) •
Preconditie
concert bestaat •
Postconditie
heel de rij, die gelinkt is aan de idconcert, wordt uit de database verwijderd tickets van dit concert worden uit de tickettabel van de database verwijderd. Als de user die deze methode oproept geen admin is, gebeurt er niets.
5 Componentendiagram
Voorstel voor verdere uitwerking 1 Toekomstplannen In overleg met de rest van het team zal er gelijktijdig aan meerdere componenten tegelijk gewerkt worden. De globale implementatie zal aan het begin van de zitting bepaald en uitgewerkt worden. Om duidelijk bij de zaak te blijven, zijn hieronder de doelstellingen vastgelegd die op het einde van elke zitting behaald moeten zijn. Het spreekt voor zich dat deze planning voorbarig is en hoogstwaarschijnlijk nog stevig zal veranderen, maar hier ligt dan toch al een houvast die de vorderingen steunt. GUI: wordt van in het begin aan gewerkt, vermoedelijke duur: week 710 Client, server, database en interface wordt gedurende de weken altijd samen geimplementeerd om concrete zaken te verwerken week 78: acties Client:
account aanmaken inloggen tickets bestellen(inclusief GUI map, mailsysteem) tickets wijzigen en annuleren
week 910: acties Administrator:
concert aanmaken(gegevens, prijsklassen, indeling zaal,...) betalingen regelen aanmaken admin aanpassen van zaal plan blancotickets, afprinten lijst aandekassaafhaal tickets,...
week 911:
barcode generator
week 1112: presentatie en verslag voorbereiden
Vakintegratie Bij dit project wordt er vooral gewerkt met de leerstof uit het vak “methodiek van de informatica”, aangezien er bij dit project een toepassing in Java moet geschreven worden. Er wordt gebruik gemaakt van de codes die in de lessen aan bod zijn gekomen, en van andere codes, die opgezocht worden in bibliotheken op internet. Ook dit opzoeken is is aan bod gekomen tijdens de lessen van informatica.
Demodag Na het lezen van de richtlijnen van de demodag is ons duidelijk geworden dat we bijna alles voorhanden hebben. Ons programma functioneert op een server van Computer Wetenschappen en een 'simpele' internet aansluiting is genoeg om onze presentatie te houden. Toch zou het een groot voordeel zijn mocht er ook een barcode scanner voorhanden zijn en een printer op de presentatie dag. Dit zou veel kunnen bijdragen bij een praktische demonstratie. Dit is aan de andere kant wel tijdrovend en aangezien onze presentatie slechts enkele (5) minuten mag duren, is het misschien minder praktisch haalbaar.
Bronnen http://tweakers.net/meuktracker/15657/Subversion1.4.4.html http://www.eecho.info/Echo/ajax/gwtajaxintroductie/
