Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Størrelse: px
Begynne med side:

Download "Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP"

Transkript

1 Hva gjøres i design? 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 å bruke leksjonene til undervisning eller kursformål må ta kontakt med TISIP for nærmere avtale. Tore Berg Hansen

2 Innholdsfortegnelse Innledning...1 Aktivitetene i design...2 Modellene i design...2 Use case modeller...2 Interaksjonsmodeller...2 Patterns...2 Ekspert...3 Skaper...4 Løs kobling...5 Høy kohesjon...6 Kontroller...7 Klassediagrammene i design...7 Lesestoff...7 i

3 Innledning I en tidligere leksjon så vi på hva vi gjør i analysen. Et av poengene er at i objektorientert systemutvikling er skillet mellom analyse og design flytende. Vi illustrerte det som et kontinuum som vist i denne figuren. (Dere finner den igjen i Larman sin bok). Mer analyseorientert Mer designorientert hva krav undersøkelse av domenet hvordan logisk løsning Det er også slik at i et objektorientert utviklingsprosjekt vil vi kjøre flere runder med litt analyse, litt design og litt implementasjon. Dette var tema i en tidligere leksjon. I analysen finner man frem til de objekter (også kalt konsepter) som er typiske for problemdomenet. Dette er ikke programvareobjekter, men objekter som er i den virkelige verden. Dvs objekter fra problemområdet (også kalt problemdomenet). Under design finner man frem til programvareobjekter som kan realiseres i et programmeringsspråk og fortrinnsvis i et objektorientert programmeringsspråk som C++ eller Java. I design detaljerer vi klasser som skal inngå i programmet som skal utvikles. Mange av disse klassene henter vi fra problemdomenemodellen. Det er nettopp noe av poenget med objektorientering. Vi arbeider med de samme begreper i programmet som i den virkelige verden. Det gjør det lettere å forstå programmene fordi terskelen fra problem til program blir mindre. Men vi legger også til klasser som vi finner opp for å kunne lage en god løsning. Det kan også tenkes at konsepter fra problemområdet ikke vil bli brukt i programmet eller de kan bli attributter i klasser. I design arbeider vi altså med å finne frem til programvareklasser. Resultatet er en logisk løsning basert på det objektorienterte paradigme. Oppgaven er å fordele ansvar på samarbeidende objekter. Samarbeidet skjer ved at objektene sender meldinger til hverandre. Ansvaret som skal fordeles er uttrykt i use case og systemoperasjoner. Til støtte for arbeidet har vi god praksis nedfelt i såkalte mønstre (engelsk patterns). Interaksjonsdiagrammer er det viktigste arbeidsredskapet i design. Objektene defineres i klasser. Vi detaljerer klassene til et nivå hvorfra vi mer eller mindre rett frem kan skrive koden for klassene i det programmeringsspråket vi skal implementere i. Hvis vi bruker et verktøy som Rational Rose og legger våre modeller inn der, kan noe av koden genereres automatisk av verktøyet. I design lager vi designmodellen. Den består av interaksjonsdiagrammer og programvare klassediagrammer. Vi har i leksjon 2 og 3 sett innledningsvis på hva vi gjør i design. I denne leksjonen skal vi skal vi se på noen flere detaljer. 1

