Transcript Hovedprosjekt - Rapport - Kristoffer Strøm Bergset

Hovedprosjekt
Tittel:
D1304: Mobil-app til støtte av kurs og undervisning
Kandidatnummer(e):
Kristoffer Strøm Bergset (1709), Terje Nilsson Wallem, Johan Alexander de Lima Hessen
Dato:
Fagkode:
Fagnavn:
31.05.13
ID303006
Hovedprosjekt - Data og automasjon
Studium:
Dokument tilgang:
Ant sider/Vedlegg: Bibl. nr:
Bachelor i ingeniørfag - datateknikk
92 / 4
Veileder(e):
Mikael Tollefsen
Sammendrag:
Dette prosjektet omhandler videreutviklingen av en e-læringsapplikasjon utviklet for Høgskolen i Ålesund i et
tidligere prosjekt. Hensikten med e-læringsapplikasjonen er å være et støtteverktøy i undervisningen for både
studenter og forelesere.
E-læringsapplikasjonssystemet består av en mobilapplikasjon for Android enheter og en webapplikasjon laget
for Java Enterprise Edition plattformen.
Målet med dette prosjektet er å forbedre applikasjonen ved å gjøre den mer stabil og fleksibel. I tillegg
ønsker vi å integrere utvalgte funksjoner fra Fronter, BibSys og TimeEdit i applikasjonen.
Resultatet ble en stabil e-læringsapplikasjon hvor man kan legge til og fjerne innhold og funksjoner på
en fleksibel måte. Den kan også søke etter bøker i skolens bibliotek, vise timeplanen for en gitt klasse eller fag,
og fra Fronter kan den presentere meldinger fra lærere, vise tilgjengelige dokumenter og status på innleveringer.
Denne rapporten inneholder en beskrivelse av hvilke teknologier som ble brukt, prosjekts fremgangsmåte,
resultatet av prosjektet, brukerdokumentasjon for mobilapplikasjonen og webapplikasjonen, drøftingen av
resultatet og konkluderer med at målene ble oppfylt.
Denne oppgaven er en eksamensbesvarelse utført av studenter ved Høgskolen i Ålesund.
Postadresse
Høgskolen i Ålesund
N-6025 Ålesund
Norway
Besøksadresse
Larsgårdsvegen 2
Internett
www.hials.no
Telefon
70 16 12 00
Epostadresse
[email protected]
Telefax
70 16 13 00
Bankkonto
7694 05 00636
Foretaksregisteret
NO 971 572 140
Høgskolen i Ålesund
Hovedprosjekt
Side 2
INNHOLD
1 INNLEDNING
2 TEORETISK GRUNNLAG
2.1 Arkitekturer, teknologier og konsepter
2.1.1 Systemintegrasjon . . . . . . .
2.1.2 Robots.txt . . . . . . . . . . .
2.1.3 Model View Controller . . . . .
2.1.4 Web Services . . . . . . . . . .
2.1.5 AJAX . . . . . . . . . . . . . .
2.2 Programmering . . . . . . . . . . . . .
2.2.1 Java . . . . . . . . . . . . . . .
2.2.2 Regulære uttrykk og Java . . .
2.2.3 Java EE / EJB . . . . . . . . .
2.2.4 Bibliotek . . . . . . . . . . . .
2.3 Programverktøy . . . . . . . . . . . . .
2.3.1 NetBeans . . . . . . . . . . . .
2.3.2 GlassFish . . . . . . . . . . . .
2.3.3 Git . . . . . . . . . . . . . . . .
2.3.4 Android . . . . . . . . . . . . .
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
11
11
14
14
14
14
15
17
18
18
18
18
18
3 MATERIALER OG METODE
3.1 Data . . . . . . . . . . . . . . . . . . . . .
3.1.1 Fronter . . . . . . . . . . . . . . .
3.1.2 TimeEdit . . . . . . . . . . . . . .
3.1.3 BibSys . . . . . . . . . . . . . . . .
3.2 Verktøy . . . . . . . . . . . . . . . . . . .
3.3 Materialer . . . . . . . . . . . . . . . . . .
3.3.1 Smartelefon - Galaxy Nexus . . . .
3.3.2 Tablet - Nexus 7 . . . . . . . . . .
3.3.3 Server . . . . . . . . . . . . . . . .
3.4 Utviklingssyklus . . . . . . . . . . . . . .
3.5 Framgangsmetode . . . . . . . . . . . . .
3.5.1 Fronter . . . . . . . . . . . . . . .
3.5.2 TimeEdit . . . . . . . . . . . . . .
3.5.3 BIBSys . . . . . . . . . . . . . . .
3.5.4 Videreutvikling av applikasjonene .
3.5.5 Arbeidsprosessen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
20
20
20
20
21
21
21
21
22
22
22
22
22
23
23
4 RESULTATER
4.1 Mobilapplikasjonen . . . . . . . . . . . . . . . .
4.1.1 Sammenligning med det gamle systemet
4.1.2 Git statistikk . . . . . . . . . . . . . . .
4.1.3 Installasjonsinstrukser . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
27
28
28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Høgskolen i Ålesund
Hovedprosjekt
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
30
37
38
38
40
50
51
51
52
52
54
55
71
73
74
5 DRØFTING
5.1 Systemintegrasjon . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Integrasjon i webapplikasjon vs mobilapplikasjon . . . .
5.2 Fronter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 TimeEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Webscraping . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Løsning . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 BibSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Implementasjon av API . . . . . . . . . . . . . . . . . .
5.4.2 Valg av struktur . . . . . . . . . . . . . . . . . . . . . .
5.5 Mobilapplikasjonen . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Android app versus webapplikasjon i nettleser . . . . . .
5.6 Webapplikasjonen . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Systemarkitekturen . . . . . . . . . . . . . . . . . . . . .
5.6.2 ER modellen . . . . . . . . . . . . . . . . . . . . . . . .
5.6.3 Serversikkerhet . . . . . . . . . . . . . . . . . . . . . . .
5.6.4 Manglende eller ikke-implementert mulig funksjonalitet
5.6.5 Gjenværende bugs . . . . . . . . . . . . . . . . . . . . .
5.6.6 Fremtid . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
79
79
79
79
80
80
80
80
81
81
81
81
82
82
83
83
83
4.2
4.3
4.1.4 Forklaring av brukergrensesnittet . . . . . . . .
4.1.5 Serviceprossesen . . . . . . . . . . . . . . . . .
4.1.6 Datainnlasting . . . . . . . . . . . . . . . . . .
4.1.7 Fragmenter/Moduler . . . . . . . . . . . . . . .
Webapplikasjonen . . . . . . . . . . . . . . . . . . . . .
4.2.1 Git statistikk . . . . . . . . . . . . . . . . . . .
4.2.2 Installasjonsinstrukser . . . . . . . . . . . . . .
4.2.3 Administrasjonsgrensesnitt . . . . . . . . . . .
4.2.4 Modulært fragmentsystem . . . . . . . . . . . .
4.2.5 ER modell . . . . . . . . . . . . . . . . . . . . .
4.2.6 REST tjenester . . . . . . . . . . . . . . . . . .
Systemintegrasjon . . . . . . . . . . . . . . . . . . . .
4.3.1 TimeEdit . . . . . . . . . . . . . . . . . . . . .
4.3.2 Lovlige hensyn . . . . . . . . . . . . . . . . . .
4.3.3 Utvikling av løsning . . . . . . . . . . . . . . .
4.3.4 Integrering av TimeEdit i mobil-applikasjonen
4.3.5 Fronter . . . . . . . . . . . . . . . . . . . . . .
4.3.6 BibSys . . . . . . . . . . . . . . . . . . . . . . .
Side 3
6 KONKLUSJON
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
7 REFERANSER
85
7.1 Prosjektlinker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A VEDLEGG
91
Høgskolen i Ålesund
Hovedprosjekt
Side 4
SAMMENDRAG
Dette prosjektet omhandler videreutviklingen av en e-læringsapplikasjon utviklet for Høgskolen i Ålesund i et
tidligere prosjekt. Hensikten med e-læringsapplikasjonen er å være et støtteverktøy i undervisningen for både
studenter og forelesere.
E-læringsapplikasjonssystemet består av en mobilapplikasjon for Android enheter og en webapplikasjon laget
for Java Enterprise Edition plattformen.
Målet med dette prosjektet er å forbedre applikasjonen ved å gjøre den mer stabil og fleksibel. I tillegg ønsker
vi å integrere utvalgte funksjoner fra Fronter, BibSys og TimeEdit i applikasjonen.
Resultatet ble en stabil e-læringsapplikasjon hvor man kan legge til og fjerne innhold og funksjoner på en
fleksibel måte. Den kan også søke etter bøker i skolens bibliotek, vise timeplanen for en gitt klasse eller fag, og
fra Fronter kan den presentere meldinger fra lærere, vise tilgjengelige dokumenter og status på innleveringer.
Denne rapporten inneholder en beskrivelse av hvilke teknologier som ble brukt, prosjekts fremgangsmåte, resultatet av prosjektet, brukerdokumentasjon for mobilapplikasjonen og webapplikasjonen, drøftingen av resultatet
og konkluderer med at målene ble oppfylt.
Høgskolen i Ålesund
Hovedprosjekt
Side 5
TERMINOLOGI
Begreper
Aktiviteter og Fragmenter - I Android er hvert skjermbilde bygd opp av en aktivitet og kan inneholde flere
fragmenter. Aktiviteten styrer fragmentene og kan hente fram, vise disse og skjule dem igjen. Et fragment kan
være ett helt skjermbilde eller bare en del av ett, så et skjermbilde kan være oppbygd av flere fragmenter. [ 1 ]
I dette prosjektet brukes begrepet “fragment” også til å beskrive moduler med informasjon i webapplikasjonen
og mobilapplikasjonen.
Bug - Dette er en feil i kildekoden som resulterer i et uventet og ofte uønsket resultat.[ 2 ]
Chen notasjon - Et sett med teknikker utviklet av Peter Chen for å lage entity-relationship modeller (ER
modeller). [ 3 ]
Commit - Dette begrepet refererer i sammenheng med denne rapporten til å bidra med kildekode til revisjonskontrollsystemet Git(se begrepet “GitHub”). [ 4 ]
E-læringsapplikasjon - Dette begrepet beskriver hele systemet som denne rapporten omhandler
GET - En metode for å hente data over HTTP protokollen.
[5] [6]
GitHub - en gratis hostingtjeneste for prosjekter som bruker revisjonskontrollsystemet Git. Git brukes for
å dele prosjektfiler mellom utviklere under produksjonen. For mer informasjon om Git se teoretisk grunnlag.
GUI - Graphical User Interface, eller grafisk brukergrensesnitt er en betegnelse på en grafisk representasjon av
data på en skjerm
Mobilapplikasjon - Dette begrepet beskriver android applikasjonen som denne rapporten omhandler.
VMWare vSphere cluster - Et virtualiseringsmiljø som kan inneholde mange virtuelle maskiner med forskjellige operativsystemer. [ 7 ] [ 8 ]
Webapplikasjon - Dette begrepet beskriver serversiden av systemet som denne rapporten omhandler
Serialisering - Konvertering av data fra objekter i minne til en bitstrøm som kan lagres i en fil eller sendes
over et nettverk. [ 9 ]
Sømløst grensesnitt - Dette beskriver et grensesnitt hvor to eller flere tjenester kommer sammen i et grensesnitt uten at det oppleves som man bruker forskjellige tjenester.[ 10 ]
Web scraping - Dette er en teknikk for innhenting av data fra en nettside. Man henter ut dataene man
vil ha ved å prosessere HTML-koden som vises på en nettside direkte. Med denne teknikken kan man hente
ut data fra nesten hvilken som helst nettside. Ulempene med metoden er at den er treg å implementere, og er
veldig sårbar for visuelle forandringer hos kildenettsiden. [ 11 ]
Høgskolen i Ålesund
Hovedprosjekt
Side 6
Web crawler - En web crawler er et program som systematisk går igjennom alle nettsider på Internett.
Denne kan ha mange hensikter, men vanligvis er hensikten å indeksere sidene og er typisk for store søkemotorer
som Google, Bing og Yahoo. [ 12 ]
Forkortelser
AJAX
APK
CSS
DOM
EJB
ER
GUI
HTML
Java EE
JAX-RS
JSF
JSON
JSP
JVM
NTNU
POJO
Regex
REST
SDK
SRU
URI
URL
WAR
Asynchronous JavaScript and XML
Android application package file
Cascading Style Sheets
Document Object Model
Enterprise JavaBeans
Entity Relationship
Graphical User Interface
HyperText Markup Language
Java Enterprise Edition
Java API for RESTful Web Services
JavaServer Faces
JavaScript Object Relation
JavaServer Pages
Java Virtual Machine
Norges Teknisk-Naturvitenskapelige Universitet
Plain Old Java Object
Regular Expression
Representational State Transfer
Software Development Kit
Search/Retrieval via URL
Uniform resource identifier
Uniform resource locator
Web application ARchive
Høgskolen i Ålesund
Hovedprosjekt
1
Side 7
INNLEDNING
Våren 2012 ble det startet et prosjekt for å lage en e-læringsapplikasjon for Android mobiltelefoner og en medfølgende webapplikasjon for å administrere innholdet i mobilapplikasjonen. Dette prosjektet var utviklet av elevene
i faget “ID303911 - Mobile og distribuerte applikasjoner [ 13 ] ” der Mikael Tollefsen var lærer og prosjektleder
og Harald Yndestad var prosjekteier. Elevene i dette prosjektet var Kristoffer Strøm Bergset, Terje Nilsson
Wallem, Johan Alexander de Lima Hessen og Lena Urkedal. Resultatet av dette prosjektet var en prototype av
mobilapplikasjonen og webapplikasjonen med begrenset funksjonalitet.
Bergset, Wallem og Hessen fikk tilbud av Tollefsen om å videreutvikle systemet høsten 2012 i et eget prosjekt. Som i det første prosjektet var Tollefsen prosjektleder og Yndestad prosjekteier. Dette prosjektet ble
finansiert av studierådet etter en søknad om midler. Det ble avgjort at mobilapplikasjonen skulle utvikles fra
bunnen igjen, basert på erfaringer gjort under utviklingen av prototypen. Hensikten med denne avgjørelsen var
å utvikle en mer stabil og fleksibel løsning. Sluttproduktet fra dette prosjektet var en uferdig og ustabil versjon
av mobilapplikasjonen og webapplikasjonen med det meste av basisfunksjonaliteten implementert.
Da utviklingen av e-læringsapplikasjonen ikke ble ferdigstilt i de to tidligere prosjektene, ble det avgjort at
utviklingen skulle fortsette som en del av hovedoppgaven til de tre prosjektdeltagerne/studentene. I tillegg
skulle enkelte funksjoner fra skolens forskjellige datasystemer integreres i applikasjonen.
Problemstillingene som dette prosjektet er ment å løse er da følgende:
• Det finnes ingen samlet tilgang til skolens mange separate IT løsninger
• Mobilapplikasjonen som ble utviklet høsten 2012 er ikke ferdig utviklet og ustabil
Disse problemstillingene ønsker vi å løse ved å videreutvikle og lage en stabil og brukbar versjon av systemet. I
tillegg ønsker vi å implementere noen av skolens egne datasystemer i mobilapplikasjonen. Systemene vi ønsker
å integrere er studentsystemet Fronter, timeplansystemet TimeEdit og bibliotekdatabasen BibSys. Her følger
en overordnet struktur over hvordan skolens systemer skal integreres.
Høgskolen i Ålesund
Hovedprosjekt
Side 8
Figur 1.1: Diagram som viser forholdet mellom mobilapplikasjonen, webapplikasjonen og Fronter, BibSys og
TimeEdit
Om man begynner fra toppen av illustrasjonen, har man de tre systemene fra skolen som skal implementeres.
Serveren(midterste nivå av illustrasjonen) henter inn data fra disse tre tjenestene etter behov, og leverer dem
til mobilapplikasjonen(nederste nivå av illustrasjonen) hvor de presenteres til brukeren.
Målene som dette prosjektet ønsker å nå:
• Å fullføre utviklingen av den eksisterende e-læringsapplikasjonen
• Å gjøre den nye versjonen av e-læringsapplikasjonen mer fleksibel
• Å integrere utvalgte funksjoner fra de eksterne systemene TimeEdit, Fronter og BibSys i e-læringsapplikasjonen
Denne rapporten beskriver teknologiene og materialene som ble brukt under prosjektet, hvordan det ble gått
frem for å løse problemstillingene, drøfting av valg og alternative løsninger, løsningen som ble utviklet, og
resultatet av prosjektet oppsummert i en konklusjon.
Høgskolen i Ålesund
Hovedprosjekt
2
Side 9
TEORETISK GRUNNLAG
Denne seksjonen beskriver de viktigste begrepene, konseptene og teknologiene som er brukt som grunnlag for
utvikling, gjøre vurderinger samt å beskrive metode og resultat i prosjektet. Noen av beskrivelsene vil også
inneholde bilder eller kodeeksempler.
2.1
Arkitekturer, teknologier og konsepter
Denne delen tar for seg de forskjellige teknologier, arkitekturmodeller og konsepter som er benyttet som designgrunnlag for prosjektet og er ellers omtalt i rapporten. Inndelingen av seksjoner er satt opp hierarkisk (dvs. at
f.eks teknologier som tilhører en annen teknologi befinner seg i en underseksjon), og lineært oppbyggende. Det
sistnevnte innebærer at den tidligere delen av seksjonen gir grunnlag for å enklere forstå senere deler.
2.1.1
Systemintegrasjon
Definisjon
Systemintegrasjon er å få to eller flere systemer til å samhandle. Det har også blitt definert som "å bringe
subsystemer sammen i et system, og forsikre at subsystemene arbeider sammen i systemet" [ 14 ] .
Systemintegrasjon kan gjennomføres ved å få de aktuelle systemene til å snakke med hverandre, det ene snakker
til det andre(som en slags monolog). I situasjoner hvor det er mer enn to systemer kan det være en kombinasjon
av de to løsningene. Det kan også forekomme at det mellom to(eller flere) systemer blir det implementert et
tredje program som har som oppgave å koordinere de andre.
I systemintegrasjon snakker man ofte om cohesion, eller grad av avhengigghet. Dette refererer til hvor mye
de forskjellige subsystemene er avhengige av hverandre. Man ønsker å ha så lav cohesion som mulig samtidig
som at systemet må kunne utføre de oppgavene som kreves av det. [ 15 ]
I systemintegrasjon finnes det en del forskjellige måter for programmer å samhandle. Her følger en kort beskrivelse av de vanligste mekanismene:
Data Scraping
Data-scraping er en teknikk som involverer bruken av software-program til å hente ut spesifikk og meningsfull
data fra et annet datasett formatert for å presentere menneskeleselig data. [ 16 ] [ 17 ]
Begrepet menneskeleselig beskriver informasjon formatert på en måte beregnet for å kunne vises til og forstås
av en sluttbruker. Dette innebærer ofte at den relevante informasjonen man søker er omsluttet av irrelevant
eller redundant data, eller befinner seg uforutsigbart plassert i datasettet. Fordi datastrukturen dermed ikke
egner seg for overføring av data mellom programmer, skiller data-scraping fra syntaktisk [ 18 ] data-analyse eller
parsing som benytter seg av etablerte formateringsregler. Man kan si at data-scraping går ut på å gjøre ellers
utilgjengelig data tilgjengelig for forståelse av programmer, eller å sette ustrukturert data i system.
Web-scraping (se begreper) er en mer spesifikk teknikk innen data-scraping for å lokalisere og hente ut data
fra nettsider som inneholder ustrukturert data. En nettside svarer typisk med data formatert som HTML,
Høgskolen i Ålesund
Hovedprosjekt
Side 10
og selve scraping-delen vil da bestå i å filtrere vekk unødvendig data, og plukke ut og sortere relevant data
programmatisk.
API
Et API (Application Programming Interface) er et grensesnitt som gir eksterne brukere og applikasjoner tilgang
til en annen applikasjons eller systems tjenester, funksjoner og data. [ 19 ] Ved bruk av API kan man bygge store
modulære systemer. Dette vil også si at om man vil endre måten programmet fungerer på, så kan man det uten
at det påvirker andre program som avhenger av det så lenge man beholder den samme API’en. [ 20 ]
Fil-dump baserte systemer
Eldre datasystemer hadde ofte ikke tilgang på store mengder minne. Variabler og mellomlagring av data måtte
derfor skrives til disk. Dette gjorde at om man ville hente inn data fra et fil-dump basert program, måtte man
lese fra disse filene. Den største ulempen med denne metoden er at disk IO er veldig tregt i forhold til IO fra
minne, så disse operasjonene var generelt ganske trege. Et annet problem var samtidighet mellom flere kilder
når de vil lese og/eller skrive til/fra den samme kilden. Om et program skriver til en fil samtidig som et annet
leser fra den, kan det oppstå feil. Dette er riktignok håndtert automatisk i nyere operativsystemer, men det kan
fortsatt oppstå feil hvor et program ikke gir fra seg rettighetene til å lese/skrive til en fil.
Selv om dette er en lite brukt måte å utvikle systemer på idag, finnes det fremdeles i bruk i bedriftsmarkedet.
2.1.2
Robots.txt
Dette er en protokoll som brukes av nettsider til å fortelle nettjenester om de få lov til å innhente data automatisk.
De vanligste tjenestene som bruker denne sjekken er søkemotorer(google, yahoo etc.), men den er aktuell for alt
og alle som vil innhente data fra en nettside eller tjeneste.
Protokollen kan forby tilgang til deler av sin egen mappestruktur, eller for å blokkere spesifikke tjenester(ofte
blokkere søkemotorer). Det er viktig å merke seg at denne protokollen ikke aktivt blokkerer noe som helst, men
fungerer som internettets trafikkskilt. Det vil si at protokollen ikke hindrer deg i å gjøre noe, men den viser om
det er lov eller ikke.
Høgskolen i Ålesund
Hovedprosjekt
2.1.3
Side 11
Model View Controller
Figur 2.1: Model View Controller-modellen
Model View Controller (MVC) er en arkitektur for programvare som begrenser hvilke deler av programmet
brukeren interagerer med. "Model"-delen er kjernen i applikasjonen og består av dataen til applikasjonen
(databasen), applikasjonslogikk, metoder og funksjoner. "View"-delen består av den informasjonen fra modelllaget som er tiltenkt brukeren som for eksempel tekst, bilde, lyd osv. "Controller" delen består av håndtering
av brukerens input for å styre de to andre lagene. [ 21 ]
2.1.4
Web Services
En web service, eller nett-tjeneste, er en mekanisme som muligjør kommunikasjon eller tilbyr tilgang til funksjoner
[ 22 ]
over et nettverk [ 23 ] . Slike nett-tjenester bruker typisk HTTP/HTTPS over internett, og er dermed en
form for distribuert system hvis tilhørende komponenter tilgjengelig for en bred rekke av enheter[ 24 ] . Det finnes
flere typer nettjenester og kan deles grovt i to grupper, SOAP- og REST-baserte nett-tjenester. [ 25 ] [ 26 ]
REST
REST (Representational State Transfer) er en ikke-protokoll-spesifikk dataoverførings-arkitektur bestående av
klienter og servere. Denne arkitekturen beskriver en del begrensinger som når benyttet i et distribuert system
fører til nyttige egenskaper som loose coupling og horisontal skalerbarhet. [ 27 ] En typisk REST transaksjon
kan beskrives på følgende måte; en klient sender en forespørsel til en server, som bearbeider forespørselen og
sender tilbake data. Måten dette foregår på, metodene og standardene som benyttes er hva begrensningene
definerer. Nettjenester som er designet i tråd med REST’s arkitektur-prinsipper kalles "RESTful services".
Grunnleggende arkitekturprinsipper i REST:
• Addressability
Ethvert objekt or enhver ressurs i et system skal være tilgjengelig gjennom en unik identifikator. (URI)
• The Uniform, Constrained Interface
Kun operasjoner som er definert innenfor protokollen tjenesten bruker er tillatt. Det skal med andre
ord ikke opprettes egne funksjoner for handlinger i URI’en. I eksempelvis HTTP begrenser man seg til
Høgskolen i Ålesund
Hovedprosjekt
Side 12
metodene som GET, PUT, DELETE, POST, etc... Formålet med dette er b.la å gjøre tjenesten lettere
forståelig ved å bygge på eksisterende terminologi og funksjonalitet.
• Representation-Oriented
En ressurs skal representeres i en dataoverføring tilbudt av en nett-tjeneste. En hent-operasjon skal gi
tilbake en representasjon av ressursen, og en endrings-operasjon skal sende en representasjon av ressursen
som skal endres.
• Stateless communication
Det skal ikke lagres sesjonsdata på serveren. Serveren skal kun håndtere tilstanden til resursser som er
tilbudt gjennom nett-tjenester.
• HATEOAS (Hypermedia As The Engine of Application Sate)
Dataformatet skal styre tilstandsendringe i applikasjonen. Hvis det er nødvendig å begrense tilgang eller
aksessere tjenesten på en spesiell måte, skal dette håndteres av hypermedia (f.eks en nettside)
REST bruker API-ressurslinker (URI) for å aksessere resursser, eksempel på dette kan være: URL for å hente
en kunde med ID 32133:
1
h t t p : / / c u s t o m e r s . m y i n t r a n e t . com/ c u s t o m e r s /32133
URI-design
En URI tjener som en identifikator til endepunkt i et system som tilbyr web-services. Defineringen og utformingen av disse URI’ene har dermed mye å si for de som vil aksessere disse endepunktene, enten om de er
programvareutviklere eller vanlige brukere. I et RESTful system vil en URI sørge for addressability-prinsippet,
og en RESTful URI burde derfor følge arkitekturprinsippene så langt det er anvendbart. [ 28 ]
Høgskolen i Ålesund
Hovedprosjekt
Side 13
Dataformater
Denne delen beskriver forskjellige dataformat som har blitt benyttet i prosjektet og er relevant ellers for denne
rapporten.
JSON JSON (JavaScript Object Notation) er et lettvekts dataformidlingsformat basert på delsyntaks fra
JavaScript. Enkelheten i JSON ligger i at det er lettlest og lettskrevet av mennesker, noe som gjør jobbing med
JSON til en relativt enkel oppgave sammenlignet med formater med lignende funksjonsområder. (b.l.a XML).
I hovedsak er JSON basert på nøkkel/verdi-par og lister som har en nøkkelverdi som identifikasjon. Som
nøkkelverdier bruker JSON strenger som demonstrert i figuren nedenfor:
1
{
3
5
7
9
11
13
15
17
19
21
}
day : "Man" ,
date : "7 jan " ,
lectures :
[
{
l e c t u r e S t a r t : " 08:15 " ,
lectureEnd : " 10:00 " ,
type : " F o r e l e s " ,
c l a s s I d : "AU1, DA1, AU−y1 , DA−y1 " ,
room : " B o r g u n d f j o r d e n " ,
t e a c h e r s : "Blom Martin " ,
comment : n u l l ,
courses :
[
{
courseName : " F y s i k k og k j e m i " ,
courseID : n u l l
}
]
]
Kodesnutt 2.1: (JSON-formatert data)
Verdiene som er knyttet til en nøkkel kan være av følgende typer:
• Strenger
• Boolske verdier (true/false)
• Matriser
• Objekter (en liste med nøkkel/verdi-par)
• Null-verdier
JSON blir ofte brukt til serialisering av data som skal sendes mellom server- og klientapplikasjoner. JSON
er plattform-uavhengig. [ 29 ] [ 30 ] [ 31 ]
XML XML er et dataformat som er ment å kunne leses både av mennesker og av maskiner. Mange nettjenester
bruker formatet til å representere og strukturere svardata for deres API’er. [ 32 ] [ 33 ]
Høgskolen i Ålesund
Hovedprosjekt
2.1.5
Side 14
AJAX
AJAX (Asynchronous JavaScript and XML) er en gruppe teknologier brukt til å lage asynkrone klientsidefunksjoner i webapplikasjoner. Dette vil si at med AJAX kan nettsider laste inn og sende data etter innlastingen
av selve nettsiden, dette kan forenkle flyten i webgrensesnittet ved at brukeren kan gjøre endringer uten å måtte
laste hele siden på nytt. [ 34 ] [ 35 ]
2.2
Programmering
Denne delen tar for seg de forskjellige programspråkene og teknikkene som er benyttet i prosjektet.
2.2.1
Java
Java er et objektorientert programmeringsspråk originalt utgitt av Sun Microsystems i 1995. Det er et språk
hvor alt behandles som objekter, og hvor objektene kan samhandle for å utføre oppgaver. Språket er mest kjent
for sin evne til å fungere på alle plattformer uten å måtte rekompilere koden. Dette prinsippet kalles Write
Once, Run Anywhere(WORA), og det var Java som var først ute med denne løsningen. [ 36 ] Språket er utviklet
med fem hovedmål [ 37 ] :
• Det skal være enkelt, objektsorientert og kjent(ligne på andre språk)
• Det skal være robust og sikkert
• Det skal være plattform uavhengig
• Det skal ha høy ytelse
• Det skal tolkes, genereres tråder og være dynamisk i sanntid
Java brukes i dag til alt ifra til et bredt spekter av formål og til mange forskjellige typer enheter. Dette
innebærer bruk som webtjenere(nettsider etc.), enkeltstående applikasjoner(normale programmer) og innebygde
systemer(vaskemaskiner, kaffemaskiner etc.).
Teknisk
Java applikasjoner, eller programmer kjører på en virtuell maskin som heter Java Virtual Machine(JVM). Dette
vil si at på toppen har man applikasjonen. Denne kjører på en virtuell maskin. Dette vil si at uansett hvilken
fysisk maskin applikasjonen kjører på, vil alltid maskinen se lik ut for applikasjonen. Om det gjøres systemkall
til operativsystemet, oversetter den virtuelle maskinen dette for applikasjonen. [ 38 ]
2.2.2
Regulære uttrykk og Java
Et regulært uttrykk (ofte forkortet "regex") er en streng med karakterer som utgjør et mønster, som igjen
beskriver eller matcher en eller flere strenger. [ 39 ] Et slikt uttrykk brukes for å søke etter grupper av sammenhengende tekst, som da kan behandles på ønsket måte. Med unntak av spesielle karakterer, vil et regulært
uttrykk beskrive en streng karakter for karakter, hvor f.eks det regulære uttrykket "regex" vil matche det første
tilfellet av strengen "regex" i en annen tekststreng. De spesielle karakterene definert i syntaksen oversettes til
en spesiell handling eller kan alene definere flere karakterer i en tekststreng.
Syntaksen i et regulært uttrykk varierer med implementasjonen da programmeringspråk eller programmer som
har støtte for regulære uttrykk benytter seg av forskjellige prosesserings-motorer, eller har sin helt egen variant
Høgskolen i Ålesund
Hovedprosjekt
Side 15
av konseptet. Til tross for dette, er likevel syntaksen svært lik hvis ikke helt identisk i de fleste tilfeller hvor de
regulære uttrykkene baserer seg på Perl. Eksempelvis i Java er det noen slike forskjeller, som siden versjon 4
har støtte for regulære uttrykk vært tilbudt gjennom java.util.regex pakken, og baserer seg på Perl’s implementasjon. Et regulært uttrykk i Perl kan være strengen "\\w", en spesiell karakter, som vil beskrive enhver
streng med én bokstav, bindende punktuasjon eller ett tall.
Tabell 2.1: Sammenligner regex på Java og Perl
Java
Perl
"\\w"
"\w"
Rekkevidde [A-Za-z0-9_] uten Unicode Rekkevidde [A-Za-z0-9_] pluss Unicode
Som figuren ovenfor illustrerer, vil Java’s dobbel-sitering for strenger og bruk av bakvendt skråstrek for
å definere spesialkarakterer gjøre det nødvendig med ekstra tegnsetting for å oppnå et ekvivalent regulært
uttrykk. I tillegg mangler dette spesielle utrykket støtte for Unicode i Java, som også er en viktig forskjell med
stor betydning for resultat.
2.2.3
Java EE / EJB
Enterprise JavaBeans arkitekturen er designet for å lage komponent-baserte applikasjoner, der hver komponent
kan representere en samling prosesser. Applikasjoner utviklet i Enteprise Java Beans arkitekturen er skalerbare
og kan publiseres på alle webapplikasjon-plattformer som støtter Enterprise JavaBeans spesifikasjonen. [ 40 ]
JavaServer Faces
JavaServer Faces (JSF) er en teknologistandard for å bygge grafiske brukergrensesnitt i serversiden, JSF blir
ofte brukt i Java EE webapplikasjoner. En JSP (JavaServer Pages) fil kan inneholde standard HTML kode
og JSF templates eller moduler kalt Facelets. JSF komponentene kan gjengis forskjellig på forskjellige klientenheter. Formålet med JSF er å forenkle bygging av grafiske brukergrensesnitt for webapplikasjons-utviklere og
å separere applikasjonslogikk og presentasjonslaget for modulær og teamvennlig utvikling. JSF gjør det også
lettere for utviklere å kommunisere mellom applikasjonslogikken og presentasjonslaget. [ 41 ]
Primefaces
Primefaces er komponentbibliotek for JavaServer Faces som blir brukt til å lage dynamiske og funksjonsrike
grafiske webgrensesnitt. Primefaces er lett å bruke, lett å implentere, har innebygd AJAX støtte og har åpen
kildekode. [ 42 ]
JAX-RS
JAX-RS er et Java API for RESTful Web-services som har som mål å være enkelt og intuitivt. [ 43 ] API’et ble
formelt anmodet utviklet i 2007, og ferdigstilt neste år i 2008 av JCP (Java Community Process). Målsetningen
som var satt ble oppnådd ved å bruke Java-annotasjoner istedenfor å kreve implementering av Java-interface
klasser eller gjøre det nødvendig med flere konfigurasjonsfiler. Dette betyr at ressursklasser som bruker JAX-RS
er regelrett POJO-klasser, som i seg selv fjerner behovet for flere base-klasser og gir økt modularitet i systemet.
JAX-RS spesifikasjonen forhindrer på ingen måte bruk av grunnleggende java-teknikk som abstraksjon eller arv,
og en JAX-RS støttet klasse kan benyttes på lik linje med ethvert POJO.
Høgskolen i Ålesund
Hovedprosjekt
Side 16
Annotasjonene i JAX-RS benyttes for å binde HTTP-metoder og spesifikke URI’er til individuelle funksjoner
i klassen, eller til og med hele java-klassen. I tillegg til dette har JAX-RS API’et god støtte for marshalling
og unmarshalling av egendefinerte dataobjekter til diverse dataformater, mapping av exceptions til HTTPresponskoder og svar, i tillegg til å kunne håndtere avansert HTTP-forhandling. Nedenfor er et eksempel på
JAX-RS i en Java-klasse, med forskjellige Java-annotasjoner som reflekterer HTTP-metoder (@GET, @POST).
2
@Path ( " / r e s o u r c e " )
public class resourceClass {
.....
4
@GET
@Path ( " / o b j e c t /{ i d } " )
@Produces ( { MediaType . APPLICATION_JSON} )
p u b l i c Response g e t O b j e c t B y I d ( @PathParam ( " i d " ) S t r i n g i d ) {
....
r e t u r n responseObjectBasedOnMethodImplementation ;
}
6
8
10
12
@POST
@Path ( " / o b j e c t / " )
@Consumes ( { MediaType . APPLICATION_JSON} )
p u b l i c Response createNewObjectFromJSON ( InputStream i n p u t S t r e a m ) {
.....
r e t u r n responseObjectBasedOnMethodImplementation ;
}
14
16
18
20
@POST
@Path ( " / o b j e c t /name/{name } : \\w{ 1 , 1 0 } " )
@Produces ( { MediaType . APPLICATION_JSON} )
p u b l i c Response getObjectFrom Name( InputStream i n p u t S t r e a m ) {
.....
r e t u r n responseObjectBasedOnMethodImplementation ;
}
22
24
26
28
30
}
Kodesnutt 2.2: (Eksempel på REST-tjenester med JAX-RS)
Kodesnutten ovenfor viser to metoder som begge er tilgjengelig via en URI som er definert i Java-annotasjonen
@Path ovenfor klassen og metodene. Innenfor @Path-strengen er "id" en variabel som kan benyttes for å hente
ut et spesifikt objekt. Java-annotasjonene @Produces og @Consumes spesifiserer hvilken mediatype (her JSON)
som skal produseres og tolkes respektivt. Java-annotasjonen @Path har også støtte for regulære uttrykk [ 44 ] ,
som muligjør flere typer URI-matching. Den tredje funksjonen i figur (FIGUR HER) demonstrerer dette,
hvor det regulære uttrykket “\\w1,10” vil i Java matche enhver streng med sammenhengende karakterer med
maksimal lengde 10. Dette gjør at man i praksis begrenser name-parameteren til 10 karakterer. Har nameparameteren en lengde på 11 eller mer, vil kun en 404-feil returneres.
Fra endepunktet’s perspektiv (den endelige URI’en)kan også det JAX-RS definerer som matrise-elementer
benyttes, som består av forhåndsdefinerte strenger (@MatrixParam) som etterfølger en @PathParam-streng
med ett semikolon (;). Denne funksjonaliten fører til økt fleksibilitet da man oppnår flere kombinasjoner med
@PathParam og @MatrixParam.
Høgskolen i Ålesund
Hovedprosjekt
2.2.4
Side 17
Bibliotek
Denne delen beskriver relevante tredjeparts støttebibliotek for Java.
JSoup
JSoup er et bibliotek for Java som blir brukt til å håndtere HTML kode fra nettsider i sanntid. Dette gjøres
ved bruk av en relativt enkel API. JSoup henter ned koden fra en nettside, og så kan man navigere gjennom
HTML koden for å hente ut den delen av koden man trenger. [ 45 ] Dette er en enkel metode å web-scrape en
nettside. Ulempen med denne metoden er at man må vite nøyaktig hvordan kildekoden til nettsiden man er
ute etter ser ut. Man kan for eksempel hente ut info som ligger mellom spesifikke HTML notasjoner, eller man
kan hente ut data ved bruk av en spesiell id. En annen funksjon er å strippe vekk alle html notasjoner, slik at
man står igjen med et rent dokument. [ 46 ]
Figur 2.2: Et eksempel på hvordan man kan bruke JSoup
RibbonMenu
Ribbonmenu er et bibliotek for Android som brukes til å presentere data i en meny som kan "skli" inn fra siden
av skjermen. Dette biblioteket etterligner den samme funksjonen som man finner i menyen på applikasjonene
FaceBook og Google+. Fordelen med å bruke denne typen meny er at man har plass til mye informasjon og
store ikoner i menyen, uten å bruke mye plass på skjermen når man ikke bruker den. En annen fordel er at
den følger Google sine retningslinjer om komformitet i applikasjonsdesign. Det finnes et standard bibliotek fra
Google med mye av den samme funksjonen, men denne var ikke tilgjengelig da utviklingen av applikasjonen
startet. [ 47 ] Dette biblioteket heter Navigation Drawer.
Høgskolen i Ålesund
Hovedprosjekt
2.3
Side 18
Programverktøy
Denne delen av rapporten detaljerer de forskjellige programverktøyene som ble benyttet under utviklingen av
prosjektet.
2.3.1
NetBeans
NetBeans er et integrert utviklings miljø(Integrated Development Environment) som brukes til å utvikle datasystemer. Netbeans er i stand til å ta seg av alle trinnene av utviklingen, som sjekk av syntaks, kompilering av
kode og feilsøking av kode. I tillegg finnes det mange moduler som kan legges til som utvider funksjonaliteten.
Netbeans blir hovedsakelig brukt til utvikling av Java, HTML5, PHP og C/C++, men kan brukes til andre
språk også, avhengig av hvilke moduler som er installert. [ 48 ]
2.3.2
GlassFish
Glassfish er en applikasjonsserver for Java Enterprise Edition webapplikasjoner. Glassfish støtter alle Java
Enterprise Edition teknologiene som: JavaServer Faces, JavaServer Pages, Enterprise JavaBeans osv. [ 49 ]
2.3.3
Git
Git er et distribuert versjonskontrollsystem for programvareutvikling. [ 50 ] Git er ideelt til teambasert programmering da det gjør det mye letter å slå sammen filer og endringer gjort av de individuelle teammedlemmene.
Et Git prosjekt består av en mappe der alle endringer blir lagret som revisisjoner (commits). Disse revisjonene
blir organisert med full historikk slik at bidragsyterene i prosjektet kan se hvem som har gjort hvilke endringer
og "rulle tilbake" endringer som ikke er ønskelige. [ 51 ] [ 52 ]
2.3.4
Android
Beskrivelse
Android er et operativsystem hovedsaklig beregnet for mobile og små enheter med berøringsskjerm. Det er
verdens mest brukte operativsystem på mobile enheter, og er stadig i vekst. [ 53 ] Mye av populariteten til
Android kommer av at det er tilgjengelig på et bredt utvalg av maskinvare og i alle prisklasser. [ 54 ] For
produsentene sin del er Android populært da det er hovedsakelig åpen kildekode [ 55 ] og dermed billig å levere
med sine enheter. Mange av produsentene modifiserer også operativsystemet noe for å gjøre det til sitt eget,
men dette er hovedsakelig grafiske forandringer.
Android er populært hos utviklerene da det er et mer åpent operativsystem. Dette gjør at det er lettere å
utvikle applikasjoner, og at de kan bli bedre integrert i den totale brukeropplevelsen ved telefonen. [ 56 ]
Teknisk
Android er basert på en åpen kildekode linux kjerne og er skrevet i C, C++ og Java. Alle applikasjoner som blir
levert til Android er skrevet i Java og og bruker XML. Dette blir kompilert om for bruk i Android sin Dalvik
virtual Machine(som er Android sin version av Java Virtual Machine).
Android applikasjoner er bygd opp av to hovedkomponenter. Disse er såkalte "aktiviteter" [ 57 ] og "tjenester"(service) [ 58 ] . En aktivitet er den delen som vises på skjermen, og kjører kun så lenge den blir vist på
skjermen. En typisk applikasjon består av flere aktiviteter hvor man kan navigere mellom disse. I tillegg kan
hver aktivitet ha flere "fragmenter". Et fragment kan inneholde logikk og et grafisk grensesnitt, men må alltid
Høgskolen i Ålesund
Hovedprosjekt
Side 19
være en del av en aktivitet. Flere fragmenter kan kombineres for å lage en samling med forskjellige brukergrensesnitt i samme skjermbilde. [ 59 ]
En tjeneste er en bakgrunnsprosess som kan kjøre selv om man bytter mellom aktiviteter. Tjenestene blir ofte
brukt til ting som IO og mellomlagring av globale variabler.
Høgskolen i Ålesund
Hovedprosjekt
3
Side 20
MATERIALER OG METODE
I denne seksjonen beskrives alt som ble brukt under utviklingen, og hvilke metoder som ble brukt til å løse
hovedproblemstillingene, og for å styre gruppen.
3.1
3.1.1
Data
Fronter
Fronter er en kompleks læringsplattform for bruk på skoler. Den tilbyr en omfattende grunnpakke som elever og
lærere kan bruke for å kommunisere og samarbeide om skolearbeid. Dette innebærer funksjoner som beskjeder
fra lærere, tilgjengeliggjøring av dokumenter og læringsmateriell, innleveringer og prøver, og chat. Fronter tilbyr
også en rekke utvidelsesmoduler for spesielle behov, som enkel bilderedigering, SMS og plagiatkontroll.
Fronter sin salgsmodell er en såkalt SaaS modell. [ 60 ] Dette vil si at Fronter selger lisenser for bruk av sin
programvare, men at de er vert for sine egne web servere. På denne måten trenger ikke kundene å drifte sine
egne servere. Dette gjør fronter til et godt alternativ både for små og store institusjoner da det eneste som
kreves av kunden er tilgang til en nettleser for sine brukere.
3.1.2
TimeEdit
Timeplan administrasjonssystemet TimeEdit er et system brukt av store institusjoner for å administrere og
allokere lokaler. Tjenesten tillater brukerne å se timeplanen for en person, klasse, studieretning eller lokale for
et ønsket tidsintervall. Høgskolen I Ålesund bruker TimeEdit versjon 1.4.8[ 61 ] hvor alle tjenestens data lagres
og administreres lokalt på skolens servere.
3.1.3
BibSys
Biblioteksystemet BibSys er et arkiveringssystem for bøker og annen media relatert til driften av norske bibliotek.
Systemet tillater brukere å søke etter, låne ut, levere inn og reservere bøker ved alle norske bibliotek tilknyttet
systemet. Systemet er underlagt Kunskapsdepartementet, men blir administrert ved NTNU i Trondheim. [ 62 ]
3.2
Verktøy
Alle gruppemedlemmene brukte Netbeans som IDE til programmeringen av både Android applikasjonen og
Java EE webapplikasjonen. Til utviklingen av Android applikasjonen ble også det offisielle Android SDKet
(Software Development Kit) brukt. For å få støtte til Android prosjekter i NetBeans brukte vi tredjeparts
pluginen NBAndroid[ 63 ] . Glassfish Server Open Source Edition ble brukt som plattform for webapplikasjonen.
Vi ønsket å bruke LaTeX til å skrive prosjektrapporten, men fant ingen prosjektmal fra skolen. Derfor utviklet vi
vår egen mal basert på skolen eksisterende prosjektmaler i andre format. Denne malen ligger offentlig tilgjengelig
på GitHub. [ 64 ]
Høgskolen i Ålesund
Hovedprosjekt
3.3
3.3.1
Side 21
Materialer
Smartelefon - Galaxy Nexus
En av de to enhetene som ble brukt til å teste mobilapplikasjonen under utviklingen var smarttelefonen Galaxy
Nexus, produsert av Samsung[ 65 ] . Denne modellen går også under modellnavnet GT-I9250. Gruppen hadde
3 slike telefoner til rådighet(en for hvert gruppemedlem). Telefonene kjørte under utviklingen Android versjon
4.2.1, kodenavn Jelly Bean.
3.3.2
Tablet - Nexus 7
Dette nettbrettet er et 7 tommers nettbrett produsert av Asus for Google. Det var helt nytt under produksjonsfasen, og tilbød veldig gode spesifikasjoner[ 66 ] til en fornuftig pris. Nettbrettet ble brukt til testing av
applikasjonen for andre skjermstørrelser(sammenlignet med Galaxy Nexus), og for demonstrasjon. Nettbrettet
kjørte Android versjon 4.2.2 under utviklingen.
3.3.3
Server
Prosjektet fikk tildelt en virtuell Ubuntu linux server på skolens VMWare vSphere cluster. På denne ble glassfish
installert og webapplikasjonen publisert.
Figur 3.1: Bilder av serveren
Høgskolen i Ålesund
Hovedprosjekt
3.4
Side 22
Utviklingssyklus
Under prosjektet tok gruppen utgangspunkt i SCRUM rammeverket, men det ble fort etablert en egentilpasset
samarbeidsstil som passet til gruppen. Denne nye stilen innebærte bi-ukentlige statusmøter, daglige statusrapportering blant gruppemedlemmene dog ikke nødvendigvis ved starten av dagen og ikke like formelt som i
SCRUM.
For arbeidet i seg selv ble det brukt to online løsninger som gjorde det mulig å sammarbeide på det samme
prosjektet samtidig. For programmeringen var det kildekode-delingstjenesten GitHub som ble brukt. Med denne
tjenesten kunne alle gruppemedlemmene sitte med hver sin kopi av arbeidet, og når det ble gjort fremskritt ble
dette sendt tilbake til serveren slik at den nye koden blir tilgjengelig for alle.
For prosjektrapporten ble det brukt tekstbehandleren Google Docs. Denne gjør at alle gruppens medlemmer
kan jobbe med det samme dokumentet samtidig, og se hva de andre skriver i sanntid. I tillegg har Google Docs
innebygd chat funksjon og mulighet til å legge igjen kommentarer i teksten. Grunnen til at disse to tjenestene
ble valgt var at alle gruppens medlemmer har god erfaring med dem, og at de tillater en stor grad av sammarbeid
uavhengig om deltakerne fysisk befinner seg på samme sted. I sluttfasen av prosjektrapporten ble teksten fra
Google Docs gjort om til LaTeX format for å kunne bedre kontrollere utseende til den endelige rapporten.
3.5
Framgangsmetode
Denne delen av rapporten omhandler prosjektgruppens framgangsmetode for å løse hovedproblemstillingene.
3.5.1
Fronter
Fronter er et lukket system og derfor måtte vi ha tilgang til APIet for å hente informasjon fra det. Informasjonen
vi ønsket å hente var meldinger fra lærere, dokumenter og innleveringsstatus fra de individuelle rommene i
Fronter-systemet. For å løse dette skulle mobilapplikasjonen gjøre relevante foresprsler mot en REST basert
API på webapplikasjonen. Webapplikasjonen skulle så hente ut relevante data fra Fronter, og returnere det til
mobilapplikasjonen, hvor de blir presentert til brukeren.
3.5.2
TimeEdit
Vi ønsket å implementere en enkel utgave av skolens timeplansystem i e-læringsapplikasjonen. Det skulle være
mulig å se dagens fag på en enkel måte. Planen var å skaffe tilgang til TimeEdit sitt API, og innhente data
derifra via serveren vår ved hjelp av enkle spørringer basert på REST og JSON. Mobilapplikasjonen skulle altså
kunne gjøre et kall mot serveren hvor den ba om informasjon om dagens timer/fag for et studieprogram, og så
skulle serveren gjøre kallet videre til TimeEdit.
3.5.3
BIBSys
Det kom tidlig frem at BiBSys hadde et API som var tilgjengelig til bruk for studenter og andre utviklere. Dette
kunne man se fra antall student-utviklede applikasjoner ved NTNU. Utifra dette ville vi forsøke å få tilgang til
APIen og implementere det i webapplikasjonen. Vi ønsket å implementere boksøk med utlånsstatus. Dette var
en del av prosjektet vi forventet ville gå relativt raskt og uten problemer.
Høgskolen i Ålesund
Hovedprosjekt
3.5.4
Side 23
Videreutvikling av applikasjonene
I den forrige versjonen av systemet var strukturen hardkodet inn i mobilapplikasjonen. Vi ønsket å gjøre
systemet mer fleksibelt slik at det kunne tilpasses de individuelle fagene og studienes behov for data. Vi ville
at strukturen på mobilapplikasjonen skulle defineres for hvert objekt i webapplikasjonen.
3.5.5
Arbeidsprosessen
Arbeidet i prosjektet skulle i utgangspunktet (ved prosjektstart) være styrt av aktivitetsplanen samt prosedyrer
for avvik som ble definert i forprosjektsrapporten[ 67 ] . Diagrammet som følger beskriver den faktiske tidsfordelingen mellom de forskjellige delprosjektene.
Figur 3.2: Dette Gantt diagrammet viser når de forskjellige deloppgavene i prosjektet ble utført
Ved prosjektstart under den initielle planleggingsfasen (ref. Forprosjektsrapport[ 68 ] ) ble det klart at å først
utvikle en stabil versjon av systemet var nødvendig, og dermed ble arbeid med både web-applikasjon og mobilapplikasjon prioritert først. Under videreutviklingen av systemet ble også ett sett med nye funksjoner inkludert,
b.la et fragmentsystem (beskrevet i senere i rapporten) felles for mobil og web-applikasjon, samt nytt design
for web-applikasjonens nettleser-grensesnitt. Det meste av arbeidet gjort her går likevel under stabilisering av
applikasjonene ved å rette bugs og utbedre logisk flyt i systemet.
Parallelt med dette startet vi også å undersøke tilgangsforholdene rundt de forskjellige tjenestene (TimeEdit,
BibSys, Fronter) som vi skulle integrere i applikasjonen. Korrespondanse med leverandørene og eierene av datasystemene for å få tilgang til systemenes API tok lengre tid enn forventet, og det ble relativt tidlig (ca. uke 3)
klart at vi måtte gå vekk fra den originale tidsplanen.
Målsetningen med å ha utført prosessene A1-B2 går likevel i orden da innsamling av data så langt det var
mulig og planlegging av arbeid videre ble gjort innenfor satt tidsfrist. TimeEdit blir prioritert under denne
fasen da vi kunne starte forarbeidet umiddelbart med å forsøke alternative løsninger for innhenting av data,
noe som også var innenfor det vi hadde forventet (ref. avvik forprosjektsraport). Milepæl #1 nås imidlertid
ikke da undersøkings-delen (pkt.2 i figur 3.2) tok lengre tid enn forventet, og fra dette punktet av omorganiseres
prosjektets framdriftsplan helt.
Den nye prosjektorganiseringen var vellykket da det var tid som var den begrensende ressursen, og ikke arbeidskraft.
Høgskolen i Ålesund
Hovedprosjekt
4
Side 24
RESULTATER
I denne seksjonen presenterer vi resultatet av prosjektet. Seksjonen er delt i tre deler, webapplikasjonsdelen
hvor forandringene på serversiden blir presentert, mobilapplikasjonsdelen hvor forandringene i mobilapplikasjonen blir beskrevet og systemintegrasjonsdelen der vi presenterer løsningene til de integrerte systemene.
Diagrammet under viser den overordnede strukturen til hele systemet som ble utviklet. Som man kan se
er det et stort system med mange deler. Hver del er i seg selv bygd opp av mange komponenter som vil bli
beskrevet i mer detalj senere i seksjonen. Det er verdt å merke seg at kildekoden til prosjektet består av over
45 000 linjer med kode, så den følgende beskrivelsen vil hovedsakelig omhandle hvordan systemet gjennomfører
oppgavene sine, og ikke nøyaktig hvordan koden fungerer.
Figur 4.1: Oversikt over hele systemet
Høgskolen i Ålesund
Hovedprosjekt
4.1
Side 25
Mobilapplikasjonen
(a) På en mobiltelefon
(b) På ett nettbrett
Figur 4.2: Skjermbilder av mobilapplikasjonen - fremsiden
Mobilapplikasjonene er laget for Android operativsystemet og bruker Android SDK versjon 14. Med unntak
av slidingmeny funksjonen brukt i TimeEdit implementasjonen er all teknologien i applikasjonen inkludert i
Android SDKet eller utviklet av prosjektmedlemmene. Med unntak av logoene til høgskolen, fronter og bibsys
er ikonene til fragmentene hentet fra en åpen ikonpakke på nettet. Resten av grafikken er standard i Android
SDKet.
Endringer i mobilapplikasjonen fra forrige versjon (høsten 2012):
• Ikke lenger statiske fragmenter / data. I den forrige versjonen var alle fragmentene tilstede på alle sidene,
selv om de ikke hadde innhold. Dette gjorde at alle lagen i applikasjonen så helt like ut og forvirret
brukere.
• Full omskriving av metodene for innlasting av data. Bruker nå kun et GET (se begreper) kall for å laste
ned et studie/fag/etc. I forrige versjon var det en GET kall for hvert fragment/side. Dette gjorde at
datainnlastingen tok lengre tid.
• Full omskriving av JSON parsingen. I den tidligere versjonen var parsingen av objektene gjort i samme
klasse som datainnlastingen. Nå har hver av dataklassene en konstruktør for JSON data og håndterer
derfor parsingen selv. Dette har gjort det lettere å feilsøke parsingen og å legge til nye dataklasser.
Høgskolen i Ålesund
Hovedprosjekt
Side 26
• Stabilitet. Bedre feilhåndtering og forenklet logikk har bidratt til å gjøre mobilapplikasjonen mye mer
stabil.
• Integrasjon av de eksterne tjenestene TimeEdit og BibSys. Mer om dette senere i rapporten.
Figur 4.3: Viser objektene på hvert lag i mobilapplikasjonen og flyten mellom lagene
Mobilapplikasjonen er delt inn i tre lag. Lag 1 er fremsiden av applikasjonen og det første brukeren ser
når applikasjonen startes. Her vises fragmentene som er knyttet til fremside objektet på webapplikasjonen som
ikoner. På dette laget er det meningen å ha informasjon relatert til skolen i seg selv, for eksempel en spørreundersøkelses quiz eller nyheter om skolen. Når brukerene trykker på et av ikonene åpnes dette fragmentet og
viser dets innhold. Får å komme tilbake til fragmentoversikten kan brukeren trykk på back knappen i android
eller bruke rullegardin-menyen øverst i skjermbildet. Systemet kan bare ha en fremside.
Når brukeren velger et studie fra studieliste-fragmentet går applikasjonen ned til neste lag. Lag 2 er studielaget,
som på fremsiden vises fragmentene som er knyttet til studie i webapplikasjonen.
Når brukeren velger et fag fra fagliste-fragmentet går applikasjonen videre til det siste laget. Lag 3 er faglaget,
som de andre lagene inneholder dette laget fragmenter definert av webapplikasjonen. Fag-laget inneholder i
tillegg ekstra datafelt for eksamener, innleveringer og tema med oppgaver.
Høgskolen i Ålesund
Hovedprosjekt
Side 27
Grunnen til at denne strukturen ble valgt er at den ble spesifisert av kunden da systemet ble bestilt i 2012.
Kravspesifikasjonen hvor strukturen ble beskrevet ble fremlagt og produsert av Harald Yndestad. Denne
kravspesifikasjonen spesifiserte systemet som ble utviklet opp til starten av dette prosjektet.
4.1.1
Sammenligning med det gamle systemet
Figur 4.4: Viser flyten i det gamle systemet
I det gamle systemet hadde alle objektene på alle lagene de samme sidene. På fremsiden måtte ressurslinkene
til informasjonen på serveren hardkodes inn i mobilapplikasjonen og kompileres hver gang det skulle gjøres en
endring. Dette gjorde det gamle systemet veldig tungvint å vedlikeholde og gjorde systemet veldig sårbart mot
systemkrasj om ressurser på serveren ble slettet. På lagene under (studier og fag) var informasjonen lagret som
attributter i lag-objektet. Det vil si at hvert lag måtte ha en og bare en av hvert type dataobjekt (artikkel,
Høgskolen i Ålesund
Hovedprosjekt
Side 28
videoer osv). Om lag-objektet manglet en ressurslink for et objekt eller linken til ressursen var ugyldig krasjet
applikasjonen.
4.1.2
Git statistikk
Statistikk for endringer i mobilapplikasjonens github repository siden prosjektstart:
• Antall commits: 60
• Antall linjer lagt til: 5513
• Antall linjer slettet: 7474
• Totalt antall linjer alle filer: 15308
• Totalt antall linjer - Java kode: 8625
• Totalt antall linjer - XML: 2146
4.1.3
Installasjonsinstrukser
For å installere mobilapplikasjonen på mobiltelefonen eller nettbrettet ditt trenger du minst versjon 4.0 (Ice
Cream Sandwich) av Android operativsystemet. Siden applikasjonen ikke er tilgjengelig på Google Play butikken
må den installeres manuelt, for å gjøre dette må du først tillate installering av eksterne applikasjoner gå inn
på innstillinger -> sikkerhet og skru på “ukjente kilder”. Etter det er det bare å åpne den kompilerte .apk
filen i prosjektmappen (Muldvarp/bin/Muldvarp-Debug.apk). Denne filen er også linket til på fremsiden av
webapplikasjonen.
Høgskolen i Ålesund
Hovedprosjekt
4.1.4
Side 29
Forklaring av brukergrensesnittet
Figur 4.5: Forklaring for brukergrensesnittet
1. Knapp for å få fram sidemenyen. Sidemenyen inneholder timeplan funksjonen.
2. Tittelen på fragmentetsiden du er på nå. Trykk her for å få opp en rullegardin-meny der du kan navigere
til de andre fragmentene i laget.
3. Søkeknapp. Trykk her når du er i en liste for å filtrere listen med søkeordet ditt.
4. Oppdateringsknapp / “Refresh”. Oppdaterer og laster ned informasjonen om siden du er på nå på nytt.
5. Diverse. Her finner du innloggingsknappen (ikke ferdig implementert) og en “om oss” knapp som popper
opp et vindu med diverse informasjon om høgskolen som for eksempel postaddresse.
6. Tittelen på laget du befinner deg på. I dette tilfellet fremsiden. Når du er på studie eller fag nivået vises
navnet til studiet / faget.
7. Fragmentene på laget. Trykk på ett fragment for å navigere til den siden.
8. Informasjon om applikasjonsversjonen og når dataen for laget du befinner deg på sist ble lastet inn.
9. Tilbake-knapp. Standard i Android operativsystemet. Trykk her når du er på fragmentoversikten for
å bevege deg opp et lag, trykk på knappen når du befinner deg i en fragmentside for å gå tilbake til
fragmentoversikten.
10. Hjem-knapp. Standard i Android operativsystemet. Trykk her for å ut av applikasjonen. Applikasjonen
lukkes ikke men legges i bakgrunnen.
11. Applikasjonsvelger-knapp. Standard i Android operativsystemet. Trykk her for å velge applikasjoner som
kjører i bakgrunnen.
Høgskolen i Ålesund
Hovedprosjekt
4.1.5
Side 30
Serviceprossesen
Serviceprossesen er en egen prosses som kjører parallelt med applikasjonens hovedprosses. Den har ansvar for
å hente data fra serveren, parse dataen og lagre dataobjektene i minne
4.1.6
Datainnlasting
Mobilapplikasjonen laster inn data fra webapplikasjonen via REST tjenestene på serveren. Tjenestene leverer
dataen i JSON format som blir parset og lagret i minnet av serviceprosessen.
Figur 4.6: Viser flyten mellom webapplikasjonen og mobilapplikasjonen
Først lager hovedprosessen en tilkobling til serviceprosessen og sender en førespørsel om dataen den trenger.
Så laster serviceprosessen ned og parser dataene hovedprosessen forespurte. Når informasjon er ferdig parset av
serviceprosessen, sender den en melding til hovedprosessen om at informasjon er klar til bruk. Deretter henter
hovedprosessen informasjonen fra serviceprosessen og gjør den tilgjengelig for bruk av fragmentene.
For eksempel så vil første innlasting av data til mobilapplikasjonen bestå av kall til “frontpage” for å få fragmentene til fremsiden, “programme” for å hente en liste av alle studiene, “articles/news” for å få nyhetene og
“timeedit/<klasseid>” for å hente brukerens timeplan. Senere vil mobilapplikasjonen sende førespørsler etter
mer data etter behov. Se seksjonen om webapplikasjonen i resultatdelen for nærmere oversikt over de forskjellige
tjeneste-kallene
4.1.7
Fragmenter/Moduler
Mobilapplikasjonen er bygd opp av flere lag der hvert lag har flere fragmenter (se begreper) eller sider med
forskjellig informasjon. Disse fragmentene styres av laget (aktiviteten, se begreper) som henter frem og viser
fragmenter etter behov. Hvilke fragmenter som er på hvilket lag og objekt er definert av webapplikasjonen. Her
er en oversikt over de forskjellige typene fragmenter.
Lister
Store deler av applikasjonens sider består av lister over andre objekter. Disse listene kan inneholde alle de
forskjellige dataobjekt typene. I disse listene kan brukerene filtrere listen med et søkeord med forstørrelsesglass
knappen i toppmenyen
Høgskolen i Ålesund
Hovedprosjekt
Side 31
Artikkel / Nyheter
(a) Liste med nyheter
(b) En artikkel
Figur 4.7: Skjermbilder av mobilapplikasjonen - artikkel-funksjonen
Artikkel fragmentet viser en HTML side fra webapplikasjonen i et standard WebView i Android. Nyhetsfragmentet viser en liste med artikler fra valgt kategori, når du velger en får du samme visning som artikkel
fragmentet.
Høgskolen i Ålesund
Hovedprosjekt
Side 32
Studier / Fag
(a) En liste med studier filtrert med søkeordet
"data"
(b) Startsiden til studie-laget
Figur 4.8: Skjermbilder av mobilapplikasjonen - studie/fag-funksjonen
Viser en liste over alle studier / fag i valgte studie. Når du velger et studie eller fag går du “ned et lag” til det
valgte studie / faget. Her vises studielisten filtrert med søkeordet “data” og fremsiden til det valgte objektet i
studielaget.
Høgskolen i Ålesund
Hovedprosjekt
Side 33
Dokumenter
(a) Detaljesiden til et dokument
(b) Et dokument
Figur 4.9: Skjermbilder av mobilapplikasjonen - dokument-funksjonen
Inneholder en liste over alle dokumentene knyttet til fragmentet. Når klikker på et dokument i listen får du
opp en oversiktsside med informasjon om det valgte dokumentet. Trykk på “Open” for å åpne dokumentet i
mobilen/nettbrettets standard dokumentvisnings-applikasjon. Trykk “Download” for å laste ned filen til mobilen/nettbrettes standard nettlastingsmappe
Høgskolen i Ålesund
Hovedprosjekt
Side 34
Video
(a) Videoliste
(b) Åpnet YouTube-video
Figur 4.10: Skjermbilder av mobilapplikasjonen - video-funksjonen
Video fragmentet inneholder en liste av alle videoer knyttet til fragmentet. Når du velger en video åpner
videoprogrammet på mobilen, i dette tilfellet YouTube
Høgskolen i Ålesund
Hovedprosjekt
Side 35
Quiz
Quiz-seksjonen av mobil-applikasjonen tilbyr quizzer eller andre type spørringer til brukerene. Av de forskjellige typene er kun de som ikke kommuniserer svar tilbake til server implementert grunnet mangel av sentralt
brukersystem. Quiz-fragmentet som tilgjengelig fra hovedsiden inneholder en liste over quizzer som er knyttet
til hovedsiden’s lagtype - fag, kurs eller genere
(a) Startsiden til en quiz
(b) Et dokument
Figur 4.11: Skjermbilder av mobilapplikasjonen - quiz-funksjonen
Etter å ha valgt en quiz får du opp startskjermen med informasjon om quizzen. Her står det en kort
beskrivelse av innholdet, og antall spørsmål quizzen inneholder. Quizzen startes herfra ved å trykke på “Start
Quiz!”. Oppgavene eller spørsmålene kan være flervalgs eller enkeltvalgs-typer, og advarsler vil komme opp
dersom ingen alternativ er valgt. Navigasjon mellom alle spørsmålene er også mulig, og ved siste vil man å en
advarsel om at er i ferd med å avslutte Quizzen og gå til resultatskjermen. Man er også i stand til å avslutte
Quizzen når som helst, og dette vil forkaste alle svar.
Høgskolen i Ålesund
Hovedprosjekt
(a) Viser dine svar
Side 36
(b) Viser korrekte svar
(c) Oppsummering
Figur 4.12: Skjermbilder av mobilapplikasjonen - quiz-funksjonen
Etter man har svart på alle spørsmålene kommer man til en oppsummeringsside. Her vises ett sammendrag
av alle spørsmålene og hvilke alternativer som ble valgt. Ved å trykke på “se fasit” knappen nederst på siden
får man opp de riktige alternativene, som viser hvilke svar du har valgt og om de er riktige eller gale. Kjent
fargekoding forklarer visuelt gale/riktige svar. Videre kan man trykke oppsummeringsknappen for å se en
opptelling riktige svar mot hvor mange som var mulig å få riktig, og eventuelt en vurdering
Høgskolen i Ålesund
Hovedprosjekt
4.2
Side 37
Webapplikasjonen
Figur 4.13: Oversikt over webapplikasjonen
Webapplikasjonen er laget på Java Enterprise Edition 6 plattformen. Arkitekturen er basert på Model View
Controller-modellen, men avviker noe fra modellen (mer om dette senere i rapporten). Webapplikasjonen har
en nettsidefrontend for administrasjon og et sett med REST tjenester for å gjøre dataen lett tilgjengelig for eksterne applikasjoner som mobilapplikasjonen. I dette prosjektet publiserte vi webapplikasjonen på en GlassFish
Open Source Edition server, men den kan også publiseres på andre webapplikasjonsservere som støtter Java
Enterprise Edition 6 webapplikasjoner.
Teknologier brukt i webapplikasjonen:
• Java Enterprise Beans - Plattformen webapplikasjonen er utviklet på.
• JavaServer Faces - Brukt til frontenden/nettsiden.
• PrimeFaces - Komponentbibliotek til JavaServer Faces. Brukt til redigeringssidene og navigasjonssystemet
i frontenden.
• JSoup - Brukt til parsing av HTML og XML i TimeEdit og BibSys implementasjon
• REST - Brukt til å eksponere data (API) til mobilapplikasjonen
• JSON - Brukt som dataformat i REST tjenestene
For mer informasjon om teknologiene, se teoretisk grunnlag.
Høgskolen i Ålesund
Hovedprosjekt
Side 38
Endringer i webapplikasjonen siden forrige versjon (høsten 2012)
• Dynamisk fragment system. Nå defineres fragmentene på mobilapplikasjonssiden i webapplikasjonen.
Dette står for den største delen av oppgraderingen i den nye versjonen.
• Stabilitet og feilfiksing. Den forrige versjonen var full av krasjbugs og feil i relasjonsdatabasen. Mye arbeid
ble gjort for å finne og fikse feilene. For mer informasjon om relasjonsdatabasefeilene se seksjonen om
drøfting.
• Grafisk oppussing. Laget ny template og css stil. Samkjørt grafikken med mobilapplikasjonen. Laget ny
fremside, med presentasjon av applikasjonens funksjoner og nedlastingslink til mobilapplikasjonen.
• Skrevet om redigeringssidene. Redigeringssidene for lagobjektene er helt skrevet om for å bruke det nye
fragmentsystemet. Laget dokumentasjonsider.
4.2.1
Git statistikk
Statistikk for endringer i webapplikasjonens github repository siden prosjektstart:
• Antall commits: 101
• Antall linjer lagt til: 15504
• Antall linjer slettet: 9963
• Totalt antall linjer 30336
• Totalt antall linjer Java-kode: 8167
• Totalt antall linjer xhtml / jsf: 7090
4.2.2
Installasjonsinstrukser
Webapplikasjonen kompileres til en .war fil. Denne filen kan publiseres på flere typer webapplikasjonsservere.
I vårt prosjekt brukte vi GlassFish Open Source Edition som vår webapplikasjonsplattform, derfor er disse
instruksjonene kun for GlassFish.
Sette opp databasen:
1. Trykk på “Resources” i venstremenyen
2. Trykk på “JDBC Connection Pools”
3. Trykk “New”
4. I feltet “Pool Name” skriv “MuldvarpPool”
5. Under “Resource Type” velg “javax.sql.DataSource”
6. Under “Database Driver Vendor” velg “JavaDB”
7. Trykk “Next”
8. Under “Additional Properties” i bunnen av siden fyll inn feltene som vist på bildet
Høgskolen i Ålesund
Hovedprosjekt
Side 39
9. Trykk “Finish
Figur 4.14: JDBC innstillinger
10. Gå til “JDBC Resources” i venstremenyen
11. Trykk “New”
12. I feltet “JNDI Name” skriv “jdbc/muldvarp”
13. Under “Pool Name” velg “MuldvarpPool”
14. Trykk “OK”
Sette opp administratorbruker
Webapplikasjonen bruker også “security-constraint” funksjonen i Java EE for å begrense tilgang til sidene i /admin/ mappen.
For å konfigurere administratorbrukeren:
1. Trykk på “server-config” under “Configurations” i venstremenyen
2. Under “Security” velg “Realms” og så “file”
3. Skriv inn “Admin” i feltet “Assign Groups”
4. Trykk “Save”
5. Trykk på “Manage Users”
6. Trykk “New” for å legge til en ny bruker
Figur 4.15: Viser hvor
file realm er
Høgskolen i Ålesund
Hovedprosjekt
Side 40
7. Skriv “Admin” i feltene “User ID” og “Group List”
8. Skriv inn valgfritt passord
9. Trykk “Save”
Publiser applikasjonen
1. Gå til “Applications” i venstremenyen
2. Trykk “Deploy”
3. Under “Packaged File to Be Uploaded to the Server” trykk “velg fil” og velg .war
filen (MuldvarpWeb/target/MuldvarpWeb-1.1-TEST.war)
4. Under “Context Root” skriv “hials” (Dette blir adressen til webapplikasjonen)
5. Om applikasjonen allerede er publisert kryss av på “Force Redeploy” for å overskrive den
6. Trykk “OK”
Applikasjonen er nå klar til bruk og kan nås med adressen “http://domene.no/hials”. Om glassfish ikke
kjører på port 80 må du legge til portnummeret i adressen (eg. http://domene.no:8080/hials).
Sett webapplikasjonen til standardapplikasjon
For at webapplikasjonen skal visest i rot-adressen (eg. eapp.uials.no) må du gjøre følgende steg for å sette
webapplikasjonen som standardapplikasjon
1. Trykk på “server-config” under “Configurations” i venstremenyen
2. Trykk på “Virtual Servers”
3. Trykk på “server”
4. Under “Default Web Module” velg “MuldvarpWeb-1.1-TEST”
5. Trykk “Save”
Nå er webapplikasjonen tilgjengelig på rot-adressen til serveren.
4.2.3
Administrasjonsgrensesnitt
Administrasjonsgrensesnittet er utviklet i JavaServer Faces og bruker spesielt funksjoner og komponenter fra
Primefaces biblioteket. Grensesnittet er delt inn i flere faner, en fane for hvert type objekt i systemet
Høgskolen i Ålesund
Hovedprosjekt
Side 41
Fremside
Figur 4.16: Skjermbilde av webapplikasjonen - Viser framside-redigeringssiden
Her kan tittelen og hvilke fragmenter som skal vises på fremsiden av mobilapplikasjonen styres. Her får også
administratoren en forhåndsvisning av hvordan dette vil se ut på mobilapplikasjonen.
Høgskolen i Ålesund
Hovedprosjekt
Side 42
Studier
Figur 4.17: Skjermbilde av webapplikasjonen - Viser listen over studier
Her vises en liste over alle studier i systemet. Her kan nye studier opprettes og eksisterende studier redigeres.
Figur 4.18: Skjermbilde av webapplikasjonen - Studie-redigeringssiden
Redigeringssiden for studier. Her kan studiets navn og brødtekst defineres. Resten av siden er delt inn i tre
seksjoner
Høgskolen i Ålesund
Hovedprosjekt
Figur 4.19: Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Studiebeskrivelse
I studie beskrivelsesseksjonen kan mer detaljert tekst om studiet skrives inn.
Figur 4.20: Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Valg av fag
Her velger administratoren hvilke fag som er i studiet.
Side 43
Høgskolen i Ålesund
Hovedprosjekt
Side 44
Figur 4.21: Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Fragmenter
Her velges fragmentene som skal visest for det valgte studiet i mobilapplikasjonen.
Fag
Figur 4.22: Skjermbilde av webapplikasjonen - Fag-redigeringssiden
Redigeringssiden for fag. Her defineres fagets navn, brødtekst og bilde. Her visest også hvilke studier faget
tilhører. Resten av siden er delt inn i underkategorier der fagets tema og oppgaver, obligatoriske innleveringer,
Høgskolen i Ålesund
Hovedprosjekt
Side 45
eksamener og hvilke fragmenter som skal vises på mobilapplikasjonen defineres.
Dokumenter
Som i de andre fanene vises først alle dokumentene i systemet i en liste.
Figur 4.23: Skjermbilde av webapplikasjonen - Dokument-redigeringssiden
Redigeringssiden for dokumenter. Her legges inn navnet til dokumentet, URL eller lenke til dokumentet
(i denne versjonen av systemet er ikke filopplasting / lagring støttet, derfor må filene lastes opp til en annen
server/tjeneste og linkes til) og en liten tekstbeskrivelse av dokumentet.
Høgskolen i Ålesund
Hovedprosjekt
Side 46
Quizzer
Som vanlig vises først en liste over alle quizzen i systemet.
Figur 4.24: Skjermbilde av webapplikasjonen - Quiz-redigeringssiden
Redigeringssiden til en quiz. Her defineres quizzens tittel, type, en kort beskrivelse og spørsmålene med
alternativer. Typene quiz er feedback, remote, remote med feedback og guide. Meningen med disse forskjellig
typene er som følge
Tabell 4.1: Viser de forskjellige quiz typene
Quiztype
Feedback
Remote
Remote med feedback
Guide
Mening
Brukeren får vite resultatet på quizzen
Brukeren får ikke vite resultatet på quizzen, men det
blir sendt til læreren/forelesere
Brukeren får vite resultatet på quizzen, og resultatet
blir sendt til læreren/forelesere
Her avhenger hvert spørsmål av det forrige. På denne
måten kan man dirigere brukeren mot for eksempel
riktig studieretning etc
Av disse typene er det kun feedback som er ferdig implementert grunnet tidshensyn. De andre typene ligger
der da de er delvis implementert og kan gjøres ferdig i fremtide
Høgskolen i Ålesund
Hovedprosjekt
Side 47
Figur 4.25: Skjermbilde av webapplikasjonen - Quiz-redigeringssiden - Spørsmål
Redigeringssiden til et valgt spørsmål. Her kan administratoren legge til alternativer og velge hvilke som er
riktig svar.
Videoer
Først vises en liste over alle videoene i systemet.
Figur 4.26: Skjermbilde av webapplikasjonen - Video-redigeringssiden
Høgskolen i Ålesund
Hovedprosjekt
Side 48
Redigeringssiden for videoer. Her legges inn / redigeres navnet til videoen, typen (youtube eller videofil),
URL / link til videoen, brødtekst, beskrivelse, URL til bildefil for videoens ikon i mobilapplikasjonens listevisning
og et thumbnail bilde
Artikler
Som vanlig vises en liste over alle artiklene i systemet.
Figur 4.27: Skjermbilde av webapplikasjonen - Artikkel-redigeringssiden
Redigeringssiden for artikler. Her legges inn / redigeres artikkelens tittel, forfatter, kategori (brukt til å
sortere artikler for nyhetsfunksjonen), dato, beskrivelse, ingresstekst og selve artikkelen. Artikkelens tekst bruker
en WYSIWYG editor og lagrer artikkelen i HTML format. Administratoren kan også legge inn egendefinerte
HTML kode. Stien til artikkel siden er: “server.no/faces/article.xhtml?articleid=<ID>” der <ID> er artikkelens
interne I
Høgskolen i Ålesund
Hovedprosjekt
Side 49
Brukere
Viser en liste over brukerene i systemet.
Figur 4.28: Skjermbilde av webapplikasjonen - Bruker-redigeringssiden
Redigeringssiden for brukere. Her fylles inn diverse informasjon om brukeren. I denne versjonen av applikasjonen har brukersystemet ingen funksjon. Brukerfunksjonen var planlagt som både et brukersystem med
rettigheter og eierskap av objekter i systemet, og som et oppslagsverk for lærere / ansatte i skolen for skolens
eleve
Høgskolen i Ålesund
Hovedprosjekt
Side 50
Dokumentasjon
Figur 4.29: Skjermbilde av webapplikasjonen - Dokumentasjon
Hjelpeside for webapplikasjonen. Her finnes instruksjoner for bruk av de forskjellige delene av administrasjonsgrensesnittet.
4.2.4
Modulært fragmentsystem
I tidligere versjoner av mobilapplikasjonen var fragmentene (se begreper) eller sidene på hvert lag statisk programmert inn i mobilapplikasjonen. I dette systemet hadde alle objektene på et lag (fremside, studieretninger,
fag) de samme sidene, en av hvert type fragment. Det var ikke alle tilfellene dette passet med objektets tilgjengelige informasjon, og derfor ble det besluttet at sidene på hvert objekt skulle bli styrt av webapplikasjonen.
Med det nye systemet kan administratorene definere nøyaktig hva som skal vises på mobilapplikasjonen. Dette
systemet var også laget for å kunne lett utvides med nye moduler. Se kapittelet om mobilapplikasjonen for
oversikt over de forskjellige fragmentene
Høgskolen i Ålesund
Hovedprosjekt
4.2.5
Side 51
ER modell
Figur 4.30: Entity Relationship diagram
ER modellen er bygd opp med det logiske lagene på topp (fremside, studier, fag) der hver av disse inneholder
dynamiske fragmenter, som igjen inneholder data objektene (artikler, dokumenter, videoer osv). Topplagene er
knyttet til fragmenter via “one to many” relasjon som betyr at for eksempel et studie har flere unike fragmenter.
Fragmentene er knyttet til data objektene med “many to many” relasjon. Dette vil si at for eksempel flere
fragmenter kan være knyttet til de samme videoene og omvendt.
I det gamle systemet hadde hvert av lagene (fremside, studie, fag) relasjoner direkte til dataobjektene. Det
vil si at hvert lag hadde en instans av hvert fragment. Med det nye fragmentsystemet kan hvert lag ha flere
instanser av samme type fragment.
4.2.6
REST tjenester
For at eksterne applikasjoner som mobilapplikasjonen skal kunne bruke dataen i systemet har vi et sett med
“RESTful” tjenester. Disse leverer begrenset informasjon basert på hva klientapplikasjonen spør om. Her er en
oversikt over hvilke tjenester som er i bruk av denne versjonen av applikasjonen.
Høgskolen i Ålesund
Hovedprosjekt
Side 52
Tabell 4.2: Viser de tilgjengelige REST tjenestene
URL/Forespørsel
(domene.no/services/ +
frontpage
programme
programme/<ID>
articles/news
course/<ID>
article/<ID>
timeedit/coursecode/<kode>
timeedit/classcode/<kode>
bibsys/<Søkeord>
fronter/room/<ID>
4.3
4.3.1
Data / respons
Henter fremsiden
Henter alle studier
Henter studiet med valgt ID
Henter artikler med kategori “news”
Henter kurset med valgt ID
Henter artikkel med valgt ID
Henter timeplanen for valgt fagkode (eks ID102012)
Henter timeplanen til valgte klasse (eks DA1)
Finner alle bøker som matcher søkeordet
Hente data fra fronter rom med ID (siden fronter
implementasjonen ikke ble fullført returnerer dette
bare dummy data)
Systemintegrasjon
TimeEdit
Den første oppgaven ved integreringen av TimeEdit var å bestemme hvilke av tjenestene som TimeEdit tilbyr
var nyttig for applikasjonen’s bruksområde. TimeEdit som implementert av HIALS tilbyr bla.
• Booking av rom. [ 69 ]
Krever HIALS brukernavn/passord
• Timeplan over planlagte forelesninger
. . . .basert på :
[ 70 ]
– Studieløp
– Enkeltfag
– Forelesere
– Rom
Hovedfokuset i applikasjonen er sentrert rundt studier og enkelt-fag, og dermed er den mest relevante tjenesten oppslag på nettopp dette. TimeEdit kan supplere den eksisterende funksjonaliteten i mobil-applikasjonen
ved å tilby dypere innsikt i og bredere oversikt over studier og enkeltfag. Mer konkret skal en bruker av mobilapplikasjonen være i stand til å slå opp et fag eller studie, og så ha muligheten til å få servert en ferdig formatert
og relatert time-plan. Det å kunne enkelt reservere rom fra applikasjonen er forsåvidt også noe som har klar
nytteverdi, men er ikke like godt knyttet opp mot applikasjonen’s hovedfokus. Dermed ble booking av rom ikke
tatt med i funksjonsimplementeringen.
Høgskolen i Ålesund
Hovedprosjekt
Side 53
Utvikling
Når hvilke tjenester fra TimeEdit som skulle implementeres i applikasjonen ble fastslått, gjensto det å bestemme
metoden for å oppnå integreringen. Denne delen beskriver hvilke valg-alternativ vi kom fram til at vi hadde,
sammenligning og den endelige vurderingen.
TimeEdit er som tidligere beskrevet en tjeneste utviklet av selskapet Evolvera som tilbys brukeren gjennom
en nettleser. Basert på kun denne kunnskapen kunne vi ramse opp tre metoder for å implementere skolens
timeplanløsning i applikasjonen. Disse tre (med begrunnelse) er:
1. Bruk av eksisterende API tilknyttet TimeEdit
For en slik data-sentrert tjeneste er det sannsynlig at en API-løsning er utviklet, da dette er vanlig for
moderne geskjefter. [ 71 ]
2. Web-scraping av HIALS TimeEdit’s nettside
Som beskrevet i delen om Web-Scraping under Teoretisk Grunnlag, er det mulig å parse en nettside for
relevant data og rekonstruere den i et mer anvendbart format.
3. Vise TimeEdit’s nettside direkte gjennom Android’s eksisterende funksjoner
Dette er et klart valg-alternativ som er gjennomførbart.
En oppsummeringsliste med ulemper/fordeler ved disse valgmulighetene er tilgjengelig lengre nede i denne
seksjonen, i tillegg til hvilken som ble valgt.
Av disse tre alternativene er direktevisning av TimeEdit’s nettside enklest å implementere, da dette kun innebærer å lage en container i applikasjonen(ved bruk av Android WebView) som peker til siden. Ulempen med
denne metoden er at nettsiden til TimeEdit ikke er designet for visning på små skjermer. Dette innebærer at
det må mye navigering (zooming, scrolling, leting) til for å komme fram til riktig data, noe som er lite ønskelig
fra et brukerperspektiv.
Gruppen benyttet Galaxy Nexus-enhetene til å besøke og navigere HIALS TimeEdit’s nettside, med dårlig
brukeropplevelse som forventet. Dataene var presentert uoversiktlig og de små skjermene gjorde det vanskelig
å utbedre dette. Dermed ble det tidlig klart at å vise TimeEdit’s nettside direkte var langt i fra et ønskelig
alternativ, selv om tilnærmings-metoder som det å bruke en WebView til å ha en egen-definert CSS-fil for å
endre layout ble inkludert i vurderingen.
Trolig kunne vi ha fått til bedre visning på små skjermer, men dataene ville likevel vært utilgjengelig for oss
dersom vi ikke benyttet oss av web-scraping-teknikker for å strukturerere de.
Den foretrukne metoden er å bruke TimeEdit’s eget API. Ved bruk av et API vil applikasjonen være tildels
beskyttet mot små forandringer i koden til TimeEdit, og dataene ville kunne bli presentert i applikasjonen med
det samme gjennomgående utseende/temaet som de andre funksjonene. Ulempene med denne metoden i forhold
til å bare vise nettsiden til TimeEdit er at det er noe mer arbeid å grafisk presentere dataene i applikasjonen.
Web-scraping er det mest tidkrevende av de tre alternativene fordi det legger til ekstra steg med arbeid for å
få hentet ut dataene. I tillegg til å hente og presentere dataene, er det nødvendig å utvikle en metode for å
filtrere ut kun riktig data fra TimeEdit’s nettsider. En annen ulempe er at løsningen er sårbar for forandringer
på TimeEdit sine nettsider. Basert på det ovennevnte kan vi hevde følgende fordeler og ulemper:
1. Bruk av eksisterende API tilknyttet TimeEdit
+ Sikker
+ Allerede utviklet og ummiddelbart anvendbar
- Avhengig av en tredjepart
Høgskolen i Ålesund
Hovedprosjekt
Side 54
2. Web-scraping av HIALS TimeEdit’s nettside
+ Mer frihet til å definere løsning
- Usikker
- Tidkrevende da ekstra arbeid er nødvendig
3. Vise TimeEdit’s nettside direkte
+ Enklest å implementere
- Kanskje vanskeligst å implementere godt
- Lite presenterbar på mobile applikasjoner
- Ingen kontroll eller strukturering av relevante dataene
Etter å ha vurdert disse tre metodene ble gruppen enige om å bruke TimeEdit’s API. Grunnlaget for dette
er at det fremsto som det alternativet som ville enklest gi oss et strukturert datasett å jobbe med, da både
alternativ 2 og 3 krever web-scraping for å ekstrahere nyttig data. Hvis dataene var allerede tilgjengelig i
et API kunne mye arbeid unngås. Enkeltheten ved å vise TimeEdit’s nettside direkte så ikke ut til å være
verdt presentasjonsproblemene som ville forekomme. Dermed følger prioriteringen for ønsket metode samme
nummerering som listen over.
For å gå frem med denne løsningen tok vi kontakt med Geir Halsvik, som er leder for IT seksjonen ved
Høgskolen i Ålesund. Av han fikk vi vite at ansvarlig for TimeEdit ved høyskolen er Nils Roald, og at systemet
driftes av Kenneth Opedal. Vi ble også informert om at skolen er i gang med å implementere en stor oppdatering av TimeEdit systemet. Den nye versjonen av TimeEdit(versjon 3.x) vil bli betydelig forskjellig fra dagens
utgave, både på frontend og backend.
Dette gjør at vi møter en ny problemstilling - skal applikasjonen lages for dagens system, og bli avleggs om
noen måneder, eller skal vi prøve å få tak i tilgang til den nye versjonen? Gruppen ble enige om å kontakte
Evolvera(de som utvikler systemet) ångående API for den nye versjonen. Etter første runde med undersøkelser
fikk vi vite at det er nødvendig med en sertifisering for å få tilgang til systemet. Etter dette bestemte gruppen
seg for å ta kontakt med Evolvera direkte, da et slikt kurs ville måtte ta sted i Sverige, og gruppen har hverken
tid eller ressurser til et slikt kurs. I mellomtiden skulle gruppen utforske web-scraping som et alternativ i tilfelle
det ikke var mulig å få API tilgang uten kurs. Som en siste utvei kan problemet løses ved å presentere TimeEdit
sin nettside i applikasjonen. Dette har fordelen med at man kan bare forandre ressurslinken når det nye systemet
kommer i drift. Ulempen med dette er at nettsidene ikke er tilpasset liten skjerm som diskutert tidligere.
Forsøk på aksessere TimeEdit’s API uavhengig av noe kurs for sertifisering med prøving-og-feiling i nettleseren
lyktes heller ikke.
Løsningen som ble valgt var å implementere en web-scraping-mekanisme på serversiden av applikasjonen som
tilbød strukturert data gjennom et egetutviklet API (web service). Mobil-applikasjonen er i stand hente de
dataene den trenger fra web-applikasjonen ved behov. Dette løser også problemstillingen med at HIALS skulle
implementere en ny versjon av TimeEdit, da det ikke blir nødvendig å oppdatere samtlige mobile enheter for
å kompensere for endringen. For brukerne vil ikke opplevelsen bli noe forskjellig med den gamle TimeEdit
løsningen og den nye TimeEdit løsningen.
4.3.2
Lovlige hensyn
Med den løsningen som ble valgt var det viktig å vite at innhentingen av dataene ikke bryter med noen lover om
opphavsrett, da spesifikt åndsverksloven [ 72 ] . Etter å ha undersøkt dette, hovedsakelig ved bruk av internett
Høgskolen i Ålesund
Hovedprosjekt
Side 55
kom vi frem til konklusjonen at innhentingen av data ikke bryter med lover eller retningslinjer for opphav av
data. Dette er basert på de to følgende argumentene;
• Dataene er produsert og administrert av skolen, og er derfor skolens eiendom. Evolvera(selskapet som
leverer og eier TimeEdit), leverer kun løsningen som presenterer dataene.
• Robots.txt filen som ligger ved timeplanen tilsier at automatiske tjenester kan innhente data fra alle
kataloger for domenet timeedit.hials.no[ 73 ] . Dette er en vedlagt fil/protokoll som viser hva automatiske
tjenester har tilgang til.
4.3.3
Utvikling av løsning
Da det var bestemt at vi skulle benytte oss av web-scraping for å søke etter og hente ut behandlingsklar
informasjon, begynte vi med analyse av TimeEdit-tjenesten som tilbudt sluttbrukeren via nettsiden [ 74 ] .
Figur 4.31: Et skjermbilde av TimeEdtit’s nettside for søk på klasser
Nettsiden i Figur 1.31 er grensesnittet til tjenesten som vi skal integrere. Den er aksesserbar fra hvilkensomhelst nettleser via HIAL’s hjemmeside [ 75 ] og inneholder de funksjonene fra TimeEdit som vi ønsker å
integrere i e-læringsapplikasjonen. Selve dataene vi ønsker befinner seg i tekstformat i en eller annen del av
kildekoden. Kildekoden kan granskes enkelt ved hjelp av en nettleser eller ved å laste ned siden og åpne den
med et tekstredigeringsprogram. Vi benyttet oss av nettleseren for å granske kildekoden. Kildekoden består av
Høgskolen i Ålesund
Hovedprosjekt
Side 56
svært mye tekst, og det vil ikke legges ved denne rapporten, men kan undersøkes ved å laste ned nettsiden selv.
Der det er nødvendig vil vi vise utdrag.
Ved å se nærmere på kildekoden finner man at nettsiden består av standard HTML, og benytter seg av Javascript
for å endre side-innhold via å manipulere og sende input-parametere via HTML-forms.
2
4
f u n c t i o n addObject ( i d ) {
v a r r e l o a d i n g d i v = document . getElementById ( ’ r e l o a d i n g ’ ) ;
reloadingdiv . style . display = ’ ’;
document . form . wv_addObj . v a l u e = i d ;
document . form . submit ( ) ;
6
.......
8
<INPUT t y p e =’ hidden ’ name=’wv_addObj ’ v a l u e=
Kodesnutt 4.1: Utdraget av HTML kildekoden til TimeEdit ovenfor viser en JavaScript-funksjon og en input-tag.
Dette foregår ved at brukeren interagerer med elementer i nettsiden (knapper, søkefelt (input forms) o.l)
som er bundet tl JavaScript funksjoner. På denne måten kan nettleseren tolke brukeren’s ønsker, og TimeEdit
vil svare med mer HTML og JavaScript som inneholder en timeplan. Bruker-input lagres som parametere i
HTML input-forms som tolkes som parametere ved sending. Disse parameterene sendes med HTTP GET, og
dette betyr at bruker-inntastet data er synlig i URLen. Det er da enkelt å hente ut ønsket innhold uten å måtte
benytte seg av Javascript eller å hente innhold mer enn en gang. Ønskede parametre kan settes som strenger i
etter den eksisterende URLen, og ønsket innhold kan hentes direkte dersom man har kjennskap til strukturen.
På denne måten unngår vi bruk av TimeEdit’s nettside helt.
Neste steg er derfor å skaffe seg kjennskap til og forståelse av strukturen i TimeEdit’s nettleser-baserte tjeneste. Selve dataene som TimeEdit leverer og dets struktur (timeplan) må forstås, i tillegg til strukturen i det
underliggende systemet og hvordan URLen kan manipuleres for å levere resultatet som inneholder dataene vi
trenger.
Høgskolen i Ålesund
Hovedprosjekt
Side 57
Figur 4.32: En vanlig timeplan
I selve timeplanen som presentert av TimeEdit, kan oversikts-perspektivet brytes ned i følgende tidsgrupperinger:
1. År (semestertimeplan)
2. Uker
3. Dager
4. Forelesninger (Tidsramme definert av klokkeslett)
Forelesningene er det meste relevante for visining i E-lærings-applikasjonen og inneholder også det meste av
informasjonen som knyttes opp til applikasjonen’s innhold. (Fag, Studieløp etc) Dette utgjør måldataene som
vi må produsere en metode for å pålitelig kunne hente ut.
Neste steg var å finne ut hvordan TimeEdit’s programstruktur gjør seg synlig via nettsiden, og hvordan dette
kunne benyttes.
Figur 4.33: Treff-element som vises etter søk i TimeEdit som presentert i en nettleser.
Høgskolen i Ålesund
Hovedprosjekt
1
<a h r e f =’ j a v a s c r i p t : addObject ( 1 7 5 0 0 0 ) ’><img s r c = ’/ img / p l u s . g i f ’
Side 58
. . .>
Kodesnutt 4.2: Utdrag av kildekoden til TimeEdit’s nettside som vist i figur 1.32
Av kildekoden til TimeEdit og det assosierte elementet i nettleseren ovenfor, kan vi resonnere oss fram til at
enheter i systemet som fag, lærere eller klasser er i systemet representert som objekt med tilhørende datafelt.
Felles for alle objektene er en ID bestående utelukkende av tall på fem eller seks siffer som benyttes for å
kunne gjøre oppslag i systemet. Dette ser vi fra JavaScript funksjonen i figur 1.33. Disse informasjonsobjektene
representerer f.eks fag, klasser eller rom, og danner grunnlaget for hvordan timeplanen skal formateres. Vi kan
videre resonnere oss fram til at TimeEdit har dermed et eget system for håndtering og kontroll av informasjonsobjekter. Dette systemet ser ikke ut til å være direkte kompatibelt med systemet i E-lærings websiden eller
Høyskolens andre systemer. Dette var forventet av gruppen, men presenterer også ett problem som må under
utviklingen løses for at systemene skulle kobles sammen sømløst. Problemet er at vi ikke kan gjøre oppslag eller
søk i TimeEdit’s system med unike data-felt i vårt eller Høyskolen’s system.
Det neste steget går ut på å analysere URLen som brukes for å hente svar fra HIALS TimeEdit’s server. URLen
påvirker direkte svar-resultatet og kan i seg selv definere hva som skal hentes uten noe behov for å sende med
ett objekt eller lignende. Nedenfor er en slik URL:
1
h t t p : / / t i m e e d i t . h i a l s . no /4DACTION/WebShowSearch/1/1 −0?wv_type=5&wv_ts=20130511 T191704X3729&
wv_search=&wv_startWeek=1301&wv_stopWeek=1318& w v _ f i r s t=0&wv_addObj=&wv_delObj=&wv_obj1
=174000&wv_text=T e k s t f o r m a t
Kodesnutt 4.3: En URL generert når man søker etter en timeplan for ett spesifikt fag
Man kan lese av URLen og analysere de forskjellige parameterene. Parameterene er forøvrig alt som befinner
seg etter spørsmålstegnet i URLen, og består av nøkkel-verdi par bundet sammen med likhetstegn. En parameter
er separert fra en annen med tegnet ampersand. Selve parameterene med tilhørende verdier er skrevet på
engelsk eller norsk, og disse ordene er forkortelser eller sammensetninger som også forteller om parameterens
bruksområde. I tillegg matcher parameternavnene funksjonsnavnene i Javascript, som også gir videre grunnlag
for å bestemme hva de gjør. Med enkel deduksjon og noe prøving og feiling, finner man fram hvilke parametre
som gjør hva, hvilken rekkefølge de må stå i, og hvilke som er nyttige for E-lærings-applikasjonens bruk.
Høgskolen i Ålesund
Hovedprosjekt
Side 59
Tabell 4.3: Tabell over parametere i URLen separert som navn og verdi med tilhørende funksjon
Navn
wv_type
wv_ts
vw_search
vw_startWeek
vw_stopWeek
vw_obj1
(inkluderer
wb_obj2,
wb_obj3 etc)
vw_text
vw_addObj
vw_delObj
Verdi
Tall
Funksjon
Bestemmer hvilket type objekt som skal
søkes etter.
Fag/Kurs = 3
Klasse/Program = 5
Foreleser = 6
Rom = 7
Dato + Streng
Sesjon
Streng
Søk på navn tilhørende objekt
Streng bestående av 4 tall, siste to siffer Bestemmer når timeplanen skal starte.
fra år og ukenummer.
Streng bestående av 4 tall, siste to siffer Bestemmer når timeplanen skal stoppe.
fra år og ukenummer.
Tall-streng bestående av fem eller seks Setter hvilke objekt i TimeEdit syssiffer.
temet som skal inkluderes i timeplanen.
Spesifikk tekst-streng:
Bestemmer hvordan timeplanen skal
tekstformat
representeres.
grafisk
tekst
Tall-streng bestående av fem eller seks Legger til ett objekt til listen.
siffer.
Tall-streng bestående av fem eller seks Fjerner ett objekt fra listen.
siffer.
Tabellen ovenfor ble utarbeidet ved å bruke TimeEdit’s nettside i en nettleser, gjøre endringer og observere
hva som blir endret, fjernet eller lagt tili URLen. Av parameterene ovenfor er har kun ett fåtall noen nytteverdi
for vår bruk, noe som er svært heldig da det vil gjøre jobben med å implementere en løsning mindre komplisert.
Vi vil med første øyekast kun ha bruk for parameterene som velger objekt for visning i TimeEdit-systemet, og
parameterne som velger tidsrammen for timeplanen. Videre testing viser at de nødvendige parameterene vi må
benytte må stå i følgende rekkefølge:
1. wv_obj1 Objektkoder går først, så mange som nødvendig (obj1, obj2 etc...).
2. startWeek, stopWeek Disse er valgfrie, men bør defineres for enkelhets skyld.
3. vw_text
Med denne kunnskapen er det mulig å konstruere en URL som returnerer en ønsket timeplan gitt at man
kan objektkoden tilhørende faget eller studieløpet i TimeEdit-systemet.
Høgskolen i Ålesund
Hovedprosjekt
Side 60
Valg av teknologi/støttebibliotek
Følgende den initielle analysen av TimeEdit’s presentasjonslag, gjenstår implementasjon av web-scraping løsning
i server-delen av web-applikasjonen. Løsningen må benytte Java, være i stand til å hente ut og analysere websider samt være godt nok dokumentert til å kunne enkelt endres ved behov. Kravet for å enkelt kunne endres
var nødvendig for å kunne svare på eventuelle endringer i Time-Edit systemet. I tillegg til en selv-utviklet
løsning som benytter Java’s HTTPClient pakke, eksisterer følgende løsninger utviklet av tredjeparter myntet
på nettopp web-scraping:
• Jsoup
[ 76 ]
• TagSoup
[ 77 ]
• HTMLUnit
[ 78 ]
• Web Harvest
• jArvest
[ 79 ]
[ 80 ]
Tanken på utvikle en egen løsning via Java’s eget HTTPClient bibliotek falt bort da det er mye enklere og
tidsbesparende å benytte en eksisterende løsning som allerede er godt dokumentert. Noe testing med en egen
løsning ble utført, men det skapte en større kodebase å vedlikeholde, noe som ikke var ønskelig og heller ikke
nødvendig i dette tilfellet. Ved å lære og bruke en av de ovennevnte støttebibliotekene kunne gruppen dermed
fokusere på den viktigste delen av løsningen - selve uthentingen og bearbeidingen av informasjonen.
Gruppen som helhet analyserte de forskjellige alternativene som nevnt i listen ovenfor ved å gå gjennom dokumentasjon og presentasjon av funksjonalitet som bibliotekene hadde. Disse er alle nettbaserte. Gruppen konkluderte med at Jsoup var det enklest benyttbare alternativet. En av de viktigste grunnene til at gruppen kom
til denne beslutningen var at Jsoup viste seg å være best dokumentert, fra både offisielt hold og tredjeparts
bruk av Jsoup. En annen og minst like viktig grunn, var hvordan gruppen oppfattet enkelheten i syntaksen. For
eksempel HTMLUnit imiterer en klient, og krever gjerne dypere kjennskap til kildekoden som skal analyseres,
og har litt mer komplisert og noe for ordrik syntaks. For å f.eks hente ut en spesifikk tag i et HTML-dokument
krevde HTMLUnit for mye. Jsoup og TagSoup imiterer HTML-hierarkiet på en logisk måde i kode-syntaksen,
noe som gjorde det mer attraktivt en andre alternativer (Objektstrukturen i biblioteket hadde et hierarki som
etterlignet HTML-hierarki-systemet). Dette ville gjøre koden mer lesbar, vedlikeholdbar og ikke minst skrivbar
for gruppemedlemmene.
TimeEdit og E-læringsapplikasjonen, to forskjellige systemer
En metode for å kunne sette likhetstegn mellom to objekter i to forskjellige systemer, f.eks et fag som representert av E-lærings websiden og et fag som representert av TimeEdit var som tidligere nevnt nødvendig.
TimeEdit støtter også søk med fritekst, og søk med fagkode eller klassekode gir som regel ett resultat som
vist i bildet nedenfor - dette kan vi utnytte til å hente ut TimeEdit-objektkodene vi trenger.
Høgskolen i Ålesund
Hovedprosjekt
Side 61
(a) Fag
(b) Klasse
Figur 4.34: TimeEdits fritekstsøk for fag og klasse
Som vist i figur 4.34 og kodesnutt 4.2 inneholder treff-elementet objektkoden, og herfra er det kun et spørsmål
om hvordan man skal legge til dette søkesteget i løsningen.
Utvikling av løsning i Java med Jsoup og JAX-RS
Basert på analysen av TimeEdit og ved valg av støttebibliotek gjensto det kun å utvikle løsningen konkret.
Generering av URL
Basert på det som kom fram av analysen av TimeEdit tidligere, opprettet vi metoder i klassen TimeEditService i
web-applikasjonen som genererte en korrekt formatert URL basert på relevante input-parametere. Kodesnutten
i vedlegg 4 dem inneholder disse metodene, og vi vil ikke gå mer i dybde mer enn nødvendig - hovedpoenget
her er å demonstrere at vi benytter dataene vi samlet inn til å generere URLer. Testing av disse ble gjort ved
å lime inn resultatet fra nettleseren og verifisere resultatet.
Parsing i Jsoup
Med Jsoup som støttebibliotek kan henting, parsing og REST-funksjonalitet skrives inn i en og samme klasse,
en EJB om nødvendig. Jsoup er kompakt, funksjonsrikt og lettbrukt nok til at dette er mulig uten å gjøre
koden uleselig. For å beholde modulariteten i systemet, utviklet vi TimeEdit-løsningen som en enkelt støttet
REST root resource klasse, som beskrevet i seksjonen Teoretisk Grunnlag - REST tjenester. Et utdrag fra
denne klassen er vist nedenfor:
1
3
5
7
9
11
13
......
im por t j a v a x . e j b . S t a t e l e s s ;
im por t j a v a x . ws . r s .GET;
im por t j a v a x . ws . r s . Path ;
im por t j a v a x . ws . r s . PathParam ;
......
@Stateless
@Path ( " t i m e e d i t " )
public c l a s s TimeEditService {
//Maximum number o f o b j e c t r e q u e s t s t h a t w i l l be p a r s e d by getURL ( )
p r i v a t e s t a t i c i n t MAX_OBJECT_REQUESTS = 1 0 ;
.......
}
Kodesnutt 4.4: Kodesnipp fra klassen TimeEditService, som er grovt kortet ned.
Høgskolen i Ålesund
Hovedprosjekt
Side 62
I første omgang var det viktigst å få gjort en tilkobling via HTTP til TimeEdit for å få hentet ut et HTMLdokument og skape en logisk struktur av de nødvendige dataene som kunne behandles programmatisk. For å få
til en slik struktur, ble en del indre klasser opprettet for representere forskjellige objekter som speilet TimeEdit’s
innordning av objekter og tidsrammer. Strukturen her kan beskrives som hierarkisk da en overordnet klasse vil
innehold lister (java.util.List) av den underordnede klassen. Disse klassene er kun nyttig i sammenheng med
midlertidig organisering av data, og har ikke nytte utenfor klasse-skopet.
Figur 4.35: Diagram over Klassen TimeEditService med indre klasser.
En forbindelse mellom vår EJB og TimeEdit er enkelt opprettet som illustrert av kode-utraget nedenfor:
1
3
5
7
9
p u b l i c Ti meEditS chedul e g e t T i m e E d i t S c h e d u l e ( S t r i n g siteURL ) {
Time EditSch edule t i m e E d i t S c h e d u l e = new Ti meEditS chedul e ( ) ;
Document doc = n u l l ;
......
try {
doc = Jsoup . c o n n e c t ( siteURL ) . g e t ( ) ;
} c a t c h ( IOException ex ) {
Logger . g e t L o g g e r ( T i m e E d i t S e r v i c e . c l a s s . getName ( ) ) . l o g ( L e v e l . SEVERE, n u l l , ex ) ;
}
Kodesnutt 4.5: Et utdrag av en metode i TimeEditService som viser hvordan Jsoup benyttes for å hente ut ett
enkelt dokument
Document-objektet doc kan så enkelt gjennomgås ved hjelp av løkker og if-setninger som utnytter vår
kjennskap til kildekoden til HTML-dokumentet som returneres av TimeEdit. Eksempelet nedenfor viser hvordan
Høgskolen i Ålesund
Hovedprosjekt
Side 63
man kan gå gjennom HTML via Jsoup og hente ut data:
1
3
5
7
i f ( ! tableColumns . g e t ( i ) . getElementsByTag ( " f o n t " ) . isEmpty ( ) ) {
s t r i n g D a t a = tableColumns . g e t ( i ) . getElementsByTag ( " f o n t " ) . f i r s t ( ) . t e x t ( ) ;
i f ( s t r i n g D a t a . c o n t a i n s ( "Uke" ) ) {
// c r e a t e new week and b r e a k l o o p i f t h e f i r s t e l e m e n t c o n t a i n s
Uke
//
System . out . p r i n t l n ( "NEW WEEK: " + s t r i n g D a t a ) ;
.....
}
Kodesnutt 4.6: Utdrag fra klassen TimeEditService i web-applikasjonen
Kodesnutten ovenfor viser en if-setning som sjekker om det eksisterer et element i HTML-koden som har
taggen "font", og at denne ikker tom. Deretter henter sjekker den innholdet i elementet. Selve arbeidet er
utelatt av plasshensyn.
HTML-dokumentet som returnert av TimeEdit sorterer informasjonen vi trenger ved hjelp av standard tabeller
med rader og kolonner. Framgangsmetoden vi benyttet for å hente ut dataene gikk dermed ut på å gå gjennom
hver rad og hente ut tekstdataene i hver kolonne. Som demonstrert i figur 1.32 er informasjonen av lik type
i alle samsvarende kolonner - dvs at i envher rad vil f.eks kolonne nummer 5 alltid vil inneholde samme type
data.
Hovedtabellen er merket med en class-tag (“booking”), og med Jsoup hentes tabellen enkelt ut og man kan iterere
over innholdet og ekstrahere data med en switchcase nummerert etter hver kolonne. Noe forkortet illustrasjon
fra funksjonen getTimeEditSchedule i klassen TimeEditService følger:
1
3
5
7
9
11
13
.....
Element c o n t e n t = doc . g e t E l e m e n t s B y C l a s s ( " b o o k i n g " ) . f i r s t ( ) ;
Elements rows = c o n t e n t . getElementsByTag ( " t r " ) ;
f o r ( Element row : rows ) {
Elements tableColumns = row . getElementsByTag ( " td " ) ;
f o r ( i n t i = 0 ; i < tableColumns . s i z e ( ) ; i ++) {
.....
switch ( i ) {
c a s e 2 : //Dag (Man, Tir , Ons e t c )
day = new ScheduleDay ( s t r i n g D a t a ) ;
break ;
.....
}
Kodesnutt 4.7: Utdrag fra klassen TimeEditService fra no.hials.muldvarpweb.v2
1
<TABLE c l a s s =’ booking ’ b o r d e r = ’0 ’ c e l l p a d d i n g = ’5 ’ c e l l s p a c i n g = ’0 ’>
Kodesnutt 4.8: Utdrag fra HTML-kildekoden til nettsiden i figur 4.32
Med dette fikk vi organisert hele timeplanen inn i en struktur som vi senere kunne behandle programmatisk.
Høgskolen i Ålesund
Hovedprosjekt
Side 64
Spørring på fagkode og klassekode
Som tidligere nevnt var det også nødvendig å kunne hente ut en timeplan basert på fagkode eller klassekode.
Dette løste vi ved å bruke to HTTP-spørringer, ett for å finne riktig TimeEdit objektkode basert på TimeEdit’s
fritekstsøk, og ett siste for å hente ut den faktiske timeplanen som benyttet metoden vi har utviklet tidligere.
1
3
5
7
@GET
@Path ( " c o u r s e c o d e /{ c o u r s e c o d e }{ s t a r t w e e k : ( / s t a r t w e e k / [ ^ / ] + ? ) ?}{ stopweek : ( / stopweek / [ ^ / ] + ? )
?}{ d a t e : ( / d a t e / [ ^ / ] + ? ) ?} " )
@Produces ( { MediaType . APPLICATION_JSON} )
p u b l i c Response getScheduleByCourseCode ( @PathParam ( " c o u r s e c o d e " ) S t r i n g courseCode ,
@PathParam ( " s t a r t w e e k " ) S t r i n g s t a r t w e e k ,
@PathParam ( " stopweek " ) S t r i n g stopweek ,
@PathParam ( " d a t e " ) S t r i n g d a t e ) {
9
11
13
}
System . out . p r i n t l n ( " c o u r s e code : " + c o u r s e C o d e ) ;
S t r i n g [ ] o b j e c t C o d e s = getObjectCodeFromCourseCode ( c o u r s e C o d e ) . s p l i t ( " / " ) ;
System . out . p r i n t l n ( " o b j e c t C o d e [ 0 ] : " + o b j e c t C o d e s [ 0 ] ) ;
r e t u r n g e t R e s p o n s e ( o b j e c t C o d e s , date , s t a r t w e e k , stopweek , t r u e ) ;
Kodesnutt 4.9: Utdrag fra en JAX-RS annotert REST resource metode i klassen TimeEditService
1
3
5
7
9
11
13
15
17
19
21
p u b l i c S t r i n g getObjectCodeFromQuery ( S t r i n g query , i n t t y p e ) {
S t r i n g searchURL = TIMEEDIT_HIALS_URL + TIMEDIT_PARAM_SEARCH_TYPE + "=" + t y p e + "&" +
TIMEDIT_PARAM_SEARCH + "=" + query ;
Document doc = n u l l ;
try {
doc = Jsoup . c o n n e c t ( searchURL ) . g e t ( ) ;
} c a t c h ( IOException ex ) {
Logger . g e t L o g g e r ( T i m e E d i t S e r v i c e . c l a s s . getName ( ) ) . l o g ( L e v e l . SEVERE, n u l l , ex ) ;
}
Elements e l e m e n t s = doc . s e l e c t ( " a " ) ;
System . out . p r i n t l n ( " Elements s i z e : " + e l e m e n t s . s i z e ( ) ) ;
P a t t e r n p a t t e r n = P a t t e r n . c o m p i l e ( " j a v a s c r i p t : addObject \ \ ( ( \ \ d { 6 } | \ \ d { 7 } ) \ \ ) " ) ;
Matcher matcher ;
f o r ( Element e : e l e m e n t s ) {
String currentString = e . attr (" href ") ;
i f ( c u r r e n t S t r i n g != n u l l && !
c u r r e n t S t r i n g . isEmpty ( ) ) {
matcher = p a t t e r n . matcher ( c u r r e n t S t r i n g ) ;
i f ( matcher . f i n d ( ) ) {
S t r i n g r e t V a l = matcher . group ( ) . r e p l a c e
( " j a v a s c r i p t : addObject ( " , " " ) ;
retVal = retVal . r e p l a c e ( " ) " , "" ) ;
return retVal ;
}
}
}
return "" ;
}
Kodesnutt 4.10: Nytte-funksjon i klassen TimeEditService som bruker regulære uttrykk for å hente ut
objektkoder
Ovenfor er en funksjon fra TimeEditService som utfører en HTTP-forbindelse via Jsoup til TimeEdit, og
bruker Java’s regex-bibliotek til å finne å identifisere søketreffene som inneholder riktig TimeEdit-kode. Som vist
i kapittelet om analyse av TimeEdit, befinner TimeEdit-koden seg som variabel inne i et kall til en javascriptfunksjon. Da vi har navnet til denne funksjonen, “addObject()”, trenger vi regex til å matche denne funksjonen.
Dette ble fullført med regex-strengen under:
Høgskolen i Ålesund
Hovedprosjekt
Side 65
j a v a s c r i p t : addObject \ \ ( ( \ \ d { 6 } | \ \ d { 7 } ) \ \ )
Kodesnutt 4.11: Utdrag fra kildekoden i figur 4.32
som vil matche all tekst som inneholder denne javascript-funksjonen, og som et ekstra lag med sikkerhet
kun variabler som har en lengde på seks eller sju siffer. I Java regex noterer “\\d” et tall (uten dobbel kvotering
og java-spesifikke spesielle karakterer), hvorav etterfølgende krøllparanteser ({}) som inneslutter et tall noterer
lengde. I sammenheng med symbolet “|” som betyr “OR”, velger vi da å matche innhold med enten seks eller
sju siffer. Dette kunne også oppnås ved å notere lengde ved å endre uttrykket til "\\d{6,7}".
Etter dette kan man enkelt skrelle vekk teksten i javascript-funksjonen og hente ut selve tallet (TimeEdit objektkode) med Java’s String replace-funksjon. Deretter kan man benytte den samme metoden vi utviklet for
å hente ut timeplaner basert på objektkoder. Videre skulle det også å ha vært mulig å lagre klasse-kode og
TimeEdit objektkodene, slik at det kun ville ha vært nødvendig å gjøre to HTTP-spørringer en gang for hver
kode, eller muligens kjøre gjennom alle fagkodene for å hente ut TimeEdit objektkodene. Dette kunne oppnås
ved å legge til ett datafelt i Course og Programme JPA-klassene som representerer en TimeEdit kode. En
web-scraping-løsning for dette måtte i så fall utvikles, og denne kunne basere seg på arbeidet gjort så langt.
Løsningen dette resulterte i kunne gjøre HTTP-kall mot TimeEdit’s nettside og motta svar, analysere og
ekstrahere svaret for å så strukturere dataene. Alt dette kunne baseres på
• TimeEdit objektoder
• Fagkoder (innenfor HIALS’s system)
• Klassekoder (innenfor HIALS’s system)
Høgskolen i Ålesund
Hovedprosjekt
Side 66
Design av API
Denne delen omhandler hvilke grunnlag vi la til rette for å utvikle vår API for TimeEdit samt hvilke resultater
vi endte opp med.
API
API’et er utviklet kun med tanke for bruk av e-læringsapplikasjonen for mobile plattformer. Med dette blir
dokumentasjon og svar-type mindre viktig og arbeidet kan fokuseres på å kunne produsere riktige og konsistente
resultater. Det blir heller ikke nødvendig å produsere svar i mer enn en type dataformat, og gruppen ble enige
om å bruke JSON siden det fremstår som mer lettlest og ikke unødvendig ordrikt. Dette betyr midlertidig ikke
at flere dataformat kan tilbys om nødvendig i framtiden.
Utforming av URI
URI-en til TimeEdit API-et som tilbudt av E-lærings-nettstedet ble utviklet med overflatisk simplisitet og
lesbarhet som mål i henhold til seksjonen om URI-design under teoretisk grunnlag. Dette innebærer at vi
bruker REST-arkitekturstilen også til utformingen av URIene. REST er beregnet for bruk med teknologier som
har blitt populære grunnet enkelhet mtp. lesbarhet og anvendbarhet av mennesker, og med dette som grunnlag
har vi rom for å hevde at en URI skal helst være:
• Beskrivende og meningsfull for mennesker
URIen må beskrive ressursen URIen identifiserer. Dette innebærer også at ordbruken må være
– Ordlagt med substantiv og ikke verb (HTTP)
I henhold med prinsippet om et uniformt begrenset grensesnitt og HTTP, må URIen også unngå å
bruke verb fordi dette er allerede dekket av HTTP-protokollen. (GET, POST etc.)
• Logisk strukturert
Rekkefølgen og oppbyggingen av URIen skal ikke vanskeliggjøre forståelse av hvilken ressurs som identifiseres, men heller gi mer innsikt jo lengre den er. Dette innebærer at URIen må forstås som logisk stykkvis
oppdelt og relatert til det foregående elementet.
• Kompenserende for menneskelig feil
• Konsistent
Dette betyr at man skulle kunne tolke og forstå hva som ønskes søkt av en spørring mot APIet kun ved å lese
URIen uten nødvendigvis å ha dyp kjennskap til APIet. Formålet med dette er å gjøre API’et lett å jobbe opp
i mot, og å redusere tiden brukere av API’et benytter for å skaffe innsikt i systemet samt for å redusere tiden
brukt til feilsøking da feil vil forhåpentligvis forekomme sjeldnere. I tillegg skulle eventuelle feiltastinger eller
annet feilbruk av API-et ikke taksere det underliggende systemet ved å gjøre unødvendig arbeid med spørringer
som ikke vil gi noe nyttig resultat. Klart feilformaterte spørringer burde dermed forkastes, og bruker opplyses
om dette.
For å oppnå disse målsetningene benytter vi oss av Java’s API for REST webservices, JAX-RS. Dette
medfølger Java EE 6 som vi bruker, og det er da kun et spørsmål om å gjøre bruk av API’et innenfor våre klasser
og metoder. Som tidligere nevnt hadde vi opprettet en REST root resource service klasse (TimeEditService),
hvor vi har annotert klassen med @Path og variabel “timeedit”, som gjør den gjeldende ressurs-stien til følgende:
Høgskolen i Ålesund
Hovedprosjekt
Side 67
Tabell 4.4: Base-URI pluss sti som defineres i web-applikasjonen.
[SERVERPATH]/services/timeedit/
Deretter vil enhver funksjon med @Path annotasjon innenfor klasse-skopet benytte ressurs-stien ovenfor, i
tillegg til sin egen-definerte variabel. Navnet "/services/" innenfor URIen gjør det klart at alt som etterfølger
er "services", eller på norsk, "tjenester" - dette har som henskit å gjøre det klart for brukeren hva som kan
foventes av svar.
Basert på behovet som definert tidligere kom vi fram til at API’et måtte tilby minst følgende tjenester:
• Henting av timeplan basert på...
– timeedit objekt-koder
– fagkode
– klassekode
I tillegg skulle det være mulig å definere en start-uke og stopp-uke eller dato i timeplanen for å avgrense
svar-innholdet.
For å tilfredsstille behovet ovenfor (og evt. ekstra behov), opprettet vi følgende @Path parmetere for webservices:
Tabell 4.5: Tabell over ikke-absolutte URIer, tilknyttet funksjon med JAX-RS og en beskrivelse.
@Path-Parameter
/
/simple/
Funksjonsnavn
getScheduleByMultipleObjectID
getParams
getSimpleScheduleByMultipleObjectID
/coursecode/
getScheduleByCourseCode
/classcode/
getScheduleByClassCode
/params/
getScheduleByMirrorParameters
/query/
getScheduleByQuery
Beskrivelse
Aksepterer TimeEdit objektkoder og
svarer med fullt formatert timeplan
Aksepterer TimeEdit objektkoder og
svarer med enkelt formatert timeplan
Aksepterer kurskoder og svarer med
enkelt formatert timeplan
Aksepterer fagkoder og svarer med
enkelt formatert timeplan
Speiler TimeEdit sitt parametersystem, aksepterer også fulle URLer
Ikke implementert
Som vist tabell 4.5 i @Path-Parameter-kolonnen, er ordene som benyttes i URIen i lowercase, og på engelsk.
Dette bidrar til at URIen blir konsistent da de eksisterende URIene i applikasjonen for fag, studier etc... allerede
er på engelsk. Hvis en bruker vet at alt er i lowercase, reduserer det sannsynligheten for skrivefeil da man ikke
trenger å bekymre seg over tegnsetting. Noe som også forhåpentlig vil bidra til mindre skrivefeil er at forholdsvis
korte men beskrivende ord brukes. Så langt har vi oppnådd en logisk struktur også, i og med at f.eks timeedit
er overordnet alle parametere som kommer etter i URIen.
Høgskolen i Ålesund
Hovedprosjekt
Side 68
Figur 4.36: Demonstrerer Web-servicene som registrert i NetBeans
Disse ressurs-endepunktene vil naturligvis ikke dekke hele TimeEdit’s funksjonsbredd, men er mer en
tilstrekkelig for vår bruk.
1
3
5
@GET
@Path ( " { o b j e c t s t r i n g : | ( ( \ \ d { 6 } | \ \ d { 7 } ) / ? ) +}{ s t a r t w e e k : ( / s t a r t w e e k / [ ^ / ] + ? ) ?}{ stopweek : ( /
stopweek / [ ^ / ] + ? ) ?}{ d a t e : ( / d a t e / [ ^ / ] + ? ) ?} " )
p u b l i c Response g e t S c h e d u l e B y M u l t i p l e O b j e c t I D ( @PathParam ( " o b j e c t s t r i n g " ) S t r i n g
objectString ,
@PathParam ( " s t a r t w e e k " ) S t r i n g s t a r t w e e k ,
@PathParam ( " stopweek " ) S t r i n g stopweek ,
@PathParam ( " d a t e " ) S t r i n g d a t e ) {
7
9
}
S t r i n g [ ] objectCodes = o b j e c t S t r i n g . s p l i t ( "/" ) ;
r e t u r n g e t R e s p o n s e ( o b j e c t C o d e s , date , s t a r t w e e k , stopweek ,
false ) ;
Kodesnutt 4.12: Utdrag fra klassen TimeEditService som viser en JAX-RS annotert funksjon.
API URIen som kan defineres i @Path annotasjonen er ikke dynamisk, noe som forhindret oss i å nå
målsetningen om en enkelt forståelig og brukbar API-URI. Fordi URIen er statisk definert, kan man ikke
utelate deler av den. En funksjon med @Path URI som er definert slik:
/ r e s o u r c e /{ o b j e c t I D }/ c o l o r /{ c o l o r }/ l e n g t h /{ l e n g t h }
Kodesnutt 4.13: Eksempel på en statisk definert URI
vil ikke kalles dersom rekkefølgen endres eller noe utelates. Det vil si at en URI formet slik:
1
h t t p : / /www. s e r v e r . com/ r e s o u r c e /25/ l e n g t h /10
Kodesnutt 4.14: Eksempel på en URI
vil kun gi tilbake en feilmelding eller 404 - Resource not found, da en av path-parameterene var utelatt. En
løsning for å unngå nettopp denne typen scenarioer, er å opprette flere funksjoner som tar i hensyn forskjellige
path-mønstre, men dette skaper overflod av kode. Derfor tok vi i bruk regex som @Path også støtter, og kom
fram til en regex-streng som vist i i utdraget av figuren nedenfor:
1
{ o b j e c t s t r i n g : | ( ( \ \ d { 6 } | \ \ d { 7 } ) / ? ) +}{ s t a r t w e e k : ( / s t a r t w e e k / [ ^ / ] + ? ) ?}{ stopweek : ( / stopweek
/ [ ^ / ] + ? ) ?}{ d a t e : ( / d a t e / [ ^ / ] + ? ) ?}
Kodesnutt 4.15: Selve strengen inne i en @Path variabel med regex
I likhet med normal URI-sti definering i @Path, matcher også denne metoden stien karakter for karakter,
men med regex syntaks-regler. I regex-strengen ovenfor er fire PathParameter-variabler definert (innenfor
krøllparanteser), og vi vil gjennomgå oppbyggingen stykkvis for å så presentere resultat:
• objectstring
Streng med TimeEdit objektkoder på enten seks eller sju siffer, separert med skråstrek.
Høgskolen i Ålesund
Hovedprosjekt
Side 69
• startweek
Streng på fire tall-karakterer som setter startuka i semesteret.
• stopweek
Streng på fire tall-karakterer som setter stoppuka i semesteret.
• date
Streng som bestemmer hvilken dato spesifikt timeplanen skal hentes fra.
Spørsmålstegnet (?) i regex er et symbol som gjør det foregående settet med karakterer “valgfritt”, (den
matcher mønsteret ingen eller en gang) det vil si at f.eks PathParameter-variabelen “date” kan være valgfri i
URIen, og at funksjonen vil kalles dersom den utelates. Dermed har vi oppnådd målsetningen om å skape en
dynamisk og enkelt brukbar URI. Forhåpentligvis kan dette være noe kompenserende for feilbruk av APIet da
resultat vil likevel returneres og bruker kan være fornøyd selv om noe utelates.
I tilegg var det ønskelig å supplere flere TimeEdit objektkoder i en og samme URI, noe vi også løste med
regex. Pluss-symbolet (+) i regex repeterer the forrige symbolet en eller flere ganger, så det kan plasseres bak
en regex-gruppering som beskriver TimeEdit objektkoder. Da matcher regex TimeEdit objektkoden (inkludert
skråstreker) flere ganger. Resultatet er at URIen kan støtte flere TimeEdit objektoder så lenge de kommer etter
hverandre og er separert med skråstrek:
1
h t t p : / /www. s e r v e r . com/ r e s o u r c e s / t i m e e d i t / 1 8 3 0 0 0 / 1 8 5 0 0 0 / 1 8 7 5 0 0 / s t a r t w e e k /1301/ stopweek /1315
Kodesnutt 4.16: Fungerende eksempel på en URI i APIet.
Eksempelet ovenfor viser en gyldig URI som inneholder tre TimeEdit objektkoder, i tillegg til at “date”
PathParameter-variablen er utelatt. Det finnes en øvre grense på hvor mange TimeEdit-koder som kan inkluderes som kan defineres i TimeEditService.
Konvertering av klasser til JSON
Når APIet var utformet gjensto det å konvertere klassene som holdt dataene til JSON. I seksjonen om JAXRS i teoretisk grunnlag nevnes det at JAX-RS har egen støtte for nettopp konvertering av POJO-klasser
(eller andre Java-API klasser som Response) til JSON, gitt at Getter-og-Setter funksjoner er definert. I klassen
TimeEditService håndteres dette i metoden getResponse, som bruker Response-klassen i Java APIet til å genere
svar. Eksempel på bygging av et slikt Response objekt ses nedenfor, hvor variabelen responseEntity er en
TimeEditSchedule-klasse.
1
r e t u r n Response . ok ( r e s p o n s e E n t i t i t y , MediaType . APPLICATION_JSON) . b u i l d ( ) ;
Kodesnutt 4.17: Oppsett av Response
I tillegg til å kunne tilby en fullt formatert timeplan i JSON som vist i forkortet versjon nedenfor:
1
3
5
7
9
{
s c h e d u l e Y e a r : " 2013 " ,
w e e k S t a r t : " 14 " ,
weeekEnd : " 15 " ,
numberOfWeeks : 2 ,
weeks :
[
{
w e e k S t r i n g : "Uke 1 4 , 2013 " ,
weekNo : " 14 " ,
Høgskolen i Ålesund
Hovedprosjekt
days :
[
{
11
13
15
17
19
21
23
25
27
29
31
33
35
37
39
41
43
45
47
49
51
53
},
{
55
57
59
61
63
}
]
}
]
Side 70
day : "Ons" ,
d a t e : " 3 apr " ,
lectures :
[
{
l e c t u r e S t a r t : " 08:15 " ,
lectureEnd : " 10:00 " ,
t y p e : " F o r e l e s , Ovinger " ,
c l a s s I d : "AU1, DA1, AU−y1 , DA−y1 " ,
room : " B o r g u n d f j o r d e n , L165 − Datalab , L167 − P r o s j e k t r o m " ,
t e a c h e r s : " Adrian R u t l e " ,
comment : n u l l ,
courses :
[
{
courseName : " O b j e k t o r i e n t e r t programmering " ,
courseID : n u l l
}
]
},
{
l e c t u r e S t a r t : " 10:15 " ,
lectureEnd : " 12:00 " ,
t y p e : " Ovinger " ,
c l a s s I d : "AU1, DA1, AU−y1 , DA−y1 " ,
room : " L165 − Datalab , L167 − P r o s j e k t r o m " ,
t e a c h e r s : " Adrian R u t l e " ,
comment : n u l l ,
courses :
[
{
courseName : " O b j e k t o r i e n t e r t programmering " ,
courseID : n u l l
}
]
}
]
},
{} ,
{}
w e e k S t r i n g : "Uke 1 5 , 2013 " ,
weekNo : " 15 " ,
days :
[]
Kodesnutt 4.18: Forkortet JSON- av en fullt formatert timeplan som hentet fra TimeEdit og behandlet i
webapplikasjonen
kan også en enklere formatert timeplan returneres som kun returnerer dager /m forelesninger og involverte
fag. Det vil si kun JSON-arrayet "days" som også er inkludert i kodesnutten ovenfor. Dette ble vurdert som
hensiktsmessig siden det ikke var nødvendig å returnere hele og fullt formaterte timeplaner til de fleste av
Høgskolen i Ålesund
Hovedprosjekt
Side 71
funksjonene i mobil-applikasjonen.
4.3.4
Integrering av TimeEdit i mobil-applikasjonen
Med ferdigutviklet metode for å koble sammen TimeEdit og vårt eget system for fag, gjensto det å implementere
og presentere dataene i mobil-applikasjonen. Funksjonalitet for å gjøre HTTP-kall er allerede implementert i
mobil-applikasjonen for Android, og dette bygger vi på. Mobil-applikasjonen er en såkalt rik applikasjon, som
kortfattet betyr at applikasjonen bruker Android’s API og retningslinjer for behanding og presentering av
data. For å oppnå dette opprettet vi en domenestruktur i form av klasser på klientsiden (mobil-applikasjon),
som kunne behandle dataene med egne funksjoner og metoder. Mobil-applikasjonen har en egen Domainstruktur, og kortfattet betyr dette at alle domene-klasser burder arve fra klassen Domain. Innholdet i disse
klassene reflekterer stort sett innholdet i domeneklassene på web-applikasjonsbiten, men med funksjoner for
deserialisering av JSON. Et eksempel på dette kan ses i kodesnutten under:
1
3
5
7
9
11
p u b l i c Ti meEditS chedul e ( JSONObject j s o n ) throws JSONException {
i f ( j s o n . o p t S t r i n g ( " s c h e d u l e Y e a r " ) . isEmpty ( ) ) {
simpleFormat = t r u e ;
t h i s . days = ScheduleWeek . JSONArrayToDays ( j s o n . getJSONArray ( " days " ) ) ;
} else {
simpleFormat = f a l s e ;
t h i s . scheduleYear = json . getString ( " scheduleYear " ) ;
t h i s . weekStart = json . g e t S t r i n g ( " weekStart " ) ;
t h i s . weekEnd = j s o n . g e t S t r i n g ( "weekEnd" ) ;
t h i s . weeks= JSONArrayToWeeks ( j s o n . getJSONArray ( " weeks " ) ) ;
}
}
13
15
17
19
p u b l i c s t a t i c L i s t <ScheduleWeek> JSONArrayToWeeks ( JSONArray j s o n A r r a y ) throws JSONException {
L i s t <ScheduleWeek> r e t V a l = new A r r a y L i s t <ScheduleWeek >() ;
f o r ( i n t i = 0 ; i < j s o n A r r a y . l e n g t h ( ) ; i ++) {
r e t V a l . add ( new ScheduleWeek ( j s o n A r r a y . getJSONObject ( i ) ) ) ;
}
return retVal ;
}
21
Kodesnutt 4.19: To funksjoner fra Domain-klassen TimeEditSchedule i mobil-applikasjonen
Integrering av TimeEdit ble gjort i henhold med den eksisterende lag-strukturen i applikasjonen som er
diskutert tidligere i dette kapittelet i seksjonen om Mobilapplikasjonen. Grovt innebærer det at den nåværende
konteksten i programmet skal styre innholdet som presenteres, dvs. at hvis man er inne på et fag, skal timeplanen
være fra dette faget.
Mye av presentasjonen i applikasjonen består av moduler som er internt kalt "fragmenter" som inneholder
lister, visninger videoer eller andre funksjoner. Det ble bestemt at et fragment for TimeEdit skulle opprettes,
og med dette var det nødvendig å tilpasse det nåværende listesystemet til å kunne vise en timeplan. Til dette
formålet opprettet vi en ny type ListView og BaseAdapter som kunne sortere og presentere disse dataene, SectionedListView og SectionedListAdapter. Disse er definert som klasser som arver fra ListView og BaseAdapter,
og det originale ListFragmentet ble utvidet med funksjonalitet til å håndtere disse nye klassene. Vi så det som
nødvendig å gjøre dette fordi å presentere en tekst-tabell produserte ikke like pene og konsistente visninger som
en liste, og en liste med objekter vil mye enklere kunne tilby rike brukeropplevelser. Resultatet var en scrollbar
liste med seksjoner for uker og dager, hvor den gjeldende dagen/uken er limt i en egen seksjon fast øverst i listen
for å enklere holde oversikt. Denne seksjonen kan animeres og gjemmes basert på scrolling, dvs. at hvis man
scroller ned til man kommer til en ny uke, forsvinner den nåværende uken og erstattes med den nye. Listen kan
i tillegg til dette akseptere trykk og annen interagering på lik linje med andre lister i mobil-applikasjonen.
Høgskolen i Ålesund
Hovedprosjekt
Side 72
I tillegg til dette kan man sjekke "dagens" timeplan fra hvor som helst i applikasjonen, som illustrert under:
(a) Viser TimeEdit fragmentet på
fremsiden
(b) Viser innsiden av TimeEdit fragmentet
(c) Viser TimeEdit i sidemenyen
Figur 4.37: Skjermbilder av mobilapplikasjonen - TimeEdit-funksjonen
TimeEdit-knappen er tilgjengelig fra hovedskjermen, og ved å trykke på den vil timeplanen for det gjeldende
faget eller studiet vises fram på en lett-oversiktlig måte. I mobilapplikasjonen er TimeEdit-funksjonalitet også
tilgjengelig ved å trykke på HIALS-ikonet oppe i venstre hjørne. En meny vil gli inn fra venstre side ut som viser
dagens timeplan for en satt klasse, i dette tilfellet DA1. Trykk på HIALS-ikonet igjen eller Android-tilbakeknapp
nederst i venstre hjørnefor å skjule sidemenyen.
Høgskolen i Ålesund
Hovedprosjekt
4.3.5
Side 73
Fronter
Figur 4.38: JSON fra REST-tjenesten til fronter - eksempeldata
Vi ville hente meldinger fra læreren, dokumenter og innleverings-status fra rommen på fronter.
Siden vi ikke fikk den nødvendige tilgangen til skolens frontersystem valgte vi å gjøre ferdig så mye som mulig
av systemet slik at det enkelt kunne tas ibruk i fremtiden når en slik tilgang foreligger. Derfor lagde vi et fast
sett med eksempel-data for å vise at vår side av APIet fungerer. Det eneste som gjensto var å parse APIet til
fronter.
Høgskolen i Ålesund
Hovedprosjekt
Side 74
Fronter i appen
(a) Viser Fronter fragmentet på
fremsiden
(b) Viser innsiden av Fronter fragmentet
Figur 4.39: Skjermbilder av mobilapplikasjonen - Fronter-funksjonen
Fronter fragmentet viser informasjon fra et valgt rom på fronter og kan kun legges til på fag laget. Siden
implenentasjonen ikke ble fullført vises kun eksempeldata her. Om fronter implementasjonen blir fullført i
fremtiden er integrasjonen i mobilapplikasjonen allerede klar til bruk.
4.3.6
BibSys
Det første som måtte gjøres var å definere hvilke funksjoner som skulle implementeres. De mer gjennomførte
søkesidene på nettet tilbyr mange muligheter for tilpassede søkekriterier, slik som tittel, forfatter, ISBN, bibliotek, etc. [ 81 ] Gruppen ble enige om å begrense funksjonaliteten til et enkelt søk på tittel, begrenset til
beholdningen til biblioteket ved Høgskolen i Ålesund. Resultatet av dette søket skulle vises i en liste i mobilapplikasjonen.
For å få tilgang til databasen til BIBSys tok vi kontakt med support på BIBSys ved hjelp av vår kontaktperson ved skolens bibliotek, Monica Marchant. Derifra ble det informert om at det grensesnittet de hadde som
passet best til vårt var SRU(search/retrieve via URL). Dette er en metode hvor man setter søkeparametrene
sine inn i en URL, og så svarer serveren med resultatet i form av et XML dokument.
Først måtte vi altså lage en mal til URLen slik at vi kunne enkelt putte inn søkeparametrene vi ønsket. Ved
hjelp av noen eksempler fra BIBSys sin support kom vi frem til følgende mal:
Høgskolen i Ålesund
Hovedprosjekt
Side 75
h t t p : / / s r u . b i b s y s . no / s e a r c h / b i b l i o ? v e r s i o n =1.2\& o p e r a t i o n=s e a r c h R e t r i e v e \& s t a r t R e c o r d=1\&
maximumRecords=10\&query=bs . b i b k o d e=xb\%20AND\%20 bs . t i t t e l =i b s e n
I denne url malen er det noen faste og variable parametre. Disse er som følger:
Tabell 4.6: Beskrivelse av parametere i søke-URLen til BibSys
Parameter
maximumRecords=10
query=bs.bibkode=xb
query=...bs.tittel=ibsen
Betydning
Dette parametret gir at det skal ikke returneres mer
enn de 10 første resultatene
Dette parametret begrenser søket til Biblioteket ved
Høgskolen i Ålesund
Dette parametret begrenser søket til bøker med tittel
som ligner på order “ibsen”. Man søker på forskjellige
titler ved å forandre på tittel parametret.
Fast/variabel
Fast
Fast
Variabel
Ved å bruke denne eksempel URLen i en nettleser vil man kunne se resultatene som blir returnert fra BibSys
sine servere.
Nå som vi visste hvordan man søker i BibSys sine databaser, og hva vi kunne vente oss tilbake, måtte vi
avgjøre hva slags struktur systemet vårt skulle ha. Av tidligere erfaring fra alle de andre funksjonene som
applikasjonen allerede tilbyr ble vi enige om at serveren skulle ta seg av spørringen til BibSys sine systemer og
prossesere resultatet til et enklere format. Mobilapplikasjonen vil da kunne gjøre en enkel spørring mot serveren,
og så tar serveren seg av spørringen og parsingen, og gir tilbake et enkelt resultat. På denne måten vil det også
være enkelt å oppdatere løsningen i frtemtiden, da alle forandringer vil skje på serveren, og brukerne ikke trenger
å oppdatere. Om det blir lagt til noen nye funksjoner, vil man alikevel måtte oppdatere mobilapplikasjonen.
Høgskolen i Ålesund
Hovedprosjekt
Side 76
Figur 4.40: Dataflyt ved en spørring mot BibSys
Som man kan se er det veldig mye informasjon som blir returnert, så vi måtte finne en måte å hente ut kun
de dataene som var relevante. For å løse dette valgte vi å bruke Javabiblioteket Jsoup som vi allerede hadde
brukt tidligere for å hente ut data fra timeplansystemet TimeEdit. Dette var fordi biblioteket hadde vist seg å
være ypperlig til å hente ut data fra store og kompliserte datasett.
For å hente ut de relevante dataene, søkte vi igjennom xml filen, og hentet ut infoen som ligger ved tag id
245. Denne under-seksjonen inneholder navnet på forfatter, tittel, og undertittel.
Høgskolen i Ålesund
Hovedprosjekt
Side 77
Figur 4.41: Relevant del av XML responsen fra BibSys
Her går koden igjennom seksjonen linje for linje, og skreller vekk alt som ikke skal være med. Til slutt lagres
tittelen og forfatternavnet i en enkel entityklasse og settes inn i listen som skal returneres til mobilapplikasjonen.
Man kan se tydelig hvordan jobben serveren gjør forenkler jobben for mobilapplikasjonen. Dataene serveren
mottar fra BibSys er på venstre side, mens dataene serveren sender videre til mobilapplikasjonen etter å ha
parset innholdet står på høyre. XML dokumentet har forøvrig blitt kortet ned med ca. 2/3 av plasshensyn.
Figur 4.42: Data før og etter parsing
BibSys APIet i webapplikasjonen er tilgjengelig via URLen: domene.no/services/bibsys/<søkestreng> der
<søkestreng> er hva som spurt om i BibSys sitt eget API.
Høgskolen i Ålesund
Hovedprosjekt
Side 78
BibSys i appen
Figur 4.43: Skjermbilde av mobilapplikasjonen - Her vises resultatet etter et søk på bøker som matchet tittelen
“ibsen
I mobilapplikasjonen er BibSys implementert som et fragmentet og kan kun settes inn på fremsiden som er det
øverste laget. I fragmentet er det en tekstboks og en knapp, brukeren skriver inn søkestrengen og trykker på
knappen. Når knappen trykkes inn sendes en spørring med søkestrengen til BibSys API’et i webapplikasjonen.
JSON dataen fra REST tjenesten blir hentet og parset av mobilapplikasjonen og vist i skjermbildet.
Høgskolen i Ålesund
Hovedprosjekt
5
5.1
Side 79
DRØFTING
Systemintegrasjon
Med unntak av Fronter ble systemintegrasjonen fullført stort sett etter planen. Men i sluttfasen av prosjektet
ble APIet til BibSys endret så vi måtte skrive om parseren vår.
5.1.1
Integrasjon i webapplikasjon vs mobilapplikasjon
Når Fronter, TimeEdit og BibSys skulle integreres i e-læringsapplikasjonen var det to måter dette kunne løses
på. Den første, som er løsningen som ble valgt, var å la mobilapplikasjonen sende forespørsler til serveren
for å så la serveren innhente og prosessere de relevante dataene fra Fronter, TimeEdit og BibSys, for å så
returnere resultatet til mobilapplikasjonen. Fordelen med dette er at vi har full kontroll over hva som foregår
ved innhenting og prosessering av data. Dette er også måten resten av e-læringsapplikasjonen er strukturert
på, så det blir et mer uniformt system. Dette er en stor fordel for de som eventuelt skal vedlikeholde systemet.
Ulempen med denne metoden er at den krever at serveren er tilgjengelig, og at den har ledige ressurser til å
utføre spørringen.
Den andre måten som Fronter, TimeEdit og BibSys kunne vært integrert på er å la mobilapplikasjonen gjøre alt
arbeidet. Det vil si at mobilapplikasjonen går direkte og henter ut og prosesserer dataene fra Fronter, TimeEdit
og BibSys. Med denne løsningen ville ikke mobilapplikasjonen tatt opp noen ressurser fra webapplikasjonen ved
spørringer, men mobilapplikasjonen ville da også være avhengig av større lokale ressurser på enheten.
5.2
Fronter
Å få tilgang til fronter krevde sikkerhetsrettigheter vi ikke hadde som studenter. Uautorisert tilgang til API
nøkkelen kunne også utgjøre en stor sikkerhetsrisiko for brukernes innloggingsinformasjon. Derfor valgte vi å
ferdigstille systemet for mobilapplikasjonen og lage en API på webapplikasjonen som mobilapplikasjonen kan
hente data ifra. På denne måten vil det være enkelt å implementere alle relevante fronter funksjoner som
meldinger ifra lærere, informasjon om dokumenter og status på innleveringer om tilgang til Fronter sin API
nøkkel blir tilgjengelig. Det ble derimot kodet inn litt testdata for Fronter på webapplikasjonen for å demonstrere
at systemet fungerer.
5.3
5.3.1
TimeEdit
Webscraping
For webscraping av TimeEdit og parsing av XML fra BibSys valgte vi det eksterne biblioteket JSoup fordi dette
biblioteket ble anbefalt av flere kilder på nettet [ 82 ] [ 83 ] . Det finnes noen andre alternativer på markedet for
java basert web scraping slik som jHarvest og å skrive sin egen implementasjon basert på standardbiblioteket
URLConnection i java. URLConnection ble ikke valgt da dette ville ha krevd en mye større kodejobb pga. få
innebygde funksjoner. jHarvest ble også valgt bort grunnet Jsoup sin gode dokumentasjon.
Web scrapingen i seg selv gikk bra, da vi fikk ut den informasjonen vi ønsket for å oppfylle minimumskravet for
løsningen, altså å vise dagens fag/timer for en bestemt studieretning. Det hadde derimot vært mye bedre om vi
kunne ha hentet ut informasjon om en hvilken som helst studieretning, men dette lot seg ikke gjennomføre da
Høgskolen i Ålesund
Hovedprosjekt
Side 80
TimeEdit har egne id’er for alle kurs og fag. Vi har ikke tilgang til noen oversikt over hva disse id’ene tilsvarer,
og det ville derfor vært altfor tidkrevende å bygge seg opp en oversikt over dette manuelt.
5.3.2
Løsning
Den løsningen som ble utviklet for TimeEdit fungerer etter de kravene som ble satt i begynnelsen av prosjektet,
men den har noen grunnleggende problemer relatert til holdbarhet.
Forandringer i nettsidestruktur
Da løsningen vår er basert på web scraping, vil enhver lille forandring på nettsidene som blir scrapet destabilisere,
eller i verste fall ødelegge løsningen vi har utviklet.
Oppdatering av TimeEdit
Det har blitt varslet fra IT avdelingen ved Høgskolen i Ålesund om at det vil bli rullet ut en ny utgave av
TimeEdit innenfor forutseelig fremtid. Denne utgaven vil være av utgave 3.x, og sammenlignet med dagens
utgave(1.4.8) vil denne være drastisk forskjellig i utseende og funksjon. Det har også blitt hintet om at API’en
til denne versjonen vil være så forskjellig fra dagens utgave at selv om vi hadde fått tilgang til API’en slik vi
ønsket, så ville sansynligvis ikke løsningen vår fungert etter oppdateringen.
5.4
5.4.1
BibSys
Implementasjon av API
Implementasjonen av BibSys i prosjektet gikk hovedsakelig greit, takket være god hjelp fra brukerstøtten til
BibSys. Det eneste problemet vi møtte på var at det kom ut en oppdatering på SRU tjenesten under utviklingen
som gjorde at den løsningen vi hadde laget ikke fungerte lengre. Det som også da skapte problemer var at etter
de hadde oppdatert til den nye versjonen av API’en, så lå ikke lengre dokumentasjonen ute. Dette antar vi
er fordi dokumentasjonen oppdateres. Dette skaper noe tvil om at BibSys vil støtte de funksjonene vi har
implementert i fremtiden. Når det er sagt så har vi blitt informert fra brukerstøtten til BibSys at de vil støtte
dagens SRU baserte API i “flere år”. Alternativet til å bruke den SRU baserte API’en til BibSys ville være å
innhente dataene fra en annen tjeneste som har implementert den slik som ask.bibsys.no, men dette ville bare
intrudusert en ekstra kilde til feil, så det ble valgt bort.
Oppdateringen av SRU hadde også et annet resultat for løsningen vår, og det var at vi ikke lengre kunne
innhente utlånsstatus for bøkene vi søkte på. Dette kan mest sansynlig løses i fremtiden når dokumentasjonen
til oppdateringen er tilgjengelig.
5.4.2
Valg av struktur
Når vi skulle starte å implementere BibSys i systemet vårt, så vi for oss to mulige måter å gjennomføre det på.
• La mobilapplikasjonen ta seg av allt arbeidet
• La serveren ta seg av arbeidet med å innhente og parse data, mens mobilapplikasjonen kun presenterer
resultatet.
Begge disse metodene har positive aspekter. Om vi hadde valgt å la mobilapplikasjonen ta seg av alt arbeidet
med innhenting av data og parsing ville dette potensielt taksert serveren mindre, noe som igjen gjør at den
Høgskolen i Ålesund
Hovedprosjekt
Side 81
kan betjene flere brukere samtidig. I tillegg ville ikke denne funksjonen da vært avhengig av at serveren var
oppe, og øker dermed forventet tilgjengelighet for tjenesten. På den andre siden vil en implementasjon på
serversiden muliggjøre enklere oppdateringer uten å måtte rulle ut oppdateringer til alle brukere. I tillegg er en
serverside implementasjon av søketjenesten den måten resten av funksjonene er implementert på, og vil derfor
bidra til at systemet har en mer uniform måte å løse ting på. Dette er en fordel for fremtidig utvikling, som
ikke nødvendigvis vil bli utført av de samme menneskene.
5.5
Mobilapplikasjonen
I løpet av prosjektet har store deler av mobilapplikasjonen blitt skrevet om og forenklet. Dette har gjort det
lettere å oppdage og fikse bugs og og har gjort applikasjonen mye mer stabil enn den tidligere versjonen. Den
resterende ustabiliteten ligger i innlastingen av data og parsing av JSON under forhold med ustabil nettilgang,
men har blitt håndtert med exceptions så de ikke får selve applikasjonen til å krasje. Vi fikk ikke utført en stor
brukertest av applikasjonen slik vi ønsket. Men selv med forbedringene er koden fortsatt relativt vanskelig å
sette seg inn i og det kan bli vanskelig for andre en prosjektmedlemmene å vedlikeholde koden.
5.5.1
Android app versus webapplikasjon i nettleser
Når prosjektet hadde startet, og det var avgjort at mobilapplikasjonen skulle utvikles var det to grunnleggende
forskjellige måter den kunne implementeres på. Den ene løsningen er å lage en android applikasjon basert på
aktiviteter og tjenester slik det har blitt løst i dag. Alternativet er å lage en HTML5 nettside beregnet på
telefoner som vises i en enkel kontainer aktivitet. Dette vil si at android applikasjonen sin eneste oppgave er å
vise nettsiden.
Det å utvikle en applikasjon basert på HTML5 har den fordelen at det er veldig enkelt å gjenbruke systemet
i andre operativsystemer, slik som IOS og Windows Phone 8, da applikasjonene bare trenger å vise nettsiden.
Ulempen med å utvikle en HTML5 applikasjon er at støtten for HTML5 ikke er like god på alle enheter ennå,
og det er et problem med manglende biblioteker i enkelte nettlesere. [ 84 ]
Resultatet ble som sagt å lage en full applikasjon basert på aktiviteter og tjenester. Dette ble valgt da prosjektet som skulle videreutvikles allerede var basert på denne løsningen. Det originale valget av denne løsningen
stammer fra våren 2012 da utviklingen av applikasjonen var en del av skolefaget ID303911 - Mobile og distribuerte applikasjoner. Her ble valget gjort basert på at Android applikasjoner blir skrevet i Java, som er
programmeringsspråket brukt i andre relaterte programmeringsfag.
5.6
5.6.1
Webapplikasjonen
Systemarkitekturen
Systemarkitekturen er løst basert på model view controller modellen (se delen om model view controller i
teoretisk grunnlag). Selv om vi i utgangspunktet basert oss på mvc modellen ble den endelige arkitekturen litt
annerledes. I vår arkitektur snakker nettsiden med kontrollerene som igjen snakker med “service”ene som igjen
snakker med databasen i en lag basert struktur. Dette avviker fra MVC der for eksempel view delen kan snakke
rett med modellen for å hente data.
Høgskolen i Ålesund
Hovedprosjekt
Side 82
Figur 5.1: Viser samhandlingen mellom de forskjellige delene i webapplikasjonen
5.6.2
ER modellen
ER modellen gjennomgikk mange forandringer før vi fikk en modell som “funket”. Modellen var ustabil lenge
og vi støtte stadig på problemer som gjorde at vi prøvde nye måter å sette opp modellen på. Til slutt bestemte
vi oss på å lage en begrenset dynamisk system, det vil si vi lagde modellen med en begrenset og statisk
trestruktur. Med dette la vi “eieransvaret” for relasjonene til hovedlagene (fremsiden, studier, kurs) og under
disse, fragmentene som igjen eide de nederste objektene (video, dokumenter, artikler osv).
Vi traff på “orphan” problematikken i relasjonsdatabasen. Dette problemet fremkommer i many to many
tilkoblinger og oppstår når et av objektene med relasjoner blir slettet. Problemstillingen er hva som skal skje
med det gjenværende objektet. For eksempel: et fragment er knyttet til en video. En administrator sletter
videoen. Nå er videoen slettet, men fragmentet har fortsatt en relasjon til videoen selv om den ikke eksisterer
lenger. Dette gjorde at applikasjonen fikk feilmelding hver gang den prøvde å laste inn objektet. Vi fikset dette
med å legge til “(cascade = CascadeType.ALL)” til “@ManyToMany” deklarasjonen i fragmentet for video feltet
slik at det ble slik.
1
@ManyToMany( c a s c a d e = CascadeType . ALL)
L i s t <Video> v i d e o s ;
Dette gjør at fragmentet i dette tilfelle blir “eieren” av relasjonen.
Vi hadde også problemer med “infinite loops” i JSON tjenestene. For eksempel et fragment inneholder en
referanse til en video som inneholder en referanse til fragmentet som inneholder en referanse til video osv. Dette
fikset vi med å bruke “@XmlTransient” taggen i get metodene for referansen til en av de to objektene med
konflikter, i dette tilfellet video.
2
4
@XmlTransient
p u b l i c L i s t <Fragment> getFragments ( ) {
return fragments ;
}
Dette gjorde at når JSONen for fragmentet blir skrevet inneholder fragmentet en referanse til video, men video
viser ikke sin referanse til fragmentet, dette løste problemet.
I løpet av dette prosjektet lærte vi mye om relasjonsdatabaser og problematikken rundt disse, spesielt om
man prøver å lage et komplekst fleksibelt system.
5.6.3
Serversikkerhet
Da prosjektet startet ble det satt opp en webserver som skulle bli brukt for å publisere webserveren under
utviklingen. Denne serveren ble ikke høyt prioritert, og hadde derfor kun grunnleggende sikkerhet.
Høgskolen i Ålesund
Hovedprosjekt
Side 83
I perioden 30. mars til 2. april(påske) klarte en hacker gruppe å bryte seg inn på denne serveren. Dette ble
oppdaget den 3. april. Gruppen hadde klart å bryte seg inn over SSH ved å gjette seg frem til riktig passord.
Dette ble mest sansynlig gjort ved å automatisk teste vanlige passord fra den engelske ordlisten. Hackerene
la igjen navnet(Cracker clan) og IP adressen sin(82.137.13.148) i loggen, men disse sporene ledet ikke til noe
nyttig informasjon.
Hva hackerene gjorde på serveren kom ikke helt klart frem, så det ble bestemt at serveren skulle slettes fra
clusteret, og det skulle opprettes en ny.
Den nye serveren er satt opp med passord som ikke finnes i noen ordliste, og man er begrenset til 3 forsøk og
begrenset tid for å logge inn. Dette gjør at datakraften og tiden nødvendig for å bryte seg inn er så høy at det
sansynligvis ikke er verdt bryet. Selv om hackerene klarer å gjette 1012 ganger i sekundet, vil det fremdeles ta
ca. 1,6 år før de finner rett passord. [ 85 ]
5.6.4
Manglende eller ikke-implementert mulig funksjonalitet
Denne delen handler om funksjonalitet i både Web- og mobil-applikasjon som ikke er implementert men enten
burde eller kunne ha vært inkludert. Av disse to er manglene viktigst, mao. funksjonalitet som ikke er ferdigstilt
og må anses som mangler.
I web-applikasjonen ble et system for oppretting og håndtering studieløp implementert, men en mangel kan
være at studieløpet ikke deles opp i årsklasser.
Felles for web-og mobil-applikasjon eksisterer det ikke noe reelt brukersystem. For å få full nytte av annen
eksisterende funksjonalitet som f.eks Quiz eller Fronter-delen er et slikt system nødvendig.
En av de opplagte funksjonen som vi ikke rakk å implementere er styring av rekkefølgen av fragmentene på
mobilapplikasjonen. Fragmentene er i denne versjonen av systemet vist i rekkefølgen til fragmentets interne ID.
Vi ønsket å lage enten et “numerisk” rekkefølge system der brukeren manuelt legger inn rekkefølgen, eller et
automatisk system der fragmentene følger en statisk prioritetsliste.
5.6.5
Gjenværende bugs
• Hver gang webapplikasjonen blir publisert på nytt slettes alle fragmentene på fremsiden. Å fikse dette har
ganske lav prioritet, fordi om system faktisk blir satt i bruk vil man ikke å publisere webapplikasjonen på
nytt ofte.
• Bug med lagring av tema, oppgaver, obligatoriske innleveringer og eksamener på fagnivået. Å fikse dette
har lav prioritet siden informasjonen godt kan lagres som en artikkel. Det burde gjøres en vurdering om
disse feltene er nødvendige, eller om artikkelfunksjonen er god nok til å erstatte de helt.
5.6.6
Fremtid
Ikonene for alle fragmentene med unntak av TimeEdit, Fronter og BibSys er hentet fra Internett og kan være
rettighetsbeskyttet. Denne grafikken burde byttes ut før mobilapplikasjonen allmenn distribueres. En grafiker
burde leies inn for å redesigne utseende til mobilapplikasjonen og lage nye ikoner.
Høgskolen i Ålesund
Hovedprosjekt
6
Side 84
KONKLUSJON
Målene med prosjektet var:
• Å fullføre utviklingen av den eksisterende e-læringsapplikasjonen
• Å gjøre den nye versjonen av e-læringsapplikasjonen mer fleksibel
• Å integrere utvalgte funksjoner fra de eksterne systemene TimeEdit, Fronter og BibSys i e-læringsapplikasjonen...
Å gjøre det eksisterende systemet mer stabilt og fleksibelt gikk veldig bra siden prosjektmedlemmene hadde
mye erfaring med plattformene, teknologiene og den opprinnelige kildekoden fra før. E-læringsapplikasjonen
har ikke lengre noen store mangler og den kan administre innholdet på en mye bedre og mer elegant måte enn
tidligere. Dette er mye takket være det nye fragmentsystemet, hvor man kan legge til og fjerne funksjoner og
innhold fra alle lag i applikasjonen på en fleksibel måte. Administrasjonsgrensesnittet i webapplikasjonen har
også blitt forbedret for å lettere kunne legge inn data. Systemet er også mye mer robust etter mye feilsøking
og utbedring av koden.
Integrasjonen av de tre eksterne datasystemene Fronter, BibSys og TimeEdit gikk ikke helt problemfritt for seg,
men vi er fornøyde med løsningen vi kom frem til for BibSys og TimeEdit da de begge leverer de funksjonene
vi ønsket. For Fronter er arkitekturen i systemet klar til å hente inn data fra Fronter. Dette gjør at ved en
eventuell videreutvikling av systemet, vil det å legge til ferdig Fronter funksjonalitet være en enkel oppgave.
I løpet av prosjektet lærte vi mye om hvordan et prosjekt fungerer og hvordan det er å jobbe sammen. I
tillegg fikk vi erfaring om korrespondanse med bedriftsmarkedet når vi skulle skaffe dokumentasjon og tilgang
til de systemene vi skulle integrere. Vi lærte også mye om relasjonsdatabaser og hvor vanskelig de er å håndtere
i et stort og komplisert system.
Systemet er godt nok til å tas i bruk som supplement til de eksisterende løsningene, men med mer utvikling
kan systemet erstatte konkurrentene.
Til tross for at vi måtte bryte med den originale tidsplanen for prosjektet, ble problemstillingene løst, og
målene til prosjektet oppfylt på en god måte. Derfor kan prosjektet regnes som en suksess
Høgskolen i Ålesund
Hovedprosjekt
7
Side 85
REFERANSER
[ 1 ] http://developer.android.com/guide/components/fragments.html
[ 2 ] http://www.techopedia.com/definition/24864/software-bug
- 29.05.2013
- 19.05.13
[ 3 ] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.123.1085
[ 4 ] http://gitref.org/basic/
- 28.05.2013
[ 5 ] http://tools.ietf.org/html/rfc2616
[ 6 ] Mike
Jasnowski, Java, XML, and Web Services Bible (Hungry Minds Inc, 2002)
[ 7 ] http://www.vmware.com/products/datacenter-virtualization/vsphere/overview.html
[ 8 ] Naveed
Yaqub, Comparison of Virtualization Performance: VMWare and KVM(Universitetet i Oslo, 2012), 23
Lervik og Vegard B. Havdal, Programmering i Java 4. utgave (Gyldendal Akademisk, 2009)
[ 10 ] http://whatis.techtarget.com/definition/seamless-interface - 28.05.2013
[ 11 ] http://en.wikipedia.org/wiki/Web_scraping
[ 12 ] Tarjei Romtveit, Load-balancing by applying a bayesian learning automata (BLA) scheme in a non-stationary web-crawler
network(Universitetet i Agder, 2010), 14
[ 13 ] http://www.hials.no/nor/content/view/full/66409/language/nor-NO- 28.05.2013
[ 14 ] http://en.wikipedia.org/wiki/System_integration - 22.05.2013
[ 15 ] http://en.wikipedia.org/wiki/Cohesion_(computer_science) - 25.05.2013
[ 16 ] http://en.wikipedia.org/wiki/Data_scraping - 28.05.2013
[ 17 ] http://onlinejournalismblog.com/2010/07/07/an-introduction-to-data-scraping-with-scraperwiki/ - 28.05.2013
[ 18 ] http://snl.no/syntaktisk - 28.05.2013
[ 19 ] https://en.wikipedia.org/wiki/Application_programming_interface - 27.05.2013
[ 20 ] http://money.howstuffworks.com/business-communications/how-to-leverage-an-api-for-conferencing1.htm - 27.05.2013
[ 21 ] Ed Lecky-Thompson, Heow Eide-Goodman, Steven D. Nowicki og Alec Cove, Professional PHP5 (Wiley Publishing, Inc , 2005)
[ 22 ] Frank Trethan Johnsen, Web services and service discovery(Kjeller : Norwegian Defence Research Establishment, 2008), 9
[ 23 ] Mike Jasnowski, Java, XML, and Web Services Bible(Hungry Minds Inc, 2002)
[ 24 ] Java Web Services - Up and running, Forfatter: Martin Kalin, Forlag: O’Reilly Media, Inc, År 2009
[ 25 ] Kim Topley, Java Web Services in a Nutshell (O Reilly, 2003)
[ 26 ] Java Web Services - Up and running, Forfatter: Martin Kalin, Forlag: O’Reilly Media, Inc, År 2009
[ 27 ] RESTful Java with JAX-RS, Forfatter: Bill Burke. O’Reilly Media, Inc, År 2003
[ 28 ] Java Web Services - Up and running, Forfatter: Martin Kalin, Forlag: O’Reilly Media, Inc, År 2009
[ 29 ] CouchDB - The Definitive Guide, Forfatter: J.Chris Anderson, Jan Lehnardt, Noah Slater, Forlag: O’Reilly Media, Inc, År:
2010)
[ 30 ] http://www.json.org/ - 6.05.2013
[ 31 ] http://en.wikipedia.org/wiki/Json - 6.05.2013
[ 32 ] http://en.wikipedia.org/wiki/XML 30.05.2013
[ 33 ] http://www.w3schools.com/xml/xml_whatis.asp - 30.05.2013
[ 34 ] http://en.wikipedia.org/wiki/Ajax_(programming) - 15.05.2013
[ 35 ] Steve Souders, Even Faster Web Sites(O‘Reilly Media Inc, 2009), 5
[ 36 ] http://www.computerweekly.com/feature/Write-once-run-anywhere - 20.05.13
[ 37 ] http://www.oracle.com/technetwork/java/intro-141325.html - 20.05.13
[ 38 ] http://www.java.com/en/about/ - 28.05.2013
[ 39 ] Regular Expression’s Cookbook, Forfatter: Jan Goyvaerts, Steven Levithan, Forlag: O’Reilly Media, Inc, År: 2009)
[ 40 ] Andrew Lee Rubinger og Bill Burke, Enterprise JavaBeans 3.1 6th Edition 2010
[ 41 ] http://www.oracle.com/technetwork/java/javaee/overview-140548.html - 15.05.2013
[ 42 ] http://www.primefaces.org - 06.05.2013
[ 43 ] RESTful Java with JAX-RS, Bill Burke, O’Reilly Media, inc, 2009
[ 44 ] RESTful Java with JAX-RS, Bill Burke, O’Reilly Media, inc, 2009
[ 45 ] http://jsoup.org/ - 06.05.2013
[ 46 ] http://jsoup.org/cookbook/ - 28.03.2013
[ 47 ] http://developer.android.com/design/patterns/navigation-drawer.html - 28.05.2013
[ 48 ] http://en.wikipedia.org/wiki/NetBeans - 29.05.2013
[ 49 ] http://en.wikipedia.org/wiki/GlassFish
[ 50 ] Git Pro, Forfatter: Scott Chacon , Forlag Apress, ISBN-10 1430218339
[ 51 ] http://en.wikipedia.org/wiki/Git_(software) - 28.05.13
[ 9 ] Else
Høgskolen i Ålesund
Hovedprosjekt
Side 86
[ 52 ] https://netbeans.org/features/index.html
- 30.05.2013
- 30.04.2013 13:29
[ 53 ] http://developer.android.com/about/index.html
[ 54 ] http://www.android.com/about/
- 28.05.2013
[ 55 ] http://developer.android.com/about/index.html
- 28.05.2013
- 28.05.2013
- 28.05.2013
[ 58 ] http://developer.android.com/guide/components/services.html - 28.03.2013
[ 59 ] http://developer.android.com/guide/components/fragments.html
[ 60 ] http://searchcloudcomputing.techtarget.com/definition/Software-as-a-Service - 06.05.2013
[ 61 ] http://timeedit.hials.no/ - 18.05.2013
[ 62 ] http://www.bibsys.no/norsk/om_oss/index.php
[ 63 ] http://www.nbandroid.org/
[ 64 ] http://github.com/Krisberg/HIALS-Prosjektrapport-mal-i-LaTeX
[ 65 ] http://www.samsung.com/no/consumer/mobile/mobilephones/smartphones/GT-I9250TSANEE
[ 66 ] http://www.asus.com/Tablets_Mobile/Nexus_7/#specifications - 22.05.2013
[ 67 ] Vedlegg 2, Forprosjektrapport Hovedprosjekt
[ 68 ] Vedlegg 2, Forprosjektrapport Hovedprosjekt
[ 69 ] https://timeedit.hials.no/WebReservations/WebObjects/
[ 70 ] http://timeedit.hials.no/4DACTION/WebShowSearch/1/1-0?
[ 71 ] Matthew A.Russel, O’Reilly Media, Inc, 2011, Mining the Social Web
[ 72 ] http://www.lovdata.no/all/tl-19610512-002-001.html#1
[ 73 ] http://timeedit.hials.no/robots.txt
[ 74 ] http://timeedit.hials.no/4DACTION/WebShowSearch/1/1-0?wv_type=5&wv_search=&wv_startWeek=1301&wv_stopWeek=1318&wv_
first=0
[ 75 ] http://www.hials.no
[ 76 ] http://jsoup.org
[ 77 ] http://home.ccil.org/~cowan/XML/tagsoup/
[ 78 ] http://htmlunit.sourceforge.net/
[ 79 ] http://web-harvest.sourceforge.net/
[ 80 ] http://sing.ei.uvigo.es/jarvest/examples.html
[ 81 ] http://ask.bibsys.no/ask/action/stdsearch - 21.05.2013
[ 82 ] http://stackoverflow.com/questions/3202305/web-scraping-with-java - 18.05.2013
[ 83 ] http://stackoverflow.com/questions/6446356/web-scraping-java-beginner - 18.05.2013
[ 84 ] http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5) - 28.05.2013
[ 85 ] http://daleswanson.org/things/password.htm - 06.05.2013
[ 56 ] http://www.passion4teq.com/articles/ios-android-development-comparison-2/
[ 57 ] http://developer.android.com/guide/components/activities.html
Høgskolen i Ålesund
Hovedprosjekt
Side 87
Figurliste
1.1
Diagram som viser forholdet mellom mobilapplikasjonen, webapplikasjonen og Fronter, BibSys
og TimeEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
Model View Controller-modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Et eksempel på hvordan man kan bruke JSoup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1
3.2
Bilder av serveren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Dette Gantt diagrammet viser når de forskjellige deloppgavene i prosjektet ble utført . . . . . . . 23
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
4.30
4.31
4.32
4.33
4.34
Oversikt over hele systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - fremsiden . . . . . . . . . . . . . . . . .
Viser objektene på hvert lag i mobilapplikasjonen og flyten mellom lagene . .
Viser flyten i det gamle systemet . . . . . . . . . . . . . . . . . . . . . . . . .
Forklaring for brukergrensesnittet . . . . . . . . . . . . . . . . . . . . . . . . .
Viser flyten mellom webapplikasjonen og mobilapplikasjonen . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - artikkel-funksjonen . . . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - studie/fag-funksjonen . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - dokument-funksjonen . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - video-funksjonen . . . . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - quiz-funksjonen . . . . . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - quiz-funksjonen . . . . . . . . . . . . . .
Oversikt over webapplikasjonen . . . . . . . . . . . . . . . . . . . . . . . . . .
JDBC innstillinger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viser hvor file realm er . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Skjermbilde av webapplikasjonen - Viser framside-redigeringssiden . . . . . .
Skjermbilde av webapplikasjonen - Viser listen over studier . . . . . . . . . .
Skjermbilde av webapplikasjonen - Studie-redigeringssiden . . . . . . . . . . .
Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Studiebeskrivelse
Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Valg av fag . . .
Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Fragmenter . . .
Skjermbilde av webapplikasjonen - Fag-redigeringssiden . . . . . . . . . . . .
Skjermbilde av webapplikasjonen - Dokument-redigeringssiden . . . . . . . . .
Skjermbilde av webapplikasjonen - Quiz-redigeringssiden . . . . . . . . . . . .
Skjermbilde av webapplikasjonen - Quiz-redigeringssiden - Spørsmål . . . . .
Skjermbilde av webapplikasjonen - Video-redigeringssiden . . . . . . . . . . .
Skjermbilde av webapplikasjonen - Artikkel-redigeringssiden . . . . . . . . . .
Skjermbilde av webapplikasjonen - Bruker-redigeringssiden . . . . . . . . . . .
Skjermbilde av webapplikasjonen - Dokumentasjon . . . . . . . . . . . . . . .
Entity Relationship diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Et skjermbilde av TimeEdtit’s nettside for søk på klasser . . . . . . . . . . .
En vanlig timeplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Treff-element som vises etter søk i TimeEdit som presentert i en nettleser. . .
TimeEdits fritekstsøk for fag og klasse . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
24
25
26
27
29
30
31
32
33
34
35
36
37
39
39
41
42
42
43
43
44
44
45
46
47
47
48
49
50
51
55
57
57
61
Høgskolen i Ålesund
Hovedprosjekt
Side 88
4.35
4.36
4.37
4.38
4.39
4.40
4.41
4.42
4.43
Diagram over Klassen TimeEditService med indre klasser. . . . . . . . . . . . . . . . . . . . . .
Demonstrerer Web-servicene som registrert i NetBeans . . . . . . . . . . . . . . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - TimeEdit-funksjonen . . . . . . . . . . . . . . . . . . . . .
JSON fra REST-tjenesten til fronter - eksempeldata . . . . . . . . . . . . . . . . . . . . . . . .
Skjermbilder av mobilapplikasjonen - Fronter-funksjonen . . . . . . . . . . . . . . . . . . . . . .
Dataflyt ved en spørring mot BibSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relevant del av XML responsen fra BibSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data før og etter parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Skjermbilde av mobilapplikasjonen - Her vises resultatet etter et søk på bøker som matchet tittelen
“ibsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
62
68
72
73
74
76
77
77
5.1
Viser samhandlingen mellom de forskjellige delene i webapplikasjonen . . . . . . . . . . . . . . . 82
. 78
Høgskolen i Ålesund
Hovedprosjekt
Side 89
Tabelliste
2.1
Sammenligner regex på Java og Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1
4.2
4.3
4.4
4.5
4.6
Viser de forskjellige quiz typene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viser de tilgjengelige REST tjenestene . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabell over parametere i URLen separert som navn og verdi med tilhørende funksjon
Base-URI pluss sti som defineres i web-applikasjonen. . . . . . . . . . . . . . . . . .
Tabell over ikke-absolutte URIer, tilknyttet funksjon med JAX-RS og en beskrivelse.
Beskrivelse av parametere i søke-URLen til BibSys . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
52
59
67
67
75
Høgskolen i Ålesund
Hovedprosjekt
Side 90
Kodesnutter
2.1
2.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
A.1
7.1
(JSON-formatert data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Eksempel på REST-tjenester med JAX-RS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utdraget av HTML kildekoden til TimeEdit ovenfor viser en JavaScript-funksjon og en input-tag.
Utdrag av kildekoden til TimeEdit’s nettside som vist i figur 1.32 . . . . . . . . . . . . . . . . . .
En URL generert når man søker etter en timeplan for ett spesifikt fag . . . . . . . . . . . . . . .
Kodesnipp fra klassen TimeEditService, som er grovt kortet ned. . . . . . . . . . . . . . . . . . .
Et utdrag av en metode i TimeEditService som viser hvordan Jsoup benyttes for å hente ut ett
enkelt dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utdrag fra klassen TimeEditService i web-applikasjonen . . . . . . . . . . . . . . . . . . . . . . .
Utdrag fra klassen TimeEditService fra no.hials.muldvarpweb.v2 . . . . . . . . . . . . . . . . . .
Utdrag fra HTML-kildekoden til nettsiden i figur 4.32 . . . . . . . . . . . . . . . . . . . . . . . .
Utdrag fra en JAX-RS annotert REST resource metode i klassen TimeEditService . . . . . . . .
Nytte-funksjon i klassen TimeEditService som bruker regulære uttrykk for å hente ut objektkoder
Utdrag fra kildekoden i figur 4.32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utdrag fra klassen TimeEditService som viser en JAX-RS annotert funksjon. . . . . . . . . . . .
Eksempel på en statisk definert URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eksempel på en URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selve strengen inne i en @Path variabel med regex . . . . . . . . . . . . . . . . . . . . . . . . . .
Fungerende eksempel på en URI i APIet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Oppsett av Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forkortet JSON- av en fullt formatert timeplan som hentet fra TimeEdit og behandlet i webapplikasjonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
To funksjoner fra Domain-klassen TimeEditSchedule i mobil-applikasjonen . . . . . . . . . . . . .
URL-genereringsmetoder fra klassen TimeEditService, som er grovt kortet ned. . . . . . . . . . .
Prosjektlinker
Prosjektets nettside: http://eapp.uials.no/
Android applikasjon - GitHub: https://github.com/mikael2/Muldvarp/
Java EE applikasjon - GitHub: https://github.com/mikael2/MuldvarpWeb/
13
16
56
58
58
61
62
63
63
63
64
64
65
68
68
68
68
69
69
69
71
92
Høgskolen i Ålesund
Hovedprosjekt
A
VEDLEGG
Vedlegg 1: Prosjektsøknad
Vedlegg 2: Forprosjektrapport
Vedlegg 3: CD med
• kildekoden til mobilapplikasjonen og webapplikasjonen
• prosjektplakat i pdf format
• prosjektrapporten i pdf og latex format
Vedlegg 4: Kodesnutt fra TimeEditService
Side 91
Høgskolen i Ålesund
Hovedprosjekt
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
40
42
44
46
48
50
Side 92
p r i v a t e f i n a l s t a t i c S t r i n g TIMEEDIT_HIALS_URL = " h t t p : / / t i m e e d i t . h i a l s . no /4DACTION/
WebShowSearch/1/1 −0? " ;
p r i v a t e f i n a l s t a t i c S t r i n g TIMEDIT_PARAM_SEARCH_TYPE = "wv_type"
p r i v a t e f i n a l s t a t i c S t r i n g TIMEDIT_PARAM_SEARCH = " wv_search " ; // S e a r c h v a r i a b l e . Can be
used with c o u r s e c o d e s o r names .
p r i v a t e f i n a l s t a t i c S t r i n g TIMEDIT_PARAM_FORMAT = " wv_text " ; // Page w i l l not r e t u r n
a n y t h i n g u n l e s s t h i s i s added f i r s t i n t h e s e t o f v a r i a b l e s .
//The " o b j e c t " i s t h e v a r i a b l e which d e f i n e s t h e c o u r s e o r name . I t i s an ID u n i q u e t o t h e
T i m e e d i t system
p r i v a t e f i n a l s t a t i c S t r i n g TIMEEDIT_PARAM_OBJECT = "wv_obj" ;
p r i v a t e f i n a l s t a t i c S t r i n g TIMEEDIT_PARAM_WEEKSTART = " wv_startWeek " ;
p r i v a t e f i n a l s t a t i c S t r i n g TIMEEDIT_PARAM_WEEKSTOP = "wv_stopWeek" ;
// S t a t i c v a r i a b l e t y p e s
p r i v a t e f i n a l s t a t i c S t r i n g TIMEEDIT_VALUE_FORMAT_TEXT = " t e x t " ;
/∗ ∗
∗ This method g e n e r a t e s an TimeEdit URL based on a S t r i n g Array o f
∗ o b j e c t C o d e s , a S t r i n g r e p r e s e n t a t i o n o f a s t a r t i n g and e n d i n g week .
∗
∗ @param o b j e c t C o d e s
∗ @param startWeek
∗ @param stopWeek
∗ @return
∗/
p u b l i c S t r i n g getURL ( S t r i n g [ ] o b j e c t C o d e s , S t r i n g startWeek , S t r i n g stopWeek ) {
S t r i n g r e t V a l = TIMEEDIT_HIALS_URL
+ generateObjectCodeURL ( o b j e c t C o d e s )
+ TIMEDIT_PARAM_FORMAT + "=" + TIMEEDIT_VALUE_FORMAT_TEXT;
i f ( startWeek != n u l l && ! startWeek . isEmpty ( ) ) {
r e t V a l += "&" + TIMEEDIT_PARAM_WEEKSTART + "=" + startWeek ;
}
i f ( stopWeek != n u l l && ! stopWeek . isEmpty ( ) ) {
r e t V a l += "&" + TIMEEDIT_PARAM_WEEKSTOP + "=" + stopWeek ;
}
return retVal ;
}
/∗ ∗
∗ This method c o n c a t e n a t e s t h e TIMEEDIT_PARAM_OBJECT p a r a m e t e r p l u s a S t r i n g a r r a y o f
∗ o b j e c t C o d e s i n t o one s t r i n g .
∗ @param o b j e c t C o d e s
∗ @return
∗/
p r i v a t e S t r i n g generateObjectCodeURL ( S t r i n g [ ] o b j e c t C o d e s ) {
S t r i n g retVal = "" ;
f o r ( i n t i = 0 ; i < o b j e c t C o d e s . l e n g t h ; i ++) {
i f ( i >= MAX_OBJECT_REQUESTS) {
break ;
} else {
r e t V a l += TIMEEDIT_PARAM_OBJECT + I n t e g e r . t o S t r i n g ( i + 1 ) + "=" + o b j e c t C o d e s [
i ] + "&" ;
}
}
return retVal ;
}
Kodesnutt A.1: URL-genereringsmetoder fra klassen TimeEditService, som er grovt kortet ned.