Kirsten Ribu - Høgskolen i Oslo 05.05.04

Prosessmodellering Strukturert analyse og design et overblikk Gurholt & Hasle, kapittel 10 Kirsten Ribu - Høgskolen i Oslo 05.05.04 1

Prosessrapporten Prosessrapporten skal beskrive valg av systemutviklings-prosess, selve systemutviklingsprosessen, og detaljer om gjennomføringen av prosjektet: Arbeidsfordelingen i prosjektgruppa, Hvordan samarbeidet fungerte Erfaringer - både gode og dårlige Eventuelle problemer og løsninger på problemene. 2

Evaluering Rapporten skal beskrive evalueringen av eget system, og hvilke endringer/forbedring/andre tiltak som ble truffet på grunnlag av evalueringen (også evalueringen gjort av den andre gruppa): 1. Systemdesignet skal evalueres i henhold til prinsipper om god objektorientert design: GRASP - mønstre, kobling, kohesjon og modularitet (eventuelt annet design, for eksempel DFD) 2. Brukergrensesnittet skal evalueres i henhold til prinsipper for god interaksjonsdesign, estetikk og brukervennlighet. Rapporten skal referere til fagstoffet i kurset: lærebøker, fagstoff som er presenter i form av notater og forelesningsnotater. Rapporten skal også inneholde vurderingen av den andre gruppas prosjekt, og erfaringer fra denne inspeksjonen. Endelig leveransedato: fredag 28. mai (uke 22). 3

Først - mer om prosessrapporten Bruk veiledningen til Ann-Mari: Innhold: Tittel, sammendrag, forord, innholdsfortegnelse, innledning (det faglige problemet). Planlegging og metode (bruk pensum!), om utviklingsprosessen: faser, problemer, utfordringer. Beskriv styrker og kvaliteter i arbeidet. (Noe vil stå i produktrapporten, men hovedtyngden kommer i prosessrapporten) Resultatet av andres evaluering og hvordan den er brukt Kravspesifikasjonen: Drøftes spesielt. Endringer, hvordan er den brukt (husk at use case beskrivelsene er selve kravspeken i detaljer), samsvar mellom produktet og kravspek. Avslutning: oppsummering, konklusjoner, hva er gjort og lært, vurdering av eget arbeid. 4

Perspektiver på modellering Datamodellering var lenge den mest brukte måten å modellere datasystemer på. Strukturert analyse og design (SA/SD) dekker analyse og design fasen På slutten av 80-tallet dukket de første variantene av objektorienterte modelleringsmetoder fram Vi har i kurset brukt objektorientert analyse og design (OOA/OOD) med UML Dataflytdiagrammer modellerer dataflyt, filer, prosesser og dataelementer 5

SA/SD vs. OO Datamodellering kan benyttes for å spesifisere og designe systemer som har mye data og datatransaksjoner ( datatunge systemer). Strukturert Analyse (SA) og Strukturert Design (SD) er metoder som sammen dekker spesifikasjons- og designfasene. Mye brukt på 70- og 80-tallet. Fortsatt vanlig i USA i dag SA består av dataflytdiagrammer (DFD), datakatalog, prosessbeskrivelser og datalagerbeskrivelser. SA-modellen benyttes som utgangspunkt for å utarbeide en SD-modell (design). Modulene i SD (og prosessbeskrivelsene) danner utgangspunkt for programmering Objektorientert utvikling kombinerer funksjonsperspektivet og dataperspektivet. Vi har i kurset brukt objektorientert analyse og design med UML, som er den vanligste metoden i Skandinavia i dag. 6

SA/SD Strukturert analyse og design er basert på oppdeling etter funksjon. Den minste byggeklossen er funksjonen (prosedyren) Programvaresystemene er hierarkisk strukturert Top-down design: begynner på toppen og deler opp etter hvert Modulene består av funksjoner som opererer på datastrukturer. Funksjoner er ikke spesielt godt egnet for gjenbruk, med unntak av biblioteker (matematikk, grafikk) for spesielle formål. 7

Et dataflytdiagram 8

Prosessmodellering med DFD Det finnes to sett av diagramsymboler for DFD, hvert sett inneholder 4 symboler 9

Diagrammene - historikk Det sentrale verktøyet ved design av dataflyt er dataflytdiagrammet (DFD) Dets historie går tilbake til Paris i 1920, hvor en rasjonaliseringsekspert skulle beskrive dokumentflyten mellom de ulike arbeidsbord i et stort kontor. Den ene utgaven av dataflytdiagrammet er utviklet av Tom demarco. Den andre hovedvarianten av DFD er utviklet av Chris Gane og Trish Sarson. Det som skiller de to metodene er stort sett den grafiske notasjonen. Tankegangen og prinsippene er de samme. 10

