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

Størrelse: px
Begynne med side:

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

Transkript

1 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 å bruke leksjonene til undervisning eller kursformål må ta kontakt med TISIP for nærmere avtale. Tore Berg Hansen/TISIP

2 Innholdsfortegnelse Innledning...1 Modeller og artefakter i analysen...3 Use case...3 Hvordan finne use case...6 Use case diagrammet...7 Konseptuelle modeller...8 System sekvensdiagram...10 Kontrakter...11 Ordbok...11 Lesestoff...11 Litteratur...13 i

3 Innledning Vi har i de tidligere leksjoner sett på forskjellige utviklingsprosesser, hvor vi spesielt har vektlagt at utviklingsprosesser må være iterative og inkrementelle. Dermed har vi forkastet vannfallsmodellen. Unified Process (UP) er trukket frem som den modellen, basert på inkrementell og iterativ utvikling, som ser ut til å vinne mest innflytelse i utviklingsmiljøer. En årsak er at den er godt støttet av verktøy. Vi kommer til å bruke den som en slags tråd gjennom dette kurset fordi også læreboken [1] gjør det. I tidligere leksjoner har vi sett på de viktigste modellene i Unified Modeling Language (UML), som er et visuelt modelleringsspråk og grovt gjennomført en iterasjon av en utviklingsprosess hvor de viktigste modellene vi kan lage med UML er presentert gjennom et enkelt eksempel. Vi skal i denne leksjonen se grundigere på hva vi gjør i analysen. I neste leksjon går vi videre og ser på aktivitetene i design. Det første vi skal gjøre er å avklare hva vi legger i begrepet analyse, og spesielt objektorientert analyse. En slik presisering er nødvendig. Hvis man leser forskjellige bøker og tidskrifter vil man finne at analyse ikke er noe entydig begrep. I en ordbok kan man finne denne definisjonen[2]: 1. Undersøkelse som består i at noe sammensatt oppløses i enkelte bestanddeler. 2. Utredning med grunnlag i slik undersøkelse. Eller sagt på en annen måte så er analyse et studium av noe gjennom å undersøke dets deler og sammenhengene mellom dem. Det kan også være resultatet av dette studiet. Innen systemutvikling har analyse tradisjonelt vært forbundet med den første fasen i vannfallsmodellen. Der kalles denne fasen Requirements analysis and definition (Dvs analyse og definisjon av krav). I neste fase foretar man så design. Iterative og inkrementelle utviklingsprosesser har i stedet for en slik sekvens av faser med tette skott imellom, to dimensjoner. Det er en tidsdimensjon oppdelt i faser og en aktivitetsdimensjon bestående av det man i UP kaller disipliner (se kapittel 2 i læreboken). En disiplin er en rekke aktiviteter som utføres. Disiplinene leverer resultater i form av modeller, dokumenter og produkter (med en fellesbetegnelse kalt artefakter). Flere av disiplinene har navn fra fasene i vannfallsmodellen. En stor forskjell er imidlertid av hver fase deles opp i flere iterasjoner som hver nærmest er et miniprosjekt som følger vannfallsmodellen. Men til forskjell fra vannfallmodellen fryses ikke artefaktene etter noen iterasjon eller fase. De gjennomgår en stadig utvikling og raffineres gjennom hver ny iterasjon inntil kunden tar produktet i bruk. I forskjellige faser vektlegges enkelte artefakter mer enn andre. Noen artefakter nærmer seg derfor en stabil tilstand tidligere enn andre. F.eks så vektlegges arbeidet med å finne frem til krav i iterasjoner i de tidlige faser. Man prøver altså så tidlig som mulig å få oversikt over de viktigste kravene. Men kravene vil ikke som i vannfallsmodellen bli frosset. Erfaring har vist at så lenge et produkt er under utvikling og bruk så vil kravene endres. I moderne utviklingsprosesser tar man hensyn til dette og innstiller seg på å kontrollere endringer. 1

