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

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

IN& &april&2019. Modellering*av*krav. Yngve&Lindsjørn. IN1030&'>Systemutvikling'>&Modellering&av&krav 1

IN2001: Kravhåndtering, modellering, design

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon

Kravspesifikasjon med. Erik Arisholm

IN2000:&Kravhåndtering,&modellering,&design

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Use Case-modellering. INF1050: Gjennomgang, uke 04

UKE 11 UML modellering og use case. Gruppetime INF1055

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? Use case modellering. Eksempel

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

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

Fra krav til modellering av objekter

UNIVERSITETET I OSLO

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

Eksamen INF1050: Gjennomgang, uke 15

Spesifikasjon av Lag emne

Fra krav til objekter. INF1050: Gjennomgang, uke 05

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

UML-Unified Modeling Language

Utvikling fra skallet og inn

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

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

Fra krav til objektdesign

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

Produktrapport Gruppe 9

UNIVERSITETET I OSLO

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

Objektorientering og UML. INF1050: Gjennomgang, uke 06

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

GJENNOMGANG OBLIGATORISK OPPGAVE 1

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

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

Prosjektrettet systemarbeid

Obligatorisk oppgave 5: Modellering av krav

GJENNOMGANG UKESOPPGAVER 6 MER OM OBJEKTORIENTERING OG UML

UNIVERSITETET I OSLO

Modellering av brukstilfeller og forretningsprosesser. Kurs i standarder, Oslo, 12. juni 2018

UML 1. Use case drevet analyse og design Kirsten Ribu

Use case drevet design med UML

Kravhåndtering. INF1050: Gjennomgang, uke 03

Løsningsforslag til Case. (Analysen)

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

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

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Mer$om$objektorientering$og$UML

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

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

GJENNOMGANG UKESOPPGAVER 9 TESTING

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

Kravspesifikasjon. Erik Arisholm. Simula Research Laboratory. Institutt for Informatikk. INF1050-krav-1

Krav analyse og objektorientert

Prøveeksamen INF1050: Gjennomgang, uke 15

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

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

Mer om objektorientering og UML

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

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

Oppgave 1: Multiple choice (20 %)

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

Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Eksamen 2013 Løsningsforslag

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

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Meeting Reservation System

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

Mer om objektorientering og UML

Beskjed fra Skagestein

Kravspesifikasjon. 14. oktober 2002

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

INF 5120 Modellering med objekter

Eksamen INF

Leveranse 2. September 27, 2002

Kravdokument Innholdsfortegnelse 1 Innledning 2 Bakgrunn og oversikt 3 Detaljerte krav 4 Systemsekvensdiagram

INF Oblig 2. Hour Registration System (HRS)

DELLEVERANSE 1 INF2120 V06

Løsningsforslag Sluttprøve 2015

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl

Gjennomgang av prøveeksamen. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Forside Eksamen INF1055 V17

Metode for ansvarsdrevet OO med UML. Dagens forelesning. Hovedflyt for Meld på kurs. Delegering av ansvar i en trelagsarkitektur

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

Entobutikk 3.TESTRAPPORT VÅR 2011

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl

Planlegging og dokumentasjon

UKE 16 Kontrakter. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

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

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

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

NB! Endring i undervisningsplanen

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

Transkript:

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 krav UML diagrammer Use Case (Bruksmønster) Domenemodell Sekvensdiagram Aktivitetsdiagram INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 2

Gode beskrivelser av krav er viktig for kontrakt oppdragsgiver leverandør planlegging og oppfølging arkitektur, design og test å støtte videreutvikling og vedlikehold INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 3

Kravene bør være forståelige (alle interessenter/stakeholders må kunne forstå kravspesifikasjonen), testbare (vi må kunne avgjøre om det ferdige systemet gjør det det skal), og sporbare (vi må vite hvilken del av koden som skal endres når det kommer nye krav). INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 4

