BackEnd Programmering PHP

17708 08/ 02/ 2013

BackEnd Programmering PHP Prototype (CMS system) 371615m02dka.sub.ots.dk/historyspot eller linket CMS system på: qrguide.mmd.eal.dk Login CMS Username: admin Password: 1234 Source kode www.qrguide.mmd.eal.dk eller i mappen Source kode på vedlagte CD.

Indholdsfortegnelse Indledning... 2 Problemformulering... 2 Metodeafsnit... 3 Objektorienteret programmering (OOP) i PHP... 3 Object... 3 Class... 3 Attributes... 3 Method... 3 Encapsulation... 3 Inheritance... 3 Use case diagram... 3 3-tier architecture... 4 Sequence diagram... 4 Class diagram... 4 Normalisering... 4 Udviklingsmetode - Scrum... 5 SCRUM... 6 Scrum roller... 6 Product backlog... 6 Sprint backlog... 7 Burndown chart... 8 Use Case Diagram... 9 Scenarier... 9 3-tier architecture... 10 Sequence Diagram... 11 Class Diagram... 11 Database... 12 Konklusion... 12 Litteraturliste... 13

Indledning I en digital alder bygger vi vores viden op omkring brugen af programmer og/eller forståelsen for disse. Med andre ord bruges viden omkring en form for teknologi eller et bestemt program til, at udvikle andre programmer. Og det er det, som programmering går ud på. At man er i stand til at udnytte teknologien med henblik på at skabe nye og alternative veje. Dermed bygger man selv videre på den teknologi, man startede med at udnytte. Og fordi vi alle er så nysgerrige på, hvad fremtiden bringer, så ligger det os lige for, at hoppe ombord på det tog der tager os dertil. Dette projekt giver os mulighed for at viderebringe teknologien i et nyt lys, og ikke mindst skabe interesse for ikke-udviklere. Programmeringen giver til projektet, hvad motoren er for bilen - netop det de nysgerrige og barnlige sjæle er ude efter. Dermed indeholder rapporten en detaljeret gennemgang af backend programmeringen i PHP, benyttet til at skabe et CMS system over en mobil hjemmeside. Problemformulering Projektet fremspringer af problemet omkring tilegnelse af nyttig information, i situationer med begrænset teknologisk tilgang, der vedrører alle former for seværdigheder. Derfor vil vi, med afgrænset fokus, søge efter informationer, der skal medvirke til at danne et billede og en analyse af en potentiel målgruppe, med dertilhørendes viden omkring QR-koder, mobilteknologi og tendenser herfor. Herfra vil vi fortolke analysen med henblik på idéudvikling. Dertil vil der blive opstillet gennemgående krav og milepæle, der skal medvirke til, at udviklingsprocessen foregår under effektive og kontrollerede forhold. Derfor vil der desuden være gennemgående vurderinger af brugen af metoder på projektet, der skal være med til at gengive et billede af det ønskede resultat. Dermed vil vi fortolke den analyserede information/data udvundet af grundig research, med henblik på at vurdere indholdet, der i sidste ende løser følgende problemstilling: Hvordan udvikler vi et bæredygtigt system, der hurtigt og effektivt kan administreres? Ud fra denne hovedproblemstilling, har vi en række mindre problemstillinger der skal være med til at løse opgaven. Hvilke redskaber skal vi benytte for at effektivisere arbejdet? Hvordan sikrer vi os, at systemet er brugervenligt og ligetil? Hvilke teknologier er de mest effektive for vores produkt? 2

