WebSite og databaseprojekt

Transkript

1 WebSite og databaseprojekt

2 Study: Project Period: Multimedia Design 3.semester 2. Project: Database og website 30.Sep Okt.2013 Fact Sheet Project title: shop4415 Class: CLmul-a12e Group Number: 7 Group member: Name: School mail & web: Sign: Ole Jørgen Hansen [email protected] shop4415.gribskovweb.dk Claus Buus Christensen [email protected] Kaspar Birk [email protected] 1

3 Indholdsfortegnelse Indledning... 3 Interessenter og kommunikation... 4 Design... 5 Sprintplan... 6 ER-Diagram... 7 Attribut tabel... 7 UseCase... 8 CRUD Matrix... 9 Bilag, værktøjer, efterskrift mv

4 Indledning Til denne opgave, som er en ordre fra et fiktivt firma, skal der planlægges og laves en hjemmeside, som indeholder nogle produkter, som interesserede brugere kan stemme på. Ved denne afstemning, genereres der en top-liste bestående af de produkter, som aktuelt har fået flest stemmer. Vi fraviger dog fra opgaveoplægget mht. at fravælge de produkter, som der beskrives deri og i stedet benytte produkter, som helt og holdent er vores egne produktioner, men med hensyntagen til, at den stillede opgave, funktionelt løses tilfredsstillende. Interessenter for denne hjemmeside er typisk personer, som interesserer sig for Märklin producerede modeltogsvogne af typen 4415, påtrykt genkendelige danske reklamer. Deraf navnet shop4415. Märklin er den største globale fabrikant af modeltog i flere skalaer og er grundlagt i 1859 af Theodor Friedrich Wilhelm Märklin ( ) i Göppingen Tyskland. I starten producerede de legetøj, mest dukkekøkkener, men nu er Märklin først og fremmest kendt for sine modeltog. I 1895 byggede firmaet verdens første elektriske modeltog, og siden 1935 er modellerne blevet fremstillet i størrelsen H0 (1:87), der er den mest udbredte standard for modeljernbaner verden over. I 1970 erne begyndte Märklin at producere H0-vogne med danske reklamer på. Selve vognen som de anvendte, var en basic-model, som har katalognummeret 4415 og de trykte reklamen på disse vogne. Med tiden har fabrikken produceret et utal af disse 4415-vogne med forskellige danske og udenlandske reklamer påtrykt. 3

5 Interessenter og kommunikation Ud fra oplægget i opgavearket, hvor det er en fiktiv virksomhed, som overdrager os opgaven som de ønsker udført, anskuer vi problematikken (FURPS) med følgende krav: Vi skal lave et site med et antal produkter Interesserede skal kunne gå på opdagelse på sitet og se alle produkter Hvis man ønsker at deltage i en afstemning om produkterne, skal man kunne logge ind Når man er logget ind skal man kunne stemme på de produkter, som man ønsker Man må kun kunne stemme én gang på hvert produkt Man skal kunne se en oversigt på, hvem man har stemt på (favoritter) Man skal kunne logge af/ud af systemet Endvidere skal brugerne af sitet kunne se en aktuel opdateret liste, over de 5 produkter, som oppebærer flest stemmer, sorteret med den mest populære vogn øverst. Ydermere skal der honoreres følgende krav: Sitet skal være nemt at navigere rundt på ( få museklik for at nå det ønskede ) Oplevelsen af sitet skal stå i mål med den interesse brugerne har for produktet og denne målgruppe skal i særdeleshed nås Funktionaliteten kræver, at sitet skal opdatere hurtigt Sitet skal være nemt at vedligeholde af en administrator Kommunikation: Det endelige resultat fremvises for kunden (lærerne på CPH-Business) af gruppen Kommunikationen mellem gruppens medlemmer foregår via internettets DropBox, Facebook og medlemmernes mobiltelefoner, samt personlige møder. Tovholder på projektet er Claus Buus. Funktionalitet, overordnet: Da gruppens medlemmer arbejder på hver sin personlige computer og har adgang til internettet, hver for sig, fra forskellige accesspunkter, må risikoen for at projektet ikke fuldføres betegnes som meget lille. Redundancen oppebæres via 3 computere og faren for at alle tre involverede maskiner fejler på én gang, er ikke ret sandsynlig. Det er udefra kommende nationale eller globale hændelser, som kan forhindre projektet i at blive færdigt eller hvis der grundet sygdom eller andet, ses at gruppemedlemmerne falder fra. I givet fald forsøges at meddele dett til rette vedkommende. Sitet uploades til flere externe servere (URL kan ses i faktaarket som danner forside for denne rapport) og der anvendes udelukkende public-servere. Det skønnes ikke nødvendigt, at indkøbe plads på særlige udvalgte servere. 4