4 I objektorientert systemutvikling blir derfor ikke analysen knyttet til en bestemt fase. Men er noe som gjøres i hele prosjektet med mer vekt i de tidlige faser, mens man senere legger mer og mer vekt på design og implementasjon. Skillet mellom analyse og design blir også mer flytende. Figuren som følger er hentet fra første utgave av læreboken til Larman. Her ser forfatteren overgangen fra analyse til design som gradvis. Hovedvekten ligger likevel i analysen på hva, mens i design dreier det seg om hvordan. Mer analyseorientert Mer designorientert hva krav undersøkelse av domenet hvordan logisk løsning Vi vil i denne leksjonen definere analyse som de aktiviteter og resulterende artefakter som er knyttet til det med å finne frem til og dokumentere kravene til systemet som skal lages. Det er vår definisjon og er ikke nødvendigvis den samme som andre legger i begrepet. Derfor er det nødvendig med en slik begrepsavklaring. F.eks så har Jacobson[3], en av hovedmennene bak UP, i sin beskrivelse av UP en disiplin han kaller analyse. Han skriver: In analysis we analyze the requirements as described in requirements capture by refining and structuring them. Hovedresultatet er hva han kaller en analysemodell. Denne modellen er en klassemodell og skal brukes av utviklere til å klarlegge hvordan systemet skal utformes. Andre vil oppfatte dette som en tidlig design. Mange som praktiserer UP hopper over denne modellen. I dette kurset gjør vi det. Booch, den andre av de tre som står bak UML og RUP har denne definisjon av analyse [4]: Objektorientert analyse er en metode for analyse som undersøker kravene i form av klasser og objekter som man finner i vokabularet til problemdomenet. Og Rumbaugh, den tredje bak UML og RUP skriver i sin klassiske bok [5] at i analysen så bygger analytikeren modeller av den virkelige verden for å vise dens viktige egenskaper. Analytikeren må arbeide sammen med brukeren for å forstå problemet fordi utsagn om problemet sjeldent er komplette eller korrekte. Analysemodellen er en 2

5 konsis, presis abstraksjon av hva det ønskede systemet skal gjøre, ikke hvordan det skal gjøre det. Objektene i modellen skal være konsepter fra applikasjonsdomenet og ikke programvarekonsepter. Forvirret? Det er etter vårt syn ikke så viktig hva aktivitetene betegnes som. Det som er viktig er at man legger innsats i å finne og dokumentere krav, både funksjonelle og ikke-funksjonelle. Dette krever igjen en grundig forståelse av problemområdet, brukerne og den terminologi som brukes. Derfor skal vi både se på modellering av kravene til systemet, så vel som på modeller for å belyse og forstå det problemområdet systemet skal brukes i. Arbeidet med dette har størst vekt tidlig i utviklingsprosjektet. Og vi understreker, som det gjøres i læreboken, at aktivitetene ikke er knyttet til en bestemt fase, som i vannfallsmodellen, men pågår hele tiden. Modeller og artefakter i analysen I det vi betegner som analysen og som har størst tyngde i oppstarts og bearbeidingsfasen (i UP) er følgende modeller og artefakter de sentrale: Use case (beskriver funksjonelle krav) Ikke-funksjonelle krav Problemdomenemodell (også kalt konseptuel modell) System sekvensdiagrammer Kontrakter Ordbok I tillegg kommer planer, eventuelle prototyper, visjoner og forretningsmuligheter. Disse vil ikke vektlegges i dette kurset ettersom vi her legger hovedvekten på objektorientert analyse og design. Use case Use case 1 står sentralt i objektorientert systemutvikling selv om det ikke er noe spesielt objektorientert med begrepet. Ivar Jacobson er trolig den som introduserte bruk av use case i objektorientert systemutvikling. Det gjorde han i sin banebrytende bok om objektorientert systemutvikling [6]. Andre teoretikere og praktikere, delvis i samarbeid med Jacobsen, har videreutviklet og systemematisert bruk av use case. I Unified Process er use case det som driver utviklingsprosessen. Jacobsen brukte use case i tillegg til tradisjonelle spesifikasjonsmetoder for bedre å forstå kravene til systemet som skal utvikles. I UP er samlingen av use case de funksjonelle kravene til systemet. Ikke-funksjonelle som naturlig kan knyttes til et use case spesifiseres sammen med use case en. Hvis det ikke er naturlig spresifiseres de i et eget dokument. I UP kalles dette dokumentet Suplementary Specification. En use case er en beskrivelse av et ganske omfattende og komplett samspill mellom brukere (aktører) av systemet og systemet. Use case er historier (på engelsk stories). Gjennom å fortelle historier om hvordan systemet skal samspille med brukerne får 1 Vi foretrekker å bruke det engelske uttrykket fordi det er et innarbeidet i terminologien. Hvis vi skulle oversette det til norsk må det bli brukssituasjon eller bruksmønster. 3