Metodeafsnit Objektorienteret programmering (OOP) i PHP Object Man har et objekt når man opretter en instance af en klasse. Når en instance er oprettet kan klassens methods bruges. Class En klasse definerer attributes og methods som vil optræde i et object. Attributes Attributes er variabler som kan bruges til at definere egenskaber for elementer i en klasse. Method Methods er de funktioner som et object kan udføre. Encapsulation Der er tre forskellige niveauer af synlighed for attributes og methods: Public: synlig og brugbar i og uden for klassen. Standard i PHP med mindre andet er angivet. Private: kun synlig/brugbar i selve klassen. Protected: kun synlig/brugbar i selve klassen og eventuelle underklasser. Inheritance En klasse kan være en underklasse af en såkaldt overklasse. Det betyder at underklassen arver alle de methods og attributes som overklassen har. Man laver en underklasse ved at tilføje extends + overklassen som f.eks.: class Car extends Vehicle. Inheritance bruges, hvis flere klasser skal have de samme attributes og methods, så man slipper for at gentage en masse kode. Vi har benyttet objektorienteret programmering, da det giver bedre struktur og dermed et større overblik over koden. Fordelene ved OOP er især, at systemet er inddelt i mindre bidder, der fungerer selvstændigt, og dermed kan genbruges i anden kode. Use case diagram Et use case diagram kan gengive de forskellige typer af brugere af et system og de forskellige måder, hvorpå de interagere med det. Et use case diagram er et interaction diagram, der er med til at afspejle en adfærd i systemet. 1 1 UML Demystified: A Self-Teaching Guide, chapter 1 - A Picture Is Worth a Thousand Lines of Code 3

Vi har benyttet use case diagrammet til, at skabe et universelt billede af, hvordan vores system fungere i forhold til brugerens aktiviteter. 3-tier architecture Systemet er bygget op efter en såkaldt 3-tier architecture, hvor hjemmesiden er delt op i tre forskellige lag. Disse tre lag kaldes typisk for "presentation tier", "logic tier (eller business logic)" og "data tier". 3- tier architecture benyttes grundet kravene om en grafisk brugerflade med dynamisk funktionalitet, samt tilgang til database. 2 Vi har valgt at beskrive en 3-tier achitecture for at vise, hvordan vores produkt kommunikerer mellem de tre tiers. Sequence diagram Et sequence diagram viser forskellige objekters interaktion mellem hinanden over tid. Dette er vist ved parallelle vertikale linje med forskellige processers eller objekter, der lever samtidigt, med horisontale pile imellem, for at beskrive forskellige situationer mellem disse. 3 4 Vi har benyttet et sequence diagram for at få et overblik over, hvordan de forskellige objekter har indflydelse på hinanden gennem forskellige handlinger. Det har desuden givet os et godt indblik i, hvilke områder, der muligvis er for kompliceret. Class diagram Et class diagram beskriver et objektorienteret systems struktur ved hjælp af klasser/classes, deres attributter, metoder og de forhold, der er imellem klasserne. Et class diagram er et statisk diagram, der giver et statisk blik over et system. 5 Vi har benyttet et class diagram til, at opbygge CMS systemet. Herefter har det været utroligt nemt at oprette databaser. Normalisering Er en måde at optimere databaser på. Det foregår ved at man tilpasser tabellerne i et class diagram efter de tre normalformer. På denne måde undgår man bl.a. redundant data 6. 1. normalform (1NF) 2 http://en.wikipedia.org/wiki/multitier_architecture, besøgt d. 06/12/2012 3 UML Demystified: A Self-Teaching Guide, chapter 4 - Discovering Behaviors with Interaction Diagrams 4 http://www.uml-diagrams.org/sequence-diagrams.html, besøgt d. 07/12/2012 5 UML Demystified: A Self-Teaching Guide, chapter 6 - Showing How Classes Are Related 6 Redundant data er en betegnelse for data der er blevet gentaget i to eller flere lister. 4

