Prosessrapport. Hovedprosjekt ved Høgskolen i Oslo. Våren 2008

Transkript

1 Prosessrapport Hovedprosjekt ved Høgskolen i Oslo Våren

2 1. Sammendrag A-Pressen Interaktiv (heretter referert til som API) ønsket seg et system for kryssreferanser av metainformasjon. Systemet henter ut relatert metadata fra databasen basert på analyse av en artikkel som skrives. Det kunne for eksempel ha vært å hente ut ekstra informasjon om navn som var nevnt i artikkelen. Denne informasjonen ville automatisk bli generert, og ville videre bli brukt til å berike artikkelen (f.eks. utdypende informasjon om personer som er nevnt, og linker til andre artikler skrevet om samme person/tema osv.). Dette gjør at avisenes artikler vil inneholde ekstra informasjon som utdyper innholdet uten at det vil været noe ekstra jobb for den som skrev selve teksten. Oppgaven vår styres inn mot politikk og i første omgang Stortinget. Vi løste oppgaven på en slik måte at det er mulig å kunne anvende det på andre temaer. 2. Forord Denne rapporten er en del av hovedprosjektet Metagen ved Høgskolen i Oslo vår Rapporten er beregnet for sensor, veiledere og andre som måtte være interessert i hvordan prosjektarbeidet har vært og hvordan vi har kommet frem til sluttproduktet. Prosessrapporten beskriver prosessen vi har vært igjennom med hovedprosjektet Metagen. Rapporten er utformet slik at den kan leses som et selvstendig dokument. Detaljert informasjon om selve produktet finnes i produktrapporten. 2

3 3. Innholdsfortegnelse 1. Sammendrag Forord Innholdsfortegnelse Innledning Om bedriften Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Metagen Søk i artikler Arkitekturdiagram av systemet Filstruktur Valg og vurdering av Verktøy Eclipse Eclipse 3.3 (med webtools) SubClipse M2clipse Tomcat Spring Framework Hibernate Ant/Maven Subversion Java SE MySQL 5 (InnoDB, UTF-8) Planlegging og metode Gruppe opprettelse og prosjektvalg Forprosjekt Kravspesifikasjonen Lære å bruke utviklingsverktøyene Fremdriftplan Utviklingsprosessen Samarbeid i gruppen SCRUM-FIGUR Utfordringer og løsninger Implementasjon/ MetaEx - Informasjonsinnsamling Teknologi og http kommunikasjon Nedlasting og uthenting Uthenting av informasjon fra nedlastede websider Sammendrag/avslutning Xml

4 8.5.1 XML parsing Spring/Hibernate og Databaseaksess Valg av database Datamodell Navn konvensjon-database Hibernate dataaksesslaget JavaBønner og assosiasjonene Mapping filer Konklusjon Innledning Dette Kapittelet inneholder bakgrunnsinformasjon for prosjektet. Først finnes en beskrivelse av oppdragiveren, fulgt av dagens situasjon. Deretter kommer det en kort beskrivelse av prosjektet, så kommer mål og rammebetingelser. 4.1 Om bedriften API drifter, utvikler og administrerer et nettverk av 56 nettaviser, 20 wapaviser og streamingtjenester for lokaltv og lokalradio. API er eid av A-pressen, men leverer også tjenester til medier utenfor konsernet. Selskapet har en sentral operativ rolle for utvikling av nye mediekanaler i A-pressen. API er organisert under divisjonen A-pressen Lokale Medier som er majoritetseier i 48 lokale og regionale aviser, over 20 lokalradiostasjoner og 8 lokale TV-stasjoner. Disse lokale mediene er organisert i mediehus. APIs rolle er å være et verktøy for flermedial utvikling og samhandling i mediehusene. 4.2 Dagens situasjon API har per i dag et lignende system for fotball (NIFS Norsk & Internasjonal Fotballstatistikk), men ikke for politikk. Systemer som dette er noe de ønsker mer av. Hensikten med MetaGen systemet var at det skulle være mulig for en som leser en artikkel å få tak i tilleggsinformasjon som er relatert til innholdet uten å gjøre ekstra arbeid. Dette bedrer 4

5 kvaliteten av artikkelen, samtidig vil leseren få ekstra informasjon som skal være relevant til innholdet. 4.3 Mål og rammebetingelser I dette kapitlet skal det gis et lite innblikk i systemets omfang, mål og rammebetingelser som er satt som krav og retningslinjer for utførelse av prosjektet. For mer detaljert beskrivelse av oppdragivers ønsker og krav, henvises det til kravspesifikasjonsrapporten Mål Systemet skal automatisk kunne generere relevant tilleggsinformasjon til artikler basert på innhold. Dette inkluderer både ekstra informasjon om temaer som tas opp, men også referanser til andre artikler som handler om lignende temaer. MetaGen skal kunne kommunisere med eksternt system, og gi ut info på forespørsel. Selve kommunikasjonen vil foregå i strukturert XML format. Selv om systemet til en viss grad skal klare å oppdatere seg selv når artikler legges ut, så trengs det et brukergrensesnitt for manuell overstyring og administrasjon av selve systemet. Målet var å ta for oss referanser til politikken, og vi valgte å konsentrere oss om informasjon knyttet til Stortinget. Vi var avhengig av å bygge opp en god metadatabase manuelt Rammebetingelser Oppdragsgiver var ganske åpen i henhold til hvordan vi ønsket å løse oppgaven. Ettersom API mest sannsynlig ville videreutvikle Metagen passet det best for bedriften at systemt ble utviklet i Java. API ønsket at det skulle brukes Spring Framework og ORM teknologi (Object Relation Mapping) for enkelt å kunne bytte ut databasen senere. Dermed ble Hibernate valgt siden det fungerer ganske bra sammen med Spring Framework. 5