6 man en bedre forståelse av hva som kreves av systemet. Historien kan være knapp i form av noen få setninger eller omfattende med mange alternativer. Tradisjonelt har kravspesifikasjoner inneholdt lister med detaljerte krav på formen: Systemet skal. Gjennom å fortelle historier i form av use case ser man ikke på enkeltegenskaper, men på samspill. Det øker forståelsen og bedrer kommunikasjonen mellom brukere og utviklere fordi det klarere kommer frem hvilken verdi systemet skal gi brukeren. Samspillet beskrives altså i form av en historie som detaljerer flyten av hendelser mellom brukere og systemet. Hos enkelte forfattere finner man begrepet scenario brukt om den detaljerte flyten av hendelser. Noen bruker dette begrepet om instanser av use case. Med det mener de at i en konkret situasjon har et use case et helt bestemt forløp og et konkret sett med data. Man trekker parallellen til klasser og objekter (instanser). Man kan si at en klasse er en beskrivelse av hva objekter kan gjøre, mens man kan ha mange objekter som gjør de samme tingene, men med forskjellige data (verdier på attributtene). I enkelte bøker kan man finne at det skilles mellom hva man kaller essensielle use case og reelle use case. Et essensielt use case er et hendelsesforløp som utrykkes på en ideell form. Det vil si at den er mer eller mindre fri for implementasjonsdetaljer. Spesielt gjelder det detaljer knyttet til brukergrensesnittet. Reelle (eller konkrete) use case er hendelsesforløp beskrevet i detaljerte implementasjonstermer. Hvis det inngår brukergrensesnitt vises disse med detaljert plassering av kontroller og felter. Her er to eksempler fra samspillet med en minibankterminal. Essensiell: Kunden identifiserer seg. Kunden presenteres for forskjellige valgmuligheter osv. Reell: Kunden setter inn sitt kort. Systemet ber om PIN kode. Kunden taster inn koden. Systemet viser en meny med valgmuligheter osv. Det er med andre ord også her mulighet for begrepsforvirring. Scenario er for mange det samme som reelt use case. Larman bruker begrepet scenario om historien som fortelles. Det vil si at et scenario kan være både essensielt og reelt (konkret). Men det vi skal legge vekt på er at use case modellering er historiefortelling. Det er ikke å tegne diagrammer. Diagrammer er nyttige for å visualisering og kommunikasjon. Men historien som detaljerer flyten av hendelser er det essensielle. Mens historiene i Jacobsons use case var ustrukturerte legges det nå vekt på at use case skal fortelles i strukturert format. Det er flere måter å gjøre dette på. I læreboken finner man den mest omfattende måten. I [7] finner vi et noe enklere oppsett. Det har denne formen: 4

7 X. Hendelsesforløpet for use case <navn> X.1 Prebetingelse X.2 Hovedløp X.3 Sideløp (hvis det finnes) X.4 Alternative løp X er et tall som identifiserer et scenario. Vi bruker eksemplet med de geometriske figurene for å vise hvordan et scenario kan skrives etter denne malen. 1. Hendelsesforløpet for use case BeregningAvArealOgOmkrets 1.1. Prebetingelse. Ingen (dvs at det ikke er noen annen use case som må være utført før denne kan starte) Hovedløp. Denne use case starter med at det kommer opp et skjermbilde som viser en sirkel, et rektangel og et triangel. FigurBeregner har nå mulighet for å få utført beregning av areal og omkrets for slike figurer. FigurBeregner klikker på en av figurene. Hvis figuren er en sirkel, utføres S-1: BeregnSirkel. Hvis figuren er et rektangel, utføres S-2: BeregnRektangel. Hvis figuren er et triangel, utføres S-3: BeregnTriangel. FigurBeregner kan også klikke på ikonet for å avslutte. Da avsluttes use case en Sideløp S-1: BeregnSirkel. Programmet viser en dialog med et felt for innsetting av radius. FigurBeregner setter inn en radius og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-2: BeregnRektangel. Programmet viser en dialog med et felt for innsetting av høyde og bredde. FigurBeregner setter inn høyde og bredde og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-3: BeregnTriangel. Programmet viser en dialog med et felt for innsetting av triangelets tre sider. FigurBeregner setter inn de tre sider og klikker på en knapp merket Beregn (A-1). S-4 utføres. S-4: VisResultat. Programmet beregner areal og omkrets. En dialog som viser resultatet spretter frem. FigurBeregner klikker på en knapp merket OK og programmet viser skjermbildet med figurene igjen. FigurBeregner kan nå få utført nye beregninger eller avslutte programmet Alternative løp. A-1: Ugyldig verdi. Denne use case starter når en ugyldig verdi for et datafelt er satt inn. En dialog spretter frem med forklaring av problemet og FigurBeregner får mulighet til å sette inn en ny verdi. Den enkelte står fritt til å velge den formen som man mener er best. Det er en smakssak. En use case kan være mer eller mindre detaljert avhengig av hvor langt man er kommet med det: Høynivå (brief) En kortfattet beskrivelse av hendelsesforløpet. Use case identifiseres med navn og historien består av noen få linjer. 5

