AirDog Hovedprosjekt ved Høgskolen i Oslo 2009

Transkript

1

2

3

4 2

5 1 Forord Denne rapporten er prosjektets produktrapport og redegjør for programmets virkemåte, funksjonalitet og tekniske oppbygging både på klient- og serversiden. Rapporten er beregnet for sensor og veileder, men kan også leses av andre interessenter. Det vil være en fordel for leser å ha datatekniske kunnskaper knyttet til programutvikling. Rapporten er beregnet på personer som allerede er kjent med de benyttede teknologiene, men som ønsker bedre kjennskap til oppbygningen av applikasjonen. Rapporten gjør rede for sentrale deler i programmets under følgende hovedtemaer: Struktur i kildekoden på klient- og serversiden Forklarer programmets oppbygning og virkemåte Adgangs- og rettighetskontroll Tar for seg sikkerhetsmekanismer i forhold til brukerne av systemet Zend Framework Tar for seg rammeverket som støtter sentrale deler i programmet, og hvordan det er benyttet Feilsøking i Flex, PHP og PHP sammen med Flex Gir innsikt i teknikker på hvordan en som utvikler kan forholde seg til utviklingsmiljøet Utvidelsesmuligheter Gjør rede for allerede planlagt funksjonalitet for programmet, samt muligheter for andre bruksområder hvor løsningen kan sees på som generisk Prosessrapporten vil gi en dypere beskrivelse av utviklingsperioden og den benyttede metodikken. Vedlagt finnes en ordbok der leseren kan slå opp datatekniske og prosessrelaterte ord og uttrykk som er nevnt her. 3

6 2 Innhold 1 Forord Innhold Innledning Gruppen Oppdragsgiver og kunde Bekk Norsk Pointerklub (NPK) Norsk Breton Klubb (NBK) Bakgrunn for oppgaven Mål for oppgaven Beskrivelse av programmet Krav for installasjon og drift av programmet Server Klient Struktur i kildekoden på klientsiden Presentasjonslaget Sesjonslaget Kontrollerlaget Servicelaget Modellene Historieklassen Renderklassene Struktur i kildekoden på serversiden index.php AMF-protokollen Model Controller ValiderBruker Database Filopplaster

7 7.2.1 FilopplastController ImportParserController Parser BildeendringController Årbok AarbokController Verktøy Databasestruktur Adgangs- og rettighetskontroll Adgangskontroll Rettighetskontroll Databasen Zend Framework Zend_Amf Eksempel Zend_Auth Zend_Db Zend_Feed Nyhetsleser Klientside Serverside Feilsøking i Flex Feil som oppdages av Flex Builder Feilmeldinger i Flash Player Feil som gjør at applikasjonen ikke starter FlexUnit Feilsøking i PHP Logging av verdier Meldinger til klienten PHPUnit Feilsøking mellom PHP og Flex Charles

8 15 Kravspesifikasjonen og det endelige produktet Oppfyllelse av krav Tilbakemelding fra oppdragsgiver Utvidelsesmuligheter Endringer i eksisterende funksjonalitet Nyhetsleser Caching Estimert funksjonalitet Ny funksjonalitet Helse Favoritthunder Andre bruksområder Konklusjon

9 3 Innledning Denne innledningen inneholder bakgrunnsinformasjon for prosjektet og finnes i både prosess- og produktrapport. Her presenterer vi først gruppen, oppdragsgiver og kunde. Videre går vi mer i detalj om bakgrunnen for, og målet med, oppgaven. 3.1 Gruppen Gruppen bestod av Hans Magnus Inderberg, Egil Paulsen, Tore Lervik og Pelle Christoffer Bjerkestrand. Medlemmene kjente hverandre fra før og har jobbet sammen ved flere anledninger. Forventningene til hverandre var basert på egne erfaringer gjort over de to foregående årene og er derfor realistiske. Vi valgte å danne denne gruppen da vi hadde god kommunikasjon, et godt samarbeid og likt ambisjonsnivå. 3.2 Oppdragsgiver og kunde I denne oppgaven er det et skille mellom kunde og oppdragsgiver. Kundene er Norsk Pointerklub og Norsk Breton Klubb, mens Bekk fungerte som vår oppdragsgiver og vil vedlikeholde systemet etter levering Bekk Bekk Consulting AS er et norsk konsulentselskap som leverer rådgivnings-, teknologi- og forvaltningstjenester til store offentlige og private virksomheter. Selskapet har i dag 210 ansatte og er en del av ErgoGroup - et kraftsenter i Norden innen teknologi. Bekk stilte med to veiledere til prosjektet: Erlend Opdahl og Ole Christian Langfjæran. Ole er utvikler og er Bekk sin ekspert på Adobe Flex-teknologi. Ole hadde som sin bacheloroppgave å utforme det eksisterende systemet som nå er utdatert. Erlend er selv fuglehundeier og har kontakter i miljøet. På denne måten har de som oppdragsgiver god innsikt i kundens situasjon Norsk Pointerklub (NPK) Pointeren i Norge representerer en liten, men sunn hunderase. Det registreres rundt 300 valper i året. Rasen har få alvorlige arvelige defekter, noe som skyldes at NPK har god kontroll over rasen, og avler på sunne og friske bruksdyr. Det er svært få pointereiere som ikke driver med jakt og hundesport, og dette har ført til at de jaktlige egenskapene alltid har Figur 1. AirDog-logo hatt høyeste prioritet for oppdretterne her i landet. Figur 2. NPK-logo Klubben har i dag ca. 950 medlemmer. Veileder Erlend Opdahl er medlem i Norsk Pointerklub Norsk Breton Klubb (NBK) Breton er en liten hunderase, så vel i størrelse som i antall, i Norge. Breton er den minste av de stående fuglehundrasene. Det skal være en kvikk, livlig og våken hund med energiske, kraftige bevegelser uten å virke tung. Klubben har i dag ca. 900 medlemmer. 7

