Kravspesifiseringsprosessen

Transkript

1 IMT2243: 18.februar 2010 DAGENS : Metoder for å få kartlagt de Funksjonelle kravene Strukturert Analyse den gamle måten og gjøre det på (dette foilsettet + wikipedia-omtalen er eneste pensum innen SA) Introduksjon til Objektorientert Analyse Use Case en scenariebasert teknikk innen metoden Objektorientert Analyse brukes til å avklare og dokumentere funksjonelle krav - Use Case diagram - Use Case tekstbeskrivelse - high level (grov, brukerkrav) - Use Case tekstbeskrivelse - expanded level (detaljert, systemkrav) - SSD : System Sequence Diagram Pensum : Kap. 7 i Sommerville Art.saml: Stumpf,Teague kap. 4 Kravspesifiseringsprosessen Feasibility study elicitation and analysis specification Feasibility report System models User and system requirements validation document Strukturert analyse Hva er det : Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser under spesifiseringsarbeidet. SA ble utformet på en tid der fossefall-modellen hadde utstrakt anvendelse, og man ofte hadde rasjonalisering som hovedmål ved utvikling av nye IT-systemer - altså på slutten av 79-tallet. ITsystemene skulle i stor grad hjelpe til med å automatisere prosessering av informasjon der man ut fra en Input og et sett manipuleringsregler skulle få generert en Output. Input Process Output (IPO) står i fokus for all kartlegging. Metoden er fortsatt relevant å anvende i spesifiseringsarbeid spesielt når man arbeider etter en sekvensiell utviklingsmodell.

2 Strukturert analyse Man forsøker å lage gode systemmodeller/beskrivelser : Dataflytdiagrammer DataDictionary Datamodeller Strukturert språk (Structured Definition Language) Beslutningstrær SA er en funksjonsorientert metode : - finne funksjonene i systemet - kartlegge informasjonsflyten rundt funksjonene Eksempel på en SYSTEMMODELL : Klient 1. Registere klient Klientregister Personalia Klientinfo 2. Motta Klientkode Timer_idag 4. Generere dagsrapport Timeforespørsel timebestilling Timeregister Timetilbakemelding Dagsinforamsjon Kapasitet Dagsforespørsel Dagsrapportgrunndata Timehistorikk Tannlege Klinikkdata Tjenesteforespørsel 5. Registrere klinikkinfo Klinikkinfo Tjenesterapportgrunndata 3. Generere Klinikkinfo tjenestestatistikk Kontoransatt Tjenesteliste Prosess (funksjon) Bearbeider/manipulerer input om til output En prosessboble for hver funksjon i systemet Navngis ut fra hva den gjør

3 Dataflyt (informasjonsflyt) Viser hvordan data/informasjon flyter i systemet. Vi fokuserer på logiske modeller og flyt av modeller. anvendes også til å vise flyt av fysiske elementer. Modellen viser ikke rekkefølgen på flytene, bare retning Navngis Detaljspesifiseres i DataDictionary Datalager / register Viser en samling av data som må ligge lagret i systemet Viser ikke hvordan dataene skal lagres Dataene ligger passive inntil de blir kalt opp Unngå registre uten inn og ut flyt Lengst mulig ned i -strukturen Terminator / Ekstern enhet Viser kilder til / mottaker av informasjonsflyt i vårt system Kan være roller, interessenter, andre systemer etc.

4 Nivåhåndteringen i Kontekstdiagram Viser omgivelsene til vårt system. Sentral informasjonsflyt til og fra systemet modelleres, og vil bidra til å klarlegge kravene til alle eksterne grensesnitt for vår løsning Nivå 1 Bryter systemboblen fra kontekstdiagrammet ned i enkeltprosesser som samlet viser den sentrale funksjonalitet i systemet. Nivå 2 Er en detaljering av de mer komplekse dataprosessene på nivå 1 Tips ved utarbeidelse av 1. Hold modellen på en side 2. Velg gode og meningsfulle navn - roller fremfor navn - navn på prosess = et verb + et objekt 3. Ikke lag modeller med mange elementer - mindre enn 10 prosesser - få registre (vi driver IKKE databasedesign her) 4. Ikke forsøk å si alt med modellen, vis det viktige - lesbart og forståelig Objektorientering - Historikk Opprinnelsen (oppdaget ikke oppfunnet) : Nygaard/Dahl - SIMULA67 OO i programmering : 70 tallet FoU / Pilot 80 tallet Kommersiell bruk (C++, Windows) 90 tallet Forretn.applik.og Internett-teknologien Forklaring : Tilgjengelighet på prog.språk Kapasitetseksplosjon innen HW OO i Design og Analyse : 67 Programmering 90 Design 95-> Analyse