6 5. Metagen Metagen er navnet på hovedprosjektet dette navnet ble til ved en brainstorming etter møte med API. Systemet er lagd for å berike artikkelen ved å generere metainformasjon (tileggsinformasjon) om innholdet. Ideen med Metagen kommer fra NIFS Norsk & Internasjonal Fotballstatistikk et system som API har for fotball.(se på 4.2 Dagens situasjon) Systemet skal tas i bruk når en bruker skal lese en vilkårlig artikkel i en av APIs nettaviser. Metagen skal supplere artikkelen med tilleggsinformasjon. Figur av MetaGen MetaGen sørger for supplere artikkelen med ekstra informasjon til artikkelen som vist til venstre i bildet. Brukeren vil aldri se MetaGen direkte, men vil isteden oppleve systemet gjennom nettsider hvor det implementeres. Dette er fordi MetaGen kun er et delsystem som kommuniserer med andre webtjenester, og ikke direkte med brukeren. Det kan oppstå to situasjoner når systemet kjører. Figurene nedenfor viser situasjonene. 6

7 Når Metagen finner artikkeliden i cache databasen skjer det følgende: 7

8 Når Metagen ikke finner artikkeliden i cache databasen skjer det følgende: 5.1 Søk i artikler For søk var det egentlig tenkt å bruke et Apache bibliotek for fulltekst søking som heter Lucene. Etter en del jobb med dette biblioteket ble det avgjort at det var for stort og avansert for søkene i oppgaven vår, og ble derfor byttet ut med Regular Expressions for å forenkle arbeidet. Metagen benytter seg av Regular Expression (som nevnt over) for å søke etter forskjellige søkeord i artikkelen. Det søkes først på fullt navn fra databasen, og hvis det får et treff, så søkes det også på bare etternavnet. Dette er gjort fordi personer som regel kun omtales en gang ved fullt navn, og kun ved etternavn i resten av artikkelen. Med denne måten kan systemet finne ut hvor mange ganger en person potensielt er omtalt i artikkelen selv om etternavn brukes. Kalkuleringen vil feile om det er to personer med samme etternavn i teksten, men dette er uvanlig, og det utgjør en minimal risiko. Ut i fra et slikt søk kan man 8

9 også finne ut rekkefølgen navnene blir nevnt i artikkelen ettersom Regex returnerer indexen i teksten hvor treffet forekommer. Dette er ekstra info som ikke MetaGen per i dag viser, men som likevel er der, og som er enkelt å trekke ut ved en senere anledning. Det er også mulighet for å relativt enkelt inkludere søk begge veier slik at man også kan få opp alle andre artikler personene i teksten også er omtalt i. For hver gang en ny artikkel søkes gjennom, så lagres id en i en database, og eventuelle treff lagres i en bidirectional relasjonstabell (kan søke begge veier). Neste gang artikkelen vises er relasjonene alt lagret i databasen, og nytt søk med regex er unødvendig. 5.2 Arkitekturdiagram av systemet Arkitekturdiagrammet viser relasjonene mellom de forskjellige delene i MetaGen og omgivelsen rundt MetaGen. Dette er en illustrasjon på hvordan de forskjelllige verktøyene er satt sammen og hvordan de kommuniserer med hverandre. Denne illustrasjonen utgjør systemet Metagen. 9

10 5.3 Filstruktur Webapplikasjoner bygges opp med en bestemt mappestruktur og pakkes i en war-fil. En war fil vil si en pakket fil som zip men med war ending til slutten av filen. Prosjektgruppen benyttet seg av maven plugin som sørget for at Eclipse bygget opp mappestrukturen vi trengte ved hjelp av plugingen. Se både Figur og Figur for illustrasjon av hvordan Eclipse med maven plugin strukturerte mappene til det endelige prosjektet. 6. Valg og vurdering av Verktøy I dette kapittel tar vi for oss de verktøyene som har blitt brukt under utviklingen av systemet. Deretter går vi nærmer inn og begrunner valg og vurdering av de teknologiske verktøyene. 6.1 Eclipse Eclipse er et rammeverk for utvikling av Java programmer. Et utviklingsverktøy som har en del nyttige plugings. Eclipse er kompatibel med de fleste platformene. Det ble brukt ulike pluging funksjoner som M2clipse, subclipse, tomcat. Hensikten med Eclipse er å lage et lett miljø for å utvikle programvarer. Eclipse har prosjekthåndtering, støtter versjonskontroller og har integrerte debuggin Eclipse 3.3 (med webtools) Gruppen bestemte seg kjapt for å bruke Eclipse som et utviklingsplattform. Eclipse sine gode funksjonalitet gjør det mulig å samle ulike teknologier inn i ett brukergrensesnitt. Ved å være en plug in basert arkitektur gjør den det enkelt å utvide eller endre en hvilken som helst funksjonalitet. Disse plugins - verktøyene gjør vi også bruk for i prosjektet SubClipse SubClipse er en pluging som muliggjør Subversion tilkobling i Eclipse, noe som ikke er standard. Vi kan si at det er en ekstramodul i Eclipse, som gjør at vi kan lett synkronisere koden mot subversion serveren uten å starte eksterne programmer. Dette viste seg å være meget lønnsomt da vi alle kunne jobbe med systemet og hver for oss og oppdater underveis. 10

