Lagerstyringssystem, 3itk0808 Side 1

Transkript

1 Lagerstyringssystem, 3itk0808 Side 1

2 Titel: Lagerstyringssystem Tema: Embedded Web & Database UCN Nordjyllands Erhvervsakademi Sofiendalsvej 60 Telefon Fax Projektperiode: 01/ til 18/1-10 Projektgruppe: 3itk Deltagere: Peter Ditlev Thomas Madum Lars Gade Møller Vejledere: Ib Helmer Nielsen Rie Nielsen Synopsis: Dette projekt omhandler konstruktionen af et lagerstyringssystem, hvor der i projektet indgår brug af WebNet og PIC16, en MsSQL database og udvikling af GUI i C#.NET. Målet med projektet var at udvikle et komplet system, hvor en lagermedarbejder via WebNet/PIC kan scanne en vare ind/ud af lageret. Derudover skulle der opsættes en database og udvikles en GUI til databasen. Denne GUI skulle så være det lag som forbinder brugeren med databasen. Det kan samlet konkluderes at der blev udviklet et komplet system, hvor PIC ens ram satte begrænsninger i programmeringsfasen, samt der blev opsat en fuld funktionsdygtig database med tilhørende GUI, som både kunne oprette, redigere og slette forekomster i databasen. Sideantal: Bilagsantal: 31 sider 5 sider Lagerstyringssystem, 3itk0808 Side 2

3 Indholdsfortegnelse INDHOLDSFORTEGNELSE... 3 INDLEDNING... 4 AFGRÆNSNING KRAVSPECIFIKATION TIL WEBNET OG PIC SPECIFIKATION AF KRAV TIL HARDWARE... 8 DESIGN AF PIC SOFTWARE FUNKTIONEN ANTAL FUNKTIONEN SCAN_VARER FUNKTIONEN SEND IMPLEMENTERING AF PIC SOFTWAREN FUNKTIONEN ANTAL FUNKTIONEN SCAN_VARER FUNKTIONEN SEND KRAVSPECIFIKATION DATABASE BAGGRUND BRUGER OG AKTØRER APPLIKATIONER ANALYSE OG DESIGN AF DATABASE BRUGERPROFILER DATAMODEL IMPLEMENTERING TEST AF DATABASEN SIKKERHED DESIGN AF GUI EN IMPLEMENTERING AF GUI UDVIKLING AF SØGEFUNKTIONEN REDIGEREFUNKTION DELETE-FUNKTION KONKLUSION BILAG BILAG A BILAG B Lagerstyringssystem, 3itk0808 Side 3

4 Indledning Vi skal i dette projekt arbejde med lagerstyring som udgangspunkt. Vi har fået til opgave at lave et system der i den ene ende kan scanne en vare, registrere den som indgående eller udgående fra lageret og i den anden ende lagre disse data sammen med andre informationer i en database så der bliver mulighed for at søge på diverse af informationer. Altså har vi et lager fyldt med varer, en medarbejder der scanner varerne så de registreres og en database med de scannede informationer så vi kan holde styr på hvor mange varer der er på lageret og hvor de ligger. Hvad skal der bruges for at dette projekt skal lykkedes? I denne rapport vil vi gennemgå hvilken hardware der påtænkes at bruges og hvordan hardwaren programmeres. Vi vil gennemgå design og opsætning af databasen hvor informationerne fra lageret skal lagres og vi vil gennemgå en dertil designet brugergrænseflade. Alt dette gennemgås i håb om at kunne illustrere hvordan vi tænker at opbygningen af lagerstyringssystemet skal foregå og hvordan systemet skal fungere. Afgrænsning. Brugergrænsefladedelen i dette projekt kan gøres uendeligt stort. Derfor har vi valgt at afgrænse denne del, så vi vil kunne overholde deadline for fremvisning. Vi har valgt at brugergrænsefladen(gui) kun skal bruges internt, dvs. at det kun er firmaet selv der kan tilgå databasen. Da der er rigtig mange søgemuligheder i databasen, vælger vi i første omgang at begrænse søgningerne så der kun kan søges indenfor de enkelte tabeller. Søgninger på flere tabeller vil kun blive forsøgt gjort muligt hvis tiden er til det. Lagerstyringssystem, 3itk0808 Side 4

5 Kravspecifikation til WebNet og Pic. 1. Indledning 1.1. Formål. Vores firma, Lageras.dk har fået til opgave at, konstruere et lagerstyringssystem. Målet med Lageras.dk s lagerstyringssystemet er at holde styr på hvad der er på lageret på et hvilket som helst tidspunkt. Kunden der har stillet opgaven er underviserne på it- og elektronikteknologuddannelsen som led i undervisningen og med henblik på en eksamen. Der kan ske ændringer undervejs i projektforløbet og følgende vil derfor gøre sig gældende: 1. Alle ændringer fra dagsdato vil blive noteret med dato og version i afsnit Alle ændringer i software vil ligeledes blive indføjet i modulhoved med dato og version. 3. Eventuelle ændringer i hardware vil blive indføjet i diagrammer og afsnit Referencer I denne kravspecifikation refererer vi til eksterne dokument semplan3itk0909v2.03 hvor oplæg til projektet forefindes Læsevejledning Ingen læsevejledning 1.4. Ændringer 2. Generel beskrivelse 2.1. Systembeskrivelse Lagerstyringssystemet består af en hardware del og en software del. Hardware delen består af en scanner, en pic, et LDC-display og et WebNet modul. På software siden har vi en database, en webserver og en webclient. På et hvilket som helst tidspunkt skal man via webclienten kunne få oplysninger om hvad der er på lageret. Webclienten er en standard PC med en vilkårlig webbrowser. Indgående og udgående varer vil blive scannet med en rfi scanner. Denne scanning sendes via pic og WebNet modul til Webserveren, hvor den registreres i databasen. Lagerstyringssystem, 3itk0808 Side 5