Symbolene Prosess. Beskriver en behandling eller transformering av data Dataflyt. Beskriver data som flyter til eller fra en prosess. Datalager. Beskriver et sted hvor data lagres over lengre tid. For eks en fil, arkiv, databasetabell, etc. Ekstern entitet. Kilder eller mottaker av data som befinner seg utenfor det systemet som beskrives (aktører). 11

Prosesser og lagre Prosesser viser hva systemet kan gjøre. En prosess beskriver en systemfunksjon (analogi: use case). DeMarco bruker av og til ordet boble om en prosess. Derfor forekommer også begrepet boblediagram. Hver prosess identifiseres med et unikt navn og et nummer Datalager er oppbevaringsplass for data. Prosesser kan hente data fra datalager (lese) og legge data på lageret (skrive). Datalageret har et unikt navn. Datalager er passive (statiske) elementer i diagrammet. 12

Dataflyt Dataflyt beskriver de dataelementer som behandles i systemet. Pilretningen viser hvilken vei dataene flyter, (input, output) Pilene har et unikt og beskrivende navn. Dataflyt forekommer mellom prosesser mellom prosess og datalager mellom prosess og ekstern entitet. 13

Input og output Ordre Prosesser ordre Input-flyt Lag faktura Faktura Output-flyt 14

Ekstern entitet Ekstern entitet representerer kilde eller mottaker av data som ligger utenfor systemet. Den eksterne entiteten er derfor utenfor det vi ønsker å modellere. I en bedriftsmodell kan det være kunder eller leverandører Det kan også være andre avdelinger i en bedrift dersom disse ligger utenfor systemet 15

Eksempel: Nivå 1 Første nivå i DFD viser hovedprosessene i systemet. Hver prosess brytes ned i subprosesser som igjen brytes ned til man når en pseudokode. 16

MERK! Dataflyt-diagrammet viser ikke rekkefølge av det som skjer, heller ikke betingelser for at noe kan utføres. (Jfr use case modellen). Et DFD er en modell av dataflyten, og ingenting annet. Alt som vises på dataflytdiagrammet kan i prinsippet skje parallelt. En vanlig nybegynnerfeil når man skal tegne et DFD er å forveksle dataflyt med kontrollflyt. Et dataflytdiagram hvor hele systemet beskrives som én prosess (øverste nivå) kalles et kontekst-diagram. 17

Kontekstdiagram En oversikt over systemet som viser grenser, eksterne entiteter som samhandler med systemet, og hovedinformasjonen som flyter mellom de eksterne entitetene og systemet. Jfr. System-sekvensdiagram. 18

Prinsipper for prosessmodellering 19

Prosessmodellering (1) En prosess (funksjon) er arbeidet eller hendelsene som utføres på data på en slik måte at de endres, lagres eller distribueres. Når en prosess modelleres spiller det ingen rolle om prosessen utføres manuelt eller av en datamaskin En prosess manipulerer, lagrer og distribuerer data mellom et system og omgivelsene samt mellom komponenter innen et system Et datalager kan inneholde data om kunder, studenter eller leverandørfakturaer 20

Hva modelleres Intern informasjonsflyt i systemet Hva brukeren gjør, ikke hvordan eller tekniske detaljer (jfr use case) DFD er et hendig kommunikasjonsmiddel kan brukes til å kommunisere med kunden 21

Prosessmodellering (2) En dataflyt kan best forstås som data i bevegelse fra en plass i systemet til en annen: en dataflyt kan representere data om en kundes ordre eller lønnsslippen til en ansatt kan også representere resultatet av en forespørsel til en database, innholdet i en rapport eller data i et datafelt på et skjermbilde en dataflyt kan være sammensatt av mange individuelle datadeler som genereres på samme tid og flyttes samtidig til et felles bestemmelsessted 22

Prosessmodellering (3) Eksterne entiteter En datakilde (source) eller et databestemmelsessted (sink) er opprinnelsen og/eller bestemmelsesstedet for data kalles eksterne entiteter fordi de ligger utenfor systemet og definerer dermed grensene for systemet (aktører, grensesnitt) data kommer alltid inn fra en eller flere kilder systemet produserer informasjon til ett eller flere bestemmelsessteder 23

Diagrammer Kontekstdiagram: Høyeste nivå. Viser en grov oversikt over systemet og interaksjonen med omgivelsene. Nivå 0 diagram: viser hoved subsystemene og hvordan d kommuniserer med hverandre Nivå x diagram: (feks. Nivå 1) viser prosessene som utgjør hvert av hovedsubsystemene Nivå x.y diagram: (For eksempel 1.1, 1.2, 2.1 etc ) Viser detaljene i diagrammene over 24

