Matematikbiennalens informationssystem

Transkript

1 Umeå universitet 31 maj 2013 Institutionen för datavetenskap 5DV087 Programvaruteknik VT 13 Teknisk dokumentation Matematikbiennalens informationssystem Versionsnummer Datum Version Första utkastet Andra utkastet Tredje utkastet Första versionen Handledare Jan-Erik Moström Jonny Pettersson

2 Dokumenthistorik Version Utförda förändringar 0.1 Första utkastet 0.2 Läsanvisningar tillagda i Introduktion Beskrivning av lösningen uppdaterad Driftsättning uppdaterad för ios-applikation, Administrationsverktyg, Server och Databas Användarguide uppdaterad för Administrationsverktyg Spårbarhetsmatris för användarfall-komponenter tillagd Avsnittet Grafisk design Mobila applikationer ersätter motsvarande avsnitt för Android- & ios-applikation Grafisk design uppdaterad för Administrationsverktyg Detaljerad design uppdaterad för Webbapplikation, Android-applikation, Administrationsverktyg samt Databas Nytt avsnitt Implementation Nytt kapitel Tester Målet Filtrera nyheter borttaget Nya användarfall Tabell angående implementerade och testade användarfall uppdaterad Nya scenarion för användarfall ER-diagram över databas uppdaterad Schema över databas uppdaterad API-specifikation uppdaterad Administrationsverktyg: Klassbeskrivningar tillagt Fortsättning nästa sida.

3 Version Utförda förändringar 0.3 Dokumenthistorik tillagd Sammanfattning av användarfallen tillagd i Beskrivning av lösningen ios-version bytt till 5.1 Driftsättning uppdaterad för Administrationsverktyg samt Server Användarguide uppdaterad för Android-applikation, ios-applikation samt Administrationsverktyg Kopplingen krav-komponenter borttagen Kopplingen användarfall-komponenter uppdaterad Arkitekturdesign uppdaterad Grafisk design uppdaterad för Mobila applikationer samt Administrationsverktyg Inledningen för Grafisk design uppdaterad Detaljerad design uppdaterad för Webbapplikation, Android-applikation, ios-applikation, Administrationsverktyg samt Databas Implementation uppdaterad för Webbapplikation, Android-applikation, ios-applikation, Administrationsverktyg samt Databas Systemtester uppdaterad Tester uppdaterad för Webbapplikation, Android-applikation, ios-applikation samt Administrationsverktyg Svarsalternativ för enkät tillagda Användarfall ändrade enligt beställares önskemål Användarfall och scenario för Ladda upp program samt Läsa allmän information tillagda Prioritering av användarfall uppdaterad enligt beställares önskemål Scenarion namngivna Krav för alla användarfall tillagda Spårbarhetsmatris för användarfall-krav tillagd ER-diagram över databas uppdaterad Schema över databas uppdaterad API-specifikation uppdaterad Administrationsverktyg: Komponentbeskrivningar ersätter Administrationsverktyg: Klassbeskrivningar 1.0 Beskrivningen av Systemadministratör i Introduktionen uppdaterad Driftsättning uppdaterad för Webbapplikation, Android-applikation samt Databas Sökvägar i Driftsättning uppdaterade Användarguide uppdaterad för Webbapplikation, Android-applikation, ios-applikation samt Administrationsverktyg Inledningen för Systembeskrivning uppdaterad Arkitekturdesign uppdaterad Användargränssnitt uppdaterad för Webbapplikation samt Mobila applikationer Detaljerad design uppdaterad för Webbapplikation, Android-applikation, ios-applikation samt Databas Innehåll flyttat från Detaljerad design till Implementation för Android-applikation, Administrationsverktyg samt Server Implementation uppdaterad för Webbapplikation, ios-applikation samt Databas Tester uppdaterad förutom komponentavsnittet där enbart Webbapplikation är uppdaterad Användarfall ändrade för att kunna användas för systemtester Tabellen för implementerade och testade användarfall uppdaterad Krav om att administratör ska kunna läsa nyheter tillagt Tabellen för implementerade och testade krav uppdaterad API-specifikation uppdaterad ER-diagram över databas uppdaterad Schema över databas uppdaterad Nya bilagor ios-applikation: Komponentbeskrivningar & Webbapplikation: Komponentbeskrivningar 2

4 Innehåll Innehåll Innehåll 1 Introduktion Bakgrund Beskrivning av målgruppen Beskrivning av lösningen Användarhandledning Driftsättning Webbapplikation Android-applikation ios-applikation Administrationsverktyg Server Databas Dokumentation Användarguide Webbapplikation Mobila applikationer Administrationsverktyg Systembeskrivning Arkitekturdesign Grafisk profil Användargränssnitt Webbapplikation Mobila applikationer Administrationsverktyg Detaljerad design Webbapplikation Android-applikation ios-applikation Administrationsverktyg Server Databas Implementation Webbapplikation Android-applikation ios-applikation Administrationsverktyg Server Databas Tester System i

5 Innehåll Innehåll 4.2 Acceptans Komponenter Webbapplikation Android-applikation ios-applikation Administrationsverktyg Server Databas Litteraturförteckning 56 A Intressentanalys B Enkät C Intervjuer D Användarfall och scenarion E Krav A1 B1 C1 D1 E1 F ER-diagram över databas F1 G Schema över databas H API-specifikation G1 H1 I ios-applikation: Komponentbeskrivningar I1 J Administrationsverktyg: Komponentbeskrivningar J1 K Webbapplikation: Komponentbeskrivningar K1 L Enhetstester för ios-applikation L1 M Manuella tester mobila applikationer N Manuella tester Webbapplikation M1 N1 ii

6 Kapitel 1. Introduktion Kapitel 1 Introduktion Detta dokument syftar till att dokumentera en tjänst som ska användas av Matematikbiennalen under I avsnitt 1.1 beskrivs tjänsten, både i form av vilka beställarna är och vad den ska användas till samt att det behandlas vilka som hör till målgruppen och de behov som tjänsten behöver ta hänsyn till. En användarhandledning för driftsättning samt en användarguide för de olika modulerna i systemet finns i kapitel 2. De efterföljande kapitlen handlar om den grafiska designen och hur tjänstens system ska fungera både arkitekturmässigt och på detaljerad nivå. För beställare finns relevans att läsa kapitel 1. Administratörer bör läsa avsnitt 2.2. Systemadministratörer bör läsa avsnitt 2.1, kapitel 3 och kapitel Bakgrund Matematikbiennalen är en återkommande konferens som har genomförts i olika delar av landet. Under biennalen anordnas föreläsningar, workshops och utställningar för deltagarna. Deltagarna representerar skolans alla verksamhetsformer från lågstadier till högskolor samt universitet arrangerade Umeå universitet konferensen med totalt 250 föreläsningar och 2500 deltagare. Även under 2014 står Umeå universitet som värd för konferensen. Till Matematikbiennalen 2014 ska en tjänst tas fram. Det är denna som dokumenteras i detta dokument. Tjänstens syfte är att ge konferensdeltagarna bättre service kring konferensens genomförande, såväl inför som under biennaldagarna. De huvudsakliga funktionaliteterna är: Nyheter: Sprida information om t.ex. inställda/flyttade föreläsningar eller nyinsatta programpunkter. Navigation: Via tjänsten ska man kunna navigera sig på campusområdet. Det ska gå att hitta en specifik föreläsningssal, utställning eller kaffestation. Tillgänglighet: Tjänsten ska fungera för smartphones, surfplattor och datorer samt vara enkel att använda. 1

7 Kapitel 1. Introduktion 1.1. Bakgrund Beskrivning av målgruppen Den identifierade målgruppen för tjänsten, deras behov av tjänsten och allmän statistik gällande dem beskrivs i följande avsnitt. Intressenter En beskrivning av de nedan förklarade intressenteras problem vid Matematikbiennalen 2012 samt mål för Matematikbiennalen 2014 finns i bilaga A. Beställare Projektgruppen för Matematikbiennalen Administratörer Projektgruppen för Matematikbiennalen Användare Denna grupp består dels av besökare på biennalen samt funktionärer hade Matematikbiennalen cirka 2500 besökare. Enligt en enkätundersökning, gjord av projektgruppen för Matematikbiennalen 2012 var 86 % av besökarna år, de jobbade inom olika områden inom skolväsendet, där 48 % jobbade inom grundskolan F ÅK6 och 72 % av besökarna deltog i minst 7 arbetspass. Funktionärsgruppen för Matematikbiennalen 2012 bestod av uppskattningsvis 100 personer. Funktionärerna kunde ha flera olika ansvarsområden och fördelningen för dessa i en enkätundersökning utförd av projektgruppen för Matematikbiennalen 2012 var dessa områden (inom parentes antal svarande som sade sig ha detta ansvarsområde) föreläsningsvärd (58 %), salsvärd (34 %), områdesvärd (20 %), tekniker (8 %) samt annat. Jurister Umeå universitets jurister. Utvecklare Studenter på kursen 5DV087 Programvaruteknik VT13. Vidareutvecklare Framtida arrangörer för Matematikbiennalen som vill använda sig av tjänsten. Matematikbiennalen 2016 kommer exempelvis anordnas av Karlstads universitet. Systemadministratör Den eller de som kommer underhålla tjänsten genom att uppdatera den allmänna informationen, samt införa koordinater för byggnader, salar, toaletter, kaffestationer, med mera i databasen. Enkät För att ta fram kvalitativ information om målgruppen har en enkät använts. Svaren finns sammanställda och utvärderade under bilaga B. Intervjuer För att ta fram kvalitativ information om målgruppen har intervjuer använts. Svaren finns sammanställda och utvärderade under bilaga C. 2

8 Kapitel 1. Introduktion 1.1. Bakgrund Statistik gällande målgruppen Enligt statcounter.com[2] är ios det mest använda mobiloperativsystemet i Sverige (april 2012 april 2013, använt på hemsidor) med 63%, Android det näst mest använda med 35%. Detta innebär att övriga mobiloperativsystem står för knappa 3 %. För de senaste två månaderna är samma siffror 62 %, 35 % respektive drygt 2 %, d.v.s. ingen trend verkar gå att påvisa. Gällande webbläsare (statcounter.com[1]) är fördelningen som i figur 1.1. Vid en titt på de senaste två månaderna är motsvarande siffror 37 %, 28 %, 20 %, 14 %. Det går att se att användningen av Chrome ökar med knappt 5 %-enheter, och användningen av IE minskar med drygt 4 %. Figur 1.1: Fördelning för webbläsaranvändning i Sverige april 2012 april

9 Kapitel 1. Introduktion 1.1. Bakgrund Användandet av olika versioner av IE (Internet Explorer) visas i diagrammet i figur 1.2. IE 8.0 står för en stor del, men IE 9.0 står för nästan dubbelt så mycket användande. Tillsammans står de för 94% av det totala användandet. Figur 1.2: Fördelning för användning av olika versioner av Internet Explorer i Sverige april 2012 april Den grafiska profilen för Matematikbiennalen 2014 måste följas och därför har ingen undersökning gällande grafiska preferenser utförts. Då målgruppen är så pass övergripande anses kraven på interaktionen med systemet vara generella och därför ska interaktionen följa allmänt vedertagna generella interaktionsriktlinjer Beskrivning av lösningen Tjänsten är implementerad med funktionalitet för att publicera och läsa nyheter, samt ett navigeringsverktyg för att hitta på campus. Kraven på tjänsten beskrivs i bilaga E. Användarfall med tillhörande scenarion beskriver all funktionalitet som tjänsten ska innefatta. En sammanställning av användarfallen finns i tabell 1.1. De finns mer utförligt dokumenterade, tillsammans med deras scenarion, i bilaga D. 4

10 Kapitel 1. Introduktion 1.1. Bakgrund Tabell 1.1: Användarfallen identifierade på Matematikbiennalens informationssystem prioriterade. Användarfallen är prioriterade enligt om användarfallet är ett skall- eller bör-användarfall. Skall är sådant som implementeras och bör är sådant som förmodligen kommer att implementeras. Användarfall Prioritering ANV.1 Skapa nyhet ANV.2 Användare kan läsa nyhet ANV.3 Administratör kan läsa nyhet ANV.4 Redigera nyhet ANV.5 Radera nyhet ANV.6 Hitta föreläsningssal ANV.7 Hitta toalett ANV.8 Hitta kaffe ANV.9 Hitta informationspunkt ANV.10 Hitta uställarkategori ANV.11 Hitta till campus ANV.12 Hitta till hotell ANV.13 Hitta till busshållplats ANV.14 Hitta till järnvägsstation ANV.15 Hitta till lunchservering ANV.16 Hitta till parkeringsplats ANV.17 Hitta till utställare ANV.18 Kolla program ANV.19 Ändra föreläsningssal ANV.20 Ändra om en föreläsning är inställd ANV.21 Ändra om en uställning är inställd ANV.22 Logga in som administratör ANV.23 Se dagens lunch ANV.24 Kolla personligt program ANV.25 Ladda upp program ANV.26 Läsa allmän information Skall Skall Skall Skall Skall Skall Skall Skall Skall Skall Skall Bör Bör Bör Skall Skall Bör Skall Bör Bör Bör Skall Bör Bör Bör Skall 5

11 Kapitel 1. Introduktion 1.1. Bakgrund Tjänsten är indelad i sex områden som motsvarar tjänstens olika huvudkomponenter. Dessa huvudkomponenter listas nedan och förhållandena mellan dessa illustreras i figur 1.3. Webbapplikation Ett webbgränssnitt för tjänsten. Android-applikation En android-applikation för tjänsten. ios-applikation En ios-applikation för tjänsten. Administrationsverktyg Verktyg för att kunna publicera nyheter. Server En central del av systemet som är länken mellan applikationerna, adminverktyget och databasen. Databas Lagrar all information som ska kunna publiceras. Figur 1.3: En översiktlig bild över alla komponenter som utgör tjänsten. 6

12 Kapitel 2. Användarhandledning Kapitel 2 Användarhandledning Detta kapitel dokumenterar hur systemet driftsätts och hur tjänsten används. 2.1 Driftsättning Under nedanstående avsnitt beskrivs hur driftsättning av systemets olika delar ska genomföras. De källkods-filer och andra filer som krävs för att driftsätta de olika komponenterna i systemet finns på Webbapplikation För att driftsätta webb-applikationen med full funktionalitet krävs att det existerar en server, se underavsnitt Källkoden för webb-applikationen finns i HTML5.tar.gz. Utöver den vanliga driftsättningen av en webbapplikation krävs följande ändring i applikationens filer. proxy.php kräver att variabeln serverurl specificeras så att den pekar på den server som ska användas. För att driftsätta webb-applikationen behövs en api-nyckel som defineras i maps.html. Information om att generera den API-nyckel som krävs vid uppladdning finns att läsa på Android-applikation Källkoden för android-applikationen finns i android.tar.gz. Android-enheten driftsätts genom att lägga upp applikationen på Google Play. Information om att generera den API-nyckel som krävs vid uppladdning finns att läsa på För att använda programmet laddas det ner från Google Play och installeras på den önskade telefonen ios-applikation ios-applikationen driftsätts genom att lägga upp den färdiga applikationen på itunes Connect som Apple tillhandahåller. Applikationen blir då granskad av Apple, tiden det tar är några dagar upp till ett par veckor. Efter att applikationen har blivit granskad och godkänd av Apple finns applikationen tillgänglig på App Store för iphone och ipad, ios version 5.1 och högre. Källkoden för ios-applikationen finns i ios.tar.gz. 7

13 Kapitel 2. Användarhandledning 2.1. Driftsättning Administrationsverktyg Administrationshemsidans filer läggs på en webbserver med stöd för PHP5 där curl är aktiverat. Källkoden för administrationsverktyget finns i admin.tar.gz Server För att köra serverapplikationen rekommenderas ett POSIX-kompatibelt system. Servern kräver Java Runtime Environment 1.6 eller senare. Dessutom krävs en installation av Apache Tomcat, vidare refererat till som Tomcat. Tomcat är en open-source webbserver utvecklad av Apache Software Foundation (ASF). Tillvägagångssättet för att installera Tomcat finns beskrivet på dess hemsida 1. Det första som måste göras är att sätta upp miljövariabeln $CATALINA_HOME så att den pekar till installationen av Tomcat. Hur detta görs beror på vilket skalprogram som används, nedan följer ett exempel på hur detta kan göras i bash. export CATALINA_HOME=$HOME/lib/apache-tomcat Kompilering och installation Källkoden för servern finns i server.tar.gz. För att kompilera och distribuera systemet används Apache Maven 2, vidare refererat till som Maven, vilket är ett verktyg för att automatisera byggprocessen av ett program skrivet i Java. Det finns två profiler till Maven som kan användas vid byggprocessen, test och prod. Profilen test ska användas vid utveckling eller testning av systemet och prod ska användas när systemet tas i produktion. Om ingen profil anges i byggprocessen användas test. Dessa profiler bestämmer vilka databasinställningar som ska användas, och de kan ändras i filerna filter-<profil>.properties i katalogen src/main/filters/. Serverapplikationen kan kompileras genom att navigera till sökvägen för källkoden och skriva mvn -P <profil> package detta kompilerar källkoden och skapar en distribuerbar fil i katalogen target. För att köra den distribuerbara filen med Tomcat måste filen kopieras till katalogen webapps som ligger i installationskatalogen för Tomcat, det vill säga $CATALINA_HOME/webapps. Serverapplikationen kommer härefter att köras nästa gång Tomcat startas Databas Databasen som används i tjänsten tillhandahålls av Institiutionen för datavetenskap på Umeå universitet och administratörerna autentiserar sig genom sina personliga konton på Umeå universitet. Det finns ett publikt konto med lösenordsinloggning och begränsad åtkomst till databasen. Dessa begränsningar bestäms av databasadministratörerna. Detta konto är tänkt att användas av servern för att lagra och hämta information. Förutom det publika kontot finns även ett konto med fulla rättigheter till hela databasen avsett för systemadministratörer. Systemadministratörerna är de som kommer att underhålla databasen om några förändringar behöver göras

