Indholdsfortegnelse for kapitel 3

Transkript

1 Indholdsfortegnelse for kapitel 3 Kapitel 3 Design Database ER-diagram Redundans og opdaterings problemer Indsættelse Sletning Ændring Forbindelse til Databasen Applikation Server Kontrol Klient Interaktionsdiagrammer Optælling Print lager rapport Optæl kassen Søg vare Ankomne varer Opret varer Ordre Klient Klasse Diagrammer Server Klient GUI Klient Kontrol XML design Protokol design

2 Kapitel 3 - Design I dette kapitel gennemgås design fasen for de to faser Database og Pocket Pc. Der ses på ERdiagrammer (Entity Relationship) over databasen og hvilke tabeller der skal være i databasen. Ligeledes ses på Serverens og Klientens metoder og funktioner, som der er gennemgået overfladisk i analysen. Der bliver også set på et udkast til klasse-diagrammer for Serveren og Klienten. Figur 3.1 Illustrerer de forskellige lag i systemet Figur 3.1 er taget fra kapitel 2, som viser de forskellige lag i systemet. Kapitel 3 gennemgås på samme måde som kapitel 2. Der startes forneden med Databasen og så arbejdes op igennem til man når GUI ene. 2-21

3 Database har en del informationer som skal bruges hhv. til varer på lager og i butik, samt solgte varer. Derfor lagres informationerne i en database. Databasen er MySQL som er en freeware version database, MySQL kører på SQL syntaks. Den imlementeres til SQLmiljø. Den er nem at flytte til andre databaser som kører i det samme miljø, hvis det skulle være nødvendigt. Figur 3.2 ER-diagram over databasen. 3-21

4 ER-diagram På Figur 3.2 kan man se et ER-diagram. ER-diagrammet danner et overblik over databasen. Diagrammet består af 11 tabeller; Varer, som har tilknyttet Tilbud, Indkøb og VareGruppe tabellerne. Solgte varer, som har Ordre tabellen til knyttet, der endvidere har tilknyttet Debitor. Tabellerne som Kasse og Optælling er til midlertidig lagring af data, og derfor har de ikke noget med de øvrige tabeller at gøre. Alle disse tabeller som er i databasen hører til 3.NF (NormalForm). Første normalform gælder for en primær nøgle i tabellen. Denne kan eventuelt bestå af flere felter. Der må ikke optræde samme data flere gange i tabellen. For at opnå 2. normalform skal 1. normalform være opfyldt. Og alle dataerne skal være afhængig af en primær nøgle, og må ikke optræde flere gange. For at få 3. normalform skal 2. normalform være opfyldt, og der må ikke være attributter som er indirekte afhængige af nøglen i tabellen. Dette sker hvis attributtet er afhængigt af en attribut, der igen er afhængigt af nøglen. Herunder vil tabeller blive gennemgået, attributterne bliver vist her med et navn og er efterfulgt af hvad de bruges til og hvilken type de er og hvor store de er. Primær nøgler bliver marker med fed, og fremme nøglerne med kursiv. Vare tabellen indeholder information om den enkelte vare. Tabellen har tre ude fra kommende fremme nøgler som kommer fra Tilbud, Indkøb og VareGruppe tabellerne. Tabellen Varer har følgende attributter : Vare_ID : Stregkode på varen(int64 15) Navn : Navnet på varen(char 30) Gruppen_NR : VareGruppes nummer(int 3) An_Butik : Antal varer i butikken(int 4) An_Lager : Antal varer på lager(int 4) IPris_NR : Nummer på den aktive indkøbspris(int 6) Upris : Den Normale udkøbs prisen(float) Tilbud_NR : Nummer på den aktive tilbud(int 3) Note : note om varen(text) Tilbuds tabellen indeholder information om det tilbud der er tilknyttet til en bestemt vare. Tabellen Tilbud har følgende attributter : Tilbud_NR : Nummer til tilbudet (Int 3) Type_Tilbud : Typen på Tilbud (Char 30) STK : Antal varer i et tilbud (Int 3) Vardi : Værdi som skal bruges i et tilbud (Float) Tabellen Indkøb holder styr på de forskellig indkøbspriser som er til en bestemt vare. Hvis nu ikke alle varerne er solgt til en bestemt pris, så bliver Naeste_IP_NR sat lig med den nye IPris_NR. På denne måde kan man holde styr på de forskellige indkøbspriser. Tabel Indkøb har følgende attributter : IPris_NR : Nummer indkøb(int 6) Naeste_IP_NR : Nummer på næste indkøb (Int 6) IPris : Indkøbsprisen på varen(float) STK : Antal varer i et tilbud (Int 3) 4-21

