DataMuseum.dk

top - metrics - download

    Length: 8448 (0x2100)
    Types: TextFile
    Names: »difbog3b«

└─⟦621cfb9a2⟧ Bits:30002817 RC8000 Dump tape fra HCØ.  Detaljer om "HC8000" projekt.
    └─⟦0364f57e3⟧ 
        └─⟦d7df738ed⟧ »difbog« 
└─⟦667bb35d6⟧ Bits:30007480 RC8000 Dump tape fra HCØ.
    └─⟦4334b4c0b⟧ 
        └─⟦d7df738ed⟧ »difbog« 
            └─⟦this⟧ 

TextFile

bog3b=set 200 
bog3bproof=set 200
bog3b=typeset machine.diablo proof.bog3bproof
*pl 297,30,235,18,10*
*pn 5,1*
*lw 170*
*lm45*
*fs +*
*ld16*
*ps*
3.3. Anvendelsesprogrammer.*nl1*
---------------------------*nl2*
*lt1,kartoteker*
Fælles for de to anvendelser vi har beskrevet i forrige kapitel er,
at vi har registreret nogle oplysninger (kontoplan, patientdata,
behandlingspriser), og at vi kan udføre forskellige administrative
funktioner v.h.a. disse oplysninger (udskrive regninger, opdatere saldi,
få kontoudtog). Oplysningerne er ofte organiseret i såkaldte kartoteker
(også kaldet registre eller filer). F.eks. kan vi have et kontokartotek,
et patientkartotek, osv. De administrative funktioner realiseres v.h.a.
programmer, som afvikles af centralenheden og som bearbejder oplysningerne 
i kartotekerne. Sådanne programmer kalder vi anvendelsesprogrammer.
Der kan være et program til rykkerudskrivning, et til opdatering af
kontokartotek, osv. (se figur 3.6). Afviklingen af disse programmer
varetages af et operativsystem.
*fn1, fig. 3.6:*
*nl2*
*lt1,BASIC, Pascal*
En række beslægtede funktioner.
*lt1,COBOL*
samles ofte i et program.
Størrelsen af programmerne afhænger bl.a. af størrelsen af det indre
lager. Som regel skrives programmerne i et højere programmeringssprog.
På mikrodatamater er dette oftest BASIC, men også Pascal og COBOL anvendes.
 I disse sprog kan programmøren bekvemt udtrykke adgangen
til kartotekerne og adgangen til de ydre enheder. I figur 3.7 ses et
eksempel på en kildetekst til et sådant program.
*fn1,fig. 3.7:*
*nl2*
Det er karakteristisk for anvendelsesprogrammerne, at deres funktion
i det væsentlige består i at indlæse og kontrollere oplysninger, at opsøge
oplysninger i kartotekerne og formatere udskrifter. Hvor let det er at skrive
et anvendelsesprogram afhænger derfor af, hvor gode faciliteter, der findes
i sproget til at håndtere kartotekerne og indlæsning/udskrivning specielt
tegnbehandling.
*nl3*
3.4. Operativsystemet.*nl*
----------------------*nl2*
Til at afvikle de oversatte anvendelsesprogrammer findes der et operativsystem.
De oversatte anvendelsesprogrammer ligger lagret på disketterne, og læses ind
i det indre lager af operativsystemet, når brugeren ved skærmen beder om det.
Desuden indeholder operativsystemet alle de funktioner, som er fælles for
anvendelsesprogrammerne f.eks. adgangen til de ydre enheder og adgangen til
kartotekerne. Med andre ord er det operativsystemet, som omdanner materiellet
(centralenhed, lager og ydre enheder) til den maskine, som ses fra
anvendelsesprogrammerne. Dette er illustreret i figur 3.8.
*fn1, fig. 3.8:*
*nl2*
Da materiellet jo er meget leverandørafhængigt er operativsystemerne det også,
og det er meget forskelligt hvilke faciliteter de indeholder (hvilken 
maskine de realiserer). Dette forhold betyder, at der ofte skal ændringer i
operativsystemet til, når materialkonfigurationen skal laves om. Der er dog
efterhånden etableret en standardiserng af operativsystemerne, f.eks. CP/M og
*mt1,CP/M, UNIX*
UNIX, som kan fås til en række forskellige anlæg, og som bevirker, at et program
skrevet i f.eks. Pascal til at køre under UNIX, kan flyttes til alle maskiner,
der kan køre UNIX. Derved er man ved køb af et anvendelsesprogram blevet mindre
afhængig af hvilket anlæg, der skal benyttes.
Vi vender tilbage til dette punkt i et senere afsnit.
*nl2*
*lt1,enkeltbruger*
Næsten alle operativsystemer, der kan fås i øjeblikket er såkaldte
enkeltbruger systemer, hvilket betyder, at der kun kan afvikles et
anvendelsesprogram ad gangen. Kun ganske få flerbrugersystemer er tilgængelige.
Dette betyder, at det er særdeles vanskeligt at tilslutte mere end en skærm
til anlægget.
*nl3*
3.5. Vedligeholdelse.*nl*
---------------------*nl2*
*lt1,fejl*
Enhver ændring af et programsystem, efter at det er taget i brug, kaldes
vedligeholdelse. Der findes to former for ændringer. For det første kan man
opdage fejl i programmerne. Det kan f.eks. være, at der mangler kontrol af en
inddateret værdi og vi kører videre med en forkert værdi; forkerte rabatter
ved for store beløb; sum af kolonne passer næsten med sum af de udskrevne tal
osv., osv. Sådanne fejl fjernes ikke ved at prøve igen eller få en ny kopi af
programsystemet fra leverandøren. Fejlene fjernes først, når programsystemet
ændres.
*nl2*
 Den anden type ændringer, der kan være nødvendige, stammer ofte fra
