1.2 Innholdsfortegnelse

Transkript

1 1 Prosessrapport

2 1.1 Forord Denne prosessrapporten beskriver utviklingen av Marcello elearning Terminal Framework. Rapporten er gruppe 4 sin besvarelse av Hovedprosjektet våren 2007, som består av disse deltagerne: Wenche Martinsen, Eline Augdal og Peter Magnus Prestesæter. Dokumentet er laget for sensor, oppdragsgiver og andre som vil ha utbytte av og er interessert i å følge prosjektets fremgang til ferdig produkt. Rapporten inneholder bakgrunnstoff om oppdragsgiver, hvilken metode vi har valgt for å løse oppdraget, og litt om de forskjellige verktøyene og teknologiene vi har brukt. Gruppen har brukt lang tid på å sette seg inn i nye teknologier som Hibernate, Spring og WebWork. Gruppen anser Hibernate og Spring som aktulle teknologier til vidre bruk etter hovedprosjektet. Å kjenne til MVC arkitektur er meget aktuelt, selv om WebWork ikke er like utbrett som Hibernate og Spring.

3 1.2 Innholdsfortegnelse 1.1 FORORD INNHOLDSFORTEGNELSE INNLEDNING Firmaets situasjon ved start av prosjektet Oppgavens mål Funksjonelle krav Rammebetingelser UTVIKLINGSPROSESSEN Planlegging og analyse Utvikle Avsluttning PLANLEGGING OG METODE Gruppnes bruk av valgt prosessmodell VALGTE VERKTØY Hibernate WebWork Spring Framework FreeMarker OPPSETT AV UTVIKLINGSMILJØ SUN Java Installering Eclipse Installering Programtillegg (plugins) Ekstra bibliotek (Jar) Apache Tomcat Installering LITTERATUR PROSJEKTORGANISERINGEN Prosjektserver Milepælsplan Prosjektets webside EVALUERINGER AV PROSJEKTPERIODEN Utfordringer i prosessen Problemer i prosessen Hva vi har lært Hva vi ville gjort annerledes... 19

4 1.3 Innledning Marcello Systems AS er en del av Marcello konsernet. Marcello er et konsulentkonsern som leverer tjenester innen nettverk, kommunikasjon og systemutvikling. Marcello har dybdekompetanse på markedets ledende produkter innen infrastruktur, og lang erfaring med systemutvikling og integrasjon i større miljøer Firmaets situasjon ved start av prosjektet Marsello Systems AS har utviklet et elearning rammeverket som er spesielt tilpasset en web bassert tjeneste hos en kunde. Teknoligiene som er benyttet er PHP og JavaScript. Disse teknologiene benytter seg ikke av kompilert kode, og dermed er det vanskelig å beskytte koden mot uønsket innsyn. Oppdragsgiver er blitt forespurt om muligheten av å kunne benytte dette rammeverket på andre web basserte tjenester, noe som per dags dato ikke er mulig uten omfattende tilpassninger på rammeverket. Rammeverket støtter heller ikke vanlige elearning standarder som AICC og SCORM. Rammeverket er beskrevet som unikt av en elearning leverandør. oppdragsgiver ønsker å vidreutvikle rammeverket med tanke på salg til andre kunder, og se på muligheten for et samarbeid med elearning leverandøren rundt salg av rammeverket Oppgavens mål Målet med prosjeketet er å gjøre rammeverket mer generelt slik at det enkelt skal kunne benyttes på andre web basserte tjeneser. Rammeverket skal gjøres mer sikkert for uønsket innsyn i de tenkiske løsningene. Rammeverket skal også implementere støtte for AICC og SCORM. Prosjektet er å videreutvikle et produkt som Marcello Systems AS har utviklet for en kunde. Produktet er et elearning rammeverk for web basserte tjenester. Rammeverket gir kunden mulighet til å opprette og gjennomføre kurs på en web bassert tjeneste. Prosjektet går ut på å gjøre rammeverket mer generelt slik at det enkelt skal kunne overføres til andre web basserte tjenester. Prosjektet skal bytte teknologi fra PHP til Java servlets Funksjonelle krav Rammeverket består av tre forskjellige rettighetsnivåer; administrator, teacher og student. Disse nivåene er beskrevet i detalj i Feil! Fant ikke referansekilden. Feil! Fant ikke referansekilden. De funksjonelle kravene for en student er: Logge på med a. Brukernavn og passord på en innloging side b. Automatisk via en link sendt i en mail til brukeren Om rammeverket ikke er knyttet opp til en elearning løsning, skal brukeren etter innlogging få informasjon om konseptet, regler for bruk, hvordan opplæringen foregår osv. Det skal være mulig å hente informasjon om bruken av systemet enten via en web side, word dokument eller pdf dokument Om rammeverket ikke er knyttet opp til en elearning løsning, skal brukeren få en liste over tilgjengelige kurs