4 Aktivitetene i design I design er vi opptatt av å få detaljert hvordan systemet som skal utvikles skal bygges. I Unified Process gjøres det vesentlige av designarbeidet i bearbeidingsfasen. Men noe design vil vi kunne gjøre i oppstartsfasen og også i senere faser. Under design får vi gjerne mer kunnskap som gjør at vi kan komme til å gjøre endringer på tidligere beslutninger. Jaccobson 1 skriver: I design utvikler vi en design modell. Det skjer i tre trinn. 1. Identifikasjon av implementasjonsmiljøet. 2. Ta hensyn til dette og utvikle en første versjon av design modellen. 3. Beskriv hvordan objektene samspiller i hver use case Hos Jacobson består Designmodellen av objekter som utgjør strukturen i systemet. Larman inkluderer to modeller i Designmodellen. De er programvare klassemodell og interaksjonsmodell. Begge disse illustreres i diagrammer med bruk av UML. I læreboken 2 poengterer forfatteren hvor viktig det er å arbeide med interaksjonsdiagrammer i design. Han sier at mesteparten av tiden i design vil man bruke på slike diagrammer. Vi kommer tilbake til dette. Men vi kommer også til å arbeide med andre modeller. Modellene i design I design arbeider vi mye med interaksjonsdiagrammer. Det er en smakssak hvilken type interaksjonsdiagram man velger sekvensdiagram eller samarbeidsdiagram. Sekvensdiagrammer viser best rekkefølgen av hendelser, mens samarbeidsdiagrammer bedre får frem mønstre i samarbeidet og hvordan ansvaret er fordelt. Arbeidet med interaksjonsdiagrammer tar en vesentlig del av tiden i designfasen. De andre modeller man arbeider med er use case modeller og design klassemodeller (programv are klassemodell). Use case modeller Man lager reelle (konkrete) use case under design. Dette er noe av det første man starter opp med i denne fasen. En reell use case viser hva som skjer i samspillet mellom systemet og aktører uttrykt i konkrete termer knyttet til en inn/ut teknologi. Hvis f.eks et grafisk brukergrensesnitt er en del av systemet vil use case inneholde detaljerte beskrivelser av vinduer og dialoger. Det er ikke nødvendig å lage brukergrensesnittet, det kan utstå til implementasjon. Men detaljerte skisser må i det minste foreligge. Egnede verktøy kan brukes til å utforme brukergrensesnittene. Interaksjonsmodeller Disse lages på basis av - den konseptuelle modell - eventuelt kontrakter for systemoperasjoner - reelle use case Interaksjonsdiagrammet skal vise utvekslingen av meldinger mellom instanser (objekter) av klasser i klassemodellen. UML definerer to slags interaksjonsdiagrammer. Det er samarbeidsdiagram og sekvensdiagram. Ikke alle har forstått betydningen av å legge arbeid i å lage interaksjonsdiagrammer. Men nøkkelen til suksess ligger i riktig fordeling av ansvar mellom objekter og i dette arbeidet er interaksjonsdiagrammer et uvurderlig hjelpemiddel. Interaksjonsdiagrammer er et av de mest verdifulle ting som lages i objektorientert design. En vesentlig del av tiden i prosjektet må brukes på disse. Patterns Pattern kan oversettes med mønster. Dette temaet har blitt viet stor oppmerksomhet i den senere tid. Vi vil i dette faget kun gi en introduksjon. Mønstre kunne vært et eget fag. Pattern må også sees i sammenheng med begrepet 1 Ivar Jacobson, Object-Oriented Software Engineering A Use Case Driven Approach, Addison-Wesley, 1992, ISBN Craig Larman, Applying UML and Patterns An Introduction to Object-Orientetd Analysis and Design and the Unified Process, Prentice Hall, 2001, andre utgave, ISBN

5 arkitektur som vi skal se litt på i en senere leksjon. Arkitektur dreier seg om mønstre på et overordnet nivå, mens patterns i den sammenheng vi skal se på her dreier seg om hvordan man fornuftig detaljerer oppbygningen av programmer. Til alle tider har dyktige og erfarne programvareutviklere laget gode programmer. Noe av årsaken til suksessen har vært ubevisst og bevisst bruk av programvarestrukturer som erfaringsmessig har vist seg å gi gode resultater for bestemt e typer av applikasjoner. Erfarne utviklerne har gjerne en verktøykiste med både generelle prinsipper og anerkjent praksis. Det har etter hvert kommet en del litteratur på markedet hvor man har forsøkt å samle og kategorisere disse prinsipper og praksis. En klassiker er boken til Gamma 3 m.fl (kjent som the gang of four ). I denne boken blir begrepet definert. Boken inneholder en beskrivelse av 23 patterns. I boken er et pattern bl.a beskrevet ved sitt navn, hvilke typer av problemer det er tenkt å løse og eksempler på bruk. Et pattern dokumenteres også ved samarbeidsdiagrammer. I denne leksjonen vil jeg følge opplegget til Larman. Han har også en del andre patterns enn Gamma. Her følger noen av de nyttigste patterns som er beskrevet i boken til Larman. Ekspert Ekspert er et pattern som gir svaret på hva som er det grunnleggende prinsipp for tildeling av ansvar til objekter. Prinsippet sier: Ansvar gis til den klasse som har den nødvendige informasjon for å kunne oppfylle ansvaret. I vårt eksempel med reis eplanleggeren betyr det at det objektet som skal ha ansvaret for å legge opp en reise er det objektet som har den nødvendige kunnskap. Jeg lar det være en del av neste øving å finne ut av det. Eksemplet i neste figur er hentet fra Larman sin bok. Salg dato tidspunkt inneholder 1..* VareLinje kvantitet * beskrevetav Produktspesifikasjon beskrivelse pris UPC Eksemplet er hentet fra en problemstilling hvor man ønsker å plassere ansvaret for å finne det totale salgsbeløp. Legg merke til at man som kandidater har hentet klasser fra problemdomenemodellen. Her gis ansvaret til salg som har all nødvendig informasjon. Salg kjenner til alle varelinjer som inngår i salget. Hver varelinje kjenner til spesifikasjonene for varen som inngår. Her har vi tre eksperter som hver har kunnskap om deler av salget: Salg har ansvar for å finne den totale salgssum VareLinje har ansvar for å finne delbeløpet Produktspesifikasjon har ansvaret for produktprisen Det betyr at klassene får operasjoner som vist i neste figur. 3 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns Elements of Reuseable Object- Oriented Software", Addison-Wesley, 1995, ISBN