14 Kapitel 2. Användarhandledning 2.2. Användarguide För att skapa databasen finns ett SQL-script som genererar alla tabeller samt konfigurerar dess restriktioner. Detta SQL-script finns i databas.tar.gz. För att köra scriptet krävs att man är uppkopplad mot en databashanterare för PostgreSQL. Detta kan till exempel göras genom den interaktiva terminalen psql 3. För att ansluta till databasen med psql används följande kommando: psql -U <username> -h postgres <database name> Efter inloggning kan scriptet köras genom kommandot: \i DB_generate_tables.sql Systemadministration Systemadministratören har i uppgift att förbereda databasen med viktig data som behövs för att tjänsten ska vara komplett och fungera för både administratörer och användare. Ett sql-script för att skapa databasen med data som samlats in för Campusområdet på Umeå universitet inför Matematikbiennalen 2014 finns i databas.tar.gz. I tabell 2.1 beskrivs vad som måste läggas in i databasen och i vilken ordning det måste ske. Insättning 1. Lägga till administratör. [Admins] 2. Lägga till områden. [Areas] 3. Lägga till byggnader. [Buildings] Lägga till föreläsningssalar. [Lecture_rooms] Lägga till föreläsningar. [Lectures] Lägga till typer för allmänna platser. [General_types] Lägga till allmänna platser. [General_places] Lägga till utställningstyper. [Exhibition_types] Lägga till utställningar. [Exhibitions] 8. Beroende Tabell 2.1: Inom parentes står namnet på den databastabell som insättningen ska ske i Dokumentation Om vidareutveckling av den tekniska dokumentationen är önskvärt, finns källkoden i filen dokumentation.tar.gz. 2.2 Användarguide I följande avsnitt beskrivs hur användaren kan interagera med systemets olika delar Webbapplikation Här nedan beskrivs hur användaren, se avsnitt 1.1.1, kan använda sig av Webbapplikationen för att ta del av det nyhetsflöde som existerar på matematikbennialen. För en mer ingående beskrivning av den design som valts för applikationen se underavsnitt

15 Kapitel 2. Användarhandledning 2.2. Användarguide Nyheter Användaren kan direkt ta till sig av information kring prioriterade nyheter via fältet till höger, användaren får även en överblick av samtliga nyheter via fältet till vänster, se figur 2.1. Figur 2.1: Skärmbild över nyhetsfliken i webb-applikationen. För att ta del av mer utförlig information kring en nyhet kan användaren klicka på en nyhet i det vänstra fältet. Den markerade nyheten expanderar då och delger användaren samtlig information om den valda nyheten. För att återgå till att visa sammanfattningar om samtliga nyheter kan användaren klicka på den expanderade nyheten som då förminskas. 10

16 Kapitel 2. Användarhandledning 2.2. Användarguide Information Under informationsfliken se figur 2.2, möts användaren av allmän information samt en undermeny som både grafiskt och funktionellt följer samma struktur som huvudmenyn. Via undermenyn kan användaren navigera sig vidare till flikar till med mer specifik information. Figur 2.2: Skärmbild över informationsfliken webb-applikationen. 11

17 Kapitel 2. Användarhandledning 2.2. Användarguide Kartor När användaren via den meny som är placerad på samtliga flikar navigerat till kartor möts denne av en karta över universitetsområdet, se figur 2.3. Figur 2.3: Skärmbild över kartfliken webb-applikationen. Precis som i den tryckta programboken är de olika byggnaderna färgkodade. Sökmenyn som är placerad ovanför kartbilden gör det möjligt för användaren att placera ut en eftersökt sal på kartan. Mellan sökfunktionen och kartan presenteras en förklarande text om den eftersökta salen. I det högra fältet presenteras en lista med ikoner, med förklarande text som representerar olika saker på kartan. Under ikonerna kan användaren fortfarande ta del av de prioriterade nyheterna. 12

18 Kapitel 2. Användarhandledning 2.2. Användarguide Mobila applikationer I det här avsnittet beskrivs hur de mobila applikationerna kan användas. Applikationen är indelad i tre flikar: nyheter, info och hitta. När applikationen först startas visas en startsida med Matematikbiennalens logotyp och en startknapp. För att börja använda tjänsten trycker användaren på startknappen och då visas fliken som innehåller nyheter. Navigering mellan de olika flikarna sker via menyraden som sitter längst upp på Android-applikationen, se figur 2.4, och längst ned på ios-applikationen, se figur 2.5. Figur 2.4: Vy över nyhetssidan på Android-enhet. 13

19 Kapitel 2. Användarhandledning 2.2. Användarguide Figur 2.5: Nyhetsfliken i ios-applikationen. Nyheter I nyhetsfliken visas en lista med nyheter som rör Matematikbiennalen. En del nyheter är viktiga och innehåller då information av mer akut karaktär. Dessa viktiga nyheter är rödmarkerade medan vanliga nyheter har grå färg. Nyheterna sorteras först och främst efter prioritet; viktiga nyheter hamnar längst upp i den ordning de publicerades. Därefter sorteras nyheterna efter publiceringstid där de senaste nyheterna hamnar längst upp. Det som visas i nyhetslistan är endast rubriker, tid och datum för publicering samt en liten del av inledningen av nyhetstexten. Genom att trycka på en nyhet i listan expanderas nyheten och hela nyhetstexten visas. Nyheten minimeras genom att trycka på den och den fullständiga nyhetstexten döljs då igen. 14

20 Kapitel 2. Användarhandledning 2.2. Användarguide Info I fliken Info finns information som kan vara till hjälp för deltagare under biennalen. Informationen är indelad i olika kategorier som visas i en lista, se figur 2.6. För att läsa mer om en kategori trycker användaren på vald kategori i listan och då visas texten tillhörande den valda kategorin. För att gå tillbaka till listan med kategorier används Androids vanliga bakåtknapp, och för ios-applikationen knappen längst upp i vyn. Figur 2.6: Vy över infofliken för android-enheter. 15

21 Kapitel 2. Användarhandledning 2.2. Användarguide Hitta För att navigera på området används fliken Hitta där en karta visas med en markering för användarens position. För att se var exempelvis kaffestationer finns utplacerade används den nedre menyn i Android, se figur 2.7, där ett klick på knappen med kaffekopp placerar ut markörer på kartan där dessa stationer finns att hitta. Hittafliken i ios-applikationen visas i figur 2.8. Vid ett tryck på knappen för utställarna visas en extra meny där användaren får välja vilken utställarkategori som ska visas. För att söka efter en sal eller någon annan plats, exempelvis brashörnan, används sökfältet i överkanten. Om ordet som börjar skrivas är en giltig plats under biennalen kommer sökfältet att ge sökförslag för att komplettera ordet som skrivs in, se figur 2.9. Figur 2.7: Hittafliken på Android-applikationen. 16

22 Kapitel 2. Användarhandledning 2.2. Användarguide Figur 2.8: Hittafliken på ios-applikationen. Figur 2.9: Sökfunktionen i hittafliken på ios-applikationen. 17

23 Kapitel 2. Användarhandledning 2.2. Användarguide Administrationsverktyg Följande sektioner beskriver hur användaren gör för att använda respektive funktion. In- och utloggning När användaren startat tjänsten loggar denne in med användarnamn och lösenord, se figur När användaren har loggat in finns, förutom en flik för den aktuella kategorin, även valet Logga ut i menyfältet, se figur Figur 2.10: Administratörsvy initialt. 18

24 Kapitel 2. Användarhandledning 2.2. Användarguide Figur 2.11: Administratörsvy efter inloggning. Nyheter När användaren har loggat in visas vyn i figur Användaren har då följande val. Skapa nyhet: En användare kan fylla i ett formulär med textfält, kryssrutor och tidsfält för att specificera en ny nyhet. Nyhetstexten får inte överstiga 600 tecken och titeln får inte vara längre än 65 tecken. Valet Livslängd för prioritet visas enbart när administratören valt att prioritera nyheten. Nyheten kan publiceras genom att trycka på knappen Publicera. Formuläret rensas när Avbryt -knappen trycks. Nyhetsflöde: En användare kan läsa nyheter som finns lagrade i databasen. Nyare nyheter fylls på uppifrån, för att se äldre nyheter scrollas längre ned. Med bland nyhetsinformationen finns vem som publicerat nyheten och tid för publicering. Tiden en nyhet är prioriterad till syns under publiceringstiden. Prioriterade nyheter har en röd ram. Knappar för att ändra eller ta bort en nyhet finns på varje nyhet. Nyhetsflödet uppdateras automatiskt löpande, sidan behöver inte laddas om för att en förändring som gjorts skall synas, oavsett vem som gjort förändringen. Ändra nyhet: En redan publicerad nyhet kan ändras genom att klicka på Ändra -knappen bredvid nyheten. Då fylls formuläret till vänster med all redan specificerad nyhetsinformation. Efter ändringar klickas Publicera och nyhetsflödet uppdateras automatiskt. 19

25 Kapitel 3. Systembeskrivning Kapitel 3 Systembeskrivning Under detta kapitel finns tjänstens uppbyggnad dokumenterad. Denna dokumentation kommer att utgå från systemets övergripande arkitektur och den grafiska-designen för att därefter avhandla systemets komponenter i detalj. Den detaljerade beskrivningen av komponenterna kommer att bestå av information kring användargränssnitt, komponentens uppbyggnad och implementationsspecifika detaljer. 3.1 Arkitekturdesign Tjänsten består av en server, en databas, ett administrationsgränssnitt och klienter för webb, Android och ios. I figur 3.1 finns en övergripande bild av tjänstens arkitektur. Tjänsten är baserad på designmönstret klientserver då all kommunikation sker via den gemensamma serverns publika API. Detta gör att antalet klienter kan utökas efter behov och klienterna kan välja att bara använda vissa delar. Funktionaliteten kan också utökas utan att påverka de befintliga klienterna. Administrationsgränssittet har funktionalitet för att modifiera och addera till informationen som lagras i databasen vilket även detta går via serverns API. Fördelen med detta är att information kan spridas fortlöpande till konferensdeltagare innan och under konferensen. Informationen som servern tillhandahåller lagras i databasen. Den information som finns lagrad i databasen är nyheter och koordinater till salar och andra platser av intresse runt om på konferensområdet. Klienterna tillhandahåller också allmän information uppdelad i olika kategorier. Denna information ingår endast i klienterna och är inte en del av serverns API och databasen. I tabell 3.1 beskrivs ansvarsfördelningen för komponenterna i designen mot användarfallen i bilaga D. 20

26 Kapitel 3. Systembeskrivning 3.1. Arkitekturdesign Figur 3.1: Ett övergripande diagram för tjänstens arkitektur. 21

27 Kapitel 3. Systembeskrivning 3.1. Arkitekturdesign Användarfall Tabell 3.1: Spårbarhetsmatris över komponenterna mot användarfall. Databas iosapplikation Androidapplikation Webbapplikation Administrationsverktyg ANV.1 x x x ANV.2 x x x x x ANV.3 x x x ANV.4 x x x ANV.5 x x x ANV.6 x x x x x ANV.7 x x x x x ANV.8 x x x x x ANV.9 x x x x x ANV.10 x x x x x ANV.11 x x x x x ANV.12 x x x x x ANV.13 x x x x x ANV.14 x x x x x ANV.15 x x x x x ANV.16 x x x x x ANV.17 x x x x x ANV.18 x x x x x ANV.19 x x x ANV.20 x x x ANV.21 x x x ANV.22 x x x ANV.23 x x x x x ANV.24 x x x x x ANV.25 x x x ANV.26 x x x Server 22

28 Kapitel 3. Systembeskrivning 3.2. Grafisk profil 3.2 Grafisk profil De grafiska gränsnitten för alla ingående komponenter använder de färger som Umeå universitet har i sin grafiska profil samt färgschemat från förra biennalen. För att uppnå detta används den blå färgen, som frekvent figurerar i Umeå universitets publikationer, och de små snöflingorna som finns med i det tryckta programmet. Detta för att besökaren ska känna igen sig från tidigare år och för att visa tillhörighet till Umeå universitet och Umeå. 3.3 Användargränssnitt Nedan följer en beskrivning av de olika komponenternas användargränssnitt Webbapplikation Knapparna på hemsidan fungerar som flikar. Om användaren trycker på en av flikarna blir den vit för att visa att den är nedtryckt medan de övriga flikarna fortfarande är gråa. I den vitmarkerade fliken är texten blå samma som överst på sidan, istället för svart, vilket förtydligar vilken sida som för tillfället är aktiv. Nyhetsfliken, se figur 3.2, är den första sidan som användaren möts av vid användandet av tjänsten. Figur 3.2: Skärmbild över nyhetsfliken i webb-aplikationen. 23

29 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Tanken är att försöka centrera allt så mycket som möjligt för att användaren lätt ska kunna ta in all information. Dessutom gör centreringen att webbapplikationen bättre anpassar sig efter skärmstorleken på användarens enhet. Sidan är uppbyggd på sådant sätt att ett fält med de nyheter som klassats som prioriterade alltid kommer att ligga längst upp till höger så att användaren snabbt kan se det och aldrig kommer missa några nyheter. Det fältet har en röd rubrik för att locka besökarens ögon, allt för att öka sannolikheten att nyheterna blir lästa. Fältet kommer att följa med till alla flikar, inte bara ligga under nyheter. Under de prioriterade nyheterna finner besökaren en lunchmeny där det går lätt att se vilken mat som erbjuds den dagen. I mitten på sidan ligger själva nyhetsflödet. Där kommer alla nyheter läggas som inte är prioriterade. Vartefter att nyheterna publiceras sorteras de så att den senaste nyheten ligger överst. Varje nyhet visas med en rubrik och de 100 första tecknen i nyheten. Då användaren klickar på nyheten expanderar den för att användaren ska kunna läsa hela nyheten. Klickar användaren en gång till på nyheten går den tillbaka till sitt minimerade läge. Då ett av huvudmålen med den grafiska designen varit att behålla den grafiska profilen från föregående års programbok har även kartfliken ett liknande formspråk. Kartflikens grafiska design har valts med utgångspunkt från kartan i programboken som har anpassats till ett webbplatsformat. Kartan är centrerad i mitten av hemsidan. Med hjälp av symboler och färger ska då alla besökare kunna hitta till de ställen de vill. De olika symbolernas färger är valda efter bokens karta för att besökarna ska känna igen sig så mycket som möjligt. Strukturen runtom kartan är samma som i den i tidigare fliken nyheter, se figur 3.3. Figur 3.3: Skärmbild över kartfliken i webb-aplikationen. De viktiga nyheterna är fortfarande lättillgängliga genom sin placering till höger på sidan. Detta för att försäkra spridningen av tidskritisk information till användaren av webbapplikationen. För att användaren ska känna igen sig med navigeringen har google maps valts att användas. 24

30 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Utseendet på informationsfliken se figur 3.4, är på liknande sätt som övriga flikar byggt på en tolkning av motsvarande kapitel i programboken. För att åtstadkomma detta så har texten delats upp i underrubriker en ytterligare effekt av detta val blir att den tänkta användaren leds till relevant information. Figur 3.4: Skärmbild över informationsfliken i webb-aplikationen. 25

31 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Mobila applikationer Användargränssnittet på de mobila applikationerna liknar varandra förutom några skillnader baserade på plattformsspecifika designmönster och riktlinjer för Android- respektive ios-applikationer. Mobilapplikationerna är uppbyggda av flikar där varje funktionalitet är en egen flik. Startsida När applikationen först startas visas en startskärm som ses i figur 3.5. Denna startskärm ser likadan ut på båda plattformar. Figur 3.5: Startskärmen för ios-applikationen. 26

32 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Nyheter Den första fliken som visas efter att användaren tryckt på startknappen är nyhetsfliken och där visas alla nyheter i en lista. Listan består av celler som innehåller en rubrik för nyheten, ett litet stycke ur nyhetstexten samt datum och tid när den skapades eller senast modifierades. Cellerna expanderas och visar hela nyhetstexten när användaren trycker på en nyhet. Detta beteende valdes för att få plats med så många nyheter som möjligt på skärmen samtidigt och för att nyhetstexten kan vara lång. De nyheter som är viktiga är markerade med röd färg för att tydligt uppmärksamma användaren på dess innehåll. En uppdateringsknapp finns så att användaren kan uppdatera vyn till att visa de senaste nyheterna för att känna en trygghet att nyheterna som visas verkligen är de senaste. I figur 3.6 visas utseendet på Android-applikationen och i figur 3.7 visas samma flik i iosapplikationen. Den största skillnaden är att menyraden i ios-applikationen är placerad längst ned istället för längst upp som hos Android-applikationen och att uppdateringsknappen är på olika ställen. Detta kommer utifrån riktlinjerna för utveckling av ios-applikationer som rekommenderar att menyraden ska ligga längst ned. Uppdateringsknappen har placerats längst upp till höger i ios-applikationen för att det är en del av menyraden på plattformen. Figur 3.6: Vy över nyhetsflik i Android-applikationen. 27