5 Om rammeverket er knyttet opp til en elearning løsning (via SCORM eller AICC), skal brukeren komme rett inn på kurset Inne på et kurs skal brukeren presenteres ett sett med oppgaver som skal løses (antall og type oppgaver er bestemt av administrator) Hver oppgave skal ha en beskrivelse av hva som skal løses/finnes Oppgaver løses ved å navigere i web systemet og klikke på rett sted / riktig element Når alle tildelte oppgaver er gjennomført skal brukeren presenteres resultatet, ett evt. diplom og passende gratulasjoner De funksjonelle kravene for en administrator og teacher er: Mulighet for å definere brukergrupper Brukergrupper kan navngis, tilknyttes forklarende tekst/kommentarer, lagres samt hentes frem for senere redigering Mulighet for å designe oppgaver samt gruppere sett/samlinger av oppgaver slik at disse kan utgjøre komplette kurs Kurs kan navngis, knyttes kommentar/forklarende tekst til samt lagres og hentes frem for senere redigering. Kurs kan tildeles brukergrupper Oppgaver vil være blant disse mulige typene: Navigere frem til en bestemt side. Navigeringen fram til siden er ikke vesentlig (noen sider kan det er mange veier fram til) Navigere frem til en bestemt del av en bestemt side (HTML tager som det skal kunne navigeres fram til er: A, IMG, MAP, AREA, P, LI). Navigeringen fram til siden er ikke vesentlig (noen sider kan det er mange veier fram til) Navigere frem til ett bestemt dokument der navigeringen fram er vesentlig Navigere frem til en bestemt del av en bestemt side (HTML tager som det skal kunne navigeres fram til er: A, IMG, MAP, AREA, P, LI) der navigeringen fram er vesentlig Multiple choice. Ett av flere oppgitte alternativer skal velges. Det forutsettes at dette er alternativer utrykt gjennom tekst Mulighet til å sende ut mail til brukere/grupper Mulighet til å sende ut mail til alle brukere som ikke har gjennomført et kurs Mulighet til å hente ut statistikk Rammebetingelser Vi fikk tildelt egen kontorplass hos oppdragsgiver, som vi har benyttet oss av. Dette fordi da fikk vi et område som var kun avsatt kun til oss, og fordi kommunikasjonen med oppdragsgiver ble mer personlig. Oppdragsgiver satte opp følgende krav til verktøy og teknologier: Rammeverket skal bygge på servlet teknologi, men kan utnytte andre teknologier (f.eks. JavaScript) Rammeverket skal bygges med Java Rammeverket skal kjøre på Tomcat 5.0 Rammeverket skal benytte Microsoft SQL Server Workgroup Edition 8 (SP4) Rammeverket skal kjøre på Microsoft Windows 2000 Standard Server Rammeverket skal utvikles i Eclipse Subversion skal benyttes til versjon håndtering

6 Jira skal benyttes til oppgave og feil håndtering Rammeverket skal kun benyttes på web basserte systemer, og skal testes opp i mot Wireless Office 6 Rammeverket skal støtte SCORM Rammeverket skal støtte AICC Rammeverket skal støtte web systemet som kjører over HTTP Rammeverket skal støtte web systemer som kjører over SSL (Basic) Rammeverket skal støtte web systemer som kjører over SSL (Digest) Rammeverket skal støtte web systemer som kjører over SSL (NTLM) Rammeverket skal kunne kjøre over HTTP Rammeverket skal kunne kjøre over SSL Rammeverket skal støtte Internet Explorer 6.0 SP2 Rammeverket skal støtte Firefox 2.0 Rammeverket skal støtte Opera 9.10 Javadoc skal benyttes All dokumentasjon skal være på engelsk Rammeverket skal støtte internationalisering der default språk er engelsk WebWork kan benyttes til å bygge web sidene Om det er hennsiktsmessig kan Hibernate kan benyttes opp i mot databasen