10 Veileder Ole Christian Langfjæran sitt system benyttes av denne klubben. 3.3 Bakgrunn for oppgaven Veileder Ole Christian Langfjæran hadde fra før laget en løsning for å vise informasjon om hunder, raser og jaktresultater fra Norsk Kennel Klubb. Løsningen blir benyttet av Norsk Breton Klubb. Dagens løsning er ikke god nok og det ønskes bedre statistikkmuligheter. For eksempel ønskes bedre muligheter for å redigere på data som ofte er feil, og å legge inn egne data. Videre ønskes bedre kompatibilitet da dagens løsning avhenger av utdatert teknologi som ActiveX i Windows XP. 3.4 Mål for oppgaven Målet med prosjektet er å utvikle et nytt system for hundeklubber som er tilknyttet Norsk Kennel Klubb (NKK). I første omgang vil dette være NPK og NBK. Systemet som skal utvikles skal erstatte det nåværende systemet og, om mulig, tilby nye funksjoner. Samtidig er det viktig at systemet kan brukes med lite eller ingen opplæring, av medlemmer av NPK og NBK. Figur 3. NKK-logo Systemet skal: Kunne kjøres på "alle" OS (Windows 2000/XP/Vista/7, Mac OS X og Linux) Parse datafilene NKK sender ut Beskytte dataene for innsyn av uvedkommende Systemet bør: Være relativt billig å drifte, vedlikeholde og utvide Kunne fullstendig erstatte det nåværende systemet Med tanke på målene og rammene står vi ikke helt fritt til å velge akkurat hvilke tekniske løsninger vi vil. Plattformuavhengighet og kravet om billig drifting betyr at åpne gratisalternativer som LAMPsystemet (Linux, Apache, MySQL, PHP/Perl/Python) blir favorisert over lukkede løsninger som Windows Server, C#.NET og MSSQL. 8

11 4 Beskrivelse av programmet Vi vil i dette kapittelet gjøre rede for den overordnede strukturen og funksjonaliteten som tilbys i AirDog-applikasjonen slik at leseren vil få større utbytte av senere kapitler. Figur 4. Hovedside AirDog er en web-applikasjon for rapportering og statistikk strømlinjet mot data levert fra Norsk Kennel Klubb. Applikasjonen er innledningsvis tilpasset fuglehundklubbene Norsk Pointerklub og Norsk Breton Klubb, men applikasjonen er laget generisk og kan enkelt tas i bruk av andre klubber. Systemet er i drift og har i startfasen registrert over hunder jaktprøver utstillinger kull personer oppdrettere veterinærer «Vi er meget fornøyd» - Bekk Applikasjonen lar klubbmedlemmer se klubbens hunders profiler, hvor på det vises jakt- og utstillingsresultater fra alle stevner hunden har deltatt på. Videre er det mulig å lese av stamtavlen til en hund, samt liste opp hundens avkom sortert etter kull. 9

12 Figur 5. Hundprofil Figur 6. Jaktprøver «Noen [...] ønsker at den skal presenteres slik den er i dag for alle klubbene» - Bekk Figur 7. Avkom AirDog tilbyr også kraftige statistiske utregninger. Applikasjonen kan generere statistiske data over alle klubbens hunder. Statistiske data kan være gjennomsnittsresultater og premiegrad for jaktprøver i ulike klasser, én eller alle hunders viltfinnerevne, kåring av beste hund i cup og mye mer. Brukerne kan også lese nyheter fra klubbenes egne sider som blir importert til applikasjonen i sanntid. Figur 8. Rasens jaktresultater Figur 9. Cup Bak alt dette ligger også en rekke administratorfunksjoner for å oppdatere data fra NKK. Blant annet kan man som administrator tildele roller til brukerne av systemet. Rollene kan også skreddersys av administrator slik at brukerne av systemet ikke svekker sikkerheten. 10

13 Figur 10. Brukerhåndtering Figur 11. Dat-opplastning Hvis en følger pilene i Figur 12 vil en se at disse viser en menystruktur og hvordan alle visningene henger sammen. Visningene er omtalt i brukermanualen. «Studentene utviklet [seg] gradvis til å bli meget dyktige» - Bekk Figur 12. Programmets visninger Figur 13. Jaktprøveregistrering Figur 14. Backup Applikasjonens over godt strukturerte kodelinjer er åpne og gratis slik at hvem som helst kan bruke eller utvide dem. 11

14 Figur 15. Systemets struktur Denne enkle strukturen ga oss en byggestein for dette store og komplekse programmet. Strukturen kan sees som en samlet enhet, men kan også brytes ned til server og klient. Dette vil bli gjort bedre rede for i produktrapporten. «Det er med glede vi gir [gruppen] våre beste anbefalinger!» - Bekk 12

15 5 Krav for installasjon og drift av programmet 5.1 Server Programmet er skrevet i PHP og benytter en MySQL-database. Dette krever en webserver med PHP med utvidelsen MySQLi og en MySQL-database installert. 5.2 Klient Klientsiden av programmet vil kreve at brukeren kjører en hvilken som helst nettleser kompatibel med Adobe Flash Player versjon 10 eller nyere. Flash Player 10 kjører per dags dato på Microsoft Windows, Apple Mac OS X, Sun Solaris og Linux. Minimumskrav for Flash Player 10 hentet fra Adobe sine nettsider: Windows Macintosh Linux Intel Pentium II 450MHz, AMD Athlon 600MHz or faster processor (or equivalent) PowerPC G3 500MHz or faster processor Intel Core Duo 1.33GHz or faster processor Modern processor (800MHz or faster) 128MB of RAM 128MB of RAM 512MB of RAM, 128MB of graphics memory 13

16 6 Struktur i kildekoden på klientsiden Her tar vi for oss struktureringen av kode i Flex-applikasjonen. Applikasjonens hovedklasser benytter seg av en MVCS-struktur for å skille de forskjellige delene. Vi betegner de ulike komponentene i MVCS strukturen som presentasjonslag, kontrollerlag, servicelag og modeller. Applikasjonen starter med AirDogMain.mxml som instansierer MainComponents.mxml for logikk og lagring, og MainView.mxml for presentasjonslaget. Components-klassen som er instansiert av AirDogMain gjennom MainComponents, er tilgjengelig globalt i applikasjonen. Dette gjør det mulig å kalle på service, historie, session eller controller ved å bruke no.airdog.services.components.instance.<klassenavn> i kildekoden. Figur 16. Filstruktur 6.1 Presentasjonslaget Presentasjonslaget tar for seg alle visninger i applikasjonen. Laget inneholder ingen større funksjoner, og all logikk som kan trekkes ut skal ligge i kontrollerlaget. Layout for brukergrensesnittet skal ligge her mens design skal ligge i stil.css. Laget starter med MainView.mxml som inneholder brukergrensesnittet for applikasjonen. 14

