SIF8035. Strukturert analyse

Transkript

1 Innhold SIF8035 Vår 2001 Prosessmodellering Strukturert analyse og konstruksjon Strukturert analyse Prosessperspektivet, Funksjonelle krav DataFlytDiagrammer Formål, syntaks Et større modelleringseksempel Strukturert design Med utgangspunkt i DFD Detaljering, Arkitektur, Konstruksjon Strukturert analyse - IS prosesser samler, lagrer, transformerer og distribuerer Informasjonsprodukter IS skal støtte forretningsprosessenes informasjonsbehov, gjennom effektiv bruk av programvare og kommunikasjonsteknologi Populært fordi Det viktigste perspektivet IS er knyttet til prosesser IS utvikling ofte en del av prosessforbedring (BPR) Lettfattelig Enkel notasjon Sentrert rundt det som skjer; Oppgaver/ Funksjon Det folk er opptatt av Om prosesser - Et sett av en eller flere lenkede prosedyrer eller aktiviteter, som tilsammen oppfyller et forretningsmål eller politisk mål, [foregår] normalt innefor en organisatorisk struktur der funksjoner og roller er definert. [Workflow Management Coalision, 1996] Produksjonsprosesser Knyttet til daglig virksomhet, gjennomføres ofte. Gir konkurransefortrinn, krav til innovasjon. Administrative prosesser Ofte underlagt regelverk Ønske om enklest mulig utførelse, ikke nødvendigvis best Samarbeidsprosesser Prosjektsetting, Komitearbeid, Likevel aktivitetsplan, tidsfrister, avhengigheter, Ad Hoc Utføres on the fly... Notasjon: DFD - DataFlytDiagrammer Agent ( Ekstern entitet) Dialekter: Gane & Sarson P Nr. Prosess Datalager DeMarco Flyt Data Materiale Prosess kjede Funksjon hendelse Funksjon Aktør ARIS - EventProcessChain 1

2 1 DFD - 3 hovednivåer opp nivå : Systemets interaksjon med omgivelsene opp-nivå DFD eksempel: WINC Inc SYSEM Videre dekomponering av hver oppgave 3 P3 2 Overordnet (Nivå 0 ) : Systemets hovedoppgaver P2 P4 P3 SYSEM Kunde Leveranse Regning Betaling Widget Inc. Kjøpsordre Leveranse Regning Betaling Leverandør P3.1 P3.2 P3.3 WINC Inc på lysark Prosess-analysen + DFD Evaluering Lettfattelig notasjon Dekker sentralt perspektiv Gir modeller på høyt nivå, enkel basis for videre dekomponering Skiller ikke mellom ulike typer flyt Dataflyt, Kontroll-flyt, Flyt av ting Hva med dekomponering av flyt? Viser ikke tidsperspektivet spesielt godt Sekvens, Start/Stopp av prosesser Klønete ved detaljert dekomponering Vanskelig å vite når man skal stoppe Vanskelig å unngå overlapp mellom oppgaver/dekomponering Overgang til design Sier ikke noe om regler for utføringen av en oppgave Har ingen eksplisitt kopling til datamodellering/db Design Dekker ikke GUI design I.e. for få detaljer, må utfylles med kopling til andre perspektiver Regelmodellering Forretningsregler definerer korrekt utførelse av en prosess/funksjon Ofte løst formulert, må spesifiseres helt formelt ned til algoritme-nivå Samtidig må de ofte dobbeltsjekkes med brukerne Spesifiseres vha. Pseudokode/strukturert språk Beslutningstrær Beslutningstabeller Logikk Regel-modellering, Eksempel Leverandører får 35% avslag. For direkte kunder, gis 5% rabatt for ordrer større enn Kr. 2000,- 10% på ordrer større enn Kr ,-, eller dersom ordren er på mer enn 50 enheter av bare et vareslag, gis 20% på ordrer større enn Kr ,-. En tilleggsrabatt på 10% gis på alle ordrer større enn100 enheter av et vareslag. ingen rabatt nei Beslutningstre: > kr 2.000,- nei nei 5 % rabatt ja > kr ,- Kun 1 vareslag? ja 10 % rabatt ja nei? direkte kunde > 50 enheter & verdi > ? ja 20 % rabatt nei Kundetype? > 100 enheter? ja 30 % rabatt leverandør > 100 enheter av 1 vareslag? ja nei 35 % rabatt 45 % rabatt 2