11 6.1.3 M2clipse M2clipse er en pluging som gjør det mulig å bruke maven i eclipse. Plugingen er ment å gi Maven-støtte i Eclipse. 6.2 Tomcat 6 Tomcat webserver ble et naturlig valg da to i gruppen allerede hadde erfaring med det. Dette er også webserveren som javakoden kjøres på. Ettersom API ikke hadde noen innvendinger i valget av denne programvaren, ble valget endelig. Tomcat plugingen gjør det mulig at java-koden kan samarbeide med en webserver, siden tomcat er en webserver som tolker JSP-kode og Java Servlet. 6.3 Spring Framework 2.5 Spring Framework er rammeverk for å håndtere kobling mellom objekter, enklere bruk av Hibernate, og inneholder også en egen MVC del som vi skal ta i bruk for administrasjonspanelet. Etter som dette var et konkret ønske fra API vår oppdragiver tok vi umiddelbart bruk av dette verktøyet. Spring er et gratis rammeverk med mange tjenester og muligheter. Det er en åpen kildekode applikasjon for Java platformer. Vi kan si at Spring er en samling av mindre rammeverk og de fleste av disse rammeverkene er dannet for å fungere uavhengige av hverandre, men de gir bedre funksjonalitet når de blir brukt sammen. 6.4 Hibernate ORM står for Object Relational Mapping, og er et rammeverk som gjør det enklere å kommunisere med en relasjonsdatabase fra et objektorientert miljø. ORM- en tar seg av lagringen av dataene fra objektene i databasen når det er nødvendig, og henter ut dataene og plassere dem i objektet når det er nødvendig. For å spare gruppen for mye unødvendig koding i programmet, valgte vi å bruke en ORMteknologi som gjør det mulig å kommunisere mot databasen. Ved bruk av denne type ORMteknologi kan man enkelt bytte database på et senere tidspunkt dersom er ønskelig. Hibernate er en av de mest populære ORM verktøyene for Java, og fungerer veldig bra sammen med Spring Framework. 11

12 6.5 Ant/Maven Byggeprogram for å automatisere utrulling av programmet, og for å kjøre unit-tester. For å få god start på prosjektet starte vi med å bruke Ant da vi syntes at dette var et lettere program å sette seg inn i. I tillegg til dette så er Ant ferdig integrert i Eclipse. Det var kun en i gruppen som hadde forkunnskap med Ant og det ble derfor naturlig å utforske funksjonaliteten og Juni-tester med dette programmet. Ettersom oppdragsgiver API anbefalte oss å ta en titt på Maven som de brukte og mente var bedre, konkluderte gruppen med å bytte fra Ant til Maven. Dette uløste en del utfordringer så vi vil komme nærere inn på. Maven er et verktøy og rammeverk for automatisert bygging, testing og deployment av Javaapplikasjoner. Maven har også en veldig avansert system for konfigurasjonsstyring av både egen koder og biblioteker. 6.6 Subversion Subversion(SVN) er et versjonkontrollsystem. Altså et system som kan holde orden på forskjellige versjoner av en eller flere filer. Flere personer kan jobbe på den samme filen, så lenge man ikke jobber med binær filer. 6.7 Java SE 6 Java er hovedteknologien for hele prosjektet. Dette ble også et naturlig valg da flere i gruppen hadde erfaring med dette språket. Vår arbeidsgiver ønsket også at vi brukte Java som et utviklingsspråk da dette var et språk de godt var kjent med. 6.8 MySQL 5 (InnoDB, UTF-8) Gruppen valgte å benytte seg av en MYSQL 5 database da alle i gruppen hadde kjennskap til dette vertøyet. Dette er databasen hvor alt blir lagret. Dersom vår oppdragsgiver ønsker å benytte seg av en annen database, vil dette ikke by store utfordringer da vi bruker Hibernate og databasen kan raskt byttes ut, i et senere tidspunkt dersom ønskelig. 7. Planlegging og metode I dette kapitelet går vi innpå hvordan gruppen ble opprettet og hvordan vi valgte dette hovedprosjektet. Vi kommer også til å si noe om forprosjektet, kravspesifikasjon og valg og vurdering av teknologiske verktøy. Videre tar vi dere med på hvordan hver enkelt 12

13 gruppemedlem måtte lære seg de ulike teknologiske verktøyene for å kunne utvikle MetaGen systemet. Tilslutte illustrer vi e fremdrift plane og sier noe om prosjektdagboken. 7.1 Gruppe opprettelse og prosjektvalg Ingen av gruppemedlemmene kjente hverandre fra før av, men vi alle var positivt innstilt på et godt samarbeid. Vi ble kjent med hverandre via skolens mailsystem og avtalte møte deretter. Gruppen besto først av to medlemmer som hadde bestem seg for å gjøre hovedprosjekt sammen, Fatima og Karen. Deretter ønsket de å utvide gruppen med ytterligere to gruppemedlemmer til Orji Og Ole. Gruppen hadde hovedsakelig tenkt til å finne et prosjekt som var basert på PHP/MySQL. Etter å ha besøkt de forskjellige bedriftene fikk vi et inntrykk av at de fleste brukte Java som et grunnspråk og det ble da naturlig å revurdere tema. Vi var i kontakt med flere bedrifter og besøkte to som het Bellit og API. Bellit hadde i utgangspunktet ikke noe prosjekt til oss, men ønsket allikevel et samarbeid som kanskje kunne utvikle seg til et hovedprosjekt. Etter å ha fått et overblikk på hva de ønsket seg av oss, fant vi fort ut at dette ikke egnet som et hovedprosjekt og takket derfor nei. Parallelt med dette var vi på besøk hos API, og fikk et mye bedre tilbud som gruppen synes var oppriktig interessant. Dette resulterte til at vi takket ja til tilbudet av API, som igjen betydde fødselen av MetaGen, vårt hovedprosjekt. Etter å ha snakket med API valgte vi å gå for en Java-løsning, både fordi det passet arbeidsgiveren best, og vi ønsket å bruke et språk vi delvis har hatt mye fra før, og som vi var interessert i å lære mer om. 7.2 Forprosjekt I forprosjektfasen konsentrerte vi oss på å bli kjent med hverandre, kartlegge hva vi skulle gjøre og hvordan oppgaven skulle løses. Siden ingen av gruppen kjente hverandre fra før brukte vi litt tid på å finne ut hva enkelte ville jobbe med. Det ble lagd et forprosjekt som skulle gi oss et bedre bilde av av selve systemet. 13