Utfordringer i kravhåndtering Kommunikasjon Felles forståelse Ø bl.a. av når et krav er realisert? Sammenhengen fag-it Ø Hvis fagsiden dominerer, kan funksjonalitet bli besluttet uten tilstrekkelig innsikt i hva som kan realiseres i systemet Ø Hvis IT dominerer, kan den tekniske sjargongen bli dominerende og dermed blir det vanskelig å få kravene riktige Sporbarhet fra krav til arkitektur, design og kode er viktig INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 5

Eksempel - E-resept - Hentet fra detaljert funksjonell kravspesifikasjon FEST= Forskrivnings- og ekspedisjonsstøtte VRS= Vareregisteret HELFO= Helseøkonomiforvaltningen INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 6

Funksjonelle krav Hva (ikke hvordan) Forretningskrav Hva organisasjonen ønsker Brukerkrav Hva brukerne ønsker å kunne gjøre Systemkrav Mer detaljert definisjon av hva som skal implementeres sett fra brukernes perspektiv INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 7

Beskrive krav Tekst Strukturert tekst User story (brukerhistorie) Use case (brukstilfelle) Modeller UML (Unified Modeling Language) BPMN (Business Process Model and Notation) INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 8

UML - diagrammer Kilde: http://en.wikipedia.org/wiki/uni5ied_modeling_language#structure_diagrams INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 9

Diagrammer i UML (Unified Modeling Language) Aktivitetsdiagrammer viser forretningsprosesser og - arbeidsprosesser Use case diagrammer viser systemets funksjonalitet og samspillet mellom systemet og omgivelsene (brukere, andre systemer, komponenter) Sekvensdiagrammer viser samspill mellom system og omgivelser og mellom de forskjellige delene av systemet (mer detaljert enn use case diagrammene) Klassediagrammer viser objektklassene i systemet og assosiasjonene mellom disse klassene Tilstandsdiagrammer viser hvordan systemet reagerer på interne og eksterne hendelser Det er disse fem diagramtypene dere skal lære i INF1050 INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 10

Use case modellering Identifiser brukere à aktører En aktør representerer en rolle som et menneske eller et annet system når det kommuniserer med dette systemet En aktør kommuniserer med systemet via ett eller flere use case INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 11

Use case modellering Identifiser brukere à aktører Oppgave: Finn aktører for et system for registrering og behandling av lånesøknader INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 12

Use case modellering Identifiser brukere à aktører Eksempel: Aktører for et system for behandling av lånesøknader Søker Lånekonsulent Kredittbyrå Bank INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 13

Use case modellering Identifiser primære aktører Primære aktører har egne mål, dvs. de initierer use case (en eller flere) som oppfyller deres mål. Primære aktører Søker Lånekonsulent Kredittbyrå Bank INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 14

Use case modellering Identifiser sekundære aktører Sekundære aktører har ikke egne mål, men er nødvendige for å realisere målene til de primære aktørene Sekundære aktører Søker Lånekonsulent Kredittbyrå Bank INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 15

Finne aktører I workshop Brainstorming Fra tekstlige krav Blant prosjektets interessenter Spørsmål Hvem skal bruke systemet? Hvem skal administrere systemet? Hvem tilbyr informasjon til bruker informasjon fra, eller fjerner informasjon fra systemet? Hvilke eksterne ressurser skal systemet bruke? Hvilke andre systemer skal kommunisere med dette systemet? INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 16

Use case modellering: Identifiser aktørenes mål à Use case Et use case beskriver hvordan systemet oppnår et mål av verdi for en aktør Ø En historie Ø Et komplett use case består av flere ulike hendelsesforløp (flyt) Et use case beskriver en komplett funksjonell enhet Ø One person one place one time Et use case er testbart Eksempel: Use cases for lånesystemet Registrer lånesøknad Vurder lånesøknad Registrer kreditt referanse Se status Lag låneavtale Registrer nytt lån INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 17

Kan bruke de samme metodene som brukes for å finne aktører F.eks. gjennomføre workshops, gjerne i flere runder Fra prosessmodeller over forretnings- og arbeidsprosesser Spørsmål For hver aktør: Finne use case Hvilke mål ønsker aktøren å oppnå med bruk av systemet? Hvilke resultater vil aktøren oppnå med bruk av systemet? Hva er de viktigste oppgavene som aktøren ønsker at systemet skal kunne utføre? Vil aktøren skape, lagre, endre, lese eller slette data i systemet? Vil aktøren ha behov for å informere systemet om eksterne endringer? Har aktøren behov for å bli informert om hendelser i systemet? INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 18