33 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Figur 3.7: Nyhetsfliken i ios-applikationen. 28

34 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Info Infofliken, se figur 3.8, är uppbyggd av en lista över olika kategorier av information som exempelvis Parkeringsinformation eller Husinformation. Vid ett klick på någon av kategorierna visas en ny sida med den valda informationen. Figur 3.8: Vy över infofliken för mobiler. 29

35 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Hitta Hittafliken för Android ser ut som i figur 3.9. I figur 3.10 visas samma flik i ios-applikationen. Här är kartan placerad i mitten med en sökfunktion för salar ovanför och en meny för att visa var exempelvis kaffestationer finns nedanför. Sökfunktionaliteten och autocomplete för hittafliken i ios-applikationen visas i figur Figur 3.9: Hittafliken på Android-applikationen. 30

36 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Figur 3.10: Hittafliken på ios-applikationen. Figur 3.11: Sökfunktionen i hittafliken på ios-applikationen. 31

37 Kapitel 3. Systembeskrivning 3.3. Användargränssnitt Administrationsverktyg Det grafiska användargränssnittet för administrationstjänsten lyfter vissa designelement från tjänstens primära hemsida, men hålls ändå visuellt distinkt. Detta är tänkt att förmedla att administrationssidan är relaterad till tjänsten utan att leda till tvetydighet om vilken sida administratören för tillfället använder. Gemensamma komponenter för alla kategorier för administratörsverktyget är följande, se exempelvis figur 3.13: Banner: Överst visas en så kallad banner som följer biennalens grafiska profil. Menyrad: Den gråa menyraden består av en länk till kategorin Nyheter samt Utloggning (visas endast när användaren är inloggad). Kategorierna delar upp administrationsfunktionalitet mellan olika ändamål. Sidfot: Här visas allmän information gällande sidan. Startsida Startsidan ser ut som i figur 3.12 och tillåter administratören att logga in med hjälp av användarnamn och lösenord. Figur 3.12: Administratörsvy initialt. Kategori Nyheter Denna vy tillåter administrering av nyhetsflödet. Den ser ut som i figur Skapa nyhet: Består av ett formulär för att specificera information om en nyhet. Nyhetsflöde: Visar ett dynamiskt nyhetsflöde som successivt fylls på med nyheter uppifrån allteftersom de publiceras. Varje nyhet har knappar för att ändra nyheten eller ta bort den från flödet. 32

38 Kapitel 3. Systembeskrivning 3.4. Detaljerad design 3.4 Detaljerad design Figur 3.13: Administratörsvy efter inloggning. Under följande avsnitt dokumenteras systemets komponenter och dess funktionalitet mer ingående Webbapplikation Webbapplikationen är designad utifrån designmönstret MVC (Model-View-Controller) 1, där strukturen representerar model, designen av webbapplikationen representerar view, beteendet för webbapplikationen och kommunikationen med servern är controller, se figur

39 Kapitel 3. Systembeskrivning 3.4. Detaljerad design Figur 3.14: Illustration av uppbyggnaden på webb-applikationen. Beteendet av webbapplikationen sköter uppdateringen av nyheter från servern. Nyheterna uppdateras automatiskt med hjälp av en timer med ett satt tidsintervall. Varje gång flödet uppdateras skickas en förfrågan från komponenten till servern. Nyheterna delas upp i två kategorier, vanliga och prioriterade. Efter uppdelningen visas nyheterna i dess flikar. Flödet för hur nyheter hanteras illustreras i figur Att hämta information till kartan går till på liknande vis som för att hämta nyheter. Det är fortfarande beteendet av webbapplikationen som hämtar information från servern men det finns ingen timer som hämtar information med jämna mellanrum, utan informationen hämtas bara på användarens begäran. Det skickas en förfrågan från komponenten till servern. Servern skickar sedan tillbaka informationen som då parsas. Sedan sker en sortering av den inkomna informationen. I figur 3.16 presenteras hur kartinformationen läses in. 34

40 Kapitel 3. Systembeskrivning 3.4. Detaljerad design Figur 3.15: Illustration av flödet för att tolka nyhetsinformation i webbapplikationen. Figur 3.16: Illustration av flödet för att tolka kartinformation i webbapplikationen. 35

41 Kapitel 3. Systembeskrivning 3.4. Detaljerad design Android-applikation Androidsystemet är uppbyggt av ett grafisk användargränssnitt och ett bakomliggande system som hämtar information från en server. Exempel på hur flödet är tänkt att gå vid presenterande av nyheter visas i figur 3.17, och i figur 3.18 visas hur det är tänkt vid visande av en karta. En mer detaljerad beskrivning av systemet finns under avsnittet Implementation. Figur 3.17: Design av hur nyheter visas i Android. Figur 3.18: Design av hur en karta visas i Android. 36

42 Kapitel 3. Systembeskrivning 3.4. Detaljerad design ios-applikation Applikationen för ios är designad utifrån designmönstret MVC, där varje flik i applikationen har sin egen MVC-struktur. Applikationens beteende vid hämtandet av nyheter visas i figur Applikationen hämtar nyheter från servern då användaren väljer att uppdatera nyheterna via uppdateringsknappen. I figur 3.20 visas applikationens beteende för att visa information. Informationsdelen i applikationen är indelad i kategorier för att snabbt ge användaren en överblick över vilken information som finns tillgänglig. Det förhindrar också att för mycket text visas på skärmen på en och samma gång. Applikationens beteende för hitta-funktionaliteten visas i figur Figur 3.19: Design av ios-applikationens hantering av nyheter. Figur 3.20: Design av ios-applikationens hantering av information. 37

43 Kapitel 3. Systembeskrivning 3.4. Detaljerad design Figur 3.21: Design av ios-applikationens hantering av kartinformation Administrationsverktyg Följande lista beskriver respektive del på en övergripande nivå i systemet. NewsComponent Gör anrop till Proxy för att kunna hämta data från API-servern. Den data som skickas tillbaka presenteras för användaren. Denna data är nyheter. Proxy Hanterar kommunikationen mellan NewsComponent och NetworkInterface. NetworkInterface Sköter själva sändningen till och mottagningen från servern Server Servern publicerar ett REST 2 -baserat gränssnitt till övriga komponenter genom HTTP. De mobila applikationerna och administrationsgränssnittet använder sig av HTTP-förfrågningar för att komma åt data på servern, och databasen via servern. REST innebär att varje resurs har en egen sökväg. Till exempel finns nyheter under /news/, och ensilda nyheter finns under /news/<id>, där <id> är en siffra som unikt identifierar nyheten. Servern fungerar som en brygga mellan databas på ena sidan och administrationsgränssnitt och appar på andra sidan. Därför måste servern kommunicera med en databas innehållande saker som nyheter och föreläsningar. Koden som utgör servern är skriven i en MVC-arkitektur, en naturlig uppdelning mellan delkomponenter. Kontrollerklasser tar emot HTTP-förfrågningar, använder modellklasser för att hämta information från databasen och använder sen vy-klasser för att transformera informationen till JSON. Kodbasen ska ha en hög grad av enhets- och integrationstester. Serverns HTTP-gränssnitt är specifierad i bilaga H

44 Kapitel 3. Systembeskrivning 3.4. Detaljerad design Databas För att förtydliga den valda designen av databasen följer nedan en övergripande design samt en beskrivning av attributen. Övergripande design I denna del av dokumentationen ges en övergripande beskrivning av de olika tabellerna som utgör databasen. Ett ER-diagram över databasen kan ses i bilaga F. News Syftet med denna tabell är att hålla reda på den nyhetsdata som utgör nyheter i systemet. Dess attribut är till exempel titel och brödtext samt vem som skrev nyheten och när. Tabellen stödjer även att ett datum sätts för att indikera om och i så fall hur länge en nyhet ska prioriteras. Lectures Tabellens syfte är att tillåta systemet att lagra id-nummer för föreläsningar samt den sal föreläsningen hålls i. Lecture_Rooms Tabellen utgör en lista över de lokaler på campus som kommer användas för föreläsningar och utställningar. Utöver namnet på lokalen lagras också dess koordinater, våning och byggnad. Den används främst som en tabell att referera till internt. Tupler i Lectures -tabellen refererar till en lokal specificerad i denna tabell. Admins Håller konto-data över de användarkonton som givits administrativa rättigheter att utföra skyddade operationer på databasen och dess data. Attributen består av användarnamn, krypterade lösenord samt användarens riktiga namn. Syftet är att tillhandahålla data för autentiseringsfunktionalitet i systemet. Sessions Lagrar autentiserade sessioner för administratörer. Syftet med detta är att tillåta en administratör att utföra flera administrativa åtgärder utan att tvingas autentisera med användarnamn och lösenord varje gång en åtgärd görs. Kort sagt lagras här data över vilka administratörer som redan loggat in på systemet. Exhibitions En tabell vars syfte är att lagra data som representerar diverse utställningar. Den data som lagras är mer specifikt dess område, ett ID-nummer samt vilket typ av utställning det är. Exhibition_Types Denna tabell utgör en lista av de olika utställningstyperna som utställningarna kategoriseras som. Den används främst för intern referens där varje utställning i Exhibitions-tabellen refererar till en specifik typ i denna tabell. Därmed behövs inte kopior av samma data lagras på flera platser i databasen. Buildings I denna tabell lagras namn och område för byggnader. Tabellen Lecture_Rooms refererar till data i denna tabell. Areas Tabellen innehåller polygoner och färger som tillsammans utgör färglagda områden. Syftet med tabellen är att kunna lagra dessa områden och koppla de till byggnader eller utställningar. Informationen kan därefter användas till att rita ut områden på kartor. General_Places Innehåller data om generella platser så som vilken typ av plats det är, vilken våning den ligger på och koordinater för platsen. 39

45 Kapitel 3. Systembeskrivning 3.4. Detaljerad design General_Types Utgör en samling av generella typer av platser. Dessa kan till exempel vara toaletter, informationsdisk eller garderober. Tabellen används främst för intern referens där varje generell plats i General_Places-tabellen refererar till en specifik typ i denna tabell. Beskrivning av attribut I detta avsnitt förklaras syftet med alla attribut uppdelade efter tabellerna i databasen. Tanken med avsnittet är att ge ytterligare klarhet angående de olika attributen som tabellerna innehåller och vad de är tänkta att användas för. News ID Innehåller ett unikt ID-nummer för en nyhet. Tillåter en användare av databasen att specifikt hantera och identifiera enskilda nyheter. Dessa ID-nummer genereras automatiskt av databasen då en nyhet skapas. Content Innehåller den brödtext som ska lagras för en nyhet. Det finns inga krav på hur detta ska se ut så det är upp till användaren vad den vill lagra som brödtext. Modified_Date Datumet ska inte sättas manuellt utan hålls automatiskt uppdaterad av databasen. Modified_By Lagrar användarnamnet på den administratör som senast förändrade nyheten. Då en nyhet skapas sätts Modified_By automatiskt till att vara densamma som den som skapade nyheten. Created_Date Lagrar det datum då nyheten lades in i databasen för första gången. Detta datum behöver inte sättas manuellt utan sätts automatiskt av databasen vid skapandet av nyheten. Created_By Innehåller i likhet med Modified_By ett användarnamn på den administratör som initialt skapade nyheten. Title Innehåller den text som utgör titeln på en nyhet. Prioritized_Until Innehåller eventuellt ett slutdatum då nyheten inte längre ska prioriteras. Attributet är tomt om nyheten inte ska vara prioriterad. Lectures Lecture_ID Ett unikt ID-nummer för en föreläsning. Tillåter en användare av databasen att specifikt hantera och identifiera enskilda föreläsningar. Lecture_Room Refererar till ett salsrum som finns listat i Lecture_Rooms -tabellen. Salsrummet är den plats där föreläsningen sker. Lecture_Rooms Room Innehåller ett namn på en sal eller lokal där föreläsningar hålls. Building Refererar till attributet Name i Buildings-tabellen. Attributets värde är namnet på den byggnad salen ligger i. Floor Innehåller data om vilken våning salen ligger på. Longitude Longitud-koordinaten för salen. Latitude Latitud-koordinaten för salen. 40

46 Kapitel 3. Systembeskrivning 3.4. Detaljerad design Admins Username Ett användarnamn som används vid autentisering så att en administratör ska kunna få tillgång till restriktiv funktionalitet, som exempelvis att modifiera nyheter. Password Innehåller ett krypterat lösenord. Används tillsammans med användarnamnet för att autentisera en administratör. FName Förnamn på administratören. LName Efternamn på administratören. Exhibitions Exhibition_ID Ett unikt ID-nummer för en utställning. Tillåter en användare av databasen att specifikt hantera och identifiera enskilda utställningar. Lecturer_FName Förnamn på en föreläsare. Type Ett attribut som refererar till en specifik utställningstyp i Exhibition_types -tabellen. Area Refererar till ett namn i Areas-tabellen som utgör byggnadens områdespolygon. Exhibition_types Type Ett attribut som representerar de olika typerna som en utställning kan anta. Utställningstyperna kan till exempel vara idéutställning, företagsutställning, förlagsutställning eller andra typer av utställningar. Sessions Session_ID Attributets värde är en sträng som utgör en sessions-nyckel. Username Användarnamnet på den administratör som sessions-nyckeln tillhör. Buildings Name Namnet på byggnaden tupeln representerar. Till exempel Samhällsvetarhuset. Area Refererar till ett namn i tabellen Areas som utgör byggnadens områdespolygon. Color En RGBA-färg i det hexadecimala talsystemet som är associerat med byggnaden. Areas Name Innehåller namnet på området som tupeln hör till. Polygon Utgör en polygon, dvs en mängd koordinater som bildar ett slutet område. General_Places Type Typ av generell plats, refererar till en typ specificerad i tabellen General_Types. Longitude Longitud-koordinaten för den generella platsen. Latitude Latitud-koordinaten för den generella platsen. Floor Vilken våning den generella platsen ligger på. Building Refererar till attributet Name i Buildings-tabellen. Attributets värde är namnet på den byggnad platsen ligger i. 41

47 Kapitel 3. Systembeskrivning 3.5. Implementation General_Types Type Innehåller en generell typ av plats. Attributets värde kan till exempel vara toalett, garderob, informationsdisk eller liknande. 3.5 Implementation Under följande avsnitt dokumenteras hur de olika komponenterna har implementerats Webbapplikation Implementationen av designen har skett genom att använda HTML5, CSS3, JavaScript och PHP. Ett stort fokus vid implementationen har lagts vid att skapa en dynamisk sida där mycket av innehållet uppdateras utan att användaren behöver agera. Därför sköts större delen av det bakomliggande systemet med javascript som medför att utseendet på sidan kan ändras utan att sidan laddas om. En brist hos JavaScript är att HTTP anrop enbart kan ske till en server belägen i samma domän som scriptet. För att lösa detta används en proxy-server skriven i PHP för att kuna göra anrop till en server som är belägen var som helst. Webbsidan har utvecklats efter HTML5 standard. Detta eftersom att alla dagens webbläsare har bra stöd för HTML5 och att webbsidor blir enklare att anpassa för olika typer av enheter och skärmstorlekar. Nedan följer en översiktlig genomgång av systemets filer och deras funktion en mer ingående beskrivning finns i bilaga K. Webbsidan består av HTML-filer för de olika funktionerna samt ett antal javascript och php-filer. Webbsidans grafiska attribut bestämms i en CSS-fil. Deras inbördes relationer illustreas i figur 3.22 Figur 3.22: Illustration över webb-applikationens filer och deras inbördes relationer. pc_webb.css Innehåller de grafiska attributen för webbsidan. serverconncetion.js Hanterar anrop till och från proxyservern, datan från proxyserver skickas vidare till relevanta funktioner. proxy.php Hanterar kommunikation mellan webbsida och server. news.js Hanterar tolkning och utskrift av nyheter mellan servern och applikationen. map.js Hanterar tolkning och utskrift av kartan samt objekt från servern. button.js Hanterar funktionaliteten i knappar på kartsidan. moment.min.js Innehåller hjälpfunktioner för news.js. 42

48 Kapitel 3. Systembeskrivning 3.5. Implementation Android-applikation Android-applikationen är implementerad i Java och xml och på ett sådant sätt att den ska fungera på de flesta olika versionerna. För att uppnå detta använder den sig till exempel av ett stödbibliotek som heter ActionBarSherlock 3 för att få den övre menyn att fungera på äldre såväl som nyare versioner av Android. Systemet är uppbyggt av GUI-delen som ses som UML-diagram i figur 3.23 och ett bakomliggande system som beskrivs längre ned. MainActivity är klassen som används för att till exempel starta upp programmet. Vid start skapas menyn som klasserna MapFragment, InformationFragment och NewsFragment knyts till. Dessa representerar de olika vyerna som ska visa karta, information och nyheter. Klassen AppTabListener används för att byta vy när en användare klickar på någon av flikarna i menyn. NewsFragment har hand om hämtningen och visandet av nyheterna, där MyExpListAdapter hjälper till att bestämma utseendet på nyhetslistan så att exempelvis en del av den första meningen på nyheten visas innan den klickas på. Klassen InformationFragment används för infofliken där den tar hjälp av InfoTextActivity för att visa informationen under varje informationskategori. MapFragment används för att visa en karta där olika platser kan markeras. När användaren väljer att klicka på en knapp för att visa till exempel toaletter på kartan, reagerar klassen MapButtonListener med att säga till MapDecorator att rita ut de positionerna. Klassen ExhibitionsMenuListener används för en extra meny som visas när en användare ska välja vilken typ av utställare som ska visas på kartan. Slutligen används klassen WelcomeActivity för att visa välkomstskärmen som syns när appen startas

