Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Størrelse: px
Begynne med side:

Download "Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5"

Transkript

1 1

2 Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5 FRA LEVERANSE 1 (GRUPPE 2)...5 TILLEGG I FORUTSETNINGER... 5 REVIDERT UTGAVE AV SPESIFIKASJON FRA LEVERANSE BRUKSMØNSTERE...6 MODELL...6 BRUKSMØNSTER 1:... 6 BRUKSMØNSTER 2:... 6 BRUKSMØNSTER 3:... 7 SEKVENSDIAGRAMMER... 8 GENERELLE ENDRINGER I SEKVENSDIAGRAMMENE... 8 SEKVENSDIAGRAM: FINN NESTE TRE AVGANGER MED KUN RUTE...9 KOMMENTARER TIL FINN NESTE TRE AVGANGER MED KUN RUTE... 9 SEKVENSDIAGRAM: FINN NESTE TRE AVGANGER MED RUTE OG HOLDEPLASS KOMMENTARER TIL FINN NESTE TRE AVGANGER MED RUTE OG HOLDEPLASS...10 SEKVENSDIAGRAM: ANNONSER NESTE HOLDEPLASS...11 KOMMENTARER TIL ANNONSER NESTE HOLDEPLASS SEKVENSDIAGRAM: FINN NESTE TRE AVGANGER DEKOMPONERT KOMMENTARER TIL FINN NESTE TRE AVGANGER DEKOMPONERT...12 DESIGNMODELL...13 KLASSEDIAGRAM KOMMENTARER TIL KLASSEDIAGRAM COMPOSITE STRUCTURE DIAGRAM KOMMENTARER TIL COMPOSITE STRUCTURE DIAGRAM...15 COLLABORATION DIAGRAM KOMMENTARER TIL COLLABORATION DIAGRAM...16 TILSTANDSMASKINER KOMMENTARER TIL TILSTANDSDIAGRAMMENE TILSTANDSMASKIN: TRAFIKANTEN KOMMENTAR TIL TILSTANDSMASKIN: TRAFIKANTEN TILSTANDSMASKIN: SYSTEM KOMMENTAR TIL TILSTANDSMASKIN: SYSTEM TILSTANDSMASKIN: BRUKERSESJON...17 KOMMENTAR TIL TILSTANDSMASKIN: BRUKERSESJON TILSTANDSMASKIN: POSISJON...17 KOMMENTAR TIL TILSTANDSMASKIN: POSISJON...18 TILSTANDSMASKIN: RUTEDYNAMISK

3 KOMMENTAR TIL TILSTANDSMASKIN: RUTEDYNAMISK TILSTANDSMASKIN: RUTESTATISK KOMMENTAR TIL TILSTANDSMASKIN: RUTESTATISK...19 TILSTANDSMASKIN: HOLDEPLASS...19 KOMMENTAR TIL TILSTANDSMASKIN: HOLDEPLASS

4 Revisjonsoversikt Tabell over de forskjellige versjonene Versjon Primær forfatter Beskrivelse av versjon Ferdigstilt (dato) 1. (Utkast) Espenol Satte sammen dokumentet (Utkast) Espenol Oppdatering av modeller/kommentarer (Utkast) Espenol Litt småoppdateringer (Ferdig) Alle Ferdig leveranse

5 Introduksjon med forutsetninger Fra leveranse 1 (gruppe 2) Trafikanten+ er et system tiltenkt å gjøre det lett for forbrukere av offentlige kommunikasjonsmidler å få informasjon om deres posisjon til ulike formål. Når kommer neste kommunikasjonsmiddel til mitt avreisested? Hva er neste stoppested for kommunikasjonsmiddelet jeg befinner meg på? Systemet tar utgangspunkt i en kontekst tilsvarende Oslo Sporveier, som opererer med tre ulike offentlige kommunikasjonsmidler i rutetrafikk: buss, trikk og t-bane. Oslo Sporveier innehar 72 trikker, 350 busser og anslagsvis 70 t-banetog. Selv om ikke alle disse er ute samtidig (trikker er på det meste 52 i aktiv drift samtidig), så kan man likevel legge opp til at systemet skal takle kontinuerlig behandling av minimum 500 kommunikasjonsmidler. Hvert kommunikasjonsmiddel har utstyr til å sende posisjonsdata samt identifikasjonsdata, og kan motta data som trigger annonsering av stoppesteder. Systemet er plassert på en eller flere sentrale servere. Det er snakk om et system som skal motta signaler fra hvert enkelt aktive kommunikasjonsmiddel hvert 5. sekund, og man kan ut i fra det anslå at databasen må takle minimum 6000 transaksjoner pr minutt, eller et snitt på 100 transaksjoner pr sekund. Det forutsettes at databasen har timestamp. Det forutsettes at kundene besitter mobil enhet som kommuniserer over GSM-nettet, da forespørsler til systemet går via SMS. Disse tjenestene forutsettes som kjent gjennom markedsføring, og kunden forventes dermed å ha kjennskap til hva som er korrekt syntaks for å kunne benytte tjenesten. Systemet forventes å sende automatisk rettledning dersom det mottar forespørsel i feil format/syntaks. Systemet er ruteavhengig, hvilket vil si at det forutsettes at så vel kunde som kommunikasjonsmiddel benytter ruteidentifikasjon/rutenummer som parameter når data sendes til systemet. En forutsetning er derfor at kunden kjenner navn på avreisested, så vel som rutenummer. Tillegg i forutsetninger Vi syntes en melding hvert 5. sekund er litt i overkant av hva som er nødvendig. Derfor har vi bestemt at kjøretøyene sender en melding hvert 30. sekund. Det er likevel uklart hvordan disse oppdateringene skal skje når vi implementerer systemet. 5

