IMT Mappe 1 Open Source Software Development Petter Schultz Jørn André Myrland

Størrelse: px
Begynne med side:

Download "IMT3102 - Mappe 1 Open Source Software Development 070327 Petter Schultz 080531 Jørn André Myrland"

Transkript

1 IMT Mappe 1 Open Source Software Development Petter Schultz Jørn André Myrland

2 Innholdsfortegnelse 1 Introduksjon Historie Situasjonen i dag Infrastruktur Lisensiering Community Prosjekt styring Bug rapportering/tracking Mailinglist Dokumentasjon Utviklingsprosessen Systemutviklingsmetode Versjonskontroll Bug submission/fixing Normer og regler Kodestandard Sikkerhet Distribuering Konklusjon Kilder... 15

3 1 Introduksjon I denne mappeinnleveringen skal vi se på 3 utvalgte OSSD-prosjekter og diskutere de opp mot hverandre, samt Vogels bok om OSSD. Vi har valgt følgende tre OSSD-prosjekter: Joomla! (et stort og kraftig prosjekt), ffdshow (et døende prosjekt) og VirtualBox (et kommersielt støttet prosjekt). Joomla!1 er et publiseringsverktøy for websider (Open Source Content Management System, forkortet til Open Source CMS). Joomla! inneholder en rekke integrerte nøkkelfunksjoner (komponenter). I tillegg har brukere/utviklere mulighet til å skrive (og installere) egne utvidelser til Joomla! uten å modifisere Joomla!-kjernen. ffdshow2 er en medie-dekoder/-enkoder hovedsaklig brukt for rask og høy kvalitets dekoding av video. De første versjonene av ffdshow ble publisert i april 2002, som et alternativ til DivX ;-) 3.11 og DivX VirtualBox3 (Oracle VM VirtualBox) er en kraftig x86 virtualiserings løsning som er beregnet både på server desktop og "embedded" bruk. Den tilbys i to utgaver: Open source: Gratis til personlig bruk og sluppet under GNU GPL v2 lisensen. Closed source: Enterprise utgave som er beregnet for profesjonelt bruk. Det er open source utgaven vi skal ta for oss i dette prosjektet, men vi vil også komme litt inn på forskjellen mellom de to produktene. 1.1 Historie Joomla! var resultatet av en fork av Mambo (et tilsvarende publiseringsverktøy), iverksatt av et team av utviklere (senere Joomla! development team ) august Opphavet til denne forken skjedde fordi det nevnte utviklings-teamet var uenig med at Mambo dannet en non-profit stiftelse (med angitt formål å finansiere prosjektet, og beskytte den mot søksmål) hvilket inkluderte, blant annet, bestemmelser som krenket kjerne verdier for åpen kildekode. Joomla! development team opprettet et nettsted kalt OpenSourceMatters.org for å distribuere informasjon til brukere, utviklere, webdesignere og samfunnet generelt. Nettstedet vokste raskt og skapte kontroverser innenfor fri programvare om definisjonen av "open source". I september 2005 ble et navn angitt for prosjektet; "Joomla!". Det er den engelske stavemåten av ordet swahili jumla betyr alle sammen eller som en helhet. Og har siden den tid vokst til å bli det mest populære frie publiseringsverktøyet i dag4. 1 Joomla!: ffdshow: 3 Virtualbox: 2

4 Ffdshow-prosjektet ble registrert på SourceForge mai 2002, av en bruker ved navnet Milan Cutka. Prosjektet ble gradvis populær i 2004, som et alternativ til andre medie-dekodere/enkodere. Rundt 2006 stanset prosjektlederen, Milan Cutka, utviklingen for prosjektet, men brukere fortsatte å laste ned programvaren. Dette resulterte i en fork; FFDshow-tryout, hvor bugfixes, nye funksjoner, stabilitet-oppdateringer og codec-oppdateringer fortsetter. Fra 2006 til dagens dato er det gjennomsnittlig nedlastinger av ffdshow per måned, men antallet er på vei ned. Open source utgaven av VirtualBox ble for første gang utgitt den 15. januar 2007, da den tidligere kun hadde vært tilgjengelig som proprietær programvare. Den originale utvikleren av virtualbox het innotek, som i februar 2008 ble kjøpt opp av Sun microsystems. Sun ble på sin side nylig (januar 2010) kjøpt opp av Oracle. 1.2 Situasjonen i dag Joomla! er i dag det mest kraftfulle og populære Open Source CMS med 15 millioner nedlastinger siden mars 2007, over registrerte medlemmer og har i gjennomsnitt nedlastinger per dag. Open Source Matters er i dag en non-profit organisasjon, registrert i USA, skapt for å tjene de finansielle og juridiske interesser for Joomla prosjektet. Ingen er per dags dato lønnet for å jobbe med Joomla! kjernen, dvs. alt arbeid vedrørende kjernen er frivillig. Per dags dato jobber Joomla! med en beta versjon (v1.6) som skal forbedre dagens stabile versjon (v1.5) med en rekke nye funksjonaliteter. Ffdshow er, som nevnt, et døende prosjekt. Brukere fortsetter å laste ned programvaren (siste stabile versjon utgitt i 2004), men utviklerne av prosjektet har kapitulert. Prosjektet mister brukermassen fordi FFDshow-tryouts er et bedre alternativ, siden det er et prosjekt med aktive utviklere. VirtualBox sin siste stabile utgave ble sluppet 6. august Det er ingen pre-release eller beta tilgjengelig per i dag. Tidligere år har de sluppet mellom 9 og 16 versjoner på ett år, men hittil i 2010 er det kun sluppet 4. Dette kan være et tegn på at Oracle nedprioriterer OSE utgaven? 4 Joomla på Wikipedia:

5 2 Infrastruktur Tabell over kritisk infrastruktur: Joomla! Lisens GNU GPLv2 (<) Real-time chat Ja Forum Ja Webside Ja Bug tracking GForge Mailing-list Ja (men lukket) Versjon Ja Kontroll Eksterne Ja communities ffdshow GNU GPLv1 Nei Nei Nei SourceForge Ja VirtualBox PUEL / GNU GPLv2 Ja Ja Ja Egen løsning Ja Ja Ja Nei Nei Mer om disse punktene nevnes i underpunktene. 2.1 Lisensiering Joomla! er lisensiert under GNU General Public Lisence versjon 2 eller senere versjon5. Dette betyr at hvis en ny GPL versjon gir ytterligere tillatelse, vil tillatelsen vil bli tilgjengelig umiddelbart for alle brukerne av Joomla!. Men hvis en ny GPL versjon har strammere krav, vil det ikke begrense bruken av den gjeldende versjonen av Joomla!, fordi det kan fortsatt brukes under GPL versjon 2. ffdshow som de andre prosjektene lisensiert under GNU GPL, versjonsnummer nevnes ikke eksplisitt men da prosjektet ble avsluttet i 2006 er det rimelig å anta det dreier seg om versjon 1. Virtualbox kommer i to utgaver og de er underlagt hver sin lisens. Såkalt "dual licensing". OSE utgaven er underlagt GNU GPL v2. Den fulle utgaven er proprietær og vi har derfor ikke innsyn eller redistribusjonsrett til denne koden. I denne utgaven er det også lagt til noen ekstra funksjoner som en gulrot til de som kjøper den. Begge utgavene er gratis til personlig og akademisk bruk men den fulle utgaven må bedrifter og andre som vil bruke den i profesjonelt øyemed betale for. De mener "dual licensing" gir dem "the best of both worlds", quote: The open-source community gets more high-quality free software at no cost, while businesses can rely on quality support from our first-hand developers. Both worlds profit from each other: The commercial licenses support both our business, and the open-source community, and vice versa. Utdrag fra FAQ til Virtualbox.6 Essensen i GPL er at et program som distribueres i kompilert form også skal være tilgjengelig for brukerne i form av kildekode alle filer som er nødvendige for å produsere den 5 6 GNU GPL:

6 distribuerte versjonen skal være tilgjengelig for fri bruk. Hvis programkode som er GPLlisensiert inkluderes i et annet program, må også dette programmet lisensieres under GPL, noe som av mange beskrives som en «virus-effekt». Ifølge Richard Stallman, er den store endringen i GPLv2 "Liberty or Death"-bisetning, som han kaller det - 7. Denne delen sier at man ikke har lov til å distribuere GPL-programvare, dersom andre brukeres frihet krenkes. For eksempel hvis en juridisk kjennelse slår fast at han eller hun kan bare distribuere programvaren i binær form. I innledningen til GNU GPL konstateres: When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things."- Utdrag fra GNU GBL 7. I følge Vogel er den mest brukte lisensen i forbindelse med Open Source; GNU GPL - lisensen. Dette er nok en av grunnene til at nevnte prosjekter har valgt GPL, siden potensielle brukere og utviklere mest sannsynlig kjenner til lisensen. En annen grunn er at denne lisensen beskytter koden mot å bli brukt i properitære programmer. Virtualbox har løst dette ved å implementere PUEL-lisensen i den kommersielle versjonen. PUEL er en Open Source lisens som ikke tillater redistribusjon, men er samtidig kompatibel med GPL-lisensen. Lisensvalget gjør det også mulig for utviklere å kommersialisere utvidelser til produktet. Dette er mye brukt i forbindelse med Joomla!. 2.2 Community Joomla! er nødt til å bidra med et spekter av community-portaler, på grunn av prosjektets størrelse og etterspørsel. Brukere/utviklere må ha en plass å referere til, ved eventuelle spørsmål/problemer. Disse brukes også i forbindelse med forslag til forbedring. IRC er en portal som benyttes, hvor man finner en blanding av brukere og utviklere på kanalen #joomla på freenode-serveren. Kanalen #joomla-dev brukes også, og er dedikert til utviklere. En annen portal som benyttes ofte er forum. Dette benyttes til alt fra utviklings-diskusjoner til bruker-support. Joomla! har over registrerte forummedlemmer fra hele verden, og dette kan være en språklig utfordring. Derfor er det flerspråklighet-støtte i forumet. Joomla! har user groups for områder, for eksempel: Joomla! Association Norway! er en Norsk brukergruppe. Det er totalt 276 registrerte og godkjente brukergrupper for Joomla. Disse fungerer som eksterne communities for sitt område. 7

7 Fig 2-1: Kart over Joomla! user groups. Siden Joomla! er et CMS for websider, er det jo selvsagt at de bruker Joomla! på sin egen hjemmeside. Denne fungerer som et bindeledd i hele community et. Fra denne siden har man tilgang til forum, dokumentasjon, community, osv. Joomla! bruker i tillegg sosiale medier (Facebook og twitter) som en informasjonskanal til brukere. ffdshow kommer dårlig ut i dette punktet. Prosjektet har ingen form for user-groups, RTC, forum eller engang en egen hjemmeside. De bruker to versjoner av versjonskontroll, SVN og CVS. Mer om dette i punkt 2.5. VirtualBox bruker blant annet forum, IRC og mailing-list som community-portaler. Forum brukes som support for brukere og der kan også andre brukere bidra med å hjelpe de som har problemer. Det er det første stedet du skal henvende deg om du har problemer med bruken av programmet. Mailing-list er også brukt for å sveise sammen community et. Mer om dette i pkt 2.5. VirtualBox opererer også med flere IRC kanaler for chat mellom brukere og utviklere. Det er ikke organisert noen form for grupper i virtualbox og det virker som det blir opp til hver enkelt å bidra, uten å få noen følelse av at det er et fellesskap av utviklere eller samarbeid mellom dem. Her burde organiseringen skjerpes. I følge Vogel er det viktig at besøkende på siden til det aktuelle prosjektet, kan komme i kontakt med de involverte i prosjektet. Her ser vi at et av prosjektene skiller seg helt ut ifra de andre. I ffdshow blir kontakten mellom alle parter dårlig ivaretatt, da de har utelatt flere av Vogel s kritiske punkter for hvordan et prosjekt skal lykkes. De to andre prosjektene som har fulgt Vogels råd lever fortsatt i beste velgående men da disse er så fundamentalt forskjellige fra ffdshow er det ikke mulig å konkludere med noe.

8 Vogel nevner også at brukere og utviklere bør separeres i starten av prosjekter, for å holde kontroll på community et. Joomla! og VirtualBox er gamle prosjekter, men har fortsatt å holde de separat. 2.3 Prosjekt styring Joomla! er delt opp i to Working Groups ; Production og Community (med flere subgrupper) og hundrevis av frivillige deltar i disse. Hver Joomla! Working Group har et leader-team, og sammen former de Joomla! Leadership team. Joomla! er ikke helt demokratisk. Det vil si at Joomla! Leadership team styrer hele butikken. Derimot kan avgjørelser være basert ut fra meninger/avstemninger i community et. Alle disse gruppene, som jobber med Joomla! kjernen, opereres av frivillige (ikke betalte). ffdshow var et veldig lite prosjekt hvor det var hovedutvikleren (Milan Cutka) som var ildsjelen og administratoren som hadde råderett over commits. Det er registrert en annen utvikler på prosjektet men hans rolle i prosjektet er ikke listet. Andre utviklere har forsøkt å bidra, men disse bidragene har ikke blitt akseptert. Dette er et slags one man rodeo. Virtualbox fungerer slik at alle som vil kan bidra, men alle bidrag skal sendes inn til Oracle for gjennomgang og godkjenning. Det er kun de ansatte i Oracle som har skriverettigheter til (den offisielle) koden. Det er ingen informasjon om Oracle sitt interne hierarki og det er ingen utenfor Oracle som har noe reell makt. Brukere og hobbyutviklere kan komme med ønsker om funksjoner og liknende men det er helt og fullt opp til Oracle om dette blir fulgt opp. Her har vi tre forskjellige styringsformer, som rangerer fra ene diktator til et konsensusbasert demokrati. Diktator-styreformen som brukes ffdshow er vanlig for nystartede Open Source prosjekter, men etter hvert som prosjektet vokser må man tilpasse styringsformen for å ta hensyn til de øvrige utviklerene. Dette ser vi at ikke har skjedd i ffdshow, som kan være en medvirkende faktor til at prosjektet gikk dukken. Ved å ha en litt mer demokratisk tilnærming (som Joomla!), vil man åpne for at utviklerene føler mer tilhørighet til prosjektet. Dette kan igjen føre til mindre sannsynlighet for frafall av utviklerne og forking. Virtualbox stiller her i en litt egen klasse siden det ikke er noen fare for frafall av coreutviklerne og at community miljøet rundt er mindre viktig. 2.4 Bug rapportering/tracking Joomla! har en egen bug-tracker (GForge) på websiden joomlacode.org, men for å rapportere en bug må man være registrert bruker. Det henvises også til Joomla! s wiki-side for å lære mer om hvordan man skal rapportere bugs via trackern og hvilke hensyn man må