8 Kausal (causal) En fri tekst historie. kan bestå av flere avsnitt som dekker flere scenarier. Fullstendig (fully dressed) Den mest omfattende og strukturerte form. Hvordan finne use case Larman hadde i første utgave av sin bok to oppskrifter. Den ene baserer seg på at man har identifisert aktørerene. For hver aktør prøver man så å finne ut hvordan de vil bruke systemet. I sin siste utgave legger han vekt på å identifisere mål hver enkelt aktør har med systemet, dvs hva aktøren ønsker å oppnå av verdi fra systemet. Definer så use case for hvert av målene. Dette er et skifte fra tidligere oppfatninger om at man oppdager use case mer eller mindre direkte, til å fokusere på måloppnåelse og deretter finne use case som viser hvordan målene oppnås i samspill med systemet. Den andre måten som han nå har forlatt besto i å finne frem til eksterne hendelser som systemet skal håndtere, for deretter å knytte disse til aktører og use case. Det å finne og definere use case er ingen enkel oppgave. Vi tror derfor at man godt kan kjenne til og bruke flere måter. Selve arbeidet kan gjøres i idé-dugnader. I læreboken finner man også retningslinjer for hva som er en use case. Nybegynnere har en tendens til å la enkelttrinn bli use case. Spesielt gjelder det folk som er vandt til å tenke informasjonsflyt. Men use case er ikke flyt av informasjon. Det er historier som forteller samspillet mellom bruker og system. Legg disse fortellingene på et relativt høyt nivå. Som Larman skriver: I forbindelse med analyse av krav til datamaskin applikasjoner, legger man use case på nivået for elementære forretningsprosesser. En elementær forretningsprosess er definert som: En oppgave som utføres av en person på ett sted til en gitt tid, som svar på en hendelse i virksomheten. Oppgaven skal resultere i noe som har målbar verdi for virksomheten. Data skal deretter være i en konsistent tilstand. Mer konkret foreslår Larman denne fremgangsmåten: 1. Fastsett grensene for systemet. 2. Identifiser primære aktører. Der er de som har mål de ønsker å nå gjennom de tjenester systemet må tilby. 3. For hver primær aktør identifiseres målene. Legg målene på et nivå som svarer til definisjonene for en elementær forretnigsprosess. 4. Definer use case som tilfredsstiller disse målene. Gi use case ene navn som samsvarer med målene. Larman skiller altså mellom flere typer av aktører. Disse er: Primære aktører. Det er de som når mål gjennom bruk av systemet. Støtteaktører. Det er slike som tilbyr tjenester til systemet. Utenforstående aktør. Det er slike som har interesse av systemet uten å være direkte involvert i samspillet med systemet. 6

9 Aktører kan være både mennesker og andre systemer. Primære aktører er gjerne mennesker, mens støtteaktører oftest er andre systemer. Utenforstående aktører kan være etater eller institusjoner. Gjennom å finne slike sikrer man at alle krav til systemet blir identifisert og tatt vare på. Etter at use case er identifisert skal de rangeres. Det innebærer å finne ut hvilke use case som skal realiseres i hvilke iterasjoner i utviklingsprosessen. Her er noen kriterier for rangering av use case. Det vil si hvilke man skal ta sikte på å realisere i de tidlige inkrement: use case som har vesentlig innvirkning på utformingen av systemarkitekturen use case som gir mye informasjon og innsikt uten for store anstrengelser use case som det knytter seg risiko til eller som er tidskritiske eller har kompleks funksjonalitet use case som krever ny og risikabel teknologi use case som fører til økte inntekter eller reduserte kostnader Og glem ikke oppstarts use case en. Alle systemer har en slik. Den må gjennomløpes før andre use case kan utføres. Use case diagrammet Som understreket tidligere er hovedoppgaven med use case modellering å fortelle historier. Men i visse sammenhenger kan bilder si mer enn ord. UML gir oss use case diagrammer som et egnet redskap for det formålet. Et use case diagram kan gjøres meget detaljert gjennom å trekke inn <<include>>, <<extend>> og generalisering. Av og til under utforming av hendelsesforløpet i use case, vil man finne at flere use case har visse deler felles. Det er f.eks tilfelle i eksemplet foran hvor sideløpet VisResultat brukes av de andre sideløpene. Et slikt løp kan modelleres som et abstrakt use case og inkluderes i et use case gjennom en include assosiasjon. En abstrakt use case vil aldri bli utført alene. Ved å bruke abstrakte use case trenger man bare å beskrive ting som er felles en gang og bli mer effektiv ved gjenbruk. En extend use case er en use case som bare unntaksvis opptrer, f.eks i en alarmsituasjon. Den vil avbryte den normale use case og denne vil fortsette der avbruddet skjedde, når extend use casen er ferdig. I UML er extend og include stereotyper som angis ved at de skrives mellom hakeparenteser. Generalisering/spesialisering kan sammenlignes med arv mellom klasser. En use case kan formuleres på et høyt abstraksjonsnivå og nye use case kan avledes av denne ved å konkretisere hvordan ting gjøres. F.eks kan man ha en use case for å identifisere en bruker. Det kan gjøres på mange måter. På høyt abstraksjonsnivå beskrives dette i generelle vendinger. Av denne kan man konkretisere flere spesialtilfeller. Et kan være å bruke det som har vært mest vanlig hittil ved bruk av passord eller PIN-kode. En variant kan være å avskanne øyet eller fingeravtrykk. 7

