Jarle Larsen 5.1.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Resymé: I denne leksjonen ser vi litt generelt på modellering og spesielt på funkasjonsmodellering. Innhold 1.1. INNLEDNING... 2 1.2. GENERELT OM MODELLER... 2 METODER... 3 1.3. STRUKTURERT ANALYSE SASD... 4 Dataflytdiagram... 6 1.3.1. Retningslinjer for å tegne dataflytdiagrammer... 7 1.3.2. Tegning av dataflytdiagram... 8 1.3.3. Datakatalog... 13 1.3.4. Prosessbeskrivelse... 14
1.1. Innledning Forståelse og bearbeiding av kompleksitet er kanskje den viktigste oppgaven til en systemutvikler. Det er skjelden at et informasjonssystem utvikles fra bunnen av. Vanligvis eksisterer det et system som brukeren ikke er fornøyd med og og det er ønskelig med et nytt og bedre system. Ofte eksisterer det en form for dokumentasjon av det eksisterende system som kan være til hjelp i startfasen med design av det nye systemet. En modell er en oversikt over utviklingsarbeidet. Den beskriver hvilket arbeid som skal gjøres, hvordan arbeidet skal inndeles i faser aktiviteter og arbeidstrinn. En metode er en detaljert beskrevet fremgangsmåte for å løse et bestemt problem. Et metode bør ideelt være så detaljert beskrevet at to personer som uavhengig av hverandre benytter metoden på samme problem ender opp med tilnærmet det samme resultat. Det finnes mange metoder, men vi skal i denne leksjonen se nærmere på Strukturert analyse og design SASD. SASD er en metode for analyse og design (utforming) av et informasjonssystem og er en av de mest kjent, eller kanskje til og med den mest kjente, systemeringsmetoden. 1.2. Generelt om modeller I alle faser av utviklingsprosessen brukes forskjellige typer modeller (ofte kalt spesifikasjoner) som uttrykkes ved hjelp av modelleringsspråk. Eksempler er kravsspesifikasjoner og konstruksjonsspesifikasjoner som er skrevet på norsk eller uttrykt ved hjelp av et formelt språk. Behov for å bruke modeller vil alltid være sentralt i utviklingsprosessen. Noen grunner til dette er: - Uhensiktsmessig å måtte observere virkeligheten for å studere / vurdere den - En modell gir ofte en bedre innsikt enn observasjon (abstraksjonsmuligheter) - En modell holder virkeligheten stille og muliggjør analyser - En modell kan endres på måter en ikke kan /våger å gjøre i virkeligheten - En modell gir et forenklet beskrivelse av en del av virkeligheten som er av interesse for problemløsningen og brukes derfor som: - Basis for kommunikasjon og forståelse mellom ulike aktører i utviklingsprosessen. Dette stiller store krav til modelleringsspråkets uttrykkskraft og brukervennlighet. - Basis for implementasjon av systemet. Dette stiller store krav til modelleringsspråkets uttrykkskraft og formelle egenskaper side 2 av 14
En modell skal best mulig reflektere de sentrale aspekter ved virkeligheten samt være lett å forandre når virkeligheten forandres (vedlikeholdbare spesifikasjoner). Viktige forutsetninger for vellykket modellering dvs. bruke modelleringsspråk til å lage en modell: - Tilstrekkelig tid har blitt brukt til problem forståelse, bestemme målsetning, etc. - Viktige interessenter er aktivt involvert (f.eks. eier og brukere). - Hensiktsmessig prosess for utvikling av spesifikasjonen samt uttrykt på en hensiktsmessig måte. - Krever samme referanseramme og representasjonsregler En skiller mellom tre hovedtyper av modeller: uformelle, formelle og hybride. Et eksempel på en uformell spesifikasjon er en kravsspesifikasjon uttrykt ved hjelp av norsk språk. Formelle spesifikasjoner er uttrykt ved hjelp av formelle språk f.eks. en kravsspesifikasjon uttrykt ved hjelp av DFD-diagram og ER-diagram. Det kan diskuteres i hvilken grad DFD-diagram og ER diagram er virkelig formelle språk, men vi nøyer oss med å slå fast at de er mer formelle enn naturlig språk siden dens syntaks og semantikk er formelt beskrevet. Eksempler på hybride spesifikasjoner er en kravsspesifikasjon der ulike deler er uttrykt ved hjelp av norsk og mer formelle språk. I utviklingsprosessen er det en tendens til å introdusere mer og mer formelle språk til lenger frem en kommer i prosessen. Typisk vil naturlige språk (f.eks. norsk) benyttes mye i tidlige faser. De er lette å bruke for å kommunisere mellom mennesker, men modellene er ofte tvetydige og inkonsistente. Når en kommer til analyse, design og implementasjonsfasene vil tekstlige beskrivelse erstattes av metode og programmeringsspråk. Metoder Det finnes mange metoder som fører til målet. De kan grupperes etter hvilket perspektiv (orientering / modelleringsretning) de støtter, hvor perspektiv blir bestemt av språkets kjernebegreper og prinsipper. De vanligste perspektivene er: - Funksjonsperspektivet. ( Strukturert analyse).den funksjonsorienterte angrepsmåten tar utgangspunkt i hvilke funksjoner (aktiviteter elle arbeidsoppgaver) som blir utført i virksomheten. Eksempler på funksjoner er produksjon, markedsføring, avlønning osv. Hovedideen i en funksjonsorientert angrepsmåte er at det er utførelsen av funksjonene i virksomheten som bestemmer hvilket informasjonsbehov en har. Ved å studere virksomhetens oppgaver vil en kunne klarlegge hvilket informasjonsbehov informasjonssystemet skal omfatte. - Dataperspektivet. (ER-modeller eller relasjonsmodeller). En dataorienter angrepsmåte ser på forholdene i og utenfor virksomheten. Indre forhold er f. eks. produkter og ansatte mens ytre forhold kan være leverandører og kunder. Disse forholdene beskrives vanligvis som entiteter. En er altså interessert i registrere informasjon om entitetene i virksomheten og denne informasjonen lagres som data. side 3 av 14
- Objektorientert (OOA, kombinerer funksjonsperspektivet og dataperspektivet. Dette perspektivet tar utgangspunk i at alt det vi kommer i befatning med stort sett kan betraktes som objekter. Produkt, ansatt, kunde, leverandør, verksted, bil, alarmsystem osv. kan alle være objekter. Objektene kommuniserer med hverandre, de kan ta i mot meldinger, bearbeide dem etter bestemte regler og sende ny informasjon til andre objekter. Et objekt er således en aktiv enhet mens en entitet er passiv ved at vi bare har informasjon om den. - Hendelsesperspektivet. Her er det den hendelsene i en virksomhet som er i fokus. Hendelsene skjer i en bestemt rekkefølge. F. eks. en student søker opptak på Høgskolen, han blir opptatt, han avlegger eksamen, han stryker og må kontinuere, etter hvert vil han ha fullført studiet og mottar vitnemål. I denne leksjone skal vi se nærmere på Strukturert analyse. Hensikten med å bruke en metode i systemutviling er å strukturere prosessene og dataanalysene som brukes i prosjektet. Videre å sikre at alle relevante detaljer er blitt dekket før systemutviklindsprosjektet går over i en ny fase. Å korrigere for feil i et datasystem etter at det er innstallert koster hundrevis av ganger så mye som å rette opp feilene i designfasen. Gode metoder med gode beskrivelser er med på å sikre at oppdragsgiverne er i stand til å kunne vurdere systemutviklingen i de ulike faser. Metodene gjør det også lettere å sikre at prosjektet er i rute og innenfor de gitte kostnadsrammer. 1.3. Strukturert analyse SASD. Strukturert analyse er en metode for å beskrive de aspekter ved en brukers omgivelser som relevante og dette skal gjøres i brukerens terminologi. I Strukturert analyse bruker man disse verktøyene: - dataflytdiagrammer - metoder for å beskrive prosesslogikk - dataflytbeskrivelse - datalager Dette fører til funksjonelle spesifikasjoner som er leselig for brukeren, som ikke sier noe om realiseringen, men som er skrevet i et språk brukeren kan forstå. SASD er en modell for analyse og utforming av et informasjonssystem. Utviklerne av modellen har også plassert SASD inn i et større perspektiv. Figuren nedenfor viser analyseog utformingsarbeidets plass i en større utviklingsmodell. Modellen er beskrevet i et dataflytdiagram. Beskrivelsesteknikkene blir gjennomgått senere. side 4 av 14
Figuren viser at SASD anbefaler at man forut for den strukturerte analysen gjør en forundersøkelse som gir retningslinjer for analysen. Parallelt med utformingen (designet) foregår den utstyrsvurdering som tar stilling til hvilket utstyr informasjonssystemet skal bruke.informasjon om det utstyr som er valgt (konfigurasjonsdata), er viktig i utformingen. Etter utformingen kommer realiseringen, som skjer på grunnlag av beskrivelsene av den tekniske løsningen. En testplan må også finnes. SASD understreker sterkt betydningen av at målet for systemeringen er klargjort og akseptert av alle berørte før den strukturerte analysen starter. Beskrivelsesteknikkene fra SADS blir ikke brukt i dette arbeidet. Det er heller snakk om intervjuer me de forskjellige involverte, utarbeiding av skriftlige notater, økonomiske kalkyler og prosjektplaner. I analysefasen av SADS bruker man følgende beskrivelsesteknikker: - dataflytdiagrammer DFD - datakatalog - strukturert språk side 5 av 14
Dataflytdiagram Dataflytdiagram viser informasjonsflyten mellom komponentene i et datasystem, hvordan den omformes og blir lagret. Videre vises datakilde og datamottaker. Et dataflytdiagram skal kun vise den logiske flyten. Fysiske prosesser som støtter dataflyten vises ikke. Et DFD-diagram består av fire komponenter: Ytre enhet. En ytre enhet er en element i omgivelsene som gir eller mottar data og er på utsiden av selve systemet. Det kan være kunder som legger inn en bestilling. En ytre enhet er representer med en firkant: Kund Prosess. En prosess er en operasjon som omformer eller flytter data på en eller annen måte. Eksempler kan være kalkuler ordretotal og sjekk pasienthistorie. Hver prosess må ha både en informasjonsflyt inn og ut for å kunne inkluderes i DFD-diagrammet. Prosesser er modellert som sirkler med en verb-basert tekst og hver enkelt prosess er numerert. 1.1 Datalager. Data lagres i datalager. Eksempel her kan være kunderegister, varelager, pasientregister, leverandørregister osv. Datalager lagrer data over tid dvs. de er tilgjengelig til en senere tidspunkt enn da de ble lagret. Et datalager må både ha informasjonsflyt inn og ut hvis det skal tilhøre et DFD-diagram. Datalager må beskrives med et navn som er et substantiv og det skal nummereres. Datalager er modellert som et rektangel. side 6 av 14
D1 Kunderegister Dataflyt. Dataflyt indikerer data i bevegelse mellom komponentene. En dataflyt må alltid starte eller ende i en prosess. Det er ikke lovlig å ha dataflyt mellom to ytre enheter, mellom to datalager eller mellom ytre enhet og datalager. Dataflyten må beskrives med et substantiv som indikerer hva dataflyten inneholder. Dataflyten modelleres som en pil for å angi retningen på dataflyten. Går det en toveis flyt mellom to komponenter kan det brukes dobbeltpil eller to piler som peker hver sin vei. Kunde B tilli Ta 1 1.3.1. Retningslinjer for å tegne dataflytdiagrammer Ta utgangspunkt i tradisjonell verbal beskrivelse og diskuter rundt den. 1. Identifiser ytre enheter (sender/mottaker av data). 2. Identifiser normal inn- og ut-data. 3. Identifiser de forespørsler etter informasjon som antas å forekomme fra mottakere av data. 4. Begynn med å tegne datflytdiagrammet, helst på et stort ark, begynn i øverste venstre hjørne. Start med den primære datakilde. side 7 av 14
5. Ikke legg vekt på å tegne pent i første omgang (gjelder ikke til eksamen!). Konsentrer deg om å få med det meste. 6. I en virkelig situasjon må en regne med minst 3 iterasjoner før en er fornøyd med formen og innholdet på høyeste nivås diagram. 7. Sjekk at alle inn- og utdata er blitt med. 8. Gjennomgang med brukere og andre involverte som kjenner systemet. 9. Rett opp og tegn en ny tegning hvor du vektlegger å tegne klart. 10. Nedbryting av hver prosess. 11. Gjennomgang med brukere. Bruk av CASE-verktøy vil gjøre at punktene over som angår rentegning endring etc. vil kunne forenkles. 1.3.2. Tegning av dataflytdiagram DFD-diagrammene viser ulike detaljenivå etter hver som prosessene blir brutt ned i mindre og mindre enheter. Det høyeste nivå eller det mest abstrakt DFD kaller vi for Kontekstdiagrammet. Kontekst-diagrammet viser utbredelsen av systemet og viser bare en prosess omgitt av de ytre enheter som sender data til eller mottar data fra systemet. Kontekstdiagrammet viser en oversikt over hovedoppgaven som systemet skal utføre. Vi skal vise hvordan DFD-diagram tegnes ved å gå gjennom et konkret eksempel: Vi skal utvikle et datasystem for et postordrefirma CBM som selger databøker. Målet med denne oppgaven er å analysere informasjonsflyten i en virksomhet og tegne et DFD diagram som viser den logiske informasjonsflyten i systemet. som bakrunnsmateriale for oppgaven har vi: Nåsituasjon i CBM: CBM mottar bestillinger fra biblioteker på databøker Det foretas samlebestilling til riktig forlag når et antall bestillinger på samme bok er mottatt. Derved oppnås kvantumsrabatt. Kundebestillingene oppfylles når CBM mottar bøkene fra forlaget Fakturering gjøres av et servicebyrå basert på formular fra CBM Ca. 100 fakturaer pr. dag i gjennomsnitt 4 boktitler pr. faktura. gj.snitt beløp: 500 kr.) Planlagt utvidelse: Holde eget lager for de 100 mest etterspurte bøkene Telefonbestilling i tillegg til postbestilling. Både for biblioteker og privatkunder Antatt volum: mer enn 1000 fakturaer pr. dag, men færre bøker pr. faktura side 8 av 14
Det første som må gjøres er å identifisere de ytre enheter for deretter å se på hvilke informasjnsflyter som går mellom de ytre enheter og postordrefirmaet. Dette skulle gi oss en total oversikt over systemet og dets omgivelser. Kontekst-diagrammet er vist nedenfor. Her ser vi at dataflytene er beskrevet med tekst som gir god informasjon om hvilket innhold det er i dataflyten. Neste trinn er å bryte ned prosessen CBM i noen mindre prosesser. For å finne frem til de delprosessene CBM-prosessen kan bestå av må vi se på dataflytene i kontekstdiagrammet for å få hjelp. Da ser vi at det er en ordreflyt og naturlig nok må det å håndtere ordre være en oppgave i CBM. Videre må CBM bestille bøker til forlag og dermed er bestilling en opgave. Kundene skal ha faktura og noen må sørge for at den oppgaven blir utført. Riktignok skal et servicebyrå utføre selve faktureringen, men de må ha informasjon om hva som skal faktureres og til hvem, og der en oppgave internt i CBM. Vi kan si at vi har kommet frem til følgende hovedoppgaver som skal utføres i CBM: Håndtere ordre Kjøpe inn varer Håndtere fakturer Dermed er vi klar til å tegne DFD-diagram på neste nivå hvor de tre nevnte prosessene skal være med. side 9 av 14
Her ser vi at Kontekstdiagrammet er brutt ned i tre prosesser som alle er nummererte. Videre er det på dette nivå, som vi betegner med DFD-0, tatt med nødvendige datalager som skal inneholde nødvendig informasjon systemet er avhengig av. Datalagrene viser hvilke prosesser som har behov for lagrede data. I realiteten kan det være at alt ligger i en felles database. Det er viktig at både prosesser, dataflyt og datalager har god og forståelig beskrivelse. Særlig bør dataflytenes navn være slik at vi klarer å skille dem fra hverandre. Som en ser av figuren er også datalagrene nummerert med D1, D2 osv. Neste trinn i nedbrytingen er å bryte ned hver av de tre prosessene i DFD-0 ddiagrammet. Vi må da tenke gjennom hvilke oppgaver hver enkelt prosess kan deles opp i. Neste nivå i nedbrytingen får betegnelsen DFD-1. side 10 av 14
Her skal en legge merke til nummereringen. Siden Håndtere ordre var prosess nr. 1 på nivået over får nedbrytingen av denne prosessen prosessnummerering som 1.1, 1.2, 1.3 osv. Tilsvarende får nedbryting av prosess 2 nummereringen 2.1, 2.2, osv. Her ser vi at det er 5 prosesser på dette nivå og det bør ikke være flere hvis det blir flere blir det lett uoversiktlig og det er da bedre å bruke flere nivå i nedbrytingen. På alle nivå i en nedbryting skal dataflytene beskrives, likeså prosesser, datalager og ytre enheter. Nedenfor vises på tilsvarende nedbryting av prosess 2 og 3. side 11 av 14
Vi ser at antall prosesser varierer fra diagram til diagram. Dette er avhengig av kompleksiteten til den prosesen som bir nedbrutt. Hvis det sendes en informasjon til en prosess som ikke tilhører den systemdelen som beskrives i DFD-diagrammet skal den side 12 av 14
prosessen ha stiplet sirkellinje slik som vist med prosess 1 Håndtere ordre i figuren ovenfor. Nå er alle prosessene på nivå DFD-0 brutt ned på et lavere nivå. Vi skal så se på nedbryting til et nivå lavere enn DFD-1 og det nivået blir da betegnet DFD-0. Vi tar fatt i prosessen 1.3 Mota ordre og bryter den ned. Vi får da følgende resultat: Hvis vi nå ser på dette DFD-diagrammet og prøver å finne oppgaver som de enkelte prosesser kan deles opp i så blir det vanskelg å finne noen fornuftig oppdeling, og vi kan si oss ferdig med nedbrytingen. Det har ingen hensikt å bryte så langt ned at oppgavene blir for oppsplittet. 1.3.3. Datakatalog Datakatalogen skal inneholde en beskrivelse av alle dataflyter og datalager som er vist på dataflytdiagrammene. Man skal også beskrve alle primitiver, det vil si prosessene på laveste nivå. Det er en smakssak hvorvidt en sier at disse beskrivelsene er en del av datakatalogen eller ikke. Vi behandler prosessbeskrivelsene for seg og ikke som en del av datakatalogen. Vi viser noen eksmpler fra DFD-diagramene vi har laget: Dataflytbeskrivelse: Mottar ordre: Kundenr + ISBNR + tittel + antall + leveringssted Ordredata: Kundenr + Varenr + navn + antall side 13 av 14
Datalager: Kunderegister: Kundenr, etternavn/firmanavn, fornavn, adresse, leveringssted, saldo Varelager: ISBNR, tittel, forfatter, opplag, antall Mest_etterspurt: ME_ISBNR, ME_tittel, ME_forfatter, ME_opplag, ME_antall 1.3.4. Prosessbeskrivelse Eksempel på prosessbeskrivelsi i strukturert språk (pseudo-kode): Sjekk kunde: for hver kunde les kundedata hvis kunde finnes fra før sjekk status return status else registrer ny kunde hvis status ok send ordre else return false Som vi ser med skikkelige bearbeidete DFD-diagram, datakatalog og prosessbeskrivelse har vi nå fått en brukbar oversikt over datasystemet vi skal utvikle. side 14 av 14