1. No category

7. Systembeskrivelse
Et informationssystem
består af to grundelementer:
data og processer. Lad os se
på et system, hvori der indgår en række priser på nogle varer, der er solgt til en
kunde (data). De forskellige priser ganges (proces) med det antal af hver vare, der
er solgt, hvorefter beløbene lægges sammen (proces) for at opnå et fakturabeløb.
Data er altså det grundmateriale,
der indgår i systemet. Disse data ændres så ved
hjælp afforskellige processer (det kan f.eks. være beregninger) således at nye data
opstår. Varepriser og vareantal var de oprindelige data. Gennem nogle beregninger kom vi frem til nye data, nemlig fakturabeløbet.
Eksemplet kan skematisk be-
skrives således (pile viser data og cirkler viser processer):
Fakturabeløb-i-e-
Varebeløb
Vareantal
7.1
Systembeskrivelsens
formål
Til beskrivelse af data og processer anvendes forskellige modelværktøjer, der hver
især har deres fordele og ulemper og fokuserer på forskellige aspekter ved det
samme system. Vi anvender forskellige beskrivelsesværktøjer
til at beskrive de
forskellige aspekter.
7. SYSTEMBESKRIVELSE
125
Systembeskrivelse har tre hovedformål:
Fokusering
Dokumentation
Kommunikation
Fokusering
Gennem systembeskrivelsen
opnår man en mulighed for at kunne fokusere på de
vigtigste og essentielle dele af systemet. Det kan være besværlige beregninger, der
skal foretages eller en specielt tilpasset brugerflade. som en bruger har ønsket. Systembeskrivelsen
er et middel til at "pille systemet fra hinanden", således at man
kan koncentrere sig om vigtige enkeltdele. Modsat kan man i beskrivelsen også
nedtone betydningen af mindre vigtige elementer, således at disse ikke ofres uforholdsmæssig lang tid i konstruktionsprocessen.
Dokumentation
Ved konstruktion
af større systemer er der ofte adskillige personer involveret.
Disse personer må nødvendigvis dokumentere
deres arbejde for at muliggøre, at
andre kan arbejde videre med de resultater, der er opnået. Systembeskrivelsen
en struktureret
og systematiseret
Desuden kan en dokumentation
er
metode til at foretage denne dokumentation.
være en hjælp efter at systemet er færdiggjort.
Ved eventuelle rettelser af fejl eller ændringer i systemet kan dokumentationen
fremdrages og benyttes som en beskrivelse af de tanker, der blev gjort, da systemet blev konstrueret.
Kommunikation
En systemudviklingsopgave
er en opgave med mange facetter. Et enkelt lille pro-
blem kan have mange forskellige løsninger. Den person, der i sidste ende skal anvende systemet (brugeren) vil måske løse et problem på en bestemt måde, medens
konstruktøren
vil løse det samme problem på en helt anden måde. Et meget væsent-
ligt mål for et moderne IT-system er, at systemet er tilpasset de krav og behov, som
brugeren af systemet har. Derfor er det vigtigt, at brugeren inddrages i systemudviklingen. Systembeskrivelsen kan indgå som et grundlag for en diskussion afhvilke løsninger, der er bedst til forskellige problemer. Ved hjælp af systembeskrivelsen
kan brugeren se - og tage stilling til- forskellige løsningsmetoder, før disse faktisk
er indbygget i det færdige system. På denne måde minimeres risikoen for fejl.
SYSTEM BESKRIVELSE:
systems
126
virkemåde
En samling
af metoder
til beskrivelse
af et IT-
og data.
7. SYSTEM BESKRIVELSE
7.2 Top-Down princippet
Et system består af dele, der hænger sammen og har indflydelse på hinandens virkemåde. Ved beskrivelsen af et system har vi mulighed for to forskellige strategier. Den
første strategi kaldes en bottom-up strategi, fordi man starter med de mest detaljerede dele af systemet, og herefter arbejder sig op mod det færdige (totale) system. Den
anden strategi kaldes en top-down strategi, fordi man her tager udgangspunkt i det
totale system, og herefter nedbryder dette i de delelementer, der indgår i systemet.
Når det handler om IT-systemer har det færdige, totale system, vores primære
interesse. Derfor er det hensigtsmæssigt,
at starte beskrivelsesprocessen
med at
give et overblik over systemet, samt en beskrivelse af hvor systemets grænser går,
og hvordan systemet skal spille sammen med andre systemer. Herefter kan man
så nedbryde systemet i dets delelementer og beskrive disse mere detaljeret. Det
er altså hensigtsmæssigt
at anlægge en top-down strategi ved systembeskrivelsen.
Vi skal igennem systembeskrivelsen
have beskrevet flere forskellige forhold ved
systemet:
Systemafgrænsningen
Processer, der indgår i systemet
Sammenhænge
mellem de data, der indgår i systemet
Detaljeret beskrivelse af data, der indgår i systemet
Top-Down princippet
kan ses som en trappe, hvor hvert enkelt beskrivelsesni-
veau ligger et trin under det foregående. I en top-down beskrivelse vil rækkefølgen typisk være følgende:
AFGRÆNSNING
AF SYSTEMET
!
BESKRIVELSE AF
PROCEDURER
l
BESKRIVELSE AF
LOGISKE DATASAMMENHÆNGE
l
BESKRIVELSE AF
FAKTISKE DATASAMMENHÆNGE
l
DETALJERET
BESKRIVELSE
AF DATA
Top-Down princippets beskrivelsesniveauer.
7. SYSTEMBESKRIVELSE
127
Afgrænsning
af systemet
Den første opgave i forbindelse med top-down systembeskrivelsen
er, at beskrive
grænserne for systemet. Det system, vi vil beskrive, modtager data og afgiver data
til en række andre systemer. Det er derfor vigtigt at få fastlagt, hvor systemet "begynder" og "slutter". Først når denne afgrænsning er foretaget, ved vi hvad det er,
vi ønsker at beskrive - og først da kan vi opdele systemet yderligere.
Beskrivelse af procedurer
Data i systemet gennemgår forskellige handlinger - eller procedurer.
f.eks. være en beregning på nogle tal, eller blot en indtastning
data. Rækkefølgen og indholdet af disse procedurer
Det kan
eller en lagring af
er af stor betydning. Vi har
derfor en række værktøjer til at beskrive disse procedurer.
Beskrivelse aflogiske datasammenhænge
Mange systemer baseres på, at data er gemt i forskellige registre. Mange transaktioner i en organisation beskriver en sammenhæng
en kunde omhandler
f.eks. sammenhængen
mellem disse data. Et køb fra
mellem de data, vi har om kunden,
og de data vi har om varer. Disse sammenhænge
er essentielle for vort system - og
skal derfor beskrives.
Beskrivelse af faktiske datasammenhænge
De logiske datasammenhænge
skalomformes
for at kunne lagres på en sådan
måde, at data let kan genfindes og opdateres.
Detaljeret beskrivelse af data
Det sidste trin i beskrivelsen er detaljeret at beskrive de enkelte data, der indgår
i systemet.
Hvis vi sætter værktøjsnavne på, vil top-down trappen få følgende udseende ved
beskrivelsen af et informationssystem:
Værktøjer i Top-Down princip.
128
7. SYSTEM BESKRIVELSE
I dette og det følgende kapitel vil vi beskrive hver enkelt af disse beskrivelsesværktøjer.
TOP-DOWN PRINCIP: Beskrivelsesprincip,
overordnet
der starter med en grov,
beskrivelse af et system for senere at gå mere i detaljer
med systemets bestanddele.
7.3 Context-diagrammer
Det første trin i systembeskrivelsen
er et context-diagram. Context-diagrammet
kaldes også et afgrænsningsdiagram, fordi det afgrænser det system, man beskriver, fra de omgivende systemer.
Formål:
Afgrænsning af systemet til omgivelserne.
Illustrerer de afgivere og modtagere af data systemet har.
Illustrerer hvilke data systemet afgiver og hvilke det modtager.
Context-diagrammet
indeholder kun tre symboler:
Cirklen illustrerer
selve det system, vi ønsker at
beskrive. Inden i cirklen skriver man et navn på
det pågældende system. Hvis man f.eks. Ønsker
at konstruere et system til styring af lageret i en
virksomhed,
kan man skrive lagerstyring.
Rektanglet illustrerer
en interessent. En interessent
er en afsender eller modtager af data til eller fra
systemet. Interessenter
kan være eksterne firmaer
eller personer, men kan også befinde sig internt i
organisationen.
Når et faktureringssystem
f.eks.
udskriver en regning, der skal sendes til en kunde,
er kunden datamodtager,
Pilen illustrerer
og altså en interessent.
en datastrøm.
I et context-diagram
er en datastrøm en mængde af data, der går fra
systemet til en interessent eller en datamængde
fra en interessent til systemet. Navnet på
datastrømmen
skrives på pilen. Når fakturaen
sendes til kunden vil der gå en pil fra systemet
(cirklen) til interessenten
7. SYSTEMBESKRIVELSE
kunde (rektangel).
129
Context-diagrammet
har følgende principielle opbygning:
Man starter med at tegne en cirkel. Denne cirkel illustrerer det system, man ønsker
at beskrive. Dernæst tegner man de interessenter, der leverer data til systemet eller
modtager data fra systemet. Disse illustreres med rektangler. Til sidst vises de datastrømme, der går mellem interessenter og systemet. Datastrømme
ses med en pil fra interessenten til systemet. Datastrømme
pile fra cirklen mod interessenterne.
til systemet vi-
fra systemet vises med
Der må ikke gå datastrømme mellem de en-
kelte interessenter.
Eksempel:
I et salgssystem bestiller en kunde varer ved at indsende en ordre. Når denne
er modtaget sendes en ordrebekræftelse
på bestillingen til kunden. Hvis den
bestilte vare ikke er på lager, sendes en bestilling til leverandøren. Når en ordre er ekspederet sendes en kopi til regnskabsafdelingen.
Enkelte ordrer mod-
tages direkte fra ansatte sælgere.
Kunde
Sælgere
Kunde
dre
Ordrebe ræftelse
Or
Varet! stilling
Regnskabsafdeling
Leverandør
Det er vigtigt at holde sig for øje, at context-diagrammet
gram. Diagrammet
Vi kan i diagrammet
er et afgrænsningsdia-
viser kun den berøringsflade vort system har til omverdenen.
se, hvilke data systemet skal kunne modtage, og hvilke det
skal kunne producere og afgive. Dette er også grunden til, at der ikke må gå pile
mellem interessenterne.
Man kan ganske vist sagtens tænke sig, at der går data-
strømme mellem to eller flere interessenter - men disse datastrømme
er ikke væ-
sentlige i forhold til det system, vi betragter. I vort eksempel fra før kunne man
forestille sig, at kunden afgiver en ordre direkte til leverandøren.
Dette skal ikke
vises i vort diagram, da denne datastrøm er irrelevant for det system, vi beskriver.
Derfor vises heller ikke kundens ordre til sælgerne.
130
7. SYSTEMBESKRIVELSE
Nogle IT-systemer har mange berøringsflader til omverdenen. Systemet skal f.eks.
producere data til kunder, leverandører, medarbejdere,
med mange flere. Dette vil i context-diagrammet
offentlige myndigheder
blive vist ved, at der optræder
mange interessenter. Andre systemer har en mere begrænset berøringsflade.
Eksempel
Et rådgivende konsulentfirma
ønsker at opbygge et system til projektstyring.
år
en kunde ønsker hjælp til en opgave, henvender kunden sig til konsulentfirmaet. Konsulentfirmaet
udfylder en projektbeskrivelse
og undersøger hvilke med-
arbejdere, der kan gennemføre projektet. Herefter sendes en ordrebekræftelse
til
kunden.
I dette tilfælde indgår kun en interessent i context-diagrammet:
Kunde
At context-diagrammet
er simpelt behøver dog ikke nødvendigvis
at betyde, at
også systemet er simpelt. Det der foregår inden i cirklen kan være endog særdeles kompliceret.
CONTEXT-DIAGRAM:
Afgrænsningsdiagram
til beskrivelse af
systemets grænser til omverdenen.
7.4
Data-flow diagrammer
Det næste trin i beskrivelsen er data-flow diagrammer. Data-flow diagrammer
faktisk en hel familie af diagrammer,
der hver især giver en mere og mere udfør-
lig beskrivelse af systemet. Man opdeler disse diagrammer
7. SYSTEMBESKRIVELSE
er
iniveauer, således at et
131
højere niveau giver en mere detaljeret beskrivelse af systemet.
Formål:
At illustrere hvilke handlinger systemet skal udføre.
At illustrere den rækkefølge hvori handlingerne
skal udføres.
At illustrere hvilke registre systemet behøver.
Data-flow diagrammet
indeholder fire symboler:
Cirklen illustrerer
en proces. En proces er en
handling, der skal udføres for at behandle data.
En ajourførinq
af data i et register er et eksempel
på en sådan proces. Navnet på processen skrives
i cirklen. Processer nummereres
tal i cirklen. Tallene illustrerer
ved at skrive et
den rækkefølge,
hvori processerne skal udføres.
Rektanglet illustrerer
en interessent. En interessent
er en afsender eller modtager
systemet. Interessenter
af data til eller fra
kan være eksterne firmaer
eller personer, men kan også befinde sig internt i
organisationen.
Når et faktureringssystem
f.eks.
udskriver en reg.ning, der skal sendes til en kunde,
er kunden datamodtager,
og altså en interessent.
De to parallelle streger illustrerer
et register.
Navnet på registret skrives mellem de to streger.
Pilen illustrerer
en datastrøm.
diagram er en datastrøm
går mellem en interessent
I et data-flow
en mængde af data, der
og en proces, mellem
to processer eller mellem en proces og et register.
Data-flow diagram (niveau O)
På det første niveau af et data-flow diagram (niveau O) skal vi give en mere detailleret beskrivelse af det system, der tidligere er blevet beskrevet i context-diagrammet. Derfor skal der også være en sammenhæng
mellem de to diagrammer:
skal optræde de samme interessenter i begge diagrammer, og alle datastrømme
og fra interessenterne
Der
til
skal være de samme. Men her holder ligheden også op. For-
målet med data-flow diagrammet
er, at give en yderligere beskrivelse af systemet.
Der optræder derfor flere processer i et data-flow diagram. Man opsplitter så at
sige context-diagrammets
132
ene proces i et antal delprocesser, der viser de handlin-
7. SYSTEM BESKRIVELSE
ger systemet skal foretage. Derudover optræder der i data-flow diagrammet
et nyt
symbol, et register, der symboliserer de datalagre, der indgår i systemet.
Data-flow diagrammet
fra det tidligere eksempel kunne se således ud:
Kunde
Sælgere
Ordreregister
Kunderegister
Vare
Ordr kopi
tilling
Leverandør
Regnskabsafdeling
Når en ordre modtages fra en kunde indtastes den, og den registreres i et ordreregister. Herefter benyttes data fra ordre- og kunderegistret
drebekræftelse,
til at udskrive en or-
der sendes til kunden. Ved at undersøge varegistret finder man
ud af, om varen er på lager. Hvis dette ikke er tilfældet, sendes en varebestilling
til en leverandør. På grundlag af data i ordre- og i kunderegistret
udskrives en or-
drekopi, der sendes til regnskabsafdelingen.
Der er i forbindelse med tegning af et data flow diagram et par principielle forhold,
der bør tages op. Det handler især om de datastrømme,
Hvis det er selvforklarende
der går til og fra registre.
hvilke data, der lagre s i eller hentes fra et register
er det ikke nødvendigt at skrive datanavn på datastrømmen:
7. SYSTEMBESKRIVELSE
133
Ordredata går ind i processen "Registrering".
Det er derfor indlysende, at
det også er ordredata, der registreres i
Ordreregister
"Ordreregister".
Hvis data i samme arbejdsgang både hentes og lagre s i et register vises dette
med en dobbeltpil. Det kan f.eks. være i forbindelse med en ajourføring af et
register:
I forbindelse
med udskrivning
ordrebekræftelse
af en
hentes kundens
navn og adresse i registret, hvorefter
der lagres data om ordren i samme
Kunderegister
Sammenhængen
register.
mellem context-diagrammet
lustreres ved at stille de to diagrammer
og data-flow diagrammet
kan il-
op over for hinanden:
Ordreregister
Kunderegister
Ordr kopi
Sammenhængen mellem et context- og et data-flow diagram.
134
7. SYSTEMBESKRIVELSE
Man kan her se, at data-flow diagrammet
er en "åbning" af context-diagram-
mets ene proces. Man kan i data-flow diagrammet
se hvilke processer, der skal
udføres for at behandle og producere de data, der udgår fra context-diagrammets
proces.
Data-flow diagrammet
for vort andet eksempel kunne se således ud:
IReniVeA~lse
Praje tdata
Prajektreg ister
Data-flow diagram (niveau l)
For yderligere at beskrive systemet kan man nedbryde de enkelte processer i dataflow diagrammet.
Dette gøres for at kunne beskrive de handlinger, der skal udfø-
res for at kunne gennemføre de enkelte delprocesser i niveau Odiagrammet.
bolerne er de samme som vi kender fra niveau Odiagrammet,
Sym-
men der optræder
ikke interessenter i et niveau l diagram.
Ordreregister
Vareregister
7. SYSTEM BESKRIVELSE
135
Vi så, at man idata-flow diagrammet
(niveau O) nummererede
de forskellige pro-
cesser. Dette gøres for at de senere kan beskrives mere præcist. Hver enkel proces
i et niveau l diagram nummereres
med nummeret på den proces, man ønsker at
beskrive, efterfulgt af processens rækkefølgenummer
Ordredata fra ordreregistret
i niveau l diagrammet.
anvendes sammen med data fra vareregistret
til at
undersøge, om de bestilte varer er på lager. Hvis dette ikke er tilfældet, udskrives en varebestilling.
Hvis varen derimod er på lager, registreres en reservation i
vareregistret.
Som det ses, består et sådant diagram af nogle datastrømme
ser. Processerne er nummererede
og nogle proces-
med 5.1, 5.2 og 5.3. Dette skal illustrere, at dia-
grammet er en udvidelse af proces nr. 5 i data-flow diagrammet
niveau
o. Proces
nr. 5 i data-flow diagram niveau O består altså af tre delprocesser. Der optræder
ikke interessenter i et niveau l diagram. Dette skyldes, at ikke alle delprocesser leverer data til eller modtager data fra en interessent. Formålet med dette diagram
er at beskrive de enkelte processer - ikke at beskrive data til og fra systemet. Diagrammet beskriver altså de enkelte processer i niveau O diagrammet,
og derfor
skal pile til og fra diagrammet svare til de pile, der går til og fra de enkelte processer i niveau O diagrammet.
På samme måde som et niveau O diagram kan ses som
en "åbning" af context diagrammets
proces, kan et niveau l diagram ses som en
"åbning" af en proces fra niveau O diagrammet:
tilling
Sammenhængen mellem to niveauer af data-flow diagrammer.
136
7. SYSTEM BESKRIVELSE
Der skal være en sammenhæng
processer i niveau O diagrammet
mellem de datastrømme,
og de datastrømme,
der vises i de enkelte
der vises i niveau l dia-
grammet. Alle relevante processer fra niveau O diagrammet
bør på denne måde
nedbrydes til et niveau l diagram. Hvis der ønskes en yderligere beskrivelse af
systemet, kan dette ske ved yderligere at nedbryde diagrammerne.
sempelvis konstruere
Man kan ek-
et niveau 2 diagram ved at beskrive de enkelte processer i
niveau l diagrammerne.
Det vil ikke være nødvendigt
at foretage en nedbryd-
ning for alle processer. Og alle processer behøver altså ikke at blive nedbrudt til
samme mveau.
DATA-FLOW DIAGRAM: Familie af diagrammer
arbejdsgangen
i et system. Diagrammerne
til beskrivelse af
opdeles i niveauer, der
beskriver systemet i stigende detaljeringsgrad.
7. SYSTEMBESKRIVELSE
137