Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database................................................. 3 Funktioner som databasen skal kunne............................. 4 Facaden........................................................... 4 Applikation........................................................ 5 Klient........................................ 5 Server........................................ 5 GUI.............................................................. 5 Klient........................................ 5 Kontrol program............................... 5 Use Case Analysen.................................................. 6 Identifikation af aktører........................................ 6 Use-case diagram............................................. 6 Bruger funktion.............................................. 7 Basis funktion for UC3........................................ 7 Basis funktion for UC4........................................ 8 Identifikation af Use Cases..................................... 9 Sekvensdiagramer.................................................. 17 1: Optælling................................................ 17 2: Optæl kassen............................................. 17 3.A: Søg vare............................................... 18 3.B: Bytte varer............................................. 19 3.C: Flytte varer............................................. 19 3.D: Ankomne varer......................................... 20 3.E: Opret varer............................................. 21 3.F: Slet varer.............................................. 21 3.G: Ordre................................................. 22 3.H: Opret tilbud............................................ 22 4.A: Opret Debitor........................................... 23 4.B: Slet Debitor............................................ 23 4.C: Info om Debitor......................................... 24 4.D: Find Debitor med Ordre.................................. 24 4.E: Indbetaling............................................. 25 5: Print.................................................... 25 Afrunding......................................................... 26 1-27

Kapitel 2 - Analyse I dette kapitel gennemgås der krav og analysen af. I analysen ses der på krav til databasen til, og krav til og analyse af software, som består af serveren på PC en og klienten på Pocket PC. Analyse af I projektet udvikles der en løsning som kan hjælpe de små butikker med at gøre hverdagen lettere ved at holde styr på varer i butikken og på lageret. Det der gøres er, at man ved hjælp af en Pocket PC med stregkode skanner og trådløs LAN, skal man kunne gå rundt i butikken eller på lageret og enten tælle varelageret eller skanne nye varer ind. Den samme Pocket PC som bruges til optælling, skal også kunne bruges til at lave ordre med, det vil sige, at det er en enhed som bruges ud af til. Figur 2.1 viser princippet i ideen bag Figur 2.1 Principskitse af 2-27

Figur 2.2 viser de forskellig lag der er. Foroven er de to GUI er som er på PockerPC og Serveren. Næste lag er det applikationerne til de to GUI. De to applikationer er forbundet til databasen igennem facade laget. Figur 2.2 Illustrerer lagene i systemet Analysen af Database Hvad skal databasen bruges til? Databasen skal bruges til at lagre alle oplysninger om varerne som har brug for. Hvad er det så har brug for? Man skal have noget som holder øje med varerne, lokalitet af varerne, ordre, lager optælling og Debitor. Varer kan have flere forskellige indkøbspriser, det er noget man skal tage højde for, når man laver lager optælling. Så databasen skal kunne have flere indkøbspriser til en vare. Varerne kan også have en varegruppe, så de er nemmere at finde fysisk. I de varegrupper kan varen findes på lageret eller i butikken. Ude på lageret kan man forestille sig at varerne står i niveau, det ville sige, at den enkelte vare står på en bestemt hylde, f.eks. kan en vare x stå på række 4, kolonne 3 og hylde 5, ud fra disse oplysninger kan man finde varen hurtigere. Når varerne forlader butikken som solgte varer, skal det registreres, så man senere på dagen kan gøre kassen op. Når varen bliver solgt kan der være tilbud på varen, der kan forskellige slags tilbud, f.eks. mængde rabat, procent rabat og prisnedsættelse. Der er også debitor. Debitor kan også være forskellig. Man kan forestille sig en debitor som kun får rabat på en bestemt vare, og dem som får procent rabat på alt. 3-27

Funktioner som databasen skal kunne Projektet afgrænses i og med databasen kun udvikles til at kunne det mest nødvendige. Det som databasen skal kunne indenfor varer, lager og ordre/salg: Skal kunne lagre en vare i databasen ud fra stregkoden Vare skal være tilknyttet en varegruppe Man skal kunne se hvor mange af den enkelte vare, der er på lager og i butik Have flere indkøbspriser, men kun en fast udsalgspris Ved ordre/salg skal alle varer tilknyttes et ordrenr. Man skal kunne lave tilbud på en vare. Man kan oprette en debitor, men alle debitorer er ens for at gøre det lidt nemmere, så man ikke skal holde styr på, hvad for en type debitor det er. Facaden Facade laget skal lave forbindelse mellem applikationerne til databasen. Der findes mange forskellige drivere til at lave en forbindelse til en database. De drivere som man kender godt til at lave forbindelsen er ADO.NET og ODCB. Der findes også en driver som er lavet specielt til MySQL databaser. Denne driver hedder MyMySQLDriverCS og lavet til brug ved C# udvikling. MySQLDriverCS virker lige som mange andre drivere til databaser, man skal lave en forbindelse til en database, derefter skal man sende en forespørgsel og dernæst fås det efterspurgte i en double array. Herunder er der et simpelt eksempel på hvordan MySQLDriverCS bruges.! " # # $ %& '! $ ( ( ( ( ( " ) ' ( # * ' # * ' +,-.$ / Kilde: http://www.dotnetforums.net/t78368.html Denne driver vælges til at bliver brugt i projektet, da der gås ud fra, at den vil køre optimalt og giver et nemmere programmerings forløb, da den er lavet til databasen og ikke andre databaser. 4-27