3 Regel-modellering, Eksempel (2) Beslutningstabell Regel-modellering, Eksempel (3) Lysark Regler R1 R2 R3 R4 R5 R6 Ja Ja Ja Ja N - Direkte kunde Leverandør - - J - Verdi > 2.000,- N J J N - - Verdi > ,- - N J enheter av samme slag N - - J - Verdi > , J - > 100 enheter av samme???? J vareslag Ingen rabatt X 5 % Rabatt X 10 % Rabatt X 20 % Rabatt X 35 % Rabatt X Øk rabatt med 10 % X Strukturert Design HVEM skal utføre de forskjellige prosessene? Automatiseringsgrense Hvilke prosesser skal vi konstruere datasystem for? Arkitektur Hvilke teknologiske komponenter trengs? Kopling / protokoller for utveksling mellom dem? Regler Hvilke regler gjelder for korrekt utførelse av en prosess? Database-design Hvilke oppslag er noedvendig? Krav til oppslag? Programvaredesign Database-konstruksjon Hvilke data-strukturer må systemet lagre? Hvem legger inn data? Hvor kommer de fra? Hvem bestemmer hva som er gyldige data? En eller flere databaser? Hvilke oppslag skal kunne gjøres? Av hvem? Hvilke data er man interessert i? Hva brukes som nøkkel? Hva er nødvendige adgangsveier? Frekvens, responskrav? Konflikter? lokal modell lokal modell Datamodell Logisk Struktur DB DB Design lokal modell Database-konstruksjon WINC Inc.: Lysark Bestem automatiseringsgrense Bestemme arkitektur Hvilke prosesser skal ha I støtte? Gruppering? Moduler, koplinger? Plassering? salgssystem Hvem har ansvaret? Hvor skal dette kjøres? Informasjonsutveksling mellom komponenter Bestem Protokoller Utnytte komponenter til andre ting eknologiske krav Samspill med eksisterende teknologi Krav til endring prosess arkitektur IP SQL Leveranseplan Faktura Administrasjon 3

4 Arkitektur WINC Inc på lysark Strukturert programvaredesign Programvarearkitektur Oppbrytning i delprogram (job/step/unit) Struktur, betingelser, kontroll Kall, Sekvens, Avhengigheter Ikke nødvendigvis lik DFD Enter & dekomponering Edit New ransformasjonsanalyse ransaksjonsanalyse OO Design, Distribuerte objekter Read order Edit From Kbd. Order Objekter, Clusters, Capsules, Nodes Mapping til underliggende infrastruktur for kommunikasjon (Java RMI, Corba, OLE/ACIVE X) Enter & Verify order Valid order Read Cust. Data Verify Cust. Credit Read Acc. Receivable Reject order Programsystem konstruksjon Eksempel: WINC Inc. Lysark Oppsummering SA&SD Strukturert analyse Knyttet til prosess, funksjoner DFD modellering Enkel grafisk notasjon, gir grei oversikt over oppgaver og funksjonelle krav Godt utgangspunkt for detaljering mot design Strukturert design Automatisering sgrense Arkitektur Databasedesign Regelmodellering GUI Programvaredesign Strukturert analyse med DFD i et videre perspektiv. Overgang mot Design Videre detaljering av modeller Kopling av DFD til andre perspektiv Utnytte spesifikasjonen i design Konstruktive modeller Detaljert modellering med formelt underlag CASE verktøy eknikker og metoder for bedret utnyttelse av modellen Bruker PPP - Process Phenomen Program som eksempel Programsystem Konstruksjon re typer konstruksjons mål: Organisasjons-mål, f.eks. økt overskudd, bedre service Informasjonssystem-mål, for eksempel mer up-to-date info, korrekt info Datasystem-mål, f.eks. responstid < 2 sek for 90% av forespørsler, koster mindre enn NOK Viktig med målkonsistens, dvs. at datasystem-målene understøtter informasjonssystem-målene som understøtter organisasjons-målene 4