49 Kapitel 3. Systembeskrivning 3.5. Implementation Figur 3.23: UML-diagram över Android-applikationens grafiska gränssnitt. Det bakomliggande systemet som visas i figur 3.24 och figur 3.25 har hand om att hämta information om nyheter och kartor på rätt sätt. GlobalState agerar mellanhand mellan GUI:t och det bakomliggande systemet. Den pratar med klasserna NewsCollection som ansvarar för hämtningen av nyheter, och exempelvis MapPositions som har hand om allt som kan ritas ut på kartan. ServerCommunicator knyter kontakt med servern med hjälp av HTTPGetExecuter och ger nyheter till NewsCollection som parsar de till rätt format med hjälp av NewsParser, och kartpositioner som parsas med LocationParser. NewsParser, som ärver från klassen JSONParser, omvandlar de givna nyheterna till items i form av News, där till exempel information om publiceringstid och prioritet lagras. NewsCollection ger därefter en lista med News till GUI t som visar dessa för användaren. AddCallable är en intern klass i NewsCollection som möjliggör trådar. LocationParser omvandlar informationen från servern till antingen BiennalPosition, som används för till exempel kaffe- eller toalettpositionering, Biennalpolygon, som representerar större områden som exempelvis utställarområden eller hela byggnader, eller LectureHall som används för att salar ska kunna lagras med namn och vilket hus de tillhör. Building ärver från klassen BiennalPolygon för att kunna handhålla ett namn på byggnaden. Alla byggnader, positioner och salar lagras slutligen i klassen MapPositions där informationen hämtas vid utritning på kartan. PlacementType är en klass som hjälper MapPositions med handhållningen av de olika typer av platserna. 44

50 Kapitel 3. Systembeskrivning 3.5. Implementation Figur 3.24: UML-diagram över Androids nyhetssystem. 45

51 Kapitel 3. Systembeskrivning 3.5. Implementation Figur 3.25: UML-diagram över Androids kartsystem. 46

52 Kapitel 3. Systembeskrivning 3.5. Implementation ios-applikation Applikationen för ios är utvecklad i Objective-C för ios 5.1 och senare. XCode användes som utvecklingsmiljö. Ett UML-klassdiagram för nyhetsrelaterade klasser visas i figur Klassdiagram för klasser relaterade till infofliken finns i figur 3.27 och för hittafunktionaliteten i figur För övriga klasser, se figur 3.29 och figur En fullständig referensdokumentation för källkoden finns att tillgå på Kommunikationen med server sker med REST och JSON via biblioteket RestKit 5. För att underlätta underhållet av systemet beskrivs i bilaga I i detalj vilka klasser som utgör en funktionalitet och vad de har för syfte. Varje klass har prefixet MB, en förkortning av Matematikbiennalen, följt av ett namn som beskriver klassens syfte och innehåll. News MBNews + NSString *title + NSString *text + NSDate *datecreated + NSDate *datemodified + BOOL sticky + NSDate *stickyexpiration MBNewsTableViewController - MBNewsListModel *model - NSIndexPath *selectedrowindex - (id)initwithstyle:(uitableviewstyle)style - (void)viewwillappear:(bool)animated - (void)viewdidload - (void)askmodelfordata - (void)updateview - (int)getcellindexfromindexpath:(nsindexpath*)indexpath - (MBNews*)getNewsObjectFromIndexPath: (NSIndexPath*)indexPath - (void)didreceivememorywarning - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableview - (NSInteger)tableView:(UITableView *)tableview numberofrowsinsection:(nsinteger)section - (UITableViewCell *)tableview:(uitableview *)tableview cellforrowatindexpath:(nsindexpath *)indexpath - (CGFloat)tableView:(UITableView *)tableview heightforrowatindexpath:(nsindexpath *)indexpath - (void)viewwilldisappear:(bool)animated - (void)tableview:(uitableview *)tableview didselectrowatindexpath:(nsindexpath *)indexpath + (BOOL)compareIfEqual:(MBNews *)newsobjecttocompare MBNewsListModel NSMutableArray *stickynews NSMutableArray *news id <NewsModelToView> viewdelegate - (id)init - (void)observevalueforkeypath:(nsstring *)keypath ofobject:(id)object change:(nsdictionary *)change context:(void *)context - (void)fetchnewdata - (void)insertnews:(nsarray*)data - (NSMutableArray*)sortArrayOnDateCreated: (NSArray*)arrayToSort - (void)updatesticky - (void)addregularnews:(mbnews*)newsobject - (void)addstickynews:(mbnews*)newsobject - (void)dealloc NewsTableViewCell MBNewsTableViewCellLabel + UILabel *title + UILabel *date; + MBNewsTableViewCellLabel *text + UIView *content MBNewsTableViewCell - (void)awakefromnib - (void)layoutsubviews - (void)setselected:(bool)selected animated:(bool)animated - (void)prepareforreuse Figur 3.26: UML-klassdiagram för nyhetsrelaterade klasser i ios-applikationen

53 Kapitel 3. Systembeskrivning 3.5. Implementation Information MBInformationView UITextView *informationfield UIWebView *infowebview; UIScrollView *infoscrollview; - (void)setbannertext:(nsstring *)text; - (void)setinfotexttoview:(nsstring *)text; MBInformationViewController UITextView *informationfield; UITableView *infotableview; MBInformationView *infoviewcontroller; Figur 3.27: UML-klassdiagram för inforelaterade klasser i ios-applikationen. Map MBMapShape NSArray *shapelocations NSString *housename NSString *shapecolor UIColor *convertedshapecolor - initshapewithcoordinates:(nsarray *)coordinates andname:(nsstring *)name; - (void)sethouseshapecolorfromrgb A:(NSString *)color; MBMapPin CLLocation *pinlocation NSString *title NSString *descriptiontext MBMapViewModel NSArray *houseshapes id <ModelToView> viewdelegate NSArray *cafees NSArray *infodesk NSArray *toilets NSArray *buidlings NSArray *companyexhibitions NSArray *conceptexhibitions NSArray *publisherexhibitions NSDictionary *lecturehalls NSDictionary *lectures - (void)fetchnewdata; - (NSArray *)getlocationfromtag: (NSInteger)tag; - initpinat:(cllocation *)location WithTitle:(NSString *)title WithText: (NSString *)descriptiontext; Figur 3.28: UML-klassdiagram för hittarelaterade klasser i ios-applikationen. 48

54 Kapitel 3. Systembeskrivning 3.5. Implementation MBBannerCreator Help Classes + (void)setbannersizewithtext: (NSString *)text navigationitem: (UINavigationItem *)navigationitem; MBConnector + sharedinstance; - (void)fetchnews; - (void)fetchmapdata; - (NSArray *)receivenews; - (NSArray *)receivemapdata; - (NSArray *)receivemapshape; - (NSArray *)receivemapconceptexhibitions; - (NSArray *)receivemapcompanyexhibitions; - (NSArray *)receivemappublisherexhibitions; - (void)fetchmapshapes; - (void)fetchexhibitions; BButton UIColor *_color; CGGradientRef _gradient; - (void)settype:(bbuttontype)type; BButton FontAwesome Figur 3.29: UML-klassdiagram för hjälpklasser i ios-applikationen. ModelToView - (void)updatenewsview; - (void)failedtofetchnewsdata; - (void)startedtofetchnewsdata; - (void)updatemapview; - (void)putshapeonmap; MBAppDelegate UIWindow *window; MBStartPageViewController - (void)gotonews; Figur 3.30: UML-klassdiagram för övriga klasser i ios-applikationen. 49

55 Kapitel 3. Systembeskrivning 3.5. Implementation Administrationsverktyg Systemet är implementerat i HTML5, CSS3, objektorienterad PHP och JavaScript med jquery Utveckling sker med TDD för PHP-koden. Filstrukturen är enkel där HTML och klassfiler för PHP ligger i rotmappen. CSS, JavaScript och PHP-filer som inte innehåller klasser ligger i en mapp med tillhörande namn, css för CSS, js för JavaScript och util för PHP. HTML Bygger upp hemsidans struktur och används för viss validering av användarinput. CSS Används för att definiera utseendet på de element som finns i HTML-filerna. JavaScript och jquery Används för att göra asynkrona anrop till de PHP-filer som står för kommunikationen med servern. Förutom detta används JavaScript för dynamiska effekter, hantering av knapptryckningar och validering av användarinput. PHP Sköter kommunikationen, både att sända och ta emot information, med API-servern. De komponenter som beskrevs i underavsnitt är implementerade enligt bilaga J Server Servern för biennalen är utvecklad i Java 6 och använder sig av ramverket Jersey, som implementerar JAX- RS standarden för REST-baserade hemsidor. Jersey gör det enkelt att vidarebefodra HTTP-förfrågningar till adekvata klasser och metoder med hjälp av Java Annotations. Det gör i sin tur att det är enkelt att lägga upp koden i en MVC-struktur. För att kommunicera med databasen används kodbiblioteket ActiveJDBC, vilket är en JDBC-baserad ORM. ORM, eller Object Relational Mapper, är en abstraktion som gör att SQL-frågor genereras automatiskt utifrån databasens struktur och den anropande koden. ActiveJDBC använder sig av designmönstret ActiveRecord, vilket är ett vida använt designmönster som har många fördelar i kodkvalitet såväl som produktivitet. Koden är uppdelad enligt MVC-designmönstret. Förfrågningar hänvisas av ramverket till den korrekta kontrollern, som med hjälp av modeller och vyer skapar en matchande respons. Modellerna sköter kommunikation med databas och vy-klasserna är gjorda för att automatiskt kunna omvandlas till JSON. Modellerna använder sig av ActiveJDBC för att automatiskt motsvara databasens tabeller. I ett statiskt sammanhang är det möjligt att göra förfrågningar motsvarande SQL Select, och få som svar instansieringar av modellklassen för varje rad i resultatet. En instansiering av en modell kan skapas, modifieras, sparas och tas bort i form av metod-anrop, utan att skriva SQL-frågor. Servern är utvecklad i enlighet med TDD (Test Driven Development). Det innebär att varje levererad funktion är utvecklad genom att skriva tester först, och sedan implementera funktionaliteten

56 Kapitel 3. Systembeskrivning 3.5. Implementation Databas I detta avsnitt beskrivs implementationen av systemets databas. Realisation Databasen implementerades med hjälp av databashanteraren PostgreSQL 7 och servern tillhandahölls av CSsektionen vid Umeå Universitet. En slags TDD-metodik eftersträvades i implementationen av databasen, dock var detta inte fullt möjligt. Allt eftersom delar av databasen blev klara testades dessa ordentligt så att de fungerade, men inga tester skrevs i förväg då det blev för svårt med en sådan approach och det upplevdes inte lämpligt för databasutveckling. Arbetsuppgifterna fördelades mellan alla gruppmedlemmar och synkades sedan mot testdatabasen innan tester gjordes mot den riktiga. Detta gjordes för att spara tid och jobb. Om någonting skulle gå fel i den riktiga databasen behöver den rensas från allting, medan om någonting skulle gå fel i testdatabasen är det bara att ta bort den helt och göra om den från grunden väldigt enkelt. Val och motivering till begränsningar Under denna rubrik kommer attribut i databasen som har relevanta begränsningar att gås igenom. Varje begränsning kommer att motiveras för att ge läsaren bättre insikt i de olika besluten som tagits vid databasens konstruktion samt underlätta för eventuell vidareutveckling. Detta avsnitt har alltså inte i avsikt att förklara syftet för alla attribut i varje tabell. Ett schema över databasen finns tillgängligt i bilaga G. Formatet för presentationen av attributen i detta avsnitt är på formen: Attributnamn - Datatyp News ID - INTEGER Detta attribut utgör den unika numreringen för varje tupel i News-tabellen. Numreringen sköts automatiskt av databasen genom en sekvensiellt ökande sifferserie. Detta värde ska således aldrig sättas manuellt. Serien tillåter värden från 1 till 2^63 vilket ska vara mer än tillräckligt för att täcka framtida behov. Content - VARCHAR(2500) Attributet Content innehåller den brödtext nyheten består av. Under ett möte med beställare framkom det att brödtexten för en nyhet med största sannolikhet kommer att bestå av drygt två till tre meningar. Motiveringen är därför att den gräns som är satt kommer kunna täcka behovet för två till tre meningar, samt ge en buffert om detta skulle förändras vid ett senare skede. Created_Date - TIMESTAMP Detta attribut har en SQL funktion satt som standardvärde, vilket betyder att värdet automatiskt kommer att bli det datum som gäller vid skapandet av tupeln. Det ska alltså inte sättas manuellt. Motiveringen för detta beslut är att få ett enhetligt format samt avlasta antalet update-förfrågningar som måste göras mot databasen. Modified_Date - TIMESTAMP Detta värde genereras automatiskt genom en SQL-Trigger när tupeln förändras, mer specifikt när en update-förfrågan körs på tupeln. Den bakomliggande motiveringen är för att få ett enhetligt format samt avlasta antalet update-förfrågningar som måste göras. Modified_By - VARCHAR(50) - FK Refererar till attributet Username i tabellen Admins. Förövrigt är en SQL Trigger kopplad till detta attribut som kopierar värdet i attributet Created_By vid skapandet av tupeln. Motiveringen är främst för att spara plats och inte lagra samma data på flera ställen samt att bibehålla integriteten i databasen. Created_By - VARCHAR(50) - FK Refererar till attributet Username i tabellen Admins

57 Kapitel 3. Systembeskrivning 3.5. Implementation Lectures Lecture_Room - VARCHAR(100) - FK Refererar till attributet Room i tabellen Lecture_rooms. Motiveringen till den satta storleken är baserad på Matematikbiennalens programbok från De flesta salsnamnen består av fyra tecken, men i enstaka fall kan lokalerna ha längre namn än så. Lecture_Rooms Building - VARCHAR(255) - FK Refererar till attributet Name i tabellen Buildings. Floor - INTEGER Attributet kontrolleras så att det värde som sätts är inom intervallet [0, 10]. Exhibitions Type - VARCHAR(40) - FK Refererar till attributet Type i tabellen Exhibition_Types. Den gräns som är satt är grundad utifrån Matematikbiennalens programbok från 2012, det vill säga längden av namnen på de tidigare utställningstyperna. Area - VARCHAR(50) - FK Refererar till attributet Polygon i tabellen Areas. General_Places Type - VARCHAR(40) - FK Refererar till attributet Type i tabellen General_Types. Den gräns som är satt är grundad utifrån Matematikbiennalens programbok från 2012, närmare sagt längden av namnen på de tidigare utställningstyperna. Building - VARCHAR(255) - FK Refererar till attributet Name i tabellen Buildings. Floor - INTEGER Attributet kontrolleras så att det värde som sätts är inom intervallet [0, 10]. Sessions Username - VARCHAR(50) - FK Refererar till attributet Username i tabellen Admins. Motiveringen är främst för att kunna koppla ett Session_ID till dess administratör. Buildings Area - VARCHAR(50) - FK Refererar till attributet Polygon i tabellen Areas. Color - Char(8) Attributets värde valideras med ett Regular-Expression mönster för att säkerställa att det är en giltigt RGBA färg i det hexadecimala talsystemet. 52

58 Kapitel 4. Tester Kapitel 4 Tester Detta kapitel dokumenterar hur systemet i sin helhet har testats, hur acceptanstesterna gått till, samt hur de olika komponenterna har testats. 4.1 System Systemet som helhet har testats genom att gå igenom användarfallen med tillhörande scenarion för att se om de fungerar enligt specifikationen. 4.2 Acceptans För att säkerställa att tjänsten som utvecklats uppskattas av potentiella användare har ett antal acceptanstester utförts. För att testa webbsidan och de två applikationerna kontaktades personer som deltagit i Matematikbiennalen Dessa fick prova att använda tjänsten och utföra några enkla uppgifter. Några av uppgifterna var att läsa upp en viktig och en vanlig nyhet, att hitta till en toalett eller utställare och att läsa någon allmän information som fanns att hitta under Infofliken. Försökspersonerna observerades och ombads att uttrycka hur tankegångarna gick vid lösandet av uppgifterna, och därefter ställdes frågor om hur de upplevt tjänsten, om något varit otydligt eller borde varit annorlunda. Slutligen ställdes frågan om de skulle använda sig av tjänsten under kommande Matematikbiennalen. Resultatet av dessa tester visar att tjänsten var enkel att använda, flera av försökspersonerna uttryckte flertalet gånger att det kändes pedagogiskt och intuitivt gjort. De uttyckte att det var lätt att hitta i tjänsten, att det var bra att viktiga nyheter var markerade med rött och att det var speciellt bra att få möjlighet att hitta till salar då de kände att det var svårt tidigare år. Observationerna visade också att både applikationerna och hemsidan var implementerade på ett sådant sätt att användarna kände igen sig i gränssnittet och lätt kunde navigera och använda funktionaliteten. Alla personer som utförde testet sa att de skulle använda sig av tjänsten. För att testa administrationsverktyget har acceptanstester utförts mot administratörerna för tjänsten. De implementerade användarfallen, som berör administrationsverktyget enligt tabell 3.1, testades. Användarna uppmanades att uppnå ett visst mål, exempelvis att lägga till en ny nyhet, och det observerades hur enkelt de kunde utföra uppgiften. Användarna stötte inte på några problem i utförandet. 53