6 Mock-Up Bilag A + B + C: Figurerne viser håndtegninger af de første tanker om hvordan sitet skal udformes og fungere Design Anvendte designmodeller, som vi benytter os af: CRAP og AIDA Med designmodellerne i tankerne, er det overordnede indtryk af sitet ikke optimalt, da vi har lagt vægt på, at lave et site der fungerer mht. funktionaliteten, som er ønsket af kunden (opgavens ordlyd). CRAP modellens fortræffeligheder er dog tilgodeset idet kontrasten i farver, forskelligheden i typografien mv. er tilrettet,- designet er blevet anvendt på flere sider og elementerne på siderne er haoldt sammen i aftale om nærhed. AIDA modellen har vi brugt til at lave en opmærksomhed på produkterne, som så fanger øjet. Hvis der klikkes på de små billeder af vognene, åbner en ny side med en flot forstørrelse. Interessen for produkterne vil fange brugeren, men når det så er sagt, er der nok ikke mange ikke interesserede, som vil blive ret længe på siden. Sitet kan forholdsvis nemt udvides med en e-handelsløsning, så brugerens ønske om, at købe vognene bliver tilgodeset,- hvis det er det vores kunde (opgaven) ønsker, - kan der sættes handling på denne del af designmodellen også. Bilag 1: Figur 1: Viser sitet ved brugerens ankomst Sitet er lavet og optimeret til alm. standart for visning på skærm, dvs. 960 x 600 pixel Sitet er lavet dynamisk og henter sine oplysninger fra tabeller i en database (se ER-diagram) Sitet indeholder generelt 4 elementer: Top med illustrativt billede med logo som er permanent på alle sider Left side-bar med en top 5 rating, hvor mest populære vogn er øverst også permanent Midt med udskiftelig content (se venligst videre herunder) Right side-bar med brugerens log-in og knap til bruger oprettelse Bilag 2: Figur 2: Viser sitet når brugeren har logget ind 5

7 Når en bruger er oprettet og logget ind, skifter content i midten til, at under hvert produkt, er der en status på, om man har stemt. Ellers kan man gøre det ved at afgive en rating fra 1-5 og derefter klikke på knappen STEM. Når afgivelsen af stemmen er registreret, skifter boxens udseende til, at man ikke kan stemme mere. Efter at flere brugere stemmer, skifter rating til venstre i takt med hvilken vogn, som er mest populær. Bilag 3: Figur 3: Viser sitet når en bruger har klikket på Opret dig som bruger Når man klikker på knappen, hvor man kan oprette sig som bruger, skifter content i midten til en formular, hvor brugeren skal indtaste de nødvendige oplysninger for at dette kan effektueres. Når brugeren er oprettet, skifter content i midten til oversigtsiden, hvor alle vognene kan ses med hvilken rating de aktuelt besidder. Man kan nu stemme og i takt med stemmerne afgives, skifter top-5 ratingen i venstre side. Den nyoprettede bruger kan selvfølgelig gå til en side, hvor man kan se sine vogne, man har stemt på osv. Bilag 4: Figur 4: Viser sitet når man er logget ind som administrator Hvis man i bruger log-in feltets brugernavn skriver admin og i password skriver , bliver man logget ind som administrator. Den som besidder denne funktion, kan normalt beherske alle CRUD-funktionerne, men i denne case, har vi valgt kun at lave en formular med oprettelse af et nyt produkt. I formularen kan der skrives en overskrift og en beskrivelse af produktet, samt up-load es et billede af vognen. Dette automatisk re-sizes til to billeder,- et lille billede (thumb) på 150px i bredden og et stort billede, som er det der vises, når man klikker på det lille billede i boxen. Hele log-in kodningen er beskyttet af SESSION-kodning. Sprintplan Bilag 5: Figur 5: Viser planen for vores sprint Vi har grebet planlægningsprocessen an ved brug af en sprintplan. På vores planlægningsmøde torsdag den 3. oktober drøftede vi systemets kravspecifikationer og på den baggrund udarbejdede vi i fællesskab en product-backlog. Alle tasks blev gennemgået og prioriteret, og herefter skrevet ind i vores sprintplan. Arbejdsopgaverne blev tids-estimeret efter tidligere erfaringer og ressourcerne fordelt. I henhold til projektbeskrivelsen er deadline 11. oktober, hvilket har givet os 7 arbejdsdage til vores sprint. Det har krævet en grundig planlægning af fordeling af arbejdsressourcer og opgavetasks. 6

