Systembeskrivning Tjoho Maj 2003

Transkript

1 Systembeskrivning Tjoho Maj 2003 Uppdragsgivare: Ylva Dalén, KI Starthus Projektmedlemmar: Sophia Demnert, Elina Eriksson, Kamilla Johansson Per-Jonny Käck, Ingela Linered, Åsa Moum, Michael Stockman, Stefan Trolle

2 Innehåll Bakgrund... 2 Designmål... 2 Oberoende... 2 Händelsebaserat... 2 Användarvänlighet... 3 Loggmöjligheter... 3 Utvecklingsbarhet... 3 Applikationsvision... 3 Moduler... 4 Huvudmodulen crm... 5 crmsrv... 5 CRMServer... 5 Meddelanden... 5 Trådar... 5 configuration... 6 ConfigurationManager... 6 Configuration... 7 jcapi... 7 JCManager... 7 Trådar... 7 tracking... 8 Klientmodulen, crmclient... 8 Trådar... 8 Meddelanden... 9 Plattformssimulatorn, pfsim Anpassa simulatorn till framtida prototyper Ändra plattformsegenskaper Ändra knappsatsen Funktionalitet som saknas på nuvarande plattform Vibrationer Hopp Lutning i sidled Idéer för vidareutveckling Grafisk konfiguration Fler klientbibliotek

3 Bakgrund Huvudmålet för producerandet av vår programvara var att tillhandahålla roliga och stimulerande applikationer för handikappade barn, som kan kommunicera med en kommande version av plattformen HoppOLek. För att uppnå att applikationerna blir roliga och stimulerande, krävs att de testas och vidareutvecklas i ett nära samarbete med barnen och vuxna i deras omgivning. Då vi inte har haft möjlighet till ett sådant samarbete, har vi istället fokuserat oss på att förenkla skrivandet av nya applikationer så långt det är möjligt, och denna tanke kommer igen i våra designmål. Designmål Designmålen är de riktlinjer som vi försökt följa under utvecklingen av systemet Tjoho och då främst under designfasen. Oberoende Systemet skall fungera oberoende av vilka applikationer som körs. Antalet applikationer skall inte påverka möjligheterna till funktionalitet hos systemet. Applikationer skall kunna läggas till och tas bort från systemet utan att det påverkar funktionaliteten. Systemet skall kunna användas mot den existerande plattformen, den kommande plattformen Tjoho samt vilken annan plattform som kan komma att användas i framtiden. Kommunikation med systemets serverdel skall ske via specificerade XMLmeddelanden över TCP/IP(se bilaga tjohoxml). Systemet blir på detta sätt oberoende genom att det kommer att fungera på samma sätt oavsett vilken utvecklingsmiljö som väljs för applikationer. Det enda kravet som finns på utvecklingsmiljön är att stöd för kommunikation via TCP/IP ska vara möjligt. Kommunikation via XML gör det bland annat möjligt att programmera applikationer i andra programmeringsspråk än JAVA. Händelsebaserat Systemet skall vara händelsebaserat. Att systemet till största delen är uppbyggt av händelsebaserade rutiner gör det enkelt att programmera och eventuellt modifiera systemet i framtiden. Att systemet är händelsebaserat gör det ganska 2