59 Kapitel 4. Tester 4.3. Komponenter 4.3 Komponenter Under följande avsnitt beskrivs testningen av systemets olika komponenter och dess funktionalitet Webbapplikation För att verifiera att webbapplikationen uppfyller de krav som ställs på dess funktionalitet har det genomförts tester under kontrollerade former. Det har även veriferats att webbapplikationen fungerar i de vanligast förekommande webbläsarna 1. Testerna har genomförts genom att använda en lokal dummy -server som levererar fördefinierad information i enlighet med produktionsservern. All testning har utgått från de användarfall som ska implementeras, de testfall som används finns specifierade i bilaga N. Utöver detta har systemtester genomförts, se avsnitt Android-applikation För att säkerställa att applikationen har önskvärt beteende har kontinuerliga tester av enheterna gjorts med hjälp av JUnit. Testerna är gjorda på ett sådant sätt att de enkelt ska visa om något går fel. Manuella tester har också gjorts för att kontrollera funktionaliteten. Dessa tester beskrivs i bilaga M ios-applikation Under utvecklingen av ios-applikationen har produkten simulerats på en simulator för ios version 5.1. Implementationen av ios-applikationen har också testats med hjälp av enhetstester samt en uppsättning manuella tester. De manuella testerna är till för att säkerställa att funktionalitet interagerar med det grafiska gränssnittet. I bilaga L återfinns en beskrivning av enhetstesterna och i bilaga M återfinns de manuella testerna Administrationsverktyg Den testning som har genomförts är syntax- och semantiktestning. För validering av syntax för HTML-kod användes W3C Markup Validation Service 2. Den kördes med endast en varning för att viss funktionalitet inte stöds i alla webbläsare. För validering av semantik av HTML-kod användes HTML 5 Outliner 3. Den kördes utan anmärkning. För validering av HTML-kodkonvention användes HTML Lint 4. Den kördes utan anmärkning. För validering av syntax för CSS-kod användes W3C CSS Validation Service 5. Den kördes utan anmärkning Server Servern är skriven enligt TDD, vilket innebär att kodtester skrivs innan koden som testas skrivs. Varje komponent på servern, till exempel nyheter och inloggningar, har en egen testsvit som genomgående testar att komponentens funktionalitet matchar både specifikation och förväntningar. Utöver det enhetstestas varje klass för sig. När en bugg uppkommer skrivs ett testfall som fångar upp buggen och sedan skrivs kod om för att rätta till buggen och därigenom klara testfallet. Testkörningarna är helt automatiserade och körs via ett enda kommando. Testerna körs då mot en testdatabas som är inledningsvis tom och som byggs upp inför varje test. 1 firefox, Google Chrome, Chromium och Safari

60 Kapitel 4. Tester 4.3. Komponenter Databas Den faktiska implementationen testades först på en lokal test-databas och sedan på den riktiga databasen. Testerna i sig består av en uppsättning med SQL queries 6 som testar uppbyggnaden av databasen, funktionaliteten, constraints och foreign key dependencies. All testning har gjorts ur både databasens och serverns perspektiv. Det har alltså testats att logga in på databasen med serverns inloggning och köra alla tester för att se att det inte uppstått några problem för servern efter implementation av en ny funktion i databasen. På så vis testades också de restriktioner som sattes på servern och det gör det möjligt att se till att databasen är säker från felaktig manipulation från servern. Testscript med SQL queries för att testa databasen finns att hämta på

61 Kapitel 5. Litteraturförteckning Kapitel 5 Litteraturförteckning [1] Statcounter.com. Mobil webbläsarstatistik för april 2012 till april #browser-se-monthly bar. (hämtad ). [2] Statcounter.com. Mobil webbläsarstatistik för april os-se-monthly bar. (hämtad ). 56

62 Bilaga A. Intressentanalys Bilaga A Intressentanalys Nedan följer en beskrivning av de problem som intressenterna upplevt tidigare år och de olika mål som tjänsten ska uppfylla enligt intressenterna. A.1 Identifierade problem I följande sektioner beskrivs de problem de identifierade intressenterna upplevde med systemet som användes Problemen har identifierats via direktiven för detta projekt, en föreläsning från beställarna samt den besökar- respektive funktionärsutvärdering projektgruppen för biennalen 2012 gjort. Problemen nedan är grupperade efter vilket område i systemet de tillhör. De intressenter som ej nämns har antingen inte interagerat med det befintliga systemet eller inte haft några problem med det. A.1.1 Nyheter 1. Beställarna ansåg att det var ett problem att deltagarna hade svårt att få information kring förändringar under biennalen. 2. Besökarna ansåg att det var ett problem att det var svårt att veta hur de kunde få reda på förändringar. 3. Funktionärerna ansåg att det det var ett problem att inte fanns någon löpande information om förändringar, exempelvis bussar. A1

63 Bilaga A. Intressentanalys A.1. Identifierade problem A.1.2 Navigation 1. Beställarna ansåg att det var ett problem att deltagarna hade svårt att hitta. 2. Besökarna ansåg att det var ett problem att det (a) var svårt att hitta till parkeringsplatser (även handikapp-platser) och från dessa till biennalen, (b) inte fanns någon karta över föreläsningssalarna, (c) var svårt att veta var och när kaffe serverades samt att det (d) fanns dåligt med information om var bussarna gick ifrån. 3. Funktionärerna ansåg att det var ett problem att det (a) inte fanns någon karta över föreläsningssalarna, (b) var svårt att veta var kaffe fanns att tillgå samt att det (c) inte fanns någon generell information rörande salssystemet. A.1.3 Program 1. Beställarna ansåg att det var ett problem att deltagarna hade svårt att hitta i programboken. 2. Besökarna ansåg att det var ett problem att (a) tiden för föreläsningar/workshops inte fanns med i abstracten för föreläsningen, (b) det inte fanns någon tydlig uppdelning mellan de olika passen i abstracten för föreläsningarna/workshopparna, (c) det inte gick att söka efter föreläsningar på hemsidan, (d) det var svårt att hitta i programboken samt att (e) programmet var svårt att överblicka. 3. Funktionärerna ansåg att det var ett problem att (a) tiden för föreläsningar/workshops inte fanns med i abstracten för föreläsningen, (b) det var svårt att hitta i programboken, (c) det var svårt att avgöra vilken information som berörde de, (d) föreläsarna inte hade med sitt eget pass på sitt schema samt att (e) allmänna aktiviteter (exempelvis invigning och avslutningsceremoni) inte fanns med på det personliga schemat. A.1.4 Tillgänglighet 1. Beställarna ansåg att det var ett problem att deltagarna fick information först när de anlände till biennalen. 2. Besökarna ansåg att det var ett problem att det fanns för lite information innan biennalen började. 3. Funktionärerna ansåg att det var ett problem att det fanns för lite information innan biennalen började. A2

64 Bilaga A. Intressentanalys A.2. Identifierade mål A.2 Identifierade mål I följande sektioner beskrivs de mål som tagits fram utifrån de identifierade problemen. Det har även identifierats några ytterligare mål. Några av dessa härleds till projektdirektivet och hur övriga har uppstått presenteras i samband med målet. A.2.1 Beställare M.B.1 En tjänst ska produceras. M.B.2 Administratörer ska kunna publicera nyheter och information i tjänsten. M.B.3 Tjänsten bör testas mot målgruppen. M.B.4 Layouten på tjänstens användargränsytor ska överensstämma med det bildspråk som Matematikbiennalen vid Umeå universitet har valt att använda. M.B.5 Förarbete i form av t.ex. kartpositioner ska ej hanteras av administratörerna (framkom vid diskussion med Catarina Rudälv). Nyheter M.B.6 Det ska vara möjligt att informera om till exempel inställda/flyttade föreläsningar eller nyinsatta programpunkter, aktuella busstider för abonnerade bussar samt dagens lunchmeny. Navigation M.B.7 Det ska gå att hitta en specifik sal, en specifik utställning eller kaffe- och matserveringar. M.B.8 Vid angivelse av en sal eller programpunkt ska det med hjälp av tjänsten vara möjligt att hitta dit. Program M.B.9 Det ska vara möjligt att få information om hela konferensprogrammet (alternativt enbart de egna programpunkterna), det vill säga föreläsningar, workshoppar och utställningar. Tillgänglighet M.B.10 Majoriteten av användarna ska tycka att tjänsten är lätt att använda. M.B.11 Tjänsten ska fungera för smartphone, läsplatta och dator (Android, ios, Windows). M.B.12 Tjänsten ska kunna användas inför och under konferensdagarna. A.2.2 Administratörer M.Ad.1 Det ska gå att uppdatera nyhetsflödet och matsedeln. M.Ad.2 Administratörerna ska tycka att det är enkelt att använda tjänsten. M.Ad.3 Administrationen ska gå att sköta från en dator. M.Ad.4 Om det går är det ett plus ifall det vore möjligt att sköta administrationen även från mobiltelefon (vid diskussion med Olof Johansson framkom detta). A3

65 Bilaga A. Intressentanalys A.2. Identifierade mål A.2.3 Användare Under nedanstående sektioner beskrivs de mål som identifierats som är kopplade till de två delgrupperna av användare. Besökare Nedanstående lista beskriver de mål som identifierats som är kopplade till besökarna. Nyheter M.An.B.1 Det ska gå att få reda på nyheter. Navigation M.An.B.2 Det ska gå att hitta exempelvis parkeringsplatser, föreläsningssalar, kaffestationer, busshållplatser samt entréer (framkom vid intervjuer, se bilaga C). Program M.An.B.3 En majoritet av användarna ska tycka att det är enkelt att överblicka programmet och att hitta i programboken. M.An.B.4 Det ska vara möjligt att veta när en föreläsning är enbart genom att titta i programboken. M.An.B.5 Det ska gå att se sitt personliga program (framkom i enkätundersökningen, se bilaga B). Tillgänglighet M.An.B.6 Det ska vara möjligt att få information även innan mässan börjar. M.An.B.7 Det ska gå att få information på både svenska och engelska. Funktionärer Nedanstående lista beskriver de mål som identifierats som är kopplade till funktionärerna. Nyheter M.An.F.1 Det ska gå att få reda på nyheter. Navigation M.An.F.2 Det ska gå att hitta exempelvis föreläsningssalar samt kaffestationer. Program M.An.F.3 Det ska vara möjligt att veta när en föreläsning är enbart genom att titta i programboken. M.An.F.4 En majoritet av användarna ska tycka att det är enkelt att överblicka och hitta i programboken. M.An.F.5 Det ska finnas allmänna aktiviteter (ex. invigning och avslutningsceremoni) på användarens schema. M.An.F.6 Föreläsarna ska ha med sina föreläsningar på det personliga schemat. A4

66 Bilaga A. Intressentanalys A.2. Identifierade mål Tillgänglighet M.An.F.7 Det ska gå att få information innan mässan börjar. A.2.4 Jurister M.J.1 Tjänsten och framtagandet av tjänsten får ej strida mot lagen. A.2.5 Utvecklare M.U.1 Tjänsten ska gå att utveckla inom avsatt tid. A.2.6 Vidareutvecklare M.V.1 Vidareutvecklare ska uppleva att tjänsten är lätt att anpassa för ett annat år och en annan plats. A.2.7 Systemadministratör M.S.1 Det ska vara möjligt att ladda upp kartor, programinformation och schema. A5

67 Bilaga B. Enkät Bilaga B Enkät Nedan följer en sammanställning av den enkät som delades ut i syfte att få mer kunskap om människors önskemål gällande hur de vill få information tilldelat sig. B.1 Frågor Enkäten inleddes med frågeställningar om ålder, kön och innehavande av en smart enhet. Efter dessa inledande frågor består enkäten av frågor som syftar till att visa på den svarandes vanor vid informationshantering i en mässmiljö Om personen har en smartphone är det intressant att undersöka om de använder e-post och om de upptäcker nya meddelanden under dagen. Ja Nej Brukar du upptäcka att du fått ny epost på din smartphone? För att kunna avgöra om en lösning som innefattar användande av webbläsare bör implementeras, ansågs det relevant att veta om de som har en smartphone har den kunskap som krävs för att använda webbläsaren i telefonen. Ja Nej Använder du webbläsaren i din smartphone? Här undersöks om användaren tycker det är intressant att få uppdateringar direkt till sin telefon, eller om det är en eventuell funktion som kan bortses ifrån. Ja Nej Skulle du vilja ha notifieringar om information som är viktig för ditt personliga schema till din smartphone? B1

68 Bilaga B. Enkät B.1. Frågor Följande fråga ger svar på om användaren är intresserad av att få all information direkt till sin telefon, eller om de föredrar att själv söka upp informationen från en webbsida. Hur vill du få information angående mässan? Notifiering till mobiltelefon/surfplatta Läsa informationen på hemsida Eget alternativ Följande fråga används för att undersöka om målgruppen är intresserad av att kunna filtrera sin nyhetstillgång. Ja Nej Vill du kunna välja vilka nyheter från mässan som du får veta? Här undersöks om det finns ett intresse av att ha information om det personliga programmet tillgänglig i tjänsten. Ja Nej Är det viktigt med ett personligt program? Med den sista frågan är målet att undersöka hur målgruppen skulle vilja få hjälp att navigera på ett mässområde. Om du m.h.a. tjänsten vill navigera på mässområdet, vilket av följande alternativ skulle du föredra? En karta med hus utmärkta med färger och information om vilket hus, vilken färg detta hus har på kartan samt vilken våning du ska till En översiktskarta över området där ett klick på ett hus visar en karta över våningarna i huset Eget alternativ B2

69 Bilaga B. Enkät B.2. Svar B.2 Svar De svarande i enkäten har inte helt korrelerat med målgruppen från tidigare utvärderingar vilket illustreras av figur B.1. Detta har hanterats genom att sortera svaren efter ålder. Efter denna åldersindelning valdes att prioritera svaren från den gruppen som var mest representerad på tidigare konferens högre än de kringliggande grupperna. Den grupp som främst medverkat på biennalen tidigare år har varit i åldrarna år och därför är det den gruppens svar på enkäten som prioriterats. Figur B.1: Åldersfördelning i enkäten och biennalens utvärdering. Då innehavet av smart enhet undersöks i enkäten, kunde det konstateras att majoriteten av individer i den efterfrågade åldersgruppen äger någon form av smart enhet. Av de som svarat i den grupp som bäst överensstämmer med de tidigare besökarna till biennalen, är deras svar i stort entydiga då det är stor majoritet på ett av de olika alternativen på varje fråga, se figur B.2. Figur B.2: Enkätsvar åldersgrupp I frågan angående navigationen på konferensområdet saknas dock denna tydliga uppdelning mellan svaren. De övriga grupper som svarat på enkäten har på liknande sätt ordnats efter ålder i grupperna och 60+ där dessa gruppers relativt låga medverkan på tidigare konferenser gjort att deras svar anses mindre intressanta. Svaren för åldersgruppen år med, respektive utan, smart enhet samt åldersgruppen 60+ visas i figur B.3, figur B.4 och figur B.5. Dessa grupper har också undersökts efter innehav av någon smart enhet vilket visade B3

70 Bilaga B. Enkät B.2. Svar Figur B.3: Enkätsvar åldersgrupp med smartenhet. Figur B.4: Enkätsvar åldersgrupp utan smartenhet. att grupperna hade en något lägre andel personer som inte hade det. I gruppen för individer i åldern över 60 var det enbart två svarande av tio som saknade en smart enhet. Detta tillsammans med att individernas svar på frågor som inte rör sådana enheter överensstämt med övriga gruppen, har gjort att de två enkätsvaren inte visas i ett eget diagram. B4

71 Bilaga B. Enkät B.2. Svar Figur B.5: Enkätsvar åldersgrupp 60+. B5

