Katrines Kælder Kasseapparat

Transkript

1 Katrines Kælder Kasseapparat Projektdokumentation Aarhus Universitet Gruppe 4-4. Semester - E15 Vejleder: Lars Mortensen Dato David Heilesen Danielewicz IKT Kalle Rønlev Møller IKT Kasper Sejer Kristensen IKT Kristian Mosegaard IKT Lærke Isabella Nørregård Hansen IKT Peter Ring Pedersen IKT

2 Indhold 1 Kravspecifikation Aktører Bartender Admin Nets MobilePay Swipp Use Cases Ikke fully dressed use cases Funktionelle Krav MoSCoW Interface System Arkitektur OverordnedeSekvensDiagrammer Overordnet sekvensdiagram for Use Case 1 Kontant salg Overordnet sekvensdiagram for Use Case 2 Udskriv kundebon Overordnet sekvensdiagram for Use Case 3 Kasseafstemning Domænemodel Accepttest Test setup Accepttests Ordliste 20 1 af 20

3 Kravspecifikation Revision Ændret af Version Dato Ændringer Alle Dokument oprettet Tabel 1.1: Revision for Kravspecifikation 1.1 Aktører I dette afsnit beskrives aktører og deres rolle i systemet. I figur 1.1 ses aktørdiagrammet, som beskriver alle aktører og deres forhold til systemet. Figur 1.1: Aktør-kontekst diagram 2 af 20

4 1.1.1 Bartender Aktørnavn Type: Beskrivelse: Bartender Primær Bartender er den primære bruger af systemet, og står for salg af varer Admin Aktørnavn Type: Beskrivelse: Admin Primær Administrator skal stå for logistikken (priser, varelager osv.) gennem systemet Nets Aktørnavn Type: Beskrivelse: Nets Sekundær Nets er leverandøren af betalingsterminalen. Betalingsløsningen er en af systemets primære betalingsløsninger MobilePay Aktørnavn Type: Beskrivelse: MobilePay Sekundær MobilePay er en betalingsløsning, som leveres af Danske Bank Swipp Aktørnavn Type: Beskrivelse: Swipp Sekundær Swipp er en betalingsløsning, som leveres af Nordea, Nykredit, Sydbank, Jyske Bank, Arbejdernes Landsbank, Spar Nord Bank og Lokale Pengeinstitutter. 3 af 20

5 1.2 Use Cases I dette afsnit ses de forskellige Use cases. På figur 1.2 vises et Use Case diagram over de fully-dressed Use Cases, som viser de Use Cases, som er i fokus. Figur 1.2: Use-case diagram for de fully dressed use-cases. På figur 1.3 vises et Use Case diagram over de ikke fully-dressed Use Cases, som ønskes implementeret på et senere tidspunkt. Figur 1.3: Use Case diagram for de ikke fully dressed use-cases. 4 af 20

6 Use Case 1 I denne Use Case ser vi hvordan et kontant salg bliver foretaget Kontant Salg Mål: Initieret af: Aktører: At sælge varer mod kontant betaling Bartender Bartender (Primær) Samtidige forekomster: 1 Prækondition: Postkondition: System skal være tændt og klar Et kontant salg er foretaget Hovedscenarie: 1. Bartender vælger varer på systemets varer knapper 2. Systemet opdaterer løbende den samlede pris [Extension 1.1: Bartender trykker på knappen der annullerer købet] 3. Bartender trykker Betalingsknappen 4. System viser Betalingssiden med total prisen [Extension 1.2: Bartender trykker på Tilbage knappen] 5. Bartender trykker Kontant knappen 6. Systemet viser hovedmenuen hvor total prisen fra salget stadig vises Udvidelser: 1. Extension 1.1: Bartender trykker på knappen der annullerer købet 1. Systemet sletter den samlede pris 2. Systemet går tilbage til hovedmenuen 2. Extension 1.2: Bartender trykker på Tilbage knappen 1. Systemet går tilbage til hovedmenuen 5 af 20

