Forelesning IMT Februar 2011

Presentasjon om: "Forelesning IMT Februar 2011"— Utskrift av presentasjonen:

1 Forelesning IMT2243 15. Februar 2011
4/3/2017 Forelesning IMT Februar 2011 Tema : Metoder for å kartlegge Funksjonelle Krav Intro : Kravspesifisering i de ulike SU-modellen og kommentarer til kravspesifiseringsprosessen og ønsket ”sluttprodukt” Strukturert Analyse – sen 70-talls metode med mulig renesanse 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 : Dataflytdiagrammer DataDictionary Datamodeller (semantiske ER-modeller) 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) Bearbeider/manipulerer input om til output
En prosessboble for hver funksjon i systemet Navngis ut fra hva den ”gjør”

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

8 DFD 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 DFD-strukturen

9 DFD Terminator / Ekstern enhet
Viser kilder til / mottaker av informasjonsflyt i vårt system 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
4/3/2017 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 : Programmering Design 95-> Analyse

12 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/Manipulerings-mekanismene 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.

13 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 (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 : 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

15 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.

16 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).

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