Applikation Klient For at holde en nogen lunde belastning på Pocket PC, skal man lade al databehandling foregå på serveren, også for at der ikke bliver lageret så meget på Pocket PC, da dens hukommelse ikke er så stor. Server Serveren, som skal køre på en almindelig PC, kører som en WindowsService. En WindowsService er et program, som kan starte op når Windows starter. Der er ikke tilknyttet nogle applikationer til servicen, men der kan laves en kontrol til servicen. Dette giver en frihed til brugeren, i og med at han ikke skal rode med at starte programmer op for at bruge de ydre enheder. Hvad nu hvis serveren går ned? Så er det bedst at lade alle handlinger gå til grunde, da det ikke er sikkert at serveren har opfanget alle data. Det samme hvis den trådløse forbindelse går, så skal alt hvad den enkelte Pocket PC var i gang med nulstilles. GUI Klient Klienten skal køre på en Pocket Pc, og derfor skal man tænke sig om en ekstra gang, da brugerinterfacet ikke er ligesom et almindeligt PC brugerinterface. Pocket PC skiller sig ud fra en almindelig PC ved, at det er en mobil enhed. Og når det er en mobil enhed, så for at gøre tingene smarte og små, så går det ud over interfacet, som f.eks. skærmen der ikke kan blive så stor; den er 240x320 pixels. Der skal også tages højde for at skærmen skal bruges til at vise et virtuelt keyboard. Når man skal lave applikationer til en Pocket Pc, skal man også tage højde for at der skal være plads til det virtuelle keyboard. Den Pocket PC, som skal bruges til dette projekt har nr. tastatur, så brugeren ikke skal bruge sin pind til at taste nummerne. Dette gør Pocket PC meget brugervenlig til lager og butikker. Ellers er den eneste måde at anvende Pocket Pc med pinden eller fingrene. På bilagene 1 kan man se skitser over layout på Klient og Kontrol programmet. Kontrol program På Server siden skal der være et simpelt kontrol program, hvorfra man kan lave de ting som ikke kan laves uden et ordentligt keyboard og skærm. En ting man kan gøre for at hjælpe brugeren, er at gøre det lettere at styre de få funktioner som serveren har. Man kan lade serveren åbne vinduer for brugeren. Så skal brugeren ikke lede efter funktionen, eller huske på at der er lavet en handling på PocketPC, som efterfølgende skal følges op på ved serveren. Man skal nok lade de to brugegrænsflader på PockePC og kontrollen til serveren være næsten identiskte, så det bliver nemt at genkende. 5-27

Use Case Analysen Identifikation af aktører I dette system kan hver bruger have hver en Pocket PC, mens der kun er én server til alle brugerne. Brugeren af systemet skal ikke have en høj uddannelse indenfor computer, dog må brugeren gerne have lidt kendskab til computer. F.eks. skal systemet kunne anvendes af Hr. Jensen som har haft en købmands butik i 20 år, og den eneste viden han har til computer, er hans kasseapparat. Det vil sige, at programmet kan hjælpe brugeren meget med at udføre handlinger, så det bliver lettere for brugeren, dvs. brugeren skal lave så lidt som muligt. Use-case diagram Nedenstående Figur 2.2 viser use-case diagrammet over projektet. Figur 2.2 Use-Case Diagram over 6-27