7 1.4 Utviklingsprosessen Gruppen har delt inn prosjektet i tre faser: 1. Planlegging og analyse 2. Utvikle 3. Avsluttning Disse fasene er beskrevet i detalj avsnittene nedenfor Planlegging og analyse Denne delen består av å få en oversikt over prosjektet. I denne fasen av prosjektet lagde vi milepælsplan og kravspesifikasjon gjennom skolens krav om å lage et forprosjekt. Gruppen har også lagd forskjellige UML-modeller av programmet for å forklare og ha et visuellt bilde av hva programmet skal gjøre. Etter forprosjektet satte gruppen seg dypere inn i de forskjellige teknologiene som skulle benyttes og gjøre klart verktøyene. Gruppen har derfor brukt lengst tid på denne fasen av prosjektet Utvikle Fasene forberedelse og utvikling gikk inn i hverandre på slutten av forberedelsesfasen. Det har vært behov for å teste og gå tilbake til dokumentasjonen flere ganger for å komme til det endelige resultatet. I denne fasen har det vært vekt på å programmere, lese og dokumentere Avsluttning I denne fasen har gruppen foretatt tester på produktet, fullført sluttrapporten og forberdet muntlig presentasjon. Grunnet noen småfeil i produktet har også denne fasen gått med til å rette feilene som er funnet.

8 1.5 Planlegging og metode Vi valgte Rational Unified Process (RUP) som prosessmodell. RUP er en modell som delt inn i disse fire fasene: 1. Innledning a. Kravspesifikasjon b. Diskutere risiko og kostnader c. Design d. Planlegge 2. Utforming a. Planlegge arkitektur og systemkravene. b. Finne farer og problemstillinger og løse disse før man går videre i utviklingen c. Produsere en prototype d. Design e. Demonstrere produktet til interessenter 3. Bygging a. Programmering b. Utvikling av programmet c. Oppnå et produkt så fort som mulig, så bruker/interessent får teste produktet og komme med tilbakemeldinger 4. Overgang a. Går ut på å få testet ut en betaversjon for å finne feil og mangler som bør utbedres før det ferdige produktet blir klargjort b. Opptrening av brukere og de som skal vedlikeholde systemet, konvertere eksisterende databaser så de fungerer opp i mot det nye systemet c. Feilretting Som du ser i disse forskjellige fasene går det igjen en del av det samme. Design for eksempel er både i innledning og i utformingsfasen. Man går tilbake på det man har gjort tidligere og endrer etter man finner en bedre løsning. Det samme gjelder testing. Testing av prgrammet som utvikles blir konstant testet, og på denne måten er RUP en fleksibel prosessmodell for endringer Gruppnes bruk av valgt prosessmodell Gruppen har brukt en enkel versjon av RUP (Rational Unified Process) som fremgangsmåte. Ved å bruke denne prosessen har vi kunnet gå tilbake i tidligere faser og endre på tidligere utført arbeid. Grunnen til at gruppen har valgt å bruke elementer av prosessmodelen RUP er fordi den klassiske fossefallsmodellen ikke strekker til. Fossefallmetodens virkemåte sier at du ikke skal ha noen form for feiltagelser eller problemer i prosjektet og det ville derfor være naivt å velge denne prosessmodellen til vårt prosjekt. Ved å bruke RUP kan man flere ganger gå tilbake på tidligere utført arbeid og endre design som vi har gjort.