10 Konseptuelle modeller Den neste modellen man skal arbeide med i analysen er den konseptuelle modellen. Et annet navn som brukes er problemdomenemodell. Det er en klassemodell som skal hjelpe oss til bedre å forstå det systemet som skal utvikles. Den består av klasser som representerer konsepter (objekter) og deres sammenhenger i den virkelige verden. Den viser altså konsepter, assosiasjoner mellom konsepter og attributter til konseptene. På den måten får vi også klarlagt terminologien og vokabularet knyttet til problemet. Konseptuelle modeller beskriver ikke design av systemet. Det vil si at den ikke inneholder klasser som er programvare. En annen ting er at under design vil klasser fra den konseptuelle modellen finnes igjen som programvareklasser. Et av poengene med objektorientering og programvare er nettopp at man skal bruke de samme begreper i programmet som i problemets verden. Dermed blir terskelen ved overgang fra problem til program mye lavere enn den er ved andre metoder for utvikling av programvare. Vi skal når vi ser nærmere på design se hvordan vi fører den konseptuelle modellen over i en programvaremodell. Vi skal prøve å beskrive hva som menes med konsept. Et konsept [8] er en abstraksjon som beskriver et sett med fenomener. Eksempler på konsepter er lærebøker i systemutvikling biler sportsklokker Et konsept defineres som tre ting. Det har et navn som skiller det fra andre konsepter, dets hensikt, dvs de egenskaper som skiller det fra andre konsepter, og medlemmer, dvs det settet med ting som inngår i konseptet. F.eks så tilhører Larman sin lærebok konseptet lærebøker i systemutvikling. Vi ser her at et det er en parallell mellom på den ene siden konseptbegrepet som vi bruker når vi skal beskrive problemet, og klassebegrepet som vi bruker i objektorienterte programmer. Derfor er det naturlig å illustrere konseptuelle modeller i form av klassemodeller. Men husk at konsepter beskriver problemets verden, mens klasser tilhører programvaresystemet som utgjør løsningen på problemet. Hvordan finner vi kandidater til konsepter? Det er flere måter: 1. Se etter substantiver i use case. 2. Snakk med eksperter på problemdomenet og fremtidige brukere av systemet. 3. Bruk en sjekkliste med kategorier av konsepter. 8

11 Her er et eksempel på en slik liste som forteller hva som er typiske konsepter man kan søke etter: Konsept kategori Ting man kan ta og føle på Beskrivelse eller spesifikasjon av ting Steder Transaksjoner Roller til personer Beholdere for ting Ting i en beholder Andre datamaskiner eller systemer Abstrakte substantiver Organisasjoner Hendelser Prosesser (sjeldent) Regler og politikker Kataloger Lagret informasjon Finansielle instrumenter og tjenester Manualer, bøker Eksempel Fly Produktspesifikasjon Flyplass Reservasjon Spiller Lager Enhet, passasjer Verifikasjonssystem for kredittkort Sult Salgsavdeling Salg, møte Produktsalg Kredittpolitikk Produktkatalog Oppskrift, kontrakt Aksje Reparasjonshåndbok Den vanligste feil man gjør når man identifiserer konsepter er at man lar noe være et attributt i stedet for et konsept. Hvis man er i tvil gjør man det til et konsept. Her er et eksempel på et tvilstilfelle: En reise har et bestemmelsessted. Er bestemmelsesstedet et attributt til reisen eller er det et eget konsept? Altså, vi kan ha denne situasjonen: Reise Reise Sted bestemmelsessted navn Hva er det riktige? Hvis det dreier seg om noe som ikke er en tekst eller tall, men som har utstrekning og kan hende tyngde, så er det et konsept. Vi går for situasjonen til høyre. I de konseptuelle modeller skal man angi assosiasjoner mellom konseptene. Til hjelp i å finne assosiasjoner kan denne listen brukes: A er en fysisk del av B A er en logisk del av B A er fysisk inneholdt i B A er en beskrivelse av B A er en linje i en transaksjon eller rapport B 9

