1. Forord... vii. 2. Resume Introduktion Pallas Informatik A/S Udvikling af et Infotainment system...

Transkript

1 i

2 Indholdsfortegnelse 1. Forord... vii 2. Resume Introduktion Pallas Informatik A/S Udvikling af et Infotainment system Motivation Projektet Indledning Formål Infotainment Navigator Navigations Editor Omfang Begrænsninger Akronymer og forkortelser Interesser og slutbrugere Planlægning Unified Process Software modeller Unified Modeling Language: UML Use-Cases Milepæle Iterationer Kravspecifikation ii

3 5.1. Indledning Krav til læseren Funktionelle krav Kommunikation til andre programmer Indhold Kontrol Editor Prioritering af funktionelle krav Ikke Funktionelle Krav Brugervenlighed Pålidelighed Kapacitet Vedligeholdelse Dokumentation Succes kriterier Teknologier ActionScript 3.0 og flash platformen Flex Frameworket Parts Flex Komponenter Adobe Integrated Runtime (AIR) Windows XP Embedded Webservices Socket Connections Datalager Design patterns iii

4 7. Analyse Automatisk sideopdatering Viewstacks Viewstacks med Database Backend Modularisering Moduler med Viewstacks Konklusion Kommunikation Socket Kommunikation Webservices Konklusion Database Editerbare moduler MXML Code-Behind Konklusion Use Cases og aktører Identifikation af aktører Use Cases Design Database Design Normalform Modulariseret opbygning Alon Design pattern Intern Kommunikation Event Baseret kommunikation iv

5 8.3.2 Direkte Kommunikation Event Data Webservice modulet Design venlig Klassediagram Implementation Autonomous Linking Object Network Design Pattern Controller Modulet Webservice modulet Opdatering af indhold Modularisering Test Test Systemet Test af usecases Opdatering af indhold Vis seks film Modulariseret opbygning Kapacitets test Formål Test Strategi Test Forløb Resultat Opsummering Konklusion Videre udvikling v

6 13. Litteraturliste vi

7 1. Forord Dette projekt er udarbejdet ved Institut for Matematisk Modellering for Danmarks Tekniske Universitet i samarbejde med Pallas Informatik A/S i perioden til Projektet er lavet som et eksamensprojekt i forbindelse med afslutningen af uddannelsen Diplom IT. Projektet omhandler en undersøgelse af Adobe Flex Frameworkets muligheder for at opbygge et infotainment system. Vejlederen under forløbet var Finn Gustafsson fra DTU IMM. Rasmus Fallesen Kjer, Lyngby Januar vii

8 2. Resume Denne rapport dokumenterer undersøgelsen af brugen af Adobe Flex Frameworkets muligheder for at opbygge en brugergrænseflade til et interaktivt infotainment system. Brugergrænsefladen skal præsentere sider defineret af et andet centralt system. Disse sider skal senere kunne oprettes eller redigeres i en editor. Nye sider skal senere kunne tilføjes efter ønske, af dem som har adgang til det centrale system. Rapporten dokumenterer En modulariseret opbygning af brugergrænsefladen virker i henhold til ønsket om benyttelse af nye sider oprettet efter installation af Navigatoren At indholdet på siderne kan ændres løbende ved brug af en webservice og database. En sidestruktur der er hensigtsmæssig for visuelle editorer. 1

9 3. Introduktion 3.1 Pallas Informatik A/S Pallas Informatik (PI) er et IT konsulenthus som yder konsulentbistand og systemudvikling. Firmaet blev startet i 1983 med kun en mand, og er vokset støt lige siden. På nuværende tidspunkt er der omkring 50 medarbejdere i virksomheden. PI har adskillelige projekter som de arbejder på løbende. Disse projekter er inden for kategorierne Transport, Sundhed og Fødevarer. 3.2 Udvikling af et Infotainment system I 2004 blev PI involveret i et projekt der havde til formål at udvikle et infotainment 1 system som præsenterer annoncer for passagerer i taxier, hver gang disse ønskede at se en nyhed eller turistinformation. Projektet blev fuldført med hjælp fra en række leverandører, lige fra nyhedsformidlere til hardware og software leverandører. PI s rolle var at samle alle delene og teste systemet. 3.3 Motivation PI vil udvikle systemer der er tæt beslægtede med det ovennævnte. PI ønsker derfor, ved selv at udvikle næste generation af det ovennævnte system, at kunne hurtigt og nemt tilpasse det til en bred vifte af anvendelser. 3.4 Projektet Indledning Affødt af ønsket om at lave et bedre system blev undertegnede sat til at undersøge Flex Frameworkets (FF) muligheder for at opnå den samme funktionalitet. Derudover skal det nye system være en forbedring af det gamle i skikkelse af et mere tilgængeligt udviklingsforløb når programmet skal have nyt udseende og indhold. Håbet er også at FF er i stand til at levere en bedre grafisk løsning en andre tilsvarende teknologier. 1 Infotainment: En sammensætning af information og entertainment. Side 2

10 3.4.2 Formål Formålet med dette projekt er at udvikle et nyt program der informerer og underholder passagerne i taxaerne. Denne prototype kaldes Navigator. Til Navigatoren skal der på et tidspunkt udvikles en visuel editor, så nye sider kan laves af folk uden programmeringserfaring Infotainment Navigator Navigatoren skal være en brugergrænseflade til et interaktivt system til passagerne i diverse transportmidler. Det er vigtigt at brugeren oplever systemet som nyt og spændende. Systemet skal derfor have en grafisk præsentation der er ud over det normale, samt en brugervenlighed der tillader langt de fleste personer at benytte det, uden forudgående introduktion. Systemet skal give brugeren mulighed for at vælge imellem en række audiovisuelle medier der kan være lagret lokalt på klienten, være leveret af andre programmer kørende på klienten eller andre ressourcer tilgængelig over internettet. For at benytte klienten skal man bruge den trykfølsomme skærm programmet bliver præsenteret på. Navigatoren skal installeres på en række klienter der befinder sig på variable positioner i et givent land. Disse klienter vil løbende blive opdateret med aktuelt indhold fra en central server, over mobilt bredbånd. Passageren må ikke bemærke at indholdet er blevet opdateret i form af genstart af computeren eller Navigatoren Navigations Editor Navigatoren skal designes således at diverse sider kan tilføjes og modificeres af en endnu ikke udviklet Editor. De nye sider skal distribueres fra en central server og benyttes af Navigatoren. Editoren skal være af visuel karakter og må ikke kræve programmeringserfaring af nogen art. Dette medfører at det programmatiske design af Navigatoren skal være hensigtsmæssig ved en senere udvikling af Editoren Omfang Projektet består af to faser. Side 3

11 Den første fase går ud på at analysere den nuværende problemstilling og FF s teknologiske muligheder til at løse denne. Der skal bl.a. undersøges hvordan FF kan opbygge en Navigator der kan opdatere sit indhold og have en hensigtsmæssig opbygning for en Editor. Anden fase går ud på at implementere og teste de grundlæggende tekniske løsninger og vurdere om de er velegnede til projektet. I denne fase vil der blive udviklet en prototype som dokumentation for validiteten af programmets design Begrænsninger Da projektet vil blive udført på 12 uger med undertegnede som den eneste udvikler, medfører det at meget få dele af projektet vil blive færdig udviklet, set i forhold til projektets størrelse. Ingen af Editorens funktionaliteter vil blive implementeret, og Navigatoren vil ikke fremstå med alle de grafiske finesser som teknologien giver mulighed for. Der sigtes kun efter at en generel arkitektur for Navigatoren bliver implementeret og testet Akronymer og forkortelser AS3 : ActionScript 3 MXML: PI: DTU: Magic extended Markup Language Pallas Informatik Danmarks Tekniske Universitet AVM2: ActionScript Virtual Machine 2 FF: WSDL: UP: UML: SWF: CSS: ALON: Adobe Flex Framework WebService Description Language Unified Process Unified Modeling Language ShockWave Flash Cascading StyleSheet Autonomous Linking Object Network Side 4