5 Hvorfor tenke objekt-orientert også i analysefasen? Drivkraften var en målsettingen om forbedret kvalitet i programvaren Produktet skal være korrekt, pålitelig, verifiserbart, robust osv... Objektorientert tilnærming hadde suksess innen programmering og dels også innen Design Sterkt ønske inne fagfeltet om å bli bedre på gjenbruk både internt og eksternt Så store fordeler av å benytte samme perspektiv gjennom hele SU-prosessen Utgangspunktet for å tenke nytt i tilnærmingen ved Spesifisering : Ønske om et metodeverk som er bedre og mer fleksibelt til å håndtere de endringer i krav som ALLTID kommer underveis i et systemutviklingsprosjekt Den bærende ideen innen Objektorientering er at man mener Objektene er den mest stabile del av problemområdet, mens Prosesseringen/Manipuleringsmekanismene i langt større grad er utsatt for stadige forandringer Objektorientert Analyse er ikke direkte knyttet til en bestemt utviklingsmodell, men kommer best til sin rett når vi utvikler iterativt og inkrementelt. ObjektOrientertAnalyse (OOA) En analysemetode : Gir en beskrivelse av hvordan man legger opp arbeidet i analysefasen Betrakter Problemområdet fra et perspektiv der man ser både verdenen og programvaren (som skal speile verdenen) som en samling samhandlende objekter Resulterer i Artefakter (informasjonsbærende modeller og beskrivelser) som bakes inn i selve kravspesifikasjonsdokumentet Sentrale artefakter vi ser på innen OOA er : Use Case (diagram + tekstlig beskrivelse) System Sekvensdiagram Domenemodell / Konseptuelt klassediagram USE CASE Use Case er en svært utbredt scenariebasert teknikk innen systemutvikling som har sin styrke i at den egner seg godt i spesifisering av Funksjonelle krav. Et use case (brukstilfelle) er en tjeneste i form av en handlingssekvens som systemet skal utføre for omgivelsene. Denne initieres normalt av en hendelse ute i systemets omgivelser, og skal alltid gi et observerbart resultat for en bestemt aktør. Karakteristika : Et Use Case viser en tjeneste systemet skal yte En av aktøren initierer vanligvis et Use Case (pil notasjon) Et Use Case gir alltid en målbar verdi til brukeren Et Use Case skal være komplett

6 USE CASE (2) En teknikk innen Objektorientert Analyse som brukes for å illustrere det nye systemets forventede tjenestetilbud omgivelser (i forma av aktører) samspillet mellom disse Det er vanlig å samle alle Use Cases i et Use Case diagram for hele systemet. Det er derimot Use Case beskrivelsene som i særklasse er viktigst ved denne teknikken. Det er her de funksjonelle kravene til systemet spesifiseres. Use Case modellering Arbeidsgangen når man setter opp Use Case : A. Skisser et Use-Case diagram som viser helheten systemavgrensningen aktørene use casene relasjonene. B. Lage en High-level Use Case Beskrivelse for hvert Use Case i diagrammet C. Lag detaljerte (expanded) beskrivelser av de Use Case som vurderes til å ha størst risiko (teknologi, forretning og prosjekt). LIBSYS use cases Fig Sommerville

7 High-level Use-Case Beskrivelse Dette er en overordnet tekstlig beskrivelse av det enkelte Use Case. Benytte en mal for beskrivelsen for å få en god stuktur. Use Case (Navn) : Aktør : Mål : Beskrivelse : Expanded Use-Case Beskrivelse Use Case (Navn) : Aktør : Mål : Beskrivelse : Type : Pre betingelser : Post betingelser : Spesielle krav ( eks. operasjonelle krav) : Detaljert Hendelsesforløp ( Main Success Scenario ) : Alternative scenarier : Ulike Varianter Ulike Feilsituasjoner