4 resurseffektivt, samt att det passar bra ihop med händelsebaserade fönstersystem. Användarvänlighet Systemet bör kunna användas av ovana användare utan att fel uppstår. Plattformen ska styras av ett konfigurationsnät och det ska inte finnas någon begränsning på hur man ska kunna styra plattformen. För att underlätta för användaren ska en bra konfiguration skapas automatiskt med hjälp av tips (hintar) som ska finnas hos plattform och applikationer. Den applikation som blir ansluten sist är den som ska få högst prioritet. Loggmöjligheter Det ska finnas en möjlighet i systemet att spara information om hur plattformen har använts av olika användare (barn). För att underlätta att man inte loggar fel händelser till fel användare kan man inte använda sig av systemet utan att en aktiv användare har valts. Utvecklingsbarhet Det ska vara möjligt att på ett enkelt sätt utveckla applikationer som kan köras mot plattformen via systemet. Detta ska göras möjligt genom att ett klientbibliotek i programmeringsspråket JAVA ska finnas. Även utveckling av applikationer i andra programmeringsspråk än JAVA ska vara möjligt, genom att all kommunikation med servern sker via specificerad XML (se bilaga tjohoxml). Det ska också vara möjligt att utveckla systemet i framtiden och detta ska underlättas av god dokumentation samt kommentering av koden i form av javadoc. Applikationsvision Beskrivning om hur en applikation optimalt skulle utnyttja den funktionalitet som systemet erbjuder. Visionen är att det i systemet ska vara möjligt att kombinera enkla (med avseende på hanteringen av plattformen) applikationer till ett varierande och utmanande system för användaren. För att uppmuntra en sådan utveckling är systemet utvecklat för att transparent hantera interaktionen mellan samtidiga applikationer och den anslutna plattformen. Systemet avser alltså att förenkla applikationsutveckling mot liknande plattformar men även att erbjuda mervärdet att en applikation kan samverka i system med flera applikationer. Detta bör vara vägande skäl vid framtida val av utvecklingsmiljö för applikationer mot sådana plattformar. Hur skulle då en applikation fungera? När en applikation startas av 3

5 en användare, försöker applikationen ansluta sig till en server med hjälp av klientbiblioteket. När den har lyckats med detta använder den sig av det grafiska gränssnitt för login som finns i klientbiblioteket, för att användaren ska kunna välja svårighetsgrad med mera. Därefter registrerar applikationen de signaler och funktioner som applikationen har, samt de tips (hint) som applikationen vill använda för att bygga konfigurationsnätet. När all registrering är utförd börjar applikationens egentliga huvudsyfte, att köra det program som ska göra barnets användning av plattformen till en njutningsfull upplevelse. När användaren känner sig färdig avslutar användaren körningen av applikationen och därmed avregistrerar applikationen sina signaler och funktioner från servern. På detta sätt kan systemet fortsätta att köras utan just denna applikation. Moduler Övergripande beskrivning av systemet vi har skapat. Detaljerad information finns i form av javadoc. Med anledning av våra designmål har vi valt att dela upp programvaran i moduler, först i tre stycken övergripande moduler: - crm (Communication and Resource Manager), är den centrala modulen som sköter koordineringen mellan plattform och olika applikationer. - crmclient, är en modul som ger ett enkelt gränssnitt för applikationer och virtuella plattformar (exempelvis simulatorn) gentemot modulen crm. - pfsim, är en plattformssimulator som utvecklats för att underlätta testning vid applikationsutveckling. Simulatorn är ett grafiskt gränssnitt som visualiserar plattformens nuvarande läge och kan simulera samma knapptryckningar som kan utföras på HoppOLekplattformen. Se tjohouml, bilaga 1, Allmän bild av systemet. Utöver de tre ovan nämnda modulerna tillkommer en modul pc/ms som består av alla existerande och kommande applikationer som skrivs till vår programvara. Således är denna modul alltså inte någon modul i vanlig mening, och kommer därför ej att behandlas särskilt ingående. Dock beskrivs hur det är tänkt att applikationer ska kommunicera med crm via crmclient. Detta för att ge en bättre bild av hur systemets delar hänger ihop. Som redan nämnts i designmålen sker all kommunikation med crm-modulen via specificerade XML-meddelanden över TCP/IP. För information om dessa XML-kommandon se bilagan tjohoxml. 4