12 A er kjent/logget/rapportert i B A er et medlem av B A er en organisatorisk subenhet av B A bruker eller administrerer B A kommuniserer med B A er relatert til en transaksjon i B A er en transaksjon som er relatert til en annen transaksjon i B A er nær beliggende til B A er eid av B I den konseptuelle modellen skal man bare vise attributter, ikke metoder. Et attributt er en logisk dataverdi. De er et uttrykk for hvilken kunnskap et konsept skal ha. For eksempel bør et sted vite sitt navn. System sekvensdiagram I et system sekvensdiagram illustrerer man hendelser som skjer mellom aktører og systemet. I dette diagrammet finner man to objekter, aktør og system. Se figuren. : Aktør : System melding1 melding2 melding3 Meldingene representerer det vi kaller systemhendelser. En systemhendelse er en ekstern input som genereres av en aktør. Hendelsen utløser en operasjon i systemet, en systemoperasjon. En systemoperasjon er altså en reaksjon fra systemet på en ekstern hendelse. I figuren over er det ikke vist tilhørende tekst fra hendelsesforløpet i use casen. Men det hører med i et konkret system sekvensdiagram. 10

13 Kontrakter Kontrakter er et hjelpemiddel til i definisjonen av systemets oppførsel. Under design skal vi sørge for at kontraktene blir oppfylt. Kontrakter er oftest knyttet til systemoperasjoner. En kontrakt settes opp etter dette skjemaet: Kontrakt Navn: signatur for operasjon Ansvar: hva som skal utføres Type: type av operasjon, vanligvis systemoperasjon Kryssreferanse: referanse til andre dokumenter Merknader: spesielle ting å ta hensyn til Unntak: hva som kan forårsake feil Utdata: utdata som ikke er knyttet til brukergrensesnittet Prebetingelser: antakelser om tilstanden til systemet før operasjonen utføres Postbetingelser: tilstanden til systemet etter at operasjonen er utført Kontrakter lages for hver use case. De er et supplement til use case hvor det ellers er vanskelig å få frem tilstandsendringene i systemet. Postbetingelsene utrykkes i termer knyttet til domenemodellen. Her er noen råd: 1. Finn frem til systemoperasjonene i system sekvensdiagrammet. 2. For hver systemoperasjon som er komplekse, lager man en kontrakt. 3. Start med å fylle ut ansvar som gir hensikten med operasjonen. 4. Skriv deretter postbetingelsene. Ansvar og postbetingelser er viktigst å få fastlagt. Postbetingelsene er en beskrivelse av den tilstand vi vil at systemet skal befinne seg i etter at en operasjon er utført. Gjennom denne beskrivelsen får man klart frem hva man skal ha ut av systemet før man begynner med å finne ut hvordan man skal få det til. Det overlater vi til design. På denne måten tvinges vi i analysen til å fokusere på hva systemet skal tilby uten å bli opphengt i hvordan vi skal utforme systemet. I design skal vi arbeide med å fordele ansvar på objekter slik at kontraktene blir oppfylt. Vi skriver vanligvis kontrakter for systemoperasjoner. Men vi kan også etter behov gjøre det for metoder i klasser. Larman har i sin siste utgave av læreboken nedtonet betydningen av kontrakter noe. Han har bla gjort dem mindre omfattende og skriver at man ikke nødvendigvis behøver å lage kontrakter for alle systemhendelser, bare de mest sentrale. Ordbok Vi holder oss til Larman som skriver at en ordbok (glossary) er et enkelt dokument som definerer ord og utrykk. Han sier videre at ordboken etter hvert kan utvides til en dataordbok (data dictionary). Lesestoff Stoff til denne leksjonen finner dere i kapitlene 4, 5, 6, 7, 8, 9, 10, 11, 12,

14 12

15 Litteratur 1. Craig Larman, Applying UML and Patterns, An Introduction to Object- Oriented Analysis and Design and the Unified Process, Prentice Hall, 2002, andre utgave, ISBN Tor Guttu, Norsk ordbok, Kunnskapsforlaget, 1998, ISBN Ivar Jacobson & al, The Unified Software Development Process, Addison- Wesley, 1999, ISBN Grady Booch, Object-Oriented Analyses and Design, Benjamin/Cummings, James Rumbaugh & al, Object-Oriented Modelling and Design, Prentice Hall, 1991, ISBN Ivar Jacobson & al, Object-Oriented Software Engineering, Addison- Wesley, 1992, ISBN Terry Quatrani, Visual Modelling with Rational Rose and UML, Addison- Wesley 1998, ISBN Bruegge&Dutoit, Object-oriented Software Engineering, Prentice Hall, 2000, ISBN

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

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP 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 å

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

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

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

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

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

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 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. 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

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

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

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

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse Dagens forelesning Kravspesifikasjon Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? Noen resultater fra et UML-eksperiment