14 Det var en del bekymringer siden ingen av oss hadde jobbet med Spring, Hibernate og maven. Noen av oss hadde ikke engang hørt om disse teknologiene, noe som medførte til at det ble brukt tid til å bi kjent med de nye teknologiene. Møtene vi hadde med vår veileder gikk bra og vi avtalte å ha møte hver tirsdag. Oppdragsgiveren ga oss et bra bilde på hvordan vi kunne få til oppgaven. 7.3 Kravspesifikasjonen Gruppen skrev kravspesifikasjonen selv. Vår arbeidsgiver var ganske åpen på hvordan vi kunne løse oppgaven, men de kom med en del anbefalinger. Vi valgte å bruke prosessmodellen scrum da dette er en modell som ivaretar en god fremdrit i henhold til arbeidsoppgaver. Dette konkretisere vi nærmere i kapitel Lære å bruke utviklingsverktøyene Alle i gruppen hadde relativt god erfaring med Java og MySQL. Det som viste seg å bli en utfordring var å bruke disse to verktøyene i sammen. Derfor brukte vi mye tid på sette oss inni funksjonaliteten av disse verktøyene. Når det gjaldt Spring, Hibernate, Ant/Maven og JUnit var det ingen av gruppemedlemmene som aktivt hadde jobbet med disse verktøyene. Dette resulterte til at det ble brukt mye tid på å komme i gang med selve prosjektet da vi måtte bruke en god del tid på å sette oss ordentlig inn i stoffet. Etter en tung og lang prosess med å sette oss inn forskjellig fagstoff ser vi at dette ikke bare har vært en fordel for prosjektet, men også for videre læring. Det var nødvendig å sette seg inn i de forskjellige verktøyene da bedriften benytter seg av den type teknologi. Dette vil gjøre det lettere for bedriften å hjelpe oss med diverse problemer og sette seg inn i prosjektet dersom de ønsker en utvidelse av systemet. 7.5 Prosjektdagbok Gruppen ble enig på et tidlig tidspunkt om å føre prosjektdagbok. Dette ønsket vi å gjøre for å holde oversikt på arbeidsoppgaver som gruppen utførte. Gruppen ble også oppfordret til å skrive en prosjektdagbok av vår fagligveileder da hun synes dette var en god rutine å innføre, som en del av gruppens arbeidsmetoder. Prosjektdagboken ble ikke alltid oppdatert og det skal sies at gruppen til tider ikke førte denne konsekvent. 14

15 7.6 Fremdriftplan Gruppen lagde en fremdriftplan som skulle virke som en pekepinne for de arbeidsoppgaven gruppen måtte har ferdigstilt til ulike datoer. Det viste seg at ting tok lengre tid enn det vi hadde planlagt da vi måtte sette oss inn i mye nytt stoff. Etter noen justeringer med hardt arbeid og mye lesing av nytt fagstoff, kom vi noe tilbake i takt med fremdriftsplanen. Gruppen ble enig om at vi skulle følge fremdriftsplanen så langt det var mulig og oppfølgingsansvaret ble tildelt vår gruppeleder Ole. Han skulle holde oversikt over ting som måtte gjøres og evt. tildele gruppemedlemmene nye arbeidsoppgaver med frister. Femdriftsplan ble noe justert på veien da vi så at dette var nødvendig. 8. Utviklingsprosessen I dette kapittelet vil vi gi et lite innblikk i diverse ufordringer gruppen har hatt under utviklingen av prosjektet. Det vil også bli konkretisert hvordan disse utfordringene har vært med på å prege systemet og endringer som har blitt gjort i følge av dette. Deretter vil vi trekke ut neon hovedaspekter under implementasjonen i systemet og forklare disse nærmere. 8.1 Samarbeid i gruppen. Gruppen har hele tiden vært opptatt av å fordele riktig arbeid til riktig gruppemedlem. I starten bestemt gruppen at det var viktig å ha en fungerende gruppeleder som kunne holde kurs i fremdriften. Det ble bestem av gruppen at Ole skulle bli gruppeleder da han var den med best overblikk av systemet. Det ble deretter bestemt av alle at alle gruppemedlemmene skulle gjøre seg kjent med de forskjellig teknologiske verktøyene. Vi begynte med å installere de forskjellige verktøyene. Deretter lagde vi et lite min prosjekt i Eclipse ved bruk av Spring Framewok, Tomcat og Hibernate. Dette lille prosjektet var med på fordype læringen av de ulike verktøyene. Det ble lagd en TO DO LISTE der gruppen konkretisert og fordelte de ulike arbeidsoppgaven. Siden det var så mye å foreta seg, valgte gruppen å fokusere på å få i gang et lite testprogram som kunne illustrer systemet. I den anledningen fikk alle gruppemedlemmene et ansvar for en liten del av systemet. 15