6 Salg dato tidspunkt total() VareLinje kvantitet Produktspesifikasjon beskrivelse pris UPC pris() Vi summerer opp: Ekspert er det mest brukte pattern Informasjon kan være fordelt på flere klasser Vi får programvareobjekter som har en parallell til de tingene de representerer Gir innkapsling (et viktig objektorientert prinsipp) Støtter løs kobling Vi får lettvektsklasser med høy kohesjon De to siste begrepene skal vi komme tilbake til. Skaper Skaper (engelsk Creator). Dette mønsteret skal gi svar på hvilket objekt som skal ha ansvaret for å instansiere klasser (dvs skape objekter i et program). Kandidatene er karakterisert ved at de aggregerer et objektet inneholder objektet lagrer instanser av objektet er brukere av objektet har initialiseringsdata som objektet trenger når det skapes Samme eksempel som foran er vist i neste figur. 4

7 Salg dato tidspunkt inneholder 1..* Produktspesifikasjon VareLinje kvantitet * beskrevetav beskrivelse pris UPC Vi gir ansvaret for å skape VareLinje til Salg fordi Salg inneholder eller faktisk aggregerer mange VareLinje. Det betyr at vi har situasjonen som vist i neste figur. skapvarelinje(kvantitet) 1: create(kvantitet) :Salg Salg dato tidspunkt :VareLinje total() skapvarelinje() Løs kobling Løs kobling er et design prinsipp som skal sørge for at de objektene vi lager skal være egnet for gjenbruk samtidig som programmene blir lettere å forstå, vedlikeholde og utvide. Figuren viser to mulige design av samme problem 5

8 betal() :Kasseterminal 1: create() b:betaling 2: leggtilbetaling(b) :Salg betal() :Kasseterminal 1: betal() :Salg 1.1: create() :Betaling Eksemplet er kyttet til betaling i en kasseterminal. Den nederste løsningen er bedre enn den øverste. Årsaken ar at den fordeler ansvaret for å ta betaling på flere objekter. Det legger færre oppgaver på klassen Kasseterminal. Den får færre koblinger. I dette enkle eksemplet er ikke antallet koblinger noe problem i noen av løsningene. Men man skal når man designer alltid ha i bakhodet at man bruker prinsippet for å evaluere sin design. Hvis man oppdager at noen klasser har fått mange koblinger til andre objekter bør man se etter om det ikke er mulig å delegere til flere objekter. To klasser X og Y er koblet hvis X har et attributt som refererer til en instans av Y X har en metode som referer en instans av Y X er direkte eller indirekte en subklasse av Y (arv) Y er et grensesnitt og X implementerer grensesnittet Bruk av prinsippet fører til uavhengige klasser. Arv skal bukes med forsiktighet. Det fører nemlig til sterk kobling mellom klasser. Arv var i objektorienteringens barndom nærmest et hellig prinsipp. Det skulle føre til gjenbruk av kode ved at man enten kunne bruke et objekt som det var, eller man kunne gjøre små endringer ved å lage subklasser. Et av problemene med arv er at de bryter med prinsippet om løs kobling. Særlig i dype arvhierarkier kan man etter hvert miste oversikten. Og hvis man oppdager at ting i superklassen må forandres for at et nedarvet objekt skal kunne brukes er man ille ute. Da må alle klasser som bruker superklassen endres! Og det fremmer ikke gjenbruk. Altså: Bruk arv med forsiktighet. Hvis du kan unngå bruk av arv så gjør du det! Høy kohesjon Prinsippet om høy kohesjon er tett koblet til prinsippet om løs kobling. Begge har sin opprinnelse i tidligere tiders strukturerte metoder. Her er poenget å bygge programmer ved hjelp av moduler som er løst koblet og som hver ideelt gjør bare en ting. Modulene skal være enfoldige. En enfoldig modul som bare gjør en ting har høy kohesjon. Prinsippet er overført til objektorientering. Man skal altså tilstrebe klasser med høy kohesjon. Da får man systemer som er lette å forstå består av gjenbrukbare komponenter lette å vedlikeholde og endre I eksemplet foran om løs kobling representerte den nederste design det beste valg. Også når vi anvender prinsippet om høy kohesjon er dette valget det beste. Vi konkluderer: Løs kobling og høy kohesjon må ses i sammenheng. De er prinsipper for design man alltid skal ha i bakhodet når man designer. En klasse med høy kohesjon er kjennetegnet ved: 6