12 RIA: MSSMSE: Rich Internet Application Microsoft SQL Server Management Studio Express Interesser og slutbrugere Et hvert software projekt har økonomiske omkostninger i form af udviklingsudgifter. Disse udgifter skal hentes hjem i form af betaling fra diverse investorer i projektet. Dette afsnit beskriver hvilke interessegrupper der er i projektet. Pallas informatik PI har allerede en rolle i forbindelse med udviklingen af et infotainment system. Denne rolle består i konsulent bistand mht. at samle alle systemets dele (hardware, software og test). PI ønsker at udvide denne rolle til også at indeholde udvikling af softwaren. PI får i den forbindelse generelle kompetencer med simple interaktive brugergrænseflade systemer til benyttelse i dagligdagen. PI har ønske om at bruge disse kompetencer til andre produkter såsom, infotainmentsystemer til tog (ikke interaktive), interaktive produktpræsentationer (infostandere) og på sigt løsning til præsentation af tilbud m.v. i slutbrugerens hjem. Investorer Finansielle investorer af infotainment systemer er i konkurrence med andre firmaer, der tilbyder lignende produkter. Investorerne ønsker derfor at distancere sig til konkurrenterne ved at tilbyde et produkt til franchisetagere, med flere egenskaber end de konkurrerende systemer. Disse egenskaber skal være et pænere og mere editerbart udseende og nem adgang til ændring af indholdet. Franchisetagerne Franchisetagerne er dem som i sidste ende køber infotainmentsystemet. Deres incitament til dette produkt er at sælge annoncepladser til firmaer der ønsker at reklamere om deres ydelser og produkter. Jo nemmere franchisetagerne har ved at konfigurere Navigatoren, jo lettere er det for dem at tilpasse den til omgivelserne, og derved optimere nyhedsindholdet o.a. til de specifikke brugertyper der benytter transportmidlet. Transportfirmaer Side 5

13 Ved at tilbyde passagerne underholdning og information på rejsen, kan rejsen opfattes som kortere og mere behagelig. Firmaets ydelse (transporten) kan være i mere positiv erindring hos passagerne. Passagerer Under rejsen kan passagererne blive informeret med relevante nyheder fra ind- og udland, specielle trafik informationer o.a. underholdning. Side 6

14 4. Planlægning For at holde overblikket over projektet har jeg benyttet mig af tidligere udvikleres erfaringer. Disse erfaringer indebærer brugen af Unified Process som udviklingsmetode og UML diagrammer til beskrivelse af designet Unified Process UP er en iterativ software udviklingsmodel som organiserer et projekt i fire forskellige faser: Inception Også kaldet planlægningsfasen. Her beskrives usecases og kravspecifikationen formuleres. Elaboration Implementationsfasen. Kerne komponenterne i programmet implementeres. Problematiske komponenter implementeres. Tidsplan reevalueres. Konstruktion - Endelig implementationsfase. De mindre og nemme komponenter implementeres. Forberedelse til Overførselsfasen Overførsel Test og Deployment. Det er vigtigt at huske at UP ikke er som den gamle vandfaldsmodel, hvor næste fase ikke kunne påbegyndes før forrige fase var afsluttet. UP er mere fleksibel. Den tillader at der arbejdes på alle faser i samme iteration. Hvor meget der arbejdes på hver fase i den enkelte iteration afhænger til gengæld af iterationen. Typisk vil der blive arbejdet meget på inception og elaboration i de første iterationer i projektet, og eftersom flere iterationer bliver gennemløbet vil udviklerne flytte mere og mere fokus over til de sidste faser. Figur 1 viser et eksempel på et UP forløb. Side 7

15 Figur 1 eksempel på et UP forløb. diagrammet viser forholdet mellem forskellige typer af arbejdsopgaver i projektet Software modeller At skrive og tale om et programs struktur bliver hurtigt uoverskueligt. Det bliver derfor nødvendigt at beskrive programmet visuelt eller skematisk. Der findes en række teknikker til dette. Det følgende er en beskrivelse af dem der er brugt i dette projekt Unified Modeling Language: UML En de facto standard til visuelt at beskrive programmers struktur inden for objekt orienteret programmering. UML har grafiske notationer der kan beskrive de fleste sammenhænge imellem objekter. Ved at bruge af UML kan der hurtigt skabes overblik over et programs design, derved nemmere sikre en fornuftig implementation Use-Cases Disse benyttes til at beskrive hvorledes slutbrugeren agere med systemet, og hvorledes systemet agere med andre systemer. Use-cases er som standard ikke visuelt, men et stykke tekst der i detaljer beskriver hvad der sker i, ofte helt simple, specifikke situationer. Ved at bruge use cases fastholdes ideen med projektet idet disse forklarer helt præcist hvordan systemet skal fungere, set fra brugerens synspunkt. 4.3 Milepæle Side 8

16 Milepælene sat for udvikleren i projektet er en grov rettesnor for hvor godt tidsplanen følges. Følgende er milepælene for dette projekt. Uge Aktivitet 42 Inception, overordnet kravspecifikation samt undersøgelse af Adobe Flex. 44 Design, implementation og test af mindre Flex Komponenter. Design, implementation og test af første udgave af Navigatoren. 46 Kommunikation mellem andre systemer og datalagring. Implementation og test. 48 Implementation og test af primær Use-Case: Positions afhængige video præsentation. 49 Prototype færdig 02 Projekt færdigt 4.4 Iterationer Projektet er delt op i følgende iterationer 1. Inception(Undersøgelse af Flex) a. Overordnet forståelse af API i. Hvad tillader API et ii. Hvad tillader API et ikke b. Undersøgelse hvordan mindre programmer bygges 2. Overordnet struktur af programmet a. Hvorledes gøres programmet fleksibelt for radikale ændringer i flowet. b. Hvorledes sikres en generel intern kommunikation i programmet 3. Kommunikation med andre systemer og datalagring a. Hvilke teknologier kan benyttes til kommunikation i. Valg af teknologi samt implementation og test b. Hvordan benyttes databaser i forbindelse med RIA er. i. Valg af metode samt implementation og test 4. Positions afhængige videopræsentationer a. Implementation af specifikke data til datamodellen b. Kreation af specifik kommunikationsservice til andet system samt database 5. Test af det samlede system samt rettelser og finpudsning efter test. a. Herunder dokumentation Her under ses en tidsplan for de ovenstående iterationer Side 9

17 Fra Til Aktivitet Iteration Iteration Iteration Iteration Iteration Dette diagram illustrerer arbejdsfordelingen sammenlagt for iteration 1, 2, 3, 4 og 5 i projektet. Figur 2 Arbejdsfordelingen for opgavetyperne i projektet. Som der står beskrevet under Milepæle ovenfor har der været flere forløb af de fire fase typer. For hvert større koncept som der skulle udvikles er det ovenstående forløb blevet gennemgået. Side 10

18 5. Kravspecifikation 5.1. Indledning I dette afsnit vil der blive beskrevet hvilke krav der er til læseren af rapporten samt kravene for systemet der designes og implementeres. Angående kravene for systemet vil disse være opdelt efter FURPS+ princippet som har rækkefølgen (Functionality, Usability, Reliability, Performance og Usability). Denne opdeling gør det nemmere at skelne kravtyperne fra hinanden. Generelt kan man sige om de funktionelle krav, at de bør være specifikke fordi det især er dem der enere skal verificeres i testen. De ikke funktionelle krav, altså resten, er ikke nær så præcise i deres beskrivelse, og det kan derfor altid diskuteres, om de er opfyldt eller ej Krav til læseren Det forventes at læseren har grundlæggende forståelse for udvikling af software og bør kende til design patterns, objekt orienteret programmering, databaser, webservices og scriptingsprog baseret på ECMAstandarden(Javascript eller ActionScript). En grundlæggende forståelse for UML er også nødvendig. 5.3 Funktionelle krav Funktionelle krav er de funktioner programmet ønskes at indeholde. Disse krav er generelt mere specifikke end de andre kravtyper og kan også indeholde sikkerhedsmæssige aspekter af programmet Kommunikation til andre programmer Datatyper Det skal være muligt at sende data i form af simple datatyper eller XML til andre programmer fra Navigatoren Omfang Kommunikationen skal fungere til programmer lokalt på klienten og over netværk. Side 11

19 Generalitet Kommunikationsformen skal kunne fungere som et generelt interface for alle programmer som skal sende informationer til brugergrænsefladen Sikkerhed Kommunikationsformen skal være sikker nok til at forhindre de mest simple former for uønsket indtrængning Indhold Ændring af bruger navigation under kørsel Det skal være muligt at ændre knapper og deres links i programmet under kørsel. Denne ændring skal foretages fra et central sted og bør ikke påvirke programmets kørsel Ændring af ikke aktive sider under kørsel Sider der ikke er under visning skal kunne ændre deres indhold og udseende uden det påvirker programmet yderligere Afspilning af video Hvis valgt af brugeren, skal programmet afspille en specifik video i Flash Video(flv) eller MPEG-4 (mp4) format. Videoen skal starte afspilningen automatisk og efter endt afspilning, skal skærmen returnere til forrige skærmbillede Kontrol Navigation Brugeren skal have mulighed for at bevæge sig frem til næste menupunkt ved tryk på punktet. Yderligere skal han også have mulighed for at gå tilbage til forrige menupunkt Hovedmenu Hver side skal give mulighed for at gå tilbage til hovedmenuen, og dermed afslutte visningen af enhver præsentation Lyd Under afspilning af video skal brugeren have mulighed for at slå lyden til eller fra. Side 12

