Indholdsfortegnelse Indledning...4 Metode...4 Disposition...5 Kodeeksempler...5 Teori...6 Objektorienteret Programmering...6

Transkript

1 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) Indholdsfortegnelse Indledning...4 Metode...4 Disposition...5 Kodeeksempler...5 Teori...6 Objektorienteret Programmering...6 Abstraktioner...6 Indkapsling...7 Nedarvning...7 Polymorfi...8 Model-View-Controller...9 Designproces...11 Første fase...11 Anden fase...14 View...15 Controller...15 Model...15 Opsummering...16 Sidste fase...17 Kravspecifikation...17 Struktur og fordeling af ansvar...20 Model...20 Model.as...20 Storage.as...21 View...21 TVGUI.as...21 Messages.as...22 Streamer.as...22 Controller...22 DocumentClass...22 Klasse-, sekvens og tilstandsdiagram...23 Realisering og Implementering...24 Fleksibel kode...24 Events og Asynkron Data...24 Grafisk Brugerflade og SWC...25 Hvordan fungerer SWC...25 Implementering af SWC...26 Produktion af grafik og SWC...27 Opbevaring af Data...29 XML...29 Begrænsninger...30 Streaming...30 Side 1 af 42

2 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) RTMP...31 NetConnection...31 NetStream...33 NetStreamClient...34 NetStatusEvent...34 Internettet faktorer der spiller ind på en stream...34 Fejlhåndtering...36 SecurityErrorEvent...36 AsyncErrorEvent...36 Arbejdsprocessen...36 Værktøjer...37 Flash Builder & AS Eclipse udvidelser...38 Subclipse...38 ASDoc...39 ArgoUML og OmniGraffle...40 Udvidelser af programmet...40 Refleksion...41 Litteratur...42 Bilag...43 Tegn indeholdt i opgaven: (heraf består tegn af kode eksempler). Indholdsfortegnelse og litteraturliste er ikke inkluderet. Opgaven er skrevet af: Peter Wolff Del Pin (5-7, 14-17, 24-26, 35-36) Simon Christian Clausen (8-10, 18-20, 31-34, 37-39) Aske Ryge Holm (11-13, 21-23, 27-30, 40-41) Siderne i parentes angiver de enkeltes ansvarsområde, resten er fælles. Side 2 af 42

3 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) Indledning Vi vil i følgende opgave beskrive, hvordan vi har udviklet et program til eksamen i faget Digitale Modeller på Informationsvidenskab på Aarhus Universitetet. Vi har valgt at udvikle en digital repræsentation af et TV, der er i stand til at streame video fra Danmarks Radios (herefter DR) live TV-stream på internettet. DR's egen afspiller er at finde på På fjernsynet er det muligt at bruge de mest almindelige kendte funktioner. Man kan tænde og slukke, skifte op og ned på kanalerne, ændre lydstyrke og mute fjernsynet. Dette foregår ved at benytte knapperne, der sidder på fjernsynet, da fjernbetjening naturligvis ikke er mulig. Programmet vi har udviklet, er ikke kommet til eksistens på baggrund af et egentligt behov eller en ide, der relaterer sig til en virkelig brugssituation. Ud over dette har valgt at udvikle et program med begrænset omfang for at være sikre på, at vi kan stå med et færdigt program ved projektets slutning, der i så højt omfang som muligt viser god programmeringsskik og korrekt implementering af principperne bag Objektorienteret Programmering. Vi besluttede os tidligt for, at vi hellere ville være i stand til at præsentere et fuldt ud fungerende program, der opfyldte dette, end en nok så korrekt, men halvfærdig implementering. Programmets hovedformål tjener altså at fungere som en demonstration. På trods af det begrænsede omfang og mindre prioriterede fokus på en bestemt brugssituation, mener vi dog stadig, at programmet tjener et faktisk formål og viser potentiale for fremtidige udvidelser og forbedringer. Den endelige udgave af programmet er at finde på CD'en i bilag nr. 4 samt på Metode Vi har valgt at inddele designprocessen og implementeringsprocessen i to separate dele. Dette har vi gjort af praktiske grunde i forhold til udformningen af opgaven og fordeling af gennemgang af de relevante områder. I systemudviklingen bliver implementering og design nødvendigvis blandet Side 3 af 42

4 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) sammen, og der findes flere forskellige udviklingsmodeller, der baserer sig på denne måde at arbejde på. Vi vil komme nærmere ind på overvejelser omkring vores udviklingsproces i afsnittet arbejdsprocessen. Selvom vi har delt disse to områder op, vil der dog stadig være steder i opgaven, hvor der vil blive inddraget beskrivelser og overvejelser, der ikke har direkte forbindelse til det aktuelle afsnit. Dette gør vi for at danne helhed i det pågældende afsnit, og der kan derfor visse steder forekomme gentagelser. Vi går i opgaven ud fra, at læseren har et vist kendskab til populære programmer og terminologien benyttet inden for dette fag, så som ActionScript og Photoshop. Dog vil vi, via fodnoter, uddybe forkortelser og udtryk, som vi mener, ikke nødvendigvis ligger centralt i opgavens rammer. Disposition Opgaven er overordnet delt op i tre; Vi starter med kort at gennemgå relevant teori for at skabe perspektiv i opgaven. Dernæst gennemgår vi designprocesserne, der har ledt frem til vores endelige realisering, som vi gennemgår centrale punkter af i sidste del af opgaven. Slutteligt vil vi opsummere og reflektere over projektet og processen. Kodeeksempler Eksemplerne på vores kode vil ofte være trimmet for kode, der er overflødig i forhold til eksemplet. De kan derfor fremkomme ukomplette i forhold til korrekt programmering. Vi gør dette for at fremhæve og tydeliggøre netop det eksempel, vi belyser. Kodeeksemplerne i opgaven er skrevet i Courier New fonten i størrelse 10, hvor syntaks er farvekodet efter Flash Builders standardindstilling, og de er indrammet i en kasse med en sort border. Side 4 af 42