6 Huvudmodulen crm Huvudmodulen crm består i sin tur av fyra mindre moduler som alla ansvarar för ett begränsat område Se tjohouml, bilaga 2, Allmän bild av crm. crmsrv crmsrv är en kommunikationsmodul som kommunicerar med en plattform och publicerar dess funktioner som tjänster till applikationer. Exempel på tjänster är möjligheten att styra plattformen, eller möjligheten att bli meddelad när något intressant på plattformen inträffat. crmsrv erbjuder alltså ett gränssnitt för kommunikation med en plattform, och sköter denna uppgift genom att hantera näthändelser, som består av meddelanden mellan applikation och plattform. CRMServer Servern är skapad enligt designmönstret Singleton. Det ska alltså bara finnas en server som alla klienter kopplar upp sig mot. Servern kan lägga till lyssnare till sig och håller reda på de klienter som har registrerat sig. Klienterna består av både applikationer och plattform. Ska detta inte vara med? Är det inte sant? Vad menar Micke? Eller ska det stå högre upp i dokumentationen att systemet är byggt för kommunikation med en plattform åt gången? Meddelanden Alla klienter har en egen associerad socket via vilken de skickar sina meddelanden till servern på porten som används. Servern skickar sina meddelanden till varje klient via klientens associerade socket. Klienten får dock bara meddelanden om de händelser som klienten verkligen är intresserad av. Vilka händelser som klienten är intresserad av registreras via de hintar som klienten har registrerat. Se tjohouml, bilaga 5, Diagram över crmsrv. Trådar CRMServer körs på en tråd. Det är via denna tråd som CRMServer skapas och det är också via denna tråd som klienter kan ansluta sig. Det är även via denna tråd som CRMClient-objekten läser de XML-kommandon som skickas till servern och genererar sedan händelser utifrån meddelandena. Dessa händelser skickas sen till CRMServer som i sin tur skickar dem till de olika CRMClient-objekten via signaler till tråden AWT-EventQueue-0. När CRMServer-tråden använder sig av tråden AWT-EventQueue-0 lägger den sig och sover tills hanteringen av det 5

7 event som skickades till AWT-EventQueue-0 är klar. Orsaken till detta är att CRMServer vill vara säker på att meddelanden från klienterna hela tiden hanteras i sekventiell ordning. Se bilaga Diagram CRM tråd. configuration Konfigurationen består av många klasser som gemensamt håller reda på användare, signaler och operationer. Det går att göra sig en mental bild av vad den viktigaste funktionen i configuration är. Denna mentala bild benämns som konfigurationsnät och är den del som vidarebefordrar och eventuellt påverkar signalerna mellan applikationerna och plattformen. Konfigurationsnätet kan ses som ett kopplingsnät mellan plattform och applikationer i vilket det finns enkla ledningar för signalerna samt även operationer. Operationerna kan på olika sätt förändra signalerna. Eftersom de flesta applikationer kommer att använda samma logik vid hantering av signaler kan den logiken delas och finns då i konfigurationsnätet. Likaså kan plattformen då den används utan applikation använda sig av samma logik. Logiken utgörs av operationer som till exempel gör det enkelt att förändra plattformens beteende beroende på svårighetsgrad. Även funktionalitet som att en viss funktion på plattformen ska ske under en viss tidsperiod eller dylikt kan hanteras av operationerna. Framför allt är det fördelaktigt att placera logiken i konfigurationsnätet om man i framtiden vill ha en möjlighet att via ett grafiskt gränssnitt hantera konfigurationsnätet. Förutom logiken är konfigurationsnätet även bra då den gör kopplingen mellan plattform och applikation mer dynamisk. När en applikation läggs till eller tas bort gör konfigurationsnätet det enklare att enkelt koppla om signalerna så att systemet fortfarande fungerar optimalt. Se tjohouml, bilaga 4, Diagram över configuration. ConfigurationManager ConfigurationManager är den klass till vilken applikation och plattform registrerar sina kända signaler. Håller reda på registrerade användare samt det konfigurationsnät som används. Varje gång en hint eller känd signal läggs till eller tas bort uppdateras konfigurationsnätet. Detsamma sker varje gång en användare väljs som aktiv användare. Är designad enligt designmönstret Singleton, det ska alltså bara finns bara en enda ConfigurationManager. 6