16 8.2 SCRUM-FIGUR Denne figuren illustrerer hvordan gruppen prioriterte og fordelte arbeidsoppgaver. Den viser også hvor mange timer vi brukte på prosjektet i uken og gruppens faste møter punkter samt avtaler med fagligveileder og Oppdragsgiver API. Gruppen valgte å jobbe etter Scrum metoden. Vi valgte å dele arbeide opp i forskjellige sprinter. Hver sprint besto av et planleggingsmøte der vi valgte et tema som vi jobbet med til neste sprint. I begynnelsen av hvert sprintmøte, så fortalte hver enkelt gruppemedlem hva den har jobbet med fra forrige sprint, og hvilke utfordringer den eventuelt har hatt. Gruppen møttes hver tirsdag og fredag og hadde hyppig kontakt via msn. Dette var for å kvalitet sikre fremdrift i prosjektet. Videre så møtte vi vår faglig veileder en gang i uken og lagde avtaler med API etter behov. Gruppen har også opprettet en Sprint backlog der vi har lagd en liste over ting som må gjøre med hensyn til arbeidsgiverens ønsker og forespørsler. 8.3 Utfordringer og løsninger Det ble brukt mye tid på å bli enig om hvordan man ønsket å fremstille prosjektet. Videre la vi ned mye arbeid for å lære oss de ulike teknologiene. Det viste det seg å være en utfordring å få de forskjellige verktøyene å til fungere sammen. Da det var lite kompetanse å finne på området ble det brukt mye tid på å finne løsninger til de problemene som oppsto. Det ble brukt tid på å søke på nettet og lese bøker for å tilegne oss nødvendig kompetanse. Et resultat av dette var at vi ble supplert med mye nytt fagstoff som var med på å heve vår faglige 16

17 kompetanse. Dette kom prosjektet til gode da feilmeldinger og tekniske problemer ble løst mer effektivt og raskere. 8.4 Implementasjon/ MetaEx - Informasjonsinnsamling Det er ikke mulig å presentere ekstra informasjon til en artikkel uten å ha informasjonen tilgjengelig. I oppgaven med MetaGen trengte vi informasjon om Stortinget til å berike artiklene med, og det var derfor nødvendig å få samlet inn dette. Det første som ble prøvd var at arbeidsgiver ringte Stortinget for å spørre om det var mulighet for å få utlevert informasjonen i strukturert format. IT avdelingen på Stortinget svarte at dette ikke var noe som var enkelt å gjøre med dagens systemer, og det ble nødvendig å finne en annen måte. Svaret på problemet ble programmet MetaEx. MetaEx er et javaprogram som er skrevet av prosjektgruppen for å løse problemet med informasjonshenting. Programmet baserer seg på å laste ned internettsider fra stortinget.no for så å hente ut informasjon etter bestemte mønstre. Det er på denne måten mulig å automatisk hente ut en god del beskrivende informasjon om politikere, når de eventuelt satt på stortinget, og hvilket parti de tilhører. En jobb som ville vært tidkrevende og totalt uaktuelt å gjøre manuelt Teknologi og http kommunikasjon Det er brukt programmeringsspråket Java for selve kodingen av MetaEx. For å kunne innhente den ønskede informasjonen trengte programmet å kunne koble seg til internett for å laste ned bestemte nettsider fra stortinget.no. Java inneholder alt en java.net pakke som blant annet kan ta seg av http kommunikasjon. MetaEx prøver å simulere en vanlig nettleser og dens funksjoner, og denne pakken viste seg etter hvert å komme til kort for dette formålet. Løsningen ble HTTPClient pakken fra Jakarta commons. HTTPClient er en pakke som utvider funksjonaliteten i forhold til bruk av java.net, og gjør det enkelt å bruke de vanligste http-funksjonene i forbindelse med nettsider. Det trengtes hovedsaklig for å kunne bruke cookies/sessions og POST i http-kommunikasjonen. Det kommer utdypende informasjon om dette lenger ned. All søking mot nett fra programmet foregår gjennom linken 17

18 Figur 1 Utsnitt av nettsiden Hvis man putter linken i nettleseren sin, så vil man se at man kommer til en søkeside for biografier. Her kan man putte inn forskjellige søkekriterier for å få opp en liste med politikere som passer med det man har valgt, og MetaEx er programmert for å kunne gjøre det samme, bare automatisert. Om man prøver søkefunksjonen manuelt i en nettleser og titter i adresselinjen, så vil man se at adressen aldri endrer seg. Dette er fordi siden bruker POST (Metode i http protokollen) ved sending av informasjon. Dette var en av flere punkter hvor java.net pakken kom litt til kort. I tillegg til at søkekriterier må sendes med POST, så var det en del andre utfordringer også. For å gjøre det enklere å løse disse ble det brukt en proxy server som har mulighet for å avskjære http kommunikasjon slik at det lar seg gjøre å inspisere (og endre) http-headeren til forespørsler og svar. Det ble her brukt Burp Suite, som er et program med en rekke hjelpeverktøy for å teste/angripe webtjenester. Nettleseren Firefox og applikasjonen MetaEx ble konfigurert til å bruke Proxy tjenesten til Burp for tilgang til nett slik at avlytting av disse ble mulig. 18

19 Figur 2 Burp viser headeren til forespørsel ved søk (Brukt nettleseren Firefox) Burp gjør at når intercept er aktivert, så stopper den alle forespørslene midlertidig. For hver forespørsel kan man velge om den skal sendes videre dit den var ment, eller om det ønskes å droppe den slik at den aldri når målet sitt. Det er også mulig å gjøre endringer i den før den sendes videre. Etter litt testing viste seg at siden trengte å støtte sessions/cookies og at den brukte POST variabler for validering av forespørselen når man gjorde søk. Dette gjør det umulig å sende en forespørsel med søk direkte uten noe forarbeid. Problemet ble løst ved at programmet først leser innholdet av linken uten å sende med parametre. HTTPClient sørger for å plukke opp session/cookies fra første siden samtidig som vi lagrer innholdet av to nødvendige POST parametre, som følger med siden tilbake (_VIEWSTATE og _EVENTVALIDATION). _EVENTVALIDATION endrer seg for hver ny økt (session) som starter, og forespørselen feiler om den ikke er korrekt. Dette ble testet i proxy delen til Burp ved å endre http forespørselen ved vanlig surfing gjennom en nettleser. Disse to er derfor nødt til og sendes med for hver forespørsel videre fordi det er påkrevd av søkefunksjonen til biografisiden på stortingent.no. 19