Understreger at man ikke må benytte enkelte felter med flere værdier i. Desuden må en kolonne ikke gentages. Opfylder en liste disse krav, er den på 1NF. 2. normalform (2NF) Denne normalform er afhængig af at den 1NF er opfyldt. Derudover er reglen for 2NF, at alle felter i en tabel skal være afhængig af en hel nøgle. Indeholder tabellen sammensatte nøgler, dvs. nøgler der består af to eller flere felter i en tabel, så opfylder den ikke 2NF. Dermed skal man oprette en ny tabel for de enkelte nøgler. 3. normalform (3NF) Denne normalform understreger at et felt kun er afhængigt af primærnøglen, og at 2NF er opfyldt. På denne kan man undgå at felt 1 er afhængig af felt 2 og 3. Her skal felt 1 være transitivt afhængig af felt 3. Således at felt 1 er afhængig af felt 2, som er afhængig af felt 3. 7 Vi har benyttet normalisering for at optimere vores system. På denne måde har vi minimeret redundansen, og dermed gjort systemet simpelt og nemt at navigere i. Udviklingsmetode - Scrum En udviklingsmetode er den fremgangsmåde, som de ansatte i projektet benytter sig af for at komme frem til det endelige resultat. Styringen af forløbet foregår ved anvendelse af en systemudviklingsmodel, der definerer en række faser og milepæle. I dette projekt, har vi valgt at bruge den agile udviklingsmetode SCRUM. SCRUM er en agil udviklingsmetode, som bruges til de mere uforudsigelige projekter, hvor forløbets arbejdsopgaver står lidt uklart. Ved at bruge denne metode, er det muligt at opnå det maksimale potentiale for et projekt. SCRUM vil herved være ideel at benytte til udvikling og videreudvikling af produkter. I SCRUM bruges der tre roller, tre ceremonier og tre værktøjer. De tre roller er ProductOwner, Team og ScrumMaster. De tre ceremonier er Sprint Planning Workshop, Daily Scrum og Sprint Review Meeting. De tre værktøjer er Product Backlog, Sprint Backlog og Burn Down Chart. Inden Sprinten startes definerer man dens indhold på en Sprint Planning Workshop. Alle der er involverede i SCRUM forløbet deltager her. På workshoppen aftales hvilke dele af backloggen, der skal laves på den kommende Sprint. Disse dele der bliver udvalgt bliver derefter en del af Sprint Backloggen, som er en erstatning for en projektplan. I dette forløb bruges der også et Burn Down Chart, dette visualiserer den resterende mængde timer i en Sprint dag for dag. Ud fra dette kan medlemmerne af 7 http://en.wikipedia.org/wiki/database_normalization, besøgt d. 06/12/2012 5

Teamet se, om indholdet i en Sprint skal reduceres eller forøges. Dette er med til at sikre en høj effektivitet gennem den givne Sprint. 8 SCRUM Vi har valgt at dele programmeringen op i to dele: CMS system delen hvor administratoren redigere og indsætter nyt indhold (normal hjemmeside) o Indhold indsættes i en database Mobilsiderne som brugerne ser og interagerer med o Indholdet fra administratoren hentes fra databasen Scrum roller Fordi vi kun er to personer i projektet, tager vi os begge af alle opgaver, der måtte opstå. Derfor ser rolle fordelingen således ud: Product owner 9 : Allan og Jeppe Scrum master 10 : Jeppe Team 11 : Allan Product backlog 12 Rolle Funktion Prioritet Forventet værdi Forventet tid i timer Admin Oprette en ny by, rute og post 1 7 6 8 The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework 9 Product Owner eller produkt ejeren, er den produkt ansvarlige. Her er det vigtigt at vælge en handlekraftig og beslutsom person. Product Owner styrer prioriteringen af indholdet og processen med at vælge indholdet til hver sprint. Product Owner styrer desuden også Product Backlog. 10 Teamet er det hold af personer, der arbejder med Sprint på Sprint Planning Workshop. Et Team beslutter indbyrdes hvor meget de kan nå på et Sprint forløb. Det er vigtigt for Teamet at sætte realistiske mål i et Sprint, da alle målene skal nås indenfor en kort tidsramme. I Teamet er det desuden meget vigtigt at have en gruppe af forskellige mennesker, eksempelvis designere, kodere og testere, da Teamet er ansvarligt for alt arbejde der udføres. Teamet er desuden også dem der opretter Sprint Backlog og organiserer arbejdet. 11 Scrum Masteren er den, der fungerer som en coach i forløbet, både for Teamet og Product Owner. ScrumMaster er ofte den daglige leder af arbejdet og den eneste kanal ind og ud af Teamet. Personer løser, eller er med til at løse, de problemer der eventuelt kommer frem på de daglige SCRUM møder (Daily Scrum). 12 Et SCRUM forløb starter typisk med at Product Owner udarbejder et Product Backlog, også kaldet en kravspecifikation. Et Product Backlog indeholder produktets funktion. Disse funktioner er aldrig låst fast, da nyt indhold altid kan tilføjes. Alt indhold i Product Backlog bliver dog prioriteret, så det vigtigste indhold altid bliver lavet først. Der kan tilføjes alt fra ønsker, krav, fejlrettelser, teknologi, egenskaber m.m. 6