17 Stilark Filen stil.css ligger under AirDogMain.mxml og inneholder alle stilene som blir benyttet av presentasjonslaget. Stilene angir hvordan applikasjonen skal se ut og hvordan elementer som knapper og tekst skal vises i brukergrensesnittet. Et eksempel tatt fra stil.css.viewmeny backgroundcolor: #e5ecf3; paddingbottom: 4; paddingleft: 4; paddingright: 4; paddingtop: 4; verticalalign: middle; } Her ser man at bakgrunnsfargen er satt til #e5ecf3, det er en 4-piksel stor padding rundt, og at elementet er plassert vertikalt i midten. 6.2 Sesjonslaget Data for applikasjonen ligger lagret i sesjonslaget. Laget er instansiert av Components.as og er tilgjengelig for alle klassene i applikasjonen. Data som skal vises i presentasjonslaget blir lagret her slik at kontrollerlaget kan manipulere informasjonen uten å røre presentasjonslaget. 6.3 Kontrollerlaget Kontrollerlaget tar for seg all logikk i applikasjonen. Presentasjonslaget kan spørre kontrollerlaget om å utføre en funksjon, som igjen vil oppdatere sesjonslaget slik at presentasjonslaget viser den nye informasjonen. Dette gjør at kontrollerlaget ikke kjenner til presentasjonslaget og er på ingen måte bundet til den ene presentasjonen. Dette gjør det enkelt å endre presentasjonslag slik at man kan konvertere en applikasjon til for eksempel en web-applikasjon. 6.4 Servicelaget Dette laget er på mange måter et underlag av kontrollerlaget, og står for logikken mot eksterne tjenester. Dette laget har som mål å kommunisere mellom applikasjonen og eksterne tjenester over en gitt protokoll. Grunnen til at dette laget er separert fra kontrollerlaget, er at man enkelt skal kunne bytte ut laget for å benytte seg av andre protokoller eller måter å kommunisere eksternt. 6.5 Modellene Modellene brukes i hele applikasjonen og sendes også fram og tilbake mellom klient- og tjenerdelen. Modellene inneholder en spesiell markering i starten av klassen for å si hvilket objekt de representerer på serverdelen. En slik markering kan se ut som dette: [RemoteClass(alias="AmfHund")] 15

18 Modellobjektene er brukt av de fleste klassene i applikasjonen, og vi har derfor valgt ikke å knytte dem til noen spesiell del. 6.6 Historieklassen Historieklassen tar for seg implementeringen av fram- og tilbakeknapp i applikasjonen. Flash har ingen innebygd måte å lagre tilstander i besøkshistorien, så applikasjonen setter manuelt disse bokmerkene med hjelp fra denne klassen. 6.7 Renderklassene Renderklassene er presentasjonsklasser som tar for seg visningen av et objekt. Disse klassene gjør det mulig å effektivt bytte ut hvordan en tabell presenterer informasjonen. 16

19 7 Struktur i kildekoden på serversiden Her tar vi for oss struktureringen av kode på serversiden der vi vil gå gjennom hovedkomponentene bak systemet. PHP-delen av applikasjonen er delt inn i to lag. Applikasjonens logikk utføres i Kontrollerlaget, mens all kommunikasjon mot databasen utføres i databaselaget. Flex-klienten fungerer som presentasjonslaget. Figur 17. Filstruktur 7.1 index.php Index.php brukes til å definere hvilke funksjoner som er tilgjengelig for Flex-applikasjonen over AMFprotokollen. I tillegg defineres modellene i index.php slik at Flex-applikasjonen sine modeller samsvarer med de på serversiden. Her defineres hver kontrollerklasse samt de forskjellige modellene som benyttes. Et eksempel på hvordan dette gjøres vises under. $server = new Zend_Amf_Server(); $server->setclass("hundcontroller"); $server->setclassmap("amfhund", "AmfHund"); 17

20 7.1.1 AMF-protokollen AMF (Action Message Format) er et binærformat som baserer seg løst på SOAP (Simple Object Access Protocol). AMF brukes primært til å sende data mellom en Adobe Flash-klient og en server. AMF tilgjengeliggjør svar av typen objekter og er den protokollen vi har benyttet mest Model Model-klassene brukes til å definere egenlagde objekter. Disse defineres på både server- og klientsiden slik at de kan sendes over AMF-protokollen Controller Controller-klassene inneholder de metodene som er tilgjengelig over AMF-protokollen som klienten benytter seg av. Det er i dette laget at brukerrettigheter blir kontrollert før handlinger i databaselaget blir utført. I tillegg er det i dette laget selve logikken blir utført, samt oversettelse mellom databasesvar og AMF-objekter. Et eksempel på en funksjon i en kontroller public function eksempelfunksjon($brukerepost, $brukerpassord, $klubbid) If (ValiderBruker::validerBrukerRettighet($this->database, $brukerpassord, $klubbid, "rettighet")) // Utføre handlinge return $informasjonen; } $feilkode = 1; throw(new Exception('Du har ikke denne rettigheten', $feilkode)); } $brukerepost, Hver funksjon i kontrollerlaget er åpent tilgjengelig, det er derfor viktig og starte funksjonen med å autentisere brukeren som ønsker å utføre handlingen ValiderBruker ValiderBruker-klassen inneholder funksjoner for autentisering. Den funksjonen som blir brukt mest i denne klassen er validerbrukerrettighet, som brukes til å sjekke om brukeren har rettighet til å utføre gitt handling. Brukervalidering er nødvendig siden funksjonene tilgjengelig over AMFprotokollen er tilgjengelige for alle. Hvis en bruker har verdien superadmin satt i databasen, vil rettigheten alltid bli validert Database Databaselaget tar for seg all kommunikasjon mellom applikasjonen og databasen, og det er her databasespesifikk logikk utføres. Dette laget er lagt for seg selv slik at man ikke skal trenge å endre noe i andre deler av applikasjonen hvis databasen endres. I vårt databaselag har vi benyttet oss av Zend_Db til å kommunisere med MySQL-databasen. 18

21 Zend_Db Zend_Db gir en god kodestruktur på databasespørringer, og rammeverket støtter i tillegg flere andre databasetyper som for eksempel Oracle, SQLLite, MSSQL og DB2. Et eksempel på en databasespørring i Zend_DB $select = $this->database->select() ->from(array('h'=>'nkk_hund'), array('h.*')) ->where('h.raseid=?', $klubbid) ->where('h.navn LIKE "%"?"%" OR h.hundid LIKE "%"?"%"', $soketekst) ->limit(100, 0) ->order('h.navn ASC'); return $this->database->fetchall($select); Dette eksempelet returnerer alle hunder fra databasen nkk_hund hvor raseid stemmer med $klubbid og navn eller hundid inneholder ordet i $soketekst Tilkobling Zend_Db bruker et databaseobjekt for å koble til en spesifikk database. Vi lagde en egen tilkoblingsklasse som har én funksjon: gettilkobling(). Denne funksjonen tas i bruk for å hente en tilkobling til databasen. Databaseobjektet definerer verdier som adapter, host, brukernavn, passord og databasenavn, og kan brukes til å definere andre særegenheter som trengs ved oppkobling til en database. Adapterverdien definerer hvilken type database som skal kobles opp mot. Siden prosjektet vårt ligger åpent på Google Code måtte vi være forsiktig med å lagre sensitiv databaseinformasjon i en tilgjengelig fil. Tilkoblingsklassen henter derfor disse opplysningene fra en fil som ligger utenfor prosjektet. På den måten vil ikke tilkoblingsinformasjon bli lastet opp til Google Code. Et eksempel på databaseobjekt $db = new Zend_Db_Adapter_Pdo_Mysql(array( 'host' => ' ', 'username' => 'webuser', 'password' => 'xxxxxxxx', 'dbname' => 'test')); 19