9 et lite antall operasjoner som gjør lite arbeid lette å forstå lette å vedlikeholde at de samtidig fører til løs kobling Kontroller Dette er det siste pattern vi skal se på i denne modulen. En kontroller skal håndtere systemmeldinger. I leksjon 5 så vi at en systemmelding er en ekstern melding til systemet. Kilden til meldingen er utenfor systemet og sendes av aktører. Systemmeldinger gir opphav til systemoperasjoner i programsystemet som er under design. Prinsippet sier at systemmeldinger skal håndteres av klasser med en av disse egenskapene: Representerer hele systemet (fasade kontroller) Representerer en hel virksomhet eller organisasjon (fasade kontroller) Representerer noe i den virkelige verden som er aktivt, f.eks rollen til en person (rolle kontroller) Representerer en kunstig håndterer for alle systemhendelser i en use case (use case controller) Med kunstig mener vi at vi lager klassen spesielt for formålet og at den ikke finnes igjen i problemdomenet til programmet vi skal utvikle. Hvis man har en klasse Reiseplanlegger eller Reise i løsningen av vår øvingsoppgave, så er de eksempler på klasser som representerer hele systemet. Hvis man har en klasse Reiseplanlegger så er det et eksempel på en rolle. De er kandidater til å håndtere meldinger som planleggreise() eller legginnstrekning() osv. Valg av kontrollerklasser må også ses i sammenheng med prinsippene om løs kobling og høy kohesjon. Dvs man må ikke legge for mye ansvar på noen få klasser. God objektorientert design tilsier delegering. Rollekontrollere kan lett føre til inkohesive klasser. Dvs at de ikke vil være enfoldige. Og husk at kontrollerklasser ikke skal ligge i brukergrensesnittet (Se side i læreboken). Hvis man gjør det binder man systemoperasjonene til et bestemt brukergrensesnitt. Det reduserer muligheten for gjenbruk og gjør det vanskeligere å bytte brukergrensesnitt. Klassediagrammene i design Når alt ansvar er fordelt på klasser, lager vi designets klassemodell. Utgangspunktet er interaksjonsdiagrammene som er laget når vi har brukt de forskjellige design patterns for fordeling av ansvar og oppfyllelse av postbetingelsene i kontraktene for hver systemhendelse. Design klassemodellen er gjerne en videreutvikling av den konseptuelle modellen. Mange av klassene har paralleller i den modellen. Design klassemodellen inneholder programvareklasser. Dvs programvareenheter. Vi husker at i den konseptuelle modellen (også kalt problemdomenemodellen) er det konsepter fra den virkelige verden som inngår. Design klassemodellen gir informasjon om klasser, assosiasjoner mellom klasser og attributter grensesnitt med operasjoner og konstanter operasjoner med angivelse av parametere, typen til parametere, returverdier og typen til returverdier typen til attributter navigerbarhet avhengigheter Gir vi all denne informasjonen til et verktøy, kan dette generere en god del av koden for oss. Lesestoff I tilknytning til denne leksjonen kan dere lese disse kapitlene: 14, 15, 16, 17 7

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

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

1. Modellering av objektorienterte systemer

1. Modellering av objektorienterte systemer Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Modellering av objektorienterte systemer Tore Berg Hansen Lærestoffet er utviklet for faget IFUD Objektorientert systemutvikling 1. Modellering

Detaljer

Programvare arkitekturer

Programvare arkitekturer Programvare arkitekturer 14. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

Use case drevet design med UML

Use case drevet design med UML Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

Detaljer

1. Objektorientert systemutvikling

1. Objektorientert systemutvikling Tore Berg Hansen 26.10.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Resymé: I denne leksjonen skal vi se på hvordan man kan arbeide

Detaljer

Design Patterns - mønstre

Design Patterns - mønstre Design Patterns - mønstre Om mønstre i design Kirsten Ribu 28.02.2005 1 I dag Om estimeringseksperimentet Mønstre Patterns 2 Estimeringsksperimentet 22 deltakere 11 fikk oppgitt 50 timer 11 fikk oppgitt

Detaljer

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 Mer om UML God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 1 I dag Litt repetisjon GRASP mønstre og OO design Prosjektoppgaven:

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

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

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

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

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