6 Revidert utgave av spesifikasjon fra leveranse 1 Her følger modellene vi har oppdatert fra gruppe 2s leveranse. Bruksmønstere Modell Bruksmønster 1: Navn: Annonsering av neste holdeplass: Aktør: Transportmiddelet Pre-betingelse: Systemet og transportmiddelet er koblet opp mot hverandre Post-betingelse: Trigger: Transportmiddel er langt nok unna en holdeplass Normal hendelsesflyt: Transportmiddel sender ut signal om posisjon, rute og retning. Systemet mottar og kontrollerer avstand til neste stoppested. Gitt avstand trigger et kall fra systemet til transportmiddelet. Neste stoppested annonseres korrekt i transportmiddelet. 6

7 Bruksmønster 2: Navn: Informasjon om neste avgang med kun rutenr Aktør: Kunde Trigger: Kunde vil ha informasjon om neste avgang. Normal hendelsesflyt: Kunde sender forespørsel til systemet med ønsket rutenr Systemet sender opplysninger om neste transportmiddel som ikke har passert stoppestedet som er nærmest kunden. Variasjoner: 1: Kundens meldingsformat er feil, får tilbakemelding om dette. 2: Om siste avgang er gått, får kunden beskjed om dette. Bruksmønster 3: Navn: Informasjon om neste avgang med holdeplass og rutenr: Aktør: Kunde Trigger: Kunde vil ha informasjon om neste avgang Normal hendelsesflyt: Kunde sender forespørsel til systemet med ønsket rutenr og holdeplass Systemet sender opplysninger om neste transportmiddel som ikke har passert stoppestedet. Variasjoner: 1: Kundens meldingsformat er feil, får tilbakemelding om dette. 2: Siste avgang er gått, kunden får beskjed om dette. 7

8 Sekvensdiagrammer Generelle endringer i sekvensdiagrammene Vi syntes at gruppe 2 har for mange sekvensdiagrammene (7 stykker, litt unødvendig og overflødig) hvor de f.eks. hadde dekomponert RuteSystem i flere sekvensdiagrammene, ref: sd RuteSystem dekomponert i sekvensdiagram finnnesteavgang og AnnonserNesteHoldePlass. Derfor har vi kun konstruert sekvensdiagrammer i utgangspunkt ut fra de use-casene de (og vi) hadde, et for hver av tjenester. En annen grunn er at gruppe 2 brukte ting som ikke er inneholdt/modellert i klassediagrammet, f.eks. splittet de klassen Rute i rutesystem, ruteinfo, rutetabell, liveoversiktruter, statiskrutetabell osv. Dette førte til at det ble uforståelig med de sekvensdiagrammene de tegnet. Man ble usikker på hva de mente Rute egentlig gjøre, hvorfor de brukte Rute slik? For å gjøre det lettere for andre tittere å skjønne hva Rute gjør, har vi splittet klasse Rute i to klasser: RuteDynamisk (den har oversikt over hvor alle busser/trikker/t-baner er til enhver tid) og RuteStatisk (den har oversikt over alle faste rutetider). Begge disse to klassene har vi brukt hele veien i sekvensdiagrammene våre. Det samme gjelder Bruker, System, BrukerSesjon, Posisjon, og Holdeplass. Det var et viktig punkt syntes vi: Sekvendiagrammene og Klassediagram må ha en sammenheng med hverandre. I tillegg har vi lagt til assert for brukersesjonen (noe som gruppe 2 ikke hadde) som sier timeout etter 5 minutter, alt informasjon om en Bruker som posisjon og mobilnummer blir da slettet. 8

9 Sekvensdiagram: finn neste tre avganger med kun rute Kommentarer til finn neste tre avganger med kun rute Først mottar systemet en melding fra brukeren. Systemet finner så brukerens posisjon ved å bruke mobilnummeret. Deretter opprettes et objekt med informasjon om brukeren. Denne returnerer en autmatisk generert ID. Deretter sjekkes det om rutenr eksisterer. Negativ okstatus under denne prosessen gir en informativ tilbakemelding til brukeren. Videre sendes et kall til RuteDynamisk og RuteStatisk for å finne de neste 3 avgangene. Til slutt returneres resultatet og sesjonen slettes. 9

10 Sekvensdiagram: finn neste tre avganger med rute og holdeplass Kommentarer til finn neste tre avganger med rute og holdeplass Bruker sender først en melding til systemet. Systemet oppretter deretter en brukersesjon som lagre informasjon om brukeren og den aktuelle spørringen. Denne returnerer en automatisk generert ID som anonymiserer brukeren. Etter dette sender systemet kall på RuteStatisk og Holdeplass sopm sjekker om oppgitt rutenr og holdeplass eksisterer. Negativ okstatus på noe sted under denne prosessen gir en informerende feilmelding tilbake til brukeren. Nå finner systemet de neste tre avgangene gjennom kall til RuteDynamisk og RuteStatisk. Til slutt returneres resultatet og informasjonen om brukeren slettes. Dersom dette ikke er gjort etter 5 minutter pga. f.eks. systemfeil eller andre ting slettes brukeren autmatisk. 10

11 Sekvensdiagram: annonser neste holdeplass Kommentarer til annonser neste holdeplass Hvert 30. sekund sender hvert enkelt aktivt transportmiddel en melding til systemet om ID, posisjon, rute og retning. Systemet oppretter så et objekt med info om transportmiddelet. Denne returnerer en ID. Deretter sender info om posisjon til RuteDynamisk som har en oversikt over posisjoner for alle transportmiddler. Etter dette finner systemet neste holdeplass' posisjon ved et kall til Holdeplass. Hvis avstanden til neste holdeplass er rett, så sendes en beskjed tilbake til transportmiddelet om at den skal spille av en bestemt lydbeskjed (F.eks. "Neste holdeplass er..."). Deretter slettes objektet som har informasjon om denne sesjonen. Dersom denne prosessen tar mer enn 30 sekunder slettes brukersesjonsobjektet automatisk. Dette er for å hindre en opphoping av gamle, ubrukte objekter. 11

