Utvikling fra skallet og inn

Utvikling fra skallet og inn Kravspesifikasjon Brukergrensesnitt! inn ut Erik Arisholm Simula Research Laboratory Utviklingsretning Applikasjon Virkelighetsmodell Bruker Oppfatning av interesseområdet & Plattform Institutt for Informatikk jfr. Fra kjernen og ut, fra skallet og inn kapittel 9 og 10 INF102-krav-1 INF102-krav-2 Oversikt over forelesningene Mal for kravspesifikasjon Uke 12: o Onsdag 12/3: Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hva er krav? Hvem og hva påvirker krav? UML: Uttrykke krav som bruksmønstre (use cases) Overordnet systembeskrivelse (visjon) o Hva er formålet med systemet? Funksjonelle krav o Hvilke tjenester skal systemet yte? Kvalitetsønsker (ikke-funksjonelle krav) o Eks: Krav til svartider, brukervennlighet, endringsevne, oppetid o Fredag 14/3: Ansvarsdrevet design Hvordan skal systemet fungere? UML: Sekvensdiagrammer CRC: Hvordan finne gode objekter? Hva er Objekt-Orientert Analyse og Design? Rammer (påvirker funksjonelle og ikke-funksjonelle krav) o Lover og forskrifter o Teknologi og samvirke med andre systemer o Standarder o Økonomiske rammer og tidsfrister INF102-krav-3 INF102-krav-4

Hvordan finne fram til kravene? Intervjuer med potensielle brukere Observasjon av arbeidsprosesser Granskning av standarder, lover og forskrifter Prototyping o Lage enkle skjermbilder eller forslag til deler av et system, som evalueres av brukere og utviklere i fellesskap Unified Modeling Language - UML Et sett på 8 diagramteknikker, utarbeidet av toneangivende grupperinger innen OO Use Case diagram Class/object diagram Sequence diagram Collaboration diagram State diagram Activity diagram Component diagram Deployment diagram Use- Case Logical Component Concurrency Deployment INF102-krav-5 INF102-krav-6 Hva brukes UML til? Notasjon som støtter opp under metoder for o objektorientert analyse (hva systemet skal gjøre), og o objektorientert design (hvordan systemet skal gjøre det) Dokumentasjon av systemets krav, design og implementasjon for andre utviklere (og for deg selv) for kommunikasjon med kunde/sluttbruker under utviklingsprosjektet Hva er en bruksmønstermodell? En komplett bruksmønstermodell består av to komponenter o UML bruksmønsterdiagrammer som gir en visuell representasjon av modellen (oversikt over aktører, bruksmønstre og sammenhengen mellom dem) o tekstlige spesifikasjoner av hvert enkelt bruksmønster Modellen beskriver hva systemet skal gjøre o Aktør: Beskriver en bestemt type bruker av systemet Aktører kan være mennesker eller andre informasjonssystemer UML symbol for en aktør: Er ikke så sikker på denne påstanden: det er ikke sikkert at kunden forstår UML spesielt godt o Bruksmønster (use case) Kontoinnehaver Studier i norsk IT-industri tyder på at prototyper fungerer mye bedre som kommunikasjonsmiddel med sluttbrukere! beskriver en bestemt interaksjon mellom systemet og aktøren UML symbol for et bruksmønster: Ta ut penger fra kontoen INF102-krav-7 INF102-krav-8