20 Terminering af programmet Brugeren skal altid have mulighed for at slukke for klienten Editor Udvikling af Editor Siderne skal have en struktur så det vil være nemt at udvikle en grafisk editor på et senere tidspunkt. 5.4 Prioritering af funktionelle krav I dette projektforløb er det ikke muligt at implementere alle kravene fra kravspecifikationen. For at få et overblik over de mest kritiske aspekter af programmet laves en evaluering af samtlige krav. Kravene er vægtet på følgende måde: 1. Ultimativt krav 2. Kritisk krav 3. Vigtigt krav 4. Krav der kan undlades, men vil give en forringelse af projektet 5. Krav der kan undlades Side 13

21 Vægt Krav # Krav Risici Kommunikation til andre programmer Ændring af knapper under kørsel Ændring af sider under kørsel Høj Hvis programmet ikke kan hente data udefra bliver dens funktionalitet statisk hvilket vil forringe kvaliteten af programmet til et niveau hvor projektet vil blive afsluttet Høj Uden denne funktionalitet vil dette program ikke skille sig ud fra andre alternativer på markedet. Høj Uden denne funktionalitet vil dette program ikke skille sig ud fra andre alternativer på markedet Navigation Medium Pga. de tidligere satte rammer skal en fornuftig implementation udtænkes Hovedmenu Lav Velkendt funktionalitet Styring af lyd Lav Velkendt funktionalitet Terminering af programmet Medium Ikke en essentiel feature ved programmet, men kan give problemer da det skal kommunikere med operativsystemet for at opnå denne funktionalitet. Hvis dette ikke kan lade sig gøre kan programmet sættes inaktivt på anden vis og derved opnå samme resultat, set fra brugerens synspunkt Editor Høj Afviger radikalt fra nuværende standard Flex program design. Grundig overvejelse af programmets design nødvendig. Uden denne mulighed mister programmet sin fordel over andre alternativer. 5.5 Ikke Funktionelle Krav Følgende ikke-funktionelle krav stille til programmet. Disse krav kan ikke påvises implementeret, men er vigtige at få med da de inkluderer nogle generelle betragtninger for systemet, som er vigtig at udvikleren holder for øje når systemet designes Brugervenlighed Systemet skal have en visuel fremtoning som demonstrerer de mest optimale grafiske teknologiske muligheder med det valgte framework, for at give passageren et indtryk af et nyt og spændende produkt. Dette på trods af at funktionaliteten er forholdsvis simpel. Det er derfor vigtigt at de nyeste grafiske tendenser og features bliver implementeret, Side 14

22 eller har mulighed for at blive implementeret i en fremtid udgave. I forbindelse med designet af prototypen i dette projekt skal der derfor tages hensyn, til at man ikke udelukker nødvendige grafiske features i det valgte design Pålidelighed Brugeren må ikke opleve at visse sider og film ikke reagerer pga. siden eller filmen ikke eksisterer. Hvis dette alligevel sker, skal centralen underrettes om den pågældende klients problem. Yderligere bør disse sider og film gøres inaktive indtil problemet er rettet. Navigatoren bør også underrette centralen om hvilken side og film der vises. Dette vil gøre det muligt at kontrollere om der er korrekt sammenhæng mellem knapperne brugeren aktiverer, og hvad brugeren får vist Kapacitet Programmet skal være i stand til at køre i dagevis uden nedbrud eller tiltagende lavere responstid. Brugergrænsefladen indeholder visuelle objekter som kan være animerede. Disse animationer skal fremstå som flydende bevægelser, hvis dette er meningen. Programmet skal med andre ord ikke virke til at belaste systemet for meget så at brugeren får oplevelsen af et langsomt program Vedligeholdelse Opdatering af sider må ikke medføre re-kompilering af programmet. Programmet bør være i stand til at opdatere sig selv til den nyeste tilgængelige version uden interaktion på klienten. Det skal være nemt at installere programmet på klienterne, og opdatering til yderligere versioner skal ikke volde besvær. 5.6 Dokumentation I forbindelse med dette projekt foreligger der også krav vedrørende dokumentation. Da dette er et eksamensprojekt skal analyse og design osv. dokumenteres i rapporten med tilhørende UML-diagrammer hvor disse er passende. I implementations afsnittet skal eventuel kildekode forklares udførligt. Hvis dette ikke var et eksamensprojekt hvor en Side 15

23 rapport var påkrævet, ville kravene til dokumentation være reduceret til fornuftig dokumenteret kildekode. 5.7 Succes kriterier Kriterierne for succes er at få opfyldt kravene der er vægtet 1-2 da disse er essentielle for programmets struktur. Endnu et kriterium er at de opstillede use cases bliver implementeret. Disse usecases er designet så den benytter de fleste af de essentielle krav til programmet og vil således tjene som dokumentation for at disse er opfyldt. Side 16

24 6. Teknologier Dette projekt benytter mange forskellige teknologier. I dette afsnit vil de blive kort introduceret så læsere der ikke har umiddelbart kendskab til dem vil blive udstyret med tilstrækkelig information til at få en grundlæggende forståelse for dem, og gøre rapporten mere anvendelig. 6.1 ActionScript 3.0 og flash platformen Den grafiske brugerflade skal udvikles i ActionScript 3.0 (fremover kaldet AS3), et objekt orienteret sprog baseret på ECMAScript standarden. En standard der også benyttes af f.eks. javascript. AS3 kompileres til byte kode der fortolkes af Adobes AVM2 (ActionScript Virtual Machine 2). AVM2 er en fortolker der omdanner byte koden til maskin kode, så programmer kan køre på hvilken som helst CPU og platform der har en Flash Player installeret. AS3 er managed code, hvilket bl.a. vil sige at hukommelsesstyring bliver håndteret af en Garbage Collector. Det er også værd at nævne at AS3 implementerer Document Object Model 3 Event model som gør den event baserede arkitektur mere struktureret end forgængeren AS2. Årsagen til valget af AS3 Flash Platformen er den velstrukturerede event model og lethed i at lave pæne GUI er. 6.2 Flex Frameworket Flex er et AS3 framework der giver udvikleren mulighed for at benytte langt flere biblioteker end standard AS3 der udvikles i Adobe Flash Proffesional, et program der er en del af Adobes Creative Suite til designere. Årsagen til det øgede antal biblioteker er at Adobe har valgt at separere udviklingen af Flash applikationer. Den ene vej er at bruge Adobe Flash Proffesional (AFP), som primært laver applikationer med vægt på visuel præsentation fremfor funktionalitet. Dette kan være knapper, reklame bannere osv. Pakken indeholder dog stadig en lang række nyttige biblioteker som skulle tilfredsstille de fleste. Side 17

25 Den anden mulighed er Flex Frameworket som fås med et Eclipse IDE. Det siger sig selv at denne pakke er ment til programmørerne som ligger vægten på funktionaliten istedet for visuel fremtoning. I dette projekt var det benyttede IDE Flex Builder 3.2 med en Adobe FlashPlayer 10 debugger version installeret. Flex Builder minder utrolig meget om Eclipse og giver mulighed for debugging med breakpoints, dette er ikke muligt i AFP, og en speciel egenskab der hedder Memory Profiling. Dette er et ret brugbart værktøj der kan fortælle hvor meget hukommelse programmet allokerer, og hvilke objekter der er instantieret på et givent tidspunkt i programmet. Det sidste kan benyttes til at vurdere om Garbage Collectoren udfører sit arbejde Parts Flex Komponenter Degrafa er en 3. Partskomponent der bliver en den af Flex 4 Frameworket når den når sit beta stadie foråret Degrafa er et grafisk bibliotek der giver rig mulighed for for at tegne diverse vectorbaseret figurer runtime. 6.3 Adobe Integrated Runtime (AIR) AIR er et platforms uafhængigt Runtime Enviroment der kan afvikle Rich Internet Applications (RIA er) udviklet i Adobe Flash /Flex som almindelige skrivebordsprogrammer installeret på PC en. Der er fordele og ulemper ved at lade sit program køre via AIR. Ved at køre i en almindelig browser kræves ingen installation af programmet, hvorimod ved AIR kræver det at applikationen bliver packet, digital underskrevet og installeret. Fordelen er tilgengæld at programmet får adgang til filsystemet, hvorimod browserbaserede applikationer er mere begrænset i dette henseende. Browserbaserede programmer benytter sig tildels også af browserens garbage collection, som kan være mere effektiv en AIR s egen. 6.4 Windows XP Embedded Dette er en udgave af Windows XP Professional der gør det muligt at undvære en lang række services der normalt følger med Windows XP. Udviklere har dermed mulighed for at pille alle de programmer og services fra de ikke finder nødvendige og dermed minimere ressourceforbruget for operativsystemet. I modsætning til Windows CE, der Side 18