5 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) Teori Objektorienteret Programmering Objektorienteret programmering (herefter OOP) er et programmeringsparadigme, hvor alt data og logik deles ind i enheder, objekter, med tilhørende metoder, der gør det muligt for andre dele af programmet at tilgå dette data på en struktureret måde. En af fordelene ved OOP er, at denne inddeling i objekter gør det nemt at genbruge kode. Der kan laves uendeligt mange objekter ud fra én klasse. Ud over dette muliggør OOP, at en programmeringsopgave kan deles ud til flere mennesker, der arbejder på det samme projekt. Hvis man bliver enige om hvilke data, der gives til og modtages fra et objekt, og hvilket format (datatype) denne optræder i, skal en programmør kun forholde sig til dette. Hvis man arbejder med et objekt, er det ikke nødvendigt at vide hvordan det fungerer internt. Således kan man, hvis man skriver koden til et objekt, gøre det efter personlig præference, så længe man holder sig inden for de aftalte rammer for dataudvekslingen. Ifølge William B. Sanders og Chandima Cumaranatunge er de fire grundlæggende principper i OOP 1 : Abstraktioner Indkapsling Nedarvning Polymofi Abstraktioner At lave en abstraktion af noget er at uddrage nogle essentielle karakteristika for fænomenet, der kan beskrive noget generelt om dette. Dette er essentielt, når man programmerer, for hver gang vi programmerer et objekt, der på nogen måde har forbindelse til virkelighedens verden, så udvælger vi hvilke detaljer, vi vil have med og dermed også hvilke detaljer, vi ikke vil have med. Det kan 1 Sanders, W. & Cumaranatunge, C., 2007, s. 11 Side 5 af 42

6 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) ikke lade sig gøre at indfange alle detaljer om noget objekt, der findes i virkelighedens verden, og det er heller ikke nødvendigt. Hvis vi skal lave et program, der kan simulere en bil, kan vi definere alle de karakteristika, vi vil have med i programmet. Vi kan definere hvilke funktioner den har: at køre, bremse, tænde og slukke lyset, dytte osv. samt de variabler den har: Brændstof, fart, farve osv. Selvom vi modellerer alt dette efter en virkelig bil, vil den computerskabte aldrig blive til netop dén bil. Det vil altid kun være en abstraktion bestående af de detaljer, vi har vurderet relevante og tilføjet til abstraktionen. Og der vil altid være detaljer, som vi har valgt ikke at tage med, som f.eks. en ridse i lakken, eller et nedrullet vindue, fordi de ikke tjener noget formål i den sammenhæng, vi laver computerprogrammet i. Indkapsling Det, der skaber objekterne i objektorienteret programmering, er indkapslingen 2. Hvis alt data i et program kan tilgås og ændres fra alle steder i programmet, kan den mindste fejl få vidtrækkende og uoverskuelige konsekvenser. Dette undgås med indkapsling, hvorved visse dele af koden gøres utilgængelig for andre dele af koden. Derpå kan der laves metoder, der på en struktureret måde kan hente data eller ændre data, hvis dette er meningen. Alt hvad dette stykke kode indeholder, som ikke skal bruges uden for netop dette stykke kode, holdes skjult og kan altså ikke tilgås. Dette kaldes black boxing. Et stykke kode, der har til opgave at udføre en bestemt funktion, skal ikke kunne ændres på andre måder, end denne funktion kræver. En given funktion er et afgrænset system. Det tager imod input fra sin omverden, og det giver output til sin omverden, men omverdenen kan hverken se eller forstyrre den proces, der foregår inde i den givne funktion. Postvæsnet kan tjene som eksempel på indkapsling. Postvæsnet tager breve og pakker som input og giver breve og pakker som output. Hvis man sender et brev fra Århus adresseret til Viborg, er det eneste man ved om denne proces, at brevet sendes fra Århus og ender i Viborg. Man er ikke vidende om, hvordan brevet havner der, og hvad der sker med det undervejs, og man kan heller ikke påvirke processen. Dette er heller ikke nødvendigt, idet den eneste intention med at sende brevet er, at det skal ende i Viborg. Resten er black boxed, indkapslet, og så længe dét fungerer, er alt andet overflødigt. Nedarvning Nedarvning betyder, at en klasse nedarver funktionalitet fra en anden klasse. Man siger, at 2 Sanders, W. & Cumaranatunge, C., 2007, s. 15 Side 6 af 42

7 Digitale Modeller, F11, Informationsvidenskab, Aarhus Universitetet. Eksamensopgave 7. Juni Peter Wolff Del Pin ( ), Simon Clausen ( ), Aske Ryge Holm ( ) underklassen nedarver fra superklassen. I stedet for at skrive koden for al den funktionalitet man vil have i en klasse, kan man ved hjælp af extend, tildele alle egenskaberne fra superklassen til dens underklasse. Dette sker ved, at al superklassens funktionalitet importeres af programmet, så programmet altså kan benytte sig af al den kode, der findes i superklassen. Man kan enten nedarve fra en klasse, man selv har lavet, eller fra én af de indbyggede klasser i ActionScript. Ved at benytte nogle af ActionScripts indbyggede klasser slipper man for at bygge en masse basisfunktionalitet op fra bunden. Bagsiden af medaljen er, at programmet kommer til at fylde mere. For når programmet skal kunne benytte sig af funktionaliteten fra superklassen, skal den selvfølgelig også huske al koden. Det gælder også for alle de dele af superklassen, som man ikke rent faktisk benytter sig af. Pladsmæssigt svarer det altså til, at man manuelt skrev al koden for superklassen ind i programmet. I de fleste situationer er vi ligeglade med de par kilobyte, det fylder ekstra, men man kan forestille sig, at man i visse mobile og ultrakompakte enheder, som f.eks. microchips, kunne være interesseret i at spare den lille smule plads. Polymorfi Polymorfi gør det muligt at lave variabler, funktioner og objekter, der har flere forskellige former på én gang. Dette gøres ved hjælp af en abstrakt superklasse. Underklasser kan derefter overskrive funktionerne og give dem ny funktionalitet. Dette giver mulighed for at lave flere forskellige underklasser med forskellig funktionalitet til den samme superklasse.vi gør ikke brug af polymorfi i opgaven, og derfor beskrives begrebet ikke yderligere. Side 7 af 42

8 Model-View-Controller 3 Model-View-Controller, herefter MVC, er et designmønster, der kan indeholde flere designmønstre, beregnet til udformning af programmer med en brugergrænseflade, der består af tre dele; Model, der indeholder programmets data og logik, View, der håndterer brugergrænsefalden og Controller, der håndterer brugerinputs fra View. Kilde: Sanders, W. & Cumaranatunge, C., 2007 Model indeholder reference til View. Den indeholder og tolker den rå datamængde, og besvarer forespørgsler om tilstande fra View. Derudover reagerer den på forespørgsler om at ændre tilstand fra Controller. Den registrerer altså hvilken tilstand den pågældende del af programmet er i. View er den visuelle repræsentation, og det er her, brugeren interagerer med programmet. View tager imod alle input fra brugeren i form af muse- og tastaturaktiviteter og giver alle output i form af lyd og billeder. Der kan i et program være adskillige Views, der henter relevante data fra Model, og viser dem for brugeren. Controller fortolker de brugerinput, den får fra View, og giver besked til Model om at foretage de nødvendige ændringer. Den er altså bindeledet mellem Model og View. Relationen mellem Model og View, fungerer stort set som relationen mellem concrete subject og concrete observer i et observer pattern. Når Model opdateres, dispatcher den et event, som View 3 Sanders, W. & Cumaranatunge, C., 2007, s. 11 Side 8 af 42