6 2.2. Programmellets funktion Figur 1. Viser overordnet diagram over projektet. Systemet består af en scanner i den ene ende og en database i den anden. På LDC-display bliver man bedt om at indtaste antal, hvilke gøres med 3 knapper. 1 for plus-antal(altså indgående varer) og 1 for minus-antal(altså udgående varer) og 1 for Enter. Derefter bliver man bedt om at scanne varen. Scannerenheden scanner varen. Pic en modtager den scannet data fra scanneren. Denne data sendes videre til WebNet modulet sammen med plus- eller minus-antal data. WebNet modulet sender den samlede data videre gennem en lan forbindelse. Dataen s destination er en dertil indrettet webserver som lagrer dataene i en database. Databasen skal sende et acknowledge eller not acknowledge tilbage til pic en som udsender et ok eller fejl på LCDdisplayet. Hvis der hverken kommer et acknowledge eller et not acknowledge tilbage, vil en timer få pic en til at gensende den tidligere sendte data Programmellets begrænsninger LCD- displayet skal vise info om scanningen, men kun om datatransmissionen er lykkedes eller ej. Indgående/udgående-antal systemet sætter en relativ begrænsning, da det bliver besværligt nu større antal man skal trykke Programmellets fremtid I stedet for LDC-display og trykknap systemet vil det være en overvejelse værd at tænke tastatur evt. touchscreen eller bærbar med indbygget klient Brugerprofil Alle med et lagerbehov vil med fordel kunne bruge dette lagerstyringssystem. Systemet stiller ikke store krav til brugeren så en kort instruktion vil være rigeligt. Lagerstyringssystem, 3itk0808 Side 6

7 2.6. Krav til udviklingsforløbet Ingen Omfang af kundeleverance. Produktet afleveres som en prototype Forudsætninger Projektet skal bygges om omkring en WebNet med et pic-modul, samt at der skal laves en database med et relativt komplekst omfang. 3. De specifikke krav Definitioner RFI-scanneren kan bruge forskellige output formater. Da der sidder en RS232 input på pic en er det oplagt at vi bruger RS232 protokollen til at overfører data. Der skal sendes data fra pic en til WebNet modulet. For at dette kan lade sig gøre skal der laves en driver. Protokollen til driveren kræver to porte til ind- og udgang og en tredje port til reset af pic en Funktionelle krav Der skal kunne opsamles data om antal varer samt varens RFI-tag og sende denne data til databasen, hvor den lagres. Funktion 1: antal varer samt indgående/udgående. Denne funktion kunne godt deles op i 2(antal varer indgående/udgående), men vil kræve yderligere hardware. Indtastningssystemet med 3 knapper er relativt nemt og plus/minus knapperne har hver 2 funktioner. De sender information om antal og om varerne er indgående eller udgående. Funktion 2: Scanning af RFI tag: RFI scanneren tilkobles pic en via RS232 stikket. 4. Eksterne grænseflade-krav 4.1. Bruger-grænseflade Samtlige funktioner vises via guide på LDC-display Hardware-grænseflade Ingen specifikke krav 4.3. Software-grænseflade Ingen specifikke krav 4.4. Kommunikationsgrænseflade Der benyttes RS232 til opkobling af RFI-scanner. Derudover bruges et WebNet modul til kommunikation mellem database og PIC16 processoren. Lagerstyringssystem, 3itk0808 Side 7

8 5. Krav til programmellets ydelse LCD displayet skal opdatere hver gang der trykkes på en tast ved indtastning af antal. Der må max gå 10 sekunder fra data til databasen er sendt til modtagelse af acknowledge. Hvis ikke udskrives fejl på display. 6. Kvalitetsfaktorer Ukritisk Ikke særlig vigtig Vigtig Meget vigtig Særdeles vigtig Pålidelighed 4 Vedligeholdelsvenlighed 3 Udvidelsesvenlig 3 Brugervenlighed 4 Genbrugbarhed 1 Integritet 2 Effektivitet 4 7. Andre krav Ingen yderlige krav 8. Del-levering Specifikation af krav til hardware Der anvendes et PIC16F876 processor board. Der benyttes et LCD display (16*4 linjer) (JM164A). Der anvendes en RFI scanner(noname). Der anvendes et WebNet modul. PIC16 boardet skal forbindes til RFI scanner via RS232 og til Lan-forbindelse med adgang til database via WebNet. De ovennævnte krav til hardwaren er nødvendige for at systemet til terminalen fungerer korrekt og den henseende som der ønskes. Der benyttes som udgangspunkt et færdig bygget PIC16F876 processor board Lagerstyringssystem, 3itk0808 Side 8

9 med WebNet modul. Udover de nævnte krav til hardwaren skal der monteres 3 ekstra knapper til brug af software systemet. Lagerstyringssystem, 3itk0808 Side 9

10 Design af PIC software Dette afsnit vil beskrive, hvordan det er tænkt at programmet skal programmeres i C. Overordnet set kommer programmet til at bestå af 3 programmeringsdele, hvis man ser bort fra drivere til RS232 og LCD display. Der skal konstrueres en funktion som skal tage sig af, at få et input fra brugeren vedrørende antal som kommer enten ind eller ud af lageret. Dernæst skal der laves en funktion som kan modtage og gemme tagget fra RFI-chippen. Til sidst skal der konstrueres en funktion som kan sende en antal+rfi til en klient. I bilag A ses et flowchart over softwaren. Af yderligere hardware end WebNet og PIC16, har vi tænkt os at bruge et LCD display til at informere brugeren, en RFI-scanner til scanning af TAGs og 3 trykknapper. Funktionen Antal Tanken med denne funktion er at montere tre trykknapper til systemet som beskrevet i kravspecifikationen. Disse tre knapper vil derfor have en funktion som enten er tæller op/ ned eller godkend, så når brugeren har trykket det ønskede antal ind, går systemet videre til næste funktion. Efter hvert tryk på en knap opdateres displayet, så brugervenligheden er i top og der ingen fejl opstår. Funktionen registrerer selv om det er en udgående eller indgående varer, da + er indgående og - er udgående. Tallet gemmes i en global variable for at spare plads i hukommelsen på PIC en. Funktionen Scan_varer Det eneste denne funktion skal er at modtage og gemme RFI-tagget som kommer fra scanneren som er koblet på systemet ved brug af RS232 protokollen. Tagget gemmes i en global variabel og displayet skriver brugervenlig information ud til brugeren. Opsætning og brug af RS232 er beskrevet i databladet for PIC16. Der skal dog laves en lille beregning omkring SPBRG i opsætningen af RS232. Denne udregning er lavet på følgende måde: SPBRG = 20Mhz/(16x9600)-1 = 129 Funktionen Send Denne funktion består af to dele, udover at sende en samlet streng med data, skal denne funktion også sammensætte antal og RFI-tagget til en streng med et specialtegn imellem. Da WebNet modulet kun kan fungere som server, er funktionen tvunget til at vente på en forespørgsel fra en klient. Denne forespørgsel kan fx være at klienten sender et x til WebNet og derefter sender WebNet modulet data strengen retur til klienten. Lagerstyringssystem, 3itk0808 Side 10