Tittel Objektorientert systemutvikling 2

Tittel Objektorientert systemutvikling 2 EKSAMENSFORSIDE Fagnr. OBJ208 Tittel Objektorientert systemutvikling 2 Ansvarlig faglærer Viggo Holmstedt Klasse(r) Dato IS/IN 2 11.06.2009 Eksamensoppgaven Ant. sider inkl. består av følgende: forside

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

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

19. januar 2012 Noen punkter fra i går

19. januar 2012 Noen punkter fra i går 1 19. januar 2012 Noen punkter fra i går Godkjente øvinger og prosjekt er obligatorisk for å få gå opp til eksamen Noen myter om systemutvikling Ariane 5 ulykken 2 Noen myter om systemutvikling Myte 1:

Detaljer

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1 HiOA TDK Ingeniørfag data DATS1600 Programutvikling Eva Hadler Vihovde Prosjektoppgaven 2015 - Prosessdokumentasjon - Alternativ 1 - Forsikring - Gruppe #14 Studentnavn Marius Alexander Skjolden Hans Christian

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Hva er programmering og hva vil det si å lære det?

Hva er programmering og hva vil det si å lære det? Hva er programmering og hva vil det si å lære det? Begreper i programmeringsspråk Programmeringsprosess Pedagogisk opplegg Jens Kaasbøll, Institutt for informatikk, Universitetet i Oslo 1 Programmering

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

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

INF5120 - Oblig 2. Hour Registration System (HRS)

INF5120 - Oblig 2. Hour Registration System (HRS) INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon...

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

Introduksjon til fagfeltet

Introduksjon til fagfeltet LC238D http://www.aitel.hist.no/fag/_dmdb/ Introduksjon til fagfeltet Datafiler side 2 Databasesystemer side 3-5 Databasearkitektur ANSI/SPARC side 6-7 Datamodeller side 8 Flerbruker databasesystem side

Detaljer

1 Kodegenerering fra Tau Suiten

1 Kodegenerering fra Tau Suiten Kodegenerering fra Tau Suiten For å generere Javakode eller en annen form for programmeringskode ut i fra Tau suiten, er det visse ting som må være utført.. En UML modell må eksistere og være korrekt.

Detaljer

Om prosesser 1. Om prosesser

Om prosesser 1. Om prosesser Tore Berg Hansen 27.1.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: Denne leksjonen handler om utviklingsprosesser.

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

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

Eksamensbesvarelser i REA3015 Informasjonsteknologi 2

Eksamensbesvarelser i REA3015 Informasjonsteknologi 2 Eksamensbesvarelser i REA3015 Informasjonsteknologi 2 Eksamensbesvarelsene er fra eksamen våren 2013. Forberedelsen og eksamensoppgaven finner du her: Eksamensoppgaver Eksamensveiledningen med kjennetegn

Detaljer

Objektorientert programmering av vassdragselement. Jostein Orvedal Sognekraft AS

Objektorientert programmering av vassdragselement. Jostein Orvedal Sognekraft AS Objektorientert programmering av vassdragselement Jostein Orvedal Sognekraft AS Kven er Jostein? Arbeidar som produksjonsingeniør i Sognekraft AS Bakgrunn: Ingeniør elektronikk Meir enn 25 års erfaring

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

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

20.1 Det objektorienterte paradigme (mønster)

20.1 Det objektorienterte paradigme (mønster) Kap. 20 Objektorienterte begreper og prinsipper Kap. 20 Objektorienterte begreper og prinsipper OOP - objektorientert programmering Opprinnelig fra norske SIMULA (67) Objektorientert utvikling kom i bruk

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

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Håndtering av unntak (eng: exceptions) Java-programmering Håndtering av unntak Exception-objekter og klasser try, catch og finally throw og throws Eclipse

Detaljer

Datastrukturer og Algoritmer

Datastrukturer og Algoritmer TOD 063 Datastrukturer og Algoritmer Forside fra lærebokens Nord Amerikanske utgave Tar for seg praktisk problemstilling: Hvordan håndtere containere som blir lastet fra containerskip i en travel havn

Detaljer

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen Tid: Mandag 06.08.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent

Detaljer

Veileder for kravspesifisering. for digitale læringsplattformer og digitale læringsressurser

Veileder for kravspesifisering. for digitale læringsplattformer og digitale læringsressurser Veileder for kravspesifisering for digitale læringsplattformer og digitale læringsressurser Kravspesifisering s.2av54 Innholdsfortegnelse KRAVSPESIFISERING...3 BEOVSANALYSE...8 OMFANGSBESKRIVELSE...12

Detaljer