9 1.6 Valgte verktøy I tillegg til verktøyene og teknologiene nevnt i Rammebetingelser har vi benyttet oss av følgende verktøy og teknologier: Hibernate 3.2 WebWork Spring Framework 2.0 FreeMarker 2.3 Marcello bruker blandt annet Hibernate og Spring til vanlig, og ville derfor at vi skulle bruke disse verktøyene i vårt prosjekt. Vi fikk også et lite tips av Marcello at vi kunne bruke den siste versjonen av WebWork grunnet innebygd støtte for AJAX. WebWork anbefaler oss å bruke FreeMarker. Vi planlagte å benytte oss en del av AJAX Hibernate Hibernate er et såkalt Objekt/Relasjons Mapping- (O/R Mapping) verktøy utviklet for programmeringsspråket Java. O/R Mapping er en programmeringsteknikk som ligger som et lag mellom databasen og javakoden, og som brukes til å lage nye dataobjekter. Hibernate lar programmereren enkelt definere hvilke objekter som hører sammen og hvordan de skal presisteres på databasenivå. Man kan da konfigurere Hibernate til å fungere med alle større databaser som Oracle, MySQL, SQLserver, Sybase etc. Formålet med Hibernate er å skape et dataaksesslag i applikasjonen som tar seg av kommunikasjonen mellom databasen og applikasjonslaget. Se mer informasjon på Feil! Fant ikke referansekilden WebWork Vi har brukt WebWork som er et MVC rammeverk. MVC står for Model View Controller, og gjør det lettere for oss å programmere programflyten. MVC har en bestemt struktur og logikk i applikasjonen. Den hjelper oss til å få en bedre struktur på kodingen i programmet. Hvis alle bruker samme oppsettet, er det lettere å forstå hva andre og man selv har gjort. En av grunnen til at vi brukte WebWork var at den hadde innebygd støtte for AJAX. Se mer informasjon på Feil! Fant ikke referansekilden Spring Framework Spring Framework er et lettvektsrammeverk for applikasjonsutvikling i Java/J2EE. Spring skal først og fremst gjøre J2EE enklere å bruke. Vi har brukt Spring sin IOC (Inversion of control) for å opprette og konfigurere objekter. Et objekt kalles en Bean og består av en BeanDefinition. Alle Beans og avhengighetene dem i mellom defineres i en eller flere konfigurasjonsfiler (applicationcontext.xml) Se mer informasjon på Feil! Fant ikke referansekilden.

10 1.6.4 FreeMarker FreeMarker er et verktøy som brukes til å generere ut tekst. Alt fra HTML til selve kildekoden. Det er ikke en applikasjon, men noe som programmereren kan legge til i produktet sitt. Se mer informasjon på Feil! Fant ikke referansekilden.

11 1.7 Oppsett av utviklingsmiljø For å sette opp et utviklingsmiljø trenger en følgende: Java (J2SDK 1.4) Eclipse SDK 3.2 Apache Tomcat SUN Java Installering Last ned og installer SUN Java fra Feil! Fant ikke referansekilden Eclipse Eclipse er et open source plattform- uavhengigrammeverk som er fritt tilgjengelig. Eclipse er et program som består av flere utviklingsmiljøer IDE (Integtated Development Environment) til å utvikle Java. Tanken bak IDE er å gi et program som gir full oversikt over programmeringsprosessen. Eclipse er satt opp med et standard oppsett, men man har muligheter for å legge inn nye programtillegg (plugins) Installering Å installere Eclipse, er svært enkelt, og det gjøres nesten av seg selv. Det eneste man må gjøre er å laste ned en zip eller tar fil fra Eclipse sin nettside. Se Feil! Fant ikke referansekilden. Etter nedlastningen må man pakke ut filen og installere den på maskinen. Det er bare å følge det som står underveis av installeringen. For å kunne kjøre Eclipse, må det være installert Java JRE på maskinen fra før Programtillegg (plugins) Som nevnt tidligere kan man utvide Eclipse, ved å legge til andre tilleggsprogram. Dette er små program som utvider funksjonaliteten i Eclipse. Siden vi skulle jobbe med en webapplikasjon, måtte vi blant annet installere tilleggsprogrammet Web Tools Platform (WTP). Dette tilrettelegger utviklingen av blant annet Java webapplikasjoner og J2EE applikasjoner Ekstra bibliotek (Jar) Utsnyttelse av teknologiene Hibernate, Spring og WebWork ble muligjort ved å legge til jar filene deres i Eclipse manuelt Apache Tomcat Tomcat er en webserver som tolker JSP-kode og Java Servleter. Den siste versjonen av Tomcat støtter JSP 2.0 og Servlet 2.4-spesifikasjonene som er utviklet av SUN Microsystems. Tomcat bruker vi til å teste programmet vårt underveis. Tomcat har en innebygd http server og anses derfor som en frittstående webserver Installering Å installere Tomcat, er like enkelt som å laste ned eclipse. Man finner Tomcat sin nedlastningsfil på Feil! Fant ikke referansekilden., der får man valget å laste ned enten en zip eller tar fil. Etter at nedlastningen er ferdig, må filen pakkes ut og installeres på maskinen. Apache Tomcat forutsetter at Java JRE er installert på maskinen fra før.

12 For å bruke tomcat sammen med Eclipse, bruker vi tilleggsprogrammet Web Tools Platform (WTP).