9 ta. For eksempel må man sjekke om buggen er rapportert fra før, slik at man unngår duplisering8. Per dags dato er det totalt 5373 bugs registrert i trackeren, hvorav 609 ikke er løst enda. Bugs er kategorisert i kategorier fra 1 til 6, hvor 1 er høyeste prioritert. Gjennomsnittlig tid brukt for å løse bugs er avhengi av hvilken prioritet og størrelse for hver bug, men det er alt fra 1 dag til 3 måneder. Men i forhold til løste bugs kontra åpne bugs, klarer Joomla! å ta unna strømmen (tatt i betraktning at bugs fra stabil- og beta-versjon er blandet). ffdshow opererer med en public bug tracker for innrapporteringer men det er ikke satt opp noen regler/retningslinjer for rapporteringen. Derfor er det stor sannsynlighet for at en bug kan få mange tickets og det hele kan bli veldig rotete. Virtualbox bruker samme tilnærming som Joomla! ang. bug tracking, med bruk av egen bug tracker og retningslinjer. Virtualbox har per dags dato 2601 åpne bug tickets og får inn i snitt rundt 4-6 nye hver dag. Siden de har betalte ansatte for å jobbe med dette blir det fikset en del bugs hver dag (2-4). Vi ser her at Joomla! og Virtualbox har gode rutiner og klare retningslinjer for bugrapportering. Dette gjør denne prosessen smidigere og lettere å vedlikeholde med mindre gnissninger mellom brukere og utviklere. Uten disse retningslinjene (ffdshow) ender bug trackeren opp med mange duplikater og frustrerte utviklere. 2.5 Mailinglist Joomla! har, og bruker, mailing-list. Men denne mailing-listen er lukket kun for administratorer av working-groups. ffdshow har lagt ut tre mailing-lister: User: Satt opp for kommunikasjon med brukerne. For at de skal få svar på evt. spørsmål. CVS: Denne listen er satt opp som en alternativ versjonskontroll hvor utviklere blir fortløpende oppdatert om patcher. Developer: mailinglist for alt som er relatert til utviklingen av codecs. VirtualBox bruker fire forskjellige mailing lists tilknyttet miljøet: Announcements list: Brukes blandt annet for å annonsere nye utgaver av programmet. Developers list: Dette er listen for alle som er med på å utvikle virtualbox og alle som bruker APIet deres. Track tickets list: Dette er en read-only liste som brukes for å finne informasjon fra bugtrackeren. Brukerdiskusjons-listen: Dette er community mailing listen. Mailing-list kan brukes til forskjellige formål. Både VirtualBox og ffdshow bruker mailing-list for å holde kommunikasjonen uniont mellom utviklere og brukere. Nødvendigheten av 8 Joomla s bug-utfyllingsguide:

10 mailinglist differerer mellom VirtualBox og ffdshow, da dette er den eneste kommunikasjonskanalen til ffdshow. Joomla! har en langt mindre utstrakt bruk av mailinglist. Som på bakgrunn av alle de andre kommunikasjonskanalene kan virke som en mer ryddig løsning, da brukere ikke trenger å forholde seg til så mange alternativer. En bakdel med denne løsningen er at utviklere som ønsker å bugfikse, ikke får tilgang til en Track tickets list (som VirtualBox har). 2.6 Dokumentasjon Joomla! er utrolig godt dokumentert. Det er et eget team satt av kun for å dokumentere kjernen av Joomla!. All dokumentasjon finnes på websiden På denne siden finner man det meste man leter etter, både som utvikler og bruker. Nettsiden til Virtualbox inneholder det meste man kan ønske seg av dokumentasjon, det er lagt opp på en oversiktlig måte men har ingen "samleside" for alt av dokumentasjon. Det ligger litt spredt utover hjemmesiden deres. ffdshow har ikke oppgitt noen webside eller dokumentasjon. Vogel sier at dokumentasjon er et kritisk punkt for et Open Source prosjekt, men dette er også et punkt man generelt ikke ser viktigheten av og derfor nedprioriterer det. Dette har Joomla! (i stor grad) og VirtualBox klart å opprettholde. Det merkelige her, er at ffdshow i komplett mangel på dokumentasjon har blitt forket og utviklingen gjennopptatt (props til ffdshow-tryouts). 3 Utviklingsprosessen 3.1 Systemutviklingsmetode Joomla! bruker en type inkrementellsystemutviklingsmetode9. Hvor hver pil (se fig. 3-1) foregår som iterasjoner. Utviklingsprosessen er oppdelt i tre faser (se fig. 3-1), Alpha fasen, Beta fasen og Stabil fasen. I Alpha fasen skjer planleggingen, med innspill fra community et. Innspillene tar form i White Papers, som hvem som helst kan skrive. Disse papirene er såkalte formelle funksjonsforespørsler, altså hva man ønsker seg i Joomla!. Disse papirene må 9 Utviklingssyklus: Fig 3-1: Utviklingsprosess for Joomla!

11 inneholde hvorfor funksjonsforespørselen bør realiseres, hva som må gjøres for å nå satte målsetninger og hvordan dette er tenkt å realiseres. Hvilke av disse White Paper -ene som skal realiseres, er opp til Joomla! Leadership Team å bestemme. Videre i denne fasen settes disse planene til liv, i form av utvikling. I Beta fasen går man direkte fra å primært utvikle løsninger, til testing og dokumentering av disse. Denne fasen skjer også i samspill med community et, hvor de kan bidra med testing og forslag til forbedring. I Stabil fasen slippes det ut en eller flere release canditates. I denne fasen er koden betraktet som stabil, og de siste bug ene blir funnet og rettet opp. Mye oppmerksomhet i denne fasen går til å promotere den nye versjonen. ffdshow har ingen informasjon om SU metode, men ut i fra tidligere releaser kan vi se at utgivelsene varierer tids- og størrelsesmessig. Ergo, det er ingen strukturert tidslinje for utviklingen. Ut i fra dette er det rimelig å anta at Code & Fix er metoden som brukes. Virtualbox nevner ingenting om deres utviklingsmetode eller modell og mangler som nevn tidligere en god måte å organisere utviklergrupper. Dette kan til sammen bidra til at mange frivillige utviklere faller fra. Selv om ikke alle Open Source prosjekter har en godt dokumentert systemutviklingsmetode, trenger det nødvendig vis ikke å bety at den er relevant for alle i utviklingsmiljøet. I Joomla! s sammenheng, er de avhengi av community et i forhold til feature-request og testing. Resten av selve utviklingen skjer av kjerne-team. I de andre to tilfellene virker det som at community et ikke trenger å være så integrert i utviklingsprosessen. 3.2 Versjonskontroll Joomla! bruker Sub Version Repository (SVN) som versjonskontroll. Det er kun Joomla! Core Development Team som har lese-/skrivetilgang til denne repository en, mens alle andre lesetilgang. ffdshow bruker to utgaver av versjonskontroll. De bruker den som er innebygget på sourceforge sine sider og CVS til bruk i mailinglists. Virtualbox fungerer identisk med joomla! på dette området, kun de ansatte i oracle har skrivetilgang. Her er det ikke mye forskjell mellom prosjektene, det later til å ha blitt ganske standardisert etter hvert. Den eneste som stikker seg litt ut er ffdshow som kjører to samtidige versjonskontroller. Dette er ikke nødvendigvis udelt positivt da det kan skape en del forvirring rundt hvilken en skal forholde seg til og hvor den mest oppdaterte til enhver tid befinner seg.

12 3.3 Bug submission/fixing Joomla! bruker SVN ved bug submission. Utviklere som vil rette opp bug en, som ikke har skrive tilgang til repository en, må endre filene lokalt, lage en patch av de lokale filene og laste opp patchen via bug-trackeren til Joomla!. Denne submission en følger så the golden path 10, som vil være Open Confirmed Pending Ready to Commit Fixed in SVN. Validering og testing skjer av Joomla! Bug Squad og Joomla! Test Team. ffdshow bruker bugtracker på sourceforge, her kommer de inn og noen av de blir fikset. Dette er da kun en liten andel og de resterende står fortsatt som åpne. Det er ingen måte å vite hvem som har rettet feilene fordi alle bugs som har status closed står som rettet av nobody. Virtualbox benytter seg ev en public bug tracker som oppdaterer en mailinglist med nyoppdagede bugs. Deretter er det opp til de som abonnerer på denne mailinglisten å fikse de. Dette er enten i community eller noen av de ansatte i Oracle. Ifølge Vogel er det viktig med god håndtering/struktur rundt bugtrackingen. Joomla! følger dette i stor grad da de har strømlinjeformet prosessen på en strukturert og ryddig måte. Virtualbox og ffdshow har en noe mindre omfattende modell hvor de merker tilstanden med open og closed. Her er det rimelig å anta at Joomla! har den klart mest effektive måten å håndtere dette på, mens Virtualbox s ess i ermet er at de har betalte utviklere til å gjøre dette. 3.4 Normer og regler I Joomla! følger man et sett med normer og regler. Som bidragsyter er Volunteer Code of Conduct 11 et sett med forventede regler/normer man skal følge. Disse reglene er avledet fra Ubuntu Code of Conduct. Nevnes ikke for virtualbox eller ffdshow. Med mange utviklere burde dette sees på som en absolutt nødvendighet, men som vi ser er ikke dette nevnt i verken Virtualbox eller ffdshow. Begge de skyldige parter kan delvis unnskyldes da virtualbox sannsynlig vis har dette internt hos seg og the one man rodeo bare går sin gang. 3.5 Kodestandard Som utvikler og bidragsyter for Joomla! forventes det at man følger en gitt kodestandard, spesifisert her: Det er ikke gitt noen kodestandard for virtualbox, men det skal kodes i c++ og det finnes instruksjoner i en pdf fil med en SDK programming guide. 10 Joomla s Golden Path: 11 Joomla Code of Conduct:

13 Ingen retningslinjer er gitt for ffdshow. Programmeringsspråk som brukes er c, c++ og assembly. Uten en klar kodestandard blir det vanskeligere for utviklere å forholde seg til kode som andre har skrevet. I store prosjekter blir det fort mye rot og unødvendig tidsbruk på å sette seg inn i koden. Samme konklusjon som i forrige punkt. 3.6 Sikkerhet Siden Joomla! ikke er demokratisk, vil alle kodebidrag valideres og testes av nevnte utviklings og testings team. På denne måten sikrer Joomla! at kjernen er malware fri. Men, hvem som helst kan lage utvidelser for Joomla! og disse kvalitetssikres nødvendig vis ikke. Dermed er det en viss risiko ved å bruke extensions som ikke er godkjent av Joomla!. Siden ffdshow kun har to patcher som er blitt akseptert ser det ut som det er hovedutvikler som er eneste med skriveaksess til SVN (CVS) Sikkerheten i virtualbox ivaretas ved at alt av kode som kommer inn fra frivillige bidragsytere blir gjennomgått og godkjent av Oracle før det blir lagt inn i den offisielle releasen. Alle opererer på samme måten, sikkerheten er da ivaretatt for alle parter. 3.7 Distribuering Joomla! distribuerer stabile versjoner ved stabil-fasen i utviklingsprosessen. Denne versjonen blir distribuert primært via men er også mulig å laste ned andre plasser, som for eksempel SourceForge. Joomla! bruker X.Y.Z som release nummerering12, hvor X er en major -, Y er en minor - og Z er en maintenance -release. For eksempel versjon ffdshow distribuerer sine versjoner via SourceForge. Den siste stabile versjonen utgitt, er datostemplet 12/ Prosjektet bruker dato som versjonsnummerering. Virtualbox tester først nye versjoner internt for så å legge de ut i public repositorys når de er sikre på at koden er stabil. Den kan lastes ned fra hjemmesiden, filehippo eller softpedia. Prosjektet bruker samme prinsipp som Joomla! når det kommer til release-nummerering. 4 Konklusjon Siden Joomla! har vokst til å bli dagens mest kraftfulle og populære CMS, ville det vært rart om det ikke var et grundig system rundt utviklingsprosessen. Prosjektet følger de aller fleste kravene i følge Vogel, for å være et suksessfullt prosjekt. Joomla! er et skoleeksempel på 12 Joomla s versjons strategi:

14 hvordan man skal drive Open Source utvikling, og burde være til inspirasjon som ønsker å starte et nytt prosjekt. Virtualbox har gjennom sin treårige eksistens vokst til å bli ett godt alternativ for de som ønsker å virtualisere operativsystemer på dataen sin. Da dette er en fork fra det originale arbeidet til innotek har det hele veien vært den profesjonelle utviklingen som har vært hovedfokuset. Dette har ført til at de har startet fra scratch i forhold til open source utviklingen og ivaretakelse av community rundt programmet. Det vil sikket komme til grupper og annet over tid men pr dags dato er det noe mangelfull ivaretakelse av open source miljøet rundt virtualbox. Her trenger de virkelig å ta seg selv i nakken, hvis ikke, vil ikke utviklere føle noen tilhørighet og da vil Oracle miste communityet sitt, ifølge Vogel er et open source prosjekt uten community en tikkende bombe. ffdshow er et utviklingsprosjekt som i all hovedsak er et enmanns prosjekt. Her har han ikke gjort noen grep for å tilrettelegge for utvikling i community et annet enn å opprette mailinglists. I henhold til hva Vogel mener om hva som trengs for å få til et vellykket open source prosjekt, har ffdshow feilet. De har ikke etablert noe forum eller live chat, og dette er med på å sende prosjektet til de evige jaktmarker. Et open source prosjekt vil dø når hovedutvikler ikke gidder mer, og han ikke har ønsket/klart å bygge opp et community. Dette er et prakteksempel på hva som skjer når Vogels regler ikke blir ivaretatt. ffdshow er per i dag, 6 år etter siste stabile versjon ble utgitt, fortsatt ettertraktet. Konklusjonen i dette prosjektet er at idéen var god, men gjennomføringen var (hinsides) dårlig. Heldigvis finnes det utviklere som har forstått hvordan man skal drive open source prosjekter, som har tatt opp tråden der Milan Cutka slapp. ffdshow-tryout (forken) er fortsatt under utvikling i dag, og vokser i popularitet. I motsetning til sin forløper (one man rodeo), er det et større OSSD-miljø rundt prosjektet hvor felleskapet kan bidra og delta aktivt i programmet.

15 5 Kilder Joomla!: 1) Hjemmeside: 2) Hva er Joomla!?: 3) Historien om Joomla!: 5) Filling bugs and issues: 6) Utviklingssyklus: 7) Code of Conduct: VirtualBox: 8) Wiki: 9) Hjemmeside: 10) Ting å bidra med: 11) Hvordan bidra: 12) Community: 13) Lisensiering: 14) Dokumentasjon: 15) Virtualbox downloads: ffdshow: 16) Wiki : 17) SourceForge Stats: &mode=alltime 18) ffdshow - SourceForge Lisenser: 18) GNU GPL: 19) Joomla! license FAQ: cle&id=55

16 IMT Mappe 2 Smidige utviklingsmetoder Jørn André Myrland

17 Innholdsfortegnelse 1 Introduksjon Valg av utviklingsmodell Scrum Team Product Backlog Sprint Sprint Planning Sprint Backlog Daily Scrums Sprint kommunikasjon Sprint Demos Sprint Retrospectives Testing Release Planning... 8

18 1 Introduksjon I dette mappearbeidet skal vi diskutere tilpasning og bruk av Scrum i kombinasjon med elementer fra øvrige smidige-systemutviklingsmetoder, relatert til bachelorprosjektet Autoklave. 1.1 Valg av utviklingsmodell I innledningen for prosjektet, under pkt 1.4 Arbeidsmetoder, spesifiseres behovet for en fleksibel utviklingsmodell. Prosjektet valgte en modifisert inkrementell utviklingsmodell med iterative prosesser, basert på behov for tidlige prototyper, testing og tilpassing. Videre planlegges utvikling av prioriterte prototyper, som er viktig å få på plass tidlig. I dette tilfellet ville SCRUM vært en god utviklingsmodell for prosjektet, med tanke på dets behov. Funksjonelle krav kan omformuleres (etter SCRUM behov) og representeres som Stories, hvor de høyst prioriterte Stories entrer Sprint en først. 1.2 Scrum Team Jeg tar forutsetning om at jeg er ScrumMaster og at jeg har 6-7 andre dyktige utviklere som Team. Som en del av teamet er det satt av en sluttbruker til testing/validering av produktet, som blir satt til andre administrative oppgaver når det ikke foregår testing. Product Owner er i dette tilfellet Bård Marken fra AH Partner AS, siden han er oppdragsgiver for Autoklavprosjektet. PO bør integreres så mye som mulig i prosessen, men må i minste fall være med på Sprint Planning og demonstrasjon i Sprinten. 2 Product Backlog Vår Product Backlog er satt sammen av Stories, som nevnt tidligere. Disse Story ene er tatt fra prosjektets funksjonelle krav, men omformulert for å imøtekomme Scrum. Hver Story inneholder en ID, navn, prioritet, estimert tidsbruk, demo og notater. For å imøtekomme Testing, er det i tillegg lagt til et felt til i Product Backlog en; Test result. Dette feltet henviser til eventuelle forandringer/tilpasninger som dukker opp etter testing. Bakdelen i dette tilfellet er operasjonelle krav, kalt Tech Stories i Scrum. Vi har, i følge H. Kniberg, 3 tiltak for å håndtere Tech Stories: 1) Se etter en måte å forvandle en Tech story til en vanlig Story med målbar forretningsverdi. På den måten har produkt eieren en bedre sjanse til å gjøre riktige avveininger. 2) Hvis vi ikke kan forvandle en Tech Story inn i en vanlig historie, se om arbeidet kan gjøres som en oppgave innen en annen Story. 3) Dersom begge ovennevnte mislykkes, definerer det som en Tech Story, og hold en egen liste over slike Stories.

19 For eksempel, et operasjonelt krav fra Autoklave er at Programvaren skal kunne kommunisere med I/O modul for kommunikasjon med automasjonsteknisk maskinvare i autoklaven.. Hvis vi skal bryte ned dette i et punkt spør vi: hva er forretningsverdien av dette punktet? Jo, vi kan styre og lese av kritiske verdier for autoklaven, og mange funksjonelle krav vil ikke være gjennomførbar utenom dette kravet. Det operasjonelle kravet er veldig generelt (pumper, ventiler, temperatur- og trykk sensorer og lignende), og det blir vanskelig å gjøre det om til et en egen story. Det vi kan gjøre, er å bake inn operasjonelle krav til sine respektive funksjonelle krav. For eksempel, for å starte/stoppe autoklaven, må vi ha I/O kommunikasjon med pumper og ventiler. Product Backlog eksempel: ID Name Imp Est Demo Notes Test res. 1 Vise hjelp 20 5 Trykk på hjelp knapp. Øvre del av skjermbilde skal så erstattes med kortfattet dokumentasjon for systemet. Ta hensyn til flerspråklig støtte. 2 Starte/Stoppe autoklav 3 Brukergrensesnitt mot autoklav 4 Åpne/lukke dør til autoklav Viktighetsgrad spesifisert av PO Trykk start/stop i hovedmeny. Autoklav skal så starte/stoppe Trykk på GUI-demo. Vis test over meny, vinduer, knapper og varsler Trykk åpne/lukk dør i hovedmeny eller prosessbildet. Døren skal så åpnes. Tidsestimat: ant. dagsverk. Installere I/O modul for automasjonsteknisk kommunikasjon med pumper og ventiler. Ved start - starter opp automatisk og gjør seg klar for kjøring av prosesser. Demo funksjon fjernes etter demonstrasjon. Krever I/O modul for automasjonsteknisk kommunikasjon med lukke/låse mekanismer. Ikke mulig å åpne steril dør om forrige prosess ikke er kjørt med godkjent resultat, heller ikke usteril dør om steril dør ikke har vært oppe siden forrige godkjente prosess. Operasjonelt krav bakt inn i Story I tabellen over ser vi et eksempel på en Product Backlog for Autoklav. Før Sprinten velges de viktigste Stories, med hensyn til at tidsestimatet totalt ikke overstiger Sprint-intervallet. Dermed sitter vi igjen etter en endt Sprint med et potensielt virkende produkt. Dette kan gjenspeiles i rapporten som en prototyp.

20 3 Sprint 3.1 Sprint Planning Sprint Planning er et kritisk møte før hver Sprint, hvor hele teamet, Scrum Master og Product Owner deltar. Hensikten med dette møtet er å avklare Sprint mål, oppsummere Product backlog, Sprint backlog, tid/sted for demo og tid/sted for Daily Scrums. Sprint-lengden (re-)defineres også i Sprint Planning. Det er forskjellige fordeler/ulemper mellom korte kontra lange Sprint-lengder, derfor setter jeg denne til å være 3 uker for dette prosjektet. Dette er et kort nok intervall for å oppnå smidighet, men samtidig gi rom for teamet å tilpasse seg problematiske situasjoner. Estimeringsteknikker tatt i bruk for å velge Stories til Sprint backlog, er en kombinasjon av magefølelsen, hastighets-beregning basert på yesterday s weather -teknikk, og hastighetsberegning basert på tilgjengelig dagsverk og estimert fokus faktor. Sprint Planning for dette prosjektet settes til 5 timer, med følgende agenda: 1. Sette mål for sprinten og demonstrasjons dato, tidspunkt og sted. 2. Oppsummere Product Backlog. 3. Oppdatere prioritetsnivå og tidsestimat for Stories. 4. Team velger ut Stories som skal utvikles. 5. Demonstrasjon av Stories diskuteres. 6. Avklare arbeidsoppgaver for tester. 7. Avtale tid og sted for Daily Scrum. 8. Bryte ned Stories ned i tasks. Tid avsatt for møtet er fleksibel for ScrumMaster, dersom det er nødvendig.

21 3.2 Sprint Backlog Sprint backlog eksempel for Autoklave: Først følger Tasks denne stien. Så flyttes Backlog-item til Done. Tasks markeres også med estimert dagsverk Over ser vi et eksempel for hvordan Sprint Backlog for Autoklave ville sett ut. Det kunne i tillegg vært integrert et ekstra felt for testing, slik at testeren kunne oppdatert testresultatet. Ved å strukturere Sprint Backlog slik, øker vi effektiviteten ved at vi til en hver tid vet hva som skjer i den aktuelle Sprint en. 3.3 Daily Scrums Daily Scrum er et stående møte som holdes hver dag til et eksakt tidspunkt (angitt i Sprint planning). Møtet burde holdes under 15 minutter, for å unngå motivasjons- og konsentrasjonstap. I dette møtet diskuteres hva ble gjort i går, hva skal gjøres i dag og om det er dukket opp hindringer/problemer. 3.4 Sprint kommunikasjon God sprintkommunikasjon er viktig, slik at alle til en hver tid vet hva som skjer. Siden vi bare opererer med ett team, løser Sprint Backlog- tavlen dette. Ved å plassere alle arbeidsplasser for Scrum Team et i samme rom, inkludert Sprint Backlog- tavlen, vil teamet ha god kommunikasjon under hele Sprinten.

22 For å bedre kommunikasjon kan en implementere par-programmering. Dette er en nødvendighet i XP, og vil bidra til økt kommunikasjon og kodekvalitet. Ved å bytte parsammensettning vil alle få jobbet sammen, som igjen kan bedre kommunikasjonen. 3.5 Sprint Demos Dette er et nødvendig punkt i Sprinten. Ved å gi en demonstrasjon av utført arbeid, vil det gi en motivasjon til å fortsette arbeidet med god innstilling. I tillegg kan dette ses på som en sosial sammenkomst, hvor teamet samhandler og diskuterer deres arbeid. Det er mange flere fordeler ved å overholde dette punktet. Alle i Scrum Team et må være til stedet under demonstrasjonen. 3.6 Sprint Retrospectives Dette møtet holdes i slutten av Sprinten, hvor alle i Scrum Team et deltar. Her diskuteres positive/negative deler av Sprinten og hva som kunne vært bedre. En måte å gjøre dette på er å dele opp et ark i 3 deler; Bra, Kunne vært bedre og Forbedring. Scrum Master går gjennom Sprint backlog og oppsummerer Sprinten (med hjelp av teamet) hvor bidrag plasseres i sine respektive kolonner. Et eksempel på et slikt bidrag kunne vært Det er et stort gap mellom estimat i forhold til reell tidsbruk, hvor teamet deretter analyserer og diskuterer hvorfor det er slik. Etter endt diskusjon, opprettes en konklusjon og plasseres under Kunne vært bedre og/eller Forbedring hvis et forslag til forbedring er gitt. Ved å analysere og diskutere dette arket med Scrum Teamet, kan det bidra til å forbedre neste sprint. 4 Testing I en perfekt SCRUM verden, trengs ikke en testfase, siden en produksjonsklar versjon av systemet slippes etter hver Sprint. I den virkelige verden fungerer dette (dessverre) dårlig og man kan ikke unngå en slik testfase for å få et optimalt system. I dette punktet står vi over for en rekke valg. Skal vi ha en tester som del av teamet eller skal vi release en beta til sluttbrukere for testing? Dette reiser igjen et nytt spørsmål; skal testing være en del av sprinten eller etter sprinten? Jeg har valgt å ha en sluttbruker som en del av teamet, som tester underveis i Sprinten. Fordelen med dette er at vi har direkte kommunikasjon med testeren, samtidig som testeren ikke har et teknisk standpunkt (kjenner ikke til koden). Bakdelen er at testeren har mye dødtid. Han/hun kan ikke teste noe som ikke er ferdig. Dette er løst ved at i Sprint Planning settes det av oppgaver testeren skal foreta seg, i tillegg til å planlegge testrutiner. På denne måten får vi utnyttet effektiviteten maksimalt.

23 Etter endt testing oppdateres Testresultat-feltet med relevant data, i Product Backlog. Deretter oppdateres Sprint Backlog og teamet får beskjed om resultatet av testen. 5 Release Planning I noen tilfeller må man planlegge litt lengre frem enn én Sprint om gangen. Vi må se på hva må vi MINST ha oppfylt for å slippe ut en endelig versjon. Dette gjør vi ved å sette opp en tabell over alle Stories, etter viktighetsgrad. For eksempel: Viktighetsgrad Navn Starte/Stoppe autoklav Brukergrensersnitt mot autoklav Åpne/lukke dør til autoklav.. Endre brukernivå Se prosesshistorikk.. Vise hjelp Hente prosessdata.. Til venstre ser vi et eksempel på en tabell over alle Stories, rangert etter viktighetsgrad. Stories merket i rødt må være ferdig for endelig release, Stories merket i gult bør være ferdig før endelig release og Stories merket i grønt kan legges til ved et senere tidspunkt. Ved å slå sammen tidsestimatet for alle de røde og gule Story ene, har vi et tidsanslag for når vi tidligst kan slippe ut første endelige versjon. Det er ikke dermed sagt at dette anslaget skal være en tidsfrist, men det kan være en god pekepinne. Konklusjonen min blir her at vi vil helst ha et ferdig produkt før vi releaser en endelig versjon, men om det er nødvendig kan vi release en versjon med røde og gule punkt integrert, hvor de siste grønne punktene bygges på etter hvert. Sistnevnte kan være aktuell om vi ligger langt bak tidsskjemaet. I forhold til Autoklave-prosjektet (med 3 utviklere) vil vi fort se resultater og komme tidligere med en release, siden vi er et større utviklingsteam.