26 bl.a. benyttes til SmartPhones, gør XP Embedded det muligt at benytte det fulde Windows XP API, samt alle applikationer og drivere der ville være tilgængelige til en almindelig XP. Navigatoren skal i sidste ende installeres på en Windows XP Embeded. 6.5 Webservices Webservices er software systemer designet til at understøtte maskine-til-maskine interaktion over netværk ved at benytte HTTP protokollen. Webservices skal hostes på en webserver og metoderne i disse vil typisk være beskrevet i WSDL er som er tilgængelige på det samme domæne webservicen bliver hosted. WSDL står for WebService Description Language og er et dokument der som navnet antyder blandt andet forklarer hvad navnene på forskellige WebMethods hedder, deres parametre og return types. Return types som er specielle objekter kun defineret i webservicens scope kan også returneres. 6.6 Socket Connections Socket forbindelser er en to vejet process til process kommunikations form over et IPbaseret netværk. Hvis to programmer skal kommunikere kræves det at de begge etablerer en socket forbindelse på en specifik port og begynder at sende og lytte. Til at fortolke de data der sendes over forbindelsen benyttes specielt implementerede protokoller der skal have identisk design i begge ender. Dvs. både sender og modtager skal mene det samme når de sender noget over netværket. Socket forbindelser er en hyppigt brugt teknik til at udveksle data over netværk og hvis den implementeres korrekt kan den blive yderst stabil. 6.7 Datalager Til systemer der skal bruge relativt store mængder data der nemt kan opdateres, udtrækkes, slettes osv. på en struktureret måde er det almindeligt at bruge databaser. Databaser er ikke andet end en ekstrem struktureret teknik til at gemme og tilgå sine informationer på. Metoden dette gøres med er såkaldte Forespørgsler. Disse forespørgsler fortages i et sprog kaldet SQL, Structured Query Language. Der findes en lang række produkter på markedet i dag, og da dette projekt ikke stille voldsomme krav til Side 19

27 hverken køretiden eller andre avancerede features på dette niveau vil der ikke blive brugt hverken tid eller kræfter på at finde den mest optimale løsning. 6.8 Design patterns Design pattern en bestemt struktur man kan påtvinge større eller mindre dele af et program. Meningen med design patterns er øges gennemskuelighed af koden, samt at fungere som en generel løsning på et type problem. I dette projekt er der brugt Autonomous Linking Object Network, ALON og Model View Controller (MVC). Det sidste kan også forstås som et arkitektur pattern, et pattern der definerer den generelle struktur i programmet men skal her ses som et pattern der er tildelt mindre komponenter. Side 20

28 7. Analyse Målet med dette afsnit er at analysere de høj-risici konceptuelle problemstillinger med høj vægtning stillet i kravspecifikationen. Ud fra denne analyse skal der komme nogle konceptuelle forslag til løsning af disse problemstillinger. I et senere afsnit vil disse forslag blive uddybet i en sådan grad at de kan implementeres. 7.1 Automatisk sideopdatering Der er en række måder hvorpå en Flex udvikler programmatisk kan kode de komponenter der viser det indhold der ønskes. Dette afsnit analyserer de forskellige muligheder, og opvejer resultatet mod 1.2 i kravspecifikationen Viewstacks Den mest almindelige måde at lave sider på i FF, er at benytte komponenter kaldet Viewstacks. Kombineret med komponenter af typen Navigators, kan brugeren navigere rundt samlingen af viewstacks. Viewstacks laves ofte som statiske sider, der strukturelt ligger på samme niveau. Navigator komponenten vælger blot hvilken der vises, og gør resten usynlige. Fordelen ved viewstacks er at man kan benytte en indbygget state machine i FF til at bestemme hvilke sider der skal vises i bestemte situationer. Med viewstacks følger også muligheden for en feature kaldet transitions. Transitions er som navnet antyder en overgangseffekt der aktiveres når der skiftes side. Ulempen ved viewstacks er at de skal være med i programmet ved kompilationstidspunktet. Det er ikke mulig at tilføre nye viewstacks under kørselstidspunktet. Da det, ifølge 1.2 er essentielt for systemet at være i stand til at optage nyt indhold under kørselstidspunktet, kan denne metode ikke bruges Viewstacks med Database Backend En anden mulighed vil være at have en enkelt viewstack der dynamisk genererer indholdet ud fra informationer lagret i databasen. Dette vil betyde at databasen skal Side 21

29 indeholde information om hvor mange knapper der er, hvilke koordinater de er placeret på, hvad de linker til og alle de visuelle træk såsom farve, form, overgangs effekter m.m. Disse informationer skal gives til den dynamiske viewstack, som genererer alle de komponenter der er påkrævet, påfylde dem med de variabler der er givet, og standard variabler hvor der mangler. Efter at siden er blevet vist, og en ny side skal forberedes, kommer problemet med at rydde op. En del vil blive opsamlet af garbage collectoren, men kun hvis det ikke længere anses som i brug af programmet. Vi står altså tilbage med et vilkårligt antal af vilkårlige elementer som skal fjernes af programmøren selv. Med denne løsning vil vi beholde understøttelsen af transitions, et godt grafisk værktøj, og miste behovet for en statemachine, da der kun er en eller to viewstacks. Derimod vil vi få en meget kompleks database og et kaotisk oprydningsproblem efterfølgende Modularisering Moduler er kompilerede.swf-filer der kan indlæses og udlæses af et hovedprogram efter behov. Moduler er ikke selvstændige applikationer, men kan ses som et stykke af et program der kan inkluderes efter behov. Det giver en kærkommen separation af programmet. Hvis programmet er opbygget i moduler, resulterer en lille ændring kun en re-kompilering af det enkelte modul, eller hvis ændringen sker i hovedprogrammet kræver det kun re-kompilering af denne. Det gør applikationen som helhed mere fleksibel overfor ændringer, og i denne applikation vil de tænkes at forekomme ofte. Ved at opbygge hver side som et modul kan siderne opdateres ved blot at udsende et nyt modul til klienterne. Når brugeren skal se siden, bliver den læst ind af hovedprogrammet, og udlæst når brugeren går væk fra siden igen, for at frigøre hukommelse. Andre fordele ved brug af moduler er mindre størrelse af hovedprogrammet (Navigatoren) og dermed mindre opstartstid, og bedre indkapsling af forskellige dele af programmet. Side 22

30 Ulempen ved denne struktur er dog at en stor menu struktur vil give mange filer, der kan få programstrukturen til at fremstå uoverskuelig og rodet i filsystemet. Dette vil det kræve unikke filnavne for hvert modul, hvilket vil gøre det nødvendigt at håndhæve en form for navngivningskonvention Moduler med Viewstacks En kombination af moduler og Viewstacks vil gøre det umuligt kun at opdatere enkelte sider ad gangen. I stedet vil man opdatere modulerne, som er en gruppering af sider i form af viewstacks. Fordelen ved denne metode er mulighed for transitions imellem sider i samme modul og brug af en statemachine imellem sider i samme modul. Ulempen er en øget kompleksitet over for en editor. Denne skal redigere i en langt mere kompliceret struktur end tidligere, hvilket går imod krav 1.4 om nem udvikling af en editor Konklusion Opsummering af løsningsmodellerne i forhold til højt prioriterede krav. Modellerne kan få disse ratings: Umuligt Besværligt Muligt Viewstacks Viewstack & DB Moduler Moduler & viewstacks Editor 1.4 Muligt Besværligt Muligt Besværligt Indhold 1.2 Umuligt Besværtligt Muligt Besværligt En ren modulariseret løsning er den bedste løsning. Den understøtter en simpel editor i henhold til 1.4 og Indhold i henhold til 1.2 Side 23