7 Use Case 2 I denne Use Case beskrives forløbet at udskrive en bon, hvis dette ønskes. Udskriv Kundebon Mål: Initieret af: Aktører: Systemet får udskrevet en bon af en tidligere transaktion Bartender Bartender (Primær) Samtidige forekomster: 1 Prækondition: Postkondition: Use Case 1: Kontant salg er gennemført Systemet udskriver bon af transaktionen Hovedscenarie: 1. Bartender trykker på knappen der åbner tidligere salg menuen 2. Systemet viser en menu med tidligere salg 3. Bartender trykker på bon knappen ud fra det salg der ønskes at udskrive bon for 4. Systemets printer udskriver bon [Extension 2.1: Der er ikke mere papir] Udvidelser: 1. Extension 2.1 Der er ikke mere papir 1. Systemets printer stopper. Dialogboks popper op med en besked om at skifte bon rulle. 2. Bartender skifter bon i printer. 3. Bartender trykker på OK knappen og use casen forsættes fra punkt 3 6 af 20

8 Use Case 3 Denne Use Case beskriver hvordan der udskrives afstemning af kassen forløber ved udprintning af bon med alt der er solgt i løbet af aftenen. Kasseafstemning Mål: Initieret af: Aktører: At Bartenderen har en bon med samlede salg og dato udskrevet Bartender Bartender (Primær) Samtidige forekomster: 1 Prækondition: Postkondition: System skal være tændt og klar At bonen med det samlede salg er udskrevet Hovedscenarie: 1. Bartender vælger Indstillinger knappen 2. System viser Indstillinger menu 3. Bartender trykker på Afstem knappen 4. System viser Afstem popup [Extension 3.1: Bartender trykker på tilbage knappen] 5. Bartender trykker på Godkend knappen 6. Systemets printer udskriver bonen [Extension 3.2: Der er ikke mere papir] 7. System viser Hovedmenuen 1. Extension 3.1: Bartender trykker på tilbage knappen 1. Systemet går tilbage til punkt 2 2. Extension 3.2: Der er ikke mere papir 1. Systemets printer stopper. Dialogboks popper op med en besked om at skifte bonrulle. 2. Bartender skifter bon i printer. 3. Bartenderen trykker på OK knappen og use casen forsættes fra punkt 4 7 af 20

9 1.3 Ikke fully dressed use cases Use Case 4 - Betalingskort Salg Skal beskrive forløbet for et salg når kasseapparatet interagerer med betalingsterminalen. Use Case 5 - Rabat Salg Her i beskrives forløbet for salg, hvor der opnåes rabat på alle udvalgte varer. Use Case 6 - Indtastning af lagervarer Til lagerstyrings delen af produktet skal der være mulighed for at indtaste varer i systemet når de ankommer/bestilles. Use Case 7 - Administrator login For at kunne ændre priser, oprette ny salgsvarer i kasseapperatet osv. skal der kunne logges ind på en administrationsdel af systemet således at kun Administratorer kan gøre dette. Use Case 8 - Fjern lagervarer Når der hentes varer på lageret skal disse kunne tjekkes ud af lager systemet. Use Case 9 - Tilføj varer til kasseapparat Det skal være muligt at tilføje en vare til kasseapparatet denne use case kræver at administrator login, use case 7, er udført. Use Case 10 - Rediger varer i kasseapparat Det skal være muligt at ændre en varepris og navn mm. denne use case kræver administrator login, use case 7, er udført. Use Case 11 - Fjern varer fra kasseapparat Det skal være muligt at fjerne varer fra systemet hvis de f.eks. ikke længere bliver serveret. Denne use case kræver at administrator login, use case 7, er udført. Use Case 12 - Vis Statistik over salg Der skal kunne genereres en statistik over de varer der er blevet solgt, gerne i detaljer der specifikt beskriver hvilke varer der er blevet solgt. Use Case 13 - Scan varer til lager Et apparat kan bruges til at scanne scanne varer ind i lagersystemet. 8 af 20

10 1.4 Funktionelle Krav MoSCoW MoSCoW metoden er blev brugt til at afgrænse produktet og identificere de vigtigste egenskaber. Det giver en opdeling således: Must have en GUI der kan betjenes med en touchskærm. interagere med betalingskort, systemet skal kunne sende en betaling til betalingsterminalen. have en printer der kan printe boner. have en kontantskuffe der kan åbnes via systemet. logge alt salg. have en backup af salgslog. Should tilføje nye varer til GUI. ændre priser på varer. fjerne varer. have mulighed for lagerstyring. have et administrator login til opsætning. Could have farvekode på forskellige varer. bruge MobilePay til at modtage betaling. bruge Swipp til at modtage betaling. have en statistik af solgte varer. have en stregkodescanner til brug ved lagerstyring. Won t have brugere til individuelle bartenderer. 9 af 20