13 1.8 Litteratur Litteraturen vi har benyttet oss av i prosjektet har for det meste omhandlet WebWork og Hibernate. Vi har brukt kilder som bøker og internettsider. Vi har hatt store fordeler av internettsider som forum. En oversikt over kilder finner du i kapittel Feil! Fant ikke referansekilden. Feil! Fant ikke referansekilden..

14 1.9 Prosjektorganiseringen Gruppen har hatt en stor frihet fra oppdragsgivers side. Det har ikke vært noen ukentlige møter med oppdragsgiver. Gruppen har hatt et avslappende forhold med oppdragsgiver hvor det ikke har vært noen form for forpliktelse til å vise produktet, men mere en avslappende tone med snakk rundt i korridorene og ved lunsj pauser Prosjektserver Vi fikk en server ferdig satt opp fra Marcello med subversion, Micorsoft SQL Server Workgroup Edition 8 (SP4), Microsoft Windows 2000 Standard Server, og Apache Tomcat 5.0. Ved bruk av subversion får alle medlemmer på gruppa tilgang til de seneste oppdaterte dokumenter Milepælsplan Under planlegging og analyse perioden lagde gruppen en milepælsplan. Denne planen har gjentatte ganger blitt endret og sprukket tidsmessig. Dette grunnet tidspress fra andre fag og ikke minst å lære seg de nye teknologiene. Gruppen har underestimert tid vi ville bruke på å sette oss inn i de nye teknologiene. Milepælsplanen har derfor ikke fungert til dens hensikt, men i stedet fungert som en liste over hvilke oppgaver som er viktigst. Denne planen er lagt med på den vedlagte CD en. Se Feil! Fant ikke referansekilden Prosjektets webside Gruppen fikk tildelt et webområde av skolen til å opprette en webside for prosjektet. Her har vi lagt ut informasjon til andre gruppemedlemmer og slik at veileder kan se hva vi driver med under de stille periodene. Adressen finner du i Feil! Fant ikke referansekilden.

15 1.10 Evalueringer av prosjektperioden Evaluere en periode er et godt verktøy for å se hva man kan gjøre bedre, bli mere effektiv i fremtiden, og bli klar over sine svakheter. Vi har skrevet om prosessen og fremgangen i prosjektet under avsnitt Utfordringer i prosessen. I tillegg har vi skrevet hva vi har lært og hva vi ville ha gjort annerledes i prosjektet i avnsitt Hva vi har lært og Hva vi ville gjort annerledes. På denne måten kan vi vidreutvikle våre ferdigheter på de punkter hvor vi har feilet eller ikke vært optimal Utfordringer i prosessen Da vi startet på prosjektet var vi optimistisk og mente at dette hadde vi taket på og den nødvendige kompetansen. Vi startet i begynnelsen med å sitte sammen for å få en oversikt over prosjektet og at alle sammen i gruppen var enige om hva produktet var. Vi merket fort at enkelte ikke forstod helt hva det handlet om, og derfor måtte vi gå gjennom flere ganger hva dette prosjektet handlet om. Vi merket også at enkelte trodde de hadde skjønt alt ved produktet, men det var ikke tilfellet. Etter alle i gruppa hadde skjønt produktet Marcello ønsket, gikk vi på analysefasen. Vi var tidlig ute i denne fasen i god tro om at det ville gi oss bedre tid på slutten av prosjektperioden. Etter å ha tegnet Use-Casene, databasemodellen, klassediagramene og andre modeller fikk vi et tips fra oppdragsgiver om å bruke WebWork. Den orginale planen anngående verktøy var å bruke XML og XSL, og kjøre på en helt enkel Java som vi har lært på skolen. Vi levde i en god tro tidlig i prosjektet på at dette ville fungere. Da Marcello kom med et tips om WebWork satte gruppen seg ned med å lese på MVC (Modell Viev Controller). Siden det nå var snakk om å lage rammeverket i WebWork måtte vi også se på IOC-delen av Spring. Grunnen til dette var at vi fikk tilbakemelding fra Marcello om at det var dette som ble brukt i deres firma, og var veldig utbredt i andre firmaer også. De mente det var lurt å bruke tid på å sette seg inn i det under hovedprosjektet da vi helt sikkert ville møte det ute i arbeidslivet. Under samme samtale kom også Hibernate opp. De benytter seg også av dette verktøyet og derfor ønsket de at vi brukte dette også. Hibernate er veldig utbrett og nyttig å kunne. Etter å ha lest mer på WebWork oppdaget vi at vi måtte sette oss inn i FreeMaker også. På dette tidspunktet følte vi at det gikk en inflasjon i nye teknologier og nytt lesestoff. Enkelte i gruppen mistet litt motet og følte at det ikke var noen fremgang i prosjektet, men heller at vi tok flere steg tilbake. Fra å ha ingen nye teknologier hadde vi nå tre omfattende nye teknologier og et klassediagram som det måtte gjøres store forandringer på. Vi leste mye i denne perioden på disse verktøyene for å skaffe oss forståelse for deres virkemåte, og hvordan de skulle jobbe sammen. Det vi er redd for ved å ha brukt så mange nye teknologier er at vi ikke har god nok kjennskap til de og dermed ikke har fått utnyttet fordelene ved de. Etter all den informasjonen vi har lest oss opp på og problemer vi har støtt på, føler vi at vi har tatt steget ut av lekekassen og blitt tre dyktige datafolk. Hovedprosjektet har gjort sin nytte ved å vært illprøven før vi går ut i arbeidslivet.