20 Figur 3 - Burp viser POST parametre som sendes med ved søk (Brukt nettleseren Firefox) Videre oppstod det problemer med tegnsett. I kildekoden til html-filen man får fra søkesiden er det angitt at det brukes tegnsettet ISO , men når man viser siden i en nettleser velger nettleseren visning i UTF-8. Hvis dette overstyres manuelt i nettleseren til ISO vil tegn som ÆØÅ vises ukorrekt. Vi kom derfor fram til at ISO er feil, og det brukes UTF-8. Stortinget.no er ikke helt konsis når det gjelder tegnsett. De har sider rundt på nettstedet både i UTF-8 og ISO , men alle sidene er merka med ISO uansett hva som egentlig brukes. En vanlig nettleser klarer imidlertid å skjønne hva den skal bruke for hver enkelt side slik at man vanligvis ikke vil merke noe. Det ble også oppdaget tegnsettproblematikk ved POST forespørsler fra MetaEx til stortingsiden. Ved sammenligning av http forespørsler fra vanlig nettleser og MetaEx ble det funnet at forespørselen brukte feil tegnsett. Ettersom alt i headeren er nødt til å være ASCII kompatibelt, så brukes det en URLEncoder som gjør om tegn som ligger utenfor ASCII til heksadesimal representasjoner. Ved bruk av UTF-8 og ISO tegnsett tabeller ble det konkludert med at teksten ble sendt med en ISO kompatibel standard på tross av at forespørselen ble spesifisert som UTF-8. Dette er noe av den samme problematikken som med nettsiden til stortinget.no. Man kan spesifisere tegnsett i vildens sky, men det endrer ikke nødvendigvis det faktiske tegnsettet som er i bruk. Det ble forsøkt å konvertere teksten til UTF-8 før den ble sendt uten at det så ut til og lykkes. Feilsøkingen fortsatte til det ble klart at det var Eclipse som var synderen. Eclipse var satt til tegnesettet Cp 1252 (som er utvidet variant av ISO og er standard i Microsoft 20

21 Windows). Når tegnsettet ble endret til UTF-8 og alle spesialtegn ble retta på til å stemme på nytt (Disse forandret seg når tegnsett ble bytta ettersom kodene blir representert annerledes i UTF-8), så sendte MetaEx endelig identiske forespørsler med det nettleseren gjorde Nedlasting og uthenting Første utgaven av MetaEx kunne ikke gjøre søk direkte til nettsiden selv, og det ble derfor gjort med en standard nettleser hvor man så lagret kildekoden av svaret man fikk. Resultatet ble så lest inn i MetaEx fra fil. Senere i utviklingen kom det på plass at programmet selv kan gjøre søk. Figur 4 Nettsiden med trykk på søk (4696 oppføringer) Første søket gjøres er med blanke søkekriterier for å få liste over alle personene som har biografi registrert på sidene til stortinget. Denne siden går så gjennom en metode som bruker Regular Expressions (heretter kalt Regex). Regex er en slags avansert søkefunksjon for tekst som her brukes til å skille ut ønsket innhold etter forhåndsbestemte mønstre. På denne måten hentes det ut blant annet fornavn, etternavn, fødselsår, og så videre til alle oppføringene på lista. 21

22 <div class="listeitem"> <li> <a href="biografi.aspx?initialer=jes">stoltenberg, Jens</a> (1959-), Arbeiderpartiet, Oslo </li> </div> Utrag fra søkeresultatet i HTML som viser hvordan en enkel oppføring ser ut. De delene av "initialer=(.*?)\">(.*?), (.*?)</a> \\((.*?)-(.*?)\\), (.*?)\\W{2}(.*?)\\s*?</li>" teksten Regex henter ut informasjon fra er vist med rødt. Regex mønsteret som fanger opp de forskjellige verdiene over. For hver oppføring legges innholdet inn i et java objekt som igjen kobles til en tabell (Array). Det er per i dag når dette skrives totalt 4696 oppføringer. Systemet trenger fremdeles kun å lese én webside for å koble alle disse oppføringene til objekter. Det neste steget var å få tak i alle biografiene til disse personene. Til nå hadde systemet kun hentet ut innhold fra den ene siden med en oversikt over alle. For hver av oppføringene er det en videre link til den enkeltes biografi. Ved første lesingen ble den unike delen av denne linken lagret under initialer i samme objektet som navn og etternavn osv. Alle biografier er å få tak i gjennom denne linkstrukturen + initialer Det var da bare å få java programmet til å gå igjennom hele tabellen med politikere og bruke denne linken sammen med de lagrede initialene til hver av dem for automatisk å laste ned alle sine biografier. 22

23 Figur 4 - Biografien til Jens Stoltenberg For å ta litt hensyn til nettstedet laster programmet først ned alt innholdet for lagring slik at det ikke ble behov for å gjenta det ved videre testing. Det ble også satt en ventetid mellom hver sideforespørsel på 1000 millisekunder. Dette fordi nedlastingen ikke skulle forveksles med et DoS angrep (Denial of Service), og for ikke å belaste serveren for mye. I tillegg ble det gjort om natta når det mest sannsynlig var færrest mulig andre besøk på siden. Klassene som innholder nedlastet informasjon er serialiserte, og alt lagres veldig enkelt til fil ved hjelp av serialiseringen. Ved rundt 1800 nedlastede biografisider, så stoppet programmet opp med feilmeldingen java.lang.outofmemoryerror: Java heap space. Denne dukket opp på grunn av at Java programmet prøvde å lagre så mye informasjon i minnet at minnemengden det hadde fått tildelt ikke var nok lenger. Ved å justere opp minnemengden programmet har tilgang til, så fullførte den nedlastingen av alle 4696 biografisidene. 23