12 Sekvensdiagram: finn neste tre avganger dekomponert Kommentarer til finn neste tre avganger dekomponert Systemet prøver først å finne de tre neste avgangene i RuteDynamisk (uavhengig av retning). Hvis det ikke er flere aktive transportmiddler kaller systemet RuteStatisk, som har en oversikt over den statisk rutetabellen, og finner de neste avgangene som ikke har begynt å gå enda (F.eks. dagen etter). 12

13 Designmodell Klassediagram 13

14 Kommentarer til klassediagram I tillegg de fire klassediagrammene som gruppe 2 hadde (Rute, Holdeplass, Posisjon og Kunde) har vi lagt til noen andre klasser i vårt klassediagram for å få vårt Trafikkoppfølgingssystem til å fungere bedre. Som dere ser så har vi prøvd å lage et overordnet klassediagram hvor vi har prøvd å modellere klassene som senere skal programmeres, og pga. det har vi lagt til metoder (i kontrast til gruppe 2), i hver av de klassene. Disse metodene er da i samsvar med sekvensdiagrammene, mens klassene finner man igjen i composite structure diagrammet. Vi har hele tiden prøvd å få knyttet klassediagram, sekvensdiagrammene, composite structure og state machine sammen slik at de har en sammenheng med hverandre. I stedet for klassen Kunde har vi kalt vår klasse for Bruker, mens klasser som Holdeplass og Posisjon har vi gjenbrukt fra gruppe 2 sitt prosjekt. Når det gjelder Rute har vi splittet den opp i to deler: RuteDynamisk (den har oversikt over hvor alle busser/trikker/tbaner er til enhver tid) og RuteStatisk (den har oversikt over alle faste rutetider). I tillegg oppretter vi objekter av BrukerSesjon som lagrer nødvendige informasjoner til en bruker for eksempel brukers posisjon og mobilnummer. Den viktigste klassen i vårt system er klassen System (vi har lagt til i vårt system siden vi syntes den er nødvendig og hensiktmessig å ha med), hvor Bruker, BrukerSesjon, Holdeplass, Posisjon, RuteDynamisk og RuteStatisk har en enkel assosiasjon med System. Når en bruker sender inn en forespørsel om en eller annen informasjon forespørselen til System. System tar da kontakt direkte med de andre klassene for å de nødvendige informasjoner (alt avhengig hva slags informasjoner en bruker trenger), for eksempel sender System en forespørsel om å finne neste holdeplass til Holdeplass for å få den informasjonen og Holdeplass returnerer da en melding til System og fra System igjen får bruker svaret. Mer om dette kommer vi tilbake til i sekvensdiagrammene. Klassen System har derfor 1..* assosiasjoner med alle de andre klassene, mens ingen av disse andre klassene har relasjoner til hverandre, alt ting må skje gjennom/ved hjelp av System. 14

15 Composite structure diagram Kommentarer til composite structure diagram Vår komposittstruktur diagram er i samsvar med sekvensdiagrammene og klassediagrammet. Komposittstruktur diagrammet viser hvem de ulike objektene har tilgang til. Bruker er ikke en del av systemet, siden Bruker bare sender en forespørsel og mottar en tilbakemelding fra System. Bruker kan for eksempel ikke kommunisere direkte med Posisjon eller Holdeplass, derfor må Bruker få hjelp av System. Vårt system kan behandle flere meldinger samtidig ved hjelp av BrukerSesjon. System er hovedelement som kommuniserer med de andre elementene. Alt skjer derfor ved hjelp av System. 15

16 Collaboration diagram Kommentarer til collaboration diagram Collaboration diagrammet viser forhold mellom alle elementene som arbeider sammen i Systemets kontekst. System er det viktigste elementet som har direkte forhold med alle de andre elementene gjennom portene, fordi System kontakter de andre elementer for å få nødvendig informasjon, mens ingen av de andre elementene har direkte forhold med hverandre. 16

17 Tilstandsmaskiner Kommentarer til tilstandsdiagrammene I utgangspunktet har vi valgt å konstruere et tilstandsdiagram (med simple state) for hver av delene i Composite Structure diagrammet, og et overordnet tilstandsdiagram for hele Trafikkantens systemet. Under følger tilstandsmaskinene med kommentarer. Tilstandsmaskin: Trafikanten Kommentar til tilstandsmaskin: Trafikanten Dette er tilstandsdiagrammet for hele vårt system. Her har vi lagt opp en tilstand som er Idle slik at i kan behandle mange brukere på en gang. Systemet venter på å motta noe å gjøre, når den f.eks blir bedt om å utføre sjekkeholdeplass() gjør den det og går tilbake til ventetilstand, slik kan systemet vårt hele tiden være klar for å motta kall fra flere brukere. 17

18 Tilstandsmaskin: System Kommentar til tilstandsmaskin: System System utfører beregnavstand() samt at den mottar melding fra Bruker, sender metodekall og tilslutt returnerer melding tilbake til Bruker. 18

19 Tilstandsmaskin: Brukersesjon Kommentar til tilstandsmaskin: Brukersesjon Brukersesjon sjekker først syntaksen på meldingen. Hvis syntaksen er ok, genererer den en ID for denne brukeren og deretter opprettes en sesjon og bevarer denne til systemet er ferdig med denne brukere. Dersom syntaksen er feil, returnerer den en feilmelding og objektet slettes. 19

20 Tilstandsmaskin: Posisjon Kommentar til tilstandsmaskin: Posisjon Fra initial state blir metoden finnposisjon() kalt. I tilstanden posisjon funnet har posisjonen blitt beregnet. Deretter returnerer den posisjonen og objektet slettes. 20