Eksempel: Bank bruksmønsterdiagram Ta ut penger fra minibank Overfør penger Aktører (1) En aktør beskriver en (og kun en) ROLLE som en bruker (en person eller et annet system) har i forhold til systemet som skal utvikles o En person (Ola) kan ha mange roller Sett inn penger på kontoen Bankfunksjonær Aktør 1: Kontoinnehaver Aktør 2: Bankfunksjonær Kontoinnehaver Men Ola er ingen aktør i banksystemet Opprett konto Lån penger Lånebehandler Ola, som er bankfunksjonær og spiller tennis på fritiden, kan også være kontoinnehaver INF102-krav-9 INF102-krav-10 Aktører (2) Aktører (3) Aktører avgrenser systemets bruksområder: o Hvilke typer brukere vil systemet ha? o Hvilke MÅL har disse brukerne? Målene til aktørene dikterer hvilke tjenester systemet skal tilby o Primære aktører initierer bruksmønstre som oppfyller deres mål o Sekundære aktører muliggjør utførelsen av bruksmønstre o Hvilke aktører et system har, og hvorvidt en aktør er primær eller sekundær avhenger av hvor man setter grensene mellom system og dets omgivelser Aktører har MÅL. Målene er gode utgangspunkt for å finne bruksmønstre: o Kontoinnehaver : Mål1: Ta ut penger Mål2: Overføre penger Mål3: Sette inn penger Mål4: Låne penger o Bankfunksjonær o Per Mål1:Behandle lånesøknad??? INF102-krav-11 INF102-krav-12

Hva er et bruksmønster? Et bruksmønster beskriver en komplett sekvens av interaksjoner mellom aktør og system for å oppnå et bestemt MÅL Eksempel: Bank bruksmønsterdiagram Ta ut penger fra minibank Hvem er primær aktør? Hva med Behandle lånesøknad? Hva med Administrere konto? Er detaljeringsnivået riktig? Navnet på et bruksmønster representerer en brukssituasjon hvor alt går bra ( happy day scenario ). Tips! Bruk aktive setninger Overfør penger Sett inn penger på kontoen Bankfunksjonær Eksempler (): o Ta ut penger fra kontoen (ikke uttak ) o Overfør penger (ikke pengeoverføring ) Kontoinnehaver Opprett konto o Sett inn penger på kontoen (ikke innskudd ) o Opprett konto INF102-krav-13 Lån penger Lånebehandler INF102-krav-14 Hvordan lage bruksmønstermodeller? Det er ofte vanskelig å finne de riktige bruksmønstrene o Hvor STORT er et bruksmønster? o Hvor DETALJERT er et bruksmønster? o Hva MANGE bruksmønstre består modellen av? Det finnes dessverre ikke noe fasitsvar, men her er noen enkle retningslinjer: o 1: Identifiser grensen mellom systemet og omgivelser. Det bestemmer hva som er primære aktører o 2: Dersom du lar målene til det du anser som de primære aktørene styre valg av bruksmønstrene har du et godt utgangspunkt å jobbe med o 3: Dersom modellen blir svært kompleks kan man ofte velge et høyere abstraksjonsnivå (med større bruksmønstre på øverste nivå) Hvilke av disse setningene tror du representerer et bruksmønster? o Logg inn på systemet o Lei en bil o Behandle retur av leiebil o Øk produksjonen med 20% o Varesalg Hint: o Hvor går systemgrensen, hvem er primær aktør og hvilke(t) mål oppfyller bruksmønsteret? o Kan bruksmønsteret beskrives som et komplett hendelsesforløp med en veldefinert start og slutt? INF102-krav-15 INF102-krav-16