9 lytter efter, og derefter ændrer sig, ved at hente den relevante data fra Model, alt efter hvilke ændringerne der er sket i. Side 9 af 42

10 Designproces Første fase Projektet tog sin begyndelse i en øvelsestime. Vi fik til opgave at udvælge en case, der kunne repræsenteres af et IT-system med en række use cases. Vores case var på dette tidspunkt tænkt som et fjernsyn med lyd og billeder. Den blev styret af en fjernbetjening, der havde følgende knapper: on/off, tallene fra nul til ni, kanal op, kanal ned, volumen op, volumen ned og mute. Vi regnede fra starten med, at denne case skulle programmeres på et senere tidspunkt, så vi holdt os til funktionalitet, vi så os i stand til at implementere, og fravalgte altså bevidst ting som tekst-tv og forskellige menu-systemer. Brugergrænsefladen skulle se ud omtrent som på nedenstående tegning. Kilde: Egen tilvirkning Vi valgte at lave en udførlig forklaring af al funktionalitet, så vi var enige om hvad vi havde med at gøre og så der ikke opstod misforståelser. Vi beskrev fjernsynets(og fjernbetjeningens) funktionalitet på følgende måde: Volumenkontrol - Funktion der enten skruer op eller ned for volumen på tv et. Tv et skal være tændt, for at volumen vil blive ændret. Udover at skrue volumen og eller ned, kan man ved tryk på Mute slukke for lyden, og ved efterfølgende tryk tænde den igen. Kanalskift - Funktion der kan udføres på 2 måder: Enten skiftes der direkte til en kanal ved at trykke på et tal, eller der kan scrolles til kanalen ved at trykke x antal gange på kanalop eller kanalned. Tv et behøver ikke nødvendigvis være tændt, da det ved tryk på enten et tal, kanalop eller kanalned vil blive tændt. Side 10 af 42

11 Vi havde altså på dette tidspunkt endnu ikke forholdt os til hvor mange kanaler der skulle være, hvor Ud fra vores use cases lavede vi en liste over alle de metoder og klasser vi mente programmet skulle indeholde: Funktionalitet i TV og fjernbetjening fordelt på klasser: Video setchan(channel:int):void getchan():iunt Sound setvolume(volume:uint):void getvolume():uint mute:boolean TVGUI setchan(channel:uint):void setvolume(volume:uint):void showmute(mute:boolean):void Remote Intet interface. Ekstra klasser til implementering i AS: Reciever Modtager events fra Remote og fordeler dem til Video, Sound og TVGUI. Modtager referencer til disse tre samt Remote fra DocumentClass. DocumentClass Sørger for at tilføje elementer til displaylisten og placere dem på scenen. Vi lavede to diagrammer over programmet. Et klassediagram, der viser alle klasserne og deres Side 11 af 42

12 respektive metoder i relation til hinanden og et sekvensdiagram over en specifik use case, hvor der blev tændt for fjernsynet, skruet op, skiftet kanal, mutet og til sidst slukket. Vores program var på dette tidspunkt ikke bygget op efter noget pattern. Begge diagrammer ses nedenfor. Side 12 af 42

13 Anden fase I anden fase valgte vi at implementere MVC i programmets struktur for at adskille data, funktionalitet og design. Det betød at vores klassediagram skulle ændres radikalt. Det nye klassediagram ses herunder. Klassediagram der implementerer MVC. Klasserne TVGUI, ChannelDisplay og Messages er alle dele af Viewet. Fjernsynet havde i forbindelse med denne omstrukturering fået en del nye detaljer. For det første var designet ændret, så der nu ikke længere var en fjernbetjening, men blot knapper på fjernsynet. Vi havde også midlertidigt erstattet idéen om levende billeder og lyd, med statiske billeder som ses nedenfor. Dette gjorde vi for at kunne fokusere på programmets struktur, og få et velfungerende dummyprogram, før vi begyndte at arbejde med muligheden for at implementere egentlig video. Side 13 af 42

14 Desuden udbyggede vi skærmvisningen til ikke kun at være et tv-billede, men også de små beskeder, der viser hvilken kanal og hvilket lydniveau, man befinder sig på. Tre billeder til at repræsentere henholdsvis DR1, DR2 og tomme kanaler. View Viewet er delt op i tre dele. TVGUI, ChannelDisplay og Messages. TVGUI er selve den grafiske repræsentation af fjernsynet inklusiv knapperne, som brugeren kan trykke på med musen. Disse knapper stammer fra klassen Button. ChannelDisplay er selve skærmen, hvor, i dette tilfælde, billederne vises. Det er også her, lyden ville have været, hvis vi havde haft lyd med på dette tidspunkt. Messages er den del af Viewet, der håndterer de små beskeder, der vises på skærmen, når man skifter kanal, lydstyrke eller muter. Controller Controlleren står for at formidle input fra brugeren, der kommer ind via TVGUI, videre til Model. Model Hvis man sammenligner det første og det andet klassediagram, kan man se, at ansvar for opbevaring af data er flyttet til Model. Dermed er det lettere at udskifte f.eks. Views. Model har ansvaret for at fortolke de inputs den får fra brugeren via Controller og dispatche et event, så View opdateres. De specifikke ansvarsområder i MVC bliver uddybet i afsnittet om 3. fase. Side 14 af 42

15 Opsummering Alt dette blev til et velfungerende program, der kunne alle de ting, der er beskrevet ovenfor. Programmet er tilgængeligt online 4. GUI en, der ses i linket, var dog ikke finpudset rent grafisk, og der var stadig en smule uønskværdig adfærd. For det første var der endnu ikke sat en timer på de små grønne tekster, der signalerede kanal- og volumenskift. Derfor blev disse på skærmen resten af runtime, også mens fjernsynet var slukket. Desuden tjekkede Controller ikke om fjernsynet var tændt, inden det ændrede tilstand i Model. Derfor kunne det lade sig gøre at skifte kanal, volumen og mutetilstand, selvom fjernsynet var slukket. Dette vil måske ikke nødvendigvis betragtes som en decideret fejl, men vi har modelleret vores program efter rigtige fjernsyn, og forsøgt at efterligne disses funktionalitet, og når rigtige fjernsyn er slukkede tager de ikke mod andre input end tænd. 4 Side 15 af 42