16 Problemer i prosessen Som nevnt tidligere følte vi oss usikre på om vi klarte å benytte oss godt nok av alle de nye teknologiene. For eksempel tenkte vi oss ikke godt nok om da vi skulle benytte oss av mulighetene i Hibernate. De fleste av klassene våre som er koplet opp i mot Hibernate inneholder lister av andre klasser (for eksempel klassen no.marcello.terminaltor.user.company inneholder listen users). Det var en stund da vi gjorde kall mot selve databasen (med hjelp av Hibernate) for å finne alle medlemmene i denne listen: public List getallusersforcompany(final Long id) { try { HibernateCallback callback = new HibernateCallback() { public Object doinhibernate(session session) throws HibernateException { Query q = session.createquery("from User user where company_id=" + id.intvalue()); return q.list(); } }; return (List)getHibernateTemplate().execute(callback); } catch(exception e){ e.printstacktrace(); } } return null; Dette er en veldig tungvind måte å finne disse medlemmene på. Etter å ha tenkt oss om, fant vi ut at en mye enklere metode var å benytte seg av mulighetene som er innebygd i Java objektene; nemlig iterator. I koden nedenfor blir listen omgjort til Map for å kunne bli brukt i et HTML select objekt. public Map getallusersforcompany() { Map map = new HashMap(); if(this.company!= null && this.company.getusers()!= null) { Iterator iter = this.company.getusers().iterator(); User user; } while(iter.hasnext()) { user = (User)iter.next(); map.put(user.getid(), user.tostring()); } return map; Da vi begynte å programmere så vi at vårt første design av utseende var dårlig tegnet. Derfor slo vi sammen enkelte funksjoner i ett bilde for at brukeren skulle slippe å gjøre dobbelt opp med jobb og bli forvirret av mange flere linker i menyen. For å se forskjellen mellom det førte designet og det endelige, gå til Feil! Fant ikke referansekilden. Feil! Fant ikke referansekilden. og Feil! Fant ikke referansekilden. Feil! Fant ikke referansekilden..

17 Vi har jobbet veldig mye rundt det med å kople seg opp i mot den eksterne web serveren. Vi jobbet en god stund ut i fra tanken om å finne alle referansene til den eksterne serveren, for så å bytte ut eller legge til en ekstra sti forran denne. Se alternativ 1 på Figure 1 - Forandring på HTML kode. På alternativ 1 henter vi HTML kode med blant annet koden <img src= /wo/bilde001.png /> i. Med hjelp av regulære uttrykk fant vi og la til TerminalServlet forran stien. TerminalServlet servleten var da satt opp til å hente ned /wo/bilde001.png fra den eksterne web siden, og standard servlet var satt til org.apache.catalina.servlets.defaultservlet. Dette fungerte godt nok så lenge det var snakk om vanlige HTML tager. Det ble riktig nok en god del forskjellige regulære uttrykk for å klare å fange opp og behandle de forskjellige tagene, men det virket. Problemene kom da vi begynte å se på selve JavaScript filene og forskjellige parametere. Det viste seg å være veldig vanskelig å finne alle referanser til den eksterne web serveren inne i JavaScript koden. Og når da JavaScriptet la til en rekke forskjellige parametere på referansen, ble det umulig å fortsette i samme sti. Vi måtte finne på noe som gjorde dette mye enklere. Løsningen ble å bytte om på hva som var standard servlet. Ved å sette TerminalServlet, som tolker alle forespørsker som kall til den eksterne web siden, til standard servlet løste vi på et blunk nærmest alle våre problemer med å finne referansene. Nemlig at vi ikke trenger å finne de, for alle forespørsler går automatisk til den eksterne web siden. Se alternativ 2 på Figure 1 - Forandring på HTML kode. Men med å bytte om på standard servlet, fikk vi plutselig problemer med å nå lokale filer. Vi måtte da legge til org.apache.catalina.servlets.defaultservlet som en egen servlet og spørre etter denne når vi trengte å nå lokale filer. Alternativ 2 er dermed alternativ 1 snudd om. Figure 1 - Forandring på HTML kode <?xml version="1.0" encoding="utf-8"?> <web-app id="terminaltor" version="2.4" xmlns=" xmlns:xsi=" xsi:schemalocation="

18 <display-name>terminaltor</display-name> <filter> <filter-name>webwork</filter-name> <filter-class>com.opensymphony.webwork.dispatcher.filterdispatcher</filter-class> </filter> <filter-mapping> <filter-name>webwork</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <servlet> <servlet-name>terminalservlet</servlet-name> <servlet-class> no.marcello.terminaltor.terminal.terminalservlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet> <servlet-name>tomcat</servlet-name> <servlet-class> org.apache.catalina.servlets.defaultservlet </servlet-class> <init-param> <param-name>debug</param-name> <param-value>1</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>tomcat</servlet-name> <url-pattern>/terminaltor_local/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>terminalservlet</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> <listener> <listener-class>org.springframework.web.context.request.requestcontextlistener</listenerclass> </listener> <listener> <listener-class>org.springframework.web.context.contextloaderlistener</listener-class> </listener> </web-app> Som en ser av web.xml koden listet ovenfor er altså TerminalServlet standard servlet. Et kall mot kaller da på TerminalServlet som henter ned /wo/bilde001.png fra den eksterne web serveren, mens et kall på

19 gir den lokale filen /wo/bilde001.png Hva vi har lært Som nevnt tidligere føler vi at vi har lært utrolig mye i denne prosjekt perioden. Vi har blant annet lært om arkitekturene IOC, MVC og DAO. Før prosjektet var dette fremmedord for oss, nå er det nermest dagligtale. Vi dermed også satt oss godt inn i Spring, Hibernate og WebWork. Dette er kunnskap vi kommer til å god bruk for vidre i arbeidslivet. Vi lærte også at det tar tid å sette seg inn i nye arkitekturer og tekologier. Det krever at en leser mye, og en del prøving og feiling i kodingen. Vi lærte at i prosjekter må en ta en grundig avveining om en skal ta i bruk nye tekologier, eller benytte noen en allerede kan. Som vi erfarte, så kan en bli overasket over hvor lang tid det faktisk tar å sette seg inn i nye teknologier. Vi har fått erfaring i å utføre et stort prosjekt, med en kunde som forventer et produkt innen en gitt tidsfrist. Vi har erfart hvordan det er å planlegge uten å kjenne godt nok til alle tekologiene. Vi har lært at estimater kan det være lurt å gange med for eksempel PI, for å komme nærmere det en faktisk bruker av tid. Dette fordi det er veldig vanskelig å kunne forutse alle problemer og hindringer på forhånd. Prosjekt medlemmene har også fått mer selvinsikt, og vet nå hva vi har lyst til å jobbe med framover. Enkelte medlemmer trives bedre med å ha en mer styrende rolle, med mindre koding og analyse. Mens andre medlemmer igjen trives bedre med mer koding og mindre styring Hva vi ville gjort annerledes Noe av det vi ville ha gjort anderledes var å utnytte forprosjekt perioden bedre, for vi ser i etterkant at vi gjorde en for dårlig jobb i denne perioden. Vi klarte ikke å identifisere alle de forskjellige teknologiene vi trengte, noe som gjorde at vi måtte bruke mye tid i selve prosjekt perioden til å sette oss inn i de. En del av klasse diagrammene måtte også forandres på grunn av disse nye tekologiene. Prosjekt gruppens medlemmer tok også andre fag under prosjekt perioden. Vi erfarte at hovedprosjektet krevde mer tid enn planlagt, så om vi kunne ha gjort noe anderledes så hadde det vært å enten avgrense hovedprosjektet mer eller ta færre/ingen fag ved siden av.