11 Implementering af PIC softwaren Dette afsnit vil beskrive hvordan designet er blevet til kode, og hvordan vi har løst de problemstillinger som ligger i kravspecifikationen og design. Overordnet set er koden meget stor, men der vil kun blive beskrevet funktionerne: Antal, scan_varer og Send. Funktionen Antal Funktionen Antal har som føromtalt, at sørge for at brugerens ønskede værdi gemmes i en variabel. Desuden sørger den for at udskrive vigtige informationsvenlige tekst på displayet til brugeren. Funktionen virker på den måde at den kører i en løkke indtil brugeren trykker på den trykknap som hedder enter. Inde i løkken tjekkes der om brugeren har trykket på tasten som hedder plus eller minus. Hvis dette er tilfældet tæller den lokale variabel a en op eller en ned og der skrives en informationstekst med den nye værdi af variablen a. Hele koden kan ses nedenfor. Inden funktionen afsluttes køres linjen: sprintf(number, %d, a);. Denne linje sørger for at int værdien i variablen a konverteres til en streng og gemmes i variablen Number. På billedet nedenfor ses hvordan funktionen virker, og at brugeren har tastet 3 gange på plus knappen og dermed en indgående varer. Lagerstyringssystem, 3itk0808 Side 11

12 Funktionen scan_varer Denne funktions eneste opgave, er at informere brugeren om at scanne RFI-tag med scanneren som er koblet til PIC en via RS232. Derefter venter rs_gets på at der kommer data fra RS232 porten. Når så funktionen rs_gets modtager data, gemmes dataen i den globale variabel som hedder TAG, og informere brugeren om at RFI-tagget er modtaget og gemt. Funktionen send Den sidste funktion i programmet, er send funktionen. Systemet kan kun fungere som en server og derfor må den vente på en klient sender data til WebNet/PIC en. Derfor er funktionen lavet sådan, at kommandoen for at modtage dataene er str, og når WebNet/PIC en modtager str sender WebNet/PIC en en datapakke til klienten som indeholder en sammensat streng, hvor de to globale variabler, Number(antal) og TAG(RFI-tag), er sat sammen, men adskilles af et + tegn. Der bruges et printf til at sende til klienten. For at sammensætte de to strenge bruges strcat som er en indbygget funktion i C, som kan sammensætte to strenge. Den indbyggede funktion strcat bruges to gange, da der skal sammensættes to variabler og et tegn. Lagerstyringssystem, 3itk0808 Side 12

13 På billedet nedenfor ses at programmet venter på at få en kommando fra klienten, og derfor venter på at sende datapakken. Lagerstyringssystem, 3itk0808 Side 13

14 Kravspecifikation database Baggrund Database funktionen er en del af lagerstyringsprojektet. Denne funktion skal hente, lagre og kunne vise de data der kommer fra pic og WebNet. Det er derfor vigtigt at få stillet kravene op for hvordan databasen skal fungere. Kunden vi laver databasen for, er en detailhandler som sælger sko til sportsforretninger i Danmark. Kunden vil gerne kunne lagre de data der kommer fra pic og WebNet og sidenhen kunne søge og redigere i disse data. Produkterne der skal laves en database over er begrænset til kondisko af forskellige typer til mænd og kvinder. De forskellige typer er igen begrænset til: indendørs sko, fodbold sko, løbesko, cykel sko og håndbold sko. Disse typer fås i forskellige brands, modeller, størrelser og i forskellige farver. Hvert produkt har sin egen leverandør, som indkøberen i detailhandlen aftaler en indkøbspris med. Denne pris bruges til at beregne salgsprisen med og er derfor vigtig for salgsafdelingen. Hos leverandøren er der én specifik kontaktperson, der kontaktes når der skal bestilles varer. Kontakt formen er: tlf. og mail. Yderligere vigtige oplysninger om leverandøren er: reg. nr. og konto nr. som anvendes ved betaling. Detailhandleren har som sagt kunder rundt om i hele landet. Selv om disse kunder kan være registreret under forskellige kæder (f.eks. intersport, sportigan osv.) handles der direkte med de enkelte forretninger. Hos kunderne skal der derfor registreres en kontaktperson pr. forretning. Med denne kontaktperson aftales salgspris og eventuelle rabatter. Kontakt formen er tlf. og mail. Yderligere vigtige oplysninger om kunden er: leveringsadressen. Alle produkterne placeres på ét lager. Lageret er opdelt i sektioner, hvor der står x antal reoler med y antal hylder. Når varerne kommer til lageret bliver de scannet og registreres med en placering på lageret. Når varerne tages ud af lageret bliver de scannet igen og registreringen om placering bliver slettet. Målet med denne database er at de enkelte brugere af databasen skal kunne oprette eksempelvis produkter, leverandører eller kunder. Der skal være mulighed for at søge på disse oplysninger ud fra forskellige kriterier, eksempelvis søge kunder ud fra postnummer eller produkter ud fra farve. De indtastede informationer skal selvfølgelig kunne redigeres og slettes. En fremtidig mulighed vil kunne være at detailhandlens kunder vil kunne tilgå databasen og udtrække forskellige informationer. Lagerstyringssystem, 3itk0808 Side 14