31 7.2 Kommunikation Systemet kan deles op i to separate programmer. Den ene del står for præsentation af sider (Navigatoren) og den anden del er forbindelsen til andre programmer og systemer. Imellem disse to programmer skal der skabes en kommunikationsmetode. De to mest brugte metoder til kommunikation imellem programmer er sockets og webservices. Kravene til kommunikation er beskrevet i 1.1 i kravspecifikationen Socket Kommunikation Socket kommunikation kan ske når to programmer sættes op til at lytte på en bestemt port. Via denne port kan data overføres. Men for at programmer kan forstå dette data, kræves det at de har samme forståelse for hvad betydningen dataene er. Til dette benyttes en protokol som skal implementeres i begge programmer for at kommunikationen skal være succesfuld. Den største ulempe i denne metode ligger i udvikling af protokollen. Jo flere situationer/kommandoer der skal understøttes jo mere kompleks bliver denne. Derudover kræver denne kommunikationsform at begge programmer har moduler der understøtter socket kommunikation. Fordelen ved socket baserede løsning er at kommunikationsformen er yderst effektiv. Kun den nødvendige data bliver overført, og programmet kører ikke ovenpå en webserver, i modsætning til webservices Webservices Webservices er et program der kan kaldes over netværket via http protokollen. Man kan se en webservice som et slags åbent program hvori der er en række metoder. Disse metoder kan kaldes med de parametre de nu kræver, og giver et svar i henhold til deres return type. Hvilke parametre og returntypes der gælder for hver metode er beskrevet i WSDL-filen, en fil som bør følge med hver webservice. Webservices er nemme at opsætte og integrere med andre programmer, og de kræver ikke nogen protokol i modsætning til socket kommunikation. Ulempen er at de kræver en webserver som afviklingsplatform. Som udgangspunkt er webservices åben for alle der kalder dem, og alle kan se hvilke parametre deres metoder tager. Side 24

32 For at undgå at uvedkommende udnytter disse services bør der indbygges en sikkerhedsforanstaltning der vurderer om der er tale om en uvedkommende person, eller valid klient Konklusion Webservices medfører en øget sikkerhedsrisiko, og kræver flere system ressourcer end en socket baseret kommunikationsløsning. Til gengæld er implementation og integration væsentlig nemmere. Sikkerhedsrisikoen er desuden kun tilstede hvis udvikleren ikke tager højde for dette i implementationen. 7.3 Database En database skal bruges i forbindelse med opdatering af præsentationerne imellem centralen og klienten. Centralen gemmer sidernes konfiguration i klientens database, så når siderne bliver indlæst i Navigatoren, vil de altid indeholde den mest aktuelle opsætning. Databasen er således en løsning på 1.2 i kravspecifikationen. Man kan forestille sig to grundlæggende lagrings rolle muligheder for databasen i forbindelse med dens rolle som konfigurationsholder til systemet. 1. Databasen indeholder alt information såsom film, billeder og tekst, næste link osv. i råt format. Dette vil medføre at disse tunge datatyper (film og billeder) skal overføres til webservicen fra databasen, for derefter at blive overført fra webservicen til Navigatoren, hver gang denne skal bruge det. Det antages at en overførsel af en video fra en database til en webservice er en relativ ressourcekrævende operation. Det samme antages mht. overførsel af en video fra en webservice til Navigatoren. 2. Databasen indeholder adresser i form af tekst, hvor disse filer befinder sig lokalt på klienten. Denne metode vil i forhold til det forrige løsningsforslag ikke kræve så mange ressourcer fordi videoer og billeder blot vil blive indlæst til Navigatoren direkte fra harddisken. Side 25

33 Ulempen ved den første løsning er at den sandsynligvis er meget ressourcekrævende, hvilket kan give forsinkelser og få systemet til at virke langsomt. Ved den anden løsning vil disse forsinkelser ikke opstå, men her kan der opstå uoverensstemmelser imellem hvad der står i databasen, og hvad der rent faktisk ligger af filer på filsystemet. Dette regnes dog for et mindre problem og løsningen anses som den bedste. 7.4 Editerbare moduler Moduler skal ifølge 1.4 være redigerbare med en visuel editor. For at undgå unødvendig besvær ved udvikling af editoren ønskes sidestrukturen derfor så enkel som mulig. For at opnå dette bruges FF s mulighed for deklarativt beskrivelse af programmer i kombination med code-behind filer og cascading style sheets (CSS) 7.5 MXML MXML er et XML-baseret user interface markup language konstrueret af Macromedia. Det bruges hovedsagligt til at beskrive et programs struktur deklarativt, men kan også bruges til at beskrive applikationens logik. MXML bruger < namespace : class > notation for at bestemme hvilken komponent der skal instantieres. Eksempel: <mx:videodisplay></mx:videodisplay> MX er det namespace, eller pakke, som klassen VideoDisplay ligger i. Alle klasser ligger i et namespace og hvis en tredje parts pakke benyttes vil klasserne ligge i dennes namespace. Diverse attributter kan sættes på normal XML vis. Når MXML kompileres bliver det først fortolket til AS3 for derfra at blive kompileret til bytekode som fortolkes af AVM2. Side 26

34 7.5.1 Code-Behind Den mest udbredte praksis blandt Flex udviklere er at blande MXML og AS3 i samme fil. Denne metode er udmærket, og ganske brugbar når man skal lave et program hurtigt, som ikke skal skalere. En smartere, dog ikke nær så udbredt stil, er at separere programmets struktur fra logikken. Visuelle elementer kan ofte opfattes som containers 2, disse containers kan indeholde elementer som igen kan indeholde elementer som igen kan indeholde elementer osv. At forsøge at kode dette i AS3 gør nemt ethvert program uoverskueligt. I deskriptive sprog beskrives elementernes forhold til hinanden nemt og overskueligt. Til gengæld er det en møjsommelig opgave at udføre logiske operationer i deskriptive sprog. Det er derfor oplagt at separere koden til det sprog hvor dens styrke er størst. Dvs. programmets struktur, med hvilke elementer der er placeret hvor og inde i hvad, beskrives i MXML. Hvad de forskellige elementer udfører af funktioner beskrives i AS3. I realiteten sker der det, at elementer i MXML strukturen arver fra AS3 klassen, og dermed al dens logik. Hvis nogle attributter defineret i MXML en med en specifik værdi, vil disse overskrive default værdierne. En yderligere separation af koden er beskrivelse af den visuelle del i CSS-filer (Cascading StyleSheets). Markup Languages såsom HTML har en tradition for at ligge denne del af koden i, CSS-filer. Når knapper og andre elementers udseende bliver beskrevet i CSS-filer vil et helt programs udseende kunne skiftes ud, ved blot at ændre CSS-filen Konklusion Idéen med separation er nem ændring af funktionalitet, struktur og udseende. Dette er hensigtsmæssigt for Editoren fordi det er disse elementer den skal arbejde med. Med denne opbygning kan en editor vælge, hvilken funktionalitet en komponent skal have i form af et udvalg af AS3 klasser, nemt placere dem i forhold til andre elementer i MXML og redigere dens visuelle features i CSS-filen. 2 Containers: Objekter som senere kan påfyldes indhold. Som regel tager containers kun en delmængde af alle datatyper som brugbart indhold. Side 27

35 Den generelle separation af den programmatiske beskrivelse af programmet lader til at være et hensigtsmæssigt træk for udvikling af Editoren. Ydereligere tillader denne separation af koden at udviklingen af Editoren kan laves i to faser. 1. Redigering af strukturen (MXML der arver fra en AS3 klasse) 2. Visuel konfiguration som farver og former (CSS) Således gøres udviklingen af Editoren nemmere ved Divide And Conquer metodikken. 7.6 Use Cases og aktører Use cases og aktører bruges til at bestemme hvilke situationer systemet kan blive udsat for. Ved at definere nogle scenarier imellem systemet og bruger, eller systemet og andre programmer, use cases, kan man sætte en ramme for hvordan systemet skal opføre sig set fra brugerens synspunkt Identifikation af aktører Aktører er alle de kategorier af personer og systemer som kommer i kontakt med programmet Primær aktører Passagerer Passagerne vil komme i kontakt med Navigatorens brugergrænseflade i forbindelse med rejser hvor de ønsker at benytte infotainment systemet Administratorer Disse benytter editoren til at ændre indholdet på siderne og indsætte nye sider Sekundære aktører Webservice Den service som forbinder Navigatoren med omverdenen. Datalager Navigatoren tilgår denne service via webservicen. Side 28