5 VareGruppe tabellen indeholder alle navne på varegrupperne. Tabel VareGruppe har følgende attributter : Gruppe_NR : Nummer indkøb(int 3) Navn : Navn på gruppen(char 30) Ordre tabellen har to tabeller tilknyttet sin tabel; Solgt varer og Debitor. Disse tabeller opfylder 3.NF(NormalForm). Ordre tabellen holder styr på ordrerne, hvilken vare som tilhører den og hvis der er en debitor tilknyttet. Tabellen Ordre har følgende attributter : Ordre_NR : Nummer på ordren(int 6) Dato : Datoen på ordren(date) Total_Pris : Den totale pris på ordren(double) Debitor_ID : Nummer på Debitor(Int 3) Solgt Varer tabellen holder styr på de varer som er tilknyttet det enkelte ordre nummer. Tabellen Solgt Varer har følgende attributter : Ordre_NR : Nummer på ordren(int 6) Vare_ID : ID på den var som bliver solgt(int64 15) STK : Hvor mange som bliver solgt af den enkelte vare(int 3) Pris : Er den enheds pris som varen blive solgt for(float) Debitor tabellen indeholder informationer om debitoren. Tabellen Debitor har følgende attributter : Debitor_ID : Nummer på Debitor(Int 3) Navn : Navn på debitoren(char 30) Firma : Navn på firmaet(char 30) Adresse : Adressen på debitoen(text) Note : Note om Debitoren(Text) Kasse tabellen holder øje med dagens omsætning. Den kan holde øje med flere forskellige typer betalings måder. Der er tilknyttet tabellen Kasse Vardi, og til Kasse Vardi er der tilknyttet tabellen Betaling Type. Disse tabeller opfylder betingelser indenfor 3.NF. Tabellen Kasse har følgende attributter : Kasse_Dato : Datoen på kasse (Date) Start_Sum : Den start sum som kassen starter med(float) Slut_Sum : Den slut sum man har når dagen er omme (Double) Kasse Vardi holder styr på dagens omsætning for hver type betaling, som der er lavet. Tabellen Kasse Vardi har følgende attributter : Kasse_Dato : Datoen på kasse (Date) Type_ID : Typen på den betaling som kan laves(int 3) Vardi : Værdien inden for den betalings type(double) Betalings Type indeholder alle de betalings muligheder der findes i den enkelte butik. Tabellen Betalings Type har følgende attributter : Type_ID : Type nummer(int 3) Type_Navn : Navn på type af betaling(char 30) 5-21

6 Tabellen Optælling tilhører ikke nogle af de andre tabeller. Denne tabel styres af applikationen, så på en måde er det kun en tabel til at lagre data i. Tabellen Optælling har følgende attributter : Vare_ID : Nummer varen(int64 15) IPris : Indkøbsprisen på varen(double) Lager_STK : Antal varer på lager(int 4) Butik_STK : Antal varer i butikken(int 4) Diff : Differencen på varen(doulble) Dato : Dato på optælling(dato) Redundans og opdaterings problemer Redundans kan resultere i et stort unødvendigt pladsforbrug på harddisken, som den enkelte database bruger. Dette kan være et væsentligt problem ved enten store datamængder eller ved anvendelse af harddisk plads. Dog er den teknologiske udvikling indenfor lagring af data så langt fremme, at plads problemet er uden betydning. Langt vigtigere er de problemer, som redundans giver anledning til ved opdatering af databasen. I det følgende ses på nogle af de problemer, der opstår ved indsættelse, sletning og ændring i tabeller Varer, Ordre og Debitor. Indsættelse Problemet ved indsættelse er, at det ikke er muligt at lave en ordre på en vare, før varen er oprettet i databasen. Dette vil nemlig resultere i nul-værdier for den del af nøglen, som udgøres af Varer_ID. Det er heller ikke muligt at lave tilbud og indsætte nye varer, før der haves mindst en vare, som har det Varer_ID som skal have tilbud eller blive summeret. Sletning Problemet ved sletning er tæt forbundet med problemet ved indsættelse. Når man sletter en vare, mister man information om varen, tilbud og indkøbs priser. Ved sletning af debitor, så er det kun information om debitoren som går tabt, men ordrer som var tilknyttet til debitoren findes endnu. Ændring Ændres indkøbspriser, tilbud eller FlytteVare i tabellen Varer, vil denne ændring kun skulle foretages i den række hvor vare_nr hører til. Ændringen ved en vare, vil for det meste medføre et nyt indkøb eller nyt tilbud. 6-21