22 7.2 Filopplaster Opplastning av filer til serveren skjer ikke over AMF-protokollen, men over vanlig HTTP. Denne funksjonen brukes til å laste opp bilder av hunder, samt dat-filer som skal inn i databasen. Figur 18. Filstruktur FilopplastController FilopplastController.php mottar filen som blir sendt fra Flex-applikasjonen. Den sjekker om filen er en dat-fil eller et bilde av en hund, og utfører nødvendige operasjoner ImportParserController I denne filen sjekkes det for hvilken type dat-fil som er blitt lastet opp slik at innholdet kan legges inn i riktig databasetabell. FilvaliderController blir brukt til å finne ut hvilken type det er før hver rad blir kjørt gjennom parserklassen, for så å bli lagt inn i databasen ved hjelp av databaseklassene Parser Parser-klassene tar imot én og én rad fra dat-filen, og konverterer innholdet til en liste som kan puttes inn i databasen BildeendringController FilopplastController.php kan også motta bildefiler. Disse filene blir sendt til BildeendringController.php som genererer én stor og én liten versjon av bildet, som så blir navngitt med den aktuelle hunden sin hundid, og lagret. 20

23 7.3 Årbok I applikasjonen kan man generere årbok for et gitt år, for enten en eller alle hundene i klubben. En årbok inneholder hunder som har avkom som har hatt jaktprøve i det angitte året. Hunden listes opp med informasjon om seg selv, der avkom grupperes i kull. Det vises jaktprøvestatistikk for hver hund i hvert kull. Aarbok.php mottar forespørselen gjennom vanlig HTTP, og returnerer verdien den får fra AarbokController.php som den utgir for å være en doc-fil. Figur 19. Filstruktur AarbokController AarbokController.php sin lag_rtf()-funksjon genererer teksten som blir til årboken brukeren mottar. Først henter den alle hundene ut fra de gitte kriteriene, for så å hente alle kullene med avkom for hver av hundene. lag_rtf() bruker maler som ligger i no/airdog/assets til å generere den gyldige doc-filen som til slutt blir returnert til brukeren. Diagrammet viser hvordan systemet bygger opp årboken. Først hentes listen med hunder, som igjen henter kulloversikten og kullisten med avkom. For hvert avkom i kullisten blir så jaktprøvene for det aktuelle året hentet fra databasen. Figur 20. Årbokstruktur 7.4 Verktøy Verktøy-klassen er en hjelpeklasse. Den inneholder funksjoner som datokonvertering, logging og årboken sin RTF-sammenfletter. Alle funksjoner som kan gjenbrukes, men ikke har noen bestemt tilhørlighet, legges i denne klassen. 21

24 8 Databasestruktur Databasestrukturen består av to hovedgrupper, AirDog-tabellene som er for applikasjonen, og dattabellene som representerer informasjonen som kommer fra NKK sine dat-filer. AirDog-tabellene inneholder applikasjonen sin informasjon om hvilke klubber, brukere, roller og rettigheter som finnes. En bruker kan som vist være medlem av flere klubber, og også kunne ha flere roller i den samme klubben. Ved innlogging settes alle rettigheter sammen slik at en bruker med flere roller får alle rettighetene fra de forskjellige rollene i klubben. I tillegg inneholder AirDog-tabellene en datreferanse-tabell. Denne tabellen brukes som problematisk import og er nevnt i avsnittet Struktur og kildekode på serversiden, samt i prosessrapporten under Import av data fra NKK. Dat-tabellene er én til én i forhold til de originale dat-filene fra NKK. Dette er gjort for å sikre best mulig kompatibilitet, samt unngå normaliseringer som senere vil kunne gjøre tabellene ubrukelige i forhold til nye formater på NKK sine dat-filer. For ER-diagram av databasen, se Figur 21 på neste side. 22

25 Figur 21. ER-diagram av databasen 23

26 9 Adgangs- og rettighetskontroll Adgangskontrollen benytter seg av Zend_Auth, mens rettighetskontrollen er egenskrevet. Dette kapittelet vil først ta for seg adgangskontroll for så å redegjøre for rettighetskontroll. 9.1 Adgangskontroll Når brukere logger inn i applikasjonen sendes et brukerobjekt fra klient til LoggInnController.php. Dette objektet inneholder brukerens e-post og passord. Disse blir sjekket opp mot innholdet i MySQL-tabellen ad_bruker. public function logginn(amfbruker $bruker) $autentisering = new Zend_Auth_Adapter_DbTable($this->database); $autentisering ->settablename('ad_bruker') ->setidentitycolumn('epost') ->setcredentialcolumn('passord'); $epost = htmlspecialchars($bruker->epost); $pass = sha1(htmlspecialchars($bruker->passord)); if($epost == "") return "FEIL_BRUKERNAVN_PASSORD"; } else $autentisering->setidentity($epost)->setcredential($pass); } $resultat = $autentisering->authenticate(); Innholdet i $resultat sjekkes så for feilmeldinger med $resultat->getcode() der et nyopprettet brukerobjekt blir sendt tilbake til klienten hvis innloggingen er vellykket. switch ($resultat->getcode()) /*spesifikke feilmeldinger*/ case Zend_Auth_Result::SUCCESS: $r = $autentisering->getresultrowobject(); $bruker->epost = $r->epost; $bruker->fornavn = $r->fornavn; $bruker->etternavn = $r->etternavn; $bruker->superadmin = $r->superadmin; } break; return $bruker; 24