Admin Redigere indhold (kategorier, koordinater, tekst, billeder og lyd) 2 6 7 Admin Logge ind på CMS 3 5 4 Bruger Læse og lære om historien bag diverse seværdigheder 4 7 3 Bruger Få teksten læst op (afspiller) 5 5 4 Bruger Se billeder (galleri) 6 4 4 Bruger Bruger Se ruten til næste punkt (Google Maps med Lat. og Long.) Scanne en QR kode som fører til en mobilside 7 5 6 8 4 3 Sprint backlog Hver af vores sprints varer en uge. Her er sprint forløbet for første uge. Vi begynder med at programmere CMS systemet for administratoren. Product backlog funktion Sprint opgave Tager sig af arbejdet Forventet tid i timer Oprette en ny by, rute og post Oprette database tabeller Allan, Jeppe 1 Oprette en brugerflade hvor der er inputfelter til navn af by, rute, poster og info tekst PHP/SQL som indsætter inputsne i databasen 2 3 7

Redigere indhold (kategorier, koordinater, tekst, billeder og lyd) Oprette en brugerflade hvor der er inputfelter til indholdet PHP/SQL som indsætter inputsne i databasen Allan, Jeppe 3 4 Timer i alt 13 Burndown chart Nedenstående tabel er en oversigt over, hvor meget arbejde der stadig er tilbage af Scrum forløbet de enkelte dage. Dag 0 1 2 3 4 Timer tilbage af arbejde 13 12 9 5 0 Ud fra denne tabel har vi lavet en graf, der visuelt viser processen. 13 Delkonklusion Ved hjælp af udviklingsmetoden Scrum, har vi kunnet fokusere på de enkelte opgaver, uden at miste overblikket. Vi har hele tiden haft overblik over, hvilke opgaver der manglede og hvilke der var færdige eller igangværende. Resultatet af brugen af Scrum ses i den kvalitet arbejdsforholdene har været under, samt resultatet af produktet. Resultatet er blevet til en prototype, der viser de basale funktioner i vores CMS system. Dermed har det været en succes at benytte Scrum, særligt fordi der har været nogle ændringer undervejs, hvor metoden netop har sine styrker. 13 Se bilag 1 8

Use Case Diagram Dette lille use case diagram viser funktionaliteten af vores prototype. Diagrammet viser, at en administrator skal kunne redigere listen over byer. For at kunne dette skal administratoren først logge ind. Scenarier Login: admin vil logge ind Et af følgene kan forekomme: Admin skriver korrekt username og password og kommer ind. Admin skriver forkert username eller password og kommer ikke ind. Maintain cities: admin vil redigere i listen over byer Et af følgene kan forekomme: Admin opretter en ny by Admin sletter en by Admin ændre navn på by Delkonklusion Diagrammet har hjulpet os til at forstå de vigtigste funktioner, som brugeren har adgang til, og hvilke problemer der kan opstå. 9

