IN2001: Kravhåndtering, modellering, design 30 januar 2018 Yngve Lindsjørn ynglin@ifi.uio.no IN2001 -> Kravhåndtering og modellering 1
Gode beskrivelser av krav er viktig for kontrakt oppdragsgiver leverandør planlegging og oppfølging arkitektur, design og test å støtte videreutvikling og vedlikehold IN2001 -> Kravhåndtering og modellering 2
Utfordringer i kravhåndtering Kommunikasjon Felles forståelse IN2001 -> Kravhåndtering og modellering 3
Funksjonelle krav Hva (ikke hvordan) Brukerkrav Hva brukerne ønsker å kunne gjøre Systemkrav Mer detaljert definisjon av hva som skal implementeres sett fra brukernes perspektiv IN2001 -> Kravhåndtering og modellering 4
Beskrive krav Tekst Strukturert tekst User story (brukerhistorie) Use case (brukstilfelle) Modeller UML (Unified Modeling Language) BPMN (Business Process Model and Notation) IN2001 -> Kravhåndtering og modellering 5
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 IN2001 -> Kravhåndtering og modellering 6
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 IN2001 -> Kravhåndtering og modellering 7
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 IN2001 -> Kravhåndtering og modellering 8
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 IN2001 -> Kravhåndtering og modellering 9
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 IN2001 -> Kravhåndtering og modellering 10
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. Tilby kreditt Ø 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>> <<include>> Utfør kredittsjekk Basis use caset vet hvilke use case det inkluderer IN2001 -> Kravhåndtering og modellering 11
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 IN2001 -> Kravhåndtering og modellering 12
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 IN2001 -> Kravhåndtering og modellering 13
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. IN2001 -> Kravhåndtering og modellering 14
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. IN2001 -> Kravhåndtering og modellering 15
Use case i design Hendelsesflyt i use casene detaljeres ut i sekvensdiagram Domenemodellen utvides til klassediagram med systemklasser IN2001 -> Kravhåndtering og modellering 16
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 IN2001 -> Kravhåndtering og modellering 17
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å. IN2001 -> Kravhåndtering og modellering 18
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 * IN2001 -> Kravhåndtering og modellering 19
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. IN2001 -> Kravhåndtering og modellering 20
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) IN2001 -> Kravhåndtering og modellering 21
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) IN2001 -> Kravhåndtering og modellering 22
Generalisering Det er ofte nyttig å undersøke klassene i et system for å se om det er mulighet for generalisering I objektorienterte språk, som Java, er generalisering en del av språket gjennom såkalt arvemekanisme ( inheritance ) Attributter og operasjoner (metoder) som er assosiert med superklasser er også assosiert med subklasser gjennom arv. Subklassene vil så legge til mer spesifikke attributter og operasjoner IN2001 -> Kravhåndtering og modellering 23
Klassediagram - Student tar kurs Alle kurs har minst en obligatorisk oppgave. Merk at her er oblig knyttet til kurs og ikke emne slik at oblig vil kunne endres neste gang kurset går. IN2001 -> Kravhåndtering og modellering 24
Spesifikasjon av grensesnitt/interface Grensesnitt/Interface bør spesifiseres slik at objektene og andre komponenter kan designes i parallell. Ikke design representasjonen av data kun navn og metoder (uten innhold). Innholdet defineres i objektene som implementerer grensesnittet. Objekter kan ha flere grensesnitt med ulike perspektiver av metodene som er spesifisert. Klassediagrammer blir brukt i UML for spesifikasjon av grensesnitt. IN2001 -> Kravhåndtering og modellering 25
Eksempel (brukt i INF1010) Ulike klasser samme grensesnitt (Interface) IN2001 -> Kravhåndtering og modellering 26
Objektdesign: Ansvarstilordning Ansvar er knyttet til objektet i form av dets oppførsel Handling: Opprette objekt, beregne, initiere handlinger i andre objekter, kontrollere og koordinere handlinger i andre objekter. Kunnskap: Vite om private data, relaterte objekter, ting som det kan utlede eller beregne Ansvar er ikke det samme som metoder, men metoder implementeres for å oppfylle ansvaret Kategorier av ansvar: Sette (set) og hente (get) verdier av attributter Opprette og initialisere nye instanser (objekter) Hente fra og lagre til fil (ofte database) Slette instanser Legge til og slette linker for assosiasjoner (relasjoner) Kopiere, konvertere og endre Beregne numeriske resultater Navigere og søke IN2001 -> Kravhåndtering og modellering 27
Kjennetegn på god design En god utforming gjør den jobben den er ment å gjøre En god utforming er enkel og elegant Eleganse innebærer å finne akkurat riktig abstraksjonsnivå En god utforming er gjenbrukbar, utvidbar og enkel å forstå Et godt objekt har et lite og veldefinert ansvarsområde Et godt objekt skjuler implementasjonsdetaljer fra andre objekter - Grady Booch IN2001 -> Kravhåndtering og modellering 28
Analyse- vs. designmodell Analysemodellen utelater mange klasser som er nødvendige i et komplett system Er typisk en domenemodell Kan inneholde mindre enn halvparten av klassene i systemet. Uavhengig av spesielle brukergrensesnittsklasser arkitekturklasser (f.eks. design patterns klasser) Den komplette designmodellen inneholder Domenemodellen Brukergrensesnittsklasser Arkitekturklasser (f.eks. slik at klasser kan kommunisere) Utility klasser (f.eks. håndtering av mengder og strenger) IN2001 -> Kravhåndtering og modellering 29
Designprosesser Det finnes flere ulike objektorienterte designprosesser avhengig av organisasjonen som bruker prosessen Felles aktiviteter i disse prosessene inkluderer Forstå og definere systemets kontekst og eksterne interaksjoner med systemet Designe systemarkitekturen Identifisere nøkkelobjektene i systemet Utvikle designmodeller Spesifisere grensesnitt IN2001 -> Kravhåndtering og modellering 30
Designmønstre Design patterns Et designmønster er en måte å gjenbruke abstrakt kunnskap om et problem og løsningen på problemet Et mønster er en beskrivelse av et problem og essensen av løsningen Bør være tilstrekkelig abstrakt til å kunne bli gjenbrukt i ulike situasjoner I beskrivelser av mønstre brukes som regel objektorienterte teknikker som arv og polymorfisme ( Virtual methods ) IN2001 -> Kravhåndtering og modellering 31
Hvorfor bruke mønstre (patterns) for informasjonssystemer? Mye av vårt daglige virke består i å lete etter strukturer (mønstre) i omgivelsene Mønstre er vanlige løsninger på vanlige problemer Det samme gjelder utvikling av informasjonssystemer Mange systemer har grunnleggende fellestrekk Det finnes mange mønstre (patterns) som er blitt utviklet gjennom systemutviklingens historie IN2001 -> Kravhåndtering og modellering 32
Mer om Mønstre ( patterns ) Mønstre er navngitte retningslinjer for hvordan ansvar skal fordeles i ulike situasjoner. Mønstre brukes bl.a. i prosessen med å forfine sekvensdiagrammer GRASP Patterns of General Principles in Assigning Responsibilites = Mønster for problem/løsning Sentrale prinsipper er Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den Kontrollobjektprinsippet: To typer kontrollere: Fasadekontroller: En kontrollklasse har ansvar for alt (brukes i et lite system) Use case kontroller: Styrer ett use case (brukes i større systemer. Ett kontrollobjekt for hvert use case). Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet IN2001 -> Kravhåndtering og modellering 33
Ekspertprinsippet: (Information Expert) Problem: Hva er det generelle prinsipp for å tilordne ansvar til objekter? Løsning: La det objektet som har kunnskapen (dataene) også behandle den Hvordan: Begynn med å formulere ansvarsområdet: Eks: Student-kurs: Hvilket objekt har ansvar for å vite om hvilke emner som kreves for å ta et gitt emne? Hvilket objekt har ansvar for å gi en liste over alle studentene på et kurs? IN2001 -> Kravhåndtering og modellering 34
Skaperprinsippet (Creator) Problem: Hvem er ansvarlig for å opprette nye objekter? Løsning: La det objektet som må vite om de nye objektene, lage dem Hvordan: Gi klasse B ansvaret for å opprette et objekt av klasse A dersom ett av følgende er sant: B inneholder A-objekter B registrerer A-objekter B bruker A-objekter B har data som sendes til A-objektet når det opprettes IN2001 -> Kravhåndtering og modellering 35
Kontrollobjektprinsippet (Controller) Hvilken klasse skal behandle en systemhendelse/melding? Kontrolleren ligger gjerne på klienten Kontrolleren har bare metoder, få eller ingen attributter Kontrolleren gjør ikke jobben selv, men mottar og fordeler oppgaver er en slags administrator Delegerer oppgaver og styrer use case Er et bindeledd mellom brukergrensesnittet og applikasjonslaget (modellen) IN2001 -> Kravhåndtering og modellering 36
Høy kohesjon Kohesjon er et mål på hva slags ansvar et objekt har og hvor fokusert ansvaret er Et objekt som har moderat ansvar og utfører et begrenset antall oppgaver innenfor ett funksjonelt område har høy kohesjon Objekter med lav kohesjon har ansvar for mange oppgaver innen ulike funksjonelle områder IN2001 -> Kravhåndtering og modellering 37
Lav kobling Kobling er et mål på hvor sterkt et objekt er knyttet til andre objekter Et objekt med sterk kobling er avhengig av mange andre objekter, noe som kan gjøre endring vanskelig IN2001 -> Kravhåndtering og modellering 38
Analyse- vs. designmodell Analysemodellen utelater mange klasser som er nødvendige i et komplett system Er typisk en domenemodell Kan inneholde mindre enn halvparten av klassene i systemet. Uavhengig av spesielle brukergrensesnittsklasser arkitekturklasser (f.eks. design patterns klasser) Den komplette designmodellen inneholder Domenemodellen Brukergrensesnittsklasser Arkitekturklasser (f.eks. slik at klasser kan kommunisere) Utility klasser (f.eks. håndtering av mengder og strenger) IN2001 -> Kravhåndtering og modellering 39
Sekvensdiagram - Reserver bil IN2001 -> Kravhåndtering og modellering 40
Pseudo-kode Reserver bil class Reservasjonssystem { // Disse objektene kjenner vi til fra før. Bilregister br; Kunderegister kr; Kundebehandler kb; //kb er her et objekt av klassen Kundebehandler ikke med i sekvensdiagrammet ArrayList <Bil> ledigebiler; Bil bil; String kundenr; Kunde k; Kontrakt kt; // metode som legger til en kontrakt i en liste AddKontrakt(kt) { } // kundebehandler velger tidsintervall (hentedato og returdato). reserverbil (hdato, rdato) { // Systemet returnerer en liste over tilgjengelige biler innenfor de spesifiserte datoene. ledigebiler = bilregister.finnledigebiler(hentedato, returdato); // Kundebehandler velger én av bilene. bil = kb.velgbil(ledigebiler); IN2001 -> Kravhåndtering og modellering 41
Pseudo-kode Reserver bil forts. // Systemet ber om kundenr... kundenr = kb.oppgikundenummer(); if (kundenr) { // og finner kunden i systemet. k = kr.finnkunde(kundenummer); // Alternativ flyt: Kunden finnes ikke. } else { // Systemet oppretter ny kunde og fortsetter til neste steg kundeinformasjon = kr.skrivkundeinformasjon(); k = new Kunde(); k.setkundeinfo(kundeinfo) kr.registrerkunde(k); } // Vi lager en ny kontrakt. // Bil blir reservert i metoden nykontrakt. kt = new Kontrakt(); kt.setkontrakt(k,bil,hdato,rdato); AddKontrakt(kt); // Systemet bekrefter at bilen er reservert for den gitte perioden. kb.visbekreftelse(kt); } } IN2001 -> Kravhåndtering og modellering 42
Oppgave - modellering Du skal modellere deler av et system for kjøp av billetter til en IT konferanse for utviklere som varer i 3 dager. Det skal være mulig å kjøpe billetter for alle dager. Det er også mulig å kjøpe én eller to dagers billett med valg av dag(er). Systemet har en betalingsmodul. Når betalingen er godkjent, blir billetten(e) tilgjengelige i PDF-format med en strekkode som skannes ved inngangen til konferansen. Det er også mulig i systemet å melde seg som frivillig hjelper for én eller flere dager. Man legger da inn en del opplysninger om seg selv og spesifiserer hva man helst ønsker å hjelpe til med (vakt, salg av mat/drikke, rydde etc.). Alle som blir godkjent som hjelpere, får gratis inngang for den eller de dagene man arbeider som frivillig. Systemet har også en administrasjonsmodul som er tilgjengelig for ledelsen av konferansen. Denne modulen gir oversikt over antall personer som har kjøpt billetter til de ulike dagene, og den gir også oversikt over alle som har meldt seg som hjelpere til de ulike dagene. Noen med spesielle rettigheter i systemet kan godkjenne hvem som får være hjelpere. a) Tegn et use-case diagram for systemet (få med alle aktører, og angi hvilke aktører som er primære og hvilke som er sekundære). b) Tegn et sekvensdiagram for kjøp av billett til én eller flere dager. Merk: sekvensdiagrammet skal ikke modellere ønske om å være frivillig hjelper. c) Tegn et klassediagram for systemet som også tar med muligheten for å bli hjelper. IN2001 -> Kravhåndtering og modellering 43