8 Configuration Configuration är en klass som fungerar som en sammanbindande länk mellan konfigurationsnätets alla olika delar. Klassen innehåller ett antal konfigurationselement (ConfigurationElement) som i sin tur är antingen noder eller kanter. Noderna kan vara signaler som kommer in till, eller går ut ur, nätet. Noderna kan även vara operationer som på olika sätt kan påverka signalerna i nätet. Konfigurationsnätet byggs utifrån kända signaler, användarens svårighetsgrad och de hintar som applikation och plattform har skickat in till ConfigurationManager. Den applikation som har registrerat sina hintar sist är den som har högst prioritet. Plattformen har lägst prioritet oavsett när den ansluts. Hintarna består av beskrivningar av objekt (ObjectDescription) som kan vara signaler eller operationer samt kanter (LinkDescription) mellan objekten. Se tjohouml, bilaga 10, Diagram över crmclient/hint. jcapi Eftersom det kommer att finnas olika versioner av plattformar existerar det virtuella plattformar, så kallade plattformshanterare, som ska förenkla kommunikationen med de verkliga plattformarna. Det är bara en enda plattform åt gången som kan köras mot crmsrv. jcapi (Java Communications API) kommunicerar med plattformen via javax.comm. jcapi har två huvuduppgifter. Den ena är att omvandla data från en plattformshanterare till händelser som sedan skickas via konfigurationsnätet till crmsrv. Den andra huvuduppgiften är att omvänt omvandla styrkommandon från crmsrv till plattformsformat, och sedan skicka dessa vidare till plattformshanteraren. Se tjohouml, bilaga 6, Diagram över jcapi. JCManager Huvudklassen i jcapi är JCManager, och det är denna klass som hanterar händelser från plattformshanteraren samt meddelar plattformshanteraren när något har hänt i konfigurationsnätet. Förutom att meddela servern om händelser på plattformen skickar JCManager också meddelanden till LogManager som loggar de funktioner som användaren utnyttjar på plattformen. Trådar JCManager körs på en egen tråd men skickar dessutom signaler till tråden AWT- EventQueue-0 för att meddela crmsrv om att något inträffat på plattformen. Till skillnad från CRMServer anropas här tråden i AWT-EventQueue-0 med 7

9 invokelater-metoden, vilket innebär att JCManager-tråden inte väntar på att koden i AWT-EventQueue-0 ska exekvera klart. Orsaken till detta är att uppgiften för JCManager endast är att meddela crmsrv om alla händelser på plattformen, och för denna uppgift behöver JCManager inte ta något ansvar för i vilken ordning händelserna ska processas. Se bilaga Diagram JCManager tråd. tracking tracking är den del av systemet som innehåller den funktionalitet som gör det möjligt att logga användarens utnyttjande av plattformen. Huvudsakliga klassen är LogManager och det är LogManager som sparar ner användarens logg i en fil i den hemkatalog som valdes vid skapandet av en ny användare. Klientmodulen, crmclient Klientmodulen kan sägas bestå av två olika delar. Dels ett gränssnitt för applikationer mot crmsrv och dels ett gränssnitt för virtuella plattformar mot crmsrv. Gränssnittet för applikationer är det centrala i modulen, medan gränssnittet för virtuella plattformar är avsett för simuleringsmodulen och är främst användbar vid applikations- eller systemutveckling i testsyfte. Se tjohouml, bilaga 8, Diagram över crmclient. CRMClient, En Singleton-klass som erbjuder ett fullständigt gränssnitt för kommunikation med en CRMServer för en applikation eller för en virtuell plattform. DataHandler, En hjälpklass till CRMClient som är implementerad som en egen tråd. Ansvarar för att lyssna på den Socket som CRMClient är ansluten till, och meddela CRMClient när ett korrekt XML-meddelande mottagits. Trådar I de fall instansen av CRMClient är ansluten till crmsrv exekveras modulen DataHandler på en egen tråd. Denna tråd ligger hela tiden och lyssnar på en socket och väntar på att data ska anlända till servern. När data anländer försöker DataHandler tolka dessa data som ett giltigt XML-meddelande. Metoderna som anropas i CRMClient exekveras på den tråd från vilken anropet skedde, oftast applikationens main-tråd eller i fallet med grafiska applikationer i JAVA, tråden AWT-EventQueue-0. AWT-EventQueue-0 används även vid behov av DataHandler-tråden för att meddela en applikation om att någon händelse som den är intresserad av har inträffat. 8