15 Bruger og aktører For at få overblik over databasesystemet skal vi finde ud af hvilke brugere der er af systemet og hvilke andre aktører der er. Brugerprofiler: Administratorprofil It-medarbejder som opretter, styrer og vedligeholder databasen Lagerkoordinatorprofil opretter placering. Sælgerprofil Sælgeren som skal have informationer om vare på lageret og informationer om kunderne. Køberprofil Indkøber som skal indtaste informationer om varen og leverandøren og kunne få informationer om hvilke varer der f.eks. skal genbestilles. Applikationer Der skal bruges forskellige applikationer til de forskellige profiler. Administrator: Der bruges det medfølgende software/program til MSSQL 2008 til vedligeholdelse, oprettelse af nye brugere, rettigheder og oprettelse af nye tabeller osv. Bruger: Der skal udvikles et brugerinterface i C#, som gør det let for brugerne at få adgang til informationerne i databasen. Brugerinterfacet skal være let forståeligt, være nem at overskue samt kunne betjenes af alle. Der skal være en opretfunktion, en søgefunktion, redigerings/slette-funktion i interfacet. De vigtigste søgekriterier for lagerkoordinatoren er produkt, sektion og hylde. For sælgerprofilen er det kundens navn, adresse, tlf., mail, produkter og produkternes attributter. For køberprofilen er det leverandørens navn, tlf., mail, produkter og produkternes attributter. Lagerstyringssystem, 3itk0808 Side 15

16 Analyse og Design af Database Brugerprofiler I kravspecifikationen er der listet 4 brugerprofiler, en administrator, en lagerkoordinator, en sælger og en køberprofil. Hver af disse profiler udfører specifikke opgaver i forhold til databassen. Figur 1. Administratoren skal i store træk have adgang til og mulighed for alt. Dvs. han er den der opretter databasen, styrer og vedligeholder den. Han opretter brugere og tildeler adgang for de enkelte profiler. Han sørger for at opsætte sikkerheden i forbindelse med server og database men også i forhold til brugerprofilerne. Er server og database ikke installeret og sat op er det også administratorens opgave. Lagerkoordinatorens opgave er primært at tildele en placering til de enkelte produkter og lagre den i databasen. Alt efter hvor mange der arbejder på lageret kunne det også være hans opgave at scanne varerne ind og ud. Sælgeren skal indtaste oplysninger, om de kunder han får kontakt med, i databasen. Disse oplysninger skal bl.a. bruges til at søge på f.eks. statistik af forskellig art eller hvis man skal i kontakt med den enkelte kunde. Han skal yderligere kunne redigere og slette i disse oplysninger. Køberen får oplysninger om produkterne og RFI-tag af leverandøren. Disse skal han indtaste i databasen og bruges til at søge efter og lave statistikker over. Køberen skal yderligere kunne redigere og slette i disse oplysninger. Produkter. Der er ikke nogen standard for oplysninger om produkterne fra de enkelte leverandører. Nogle leverandører skriver f.eks. meget om farve mens andre ingenting skriver. Men for at databasen ikke skal blive uoverskuelig og have standarder fra hver leverandør, påtænker vi at lave vores egen standard med Lagerstyringssystem, 3itk0808 Side 16

17 lige netop de oplysninger vi mener, er vigtige i søgesammenhæng. Produkterne kan beskrives ud fra mærke/brand, model, farve, sportstype, størrelse og om det er en herre eller dame sko. Leverandører. Det er vigtigt med oplysninger om leverandøren da, indkøberen f.eks. skal kunne finde oplysninger om leverandøren i forhold til, hvis han skal i kontakt med leverandøren eller skal kunne søge på oplysninger om hvilke eller hvor mange produkter der er købt fra den enkelte leverandør eller søge på indkøbspris. Kunder. Det er vigtigt med oplysninger om kunden da, sælgeren f.eks. skal kunne finde oplysninger i forhold til at kontakte kunden eller vide hvor produkterne skal sendes hen eller i forhold til at lave statistik over hvilke produkter der bliver solgt mange eller få af. Lager. På lageret skal der scannes varer ind og ud. Disse scannings oplysninger skal sendes til databasen og lagres så de indgående varer kan blive talt op og få tildelt en lagerplacering og de udgående varer kan blive reduceret i antal og evt. frigøre en lagerplacering. Datamodel Ud fra disse oplysninger er det oplagt at der først laves 4 tabeller. En tabel for produkt, en for leverandører, en for kunder og en for lageret. Produkt tabellen skal mindst indeholde informationer om hvilken type sko(løbe, indendørs, fodbold ), Brand (Nike, Adidas, Puma ), Model(Nike Air, Puma Vectana, Asics Blast ), Herre eller Dame sko, størrelse, Farve og antal. Leverandør tabellen skal mindst indeholde informationer om leverandørens navn, kontaktpersonens navn, mail, tlf. og informationer om bankforbindelse(reg. nr. og konto nr.). Købsprisen kan enten være i produkt tabellen eller i leverandør tabellen da denne attribut kan tilhører begge tabeller. Man kan også vælge at lave en ny tabel af relationen mellem produkt og leverandør og tilføje købsprisen. Kunde tabellen skal mindst indeholde informationer om Kundens navn og adresse, kontaktpersons navn, mail og tlf.. Salgsprisen og rabat kan tilføjes både produkt tabellen eller kunde tabellen eller de kan deles op med salgspris i produkt tabellen og rabat i kunde tabellen. Man kan også vælge at lave en ny tabel af relationen mellem produkt og kunde og tilføje begge attributter. Lager tabellen skal mindst indeholde informationer om det enkelte produkt (f.eks. i form af et ID nr. der referere til produkttabellen), sektion nr. og hylde nr.. Lagerstyringssystem, 3itk0808 Side 17