8 ER-Diagram Bilag 6: Figur 6: Viser ER-Diagram for databasetabellerne Diagrammet er udviklet i programmet WorkBench, som hjælper med at generere relationerne i databasens tabeller. Vi startede med en oplistning af tabellerne og arbejdede os derefter videre til 3. Normalform blev nået. Diagrammet viser den hierakiske opbygning med en samletabel øverst. Vi har i denne opgave fravalgt at lade programmet kode vores sql, - vi har selv lavet alt kodningen. Attribut tabel Entity Attribute Value Notes Datatype Produkt4415 ProdID 1-x Unique No. N Prodtitel All char Max. 45 char AN Prodtekst All char Textarea AN Billede All char Max. 45 char AN Bruger4415 BrugerID 1-x Unique No. N Brugernavn All char Max. 45 char AN Password All char Max. 45 char AN Rating4415 FK_brugerID 1-x Unique No. (From N product table) FK_brugerID 1-x Unique No. (From N product table) score 1-x Ratingscore N Ovenover ses vores attributtabel. Denne benyttes til at skabe det altafgørende overblik på, hvordan de enkelte records i en given tabel, bliver oprettet. Navnet på en tabel kaldes for Entitet. Attributterne er det indhold som lægges i entiteten og i disse attributter angives values eller oversat, egenskaberne, som skal tilknyttes de data, som lægges i attributten. Her angives datatypen, om det skal være kun tal, INT eller blandede karakterer VARCHAR, antallet af karakterer, om feltet skal udfyldes, NOT NULL osv. samt unikke datanøgler, PRIMARY-KEY, FOREIGN-KEY mv. Endvidere kan attributten forsynes med Auto Increment som er en automatisk tildeling af et tal, som altid vil være unikt. Ud over dette kan attributten tildeles forskellige standardværdier, DEFAULT s.usecase 7

9 UseCase Bilag 7: Figur 7: Viser tegning over sitets UseCase Use-case description Name Identifier Preconditions Basic Course Rating at et produkt Rating UC1 Database åben, table altered Besøger ser produkter Tjekker om brugeren er logget ind og ikke har stemt på produktet før. Hvis brugeren er logget ind og ikke har stemt før: Tilladelse til at stemme via dropdown. Hvis ikke: Fejlmeddelse udskrives og beder brugeren om at logge på. Alternate Course Condition Post conditions Hvis alt går igennem bliver stemmen med brugerid og produktid indsat i table. Hvis besøgeren ikke er logget ind anbefal besøgeren at logge ind eller oprette sig for at få rettigheder til at stemme 1. Database åbnet 2. Table altered 3. Entry (rating) oprettet Table lukket, database lukket Use-Case s, som vist ovenover, er en metode som er anvendelig i forbindelse med at klarlægge scenarier på, hvordan et system skal interagere med en bruger. I vores tilfælde blotlægges anvendelsesmåden, for hvordan og i hvilke rækkefølge funktionerne udføres og hvad der i pågældende situationer sker. F.eks. brugeren klikker på en knap som indeholder en betingelse for, at vedkommende er logget ind i systemet. Hvis brugeren eksisterer sendes vedkommende videre f.eks. med en meddelelse velkommen ellers en meddelelse log venligst ind. Når betingelsen er opfyldt kan der fortsættes til anden aktivitet, som herefter beskrives. 8

10 CRUD Matrix Case / Rolle Besøger Bruger Administrator Rating R CR CRUD Bruger C C RUD Produkter CRUD CRUD Matrix er et skema, som blotlægger funktioner og tilladelser for de forskellige brugere. Det er af stor vigtighed, at når der er mere end een person involveret I en database, at angive hvilke tilladelser den enkelte bruger har må vedkommende f.eks. slette en record I en tabel eller f.eks oprette et produkt? CRUD er en sammensætning af: C = Create - R = Read - U = Update - D = Delete Ved hjælp af ovenstående kan man altså tildele hver enkelt bruger af en database de roller som den pågældende må besidde. F.eks. må ejeren af databasen CRUD, altså både oprette, læse, redigere og opdatere, samt slette. 9

11 Bilag, værktøjer, efterskrift mv. Bilag A + B + C 10

12 Bilag 1: 11

13 Bilag 2: Bilag 3: 12

14 Bilag 4: 13

15 Bilag 5: 14

16 Bilag 6: Bilag 7: 15

17 Værktøjer Vi har til brug for udarbejdelse af denne opgave brugt programmerne fra Adobe, Photoshop, Illustrator, Dreamweaver. Endvidere er brugt Notepad++, Officepakken og diverse internetbrowsere. Vejledere Gruppen har modtaget vejledning af: IRF - Ivan R. Frederiksen JHI - Jesper Hinchely TUJE - Tue Becher FDTA - Frederik Tang THA - Thomas Hartmann 16