72 Bilaga B. Enkät B.3. Slutsatser Grupperna har i stor utsträckning svarat relativt entydigt på de olika frågorna med ett fåtal undantag. Dessa undantag har varit centrerade kring användarens önskemål om uppdateringar och användandet av navigeringstjänsten. I dessa fall har gruppernas svar varit jämnt fördelade mellan de olika alternativen vilket kan antyda att dessa frågor har stora inslag av personliga preferenser. B.3 Slutsatser I de svar som enkäten genererat går det att märka att de flesta frågor har väldigt tydliga utfall som dessutom är relativt oberoende av de tillfrågades ålder. I enkäten märks att en stor andel användare av smarta enheter upptäcker ny epost vilket gör att detta kommunikationssätt går att använda för att tillkalla uppmärksamheten på stora delar av målgruppen. Enkätsvaren visar också på att de som har en smart enhet vet hur webbläsaren används och kan därför antas ha en viss vana av att inhämta information via Internet på sin smarta enhet. Det är också möjligt att se att en övergripande majoritet av användarna är intresserade av att få någon typ av notifiering om schemaändringar i det personliga schemat direkt till sin smarta enhet. På frågan om hur de tillfrågade vill få allmän information angående mässan har de flesta svarat att de är intresserade av att få också dessa till sin smarta enhet. Det är dock ett mindre antal som har uttryckt önskemål om att denna typ av information ska finnas tillgänglig i tryck samt på en eventuell hemsida. En slutsats som kan dras är att det anses önskvärt att som mässdeltagare kunna filtrera och välja vilka av alla nyheter och uppdateringar som de får veta. Detta baseras på att en stor majoritet av de svarande uttryckt sig positivt till detta. Vad gäller personliga program svarade även här en stor majoritet att det ansågs som viktigt och önskvärt. Dock var ålderskategorin år mindre övervägande positiva till detta, och av de i den kategorin som dessutom inte hade någon smart enhet ansåg fler att det inte var viktigt. Då just denna ålderskategoris svar är mindre intressanta då den inte stämmer överens med åldern på tidigare deltagare, spelar just dessa svar mindre roll. Slutsatsen blir således att de är viktigt med tillgång till ett personligt program. På den sista frågan, som handlade om navigeringen på mässområdet, har inget svar en tydlig övervägande majoritet. Det alternativ som fått flest svar är att få se en karta med färgade hus och att få veta vilken färg det eftersökta huset har och vilken våning användaren ska till, men då det andra alternativet, som var att kunna klicka på hus på en karta och på så vis få upp en bild på våningsplan, har fått nästan lika många svar, är det inte möjligt att dra någon slutsats om preferens i just det här fallet. De få som svarade alternativet övrigt skrev att de ville ha en kombination av de två alternativen och sin egen position, att det beror på hur stort området är och hur svårt det är att hitta till rätt sal när rätt våning hittats, att de vill ha en personlig kartläsare som säger var de ska gå, samt att de inte vill behöva använda mobilen till det ändamålet överhuvudtaget. De slutsatser som dras av det här utfallet på frågan är att det är en smaksak hur navigationen helst går till och att båda de största alternativen är gångbara. Dessutom utesluter inte alternativen varandra, så en kombination vore inte omöjlig att tänka sig för att göra så många som möjligt nöjda. B6

73 Bilaga C. Intervjuer Bilaga C Intervjuer Nedan följer en sammanställning av den information som insamlats från intervjuer med representanter ur målgruppen. Intervjuerna består av frågor som syftar till att visa på den svarandes vanor vid informationshantering i en mässmiljö. Frågorna som ställdes var baserade på frågorna från enkäten i bilaga B, men ibland mer detaljerade och med följdfrågor. Syftet för varje intervjuare var att dessa frågor skulle ställas på ett öppet sätt. Totalt intervjuades 15 personer inom åldersspannet 10 till 69 år. C.1 Frågeställningar Frågorna som ställdes är kategoriserade inom följande ämnen. Användarvana gällande smartphones/surfplattor. Majoriteten av de tillfrågade med en smart enhet hade viss/god erfarenhet av den. Ett fåtal av de tillfrågade med en smart enhet använde inte mail- eller webbläsarfunktionaliteten. Informationshantering. Tillfrågade utan smart enhet påpekade att även de ville kunna ta emot information via andra tekniker, som sms. Även vissa med smart enhet kunde tänka sig att få viss information via sms (enbart viktig information, t ex salsändring). Ett flertal ville ha notiferingar (inkl. sms) men enbart information angående sig själva. Andra förslag som sas av fler än en person: QR-koder med information om utställare/föreläsningar som ska kunna taggas/bokmärkas (både information och plats på karta). Tydlig information i förväg om hur mässinformationen kommer att uppdateras och skickas ut under mässan. Även information om var mässinformationen kommer att finnas tillgänglig. Information om lediga föreläsningar under mässan. C1

74 Bilaga C. Intervjuer C.2. Slutsats Navigering av mässområde. Byggnader med olika färger. Tydliga kartor som visar vart man är, vart man ska gå och med markerade ingångar och salar. Förklaring av namngivningsstruktur på salsnamn (N430 -> Naturvetarhuset 4:e våningen). Många av de tillfrågade skulle uppskatta kartor över våningsplan med enbart relevant information. Ett fåtal påpekade att dessa kartor ej var viktiga, pga att de var för komplicerade. Logistisk information, till exempel var bankomater finns och öppettider för kaféer och matställen. Instruktioner inomhus för att ta sig till rätt plats ( indoor navigation, gps). Bilder av de stora ingångarna till byggnader. Övriga kommentarer Kunna synkronisera personligt mässprogram med kalender på sin smarta enhet. Recensera evenemanget via smart enhet. En applikation föredrogs framför en hemsida. Enkla menyer och stor text. C.2 Slutsats Slutsatserna som kan dras från intervjuerna är att de flesta tillfrågade med en smart enhet hade viss/god erfarenhet av att använda denna. De flesta tillfrågade ville att tjänsten skulle använda sig av notifieringar, antingen som push notification i applikation eller som sms. Det är dock viktigt att den information som fås via notifiering endast är viktig för den personen, alltså inga notifieringar för allmän och mindre viktig information. Andra kommentarer/förslag som nämndes av flera av de tillfrågade har sammanfattats i följande punkter: Information om mässan ska kunna fås innan mässan börjar. Tydlig karta med relevant information. Byggnader ska kunna identifieras med olika färg, och ingångarna ska tydligt kunna urskiljas. Information som förklarar namnstrukturen för salar på Umeå Universitet ska finnas tillgänglig. Det ska gå att kunna se var man är någonstans på en karta. C2

75 Bilaga D. Användarfall och scenarion Bilaga D Användarfall och scenarion I detta dokument beskrivs användarfallen samt scenariona för systemet för Matematikbiennalen Dessa har tagits fram utifrån bilaga A. D.1 Användarfall De användarfall som identifierats utifrån målen i avsnitt A.2 listas i tabell D.1. D1

76 Bilaga D. Användarfall och scenarion D.1. Användarfall Tabell D.1: Användarfallen identifierade på Matematikbiennalens informationssystem prioriterade med indikering på om de är implementerade respektive testade. Användarfallen är prioriterade enligt om användarfallet är ett skall- eller bör-användarfall. Skall är sådant som implementeras och bör är sådant som förmodligen kommer att implementeras. Ett kryss för ett användarfall i kolumnen Implementerat eller Testat indikerar att användarfallet är implementerat respektive testat. Implementerat innebär att funktionaliteten är implementerad samt dokumenterad. Dokumentationen ska ske enligt de riktlinjer som finns i dokumentet README som följer med koden för den tekniska dokumentationen. Med hjälp av dokumentationen (exempelvis kommentarer och den tekniska dokumentationen) ska koden sedan vara självförklarande. Testat innebär att systemtesterna och acceptanstesterna gått igenom. Kolumnen Scenarion kvar specificerar vilka scenarion som inte ännu är implementerade eller testade för påbörjade användarfall, L2 står för Lyckat scenario 2 och M1 står för Misslyckat scenario 1. Användarfall Prioritering Implementerat Testat ANV.1 Skapa nyhet Skall X X ANV.2 Användare kan läsa nyhet Skall X ANV.3 Administratör kan läsa nyhet Skall X X ANV.4 Redigera nyhet Skall X X ANV.5 Radera nyhet Skall X X ANV.6 Hitta föreläsningssal Skall X ANV.7 Hitta toalett Skall X ANV.8 Hitta kaffe Skall X ANV.9 Hitta informationspunkt Skall X ANV.10 Hitta uställarkategori Skall X ANV.11 Hitta till campus ANV.12 Hitta till hotell ANV.13 Hitta till busshållplats ANV.14 Hitta till järnvägsstation Skall ANV.15 Hitta till lunchservering Skall X ANV.16 Hitta till parkeringsplats ANV.17 Hitta till utställare ANV.18 Kolla program Bör Bör Bör Skall Bör Skall ANV.19 Ändra föreläsningssal ANV.20 newpageändra om en föreläsning är inställd Bör Bör ANV.21 Ändra om en uställning är inställd Bör ANV.22 Logga in som administratör Skall X X ANV.23 Se dagens lunch Bör ANV.24 Kolla personligt program Bör ANV.25 Ladda upp program Bör ANV.26 Läsa allmän information Skall X X D2

77 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2 Scenarion D3

78 Bilaga D. Användarfall och scenarion D.2. Scenarion I nedanstående avsnitt listas alla scenarion kopplat till varje användarfall. D.2.1 Användarfall ANV.1, skapa nyhet Beskrivning Administratörer ska kunna skapa en nyhet. Lyckat scenario 1, vanlig nyhet Aktörer Administratör, administrationsverktyg, databas, server. Startvillkor Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har skapat en nyhet. 1. Administratören väljer att skapa en nyhet. 2. Administrationsverktyget presenterar ett formulär för inmatning av information gällande nyheten. 3. Administratören matar in informationen och väljer att publicera nyheten. 4. Administrationsverktyget skickar nyheten till servern. 5. Servern lagrar nyheten i databasen. 6. Servern svarar att det gick bra. 7. Administrationsverktyget uppdaterar nyhetsflödet. Lyckat scenario 2, prioriterad nyhet Aktörer Administratör, administrationsverktyg, databas, server. Startvillkor Administratören är inloggad i administrationverktyget. Slutvillkor Administratören har skapat en nyhet med prioritet. 1. Administratören väljer att skapa en nyhet. 2. Administrationsverktyget presenterar ett formulär för inmatning av information gällande nyheten. 3. Administratören matar in informationen. 4. Administratören väljer att prioritera nyheten och en tid då nyheten slutar vara prioriterad. 5. Administratören väljer att publicera nyheten. 6. Administrationsverktyget skickar nyheten till servern. 7. Servern lagrar nyheten i databasen. 8. Servern svarar att det gick bra. 9. Administrationsverktyget uppdaterar nyhetsflödet. D4

79 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, glömmer fält Aktörer Administratör, administrationsverktyg, databas, server. Startvillkor Administratören är inloggad i administrationverktyget. Slutvillkor Administratören har inte skapat en nyhet och fått återkoppling om varför. 1. Administratören väljer att skapa en nyhet. 2. Administrationsverktyget presenterar ett formulär för inmatning av information gällande nyheten. 3. Administratören matar in informationen, men glömmer att skriva in en rubrik eller innehåll samt väljer att publicera nyheten. 4. Administrationsverktyget visar ett felmeddelande och nyheten skickas inte till servern. 5. Administrationverktyget presenterar formuläret igen med den gamla informationen sparad. 6. Administratören får möjlighet att rätta till nyheten. Misslyckat scenario 2, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server. Startvillkor Administratören är inloggad i administrationsverktyget. Servern är inte nåbar. Slutvillkor Administratören har inte skapat en nyhet och fått återkoppling om serverkopplingsproblemet. 1. Administratören väljer att skapa en nyhet. 2. Administrationsverktyget presenterar ett formulär för inmatning av information gällande nyheten. 3. Administratören matar in all information som behövs och väljer att publicera nyheten. 4. Administrationsverktyget försöker få kontakt med servern. 5. Administrationsverktyget får ej tillgång till servern. 6. Administrationsverktyget ger administratören återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 3, för många tecken i titel Aktörer Administratör, administrationsverktyg, databas, server. Startvillkor Administratören är inloggad i administrationverktyget. Slutvillkor Administratören har inte skapat en nyhet och fått återkoppling om varför. 1. Administratören väljer att skapa en nyhet. 2. Administrationsverktyget presenterar ett formulär för inmatning av information gällande nyheten. 3. Administratören matar in all information som behövs, men använder för många tecken till titel. 4. Administrationsverktyget visar ett felmeddelande och nyheten skickas inte till servern. 5. Administrationverktyget presenterar formuläret igen med den gamla informationen sparad. 6. Administratören får möjlighet att rätta till nyheten. D5

80 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 4, för många tecken i innehåll Aktörer Administratör, administrationsverktyg, databas, server. Startvillkor Administratören är inloggad i administrationverktyget. Slutvillkor Administratören har inte skapat en nyhet och fått återkoppling om varför. 1. Administratören väljer att skapa en nyhet. 2. Administrationsverktyget presenterar ett formulär för inmatning av information gällande nyheten. 3. Administratören matar in all information som behövs, men använder för många tecken till nyhetstexten. 4. Administrationsverktyget visar ett felmeddelande och nyheten skickas inte till servern. 5. Administrationverktyget presenterar formuläret igen med den gamla informationen sparad. 6. Administratören får möjlighet att rätta till nyheten. D6

81 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.2 Användarfall ANV.2, användare kan läsa nyhet Beskrivning Användare ska kunna läsa en publicerad nyhet. Lyckat scenario Aktörer Användare, klienter, server, databas. Startvillkor Administratören har publicerat en nyhet. Slutvillkor Användaren har läst nyheten. 1. Användaren väljer att läsa nyheter. 2. Klienten skickar en förfrågan till servern för att hämta alla publicerade nyheter. 3. Servern hämtar alla publicerade nyheter från databasen. 4. Servern skickar alla publicerade nyheter till klienten. 5. Klienten visar upp nyheterna för användaren. Misslyckat scenario, ingen koppling mot server Aktörer Användare, klienter, server. Startvillkor Administratören har publicerat en nyhet. Servern är inte nåbar. Slutvillkor Klienten visar inte nyheterna och användaren har fått återkoppling om serverkopplingsproblemet. 1. Klienten skickar en förfrågan till servern för att hämta alla publicerade nyheter. 2. Klienten får ej tillgång till servern. 3. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. D7

82 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.3 Användarfall ANV.3, administratör kan läsa nyhet Beskrivning Administratörer ska kunna läsa en publicerad nyhet. Lyckat scenario Aktörer Administratör, administrationsverktyget, server, databas. Startvillkor Administratören har publicerat en nyhet. Slutvillkor Administrationsverktyget visar nyheterna. 1. Administrationsverktyget skickar en förfrågan till servern för att hämta alla publicerade nyheter. 2. Servern hämtar alla publicerade nyheter från databasen. 3. Servern skickar alla publicerade nyheter till administrationsverktyget. 4. Administrationsverktyget visar upp nyheterna för användaren. Misslyckat scenario, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server. Startvillkor Administratören har publicerat en nyhet. Servern är inte nåbar. Slutvillkor Administrationsverktyget visar inte nyheter och administratören har fått återkoppling om serverkopplingsproblemet. 1. Administrationsverktyget skickar en förfrågan till servern för att hämta alla publicerade nyheter. 2. Administrationsverktyget får ej tillgång till servern. 3. Administrationsverktyget ger administratören återkoppling om att den ej fått tillgång till servern. D8

83 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.4 Användarfall ANV.4, redigera nyhet Beskrivning Administratörer ska kunna redigera en publicerad nyhet. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor En administratör har publicerat en nyhet. Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har redigerat nyheten. 1. Administratören väljer att redigera en nyhet. 2. Administrationsverktyget skickar en förfrågan till servern för att hämta alla publicerade nyheter. 3. Servern hämtar alla publicerade nyheter från databasen. 4. Servern skickar alla publicerade nyheter till administrationsverktyget. 5. Administrationsverktyget presenterar nyheterna för användaren. 6. Administratören väljer en specifik nyhet att redigera. 7. Administrationsverktyget presenterar nyheten i ett formulär. 8. Administratören redigerar nyheten och väljer att spara nyheten. 9. Administrationsverktyget skickar nyheten till servern. 10. Servern uppdaterar nyheten i databasen. Misslyckat scenario 1, glömmer fält Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor En administratör har publicerat en nyhet. Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har misslyckats att redigera nyheten och fått återkoppling om varför. 1. Administratören väljer att redigera en nyhet. 2. Administrationsverktyget skickar en förfrågan till servern för att hämta alla publicerade nyheter. 3. Servern hämtar alla publicerade nyheter från databasen. 4. Servern skickar alla publicerade nyheter till administrationsverktyget. 5. Administrationsverktyget presenterar nyheterna för användaren. 6. Administratören väljer en specifik nyhet att redigera. 7. Administrationsverktyget presenterar nyheten i ett formulär. 8. Administratören redigerar nyheten och lämnar ett fält tomt. 9. Administratören väljer att spara nyheten. 10. Administrationsverktyget ger administratören återkoppling på att denne glömt att fylla i ett fält. 11. Administrationverktyget presenterar formuläret igen med den gamla informationen sparad. 12. Administratören får möjlighet att rätta till nyheten. D9

84 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 2, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server. Startvillkor En administratör har publicerat en nyhet. Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har misslyckats att redigera nyheten och fått återkoppling om varför. 1. Administratören väljer att redigera en nyhet. 2. Administrationsverktyget hämtar alla publicerade nyheter från servern och databasen samt presenterar dessa. 3. Administratören väljer en specifik nyhet att redigera. 4. Administrationsverktyget presenterar nyheten i ett formulär. 5. Administratören redigerar nyheten och väljer att spara nyheten. 6. Administrationsverktyget försöker få kontakt med servern. 7. Administrationsverktyget får ej tillgång till servern. 8. Administrationsverktyget ger administratören återkoppling om att den ej fått tillgång till servern. 9. Administrationsverktyget presenterar formuläret igen med den gamla informationen sparad. 10. Administratören får möjlighet att rätta till nyheten. D10