Konseptuell modell, skjermdesign og konstruksjon

Konseptuell modell, skjermdesign og konstruksjon Konseptuell modell, skjermdesign og konstruksjon Vedlegg til øving D3 1. Gjennomgående eksempel 2. Beskrivelse av konseptuell modell 3. Skjermdesign, kobling mot konseptuell modell og oppførsel 4. Dokumentasjon

Detaljer

Bygg et Hus. Steg 1: Prøv selv først. Sjekkliste. Introduksjon. Prøv selv

Bygg et Hus. Steg 1: Prøv selv først. Sjekkliste. Introduksjon. Prøv selv Bygg et Hus Introduksjon I denne leksjonen vil vi se litt på hvordan vi kan få en robot til å bygge et hus for oss. Underveis vil vi lære hvordan vi kan bruke løkker og funksjoner for å gjenta ting som

Detaljer

Conference Centre Portal (CCP)

Conference Centre Portal (CCP) IN-MMO Obligatorisk oppgave 1 Brian Elvesæter mmo-oppgaver@ifi.uio.no 1 Conference Centre Portal (CCP) 2 1 Oblig 1: Problem description [1/3] The Conference Center Portal is an Internet portal that organizers

Detaljer

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 1 DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 2 INNHOLDSFORTEGNELSE DEL 1: Regler for navning av geografiske elementer 1 0 Orientering og

Detaljer

Produktdokumentasjon

Produktdokumentasjon Produktdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer

Detaljer

Rollemodell. for. det norske kraftmarkedet

Rollemodell. for. det norske kraftmarkedet Rollemodell for det norske kraftmarkedet Versjon: 1.1.A Dato: 27. mai 2010 INNHOLD 1. INNLEDNING... 3 1.1 OM ROLLEMODELLEN... 3 1.2 EDIEL/EBIX... 3 1.3 NOEN UAVKLARTE PROBLEMSTILLINGER... 4 1.3.1 Nettområder

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

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

det offentlige kartgrunnlaget (DOK)

det offentlige kartgrunnlaget (DOK) geografiske data som er tilrettelagt for plan- og byggesaksarbeid = det offentlige kartgrunnlaget (DOK) Terje Nuland, geodataavdelingen Det offentlige kartgrunnlaget ØK FKB DOK Lover forskrifter veiledning

Detaljer

Fra data til innsikt. Om prosjektet

Fra data til innsikt. Om prosjektet Fra data til innsikt DEFINERE FOKUS Om prosjektet De store produksjonsselskapene innen olje og gass må hele tiden strebe etter å effektivisere drift og øke sikkerheten på sine installasjoner. For å støtte

Detaljer

2. Beskrivelse av mulige prosjektoppgaver