16 Sidste fase Dette er udgangspunktet for den endelige produktion af programmet. Som vi nævner senere, har der været mindre udviklinger efter vi nåede dette punkt, men forklaringerne til programmet samt diagrammer repræsenterer den endelige version. Kravspecifikation Dette er vores endelige kravspecifikation. Den er opbygget som én stor if-sætning, der viser hvad der sker i en hvilken som helst situation, når der trykkes på hver af knapperne. Tænd/sluk-knap: Hvis fjernsynet er slukket Fjernsynet tændes Programmet henter kanalnummer og volumennivaeu fra XML-filen. [nuværende kanalnummer] i øverste venstre hjørne i 4 sek Hvis fjernsynet er tændt Fjernsynet slukkes Øverste højre hjørne ryddes for tekst Øverste venstre hjørne ryddes for tekst Kanal op-knap: Hvis fjernsynet er slukket Intet sker Hvis fjernsynet er tændt. Hvis kanalnummer er 0-8 Kanalnummeret øges med én Hvis kanalnummeret er 9 Kanalnummeret ændres til 0 Øverste venstre hjørne ryddes for tekst [nuværende kanalnummer] i øverste venstre hjørne i 4 sek Kanal ned-knap Hvis fjernsynet er slukket Side 16 af 42

17 Intet sker Hvis fjernsynet er tændt. Hvis kanalnummer er 1-9 Kanalnummeret mindskes med én Hvis kanalnummeret er 0 Kanalnummeret ændres til 9 Øverste venstre hjørne ryddes for tekst [nuværende kanalnummer] i øverste venstre hjørne i 4 sek Volumen op-knap Hvis fjernsynet er slukket Intet sker Hvis fjernsynet er tændt Hvis volumenniveau er 0-9 Volumenniveau øges med én Hvis volumenniveau er 10 Intet sker Øverste højre hjørne ryddes for tekst [nuværende volumenniveau] i øverste højre hjørne i 4 sek Volumen ned-knap Hvis fjernsynet er slukket Intet sker Hvis fjernsynet er tændt Hvis volumenniveau er 1-10 Volumenniveau mindskes med én Hvis volumenniveau er 0 Intet sker Øverste højre hjørne ryddes for tekst [nuværende volumenniveau] i øverste højre hjørne i 4 sek Mute-knap Hvis fjernsynet er slukket Intet sker Side 17 af 42

18 Hvis fjernsynet er tændt Hvis MUTE er slået til MUTE slås fra Øverste højre hjørne ryddes for tekst [nuværende volumenniveau] i øverste højre hjørne i 4 sek Hvis MUTE er slået fra Øverste højre hjørne ryddes for tekst MUTE i højre hjørne Side 18 af 42

19 Struktur og fordeling af ansvar I følgende vil vi komme nærmere ind på, hvordan strukturen i vores endelige program hænger sammen. Vi gennemgår de forskellige klasser, og forklarer hvad de enkelte gør. Desuden vedlægger vi et UML diagram over programmet for at lette forståelsen af, hvordan elementerne forholder sig til hinanden. I den forbindelse vil vi også her give et kort overblik over, hvilke klasser der instantieres i de forskellige elementer dette er yderligere vist i UML'ens grafik. Overordnet består vores program af 3 pakker - Model, View og Controller. Disse pakker, på nær Controller, indeholder flere klasser, hvis ansvar relaterer sig til pakkerne. Model I Model bliver vores data og programmets tilstand opbevaret. Dette ansvar er fordelt på to klasser. Model.as Model er ansvarlig for at opbevare den nuværende tilstand af programmet. Det er ting som URL'en til RTMP serveren, streamnavne samt kanal- og volumeindstilling. I teorien skal Model holdes fri fra funktionalitet og logik, da det er Controllers ansvar at fortolke bruger input. Vi har dog valgt at tildele Model ansvar for at kontrollere integriteten af data, den modtager både i form af mere direkte kontroller som at volume <= 10 (volume værdien skal være under 10, for at den gemmes) men også indirekte i form af vores strict datatyper; setchan(channel:uint)hvor en kanal på den måde ikke kan have en negativ værdi. Når Model bliver opdateret med data, dispatcher den et event for at fortælle dens omverden, at dens tilstand er blevet ændret. Der er fire typer opdateringer, der relaterer sig til, hvilken data der bliver ændret; kanalskift, volumeændring, tænd/sluk og mute til/fra. Disse er implementeret i konstanter og bliver brugt på følgende måde: public static const VOLUME_UPDATE:String = "volumeupdate"; public static const CHANNEL_UPDATE:String = "chanupdate"; public static const POWERSTATE_UPDATE:String = "powerstateupdate"; public static const MUTE_UPDATE:String = "muteupdate"; dispatchupdate(model.volume_update); dispatchupdate(model.channel_update); Side 19 af 42

20 dispatchupdate(model.powerstate_update); dispatchupdate(model.mute_update); Storage.as Hvor Model har til ansvar at opbevare programmets tilstand imens det kører, har Storage til ansvar at formidle data, der er opbevaret uden for programmet, når det er stoppet. I nuværende implementering gælder det en default indstilling til volume og kanal samt informationerne til stream server og stream navne. Storage har kun til opgave at loade disse data fra en XML fil, fortolke dem og give dem videre til Model. Ved at tage ansvar for at kontakte programmets omverden og lægge det uden for Model, åbner vi muligheden for nemt at kunne udskifte kilden hvorfra og metoden hvorpå, vi henter denne data ind. En mulighed kunne være at Storage får til ansvar at opdatere tilstanden i Model til en ekstern dataopbevaring. Dette kunne gøres, uden at ændre Model, ved at Storage lytter efter opdateringer fra Model, henter data og gemmer disse i det datalager, der nu måtte være valgt til at løse opgaven; eksempelvis en SQL server. View Klasserne i View har til opgave at formidle programmets tilstand, opbevaret i Model, til slutbrugeren. Da vores program er udviklet i Flash og ActionScript, der er et visuelt og præsentationsmæssigt tungt sprog, bærer View klasserne i relativt stort ansvar. Dette ses mest i Streamerklassen, hvor videostreamen bliver håndteret. TVGUI.as Denne klasse fungerer som udgangpunktet for View. Den har til opgave at instantiere og placere alle de grafiske elementer og give brugeren feedback om en eventuelt fejlet forbindelse til streamingserveren. Den giver også en reference til Model (og Stage) videre til Messages og Streamer, så de kan lytte efter events på denne. Ud over dette er den også punktet hvor Controller lytter efter brugerinput på. TVGUI laver instanser af følgende: Messages, Streamer, InfoBox, TVFrameAsset og ButtonsAsset. Side 20 af 42