24 Nettsidene som inneholdt biografier ble lastet ned i sin helhet uten å hente ut spesifikk informasjon fra dem før de ble lagret i minnet i samme objektet som holder på navn og resterende informasjon. Ved ferdig nedlasting ble alt lagret til disk for siden å kunne hentes tilbake ved behov. For å spare lagringsplass kan det ved ny nedlasting være aktuelt å skrive kode for å filtrere bort en del av html-koden som ikke har noe med selve biografiene å gjøre før de lagres til disk. Filen som innholder alt som er lagret til disk med MetaEx har per i dag en filstørrelse på 76,3 MB Uthenting av informasjon fra nedlastede websider Det ble videre arbeidet med å hente informasjon ut fra biografiene, men ettersom strukturen og innholdet var svært varierende, så ble det begrenset til visse nøkkelopplysninger som fødselsdato (og evt. død), og nåværende parti. Det var bedre å bruke søkefunksjonen til stortingssiden (gjennom MetaEx) for å filtrere ut hvem som hadde sittet hvilke perioder osv.. Denne delen ble testet og fungerte utmerket, men det kom aldri så langt at informasjonen den kunne generere ble brukt videre i MetaGen. Det er likevel stort potensial for videre informasjonshenting ved hjelp av programmet uten at det er trengs og utvides nevneverdig Sammendrag/avslutning MetaEx var et program som kom til liv på grunn av at det var behov for å få tak i informasjon som skulle fylle databasen med meta-informasjon. Uten denne ville ikke MetaGen hatt noe å supplere artiklene med. Programmet er hovedsakelig skrevet som et engangsprodukt. Det er heller ikke ment å brukes utenfor et utviklingsmiljø. Det er beregnet for bruk av utviklere som kan java, så brukervennlighet er ikke akkurat prioritert. Etter at søkefunksjonen ble implementert, så er potensialet stort for å rimelig enkelt hente ned en god del mer spesifisert info for å fylle vider meta-tabeller med informasjon. 8.5 Xml XML står for Extensible Markup Language. Kort sakt er XML for å strukturere data eller beskrive data (metadata) i elementer ved å bruke tekstkoding eller markeringskoder. 24

25 8.5.1 XML parsing Det XML- parsere gjør er å analysere XML- teksten og generere trestruktur(setter teksten inn i objekter). XML-parseren kan også sjekke at dokumentet er i henhold til forhåndsdefinert språk.(validering) I vårt system brukes XML-parsingen når Metagen ikke finner artikkel iden i cache databasen.hvis Metagen sjekker artikkeliden mot cache databasen og ikke finner iden, henter den xml representasjonen av artikkelen og representasjonen blir parset av Java og putta i Java objekter. Altså xml filen(representasjonen av artikkelen) blir parset til Java objekter. Vi brukte Jakarta Commons Digester for å lage Java objekter av xml. Commons Digesterer et kjent verktøy som standardiserer koden for å opprette Java objekter av xml filer. Med Commons Digester slipper man masse unødvendig koding og kan bruke dette i ulike operasjoner når man skal parse xml filer til Java objekter Spring/Hibernate og Databaseaksess I dette delkapitelet beskriver vi utviklingen av systemet med Spring, Hibernate og databasen Valg av database I vårt første møte med API fikk vi gode innspill på hva slags teknologiske vertkøy vi burde bruke for å utvikle systemet. Ettersom gruppen hadde erfaring med mysql og plattformen var åpen kildekode gikk vi for den. I følge API var det nødvendig å ta i bruk en ORM() for å enkle gjøre kommunikasjonen mellom databasen og Javaobjektene. Ved hjelp av Hibernate konfigurasjonsfil, programmerte vi en databasetilkobling til et eget Hibernate konfigurasjonsfil. Dette skal gjøre det enklere for en utvikler å bruke databasen Datamodell Ved hjelp av cach databasen valgte vi å skille mellom referanseinfo og metagendata i databasen. I Cashe tabellen skulle det kunne inneholde referanseinfo. Dette var den sammen databasen som vi forbedret ved å bruke initialer i navn tabellen, noe som skulle forenkle prosessene. Det første vi undrer oss over var hvilken type data som skulle ligge i metagen databasen. Vi var inne på Stortingssidene for å prøve å finne relevant stoff som egnet seg å ha i databasen. 25

26 Vår oppdragsgiver tilbydde seg å kontakte Stortinget for å hente ut informasjon i strukturert format slik at vi enkelt kunne putt dette gjennom en xml parse. Dette gikk dessverre ikke som planlagt da Stortinget ikke kunne eksporterer informasjon til strukturert format, siden de kjørte et gammelt system og var i ferd med å bytte til en nyere versjon. Gruppen måtte da lage et eget program som hentet fysisk ut informasjon fra stortingssiden. Dette programmet ble kalt MetaEX. MetaEx blir videre konkretisert i delkapitelet 8.4 og i produktrapport. Vi listet deretter opp tabeller ved hjelp a databasedesign og designet deretter koblinger mellom tabellene. Vi har valgt å ta utgangspunkt i biografiene til politikerne og inkludert blant annet fødsel, død, fornavn og etternavn. En av de mest selvforklarende relasjonene i databasen er forholdet mellom stortingsrepresentant tabellen og parti tabellen. Der eksisterer det en-til-mange relasjon. En Stortingsrepresentant tilhører et parti mens et vanlig parti består av flere stortingsrepresentanter. Relasjonen mellom artikkel og politiker, er mange-til-mange. Vi mente at en artikkel kunne enten bestå av en eller flere politikere mens en politiker kan bli skrevet om i ingen, eller mange artikler. Dette er representert med en toveis en-til-mange link-tabell mellom entitetene(artikkel_has_politiker og artikkel_has_parti). Gjennom hele prosessen har vi endret og tilpasset databasen, fra utkastet i forprosjektrapporten og dette er det endelige ER-diagrammet av databasen.mer detaljert beskrivelse om tabellene og relasjonene kan leses i produktdokumentet. 26