27 Bruker vil da, i klienten, få opp en liste bestående av tilgjengelige klubber. Rettighetene populeres når brukeren velger klubb. Ved utlogging slettes identiteten til brukeren fra gjeldende instans på server. public function loggut() Zend_Auth::getInstance()->clearIdentity(); return true; } 9.2 Rettighetskontroll Brukerobjektet på klientsiden inkluderer variabler for hver eneste rettighet. Disse finnes ikke i objektet på serversiden, men genereres når brukeren velger klubb i innloggingsskjermen. Til dette brukes ACLController.php der funksjonaliteten for å hente ut rettigheter ligger i den inkluderte ValiderBruker.php. Når bruker har valgt ønsket klubb, kjøres det en rekke funksjoner. public function settbrukersklubb($raseid, $brukerepost, $brukerpassord) public function hentbrukersroller($brukerepost, $brukerpassord, $klubbid) public function hentbrukersrettigheter($brukerepost, $brukerpassord, $klubbid) Vi skal her se nærmere på hentbrukersrettigheter($brukerepost, $brukerpassord, $klubbid). Denne funksjonen gjør først en sjekk for å se om bruker er superadministrator. I det tilfelle settes alle rettigheter til true og sendes tilbake til klient som et AmfRettigheter-objekt. if(validerbruker::validersuperadmin($this->database, $brukerepost, $brukerpassord)) $tmp = new AmfRettigheter(); $tmp->lese = true; /*alle de andre rettighetene*/ } return $tmp; 25

28 Hvis bruker ikke er superadministrator, vil hver eneste rettighet sjekkes før de samles i samme type objekt og returneres til klient. if(validerbruker::validerbrukeren($this->database, $brukerepost, $brukerpassord)) $db = new ACLDatabase(); $rettigheter = $db->hentbrukersrettigheter($brukerepost, $klubbid); $tmp = new AmfRettigheter(); foreach($rettigheter as $r) if($r['navn'] == "lese") $tmp->lese = true; /*alle de adnre rettighetene*/ } >legginnjaktprove >arrangementer } if($tmp->redigerhund $tmp->importerdatabase $tmp- $tmp->rollerettighethandtering $tmp->klubbrollebrukerhandtering $tmp->administrerebackup $tmp->importerdatabase $tmp- $tmp->lagaarbok) $tmp->administrere = true; return $tmp; Den siste sjekken i koden over setter administrere til true hvis brukeren har rettigheter som gjør at administratormenyen skal vises i klienten. 26

29 9.3 Databasen Diagrammet under viser relasjonene mellom brukere, roller og klubber. Figur 22. ER-diagram av AirDog-tabellene Roller kan ha fra null til mange rettigheter Brukere kan være registrert i fra null til mange klubber Brukere kan ha fra null til mange roller i hver klubb hun eller han er registrert i Sammen med ad_bruker_klubb_rolle_link er ad_rolle_rettighet_link de sentrale tabellene med tanke på oppslag. Det er disse som blir spurt hver gang systemet trenger å sjekke om en bestemt bruker har en bestemt rettighet eller er medlem i en bestemt klubb. Legg merke til at vi valgte å ikke benytte oss av arv. Dette valget tok vi for å unngå problematikk som kan oppstå når en rolle det arves fra endrer seg. Hver enkelt rolle og dens rettigheter er derfor isolert fra, og upåvirket av, de andre. 27

30 10 Zend Framework Rammeverket er utviklet av Zend Technologies og ble for første gang annonsert i oktober Den første testutgaven kom i april Kildekoden er fri og gratis og har mange frivillige bidragsytere. I tillegg har Google og IBM også sponset noe av utviklingen. Rammeverket baserer seg på «ved behov»-prinsippet, noe som gjør at brukere kan ta i bruk delene av rammeverket som trengs i applikasjonen brukeren utvikler og forkaste de modulene som ikke er relevante. Tar man i bruk hele rammeverket, vil man merke at det er bygget opp for å følge MVC-arkitekturen (Model, View, Controller). I det enkle så betyr det at en skiller objektdefinisjonene (Model), design og layout i brukergrensesnittet (View) og forretningslogikken (Controller) fra hverandre. I vår applikasjon er følgende moduler brukt: 10.1 Zend_Amf Zend_Amf gir AMF3 (Action Message Format) støtte til Zend rammeverket. AMF3 er kompatibel med Flash Player 9 og oppover. AMF (Action Message Format) er en måte å sende objekter frem og tilbake mellom klienten og serveren på. Å serialisere objektene til en kompakt binær representasjon for så å sende dem gir bedre ytelse og økt sikkerhet i forhold til for eksempel å gjøre de om til XML. AMF-objekter kan overføres med både HTTP- og HTTPS-protokollen. Zend_Amf fungerer som en AMF oversetter slik at serveren kan respondere på prosedyrekallene Adobe Flash Player sender. For å fungere må både server og klient ha definert hvilke objekter som tilsvarer hverandre på begge sider. Dette kalles mapping, og AS3-objektet må inneholde minst det PHP-objektet består av. 28

31 Eksempel ActionScript 3 package no.airdog.model import mx.collections.arraycollection; [RemoteClass(alias="AmfBruker")] [Bindable] public class Bruker public var epost:string; public var fornavn:string; public var etternavn:string; public var passord:string; public var innlogget:boolean = false; public var sattklubb:klubb; public var klubber:arraycollection; public var superadmin:boolean; public var roller:arraycollection; public var rettigheter:rettigheter; } } PHP <?php class AmfBruker public $epost; public $fornavn; public $etternavn; public $passord; public $superadmin; } 10.2 Zend_Auth Denne modulen gir et API for autentisering. Den håndterer kun autentisering og ikke autorisering. Autentisering er å finne ut om en bruker er den han utgir seg for å være, mens autorisering er tilgangskontroll. Dette gjøres ofte ved hjelp av brukernavn og passord. 29