36 7.6.2 Use Cases Use cases beskriver hvordan programmet opfører sig, typisk set fra brugerens synsvinkel. De er black box scenarier og omhandler ikke beskrivelser om hvad der foregår dybt nede i systemet. Følgende er en række usecases som vil blive gennemgået i dette projekt. De er udvalgt fordi de tester høj risiko kravene for systemet. Side 29

37 Use case 1: Opdatering af indhold Goal: Preconditions: Success End Condition: Scope: Failed End Condition: Primary Actor: Trigger: Ændring af bruger navigation under kørsel At webservices og database fungerer. Netværksforbindelse virker. En knap ændrer sit link mens programmet kører. Dette er en blackbox test. Brugeren ser kun brugergrænsefladen. Den gamle side vises stadig, eller ingen side vises. Bruger En administrator ønsker at ændre indholdet. Main Success Scenario: 1. Bruger ser en vilkårlig side. 2. Bruger går væk fra denne side. 3. Administrator ændrer siden brugeren lige så til en anden. 4. Brugeren prøver at navigere hen til den gamle side igen, og får den nye. Extensions: 1) Siden kan ikke vises fordi den ikke findes på den angive lokation. a. En standard fejlside skal vises så brugeren informeres, og klienten rapporterer til centralen at noget er galt. Other information: Prioritet: Høj Performance Target: 1-2 minutter. Frequency: Ofte Side 30

38 Use case 1: Find de 6 nærmeste Goal: Preconditions Scope Success End Condition: Failed End Condition: At få præsenteret de 6 nærmeste seværdigheder i form af en knap hvor på et billede af seværdigheden befinder sig. På knappen skal være et tal imellem 1-6. Knapperne er placeret 3 i venstre side og 3 i højre side. Imellem dem er et kort hvorpå 6 tal mellem 1-6 indikerer hvor seværdigheden ligger. Ved tryk på knappen vises en kort videofilm der præsenterer seværdigheden. At webservices og databaser fungerer. Netværksforbindelse virker. Dette er en blackbox test. Brugeren ser kun brugergrænsefladen. De 6 nærmeste seværdigheder vises korrekt. Efterfølgende præsentation vises korrekt. Billederne vises ikke på knappen. Billederne stemmer ikke overens med seværdigheden. Den forkerte eller ingen film vises. Primary Actor: Bruger Trigger En slutbruger ønsker at se de 6 nærmeste seværdigheder. Main Success Scenario: Brugeren vælger funktionen Se de 6 nærmeste seværdigheder. 6 knapper med tilhørende korrekte billeder, labels, tal og et kort kommer op på skærmen. Brugeren vælger en seværdighed. En kort film bliver præsenteret. Når filmen er færdig vises siden med de 6 seværdigheder igen. Extensions: Siden kan ikke vises fordi den ikke finis på den angive location En standard fejlside skal vises så brugeren informeres, og klienten rapporterer til centralen at noget er galt. Other information: Prioritet: Høj Performance Target: 10 sekunder Frequency: Ofte Side 31

39 Use case 3: Modulariseret opbygning Goal: Preconditions Scope Success End Condition: Failed End Condition: Primary Actor: At generere et modul der er kompileret separat fra hovedprogrammet og indtage det i programmets kørsel At webservices og databaser fungerer. Netværksforbindelse virker og plads på disken. Hovedprogrammet virker. Dette er en blackbox test. Brugeren ser kun brugergrænsefladen. Modulet bliver vist. 1. Modulet bliver ikke vist. 2. Programmet går ned. Hovedprogrammet. Trigger: Main Success Scenario: 1. Administratoren laver et nyt modul. 2. Modulet bliver sendt til klienten. 3. Modulet bliver lagt ind I programmets flow. 4. Modulet bliver vist. Extensions: En slutbruger ønsker at se de 6 nærmeste seværdigheder. 1) Siden kan ikke vises fordi den ikke findes på den angive location a. En standard fejlside skal vises så brugeren informeres, og klienten rapporterer til centralen at noget er galt. Other information: Prioritet: Høj Performance Target: 10 sekunder Frequency: Ofte Side 32

40 8. Design I kravspecifikationen blev der klarlagt hvilke krav der var til programmet. Mulige løsninger til problemerne blev præsenteret i analysen og for hvert problem blev en specifik løsning valgt. Dette afsnit koncentrerer sig om at beskrive hvorledes disse løsninger skal fungere i flere detaljer. 8.1 Database Design Databasen er det persistente lager hvor den aktuelle information i forbindelse med præsentationsstrukturen foreligger. Helt specifik skal der ligge information om knappernes label, deres links og eventuelle ikoner på knapperne. Figur 3 Designet af database i projektet. Side 33

41 Det ovenstående er et database design diagram. Hovedprincippet i dette design er at hver side har en række i Content tabellen. Content tabellens indhold er referencer til unikke id s i de seks andre tabeller Normalform Databasen er normaliseret efter 3. Normal Form for at undgå redundante data og gøre det nemmere at ændre indholdet. 3. normal form karakteriserer sig ved at informationer opdeles i mange tabeller. Disse tabeller har et id for hver tuppel. Ved at samle en række id er i en hoved -tabel (Content), fås en delmængde af alle data der betragtes som at høre sammen. Ved at opdele data i flere tabeller bliver det nemmere at rette på f.eks. stier til billeder og videoer, da hver af disse har bestemte id er. Disse rettelser vil derfor omgående slå igennem for alle sider der bruger disse id er. Hvis andre hoved tabeller, der bliver oprettet senere i projekt forløbet, skal bruge de samme data, kan de blot benytte de eksisterende, og derved undgå redundans. 8.2 Modulariseret opbygning En modulariseret opbygning blev i analysen konkluderet som den bedste løsning. Denne opbygning skal sikre at nye sider der er kompileret post kompile time i forhold til hoved programmet, stadig kan vises under kørsel. Strukturen i programmet må derfor nødvendigvis bestå af en minimal fast del, og en del som er selve siden af præsentationen. En minimal Navigator vil derfor bestå af en del som står for at indlæse nye sider, en del som står for kommunikation med webservicen og en del som står for kommunikation imellem moduler, da disse ikke har evnen til at kommunikere internt. Side 34

42 Navigator klassen indeholder, som vist på billedet ovenfor, en webservice klasse og en controller klasse. Webservicen står for ekstern kommunikation og controller klassen står for præsentation af indholdet. Strukturen på billedet kan ses som container struktur, der viser forholdet mellem children og parents. Navigator er parent, den indeholder en webservice child og et controller child. Controller en er parent til Sider. 8.3 Alon Design pattern Intern Kommunikation Autonomous Linking Object Network 3 design pattern skaber en enkel kommunikationslinie for hele applikationen. En enkel uafhængig klasse agerer som medium for alle objekter og komponenter. Dette inkluderer også moduler. Der er to typer af kommunikation i ALON. Event Baseret og Direkte kommunikation Event Baseret kommunikation Den Event baserede kommunikationsmetode kræver at alle eventlisteners registrerer sig selv som lytter på den globale kommunikations dispatcher. Dette giver dem adgang til at lytte på alle events der udsendes inden for denne eventdispatchers scope. Alle events dispatches også fra den globale eventdispatcher og systemet kan derfor beskrives som en unicast kommunikationsmetode. Når en event sendes ud, opfattes den af alle der lytter til den specifikke eventtype, og kan potentielt ageres på. 3 ALON er udviklet af Alex fra Side 35

43 Figur 4 illustrerer at events udsendt fra et objekt registreres på den globale broker. Fordi de lyttende objekter lytter på brokeren vil disse opdage at eventen er afsendt Direkte Kommunikation Ved direkte kommunikation registrerer objekter sig ved kommunikations mediumet som en service tilbyder. Andre objekter der ønsker at benytte sig af de registrerede objekters metoder kan få en direkte reference til det ønskede objekt via mediumet. Denne metode er direkte fra modul til modul, eller fra objekt til objekt, om man vil. I dette projekt vil det ikke være nødvendigt med direkte kommunikation. Figur 5 viser at instanser af klasser kan registerer visse Services hos den globale broker. Disse services kan bruges explicit af andre klasser, igennem den globale broker. Side 36