3-tier architecture Så snart at en bruger redigere indholdet i CMS systemet, så vil den information gennemgå de 3 trin/tiers. Først og fremmest sendes der en anmodning til serveren, hvori der står en bestemt information. Denne anmodning tolker serveren og henter det ønskede materiale frem fra en database. Materialet bliver igen bearbejdet hos serveren, hvorefter det bliver sendt til klienten og browseren. Delkonklusion Denne løsning har været særdeles velegnet til vores system, da den opfylder kravene om redigering i databasen via serveren. På denne måde opstiller vi et CMS system, der kombinerer de tre tiers og dermed åbner muligheden for at kombinere CMS system / administrator siden med mobilsiderne som brugerne ser og interagerer med. 10

Sequence Diagram 14 Her er et lille sequence diagram, som viser et eksempel på en administrator, som logger ind i CMS systemet, opretter, redigere og sletter byer. Der er ikke så meget fokus på selve log ind delen, så sequence diagrammet illustrerer ikke, hvordan vi har tænkt os at gøre med sikkerhed osv. Delkonklusion Diagrammet har hjulpet os med at få overblik over, hvad der sker når en administrator bruger CMS systemet. Det gør det nemmere for os at se, hvad der sker i forløbet og dermed nemmere at programmere. Class Diagram Diagrammet viser klasserne i vores prototype. Klasserne Login, City og Edit er forbundet med Connection med stiplede linjer med hvide pile, som indikerer realizations 15. I klassen Connection defineres host, database navn, brugernavn og kodeord til databasen og metoden dbconnect opretter en forbindelse dertil. Dette skal bruges i Login, City og Edit, og vi har derfor en realization forbindelse. 14 Se bilag 2 15 I en realization forbindelse implementeres funktionalitet fra én klasse til en anden. Forbindelsen vises med en hvis pil med en stiplet linje, der går fra klassen, som definerer funktionaliteten til den klasse, hvor man implementerer funktionen. 11

Delkonklusion Diagrammet har hjulpet os med at programmere systemet på den mest effektive måde. Database Vores database er optimeret efter den 3. normalform. Inddelingen af tabellerne er som følge af 1NF, 2NF og 3NF: 1NF opfyldes ved, at der ikke optræder flere værdier i de enkelte felter. 2NF opfyldes, da hver enkelt primærnøgle har sin egen tabel. 3NF opfyldes, da felterne i hver tabel kun er afhængig af primærnøglen. Konklusion For at kunne give brugerne den bedste oplevelse med vores produkt, er det essentielt, at vi har mulighed for at redigere og oprette indhold i løbet af kort tid. Derfor har vi udviklet et CMS system, så vi nemt kan administrere mobilsiderne. Til dette har vi benyttet en række metoder, der har hjulpet os med at skabe overblik og samhørighed mellem elementerne. Dermed er systemet gjort brugervenligt og ligetil. Desuden har vi benyttet velkendte teknologier i en ny sammenhæng. Det betyder at systemets opbygning ligeledes er velkendt. Dermed sortere vi ikke potentielle brugere fra, i håb om at skabe noget helt nyt og smart. Og på den måde har vi udviklet et system, der kan være med til at gøre hverdagen lidt mere spændende uden at sprænge rammerne for den gængse tekniske formåen. 12

Litteraturliste Bøger: UML Demystified: A Self-Teaching Guide Forfatter: Paul Kimmel Publiceret: Oktober 2005, 1. oplag Udgivet af: McGraw-Hill Osborne Media Hjemmesider: http://en.wikipedia.org/wiki/database_normalization, besøgt d. 11/12/2012 http://en.wikipedia.org/wiki/multitier_architecture, besøgt d. 11/12/2012 Andre publiceringer: The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework Forfatter: Jeff Sutherland Publiceret: April 2012, Version 1.1 Udgivet af: Scrum, Inc., One Broadway, 14th Floor, Cambridge, MA 02142 13

Bilag 1 14

Bilag 2 15