85 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.5 Användarfall ANV.5, radera nyhet Beskrivning Administratörer ska kunna radera en publicerad nyhet. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor En administratör har publicerat en nyhet. Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har raderat nyheten. 1. Administratören väljer att radera en nyhet. 2. Administrationsverktyget hämtar alla publicerade nyheter från servern och databasen samt presenterar dessa. 3. Administratören väljer en specifik nyhet att radera. 4. Administrationsverktyget frågar om det är korrekt nyhet som ska raderas. 5. Administratören svarar ja. 6. Administrationsverktyget säger till servern att radera nyheten från databasen. 7. Servern raderar nyheten ifrån databasen. 8. Servern svarar att det gick bra. 9. Administrationsverktyget uppdaterar nyhetsflödet. Misslyckat scenario 1, administratör väljer fel nyhet Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor En administratör har publicerat en nyhet. Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har inte raderat nyheten. 1. Administrationsverktyget hämtar alla publicerade nyheter från servern och databasen samt presenterar dessa. 2. Administratören klickar radera en nyhet. 3. Administrationsverktyget frågar om det är korrekt nyhet som ska raderas. 4. Administratören svarar nej. 5. administrationsverktyget återgår till den vanliga vyn. D11

86 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 2, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server. Startvillkor En administratör har publicerat en nyhet. Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har inte raderat nyheten och fått återkoppling om varför. 1. Administrationsverktyget hämtar alla publicerade nyheter från servern och databasen samt presenterar dessa. 2. Administratören klickar radera en nyhet. 3. Administrationsverktyget frågar om det är korrekt nyhet som ska raderas. 4. Administratören svarar ja. 5. Administrationsverktyget försöker få kontakt med servern. 6. Administrationsverktyget får ej tillgång till servern. 7. Administrationsverktyget ger administratören återkoppling om att den ej fått tillgång till servern. D12

87 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.6 Användarfall ANV.6, hitta föreläsningssal Beskrivning Användare ska kunna få hjälp att hitta till en föreläsning. Lyckat scenario 1, söker på salsnummer, med positioneringsdata Aktörer Klienter, användare, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en föreläsning. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar en karta till klienten. 4. Klienten visar en översiktskarta med en markör där användaren befinner sig. 5. Användaren väljer att söka efter en föreläsning genom att ange ett salsnummer. 6. Klienten frågar servern om positionen för det givna salsnumret. 7. Servern hämtar positionen ifrån databasen. 8. Servern skickar positionen till klienten. 9. Klienten visar salens position med en markör på kartan. Lyckat scenario 2, söker på salsnummer, utan positionseringsdata Aktörer Klienter, användare, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en föreläsning. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen. 5. Servern skickar positionen till klienten. 6. Klienten skickar en förfrågan till Google maps om karta. 7. Google maps skickar en karta till klienten. 8. Klienten visar en översiktskarta med en markör där användaren befinner sig. 9. Användaren väljer att söka efter en föreläsning genom att ange ett salsnummer. 10. Klienten frågar servern om positionen för det givna salsnumret. 11. Servern hämtar positionen ifrån databasen. 12. Servern skickar positionen till klienten. 13. Klienten visar salens position med en markör på kartan. D13

88 Bilaga D. Användarfall och scenarion D.2. Scenarion Lyckat scenario 3, söker på föreläsningsnummer, med positionseringsdata Aktörer Klienter, användare, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en föreläsning. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar en karta till klienten. 4. Klienten visar en översiktskarta med en markör där användaren befinner sig. 5. Användaren väljer att söka efter en föreläsning genom att ange ett föreläsningsnummer. 6. Klienten frågar servern om positionen för den givna föreläsningen. 7. Servern hämtar positionen ifrån databasen och skickar den till klienten. 8. Klienten visar föreläsningssalens position med en markör på kartan. Lyckat scenario 4, söker på föreläsningsnummer, utan positionseringsdata Aktörer Klienter, användare, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en föreläsning. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten visar en översiktskarta med en markör där användaren befinner sig. 6. Användaren väljer att söka efter en föreläsning genom att ange ett föreläsningsnummer. 7. Klienten frågar servern om positionen för den givna föreläsningen. 8. Servern hämtar positionen ifrån databasen och skickar den till klienten. 9. Klienten visar föreläsningssalens position med en markör på kartan. Lyckat scenario 5, föreläsningsinformation, med positionseringsdata Aktörer Klienter, användare, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Användaren är inne i programvyn och läser om en föreläsning. Slutvillkor Användaren har fått hjälp att hitta till en föreläsning. 1. Användaren väljer att hitta till föreläsning. 2. Klienten visar en översiktskarta med en markör där användaren befinner sig samt en markör för salens position. D14

89 Bilaga D. Användarfall och scenarion D.2. Scenarion Lyckat scenario 6, föreläsningsinformation, utan positionseringsdata Aktörer Klienter, användare, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Användaren är inne i programvyn och läser om en föreläsning. Slutvillkor Användaren har fått hjälp att hitta till en föreläsning. 1. Användaren väljer att hitta till föreläsning. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten visar en översiktskarta med en markör där användaren befinner sig samt en markör för salens position. Misslyckat scenario 1, sal finns ej Aktörer Klienter, användare, server, databas. Startvillkor Användaren är inne i navigeringstjänsten. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att söka efter en föreläsning genom att ange ett salsnummer som inte existerar. 2. Klienten frågar servern om positionen för det givna salsnumret. 3. Servern försöker hämta positionen för den givna salen ifrån databasen, men salen existerar ej. 4. Servern skickar ett felmeddelande till klienten. 5. Klienten visar ett felmeddelande för användaren som säger att salen inte existerar. 6. Användaren får möjlighet att söka efter en föreläsning på nytt. Misslyckat scenario 2, föreläsning finns ej Aktörer Klienter, användare, server, databas. Startvillkor Användaren är inne i navigeringstjänsten. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att söka efter en föreläsning genom att ange ett föreläsningsnummer som inte existerar. 2. Klienten frågar servern om positionen för den givna föreläsningen. 3. Servern försöker hämta positionen för den givna salen ifrån databasen, men salen existerar ej. 4. Servern skickar ett felmeddelande till klienten. 5. Klienten visar ett felmeddelande för användaren som säger att föreläsningen inte existerar. 6. Användaren får möjlighet att söka efter en föreläsning på nytt. D15

90 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 3, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 4, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D16

91 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.7 Användarfall ANV.7, hitta toalett Beskrivning Användare ska kunna få hjälp att hitta till en toalett. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en toalett. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar översiktskartan med användarens position markerad. 5. Användaren väljer att visa toaletter. 6. Klienten frågar servern om alla positioner för toaletter. 7. Servern hämtar alla positioner för toaletter ifrån databasen. 8. Servern skickar alla positioner till klienten. 9. Klienten visar en översiktskarta med alla toaletter markerade. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en toalett. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten ansluter till Google maps för att hämta översiktskarta. 6. Google maps skickar tillbaka översiktskarta. 7. Klienten visar en översiktskarta med användarens position markerad. 8. Användaren väljer att visa toaletter. 9. Klienten frågar servern om alla positioner för toaletter. 10. Servern hämtar alla positioner för toaletter ifrån databasen. 11. Servern skickar alla positioner till klienten. 12. Klienten visar en översiktskarta med alla toaletter markerade. D17

92 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D18

93 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.8 Användarfall ANV.8, hitta kaffe Beskrivning Användare ska kunna få hjälp att hitta till en kaffestation. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till kaffestationer. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa kaffestationer. 6. Klienten frågar servern om alla positioner för kaffestationer. 7. Servern hämtar alla positioner för kaffestationer ifrån databasen. 8. Servern skickar positionerna till klienten. 9. Klienten visar alla kaffestationer på kartan. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till kaffestationer. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten ansluter till Google maps för att hämta översiktskarta. 6. Google maps skickar tillbaka översiktskarta. 7. Klienten visar en översiktskarta med användarens position markerad. 8. Användaren väljer att visa kaffestationer. 9. Klienten frågar servern om alla positioner för kaffestationer. 10. Servern hämtar alla positioner för kaffestationer ifrån databasen. 11. Servern skickar positionerna till klienten. 12. Klienten visar alla kaffestationer på kartan. D19

94 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D20

95 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.9 Användarfall ANV.9, hitta informationspunkt Beskrivning Användare ska kunna få hjälp att hitta till en informationspunkt. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till en informationspunkt. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa informationspunkter. 6. Klienten frågar servern om alla informationspunkter. 7. Servern hämtar all data om informationspunkter ifrån databasen. 8. Servern skickar all data till klienten. 9. Klienten visar en översiktskarta med alla informationspunkter markerade. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till en informationspunkt. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten ansluter till Google maps för att hämta översiktskarta. 6. Google maps skickar tillbaka översiktskarta. 7. Klienten visar en översiktskarta med användarens position markerad. 8. Användaren väljer att visa informationspunkter. 9. Klienten frågar servern om alla informationspunkter. 10. Servern hämtar alla positioner för informationspunkterna ifrån databasen. 11. Servern skickar alla positioner till klienten. 12. Klienten visar en översiktskarta med alla informationspunkter markerade. D21

96 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D22

97 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.10 Användarfall ANV.10, hitta utställarkategori Beskrivning Användare ska kunna få hjälp att hitta till en utställarkategori. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till utställningar inom en viss kategori. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa en utställningskategori. 6. Klienten visar en översiktskarta med ett markerat område där den specifika utställningskategorin befinner sig. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till utställningar inom en viss kategori. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten ansluter till Google maps för att hämta översiktskarta. 6. Google maps skickar tillbaka översiktskarta. 7. Klienten visar en översiktskarta med användarens position markerad. 8. Användaren väljer att visa en utställningskategori. 9. Klienten visar en översiktskarta med ett markerat område där den specifika utställningskategorin befinner sig. D23

98 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D24

99 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.11 Användarfall ANV.11, hitta till campus Beskrivning Användare ska kunna få hjälp att hitta till campus-området. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till campus. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa campus. 6. Klienten frågar servern om positioner för campus området. 7. Servern hämtar positionerna för campus området ifrån databasen. 8. Servern skickar positionerna till klienten. 9. Klienten visar en översiktskarta med campusområdet markerat. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till campus. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren väljer att visa campus. 3. Klienten ansluter till Google maps för att hämta översiktskarta. 4. Google maps skickar tillbaka översiktskarta. 5. Klienten frågar servern om positioner för campus området. 6. Servern hämtar positionerna för campus området ifrån databasen. 7. Servern skickar positionerna till klienten. 8. Klienten visar en översiktskarta med campusområdet markerat. D25

100 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D26

101 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.12 Användarfall ANV.12, hitta till hotell Beskrivning Användare ska kunna få hjälp att hitta till sitt hotell. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till sitt hotell. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa positionen för ett hotell från en lista. 6. Klienten visar en översiktskarta med hotellet markerat. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till sitt hotell. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren väljer att visa positionen för ett hotell från en lista. 3. Klienten ansluter till Google maps för att hämta översiktskarta. 4. Google maps skickar tillbaka översiktskarta. 5. Klienten visar en översiktskarta med sitt hotell markerat. Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. D27

102 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D28

103 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.13 Användarfall ANV.13, hitta till busshållplats Beskrivning Användare ska kunna få hjälp att hitta till en busshållplats. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till busshållplatser. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa busshållplatser. 6. Klienten frågar servern om alla busshållsplatser. 7. Servern hämtar alla positioner för busshållsplatser ifrån databasen. 8. Servern skickar alla positioner till klienten. 9. Klienten visar en översiktskarta med alla busshållplatser i närheten av campusområdet markerade. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till busshållplatser. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där den befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten ansluter till Google maps för att hämta översiktskarta. 6. Google maps skickar tillbaka översiktskarta. 7. Klienten visar en översiktskarta med användarens position markerad. 8. Användaren väljer att visa busshållplatser. 9. Klienten frågar servern om alla informationspunkter. 10. Servern hämtar alla positioner för informationspunkterna ifrån databasen. 11. Servern skickar alla positioner till klienten. 12. Klienten visar en översiktskarta med alla busshållplatser i närheten av campusområdet markerade. D29

104 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D30

105 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.14 Användarfall ANV.14, hitta till järnvägsstation Beskrivning Användare ska kunna få hjälp att hitta till en järnvägsstation. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till järnvägsstationer. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa järnvägsstationer. 6. Klienten visar en översiktskarta med järnvägsstationerna i Umeå markerade. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till järnvägsstationer. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren väljer att visa järnvägsstationer. 3. Klienten ansluter till Google maps för att hämta översiktskarta. 4. Google maps skickar tillbaka översiktskarta. 5. Klienten visar en översiktskarta med järnvägsstationerna i Umeå markerade. Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. D31

106 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D32

107 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.15 Användarfall ANV.15, hitta till lunchservering Beskrivning Användare ska kunna hitta till lunchserveringen. Lyckat scenario, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till lunchserveringen med hjälp av tjänsten. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten ansluter till Google maps för att hämta översiktskarta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa lunchserveringen. 6. Klienten frågar servern om position för lunchserveringen. 7. Servern hämtar positionen för lunchserveringen ifrån databasen. 8. Servern skickar positionen till klienten. 9. Klienten visar en översiktskarta med lunchserveringen markerad. Lyckat scenario, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till lunchserveringen med hjälp av tjänsten. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där denne befinner sig. 3. Klienten frågar servern om positionen för det givna salsnumret. 4. Servern hämtar positionen ifrån databasen och skickar den till klienten. 5. Klienten ansluter till Google maps för att hämta översiktskarta. 6. Google maps skickar tillbaka översiktskarta. 7. Klienten visar en översiktskarta med användarens position markerad. 8. Användaren väljer att visa lunchserveringen. 9. Klienten frågar servern om position för lunchserveringen. 10. Servern hämtar positionen för lunchserveringen ifrån databasen. 11. Servern skickar positionen till klienten. 12. Klienten visar en översiktskarta med lunchserveringen markerad. D33

108 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D34

109 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.16 Användarfall ANV.16, hitta till parkeringsplats Beskrivning Användare ska kunna hitta till parkeringsplatser som ligger inom gångavstånd från biennalen. Lyckat scenario 1, med positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till en parkeringsplats med hjälp av tjänsten. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar en karta till klienten. 4. Klienten visar en översiktskarta med användarens position markerad. 5. Användaren väljer att visa parkeringsplatser. 6. Klienten frågar servern om positioner för parkeringsplatser. 7. Servern hämtar positionerna ifrån databasen. 8. Servern skickar positionerna till klienten. 9. Klienten visar en översiktskarta med parkeringsplatserna markerade. Lyckat scenario 2, utan positioneringsdata Aktörer Användare, klienter, server, Google maps, databas. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått information om hur denne kan hitta till en parkeringsplats med hjälp av tjänsten. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där denne befinner sig. 3. Klienten frågar servern om positionen för det givna salsnummret. 4. Servern hämtar positionen ifrån databasen. 5. Servern skickar positionen till klienten. 6. Klienten skickar en förfrågan till Google maps om karta. 7. Google maps skickar en karta till klienten. 8. Klienten visar en översiktskarta med användarens position markerad. 9. Användaren väljer att visa parkeringsplatser. 10. Klienten frågar servern om positioner för parkeringsplatser. 11. Servern hämtar positionerna ifrån databasen. 12. Servern skickar positionerna till klienten. 13. Klienten visar en översiktskarta med parkeringsplatserna markerade. D35

110 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D36

111 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.17 Användarfall ANV.17, hitta till utställare Beskrivning Användare ska kunna få hjälp att hitta till en utställare. Lyckat scenario 1, med positioneringsdata Aktörer Klienter, användare. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en utställare. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten visar en översiktskarta med en markör där användaren befinner sig. 3. Användaren väljer att söka efter en utställare genom att ange ett monternummer. 4. Klienten visar utställarens position med en markör på kartan. Lyckat scenario 2, utan positioneringsdata Aktörer Klienter, användare. Startvillkor Positioneringsdata finns ej tillgängligt på användarens enhet. Slutvillkor Användaren har fått hjälp att hitta till en utställare. 1. Användaren väljer att använda navigeringstjänsten. 2. Användaren skriver in ett salsnummer där denne befinner sig. 3. Klienten visar en översiktskarta med en markör där användaren befinner sig. 4. Användaren väljer att söka efter en utställare genom att ange ett monternummer. 5. Klienten visar utställarens position med en markör på kartan. Misslyckat scenario 1, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Google maps skickar tillbaka översiktskarta. 4. Klienten försöker få kontakt med servern. 5. Klienten får ej tillgång till servern. 6. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. D37

112 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 2, ingen koppling mot Google maps Aktörer Administratör, administrationsverktyg, Google maps. Startvillkor Positioneringsdata finns tillgängligt på användarens enhet. Slutvillkor Användaren får inte se någon karta, har inte fått hjälp att hitta till en föreläsning och fått återkoppling om varför. 1. Användaren väljer att använda navigeringstjänsten. 2. Klienten skickar en förfrågan till Google maps om karta. 3. Klienten får ej tillgång till Google maps. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till Google maps. D38