5 Overordnet mål: å levere brukerfunksjonene Programsystemer vurderes m.h.t. Ytelse - throughput (#transaksjoner/sek) - run-time (gjennomløpstid) - respons-tid Pålitelighet - begrenset lese/skrive adgang - kontrollsiffer, logfiler, invarianter Modifiserbarhet - feilreparasjon, utvidelser, forandring er Ofte konflikt mellom ytelse, pålitelighet, modifiserbarhet f.eks. 1)høy pålitelighet hvis streng kontroll, som krever mange ressurser, som gir lav ytelse. 2) høy ytelse gir ofte lav modifiserbarhet Vanskelig å operasjonalisere vurderingskriteriene, f.eks. hvordan måle at et alternativ er 20% lettere å modifisere enn et annet konstruksjonsalternativ Datasystemer består av database programsystem kommunikasjonssystem systemomgivelse brukergrensesnitt som alle må konstrueres.. Gjensidig avhengighet mellom del-konstruksjonene. Relativ viktighet mellom del-konstruksjonene avhenger av systemtypen. Forskjellige systemtyper krever forskjellige konstruksjonsmetoder, f.eks.. Jackson structured programming for hierarkisk fil-prosessering. Strukturert konstruksjon for transaksjonsorienterte systemer Strukturert konstruksjon re nivåer: Kode-nivå modul -nivå pakke -nivå Strukturert konstruksjon Overordnet prinsipp: Oppnå uavhengighet mellom de forskjellige programkomponentene information hiding - en modul s data og prosedyrer gjøres utilgjengelige for andre moduler (Parnas) Abstraksjons-prinsippet- klassifikasjon av systemers egenskaper i økende detalj-nivå funksjonsorienterte komponenter- en funksjon pr. program plug-in komponenter Strukturert konstruksjon Kode-nivå begreper: Abstraksjon: -nivåer av virtuelle maskiner - abstrakte datatyper - kompleksitet beskrives på lave abstraksjons-nivåer Kontroll-flyt begreper - sekvens - seleksjon - repetisjon Lesbarhet Strukturert konstruksjon Sub-program begreper: Struktur: statiske forbindelser mellom program- komponenter kopling: kommunikasjon mellom programkomponenter liming ( cohesion ): assosiasjon mellom setninger i et subprogram 5

6 Strukturert konstruksjon Liming ( cohesion ): tilfeldig liming logisk liming temporal liming prosedural liming kommunikasjons liming sekvensiell liming funksjonell liming lav liming høy liming Høyest mulig liming tilstrebes Strukturert konstruksjon Kopling- et mål for hvordan programmer kommuniserer data kopling stamp kopling kontroll-kopling ekstern kopling common kopling innholds-kopling lav kopling høy kopling Lav kopling tilstrebes DFD - utgangspunkt for design BEGIN if <element> then <block> Endif END Detaljering av modeller Modellen danner basis for: Kommunikasjon og forståelse Evaluering av systemet underveis Implementasjon Dokumentasjon Ønsker: Glidende overgang til design Mao. en kontinuerlig detaljering av modeller i flere perspektiv Dette krever: Solide verktøy som kan håndtere høy grad av detaljer eknikker for kompleksitetshåndtering og modell-utnyttelse Modell IS Database Programstruktur GUI Meta-Modell CASE tools generelt Repository: Lagring av modeller Flerbruker-funksjonalitet Flere integrerte modelleringsspråk Meta-Modell: Spesifiserer modelleringsspråkene Definerer sammenhenger mellom modeller og elementer i forskjellige perspektiv Samarbeidsstøtte: Kommunikasjon Samhandling Koordinering Verktøy og teknikker for bedret utnyttelse av modellene: Syntakssjekking Konsistenstesting Simulering Inspeksjon Forklaringsgenerering Eksekvering Protoyping Kodegenerering PPP - Phenomenon, Process & Program Forskningsprosjekt Prototype implementert i prolog 1994 Målsetninger: Å formalisere eksisterende modelleringsspråk Høy integrasjon mellom de ulike språkene Definere avanserte teknikker som muliggjør testing og videre utnyttelse av spesifikasjonen 3 modelleringsspråk PRM - Prosess-modellering (basert på DFD) PHM - Ph enomen modellering, Idag : Konseptmodellering/referentmodell PLD - Prosessbeskrivelse vha. visuelt pseudokodespråk Spesifiserte egenskaper Konsistenstesting Kodegenerering Forklaringsgenerering Forenkling 6

7 DFD: Manglende Detaljering idsperspektiv Start/Stopp Sekvens Hendelser Formalisering av inn/utgang Grunnlag for spesifisering av regler Markering av ressurser Personer prosjektleder Datakraft Verktøy/hjelpemidler A2.1 Lag styringsrapport Prosjektstyrings Siste verktøy statusrapport PrM - Prosess Modellering Porter beskriver sammenheng mellom inn- og utflyter AND OR XOR Porter kan gjøres beting ede eller repeterende conditional repeating kombinasjon idsperspektiv angis vha. riggere/erminatorer, Klokker og timere Delay PRM - Eksempel PLD - Process Life Description Visuell notasjon for pseudokode Alle PLD sekvenser er knyttet til 1 prosess PLD beskriver både intern algoritme og kommunikasjon med andre prosesser PLD - Eksempel SAR blokk motta motta iterasjon blokk blokk seleksjon alternativ alternativ blokk blokk send send 7

8 Konstruktivitet Å kunne utlede egenskapene til et system ved å summere alle dets delsystemer eller : Konstruktivitet i DFD Å kunne gradvis berike en modell med detaljer ned til den utgjør en eksekverbar spesifikasjon Kundedata.1 elefon k.3 Krever at elementer i modellene har en formelt definert semantikk F.eks. at sammenhengen mellom elementer på ulike nivåer er fast definert Varedata.2 ferdig utfylt Fyll ut ordrer.4 Sjekk ordre godkjent ugyldig Kundedata Varedata Kundedata Varedata Konstruktivitet i PrM.1 elefon k.2 ferdig utfylt godkjent ugyldig.3 Fyll ut ordrer.4 Sjekk ordre I/O Matrise, Logisk uttrykk.1 I1 O1 X.2 I1 O1 X O2 X I1 I2 I3 O1 X X O1 X O2 X X O2 X.3 I1 I2 O1 X X O2 X X Statisk konsistenstest i PrM.4 I1 I2 I3 O1 X X O1 X X O2 X X O2 X X O1 = (:I1 :I2) (:I3) O1 =.4:O1 = (.4:I1.4:I3) (.4:I2.4:I3) (.3:O1 (.3:O2.2:O1)) (.2:O2 (.3:O2.2:O1)) ((.3:I1.3:I2) ((.3:I1.3:I2) I3)) (I3 ((.3:I1.3:I2) I3)) ((.1:O1 I2) (.1:O1 I2)) (((.1:O1 I2) (.1:O1 I2)) I3 ) (I3 (((.1:O1 I2) (.1:O1 I2) ) I3)) (((I1 I2) (I1 I2)) ((I1 I2) (I1 I2)) I3 ) (I3 (((I1 I2) (I1 I2)) I3)) (I1 I2) I3 8

9 ilstandsdiagram Dynamisk konsistenstest i PrM eknikk-eksempler Forenkling Forklaring Simulering Hvorfor var ordren Ugyldig? Flyten Ug yldig ordre ble sendt av fordi Kundedata ikke var gyldige Kodegenering A priori regler : Aldri lov Syntakssjekking Forklaring av syntaks Forklaring av modellen inn-ordrer ut-ordrer A posteriori regler : Ikke lov i en ferdig modell Navn? Sjekkliste: Navn Flyter riggere/erminering Porter Flytinnhold Prosessalgoritmer Datalagerinnhold navn Forklaring av feil Dette er en prosess. En prosess er et dynamisk konsept som leser et sett med innflyter og genererer et sett med ut-flyter. Alle prosesser har en ID og et navn. Diagrammet er ulovlig siden ikke produserer noen ut-flyt. Alle prosesser må generere minst 1 ut-flyt inn-ordrer ut-ordrer En data-flyt kan ikke gå direkte mellom 2 datalagre Forklaring av modellen (2) Forklaring av modellen (3) Hvorfor ble ordren avslått? ordre Ugyldig ordre ble sendt av prosess fordi kundedata var ugyldig Hvorfor var kundedata ugyldig? ordre Kundedata var ugyldig fordi kunden har mindre enn 5000,- på konto. Dette bryter med regel R3: r fra direkte kunder godkjennes bare dersom vedkommende har mer enn 5000,- på konto 9

10 Forenkling PrM Modell Skjule porter, Kollapse flyter og omorganisere layout PrM forenkling Lysark Boka Fig PrM-eksempel: forenkling må til Boka Fig Kodegenerering Fra PrM & PhM til ADA kode-skall.1.2 elefonisk Ferdig PhM PhM.3 Fyll ut PhM.4 Sjekk PhM ask 1 ask 2 ask 3 ask 4 Utnytte ADA s mekanismer for intertask kommunikasjon og synkronisering Kodegenerering (2) Databasegenerering Fra Datamodell til databasedefinisjon Create table Kunde (KundeID int not null unique; Navn char(150) not null; PostAdr char(200) not null; KontoNr int not null references Konto.KontoNr;) Create table KredittKonto (KontoNr int not null unique; Kreditt int not null KundeNr int not null references Kunde.KundeNr;) Fra flyter til/fra datalagre til SQL statements Select Kunde.Navn Kunde.Postadr Konto.Kreditt From Kunde, Konto Where Kunde.Nr=<ID> AND Insert, Dato Into Bestilling, 10

11 Oppsummering DFD - sentralt perspektiv Binder sammen flere andre perspektiver Ren notasjon, kan detaljeres Godt utgangspunkt for design Konstruktivitet - kontinuerlig detaljering av spesifikasjon Avhengig av formelt grunnlag Krever verktøy og metoder for detaljhåndtering CASE verktøy for analyse Inneholder flere modelleringsspråk Definerte sammenhenger mellom språkene Inneholder avanserte teknikker for modell-testing og bruk 11