32 10.3 Zend_Db Zend_Db sitter som et lag mellom databasen og logikken i PHP. Dette gjør at typen database kan byttes ut uten å endre spørringer, da disse er skrevet i Zends eget databasespråk og oversettes, sikres og optimaliseres dynamisk. Zend_Db har støtte for IBM DB2, MySQL, Oracle, MsSQL, PostgreSQL og SQLite. Et eksempel på en konfigurasjon kan være slik: return array( 'webhost' => ' 'database' => array( 'adapter' => 'Mysqli', 'params' => array( 'host' => 'localhost', 'username' => 'test', 'password' => 'air', 'dbname' => 'airdog', 'profiler' => false))); Hvis vi ville byttet til IBM DB2 endrer vi kun 'adapter' => 'Mysqli' til 'adapter' => 'Db2'. Eksempel på standard SQL satt opp mot Zend_Db-syntaks: SQL-spørring SELECT p."product_id", p."product_name", l.* FROM "products" AS p JOIN "line_items" AS l ON p.product_id = l.product_id Zend_Db-spørring $select = $db->select() ->from(array('p' => 'products'), array('product_id', 'product_name')) ->join(array('l' => 'line_items'), 'p.product_id = l.product_id'); 10.4 Zend_Feed Zend_Feed muliggjør rask oversetting av RSS1-, RSS2-, og Atom-feeds til objekter som kan behandles og sendes videre til klienten. I vår applikasjon gjøres hver nyhet om til et egendefinert AMF3-objekt som det kan sendes en array av tilbake til klienten. 30

33 11 Nyhetsleser Nyhetsleseren er implementert både på server- og klientsiden. Vi vil her gå gjennom koden i begge. Leserene populerer lister med nyhetsobjekter generert fra en klubb sin RSS-feed. ActionScript PHP [RemoteClass(alias="AmfNyhet")] [Bindable] public class Nyhet public var tittel:string; public var tekst:string; public var dato:string; public var url:string; } class AmfNyhet public $tittel; public $tekst; public $dato; public $url; } Tabellen viser nyhetsobjektet som blir definert for å hentes inn til klienten (ActionScript) Klientside Vi vil her kun gå gjennom leserens logikk, ikke utseende. Leseren er naturlig nok skrevet i ActionScript og MXML. Den baserer seg på Adobes egne biblioteker for XML og RSS2.0. import com.adobe.utils.xmlutil; import com.adobe.xml.syndication.rss.item20; import com.adobe.xml.syndication.rss.rss20; NyheterView.mxml, som leseren heter, lytter på den satte klubbens RSS og oppdaterer seg selv ved endring. <view:nyheterview rssurl="components.instance.session.bruker.sattklubb.rss}"/> [Bindable] private var _rssurl:string; public function set rssurl(url:string):void _rssurl = url; hentnyheter(); } 31

34 Her kjøres funksjonen hentnyheter() som nuller ut nyhetslisten og setter i gang HTTPServicen som henter klubbens RSS direkte fra klubbens side. public function hentnyheter():void if(_rssurl!= null) nyhetsliste.removeall(); rssparse.send(); } } HTTPServicen definerer funksjoner som kjøres ved resultat og feiling. <mx:httpservice id="rssparse" url="_rssurl}" result="rss_handler(event)" fault="rss_fault_handler(event)"/> rss_handler() er en stor funksjon, men vi vil her vise det viktigste. Resten av funksjonen itererer gjennom klubbens nyheter, stripper HTML, lager nyhetsobjekter og legger dem til nyhetslisten. private function rss_handler(event:resultevent):void var xmlstring:string = event.message.body.tostring(); if(xmlutil.isvalidxml(xmlstring)) var rss:rss20 = new RSS20; rss.parse(xmlstring); var items:array = rss.items; rss_fault_handler() viser feilen i nyhetslisten. private function rss_fault_handler(event:faultevent):void var tom:nyhet = new Nyhet; tom.tittel = "Feil"; tom.tekst = "Klubben har en ugyldig RSS"; tom.url = ""; tom.dato = ""; nyhetsliste.additem(tom); } Videre finnes funksjonene riktighoyde() som mottar felter og setter høyden på dem lik innholdet, og lesnyhet() som er koblet opp mot en knapp på hver nyhet som sender bruker til nyhetens URL. 32

35 11.2 Serverside Logikken her ligger i filene NyhetController.php og NyhetDatabase.php. NyhetDatabase.php har kun én funksjon som benyttes i denne sammenheng, hentrss($klubbid), som returnerer klubbens RSS URL. Dette, og bruken av Zend_Feed, vises under. $nd = new NyhetDatabase(); $rss = $nd->hentrss($klubbid); $ret = array(); if(trim($rss['rss'])!= '') try $feed = new Zend_Feed_RSS($rss['rss']); } Bruken av Zend_Feed_RSS gjøres direkte, da vi vet at klubbens feed er RSS. Zend_Feed::import($rss['rss']) fungerer på RSS1.0, RSS2.0 og Atom, men vi opplevde det som merkbart tregere. Videre fanges et eventuelt unntak (exception) på vanlig måte. $feed gåes så gjennom der det lages nyhetsobjekter som populerer en liste som sendes tilbake til klienten. foreach($feed as $nyhet) $tmp = new AmfNyhet(); $tmp->tittel = $nyhet->title(); if(trim($nyhet->description())!= '') $tmp->tekst = substr(trim(strip_tags($nyhet->description())), 0, 197).'...'; } else $tmp->tekst = null; } $tmp->dato = $nyhet->pubdate(); $tmp->url = $nyhet->link(); $ret[] = $tmp; } Denne implementeringen sikrer nyhetsleveranse til klienten uansett om klienten har støtte for å hente RSS direkte eller ikke. 33

36 12 Feilsøking i Flex Her vil vi gå gjennom metoder vi har benyttet oss av mens vi har brukt Flex som programmeringsplattform. Noen feiltyper oppdages av utviklingsmiljøet, mens andre vil resultere i at Flash Player viser en feilmelding. Alvorlige feil kan føre til at applikasjonen ikke starter opp i det hele tatt, og da uten noen form for melding Feil som oppdages av Flex Builder Syntaksfeil er den enkleste formen for feil. Det er også den typen feil som er lettest for Flex Builder å oppdage. Videre kan også utviklingsmiljøet oppdage forsøk på å bruke udefinerte funksjoner, objekter og liknende. Figuren under viser hvordan Flex Builder viser utvikleren hvor det er slike feil. Figur 23. Flex Builder Vi ser her at det er en rekke indikatorer på at det er en feil i kildekoden: Flex Navigator-fanen viser en rød X på filer som inneholder feil Koderedigeringsvinduet har en større X på linjer med feil Koderedigeringsvinduet har også markert ved rullefeltet, hvor i filen feilen befinner seg Problems-fanen gir detaljert informasjon om feilen SVN-fanen markerer feil på samme måte som Flex Navigator-fanen, men kun for filer som er annerledes enn på serveren 34

37 Alle disse indikatorene gjør det relativt enkelt å finne feil og rette på de i Flex Builder. Flex Builder nekter også å kompilere kildekoden så lenge den finner feil Feilmeldinger i Flash Player Feil knyttet til referanser til usatte verdier (null pointer exception), samt andre feil som kan skje under kjøring, vises med debuggingsinfo direkte i Flash Player. Meldingen viser da en feilkode og spesifiserer hva slags type feil som skjedde. Her vises en feilmelding knyttet til et uhåndtert IOErrorEvent der applikasjonen ikke finner en fil som er spesifisert med ekstern URL inne i kildekoden. Figur 24. Feilmelding i Flash Player De andre tilfellene Flash Player har vist feilmeldinger har vært når det har vært uoverensstemmelser mellom server og klient. Dette står det mer om i kapittelet Feilsøking mellom Flex og PHP Feil som gjør at applikasjonen ikke starter Når Flash-applikasjonen starter opp, kjøres det først en egen kodesnutt som laster resten av applikasjonen. Denne koden genererer lasteskjermen og kjører i en strippet utgave av det miljøet applikasjonen lastes inn i. Feil her vil ikke bli oppdaget av utviklingsmiljøet og vil heller ikke generere noen feilmeldinger fra Flash Player. 35