11 1.5 Interface Interfacet som befinder sig på systemet, kan som udgangspunkt ligne skitsen som ses her på figur 1.4. Dette Interface skal befinde sig på en touchskærm. Figur 1.4: Skitse for Bruger interface på systemet - grupper For at give Bartenderen mulighed for at udføree en hurtig betjening, skal alle valg kunne tages på samme skærmbillede, dette er mulig under fanen grupper, som ses på figur 1.4. På skærmen kan bartenderen se en knap til hver vare, det kunne f.eks. være FAD for fadøl. Når bartenderen trykker på en vare vil den tilføjes varelisten og den totale pris vil blive opdateret. Figur 1.5: Skitse for Brugerinterface på systemet - betaling Når købet er slut kan Bartenderen trykke på betalingsknappen som tilgår det skærmbillede, med betalingsmulighederne, som ses på figur 1.5. Her trykker Bartenderen på den betalingsform der ønskes betales med. 10 af 20

12 I tilfælde af at Bartenderen ønsker noget mere præcis data om salget, f.eks. på dage hvor der ikke er så travlt, kan Bartenderen vælge at taste den specifikke vare ind, som kan findes under de forskellige faner ude i højre side af interfacet. Et eksempel på dette kunne f.eks. være Øl, som ses på figur 1.6 Figur 1.6: Skitse for Brugerinterface på kasseapparetet - Øl Her kan bartenderen så vælge en specifik øl, som f.eks. Tuborg, i stedet for at indtaste alm. øl eller en special øl. 11 af 20

13 System Arkitektur Revision Ændret af Version Dato Ændringer Alle 1.0 XX-XX-XX Tabel 2.1: Revision for System Arkitektur 2.1 OverordnedeSekvensDiagrammer I dette afsnit vises de overordnede sekvensdiagrammer som er lavet med det formål at kunne vise interaktionen mellem aktør og systemet. Samtidig viser der også systemets funktionalitet i henhold til kravspecifikationen, og derfor at gøre det lettere at forstå systemet i forhold til den ydre verden Overordnet sekvensdiagram for Use Case 1 Kontant salg Diagrammet viser interaktion mellem Bartender og system for Use Case 1, Kontant Salg Figur 2.1: Sequence Diagram af Use Case 1 12 af 20

14 Som der kan ses på på sekvensdiagrammet figur 2.1, har bartenderen mulighed for at opdaterer betalings listen inde i et loop, indtil alle bestillingerne er tastet ind. For at komme ud af loopet skal Bartenderen enten annullerer købet eller gå til Betaling Overordnet sekvensdiagram for Use Case 2 Udskriv kundebon Diagrammet viser interaktion mellem Bartender og system for Use Case 2, Kontant Salg Figur 2.2: Sequence Diagram af Use Case 2 Når Bartender printer en Bon kan skal systemmet udskrive en bon, men i tilfælde af at der ikke er mere papir vil systemmet melde en besked om at der ikke er mere papir. For at se hvordan man skifter Bon papiret skal man se under Use Case 2 - Extension Overordnet sekvensdiagram for Use Case 3 Kasseafstemning Diagrammet viser interaktion mellem Bartender og system for Use Case 2, Kasseafstemning 13 af 20

15 Figur 2.3: Sequence Diagram af Use Case 3 Når Bartender skal afstemme kassen afslutter han Use Casen med udskiver en udskrive en bon over afstemningen, men i tilfælde af at der ikke er mere papir vil systemmet melde en besked om at der ikke er mere papir. For at se hvordan man skifter Bon papiret skal man se under Use Case 3 - Extension Domænemodel Ud fra de definerede use-cases i kravspecifikationen er følgende klasser og interfaces blevet udledt. Klassediagrammet i figur 2.4 tager udgangspunkt i ICashRegister. Denne har forbindelse til GUI, som er en boundry klasse dvs. en klasse, som er udefrakommendes vej til brug af systemet. Klassen CashRegister skal varetage systemets funktionalitet såsom opsætning af salg, gennemførelse af transaktion, udprintning af bon osv. Figur 2.4: Domain Diagram af ICashRegister I figur 2.5 ses PaymentController klassen. Denne skal håndtere hvilke betalingsmetoder, som skal bruges under en transaktion. Klassen har forbindelse til IPrint, som skal printe en bon og IDrawer, der skal kunne åbne skuffen. 14 af 20