Detaljer

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav? Kravspesifikasjon Kravspesifikasjon Erik Arisholm Simula Research Laboratory & Institutt for Informatikk Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? o Noen resultater

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

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

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

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

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

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

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler

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

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

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

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

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

Detaljer

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

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

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

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

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

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

AP221 Use Case TUL Oversett tjenesteutgave

AP221 Use Case TUL Oversett tjenesteutgave AP221 Use Case TUL En utgave av en tjeneste skal kunne oversettes til valgte språk. Dette gjøres av oversetter når utgaven er utviklet nok til at det er hensiktsmessig å oversette. Det er definert et hovedspråk

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

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

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

Vakt og lønnssystem - Rema 1000

Vakt og lønnssystem - Rema 1000 Avdeling for ingeniørutdanning Høgskolen i Oslo og Akershus Prosjektrapport Systemutvikling (LO138A) Høst 2011 Vakt og lønnssystem - Rema 1000 Gruppe 8 Forfattere: Andreas Baaserud, s169982 Ravi Agnihotri,

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

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

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen TDT4140: Kravinnhenting Torbjørn Skramstad IDI / NTNU Introduksjon til objektorientert design Agenda Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav Intervju Scenarier Etnografi Eksempel

Detaljer

STE6221 Sanntidssystemer Løsningsforslag

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

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

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

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

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

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

Installere JBuilder Foundation i Windows XP

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

Detaljer

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er

Detaljer

1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen

1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen Lærestoffet er utviklet for faget IFUD1019 Objektorientert systemutvikling 1. Om prosesser Resymé: Denne leksjonen

Detaljer

Tom Røise 18. Februar 2009

Tom Røise 18. Februar 2009 Forelesning IMT2243 18. Februar 2009 Tema : Kravspesifisering : litt mer om prosessen Viewpoint en myk tilnærming Use Case en scenariebasert teknikk innen metoden Objektorientert Analyse brukes til å avklare

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

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

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

Detaljer

INF 1050 BRUK AV MODELLERINGSVERKTØYET RATIONAL ROSE

INF 1050 BRUK AV MODELLERINGSVERKTØYET RATIONAL ROSE INF 1050 BRUK AV MODELLERINGSVERKTØYET RATIONAL ROSE Datamodeller og andre UML diagrammer kan selvsagt tegnes for hånd, men vi kan også bruke alt fra enkle tegneprogrammer til komplette utviklingsmiljøer.

Detaljer

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

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

Detaljer

Kreativitet i brukerundersøkelser: Personas and beyond

Kreativitet i brukerundersøkelser: Personas and beyond Kreativitet i brukerundersøkelser: Personas and beyond Riitta Hellman Karde AS Brukerundersøkelser for universell utforming av IKT fra forskning til praksis Metodeworkshop om brukerundersøkelser 21. mai

Detaljer

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse Forelesning IMT2243 1. mars 2007 Tema : Litteratur : Art.saml. Punkt 9 : Kap. 9. SASD - modellen, E. Andersen Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser

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

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

1. Datamodellering. 1.1. Kommentarer til læreboka

1. Datamodellering. 1.1. Kommentarer til læreboka Tore Mallaug 20.10.2009 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for fagene LN323D Databaser 1. Datamodellering Resymé: Denne leksjonen viser et par eksempler på ER-modellering

Detaljer

AP221 Use Case TUL Utarbeid designdokumenter

AP221 Use Case TUL Utarbeid designdokumenter AP221 Use Case TUL Utarbeid designdokumenter Utarbeid design Tjenesten designes. Dette er en samling av tre use case: Endre designdokument, Lag nytt designdokument, Last opp designdokument. Designet kan

Detaljer

Kirsten Ribu - Høgskolen i Oslo 05.05.04

Kirsten Ribu - Høgskolen i Oslo 05.05.04 Prosessmodellering Strukturert analyse og design et overblikk Gurholt & Hasle, kapittel 10 Kirsten Ribu - Høgskolen i Oslo 05.05.04 1 Perspektiver på modellering Datamodellering var lenge den mest brukte

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

UiB :: INF111 :: Øving 2

UiB :: INF111 :: Øving 2 UiB :: INF111 :: Øving 2 En øving skrevet av Martin Kolbeinsvik Innholdsfortegnelse 1 Sjakk og språkoversettelse...2 Omfang og verdensbilde...3 Gyldighet og dens relevans...3 Gyldighetsbetont omfang...4

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

KONTOR påloggingsguide / Oppsett av Outlook 2010

KONTOR påloggingsguide / Oppsett av Outlook 2010 KONTOR påloggingsguide / Oppsett av Outlook 2010 Pålogging 1. Start nettleseren (Internet Explorer) 2. Skriv kontor i URL feltet (alternativt kontor.smikt.local ) for å starte Citrix påloggingen. 3. Hvis

