Kassa automatisering

Transcriptie

1 Kassa automatisering van Robin Speijer ( ) CMI-Opleiding Technische Informatica Hogeschool Rotterdam 10 januari 2012 Eerste docent Tweede docent Dhr. M. Abd El Ghany Dhr. A. van der Padt

2 Samenvatting De samenvatting is leeg en zal geschreven worden wanneer het hoofdverslag klaar is. ii

3 Inhoudsopgave Samenvatting ii Inleiding 2 De kassa Innovatie Analyse 3 Huidige situatie Probleembeschrijving Tablet Prototypes 4 Kassasysteem Betalingssysteem Communicatie Technisch ontwerp 6 Kassasysteem Gebruikersapplicatie Serverapplicatie Dataflow Implementatie 11 Servergedeelte Push notifications iphone applicatie Testen en Exploitatie 13 Conclusies en aanbevelingen 14 iii

4 Bronnen 15 Evaluatie 16 A Serverdatabase 17 1

5 Inleiding De laatste tijd is er een duidelijke trend op te merken in het gebruik van computers. Tabletcomputers zijn steeds meer in trek en worden steeds krachtiger. Ze zijn te besturen met een aanraakscherm en zijn makkelijk mee te nemen. Ze lijken relatief veel op smartphones, maar hebben een groter scherm omdat het gebruiksdoel verschilt. De kassa Wanneer er gekeken wordt naar de technische eisen van het systeem achter de kassa, is al snel te concluderen dat smartphones en tablets mogelijk als kassa gebruikt kunnen worden. Qua prijs verschilt deze apparatuur aanzienlijk in vergelijking met de huidige kassasystemen. Prijzen van kassa s met een aanraakscherm kosten op moment van schrijven rond de e3.000 euro, waar bijvoorbeeld een ipad 1 al te krijgen is vanaf e479. Innovatie De kassa heeft in de afgelopen jaren betrekkelijk weinig innovatie gekend de afgelopen maanden, als we kijken naar de smartphone, tablet of andere apparaten die op de een of andere manier te maken hebben met internet. Dit onderzoek zal zich richten op de volgende vraag: Hoe kan de traditionele kassa interactief gemaakt worden door innovatief gebruik te maken van de hedendaagse technologieën en trends? 1 Een van de meest populaire tablet computers op moment van schrijven 2

6 Analyse Huidige situatie Momenteel worden veel kassa s verkocht als offline apparaten die de gebruiker in staat stelt om producten op te geven die aangekocht worden, en hierbij de totaalprijs te geven en een bon te printen. Hierbij moet de betaling tussen de kassagebruiker en de klant handmatig geregeld worden met behulp van bijvoorbeeld contant geld of een pinterminal. De kassa houdt alle verkochte producten bij zodat men aan het einde van de dag een bon uit kan printen met de totale omzet van die dag. Probleembeschrijving De problemen waarvoor een oplossing gemaakt zal worden zijn: Het betalen van artikelen kan veel eenvoudiger en neemt nog te veel stappen in beslag. De gebruikerservaring van de kassa is te wensen over te laten. Meestal is een handleiding nodig om deze te programmeren. De prijzen kan kassa s zijn erg duur. De kassa is zwaar en log. Het verplaatsen van deze apparaten is lastig. Als we kijken naar de problemen van de huidige kassasystemen, hebben we met een eventuele tablet als kassa de prijzen en mobiliteit sterk verbeterd. Ook de gebruikerservaring zal hoogstwaarschijnlijk veel beter zijn dan met de huidige kassasystemen, aangezien de grafische prestaties veel beter zijn (er kunnen zelfs 3D games op gespeeld worden). Het enige wat nog rest is het proces van betalen. Tablet Tegenwoordig zijn mobiele apps populair. Tablets die gebruikt kunnen worden zijn veel goedkoper, terwijl ze beschikken over veel betere prestaties op grafisch gebied. Aan de hand hiervan is te concluderen dat mooie grafische interfaces makkelijk(er) te maken zijn dan met de huidige systemen. Het is mogelijk om een kassasysteem te maken zonder handleiding, net als vele andere apps die verkrijgbaar zijn. 3