44 8.3.3 Event Data Som kommunikationspakke vil der blive benyttet en udvidelse af Event klassen. Udvidelsen vil bestå af en datatype der definere hvilken klasse der har afsendt eventen og et array med argumenter der skal videregives til den eller de objekter der lytter. 8.4 Webservice modulet Hver side skal have muligheden for at kommunikerer med webservicen for. Et webservice kommunikationsmodul vil derfor være bedst implementeret i Navigatoren, så moduler og andre komponenter kan kommunikerer med via ALON. Figur 6 Viser hvorledes ALON bruges til at kommunikere imellem moduler, og http benyttes til kommunikerer med webserveren. Via den interne kommunikations service skal webservice kommunikations klassen modtage ordrer som initierer kommunikation med den egentlige webservice. Når et svar er modtaget skal den via samme kommunikationskanal sende dette videre. Webservice klassen er et godt sted at benytte direkte kommunikation, for at sikre at andre moduler ikke modtager den forkerte information. Det er dog ikke nødvendigt for denne udgave af Navigatoren, og derfor vil den simple Event baserede kommunikation anvendes. 8.5 Design venlig At lave sider editerbare for visuelle designere er lig med at lave sidestrukturen så enkel som mulig men samtidig beholde den fulde funktionalitet. Som nævnt i analysen opnås dette ved code-behind teknikken. Side 37

45 Figur 7 Viser forholdet mellem de forskellige filtyper. Actionscript 3 filen definerer package og klassen. MXML instantierer klassen. Sidst men ikke mindst bliver, klassen stylet af CSS filen. Den generelle funktionalitet stilles til rådighed via codebehind klasserne. Selve strukturen leveres fra MXML dokumentet, og udseende defineres i CSS dokumenterne. I analysen blev der konstrueret en use case kaldet Find de 6 nærmeste, fremover kaldet FDSN. For at gøre FDSN design venlig skal to AS3 klasser laves. Disse er en Sights klasse og en videoknap klasse. Side 38

46 Figur 8 Sightsmodulet indeholder en række videoknapper som ilustreret på figuren. Ved at stille disse klasser til rådighed for en editor vil den være i stand til at lave andre SigthsModule s som varierer fra den originale ved anderledes placering af knapper og flere eller færre af dem. I dette projekt vil en mindre udgave af FSDN blive implementeret. Denne udgave kaldes Vis seks Film, som begrænser sig til at demonstrere databasen, webservice kommunikationen og Navigatoren. Side 39

47 8.6 Klassediagram Figur 9 Klassediagram over Navigatoren. MainNavigator benytter GlobalBroker, Combroker og ObjectDataEvent til ALON kommunikation. FlexToWebservice er Navigatorens kommunikationsdel til webservicen på klienten. ControllerModule bruges af Navigatoren til at skifte imellem siderne som er SightsModule, MenuModule og MovieModule. Side 40