21 Messages.as Denne klasse har til ansvar at lytte efter opdateringer på Model efter kanalskift, volume ændringer og mute, samt at kontrollere hvor og hvor længe disse beskeder bliver vist på skærmen. Messages opretter instanser af: MuteDisplay, ChanDisplay og VolDisplay. Streamer.as Streamer er central for al håndtering serverforbindelser, video og lyd. Den lytter på Model efter opdateringer for: tænd/sluk, kanalskift, volume ændring og mute til/fra. Når Streamer instantieres, henter den disse data samt information om server URL og stream navne fra Model. Som vi forklarer nærmere i afsnittet om realisering af programmet er NetConnection, NetStream og NetStreamClient centrale for, at Streamer kan løse sin opgave i forhold til at vise videostreamen samt håndtere eventuelle fejl. I denne klasse oprettes en instans af NetStreamClient. Controller Controller fungerer som bindeled imellem View og Model. Den modtager brugerinput på TVGUI i form af MouseEvents og kontrollerer om og hvordan data, og dermed programmets tilstand, skal ændres i Model. Dette kunne eksempelvis være at kontrollere, at der ikke bliver skiftet kanal på tv'et, hvis tilstanden i Model er, at det er slukket. DocumentClass Det overordnede ansvar for at starte programmet op i sekvens, efter events der bliver dispatched, er givet til DocumentClass. Den sørger for at programmets klasser bliver instantieret og sat i gang i rækkefølgen, der er nødvendig. Både TVGUI og Controller kræver en reference til Model, så derfor skal denne instantieres og fyldes med data fra Storage, før de to andre klasser bliver oprettet. Ud over dette sørger DocumentClass også for at tilføje TVGUI til displaylisten og give en reference til stage videre. Side 21 af 42

22 Klasse-, sekvens og tilstandsdiagram De, i forrige afsnit, beskrevne klasser samt resten af programmets elementer er vedlagt i et UML klassediagram. Vi har altså også inkluderet en repræsentation af filerne, der bliver benyttet i programmet. Se bilag nr. 1. Ud over det har vi vedlagt et sekvensdiagram, der beskriver, hvad der sker ved opstart af programmet. Se bilag nr. 2. Slutteligt har vi lavet et tilstandsdiagram over de forskellige mulige tilstande i programmets brugerflade. Se bilag nr. 3. Side 22 af 42

23 Realisering og Implementering I dette afsnit vil vi beskrive nogle af de overvejelser og relevante punkter i realiseringen af programmet. Ud over dette beskriver vi også arbejdsprocesser. Fleksibel kode Vi har i implementeringen af vores projekt forsøgt at gøre vores kode så dynamisk og fleksibel som muligt. Dette både i forhold til dynamisk håndtering af nuværende indhold og funktionalitet, men også med henblik på eventuelle fremtidige udvidelser eller genbrug af kode fra dette projekt i andre. Et eksempel på hvordan vi håndterer nuværende indhold dynamisk ser vi i, hvordan kanalskift fungerer på TV'et. Hvis man skifter op til kanal 10, og prøver at komme et skridt yderligere, ender man på første kanal, osv. Mere specifikt er dette implementeret på følgende måde: switch(e.target.name) { case "chandown": if(_model.getcurrentchan() > 1 && _model.getcurrentchan() <= _model.gettotalchans() && _model.ison){ _model.setchan(_model.getcurrentchan() - 1); } else { _model.setchan(_model.gettotalchans()); } break; case "chanup": if(_model.getcurrentchan() < _model.gettotalchans() && _model.ison){ _model.setchan(_model.getcurrentchan() + 1); } else { if(_model.ison) { _model.setchan(1); } } break; } } Events og Asynkron Data I vores program benytter vi os i høj grad af events som grundlag for funktionalitet. Dette er både på grund af programmets asynkrone natur i forhold til, at vi loader data ind fra programmets omverden, men også for at sikre at programmets byggedele kan forblive uafhængige af hinanden Side 23 af 42

24 altså eksempelvis ved at Model ikke behøver at kende til forskellige Viewklasser, hvilket sikrer en lav kobling og gør det muligt at udskifte kode og grafik uden det store besvær. Grafisk Brugerflade og SWC Til den grafiske brugerflade har vi valgt at benytte grafik, som vi har lavet uden for Flash Builder. Vi gør dette for bedre at have kontrol over selve udformningen af designet, da eksempelvis Photoshop giver flere muligheder for at lave grafik end at benytte Graphics i ActionScript 3. Ud over dette foretrækker vi også en mere visuel udviklingsproces altså at producere vores grafik i en WYSIWYG 5 editor. Denne løsning resulterer dog i problemer med importering af grafikken i vores færdig-kompilerede Flash-applikation. For at løse dette problem bruger vi Flash til at lave SWC'er, som vi gør tilgængelige for Flash Builder compileren, hvilket giver os muligheden for at bruge dem direkte i vores kode. Hvordan fungerer SWC Flash Builder, Flash og ActionScript giver muligheden for at lave filer af typen SWC. Dette er et arkiv, der kan indeholde grafik og ActionScript-kode pakket sammen til brug på områder, hvor denne ikke skal ændres. En SWC fungerer ved, at den gøres tilgængelig for ActionScript ved compiletime, så både grafik og ActionScriptkode fra denne kan benyttes. Beskrevet på en mere håndgribelig måde bliver grafik og/eller kode eksporteret til en fil, eksempelvis playpauseknap.swc. Flash Builder eller et andet program, der kan kompilere SWF'er, er så i stand til at bruge indholdet af denne fil til at tilføje indhold ved kompilering. I forhold til at embedde et asset 6 i ActionScript, har SWC'er den fordel, at de, som nævnt, kan indeholde kode, samt at Flash Builder giver code hinting på dem og deres indhold. Dette letter arbejdsgangen. Som andre assets, der kan bruges i en Flash-applikation, kan SWC'er også loades runtime Betegnelsen for eksempelvis SWF, billeder, lyd og video, der kan benyttes i Flash via ActionScript Side 24 af 42