18 Sko_str HD_type Fnavn Mnavn Enavn ID Notater Købspris ID_Lev Navn RFI Antal Produkt Sko_type N Købspris 1 Leverandør Kontakt Mail Brand Farve 1 Model Salgspris Notater Kontonr Regnr Telefon 1 M Salgspris Rabat i % Notater ID_Kunde Navn N Telefon Pro_ID. Lager 1 1 Kunde Kontakt Lev adr Sektion Nr. Hylde Nr. Postnrby By Pnr. Postnr Adresse Mail Fnavn Mnavn Enavn Figur 2. ER-diagram over Sko databasen Figur 2 viser hvad vi har navngivet tabellerne og deres dertil hørende attributter. Der er de 4 tabeller: Produkt, Leverandør, Kunde og Lager. Produkt som er omdrejningspunktet i databasen er i relation til Leverandør, Kunde og Lager, men disse 3 er ikke i relation til hinanden. Relationen til Leverandør er en mange til 1 relation. Dvs. et produkt har kun 1 leverandør og 1 leverandør kan levere mange produkter. Relationen til Kunde er en mange til mange relation. Dvs. 1 kunde kan købe mange produkter og et produkt kan sælges til mange kunder. Relationen til lageret er en 1 til 1 relation. Dvs. et produkt har én placering og en bestemt placering har kun et produkt. Relationen Produkt Leverandør har vi valgt at kalde Købspris og lave til en selvstændig tabel. Vi har tilføjet attributten Købspris. Dette er gjort ud fra en betragtning af at der er forskel på købsprisen fra gang til gang. Dette kan bl.a. skyldes den globale økonomi, valutakurser, mængderabat osv.. Relationen Produkt Kunde har vi valgt at kalde Salgspris og lavet til en selvstændig tabel. Vi har tilføjet attributterne Salgspris og Rabat i %. Selv om salgsprisen er ens for alle kunder, så afgør rabatten den egentlige salgspris. Rabatten varierer fra kunde til kunde og fra salg til salg. Fordi den varierer så meget er det svært at placere den enten hos kunden eller på produktet, derfor er der lavet en selvstændig tabel. Relationen Produkt Lager har vi ikke givet noget navn og ikke lavet til en selvstændig tabel. Dette skyldes bl.a. at det er en 1 til 1 relation, hvilket betyder at de to tabeller indeholder alle de relevante informationer der skal kunne udskrives fra relationen. Lagerstyringssystem, 3itk0808 Side 18

19 Der er oprettet en selvstændig tabel Postnrby, som er en tabel med samtlige postnumre og deres relationer til byerne i Danmark. Denne tabel er en såkaldt svag entitet, hvilket skyldes at den refererer til en allerede oprettet attribut i en anden entitet. Mail og Telefon attributterne i henholdsvis Leverandør og Kunde har 2 cirkler, hvilket betyder at det er en multi-valued attribut. Dvs. at der kan være mere end 1 forekomst i lige netop denne attribut. F.eks. kan der være mere end 1 telefon nummer til kontaktpersonen hos kunden. Lev adr i Kunde og Kontakt i henholdsvis Leverandør og Kunde er det der kaldes en composite attribute. Dvs. at attributten består af flere oplysninger som derfor kan deles op i flere attributter. Produkt ER-Skema ID RFI Brand Model Sko_type HD_type Sko_str Farve Antel Notater Købspris P_ID L_ID Købspris Leverandør ID_Lev Navn Telefon Fnavn Mnavn Enavn Mail Regnr Kontonr Notater Salgspris P_ID K_ID Salgspris Rabat i % Kunde ID_Kunde Navn Telefon Fnavn Mnavn Enavn Mail Adresse Postnr Notater Lager Pro_ID Sektion Hylde Post Nr. Post Nr. By Figur 3. ER-skema over Sko databasen Som det ses i ER-skemaet er Lev adr og Kontakt -attributterne fra ER-diagrammet ikke med, da de kun er med i diagrammet for at illustrere hvad de underliggende attributter handler om. For at gøre de enkelte produkter, leverandører og kunder identificerbare, har vi udstyret hver tabel med et unikt id nummer. Dette gøres bl.a. for at undgå redundant data og for at kunne gøre søgninger så specifikke Lagerstyringssystem, 3itk0808 Side 19

20 som muligt. Disse id numre gøres til det vi kalder for Primary Key(PK eller primær nøgle) for de enkelte tabeller(pk er illustreret med understregning i både ER-skema og ER-diagrammet). Nøglerne vil nu kunne bruges til identifikation af de enkelte tubler eller forekomster i tabellerne og dermed vil en avanceret kombineret søgning blive mulig. Implementering Når vi starter på at implementere databasen på serveren skal vi først finde ud af hvilke datatyper de enkelte attributter skal være og hvor meget plads der skal afsættes til hver enkelt. Dette er bl.a. vigtigt i forhold til at finde ud af hvor stor lager kapacitet der er behov for. Figur 4. Oversigt af datatyper fra Sko databasen Figur 4. viser en oversigt over 3 tabeller. I hver tabel er der listet attributterne i første række, datatypen i anden række og en funktion der fortæller om attributten må stå tom eller der skal indsættes data for at være gyldig. Som det ses i både Kunde og Leverandør tabellen er Mnavn sat til at være en char på 1 karakter, hvilket betyder at der bliver sat lagerkapacitet af i hukommelsen til max. 1 karakter for denne attribut. Samtidig er funktionen Allow Nulls sat til, hvilket betyder at attributten godt må stå som uden at den enkelte tuple bliver erklæret ugyldig. Når datatyperne er fastsat kan database opsætningen sættes i gang. Først startes med at oprette databasen(dette gøres med create database Sko_database ). Dernæst de enkelte tabeller med deres attributter, datatyper, Allow Nulls, Primary Keys og Foreign Keys. Syntaksen til opret tabel kunne f.eks. se sådan ud: - use Sko_database; create table Produkt( ID varchar(20) NOT NULL, RFI int NOT NULL, Lagerstyringssystem, 3itk0808 Side 20

21 Sko_type varchar(25) NOT NULL, Brand varchar(25) NOT NULL, Model varchar(25) NOT NULL, Farve varchar(25) NOT NULL, HD_type varchar(10) NOT NULL, Sko_str float NOT NULL, Antal int NOT NULL, Beskriv text, Primary key (ID), Unique (RFI)); Dette vil oprette Produkt tabellen som vist i figur 4. med ID som PK og RFI som en unique attribut. Disk Usage by Top Tables [Sko_database] on DITLEV-PC\SQLEXPRESS at :41:37 This report provides detailed data on the utilization of disk space by top 1000 tables within the Database. Table Name # Records Reserved Data (KB) Indexes (KB) Unused (KB) dbo.produkt (KB) dbo.salgspris dbo.sysdiagrams dbo.leverandoer dbo.kunder dbo.lager dbo.postnrby dbo.koebspris Figur 4a. Oversigt over de enkelte tabellers forbrug af data samt reserveret diskplads. Tabellen i figur 4a. viser hvor mange forekomster (tubler) der er registreret i hver tabel. Til disse forekomster er der reserveret noget lagerplads. Dette er bestemt ud fra hvordan vi har oprettet databasen og tabellerne. Vi kan endvidere se hvor meget plads vi reelt set har brugt og hvor meget af den reserverede plads der ikke er i brug. Dette skema kan vi bl.a. bruge til at reducere den ubrugte diskplads samt få et overblik over hvor meget lagerkapacitet der egentligt er brug for. Lagerstyringssystem, 3itk0808 Side 21