21 Tilstandsmaskin: RuteDynamisk Kommentar til tilstandsmaskin: RuteDynamisk Fra rutedynamisk blir det enten kalt på finnneste3avg() eller oppdaterdynamisk(). Dersom kallet var finnneste3avg() blir det returnert de 3 neste avganger. Mens Dynamisk Rutetabell blir oppdatert hvis kallet var oppdaterdynamisk(). 21

22 Tilstandsmaskin: RuteStatisk Kommentar til tilstandsmaskin: RuteStatisk Tilstanden venter utfører metoder som sjekkomrutenreksisterer() / sjekkomholdeplasseksisterer() eller finnnesteavgangstatisk(). Etterpå blir informasjon returnert. 22

23 Tilstandsmaskin: Holdeplass Kommentar til tilstandsmaskin: Holdeplass Første tilstand oppstår når Holdeplass mottar et kall. Denne tilstanden er venter hvor den enten kaller på finnnærmesteholdeplass() eller finnnesteholdeplass(). Når den har utført den/de metodene den skal, returnerer den holdeplassen og objektet slettes. 23

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle Del - leveranse Del 2 Inf 2120 fredag 29.4 Gruppe 1 Knut Johannes Dahle AV Catrine Myhre (catrinem@ifi.uio.no) Mehdi Zare (mehdiz@ifi.uio.no) Odd Christer Brovig (oddcb@ifi.uio.no) Christer Aas (chrisva@ifi.uio.no)

Detaljer

Vårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass)

Vårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass) 1 Vårt system kan kjøres ved å skrive STUD1 konto fredo 37 (holdeplass) Holdeplass er frivillig. Dersom man kun sender linjenr finner systemet den nærmeste holdeplassen. Systemet returnerer de 3 neste

Detaljer

Universitetet i Oslo Institutt for informatikk. Leveranse 2 - inf2120. Gruppe 9. Mads Andre Bergdal Neeru Bhardwaj Saqib Riaz Trond Arne Sørby

Universitetet i Oslo Institutt for informatikk. Leveranse 2 - inf2120. Gruppe 9. Mads Andre Bergdal Neeru Bhardwaj Saqib Riaz Trond Arne Sørby Universitetet i Oslo Institutt for informatikk Leveranse 2 - inf2120 Gruppe 9 Mads Andre Bergdal Neeru Bhardwaj Saqib Riaz Trond Arne Sørby 29. april 2005 2 1 Innledning Vi har nå designet et system kalt

Detaljer

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten +

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten + INF 2120 Innlevering 1 Levert av Gruppe 4 Anders Bakken (andeba) Are O. Pedersen (arep) Daniel M. Wittwer (danielmw) Naima Akram (naimaa) Ronnie Østgaard (ronnieo) Kravspesifikasjoner til trafikanten +

Detaljer

INF 2120-PROSJEKT: ATLE WANDSVIK DAMIR NADIC SOHAIL AHMED CHAUDRY LARS ANTHONY LAMPAY FOZIA SAEED

INF 2120-PROSJEKT: <DROP 2 GRUPPE 7> ATLE WANDSVIK DAMIR NADIC SOHAIL AHMED CHAUDRY LARS ANTHONY LAMPAY FOZIA SAEED INF 2120-PROSJEKT: ATLE WANDSVIK DAMIR NADIC SOHAIL AHMED CHAUDRY LARS ANTHONY LAMPAY FOZIA SAEED 1. INTRODUKSJON Traffikanten pluss systemet er et system som gir brukere mulighet til

Detaljer

DELLEVERANSE 2 INF2120 GRUPPE 12. Jon G. Berentsen Geir A. Nilsen Lailuma Arezo

DELLEVERANSE 2 INF2120 GRUPPE 12. Jon G. Berentsen Geir A. Nilsen Lailuma Arezo DELLEVERANSE 2 INF2120 GRUPPE 12 Av Jon G. Berentsen Geir A. Nilsen Lailuma Arezo Innledning: Hensikten med vår oppgave er å lage et overvåkningssystem basert på posisjonering av mobiltelefon. Overvåkningssystemet

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 11 UML modellering og use case. Gruppetime INF1055 UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav

Detaljer

INF2120 Prosjektoppgave i modellering. Del 1

INF2120 Prosjektoppgave i modellering. Del 1 INF2120 Prosjektoppgave i modellering Del 1 Håkon Ulvestad haakonu@ifi.uio.no Jonas Winje jonaw@ifi.uio.no Amaia Santacoloma amaiac@ifi.uio.no Rakel Johnsen rakelj@ifi.uio.no Våren 2006 Innledning Prosjektoppgaven

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

Fra krav til objektdesign

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

Detaljer

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell (ny versjon) Dagens forelesning. Fra krav til objektdesign Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objektdesign Hva skal systemet gjøre? UML: Bruksmønstermodeller o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte Universitetet i Oslo Institutt for informatikk Eskild Busch UML hefte 6. desember 2000 Innhold Dette heftet tar for seg deler av UML som er sentralt i kurset IN29. Use case-, sekvens-, tilstand- og klassediagrammer,

Detaljer

INF2120. Gruppe 14. Innlevering 1. Våren Joakim Bjørnstad

INF2120. Gruppe 14. Innlevering 1. Våren Joakim Bjørnstad JegSerDeg INF2120 Gruppe 14 Innlevering 1. Våren 2006 Joakim Bjørnstad joakibj@student.matnat.uio.no Jon Andreas Lind Tollefsen jatollef@student.matnat.uio.no Abdirahman Hassan Barre abdirahb@student.matnat.uio.no

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

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG UKESOPPGAVER 7 REPETISJON GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon

Detaljer

UML-Unified Modeling Language

UML-Unified Modeling Language UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Fra krav til objekter. INF1050: Gjennomgang, uke 05 Fra krav til objekter INF1050: Gjennomgang, uke 05 Kompetansemål Systemmodellering og systemperspektiv Utvikle abstrakte modeller av et system Ulike modeller representerer ulike perspektiver av systemet