25 Implementering af SWC Der er forskellige metoder hvorpå man kan tildele ansvar til indhold i en SWC. Eksempelvis vil det være logisk, at en SWC, der indeholder en knap, selv er i stand til at sørge for at håndtere MouseOver osv. Ud over overvejelser om fordeling af logik og ansvar, er der også overordnet 3 forskellige metoder til at tildele funktionalitet til en SWC før brug i et ActionScriptprojekt. Vi vil kort ridse disse metoder op: En SWC kan efter almindelige OOP principper nedarve funktionalitet fra en klasse. Den extender altså den tidligere oprettede klasse med grafik ( grund klassen skal nedarve fra et DisplayObject typisk MovieClip eller Sprite) En klasse kan også extende indholdet i en SWC altså udvide det grafiske indhold i SWC'en med funktionalitet. I dette tilfælde vil SWC'en nedarve fra et DisplayObject. Trejde mulighed er, at SWC nedarver fra et DisplayObject, og funktionalitet bliver skrevet ind i SWC'en via Flash's timeline. Dette er en hurtig løsning til funktionalitet af lille omfang. Det kan dog hurtigt blive uoverskueligt at have kode liggende i forskellige frames i en Flash timeline. I vores projekt har vi valgt at bruge løsningen, hvor vi nedarver det grafiske indhold fra en SWC og udvider den med funktionalitet via en klasse, hvor det er nødvendigt. Side 25 af 42

26 Produktion af grafik og SWC De fleste af vores grafiske elementer har vi lavet i Photoshop. Derefter er de importeret til Flash, arrangeret og eksporteret til SWC'er. I Photoshop er alle de grafisk elementer lavet i samme kontekst og derefter klippet ud og eksporteret til enkelte filer. Side 26 af 42

27 Når opsætningen i Flash er komplet, bliver elementerne eksporteret til SWC'er. Til sidst bliver de loaded ind i ActionScript projektet via en Library path. Her ses hvordan vi benytter ChanDisplayAsset i vores kode: var _chan:chandisplay = new ChanDisplay(); _chan.makechandisplay(_model.getcurrentchan()); Vores ChanDisplayAsset er udvidet i ChanDisplay klassen med følgende funktionalitet: function makechandisplay(number:int):void{ _chandisplay.channel.text = String(number); addchild(_chandisplay); } Side 27 af 42

28 Opbevaring af Data I vores program har vi ikke det store behov for opbevaring af data. Da vi specifikt har udviklet programmet med henblik på at streame fra DR's live TV, kunne vi altså have valgt at hardcode streamnavne og server URL i programmet. Vi har dog valgt at lægge disse data eksternt i en XML, for at det er muligt at ændre eksempelvis server URL uden at skulle ændre koden og kompilere programmet igen. Af samme årsag har vi valgt at ligge indstillinger for volumen og kanaler i en separat XML fil. På den måde kan alle variable indstilinger i programmet manipuleres uden at ændre i koden. XML Som nævnt benytter vi os af XML til at loade data ind i vores program. XML står for extensible Markup Language 7 og ActionScript 3.0 har udemærket native understøttelse af dette sprog. Derfor har vi valgt dette til vores eksterne dataopbevaring. XML et markupsprog, der minder ret meget om HTML, hvor tags og et hierarki benyttes til at kategorisere indhold. Dette giver et computerprogram muligheden for nemt at læse indholdet, men på samme tid er XML udformet på en måde, der også gør det nemt for mennesker at forstå indholdet. Det er derfor let at arbejde med. Når vi bruger XML, gennemgår vi en række skridt; loader filen fra disken, parser indholdet og deler disse ud i relevante variabler, eksempelvis strings og Arrays. Følgende er et eksempel på, hvordan vi henter stream navne ud fra vores serverdata.xml: var xmlloader:urlloader = new URLLoader(); var xmldata:xml = new XML(); xmlloader.addeventlistener(event.complete, loadurlxml); xmlloader.load(new URLRequest("serverData.xml")); function loadurlxml(e:event):void{ xmldata = new XML(e.target.data); parsexml(xmldata); } function parsexml(thexml:xml):void{ _channelurl = thexml.serverurl; 7 Side 28 af 42

29 var channelchildren:xmllist = thexml.streams.children(); for each (var channelurl:xml in channelchildren) { var tempchan:string; tempchan = channelurl.text().tostring(); _channellist.push(tempchan); } } _model.setstreamdata(_channelurl, _channellist); dispatchcomplete() Begrænsninger En af de største forhindringer ved at bruge XML som datalager i Flash er, at datastrømmen kun kan gå én vej. I hvert fald hvis det skal være praktisk at bruge. I forhold til vores program kunne vi godt tænke os at gemme volumen og kanal indstillingerne i XML'en når de ændres. Men Flash giver simpelthen ikke adgang til en computers filsystem, uden at brugeren specifikt tillader det. Flash er meget udbredt på internettet, og en almindelig internetbruger vil se mange flash baserede spil, reklamer og programmer om dagen. Hvis alle disse applikationer havde tilladelse til at skrive til en brugers computer, ville det være et enormt sikkerhedshul. En XML fil er egentligt bare en velformateret tekst fil. I modsætning til eksempelvis at bruge SQL som datalager, er der ikke et lag imellem applikationen, der bruger data, og selve opbevaringen, så det er helt afhængigt af klientens sikkerhedstilladelser, om der kan skrives til filsystemet. Flash er udviklet til at lave onlineapplikationer, og det vil være problematisk at kæde data gemt lokalt på en computer sammen med et online program uden at lave en form for bruger-login. Dette ville fungere på samme måde som eksempelvis en webmail, der ved hvilke mails, der tilhører en given brugers konto. Det vil selvfølgeligt være muligt at lave dette, og strukturen af vores program tillader, at det relativt nemt kunne udvides med en login-lignende funktionalitet. Vi vil senere i afsnittet om udvidelser og forbedringer også komme ind på, hvordan vi evt. kunne komme udenom problem med tilladelser til det lokale filsystem. Streaming En central del af programmet er streaming fra DRs Nu webservice live TV. Flash og ActionScript indeholder forskellige måder, hvorpå man kan streame indhold som lyd og video. I dette tilfælde Side 29 af 42