Bruger funktion Ref # Funktion Synlig Egenskaber Detaljer og krav Fejl tilfælde UC1 Brugeren skal kunne optælle sit varelager der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen UC2 Brugeren skal kunne holde styr på omsætningen. der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen UC3 Brugeren kan adminstrere varen synlig Interface Explorer med ikoner basisfunktion 3A-H UC4 Brugeren kan administrere varen synlig Interface Explorer med ikoner basisfunktion 4A-E UC5 Brugeren kan printe ordrer og rapporter ud skjult System Den skal være som en funktions knap, der hvor den skal bruges. Kan være Basis funktion for UC3 Ref # Funktion Synlig Egenskaber Detaljer og krav Fejl tilfælde UC3.A Brugeren kan søge efter varer der er tekstbokse, til at indtaste oplysninger. UC3.B Brugeren kan bytte varer der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen Kan være UC3.C Brugeren kan flytte varer fra lageret til butikken der er tekstbokse, til at indtaste oplysninger. UC3.D Brugeren kan tilføje ny-ankomne varer der er tekstbokse, til at indtaste oplysninger.. UC3.E Brugeren kan oprette en vare som ikke findes der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen UC3.F Brugeren kan slette en vare som findes der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen UC3.G Brugeren kan oprette en ordre der er en liste dialogboks med info om fejlen UC3.H Brugeren kan oprette et tilbud. der er tekstbokse. dialogboks med info om fejlen UC3.I Brugeren kan oprette en varegruppe der tekstbokse til at skrive navnet i 7-27

Basis funktion for UC4 Ref # Funktion Synlig Egenskaber Detaljer og krav Fejl tilfælde UC4.A Brugeren kan oprette en debitor. der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen UC4.B Brugeren kan slette en debitor. der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen Kan være UC4.C Brugeren kan finde info om en debitor der er tekstbokse, til at indtaste oplysninger. Kan være UC4.D Brugeren kan finde de debitorer som har en ordre der er en liste UC4.E Brugeren kan lave en indbetaling på en debitor der er tekstbokse, til at indtaste oplysninger. dialogboks med info om fejlen 8-27

Identifikation af Use Cases Brugeren har mulighed for at administrere varer og debitor, dette er et samarbejde mellem Pocket PC og Server. Use-case Opret Debitor, Opret vare og Slet vare er nogle af de funktioner som kommer til at køre på serveren, da der kan komme for meget taste arbejde. Use-case 1 - Optælling Formål Aktører Trigger Forudsætninger Brugeren kan tælle sit varelager op. Brugeren Brugeren vælger ikon som står for optælling. At serveren er online. Brugeren skanner varen og systemet går ned i databasen og finder varen. Så indtaster brugeren antal varer og systemet regner differencen ud og viser den. Brugeren kan få listen over hele varelaget printet ud (Use-case 5) Forbindelsen til serven kan være nede. Så skal varen tælles forfra. Forløb 1. Brugeren vælger et område(lager/butik). 2. Brugeren skanner varen. 3. Systemet ser om varen findes. 4. Systemet viser hvor mange der skal være af varen. 5. Brugeren kan så indtaste sin optælling 6. Systemet beregner differencen. 7. Viser differencen. 9-27

Use-case 2 - Optæl kasse Formål Aktører Trigger Forudsætninger At brugeren kan gøre kassen op. Brugeren Brugeren vælger ikon som stå for Optæl kassen. At serveren er online. Brugeren kan tilføje start/slut beløbet i kassen. Brugen får at vide hvor mange penge der skal være i kassen, herefter skal brugeren tælle hvor mange der er og indtaste det, hvorefter systemet beregner differencen. Brugeren kan få dagens omsætning printet ud (Use-case 5) Forbindelsen til serveren kan være nede, hvis det er tilfældet så må brugeren prøve igen. Forløb 1. Brugeren får at vide hvor mange penge der skal være. 2. Brugeren indtaster antal penge som der er. 3. Derefter vises differencen. Use-case 3 - Administration af varer Formål Aktører Trigger Forudsætninger Brugeren kan administrere varerne. Brugeren Brugeren vælger ikon som står for hvad brugen vil lave ved varen. At serveren er online. A: Søg vare : System går ned i databasen og finder varen. Brugeren vil derefter se information om varen på skærmen. Varen findes ikke eller forbindelsen til serveren er afbrudt. Brugeren for en fejlmeddelelse om det. Forløb 1. Brugeren indtaster/skanner varenr. 2. Systemet finder varen. 3. Hvorefter information om varen kommer frem. 10-27

