Projekt database http://bysileha.com/3.semester/database-eshop/index.html (vores htmlside) Amanda Lindschouw - cph-al144@cphbusiness.dk http://ahldesign.dk/learningthird.html Charlotte Øberg - cph-co74@cphbusiness.dk http://charlotteoeberg.dk/semester3.html Simone Hansen - cph-sh248@cphbusiness.dk http://bysileha.com/x/cph.portfolio/3-semester-1-database/ Michelle Andersen - cph-ma236@cphbusiness.dk http://michelle-denise.dk/portfolio-skole/ Gruppe nr. MULB5, Multimediedesign hold B. Tue Becher Ivan Rosenvinge Frederiksen 1
Indholdsfortegnelse GRUPPEKONTRAKT Side 3 INDLEDNING Side 3 UDVIKLINGSMETODE Side 4 PBS Side 4 WBS Side 5 ER Side 6 ATTRIBUT TABEL Side 8 NAVIGATIONSSYSTEM Side 9 HTML Side 9 FUNKTIONELLE KRAV Side 9 User story Side 9 Nødvendige kompetencer Side 11 Use case Side 12 Beskrivelse af UC04: Side 13 Beskrivelse af UC07: Side 14 Beskrivelse af UC08: Side 15 NON-FUNKTIONELLE KRAV Side 16 CRUD-MATRIX Side 16 KONKLUSION Side 17 LITTERATURLISTE Side 18 2
Gruppekontrakt Vi har valgt at lave en gruppekontrakt over vores forventninger til deltagelse i projektet. Hvis de valgte punkter ikke overholdes, gives der tre chancer, hvor der derefter tages stilling til, om den/de person(er) fortsat kan deltage i samarbejdet. 1. Alle mødetider og aftaler skal overholdes, da disse bliver lavet i samarbejde med resten af gruppens medlemmer. 2. Ved sygdom eller andre pludselige gøremål, skal gruppen kontaktes så hurtigt som muligt. 3. Alle deadlines skal overholdes og hjemmearbejde skal laves til aftalte tidspunkt, så vores projektplan overholdes bedst muligt. 4. De fleste opgaver laves samlet i gruppen, så alle får det maksimale ud af projektet og lærer mest muligt. Derudover skal alle være inde over hver opgave så meget det er muligt. Der tages dog forbehold for tidspres, hvor arbejdsopgaverne så vidt muligt vil blive uddelegeret, for at overholde valgte deadline. Indledning I dette projekt skulle vi vælge en hjemmeside og lave en e-shop løsning til den. Vi har valgt hjemmesiden Den Lille Have, som er en lille hjemmeside med tilhørende e-shop. Da ejeren ønsker en ny e-shop, vil vi lave et udkast til hvordan den kan fungere. Vi vil udarbejde en række analyser og modeller (bl.a. ER-model og CRUD matrix), for at sikre at interaktionen mellem kunden og databasen kommer til at fungerer optimalt og de nødvendige funktioner er på plads. Dette er nødvendigt for at finde ud af, hvordan databasen skal bygges op, men også for at vi kan uddele rettighederne mellem kunden og administratoren. Udover disse ting, vil vi lave en html side, for at vise hvordan vi mener hjemmesiden skal se ud således at vi har nogle retningslinjer for hvad det egentlig er vi skal kode til. Derudover vil vi tage stilling til nogle non-funktionelle krav, som vi mener, er vigtige når man blandt andet har med personfølsomme oplysninger at gøre. 3
Udviklingsmetode Vi har valgt at arbejde med metoden prototyping, hvor vi i projektets to uger, har lavet éet sprint. Dette sprint har vi lavet i et Gantt kort over. Grunden til at vi har lavet et Gantt kort er, at selve sprintet har en afslutningsdato og derfor er der mulighed for at bruge Gantt til dette, selvom metoden prototyping fortsætter og kører i en spiral. Product Breakdown Structure (PBS) Vi har lavet en PBS til at analysere og dokumentere den e-shop som vi skal lave. Vores tre hovedpunkter er selve databasen, funktionaliteten og websitet. Over databasen laver vi en ER-model i 3.NF for at analysere relationerne mellem attributterne. På baggrund af den kan vi lave en attribut tabel til specificere værdierne for attributterne. Dernæst har vi lavet en CRUD matrix. For at analysere funktionaliteten af e-shoppen har vi lavet en user story og use cases, som gør at vi kan se hvilke krav vores e-shop skal have i forhold til brugere som er administrator og kunderne. 4
Work Breakdown Structure (WBS) Vi har valgt at lave vores WBS i et Gantt-kort, hvor arbejdstimer pr person er udregnet ud fra en 3 punkts estimering, hvor vi tog ét optimistisk, ét sandsynlige og én pessimistisk og beregnede ud fra dem. Det er godt til at sikre et realistisk bud på arbejdstimer. Måden vi har beregnet det på er, at vi tog tre bud fra tre gruppemedlemmer. Derefter tog vi A + B *3 + C og dividere det med 5. Vi havde disse tre bud på, hvor lang tid det tog én person at have en PBS. 1. person sagde: 2 timer 2. person sagde: 4 timer 3. person sagde: 3 timer. Derefter regnede vi det ud således: 2 + 3*3 + 4 = 15 15 / 5 = 3 og det blev vores resultat. Vi har også taget udgangspunkt i, at folk ikke arbejder 100 procent hele tiden og de også holder pauser og har personlig tid. 5
ER-diagram Customers: Customers har én primary key og én foreign key. De to keys består kun af tal (INT=integers). De øvrige attributter består henholdsvis både af tal (INT) og bogstaver (varchar=variable character). Foreign key peger på tabellen Zipcode. Zipcode: En kunde kan kun have en Zipcode. Zipcode-tabellen indeholder et unikt id/primary key med datatypen INT, som peger på foreign key i customers-tabellen. Derudover har denne tabel et bynavn med en varchar datatype, hvor man max. kan indtaste 30 tegn. Et postnummer kan have mange eller ingen kunder. Orders: Orders har en primary key og en foreign key som begge er INT. RecievedDate og ShippingDate er begge datofelter og StatusOrder er en varchar til max. 45 characters. En ordre kan kun have én kunde, men kan have mange produkter og en ordre skal have minimum ét produkt. Products_has_Orders Products_has_Orders består af to primary keys som begge har datatypen INT. Desuden består den af en attribut, vi kalder Quantity, som er INT og som fortæller hvor mange varer der er valgt. Entiteten Products_has_Orders skal fortælle os hvilket produkt kunden har valgt ved hjælp af Product_ProductNo. Orders_ordersID linker over til orders. Products: Products består af en primary key og en foreign key som peger på producttype og en række attributter med oplysninger om produktet. Produktet kan være i en eller flere ordrer. ProductType: ProductType består af en primary key som er en INT og Category som er en varchar der beskriver i hvilken kategori produktet hører ind under. 6
7
Attribut tabel Vi har lavet en attribut tabel over entiteterne og deres attributter. Hvilket giver et overblik over hvordan det skal hænge sammen i vores database. Vi har seks entiteter som danner rammen om vores database. Alle attributter har en datatype og en værdi, for at vise hvad de enkelte attributter består af. For eksempel kan CustomerID kun bestå af tal og den skal have seks værdier. Attribut tabellen uddyber vores ER, hvor vi i denne nedskriver datatypen og værdier, som vi ikke har angivet i vores ER. I fremtiden vil vi dog sortere i placeringen af attributterne, så det bliver nemmere at kode. Så vi eksempelvis har roller før Zipcode_zipID, da Zipcode_zipID er en foreign-key fylder den mere i koden. 8
Navigationsdiagram Vi har lavet et navigationsdiagram over vores side, for at få struktur og give et bedre overblik over sidens størrelse og hvad den skulle indeholde. HTML Vi har lavet en lille hjemmeside, som vi dog ikke har brugt til noget efterfølgende men vi har valgt at vedhæfte den, da vi har brugt ressourcer på den. Da design og layout ikke var en del af opgaven, har vi ikke lagt stor vægt på dette på vores website. Vi kan dog bruge den i dette projekt til at sætte nogle retningslinjer for hvad det er vi gerne vil have skal kodes i e-shoppen. http://bysileha.com/3.semester/database-eshop/index.html Funktionelle krav User story Vi har lavet en user story over indtastning af information fra kunden, ved køb af et produkt på e-shoppen. Selvom man ikke kan lave både en user story og en use case, som vi har gjort, har vi valgt alligevel at gøre det for at øve os i at lave begge dele. Her ses hvordan e-shoppen ser ud, når en kunde skal indsætte informationer, for at få varen tilsendt. Kontaktformularen skal valideres, så kunden ikke kan få lov til at gennemføre et køb, før nogle af felterne er udfyldt korrekt. Derudover er der på bagsiden en oversigt over, hvilke fejlmeddelelser man kan få, hvis der er sket en fejl. 9
10
Nødvendige kompetencer for brug af e-shop: For at give et bedre overblik valgte vi at lave en oversigt over de forskellige muligheder kunder og administrator skulle have, på den måde var det langt nemmere for os at begynde på vores use cases og user story. Kunder har rettigheder til at: - Finde et produkt eller søge efter produkter og købe ved hjælp af e-shoppen. - Vælge produkter og se deres total pris + antal, når man har tilføjet dem til e-shoppen. - Bestille en ordre for de ønskede produkter, ved hjælp af en shopping kurv. - Betal for ordren (ved hjælp af en betalingsordning) - Ret i ordren inden den bestilles Administrator har rettigheder til at: - Adgang til de produkter der tilbydes - Adgang til en elektronisk shopping kurv - Behandle en ordre - Oprette en varer - Oprette en ordre - Tildele rettigheder 11
Use Case: Vi har lavet en use case med det formål at kunne vise, hvilke roller henholdsvis administratoren og kunderne har på vores e-shop. Vi har valgt at administratoren har adgang til alt. Nedenfor er 3 af use casene beskrevet i detaljer: 12
Beskrivelse af UC04: Navn: UC04 Identifikation: Denne use case viser hvem, der kan se varer som er oprettet på siden. Beskrivelse: Når der er oprettet varer i systemet skal det være muligt at se dem på siden. Dette er også en forudsætning for at kunden kan vælge en vare. Mål: Målet med denne use case er, at kunne se de varer der er i e-shoppen. Forudsætninger: 1. Administrator skal først oprette sig i systemet. 2. Der skal oprettes varer i systemet før man kan se dem i e-shoppen. Hyppighed: Denne use case er muligvis den der bruges mest. Er man landet på hjemmesiden for at shoppe er det en forudsætning at man kigger på varerne. Derfor vil hyppigheden være på mindst 100 gange om dagen. Grundforløb: 1. Use casen begynder når administrator/kunder går ind på siden. 2. Derefter kan kan administrator/kunder enten søge efter en varer eller blot få vist alle e-shoppens varer i en liste. Efter grundforløb: Efter kunden har set produktet skal det være muligt at vælge og købe det. Aktører: I denne use case er der to aktører nemlig kunder og administrator. Det er en forudsætning for kunden at kunne se varerne hvis han/hun skal købe dem. Men også administrator skal kunne se sine varer på hjemmesiden. 13
Beskrivelse af UC07: Navn: UC07 Identifikation: Denne use case viser hvem der kan oprette varer i databasen. Beskrivelse: For at en kunde skal kunne vælge og købe varer, skal der være nogle varer at vælge imellem i databasen. Administrator skal derfor sørge for at oprette varer, som kunden kan købe. Mål: Målet med denne use case er, at tilføje varer til databasen, således at administrator kan sælge dem. Forudsætninger: 1. Administrator skal oprette sig først i systemet. Derefter kan han oprette varer i alle systemets tilstande. Hyppighed: Denne use case bruges hver gang administrator skal oprette en ny varer til systemet. Da det er en lille shop, vil administrator ikke oprette varer så tit. Måske 2 gange om måneden. Grundforløb: Use casen begynder når administrator har logget sig ind i systemet. Varens type skal først oprettes. Dette kan administrator gøre ved selv at indtaste en varetype hvis varens type allerede er oprettet springes dette trin over. Administrator opretter en vare ved at indtaste de nødvendige informationer samt vælge en varetype Use casen afsluttes når varen er oprettet i databasen Efter grundforløb: Varen er nu oprettet i databasen og kunder kan gå ind på hjemmesiden og se/vælge produktet. Aktører: Der er kun en aktør i denne use case;; administratoren. 14
Beskrivelse af UC08: Navn: UC08 Identifikation: Denne use case viser hvem der kan vælge produkter til indkøbskurven på hjemmesiden. Beskrivelse: For at en kunde skal kunne købe varer på hjemmesiden, skal det først være muligt at vælge varerne, hvilket er hvad denne use case bruges til. Mål: Målet med denne use case er, at tilføje varer til indkøbskurven således at det derefter er muligt at kunne betale for dem. Forudsætninger: 1. Kunden skal se/finde de varer han/hun gerne vil købe. 2. Derefter skal det være muligt at han/hun kan vælge de varer som de gerne vil købe ved at trykke på læg i indkøbskurv Hyppighed: Denne use case bruges hver gang kunden har fundet en varer, som han/hun vil lægge i indkøbskurven. Dette sker omkring 10 gange om dagen. Grundforløb: 1. Use casen begynder, når kunden har set på et produkt og gerne vil lægge det i indkøbskurven 2. Kunden trykker på en knap, der skal gøre at varen bliver lagt i indkøbskurven 3. Use casen slutter dermed når varen er valgt og ligger i indkøbskurven Efter grundforløb: Den/de valgte vare(r) ligger nu i indkøbskurven og kunden kan gå videre til betalingen. Navn: I denne use case er der to aktører;; kunde og administrator. 15
Non-funktionelle krav Sikkerhed: Når kunden angiver personlige oplysninger, skal disse ikke kunne ses af andre end administratoren. Hvis kunden har været inaktiv i mere end 30 minutter og ikke har valgt at gå videre med købet, skal de indtastede oplysninger slettes automatisk. Dette vil sikre at kundens oplysninger ikke vil blive misbrugt. Performance: Websitet skal have en hurtigt response, billeder skal loade hurtigt og siden skal kunne refreshes hurtigt. Shopping kurven skal opdateres og priserne rettes alt efter varerne i kurven med det samme. Kapacitet: Da websitet primært skal fungere som e-shop, skal det have så stor kapacitet at 300 kunder kan bruge e-shoppen på samme tid. Siden skal samtidig kunne gemme en del data, da e-shoppen i fremtiden skal kunne udvide med flere produkter. Tilgængelighed: Websitet skal være tilgængeligt 24/7. Vedligeholdelse skal ske på tidspunkter, hvor der er færrest kunder, helst om natten, og siden skal altid være tilgængelig mens der er vedligeholdelse, hvis dette ikke er muligt skal det gøres, så det er til mindst mulig chikane for kunderne. Pålidelighed: E-shoppen må ikke være nede mere end 3 gange på et år. Der skal tages daglig backup af database og filer. Usability: Layout skal være simpelt og webshoppen skal være med få varer. Der skal være tjekket for stavefejl og sproget skal være på dansk i første omgang, hvis e-shoppen bliver en kæmpe succes, kan der overvejes at være en engelsk version. CRUD-matrix Vi har lavet en CRUD-matrix, som gør det nemt at identificere tabellerne i vores database. Vores CRUD har også en rød tråd til vores use case, da kundens og administratorens forhold også illustreres her. Her kan man se, hvem der har lov til at gøre hvad og hvad deres roller er. CRUD står for create, read, update og delete, som tildeles de roller man har valgt. Hvordan dette er gjort kan ses nedenfor. Vi har valgt at administratoren skal have adgang til alt stort set alt og har mulighed for at udøve alle funktionerne, hvorimod at kunden kun har mulighed for de nødvendige funktioner. 16
Konklusion På baggrund af vores store forarbejde med de forskellige analyser og modeller har vi fået et godt og gennemarbejdet produkt ud af det. I fremtiden vil vi gøre navnene på vores attributter i ER-diagrammet og attributtabellen mere overskuelige ved at bruge enten kun små bogstaver eller store bogstaver i forbogstavet således at det er nemt at kode det. Vi har brugt ressourcer på at lave en HTML-side som ikke skulle bruges alligevel men den har hjulpet os med at se projektet i sin helhed. Vi har fået godt styr på interaktionen mellem kunden og databasen og rettighederne for brugerne. Alt i projektet er veldokumenteret ud fra vores analyser men også med kommentarer i vores SQL filer, så udefrakommende hurtigt og nemt kan få indblik i projektet og eventuelt arbejde videre med det. 17
Litteraturliste Bøger: Sams Teach Yourself In Ten Minutes - Ben Forta, 2012 Hjemmesider: www.w3schools.com http://www.databaseanswers.org 18