Detaljer

Kom i gang med programmering i Java

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

Detaljer

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

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

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

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

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

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

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes Krav og terminologi Krav Et utsagn som gjelder produktet vi skal teste og evaluere. Vi skal vurdere graden av sannhet i kravet opp mot funksjonen i produktet Funksjonelle krav Beskriver tjenestene produktet

Detaljer

AP221 Use Case SBL Send inn innsendingstjeneste

AP221 Use Case SBL Send inn innsendingstjeneste AP221 Use Case SBL Send inn innsendingstjeneste Send inn innsendingstjeneste Portalbruker kan sende inn innsendingstjeneste, sette tilbake innsendingstjeneste til forrige steg og signere innsendingstjeneste.

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

Veiledning for vedlikehold av informasjon i RESH. Versjonskontroll. Versjon Status/ Endring Ansvarlige Dato

Veiledning for vedlikehold av informasjon i RESH. Versjonskontroll. Versjon Status/ Endring Ansvarlige Dato Versjonskontroll Versjon Status/ Endring Ansvarlige Dato 1.0 Godkjent for produksjon / Pål Arve Sollie 30.juni 2011 1.1 /revidert Pål Arve Sollie 12.okt 2011 1.2 /ikoner og tekster oppdatert Pål Arve Sollie

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

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

Installere JBuilder Foundation i Mandrake Linux 10.0

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

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Eksamen i IN219, 13. desember 2001 Side 1 av 6 UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : IN219 Store programsystemer Eksamensdag : Torsdag 13. desember 2001 Tid for eksamen

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

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

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

Dette er nytt i GM EPC

Dette er nytt i GM EPC Dette er nytt i GM EPC GMs neste versjon av EPC har utallige nye funksjoner for å gjøre det raskere og enklere å finne den riktige delen. Velg Brukerhåndbok på Hjelp-menyen i EPC for å få nærmere instruksjoner

Detaljer

ff Brukermanual ebladadmin Pro

ff Brukermanual ebladadmin Pro ebladadmin ebladadmin er en nettbasert publiseringsløsning for publisering av eblad (digitale magasiner, publikasjoner, DM, årsrapporter, tilbudsaviser, kataloger, produktpermer, bruksanvisninger, mm)

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

Prosessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå

Prosessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå Prosessmodell Hurtigguider - rammeverk Sist redigert 13.06.2009 For å arbeide med prosessene, må du kunne synliggjøre og kommunisere dem på overordnet nivå. Du må også kunne bryte dem ned i mer detaljerte

Detaljer

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter AP221 Use Case - TUL - Utarbeid komponenter Utarbeid komponenter En tjeneste i Sluttbrukerløsningen har en arbeidsflyt som bestemmer de forskjellige stegene som må gjennomføres i skjemainnsendingen. Disse

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

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

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey Mamut Open Services Mamut Kunnskapsserie Kom i gang med Mamut Online Survey Kom i gang med Mamut Online Survey Innhold MAMUT ONLINE SURVEY... 1 KOM I GANG MED MAMUT ONLINE SURVEY... 3 MAMUT-BRUKERE: OPPRETT

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Side 1. Sniggabo CMS brukermanual rev. 2

Side 1. Sniggabo CMS brukermanual rev. 2 Side 1 Sniggabo CMS brukermanual rev. 2 INNHOLDSFORTEGNELSE Logg inn... 3 Menylinje... 3 Artikkelliste... 4 Ny artikkel... 5 Aktiviteter... 8 Rediger aktivitet... 9 Dokumenter... 9 Nytt dokument... 10

Detaljer

AP221 Use Case SBL Preutfyll og instansier innsendingstjeneste

AP221 Use Case SBL Preutfyll og instansier innsendingstjeneste AP221 Use Case SBL innsendingstjeneste innsendingstjeneste Preutfylling av innsendingstjenester skal hjelpe brukerne med utfyllingen av innsendingstjenesten. Der tjenesteeier kjenner til informasjonen

Detaljer

Bytte til OneNote 2010

Bytte til OneNote 2010 I denne veiledningen Microsoft OneNote 2010 ser helt annerledes ut enn OneNote 2007, så vi har laget denne veiledningen for å gjøre det så enkelt som mulig for deg å lære forskjellene. Les videre for å

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

Komme i gang. Kapittel 1 - Komme i gang... 3

Komme i gang. Kapittel 1 - Komme i gang... 3 30.01.2012 Kapittel 1... 1 DDS-CAD Arkitekt innføring i versjon 7 Komme i gang Kapittel Innhold... Side Kapittel 1 - Komme i gang... 3 Velkommen... 3 Er DDS-CAD Arkitekt installert?... 4 Operativmiljøet

Detaljer