Use case modellering: Tegn use case diagram Registrer lånesøknad Søker Se status Kredittbyrå Vurder lånesøknad Lånekonsulent Registrer kreditt referanse Lag låneavtale Registrer nytt lån Bank INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 19

Eksempel eksamensoppgave INF1050-2012 Oppgave 2 Modellering av en nettbank (40 %) Du skal lage en modell for et program som skal implementeres for en nettbank. I bankens system skal en kunde først logge seg inn i nettbanken med brukernavn og passord. Følgende tabell beskriver funksjoner som skal være tilgjengelige etter vellykket innlogging: # Funksjonelle krav 1 2 3 4 5 6 Systemet må kunne gi en oversikt over alle kontoene kunden har i nettbanken. I oversikten skal det gis saldo for hver konto som er tilgjengelig i nettbanken. Ved å trykke på et kontonavn eller kontonummer skal det gis en oversikt over alle transaksjonene siste måned for denne kontoen. Detaljene i en transaksjon viser dato for transaksjonen, en forklarende tekst, beløp og saldo på kontoen etter transaksjonen. Systemet må kunne gi en oversikt over alle transaksjonene for en gitt konto for et gitt tidsintervall (for eksempel siste år). Systemet må kunne betale en regning fra en gitt konto ved bruk av KIDnummer. Systemet må kunne legge inn en ny betalingsmottaker som fast mottaker for en gitt konto. Systemet må kunne gi en oversikt over alle faste betalingsmottakere for en gitt konto, samt endre eller slette informasjon om en betalingsmottaker. a) Lag et bruksmønster-diagram (use-case diagram) der du inkluderer alle bruksmønstrene som er nødvendige for å implementere kravene i tabellen over. INF1050->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 20

Detaljert beskrivelse av hovedflyt - Registrer lånesøknad 1. Søkeren fyller ut en lånesøknad 2. Systemet validerer informasjonen i lånesøknaden 3. Systemet henter søkerens kontohistorie med banken 4. Systemet innhenter kredittrapport for søkeren fra et kredittbyrå 5. Systemet beregner søkerens kreditt score basert på kredittrapport og kontohistorie 6. Systemet informerer søkeren om at søknaden er mottatt og blir vurdert 7. Systemet setter status på lånesøknaden til Initiell kredittsjekk ferdig 8. Systemet legger lånesøknaden i oppgavelisten til en lånekonsulent INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 21

Tilleggsinformasjon Input Lånesøker må oppgi: Navn, adresse, telefon, fødselsdato, arbeidsgiver, årslønn og samlet gjeld Forretningsregler Eksempel: Lån gis bare til personer med fast jobb Ikke-funksjonelle krav Brukervennlighet Ny bruker skal kunne registrere søknad på mindre enn 10 min. Mindre enn 1 av 10 brukeres skal avslutte registreringen uten å fullføre. Ytelse Systemet skal håndtere inntil 100 samtidige brukere INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 22

Alternativ flyt Use casene kan oppnå sitt mål på flere måter, og kan feile på flere måter, så detaljerte use case har også alternative flyt. Alternative flyt (blant annet feilsituasjoner) er viktige da det ofte er mer uenighet blant prosjektets interessenter om hva som skjer i de tilfellene enn for hovedløpet. Ethvert steg i hovedløpet kan være utgangspunkt for et alternativ flyt. Hovedløp: -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- Alternativ flyt: -------------------- -------------------- -------------------- -------------------- Alternativ flyt: -------------------- -------------------- -------------------- -------------------- Alternativ flyt: -------------------- -------------------- -------------------- -------------------- INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 23

