SIF 8035 Informasjonssystemer Våren 2001 Øving 2 DFD-modellering Innlevering: Mandag 12. februar I denne oppgaven skal dere gjøre en strukturert analyse av den vedlagte oppgavebeskrivelsen for Fias Fjernundervisning. Dere skal fokusere på hovedprosessene og informasjonsflyten i systemet. Dere skal levere en prosessmodell i modelleringsspråket DFD (Data Flyt Diagram) i 3 nivåer slik som angitt i de 3 deloppgavene. Prosess-modellering er beskrevet i pensumartiklene P3, P4 og P5. Dere skal lage DFD diagrammer etter Gane & Sarsons notasjon (P3,s31,32). Som tegneverktøy, kan dere enten bruke PPP DFD editoren som er installert på datasalene eller kan lastes ned via web: (http://www.idi.ntnu.no/~ppp/dfd/) eller dere kan også bruke et hvilket som helst tegneprogram, f.eks. VISIO eller PowerPoint. Modellene skal forklares med tekst. Øvingen skal som vanlig leveres som en e- post til deres und.ass. Dersom dere skriver forklaringen til oppgavene direkte i e- post meldingen, så husk å legge ved alle modell/diagramfilene dere har laget. Dersom dere skriver rapporten i den tekstbehandler, kan dere bruke File- >Export EPS... fra DFD-editoren og lage en EPS fil som så kan importeres i tekstbehandleren dere bruker denne EPS filen vises bare som en grå boks i Word, men den skal se fin ut på utskrift. Klipp og lim fra editoren virker også, men dere må da skalere opp diagrammene etter å ha pastet dem i word (de blir knøttsmå).
OPPGAVE 1 - TOPPNIVÅ DFD Lag først et såkalt ToppNivå DFD diagram. Et slikt toppnivå DFD skal kun inneholde én eneste prosess, nemlig den svært abstrakte prosessen FIA s System. Formålet med dette diagrammet er å vise systemets interaksjon med omverdenen. Dere skal få med all flyt til/fra systemet og de eksterne agenter (så som Foreleser, Undervisningsutvalg, Studenter). Dersom diagrammet blir seende ut som et edderkoppnett med massevis av overlappende flyter til/fra systemet, kan dere prøve og slå sammen noen av flytene, for så å dekomponere disse i neste oppgave. For slike abstrakte flyter er det viktig at de gis gode navn og/eller beskrives slik at alt innholdet i flyten kommer klart frem. OPPGAVE 2 - FØRSTEORDENS DFD Dere skal så lage et førsteordens dataflytdiagram som viser hovedprosessene i systemet. Prøv å beskrive de prosessene og informasjonsflyten som skjer i systemet fra planleggingen av et semester starter og til alle studentene har fått sine vitnemål. Fokusér på de viktigste funksjonene systemet skal gjøre, men husk at all funksjonalitet må dekkes på dette nivået. En litt grov tommelfingerregel sier at det ikke bør være mer enn 10 prosesser i et slikt overordnet diagram. Får dere veldig mange, se om noe funksjonalitet hører naturlig sammen og derfor kan grupperes, for så å dekomponeres i et senere diagram. For at diagrammet her skal være konsistent med toppnivå-diagrammet dere laget i oppgave 1, må all interaksjonen mellom systemet og de eksterne entitetene som dere har modellert inn i oppgave 1 kunne finnes igjen på dette nivået. Gi så en kort tekstlig beskrivelse av innholdet/funksjonen til: Hver prosess med dens inn og ut flyt(er) Datalager Agenter OPPGAVE 3 - DEKOMPONERING Dekomponer prosessen(e) som omhandler selve forelesningen et hakk ned. Tegn den dekomponerte prosessen i et nytt diagram. Dere kan bruke 'edit properties' funksjonen i editoren for å sette riktig nummer på underprosesser. Legg vekt på konsistens mellom diagrammene på de ulike nivåer. Med konsistens menes her for eksempel at alle flyter som går inn til en prosess på et nivå, også må finnes igjen på nivået under (i den dekomponerte prosessen). For å "hente inn" flyter utenfra (for eksempel fra eksterne Agenter eller andre prosesser utenfor dekomponeringen), kan dere bruke sirkel symbolet (kalt Condition Class symbol ) og indikere med tekst hvor flyten kommer fra eller går til. Sirkelsymbolet har ingen betydning i denne sammenhengen, dette er bare for å ha et sted å feste lenkene.
Vedlegg: CASE Utvikling av informasjonssystem for Fia s Fjernundervisning Fia har startet et internett-basert fjernundervisningsselskap. Selskapet har vokst seg stort de siste årene, og hun trenger nå et informasjonssystem som kan støtte både planlegging og gjennomføring av et semester. Semesterforberedelsene starter ved at Rektor (Fia) sender ut invitasjon til potensielle faglærere om å bidra med fag. Hvis en faglærer har hatt fag tidligere, sender systemet også ut den eksisterende fagbeskrivelsen. Faglærere som ønsker å bidra, sender inn et forslag til fagbeskrivelse. Alle må sende inn nye forslag Fia godtar ikke at gamle fag kjøres om igjen uten fornyelse. Når fagbeskrivelsene er mottatt, starter planleggingen av semesteret. Undervisningsutvalget går gjennom beskrivelsene og setter sammen en fagplan. De utvalgte faglærerne får tilsendt kommentarer på sine fagbeskrivelser, og må korrigere disse, slik at fagene passer inn i fagplanen. Fagplanen gjøres tilgjengelig for studenter på Web. Det opprettes så et fag-nettsted for alle fag, hvor fagene presenteres med fagnummer, tittel og tilhørende beskrivelse. Alle studentene som ønsker å ta fag hos Fia, må registrere seg selv over web. Studentene legger selv inn sin studentinformasjon, og får tilsendt studentnummer. Registrerte studenter kan så logge seg inn og se gjennom tilgjengelige fag. Alle fag er delt inn i grunnfag, videregående fag og påbygningsfag, slik at studenter som har tatt fag tidligere, kan bygge videre på den studiekompetansen de har opparbeidet hos Fia. Fagene er også kategorisert etter emne (for eksempel IT eller Økonomi ), slik at studenter kan få anbefalt tematisk beslektede fag. Når tidsfristen for å melde seg opp til fag er gått ut, genereres det navnelister for hvert fag som lagres på fagets nettsted. Før semesterstart må faglæreren forberede faget. Systemet gir faglærer tilgang til den endelige fagbeskrivelsen og til listen over oppmeldte studenter. I tillegg kan faglærer få tilgang til evt. eksisterende studiemateriale fra tidligere gjennomførte fag. Faglærer setter opp forelesningsplan som forteller når forelesningene skal finne sted og hvilke deler av pensum som skal behandles. Siden all undervisning skal foregå over web, må alt fagmateriale publiseres på fagets nettsted. Foreleser må dermed lage eller skaffe elektronisk publiserbare utgaver av alle forelesninger, alle pensumartikler og alle oppgaver som studentene skal utføre. Spesielt for Fia s system, er at det må lages kontrolloppgaver for hver enkelt forelesning. Det er disse kontrolloppgavene som tilsammen utgjør eksamen i faget. Disse oppgavene utføres individuelt av studentene etter hver forelesning. Kontrolloppgavene lages på en slik måte at de kan leveres over nett og at studentens poengsum kan beregnes automatisk. Selve forelesningene kringkastes live fra et studio hvor forelesningen filmes og sendes over nett til studentene. Interaksjon fra studenter til foreleser og studentene imellom foregår ved hjelp av flerbruker chat-programmer av typen IRC. Før en forelesning lastes presentasjonen inn i systemet. Studentene kan så logge seg på, laste ned forelesningsmaterialet og evt. nødvendige verktøy før selve fremføringen kan starte. Studenter og forelesere kommuniserer fritt under selve presentasjonen. Etter at forelesningen er ferdig, må studentene gjennomføre kontrolloppgavene innen en gitt tidsfrist. Poeng beregnes automatisk ved innlevering og studenten kan dermed selv følge sin progresjon. Besvarelsene sendes til faglærer, som har en ukes frist til å gi en kort skriftlig tilbakemelding. Når alle forelesninger er over for semesteret, avsluttes faget ved at foreleser går gjennom alle tilbakemeldingene på kontrolloppgavene og skriver en totalvurdering av studenten. Det genereres så et vitnemål som sendes studentene pr. e-post. Vitnemålet lagres også i studentdatabasen og gir studenten økt studiekompetanse og adgang til å ta nye fag.
Vedlegg: INTRODUKSJON TIL STRUKTURERT ANALYSE I pensum finnes en beskrivelse av hvordan man bruker strukturert analyse for å utvikle funksjonelle spesifikasjoner. Strukturert analyse er en metode for å beskrive de aspekter ved en kundes omgivelser som er relevante, og dette skal gjøres i kundens terminologi. I strukturert analyse bruker man disse verktøyene: dataflytdiagrammer metoder for å beskrive prosesslogikk; dette kan være strukturert norsk, beslutningstabeller, beslutningstrær eller utvidelser av DFD som f.eks. PrM. Dette fører til funksjonelle spesifikasjoner som er leselige for brukeren, som ikke sier noe om implementasjonen, men som er skrevet i et språk brukeren kan forstå. KOMPONENTER I DATAFLYTDIAGRAMMER Vi skal bruke de ulike komponentene i PPP DFD som bygger på Gane og Sarsons standardnotasjon for DFD-diagrammer. Diagrammene inneholder følgende konsepter: Agenter, dvs. steder hvor data kommer fra eller sendes til. Agenter kan sees på som objekter med predefinerte egenskaper - f.eks. en menneskelig rolle eller et program. Prosesser som gjør noe med data Flyt av data Datalagre Det er vanlig å nummerere prosessbokser og datalagre. Et datalager ikke er det samme som en database. Et datalager indikerer bare at data er persistente utenfor prosessen - dvs. at de kan eksistere selv etter at prosessen har avsluttet. I en implementasjon kan flere datalagre implementeres i en og samme database, eller motsatt; et datalager kan implementeres på forskjellige måter. Tradisjonelle DFD-diagrammer dekker ikke tidsperspektivet særlig godt. Derfor er det i PrM språket bl.a. innført klokker, triggere og terminatorer. Triggere og terminatorer kan brukes for å markere hvilke flyter som starter og stopper en prosess. I editoren dere bruker er det støtte for å kunne markere flyter med en T for å vise dette.
TIPS TIL ØVINGEN Når man skal tegne dataflytdiagrammer for et informasjonssystem, vil man stå overfor et utall av valgmuligheter m.h.t. detaljeringsgrad, hva som er relevante prosesser, hva som er dataflyt, identifikasjon av agenter osv. Denne beskrivelsen vil hjelpe dere et stykke på vei med dette. Hierarkisk Dekomponering Ettersom diagrammene ville bli håpløst uoversiktlige hvis alt skulle tegnes på samme A4-ark, tegner man først bare hovedkonseptene. Disse vil så senere dekomponeres, det vil si at man detaljerer det som ligger bak prosesser, flyter og datalagre på et nivå.. Valg av prosesser, agenter og dataflyt Identifisér all innflyt og utflyt til diagrammet. Arbeid fra input til output. Alle dataflytlinjer skal ha navn. En god idé kan være å navngi prosesser med ord fra inn- og utflytnavnene. Vær forberedt på å starte pånytt når du oppdager at du kunne gjort ting bedre, eller du støter på problemer med prosessnavn, flytnavn osv. Første ordens DFD Dette er DFD-diagrammet på øverste nivå. Dette skal ikke være altfor detaljert. Kun hovedaktiviteter skal være med - detaljene skal spares til lavere nivåer. Husk likevel at du nå setter konteksten (rammen) for systemet. Det du utelater av hovedaktiviteter vil bli ignorert senere i dekomponeringen. Det ovenstående gjelder også for datalagre. Det er forøvrig lovlig å bruke datalagre som er interne for prosessen. Disse er skjult på øverste nivå. Agenter Valg av agenter er ikke alltid like enkelt. Er f.eks. legen på et legekontor en agent som sender/ mottar data? I de fleste tilfeller vil han kun trekkes inn i konstruksjonsfasen som en agent som trigger og terminerer prosesser, i og med at han er den som utfører mange av funksjonene som er beskrevet. Dataflyt Det er lovlig å legge dataflyt mellom agenter og prosesser, mellom prosesser, mellom prosesser og datalagre. Agenter kan ikke legge data direkte i datalagre. Dataflyt mellom to datalagre er heller ikke lovlig. All dataflyt skal gis distinkte navn.
Navnsetting Dataflytnavn: Navnene som velges for dataflytlinjer betyr mye for lesbarheten av ditt diagram: Hver flyt skal ha sitt distinkte navn. Husk at navnene skal beskrive det som flyten inneholder, og helst alt flyten inneholder - ikke bare hovedkomponenten. Ikke bruk dvaske flytnavn som data og informasjon. Av og til ender du opp med flytnavn som nødvendige data, eller forskjelligeting. Når dette skjer, ikke prøv å spekulere ut nye navn, men bli heller kvitt den flytlinjen ved å omstrukturere diagrammet noe. Prosessnavn: Det kan være nyttig å sette navn på prosesser etter at all dataflyt har fått navn. Husk at alle dataflytlinjer skal ha forskjellige navn. Når du så gir navn til prosesser, husk følgende: Prosessnavn skal gjenspeile hva som foregår i prosessen. Det er ikke ærlig overfor prosesser som gjør flere ting å bare nevne en av tingene. Bruk fortrinnsvis navn som har et verb og et objekt. Har du to verb, burde kanskje prosessen vært oppdelt. Unngå dvaske verb som prosessér'', eller behandle, som ikke sier deg noenting. Hvis det beste navnet du kommer på inneholder slike ord, har du en prosess du ikke kan sette navn på. Du må da antageligvis oppdele prosesser på en annen måte. Del dem i to eller tre deler, eller grupper dem sammen med andre prosesser for å finne noe som kan settes navn på. TEKSTLIGE BESKRIVELSER AV DIAGRAMMENE Tenk over hva du vil med beskrivelsen. Tenk dere at dere skal sende modellen til vurdering hos en en prosjektleder som ikke har vært med på selve modelleringen, eller til en kunde som ikke nødvendigvis er trenet i å lese modeller. Forklaringene skal være en oversiktlig hjelp til forståelsen av hver prosess. Du skal da ikke skrive en stil om hva som skjer med et dataobjekt i prosessen. Du skal heller ikke skrive bare opplagte ting, som du ellers vil kunne se av diagrammet. Det samme gjelder for dataflyt og datalagerbeskrivelser.