Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Produktrapport
1 Innholdsfortegnelse 1 Innholdsfortegnelse... 1 2 Produktdokumentasjon... 2 3 Beskrivelse av mobilapplikasjonen... 3 3.1 Generell beskrivelse... 3 4 Rammekrav... 3 4.1 Krav til løsning... 3 4.1.1 Funksjonskrav... 3 4.1.2 Tekniske krav... 3 4.1.3 Teknologi... 4 4.1.4 Økonomi... 4 5 Sentrale funksjoner... 4 5.1 Administrator... 5 5.1.1 Opprette... 5 5.1.2 Endre... 6 5.1.3 Slette... 6 5.1.4 Invitere... 6 5.2 Brukergrensesnitt... 6 5.2.1 Teknisk brukergrensesnitt... 6 5.2.2 Interaksjonsteknikker... 7 5.2.3 Skisser... 8 6 Teknisk arkitektur... 10 6.1 Backend... 11 6.2 Frontend... 14 7 Verifisering... 15 8 Metode og planlegging... 15 8.1 Scrum/vannfall... 15 8.2 Parprogrammering... 16 8.3 Utviklingsmiljø... 16 9 Sikkerhet... 16 9.1 OAuth 2.0 authorization framework... 17
2 Produktdokumentasjon Produktdokumentasjonen inneholder en beskrivelse av hvordan oppgaven er løst. Inneholder en beskrivelse av applikasjonen/produktet, rammekravene, arkitektur, funksjoner, verifisering og sikkerhet. Produktdokumentasjonen gir en beskrivelse av: Krav til løsning Applikasjonens funksjoner Brukergrensesnitt Teknisk arkitektur Verifisering av applikasjonen Sikkerhet
3 Beskrivelse av mobilapplikasjonen I dette kapitelet gis det en grundig beskrivelse av mobilapplikasjonen. Både dens funksjonalitet og overordnede struktur. Hensikten er å gi en innsikt til leseren om hvordan applikasjonen er bygd opp. 3.1 Generell beskrivelse Mobilapplikasjonen er en arrangementbehandler for ansatte hos Accenture, med en tilhørende webside for påmelding av studenter. Applikasjonen skal bidra til bedre flyt og mer oversiktlig håndtering og planlegging av kommende arrangementer hos sluttbruker. Brukeren blir gitt full kontroll til å opprette, vedlikeholde og slette arrangementer, sende ut invitasjoner og se hvem som er påmeldt. I tillegg til å ha en oversiktlig sjekkliste for å sørge for at klargjøringen til arrangementet blir gjennomført. 4 Rammekrav Rammekravene som her beskrives, er krav og avgrensninger, som ble satt før utviklingen startet. 4.1 Krav til løsning Kravene er blitt endret underveis i samarbeid med Accenture. For den endelige kravspesifikasjonen se Vedlegg. 4.1.1 Funksjonskrav Mobilapplikasjonen skal være tilgjengelig for alle accenture-ansatte. Man skal kunne registrere arrangement på gitt dato. Skal ta imot påmeldinger fra studenter via webgrensesnitt. Skal sende kvittering til studenter via mail, med bekreftelse om tid/sted ELLER informasjon om at arrangementet er fullbooket og at de vil kontaktes via telefon. Visning av enkelt arrangement med påmeldte studenter. Skal kunne legge til sjekklistepunkter i arrangement Skal kunne tildele en accentureansatt til et arrangement, som ansvarlig. Skal ha mulighet for å flytte eller stokke på avtaler i arrangementet med automatisk e- postbekreftelse til involverte studenter. 4.1.2 Tekniske krav Utvikles i HTML5, CSS og JavaScript(jQuery, Ajax, jquery Mobile) Kompileres til smarttelefonplattformer med PhoneGap Build. Bruker Netbeans 7.2 til å skrive koden. Backend skal skrives i rammeverket CodeIgniter(PHP) og følge REST. JSON skal brukes til å overføre data til og fra mobil. OAuth skal brukes til sikker sending av data. MySQL skal brukes til databasespørringer. Design skal følge retningslinjene til forskjellige OS
4.1.3 Teknologi Her følger en kort beskrivelse og bruksområde for noen av de mest sentrale teknologiene brukt i systemet. 4.1.3.1 CodeIgniter CodeIgniter er et open source MVC rammeverk for oppsett av webapplikasjoner og er skrevet i PHP. Rammeverket ble benyttet for å skrive backend og lage API et. Mobilapplikasjonen prater med API, som sender forespørsler frem og tilbake til modeller for å hente ut ønsket data. 4.1.3.2 Phonegap Build Phonegap Build er en hybrid skytjeneste for å kompilere HTML5-, CSS- og JavaScript-basert kode til flere forskjellige plattformer uten å måtte installere hver enkelt kompilator på lokal PC. Filene kobles enten direkte mot et gitrepository eller lastes opp som en zip-fil på nettsiden. Applikasjonen kompileres og kan enkelt hentes ned ved å skanne en QR-kode eller laste ned filen manuelt og installere. Mobilapplikasjonen det i denne rapporten er snakk om, ble kompilert i Phonegap Build v. 2.3. 4.1.3.3 jquery Mobile jquery Mobile er et touch-optimalisert rammeverk for smarttelefoner og nettbrett. Et HTML5-basert brukergrensesnittsystem for alle populære mobilplattformer. Har en enkel måte å bruke themes for å style utseende. I applikasjonen er det importert jquery Mobile og tilhørende CSS fil på klientsiden. Applikasjonen bruker themebasert utseende, med modifikasjoner i både theme og CSS. 4.1.4 Økonomi I utgangspunktet er dette en nullbudsjettsoppgave, men Accenture stiller med nødvendig hardware og software. Dette inkluderer to bærbare maskiner, samt standard programvare på dem som Microsoft Office mm. Accenture har også stilt med lisens til Apple iphone, for å kunne kompilere kode til angitt mobiltelefon. 5 Sentrale funksjoner Applikasjonen har kun en type bruker og det er Accenture-ansatte. Det er da et admin brukersnitt de bruker. Studenter, som skal melde seg på, bruker en tilhørende påmeldingsside på web, som er unik for hvert arrangement. Slik er dagens situasjon og skal ha tilnærmet samme funksjonalitet med den nye løsningen. (Bilde: 5.1)
Bilde: 5.1 5.1 Administrator En accenture-ansatt, videre referert til som administrator, har full kontroll over arrangementer. Opprette, endre, slette og invitere til arrangementer. 5.1.1 Opprette Når et arrangement blir opprettet må en rekke felter fylles ut, som navn, ansvarlig, dato, sted osv. Etter data er fylt ut og sendt til lagring, vil en sjekkliste for punkter som må utføres bli opprettet og blir tilgjengelig fra arrangementet. Denne listen kan oppdateres ved å ferdigstille, oppdatere, legge til og slette sjekkpunkt. Hvert nytt arrangement vil også bli tildelt en startstatus, som NY. Denne
statusen endres i arrangementets planlegging, men kun en status av gangen for å ha kontroll over at alle stadier blir utført. 5.1.2 Endre Hvert arrangement kan endres til en hver tid. Gjøres enkelt ved å oppdatere felt for felt. Her endres også status for arrangement referert til i 5.1.1. 5.1.3 Slette Om et arrangement ikke skal finne sted lenger, kan det slettes, og en advarsel gis før dette gjennomføres. 5.1.4 Invitere Et arrangement krever påmeldte og det er stort sett studenter som skal melde seg på. Som nevnt i innledningen til kapitelet eksisterer det en unik webside til hvert arrangement. Hvert arrangement har en egen URL en lagret sammen med resten av dataene. Denne URL en brukes for å bestemme hvilket arrangement studenten melder seg på. Det finnes en egen knapp for å invitere til hvert arrangement, og det bygges en tekst basert på data fra arrangementet, som settes i meldingsfeltet, og lastes over til brukerens epostklient. Mailen sendes som regel til en ansvarlig på en skole, som videresender internt til grupper av studenter. Studenten følger URLen og legger inn sin informasjon og kommer dermed opp i listen over påmeldte studenter i mobilapplikasjonen. 5.2 Brukergrensesnitt På en mobilapplikasjon er brukergrensesnittet et av de mer viktige punktene, da dette har stor betydning for brukeropplevelsen. I dag brukes stort sett touch smarttelefoner, og byr på utfordringer som at folk skal fysisk klikke på elementer plassert på en relativt liten skjerm. Derfor er utseende og oppbygningen av brukergrensesnittet viktig. 5.2.1 Teknisk brukergrensesnitt For å lage brukergrensesnittet til applikasjonen ble det dratt inn en del tilleggsfunksjonalitet for at applikasjonen skulle fungere som ønsket. Der i blant var det biblioteker, teknikker og utseendefiler, som bidro til penere utseende og kode, høyere kodefunksjonalitet og bedre touchstøtte. jquery Mobile (JavaScript og CSS) jquery (JavaScript) Mustache templates (HTML) Ajax (Asynchronous JavaScript and XML) JSON (JavaScript Object Notation) Disse teknologiene er forklart i kapittel 4.4 i prosessdokumentasjonen.
5.2.2 Interaksjonsteknikker 5.2.2.1 Touch Siden dette er en mobilapplikasjon, så har vi måtte lage og utforme alt i forhold til det. Koden er skrevet som Markup Language, men kompileres i Phonegap Build til de forskjellige plattformene vi ønsker, og det er her koden blir touch- og mobilvennlig. Bilde: 5.2 5.2.2.2 Ajax (Asynchronous JavaScript and XML) Gir oss muligheten til å laste inn data fra server uten å måtte laste siden brukeren befinner seg på. Dette gir en bedre brukeropplevelse og gjør applikasjonen mer responsiv. 5.2.2.3 Klientvalidering Når det skal settes inn nytt arrangement i applikasjonen må gitte felter være fylt ut. Dette kontrolleres med en klientvalidering. Nedtrekksmenyer er på en måte allerede validert, med at data hentes fra en forhåndsutfylt tabell og puttes inn som valg i menyene. Bilde: 5.3 5.2.2.4 Popup-valg Mobiscroll er en egen datovelger importert i vårt system. Gir en elegant og oversiktelig måte å sette dato og tid vha. touch. Nedtrekksmenyer kommer frem når du klikker på menyelementer som du ser på bilde 5.3. Gir en klar og enkel måte å velge menyelement på. Kommer i ettvalgs- og flervalgsmenyer. Lokal epostklient popper opp når du klikker send i vinduet vist under. Dette er et valg du har til hvert arrangement for å invitere studenter.
Bilde: 5.4 5.2.3 Skisser Før arbeidet startet med å lage applikasjonen ble det laget noen skisser i Balsamiq Mockups (se kapitel 4.4 i prosessrapport). Bilde 5.5 er av startsiden i applikasjonen. To forskjellige varianter, hvor kun den venstre versjonen ble implementert i vårt system. Skissen til venstre er en liste over arrangementer i systemet.
Bilde: 5.5 Bilde 5.6 er en skisse av tenkt funksjonalitet når det legges til et nytt arrangement (venstre), og en tilhørende sjekkliste (høyre).
Bilde: 5.6 6 Teknisk arkitektur Eventhandler er bygget opp med en serviceorientert arkitektur (SOA) som skissert i bilde 6.1. Frontend (mobilapplikasjonen) og påmeldingssiden kommuniserer med backend via et API, som tar seg av alle spørringer mot databasen.
Bilde: 6.1 Videre følger en beskrivelse av frontend og backend som viser oppbygging og kodeeksempler. 6.1 Backend All kommunikasjon i systemet går gjennom API et i backend. Backend er skrevet i PHP og benytter seg av rammeverket CodeIgniter som er basert på model-view-controller (MVC). Dette designmønsteret brukes for å skille mellom data (model) og brukergrensesnitt (view) mens et mellomliggende komponent (controller) tar seg av kommunikasjonen mellom view og model. Viewdelen er ikke tatt i bruk ettersom brukergrensesnittet ligger i frontend. Bilde: 6.2
Bilde: 6.3 Kontrolleren api.php inneholder alle tilgjengelige ressurser og er implementert på en RESTful måte. Dvs. at kontrolleren kan inneholde ressurser med samme navn men som bruker forskjellige HTTPverb eller request methods. HTTP-verbene som er tatt i bruk er: GET hente ut informasjon fra databasen. POST lager en ny oppføring i databasen. PUT oppdaterer en oppføring i databasen. DELETE sletter en oppføring fra databasen. Følgende kodeeksempel er ressursen for å liste ut alle arrangementer.
//Gets all events function arrangementer_get() { $this->load->model("arrangement_model"); $data = $this->arrangement_model->hentalle(); } if($data) { $this->response($data, 200); } else { $this->response(null, 404); } Bilde: 6.4 Totalt inneholder API et disse ressursene: Ressurs Metode Beskrivelse arrangementer Get Henter alle arrangementer. arrangement Get Henter arrangement med gitt ID. arrangement Post Setter inn arrangement arrangement Put Endrer arrangement med gitt ID arrangement Delete Sletter arrangement med gitt ID arrangementurl Get Henter URL til påmeldingssiden for studenter poststed Get Henter poststed med gitt postnummer sjekkpunkter Get Henter alle sjekkpunkter til et gitt arrangement sjekkpunkt Get Henter sjekkpunkt med gitt ID sjekkpunkt Post Setter inn sjekkpunkt sjekkpunkt Put Endrer sjekkpunkt sjekkpunkt Delete Sletter sjekkpunkt med gitt ID items Get Henter alle predefinerte sjekkpunkter aktivitetstyper Get Henter alle aktivitetstyper accusers Get Henter alleaccenture-brukere statuser Get Henter alle statuser skoler Get Henter alle skoler skolegrupper Get Henter alle skolegrupper skolegruppe Get Henter skolegruppe knyttet til ID på arrangement skolegrupper Post Setter inn skolegruppe student Get Henter alle studenter med gitt arrangement ID student Post Setter inn student Modellene har navn etter hvilken tabell i databasen de aksesserer og inneholder metoder for å hente, sette inn, oppdatere og slette oppføringer. Her er et eksempel på en hent-metode i modellen sjekkpunkt_model.php:
//Returns a spesific Sjekkpunkt function hentsjekkpunkt($idsjekkpunkt) { $sql = "SELECT * FROM Sjekkpunkt WHERE idsjekkpunkt = $idsjekkpunkt"; } $query = $this->db->query($sql); if($query->num_rows() > 0) { return $query->result(); } Bilde. 6.5 6.2 Frontend Frontend er selve mobilapplikasjonen som brukerne interagerer med og som installeres på telefonen. Frontend kommuniserer med backend via ressusene som ligger i API. Frontend er skrevet i HTML, JavaScript og CSS og benytter seg av rammeverket jquery Mobile. Rammeverket bruker en «singlepage» modell, dvs. at ved kjøring, så lastes sidene inn og ut av et enkelt HTMLdokument. Pga. dette trenger man kun å laste inn biblioteksfiler og scripts i index.html. Alle sidene i applikasjonen ligger i hver sin HTML fil med hver sin tilhørende JavaScriptfil som håndterer data. Bilde: 6.6 For å lage en side i jquery Mobile definerer man en <div> og legger til data-role= page :
<html> <head> </head> <body> <div id="eventdetailspage" data-role="page"> <...> </div> </body> </html> Bilde: 6.7 Så lastes siden inn i dokumentet med følgende JavaScript-kode: $(document).on('pageshow', '#eventdetailspage', function(event) { id = geturlvars()["id"]; displayevent(id); }); Bilde: 6.8 Ajax brukes for å gjøre kall mot backend. Disse metodene ligger i getdata.js Eksempel på et Ajax-kall: this.updatearrangement = function(data, callback) { $.ajax({ type: "PUT", contenttype: "application/json", datatype: "json", url: (serviceurl + "/api/arrangement/format/json"), data: JSON.stringify(data), cache: false }).done(function(returningdata){ calllater(callback, returningdata); } Bilde: 6.9 7 Verifisering Under hele prosessen er det testet og optimalisert kode til beste evne. Programkode og samspillet mellom applikasjon og eksterne enheter er testet. Når det gjelder validering er dette et punkt som havnet lenger nede på prioriteringslisten, og derfor er det kun validering på klientside i denne versjonen (se kap 5.2.2.3). For mer info om testene som er utført, bes leseren henvende seg til vår detaljerte testrapport. 8 Metode og planlegging For å komme i mål og ha en god arbeidsflyt er det tatt i bruk ulike metoder, teknikker og verktøy. 8.1 Scrum/vannfall Applikasjonen er utviklet vha. verdier fra de to utviklingsmodellene Scrum og Vannfall.
Bilde: 8.1 (venstre: Vannfall, Høyre: Scrum) Backlog, sprints og daglige møter fra scrum er brukt. Og prinsippet med å sette opp frister og milepæler fra vannfallsmetoden. Scrum er en iteraktiv og inkrementell smidig utviklingsmodell. I Scrum blir det ikke definert hvordan noe skal gjøres, men heller hva som skal gjøres. Vannfall er en streng utviklingsmodell, som vist på venstre figur 8.1, så går det ingen piler tilbake. Det er kun brukt muligheten for å sette frister med vannfallsmetoden, for å kunne sette opp en plan fra start til slutt. 8.2 Parprogrammering Er en enkel metode hvor den ene sitter og koder, mens den andre sitter og følger med. Denne metoden er mye brukt når det ikke er så mange gruppemedlemmer. En del av koden er skrevet av gruppemedlemmene i plenum. 8.3 Utviklingsmiljø Da oppgaven vår var å lage en mobilapplikasjon, som skulle kompileres og distribueres, så var det lett og logisk å skrive klientkoden lokalt, med ekstern backup. Backend ble også i starten skrevet lokalt, da ingen andre trengte tilgang før brukertestingen skulle starte. Mot slutten ble backend lastet opp live hos «itforalle» (firmaet til en klassekamerat), for å kunne tillate brukertesting live. Databasen ble til fordel lagret eksternt hos «itforalle» under hele prosessen for å slippe å måtte laste opp og ned databasefiler lokalt. 9 Sikkerhet Sikker sending av data er et punkt som i samarbeid med veilederne er valgt å nedprioritere da funksjonalitet i applikasjonen kom foran. Derfor ligger det ved en beskrivelse av en mulig løsning, som kan implementeres på sikt.
9.1 OAuth 2.0 authorization framework Det var i løsningen meningen å bruke OAuth 2.0 authorization framework. OAuth gir muligheten til å begrense tredjepartsapplikasjoner sin tilgang til en http-tjeneste. OAuth er til fordel gratisvare. Nettsiden http://oauth.net/ sier: OAuth er en åpen protokoll for å tillate sikker autorisasjon i en enkel og standard metode for web, mobil og skrivebordsapplikasjoner. OAuth støtter de fleste store språk, og da også CodeIgniter, som er skrevet i PHP. Her finnes en liste over støttede språk http://oauth.net/code/. OAuth er en anerkjent sikkerhetsprotokoll og brukes i dag av store aktører som Facebook og Twitter.