ændringer i firmaet eller omgivelserne. Omlægningen fra OMS til MOMS er en
sådan ændring; som andre eksempler kan nævnes: Kursen for lire er ændret,
så antal lire ikke længere kan være i de felter, der er afsat til dem;
tænderne nummereres anderledes i patienternes journal; sygesikringsordningen
laves om osv., osv. Der er selvfølgelig en flydende overgang mellem de to
kategorier. Hvis firmaets vareudbud vokser op over en vis størrelse er det
så en fejl, at der ikke er afsat plads til så mange varer i varekartoteket?
*nl2*
*lt1,simple/svære*
Omfanget af de ændringer man skal
*lt1,ændringer*
 foretage i programsystemet for at afhjælpe
fejlen eller manglen er meget forskelligt. Som en tommelfingerregel kan man
sige, at ændringer som berører formatet for de enkelte oplysninger i kartotekerne ofte kan være særdeles omfattende og næsten kræve, at man begynder forfra
og laver et nyt system.
*nl2*
Det kan være svært at forstå, hvilke ændringer som simpelt lader sig indføre,
og hvilke som er næsten umulige. Det er ofte helt simpelt at ændre
momsprocenter, antallet af konti i en kontoplan, udseendet af udskrifter,
eller endog at få helt nye rapporter fra de eksisterende oplysninger i
kartotekerne. Men at forlange at få to skærme tilsluttet, så man kan lave
transaktioner fra disse samtidig, kan næsten ikke lade sig gøre i de nuværende
systemer; hvorimod en udvidelse fra to til flere igen er simpelt.
Hvis en person både er kreditor og debitor, og vi ikke ønsker oplysningerne
stående i både kreditor- og debitorkartoteket, ja, så er det næsten også
umuligt.
*nl2*
Man skal også være opmærksom på, at ændringer i anlæggets sammensætning,
f.eks. tilslutningen af en ny linieskriver, kan kræve ændringer af programsystemet.
*nl2*
Letheden, hvormed ændringer kan foretages, afhænger både af hvilken ændring
der er tale om, men også programsystemets kvalitet, og hvordan det er
dokumenteret. Dette behandler vi i næste afsnit.
*nl3*
3.6. Dokumentation.*nl1*
-------------------▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀▶16◀*nl2*
Hvis man kigger ind i en dyr og en billig radio, kan man godt få en fornemmelse
af, hvilken man helst vil reparere. Sådan er det også med programsystemer.
Nogle er det let at foretage ændringer i, mens det er meget svært at gøre det
i andre. De faktorer, som spiller ind her, er dels hvilket sprog programmerne
er skrevet i, dels hvilken stil der er anvendt ved programmeringen, dels hvilket
design der ligger til grund for programsystemet. Programmer i maskinsprog er
ofte uoverskuelige, og der findes ikke mange programmører, der kender sproget;
programmer i højere programmeringssprog er at foretrække. Programmer opdelt
i naturlige dele (moduler) og skrevet i struktureret stil er at foretrække,
se figur 3.9.
*fn1,fig. 3.9:*
*nl2*
Endelig er det afgørende for et programsystems anvendelighed og mulighed for
enkel vedligeholdelse, at der findes en god dokumentation. Der er mindst to
former for dokumentation:
 brugervejledning og teknisk dokumentation
(se fig. 3.10, 3.11, 3.12).
Den første fortæller, hvordan programsystemet skal betjenes, og henvender sig
til den daglige bruger. Det andet er lavet til vedligeholderen. Det vigtigste
er simpelthen en velstruktureret og læselig programtekst med variabelforklaring
og indholdsfortegnelse osv. Desuden skal der være en kortfattet beskrivelse
af designmæssige overvejelser og overordnet "filosofi", fordi systemet helst
skal vedligeholdes i overensstemmelse
med de oprindelige intentioner; ellers bliver det hurtigt
uoverskueligt. Endvidere skal der være lister og oversigter så som
systemdiagrammer, postbeskrivelser, datasammenhænge 
(se fig. 3.11, 3.12).
Det er vigtigt at holde sig for øje, at dokumentationen skal ændres, når
programsystemet skal ændres, og derfor skal dokumentationen være let at ændre.
I modsat fald får man uoverensstemmelser mellem programsystem og dokumentation,
og så er dokumentationen nytteløs.
*fn1,fig. 3.10: brugervejledning.*
*fn1,fig. 3.11: systemdiagram.*
*fn1,fig. 3.12: datasammenhænge.*
*ef*
scope user bog3bproof bog3b
▶EOF◀