Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Forelesning IMT2243 15. Februar 2011 Tema : Metoder for å kartlegge Funksjonelle Krav n Intro : Kravspesifisering i de ulike SU-modellen og kommentarer.

Liknende presentasjoner


Presentasjon om: "Forelesning IMT2243 15. Februar 2011 Tema : Metoder for å kartlegge Funksjonelle Krav n Intro : Kravspesifisering i de ulike SU-modellen og kommentarer."— Utskrift av presentasjonen:

1 Forelesning IMT Februar 2011 Tema : Metoder for å kartlegge Funksjonelle Krav n Intro : Kravspesifisering i de ulike SU-modellen og kommentarer til kravspesifiseringsprosessen og ønsket ”sluttprodukt” n Strukturert Analyse – sen 70-talls metode med mulig renesanse n Objektorientert Analyse – intro om metoden og gjennomgang av Use Case som teknikk for å spesifisere funksjonelle krav Pensum : Sommerville kap 4, 5.2 og artsaml. 6 (s )

2 Kravspesifiseringsprosessen

3 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 (slutten av 70-tallet) der fossefall-modellen hadde utstrakt anvendelse, og man oftest hadde rasjonalisering som hovedmål ved utvikling av nye IT-systemer. IT-systemene 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. Moderne programvarearkitekturer basert på tjenesteorientering bidrar nå til en renesanse for denne type modelleringsteknikker ved spesifisering av de funksjonelle krav.

4 Strukturert analyse Man forsøker å lage gode systemmodeller/beskrivelser : u Dataflytdiagrammer u DataDictionary u Datamodeller (semantiske ER-modeller) u Strukturert språk (Structured Definition Language) SA er en funksjonsorientert metode : - finne funksjonene i systemet - kartlegge informasjonsflyten rundt funksjonene

5 Eksempel på en SYSTEMMODELL :

6 DFD Prosess (funksjon) u Bearbeider/manipulerer input om til output u En prosessboble for hver funksjon i systemet u Navngis ut fra hva den ”gjør”

7 DFD Dataflyt (informasjonsflyt) u Viser hvordan data/informasjon flyter i systemet. u Vi fokuserer på logiske modeller og flyt av modeller. DFD anvendes også til å vise flyt av ”fysiske elementer”. u Modellen viser ikke rekkefølgen på flytene, bare retning u Navngis u Detaljspesifiseres i DataDictionary

8 DFD Datalager / register u Viser en samling av data som må ligge lagret i systemet u Viser ikke hvordan dataene skal lagres u Dataene ligger passive inntil de blir kalt opp u Unngå registre uten ”inn” og ”ut” flyt u Lengst mulig ned i DFD-strukturen

9 DFD Terminator / Ekstern enhet u Viser kilder til / mottaker av informasjonsflyt i vårt system u Kan være roller, interessenter, andre systemer etc.

10 Tips ved utarbeidelse av DFD 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 (benytt nivåinndeling med kontekstdiagram, DFD1 og DFD2 - få registre (vi driver IKKE databasedesign her) 4. Ikke forsøk å ”si alt” med modellen, vis det viktige - lesbart og forståelig

11 Objektorientering - Historikk Opprinnelsen (oppdaget ikke oppfunnet) : Nygaard/Dahl - SIMULA67 OO i programmering : 70 tallet FoU / Pilot 80 talletKommersiell 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

12 Hvorfor tenke objekt-orientert også i analysefasen ? Drivkraften var en målsettingen om forbedret kvalitet i programvaren u Produktet skal være korrekt, pålitelig, verifiserbart, robust osv... u Objektorientert tilnærming hadde suksess innen programmering og dels også innen Design u Sterkt ønske inne fagfeltet om å bli bedre på gjenbruk både internt og eksternt u Så store fordeler av å benytte samme perspektiv gjennom hele SU-prosessen Utgangspunktet for å ”tenke nytt” i tilnærmingen ved Spesifisering : u Ønske om et metodeverk som er bedre og mer fleksibelt til å håndtere de endringer i krav som ALLTID kommer underveis i et systemutviklingsprosjekt u Den bærende ideen innen Objektorientering er at man mener Objektene er den mest stabile del av problemområdet, mens Prosesseringen/Manipulerings- mekanismene i langt større grad er utsatt for stadige forandringer u Objektorientert Analyse er ikke direkte knyttet til en bestemt utviklingsmodell, men kommer best til sin rett når vi utvikler iterativt og inkrementelt.

13 ObjektOrientertAnalyse (OOA) En analysemetode : n Gir en beskrivelse av hvordan man legger opp arbeidet i analysefasen n Betrakter Problemområdet fra et perspektiv der man ser både verdenen og programvaren (som skal ”speile” verdenen) som en samling samhandlende objekter n Resulterer i Artefakter (informasjonsbærende modeller og beskrivelser) som bakes inn i selve kravspesifikasjonsdokumentet n Sentrale artefakter vi ser på innen OOA er : F Use Case (diagram + tekstlig beskrivelse) F System Sekvensdiagram F Domenemodell / Konseptuelt klassediagram (senere forelesn)

14 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 : n Et Use Case viser en tjeneste systemet skal yte n En av aktøren initierer vanligvis et Use Case (pil – notasjon) n Et Use Case gir alltid en målbar verdi til brukeren n Et Use Case skal være komplett

15 USE CASE (2) En teknikk innen Objektorientert Analyse som brukes for å illustrere det nye systemets F forventede ”tjenestetilbud” F omgivelser (i forma av aktører) F 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.

16 Use Case modellering Arbeidsgangen når man setter opp Use Case : A. Skisser et Use-Case diagram som viser helheten F systemavgrensningen F aktørene F use casene F 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).

17 LIBSYS use cases Fig.4.15 Sommerville

18 Use Case modellering Eksempler på UC fra artikkelsamlingen og fra tidligere studentprosjekter som ligger på emnets hjemmeside : Public University registration system Athletic Manager NorBud IHID ThrustFlow


Laste ned ppt "Forelesning IMT2243 15. Februar 2011 Tema : Metoder for å kartlegge Funksjonelle Krav n Intro : Kravspesifisering i de ulike SU-modellen og kommentarer."

Liknende presentasjoner


Annonser fra Google