24 IMT Mappe 3 Design Patterns Jørn André Myrland

25 Innholdsfortegnelse 1 Introduksjon Factory method Decorator Template method Kilder... 12

26 1 Introduksjon I denne oppgaven skal jeg se på 3 valgfrie "Design Patterns" blandt de 23 beskrevet av Gang Of Four i boka "Design Patterns - elements of reusable Object oriented software". Videre skal jeg se på et og et pattern, beskrive hva det gjør, hva det brukes til og hvorfor. Jeg skal også gi en kjapp inføring i hvordan disse kan realiseres, ved bruk av egne eksempler. Jeg skal se på patterns av ulike kategorier, dermed har jeg valgt Factory method (Creational pattern), Decorator (Structural pattern) og Template method (Behavioral pattern). 2 Factory method Factory method pattern-et er (i følge boken Design Patterns ) et Creational pattern og det gjør at vi kan opprette et objekt, uten å direkte spesifisere hvilken instans av objektet vi vil ha. Factory method gjør dette ved å definere en separat metode (funksjon) som subklasser kan overstyre for å spesifisere hvilket type objekt som skal opprettes. Det er altså en fabrikk som produserer objekter. Vi kan se for oss at vi har en fabrikk som produserer ulike produkter av samme type, f.eks. kniver og gaffler av typen bestikk. Disse brukes på samme måte, men har forskjellig funksjonalitet. Dette gjenspeiles i pattern-et; vi har flere produkter av samme typen, med forskjellig funksjonalitet. For å løse dette deler vi opp produkt-klassen i flere subklasser (f.eks. kniv og gaffel), hvor vi har en hovedklasse (f.eks. bestikk). Denne er ofte abstrakt, siden vi ofte ikke trenger å instansiere den. Videre har subklassene en privat constructor, slik at vi MÅ opprette dem via en Factory-metode. Factory-metoden skaper et objekt av det aktuelle produktet og returnerer dette. På denne måten vil vi enkelt kunne få tak i et ønsket produkt ved å kalle dets Factory-metode. Selv om motivasjonen bak Factory method er å tillate underklasser å velge hvilket type objekt som skal opprettes, er det også andre fordeler ved å bruke "factory-methods", hvorav mange ikke avhenger av subklasser. For å dra nytte av disse fordelene, er det derfor vanlig å definere "factory-methods" som ikke er polymorfe for å lage objekter. Slike metoder er ofte statisk. Vi skal se et eksempel på dette senere. Ved å bruke dette patternet medfølger tre begrensninger. Første begrensning er at vi ikke kan opprette produkter direkte uten å kalle factorymethod funksjonen. Ergo, vi liker ikke operatoren new om produkter. Siden constructor-en i produkt-klassene er privat, er andre bergensning at vi ikke kan utvide disse (lage underklasser). Hvis vi derimot endrer constructor-en i et produkt til protected, kan vi utvide produkt-klassen. Dette fører oss til tredje begrensning: underklassen må gi sin egen re-implementering av alle factorymehods med nøyaktig samme signaturer. Hvis ikke vi gjør dette, kan vi risikere å få en instans av moren, i motsetning til det vi var ute etter: en instans av underklassen.

27 Hvorfor skal vi bruke Factory Method? Ved å bruke dette design pattern-et trenger klienten (klassen som skal bruke produkte) KUN å vite API-et for produktet som returneres. Vi kaller altså kun factory-klassen for å få tak i et ønsket produkt, uten å bruke operatoren new. Vi får også lave koblinger ved å bruke dette. Da dette er et problem for applikasjonen, anvender vi Factory method! La oss se hvordan Factory method er realisert i Java. La oss si at vi skal produsere biler; Audi, Volvo og Ferrari. Alt vi ønsker å vite til slutt i programmet, er hvor produktet skal produseres. Vi bygger på følgende struktur, basert på UML diagrammet under. Produkt klassene ser altså slik ut: // Hoved-produkt klasse: Bil abstract class Bil { public abstract Bil factorymethod(); public abstract String getnationality(); class Volvo extends Bil { // Subklasse: Volvo: private Volvo() { public static Bil factorymethod(){ return new Volvo(); public String getnationality() { return "Sverige"; class Ferrari extends Bil { // Subklasse: Ferrari: private Ferrari() { public static Bil factorymethod(){ return new Ferrari(); public String getnationality() { return "Italia";