22 Produkt ID RFI Sko_type Brand Model Farve HD_type Sko_str Antal Beskriv Koebspris P_ID L_ID Koebspris Leverandoer ID_Lev Navn Fnavn Mnavn Enavn Telefon Mail Regnr Kontonr Notat Lager Pro_ID Sektion Hylde Salgspris P_ID K_ID Salgspris Postnrby * Pnr City Kunder * ID_Kunde Navn Fnavn Mnavn Enavn Adresse Postnr Telefon Mail Notat Figur 5. Database diagram over Sko databasen. Figur 5. viser de enkelte tabeller, deres attributter, nøgler og nøglernes forbindelser. I Produkt er ID Primary Key, i Leverandoer er ID_Lev Primary Key og i Kunder er ID_Kunde Primary Key. I Lager referere Pro_ID som er Foreign Key til ID i Produkt. Det samme gør P_ID i henholdsvis Koebspris og Salgspris. L_ID i Koebspris er Foreign Key og referere til ID_Lev i Leverandoer. Det samme gælder K_ID i Salgspris i forhold til Kunder. Pnr i Postnrby referere til den unikke attribut Postnr i Kunder. Når disse tabeller er lavet, mangler der bare at blive lagt nogle data ind så vi kan teste om databasen virker som den skal. Når vi nu ikke har et brugerinterface endnu kan data læses ind i databasen med nogle simple kommandoer. Syntaksen for et produkt kunne f.eks. være: - use Sko_database; insert into Produkt values ( , , Håndboldsko, Nike, Nike Free, Black 1, Herre, 33, 200, denne sko er god ) Første produkt er nu indskrevet i databasen med: ID, RFI, Sko_type, Brand, Model, Farve, HD_type, Størrelse, antal og beskrivelse. I stedet for at lave mange insert strenge, er det muligt at indtaste alle informationer i f.eks. et excel ark og derefter importere det til databasen. Lagerstyringssystem, 3itk0808 Side 22

23 Test af databasen Inden vi sender den nylige konstrueret database til kunden skal vi have lavet nogle tests for at sikre os at der ikke er lavet fejl og at systemet kører optimalt. Det skarpe øje har sikkert opdaget at i ER-diagram og ER-skema har vi lavet en attribut der hedder Rabat under Salgspris og at denne attribut ikke er med i implementeringen. Dette har været et bevidst valg. Rabat -attributten har vi tænkt skulle bruges til at teste Alter table - og Update - funktionerne. Disse funktioner bruges til at tilføje attributter og til at opdatere dem. Desværre nåede vi ikke at afprøve Alter table inden deadline. Derimod fik vi afprøvet Update -funktionen. Heldigvis havde vi forinden denne test lige snakket om at få lavet en backup af databasen, for vores første forsøg endte med at samtlige produkter blev ændret og kunne ikke ændres tilbage. Hurra for backup. Med en intakt database har vi afprøvet forskellige select sætninger for at se om der har været forbindelse mellem tabellerne. Disse tests har alle givet positive og valide resultater og vi konkludere derfor som udgangspunkt at databasen er opsat rigtigt og funktionsdygtig. Sikkerhed Vi har desværre ikke nået at få implementeret nogen form for sikkerhed i forhold til databasen inden deadline. Men her er nogle af de overvejelser vi har gjort os igennem projekt forløbet. Når en bruger tilgår databasen har han i princippet tilladelse til at gøre alt. For at undgå dette vil det være hensigtsmæssigt at dele brugerne op i grupper og tildele forskellige adgangsrettigheder til disse. Så undgår man unødig og ukontrolleret tilgang til databasen. For at identificerer en bruger skal det være obligatorisk at man skal logge sig ind med brugernavn og adgangskode. Så vil brugeren blive identificeret som medlem af en given gruppe og dermed få tildelt bestemte adgangsrettigheder. Når nu databasen er koblet på internettet vil der være mulighed for at personer med ikke reelle hensigter vil kunne få adgang til databasen. For at undgå de fleste af disse angreb kan der opsættes en firewall på serveren. Denne vil nægte alle der ikke har autorisation adgang. Som vi beskrev tidligere var det ved at gå galt for os under testningen af databasen. Vi undgik kun katastrofen ved at vi lige havde lavet en backup. Heldigt for os, men man kan ikke altid være heldig. Så for at sikre at vi altid har en up to date backup at falde tilbage på vil det være hensigtsmæssig at opsætte serveren til at lave en backup regelmæssigt. Hvor ofte der skal laves backup afgøres typisk af databasens indhold. Lagerstyringssystem, 3itk0808 Side 23

24 Design af GUI en. For at de enkelte brugere kan tilgå databasen, er det nødvendigt med en brugergrænseflade(gui). I dette afsnit vil vi kort gennemgå use-cases og templates for at illustrere hvordan vi har tænkt GUI en skal se ud. De enkelte brugerprofiler er beskrevet i databasens kravspecifikation og design. Figur 1. Use-case diagram over GUI en. Figur 1. viser hvilke funktioner de enkelte brugere har brug for. Administratoren er ikke vist i figur 1. da han ikke skal bruge GUI en, men kun redigere i den. Som det ses i figur 1. har hver bruger de samme 4 Lagerstyringssystem, 3itk0808 Side 24