Detaljer

Use Case-modellering. INF1050: Gjennomgang, uke 04

Use Case-modellering. INF1050: Gjennomgang, uke 04 Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram

Detaljer

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 13 Mer UML modellering Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Objektorientert design - kapittel 5 og 7 UML modellering Aktivitetsdiagrammer Klassediagram Ukesoppgaver

Detaljer

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering Use case realisering Designmodellering 31.01.2005 Kirsten Ribu UML-Unified Modeling Language Use Case diagram Klassediagram Oppførselsdiagrammer Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

Hovedprosjekt i Anvendt Datateknologi Våren 2008 FORSIDE

Hovedprosjekt i Anvendt Datateknologi Våren 2008 FORSIDE PRODUKTRAPPORT Hovedprosjekt i Anvendt Datateknologi Våren 2008 FORSIDE FORORD Dette dokumentet er produktrapporten for vår gruppes hovedprosjekt ved Høgskolen i Oslo, avdeling for Ingeniørutdanning, Bachelor

Detaljer

Beskjed fra Skagestein

Beskjed fra Skagestein Beskjed fra Skagestein "I forbindelse med prosjektoppgavens delinnlevering 4 vil gruppelærerne sette opp en PHP-orakeltjeneste torsdag 7. april kl 1415-1800 på termstua i Niels Henrik Abels hus." INF1050-klasser-1