48 9. Implementation 9.1 Autonomous Linking Object Network Design Pattern ALON benytter en global EventDispatcher som alle moduler kan bruge til at sende og modtage Events. broker er en public instans af Combroker, en EventDispatcher klasse. Ved at gøre brokeren public kan den tilgås af alle objekter i Navigatoren. Derudover er den globale broker static, hvilket gør, at den bliver instantieret når Navigatoren starter. Andre objekter kan afsende og lytte til events på brokeren. public static var broker:combroker = new ComBroker(); Når et modul skal lytte på, eller sende, en event, skal det gøres for en bestemt event type. For at gøre det nemt at finde den korrekte event type er alle disse defineret i én enkel fil kaldet EventsGlobals. Når objekterne skal lytte til events på brokeren tilføjes dette i klassen. GlobalBroker.broker.addEventListener(EventsGlobals.EventName, eventnamehandler); Når eventen indtræder, vil den lokale metode angivet af eventnamehandler blive kaldt, og håndterer situationen. Når objekter skal sende events skrives dette i metoden. GlobalBroker.broker.dispatchEvent( new ObjectDataEvent(EventsGlobals.EventName,this,new Array(args) ); Side 41

49 9.2 Controller Modulet Controller modulet er det modul der indlæser de sider brugeren ønsker at se. Controller modulet er loadet ind i hovedprogrammet via en ModuleLoader komponent. Dette er i sig selv ikke nødvendigt, men gør programmet mere fleksibelt, da det giver mulighed for i fremtiden at indlæse nye og mere smarte controller moduler til Navigatoren hvis den skal have en anden anvendelse. Controller modulet kommunikerer, ligesom resten af systemet, via ALON. Sideskift sker ved at en bruger trykker på en knap. Denne knap sender en besked til Controlleren at der skal ske et sideskifte. Knappen sender også, via DataObjektEvent datatypen, et link til hvilken side der skal skiftes til. Når Controlleren modtager denne event unloader den siden, og indlæser den nye med en overgangseffekt. Overgangseffekten er implementeret som en erstatning for transitions da disse ikke kan udføres mellem modulskift. 9.3 Webservice modulet Applikationer udviklet i FF implementerer webservices ved brug af deres WSDL-filer. WSDL-filer er et XML-baseret dokument der beskriver en model for webservicen. public function callwebservicemethodandargs(methname:string,args:array):void{ var methodname:string = methname; ws = new WebService(); ws.wsdl=" ws.addeventlistener(faultevent.fault,onfaultevent); ws.addeventlistener(loadevent.load,onwsdl); op = ws.getoperation(methodname) as Operation; op.arguments = args as Object; ws.loadwsdl(); } I koden ovenfor bliver et webservice objekt instantieret ud fra WSDL-filen. Dette sker ved at adressen til WSDL en bliver sat i webservice objektet ws. Side 42

50 Derefter tilføjes en Load eventlistener som aktiverer funktionen onwsdl når WSDLfilen bliver indlæst. Webservice objektet bliver derefter opsat til at udføre operationen givet af variablen methodname med argumenterne args. Til sidst bliver webservicen kaldt med den opsatte konfiguration. Når resultatet kommer tilbage fra webservicen bliver onresult funktionen kaldt. public function onresult(event:resultevent):void{ var mydoc:xmldocument=new XMLDocument(event.result.toString()); var resourcexml:xml = new XML(event.result.toString()); var resourcelist:xmllistcollection = new XMLListCollection(resourceXML.children()); GlobalBroker.broker.dispatchEvent( new ObjectDataEvent(EventsGlobals.UPDATE_RETRIEVED,this, new Array(resourceList) ) ); } Ovenstående kode viser at onresult funktionen modtager en String som castes til et XMLDocument. Ud fra XMLDocument udtrækkes en XMLListCollection som sendes, via ALON, til det lyttende modul. 9.4 Opdatering af indhold Dette afsnit beskriver den implementationen på webserver siden der udtrækker de relevante data, når en ny side indlæses i Navigatoren. Siden kontakter webservicen for at få information til at udfylde dens containers (knapper, tekstfelter, billedholdere osv.) udfyldt. Denne implemenation af webservicen finder ikke de seks nærmeste, men derimod alle seværdigheder. Det er dog ikke af betydning for denne implementation, da det der ønskes testet blot er om datastrukturen, kommunikationsformen og databinding på Navigatoren fungerer efter hensigten. Side 43

51 SELECT FROM JOIN INNER JOIN Resource.ResourcePath, Page.PageName, Label.LabelName, Icon.IconPath, ResourceLink.ResourceLinkName [Content] INNER JOIN Resource ON [Content].ResourceID = Resource.ResourceID INNER Page ON [Content].PageID = Page.PageID Label ON [Content].LabelID = Label.LabelID INNER JOIN Icon ON [Content].IconID = Icon.IconID INNER JOIN ResourceLink ON Page.ResourceLinkID = ResourceLink.ResourceLinkID WHERE ([Content].PageID IN (SELECT PageID FROM Page AS Page_1 WHERE (PageName = ' Something '))) Denne ovenstående SQL henter sidens navn, label og sti til ikonet og videoen. Der laves inner joins med Content tabellen på Ressource, Page, Label, Icon og ResourceLink tabellerne. Referencerne fra Content tabellen er Foreign Keys til rækker i de andre tabeller. Med Inner join hentes referencerne, og en der fås en tabel med det reelle indhold for alle sider i programmet. WHERE udsagnet vælger dem med det ønskede sidenavn. Det endelige resultat er alle de knapper og links der hører til den pågældende side. 9.5 Modularisering Den modulariserede opbygning er implementeret med en ModuleLoader i Navigator programmet. Moduler implementeres med modul klassen fra FF. Derefter kan det kompileres på to forskellige måder. Den første måde optimerer modulet til Navigator projektet. Bygges modulet på denne måde medtages de biblioteker der allerede benyttes i Navigatoren ikke i modulet. Dette medfører at modulet får en mindre filstørrelse. Til gengæld kan det kun bruges af Navigatoren. Den anden metode undlader denne optimering, og gør modulet større men også brugbart i alle programmer. Side 44

52 Der er ikke nogen umiddelbar fordel i at have moduler der kan benyttes af andre applikationer i dette projekt, så alle modulerne blev opbygget efter første metode. Side 45

53 10. Test Test Systemet Testen er udført af udvikleren på et system med følgende programmer. Windows Vista - 32 bit Adobe Integrated Runtime 1.5 (AIR) Adobe Flash Player 10 FlexBuilder 3.2 Visual Studio 2008.Net 3.5 Frameworket Microsoft SQL Server Management Studio Express Det bør nævnes at der var mange andre programmer installeret på test systemet, men disse burde ikke have nogen indflydelse på de udførte tests. PC en er en bærbar Dell XPS M1530 med 2,5 Ghz Duo Core CPU, 4 GB RAM og nvidia Geforce 8600M grafikkort. For at reproducere disse tests skal det ovenstående være installeret på et system der ydelsesmæssigt svarer til det samme som test maskinen, pånær Windows Vista, der kan erstattes med Windows XP Test af usecases I analyse afsnittet blev der beskrevet en række use cases. Disse havde til formål at beskrive de essentielle funktionaliteter for Navigatoren. For at verificere om disse er implementeret korrekt køres et testforløb der undersøger om det faktiske resultat er lig det ønskede resultat. Side 46

54 Opdatering af indhold Formål: Indholdet bliver indlæst på siden hver gang denne skal vises. Dette sker ved at kalde webservicen som henter de nødvendige informationer fra databasen og sender dem til Navigatoren. Informationerne er i XML format som Navigatoren indsætter i de korrekte containers. Denne test undersøger om knapperne kan ændres til at pege på nyt indhold mens Navigatoren kører, i henhold til krav Denne test vil indirekte også verificere at webservice modulet og databasen fungerer efter hensigten Test Strategi 1. Start Webservicen InfoFlex i Visual Studio Start Navigatoren i FlexBuilder. 3. Naviger til Sights menuen i Navigatoren. 4. Se en film. 5. Gå tilbage til hovedmenuen 6. Omdøb den viste film til en anden i databasen med SQL Server Management Studio Express. 7. Gå tilbage til Sights menuen. 8. Tryk på den samme knap igen. 9. Den viste film skulle nu være en anden Test Forløb 1. Webservice og Navigator blev start 2. Første film (Amagerstrand) blev vist i Sights menuen 3. Tilbage til hoved menuen 4. Microsoft SQL Server Management Studio Express (MSSMSE) blev brug til at ændre stien for AmagerStrandPark.flv til Borsen.flv en anden video fil på harddisken. 5. Gik til Sights menuen 6. Valgte præsentation af Amager strandpark. Side 47

55 7. Børsen blev præsenteret Resultat Det viste sig at være muligt at ændre indholdet i programmet runtime. Databasen og webservicen fungerede også efter hensigten. Testen endte derfor i en succes Vis seks film Formål Vis seks film funktionen kalder webservicen som returnerer seks film præsentationer i xml format. Knapperne skal have labels, cirkler med tal og billeder som beskriver filmen. Når filmen er færdig skal Navigatoren gå tilbage til det forrige skærmbillede. Denne test undersøger om Sights funktionaliteten kan bygges i Flex Test Strategi 1. Start Webservice 2. Start Navigator 3. Vælg Sights menuen 4. Vælg en videofilm 5. Se filmen færdig 6. Filmen bør returnere til Sights skærmen Testforløb Første gennemløb. 1. Webservice og Navigator startet 2. Sights menu valgt billeder loades efter siden vises 3. Film valgt 4. Film Vises 5. Efter film vises kommer sort skærm. Filmen går ikke videre til forrige menu. Side 48

56 Resultat Sights siden bliver præsenteret for tidligt, sandsynligvis fordi den ikke er opsat til at vente på billederne. Seks film bliver præsenteret korrekt og det er muligt se dem. Testen betegnes som en succes Modulariseret opbygning Formål At verificere om den modulariserede opbygning tillader at Navigatoren benytter nye sider der er udviklet efter Navigatoren er installeret på test systemet.. Modularisering opfylder krav i kravspecifikationen. Den modulariserede opbygning er implementeret med et hovedprogram som kaldes for Navigatoren, og med underliggende sider opbygget af modul komponenter fra FF. Navigatoren indlæser siderne angivet i links fra knapper i selve Navigatoren eller andre moduler. Disse links er hentet fra databasen. Disse sider ligger i en undermappe kaldet /Modules Test Strategi 1. Kompiler Navigator 2. Installer Navigator 3. Kompiler et nyt modul 4. Indsæt modulet i /Modules mappen i Navigatoren installationsmappe 5. Opsæt Navigatoren til at benytte det nye modul med MSSMSE. 6. Gå til det nye modul i Navigatoren Test Forløb 1. Navigatoren kompileres. 2. Det nye modul oprettes i et nyt projekt. Under kompilerings egenskaber vælges at modulet skal kompileres så det kan fungere med alle applikationer. 3. Det kompilerede modul flyttes til mappen hvor programmets andre moduler er placeret. 4. Navigatoren startes. 5. MSSMSE bruges til at ændre et link i Navigatoren til det nye modul. 6. Det nye modul vælges i Navigatoren Side 49

57 7. Det nye modul vises Resultat Det nye modul der blev kompileret efter Navigatoren blev succesfuldt vist og modulariseringen af siderne er implementeret så det opfylder Testen endte i succes Kapacitets test Formål Som nævn tidligere har applikationer på Flash Platformen problemer med memory leaks 4. I FlexBuilder findes et værktøj der hedder Memory Profiler, som kan bruges til at se hvor mange instanser der er af hver klasse og hvor meget hukommelse de hver især bruger. Hvis Navigatoren har memory leaks vil den med tiden, på et hvilken som helst givent system, begynde at køre langsomt, og til sidst gå helt i stå. For at undgå dette scenarie vil Navigatoren blive testet med Memory Profileren for at undersøge om der er memory leaks Test Strategi 1. Start Webservice 2. Start Navigator 3. Gå til Sights 4. Se en film 5. Observer status på Memory Profileren. 6. Gentag punkt 3-, et antal gange. 7. Observer status på Memory Profileren. 8. Hukommelses Forbruget bør ikke være øget i takt med gentagelserne Test Forløb Første gennemløb. 4 Memory Leak: En fejl i en program der forhindrer at hukommelse bliver frigivet når det ikke længere bruges. Side 50

58 1. Webservice og Navigator startet 2. Sights vælges 3. Film vælges 4. Det observeres på MP en hvor mange at instanser der er af videofilm klassen 5. Film køres færdig og vælges igen. 6. Punkt 3-5 gentages et par gange 7. Det observeres at der er alt for mange instanser af video film og Sights klasserne. Ifølge MP en bliver en række instanser ikke opsamlet af GC en. Dette kan skyldes at instanserne indeholder EventListeners der stadig er aktive. Ved at fjerne disse EventListeners gives GC en mulighed for at fjerne instanserne, og derved forhindre memory leaks med den pågældende klasse. Figur 10 Memory Profiling: Dette memory snapshot er taget mens Navigatoren står i hovedmenuen. Der bør ikke være nogen instanser af klassen SightsMovie. Alligevel kan vi se at alle 3 brugte instanser stadig er i live i hukommelsen. Et eller andet gør at GC en ikke opsamler dem. Alle video klasserne sættes til at fjerne eventlisteners inden de unloades. Andet gennemløb. 1. Webservice og Navigator startet 2. Sights vælges Side 51

59 3. Film vælges 4. Det observeres på MP en hvor mange at instanser der er af SightsMovie klassen 5. Film køres færdig og vælges igen. 6. Punkt 4 og 5 gentages et par gange 7. Det observeres at der ikke er nogen instanser af SightsMovie klassen. Figur 11Memory Profiler: SightsMovie har I programmets levetid været i 3 instanser, men er nu på 0 instanser. Det viser at GC en har fjernet de ubrugte instanser. Der er dog stadig for mange instanser af SightsModule, som præsenterer de seks film. Dette skyldes at denne klasse er langt mere kompleks, og indlæser blandt andet billeder til ikoner på knapperne runtime. Til dette benyttes en open source komponent der er skyld i en del af SightsModule s memory leaks memory leaks. Figur 12Memory Profiling: Degrafa komponenten står for 18% af det samlede hukommelses forbrug, på trods af den kun tegner 6 cirkler for hvert Sights Module. Side 52