10 Meddelanden De flesta meddelanden till servern skickas utan att vänta på något svar. Vissa meddelanden är dock av typen att de begär information från servern, och dessa kräver uppenbarligen ett svar. Detta sker genom att applikationen anropar rätt metod i CRMClient för sin begäran, och denna metod skickar en begäran till servern. Sedan lägger sig denna tråd (applikationstråden) och sover en viss tid. Om DataHandler-tråden under denna tid tar emot svaret från servern, så lagras detta svar undan och applikationstråden som befinner sig i en metod i CRMClient väcks av då av ett avbrott. CRMClient returnerar sedan det undanlagrade svaret tillbaka till applikationen. Om applikationstråden vaknar av sig själv i CRMClient (alltså ej genom ett avbrott) kollar den om ett svar finns undanlagrat och returnerar i så fall detta svar, annars returneras null som indikation på att inget svar från servern erhölls inom rimlig tid. Hela begäran-svar-proceduren döljs alltså för applikationen med undantag för returneringen av null om ingen information kunde erhållas. Om ett giltigt meddelande från servern mottages av DataHandler, så informeras applikationen om detta på olika sätt beroende på typen på meddelandet: Om meddelandet är ett signalkommando så innebär det att en händelse som ändrar värdet på någon av applikationens insignaler har inträffat på plattformen, och i så fall informeras (via tråden AWT-EventQueue-0) alla signallyssnare till den berörda signalen om det ändrade värdet. Om meddelandet är ett administrationskommando eller ett serieportskommando, är det ett svar på ett meddelande från klientmodulen, och i så fall meddelas applikationen genom ett vanligt return från den anropade metoden i CRMClient. Om meddelandet är ett plattformskommando, så meddelas alla plattformslyssnare (via tråden AWT-EventQueue-0) till klientobjektet. 9

11 Plattformssimulatorn, pfsim Plattformssimulatorns main()-funktion är placerad i PfSim i paketet se.kth.nada.tjoho.pfsim. Vid programstart försöker simulatorn skapa en anslutning till servern genom anropet CRMClient.getInstance(). Om anslutningen lyckas fortsätter applikationen att köra. Applikationen är uppbyggd av en mängd grafikelement där SimFrame är huvudfönstret. I SimFrame finns tre olika fönsterdelar; ControlJPanel som visualiserar plattformens knappsats, StatusJPanel som ritar ut fyra stycken tidsgrafer (TimeGraph) och StimulatorViz som ritar ut en bild av plattformen. Klassen som styr hur utseendet på dessa förändras är SimFrame ControlJPanel StatusJPanel TimeGraph TimeGraph StimulatorViz UpdateThread, som uppdaterar plattformens status, och om nödvändigt ritar om grafer och StimulatorViz var 0,08:e sekund. UpdateThread tar in information om nya händelser genom att metoderna newxinput( ) anropas, där X är typen av händelse till exempel Height. Anropen sker genom en PlatformListener i SimFrame. Anpassa simulatorn till framtida prototyper Då HoppOLek endast är en prototyp som planeras ersättas med en ny prototyp med andra egenskaper, har en av de viktigaste delarna i utvecklingen av simulatorn varit att lätt kunna uppdatera den för att passa framtida plattformar. I simulatorn finns stöd för funktioner som inte finns i nuvarande versionen av HoppOLek, men som antagligen kommer att finnas i nästa prototyp. Bland dessa funktioner ses bland annat vridning och lutning. Man kan även lätt göra så att simulatorn rör sig i mjuka funktionskurvor istället som nu i linjära funktioner. Plattformen rör sig med andra ord i nuläget med oändlig acceleration vid speciella tidpunkter, för att därefter följa den maximala förändringshastigheten. 10