25 funktioner: opret, søg, rediger og slet. De enkelte funktioner fungerer dog forskelligt fra bruger til bruger. Dette er tydeligere beskrevet i de forskellige templates (Bilag B). Implementering af GUI Dette afsnit vil beskrive hvordan GUI en er udviklet ud fra use-cases og designfasen til kode og et grafisk interface mellem brugeren og databasen. Tidligere omtalt består designet grov sagt af en opret, søge, rediger og slet funktion. Disse funktioner skal dække kundens og brugerens behov, for at styre og bruge databasen. Udvikling af opret-funktionen Der skal laves fire forskellige opret-funktioner(1): opret produkt, leverandør, kunde og lager plads. Som det kan se på billedet nedenfor er det delt op i faneblade, alt efter hvad man skal oprette. Her ses siden til at oprette et produkt, som er den jeg vil fortælle om, der det er den mest avanceret af de fire og de ligner hinanden så jeg vil ikke skrive om alle fire. Lagerstyringssystem, 3itk0808 Side 25

26 Vi har prøve at lave det let og overskueligt at bruge, så man ikke behøver at få flere timers undervisning for at kan finde ud af det. Vi har lavet det så at man ikke kan lave for mange indtastnings fejl, ved fx at låse nogen af felterne(2), så man kun kan vælg imellem nogen udvalgte. Vi har også gjort sådan at programmet går ind og kontrollere om der er skrevet noget i de der skal stå noget i og om ID og RFI har den rigtig længde. Der er to opret-knapper. Den ene hedder Opret og indtast ny str. (3). Den gør det at den opretter produktet i databasen, men den sletter ikke alle oplysningerne som man har indtastet, for hver sko str. har hver sit ID-nr. og RFI-nr.(4). Så når man skal oprette flere str. af samme sko skal man ikke til at indtaste det hele være gang, og når man har indtast alle skostørrelserne trykker man på Opret og ryd alt (5) og man er klar til en ny sko. Her er et udkast af koden til opret produkt. Her er det koden til hvis man trykker på Opret og indtast ny str. 1. Her bruger vi en if til kontrollere om der står nogen i de felter som der skal og om dem der har en bestemt længde, har den rigtig længde 2. Her konverterer vi de indtastede oplysninger så de passer ind i databasen, og putter dem ind i nogle variabler. 3. Her kører vi en funktion som står for at sende variabler med de indtastede oplysninger til databasen og indsætter dem i det rigtige sted. I opret produkt skal der indsættes i to tabeller så derfor er der to funktioner. 4. Her er det hvor vi rydder de felter som skal, så man kan indtast en ny str. 5. Her er den else til if en, så hvis man indtast nåde forkert kommer der en besked om det. Lagerstyringssystem, 3itk0808 Side 26

27 Udvikling af søgefunktionen Udvikling af søgefunktionen bestod af flere dele, da der skulle udvikles en søge-funktion til søgning i tabellen med produkter, leverandører, kunder, lagerplacering, samt de to tabeller med købspris og salgspris. Dette gjorde at disse i alt 6 søgefunktioner skulle laves forskelligt og SQL-sætningerne skulle laves forskelligt. Desuden skulle søgefunktionen specielt til produkt-tabellen laves fleksibel, så brugeren har mulighed for at kombinere flere søgestrenge og dermed indkredse søgning til et bestemt produkt, da der sandsynligvis vil være mange tubler(rækker) i databasen. Derfor vil der i dette afsnit kun blive gået i dybden med søgefunktionen til produkter. Et eksempel på en mulig SQL-sætning som er opsat i søgefunktionen til produkt: else if (Antal!= "" && SkoStr!= "" && (Brand!= "" Model!= "" Type!= "" HDType!= "" Farve!= "")) { querystring = "SELECT * FROM Produkt WHERE Brand LIKE '" + Brand + "%' and Model LIKE '" + Model + "%' and Sko_type LIKE '" + Type + "%' and HD_type LIKE '" + HDType + "%' and Sko_str = '" + SkoStr + "' and Farve LIKE '" + Farve + "%' and Antal = '" + Antal + "'"; loaddatagrid(querystring); } Det kan ses i dette eksempel at if-statement er opsat til at både antal og skostr skal være forskellige fra ingenting, samt brand, model, type, HDtype eller farve skal være forskellig fra ingenting. Hvis dette er tilfældet bruges SQL-sætningen som står i strengen querystring og derefter eksekveres SQL-sætning og resultatet vises i datagriden, som gøres i funktionen loaddatagrid(querystring). Med denne SQL-sætningen kan brugeren søge i alle attributter undtagen RFI og ID. Som det ses i kodeeksemplet, er der i SQL-sætningen et % -tegn efter hver attribut som består af en streng. Dette er for at hjælpe brugeren, fx hvis brugeren skriver NIKE under model, vises alle tubler hvor starten af ordet i model hedder NIKE. Dette betyder at søgningen medtager alle tubler, hvor ordet NIKE er de første fire bogstaver under model. Lagerstyringssystem, 3itk0808 Side 27