38 Figur 25. Laster.as inneholder mange kommentarer for å prøve å unngå kodefeil Lasteren følger standarden for den første versjonen av ActionScript slik at den er være kompatible med alle versjonene av Flash. Oppførselen til lasteren minner oss om at ActionScript er et scriptspråk og i utgangspunktet ikke objektorientert, da verdier må deklareres og settes før kan bli brukt. Alle komponenter, inkludert de enkle TextField og TextFormat, må også importeres før de kan bli brukt. Disse, og alle andre feil i lasterkoden, vil ikke resultere i et kræsj, men kun vise blank skjerm i nettleseren. 36

39 12.4 FlexUnit I tillegg til programmatiske feil, er det også ønskelig å teste for funksjonelle feil. Dette kan gjøres ved å ta i bruk Adobes FlexUnit. Man skriver da egne testklasser for hver klasse i programmet ellers. Man sammenlikner så ønsket resultat opp mot faktisk resultat. FlexUnit vil da si fra om funksjonene gjør det de er ment til å gjøre. Figur 26. Her ser vi resultatet av testing av avkomsobjektet 37

40 13 Feilsøking i PHP Feilsøking i PHP byr på utfordringer da ingen kompilator viser feilmeldinger og retter syntaks. Derfor vil vi her kort gjøre rede for metoder og hjelpemidler vi benyttet under feilsøking Logging av verdier Vi benyttet oss av en selvlaget loggfunksjon som lagret variabler til fil. På den måten kunne vi se om variablene inneholdt det de skulle Meldinger til klienten Det er ikke alle feil i PHP som sender en feilmelding tilbake til klienten. Slike feil kan være vanskelige å rette da serverdelen bare stopper uten at klienten noen gang får svar. Vi løste dette problemet med å sette inn en kodesnutt i PHP-koden som viste en feilmelding på klientsiden. Ved å flytte snutten rundt i koden, kunne vi lett se hvilke funksjoner som resulterte i at snutten ikke lenger viste noen feilmelding. Figur 27. Feilmelding i applikasjonen For å vise en feilmelding skrives kodesnutten: throw(new Exception('Feilen ligger ikke her', "1")); 13.3 PHPUnit Da PHP er et scriptspråk er det ingen kompilator som gir feilmeldinger ved bygging av koden. Det kan derfor ligge syntaksfeil i kildekoden som ikke kommer til syne før den spesifikke funksjonen blir kjørt. Med PHPUnit kan man lage logiske tester som kjører funksjonene i scriptet. På en slik måte at man få 38

41 en oversikt over hvilken kode som fungerer, og hvilken kode som inneholder feil. Her er et eksempel på en testklasse. Figur 28. Testklasse i PHP I dette tilfellet skal vi teste om klassen FilvaliderController returnerer riktig verdi. Funksjonen assertequals brukes til dette og kan skrives på denne måten: $fv = new FilvaliderController(); $this->assertequals("eier", $fv-> getfiltypefrafil (dirname( FILE ).'/../../../../dummyfiler/eier.dat')); Hvis assertequals returnerer true i dette tilfellet så vil «Console»-vinduet vise at testen er godkjent. Hvis ikke, vil den vise dette: PHPUnit by Sebastian Bergmann. F. Time: 0 seconds There was 1 failure: 1) testgetfiltypefrafil(filvalidercontrollertest) Failed asserting that two strings are equal. expected string <Eier2> difference <?> got string <Eier> /no/airdog/controller/filvalidercontrollertest.php:11 FAILURES! Tests: 2, Assertions: 14, Failures: 1. På denne måten kan en feilsøke i koden på en effektiv måte. 39

42 14 Feilsøking mellom PHP og Flex Ved feilsøking av hva som blir sendt mellom klient og server er det ikke alltid mulig å bruke de teknikkene som er beskrevet i kapitlene: Feilsøking i PHP og Feilsøking i Flex. Noen ganger må en se på de pakkene som blir sendt mellom klient og server. Vi vil her gjøre rede for en metode som lot oss feilsøke i trafikken som går mellom PHP og Flex Charles Charles er et program som fungerer som en HTTP-proxy. Programmet overvåker trafikk slik at man enkelt kan se hva som blir overført mellom klient og server. Charles har innbygget støtte for å overvåke flere overføringsformater. Flash Player bruker blant annet AMF0 og AMF3. Charles kan også brukes til å sjekke tidsbruk ved overføringer. Noe som var nyttig da vi ville effektivisere applikasjonen. Figur 29. Charles Figur 29 viser en oversikt over hva som blir sendt over AMF når en bruker gjør et hundesøk. 40

43 15 Kravspesifikasjonen og det endelige produktet Bak kravspesifikasjonen som styringsdokument lå en rekke forventninger til produktet vi leverte. Her vil vi reflektere rundt kravspesifikasjon og det endelige produktet. Mer om kravspesifikasjonen som styringsdokument er omtalt i prosessrapporten Oppfyllelse av krav Alle storyene som ble lagt frem per iterasjon ble fullført. I kapittelet Smidig utviklingsmetodikk nevnes det at user storyes fungerer som funksjonelle krav til systemet. Kravene listes i utgangspunktet opp som en svært optimistisk ønskeliste av en rekke funksjoner. Det var ikke forventet av oppdragsgiver at vi skulle klare å levere alle funksjoner ved prosjektets slutt. Det var opp til oppdragsgiver å prioritere hvilken funksjonalitet de ønsket å ha implementert for å kunne benytte seg av produktet så langt det ble ferdig. Likevel klarte vi å levere langt flere funksjoner enn hva som var regnet med i utgangspunktet. Funksjonelle krav som ikke ble implementert til fordel for prioritert funksjonalitet, blir nærmere omtalt i kapittelet Utvidelsesmuligheter under Estimert funksjonalitet Tilbakemelding fra oppdragsgiver Da vi ikke gikk ut fra en tradisjonell kravspesifikasjon, men fulgte en Scrum-basert smidig utviklingsmetodikk, ville den endelige kravspesifikasjonen i form av user storyer alltid stemme med ferdig produkt. På den andre siden fikk vi gode tilbakemeldinger både på antall gjennomførte user storyer og det ferdige produktet. Hvorvidt kravspesifikasjonen stemmer overrens med produktet kan vurderes etter måten løsningen tilfredstiller kravene til oppdragsgiver. Sitatene som følger kan leses i sin helhet under delkapittelet Ord fra eksterne veiledere: "Noen er såpass fornøyd med løsningen at de ønsker at den skal presenteres slik den er i dag for alle klubbene!" "Ekstra hyggelig var det å se at de ble ferdige med brukerhistorien for Årboka, som før prosjektstart var fryktet å være for omfangsrik til å kunne utføres innenfor tiden." "De overrasket oss [...]" "Det viktigste kravet [...] må også sies å være opprettholdt. Bra!" - Bekk 41