B: Bytte vare : Systemet søger i databasen efter om varen findes. Hvis den gør så bliver den tilføjet til databasen. Forbindelsen til serven kan være nede. Og hvis varen ikke finde så findes byttet ikke sted i systemet. Forløb 1. Brugeren skanner varen. 2. Systemet tilføjer varen igen i butikken/lager og beregner udbetalingen. 3. Systemet viser udbetalingen. C: Flytte vare : Systemet søger i databasen om varen findes, hvis den gør får brugeren at vide hvor mange der kan flyttes. Brugeren kan nu flytte det antal varer, der skal flyttes. Forbindelsen til serven kan være nede. Varen findes ikke, brugeren kan ikke flytte varen i systemet. Forløb 1. Brugeren skanner varen. 2. Systemet ser om varen findes. 3. Systemet viser antal af varer der står på lageret. 4. Brugeren indtaster hvor mange brugeren vil flytte. 5. Systemet flytter antallet i databasen. D: Ankomne varer : Systemet søger i databasen om varen findes. Hvis den gør så bliver der tilføjet en ny indkøbspris til varen og antal bliver tilføjet til varen. Forbindelsen til serven kan være nede. Hvis varen ikke findes så skal varen oprettes.(e) Forløb 1. Brugeren skanner varen. 2. Systemet finder varen. 3. Brugeren indtaster antal 4. Tilføjer varen til lageret 11-27

E: Opret vare : Systemet laver et XML dokument hvor oplysningerne bliver gemt. Systemet åbner et vindue hvor brugeren kan indtaste alle oplysningerne. Systemet opretter varen i databasen Serveren går ned. I dette tilfælde skal serven nok genstartes og basisfunktion 3.D skal udføres igen. Forløb 1. Systemet opretter XML med oplysninger 2. Systemet åbner vindue. 3. Brugeren indtaster informationer om varen. 4. Systemet opretter varen i databasen. Forudsætning Basisfunktionen 3.D er blevet kørt. Hvis 3.D ikke er blevet kørt, så åbner serverapplikationen ikke et vindue, så basisfunktion 3.E kan køres. F: Slette vare : Systemet ser om varen findes i databasen, hvis den gør det, slettes alt om varen og de tilhørende indkøbspriser. Serveren er nede, herved kan varen ikke slettes. Forløb 1. Brugeren indtaster vare nr. 2. Systemet ser om varen findes. 3. Systemet spørger om brugeren er sikker på at slette varen. 4. Brugeren accepterer. 5. Systemet sletter varen. 12-27

G: Ordre : Brugen skanner varen og systemet ser om varen findes, og hvis den gør det bliver den tilføjet til databasen, og varen kommer frem på et en liste til brugeren. Ved en afslutning af ordren tilføjer systemet indeholdet af XML dokumentet til databasen. Bruger kan får ordren printet ud (Use-case 5) Forbindelsen til serveren er nede, i dette tilfælde vil man starte der hvor man slap, når serveren kommer op at køre igen. Hvis varen ikke findes, så kommer varen ikke med i ordren. Forløb 1. Brugeren skanner varen 2. Systemet finder varen 3. Brugeren indtaster antal 4. Systemet lagre informationerne i et XML dokument. 5. Varen kommer på en liste på Pocket PC. 6. Brugeren godkender handlen. 7. System gemmer indholdet fra XML dokumentet i databasen. Gentagelse Punkt 1 til 5 kan gentages indtil brugen afslutter ordren. H: Opret Tilbud Tilbudet bliver oprettet og derved bestemmer tilbudet prisen på varen. Forbindelsen er nede til serveren. Tilbudet bliver ikke oprettet. Forløb 1. Brugeren skanner varen. 2. Systemet ser om varen findes 3. Brugeren indtaster information om tilbud. 4. Systemet opretter tilbudet. I: Opret Varegruppe Der bliver tilføjet en ny varegruppe i databasen Serveren kører ikke. Varegruppen bliver ikke oprettet. Forløb 1. Indtaster navnet på gruppen 2. Systemet opretter gruppen 13-27

Use-case 4 - Administrer Debitor Formål Aktører Trigger Forudsætninger At oprette debitor i databasen. Brugeren Brugeren vælger ikon som står for det som brugeren vil lave ved debitoren. At serveren er online. A: Opret Debitor Systemet ser i databasen om den nye debitors firma findes i databasen, hvis ikke så opretter systemet Debitor i databasen. Hvis firmaet findes i databasen, så bliver debitoren ikke oprettet. Forløb 1. Brugeren indtaster information om debitoren. 2. Systemet opretter debitoren. B: Slet Debitor Systemet ser i databasen om debitor findes i databasen, hvis den gør det, så sletter systemet debitoren fra databasen. Serveren kan være nede, eller debitoren findes ikke i databasen. Debitoren bliver så ikke slettet. Forløb 1. Brugeren indtaster debitor nummer. 2. Systemet sletter debitoren. C: Info om Debitoren Systemet ser i databasen om debitor findes i databasen, og hvis debitoren findes henter systemet dataene om debitoren og viser dem på skærmen. Forbindelsen kan være nede til serveren, eller debitoren findes ikke. Så får brugeren ingen informationer om debitoren. Forløb 1. Brugeren indtaster nummer på debitoren. 2. Systemet henter information om debitoren. 3. Systemet viser informationerne. 14-27