Mal for spesifikasjon av et bruksmønster Et bruksmønster er ikke komplett uten en tekstlig beskrivelse som skal bestå av følgende informasjon Navn: Hva heter bruksmønsteret Aktør: Hvem initierer bruksmønsteret Pre-betingelse: Beskriver hva som må være oppfylt for at bruksmønsteret skal kunne utføres (opsjon) Post-betingelse: Beskriver tilstand til system og aktør etter at bruktsmønsteret er utført, både ved normal hendelsesflyt og variasjoner. (opsjon) Trigger: Et situasjon eller hendelse som initierer bruksmønsteret Normal hendelsesflyt: Hva skjer når alt går bra, dvs når målet til aktøren oppnås på enklest mulig måte Beskriv spesialtilfellene (unntak fra normal hendelsesflyt) separat. Format: <Betingelse>: <konsekvenser> Relatert informasjon: For eksempel ikke-funksjonelle krav ( svartid må være bedre enn 10 sekunder ) (opsjon) Student Eks.1: Design av (del)system for kursregistrering Meld på kurs Betal semesteravgift Lag kursbeskrivelse Behandle dispensasjonssøknad K ursa dm inistra tor INF102-krav-17 INF102-krav-18 Aktør: Student Spesifikasjon av Meld på kurs Trigger: Student ønsker å melde seg på et kurs Pre-betingelse: Student har betalt semesteravgift og er logget inn på systemet Post-betingelse: Student er meldt på kurset eller student har sendt søknad om dispensasjon Normal Hendelsesflyt: 1. Studenten gir opplysinger om kurs 2. Systemet sjekker om det er ledig plass på kurset 3. Systemet sjekker at studenten kvalifiserer til å ta kurset 4. Systemet registrerer studenten på kurset og oppdaterer antall oppmeldte på kurset Spesifikasjon av Meld på kurs (forts.) 1a. Ugyldig kurs: 1. Studenten prøver igjen 2a. Kurset er fullt: 1. Systemet avslutter registreringen 3a. Kurset forutsetter andre kurs: 1. Systemet sjekker om studenten har tatt kursene 1a. Studenten har tatt kursene som forutsettes: 1. Systemet fortsetter registreringen 1b. Studenten har IKKE tatt kursene som forutsettes 1. Systemet spør om studenten ønsker å søke om dispensasjon 2. INF102-krav-19 INF102-krav-20

Eks.2: ReCycle Lag et system for deponering, gjenvinning og salg av sykler Bruksmønsterdiagram Definer produkt En sykkel er et produkt som er komponert av (består av) delprodukter (styre, gaffel, sete, osv) Produsent Komponer produkt Dekomponer produkt "Produkt" brukes som synonym for sykkel eller sykkeldel Et produktindivid er en bestemt instans av produktet (For eksempel DIN sykkel) Sjekk bestillinger Definer bruker Gjenvinning betyr å lage nye produktindivider basert på andre deponerte produktindivider Gjenbruker Legg produkt ut for salg Administrator o Dekomposisjon av deponerte produktindivider til dets bestanddeler (delproduktindivider) Deponer produkt o Komposisjon av bestanddeler (delproduktindivider) til et nytt produktindivid Kjøp produkt Betalingssystem Forbruker INF102-krav-21 INF102-krav-22 Prototyping av sentral funksjonalitet Felles funksjonalitet for alle bruksmønstrene: o Systemet lager liste over definerte produkter og aktør velger produkt o Lage en trestruktur som viser produktene * * Velg produkt komponertprodukt Produkt delprodukt Produkt A Produkt D Produkt E Produkt F Produkt G Produkt B Product D Produkt C Består av OK Cancel Spesifikasjon av dekomponer produkt Aktør: Gjenvinner Trigger: Aktør ønsker å splitte opp (dekomponere) et produktindivid i dets bestanddeler. Det kan for eksempel skyldes at en bruker har lagt inn en bestilling på en del som et bestemt produktindivid på lageret består av. Gjenvinner ønsker derfor å dekomponere slik at bestanddelen som er bestilt deretter for eksempel kan legges ut for salg. Normal Hendelsesflyt: 2. Gjenvinner angir produkt 3. Systemet returnerer liste over de produktindividene som finnes på lageret 4. Gjenbruker velger det produktindividet som skal dekomponeres 5. Systemet lager et nytt produktindivid for alle bestanddelene til det opprinnelige produktindividet og registrerer at hvert delproduktindivid nå finnes tilgjengelig hos Gjenvinner 6. Systemet fjerner det opprinnelige produktindividet <Ingen viktige. Utsatt spesifikasjon til neste iterasjon> INF102-krav-23 INF102-krav-24