7 Forbindelse til Databasen Facade laget er det lag som går til databasen. Facade laget består af MySQLDriverCS som er lavet til C#.Net udviklings miljø, og bygget til MySQL databaser. Facade laget skal holde styr på alle forespørgsler til databasen. For at lave et enkelt og overskueligt facade lag er dette bygget i en klasse for sig selv. Klassen kommer til at indeholde de funktioner som serveren skal bruge til at lave forbindelse til databasen. Funktioner som facade laget skal indeholde ses herunder i tabellen. XML i tabellen er en string som indenholder et XML dokument. Funktion Navn UC Handling i databasen Tabeller Parameter Returnere Optalling 1 Indsætte Optaelling, Varer, Inkoeb vare_nr, fysisklager, fysiskbutil boolean OptallingInfo 1 Hente inkoeb, optaelling - XML PrintRapport 1 Hente Optaelling, Varer, Inkoeb - XML OptalKasseInfo 2 Hente kassevardi, kasse - XML OptalKasseBetalTy pe 2 Hente Kassevardi, betalingtype - XML OptalKasse 2 Indsætte Kassen start, slut boolean PrintRapport 2 Hente Kassen, Kasse vardi dato XML SogVare 3.A Finde, Hente Varer, Indkoeb vare_nr XML Bytte_Vare 3.B Tilføje, Hente Varer, soltvare, kassenvardi vare_nr, ordrenr XML Flytte_Vare 3.C Flytte Varer vare_nr, antal XML Ankommet_Vare 3.D Tilføjer Varer, Indkoeb vare_nr, antal, ipris boolean Opret_Vare 3.E Indsætte Varer, Indkoeb vare_nr, stk, gruppenr, ipris, upris, note boolean Slet_Vare 3.F Slet Varer, Indkoeb, Tilbud Ordre 3.G Indsætte Tilbud, Ordre Soldt varer. vare_nr, Navn XML boolean diff BetalingForm 3.G Hente betalingtype - XML PrintOrdre 3.G Hente Ordre, Soldt varer ordrenr XML Opret_Tilbud 3.H Indsætte, Tilføje Tilbud, Varer vare_nr, type, vardi, antal, strslutdato Opret_Debitor 4.A Indsætte Debitor navn, firma, adresse, note boolean debitornr 7-21