7 Prototypes Er zijn verschillende implementaties waarbij de beschreven problemen op te lossen zijn. In dit hoofdstuk behandel ik alle mogelijke oplossingen voor de verschillende facetten die komen kijken bij het systeem. Uiteindelijk worden de oplossingen met elkaar vergeleken en wordt een oplossing geïmplementeerd. Dit gemaakte prototype wordt uiteindelijk geëvalueerd aan de hand van de andere prototypen vanwege tijdsdruk. Kassasysteem Het bedrijf Moop.me ( is bezig met kassasoftware voor de ipad. Bij gebruikerstesten blijkt het dat gebruikers van de software geen handleiding nodig hebben om deze te besturen, en dat ze het zelfs leuk vinden om met deze software om te gaan. De software is altijd verbonden met het internet, en het beschikt over de mogelijkheid om uitbreidingen via een camera toe te staan voor code tags. Omdat ik een goede band met het bedrijf Moop.me heb, spreekt het voor de hand met hen een samenwerking aan te gaan voor hun kassasysteem. Ze geven toestemming om voort te boorduren op de code die zij tot nu toe geschreven hebben. Ook bieden ze de mogelijkheid aan om naar het design te kijken van de applicaties die ik eventueel ga ontwerpen. Betalingssysteem Een mogelijkheid van online betalen kan een online portemonnee zijn. Dit heeft enige voor- en nadelen. Het grootste voordeel is het gebruiksgemak: de gebruiker hoeft zich geen zorgen meer te maken over het betaalproces. Munten hoeven niet meer uitgeteld te worden, de pincode hoeft niet meer te worden ingevoerd, en de gebruiker heeft verder niets meer nodig dan alleen zijn smartphone. Nadelen zijn er zeker ook: de data staat bijvoorbeeld centraal opgeslagen, waardoor het eventueel kwetsbaar kan zijn voor storingen of kwaadwillige gebruikers. Hier dient bij een eventuele implementatie dan ook rekening mee gehouden te worden, om de risico s zo veel mogelijk te vermijden. Naast een online portemonnee, kan een andere manier van betalen ook een offline variant zijn van een elektronische portemonnee. Dit zou eventueel via RFID kunnen werken, maar ook via bar- of QR codes. Aangezien de laatste twee mogelijkheden niet te wijzigen zijn bij het maken van een transactie (de code kan niet veranderd worden op de pas), moet in dit geval een lokale database bijgehouden worden met alle informatie die bij de codes hoort. 4

8 Om het meest dynamische betalingssysteem te bouwen, is het makkelijk om voor een centrale opslag te kiezen van data. Aan de hand van SSL encryptie is de communicatie met deze opslag versleuteld, waardoor misbruik zeer lastig wordt gemaakt. Er dient voor de centrale opslag van een portemonnee een identificatiemethode te zijn die het verschil maakt tussen de verschillende portemonnees. De Facebook API is een goede methode om deze identificatiemethode te bieden. Als prototype wordt dus in eerste instantie een server ingericht op het juist afhandelen van transactie via een SSL versleutelde verbinding. De mogelijkheid bestaat voor gebruikers om deze portemonnee van buitenaf op te laden via bijvoorbeeld PayPal. Communicatie De gebruiker heeft het recht om ten alle tijde het saldo op te vragen van zijn digitale portemonnee. Ook moet de gebruiker ten alle tijde transacties kunnen plaatsen in de winkel. Een mogelijkheid om dit te bieden is via een mobiele applicatie. Deze applicatie kan communiceren met de digitale portemonnee om zo het saldo en transacties ten alle tijden te kunnen inzien. Omdat de smartphone beschikt over een GPS chip, is het mogelijk om te detecteren of de gebruiker in de winkel aanwezig is, en dit te tonen in het kassasysteem van Moop.me. Dit zorgt voor de koppelingslaag van de kassa naar de gebruiker toe. Zo kan via het kassasysteem afgerekend worden met de digitale portemonnee van de klant die aanwezig is. Om te controleren of een bepaalde transactie wel echt bij de rekening in kwestie hoort, zijn twee mogelijkheden. Het personeel kan namelijk de Facebook foto controleren van de persoon of deze wel lijkt, maar de andere mogelijkheid is dat de gebruiker een bevestiging moet geven bij het plaatsen van een transactie. Met name de laatste oplossing is het meest waterdicht. Gebruikers die niet over een (goede) smartphone beschikken, hebben met de eerste oplossing geen toegang tot hen digitale portemonnee. Een andere oplossing zou kunnen zijn dat iedere klant een klantenkaart met een QR code hierop uitgereikt krijgt. Aan de hand van de code, kan de digitale portemonnee online geïdentificeerd worden. Transacties kunnen aan de hand van de klantenkaart gemaakt worden, en gegevens kunnen voor de kaart online worden ingezien aan de hand van de code van deze QR code. Ook is er een mogelijkheid om via het internet het saldo op te laden van de klantenkaart, omdat het centraal beheerd wordt. Beide oplossingen hebben zo zijn voor- en nadelen. Het voordeel van de eerste oplossing is met name de bereikbaarheid en automatisering. Het voordeel van de tweede oplossing is in de compatibiliteit. Iedereen kan gebruik maken van deze mogelijkheid. Een tussenoplossing is om ze beide te implementeren, maar in het kader van het project de eerste oplossing een hogere prioriteit te geven. Wanneer dit mee blijkt te vallen, kan deze voor de volledigheid uitgebreid worden met de tweede oplossing. 5

9 Technisch ontwerp Kassasysteem Het kassasysteem heeft voor het prototype de volgende eisen: Het systeem draait op een tablet met het ios operating system versie 5.0 of hoger Het systeem heeft de beschikking over het opnemen van een database met te verkopen artikelen De software kan gebruikt worden door een gebruiker om orders mee te plaatsen en hier bonnen mee te maken De software laat de bezoekers zien met de gebruikersapplicatie die zich fysiek in de buurt van de winkel bevinden De software stelt de gebruiker in staat af te kunnen rekenen via de digitale portemonnee van de klant met behulp van de locatieservice Hierbij wordt gebruik gemaakt van het technische design van Moop.me. Er dient een plugin te worden gemaakt die een lijst kan ophalen van de server met gebruikers in de buurt, en een mechanisme om af te rekenen met de gebruikers. Gebruikersapplicatie De gebruikersapplicatie heeft in feite de volgende eisen: De applicatie draait op een iphone met een ios operating system versie 5.0 of hoger Het identificeren van de gebruiker en dit te communiceren met de server Het up-to-date houden van een database met winkellocaties De gebruiker in de gaten houden of deze in de buurt is van een winkel. Als dat het geval is, moet dit doorgegen worden naar de server. Het kunnen inkijken van de inhoud van de digitale portemonnee Het kunnen accepteren of weigeren van transacties die geplaatst worden 6

10 Het prototype wordt voor de iphone ontwikkeld in de taal Objective-C. Hierbij wordt gebruik gemaakt van het klassediagram in figuur 1. Hierbij moet ook rekening gehouden met de taal Objective-C. Een voorbeeldfunctie in deze taal ziet er als volgt uit: ( void ) d o e I e t s M e t B e h u l p V a n V a r i a b e l e : ( NSString ) s t r i n g W a a r d e 1 e n M e t V a r i a b e l e : ( NSString ) s t r i n g W a a r d e 2 ; Figuur 1: Klassediagram iphone applicatie Serverapplicatie Omdat het in het volledige systeem om zeer gevoelige data als een betaalmiddel gaat, dient de beveiling zeer goed te zijn. In eerste instantie was het plan om een samenwerking aan te gaan met het bedrijf Intersolve, welke een samenwerking heeft met het bedrijf Moop.Me (maker van het kassa ipad systeem). Vanwege de beperkte tijdsplanning is gekozen om hier vanaf te zien en het betalingssysteem via een eigen server te lopen. Het is zeker niet de bedoeling om dit als productieomgeving te gebruiken. De eisen van de serverapplicatie zijn als volgt: De server moet per identiteit een saldo en een transactieoverzicht bijhouden 7

11 Alle communicatie moet via een SSL versleutelde verbinding lopen De communicatie met de applicaties verloopt via JSON pakketten De server moet op een juiste manier transacties kunnen verwerken De server houdt een connectie met de Apple Push Notification Service, om zo nodig gebruikersapplicaties te vragen om bevestiging bij een transactie Dataflow Voor het implementeren van de prototypes, is een eerste opzet van de dataflow benodigd. In figuur 2 is het algemene beeld te zien van alle onderlinge systeementiteiten. In figuur 3 is de onderlinge communicatie in detail uitgelicht. Figuur 2: Structuur van systeemonderdelen 8

12 9

13 Figuur 3: Communicatie tussen systeemonderdelen 10

14 Implementatie In dit hoofdstuk wordt de implementatie besproken van de prototypes die behandeld zijn in het vorige hoofdstuk. Servergedeelte Op de server wordt alle data verzameld over de klanten en winkels. In het eerste prototype wordt dit voor het gemak gedaan met een MySQL database. Een dump van de database is te vinden in bijlage A. Er zijn verschillende manieren van omgaan met een backend voor de serverapplicatie. Ik heb gekozen om een VPS te gebruiken met een Debian installatie, omdat dit toevallig al voor handen was. Er zijn verschillende manieren van formaten in dataoverdracht. Zo is er bijvoorbeeld het formaat XML, maar de JavaScript Object Notation (JSON) is de laatste tijd ook populair, omdat dit minder data kost door de compacte opzet. Ook zijn er veel meer ingebouwde conversietools beschikbaar van en naar JSON binnen talen als bijvoorbeeld PHP en Objective-C. Vanwege deze redenen, heb ik gekozen om het JSON bestandsformaat te kiezen. Push notifications Zoals in figuur 3 te zien is, moet de systeem server pakketten naar de kassa software en mobiele app versturen zonder dat er vanaf deze twee systemen een verbinding opgezet is. Dit betekent dat er een constante verbinding tussen beide componenten moet worden gelegd, of dat er poorten open gezet moeten worden om een verbinding te leggen tussen de systemen. Ook kan er gebruik gemaakt worden van het Apple Remote Notification systeem, waarbij het apparaat een verbinding houdt met de Apple service en alle notification via deze verbinding binnen krijgt. Wanneer de systeemserver een bericht naar een van deze apparaten wilt versturen, moet het een SSL verbinding met de Apple service opzetten en dit bericht wederom in JSON versturen. Gezien de betrouwbaarheid, beveiliging en ondersteuning heb ik ervoor gekozen om in dit project voorlopig gebruik te maken van deze APNS service van Apple. In de toekomst kan er wellicht zelf een protocol worden gecreëerd die gecommuniceerd kan worden met de serverapplicatie. iphone applicatie De gebruikersapplicatie wordt in eerste instantie alleen voor de iphone ontwikkeld. Dit gebeurt in de Objective-C taal, met Xcode als IDE, dat is namelijk de enige manier om iphone applicaties 11

15 in elkaar te zetten. Voorbeelden van frameworks zijn UIKit voor de gebruikersinterface, Foundation voor de basiselementen, CoreLocation voor locatievoorzieningen, CoreData voor de lokale database opslag en MapKit. De gebruikersinterface kan makkelijk in elkaar gesleept worden. 12

16 Testen en Exploitatie 13

17 Conclusies en aanbevelingen Conclusies en aanbevelingen moeten verzameld worden in een apart en herkenbaar deel van het verslag. Hoewel in het hoofdverslag op diverse plaatsen conclusies getrokken kunnen worden, moeten de belangrijkste conclusies samengevoegd en samengevat worden. Belangrijk is dat het verschil tussen objectief controleerbare conclusies en subjectieve aanbevelingen duidelijk wordt aangegeven. Ook is het aan te bevelen om de belangrijkste conclusies conform de opdrachtomschrijving te formuleren. 14

18 Bronnen [1] Lamport L.: LATEX: A Document Preparation System, Addison-Wesley, 1994 [2] Oostrum van P.: Handleiding LATEX, Vakgroep Informatica, Universiteit Utrecht, 1998, [3] Wikibooks LATEX: 15

19 Evaluatie In de evaluatie reflecteer je over je eigen afstudeerproces. Daarbij moet je vooral letten op de leereffecten. Welke competenties had je nodig? Welke competenties kwam je tekort en moest je zelf verwerven? Waren dit algemene of specifieke competenties? Voldeden de beroepscompetenties aan de standaard van het HBO-I (analyseren, adviseren, ontwerpen, realiseren en beheren)? Vielen de algemene competenties in de vijf categorieën van de Dublin Descriptoren 2 zoals het verkrijgen van kennis en inzicht, het toepassen van kennis en inzicht, het maken van onderbouwde keuzen (oordeelsvorming), het communiceren (schriftelijk en mondeling) en het verkrijgen van leervaardigheden? 2 Dublin Descriptoren zijn eisen aan de competenties voor de bachelor en master studies aan universiteiten en hogescholen in Europa. 16

20 Bijlage A Serverdatabase Tabel A.1: Structuur van de tabel account Kolom Type Null Standaardwaarde id bigint(20) Nee clientuuid varchar(255) Nee balance double Nee Tabel A.2: Structuur van de tabel account Kolom Type Null Standaardwaarde id bigint(20) Nee clientuuid varchar(255) Nee balance double Nee Tabel A.3: Structuur van de tabel checkin Kolom Type Null Standaardwaarde client varchar(255) Nee store bigint(20) Nee checkin varchar(255) Nee startdate datetime Ja NULL Tabel A.4: Structuur van de tabel checkin Kolom Type Null Standaardwaarde client varchar(255) Nee store bigint(20) Nee checkin varchar(255) Nee startdate datetime Ja NULL 17

21 Tabel A.5: Structuur van de tabel client Kolom Type Null Standaardwaarde uuid varchar(255) Nee system varchar(255) Ja NULL facebookid varchar(255) Ja NULL Tabel A.6: Structuur van de tabel client Kolom Type Null Standaardwaarde uuid varchar(255) Nee system varchar(255) Ja NULL facebookid varchar(255) Ja NULL Tabel A.7: Structuur van de tabel store Kolom Type Null Standaardwaarde id bigint(20) Nee title varchar(255) Nee subtitle varchar(255) Nee latitude double Nee longitude double Nee ispublic tinyint(1) Nee address varchar(255) Ja NULL zip varchar(6) Ja NULL city varchar(255) Ja NULL Tabel A.8: Structuur van de tabel store Kolom Type Null Standaardwaarde id bigint(20) Nee title varchar(255) Nee subtitle varchar(255) Nee latitude double Nee longitude double Nee ispublic tinyint(1) Nee address varchar(255) Ja NULL zip varchar(6) Ja NULL city varchar(255) Ja NULL Tabel A.9: Structuur van de tabel transaction Kolom Type Null Standaardwaarde id bigint(20) Nee account bigint(20) Nee 18

22 Tabel A.9: Structuur van de tabel transaction (vervolgd) Kolom Type Null Standaardwaarde balance double Nee title varchar(255) Ja NULL date datetime Nee Tabel A.10: Structuur van de tabel transaction Kolom Type Null Standaardwaarde id bigint(20) Nee account bigint(20) Nee balance double Nee title varchar(255) Ja NULL date datetime Nee 19