30 benytter vi os af RTMP, da det er denne platform DR har valgt at bruge til deres Nu afspiller samt live TV streams. RTMP Real Time Message Protocol 8, blev oprindeligt udviklet af Macromedia med henblik på at streame lyd, video og data fra en server til en flash klient. Under Adobe er RTMP's specifikationer nu gjort offentlige. Der findes tre udgaver af RTMP; grundversionen RTMPT RTMP protokollen wrapped i HTTP requests med formålet at omgå firewall regler og RTMPS som er RTMP implementeret med SSL 9 sikkerhed. RTMP fungerer på den måde, at der oprettes forbindelse til serveren, før en stream startes. I et mere udvidet perspektiv er det værd at nævne, at RTMP også kan benyttes til at sende data fra en flash klient via serveren til en anden flash klient. Ud over dette kan der også laves Remote Procedure Calls 10, hvor klienten benytter sig af logik implementeret på server siden. Disse calls håndteres asynkront. Ved at benytte sig af disse muligheder vil det eksempelvis være muligt at lave et program, der tillader video chat med lyd. Der er altså en stor del af RTMP protokollens funktionalitet, der ikke bliver benyttet i dette program. I det følgende vil vi forklare de centrale dele af streaming fra DR's live TV stream via RTMP. NetConnection NetConnection klassen er ansvarlig for at oprette og opretholde forbindelse til RTMP serveren samt at sende og modtage data til og fra serveren. Der forbindes til serveren via connect() metoden, som tager imod en string formateret i protokol: [//vært][:port]/[navn på applikation]/[navn på instans] stien til DR's live stream-applikation er: rtmp://rtmplive.dr.dk:1935/live/. Det er også muligt at passe yderligere argumenter til onconnection() metoden på server side applikationen, man forbinder til. Det bliver dog ikke brugt i Side 30 af 42

31 forbindelse med vores projekt. NetConnection giver i form af opdateringer NetStatusEvents og SecurityErrorEvents, hvilke vi kommer ind på senere. Desuden kræver NetConnection, at der gives en reference til et klient-objekt, hvorpå der foretages callbacks. Vi har lavet vores egen custom klasse til at håndtere disse callbacks. Denne klasses funktionalitet vil blive yderligere forklaret i et senere afsnit. Da vi med NetConnection har at gøre med netværksforbindelser, vil der naturligvis forekomme forsinkelser, så dataoverførelse og kommunikation vil være asynkron. Derfor behovet for et klientobjekt, der kan fortages callsbacks på ud over dette fanger vi NetStatusEvents og SecurityErrorEvent med EventListeners. Dette er implementeret som følger: private var _nc:netconnection; private var _nsc:netstreamclient; public function Streamer(model:Model) { // Instantiate a NetConnection _nc = new NetConnection(); // Make sure we handle errors and status updates from NetConnection. _nc.addeventlistener(securityerrorevent.security_error, securityerrorhandler); _nc.addeventlistener(netstatusevent.net_status, onnetstatus); // Connect NetConnection to the server. _nc.connect(_model.getserverurl()); // Set our custom client as client on NetConnection. _nc.client = _nsc; } private function onnetstatus(e:netstatusevent):void { // Interpret the recieved NetStatusEvent code. switch (e.info.code) { case "NetConnection.Connect.Success": // If connection is successful, run ncconnected() ncconnected(); break; default: // Handle exceptions from the above. break; } } private function securityerrorhandler(event:securityerrorevent):void { } Side 31 af 42

32 NetStream NetStream klassen er ansvarlig for at åbne en envejs dataforbindelse til serveren. Den kan både have ansvar for at at sende og modtage en stream til og fra serveren. I vores projekt bruger vi NetStream til at modtage en stream fra serveren. Det er også NetStream, der sørger for at afkode video codecet, serveren sender streamen i. NetStreamobjektet oprettes som en kanal på NetConnection, hvilket betyder at den ikke kan fungere alene. Ligesomom NetConnection har NetStream også brug for at få en reference til et klient-objekt, som den kan sende callbacks til. Vi benytter samme custom klientklasse til både NetConnection og NetStream. Ud over callsbacks til klientobjektet sender NetStream også et AsyncErrorEvent, som vi bliver nødt til at håndtere, i tilfældet af dennes forekomst. Efter NetConnection har oprettet forbindelse, bliver NetStream oprettet med en reference til NetConnection. På dette tidspunk giver vi også NetStream en reference til NetStreamClient, sætter buffertid og tilføjer en EventListener til at håndtere AsyncErrorEventet ASYNC_ERROR. For at kende indholdet af NetStream, altså hvad den streamer, skal den tilføjes til et Video-objekt og tilføjes til scenen. Følgende kode bliver kørt når NetConnection.Connect.Success modtages fra NetConnection. private function ncconnected():void { // NetConnection is now connected to the server. _ncconnected = true; // Instantiate a NetStream. _ns = new NetStream(_nc); // Make sure we handle errors. _ns.addeventlistener(asyncerrorevent.async_error, asyncerrorhandler); // Set our custom client. _ns.client = _nsc; // Set buffertime for the stream. _ns.buffertime = 2; // Add the NetStream to the video object, so it can be viewed and controlled. video.attachnetstream(_ns); } Side 32 af 42

33 NetStreamClient Denne klasse er lavet med det formål at fungere som callback klient for NetConnection og NetStream. Ud over dette bruger vi den også til at sætte størrelsen på video, når den modtager metadata fra NetStream. Derfor kræver den en reference til Video, når den instantieres. I udgaven hvori NetStreamClient nu eksisterer, bliver den brugt til at modtage metadata for bredde og højde på videostreamen samt at opstille dummy-metoder. Når der er oprettes forbindelse serveren via NetConnection, bliver der foretaget en måling af den båndbredde, der er til rådighed imellem klient og server. Dette bliver efter oprettet forbindelse sendt til klienten. Vi kunne via vores custom-klient benytte denne data til eksempelvis at estimere, hvilken buffertid vi burde sætte på vores NetStreamobjekt samt til grafiske formål i forhold til indikatorer og progressbars til loading. NetStatusEvent Dette event bliver dispatched fra både NetConnection og NetStream. Som programmet er implementeret nu, lytter vi dog kun efter dette event på NetConnection. Der findes kun ét NetStreamEvent; NET_STAUS. Klassen har en public property ved navn info, der indeholder et objekt med informationen. Der sendes code properties i tre kategorier; error, status og warning. I vores program benytter vi os kun af følgende to: NetConnection.Connect.Success og NetConnection.Connect.Failed, som er henholdsvis en status og error status. Internettet faktorer der spiller ind på en stream Som nævnt tidligere er det muligt at benytte sig af en implantation af RTMP, hvor TCP pakker bliver wrapped i HTTP requests. Det vil sige, at dataen, der sendes til og fra server, bliver maskeret i en anden type pakker, end dem RTMP normalt bruger. Det er relativt almindeligt, at der på internetforbindelser er sat en firewall op, der skal sørge for at beskytte computere på et lokal netværk imod evt. trusler fra nettet dette kunne være orme 11 og 11 Side 33 af 42

34 portscannere 12 - samt sørge for NAT 13. Dette vil være tilfældet på de fleste internetforbindelser i hjemmet, hvor der er sat en router på for at dele forbindelsen mellem flere computere, eksempelvis over trådløst netværk. På eksempelvis skoler, i firmaer og andre netværk, hvor en stor mængde computere har adgang til nettet, vil der, ud over kontrol af indgående forbindelser, også være nogle sikkerhedsforanstaltninger i forbindelse med udgående forbindelser. En sådan sikkerhed kunne være, at udgående forbindelser begrænses til kun at være tilladt benyttelse af almindeligt benyttede typer som HTTP og FTP. Altså for at undgå der benyttes forbindelser, der kunne udgøre en sikkerhedsrisiko. Af samme årsag kan der være begrænsninger på hvilke porte, der kan forbindes til på serveren. I tilfælde af HTTP og FTP vil dette være port 80 og 21. Altså vil alle andre porte end disse være blokeret. RTMP benytter sig af port 1935 som standard, og det gør DR's RTMP servere også. Ydermere bruger de også den almindelige udgave af RTMP, hvor der ikke bliver gjort forsøg på at skjule data, der sendes til og fra serveren. At RTMP, og dermed også datapakkerne og server porten, skal opfattes som værende almindelige, er et subjektiv valg, der foretages af systemansvarlige på de pågældende netværk. Dog er faktum, at det vil være blokkeret nogle steder. Mere specifikt og relevant for netop denne opgave er, at Aarhus Universitetet har valgt for nyligt at blokere ikke almindelig data trafik og dermed også muligheden for at benytte RTMP protokollen. Der er desværre ikke noget vi kan gøre, i forhold til udformningen af klienten, der kan komme uden om dette problem, da både at ændre port benyttet på serveren samt at wrappe RTMP pakkerne kræver ændringer på serversiden, hvilket ikke er muligt, da det er DR, der opererer serverne. Ud over dette vil båndbredden til rådighed også være afgørende for vores programs performance. Da vi streamer video og lyd, skal der i de streams, vi benytter fra DR være minimum 1mbit båndbredde til rådighed, for at det kører optimalt Side 34 af 42

35 Fejlhåndtering I forbindelse med den asynkrone natur af vores program, vil der være risiko for en række fejl, som vi, ifølge god programmeringsskik, sørger for at håndtere. Dette vil ofte være i form af en tom funktion eller en funktion der blot tracer til konsollen for at indikere, at der er sket en fejl det vigtigste er, at de bliver fanget. Vi håndterer fejl ved at tilføje en EventListener, der lytter specifikt efter en fejl event type. Eksempelvis som her hvor vi lytter efter SecurityErrorEvent på NetConnection: // Make sure we handle errors from NetConnection. _nc.addeventlistener(securityerrorevent.security_error, securityerrorhandler); private function securityerrorhandler(event:securityerrorevent):void { trace("securityerrorhandler: " + event); } SecurityErrorEvent Dette event bliver ofte dispatched i forbindelse med en asynkron handling, som eksempelvis når vi tilgår ressourcer over et netværk eller fra en harddisk, hvor en fejl ikke vil opstå med det samme. I vores program vil det være aktuelt i forbindelse med vores forbindelser over netværk samt loading af filer. Vi bliver nødt til at tage højde for, at denne fejl kan opstå i tilfælde af, at vores programs miljø bliver ændret dette kunne være en forbindelsesfejl, eller at DR ændrer deres serveropsætning. AsyncErrorEvent Denne fejl bliver dispatched, når der sker en undtagelse i et stykke asynkron kode. Det vil typisk være i forbindelse med handlinger foretaget i eksempelvis NetConnection og NetStream.Vi vil også kunne se den i forbindelse med loading af XML-filer. Arbejdsprocessen Vores udvikling af programmet har overordnet været lineær, hvor vi dog, som beskrevet i afsnittene om faser, i starten havde en iterationsbaseret fremgangsmetode. Efter en grovere designproces af Side 35 af 42

36 programmets opbygning blev dette design testet, enten ved diskussion eller faktisk implementering i et ActionScriptprojekt. Resultatet af dette blev så til ændringer i designet, der så igen gennemgik samme proces. Vores kravspecifikation har løbende udviklet sig i takt med at vi fik tænkt de forskellige dele igennem. Der er under udviklingsarbejdet også forekommet ideer til ændringer undervejs. Som beskrevet har vores modulære opbygning af programmet netop tilladt os at udbygge og ændre dele af programmet, uden at skulle starte forfra. På samme måde har vi været i stand til at arbejde på udviklingen parallelt. Det har været en stor fordel for os, at vi har taget os tid til at planlægge og designe opbygningen af programmet, før vi er gået i gang med at lave det egentlige udviklingsarbejde. Til udarbejdningen af programmet har vi brugt en subversion server, hvilket tillod os nemt at arbejde på synkroniserede projekter, samt holde styr på ændringer og milepæle. Ud over det har vi også brugt dropbox til deling af dokumenter i forbindelse med specifikationer, noter og skriveproces af opgaven. Værktøjer Vi har benyttet os af en række værktøjer der har været centrale for udviklingen af vores projekt samt dokumentationen af det. Vi vil her kort gennemgå dem og vores erfaringer med dem. Flash Builder & AS3 I vores udvikling har Flash Builder 4 været central. Det er et integreret udviklingsmiljø baseret på Eclipse 14. At vi har brugt et IDE (Integrated Development Enviroment) betyder at vi har kunne gøre brug af løbende syntaks kontrol og code hints, samt ASDoc, som vi vil uddybe senere. Ud over dette er ActionScript 3 et strict sprog, hvilket betyder, at compileren kræver, at eksempelvis datatyper erklæres, hvilket sørger for at risikoen for forekomsten af menneskelige fejl minimeres Side 36 af 42

37 Eclipse udvidelser Da Flash Builder er bygget på Eclipse platformen, er der mulighed for at gøre brug af forskellige udvidelser. De to vi har gjort mest brug af, er Subclipse og ASDoc. Subclipse Subclipse 15 er en Subversion 16 klient til brug i Eclipse. Med denne har det været muligt for os, via en central server, at holde bedre styr på udviklingen af projektet. Herunder ses et screenshot af comits fortaget og deres tilhørende kommentarer Side 37 af 42

38 ASDoc Selvom denne udvidelse er pre-installeret og integreret, vil vi gerne fremhæve den. ASDoc tillader, ud over at genere HTML dokumenter med dokumentation til ens klasser, at vise dokumentation til metoder, der bliver vist i code hints. Dette har været vigtig i forbindelse med, at vi har været flere, der har arbejdet på klasser, der ligger udenfor Model. Via ASDoc har vi været i stand til, med ord, at specificere hvilket input og out put en metode krævede og gav. Her ses et eksempel: ASDoc i Model klassen: Side 38 af 42