Programutvecklingsprojekt 2003-04-24 Projektgrupp Elvin Detailed Design Document Björn Engdahl Fredrik Dahlström Mats Eriksson Staffan Friberg Thomas Glod Tom Eriksson engdahl@kth.se fd@kth.se d94-mae@nada.kth.se sfriberg@kth.se glod@kth.se tome@kth.se
1 Introduktion 1.1 Syfte Syftet med detta dokument DDD, Detailed Design Document, är att beskriva de olika komponenterna som existerar i Elvin klienten. 1.2 Mjukvarans omfattning Mjukvaran skall möjliggöra kommunikation med Elvin-meddelanden från och till en mobiltelefon av modell Sony-Ericsson P800/802. Elvin är ett system för meddelandehantering som skiljer sig från vanliga meddelandetjänster. Istället för att ett meddelande skickas specifikt mellan två applikationer som är fallet i vanliga meddelandesystem, så styrs meddelandedirigeringen i Elvinsystemet helt och hållet av innehållet i de specifika meddelanden som skickas. 1.3 Definitioner, akronymer och förkortningar API, Application Programming Interface GPRS, General Packet Radio System HTTP, Hypertext Transfer Protocol SDK, Software Development Kit TICKERTAPE, En speciell typ av Elvin-meddelanden avsedd för chatt och nyheter Sony-Ericsson P800/802, En mobiltelefon med handdatorfunktioner C++, Ett vanligt förekommande högnivåprogrammeringsspråk Java, Ett vanligt förekommande plattformsoberoende högnivåprogrammeringsspråk Elvin-klient, Den programvara som en vanlig användare använder för att få tillgång till Elvinmeddelanden 1.4 Referenser Projektets hemsida: http://www.nada.kth.se/projects/proj03/elvin/ Elvin huvudsida: http://elvin.dstc.edu.au/ Elvin klient-api: http://elvin.dstc.edu.au/doc/apis.html Elvin Subscription Language: http://elvin.dstc.com/doc/esl4.html Tickertape standarder: http://elvin.dstc.com/projects/tickertape/doc/index.html Sony-Ericsson P800/802: http://www.sonyericsson.com/ Elvins Java API JE4: http://elvin.dstc.edu.au/projects/je4/index.html PSS05: ESA Software Engineering Standards 1.5 Översikt av dokumentet Avsnitt två i dokumentet beskriver vilka standarder och konventioner som har använts i projektet. Del tre i dokumentet består av detaljerad information om de olika komponenterna Elvinklienten är uppbyggd av.
2 Standarder 2.1 Designstandard För att på ett tidigt stadium bestämma vilka moduler som skulle ingå i klienten användes UML. Detta gjorde det enkelt att se vilka moduler som behövdes och vilken funktionalitet dessa skulle innehålla. UML diagrammet visar även vilka moduler som kommer att kommunicera med varandra och underlättar bygga bra gränssnitt mellan dessa moduler. För det grafiskagränssnittet i mobilen används ett designmönstret Model-View-Controller (MVC) som ofta används för att skilja på olika logiska lager i en grafisk applikation. 2.2 Dokumentationsstandard Dokumentationen i projektet följer PSS05 utvecklad av ESA. Flera av de dokument som beskrivs i PSS05 existerar och har använts under utveckling av klienten, även detta dokument är en del av denna standard. I koden används JavaDoc kommenterar för att beskriva olika metoders funktionalitet och användningsområde. Dessa kan lätta extraheras och användas för att åskådliggöra gränssnitten till de olika modulerna i klienten. Vedertagna kommentarer av koden har använts där det har varit nödvändigt med förtydliganden. 2.3 Programmeringsstandard Programkoden följer normal kodstandard för Java. För att skilja modulerna från varandra har dessa placerats i olika paket för att hållas så åtskilda som möjligt. 2.4 Mjukvaruutvecklingsmiljöer Utveckling har skett i SonyEricssons SDK för Symbian v7. Denna används för att kompilera koden för Symbian v7. SDK möjliggör dessutom att enklare testa och söka fel i applikation då allt arbete kan ske på en dator utan tillgång till mobiltelefon.
3 Systemskiss Figur 1. Förenklad skiss över kommunikationen mellan applikationen och en Elvind server 3.1 Backend ElvinBackend (EB) är vår inkapsling av all kommunikation till och från en Elvinservern. EB ansluter till en specificerad Elvinserver och börjar prenumerera på den information användaren har bestämt. Det finns möjligheter att enkelt koppla upp och ner förbindelsen till server samt att ändra vilken information som ska prenumereras på. Figur 1 ovan illustrerar hur applikationen kommunicerar med servern via en GPRS länk. Användaren av modulen kan registrera lyssnare till modulen som får information från EB när exempelvis ett nytt meddelande har kommit. Lyssnarna får även information när något går fel. Exempelvis om förbindelsen till server går ner eller ett meddelande misslyckas att skickas. När ett nytt meddelande kommer får alla lyssnare till EB detta meddelande tillsammans med notifikationen. Det är sedan upp till klienten att extrahera informationen ur meddelandet och
tolka det efter sin meddelande standard. ER skickar endast vidare meddelandet som det kom in från servern utan att påverka det något. För att skicka ett meddelande krävs att EB först är uppkopplade mot en server. Därefter kan användaren ge EB meddelande som skall skickas och EB ser till att meddelandet skickas till servern. Om fel uppstår kommer detta meddelas. Figur 2. Översikt av applikationens huvudkomponenter 3.2 GUI Controller Controllern är den komponent som hanterar all kommunikation mellan de övriga delarna av applikationen, se figur 2. Genom att lyssna på händelser hos ElvinBackend kan controllern uppdatera modellen om ett nytt meddelande tas emot. På samma sätt lyssnar controllern på förändringar hos modellen för att uppdatera den vy som visar modellens innehåll. När en användaren via ett GUI ger ett kommando är det controllerns uppgift att anropa rätt metod hos rätt komponent. Om användaren till exempel tar bort ett meddelande i MessageList vyn så är det controllern som uppdaterar listans modell TickerTapeMessageList. Controllern hanterar även de fel som kan uppstå hos ElvinBackend. Det till exempel vara problem med uppkopplingen mot Internet som medför att det inte går att skicka eller ta emot meddelanden. 3.3 GUI Model Meddelandelistan Varje meddelande är i grunden ett ElvinMessage, detta betyder att applikationen inte är låst vid en specifik meddelandetyp utan klarar i teorin av att hantera alla typer av Elvinmeddelanden.
Applikationen är i dagsläget dock implementerad för att i första hand fungera med en speciell typ av Elvinmeddelande, TickerTapeMessage som ärver från ElvinMessage. Ett tickertapemeddelande har vissa speciella fält, till exempel meddelandeid och avsändare. Dessa fält sparas i tickertapemeddeladet som TypedTuples. Dessa TypedTuples består av namnet på fältet, dess värde och dess typ. Alla meddelanden som tas emot av applikationen sparas i en meddelandelista, som är implementerad som en vektor. Så fort man lägger till ett nytt meddelande eller tar bort ett meddelande i listan sparas hela listan till en fil som är uppbyggd i ett XML-format. När man startar applikationen läses denna fil in igen. Varje gång det sker en ändring i listan skickas det ut en händelse så att berörda delar av applikationen, t.ex. vyn, får reda på vad som har hänt. Nytt meddelande Denna del av applikationen hanterar inmatning av ett nytt meddelande. Enligt Model/View/Controller så skapas en modell som representerar ett nytt elvin-meddelande, som tex meddelandetext, andvändarnamn, grupp som meddelandet skall skickas till och eventuell information om vilket meddelande detta är ett svar till. En vy som lyssnar på förändringar i modellen skapas också och denna visar och möjliggör förändringar i modellen. Eftersom applikationer kan stängas ner automatiskt i Symbian 7 när systemet behöver frigöra resurser så sparas modellens information på disk när detta händer. När applikationen sedan startas läses denna information in och användaren upplever det då som om applikationen aldrig stängts ner. 3.4 GUI View Samtliga vyer i applikationen ärver av den abstrakta klassen ElvinView, som innehåller tre metoder update, save och modelchanged. Tanken är att ElvinView-instanser kan prenumerera på händelser av typen ModelChangedEvent hos de modeller som vyerna är bundna till. På så sätt kan modellerna meddela vyerna att data har förändrats utan att binda modell och vy till varandra. De vyer som önskar utnyttja denna arkitektur ska se till att registrera sig som ModelListener hos modellen. En alternativ metod som controllern kan utnyttja är att anropa update-metoden hos vyn. Denna anropas när användaren byter vy i applikationen, och tvingar vyn att rita om sig. Save-metoden används då applikationen stänger ner sig, och sparar innehållet i vyn. Meddelandelistan Meddelandevyn är uppbyggd av en grafisk lista där samtliga Elvin-meddelanden listas. Vyn är bunden till modellen genom att prenumerera på ModelChanged-händelser. När en sådan händelse inträffar rensas listan och den nya meddelandelistan ritas upp. Save-metoden utnyttjas inte för meddelandelistan, eftersom modellen alltid sparar den aktuella listan på text-fil. Meddelandevyn Denna vy visar ett elvin-meddelande på skärmen och presenterar knappar för att stänga meddelande eller svara på detta. 3.5 Preferences Preferences är den del av modellen som sköter inställningarna som användaren kan göra i inställningsvyn. Dess huvuduppgift är att läsa in och spara ut inställningarna på fil, ta emot nya förändringar i inställningarna från controllern och meddela de delar av vyn som behöver uppdatera sig när inställningarna ändras.
Controllern är den del av applikationen som skapar Preferences-objektet och anropar dess metoder. Preferences laddar inte in inställningarna automatiskt från disk för att vyerna, som eventuellt inte är skapade vid den tidpunkten, ska ha en chans att kunna ta emot meddelandet om förändringen som sker när inställningarna förändras. Metoder för att spara inställningarna till fil och att läsa in dem från fil är publika. Det finns även metoder för att hämta varje inställning separat om någon del av programmet behöver det. På samma sätt finns motsvarande funktioner för att ändra varje del av inställningarna. Det finns metoder för att ett objekt ska kunna lägga till och ta bort sig som lyssnare på förändringar i denna del av modellen. Så fort någon del av inställningarna förändrats meddelar Preferences alla objekt som är inlagda som lyssnare det med ett ModelEvent. Detta ModelEvent innehåller det PreferencesState som kapslar in värdena på inställningarna. 3.6 PreferencesState PreferencesState är ett objekt som kapslar in värdet för de inställningar som kan göras i inställningsvyn för programmet. Objektets variabler är publika och har ingen metoder för åtkomst och förändring, utan refereras direkt. Både Preferences och PreferencesView har egna instanser av detta objekt. Detta för att inställningarna inte ska sparas förrän användaren verkligen trycker på OK-knappen i inställningsvyn. 3.7 PreferencesView PreferencesView är den del av vyn som har hand om inställningarna för programmet. Vyn ritar ut fält för att fylla i användarnamn, serveradress, lägga till/ta bort grupper och ställa in hur många meddelanden som ska få plats i listan över inkomna meddelanden. PreferencesView skapas från controllern, som också lägger till PreferencesView som lyssnare på förändringar i Preferences-modellen. Vid initieringen av objektet är samtliga fält tomma. För att användarens sparade inställningar ska synas i fälten måste PreferencesView först läggas till som lyssnare till Preferences-modellen innan inställningarna kan laddas från fil. Metoder för att controllern ska kunna lägga till sig själv som lyssnare på vyns knappar finns, och även en metod för att controllern ska kunna hämta de inställningar som har fyllts i. Det senare används när användaren trycker på OK-knappen. Dessa inställningar skickas då till Preferences-objektet som i sin tur uppdaterar och sparar inställningarna.