28 Test af søgefunktion På billedet nedenfor ses et eksempel på en eksekvering af SQL-sætningen i programmet. Som det kan ses på billedet, søger brugeren efter Brand = Nike, Sko Type = Indendørssko, H/D Type = Herre, Sko Str = 43 og Antal = 175. I datagriden ses resultatet af søgningen som har fundet 3 tubler, hvor alle søgeordene indgår. På billedet kan man se, at ID er opdelt i 4 tekstbokse, dette skyldes at brugerne ikke skal skrive bindestreg mellem hvert tal, dette sørger programmet selv for og skifter også selv til næste tekstboks, når boksen har de nødvendige cifre. Tekst boksen med RFI, er også fastsat til max 8 cifre. Redigerefunktion Ligesom søgefunktionen bestod redigere funktionen af flere dele, da man skulle redigere tupler i de forskellige tabeller. Måden denne funktion er lavet på, er ved at tilføje en knap i datagriden, som er et objekt i C#, hvor alle søge resultater bliver vist i. Knappen er derfor sat udfor hver eneste forekomst af tubler. Når man trykker på redigereknappen åbner et nyt vindue, hvor alle informationer fra tuplen er indsat i de forskellige tekstbokse. For at redigere skal brugeren bare ændre teksten i en eller flere tekstbokse og når det ønskede indhold er ændret, trykkes på knappen update og tuplen er opdateret med det nye indhold. Kodeeksempel nedenfor viser, hvordan værdierne i kolonnerne tildeles variablen og konverteres til en string. Her bliver værdien i kolonne 0 og 1, sat i henholdsvis variablen ID og RFI. string ID = datagridview1[0, currentrow].value.tostring(); string RFI = datagridview1[1, currentrow].value.tostring(); Lagerstyringssystem, 3itk0808 Side 28

29 Dette kodeeksempel nedenfor opretter en ny form2 som hedder f2, og værdierne som er i ID og RFI tildeles variablerne ID og RFI som er i form2. Kort sagt hentes værdierne i tuplen igennem form1, men bliver kopieret over og bliver brugt i form2. Form2 f2 = new Form2(); f2.id = ID; f2.rfi = RFI; Test af redigeringsfunktionen Billedet nedenfor viser et eksempel på en redigering af informationer i en forekomst i produkttabellen. I dette eksempel, ses at farven på tuplen hedder hvid, men bliver ændret til white og brugeren får en besked, hvor redigeringen er sket vellykket. Som det ses er værdierne indsat i de forskellige tekstbokse til hjælp for brugeren og det er ikke muligt for brugeren at ændre ID nummeret. Lagerstyringssystem, 3itk0808 Side 29

30 Delete-funktion Denne funktion er lavet på samme måde som redigere-funktionen, ved at tilføje en knap i datagriden med navnet delete udfor hver eneste tupel. Når man trykker på knappen udfor tuplen, slettes hele tuplen fra databasen. Billedet ovenfor viser at brugeren har valgt at slette den forekomst, som er markeret blå. For at informere brugeren om sletningen er gået godt, får brugeren en meddelelse tilbage. Billedet nedenfor bekræfter at sletningen er foregået korrekt. Lagerstyringssystem, 3itk0808 Side 30

31 Konklusion I dette projekt har vi arbejdet ud fra titel Lagerstyringssystem, med udgangspunkt i temaet Embedded Web. Ud fra denne titel og tema, skulle der minimum opbygges en lokal enhed som består af en WebNet/PIC16 enhed, hvor man kan scanne varer ind og ud af et lager. Derudover skulle der opbygges og udvikles en database, samt en tilhørende brugergrænseflade til databasen. Hele projektet har været delt op i to dele som bestod af en WebNet og PIC del, og en databasedel. Meningen var derfor at lave den ene del færdig, før man begyndte på næste del af projektet. Dette forløb også rimelig godt, WebNet/PIC delen blev dog først rigtig færdig et par uger inde i undervisning af database, men dette drejede sig mest om test og finpudsning af softwaren til PIC en. Dog var programmeringen af softwaren til PIC en ikke særlig glat, da vi midt i programmeringen blev klar over at rammene på PIC en ikke være store nok til at skabe det ønskede design og derfor måtte der laves en mindre ændring i softwaren. Det må dermed også konkluderes at et client/server som skulle bringe dataene fra WebNet/PIC en til databasen ikke blev færdigudviklet og derfor er udeladt fra rapporten, da vi havde store problemer med at skabe forbindelse til WebNetten. Databasedelen må siges at være forløbet rimelig glat, da vi hurtig fik uddelegeret opgaverne i databasedelen og programmeringen af GUI. Men disse opgaver blev først givet ud, da vi var ovre designet af database og GUI. En person havde hovedansvaret for databasen og input af data og informationer til videre brug i test, samt opbygningen. De to andre delte GUI programmeringen op og dermed havde ansvaret for det. Dermed brugte vi tiden optimalt for at skabe et godt produkt. Det kan derfor konkluderes i databasen delen at databasen blev fuld funktionsdygtig i forhold til vores design og GUI en også blev rimelig funktionsdygtig, da man i denne både kunne oprette nye data, søge i data, redigere data og slette data i de forskellige tabeller. Dog blev det ikke muligt at skabe en brugergrænseflade til de to relationstabeller i databasen, hvor man kunne søge, redigere og slette, men opret funktionen blev funktionsdygtig. Samlet set må det siges at WebNet og PIC programmet blev en delvis succes, da man som bruger kan indtaste, scanne og sende data, men pga. manglende understøttelse af protokol direkte til database og manglende ram på PIC en, må denne del ses som ufærdigt og ikke fejlfri. Derimod anses databasen delen og GUI en som en succes, hvor vi har formået at skabe en funktionsdygtig database og en tilhørende brugergrænseflade, som kan bruges af brugerne. Der kan dog altid blive lagt mere på brugergrænsefladen af funktioner og brugervenlighed. Hvis man tager hele projektet i betragtning synes vi, at vi samlet set har skabt et godt produkt og gjort mange overvejelser omkring programmeringen og det kun har været tiden som har sat grænsen for, hvor mange små funktioner og detaljer som kunne tilføjes produktet. Alt i alt et lærerigt projekt, som har været spændende og sjovt at udvikle. Lagerstyringssystem, 3itk0808 Side 31

32 Bilag Bilag A Main Init Antal Scan_varer Send RS232 Driver WebNet Driver LCD Driver Knap 1 Knap 2 Knap 3 RFI-Scanner WebNet LCD Lagerstyringssystem, 3itk0808 Side 32

33 Bilag B Lagerstyringssystem, 3itk0808 Side 33

34 Lagerstyringssystem, 3itk0808 Side 34

35 Lagerstyringssystem, 3itk0808 Side 35

36 Lagerstyringssystem, 3itk0808 Side 36