Use case Registrer lånesøknad - Alternative flyt Hovedløp: 1. fyller ut en online lånesøknad 2. Systemet validerer informasjonen i lånesøknaden 3. Systemet henter søkerens kontohistorie med banken fra kontosystemet 4. Systemet innhenter kredittrapport for søkeren fra et eksternt kredittbyrå 5. Systemet beregner søkerens kreditt score basert på kredittrapport og kontohistorie 6. Systemet informerer søkeren om at søknaden er mottatt og blir vurdert 7. Systemet setter status på lånesøknaden til Initiell kredittsjekk ferdig 8. Systemet legger lånesøknaden i oppgavelisten til en lånekonsulent Alternativ flyt 1, steg 2: Informasjonen i lånesøknaden er ikke komplett og korrekt A1.1. Systemet returnerer lånesøknaden til søker for ytterligere utfylling. A1.2. Systemet setter lånesøknadens status til Avventer. Alternativ flyt 2, steg 3: Det er ikke tilstrekkelig kredittinformasjon om søkeren (kredittrapport er ikke tilgjengelig eller er for dårlig) A2.1. Systemet sender beskjed til søker om at søknaden er avslått A2.2. Systemet setter lånesøknadens status til Avslått. INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 24

Pre- og postbetingelser Use case Vurder lånesøknad : Prebetingelse: Lånesøknaden har status Initiell kredittsjekk ferdig Postbetingelser: Lånesøknaden har status Godkjent, Lånesøknaden har status Informasjon mangler, eller Lånesøknaden har status Avslått og søker har fått beskjed om at søknaden er avslått Mer presist v.h.a. domeneobjekter: Prebetingelse: Lånesøknad.status = Initiell kredittsjekk ferdig Postbetingelser: Lånesøknad.status = Godkjent or Lånesøknad.status = Informasjon mangler or (Lånesøknad.status = Avslått and Kunde.beskjed = Sendt ) Pre- og postbetingelser er bl.a. nyttige i funksjonell test INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 25

Relasjoner mellom og use case Extend og Include relasjonen Include-relasjonen: Et use case kan være en del av ett flere andre use case. Extend-relasjonen: Et use case som beskriver tilleggsoppførsel som utføres under gitte omstendigheter INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 26

Include-relasjonen To eller flere use cases kan ha en felles del (noen like steg). Denne delen kan da legges ut i et eget use case som disse use casene kan inkludere. Ø Include kan også brukes for å forenkle store use case med mange steg Ø Include kan også brukes for å håndtere steg som kan forekomme når som helst i utførelsen av use caset Søker * * Kunde Registrer lånesøknad Basis use case * * <<include>> Tilby kreditt <<include>> Utfør kredittsjekk Basis use caset vet hvilke use case det inkluderer INF1050->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 27

Extend-relasjonen Alternativ oppførsel som utføres i noen tilfeller kan skrives som eget use case som utvider (extends) et annet Extend use case beskriver hvordan oppnå et tilleggsresultat Basis use caset er fullstendig definert uten extensions, disse utvider funksjonaliteten Basis use caset kjenner sine extend use cases Bruk av alternativ flyt vs. bruk av extend use case: Ø Alternativ flyt beskriver hva som skjer ved avvik i normal flyt, mens Ø Extend use case beskriver hvordan oppnå tilleggsresultat. Lånekonsulent * * Vurder lånesøknad <<extend>> Basis use case <<extend>> Godkjenn lånesøknad med betingelser Be om ytterligere kredittinformasjon Extend use case INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 28

Use case vs. smidig utvikling I smidig utvikling jobber produkteier sammen med utviklere i samme team Det er mindre behov for detaljerte beskrivelser av krav og ofte brukes user stories (en lett versjon av use case) Eks: Som lånekonsulent ønsker jeg å kunne vurdere lånesøknader slik at jeg kan gi en riktig og rask vurdering Krav utvikles underveis og beskrives on demand v Først tilstrekkelig for prioritering i produktkøen v Så tilstrekkelig for prioritering i sprint backloggen INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 29

