Webdatabase 3. semester MulA 2. Projekt Nathalie Heiden cph-nh101@cphbusiness.dk www.nathalieheiden.dk/portfolio Lars Emil Christensen cph-lc106@cphbusiness.dk www.oswaldo.dk Noor Abdel Aziz cph-na68@cphbusiness.dk www.mul31.itkn.dk/noorsportfolie-2semester Tania Carlsen cph-tc97@cphbusiness.dk www.taniacarlsen.dk Mathias Kofoed cph-mk251@cphbusiness.dk www.moohpied.com/portfolio 1 Indholdsfortegnelse 1. Introduktion 3 2. Planlægning 3 WBS3 PBS4 SCRUM4 3. Modellering 5 ER-Model5 Database5 Attribut tabel6 Use case model 7 Fully dressed Usecases7 Navigationsdiagram10 CRUD11 4. SQL code forklaring 11 Senest uploaded 11 Upload media12 Show/rate media 12 Login proces13 5. Testcase13 6. Designbrief14 2 1. Introduktion I dette projekt har vi lavet et voting/rating system, som er baseret på et professionelt webite, hvor voting/ rating systemet virker funktionelt. Vi har valgt at lave et musikwebsite, som vi har kaldt for 80SHARE, hvor man som bruger har mulighed for at dele 80´er synth pop musik i forkellige medietyper. I rapporten ses vores fulde projektdokumentation for både struktur- og designvalg. Derudover ses også vores udarbejdelsesopgaver såsom planlængning og modeller. 2. Planlægning Vi har udarbejdet nogle projektplaner, enWBS (Work Breakdown Structure) og en PBS (Product Breakdown Structure). I WBS´en har vi skrevet alle de opgavedele, der skal arbejdes på, og i PBS´en har vi skrevet de opgavedele selve produktet/websitet skal indeholde. Derudover har vi lavet et scrum (Script Creation Utility for Maniac Mansion). Vores SRUM viser et overblik over procesarbejdet og procesudviklingen. WBS I nedenstående ses modellen af vores WBS. WBS´en giver et overblik over, hvilke opgaverdele vi har, som er sat i struktureret form, hvor hver opgave er nedbrudt i flere opgavedele. 3 PBS Her ses en model af vores PBS. PBS´en giver et overblik over, hvad vores website skal indeholde i både dets frontend og backend. I frontendet skal der være fire overordnede sektioner, ’Forside’ , ’Alle videoer’, ’Mine videoer’ og ’Nyeste versioner’. Derudover skal hver side og underside indeholde et login. I backend skal der være et ratingsystem. Ratingsystemet skal dække et login. Derfor skal der være en database, der skal indeholder user- og mediainfo. SCRUM Her ses udviklingen af vores arbejdsproces. SCRUM giver en oversigt over, hvor mange antal personer, der skal sidde med samme type opgave, og hvor meget tid, den enkelte opgave vil tage. 4 Modellering Modelleringen af databasen er inddelt i to forskellige typer, en ER-model og en attribut tabel. ER-Model ER-modellen viser en opsætning af de nødvendige tabeller, der skal bruges i vores database. Hver tabel er navngivet og har nogle attributer. Disse attributter er de informationer/data, vi spørger efter i vores website. Der skal både være user- og mediainformationer gemt i vores database, så rating, oploading og loginsystemet fungerer. Når vi laver vores databasesystem, skal vi skrive attributterne i hver sin tabel, så vi derefter kan få tilføjet nye brugere i vores databasesystem. Database Vores ratesystem er bygget op omkring et loginsystem; dvs. user og media tabellerne er omdrejningspunktet. En ting, der er værd at lægge mærke til, er user_password i usertabellen. Da vi gør brug af password_ hash-funktionen skal vi have plads til et ouput på 60 chars. Fremadrettet ville en højere grænse være krævet, da default hash algoritme kan variere over tid, men i vores tilfælde holder vi den til 60. En anden interessant ting er opbygningen af ratingtabellen. Da vi her gør brug af en sammensat primærnøgle, er den naturlige konsekvens, at en bruger kun kan rate et givent media ÉN gang. En fordelagtigt konsekvens kan man kalde det. Det samme gør sig naturligvis gællende for flagged_media. Stukturen i databasen, med de nuværrende attibutter, kan fremadrettet udbygges med søgning efter artist, ban bruger, sortering i bruger genereret data(flagged media) og at lister af media kan tage højde for de enkelte flags. Ligeledes, i vores database script struktur fil, har vi oprettet et view af usertabellen, for at kunne oprette en fremtidig liste af flagged media. På den måde kan navnene på både flagger og uploader hentes frem. 5 Attribut tabel Attribut tabel er værktøjet, der bruges til at vise programmøren, hvordan ens database skal modelleres. Den viser hvilke tabeller de forskellige rækker skal være i, hvilke værdier der kan benyttes i rækken og hvilken slags datatype rækken skal være. 6 Use case model I modellen ses de muligheder brugeren har på websitet. Derudover ses administratorens opgaver. Fully dressed Usecases Fully dressed use case UC3 Name: Rate media Identifier: UC3 Description: Bruger giver bedømmelse for det enkelte medie. Goal: Give brugeren mulighed for at bedømme det enkelte medie. Preconditions: At brugeren er logget ind. Refererer til UC2. Basic Course 1. Bruger vælger et medie 2. Brugeren bedømmer videoen fra 1-5. 3. Systemet gemmer ratingen i tabellen. Alternate course: 1 Hvis brugeren ikke er logget ind, kan der ikke rates. 2 Hvis brugeren har ratet et givent medie før, kan den ikke rates igen. Post conditions: Rating er fuldført og gemt. Actors 1. Brugeren 2. System 7 Fully dressed use case UC5 Name: Search videos Identifier: UC5 Description: Brugeren søger efter et medie. Goal: At brugeren finder det ønskede medie. Preconditions: At brugeren har fundet søgefeltet. Basic Course 1. Brugeren skriver et ord i søgefeltet. 2. Systemet matcher søgeordet med indholdet fra databasen. 3. Systemet giver en liste med resultater af søgningen. Alternate course: Hvis søgeordet ikke bliver fundet i databasen, skal systemet gøre brugeren opmærksom på dette. Post conditions: Søgning bliver fuldført. Actors 1. Brugeren 2. System Fully dressed use case UC6 Name: Upload media Identifier: UC6 Description: Bruger uploader et medie. Goal: At tilføje et medie til sitet. Preconditions: At brugeren er logget ind. Refererer til UC2. Basic Course 1. Brugeren går ind under upload media. 2. Bruger udfylder felterne med de nødvendige oplysninger for mediet. 3. Systemet gemmer den uploadet medie. Alternate course: 1. Hvis brugeren ikke er logget ind, kan mediet ikke uploades. 2. Hvis mediet allerede eksisterer på sitet, kan det ikke uploades igen. Post conditions: Uploadingen er fuldført. Actors: 1. Brugeren 2. System 8 Fully dressed use case UC7 Name: Flag media Identifier: UC7 Description: Brugeren flagger et medie. Goal: Brugeren kan flagge de uønskede medier, så admin kan fjerne dem fra sitet. Preconditions: At brugeren er logget ind. Refererer til UC2. Basic Course 1. Brugeren vælger et medie på listen. 2. Brugeren vælger flag media. 3. Systemet gemmer brugerens valg. Alternate course: Hvis brugeren ikke er logget ind, kan brugeren ikke flagge. Post conditions: Ændringerne bliver fuldført. Actors 1. Bruger 2. System Fully dressed use case UC-A2 Name: Approve flag Identifier: UC-A2 Description: Admin godkender et flag og kan fjerne mediet. Goal: Giver brugeren mulighed for at anmelde et medie, så admin kan fjerne det fra databasen. Preconditions: At admin er oprettet, logget ind og ser listen over medierne, som har flag på. Refererer til UC2 og UCA1. Basic Course 1. Admin vælger det medie, som har flag på. 2. Admin godkender det på listen. 3. Systemet updaterer efter admins valg. Post conditions: Mediets flag er updateret. Actors 1. Admin 2. System 9 Fully dressed use case UC – A4 Name: Edit user Identifier: UC – A4 Description: Admin redigerer brugerens oplysninger. Goal: Admin har mulighed for at ændre på brugerens oplysninger. Preconditions: At admin er logget ind og kan se en liste over brugere. Refererer til UC2. Basic Course 1. 2. 3. Admin vælger en bruger fra listen. Admin ændrer brugerens oplysninger. Systemet gemmer ændringerne. Alternate course: Hvis admin ikke er logget på eller er oprettet som admin, kan der ikke ændres på brugernes oplysninger. Systemet skal give besked om dette. Post conditions Ændringerne bliver fuldført. Actors 1. Admin 2. System Navigationsdiagram Navigationsdiagrammet viser opbygning af websitets menu. 10 CRUD Vi benytter CRUD modellen til at danne os et overblik over hvad der skal ske i vores database, når de forskellige use cases eksekveres. Eksempelvis oprettes (C) der information i tabellen ‘user’, når der oprettes en ny Table 1 bruger. user UC1: Create login C UC2: Login R media artist media_type UC3: Rate media rating ßagged_media CU UC4: Comment C UC5: Search R R R UC6: Upload media C CR R UC7: Flag media comment R R C UC-A1: Check ßag R R R UC-A2: Approve ßag R R RU UC-A3: Reject ßag R R RU UC-A4: Edit user RU UC-A5: Ban user RU UC8: Logout SQL code forklaring Senest uploaded På forsiden har vi 3 lister, et for hver type media, som viser de 3 senest uploadede. For at hente de nødvændige data, om hver enkelt media, skal alle de relevante tabeller joines. Derefter sortere vi det efter media_id i en fallende orden, og afgrænser til 3 resultater. I nedstående eksempel fetches der til video, hvoraf html koden, der wrappes om resultaterne, naturlivis ændres til den enkelte type af media. Når de to sidste lister skal genereres, genbruger vi samme prepared statement, da det kun er type id’et der ændres - altså er det samme forspørgsel struktur der anvendes. Herover ses et udsnit af index.php 11 Upload media For at kunne håndtere at flere uploads, potentielt har samme kunstner, skal der efter artist insert hives et id ud på senest indsatte row. Hvis intet id blev hevet ud, betyder det, at den givne artist allerede findes. Hvis dette er tilfældet gennmføres en query på navnet af artisten, og af den vej får vi et artist id alligevel. Til sidst indsættes alle data i media tabellen. Igen gør vi brug af javascript for at redirecte brugeren. Show/rate media Her er et eksempel på, hvordan login systemet har effekt på sitet. Vi checker om uid er sat i sessionen; hvis dette ikke er tilfældet vises rateformen ikke, og omvendt hvis uid ér sat. Sidste del af kodeudsnittet omhandler, hvordan en rate ser ud, hvis et givent media endnu ikke er ratet. For hvis ingen rate kan findes, indeholder variablen $rate en tom tekststreng, og derfefter sættes samme variable til 0. 12 Login proces Da vi gør brug af funktionerne password_hash og password_verify(PHP5.5) checker vi ikke input data direkte op imod databasen. Vi skal derimod have det hashed password, som ligger i databasen, og checke op imod det password der kommer fra formen - dette gør password_verify(). Hvis funktionen finder et match, returnes true(1) og vi kan derpå sætte sessions variable u_id og u_name. Da der allerede er ”spyttet” html ud før hele checket, kan header ikke bruges, hvorpå vi går ud af php og ind i java script, som redirecter brugeren til forsiden. Hvis der ingen match er, udskrives en passende fejlbesked, i en div der senere kan styles. Herover ses et udsnit af login.php Testcase Ved hjælp af testcases får vi afprøvet vores usecases. Testcasene viste at der er nogle ting der endnu ikke er som de skal være. Der mangler feedback til brugeren ved nogle af testene. Test Cases Date: Project: WEB-Project No.2 TestManag er: IRF Test Date Steps Name Descriptions Prerequisites Input / Steps Expected Output 1.01 Opret bruger En bruger ønsker at oprette sig Brugeren er på hjemmesiden Klikker på Sign Up 1.02 Formular På signup.php udfylder bruger formular Brugeren har klikket på signup Brugernavn: Tuetrack , Password: 1234 , email: test@test.dk 1.03 Formular På signup.php udfylder bruger formular Brugeren har klikket på signup 2.01 Rate et medie Brugeren ønsker at rate et medie 2.02 Rate et medie Brugeren ønsker at rate et medie 3.01 Upload medie 3.02 Formular Actual Output Approved Sendes til signup.php Jeg blev sendt til signup.php tjek Oprettelsen accepteres Jeg får beskeden: "User Tuetrack is now created". tjek Brugernavn: Tu3tr4ck , Password: 1234 , email: test@test.dk Besked: Invalid username/password Jeg får beskeden: "Username/ email is already in use". tjek Bruger skal være logget ind Rating input: 4 , tryk Rate Ratingen er gemt Bruger modtager besked om at rating er gemt Den skriver 4.0/5 i rating tjek Bruger skal være logget ind Rating input: intet, tryk rate Fejlmeddelse Besked om at ingen rating Der sker intet er valgt Bruger ønsker at tilføje et medie Brugeren er logget ind Klikker på Upload sendes til upload.php Bruger er på upload.php der indeholder en formular Brugeren har klikket på upload Artist: Kraftwerk Titel: Autobahn Link: G28iyPtz0 At mediet er uploaded Bruger er på upload.php der indeholder en formular Brugeren har klikket på upload Artist: Kraftwerk Titel: Autobahn Link: https://www.youtube.com/ watch?v=x-G28iyPtz0 Fejlmeddelse Der kommer ingen fejlmeddelse fejl Besked om flagning er gemt Der kommer ingen fejlmeddelse fejl med den er flagget i db 3.03 Formular 4.01 Flag medie Bruger flagger et medie Brugeren skal være logget ind Klikker på flag media 4.02 Flag -> DB Oprettes i flagged_media med status N/A Bruger har trykket flag Flag info Comment Action taken Responsible tjek tjek Man bliver sendt tilbage til forsiden og ser at mediet er under ‘latest’ Linket er uploadet og jeg bliver fejl sendt tilbage til forsiden tjek 13 Designbrief 1. Overordnede parametre: Deadline: søndag den 2. november 2. Hvad er det specifikke problem, som skal løses? Vi skal designe et website specifikt for en musik genre, hvor man kan rate musikken, albumart og musikvideoer. Musik genren er synthpop i 80’erne. 3. Formål med designet? Formålet er at fange og fastholde målgruppens opmærksomhed. Designet skal være funktionelt og overskueligt for brugeren. 4. Overblik over målgruppen: Hovedsagligt kvinder/mænd i alderen 40+ der lyttede til synthpop i 80’erne, men også andre aldersgrupper der kunne nyde genren. Målgruppen reagerer positivt på 1980’ernes stilarter. Her tænkes især på neonfarver, der er kendetegnende for datidens bybillede. Målgruppens mål med at besøge hjemmesiden er at øge deres kenskab til emnet. 5. Overblik over den kreative metode: Målet er at få målgruppen til at føle sig tilbage i 80’er, så stemningen på sitet skal være tilpasset den stil de havde dengang, men med en mere moderne tilgang. Stilen skal være Synthpop og farverne skal være er neon. 14