2. Beskrivelse av mulige prosjektoppgaver Avanserte databaser (øving 9, 10, 11 & 12) Tore Mallaug 25.01.2008 Opphavsrett:Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO326D Avanserte Databaser INNLEVERINGSFRISTER (Obligatorisk

Detaljer

Førsteamanuensis John I. Dalseng Høgskolen i Finnmark 9500 Alta

Førsteamanuensis John I. Dalseng Høgskolen i Finnmark 9500 Alta Visualisering og animasjon av diskret-event simuleringsmodeller Innledning Førsteamanuensis John I. Dalseng Høgskolen i Finnmark 9500 Alta En diskret-event simuleringsmodell er et program som etterligner

Detaljer

ADDISJON FRA A TIL Å

ADDISJON FRA A TIL Å ADDISJON FRA A TIL Å VEILEDER FOR FORELDRE MED BARN I 5. 7. KLASSE EMNER Side 1 Innledning til addisjon 2 2 Grunnleggende om addisjon 3 3 Ulike tenkemåter 4 4 Hjelpemidler i addisjoner 9 4.1 Bruk av tegninger

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

S Y S T E M U T V I K L I N G ( L O 1 3 8 A )

S Y S T E M U T V I K L I N G ( L O 1 3 8 A ) A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S P R O S J E K T R A P P O RT S Y S T E M U T V I K L I N G ( L O 1 3 8 A ) H Ø S T 2011 GRUPPE 24:

Detaljer

1. SQL server. Beskrivelse og forberedelse til installasjon

1. SQL server. Beskrivelse og forberedelse til installasjon Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag SQL server. Beskrivelse og forberedelse til installasjon Stein Meisingseth 15.10.2014 Lærestoffet er utviklet for faget IDRI2001 Drift av

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

Enkle generiske klasser i Java

Enkle generiske klasser i Java Enkle generiske klasser i Java Oslo, 7/1-13 Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo Del 1: Enkle pekere Før vi tar fatt på det som er nytt i dette notatet, skal vi repetere litt

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

DOMAINING AS GRUPPENR.24

DOMAINING AS GRUPPENR.24 A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O PROSJEKTPLAN SYSTEMUTVIKLING (LO138A) HØST 2011 DOMAINING AS GRUPPENR.24 Forfattere: s171633, Truc Tran, s171171, My

Detaljer

INNFØRING I PRINSIPPER FOR OBJEKTORIENTERT PROGRAMMERING EMILIE HALLGREN OG KRISTIN BRÆNDEN

INNFØRING I PRINSIPPER FOR OBJEKTORIENTERT PROGRAMMERING EMILIE HALLGREN OG KRISTIN BRÆNDEN INNFØRING I PRINSIPPER FOR OBJEKTORIENTERT PROGRAMMERING AGENDA Bakgrunn Hva er objektorientert programmering? Pseudokode Datatyper Attributter Metoder Returverdier Lister Relasjoner Spørsmål BAKGRUNN

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

SPPR Software Project Progress Report Uke 44-45-46

SPPR Software Project Progress Report Uke 44-45-46 SPPR Software Project Progress Report Uke 44-45-46 Heiskontrollsystem Gruppe 7 Gunhild Kristiansen, Arne Enger Hansen, Cecilie Vådahl, Kristian Vågen, Magnus Asbjørnsen, Martin Stenmark Høgskolen i Østfold

Detaljer

2 Grafisk grensesnitt 1

2 Grafisk grensesnitt 1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Grafisk grensesnitt 1 Mildrid Ljosland 01.02.2011 Lærestoffet er utviklet for faget LN350D Applikasjonsutvikling for mobile enheter 2 Grafisk

Detaljer

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur 14. juni 2010 Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur Lill Kristoffersen lill.kristoffersen@ssb.no Statistisk sentralbyrå IKT Abstract:

Detaljer

AP221 Use Case TUL Administrer brukere, grupper og rettigheter

AP221 Use Case TUL Administrer brukere, grupper og rettigheter AP221 Use Case TUL Administrer brukere, grupper og rettigheter Administrer rettigheter En løsningsadministrator kan tildele andre brukere forskjellige rettigheter i Tjenesteutviklingsløsningen. Den grunnleggende

Detaljer

Pipfrog AS www.pipfrog.com. Flere nettbutikker og språk

Pipfrog AS www.pipfrog.com. Flere nettbutikker og språk Flere nettbutikker og språk Flere nettbutikker og språk For å nå en bredere kundebase og gi en bedre tjeneste ønsker du kanskje å tillate kundene å velge et språk de foretrekker når de handler. Pipfrog

Detaljer

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE Det gis ulike anbefalinger for hvordan en prosjektrapport skal se ut. Noen krav til innhold og utseende er beskrevet i forslaget nedenfor.

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

RAPPORT RAPPORT. Undersøkelse av virkningene av nytt opplegg for undervisning i objektorientert programvareutvikling

RAPPORT RAPPORT. Undersøkelse av virkningene av nytt opplegg for undervisning i objektorientert programvareutvikling R a p p o r t e r f r a H øg s k o l e n i B u s k e r u d nr. 51 RAPPORT RAPPORT Undersøkelse av virkningene av nytt opplegg for undervisning i objektorientert programvareutvikling Hallstein Asheim Hansen

Detaljer

Grafisk løsning av ligninger i GeoGebra

Grafisk løsning av ligninger i GeoGebra Grafisk løsning av ligninger i GeoGebra Arbeidskrav 2 Læring med digitale medier 2013 Magne Svendsen, Universitetet i Nordland Innholdsfortegnelse INNLEDNING... 3 GRAFISK LØSNING AV LIGNINGER I GEOGEBRA...

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

BAAN IVc. BAAN Data Navigator - Brukerhåndbok

BAAN IVc. BAAN Data Navigator - Brukerhåndbok BAAN IVc BAAN Data Navigator - Brukerhåndbok Utgitt av: Baan Development B.V. P.O.Box 143 3770 AC Barneveld The Netherlands Trykt i Nederland Baan Development B.V. 1997. Med enerett. Informasjonen i dette

Detaljer

Kravspesifikasjon. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Kravspesifikasjon. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Kravspesifikasjon Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Overordnet systembeskrivelse 4 2.1 Bakgrunn for prosjektet................................. 4 2.2 Funksjoner og

Detaljer

EKSAMEN I FAG SIF8040 - MMI OG GRAFIKK Lørdag 16. august 2003 Tid: kl. 0900-1400

EKSAMEN I FAG SIF8040 - MMI OG GRAFIKK Lørdag 16. august 2003 Tid: kl. 0900-1400 Side 1 av 6 NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET INSTITUTT FOR DATATEKNIKK OG INFORMASJONSVITENSKAP Faglig kontakt under eksamen: Dag Svanæs, Tlf: 73 59 18 42 EKSAMEN I FAG SIF8040 - MMI OG GRAFIKK

Detaljer

LocalBank Prosjektbeskrivelse

LocalBank Prosjektbeskrivelse LocalBank Prosjektbeskrivelse INNHOLD MÅL... 2 STRUKTUR... 2 IMPLEMENTASJON AV ILOCALBANKREPOSITORY... 3 GUI... 4 EXCEPTION... 4 KODE... 4 NOEN KLASSER OG SPESIELLE EMNER SOM DE VISER... 5 KLASSE DIAGRAMMER...

Detaljer

SOSI standard - versjon 4.0 1 Del 1: Introduksjon. DEL 1: Introduksjon

SOSI standard - versjon 4.0 1 Del 1: Introduksjon. DEL 1: Introduksjon SOSI standard - versjon 4.0 1 DEL 1: Introduksjon SOSI standard - versjon 4.0 2 DEL 1: Introduksjon 0 Innledning.....3 1 Endringslogg fra SOSI-versjon 3.4......4 2 Organisering......5 2.1 Målsetting...5

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF1010 Objektorientert programmering Eksamensdag: 17. august 2012 Tid for eksamen: 09.00 15.00 Oppgavesettet er på 5 sider. Vedlegg:

Detaljer

nettbasert produksjon og distribusjon av lydbøker

nettbasert produksjon og distribusjon av lydbøker nettbasert produksjon og distribusjon av lydbøker Formater i PipeOnline DAISY (Digital Accessible Information System) er en veletablert internasjonal standard for strukturering av digitale lydbøker. Standarden

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

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

JavaScriptbibliotek. Introduksjon MVVC. Informasjonsteknologi 2. Gløer Olav Langslet Sandvika VGS

JavaScriptbibliotek. Introduksjon MVVC. Informasjonsteknologi 2. Gløer Olav Langslet Sandvika VGS MVVC JavaScriptbibliotek Gløer Olav Langslet Sandvika VGS Knockout.js Informasjonsteknologi 2 Introduksjon I dag skal vi se nærmere på et JavaScriptbibliotek som heter Knockout. Knockout og andre biblioteker,

Detaljer

Geosynkronisering. Nasjonale tjenester. Kommuner GeoNorge / andre portaler. Metadata. Visning. Nedlasting. Deltakende virskomhet. Geosynkronise ring

Geosynkronisering. Nasjonale tjenester. Kommuner GeoNorge / andre portaler. Metadata. Visning. Nedlasting. Deltakende virskomhet. Geosynkronise ring Geosynkronisering Geosynkronise ring Kommuner GeoNorge / andre portaler Nasjonale tjenester Metadata Visning Nedlasting Deltakende virskomhet 1 Hva er utviklet til nå? Geosynkronise ring Spesifikasjon

Detaljer

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet?

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? HelsIT 2011 Roar Engen Leder for arkitekturseksjonen,teknologi og ehelse, Helse Sør-Øst RHF Medforfatter: Jarle

Detaljer

Tema: Nytt skoleår Fronter 92

Tema: Nytt skoleår Fronter 92 Tema: Nytt skoleår Fronter 92 Dette heftet er produsert av Fronter as www.fronter.com Heftet kan kun kopieres eller distribueres elektronisk ifølge kontrakt eller avtale med Tema: Nytt skoleår... 1 Innledning...

Detaljer

public class NaivRiking { private HeldigSnylter minsnylter; public NaivRiking(HeldigSnylter h) { minsnylter = h;

public class NaivRiking { private HeldigSnylter minsnylter; public NaivRiking(HeldigSnylter h) { minsnylter = h; Forklaring til programmet NaivRiking.java (med tilhørende filer HeldigSnylter.java, Skattbar.java, FremkomstMiddel.java, Bil.java, Sykkel.java, Hus.java, Pils.java, Brus.java, Konto.java, SpareKonto.java)

Detaljer

TDT4113 - Datateknologi, programmeringsprosjekt

TDT4113 - Datateknologi, programmeringsprosjekt TDT4113 - Datateknologi, programmeringsprosjekt Oppgave 1: Stein, Saks, Papir Dette dokumentet beskriver den første oppgaven i ProgLab 2, som vi kaller Stein, Saks, Papir. For denne oppgaven gjelder at:

Detaljer