8 Slet_Debitor 4.B Slet Debitor, Ordre debitornr void Info_om_Debitor 4.C Hente Debitor, Ordre debitornr XML FindDebitorOrdre 4.D Hente Debitor, Ordre - XML Indbetal 4.E Tilføje Debitor, Ordre, Kassen vardi debitornr, ordrenr, vardi boolean Opret_VareGruppe 3.G Indsætte varegruppe navn - Vis_VareGruppe_ Navn 3.G Hente varegruppe - string[] Funktionerne i tabellen før er ikke så uddybende, men er der for at danne et overblik over hvad facade laget skal bestå af i systemet. Funktionerne vil blive gennemgået detaljer i afsnittene Interaktionsdiagrammer og Applikation. Applikation Design afsnittet om applikationerne, består af applikationerne i systemet, og interaktionsdiagrammerne som viser use-casene i en applikations udgave. Og til sidst klasse diagrammer, som giver et indblik i hvordan klasserne skal se ud i systemet. Applikationerne i systemet vil komme til at bestå af tre forskellige. De forskellige applikationer består af; en WindowsService, en Pocket PC applikation og en kontrol applikation. WindowsServicen er en Server, der holder styr på forbindelsen imellem Klienten og databasen. Kontrol applikationen skal bruges til den svære håndtering at varer, debitor og indstillingen til Serveren. Klienten er en applikation som kører på Pocket PC og som har forbindelse til Serveren. Server Serveren skal laves som en WindowsService, dette betyder, at der ikke kan ses på GUI til denne applikation. Serveren skal starte op når Windows starter, så brugeren ikke skal bekymre sig om at Serveren kører. Det kan ske at brugeren slår servicen af, men i dette tilfælde vil brugeren selv få ansvaret for at starte den op. Som tidligere nævnt skal Serveren styre forbindelsen imellem Klienten og databasen, udover det skal den også kunne styre printeren. Kommunikation mellem Serveren og databasen kommer til at ske igennem Facade klassen, som indeholder alle givne funktioner. Serveren har en kontrol applikation tilknyttet der hvor man kan administrere debitor og vare. Dog ikke oprette varer, der kommer til at køre i en tråd fra Serveren. Der bliver brugt tråd fordi Serveren skal kunne arbejde videre uden at skulle vente på at brugeren indtaster oplysningerne. Kommunikation imellem Serveren og Klienten laves over en socket forbindelse. For at gøre det lidt mere brugervenligt, startes der en tråd op for hver ny Klient som forbinder sig til serveren, så kan systemet havde flere brugere på engang. 8-21

9 Kontrol Kontrol applikationen har forbindelse med Serveren som er en WindowsService. De arbejder tæt sammen, og de fælles oplysninger, såsom indstillinger, bliver gemt i registrerings databasen. Kontrol har hovedsageligt knap-funktioner. Knap-funktioner er funktioner, som bliver kaldt, når man trykker på knappen. Disse funktioner kalder lige til Serveren, som er WindowsServicen, herved skal Kontrol ikke lave så meget arbejde. Når der skal oprettes en vare er det Server som sørger for at der bliver åbnet et vindue som brugeren skal bruge til at indtaste i. Der bliver startet en tråd, som starter en form op, som brugeren skal bruge til at indtaste i. Tråden finder de oplysninger om de varer som findes i en XML fil. Tråden kører så længe der findes XML filer. Klient Klient er en applikation som kører på en Pocket PC. Denne applikation skal ikke kunne så meget da det er interface til Serveren. Klient skal dog kunne håndtere XML og socket forbindelse til Serveren. Når applikationen startes op, skal den selv oprette forbindelse til Serveren, så brugeren ikke skal rode med det. Klinten har funktionen VisXML, som sørger for at pakke XML en ud, der kommer fra Serveren, og viser dataene på de pladser som de tilhører. Ud over funktionen VisXML er der også en række funktioner som tilhører knapperne, disse funktioner laver en XML hver især som indeholder en mængde data som kommer fra GUI, som derefter sendes til serveren. 9-21

10 Interaktionsdiagrammer Der er tidligere lavet system sekvensdiagrammer for de enkelte Use-cases, der viser hvordan de kommunikerer med systemet. Interaktionsdiagrammerne går dybere med designet, den åbner systemet og ser hvilken klasser i use-casen der kommunikerer med hinanden. Da systemet er udviklet til at køre på en PC og en Pocket PC, så der vil være et diagram for både PC og Pocket PC, hvor PC er Serveren og Pocket PC er Klienten. Interaktionsdiagrammer for Klienten behandler serveren som en black-box og det samme ved diagrammer over Serveren, da vil det være databasen og Klienten som er black-box. Optælling Herunder på Figur 3.X kan man se sekvensdiagram over optælling af varelager. Sekvensdiagrammet er på Server s side. Serveren modtager en XML, hvorefter der en Figur 3.3 Optælling fortolker, som finder ud af hvad for en funktion som den skal bruge i facade laget. Det første som sker er at Klienten spørger efter en vare, og derefter at Klienten kan komme med optællings oplysninger til databasen