28 class Audi extends Bil { // Subklasse: Audi: private Audi() { public static Bil factorymethod(){ return new Audi(); public String getnationality() { return "Tyskland"; Her ser vi at det er en hovedklasse for type produkt. Denne er abstrakt; det vil si at vi ikke kan instansiere den. Videre har vi produkter som subklasser av Bil; Volvo, Ferrari og Audi. Alle disse har en privat constructor. Dette gjør at vi KUN kan opprette et objekt via den statiske funksjonen factorymethod(). Alle subklassene har også en funksjon for å returnere nasjonalitet, som vi skal bruke senere i programmet. For å opprette en Bil, går vi via en klasse kalt FactoryBil. Denne ser slik ut: class BilFactory { public enum BilType { Volvo, Ferrari, Audi public static Bil createbil(biltype BilType) { switch (BilType) { case Volvo: return Volvo.factoryMethod(); case Ferrari: return Ferrari.factoryMethod(); case Audi: return Audi.factoryMethod(); Her utnytter det som er nevnt tidligere: en statisk factory-metode (createbil), uten polymorfisme. Klassen BilFactory er kun til for å kunne produsere Bil er. Klassen har en public enum over biltyper vi kan produsere. Denne brukes i createbil for å bestemme hvilken bil vi skal produsere. Ut i fra dette parameteret bestemmes hvilken bil vi skal returnere, ved å kalle bilens factorymethod(). Objektet som er klienten for produkter, vil i dette tilfellet være klassen main ligger i. For å illustrere dette, ser vi litt nærmere på koden i main: public static void main (String args[]) { for (BilFactory.BilType BilType : BilFactory.BilType.values()) { Bil b = BilFactory.createBil(BilType); System.out.println( "Bilen " + BilType + " produseres i " + b.getnationality());

29 I main går vi en løkke for hver biltype som eksisterer og produserer en av hver bil via BilFactory s createbil-funksjon. Deretter skriver vi ut til skjerm hvor bilen produseres. Utskriften blir som følger: Bilen Volvo produseres i Sverige Bilen Ferrari produseres i Italia Bilen Audi produseres i Tyskland Her ser vi at alle bilene blir opprettet (uten operatoren new og via metoden createbil), og de skriver ut sin nasjonalitet via metoden getnationality(). Fordelene ved å bruke Factory method er at vi ikke får direkte koblinger til flere klasser, men i stedet via én factory-klasse. I tillegg vil vi få en logisk og strukturert klassestruktur. Det er også enkelt å legge til en ny subklasse for å skape et nytt produkt, i motsetning til å duplisere/modifisere klasser. Ulempene ved dette pattern-et er at vi må forholde oss til begrensningene som medfølger, som i noen tilfeller kan være svekkende for applikasjonen. 3 Decorator Decorator pattern-et er (i følge boken Design Patterns ) et Structural pattern. Det gjør at vi enkelt kan endre et eksisterende objekt s adferd ved å (dekorere) legge til/utvide funksjonalitet ved runtime. Dette gjøres ved å opprette egne klasser for å utvide et annet objekts funksjonalitet. Det vil si at vi har én hovedklasse og opp til flere dekoreringsklasser som bygger videre på et gitt objekt (av typen hovedklasse eller dekoreringsklasse). Antall dekoreringsklasser er avhengi av mengden forskjellige funksjonaliteter et objekt kan ha. Denne strukturen krever altså at hovedklassen og dekoreringsklassene opererer med samme interface. Det vil si at det er et minstekrav for hovedklassen og dekoreringsklassene å inneholde samme funksjoner som er oppgitt i interface-et. For å utvide en funksjon i en dekoreringsklasse, kaller vi først bare funksjonen for det objektet vi vil utvide, for så å utfylle videre funksjonalitet. På denne måten kan vi sette sammen flere objekter for å få den funksjonen vi ønsker. Som vi ser har Decorator mange likheter med Strategy pattern-et, med tanke på funksjonalitet. Hovedforskjellen mellom disse, er at vi i Decorator kan bygge VIDERE på objekter som allerede er utvidet. Vi kan med andre ord bygge utvidede objekter oppå hverandre. Hvorfor vil vi bruke Decorator? Vi bruker pattern-et for å unngå direkte endring i en klasse eller for å unngå flere klasser med nesten lik funksjonalitet. Vi andvender det derfor når dette er et problem for applikasjonen.

30 For å vise hvordan dette realiseres, har jeg laget et eksempel i Java med utgangspunkt i fra spillet Monopol. I Monopol kan man kjøpe seg en eiendom, bygge hus på eiendommen og bygge hotell på eiendommen. I mitt eksempel stiger leien på eiendommen med 10% for hvert hus man har og 50% for hvert hotell. F.eks. hvis jeg lander på en eiendom hvor leien er 100kr, og det er 3 hus på eiendommen må jeg betale ((100kr + 10%) + 10% ) +10%, ergo leien med alle husene blir 133kr. Klassestrukturen er vist i UML-diagrammet under: Det første vi må gjøre for å realisere dette, er å opprette et felles interface for hovedklassen og dekoreringsklassene. Det gjør vi på følgende måte: // Felles interface for hoved og dekoreringsklasser: interface EiendomInterface { public double leie(double s); Ved å implementere dette interface-et I hovedklassen og dekoreringsklassene, er vi garantert å ha en funksjon navngitt leie som tar en tall-verdi som parameter og at den returnerer en tallverdi. Neste trinn er å opprette koden for hoved klassen: // Hovedklassen: Eiendom class Eiendom implements EiendomInterface { public double leie(double s){ return s; Vi ser at klassen implementerer interfacet, som vil si at vi MÅ opprette funksjoner spesifisert i EiendomInterface-et. Vi trenger også en abstrakt klasse for dekoreringsklasser. Dette er for å ha en lik constructor som tar inn et objekt som parameter og lagrer det unna i en objektpeker for klassen. Koden for den abstrakte klassen realiseres slik:

31 abstract class EiendomDecorator implements EiendomInterface { Eiendom eiendom; public EiendomDecorator(Eiendom e){ eiendom = e; Vi ser at klassen arver fra hovedklassen og implementerer samme interface som hovedklassen. Dette gjør vi for å kunne lagre unna et dekorerings-objekt i samme variabel som et hoved-objekt. Koden for dekoreringsklassene er realisert på følgende måte: // Dekoreringsklassen for Eiendom: Hus class Hus extends EiendomDecorator{ Eiendom eiendom; public Hus(Eiendom e){ super(e); // Leien med Hus blir 10% dyrere: public double leie(double s){ return eiendom.leie(s) * 1.1; // Dekoreringsklassen for Eiendom: Hotell class Hotell extends EiendomDecorator{ Eiendom eiendom; public Hotell(Eiendom e){ super(e); // Leien med Hotell blir 50% dyrere: public double leie(double s){ return eiendom.leie(s) * 1.5; Vi ser her at begge dekoreringsklassene arver av den abstrakte klassen EiendomDecorator. Det betyr at vi må MINST ha samme funksjoner som er spesifisert i interfacet, og det har begge klassene. I constructor-ene til klassene sender vi med det medsendte objekte til superklassen, altså den abstrakte klassen EiendomDecorator. Der lagres objektet unna i en variabel, slik at vi kan kalle det ved et senere tidspunkt. Vi kaller objektet i funksjonen leie, hvor vi videresender s som parameter til objektets leie funksjon, for så å manipulere return-verdien (+10%/+50%).

32 Når vi har Decorator-strukturen på plass, la oss teste ut dets funksjon: public static void main(string args[]){ Eiendom e = new Eiendom(); System.out.println(e.leie(100)); // Vi kjøper ett hus til eiendomen: e = new Hus(e); System.out.println(e.leie(100)); // Vi kjøper et til hus til eiendomen: e = new Hus(e); System.out.println(e.leie(100)); Skriver ut 100 Skriver ut 110 (100*10%) Skriver ut 121 (110 * 10%) // Vi kjøper et 3. hus til eiendomen: e = new Hus(e); System.out.println(e.leie(100)); Skriver ut 133 (121 * 10%) // Vi kjøper ett hotell: e = new Hotell(e); System.out.println(e.leie(100)); Skriver ut 199 (133 * 50%) I main ser vi at vi oppretter et nytt objekt kalt e. I starten er dette kun et vanlig eiendomsobjekt, dermed blir verdien medsendt til leie uendret. Videre opprettes nye hus, hvor eiendoms-objektet e sendes med som parameter og det nye objektet lagres i eiendomsobjektet e. Samme prinsippet gjelder også for Hotell. Vi ser at leien stiger etterhvert som vi legger til nye hus og hotell. Slik kunne vi fortsatt uendelig, uten å måtte legge til subklasser eller skrive om selve innmaten for klassen Eiendom. Fordelene ved å bruke Decorator pattern-et er at vi kan opprettholde applikasjonen enklere, manipulere objekter dynamisk ved runtime og vi har større fleksibilitet (i forhold til subklasser). For enhver løsning finnes det også ulemper, hvis en ikke trår varsomt. I dette tilfellet kan det skape stor forvirring for nye utviklere, da dene løsningen kan bli oversett. Dette kan resultere i at f.eks. hovedklassen endres direkte, istede for å opprette en ny dekoreringsklasse. Ergo, løsningen må dokumenteres godt. 4 Template method Template method pattern-et er (i følge boken Design Patterns ) et Structural pattern. Dette gjør at vi kan opprette forskjellige klasser (med forskjellig funksjonalitet), basert på en spesifisert struktur sett på som skjellettet. Dette skjellettet har som regel noen operasjoner (funksjoner) som ikke kan overstyres. Dette gjøres ved at vi har en abstrakt skeleton -klasse som definerer en rekke operasjoner/algoritmer i form av funksjoner. Vi har to typer funksjoner i skeleton-klassen: hooks og template methods. Hooks er funksjoner vi overstyrer i subklassene, ergo vi

33 henger nye funksjoner på kroken. Template methods er låste funksjoner, hvilket subklasser ikke kan overstyre. Vi skal se nærmere på dette i eksemplet under. Denne klassen blir en mal (eller template om du vil) for konkrete subklasser. Subklassene må følge 2 regler for å arve av skeleton-klassen. Den første reglen er at alle hook-funksjoner må implementeres i subklassen. Den andre reglen er at vi ikke kan overstyre templatemethods. Vanligvis utnyttes programmeringspråket for å forhindre dette, f.eks. (Java) ved å si final om en metode som ikke skal overstyres. Design pattern-et implementerer Protected variations GRASP prinsippet, slik Adapter patternet gjør. Forskjellen er at Adapter gir samme grensesnitt for flere operasjoner mens Template Method bare gjør dette bare for én. Hvorfor skal vi bruke template method? Vi kan enkelt sette opp nye klasser som arver dette templatet, uten å duplisere kode. Dette gjør at vi får en mye ryddigere og logisk struktur for programmet. Når skal vi andvende det? Når overnevnte er et problem. Jeg har laget et eksempel i Java som illustrerer bruken av Template method. Klassestukturen vises i UML-diagrammet under: Vi har en skeleton-klasse kalt PrintTemplate, med to subklasser; Wide og Narrow. La oss se nærmere på koden. abstract class PrintTemplate { protected char tegn; protected int hoyde; public final void printfigure(){ // Template method: for(int i = 0; i < hoyde; i++){ // skriver ut et kvadrat: for(int j = 0; j < hoyde; j++) printtegn(); System.out.println(); abstract void printtegn(); // Hook: Bestemmer utskrift.

34 Vi ser at klassen PrintTemplate har en template- og en hook-funksjon. I templatefunksjonen kaller vi den abstrakte hook-funksjonen. Vi ser videre på hvordan disse funksjonene er implementert i subklassene: class Wide extends PrintTemplate { public Wide(char t, int h){ tegn = t; hoyde = h; public void printtegn(){ // Printer ut tegn med mellomrom: System.out.print(" " + tegn + " "); class Narrow extends PrintTemplate { public Narrow(char t, int h){ tegn = t; hoyde = h; public void printtegn(){ // Printer ut tegn uten mellomrom: System.out.print(tegn); Her ser vi at disse implementerer hook en fra skeleton-klassen. Funksjonene er implementert forskjellig, da Wide printer ut tegn et med mellomrom og Narrow printer det uten. La oss se hvordan dette fungerer i main: public static void main(string args[]){ PrintTemplate w = new Wide('*', 5); w.printfigure(); PrintTemplate n = new Narrow('#', 5); n.printfigure(); Utskrift Vi ser at begge objektene skriver ut figuren med en høyde på 5, men utskriften blir annerledes. Vi ser på utskriften til venstre, at firkantene er mere tettpakket, iforhold til stjernene. Dette skyldes de forskjellige hookfunksjonene i underklassene Narrow og Wide. * * * * * * * * * * * * * * * * * * * * * * * * * ##### ##### ##### ##### ##### Template method bruker en invertert kontroll struktur, ofte omtalt som "Hollywood prinsippet": sett fra superklassens synspunkt: "Ikke ring oss, vi ringer deg". Dette vil si at istedet for å kalle funksjoner fra hovedklassen i subklassen, kalles funksjoner fra subklassen i template-funksjonene fra superklassen. På grunn av dette bør vi ta spesielt hensyn til at template-funksjoner kun gjennomføres i hovedklassen og at hooks kun implementeres i subklasser. Vi må også huske på én ting før vi andvender patterns: Vi trenger ikke skyte spurv med kanon!. Vi bør kun anvende Design Patterns når vi står fast i designet. Overdrevet bruk fører til totalt kaos, og her snakker jeg desverre av erfaring.

35 5 Kilder Design Patterns elements of reusable object oriented software (1994) av Gang of Four. Alle kilder funnet Oktober Factory method: Decorator: Template method: UML-verktøy:

36 HIG Mappe 5 RUP - Elaborationfasen av Fredrik Hørtvedt Jørn André Myrland Fredrik Kvitvik

37 Innhold 1. Introduksjon Oppsummering av aktørene Valg av nettbrett Mål og begrensninger Generelle mål Moduler Begrensninger Utviklingsmiljø Logical view Deployment view... 10

38 1. Introduksjon På bakgrunn av inceptionfasen skal vi i elaborationfasen tenke på hvordan løsningen skal realiseres. Vi skal se på hvordan vi best mulig kan utvikle programvare for de forskjellige aktørene (Bruker, Operatør og Pårørende). 1.1 Oppsummering av aktørene Bruker: Personen som benytter nettbrett-delen av løsningen vår. Dette vil som regel være en bruker av hjemmetjenesten. Unntaket er situasjoner der pleieren går da inn i rollen som bruker. Dette kan for eksempel være for å hjelpe til med ulike innstillinger. Sentral-operatør: Denne aktøren administrerer systemet som kommuniserer med bruker-aktøren. Sentralen kjører en egen programvareløsning, og har oversikt over alle brukere og pårørende i systemet. Pårørende: Denne aktøren kommuniserer også med bruker-aktøren, men har kun tilgang på en bestemt bruker. Hver enkelt pårørende må aktiveres hos sentralen, for å få tilgang på sin funksjonalitet. 2. Valg av nettbrett Utviklingsmiljø Apple benytter utviklingsmiljøet XCode, og C, C++ og Objective-C som programmeringsspråk. XCode er kun tilgjengelig for Mac OS X. Om ikke en stor ulempe, så er det i hvert fall ikke er en fordel. Android benytter Java som programmerings-språk, og anbefaler Eclipse som utviklingsmiljø. Vi har også erfaring med IDEA, som er et annet velfungerende utviklingsmiljø for Java. IDEA og Eclipse er tilgjengelig for både Windows og Mac, og har begge muligheter for å simulere kjøring på Android nettbrett. I følge Wheroscope 1 sin sammenligning mellom Android og ios, er det flere punkter som går i Androids favør. Blant annet pekes det på at Apple sine simulator-løsninger er misvisende, fordi programmene kjøres med ytelsen til vertsmaskinen, og ikke med ytelsen som bruksenheten innehar. Dette fører til misvisende hastigheter på applikasjonen under testing. I utviklingsmiljøet til Android kjører man en virtuell maskin under testing, for å gjøre det mer realistisk. Det pekes også på at Android har god dokumentasjon, mens flere utviklere klager på at de må hacke Apples løsninger for å få applikasjonene slik man ønsker. Dette er riktig nok bare enkelte utvikleres meninger, men vi må likevel ha det i bakhodet når vi bestemmer oss for hvilken plattform vi ønsker å satse på. Maskinvare Nedenfor ser du en oversikt over maskinvaren for de tre nettbrettene vi nå skal se nærmere på. Vær oppmerksom på at selv om alle har likt checkmark på et punkt, kan det være variasjoner. For eksempel kjører ipad bluetooth 2.1, mens Samsung Galaxy kjører versjon 3.0. Den grønne haken viser bare at nettbrettet oppfyller vårt systemkrav på dette punktet. 1

39 Operativsystem ipad Huawei S7 Samsung Galaxy ios 4 Android 2.1 Android Mp 3.15 Mp Mp 500 g 380 g Wi-fi 3G + SIM-kort Bluetooth Kamera USB-inngang Minnekort-leser Vekt Dimensjoner g x x 13.4 mm Skjerm-størrelse x x 15.5 mm x x 12 mm x x x 600 Berøringsfølsom Trykkfølsom Berøringsfølsom Harddisk GB 4 GB + MicroSD GB + MicroSD Prosessor 1 GHz 750 Mhz 1 GHz 256 MB 256 MB 512 MB Stereo-utg. utg. + høyttalere Stereo-utg. + høyttalere Stereo-utg. + høyttalere Skjerm-oppløsning Skjerm-type Multi-touch RAM Lydutgang Mikrofon * Ikke tilgjengelig på alle modeller ipad Før vi bestemte oss for hvilket nettbrett vi skulle bruke, prøvde vi ut noen modeller vi hadde tilgjengelig. Først så vi på ipad, som er Apples nettbrett-løsning. nettbrett løsning. Den hadde stor fin skjerm, som passer er godt for vår målgruppe. Hvis vi ser bort fra størrelsen på skjermen, så var det stort sett de negative sidene vi bet oss merke i. Apple har gjort det unødvendig tungvint å koble til eksterne apparater, som for eksempel utstyrer vi trenger for å registrere registrere helsedata. For å koble til en USB USBenhet, eller bruke et minnekort med for eksempel bildet til galleriet, må man kjøpe to tilleggs-adapter tilleggs fra Apple. Allerede der skuffet ipad nok til at vi hadde lyst å se bort fra den. Når den da i tillegg mangler kamera, kamer så holder den ikke mål i forhold til systemkravene våre heller. ipad'en kan ikke brukes til å ha videosamtalene vi hadde planlagt å ha implementert støtte for i vår løsning. Dette gjør at vi velger bort ipad, selv om skjermstørrelsen var den mest fristende friste av nettbrettene vi så på. Figur 2.1:.1: Adapter for tilkobling USB og Minnekort på ipad.

40 Android Når vi gikk bort fra Apple, så var det Android-løsningene som gjensto. Vi hadde fått to ulike Androidnettbrett som vi kunne evaluere. Vi fikk testet en Huawei S7, samt Samsungs Galaxy-tab. Førstnevnte har lagt seg i en noe rimeligere prisklasse. Både Galaxy og S7 hadde alle tilkoblingsmulighetene vi var ute etter, i tillegg til kamera for bruk til videosamtaler. Begge har også støtte for å sette i SIM-kort å sende SMS eller ringe på telefonnettet fra enheten. Dette var ikke noe krav fra vår side, og heller ikke en del av vår løsning. Likevel er det absolutt ingen ulempe å velge et nettbrett som innehar denne kvaliteten, da det ikke er en usannsynlig utvidelse av løsningen i senere tid. Begge Android-brettene vi testet hadde en 7" skjerm. Dette er noe mindre enn ipads 9.7", men alle andre aspekter gjør at vi har bestemt oss for å gå for Android. Huawei S7 er som sagt en billigere løsning, og er svakere enn Galaxy på en del områder. Blant annet har S7 en del mindre plass i intern-minnet, og lavere oppløsning på skjermen (se tabellen på forrige side). Begge er likevel innenfor systemkravene våre. På papiret ser Samsung Galaxy-tab en del bedre ut, men vi måtte prøve begge før vi bestemte oss, ettersom det var en ganske merkbar prisforskjell som kan ha betydning for oppdragsgiver. Huawei eller Samsung? Etter å ha evaluert begge så ble skjermen hovedtema når vi skulle ta valget. Det er her det største skillet mellom enhetene er. Mens Galaxy-tab - som de fleste andre nettbrett - har en berøringsfølsom skjerm, har Huawei valgt en løsning med trykkfølsom skjerm. Skjermen på S7 virket litt treig når vi opererte på den med fingrene, men fungerer bra med pekepenn. Skjermen til Samsung fungerte bra med fingrene, men kan ikke brukes med pekepenn. For oss personlig var det helt klart Samsung Galaxy-tab som fristet mest, men så er det ikke vi som er målgruppa heller. Med tanke på at målgruppa ikke er like kjent med slik teknologi som oss, vil det for mange være helt nytt å skulle bruke fingrene på en skjerm. Dette stritter jo mot hva man er vant med fra tidligere, med fingeravtrykk som setter seg på vinduer og skjermer. Ved å bare kunne bruke fingrene - og i tillegg multi-touch - på Samsungs brett, er vi redd det kan oppstå en del kluss for de eldre brukerne. Det er derfor en fordel å ha muligheten til å benytte pekepenn på skjermen. S7'en kan jo tross alt opereres på begge måter. Når S7'en er nesten dobbelt så rimelig, så måtte pris også med i vurderingen, ettersom dette vil ha innvirkning på hvor mange som faktisk kommer til å ta i bruk løsningen. Vi bestemte oss derfor til slutt for å gå for Huawei S7, som oppfyller systemkravene, og i denne sammenheng fungerer tilfredsstillende på de viktigste områdene. Figur 2.2: Nettbrettet Huawei S7. Skjermbildet er kun ment som en illustrasjon av nettbrettet, og er ikke relatert til vår løsning.

41 3. Mål og begrensninger 3.1 Generelle mål Det er meget viktig at vi overholder kravene i forhold til konfidensialitet, integritet og tilgjengelighet i forbindelse med sensitiv informasjon. Derfor er det viktig at vi designer en arkitektur på bakgrunn av dette. Ved å benytte oss av en 3 lags modell, kan vi sikre kommunikasjonen mellom lagene ved å kryptere informasjonsflyten. Krypteringen gjør at vi kan forsikre oss om at det er vårt system som prøver å hente ut data, samt at den motvirker sniffing av informasjon. 3.2 Moduler Et annet mål er at pad-løsningen (for brukeren) skal ha støtte for utvidelse. Dette kan gjøres ved å opprette et grensesnitt mot applikasjonen (API), som kan brukes for å opprette moduler/plugins som kan integreres i applikasjonen. For å realisere dette kan vi benytte oss av design pattern et Template Method 2. Ved å benytte oss av dette, vil vi skape et felles grensesnitt for alle utvidelser. På denne måten kan også 3. parts applikasjoner integreres på en enkel måte i applikasjonen, ved å benytte dette grensesnittet. Prinsippet er vist i UML-diagrammet under (Fig 3.1). Figur 3.1 Klassediagram for pattern et Template Method i forhold til moduler. I tillegg ønsker vi å gjenbruke komponenter, i forhold til å utvikle egne komponenter. Derfor har vi satt et mål om å gjenbruke komponenter, i den grad det lar seg gjøre. Et eksempel på dette kan for eksempel være å ta i bruk Skype som en videosamtale-komponent, i forhold til å utvikle en selv. Dette vil være lønnsomt, både i form av tid og penger. Klassifisering av moduler Modulene kan klassifiseres i flere ulike typer, som sier noe om hvem som kan få tilgang til hva. Noen moduler er privat, mens andre eies av sentralen. Forskjellen på disse er at sentralen ikke har noen relasjon til de private modulene. En annen variant av disse er private moduler med tilknytning til en pårørende-konto. Denne har heller ikke noen relasjon til sentralen, men kan ha en brukerdefinert tilknytning til en pårørende. Et godt eksempel på dette er bildegalleriet. Der kan den pårørende oppdatere bildemappa, som synkroniseres med galleri-modulen på nettbrettet. 2 Design pattern Template Method :

42 Modulene som eies av sentralen vil være mindre privat, og kan også endres eller deaktiveres eksternt fra sentralen. En variant av disse er hvis en modul både har private, og sentral-styrte deler. For eksempel kan kalenderen ha oppføringer som er flagget privat, slik at sentralen ikke har innsyn. Hvordan de ulike modulene bygges opp, vil defineres ved hjelp av modul-grensesnittet. Videre kan lese/skrive-rettigheter eventuelt justeres i de avanserte innstillingene på nettbrettet. Anbefalinger i forhold til videreutvikling Systemet er i dag planlagt og oppbygd med tanke på utvidelser i form av moduler. På denne måten vil man også lettere kunne legge inn begrensninger for den pårørendes webløsning, med tanke på hvilke deler av pad-systemet den pårørende får tilgang til. Den pårørende skal for eksempel (med tillatelse) kunne endre bilder i galleriet som ligger på nettbrettet. Andre moduler vil være privat for brukeren, uten innblanding fra de andre aktørene. Ved å kontrollere tilgangsnivået for hver enkelt modul, vil vi få et sikrere system, som også gir større valgfrihet til brukeren. Denne modellen vil også gi sentralen større frihet til å begrense hvordan den enkelte bruker benytter systemet. Ved misbruk av systemet kan sentralen etter ønske deaktivere en modul, i stedet for å frata brukeren retten til å bruke systemet generelt. Det vil ikke alltid være nok å forhåndsbegrense tilgangen til ulike moduler. Det vil også være behov for å la pad-brukeren legge inn sperrer på lese og skrive-rettigheter, for å kunne tilpasse hvilke moduler som kan påvirkes av eksterne aktører. Denne muligheten må være med i alle moduler som skal involvere pårørende-systemet, slik at vi ivaretar brukerens personvern. Pad-brukeren bør kunne endre slike rettigheter på moduler som kan klassifiseres som privat, og sentralen ikke har noen ekstern kommunikasjon med. 3.3 Begrensninger Vi er også nødt til å ta hensyn til begrensninger. En av disse er at pad-løsningen skal fungere optimalt med 3G nett. En annen begrensning vi må ta høyde for, er at nettbrettet har en liten skjerm på kun 7". Da må vi være nøye med hva vi velger å vise til enhver tid, slik at det er plass til alt. Vi må også tenke nøye igjennom valg av ikoner, slik at de er lette å forstå og at de er selvforklarende. Siden bilder sier mer enn 1000 ord, sparer vi plass med gode ikoner. Men Ikonene kan ikke være for små, for da kan de bli vanskelig å trykke på, hvis man er litt ustø på hånden. Bilde til høyre (Fig. 3.2) er en mockup av pad-løsningen, og illustrerer tydelig bruk av ikoner. Figur 3.2 Mockup på hjem-skjermen til pad-applikasjonen.. En annen begrensning er at nettbrettet kjører Android. Det kan hende enkelte ting ikke er mulig å få til, eller er svært vanskelig, så vi må sette oss godt inn i dette også. Nettbrettet har også begrenset med ressurser (CPU, RAM, batteri-tid, etc), derfor må vi lage løsningen så optimal som mulig. Hvis vi får en effektiv løsning, vil også batteritiden forlenges.

43 4. Utviklingsmiljø Siden vi har valgt et nettbrett med operativsystemet Android, Android, vil vi benytte oss av Java Development Kit (JDK) versjon 1.6 og Android Software S Development Kit (SDK) som grensesnitt mot nettbrettet. Som utviklingsmiljø vil vi benytte oss av Intelli IDEA, siden det er snakk om Java som programmerings språk. Vi vil også så benytte oss av plugins til IDEA som gjør det mulig å simulere et nettbret nettbrett, for å gjøre testing enklere. Nettbaserte løsninger vil skriptes i PHP og JavaScript, samt benytte seg av asynkron JavaScript og XML (AJAX). På denne måten får vi en optimal nett-tjeneste, ne i forhold til dagens standarder. Som database sto vi over tre valg; Firebird, Oracle og mysql. Valget endte på mysql som databaseserver, av den enkle grunnen: det er enkelt, kjapt og åpent. De andre alternativene krever lisensiering, og er til vårt formål på lik linje med mysql. Alle servere vil kjøre på plattformen Ubuntu Server versjon LTS, da denne oppfyller alle øvrige krav til en serverløsning3. 5. Logical view Vi har i vårt system valgt å bruke en enkel tre-lagsstuktur.. Dette har vi gjort fordi vi ønsker en hierarkisk struktur. Dette vil si at de overliggende lagene har tilgang ilgang til funksjonaliteten til underliggende lag. lag Ved å strukturere systemet på denne måten unngår nngår vi all form for redundans og vi får en logisk struktur over systemet. systemet I modellen til venstre (Fig. 5.1) ser vi de tre forskjellige lagene (Presentasjons Presentasjons-, Forretnings- og Databaselaget) og deres tilhørende pakker. I punktene under skal vi gå i dybden på disse lagene for å forklare disse nærmere. Presentasjonslaget: Figur 5.1: Lagdelingsmodell. Presentasjonslaget asjonslaget vil bestå av 3 forskjellige pakker; En pakke for brukere, en for pårørende og en for sentralen, og pakkene er spesial -tilpasset i forhold til hver enkelt av disse. Disse pakkene bygger på pakkene pakkene fra forretningslaget. I tillegg vil presentasjonslaget asjonslaget ha modulpakkene, som er en del av brukerpakken. Modulpakken inneholder alt 3 Server spesifikasjoner: https://help.ubuntu.com/community/server/techspecs/1004lts https://help.ubuntu.com/community/server/techspecs/1004lts

44 av funksjonalitet som trengs for å få 3.parts applikasjoner til å fungere opp mot vårt system. Denne pakken er det bare brukeren som har tilgang til. Meldingspakken inneholder alle funksjoner for å sende/motta og svare på meldinger. For sentralen og pårørende vil funksjonaliteten for å sende meldinger inneholde funksjoner for å sende ja/nei/ok spørsmål eller en vanlig melding. For Brukeren vil det være funksjoner som gjør det mulig å svare ja/nei/ok (hvis dette er påkrevd) eller svare med en vanlig melding. Videosamtalepakken vil inneholde alt man trenger av funksjonalitet for å starte og motta en videosamtale. Brukeren skal ha funksjonalitet for å starte en videosamtale med de pårørende, eller sentralen, mens pårørende kun skal kunne starte en samtale med brukeren. Sentralen skal ha mulighet for å starte en samtale med alle de forskjellige brukerne. Kalenderpakken vil for brukeren inneholde funksjonalitet som gjør det mulig å oppdatere og endre kalenderen. Det skal også være funksjonalitet for at sentralen skal ha mulighet til å fjernoppdatere/synkronisere den med besøksplanen. For sentralen vil den altså inneholde funksjonalitet for å oppdatere brukerens kalender. Hvis sentralen gjør en endring i kalenderen vil det automatisk sende en melding til brukeren om at en ny hendelse er lagt inn. Sentralen vil også ha brukerbehandlingspakke og pårørendebehandlingspakke. Disse pakkenes funksjonalitet ligner ganske mye på hverandre, og hovedforskjellen er at brukerbehandligspakken inneholder funksjonalitet for å oppdrette og endre en brukerkonto, og dens innstillinger. I motsetning har pårørendebehandlingspakken funksjonalitet for å gjøre det samme med en pårørende konto. Forretningslaget: Forretningslaget vil ha pakker for all hovedfunksjonalitet, som for eksempel meldinger og videosamtaler. Det er disse pakkene presentasjonslaget vil spesialtilpasse. Forskjellen på pakkene i forretningslaget og presentasjonslaget er at pakkene i forretningslaget er generelle, mens de i presentasjonslaget er skreddersydd og bygger på pakkene i forretningslaget. Forretningslaget benytter seg av databasekommunikasjonspakken, når det trengs å hente/lagre data fra databasen. Videosamtalepakken vil inneholde all funksjonalitet som har med videosamtaler å gjøre. For eksempel vil den inneholde funksjonalitet for å starte og motta en videosamtale. Meldingspakken vil selvfølgelig inneholde all funksjonalitet som angår meldinger, slik som å sende, motta og kvittere. Videosamtalepakken bygger på ett eksternt grensesnitt, som er levert av Skype. Dette har vi valgt å gjøre for da slipper vi å utvikle all funksjonaliteten selv, men kan bygge på det som noen andre har lagd før. Dette er økonomisk lønnsomt i tillegg til å være tidsbesparende, siden vi vet at det virker og funksjonaliteten vi trenger er lagd allerede. Det eneste vi trenger å gjøre er å kode løsninger i presentasjonslaget som gjøre at brukerne får ett spesialtilpasset gui. Kalenderpakken vil ha funksjonaliteten for å oppdatere og endre brukernes kalendere. Databaselaget: I databaselaget vil alt som har med databasekommunikasjon ligge i en pakke. Forretningslaget vil bruke denne pakken for å holde databasen oppdatert, og for å hente ut data.

45 Databasekommunikasjonspakken inneholder all funksjonalitet som har med databasen å gjøre. Det er denne pakken som for eksempel meldingspakken i forretningslaget benytter seg av når en melding blir sendt, for da skal den automatisk bli lagret i databasen. Meldingspakken bruker denne pakken også når en bruker skal hente ned en ny melding. 6. Deployment view Etter å ha fått på plass den logiske oppbygningen av løsningen, skal vi nå se på hvordan de ulike pakkene skal distribueres mellom aktørene og de øvrige systemene vi trenger for å drifte løsningen. Presentasjonslaget er spredt utover brukersystemet, webserveren og sentralserveren. Brukerpakken ligger på brukersystemet, pårørendepakken ligger på webserveren som de pårørende kobler seg opp mot. Sentralpakken ligger på sentralserveren. At hele brukerpakken ligger på brukersystemet gjør at brukeren kan benytte seg av systemet, selv om han ikke er tilkoblet internett. Brukeren vil selvfølgelig kun få tilgang til offline funksjoner, som å lese lagrede meldinger, se kalender osv. De pårørende vil koble seg opp til en webserver via en nettleser, for å få tilgang til funksjonalitet. Grunnen til at vi har valgt å legge pårørendepakken på webserveren, er at de ikke har bruk for noen form for offline funksjonalitet. Dette vil si at pårørendesystemet er en tynnklient, siden alt ligger på webserveren. Sentralpakken vil ligge på sentralserveren, slik at sentraloperatørene kan koble seg opp mot den, ved hjelp av tynnklienter. Da kan man ha en stor server, og mange små billige tynnklienter som jobber samtidig. Hele forretningslaget og databaselaget ligger samlet på databaseserveren, dette er gjort for å sikre at man alltid får tilgang funksjonaliteten man trenger.

46 Fig. 6.1: Nettverksdiagram. Som vi ser i nettverksdiagrammet (Fig. 6.1), er brukersystemet koblet direkte mot skyen, som her illustrerer internett. Vi ser også en indirekte kobling mellom pårørende-systemet og webserveren (markert med en jordklode). For øvrig har disse to også direktekobling mot internett. Videre på figuren ser vi sentralen i grupperingen til høyre. Sentraloperatørene er koblet opp mot sentralserveren, som fungerer som et knutepunkt mellom operatørene og brukersystemet. Som vi ser er pårørende-systemet og brukersystemet, samt brukersystemet og sentralen indirekte sammenkoblet via internett, når det overføres data mellom dem. Alle disse kommuniserer via databasen. Alle meldinger som sendes eller mottas, går via denne. Vi skal nå gå litt mer i dybden for hvert system representert i nettverksdiagrammet. Bruker-systemet: Brukersystemet er et Huawei S7 nettbrett som oppfyller spesifikasjonskravene som ble satt i inceptionfasen. Nærmere beskrivelse kan leses i punkt 2. Nettbrettet vil være koblet opp mot internett, og på denne måten vil det være indirekte koblet til de andre systemene (sentralen, databasen og pårørende). Pårørende-systemet: Dette systemet vil være en web-browser (Klient) som jobber opp mot Web-tjeneren. Se øvrige systemkrav for dette systemet i dokumentet fra Inseptionfasen.

47 Web-tjener: Webtjeneren er markert med en jordklode i nettverksdiagrammet. Webtjeneren vil kjøre Apache web server, med støtte for PHP, ajax og javascript. Denne vil fungere som en tjener for pårørendesystemet, siden alt av funksjonalitet ligger på webtjeneren. Sentral-server: Serveren vil (som nevnt tidligere) kjøre på en Ubuntu Server platform og vil fungere som en tjener for sentraloperatør-systemer. Denne er direkte koblet opp mot internett for å kommunisere mot de andre systemene. Sentraloperatør-systemer: Dette systemet vil være en applikasjon som jobber opp mot sentral-serveren. Den vil med andre ord fungere som en tynnklient, hvor alle operasjoner går via sentral-serveren. Database-server: Serveren vil (som nevnt tidligere) kjøre på en Ubuntu Server platform. På denne serveren er selve databasen samt foretningslaget (se logical view) plassert. Denne serveren er indirekte koblet til alle de andre systemene i nettverksdiagrammet. Disse kommuniserer da med serveren via internett.

48 For å illustrere hvordan distribueringen fungerer i denne løsningen, har vi valgt å lage et sekvensdiagram (Fig. 6.2) for et spørsmål som sendes fra en sentral-operatør, til en bruker. Det første som skjer er at operatøren - via sentralen - sender spørsmålet til en bestemt bruker, med parametere som sier noe om at dette er en melding som krever et ja/nei-svar. Diagrammet er noe forenklet, ettersom kommunikasjonen mellom sentralen og sentral-operatørens klient ikke er tatt med. Sentralen må være koblet opp mot internett (skyen) for å få distribuert denne meldingen. Hvis alt er i orden med oppkoblingen, vil meldingen lagres i databasen. Deretter sendes det (over internett) et notify til bruker-systemet, for å si ifra om at det har kommet en ny melding. Når bruker-systemet mottar dette notify et vil det først svare til serveren med en respond, for å gi beskjed om at systemet er oppe og går som normalt. Deretter hentes den aktuelle meldingen fra databasen, og vises på skjermen til brukeren. Når brukeren har kvittert ja eller nei på spørsmålet, lagres dette svaret sammen med spørsmålet i databasen. Det sendes så et nytt notify til sentralen, for å si ifra at det finnes ny informasjon å hente i databasen. Sentralen svarer med en respond, og henter svaret i databasen. Meldingene og kvitteringene blir altså distribuert mellom bruker-systemet og sentralen via internett og database-serveren, mens notify og respond blir sendt mellom systemene gjennom internett. Figur 6.2: Sekvensdiagram over meldingsflyten.

Kapittel 8: Programutvikling

Kapittel 8: Programutvikling Kapittel 8: Programutvikling Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk

Detaljer

Kapittel 7: Mer om arv

Kapittel 7: Mer om arv Kapittel 7: Mer om arv Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk Forlag,

Detaljer

INF1000 Metoder. Marit Nybakken marnybak@ifi.uio.no 16. februar 2004

INF1000 Metoder. Marit Nybakken marnybak@ifi.uio.no 16. februar 2004 INF1000 Metoder Marit Nybakken marnybak@ifi.uio.no 16. februar 2004 Motivasjon Når man begynner å skrive store programmer, vil man fort oppleve at programmene blir uoversiktlige. Det blir vanskeligere

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus // class Bygning Oppgave 1 System.out.println( Bolighus ); // class Bolighus Hva blir utskriften fra dette programmet? class Blokk extends Bolighus{ // class Blokk IN105subclassesII-1 Eksekveringsrekkefølgen

Detaljer

(MVC - Model, View, Control)

(MVC - Model, View, Control) INF1010 - våren 2008 Modell - Utsyn - Kontroll (MVC - Model, View, Control) Stein Gjessing Inst. for informatikk Et bankprogram Vi skal lage et program som håndterer kontoene i en bank. En konto eies av

Detaljer

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish.

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish. Brukermanual - Joomla Bonefish brukermanual - Joomla Gratulerer med ny nettside fra Bonefish. Du er nå blitt eier og administrator for din egen nettside, noe som gir deg visse forpliktelser ovenfor din

Detaljer

og open source spillutvikling FreeCol

og open source spillutvikling FreeCol og open source spillutvikling FreeCol Colonization FreeCol bygger på Sid Meier s Colonization (1994), som er et rundebasert strategispill (à la Civilization). Handlingen er lagt til Amerika år 1492-1800

Detaljer

En algoritme for permutasjonsgenerering

En algoritme for permutasjonsgenerering Innledning La oss tenke oss at vi har en grunnskole-klasse på 25 elever der enkelte av elever er uvenner med hverandre. Hvis uvenner sitter nær hverandre blir det bråk og slåssing. Er det mulig å plassere

Detaljer

Kom i gang med programmering i Java

Kom i gang med programmering i Java Kom i gang med programmering i Java Dette dokumentet forteller hvordan du skal komme i gang med programmering inkludert nedlasting av den programvare du trenger samt oppsett av disse samt en del innstillinger

Detaljer

Installere JBuilder Foundation i Mandrake Linux 10.0

Installere JBuilder Foundation i Mandrake Linux 10.0 Installere JBuilder Foundation i Mandrake Linux 10.0 Installasjon av JBuilder Foundation på Linux (dekker her spesifikt fremgangen ved bruk av Mandrake Linux 10.0, men distribusjon vil gjøre liten eller

Detaljer

or*dtrosnilt,'+'.q':'

or*dtrosnilt,'+'.q':' %,u lbnvaston.*.'. or*dtrosnilt,'+'.q':' JavaBin 5. mai Vidar Alvestad - Skatteetaten Inspirert av: Noen eksempler er hentet fra boken. Jeg tror Mr. Feathers tilgir meg dersom du kjøper boken ;-) Hva er

Detaljer

Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet

Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet Factory Patterns Interface Deklarerer at klassen skal bruke et interface (implements i Java) Definerer implementasjoner for alle metodene i interfacet Slide 2 v Factory Method Pattern Class creational

Detaljer

2 Om statiske variable/konstanter og statiske metoder.

2 Om statiske variable/konstanter og statiske metoder. Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo 1 Innledning Dette notatet beskriver noe av det som foregår i primærlageret når et Javaprogram utføres.

Detaljer

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP Flere design mønstre 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Introduksjon til versjonskontroll av Ola Lie

Introduksjon til versjonskontroll av Ola Lie Introduksjon til versjonskontroll av Ola Lie Installere Subversion Subversion (også kalt SVN) er et versjonskontrollsystem som hjelper oss å holde orden på de forskjellige versjonene når vi utvikler programmer.

Detaljer

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert. Grunnkurs i objektorientert programmering Introduksjon til objektorientert programmering INF1000 Høst 2015 Siri Moe Jensen INF1000 - Høst 2015 uke 5 1 Siri Moe Jensen INF1000 - Høst 2015 uke 5 2 Kristen

Detaljer

- Java kan lastes ned gratis http://www.java.com. For installasjon, se punktet Hvordan laster jeg ned og installerer Java på min maskin?.

- Java kan lastes ned gratis http://www.java.com. For installasjon, se punktet Hvordan laster jeg ned og installerer Java på min maskin?. Innhold Hva er Java?... 2 Hvor finner jeg Java?... 2 Hvorfor må jeg ha Java for å bruke nettbanken?... 2 Hvordan installerer jeg Java på min maskin?... 2 Jeg får bare en feilmelding om "File is corrupt"

Detaljer

Open Source Software Development

Open Source Software Development Open Source Software Development Dagens : Open Source Software Development Hva er OSSD? Historikk, noen viktige personligheter Karakteristika ved OSSD Prosjekter Arbeidsprinsipper og hjelpemidler (Kilde:

Detaljer

Programmering i C++ Løsningsforslag Eksamen høsten 2005

Programmering i C++ Løsningsforslag Eksamen høsten 2005 Programmering i C++ Eksamen høsten 2005 Simen Hagen Høgskolen i Oslo, Avdeling for Ingeniørutdanning 7. desember 2005 Generelt Denne eksamensoppgaven består av tre oppgaver, pluss en ekstraoppgave. Det

Detaljer

TDT4100 Objektorientert programmering

TDT4100 Objektorientert programmering Eksamensoppgave i TDT4100 Objektorientert programmering Torsdag 12. august 2010, kl. 09:00-13:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikret av Svein Erik Bratsberg. Kontaktperson

Detaljer

INF1010 - Seminaroppgaver til uke 3

INF1010 - Seminaroppgaver til uke 3 INF1010 - Seminaroppgaver til uke 3 Oppgave 1 I denne oppgaven skal vi lage et klassehiearki av drikker. Alle klassene i hiearkiet skal implementere følgende grensesnitt p u b l i c i n t e r f a c e Drikkbar

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Eksamen Objektorientert Programmering 2013

Eksamen Objektorientert Programmering 2013 Eksamen Objektorientert Programmering 2013 Høgskolen i Østfold 2013-01-07 Emnekode Emne ITF10611 Dato 2013-01-07 Eksamenstid 09:00-13:00 Hjelpemidler Faglærer Objektorientert Programmering To A4-ark (fire

Detaljer

notater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS

notater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS Mine notater Gløer Olav Langslet Sandvika VGS Et praktisk eksempel med objekter Vi kjenner alle til korktavlen med gule lapper. Vi henger opp en lapp for at vi selv eller andre skal huske eller bli minnet

Detaljer

Bruk av HP Quality Center med smidige utviklingsmetoder. HP Sofware Norge

Bruk av HP Quality Center med smidige utviklingsmetoder. HP Sofware Norge Bruk av HP Quality Center med smidige utviklingsmetoder Kjell Lillemoen HP Sofware Norge QC og smidige metoder Agenda Smidig terminologi Smidig metoder og verktøy Hvilke krav bør vi stille QC med Scrum

Detaljer

INF1000 - Uke 10. Ukesoppgaver 10 24. oktober 2012

INF1000 - Uke 10. Ukesoppgaver 10 24. oktober 2012 INF1000 - Uke 10 Ukesoppgaver 10 24. oktober 2012 Vanlige ukesoppgaver De første 4 oppgavene (Oppgave 1-4) handler om HashMap og bør absolutt gjøres før du starter på Oblig 4. Deretter er det en del repetisjonsoppgaver

Detaljer

Mål med kurset. Java i INF 2400. Dagens tema. GUI med Swing. Dokumentasjon

Mål med kurset. Java i INF 2400. Dagens tema. GUI med Swing. Dokumentasjon Mål med kurset Java i INF 2400 Introduksjon til signalbehandling Lyd som anvendelse Få programmeringserfaring Dagens tema Utplukk av Java (GUI, kode-konvensjon, polymorfisme, classpath, javadoc) Java og

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS Løkker og if-tester Gløer Olav Langslet Sandvika VGS 29.08.2011 Informasjonsteknologi 2 Funksjoner, løkker og iftester Læreplansmål Eleven skal kunne programmere med enkle og indekserte variabler eller

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Fredag 4. desember 2015 Tid for eksamen: 14.30 (4 timer)

Detaljer

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

Detaljer

Argumenter fra kommandolinjen

Argumenter fra kommandolinjen Argumenter fra kommandolinjen Denne veiledningen er laget for å vise hvordan man kan overføre argumenter fra kommandolinjen til et program. Hvordan transportere data fra en kommandolinje slik at dataene

Detaljer

Kompilering Statiske Syntaksanalyse Feilsjekking Eksempel Oppsummering

Kompilering Statiske Syntaksanalyse Feilsjekking Eksempel Oppsummering Dagens tema Hva er kompilering? Hvordan foreta syntaksanalyse av et program? Hvordan programmere dette i Java? Statiske metoder og variabler Hvordan oppdage feil? Kildekode Hva er kompilering? Anta at

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

1. NetBeans IDE: Lage en enkel mobilapplikasjon

1. NetBeans IDE: Lage en enkel mobilapplikasjon Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag NetBeans IDE: Lage en enkel mobilapplikasjon Mildrid Ljosland/Lene Hoff 09.09.2008 Lærestoffet er utviklet for faget SO350D J2ME for programmering

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Side 1 UNIVERSITETET I OSLO Kandidatnr Det matematisk-naturvitenskapelige fakultet LØSNINGSFORSLAG Eksamen i: PRØVEEKSAMEN INF1000 Eksamensdag: Prøveeksamen 22.11.2011 Tid for eksamen: 12:15-16:15 Oppgavesettet

Detaljer

Eksamen. Objektorientert Programmering IGR 1372

Eksamen. Objektorientert Programmering IGR 1372 + JVNROHQL1DUYLN $YGHOLQJIRU7HNQRORJL Eksamen i Objektorientert Programmering IGR 1372 7LG'HVHPEHU± 7LOODWWHKMHOSHPLGOHU 6NULYHVDNHU2UGE NHU -DYD6RIWZDUH6ROXWLRQV)RXQGDWLRQVRI3URJUDP 'HVLJQVNUHYHWDY/HZLV

Detaljer

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM Scrum Master og Product Owner i Høst 2015 1 Om Scrum Scrum er et populært rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer.

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Abstrakte klasser og grensesnitt, redefinering av metoder Java-programmering Arv og bruk av abstrakte klasser Eclipse Undersøke instanser i Eclipse 1 Dagens

Detaljer

Object interaction. Innhold. Abstraksjon 03.09.2007. Grunnleggende programmering i Java Monica Strand 3. september 2007.

Object interaction. Innhold. Abstraksjon 03.09.2007. Grunnleggende programmering i Java Monica Strand 3. september 2007. Object interaction Grunnleggende programmering i Java Monica Strand 3. september 2007 1 Innhold Til nå: Hva objekter er og hvordan de implementeres I klassedefinisjonene: klassevariable (fields), konstruktører

Detaljer

VMware Horizon View Client. Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang

VMware Horizon View Client. Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang VMware Horizon View Client Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang Introduksjon Fjerntilgang er blitt oppgradert til en bedre og mer moderne løsning. Programmet er identisk

Detaljer

OO-eksempel. Modellen ser slik ut: Studenter + antstudenter : int = 0

OO-eksempel. Modellen ser slik ut: Studenter + antstudenter : int = 0 OO-eksempel I eksemplet er det deklarert tre klasser: 1) Fag (skal instansieres ett objekt for hvert fag) 2) Student (skal instansieres ett objekt for hver student) 3) Studenter (abstrakt klasse skal ikke

Detaljer

Kapittel 9: Sortering og søking Kort versjon

Kapittel 9: Sortering og søking Kort versjon Kapittel 9: Sortering og søking Kort versjon Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen

Detaljer

Brukermanual for nettpublisering. frivilligsentral.no

Brukermanual for nettpublisering. frivilligsentral.no Brukermanual for nettpublisering frivilligsentral.no Innholdsfortegnelse Introduksjon 3 1 - Innlogging 4 1.1 - Logge inn 4 1.1 - Logge ut 4 2 - Grensesnitt 5 2.1 - Menyfelt 5 2.2-3 - Opprette, lagre og

Detaljer

Kapittel 1: Datamaskiner og programmeringsspråk

Kapittel 1: Datamaskiner og programmeringsspråk Kapittel 1: Datamaskiner og programmeringsspråk Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

INF1010, 15. januar 2014 2. time. Parametriserte klasser (generiske klasser) Stein Gjessing Inst. for Informatikk Universitetet i Oslo

INF1010, 15. januar 2014 2. time. Parametriserte klasser (generiske klasser) Stein Gjessing Inst. for Informatikk Universitetet i Oslo INF1010, 15. januar 2014 2. time Parametriserte klasser (generiske klasser) Stein Gjessing Inst. for Informatikk Universitetet i Oslo Repetisjon fra gamle dager: Metoder med parametre En metode uten parameter:

Detaljer

Prosjektledelse - fra innsiden

Prosjektledelse - fra innsiden Prosjektledelse - fra innsiden Presentasjon hos UiO 31.08.2012 Ida Lau Borch, fagansvarlig i Metier AS Det ligger et fantastisk potensial i det å være best i prosjektledelse og -styring Prosjekteierstyring

Detaljer

Hvordan installere Java og easyio på Windows

Hvordan installere Java og easyio på Windows Hvordan installere Java og easyio på Windows Denne veiledningen forklarer en enkel måte å installere Java og easyio på din egen Windows-datamaskin. Du kan finne veiledninger for andre operativsystemer

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

TDT4100 Objektorientert programmering

TDT4100 Objektorientert programmering Eksamensoppgave i TDT4100 Objektorientert programmering Tirsdag 2. juni 2009, kl. 09:00-13:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikrer Trond Aalberg. Kontaktperson under

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Mellom barken og veden Smidig testing i krevende terreng TTC 2015 Mellom barken og veden Smidig testing i krevende terreng TTC 2015 FOREDRAGSHOLDERE Kristian Bjerke-Gulstuen Accenture siden 1999 Fra utvikler til Testleder og Kvalitetsansvarlig Leder Accenture Norway

Detaljer

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Obligatorisk oppgave 1 INF-3200 12. oktober 2003 Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Oppgavebeskrivelse: Designe og implementere en distribuert ray-tracing applikasjon, med basis i kontroller-

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

BRUKERMANUAL. Deviations and Reporting

BRUKERMANUAL. Deviations and Reporting BRUKERMANUAL Deviations and Reporting Forord Dette er brukermanual for CEMAsys Immediate Reporting applikasjon som er laget for iphone og Android telefoner. CEMAsys Immediate Reporting er en applikasjon

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

Detaljer

Norsk versjon. Installasjon av hardware. Installasjon Windows XP og Vista. LW312 Sweex trådløs LAN PCI kort 300 Mbps

Norsk versjon. Installasjon av hardware. Installasjon Windows XP og Vista. LW312 Sweex trådløs LAN PCI kort 300 Mbps Norsk versjon LW312 Sweex trådløs LAN PCI kort 300 Mbps Ikke utsett trådløs LAN PCI kort 300Mbps for ekstreme temperaturer. Ikke plasser innretningen i direkte sollys eller nær varmeelementer. Ikke bruk

Detaljer

Brukertesting i et nøtteskall

Brukertesting i et nøtteskall Brukertesting i et nøtteskall Seniorrådgivere brukervennlighet og design Eli Toftøy-Andersen og Jon Gunnar Wold Steria Introduksjon av deltakerne Hvor jobber du og hvilken rolle har du? Nevn en ting du

Detaljer

Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1

Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1 Delkapittel 3.1 Grensesnittet Liste Side 1 av 11 Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1 3.1 En beholder 3.1.1 En beholder En pappeske er en beholder En beholder er noe vi kan legge ting

Detaljer

Kapittel 1. Datamaskiner og programmeringsspråk. 1.1 Programmering

Kapittel 1. Datamaskiner og programmeringsspråk. 1.1 Programmering Kapittel 1 Datamaskiner og programmeringsspråk Dette kapitlet er en kort introduksjon til programmering. Vi vil se på hvordan man skriver, bygger og kjører programmer, samt illustrere noen sentrale programmeringsbegrep

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

INF1000 Klasser og objekter

INF1000 Klasser og objekter INF1000 Klasser og objekter Marit Nybakken marnybak@ifi.uio.no March 1, 2004 Dette dokumentet skal tas med en klype salt og forfatter sier fra seg alt ansvar. Dere bør ikke bruke definisjonene i dette

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Delegeringsteknikken Delegering vs. arv 1 Dagens forelesning Introduksjon og motivasjon Hvorfor forelese om standardteknikker, såkalte patterns? Hva slags

Detaljer

Qt Jambi E t R ammeverks His torie

Qt Jambi E t R ammeverks His torie Qt Jambi E t R ammeverks His torie Hvem er jeg? Eskil Abrahamsen Blomfeldt Hovedfag i informatikk fra Blindern Spesialisering i programmeringsspråk og kompilatorteori Utvikler i Trolltech siden 2005 Vedlikehold

Detaljer

Debugging. Tore Berg Hansen, TISIP

Debugging. Tore Berg Hansen, TISIP Debugging Tore Berg Hansen, TISIP Innhold Innledning... 1 Å kompilere og bygge et program for debugging... 1 Når debugger er i gang... 2 Symbolene i verktøylinjen... 3 Start på nytt... 3 Stopp debugging...

Detaljer

Løypelegging ved bruk av

Løypelegging ved bruk av Løypelegging ved bruk av 1 Innholdsfortegnelse 1 Bruk av OCAD 9...3 2 Kart...3 3 Oppstart...3 4 Plasering av detaljer...5 5 Løyper...7 6 Postbeskrivelse...9 7 Innstillinger...11 7.1 For løyper... 11 7.2

Detaljer

Scan Secure GTS 5.1 + PAS

Scan Secure GTS 5.1 + PAS Scan Secure GTS 5.1 + PAS Installasjonsmanual For versjon 5.1.7 og nyere Denne installasjonsmanualen er konfidensiell Den er kun ment til bruk for system administrator Den skal ikke benyttes av brukere

Detaljer

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres

Detaljer

WWW.POLARPRODUKSJON.NO

WWW.POLARPRODUKSJON.NO GUIDE RSHL.NO Av Fredrik Mediå Oppgraderingen av nettstedet RSHL.NO har ført til at det kan oppstå en del spørsmål og forvirringer rundt hvordan forskjellige elementer fungerer. Denne guiden skal fungere

Detaljer

JSP - 2. Fra sist. Hvordan fungerer web? Tjenerside script HTML. Installasjon av Web-tjener Et enkelt JSP-script. Ønsker dynamiske nettsider:

JSP - 2. Fra sist. Hvordan fungerer web? Tjenerside script HTML. Installasjon av Web-tjener Et enkelt JSP-script. Ønsker dynamiske nettsider: Fra sist JSP - 2 Installasjon av Web-tjener Et enkelt JSP-script HTML statisk Forms Tags Ønsker dynamiske nettsider: Klientside-script/programmering Javascript, vbscript, applets Tjenerside-script/programmering

Detaljer

Eksamensoppgave i TDT4100 Objektorientert programmering med Java

Eksamensoppgave i TDT4100 Objektorientert programmering med Java Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4100 Objektorientert programmering med Java Faglig kontakt under eksamen: Hallvard Trætteberg Tlf.: 918 97263 Eksamensdato: 2013,

Detaljer

Kapittel 3. The fun starts

Kapittel 3. The fun starts Kapittel 3 The fun starts Introduksjon I dette kapittelet vil jeg prøve å gjøre ting på en annen måte. Siden vi nå skal begynne å faktisk lage noe, tenkte jeg at jeg vil gjøre det slik at kapittelet blir

Detaljer

Nye funksjoner kombinert med enkel oppgradering

Nye funksjoner kombinert med enkel oppgradering Norgeslansering under brukermøtet 25. - 26. mars 2014 på Clarion Hotel Oslo Airport, Gardermoen. (Bildetekst) Infor har investert kraftig i oppgradering av ERP-løsningen M3, programvare mange store norske

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Objektorientering i VB en introduksjon

Objektorientering i VB en introduksjon Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Objektorientering i VB en introduksjon Oppdatert av Atle Nes Objektorientering i VB en introduksjon Resymé: Visual Basic.NET er et objektorientert

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

For mer informasjon om SQL Server 2014 Express, se Microsoft sine nettsider: https://msdn.microsoft.com/en-us/sqlserver2014express.

For mer informasjon om SQL Server 2014 Express, se Microsoft sine nettsider: https://msdn.microsoft.com/en-us/sqlserver2014express. 1 Innholdsfortegnelse Microsoft SQL Server 2014 Express... 3 Nedlastning av installasjonsfil for SQL Server 2014 Express... 3 Installasjon av SQL Server 2014 Express... 4 Installasjon av Huldt & Lillevik

Detaljer

KONTROLL INSIDE MSOLUTION

KONTROLL INSIDE MSOLUTION KONTROLL INSIDE MSOLUTION Forandre renholdsteam eller renholdsdager på oppdrag I denne brukerveiledningen skal vi bruke bytte renholdsdager. Det skjer jo at vi bytter renholdsdager eller team på kunder.

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Kandidatnr Eksamen i INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Prøveeksamen tirsdag 23. november 2010 Tid for eksamen:

Detaljer

Objective-C. Shermila Thillaiampalam 01.11.2011

Objective-C. Shermila Thillaiampalam 01.11.2011 Objective-C Shermila Thillaiampalam 01.11.2011 Innhold 1 Kort om Objective-C 4 1.1 Xcode................................ 4 2 Historie 5 2.1 Programmeringsspråket C..................... 5 2.2 Smalltalk..............................

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

Åpent alle veier. 13.10.2011 Roar Skålin, IT-direktør ved Meteorologisk institutt. E-post: roar.skalin@met.no Bilder/illustrasjoner fra met.

Åpent alle veier. 13.10.2011 Roar Skålin, IT-direktør ved Meteorologisk institutt. E-post: roar.skalin@met.no Bilder/illustrasjoner fra met. Åpent alle veier 13.10.2011 Roar Skålin, IT-direktør ved Meteorologisk institutt E-post: roar.skalin@met.no Bilder/illustrasjoner fra met.no Hvordan lager vi et værvarsel? WMS Kjøring og overvåking av

Detaljer

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold Ove Dalen There is a lack of discipline in many web publishing processes because managers in charge of websites often don't respect

Detaljer

Start et nytt Scratch-prosjekt. Slett kattefiguren, for eksempel ved å høyreklikke på den og velge slett.

Start et nytt Scratch-prosjekt. Slett kattefiguren, for eksempel ved å høyreklikke på den og velge slett. Norgestur Introduksjon Bli med på en rundreise i Norge! Vi skal lage et spill hvor du styrer et helikopter rundt omkring et kart over Norge, mens du prøver å raskest mulig finne steder og byer du blir

Detaljer

Hvordan oppdatere Java.

Hvordan oppdatere Java. Hvordan oppdatere Java. Trykk på din nettleser under for veiledning til å oppdatere Java: Internet Explorer Mozilla Firefox Google Chrome Safari (Mac) Internet Explorer Skriv inn www.java.com i adressefeltet

Detaljer

1. Profiler og variabler

1. Profiler og variabler Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Profiler og variabler Stein Meisingseth 26.05.2014 Lærestoffet er utviklet for faget IDRI3005 PowerShell 1. Profiler og variabler Resymé:

Detaljer

Klasser, objekter, pekere og UML. INF1000 - gruppe 13

Klasser, objekter, pekere og UML. INF1000 - gruppe 13 Klasser, objekter, pekere og UML INF1000 - gruppe 13 Klasse Beskriver ofte ting fra den virkelige verden Veldig ofte et substantiv (Person, Bok, Bil osv.) class Person { String navn; int alder; } class

Detaljer

J2EE. CMP Entity Beans, Transaksjoner, JSP

J2EE. CMP Entity Beans, Transaksjoner, JSP J2EE CMP Entity Beans, Transaksjoner, JSP CMP Entity Beans Container Managed Persistence Container sin oppgave å lagre innholdet i EJB til varig lager (typisk DB). Implementasjonsklassen lages abstrakt.

Detaljer

DIAGNOSERAPPORT. for. Dato:19122012 Utført av: Tommy Svendsen

DIAGNOSERAPPORT. for. Dato:19122012 Utført av: Tommy Svendsen DIAGNOSERAPPORT for Dato:19122012 Utført av: Tommy Svendsen Generell synlighet (pagerank) En god start er å sjekke den generelle synligheten på siden. Dette er en test som rangerer med utgangspunkt i hvor

Detaljer