44 16 Utvidelsesmuligheter Dette kapittelet vil ta for seg tanker rundt hvilke funksjoner som kan utvides, endres eller legges til. Først vil vi redegjøre for endringer av eksisterende funskjonalitet. Videre vil vi presentere user storyene som ligger i prosjektets backlog i Pivotal Tracker. Etter dette vil vi foreslå ny funksjonalitet. Til slutt vil vi ta for oss hvilke andre bruksområder vi mener kan være aktuelle for systemet Endringer i eksisterende funksjonalitet Nyhetsleser Slik det er i dag er nyhetsleseren implementert i to versjoner: en er skrevet i ActionScript på klientsiden, mens den andre er skrevet i PHP på serversiden. Det er gjort slik fordi produksjonsserveren mangler noe for få leseren implementert i PHP til å fungere. Akkurat hva det er vet vi ikke, da vi ikke hadde tilgang til konfigurasjonsfilene eller oppsettet ellers på produksjonsserveren. Vi regner med at det vil, med små endringer i serverens konfigurasjon, være mulig å ta i bruk nyhetsleseren. Denne vil hente nyheter, lage nyhetsobjekter og sende en liste av disse til klientene. Det vil da ikke være nødvendig å implementere en nyhetsleser for hver eneste plattform klienten eventuelt oversettes til. Denne listen kan også caches på serversiden slik at et kall til server ikke nødvendigvis resulterer i henting og parsing av nyheter Caching Under utvikling prioriterte vi sanntidsinformasjon fremfor caching uten å vite endelige spesifikasjoner for produksjonsserver. Vi ser nå at mange av spørringene og utregningene som skjer på serveren er tunge og bruker lengre tid enn optimalt. Det kan opprettes egne tabeller der alle, eller de tyngste, utregningene som foretas blir mellomlagret. Dette kan gjøres slik at utregningene blir kjørt: I perioder med lav trafikk Av administratorer som har rettighet til det Ved innlegging eller endring av informasjon andre steder i databasen Ved første spørring som krever det etter et gitt tidsintervall siden forrige Punktene over kan også kombineres og utvides. Tiden det tar før klient får svar fra server kan bli kraftig redusert som resultat av dette, da det i beste fall kun foretas enkle spørringer uten noen utregninger. 42

45 Estimert funksjonalitet Oppdragsgiver hadde i utgangspunktet flere user storyer, altså funksjonelle krav, enn det som var regnet med å få gjennomført. Likevel ble kravene estimert og lagt i backlog for eventuell senere utvidelse. Vi vil ikke gå nærmere inn på disse enn å liste dem opp her da de ikke er tatt med i kravspesifikasjonen. En bruker skal kunne: Sammenligne to hunders avkomsstatistikker Lage valpeannonse som vises på en oppslagstavle Se rasens utstillingsresultater for et gitt år Avlstallsrapport for alle hunder for å finne gode avlstall HQ-gjennomsnitter for avkom med filter for tisper, hannhunder og minimum antall avkom Skrive SQL-spørringer i applikasjonen og se resultater i en datagrid for å lage personlige rapporter, gitt at spørringene ikke endrer eller henter sensitive data Administrator skal kunne: Redigere person Redigere arrangør Redigere veterinær Redigere kull Oppdatere databasen med nye HQ- og avlsverdier Oppdatere databasen med genotypetall for epilepsi Låse Last opp-knappen under opplasting slik at det ikke er mulig å laste opp to filer samtidig Redigere utstillingsresultat Deploye applikasjonen automatisk til airdog.no ved utvikling slik at den kan testes 43

46 16.2 Ny funksjonalitet Vi gjør her rede for mulig ny funksjonalitet som er relevant til brukerne av applikasjonen Helse En egen visning for helse kan legges til hundenes profil der man kan se informasjon om vaksiner, operasjoner, sykdommer og andre hendelser som gir inntrykk av hundens helsetilstand. Denne informasjonen ligger tilgjengelig i dat-filene NKK gir fra seg. Det er ikke avklart om dette er konfidensielt eller privilegert informasjon som kun få sentrale medlemmer i klubbene, eller eier, får lov til å benytte seg av Favoritthunder Vi ser for oss at en bruker skal kunne ha en liste med sine egne favoritthunder slik at brukere har rask tilgang til de hundene hun eller han er mest interessert i å følge med på. Dette kan igjen utvides med mappestruktur eller et kategoribasert system med flere lister Andre bruksområder Med få eller enkle modifikasjoner kan AirDog benyttes av helt andre brukergrupper. Eksempler på dette kan være: Idrettslag Hvis et idrettslag ønsker å holde styr på konkurranseresultater kan de registrere personer i systemet og registrere konkurranseresultater i stedet for jaktprøveresultater. Stamtreet kunne bli gjort om til fremvisning av konkurranseresultater, slik at det blir vist deltagere i en cup, semifinaler og finale. Rankinglisten kan også være en sentral rolle i et slikt system Familier Her kan man registrere familiemedlemmer istedenfor hunder. Funksjonene avkom og stamtre kunne da bli tatt i bruk for å få en oversikt over sin egen, og andres, familie. Systemer som dette kan bidra til økt effektivitet når det gjelder slektsforskning. En kan også se for seg at jaktprøver kunne bli brukt som en oversikt over en families oppgaver. Som for eksempel å gå ut med søppel, vaske hus, vaske klær og lignende Konklusjon Vi mener AirDog har stort utvidelsespotensial både når det gjelder ny funksjonalitet og konvertering til liknende bruksområder. AirDog har allerede en rekke planlagte funksjoner som under vår prosjektperiode ble nedprioritert, men er fortsatt aktuelle for sluttbrukerne. I dat-filene fra NKK ligger det fortsatt mer data som kan utnyttes, så AirDog har potensial til å få en rekke nye funksjoner dersom behovet skulle være der. AirDogs oppbygning er løst såpass generisk at det, med enklere modifikasjoner, er mulig å lage nye løsninger til andre formål. Med dette mener vi at vi har laget et solid fundament med stort utvidelsespotensial. 44