Detaljer

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Objektorientering og UML. INF1050: Gjennomgang, uke 06 Objektorientering og UML INF1050: Gjennomgang, uke 06 Kompetansemål Objektorientert design Objektdesign og ansvarstilordning Bruk av UML Fokus på klassediagrammer Designmodeller Designmønstre ( design

Detaljer

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller UML- Use case drevet analyse og design Bente Anda 23.09.2004 23.09.04 INF320 I dag Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller 23.09.04 INF320

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

Utvikling fra skallet og inn

Utvikling fra skallet og inn Utvikling fra skallet og inn Kravspesifikasjon Brukergrensesnitt! inn ut Erik Arisholm Simula Research Laboratory Utviklingsretning Applikasjon Virkelighetsmodell Bruker Oppfatning av interesseområdet

Detaljer

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av

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

DELLEVERANSE 1 INF2120 GRUPPE 12. Jon G. Berentsen Geir A Nilsen Lailuma Arezo

DELLEVERANSE 1 INF2120 GRUPPE 12. Jon G. Berentsen Geir A Nilsen Lailuma Arezo DELLEVERANSE 1 INF2120 GRUPPE 12 av Jon G. Berentsen Geir A Nilsen Lailuma Arezo Innledning: Hensikten med vår oppgave er å lage et overvåkningssystem basert på posisjonering av mobiltelefon. Overvåkningssystemet

Detaljer

Prosjektoppgave INF2120 Våren 2007: Rebusløp

Prosjektoppgave INF2120 Våren 2007: Rebusløp Prosjektoppgave INF2120 Våren 2007: Rebusløp Versjon 070219. Vi skal lage programvare for å kunne gjennomføre et Rebusløp. Prosjektformalia Generelt Alle prosjektgruppene får samme oppgave Det lages ny

Detaljer

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Klassediagram Aktivitetsdiagram Tilstandsdiagram Sekvensdiagram 1 Ta utgangspunkt i følgende klasser:

Detaljer

UNIVERSITETET I OSLO Institutt for informatikk. INF2120: ICU - a surveillance system, Drop 1. gisleal, eivindjo, tanxn, behrozm

UNIVERSITETET I OSLO Institutt for informatikk. INF2120: ICU - a surveillance system, Drop 1. gisleal, eivindjo, tanxn, behrozm UNIVERSITETET I OSLO Institutt for informatikk INF2120: ICU - a surveillance system, Drop 1 gisleal, eivindjo, tanxn, behrozm 22. februar 2006 Systemkrav I tabellen nedenfor er en oversikt over systemkravene

Detaljer

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon av Lag emne. Kursregistrering bruksmønstermodell. Dagens forelesning. Fra krav til objekter 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

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

Operatørkontroll Kvalitetsmanual - Buss. Ruter AS Versjon: Kvalitetsmanual Buss. Operatørkontroll. Fotograf: Bonanza AS

Operatørkontroll Kvalitetsmanual - Buss. Ruter AS Versjon: Kvalitetsmanual Buss. Operatørkontroll. Fotograf: Bonanza AS Operatørkontroll Kvalitetsmanual - Buss Ruter AS 15.06.2016 Versjon: 11.0 Kvalitetsmanual Buss Operatørkontroll Fotograf: Bonanza AS Innhold: Q1Dato... 2 Q2 Intervjuer ID... 2 Q3 Transportmiddel... 2 Q5

Detaljer

NB! Endring i undervisningsplanen

NB! Endring i undervisningsplanen NB! Endring i undervisningsplanen Forelesningen 24. mars må dessverre avlyses på grunn av Fagkritisk dag Se beskjed som er lagt ut på kursets nettsider og den oppdaterte undervisningsplanen INF1050-klasser-1

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

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni, 2008 Eksamen

Detaljer

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter

Spesifikasjon av Lag emne. Kursregistrering g bruksmønstermodell. Dagens forelesning. Fra krav til objekter 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

TDT4140. Systemutvikling. Øving 1. gruppe 215. Kristoffer Hagen. Sondre Løberg Sæter. Håvard Geithus. Bjørnar Valle. Henrik Knutsen.

TDT4140. Systemutvikling. Øving 1. gruppe 215. Kristoffer Hagen. Sondre Løberg Sæter. Håvard Geithus. Bjørnar Valle. Henrik Knutsen. TDT4140 Systemutvikling Øving 1 gruppe 215 Kristoffer Hagen Sondre Løberg Sæter Håvard Geithus Bjørnar Valle Henrik Knutsen Andreas Hagen Innholdsfortegnelse Use case diagram...side 3 Tekslig use case

Detaljer

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer

INF Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer INF5120 - Modellering med objekter (Oblig 2) **TimeregistreringSystem** (Designet av Alen Cemer alence@ifi.uio.no) 1 2 2-1: Business Model... 5 Scoping Statements Context Statements... 5 Goal modell...

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

1 Introduksjon til designmodellen - del B 2

1 Introduksjon til designmodellen - del B 2 Innhold Introduksjon til designmodellen - del B 2 2 UseCase 3 2. Usecasediagram........................... 3 2.2 Aktørbeskrivelser.......................... 4 2.3 Hendelsesforløp og sekvensdiagram for

Detaljer

Use Case-modell. Vurdering av oppdragsgivers krav

Use Case-modell. Vurdering av oppdragsgivers krav Use Case-modell Vurdering av oppdragsgivers krav Kravspesifikasjonen presiserer at brukergrensesnittet skal være grafisk, menybasert, ha støtte for bruk av mus og ha et intuitivt utseende, slik at enhver

Detaljer

Humanware. Trekker Breeze versjon 2.0.0.

Humanware. Trekker Breeze versjon 2.0.0. Humanware Trekker Breeze versjon 2.0.0. Humanware er stolte av å kunne introdusere versjon 2.0 av Trekker Breeze talende GPS. Denne oppgraderingen er gratis for alle Trekker Breeze brukere. Programmet

Detaljer

Fra krav til modellering av objekter

Fra krav til modellering av objekter INF1050: Systemutvikling 14. februar 2017 Fra krav til modellering av objekter Førstelektor Yngve Lindsjørn INF1050 -> Systemutvikling -> Fra krav til modellering av objekter 1 Temaer i dagens forelesning

Detaljer

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN

GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING HELGA NYRUD & KRISTIN BRÆNDEN GJENNOMGANG UKESOPPGAVER 4 USE CASE MODELLERING INF1050 V16 HELGA NYRUD & KRISTIN BRÆNDEN TEMAER SÅ LANGT I KURSET Forelesning 1: Systemutvikling og systemutviklingsprosesser Forelesning 2: Prosessmodeller

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

Leveranse 2. September 27, 2002

Leveranse 2. September 27, 2002 Leveranse 2 gruppe 42 Nils-Kristian Liborg (brukergrensesnitt), Bente Brevig (beskrivelser, aktørbeskrivelser, diagram, kvalitetssikring), Tom Olav Bruaas (beskrivelser), Eirik Lied (beskrivelser, diagram,

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

Planlegging og dokumentasjon

Planlegging og dokumentasjon Planlegging og dokumentasjon Edgar Bostrøm. - leilighetsnotat, etterutdanningskonferansen, 17.02.2010, noe revidert. Generelle kommentarer: Begrunnelse for hovedområdet Planlegging og dokumentasjon : o

Detaljer

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider.

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. 1 For hver del, alle sub deler teller likt. Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. For hvert spørsmål, hvis du trenger å

Detaljer

ProMed. Brukermanual for installasjon og bruk av mobiltelefon eller SMS og nett for sending av SMS direkte fra. for Windows

ProMed. Brukermanual for installasjon og bruk av mobiltelefon eller SMS og nett for sending av SMS direkte fra. for Windows Side 1 av 9 Brukermanual for installasjon og bruk av mobiltelefon eller SMS og nett for sending av SMS direkte fra ProMed for Windows Kundeoppfølging og Administrasjon Versjon 1.7 23.10.2009 Litt om sending

Detaljer

INF3340. Tilstandsmaskiner

INF3340. Tilstandsmaskiner INF3340 Tilstandsmaskiner Innhold Tilstandsmaskiner Mealy og Moore maskiner ASM tilstandsdiagrammer Syntese av ASM diagrammer Tilstandskoding Implementasjon ved bruk av VHDL Eksempler INF3430-Tilstandsmaskiner

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

1. Innholdsfortegnelse

1. Innholdsfortegnelse Ruteinformasjon Side 2 av 9 1. Innholdsfortegnelse 1. Innholdsfortegnelse... 2 2. Kort presentasjon av systemet... 3 3. Funksjoner... 4 3.1. Lister... 4 3.2. Melding... 5 3.3. Farger og skrifttyper...

Detaljer

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:

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

Operatørkontroll Kvalitetsmanual Buss. Kvalitetsmanual Buss. Versjon 8.0 Februar 2011 1

Operatørkontroll Kvalitetsmanual Buss. Kvalitetsmanual Buss. Versjon 8.0 Februar 2011 1 Kvalitetsmanual Buss Versjon 8.0 Februar 2011 1 Q1Dato Dato for gjennomføring av kontrollen registreres. Q 2 Intervjer ID Intervju ID registreres. (inntil 3 siffer) Q3 Transportmiddel Transportmiddelet

Detaljer

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur

Metode for ansvarsdrevet OO. Dagens forelesning. Delegering av ansvar i en trelagsarkitektur Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram

Detaljer

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8 Testdokumentasjon 1 Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte

Detaljer

MONTERINGSANVISNING TERMLIFT

MONTERINGSANVISNING TERMLIFT MONTERINGSANVISNING TERMLIFT MONTERINGSANVISNING Før du setter i gang. For montering, bruk og vedlikehold av denne motoren pakken på en sikker måte, er det flere forutsetninger som må tas. For sikkerheten

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

INF2120 Prosjektoppgaven Våren 2006

INF2120 Prosjektoppgaven Våren 2006 INF2120 Prosjektoppgaven Våren 2006 (Versjon 060125) Generelt Alle prosjektgruppene får samme oppgave. Det lages ny oppgave hvert år. Det er 3 del-leveranser (Spesifikasjon, Design, Implementasjon/Test).

Detaljer

Ofte stilte spørsmå l om Min side og Personålportålen

Ofte stilte spørsmå l om Min side og Personålportålen Ofte stilte spørsmå l om Min side og Personålportålen Klikk på problemstillingene nedenfor for å komme til svaret INNHOLDSFORTEGNELSE Hvordan logger jeg meg på Min side første gang?... 1 Hvordan setter

Detaljer

Oversikt over forelesningen. DFD sentrale konsepter. Intro til Dataflytdiagrammer (DFD) Marakas, kap. 5

Oversikt over forelesningen. DFD sentrale konsepter. Intro til Dataflytdiagrammer (DFD) Marakas, kap. 5 1 2 Oversikt over forelesningen Institutt for datateknikk og informasjonsvitenskap Guttorm Sindre Intro til Dataflytdiagrammer (DFD) Marakas, kap. 5 DFD, intro Sentrale konsept Diagramnotasjon, dialekter

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

Oppgave 1. Finn krav. Finn krav. Finn test Oppgave 1 1. Hensikten med use case er å oppnå en felles forståelse av krav til systemet mellom brukere / kunder og utviklere. Et use case er et scenario, ikke en komplett, deltaljert kravspesifikasjon.

Detaljer

Fjernstyringsenhet VRT012

Fjernstyringsenhet VRT012 Fjernstyringsenhet VRT012 Brukerveiledning V 0.1 Takk for at du kjøpte produktet vårt! Vi håper denne brukervennlige styreenheten kan hjelpe deg til å realisere dine ideer og gjøre livet enklere for brukeren.

Detaljer

INF1400. Tilstandsmaskin

INF1400. Tilstandsmaskin INF4 Tilstandsmaskin Hovedpunkter Tilstandsmaskin Tilstandstabell Tilstandsdiagram Analyse av D-flip-flop tilstandsmaskin Reduksjon av antall tilstander Tilordning av tilstandskoder Designprosedyre for

Detaljer

Basis interoperabilitetstest - ebxml

Basis interoperabilitetstest - ebxml Basis interoperabilitetstest - ebxml Testversjon: 1.0 2 Basis interoperabilitetstest - ebxml Innholdsfortegnelse 1. Revisjonshistorikk... 3 2. Basis interoperabilitetstest - ebxml... 4 Hvordan gjennomføre

Detaljer

INF1400. Tilstandsmaskin

INF1400. Tilstandsmaskin INF4 Tilstandsmaskin Hovedpunkter Tilstandsmaskin Tilstandstabell Tilstandsdiagram Analyse av D-flip-flop tilstandsmaskin Reduksjon av antall tilstander Tilordning av tilstandskoder Designprosedyre for

Detaljer

Prosjektoppgave våren 2007

Prosjektoppgave våren 2007 Prosjektoppgave våren 2007 Innledning Formålet med kurset er å bli i stand til å delta i utviklingen av informasjonssystemer. Dette innebærer: å kjenne til bruken av informasjonssystemer, å kjenne til

Detaljer

Innlevering 2b i INF2810, vår 2017

Innlevering 2b i INF2810, vår 2017 Innlevering 2b i INF2810, vår 2017 Dette er del to av den andre obligatoriske oppgaven i INF2810. Man kan oppnå 10 poeng for oppgavene i 2b, og man må ha minst 12 poeng tilsammen for 2a + 2b for å få godkjent.

Detaljer

7. Hvilket alternativ (A, B eller C) representerer hexadesimaltallet B737 (16) på oktal form?

7. Hvilket alternativ (A, B eller C) representerer hexadesimaltallet B737 (16) på oktal form? Jeg har rettet alle oppgavene og legger ut et revidert løsningsforslag. Noen av besvarelsene var glitrende! 6. Hva er desimalverdien av 0 0000 0000 (2)? Tallet er gitt på toerkomplement binær form. Eneren

Detaljer

Eksamen INF

Eksamen INF Eksamen INF5120 06.06.2005 Et løsningsforslag Oppgave 1 a) Business Model Oppgaven spør om en business model for samhandlingen mellom Buyer og Seller, og det er da viktig å ikke modellere alt det andre!!!

Detaljer

PRODUKTBESKRIVELSE NRDB. NRDB Nummerforespørsel

PRODUKTBESKRIVELSE NRDB. NRDB Nummerforespørsel PRODUKTBESKRIVELSE NRDB NRDB Nummerforespørsel Versjon 1.0 11/10/04 Nasjonal referansedatabase AS 15/10/04 Page 1 of 8 Innholdsfortegnelse 1 PRODUKTBESKRIVELSE...3 1.1 PRINSIPP...3 1.2 BESKRIVELSE AV TJENESTEN...3

Detaljer

INF 5120 Modellering med objekter

INF 5120 Modellering med objekter INF 5120 Modellering med objekter Obligatorisk oppgave nr. 1 Gruppe 4 Problem: Det skal designes en kaffemaskin til bruk blant de ansatte hos en bedrift. Eieren av bedriften ønsker en enkel og billig maskin.

Detaljer

INF1050 Systemutvikling

INF1050 Systemutvikling INF1050 Systemutvikling Prosjektoppgave V2004 Innledning Formålet med kurset er å bli i stand til å delta i utviklingen av informasjonssystemer. Dette inkluderer å kjenne til bruken av informasjonssystemer

Detaljer

INF1050 Systemutvikling

INF1050 Systemutvikling INF1050 Systemutvikling Krav til innlevering: Innleveringene skal ha: Forside med gruppenummer, dato, leveransenummer, navn på gruppemedlemmer med brukernavn og navn på prosjektet Forklarende overskrifter

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300 Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 27. juni, 2006 Eksamen

Detaljer

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl Side av 9 NTNU Norges teknisk-naturvitenskapelige universitet BMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:. juni Eksamen i fag SIF808

Detaljer

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006 Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................

Detaljer

Dagens forelesning. o Litt mer om design med UML sekvensdiagrammer. Sentralisert og delegert kontrollstil

Dagens forelesning. o Litt mer om design med UML sekvensdiagrammer. Sentralisert og delegert kontrollstil Dagens forelesning o Litt mer om design med UML sekvensdiagrammer Sentralisert og delegert kontrollstil Resultater fra et eksperiment o UML klassediagrammer Notasjon: UML klassediagram og objektdiagram

Detaljer

Brukermanual for administrasjonsverktøy Gruppe: 08-03

Brukermanual for administrasjonsverktøy Gruppe: 08-03 Brukermanual for administrasjonsverktøy Forord Denne manualen dekker administrasjonsgrensesnittet til applikasjonen. Den er tiltenkt personene som skal legge inn data, men kan også være til hjelp for de

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

Prosjektrettet systemarbeid

Prosjektrettet systemarbeid Prosjektrettet systemarbeid Funksjonsmodellering Faglærer: Kjell Toft Hansen Funksjonsmodellering Fra prosjektets brukerkravdokument: Kap. 3.1 Krav til funksjoner Kravene til funksjoner beskriver hva bruker

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

Opus Systemer AS 2013

Opus Systemer AS 2013 2013 2 Opus Dental 7.0 Innholdsfortegnelse Kapittel 1 SMS - funksjonen 3 1.1... 3 Innstillinger for SMS i firmakortet 1.2... 4 Opus SMS Service Manager 1.3... 6 Personaliakortet til pasienten 1.4 7 SMS...

Detaljer

KURSMATERIELL REPORT STUDIO DEL 1 INNHOLD: Del 1: Arbeidsområdet Del 2: Spørringer Del 3: Filterknapper

KURSMATERIELL REPORT STUDIO DEL 1 INNHOLD: Del 1: Arbeidsområdet Del 2: Spørringer Del 3: Filterknapper KURSMATERIELL 05.02.2015 REPORT STUDIO DEL 1 INNHOLD: Del 1: Arbeidsområdet Del 2: Spørringer Del 3: Filterknapper 1. ARBEIDSOMRÅDET I Workspace Advanced opprettes en «spørring» i bakgrunnen som inneholder

Detaljer

Forelesning IMT Mars 2011

Forelesning IMT Mars 2011 Forelesning IMT2243 31. Mars 2011 Tema: forts. arkitektur og OOD (ObjektOrientert Design) Eksempler på arkitekturvurderinger Yummy Inc., BUSTA, Tidligere studentprosjekter Prosjekt del 3 Designfasen Forventninger

Detaljer

Akseptansetest for mottak PLO-meldingen: Orientering om tjenestetilbud

Akseptansetest for mottak PLO-meldingen: Orientering om tjenestetilbud Akseptansetest for mottak PLO-meldingen: Orientering om tjenestetilbud Meldingsversjon: Standard for elektronisk kommunikasjon med pleie- og omsorgstjenesten, versjon 1.5, datert 30.06.2009 2 Akseptansetest

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

Brukerveiledning Versjon 1.3

Brukerveiledning Versjon 1.3 Brukerveiledning Versjon 1.3 Innholdsfortegnelse Innledning... 3 Registrering i elektronisk gjesteliste... 4 Tillatelser for gjestene... 4 Servicenivå... 4 Adgangsnivå... 4 Egendefinert... 4 Registrering

Detaljer

Akseptansetest av sending og mottak Applikasjonskvittering

Akseptansetest av sending og mottak Applikasjonskvittering Akseptansetest av sending og mottak Applikasjonskvittering Meldingsversjon: 1.0 Akseptansetest av sending og mottak Applikasjonskvittering 2 Innholdsfortegnelse 1. Revisjonshistorikk 3 2. Akseptansetest

Detaljer

PRODUKTBESKRIVELSE. NRDB Nummerforespørsel

PRODUKTBESKRIVELSE. NRDB Nummerforespørsel PRODUKTBESKRIVELSE NRDB Nummerforespørsel Versjon 1.3, mars 2012 NRDB Nummerforespørsel Versjon 1.3, mars 2012 Side 1 av 5 1. Innledning... 3 2. Beskrivelse av tjenesten... 3 2.1 Krav for tilknytning og

Detaljer

Test Beskrivelse Resultat Innhenting CBIS Programmet mottar data fra CBIS OK, men kun. Innhenting Tellus Programmet mottar data fra Tellus OK

Test Beskrivelse Resultat Innhenting CBIS Programmet mottar data fra CBIS OK, men kun. Innhenting Tellus Programmet mottar data fra Tellus OK Forord Denne testrapporten beskriver testingen som har blitt utført i løpet av prosjektet. Vi har gjennom hele utviklingsprosessen testet koden manuelt ved hjelp av debugging og ved kjøring med sammenligning

Detaljer

Ingen investeringskostnader Ingen risiko Ingen bindinger eller forpliktelser Løpende oversikt over status Enkel håndtering av nye poster

Ingen investeringskostnader Ingen risiko Ingen bindinger eller forpliktelser Løpende oversikt over status Enkel håndtering av nye poster Innledning GEOREG er et nytt system for registrering i konkurranser. Systemet baserer seg på at deltakerne har en smarttelefon med en app som muliggjør enkel registrering i en database. Systemet er spesielt

Detaljer

Prosessgrensesnitt. Generell informasjon

Prosessgrensesnitt. Generell informasjon Generell informasjon Innholdsfortegnelse Innholdsfortegnelse... 2 1.0 Innledning... 3 1.1 Ordliste... 3 1.2 Kontaktpunkt... 3 2.0 Grensesnitt for anlegg... 3 2.1 OPC... 3 2.2 OPC Server... 3 2.3 Leid samband

Detaljer