Use case vs. user stories Likheter. Begge viser Hvem som skal bruke systemet Hva de skal gjøre med det Hvorfor de skal gjøre det Forskjeller Omfang, kompletthet, livslengde, hensikt User stories er godt egnet for å finne krav og bruke disse i smidig utvikling i samarbeid med produkteier/kunde Use case er mer detaljert, har flere bruksområder videre i prosjektet og er mer egnet som dokumentasjon Men, det er en flytende overgang mellom dem. INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 30

Use case i prosjektplanlegging Planlegg hvilke use case som skal implementeres i hvilke iterasjoner av prosjektet: Implementer use casene i henhold til hvor viktige de er og/eller hvor vanskelige de antas å være å implementere. Hovedflyt implementeres først, deretter alternativene. Estimer hvor mange use case (eller hendelsesflyt og alternative flyt) som kan implementeres i en iterasjon. INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 31

Use case i design Hendelsesflyt i use casene detaljeres ut i sekvensdiagram Domenemodellen utvides til klassediagram med systemklasser INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 32

Use case i funksjonelle tester Use case kan være utgangspunkt for testprosedyrer (manuelle eller automatiserte) Dette gir Effektiv utforming av tester Fokus på test av egenskaper som er viktig for bruker Et testcase for hver vei Gjennom use caset Testcase: 1. Prebetingelse 2. Input data 3. Steg 4. 5... 6. Forventet resultat INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 33

Domenemodell UML klassediagrammer uten metoder Domenemodellen viser objekter i problemdomenet. Hensikten med domenemodellen er å forstå objektene og få en oversikt over terminologi. Domenemodellen er nyttig i forbindelse med use case modellering fordi: Domenemodellen viser informasjonen om objekter i use casene. Den er et viktig verktøy for å sjekke at use casene er beskrevet med riktig detaljeringsnivå. Klassene i domenemodellen kan brukes i utforming av pre- og postbetingelser for use caset. INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 34

Domenemodell - eksempel Kunde -Navn -Persnr -Kundenr -Beskjed 1 * Lånesøknad -Nummer -Beløp -Status -Kundenr 1 1 1 1 * Konto * Lån -Nummer -Saldo -Betingelser * -Nummer -Saldo -Betingelser 1 1 * Kontohistorikk -Innskudd -Uttak * Kreditt score -Score * Kredittbyrå -Navn 1 Kredittrapport -Kundenr -Score * INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 35

Sekvensdiagrammer Et flyt i et use case kan modelleres med sekvensdiagrammer. For hvert use case lages typisk sekvensdiagram for hovedflyt og for hyppig forekommende alternative flyt. Stegene (sekvensene se tekstlig beskrivelse) i et use case vises som meldinger som sendes mellom objektene ved kall på objektenes metoder. INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 36

Sekvensdiagram Registrer lånesøknad hovedflyt Lånesys : Lånesyst em : Søker 1: fyllutsøknad() konto : Kontosystem kbyrå : Kredittbyrå lånekons : Lånekonsulent 2: HentKontoInformasjon(Pnr) 3: kontoinformas jon 4: HentKredit trapport(pnr) 5: KredittRapport 6: BeregnKredittscore() 7: LeggiOppgaveliste(søknad) INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 37

Sekvensdiagram Se pasientinfo P : Pasientinfo D : MHCPMS-DB A : Autorisasjon : Medisinsk saksbehandler 1: SePasient info (PID) 2: Report (Info, PID, UID) 3: Autorisasjon(Info, UID) 4: Autorisasjon Alt Autorisasjon ok 5: Pasientinfo Autorisasjon feilet 6: Feilmelding (Ingen aksess) INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 38

Sekvensdiagram Hent resept Fra detaljert funksjonell spesifikasjon E-resept INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 39

Aktivitetsdiagrammer Et aktivitetsdiagram kan grafisk representere hendelsesflyten i et use case. Stegene i use casene vises som aktiviteter Beslutninger underveis vises som (diamant) Aktivitetsdiagrammer og sekvensdiagrammer brukes noe overlappende, men sekvensdiagrammer er typisk mer kodenært mens aktivitetsdiagrammer er mer forretningsnært. INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 40

Aktivitetsdiagram Registrer lånesøknad INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 41