Kap. 12 Analysemodellering (Analysis Modeling)

Kap. 12 Analysemodellering (Analysis Modeling) Strukturert analyse er en av de mest brukte brukte modelleringsmetoder i analysen. Den andre er objektorientert analyse. 12.1 Kort historikk Strukturert analyse er en måte å lage modeller på. Systemet/problemet deles hierarkisk opp i subsystemer. Utviklinga starta på 70-tallet, først Strukturert Design senere Strukturert Analyse. Samlet omtales de som SASD. Sentrale personer: DeMarco, Yourdon,. Systemutvikling Kap. 12 Analysemodellering 1 Systemutvikling Kap. 12 Analysemodellering 2 12.2 Elementene i analysemodellen 12.2 Elementene i analysemodellen Analysemodellen må oppfylle 3 hovedmål: 1. Beskrive hva kunden krever. 2. Lage et grunnlag for system konstruksjon 3. Definere et sett med krav som kan valideres når systemet er ferdig utviklet (testgrunnlag). Fig. 12.1 viser analysemodellen. Data Dictionary (termkatalog) beskriver alle dataobjekter. Entitetsrelasjonsdiagrammet (ERD) beskriver relasjonene mellom dataobjektene (brukes i datamodellering). Dataobjektbeskrivelsen inneholder beskrivelsene av alle dataobjektene og attributtene. Data object description Dataflyt diagram Data Dictionary Entitets- Relasjonsdiagram Tilstandsovergangsdiagram Control Specification (CSPEC) Systemutvikling Kap. 12 Analysemodellering 3 Systemutvikling Kap. 12 Analysemodellering 4 12.2 Elementene i analysemodellen Dataflytdiagrammer (DFD) har to hensikter: 1. Å vise hvordan data transformeres (overføres) når de går gjennom systemet. 2. Beskrive funksjonene (og subfunksjonene) som transformerer (overfører) dataflyten. Prosess-spesifikasjon (PSPEC) er en beskrivelse av alle prosessene i DFD. Tilstandsovergangsdiagrammet (State Transition Diagram (STD) viser hvordan systemet oppfører seg som følge av eksterne hendelser. Diagrammet viser tilstandene, og overgangen mellom dem. Kontrollspesifikasjonen (CSPEC) gir tilleggs om systemkontroll. 12.3 Datamodellering Vi bruker datamodellering til å definere dataobjektene i systemet, deres attributter, hvor de befinner seg, relasjonene mellom dem, og forholdet til prosessene. Til dette bruker vi entitets-relasjonsdiagram (ERD) som definerer alle dataobjektene. Mer om datamodellering i databasekurset!! Systemutvikling Kap. 12 Analysemodellering 5 Systemutvikling Kap. 12 Analysemodellering 6

12.4 Funksjonell modellering og sflyt Teknikker som brukes er: Dataflytdiagrammer (DFD) Data Dictionary (DD - termkatlog, datakatalog) Minispesifikasjoner 12.4.1 Dataflytdiagrammer - DFD Kan f.eks. bruke Word, PowerPoint eller andre tegneverktøy til å tegne DFD: Input Input Output Datamaskin Output basert system Output Informasjonsflyt modell (kontekstdiagram) Systemutvikling Kap. 12 Analysemodellering 7 Systemutvikling Kap. 12 Analysemodellering 8 12.4.1 Dataflytdiagrammer - DFD -2 Dataflytdiagrammer - DFD -3 Dataflytdiagram viser flyten av info og transformasjonene som brukes når data flyter fra input til output. DFD kalles også dataflytgraf og boblediagram. DFD kan representere system og programvare på alle abstraksjonsnivå. DFD bruker hierarki (flere nivå) for å vise oppdeling. Nivå 0 kalles kontekstdiagram (context model, fundamental system model). Der er hele systemet en boble, og all Prosess/transformasjon input og output til systemet vises. Nivå 1 viser hovedfunksjonene i Dataflyt systemet. Datalager Inn data Inn data 1.0 Transform #1 Midlertidige data 2.0 Transform #2 Midlertidige data 3.0 Transform Midlertidige data #3 4.0 Transform #4 Data lager Ut data Ut data Systemutvikling Kap. 12 Analysemodellering 9 Systemutvikling Kap. 12 Analysemodellering 10 12.4.1 Dataflytdiagrammer - DFD -4 Dataflytdiagrammer - DFD -5 A B F DFD viser ikke prosesseringssekvens. (Den vises ikke før i konstruksjonen.) Fig. 12.11 viser videre oppdeling i subdiagrammer Nivå 0: System F kontekstdiagram Nivå 1: Funksjonene f1, f2,.,f7 Kontinuiteten i infoflyten må opprettholdes, d.v.s. at input og output på hvert nivå må være det samme. Dette kalles balansering, og er sentralt i å lage en konsistent modell, d.v.s. at ved detaljering av system F med input/output A og B, må A og B også være input til nivået under. A f 1 X Y V W f 2 f 3 f 41 f 42 X f 4 Z Y x 1 f 43 x 2 y 1 f 44 y 2 f 6 z 2 z 1 z f 3 5 Z f 45 f 7 B Systemutvikling Kap. 12 Analysemodellering 11 Systemutvikling Kap. 12 Analysemodellering 12

12.4.1 Dataflytdiagrammer - DFD -6 Til å beskrive innholdet i en dataflyt eller et lager brukes DD -Data Dictionary eller RD - Requirement Dictionary (Termkatalog) I tillegg til flyten brukes beskrivende tekst: Prosessbeskrivelse som beskriver hver prosess i detalj. En slik minispesifikasjon beskriver: Input Output Algoritme Restriksjoner og begrensninger på prosessen Ytelseskarakteristikker Konstruksjonsbegrensninger 12.4.2 Utvidelser for sanntidssystemer Sanntidssystemer (real-time systems) virker (arbeider) ut fra input (interrupt) fra omgivelsene i en tidsluke som bestemmes av omgivelsene: Prosesstyring Forbrukselektronikk osv.. Systemutvikling Kap. 12 Analysemodellering 13 Systemutvikling Kap. 12 Analysemodellering 14 12.4.3 Ward og Mellors utvidelser Informasjonsflyten er kontinuerlig Kontrollen som går gjennom systemet, og tilhørende kontrollprosessering vises. Mange forekomster av samme transformasjoner som ofte forekommer i multitasking situasjoner Systemtilstander og mekanismer som forårsaker transisjoner (overganger) mellom systemtilstander Eks. Tidskontinuerlig prosessering: Overvåking av gassturbinmotor: turbinhastighet forgassertemperatur trykk på forskjellige steder Fig. 12.12 viser utvidelser for tidskontinuerlig prosessring 12.4.3 Ward og Mellors utvidelser -2 Ytelseskritiske prosesser er ofte tidskontinuerlige. I en fysisk eller implementasjonsmodell, må det være en mekanisme for innsamling av tidskontinuerlige data. Dette kan også gjøres kvasikontinuerlig i en høyhastighets pollingløkke (round-robin). Modellen viser også AD/DA-konvertering. Fig. 12.13 viser kontrollflyt og kontrollprosessering med Ward og Mellor notasjon. Figuren viser øverste nivå av data og kontrollflyt for en produksjonscelle. Komponenter skal settes sammen av en robot.... Systemutvikling Kap. 12 Analysemodellering 15 Systemutvikling Kap. 12 Analysemodellering 16 12.4.4 Hatley og Pirbhai utvidelser Disse utvidelsene fokuserer på representasjon og spesifikasjon av kontrollorienterte forhold ved systemutviklingen. Kontrollflyten representeres i eget kontrollflytdiagram: CFD - Control Flow Diagram viser de samme prosesser som DFD, men viser altså kontrollflyt (ikke dataflyt). I diagrammet er det også en kontrollspesifikasjon CSPEC som viser: 1. Hvordan systemet (programmet) reagerer (oppfører seg) når en hendelse eller et kontrollsignal detekteres. 2. Hvilken prosess som startes som følge av hendelsen. 12.4.4 Hatley og Pirbhai utvidelser -2 Vi bruker også en prosesspesifikasjon PSPEC som beskriver den indre virkemåte av en prosess i et DFD. Fig. 12.14 Databetingelser inntreffer når data input til en prosess resulterer i en kontroll output. Figuren viser deler av en flytmodell av et automatisk overvåkings- og kontrollsystem for trykkventiler i et oljeraffineri. PSPEC er skrevet i psevdokode. Data og kontrollflyten er i adskilte diagrammer. Systemutvikling Kap. 12 Analysemodellering 17 Systemutvikling Kap. 12 Analysemodellering 18

12.4.4 Hatley og Pirbhai Utvidelser -3 Kontrollspesifikasjonen kan i tillegg vise PAT - prosess aktiverings-tabell (kap. 12.6.4) som viser hvilke prosesser som aktiveres av en gitt hendelse som flyter gjennom en vertikal strek. CSPEC kan også inneholde et tilstandsovergangsdiagram STD - State Transition Diagram. En systemtilstand (system state) er en observerbar oppførselsmåte Eksempel på tilstander er overvåking, alarm, trykk av (for trykkventiler). 12.5 Modellering av oppførsel Modellering av (virkemåte) er sentralt i alle kravanalyse metoder. Dette vises bare i utvidelsene av strukturert analyse. Tilstandsovergangsdiagram (STD) viser virkemåte ved å vise tilstander, overganger og hendelsene som fører til overgangene. STD viser også aksjonene som utføres. STD brukes bl.a. til å dokumentere kommunikasjonsprotokoller. Fig. 12.15 viser eksempel på CFD for en kopieringsmaskin. Fig. 12.16 viser et tilstandsovergangsdiagram (STD) for fotokopiering. Sirkler kan også brukes i STD for å vise prosessene. Systemutvikling Kap. 12 Analysemodellering 19 Systemutvikling Kap. 12 Analysemodellering 20 State Transition Diagram Notation state 12.6 Bruk av Strukturert analyse The mechanics of Structured Analysis I dette kapitlet vises trinnene i utvikling av en strukturert analysemodell, og bruk av Hatley og Pirbhai utvidelser. event causing transition action that occurs new state Systemutvikling Kap. 12 Analysemodellering 21 Systemutvikling Kap. 12 Analysemodellering 22 12.6.1 Utvikling av et E-R diagram E-R diagrammet brukes til å spesifisere dataobjektene som er input til og output fra systemet, attributter som definerer objektenes egenskaper og relasjonene mellom dem. Følgende iterative fremgangsmåte kan brukes til å lage ERD: 1. Kunden lager en liste over ting som inngår i systemet, er input eller output, eller er i dets omgivelser. 2. Utvikler og kunde går gjennom lista av objekter, og vurderer om objektet har forbindelser (relasjoner) med andre (objekter). NB: ikke navn på forbindelsene! 3. Der det eksisterer en forbindelse, dannes et eller flere objekt-relasjonspar. 4. For hvert objekt-relasjonspar bestemmes kardinalitet og modalitet (koplingsdeltagelse). 12.6.1 Utvikling av et E-R diagram -2 5. Steg 2 til 4 gjentas til alle objekt-relasjonspar er definert. Utelatelser oppdages, nye objekter og relasjoner legges til. 6. Attributtene til hver entitet defineres. 7. Det utarbeides et E-R diagram som gjennomgås. 8. Steg 1. til 7. gjentas til datamodelleringen er komplett. Eks. s. 313-315: Safe Home. Fig. 12.17 viser forbindelser. Fig. 12.18 viser relasjoner, kardinalitet og modalitet (koplingsdeltagelse). (Mer om dette i Databasekurset!!) Systemutvikling Kap. 12 Analysemodellering 23 Systemutvikling Kap. 12 Analysemodellering 24

12.6.2 Utvikling av en dataflyt modell DFD er et verktøy for å lage modeller av s- og funksjonsdomenene samtidig. Vi lager en funksjonell dekomponering av systemet. Retningslinjer for å lage en dataflytmodell: 1. Nivå 0 er kontekstdiagrammet der hele systemet er en prosess. 2. Primær input og output må vises tydelig. 3. Dekomponering (refinement) starter med å isolere hovedprosessene, dataene (items) og lagre som skal vises på neste nivå. 4. Alle piler og bobler må merkes med meningsfulle navn. 5. Kontinuitet i sflyt må bevares fra nivå til nivå. 12.6.2 Utvikling av en dataflyt modell -2 6. En prosess av gangen dekomponeres. (Prosess 1 dekomponeres i 1.1, 1.2,.. og 1.1 dekomponeres i 1.1.1, 1.1.2 osv..) Gode råd: Ikke lag for kompliserte DFD. Ikke vis for mange detaljer tidlig i prosessen. Ikke vis prosedyremessige forhold i stedet for info-flyt. Eks. DFD og Prosessbeskrivelse for Safe Home overvåkingssystem. Fig. 12.19 viser kontekstdiagram (nivå 0) Fig. 12.20 viser nivå 1. Kontinuiteten i info-flyten er bevart fra nivå 0. Fig. 12.21 viser videre dekomponering. Dekomponeringen fortsetter til hver prosess (boble) utfører en enkelt funksjon. (jfr. cohesion ) Systemutvikling Kap. 12 Analysemodellering 25 Systemutvikling Kap. 12 Analysemodellering 26 12.6.3 Utvikling av en kontrollflyt modell I de fleste tilfeller er det nok å lage en DF-modell. I sanntids-system (event-styrte anvendelser) som produserer kontroll- flyt med krav til tid og ytelse, kreves det modellering av kontrollflyt i tillegg til dataflytmodellen. For å lage en kontrollmodell tar en utgangspunkt i en dataflyt-modell som strippes for alle dataflytpiler (vises som stiplede piler) Hendelser og kontroll items (felt/data stiplet) legges til diagrammet, og et vindu settes inn i kontrollspesifikasjonen. 12.6.3 Utvikling av en kontrollflyt modell -2 Fig 12.22 viser nivå 1 av CFD for safehome Når en hendelse flyter inn i CSPEC streken fra utsiden (omgivelsene), fører det til at CSPECen aktiverer en eller flere av prosessene som vises i CFD. Når et kontroll-item flyter fra en prosess og flyter inn i CSPEC vinduet, fører det til kontroll og aktivering av en annen prosess eller en utenforliggende. Systemutvikling Kap. 12 Analysemodellering 27 Systemutvikling Kap. 12 Analysemodellering 28 12.6.4 Kontrollspesifikasjonen CSPEC CSPEC representerer virkemåten til systemet på 2 måter: 1. STD - tilstandsovergangsdiagram som viser sekvensiell spesifikasjon av virkemåten 2. PAT - Program Activation Table (programaktiveringstabell) som gir en kombinatorisk spesifikasjon av virkemåte. Fig. 12.23 viser et STD for safehome. Merkede piler indikerer hvordan systemet reagerer på hendelser og går mellom de 4 tilstander som er definert på dette nivået. Fig. 12.24 viser PAT som viser hvilke prosesser som aktiveres av de forskjellige hendelser. 12.6.5 Prosesspesifikasjon - PSPEC Minispesifikasjon PSPEC brukes til å beskrive alle prosesser som forekommer på det siste nivå av detaljeringen. PSPEC kan skrives som: tekst PDL - Program Design Language Matematiske ligninger Tabeller Diagrammer Flytkart (Chart) Psevdokode Minispec er første trinn i å lage en kravspesifikasjon, og som en guide for konstruksjon av programkomponenter som implementerer prosessen. Systemutvikling Kap. 12 Analysemodellering 29 Systemutvikling Kap. 12 Analysemodellering 30

Process Specification (PSPEC) A Design Note bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts PSPEC one or more components" in the software design Systemutvikling Kap. 12 Analysemodellering 31 Systemutvikling Kap. 12 Analysemodellering 32 12.7 Termkatalog Data Dictionary (DD) Termkatalog (DD) eller krav (data) ordbok kan skrives på mange former. De fleste inneholder: Navn - primærnavn på data/kontroll element (item), datalager, eller ekstern Alias - Andre navn som brukes om det første Hvor/hvordan brukes det? - liste av prosesser som bruker data eller kontrollfelter, og hvordan det brukes (input/output til prosesser, lager, eksterne er). Innholdsfortegnelse - Tilleggs - annen som en database (i CASE-verktrøy) kan inneholde slik at det er lett å finne hvor de forskjellige termer er brukt. 12.7 Termkatalog (Data Dictionary) -2 Sammensatte data kan forekomme på 3 måter : 1. Sekvens av data: A = B + C 2. Valg fra en mengde: A= [B C D] 3. Repeterende grupper: A= {B} n Systemutvikling Kap. 12 Analysemodellering 33 Systemutvikling Kap. 12 Analysemodellering 34 12.8 Oversikt over andre klassiske analysemetoder. 12.8 Oversikt over andre klassiske analysemetoder -2 Metodene følger analyseprinsippene (fra kap. 11), men de har forskjellig notasjon (symbolbruk) og regler (fremgangsmåter). Datastrukturert systemutvikling (DSSD) (Warnier-Orrmetode/diagram) er basert på metoder for analyse av sdomenet. Det lages en hierarkisk modell av en, som grupperes i sekvens, seleksjon (utvalg) og repetisjon. Programstrukturen kan i stor grad følge sstrukturen. Jackson Systemutvikling (Jackson Structured Developement - JSD) er også utviklet ut fra analyse av s-domenet, og dets relasjoner til program og system-konstruksjon. Strukturert Analyse og Design Teknikk er en dokumentasjonsteknikk som er blitt mye brukt i systemdefinisjon, prosessrepresentasjon, kravspesifikasjon og system- /program-konstruksjon. Systemutvikling Kap. 12 Analysemodellering 35 Systemutvikling Kap. 12 Analysemodellering 36