D: Find Debitor med Ordre Systemet søger i databasen efter alle de debitorer med en eller flere ordrer. System viser en liste til brugeren med de debitorer som har ordrer. Brugeren kan få listen printet ud (Use-case 5) Forbindelsen kan være nede til serveren. Så kan brugeren ikke få listen over debitorene. Forløb 1. Brugeren indtaster nummer på debitoren. 2. Systemet henter debitorene med ordre. 3. Systemet viser debitorer med ordre. E: Indbetaling Systemet ser i databasen om debitor findes i databasen, og hvis debitoren findes så fjerner system debitoren fra den pågældende ordre, derefter lægger systemet pengene i kassen i databasen. Forbindelsen kan være nede til serveren, debitoren findes ikke eller debitoren ikke har en ordre. Så bliver brugeren bedt om at prøve igen. Forløb 1. Brugeren indtaster nummer på debitoren. 2. Systemet finder debitoren. 3. Brugeren indtaster ordre nummer. 4. Systemet ser om ordren tilhører debitoren 5. Systemet fjerner debitoren på ordren. 15-27

Use-case 5 - Print Formål Aktører Trigger Forudsætninger At printe information om lageret og butikken. Brugeren Brugeren vælger funktionsknappen for print i det vindue som brugeren står i. At serveren er online. Systemet laver en XML fil som indeholder det som brugeren har forespurgt. Derefter laver systemet et dokument som bliver printet ud. Printeren kan være nede, i dette tilfælde er det brugeren og Windows, som skal løse problemerne. Forløb 1. Brugeren giver en forespørgers på det som brugeren vil have printet ud. 2. Systemet henter data fra databasen og lagre det i et XML dokument. 3. Systemet printer XML en ud. 16-27

Sekvensdiagramer 1: Optælling Figur 2.3 viser optælle-sekvensen, når man skal tælle varelageret op. Figur 2.3 Optælling 2: Optæl kassen Figur 2.4 Optæl kassen 17-27

3.A: Søg vare Figur 2.5 Søg vare 18-27

3.B: Bytte varer Figur 2.6 Bytte varer 3.C: Flytte varer Figur 2.8 Flytte varer 19-27

3.D: Ankomne varer Figur 2.9 viser system sekvensdiagram for ankomne varer. Hvis punkt 2 melder fejl så køres sekvens 3.E (Opret vare). Figur 2.9 Ankomne varer og varer som skal oprettes 20-27

3.E: Opret varer Figur 2.10 Opret varer 3.F: Slet varer Figur 2.11 Sletning af varer 21-27

3.G: Ordre Figur 2.12 viser sekvensdiagramet for Ordre. Det bruger et XML dokument som mellemlager inden det bliver lagt i databasen (Nr.4). Figur 2.12 Ordre 3.H: Opret tilbud Figur 2.13 Opret tilbud 22-27

3.H: Opret varegruppe Figur 2.14 Opret varegruppe 23-27

4.A: Opret Debitor Oprettelse af Debitor kan kun ske på serveren, fordi der er et nemmere interface til brugeren. Det samme gælder for Slet og Opret varer. Figur 2.15 Opret Debitor 4.B: Slet Debitor Figur 2.16 Slet Debitor 24-27

4.C: Info om Debitor Figur 2.17 Info om Debitor 4.D: Find Debitor med Ordre Figur 2.18 Find Debitor med Ordre 25-27

4.E: Indbetaling Figur 2.19 Indbetaling 5: Print Figur 2.20 Print 26-27

Afrunding Her som en afrunding på kapitel 2, ses der på hvad der er blevet gennemgået. Der er blevet analyset på databasen, set på hvad databasen skal bruges til, og hvilke problemer, der kan opstå ved brug i et lager system. Ligeledes blev facade lagets funktion analyseret, dvs. bl.a. valg af driver. Det blev MySQLDriver som skal bruges, da den er udviklet til netop MySQL database. For selve Serveren og Klienten har analysen gået ud på at analysere applikationerne og GUI, hvor der blev set på, hvor det er bedst at lægge belastningen, og hvordan den grafiske brugerflade er optimal. I Use-Case analyserne ses der på hvem aktøren kan være, og de fem use-case funktioner Optælling, Optæl kassen, Administrer vare, Administrer Debitor og Print kan ses på Figur 2.2. Funktionaliteten i disse use-case funktioner blev gennemgået, samt hvilke basisfunktioner, der er til dem. 27-27