11 Print lager rapport Sekvensdiagrammet herunder er et sekvensdiagram, som der er næsten identiske med nogle af Figur 3.4 Print lager rapport de andre sekvensdiagrammer. De andre kan man finde i Bilag Det drejer sig om Print Kasse Rapport, Find Debitor med ordre og Print ordre. Det der er fælles for de tre sekvenser er at Klient sender en XML, hvor der står hvad for en rapport der skal printes ud. Facade laget laver en XML som Serveren modtager og sender videre til Print. Print ser hvordan layoutet skal se ud, og printer det

12 Optæl kassen Sekvensen for Optæl kassen ligner meget sekvensen for Optælling af lager. Klienten spørger efter hvad der findes i kassen og Klienten svarer senere med hvad der skal afsluttes med i kassen. Figur 3.5 Optæl Kassen Søg vare Søg vare sekvensen er et sekvensdiagram som ligger grund for følgende andre sekvensdiagrammer: Bytte varer, Flytte varer, Opret tilbud, Info om debitor og Indbetaling. Disse findes i Bilag 3X. Det der er fælles for disse sekvensdiagrammer er, at der kommer en XML fra Klienten som beder om nogle informationer, og fortolkeren finder den funktion som skal bruges til der er bliver spurgt efter. Figur 3.6 Søg vare 12-21

13 Ankomne varer Sekvensen for Ankommet vare er ligesom Søg vare, der er bare det ved Ankommet vare at hvis Facade lage melder ud at varen ikke findes, så kalder Serveren Opret vare. Figur 3.7 Ankommet varer Opret varer Opret varer kører ikke på Klient en, den køres fra kontrollen, som er tilknyttet Serveren. Sekvenserne Slet varer, Opret Debitor og Slet Debitor kører på samme måde som Opret vare, bortset fra at det ikke er Klienten XML kommer fra. g Figur 3.8 Opret varer 13-21

14 Ordre Herunder er sekvensdiagrammet for Ordre. Punkt 1 til 4 kan blive kaldt flere gange, så man kan bygge en liste op af varer til en given ordre. Når Klienten er færdig kommer punkt 5, hvor den XML som ligger på serveren bliver gemt i databasen. Figur 3.9 Ordre 14-21

15 Klient Sekvensdiagrammet herunder viser Klient. Klient er en skal til Serveren, så Klient skal ikke lave så meget andet end at tage data som brugeren indtaster og lave en XML, som sendes til serveren, og vise de XML som Serveren sender. Den sekvens gælder for alle funktioner som Pocket PC skal lave. Figur 3.10 Klient 15-21

16 Klasse Diagrammer Klasse diagrammer over applikationerne viser kun de klasser som skal laves til systemet, og ikke de klasser som der bruges fra.net Frameworket. Dette gøres for at opretholde et overblik over hvad der skal implementeres. Server Figur 3.11 Klassediagram over Server Klient Figur 3.12 Klassediagram over Klient 16-21

17 GUI GUI er den grafiske brugerflade, det er vigtig at den er nem for brugeren at bruge. Den måde som dette system vil køre på, er at lave en explorer som viser store ikoner, hvert ikon har hver deres funktion til systemet. Det ville gøre det lettere for brugeren at finde rundt da brugen kan se billede og tekst sammen med funktionerne. Serveren har ingen GUI. Klient GUI på Klienten er det interface som skal bruges mest, derfor skal det være let at gå til. Med et skærm areal på 240x320 pixels er det begrænset hvor nem og synlig man kan gøre brugergrænsefladen. Den løsning som skal anvendes på Klient er en form for explorer som man kender fra Windows skrivebord. På Figur 3.2 ses det hvordan det forventes at se ud, når det hele er implementeret. Denne brugergrænseflade vil lave en række af Formene, og en ListView kontrol som kan indeholde en liste af elementer med ikoner. Formene kører som dialogbokse og kan kun styres fra den form som indeholder ListView kontrol. Det at de køres som dialogbokse, gør at man ikke skal lave andet i programmet imellem tiden. Så alle formene viser tilbage til ListView kontrollen, når den enkelte handling er færdig. Figur 3.13 Kontrol vindue på Klient 17-21