27 ER- Diagram Figur eksempel Navn konvensjon-database Gruppen valgte å bruke navn konvensjon under implementasjonen av databasen. Dette betyr at vi følger en standart og logisk struktur å implementere databasen på i applikasjonen. Ved å bruke navn konvensjon kunne vi alle forholde oss til standart regler som å bruke store eller små bokstaver på navn og attributter, samt notasjon og stil. Dette forhindret uønsket feilmeldinger og ekstra arbeid. Ved å bruke navn konvensjon så vil det bli enklere for en utvikler å sette seg inn i databasen og evt utvidet systemet. Dette var navn konvensjonen vi fulgte: Alle tabellnavnene begynte med små bokstaver Databasenavnet var systemnavnet vi brukte for prosjektet Vi separerte navn ved underlinje da dette forbedret lesbarheten av hvert enkelt navn Primærnøkler begynte alltid med tabellnavn, deretter underlinje og id(artikkel_id) Hver kolonne i tabellen begynte med liten bokstav For mange-til-mange relasjoner valgte vi å skrive tabellnavn_has_tabellnavn. Vi valgte å bruke prefix(cache og metagen) for alle tabeller som tilhørte i samme kategori Hibernate dataaksesslaget Hibernate er et såkalt Objekt/Relasjons Mapping rammeverk som gjør bruken av databaseaksess i et objektorientert miljø lettere. API hadde tidligere erfaring med dette verktøyet og ønsket at vi skulle benytte oss av det.noe av de største fordelene med Hibernate 27

28 er at den også har sitt eget query språk. HQL altså et språk som ligner veldig på SQL, men er spesiallaget for å gjøre spørringer i databaser med persisterte objekter. HQL er blant annet objektorientert, noe som gjør det veldig lett å hente ut ønsket informasjon. Gruppen begynte i begynnelsen av prosjektet å sette seg inn i hvordan Hibernate fungerer, ved hjelp av dokumentasjonen som fulgte med. Vi fant også en guide om Hibernate på nett som vi fulgte for å lære mer om det. Det var i grunn til stor hjelp for oss som ikke hadde noen forkunnskaper i dette området. Vi var ganske fornøyde med Hibernate guiden noe som førte til at vi gikk i gang med å utvikle Hibernate. Siden det var enkelt å konfigurere Hibernate til å fungere med databasen vår begynte vi deretter på kodingen. Etter at vi fikk til Hibernate var utfordringen i å finne ut hvordan dette skulle integreres med spring JavaBønner og assosiasjonene I Hibernate brukte vi 3 forskjellige Java-bønner som inneholdt get-metoder, set-metoder og add-metoder. Siden det var mange-til-mange relasjon mellom artikkel og politiker og mellom parti og artikkel valgte vi å programmere mappingen i bidirectional som står for at assosiasjonene er toveis og ikke enveis. Det vil si at vi slår opp artikkel ut ifra en politiker og politiker ut ifra artikkel. Java-bønnene var en av avbildning av tabellen de representerte. Det siste resultatet av Java-bønnen kan sees nedenfor: Mapping filer Hibernate trengte å vite hvordan et objekt fra en javabønne skal hentes og lagres. Det var her mappingen kom inn i bildet. Et mapping dokument er en xml fil som forteller hvilken tabell i databasen en javaklasse skal relateres til, og hvilken kolonne i tabellen som skal brukes. Det finnes forskjellige måter å bruke mappingen på, enten lagre man alle objektene i en fil eller velger hvert mapping fil for hvert objekt. Siden vi ikke hadde alt for mange objekter å holde styr på, gikk vi for en egen mapping for hvert objekt. Fordelen med å ha hvert objekt i egen mapping xml fil var at det var enklere å finne feil hvis det oppsto. 9. Konklusjon MetaGen har vært et meget spennende prosjekt å jobbe, selv om gruppen har vært nødt til å sette seg inn i mye nytt fagstoff. Det har vært utrolig mye arbeid med å sette seg inn i hvordan teknologien vi skal bruke fungerer, og det å løse nye problemer underveis. Ingen av 28

29 gruppemedlemmene hadde jobbet sammen før, noe som ble en utfordring, men samtidig en virkelighetsnær opplevelse. I arbeidslivet er det akkurat det man som ofte må forholde seg til, og da er det fint å ha erfaring med det fra før. Alle i gruppa er enige om at det har vært en veldig lærerik prosess hvor man har blitt utfordret på forskjellige nivåer, både på godt og vondt. Det gode samarbeidet i gruppen samt prosjektoppgaven har ført til mye viktig lærdom og god mellom menneskelig relasjoner. Det er ikke alltid like lett å beregne hvor lang tid noe tar når man aldri har vært borti det før. Gruppa har likevel klart å komme seg gjennom de utrolige mengdene med knytte sammen alle de forskjellige teknologiske verktøyene for å få prosjektet til å fungere. Oppgaven er av en slik art at det er mye arbeid bak systemet som ikke nødvendigvis kommer frem i koden. MetaGen er et type system som allerede er tatt i bruk i flere sammenhenger, og bare kommer til å bli mer og mer er populært i fremtiden. I samarbeid med API har vi ferdigstilt en demoløsning for hvordan slike oppgaver kan løses. Til slutt så vil vi gjerne takke vår veileder, Eva Hadler Vihovde, for mye bra konstruktiv tilbakemelding og oppmuntring gjennom et spennende og krevende prosjektperiode. 29