16 Figur 2.5: Domain Diagram af IPaymentController I figur 2.6 ses klassen ProductController. Klassen står for håndteringen af Product s (varer) i systemet. Klassen skal kunne tilføje, slette og ændre i systemets varekartotek. Disse ændringer skal derefter videreformidles til databasen gennem IProductDao en såkaldt Dao (Data Access Object Pattern) implementation. Implementeringen ProductDaoImpl omsætter systemet Product s til database information, som derefter kan skubbes ind i databasen gennem interfacet IDatabase. Figur 2.6: Domain Diagram af IProductController I figur 2.7 ses klassen ProductGroupController. Klassen står for behandle de forskellige Product s i deres respektive ProductGroup s (varegrupper). Denne bruger ligeledes Dao implementationen til kommunikationen mellem systemet og databasen. Figur 2.7: Domain Diagram af IProductGroupController I figur 2.8 ses klassen DiscountController. Klassen skal holde styr på de rabat, som kan gives på varerne. Der gøres heri ligeledes brug af Dao. 15 af 20

17 Figur 2.8: Domain Diagram af IDiscountController I figur 2.9 ses klassen ReceiptController. Klassen skal opbevare de salg, som er foretaget i løbet af en salgsdag. Salgene bliver skrevet ind i databasen, hvilket kan tages ud igen, når der skal dannes en dagssalgs kvittering. Figur 2.9: Domain Diagram af IReceiptController I figur 2.10 ses klasserne Log, Printer og FilePrinter. Log står for at logge hændelser i programmet, som har værdi. Hændelserne bliver sendt videre til et interface IPrinter hovedsageligt klassen FilePrinter, som udskriver til en bestemt fil, hvor alle de loggede hændelser står. Klassen Printer er en implementering til bonprinteren, der skal udskrive bon, dagssalg osv. Figur 2.10: Domain Diagram af ILog og IPrinter Det fleste af systemets klasser har kendskab til ILog. Dette er dog ikke tegnet på diagrammerne. Hændelser gennem klassehierakiet kan derved logges. 16 af 20

18 Accepttest Revision Ændret af Version Dato Ændringer Alle Dokument oprettet Tabel 3.1: Revision for Accept Test 3.1 Test setup Til at teste følgende skal der bruges et setup med en PC med windows 10 installeret. 3.2 Accepttests Accepttest for Use Case 1 - Kontant Salg Test Forventet resultat Resultat Bartender vælger Drink 20 kr. på systemets varerknapper Bartender vælger Drink 30 kr. på systemets varerknapper Bartender vælger Betalingsknappen Bartender vælger Kontantknappen Systemet opdateres med Drink 20kr på varelisten. Systemets viser nu både Drink 20kr og Drink 30kr på varelisten og den samlede pris på 50 kr Systemet viser Betalingssiden Systemet viser totalprisen af 50 kr. Tabel 3.2: Accepttest for Use Case 1 - Kontant Salg 17 af 20

19 Accepttest for Use Case 2 - Udskriv Kundebon Test Forventet resultat Resultat Bartender gennemfører accepttest for Use Case 1 - Kontant Salg 3 gange Bartender tykker på Tidligere salg knappen Bartender vælger bon knappen ud for det andensidste salg Bartender læser bonen Total pris 50 kr fra sidste salg Tidligere salg menuen vises Bonen bliver udskrevet Bonen viser et køb på 50 kr. Tabel 3.3: Accepttest for Use Case 2 - Udskriv Kundebon Accepttest for Use Case 3 - Kasseafstemning Test Forventet resultat Resultat Bartender gennemfører accepttest for Use Case 1 - Kontant Salg 3 gange Bartender vælger Indstillinger knappen Bartender vælger Afstem knappen Bartender vælger godkend Bartender kigger på linjen nettosalg på bonen Total pris 50 kr. fra sidste salg Indstillinger menuen vises Systemet viser en godkend/annuller dialog Systemets printer udskriver bon og Hovedmenuen vises Værdien er 150 kr. Tabel 3.4: Accepttest for Use Case 3 - Kasseafstemning 18 af 20

20 19 af 20

21 Ordliste Admin Brugeren som varetager systemet.. Bartender Den primære bruger af systemet. Betalingskort Et kort som kan bruges som betalingsmiddel f.eks. et Dankort eller VISA/Dankort. Betalingsterminal En terminal der bruges til at udføre transaktioner, når et betalingskort bruges som betalingsmiddel. Systemet Katrines Kælders Kasseapperat. Vare En vare kan bruges til at omtale en alkoholisk drik eller en øl. 20 af 20