Nivåer (1) 25

Nivåer (2) 26

Kontekstdiagram - notasjon 2 Kontekstdiagram for et ordresystem 27

Et dataflytdiagram nivå 0 Notasjon 2 Et dataflytdiagram som representerer systemets hovedprosesser, dataflyt, datalagre og eksterne entiteter på et overordnet nivå. 28

Nivå 0 eksempel Nivå-0-diagram for et ordresystem 29

Dekomponering (1) En prosess kan deles opp i flere delprosesser. Dette angis i dataflytdiagrammet ved nummereringsregler. Dersom prosess 3 deles i 2 delprosesser, vil disse få numrene 3.1 og 3.2. Hvis prosess 3.2 igjen deles opp i 4 delprosesser, vil disse nummereres som henholdsvis 3.2.1, 3.2.2, 3.2.3 og 3.2.4. Vi beveger oss mot stadig lavere detaljeringsnivå. På øverste nivå (nivå 0) har vi kontekstdiagrammet. På neste nivå vil prosessene nummereres fra 1 og oppover. Nivået under der vil ha 2 komponenter i prosessnummeret (1.1, 1.2,..) osv. 30

Dekomponering (2) Funksjonell dekomponering En iterativ prosess der beskrivelsen av et system brytes ned slik at hvert nivå blir mer detaljert enn det foregående Nivå-n-diagram Et dataflytdiagram som er resultatet av n dekomponeringer av en prosess i et nivå-0-diagram Viser ikke eksterne entiteter (datakilder/databestemmelsessteder) Hver prosess skal dekomponeres inntil de består av enkeltstående funksjoner Hvert nivå-n-diagram skal lages på atskilte sider 31

Dekomponering - eksempel Nivå-1-diagram som viser dekomponering av prosess 1.0 fra ordresystemet 32

Tommelfingerregler 1. Lag faktura Prosessene skal nummeres for å kunne identifisere dem. En prosess navngis med et enkeltord, et uttrykk eller en enkel setning Navnet skal beskrive hva prosessen gjør (jfr use case navn). Et godt navn vil ofte bestå av et verb-objekt uttrykk, feks. LAG FAKTURA 33

Flyten Kundeforespørsel Flyten, representert med en pil, brukes for å beskrive bevegelsen av informasjonspakker fra en del av systemet til en annen. Flyten representerer data i bevegelse, og navngis. Flyten viser retningen dataene beveger seg: inn eller ut av en prosess. 34

Eksempel ORDER DETAILS ORDER ORDER 1. ENTER ORDERS ORDERS 2. RESPOND TO INQUIRY INQUIRY ACKNOWLEDGMENT RESPONS E Flyten fra et lager representerer lese eller hente informasjon. Datalageret endres ikke når informasjonspakken flytter seg fra lageret langs flyten. Flyten til et lager er enten skriv til, oppdater eller slett. Datalageret endres 35 som et resultat av flyten inn I lageret.

Typisk DFD for et lite system ORDRE Fakturaer Kunder 36

Eksempel Lagerutsalg Nice Club Kravspek: Varene som selges blir registrert elektronisk i kassen. Kunden får kvittering for betalt beløp. Alle salg blir registrert i en salgsdatabase. Samtidig blir lagerdatabasen oppdatert. Når lagerbeholdningen for en bestemt vare underskrider en bestemt verdi, blir det automatisk bestilt nye varer fra leverandøren. Leverandøren sender en faktura med varen. Ved salg blir også MVA (merverdiavgift) automatisk beregnet. Én gang pr mnd blir den oppsamlede MVA betalt inn til fylkeskemneren. Kvittering for innbetaling blir arkivert. 37

Kontekstdiagram med eksterne aktører 38

Nivå 0 uten eksterne aktører NB! Ved dekomponering vises ikke de eksterne aktørene 39

Viktig: Konsistens Det må være konsistens mellom nivåene Data må ikke forsvinne eller komme til på veien Dataflytene må gjenfinnes i alle diagrammer 40

Resten av kurset: Neste gang: Lov, rett og avtaler, emne 3 G&H Etikk i cyberspace, emne 8 G&H Torsdagsøvingen: DFD-oppgaver Uke 21: Tirsdag: Veiledning Onsdag: Oppsummering kom gjerne med ønsker. Obligatorisk test gjennomføres i løpet av uka. Innlevering av prosjektoppgaven 28.mai. Ingen utsettelser! 41