12 Ändra plattformsegenskaper Endast ett fåtal konstanter behöver ändras för att anpassa simulatorn till en ny plattform, nämligen UpdateThread.java. Rad 12 till rad 50 innehåller konstanter som definierar olika maxhastigheter, accelerationer och gränslägen för plattformen. Då dessa ändras kommer alla delar i programmet som beror av dessa också att ändras, till exempel förändringsgrafernas skalor och utritningen av plattformen. Vill man ändra de olika förändringsfunktionerna för att skapa mjuka accelerationer ska f-funktionerna i rad skrivas om. För att skriva dessa kan man ta hjälp av variablerna double xcurrentspeed (nuvarande hastighet), double xstartspeed (hastigheten då förändringen skulle inledas) och double xt (hur lång tid förändringen pågått). x ska ersättas av h för höjd, l för lutning eller t för vridning. Ändra knappsatsen För att ändra knappsatsen ska ControlJPanel.java ändras. CRM servern stöder för till fället nio stycken knappar, vilket är antalet som krävs för att kunna styra alla funktioner som simulatorn stöder. Dessa knappar är definierade i ControlJPanel.java, och behöver inte ändras. Det som man istället kan ändra är hur knapparna är placerade på plattformen. I simulatorn är knapparna placerade på enklast möjliga sätt, i två centrerade rader, men detta kan givetvis ändras. Om färre knappar än nio finns på den nya prototypen är det mest praktiskt att kommentera bort de sista överflödiga knapparna, då dessa kan komma att behövas till ytterligare senare prototyper. Funktionalitet som saknas på nuvarande plattform Det finns många funktioner som systemet har men som inte kan visas på den nuvarande plattformen. Dock ska det fungera för den kommande plattformen Tjoho. Vibrationer På den nuvarande plattformen kan man inte styra plattformens vibrationer. Det kommer dock att kunna göras på den kommande plattformen. I konfigurationsdelen av systemet finns operationer som kan omvandla insignaler i form av t ex knapptryckningar till ökning respektive minskning av vibrationen. 11

13 Hopp På den nuvarande plattformen finns endast stöd för att åka upp och ner. Något stöd för den i systemet implementerade hoppsignalen finns inte. Denna funktion är dock planerad att finnas på nästa version av plattformen. Lutning i sidled Den kommande plattformen Tjoho, kommer att ha en funktion som gör att plattformen kan luta i sidled. Den XML som behövs för att styra denna funktion finns och systemet kan redan använda sig av denna XML. Idéer för vidareutveckling Här under kommer vi att beskriva de funktionaliteter vi tänkt på kring det system vi byggt men inte implementerat. Kan ses som möjligheter för vidareutveckling. Grafisk konfiguration En möjlighet att via ett grafiskt gränssnitt direkt ändra i konfigurationen av systemet. Passar kanske en mer van användare. Det finns goda möjligheter att bygga ut systemet med denna funktionalitet. Stöd finns redan i form av specificerad XML (se bilaga tjohoxml). I och med att man går in och ändrar konfigurationen bör det också finnas en möjlighet att spara konfigurationerna. Det ska också vara enkelt att ladda in en gammal konfiguration så att man inte behöver ändra en automatisk genererad konfiguration varje gång användaren vill använda en viss konfiguration till en viss applikation. Fler klientbibliotek Så som systemet ser ut nu finns det endast ett klientbibliotek skrivet i JAVA. Genom att systemet kommunicerar med XML över TCP/IP är det dock oberoende av vilken miljö applikationerna är skrivna i och körs i. Det är således önskvärt att nya klientbibliotek skrivs för andra programmeringsspråk som applikationer kan önskas skrivas i. 12

14 Bilaga Diagram JCManager tråd 13

15 Bilaga Diagram CRM tråd 14