Spesifikasjon av komponer produkt Aktør: Gjenvinner Trigger: Aktør ønsker å sette sammen et produktindivid fra tilgjengelige bestanddeler. Post-betingelse: Et nytt produktindivid er laget som består av delproduktindivider (bestanddeler) som slettes Normal Hendelsesflyt: 2. Gjenvinner velger produkt 3. Systemet returnerer liste over de produktindividene som finnes på lageret for et delprodukt 4. Gjenbruker velger et produktindivid som skal være med i komposisjonen for et av delproduktene Punkt 3-4 gjentas for alle delproduktene til valgt produkt 5. Systemet lager nytt produktindivid av typen "valgt produkt" 6. Gjenbruker angir kvalitet på det nykomponerte produktindividet 7. Systemet sletter de opprinnelige delproduktindividene Spesifikasjon av kjøp produkt Aktør: Forbruker Trigger: Forbruker ønsker å kjøpe et produkt Normal Hendelsesflyt: 2. Forbruker angir produkt som ønskes kjøpt 3. Systemet spør Forbruker om han også ønsker oversikt over erstatningsproduktindivider 4. Systemet returnerer en liste over produktindivider, kvalitet, hvor de befinner seg og pris 5. Forbruker velger produktindividet som ønskes kjøpt 6. Forbruker gir betalingsinformasjon (VISA el.l.) 7. Systemet gjennomfører betalingen 8. Systemet gir kvittering til Forbruker med frist for henting 3a. Det finnes ingen produktindivider for et delprodukt: 1. Systemet gir feilmelding og avslutter bruksmønsteret.... INF102-krav-25 INF102-krav-26 Variasjoner på kjøp produkt 4a. Forbruker ønsker oversikt også over erstatning produktindivider: 1. Systemet utvider listen med erstatningsproduktindivider 5a. Ingen slike produktindivider er tilgjengelige eller forbruker ønsker ingen av tilgjengelige produktindivider: 1. Systemet spør om Forbruker ønsker å legge inn en uforpliktende bestilling 1a. Forbruker ønsker ikke å legge inn bestilling: 1. Systemet avslutter bruksmønsteret 1b. Forbruker ønsker å legge inn bestilling: 1. Forbruker oppgir ønsket kvalitet på produktet 2. Systemet bekrefter bestillingen 3. Systemet avslutter bruksmønsteret 7a. Betalingen godtas ikke 1. Systemet gir feilmelding til Forbruker 2. Systemet avslutter bruksmønsteret Spesifikasjon av deponer produkt Aktør: Gjenbruker Trigger: Forbruker ønsker å deponere produkt Pre-betingelse: Produktindividet må bestå av originale deler og være komplett Post-betingelser: Deponert produktindivid er registrert i systemet. Normal hendelsesflyt: 2. Gjenbruker angir produkt som skal deponeres 3. Gjenbruker angir kvaliteten til produktindividet (god, middels, dårlig) 4. Systemet bekrefter deponering. Annen info: I denne versjonen er betalingsinformasjon ved deponering av produkt utenfor systemgrensen (privat affære mellom forbruker og gjenbruker) INF102-krav-27 INF102-krav-28

Spesifikasjon av Legg ut produkt for salg Spesifikasjon av sjekk bestillinger Aktør: Gjenbruker Trigger: Gjenbruker ønsker å legge ut et av sine produktindivider for salg Normal hendelsesflyt: 2. Gjenbruker angir produkt som ønskes solgt 3. Systemet lager liste over produktindivider som finnes på lageret 4. Gjenbruker velger produktindivid og spesifiserer utsalgspris 5. Systemet bekrefter at produktindividet er lagt ut for salg 3a. Det finnes ingen slike produktindivider på lager: 1. Systemet avslutter bruksmønsteret Aktør: Gjenbruker Trigger: Gjenbruker ønsker å sjekke bestillinger slik at han kan komponere/dekomponere produkt og/eller legge ut eksisterende produktindivider for salg Normal hendelsesflyt: 2. Gjenbruker angir produkt som det ønskes oversikt over 3. Systemet lager liste over eksisterende bestillinger på produktet 4a. Gjenbruker ønsker likevel ikke å legge ut noen av produktindividene for salg: 1. Systemet avslutter bruksmønsteret INF102-krav-29 INF102-krav-30