18 De andre faneblade som skal bruges vil ikke blive gennemgået. Der vil blive set på en fælles form for alle faneblade. Figur 3.14 viser hvordan et standard faneblad skal se ud. Ordre er dog den eneste som ikke har varenummer for oven, da den skal have en liste af numre og priser. Figur 3.14 Viser standard faneblad Layouts på skitseform til alle vinduer på Pocket PC kan man se i Bilag indikerer et input felt, og den blå indikerer en trykknap, brun og orange indikerer områder som viser data man ikke kan skrive i eller trykke på

19 Kontrol Kontrol programmet kommer til at ligne Klient meget. Der bliver også lavet en explorer med en række ikoner som brugeren skal bruge som genvej til de forskellige dialoger. Der er dog Opret vare, der ikke kan findes imellem ikonerne, da den er en form for sig selv, som der bliver startet op af WindowsServicen. Formen for Opret varer kommer til at ligne de andre i opsætning. På Figur 3.15 kan man se opdelingen af arealet som Kontrol har. Denne opdeling kommer Opret varer også til at have. Figur 3.15 Areal view over Kontrol Layoutet på skitseform til at alle vinduer til kontrollen kan man se i Bilag 3XXX. Den gule farve er indikerer et input felt, og den blå indikerer en trykknap, brun og orange indikerer områder som viser data man ikke kan skrive i eller trykke på

20 XML design Hvad skal XML bruges til i dette produkt? XML er en smart måde at pakke data ind i en tekstfil. Det som XML skal bruges til, er at bringe data imellem Klient og Server, og den modsatte vej. Der bliver brugt XML, så man er fri for at lave en protokol til socket forbindelsen, det gør projektet nemmere at overskue, da man ikke skal til at lave fortolkere selv, da de findes i.net. Herunder i tabellen ses elementerne, der bruges i XML koderne. Samtlige XML koder, der bruges til kommunikation i systemet ses i bilag 4. Tilhører Overskrift Emne Optælling OptælKasse SøgVarer BytteVare FlytteVare AnkommetVare Ordre OpretTilbud InfoDebitor FindDebitorOrdre Indbetaling Print OpretVare SletVare OpretDebitor SletDebitor OpretVareGruppe Fejl Butik Lager StartVærdi SlutVærdi Ordreliste OrdreNyVare NyVare PrintOrdre PrintOptælling PrintKasse PrintDebitor OrdreBetal OrdreTotal BetalType OptællingInfoKasse Fysisk Antal Difference Værdi BetalingForm VareNr VareNavn AntalLager AntalButik UdPris IndPris OrdreNr Udbetaling DebitorNr Procent Type Firma Adresse Note VareGruppe FejlMeddelse Sted Nedenfor ses et eksempel på opbygningen af XML en. Tilhører siger hvad det er for en handling, og overskrift hvad der skal ske, men der kan komme tilfælde hvor der ikke behøves en overskrift. Emne er den data mængde som skal transporteres, f.eks. informationer om værdi og antal. Herunder kan man se hvorden de forskellige lag skal stå, når de skal bruges. <Tilhører> <Overskrift> <Emne>... </Emne> <Emne>... </Emne> </Overskrift> </Tilhører> 20-21

21 Protokol design I kommunikationen imellem Server og Klient bliver der brugt en TCP/IP protokol. Over denne forbindelse bliver der brugt XML, dette gør at man ikke skal lave en protokol fortolker. Når der en Klient som lave en forbindelse til Server, så startes en tråd som laver forbindelse til Klienten, så der kan udveksles meddeleser. Figur 3.16 Oversigt over forbindelsen imellem Server og Klient Kommunikationen imellem Server og Klient forgår over porten For at undgå problemer med operativsystemet, så er porten langt så højt, da operativsystemet selv bruger port til at bestemme kommunikationsfunktioner