113 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.18 Användarfall ANV.18, kolla program Beskrivning Användare ska kunna se blockschemat för programmet. Lyckat scenario Aktörer Användare, klienter, server, databas. Startvillkor - Slutvillkor Användaren har fått information om blockschemat för programmet. 1. Användaren väljer att gå in i klientens programtjänst. 2. Klienten skickar en förfrågan till servern om att få data om blockschemat för programmet. 3. Servern hämtar all data från databasen om blockschemat för programmet. 4. Servern skickar datat till klienten. 5. Klienten presenterar blockschemat för användaren. Misslyckat scenario, ingen koppling mot server Aktörer Användare, klienter, server. Startvillkor - Slutvillkor Användaren har inte fått information om blockschemat för programmet. 1. Användaren väljer att gå in i klientens programtjänst. 2. Klienten skickar en förfrågan till servern om att få data om blockschemat för programmet. 3. Klienten har ej tillgång till servern. 4. Klienten ger användaren återkoppling om att den ej fått tillgång till servern. D39

114 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.19 Användarfall ANV.19, ändra föreläsningssal Beskrivning Administratörer ska kunna ändra föreläsningssal. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har ändrat föreläsningssal. 1. Administratören väljer att ändra programpunkter. 2. Administratören väljer att ändra föreläsningar. 3. Administrationsverktyget hämtar alla föreläsningar från servern och databasen samt presenterar dessa. 4. Administratören väljer att ändra sal på en specifik föreläsning. 5. Administrationsverktyget presenterar ett formulär för sal. 6. Administratören ändrar föreläsningssal och väljer att spara föreläsningen. 7. Administrationsverktyget skickar föreläsningen till servern som uppdaterar föreläsningen i databasen. D40

115 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.20 Användarfall ANV.20, ändra om en föreläsning är inställd Beskrivning Administratörer ska kunna ändra om en föreläsning är inställd eller ej. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har ändrat om en föreläsning är inställd eller ej. 1. Administratören väljer att ändra programpunkter. 2. Administratören väljer att ändra föreläsningar. 3. Administrationsverktyget hämtar alla föreläsningar från servern och databasen. 4. Administrationsverktyget presenterar alla föreläsningar. 5. Administratören väljer en specifik föreläsning att ändra om den är inställd eller ej. 6. Administrationsverktyget skickar föreläsningen till servern. 7. Servern uppdaterar föreläsningen i databasen. Misslyckat scenario, ingen koppling mot server Aktörer Administratör, administrationsverktyget, server. Startvillkor Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har ej ändrat om en föreläsning är inställd eller ej. 1. Administratören väljer att ändra programpunkter. 2. Administratören väljer att ändra föreläsningar. 3. Administrationsverktyget försöker få kontakt med servern. 4. Administrationsverktyget får ej tillgång till servern. 5. Administrationsverktyget ger användaren återkoppling om att den ej fått tillgång till servern. D41

116 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.21 Användarfall ANV.21, ändra om en utställning är inställd Beskrivning Administratörer ska kunna ändra om en utställning är inställd eller ej. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Administratören är inloggad i administrationsverktyget. Slutvillkor Administratören har ändrat om en utställning är inställd eller ej. 1. Administratören väljer att ändra programpunkter. 2. Administratören väljer att ändra utställningar. 3. Administrationsverktyget hämtar alla utställningar från servern och databasen samt presenterar dessa. 4. Administratören väljer en specifik utställning att ändra om den är inställd eller ej. 5. Administrationsverktyget skickar föreläsningen till servern som uppdaterar föreläsningen i databasen. D42

117 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.22 Användarfall ANV.22, logga in som administratör Beskrivning Administratörer ska kunna logga in i Administrationsverktyget. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Administratören har tillgång till sitt användarnamn och lösenord. Slutvillkor Administratören har loggat in. 1. Administratören öppnar administrationsverktyget. 2. Administrationsverktyget presenterar en inloggningsvy för administratören. 3. Administratören skriver in sina inloggningsuppgifter. 4. Administrationsverktyget kontaktar servern med ett anrop för att validera inloggningsuppgifterna. 5. Servern validerar inloggningsuppgifterna mot databasen och får en sessionsnyckel. 6. Servern skickar sessionsnyckeln till administrationsverktyget. 7. Administratören loggas in i administrationsverktyget. Misslyckat scenario 1, fel inloggningsuppgifter Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Administratören har tillgång till sitt användarnamn och lösenord. Slutvillkor Administratören har inte loggat in. 1. Administratören öppnar administrationsverktyget. 2. Administrationsverktyget presenterar en inloggningsvy för administratören. 3. Administratören skriver in sina inloggningsuppgifter, men skriver in fel uppgifter. 4. Administrationsverktyget kontaktar servern med ett anrop för att validera inloggningsuppgifterna. 5. Servern validerar inloggningsuppgifterna mot databasen och får ett negativt svar. 6. Servern skickar svaret till administrationsverktyget. 7. Administrationsverktyget ger åtterkoppling om att inloggningen misslyckades. 8. Administratören loggas inte in i administrationsverktyget. D43

118 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario 2, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server. Startvillkor Administratören har tillgång till sitt användarnamn och lösenord. Slutvillkor Administratören har inte loggat in. 1. Administratören öppnar administrationsverktyget. 2. Administrationsverktyget presenterar en inloggningsvy för administratören. 3. Administratören skriver in sina inloggningsuppgifter. 4. Administrationsverktyget kontaktar servern med ett anrop för att validera inloggningsuppgifterna. 5. Administrationsverktyget får ej tillgång till servern. 6. Administrationsverktyget ger administratören återkoppling om att den ej fått tillgång till servern. D44

119 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.23 Användarfall ANV.23, se dagens lunch Beskrivning Användare ska kunna se dagens lunch. Lyckat scenario Aktörer Användare, klienter. Startvillkor - Slutvillkor Användaren har fått information om dagens lunch. 1. Användaren väljer att se dagens lunch i klienten. 2. Klienten visar upp dagens lunch för användaren. D45

120 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.24 Användarfall ANV.24, kolla personligt program Beskrivning Användare ska kunna se sitt personliga schema. Lyckat scenario Aktörer Användare, klienter, databas, server. Startvillkor Användaren har sin personliga kod. Slutvillkor Användaren har fått information om sitt personliga schema. 1. Användaren väljer att använda klientens programtjänst. 2. Användaren väljer att visa sitt personliga program. 3. Användaren anger sin personliga kod i klienten. 4. Klienten ber om att få det personliga programmet kopplat till koden från Server. 5. Server hämtar det personliga programmet från databasen med hjälp av koden. 6. Servern skickar det personliga programmet till Klienten. 7. Klienten visar upp det personliga programmet. Misslyckat scenario, fel personliga kod Aktörer Användare, klienter, databas, server. Startvillkor Användaren har inte sin personliga kod. Slutvillkor Användaren har inte fått information om sitt personliga program. 1. Användaren väljer att använda klientens programtjänst. 2. Användaren väljer att visa sitt personliga program. 3. Användaren anger fel personliga kod i klienten. 4. Klienten ber om att få det personliga programmet kopplat till koden från Server. 5. Servern hittar inte koden i databasen och skickar ett felmeddelande till klienten. 6. Klienten ger användaren återkoppling om att koden är fel. Misslyckat scenario, ingen koppling mot server Aktörer Användare, klienter, server. Startvillkor Användaren har sin personliga kod. Slutvillkor Användaren har inte fått information om sitt personliga program. 1. Användaren väljer att använda klientens programtjänst. 2. Användaren väljer att visa sitt personliga program. 3. Användaren anger sin personliga kod i klienten. 4. Klienten ber om att få det personliga programmet kopplat till koden från Server. 5. Klienten har ej tillgång till servern. 6. Klienten ger användaren återkoplling om att den ej har tillgång till servern. D46

121 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.25 Användarfall ANV.25, ladda upp program Beskrivning Administratörer ska kunna ladda upp den programinformation de får från Trippus som ett kalkylark. Lyckat scenario Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Ett kalkylark på det format som fås från Trippus används, med två kolumner extra längst åt höger, varav den första är programpunkts-id och den andra är programpunktens eventuella sal. Administratören är inloggad i administrationsverktyget. Slutvillkor All relevant programinformation finns lagrad i databasen. 1. Administratören väljer att ladda upp programinfo. 2. Administrationsverktyget visar anvisningar, ett textfält för sökväg till programinfo-filen och en Ladda upp programinfo -knapp. 3. Administratören väljer en korrekt fil att ladda upp och trycker på Ladda upp programinfo -knappen. 4. Administrationsverktyget tar emot filen, läser ut relevant data ur filen. 5. Administrationsverktyget skickar informationen till servern. 6. Servern sparar informationen i databasen. Misslyckat scenario, inkorrekt programinformations-fil Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Ett kalkylark på det format som fås från Trippus används inte. Administratören är inloggad i administrationsverktyget. Slutvillkor Ingenting har lagts till i databasen. 1. Administratören väljer att ladda upp programinformation. 2. Administrationsverktyget visar anvisningar, ett textfält för sökväg till programinformations-filen och en Ladda upp programinfo -knapp. 3. Administratören väljer en inkorrekt fil att ladda upp och trycker på Ladda upp programinfo -knappen. 4. Administrationsverktyget upptäcker formatfelet. 5. Administrationsverktyget ger administratören återkoppling om att det är en inkorrekt fil och var felet börjar i filen. D47

122 Bilaga D. Användarfall och scenarion D.2. Scenarion Misslyckat scenario, ingen koppling mot server Aktörer Administratör, administrationsverktyg, server, databas. Startvillkor Ett kalkylark på det format som fås från Trippus används, med två kolumner extra längst åt höger, varav den första är programpunkts-id och den andra är programpunktens eventuella sal. Administratören är inloggad i administrationsverktyget. Slutvillkor ingenting har lagts till i databasen. 1. Administratören väljer att ladda upp programinfo. 2. Administrationsverktyget visar anvisningar, ett textfält för sökväg till programinfo-filen och en Ladda upp programinfo -knapp. 3. Administratören väljer en korrekt fil att ladda upp och trycker på Ladda upp programinfo -knappen. 4. Administrationsverktyget tar emot filen, läser ut relevant data ur filen. 5. Administrationsverktyget får ej tillgång till servern. 6. Administrationsverktyget ger administratören återkoppling om att den ej har tillgång till servern. D48

123 Bilaga D. Användarfall och scenarion D.2. Scenarion D.2.26 Användarfall ANV.26, läsa allmän information Beskrivning Användare ska kunna läsa allmän information om Matematikbiennalen och Umeå. Lyckat scenario Aktörer Användare, klienter. Startvillkor - Slutvillkor Användaren har kunnat läsa den allmänna informationen. 1. Användaren väljer att läsa allmän information. 2. Klienten visar upp den allmänna informationen för användaren. D49

124 Bilaga E. Krav Bilaga E Krav Nedan dokumenteras de tekniska kraven på Matematikbiennalens informationssystem. Dessa utgår ifrån användarfallen i bilaga D. Kraven är uppdelade i sex kategorier: karta, schema, nyhetsflöde, administration, transport samt information. Under respektive sektion presenteras de krav som relaterar till kategorin ifråga och huruvida kravet är testat och implementerat. Prefixet K. indikerar att punkten är ett krav och det efterföljande prefixet indikerar vilken kategori kravet härrör till. Funktionella krav har prefixet F., icke-funktionella krav har IF. och affärsregler har prefixet AR. E.1 Generellt Kravnummer Prioritering Implementerat Testat K.AR.G.1 Tjänsten ska inte bryta mot PUL. Skall X X K.AR.G.2 Utvecklandet av tjänsten ska inte bryta mot PUL. Skall X X K.F.G.3 Det ska gå att logga in på tjänsten som administratör. Skall X X K.F.G.4 Det ska gå att logga ut ur tjänsten som administratör. Skall X X K.F.G.5 Det ska gå att logga in som användare. K.IF.G.6 Tjänsten ska vara uppskattad av målgruppen. Skall X X K.IF.G.7 Den grafiska profilen ska följa det bildspråk som Matematikbiennalen vid Umeå universitet har valt att använda. Skall X K.IF.G.8 Tjänsten ska vara enkel att använda. K.IF.G.9 Tjänsten ska fungera för Android. Skall X X K.IF.G.10 Tjänsten ska fungera för ios. Skall X X K.IF.G.11 Tjänsten ska fungera för datorer. Skall X X K.IF.G.12 Tjänsten ska fungera för surfplattor. Bör X X K.IF.G.13 Det ska vara enkelt att administrera tjänsten. K.IF.G.14 Tjänsten ska utvecklas inom avsatt tid. Skall X X Bör Bör Skall E1

125 Bilaga E. Krav E.2. Nyheter E.2 Nyheter Kravnummer Prioritering Implementerat Testat K.F.N.1 Det ska gå att läsa samtliga nyheter. Skall X X K.F.N.2 Det ska gå att lägga till nyheter som administratör. Skall X X K.F.N.3 Det ska gå att redigera nyheter som administratör. Skall X X K.F.N.4 Det ska gå att radera nyheter som administratör. Skall X X K.F.N.5 Det ska gå att läsa nyheter som administratör. Skall X X E.3 Karta Kravnummer Prioritering Implementerat Testat K.F.K.1 Det ska gå att visa en översiktskarta över området. Skall X X K.F.K.2 Det ska gå att visa position för lunchtältet. Skall X X K.F.K.3 Det ska gå att visa positioner för utställare. Skall X X K.F.K.4 Det ska gå att visa positioner för salar. Skall X X K.F.K.5 Som användare ska det gå att visa egen position. Bör X X K.F.K.6 Det ska gå att visa positioner för toaletter. Bör X X K.F.K.7 Det ska gå att visa positioner för informationspunkter. Skall X X K.F.K.8 Det ska gå att visa positioner för kaffestationer. Skall X X K.F.K.9 Det ska gå att visa positioner för parkeringsplatser. Skall X X K.F.K.10 Det ska gå att visa positioner för busshållplatser. K.F.K.11 Det ska gå att visa positioner för järnvägsstationer. K.F.K.12 Det ska gå att visa positioner för hotell. K.F.K.13 Det ska gå att visa position för campus. Skall X K.F.K.14 Det ska gå att visa samtliga positioner samtidigt. K.IF.K.15 Kartan ska vara läsbar för användare med små skärmar. Skall X X Bör Bör Bör Bör E2

126 Bilaga E. Krav E.4. Program E.4 Program Kravnummer Prioritering Implementerat Testat K.F.P.1 Det ska gå att se information om föreläsningar. K.F.P.2 Det ska gå att se information om utställningar. K.F.P.3 Det ska gå att se blockschemat. K.F.P.4 Användare ska kunna se sitt personliga program. K.F.P.5 Det ska gå att ladda upp programinformation som administratör. K.F.P.6 Det ska gå att ändra om föreläsningar är inställda eller ej som administratör. K.F.P.7 Det ska gå att ändra om utställningar är inställda eller ej som administratör. K.F.P.8 Det ska gå att ändra föreläsningssal som administratör. Skall Skall Skall Bör Bör Bör Bör Bör E.5 Information Kravnummer Prioritering Implementerat Testat K.F.I.1 Det ska gå att läsa allmän information. Skall X X K.F.I.2 Det ska gå att se dagens lunch. Bör E.6 Tillgänglighet Kravnummer Prioritering Implementerat Testat K.IF.T.1 Det ska gå att använda tjänsten före konferensdagarna. Bör X K.IF.T.2 Det ska gå att använda tjänsten under konferensdagarna. Skall X K.IF.T.3 Tjänsten ska finnas tillgänglig på Svenska. Skall X X Kopplingen mellan kraven ställda på tjänsten och användarfallen i bilaga D beskrivs i tabell E.1. E3

127 Bilaga E. Krav E.6. Tillgänglighet Tabell E.1: Spårbarhetsmatris över kraven mot användarfall. Användarfall Krav 1 Krav 2 Krav 3 ANV.1 K.F.N.2 ANV.2 K.F.N.1 ANV.3 K.F.N.5 ANV.4 K.F.N.3 ANV.5 K.F.N.4 ANV.6 K.F.K.1 K.F.K.4 ANV.7 K.F.K.1 K.F.K.6 ANV.8 K.F.K.1 K.F.K.8 ANV.9 K.F.K.1 K.F.K.7 ANV.10 K.F.K.1 K.F.K.3 ANV.11 K.F.K.1 K.F.K.13 ANV.12 K.F.K.1 K.F.K.12 ANV.13 K.F.K.1 K.F.K.10 ANV.14 K.F.K.1 K.F.K.11 ANV.15 K.F.K.1 K.F.K.2 ANV.16 K.F.K.1 K.F.K.9 ANV.17 K.F.K.1 K.F.K.3 ANV.18 K.F.P.3 K.F.P.1 K.F.P.2 ANV.19 K.F.P.8 ANV.20 K.F.P.6 ANV.21 K.F.P.7 ANV.22 K.F.G.3 ANV.23 K.F.I.2 ANV.24 K.F.P.4 K.F.G.5 ANV.25 K.F.P.5 ANV.26 K.F.I.1 E4

128 Bilaga F. ER-diagram över databas Bilaga F ER-diagram över databas Orginalbilden finns att nå via denna länk: png. F1

129 Bilaga F. ER-diagram över databas Figur F.1: ER-diagram över databasen. F2

130 Bilaga G. Schema över databas Bilaga G Schema över databas Orginalbilden finns att nå via denna länk: png. G1

131 Bilaga G. Schema över databas Figur G.1: Schema över databasen. G2