Læseren er sikkert fortrolig, og -- hvad der i forbindelse med dette notat er mere relevant -- føler sig rimelig tryg ved at anvende programmel, der betinger elektronisk post og muliggør brev- og rapport-skrivning. Men ville læseren på samme måde vide sig sikker, føle sig tryg, ved at flyve i et passagerfly, eller bo tæt ved et atomkraftværk, der blev delvist styret udfra programmel-forskrifter ? Enhver bygnings-ingeniør, der deltager i `designingen' af en bro, foretager til stadighed matematiske beregninger med henblik på at ``afprøve'' om broen eventuelt styrter sammen. Tilsvarende for ingeniører og deres konstruktions-opgaver indenfor medicinsk elektronik, skibs-, fly- oma. konstruktioner. Og så videre. Men sligt -- matematiske beregninger med henblik på at sikre programmel's korrekthed -- er desværre oftere snarere undtagelsen end reglen indenfor programmel.
Dette notat forsøger introducere læseren til metoder indenfor programmel-udvikling, der leder frem til mindst samme professionelle stade for data-ingeniører, som indenfor andre, mere klassiske ingeniør-discipliner. Det er ikke gjort alene med objekt-orienteret design, UML og strammere discipliner indenfor krav-definition. Der skal en hel ny måde til at anskue programmel på. Et anskuelses-synspunkt, der fokuserer på programmel som matematiskt bestemte -- såvelsom uformelle, dog stringent Dansk- (eller Engelsk-sprogligt) beskrevne -- størrelser. Dog, i dette notat skal vi alene fokusere på den uformelle, men stringente måde, i mange trin af udvikling, at anskue programmel.
Læseren er sikkert bekendt med ibrugtagning og foreløbig drift af sådanne programmel-systemer hvis funktionalitet ``spænder'' over flere ``oktaver'': De forventes tilbyde ikke bare almene funktioner indenfor hvert af flere, tilsyneladende kun løst relaterede funktions-områder, men forventes også at koble disse, oprindeligt set ikke-relaterede, funktions-områder sammen og at tilbyde funktioner der ``går på tværs'' og derved at tilbyde et reelt, begrebs-mæssigt ``løft''.
I dette notat skal vi plædere for en tilgangsvinkel i programmel-udviklingen, der tilgodeser en fordybelse i forståelsen af genstands-området (også kaldet anvendelses-domænet, eller, som oftest, her, blot `domænet'). Vi skal mao. plædere for udvikling af omfattende (både uformelle, dog rigorøst sådanne, såvelsom formelle) beskrivelser af sådanne infra-struktur-komponent-domæner som f.eks. transport-, sundheds-, (E-)handels-, og finans-sektoren.
Læseren er sikkert bekendt med fatalt fejlslagne, t.eks., offentlige programmel-systemer (Vue, Amanda, oa.). I flere tilfælde kan store dele af ``ansvaret'' for ``katastroferne'' føres tilbage til topledelsen i klient-institutionerne: De har simpelthen ikke forstået, at mange programmel-systemer, typisk for infra-struktur-komponenter, kræver dybt-gående og bredt favnende forandringer i den måde hele institutionen i fremtiden, med det nye, omfattende programmel-system, skal ledes og drives på.
Dette notat vil koble forandrings-ledelses-problematikken til problematikken omkring udviklingen af infra-struktur-komponent-domæne-beskrivelser.
Dette dokument blev første gang udleveret Onsdag 14 November 2001. Da blev en første net version installeret:
Idéen til at skrive dette notat opstod i begyndelsen af Oktober 2001. Dels er det en første Dansk-sproget rapport fra min hånd indenfor mit forsknings- og undervisnings-felt; dels er det et første forsøg, på populariserende form, på at henvende sig til en basalt ikke-IT-teknisk gruppe ``beslutnings-tagere'' med henblik på at forklare denne gruppe hvorledes ihvertfald nærværende forfatter anskuer problematikken: At indforskrive, at udvikle og at tage ibrug endog meget store programmel-baserede IT systemer.
Når jeg således ``henvender'' mig er det jo forståeligvis for at bidrage mit til at ændre en situation sådan som jeg ser den.
Og denne situation er at jeg ser dagens indforskrevne informatik-systemer som langt fra gode nok, som langt fra ambitiøse nok, og som slet ikke udnyttende det store potentiale der dog ligger nedlagt i flertallet af de mange professionelle datalog-kandidater de seks datalogiske universitets-institutter i Danmark årligt genererer.
Mao. jeg vil gerne advare mod visse tendenser.
Jeg ser også meget gerne at det offentlige Danmark gav sig i kast med at indforskrive, at udvikle og at tage ibrug langt mere omfattende informatik-systemer, både i omfang og i dybde, systemer med langt større `semantisk' indhold, end jeg i dag ser. Eette medfører langt mere eksperimentel udvikling, herunder forskning, end man idag er vant til. Dette, igen, kræver største åbenhed, og deltagelse af den samlede Danske datalogiske forsknings-verden, i snævert gensidigt arbejde med Danske IT udviklere, IT leverandører, og de offentlige institutioner -- der skal bruge de således eksperimentalt udviklede informatik-systemer.
Nu, hvor der foreligger en første ``komplet'' udgave af dokumentets hoveddel, dvs. undtagen Appendiks B, er det på tide at forsøge formulere en ultra-kort version af hoveddelen. F.eks. i form af en ``power-point''-lignende 30-45 minutters foredrags-lignende præsentation.
Notatet benytter sig af, for mange læsere sikkert, fremmedartede sætnings-konstruktioner, og fremmedartet bogstavering (herunder en systematisk, men udbredt, brug af binde-streger i forbindelse med lange ord) og tegn-sætning.
© Dines Bjørner
Fredsvej 11, 2840 Holte, 2001
Hensigten med dette notat er at meddele en gruppe af ikke-tekniske personer, sådanne som er beskæftigede f.eks. i den offentlige sektor, i ministerier, styrelser, mv., [ -- for at meddele dem -- ] en række nutidige forhold omkring nyere, teknisk-videnskabelige metoder som tilbyder muligheder for at man mere sikkert kan ``tackle'' udvikling af endog meget store programmel (cum IT) systemer, dvs. for at man med større troværdighed kan indforskrive og ibrugtage sådanne systemer.
Sagen er ikke helt så enkel som: ``at programmere'', det kan man bare sådan lære, enten på en teknisk erhvervs-, eller på en teknisk-videnskabelig akademisk uddannelse. Og det på to år, om man tidligere har en Bachelor grad fra et andet dertil ikke relateret område. Derfor er dette notat lidt langt -- og går i detaljer for at vise ``what IT takes to do IT !''. Før man, stort set alene på dette notats grundlag, får en fornemmelse for dette, kan man ikke, mener jeg, troværdigt gennemskue hvilke herlige muligheder, der dog er, for at rekvirere endog meget store, meget komplekse programmel-systemer. Systemer, der kan sikre klart bedre sundheds-sektor service-systemer, klart bedre arbejds-markeds-anvisnings service-systemer, endnu bedre Told & Skat systemer, endnu bedre logistik systemer, klart bedre transport systemer, klart bedre finans-systemer, klart bedre I-handel mmm.
Med afsæt i den senere tids omtalte IT ``skandaler'' (jvf. VUE, Amanda, Told & Skat, mfl. infra-struktur-komponenter) gives først, i Afsnit 3, en afgrænsning af og eksempler på begrebet `infra-struktur'; dernæst i Afsnit 4 berettes om konventionelle måder, såvelsom om en nyere metode, for udvikling af programmel. I Afsnit 5 gennemgås et bestemt trin i udvikling af programmel efter denne nyere metode: Den såkaldte `domæne-beskrivelses-metodik'. Afsnit 6 detaljerer hvorledes man kan bygge videre på domæne-beskrivelser i arbejdet med krav-definitioner og programmel-design (specifikation). Summen af Afsnittene 4--6 peger på programmel-udvikling som en uhyre findelt process, med mange principper, teknikker og værktøj. Virkeligheden idag lever desværre ikke op til den krævende modenhed -- og vi står derfor i den noget tvivlsomme situation at man, i Danmark, arbejder langt mere seriøst i f.eks. skibs- og bro-bygnings-branchen end i programmel-konstruktions-branchen.
Afsnit 7 indsætter de tidligere afsnit i en større sammenhæng -- idet afsnittet samtidig indfører og præciserer begrebet `informatik'. Dette informatik-begreb kontrasteres til det komplementære `IT' begreb. Vigtigheden af at fokusere kraftigere på informatik, end på det komplementære `IT' begreb, understreges.
Afsnit 8 diskuterer domæne ingeniør-arbejdet i relation til ``Business Process [Re-]Engineering''. Vi mener at den klare hovedvægt, der bliver lagt på domæne-beskrivelser dels medfører et afklaret forhold til ``Business Process [Re-]Engineering'', dels medfører at man langt mere systematisk kan ``tackle'' problematikken: `Forandrings-ledelse'. Som bemærket i anbefalinger (til undgåelse af visse negative aspekter ved inførelse af nye, store, infra-struktur-informatik-systemer), er det alt mere bydende nødvendigt at rekvirenter -- de institutioner, der indfører disse systemer, til afløsning af tidligere arbejds-gange -- i langt højere grad end tidligere akcepteret, forbereder sig på de forandringer sådanne, ``om-sig-gribende'' informatik-systemer med usvigelig sikkerhed medfører.
Et appendiks giver eksempler på beskrivelser af infra-struktur-komponenter.
Dette afsnit er formuleret som et ``Executive Summary''.
Det opsummerer:
af
Datalogi er læren og viden om hvilke størrelser der kan eksistere inde i datamaten, og hvorledes de konstrueres: Processer og data. Datalogi, som fag, kan, alt efter datalogi-forskerens eller datalogens indstilling (holdning), opdeles i en lang række fag-discipliner:
Datalogien bygger på matematikken, i særdeleshed:
Og datalogien inddrager, i sit virke, andre matematiske discipliner:
Fag-disciplinerne som er optalt først i Afsnit 1.1 kan enten studeres (udforskes, tilegnes (læres)) udfra en teoretisk vinkel: Hvilke teorier udgør de (hvad er muligt), eller udfra et metode-lære synspunkt. Typisk vil en rimelig moden, akademisk datalogi-uddannelse beskæftige sig med disse to områder i tids-forholdet 50/50%: Lidt mere ingeniør-orienterede uddanelser vil sikkert ændre forholdet fra 50/50% til 40/60% eller endog 30/70%. Men alene at fokusere, 100%, på metode-lære er som at lære at regne uden at forstå den underliggende matematik. Dog, mener jeg, må man med skam melde at forholdet meget ofte er 10/90%-0/100% !
I dette notat skal vi fokusere på sådanne metode-lærer, der bygger meget direkte på et matematisk (dvs. teoretisk) fundament. Mao.: Der findes såkaldte metode-lærer, der ikke bygger på en (eksplicit erkendt) matematisk teori.
Ved en metode forstås her en række principper for udvælgelse og anvendelse, til både analyse og syntese, af teknikker og værktøj således at man, ingeniøren, effektivt kan udvikle et effektivt ``apparat'' (herunder programmel).
Den i dette notat skitserede metode-lære bygger på et matematisk fundament, udspringer fra cirka 30 års forskning og anvendelse i Europa, USA, Canada, Australien, m.fl.
Metode-lære-situationen idag kan bl.a. karakteriseres ved at der fra universiteterne udgår en stadig strøm af forsknings-resultater og kandidater der helst skulle bruges, hhv. bliver ansat i en industri (herunder programmel-huse), der i endog meget stor udstrækning bruger ``andre'' metoder, i særdelsehed sådanne, som ikke bygger på et matematisk fundament, men som er udviklede af een-mands konsulent-firmaer og få andre sådanne (f.eks. er UML ``udviklet'' af det kommercielle firma Rational).
Dette notat anbefaler, forståeligvis, metoder, der, som alle andre ingeniør-grenes metoder (kalkyler), bygger på et teoretisk (for programmel: Matematisk) fundament.
Problemet, sådan som det fremgår indirekte af de to sidste paragraffer i det foregående afsnit (Afsnit 1.2), er evnen til at sikre troværdigt programmel: Sådant som leverer den funktionalitet kunden forventer, som leveres til tid og indenfor oprindeligt budget, og som det er en fornøjelse at bruge, at udvikle, og at vedligeholde. Og meget mere.
Problement er, på troværdig vis, at påvise at programmel er korrekt mht. en lang række kriterier.
Dette notat udgår fra en ``skole'', der vedkender sig at mange former for programmel kan og derfor bør udvikles vha. matematiskt baserede metoder; fra en ``skole'', der objektivt kan påvise at programmel, der er udviklet vha. sådanne metoder, kan sikres en langt større troværdighed; og fra en ``skole'' der idag, efter godt 30 års virke, alt mere synes at ``gribe om sig'', at udbredes, mere-og-mere.
Det er en hoved-tese i dette notat at sådanne troværdige programmel-udviklings-metoder idag muliggør udvikling af endog meget komplekse programmel-systemer til understøttelse af endog meget store infra-struktur-komponenter. Der bruges allerede idag programmel til hjælp i de daglige handlinger i sådanne infra-struktur-komponenter som f.eks. finans-, transport- (inklusive logistik-), sundheds-, handels- (herunder elektronisk handels-), fremstillings- (produktions-), service-, oa. sektorer. Men, påstås det nu, slet ikke (måske med finans-sektoren som en positiv undtagelse) med den konsekvens, dvs. i den udstrækning, som faktisk er muligt.
Mao., pga. ``angst'' for nok en ``EDB-skandale'', og stort set uvidende om hvad der faktisk idag er muligt, dog kun med altfor få programmel-leverandører, undgår ledelsen i potentielle informatik-forbrugende institutioner (og firmaer) at indforskrive sådant programmel -- medens andre firmaer, meget naïvt (institutioner), ``rask væk'' indforskriver programmel uden at sikre sig at dets udvikling er troværdig -- samtidig med at man ikke selv, til fulde, er forberedt.
Der er, mao., tale om et toægget sværd: På den ene side skal leverandøren kunne yde troærdigt programmel, og, på den anden side skal klienten (modtageren) være vel forberedt -- især når det drejer sig om (``store'') programmel-systemer til infra-struktur-komponenter.
Den generelle (meta-) metode, vi her skal plædere for, foreskriver at klient og programmel- (i bredere forstand maskinel- plus programmel-) leverandør sammen sikrer at det leverede system bygger på vel-gennemtænkte krav-definitioner -- hvad der, i og for sig, muligvis ikke er så meget nyt, endsige noget revolutionerende, i -- og (eller snarere: men) at disse krav-definitioner bygger på tilsvarende vel-gennemtænkte beskrivelser af anvendelses-domænet (herefter blot benævnt: `domænet'). Det nye, som dette notat primært ønsker at berette om, er netop domæne-beskrivelses-konceptet. Visse vil påstå at ``det gør vi allerede'', men jeg vil forlange, at en sådan viden om domænet skal være nøje dokumenteret, og det på en sådan vis at domæne-beskrivelsen overhovedet ikke nævner (dvs. inddrager) krav til evt. programmel -- endsige antydninger af hvad dette programmel ``gør'' (for slet ikke at tale om hvorledes det er struktureret).
Notatet går i en vis dybde hermed.
Indførelse, tilstedeværelse, brug, af store programmel-systemer har det med at indvirke på, ja faktisk at forudsætte ofte drastiske ændringer i ledelsen og det daglige, øvrige operationelle beteende af den institution, den virksomhed, hvori programmel-systemet virker.
Det synes som om stort set alle, på nær måske de ``aller-laveste'', ledelses-niveauer ikke forstår dette tilfulde: De reagerer ihvertfald ikke korrekt på problematikken.
Vi vil, i dette notat, påstå, at én, blandt sikkert flere, forudsætninger for fornuftig forandrings-ledelse udgøres netop af det ovenfor omtalte par af dokumenter: Domæne-beskrivelse ``plus'' krav-definition: At med en sådan beskrivelse af hvorledes domænet er idag, og med en definition af hvorledes man ønsker det ``i morgen'', at dér er grundlaget tilstede for omhyggeligt at gennemtænke og at planlægge og siden at gennemføre de nødvendige ledelses og operationelle forandringer firmaet, institutionen, har behov for.
At en sådan forandrings-ledelse går hånd-i-hånd med både udviklingen af firmaet's, institutionen's, domæne-beskrivelse og udviklingen af krav-definition turde være en selvfølge: De to virker ind på hverandre.
Store Danske programmel (og i bredere forstand: IT) systemer lever funktionelt ikke op til forventningerne (dvs. yder ikke de funktioner man troede de ville yde), deres udviklings-omkostninger overskrider oprindelige budgetter, udviser altfor mange såkaldte ikke-funktionelle problemer (fejl, lange reaktions- (``respons'') tider, mm.), og/eller medfører/afslører store tilpasnings-problemer i de organisationer i hvilke de indføres.
I dette notat vil jeg forsøge skitsere én af de (sikkert flere nutidige) måder ved hvis brug man givetvis kunne undgå de værste excesser ved ovenstående problematik.
Appendiks B giver eksempler på beskrivelser af infra-struktur-komponenter.
Ifølge Verdens Banken er termen `infra-struktur' ``en paraply-term for mange former for aktiviteter der, af visse udviklings-økonomer, forstås som ``social overhead capital''. Begrebet infra-struktur omfatter aktiviteter som deler teknologiske og økonomiske egenskaber -- såsom ``economies of scale and `spill-overs' from users to non-users''.'' Winston Churchill citeres for i Underhuset, i 1946, at have sagt: ...Den unge Labour-taler, som vi netop har lyttet til, ønsker klart at imponere sin valgkreds med det faktum at han har gået på Eton og Oxford siden han nu bruger sådanne moderne termer som `infra-struktur' ...
Følgende er eksempler på komponenter i et land's infra-struktur -- nævnt i aldeles tilfældig rækkefølge:tex2html_deferred
Almindelige Danske erhvervsvirksomheder, som f.eks. hoteller, restauranter, detail-forretninger, fremstillings-virksomheder, aviser, reklamebureauer, mmfl., opfatter f.eks. de ovenstående infra-struktur-komponenter som dele af Danmarks infra-struktur. Mere generelt, så synes én bestemt erhvervsgruppe at opfatte ``alt andet, som omslutter det,'' på nær direkte leverandører og kunder, som tilhørende infra-strukturen.
Vi skal anlægge, i vores betragtning af samspillet mellem begreberne infra-struktur og store IT, cum data & kommunikations-systemer, det bredere syn på begrebet infra-struktur: som omfattende, foruden ovenstående, også følgende ``størrelser'':
Vi skal, mao., anlægge et mere teknisk syn, og ser begrebet `infra-strukturer' (det hele, komponenter, under- eller del-komponenter, etc.) som havende til formål at understøtte andre systemer og aktiviteter.tex2html_deferred
Programmel, og i bredere forstand IT, til infra-strukturer er som regel distribueret (hhv. distribuerede), og er i vid udstrækning ``beskæftiget'' med at understøtte kommunikation af mennesker, materialer og information. Derfor er begreber som `åbne systemer' tidmæssig påpasselighed sikkerhed ubestikkelighed og modstands-dygtighedfte meget vigtige ``størrelser''.
Jeg var i årene 1991-1997 FN Direktør. Da opbyggede jeg et Forsknings & `Post-Doctoral' ``Trænings'' Center, UNU/IIST: UN University's International Institute for Software Technology, i Macau. Centret lever i bedste velgående. En vigtig ingrediens i centrets virke var at hjælpe regeringer, universiteter og ledende IT brugere og IT industrier, herunder programmel-huse -- altsammen i udviklings-lande -- ``self-sufficience'' og ``self-reliance'' mht. programmel til infra-strukturer. Dette er dokumenteret i bl.a. UNU/IIST Annual Reports [4,9,10,15,], i mere generelle ``brochurer'' [3,6,7,12,,18], samt i rapporter, der specifikt omhandler infra-struktur emnet: [13,11,43] (sidste reference skal skrives til UNU/IIST's 10 års jubilæum's Symposium, Lissabon, 18-22 Marts 2002).
Ved IT system udvikling forstås planlægning og konstruktion af et samlet system af maskinelg programmel. Vi skal her alene fokusere på den mest styr- & kontrollér-bare af disse to størrelser: Programmellet.
Visse dele af en krav-definition sikres (dvs. ``implementeres'') vha. maskinel og indkøbt programmel. Andre, dvs. stort set tilbageværende, dele programmeres. Dog:
Data-, cum informatik-ingeniøren, har, eller bør, i det mindste have en special-uddannelse indenfor programmering og almen krav-definition. Men vedkommende har, og kan, som regel ikke, som nybagte ingeniører, have en professionel baggrund i ethvert domæne. Men de bør have en general uddannelse indenfor almene principper og teknikker for indkredsning, forståelse og beskrivelse af stort set vilkårlige anvendelses-domæner.
Hermed menes blot: Det kan iblandt være akceptabelt at påbegynde programmel-konstruktions- eller krav-definitions-arbejdet inden krav-definitions-, hhv. domæne-beskrivelses-arbejdet er fuldt afsluttet.tex2html_deferred
Dog menes der også at når programmel-konstruktions-arbejdet er afsluttet da forventes også domæne-beskrivelses- og krav-definitions-arbejdet at være fuldt afsluttet.
Vi analyserer tre facetter, (a), (b) og (c), ved det vi vil forstå som den traditionelle programmel-udvikling.
I traditionel programmel-udvikling kan det nok være at selve programmerings-, dvs. kodnings-fasen tages rimeligt alvorligt: Programmel-huse (software houses, generelt IT + Software leverandører) følger ofte rimeligt velordnede procedurer med henblik på at sikre en rimelig kvalitet -- hvad der så ellers skal forstås herved, set i lyset af hvad vi siden påstår -- herunder tilgængelig og sikker dokumentation af programmel-produktet og dets konstruktion. Programmerings-fasen leder til programmel, der opfylder en lang række tekniske normer: (i) Er korrekte mht. syntaksen af det (formelle) sprog (f.eks. C++ eller Java), som programmerne er skrevne i; (ii) er vel-dokumenterede; (iii) har været underkastet en række afprøvninger, ``tests'', der kan reproducerers; mv.
Men det skorter ofte på samme `stringens' når det kommer til krav-definitioner: Selvom der findes internationale standarder herfor opfylder kommercielle krav-definitioner ikke altid -- for ikke at påstå: Sjældent -- disse ! Situationen skyldes bl.a. at krav-definitioner nødvendigvis ikke kan danne et direkte grundlag for datamaskiners arbejde (``execution'') sådan som programmel gør det. Derfor er der ikke de samme tekniske værktøjer, der -- som program-oversættere (compilers) med samt alle deres mulige kode-analysatorer -- kan delvis afprøve de således, som ofte uformelt, formulerede krav-definitioner. Disse afprøvninger kunne forestilles udført med henblik på f.eks. relativ komplethed, konsistens, mv. Samtidig må det erkendes at den teknisk-videnskabelige viden om hvorledes man kan sikre rimeligt udtømmende krav-definitioner, at denne teknisk-videnskabelige viden, ikke endnu idag er forholdsvis så omfattende som den teknisk-videnskabelige viden om program-kodning.
Og endelig må man nok ret så konsekvent erkende at selv eksisterende, gode krav-definitioner (i) ikke nuancerer mellem hvad der er krav og hvad der er mere eller mindre uforanderlige egenskaber ved anvendelses-domænet, (ii) og dermed også på hvilke antagelser krav-definitionerne bygger.
Mao. dagens programmel afspejler ofte en beklagelig mangel på affinitet til den aktuelle verden i hvilket det skal tjene. Samtidig må det være en internationalt kendt forsker tilladt at ytre den yderligere beklagelse at megen god Dansk forskning, som det selvfølgelig for det meste er tilfældet, ikke endnu er trængt ind de nødvendige steder. Herom mere i Afsnit 9.
Der undervises idag på universiteterne i Nord-europa, i Danmark, og på DTU, i sådanne metoder: Principper, teknikker og værktøj, der, når de anvendes efter deres hensigt, fra systematisk til rigorøst, har vist sig -- og dette er dokumenteret gennem mange års publikationer fra især Europæiske forskere og praktiserende data-ingeniører -- (har vist sig) at medføre klart mindre problematisk programmel: (i) Programmel, der klart bedre leverer de funktioner brugerne og øvrige interessenter ønsker sig; (ii) programmel, der indeholder klart færre fejl; og (iii) programmel, der er udviklet indenfor oprindeligt estimerede budgetter.
Jeg skal i det følgende, i dette afsnit, Afsnit 4.2, og i følgende afsnit, Afsnittene 4.3, 5, og 6, alene beskæftige mig med de metoder, teknikker og værktøj, jeg dels forsker i, dels underviser i, og som mange af vore kandidater har fortrolighed med fra realistiske studie-tids-projekter: Midtvejs-, for- og eksamens-projekter.
Princippet om ``del og hersk'', på Engelsk: ``separation of concerns'' -- et princip der er nødvendigt at følge om man skal kunne beherske ``systemernes'' kompleksitet -- ligger bag opdelingen af programmel-udvikling i faser, disse i afsnit, og disse igen i trin.
Om de bliver udført i streng, eller mindre streng rækkefølge, er -- indtil videre, for denne fremstillings hovedformål, mindre væsentligt. Dog er det væsentlig, mener vi, at når et programmel-system er fuldt udviklet og kan leveres til rekvirenten, at da er al dokumentation vedrørende de tre faser ikke alene fuldt gennemført, men også, på rimelig overbevisende facon, kryds-relateret. Hvad der forstås ved kryds-relateret fremgår af det følgende.
Typisk vil, f.eks., programmel- specifikations-fasen opdeles i f.eks. følgende afsnit: Design af system-, siden programmel-arkitektur; dernæst design, udfra disse, af programmel-komponent-organisation & -struktur; dernæst, typisk, et afsnit i hvilket en mere detaljeret modularisering finder sted; etcetera; afsluttende, hvor det er nødvendigt, i kodning (i et programmerings-sprog som f.eks. Java eller C++).
Afsnittene 5.2 og 5.3 detaljerer væsentlige afsnit indenfor domæne-forståelse, ligesom Afsnit 6 detaljerer væsentlige afsnit indenfor krav-definition, hhv. programmel-specifikation.
Typisk kan sådanne årsager være: Fra en abstrakt specifikation af hvad en programmel-procedure skal producere af resultater til en ``snedig'' algoritme og/eller data-struktur, der aktuelt realiserer en sådan procedure, kan der være indeholdt et ``heureka'', der bedst kan forklares for, forstås af, andre, ved at ``omsætte'' dette ``heureka'' i ét eller flere udviklings-trin. Tilsvarende kan det, i overgange fra egenskabs-orientede domæne-beskrivelser og/eller krav-definitioner til følgende fase, eller afsnit, være formålstjenligt med ét eller flere mellem-trin.
Fælles for alle faser, fælles for alle hovedafsnit indenfor disse faser, og fælles for de ofte flere trin indenfor visse af disse hovedafsnit, er, i de metoder jeg kan anbefale, at de kræver en omhyggelig, påpasselig og gennem-checket udvikling af dokumenter, og at disse faser, afsnit og trin af udvikling relateres nøje (herunder fra systematisk, via rigorøst til matematisk formelt -- det sidste hvor det bedømmes nødvendigt at foretage en sådan, eventuel matematisk bevisbar, relatering).
Typisk omfatter dokumentationen, for hver fase, for hvert afsnit indenfor enhver fase, og for ethvert trin indenfor ethvert afsnit, en buket af komplementerende -- herunder konkordante -- dokumenter:
Informationen er ofte af pragmatisk art.
Den hjælper ikke til at forstå domænet. Den meddeler ikke bestemte krav (eller design), men bringer en kontekst i hvilken relevansen af senere fremførte krav måske bedre kan fornemmes.
Blandt informative dokumenter kan man forestille sig flg.:
De i Appendiks B bragte beskrivelser har for det meste karakter af at være råskitser.
Vi skal have meget mere at sige om ``narratives'' (fortællinger) siden.
Eksempel 4 illusterer en ``stram'' fortælling.
Man kan ikke forvente at kunden, rekvirenten, kan forstå disse ``formler''. Og det skal kunden da ej heller. Derfor Narratives og Terminologi. Det er dem kunden ``skriver under på''.
I Danmark repræsenterer IFAD (Institut for Anvendt Datalogi, Odense) et bedste Dansk eksempel på et seriøst opmands-firma.
Man kan også, istedetfor at tale om dokumenter, som for de tre klasser ovenfor, og disses under-klasser, tale om dokument-dele: Disse er så mere indflettede med hverandre i hvad der kan opfattes som enkelt-dokumenter. Dog bør der klart sondres mellem arten (de tre klasser og de flere under-klasser) af de enkelte dokument-dele.
Eet af de ``nye'' aspekter, ved den her fremførte, og i mange henseender vidt udbredte metode, er således sikringen af at udviklingen både har et uformelt, men præcist, såvelsom et formelt grundlag - og at disse hviler på en ``finkornet'' opfattelse af nødvendig dokumentation -- herunder en tilsvarende finkornet udviklings-process.
Eet andet af de ``nye'' aspekter ved den her fremførte, og i stedse stigende grad anerkendte metode er sikringen af at udviklingen bygger på en klar opfattelse af domænet.
Jeg gentager fra indledende afsnit i Afsnit 4:
Konsekvensen heraf er ``nedlagt'' i flg. Triptych:
Mao.: Hvor der ``før'' var to hoved-faser i det data-ingeniørmæssige arbejde omkring udvikling af programmel (dvs. system), er der nu tre i (det vi nu vil kalde) det informatik-ingeniørmæssige arbejde.
Vi antager i det følgende, at der i alle trin af udvikling, fra fase til fase, kan identificeres et klart kontraktligt forhold: En kontrakt og kontraktens partnere: Leverandør og rekvirent. Førstnævnte er her primært repræsenteret ved informatik-ingeniører.
De kontraktlige forhold ytrer sig, typisk, som følger:
Ved domæne-forståelse forstår vi her [a] tilegnelse af anvendelses-domæne-viden, [b] en analyse af den indhentede information: Klargøring, identifikation og afklaring af domænets begrebs-dannelser, [c] en terminologisering af domænets begreber, [d] en domæne-beskrivelse, og [e] validering (godkendelse) af domæne-terminologi og domæne-beskrivelse.
En således tidligt i programmel-udviklingen etableret terminologi skal hele tiden, i hele programmel-udviklings-processen bruges og vedligeholdes (dvs. opdateres). Brug af eventuelt ændrede termer spores til alle relevante dokumenter og deres brug bør så rimeligvis revideres.
En beskrivelse beskriver noget. En god beskrivelse blander ikke tingene sammen.
Man kan tale om det syntaktiske og om det semantiske i en beskrivelse: Hvorledes manifesterer ``størrelserne'' sig (syntaktisk) og hvad står de egentlig for (hensigt, mål -- i snæver, semantisk, forstand).
Dertil kommer et vigtigt, ikke et beskrivelses-, men et informations-, forklarings-mæssigt forhold: Det pragmatiske. Hvorfor, i bredere forstand, fokuserer vi, i beskrivelserne, på de udvalgte ``størrelser'', hvorfor udelades andre ?
Eventuelle indsigelser medfører, principielt, en total iteration over alle områderne [a-e].
Afsnit 5 går i teknisk detalje.
Med en rimeligt udtømmende domæne-beskrivelse ``bag sig'', kan man nu påbegynde arbejdet med at opstille krav-definitionerne. Igen, som ved opstillingen af en domæne-forståelse, er der tale om et kontraktligt forhold mellem rekvirent og leverandør.
Ved krav-definition, som process, forstår vi her (a) tilegnelse (indhentning, ``hjemtagning'') af krav til ønsket programmel, (b) en analyse af den indhentede information: klargøring, identifikation og afklaring af kravenes eventuelle nye begrebs-dannelser, (c) en terminologisering af disse begreber, (d) en krav-definition (som dokument), og (e) validering (godkendelse) af krav terminologi og krav-definitions dokumentet.
Forholdene (a-e) svarer ``mangt og meget'' til emnerne [a-e] i Afsnit 4.3.2.
Afsnit 6.1 går i teknisk detalje.
Fra krav-definition udvikles programmellet. Vi skal ikke her, men i Afsnit 6.2, komme ind på program-specifikations-metodikker.
Dette afsnit kan, og bør vel, læses før læsning af flere tidligere afsnit -- sådan som det også tidligere er antydet.
Ved en domæne-beskrivelse forstås her en beskrivelse af et praktisk, ikke nødvendigvis IT-relateret, genstands-område. Eksempler herpå kunne være
Disses domæne-beskrivelse, som process, kan foregå uden relation, og som resulterende dokumentation forblive ikke-relateret, til eventuelle ønsker om krav til muligt programmel der kan understøtte, herunder ``erstatte'', funktioner (nuværende arbejds-processer) i domænet. Der henvises til Appendiks B.
En domæne-beskrivelse er således, idéelt set, en beskrivelse af domænet sådan som det er, ikke som det ønskes, og ihvertfald uden referencer til eventuelt ønsket programmel.
Som den første altivitet ved opstillingen af en domæne-beskrivelse, er identifikationen af alle de bruger- og, mere generelt, de interessent-grupper, mennesker, institutioner, mv., der på den ene eller anden måde ``har et ord at skulle have sagt'', og som kan forventes, før eller siden at sige dette eller disse ord !
EKSEMPEL 1
Listen i eksemplet ovenfor er ikke nødvendigvis udtømmende.
Ved opstilling af listen over bruger- og interessent-grupper identificeres yderligere (ved navn og adresse, tlf. nr., mm.) de bestemte personer og institutioner man ønsker -- man måtte ønske -- at inddrage i domæne-beskrivelses-processen og i valideringen af det beskrevne.
Men hvad de enkelte bruger- og interessent-grupper har at meddele nedskrives først senere.
Der er mange måder at ``tackle'' domæne-beskrivelses-processen på, og at opdele, strukturere domæne-beskrivelsen. Vi skal blot antyde én af koordinaterne i sådanne. Vi vil kalde denne koordinat `domæne-facet-koordinaten'
Vi fremhæver blot fem facetter ved domæne-facet-koordinaten:
Vi skal kort karakterisere disse facetter for at læseren derigennem kan fornemme hvad det er der forstås ved en domæne-beskrivelse.
Der er som regel mange basale facetter i ethvert domæne. En egenskab ved et domæne udgør et basalt facet hvis denne egenskab går igen, ``bruges'' i to eller flere af de andre facetter.
EKSEMPEL 2
Andre basale forhold kan beskrives, sikkert (mindst) én for hver bruger- og, mere generelt, interessent-gruppe.
Det er vigtigt at den i Eksempel 2 udarbejdede beskrivelse -- hvis elementer blot blev antydet i eksemplet -- er basalt udtømmende. Dvs., det er nok begrebs-mæssigt abstrakt, men alligevel præcist, tilladende en række ``lige gode'' tilsigtede fortolkninger.
EKSEMPEL 3
Grunden til at man, som i Eksempel 3, ønsker også at beskrive sådanne egenskaber ved domænet som ikke umiddelbart dækker over alment erkendte forhold, er at man før eller siden måtte ønske at inddrage sådanne forhold i fremtidige informatik-systemer. Man kan jo tale om dem, om de så er nok så flygtige -- og de kan være flygtige fordi vi ikke gør os den umage at ``nedskrive'' det, f.eks. fordi vi ikke mener at have en passende, understøttende teknologi til at nedskrive -- optegne, registrere -- disse flygtige forhold.
Mao. vi ser at allerede i den basale domæne-beskrivelse stilles beskriverne, herunder interessent- og bruger-grupperne overfor et valg: At inddrage visse forhold, og at udelade andre forhold fra domæne-beskrivelserne.
Aht. senere eksempler anfører vi et eksempel fra transport-infrastrukturen:
EKSEMPEL 4
Bemærk at vi, i den ovenstående beskrivelse af det basale i et(hvert) jernbane-net, har abstraheret, også i den Dansk-sprogede beskrivelse, fra spor-enheders konkrete topologi: Deres terræn-koordinater, svaj i kurver, stigning, fald, om de går over broer, langs perroner, gennem tuneller. Slige forhold skal der blive rig anledning at beskæftige sig med siden.
De første og de fleste, om ikke alle følgende eksempler vil ikke være udtrykt med den stringens vi virkelig fordrer. Det just overståede jernbane--net eksempel (Eksempel 4)illustrerer den nødvendige stringens. Vi henviser til diskussionen i Afsnit 5.4.
Med understøttende teknologi forstås ikke den informations teknologi (IT) og den deri indeholdte informatik, der som regel er målet for den domæne-forståelse hvoraf domæne-beskrivelsen er et led. Istedet forstås ethvert sådant menneskeligt, eller mekanisk, eller elektronisk, herunder datamat og data-kommunikations udstyr (inkl. fax, telefon, E-post, EDI-FACT, mv.), som allerede i et nuværende domæne understøtter dets funktioner.
EKSEMPEL 5
Vi så i ovenstående eksempel hvorledes en ``understøttende teknologi'' kunne udgøres af et menneske, i én version, af noget mekanisk, i en anden version, osv. I Eksempel 6 skal vi se at fortrykte formularer kan siges at repræsentere en understøttende teknologi.
EKSEMPEL 6
Nok et eksempel:
EKSEMPEL 7
Beskrivelser af understøttende teknologi-aspekter tjener, dels til at komplettere forståelsen af domænet, dels til at sikre at sikre at eventuelle datamatiske ``forbedringer'' (udvidelser, ``erstatninger'') af de teknologiske understøttelser tilpasses disses omgivelser.
Ledelse er defineret i forhold til de, der bliver ledet, og til dem til hvilke lederne rapporterer. En leder udstikker generelle retnings-linjer for sædvanlige arbejds-processer, sådan som de ledede forventes at udføre dem, samt reagerer på henvendelser fra de ledede. De sidste henvendelser rapporterer typisk om sådanne forhold hvor baggrunden for de generelle retnings-linjer for sædvanlige arbejds-processer ikke er tilstede. Mao.: Ledere dikterer (``direkterer'') normal-forhold ``nedad'' i firma-``pyramiden'', hvor de ledede rapporterer unormale forhold ``op ad'' i samme pyramide. Veje for `direktion', henholdsvis `rapportering', fastlægges ved organisations-strukturen. Eksempler på sådanne er f.eks. de hierarkiske og matrix-strukturerne.
En beskrivelse af et domænes ledelses- & organisations-struktur har til formål at sikre, dels domæne-forståelsen, dels at eventuelle krav til understøttelsen af ledelses-, hhv. tilbage-rapporterings-processen, formuleres med reel affinitet til virkeligheden.
EKSEMPEL 8
I domænet er alt muligt -- som vi skal se i Afsnit 5.3.5. Enhver ledelses- & organisations-mæssig struktur kan omgås. Derfor skal man i første omgang ikke, i domæne-beskrivelserne, fastlægge altfor ``stramme'' bekrivelser af ledelses- & organisations-strukturen. Dog skal det være muligt at beskrive visse leder/arbejder-interaktioner som værende ønskelige, andre som værende uhensigtsmæssige, etc. Det bliver mao. først, når man skal beskrive krav til en datamatiseret understøttelse af leder/arbejder-interaktioner, at man kan pålægge at systemet detekterer og så vidt muligt sikrer `korrekt' brug af ledelses- & organisations-strukturen.
De basale (m.fl.) egenskaber ved et domæne danner grundlaget for menneskelig aktivitet. Men disses basale egenskaber, de understøttende teknologier, den ``herskende'' ledelses- & organisations-struktur er, set i isolation, ikke tilstrækkelige til -- blot nødvendige for -- at sikre en forventet, korrekt (hensigtsmæssig) ``opførsel'' af systemet, herunder dets stab, brugere, kunder. Hertil tjener almene og disciplinære forskrifter: Regler og regulativer: Love, ministerielle cirkulærer, styrelses-forordninger, kontor-procedurer, mmm., -- og tilsvarende for ikke-offentlige institutioner: Private virksomheder. Alle har de behov for at udtrykke regler for hvorledes ``man'' forventer at systemet skal ``opføre'' sig.
Almene forskrifter (``rules'') angiver hvorledes man ønsker at systemet skal fungere. Retlige forskrifter (``regulations'') angiver disciplinære forholdsregler som ``systemet'' har tænkt sig at iværksætte om ikke de almene forskrifter følges efter hensigten.
EKSEMPEL 9
EKSEMPEL 10
EKSEMPEL 11
Man kan beskrive disse forskrifter, men man kan, i domænet, ikke sikre sig at det opfylder dem. Mao., man kan tale herom, man kan tale om at detektere brud på regler, og man kan tale om eventuel `disciplinering' heraf. Men det er først ved opstilling af krav-definitionerne at man kan beslutte sig for eventuelt at ``gøre noget ved sagen !'' vha. datamatisering !
Forskrifter eller ej, ledelses- & organisations-struktur eller ej, mennesker og understøttende teknologi kan fejle. Nogle mennesker forsøger til stadighed at udføre deres arbejde efter bedste vilje: Korrekt, omhyggeligt, ``med rette omhu'', og blandt disse er der folk der altid undgår fejltagelser. Andre mennesker er mindre agtsomme, nogle direkte sløsede i udførelsen af deres daglige arbejde. Og atter andre mennesker er direkte kriminelle: Snyder og bedrager.
EKSEMPEL 12
I enhver fyldestgørende beskrivelse af et domæne er det bydende nødvendigt at beskrive alle tænkelig fejl og misbrugs-situationer.
EKSEMPEL 13
Så selvom man udmærket godt véd, hvad de korrekte tilstande af systemet er, må man i beskrivelser tage højde for snart sagt enhver mulig fejl-tilstand. Uden at gøre dette, systematisk og (``kedsommeligt'') udtømmende, kan man ikke, siden, gøre sig forhåbninger om at opstille et konsistent og relativt komplet sæt krav-definitioner til et ``fejl-detekterende'' system.
Hvad der ovenfor blev sagt om mennesker's opførsel (``behaviour'') gælder, inter alia, også for understøttende teknologi: Før eller siden vil maskinelt, mekaniskt, elektriskt, og elektroniskt udstyr fejle.
En række spørgsmål melder sig:
Flere end man sædvanligvis tager hensyn til; flere end man normalt adspørger.
I beskrivelsen af én interessent- eller, mere specifikt, én bruger-gruppe, kommer man ofte over interaktions-grænseflader mellem dem (og det) man har valgt at beskrive, og forhold omkring interessent- eller bruger-grupper som man har udeladt. Sker det, er det på tide at overveje om man også burde tage disse sidste i betragtning.
Svaret beror på hvilket formål beskrivelsen skal tjene. Hvis formålet er opstilling af nødvendige og tilstrækkelige krav, ja så vides det egentligt først, om en herfor tilgrund-liggende domæne-beskrivelse er ``komplet'', når man mener at krav-definitionen har berørt alle relevante aspekter. Mao.: Kombinationen af domæne-beskrivelses og krav-definitions processerne itererer ``hen imod'' en situation hvor man mener at ``nu er alt beskrevet'' !
Der henvises til bemærkning Side , lige før Afsnit 5.3.2.
Svaret her er enkelt, en uformel beskrivelse skal mindst være så præcis, jvf. jernbane-net eksemplet, Eksempel 4, at man alene på dens grundlag kan opstille en matematisk model, dvs. en formel beskrivelse der kan siges at dække ``det samme'' som den uformelle beskrivelse.
Vi skal ikke vise udtømmende eksempler på sådanne formelle beskrivelser. Istedet henvises til en lang række offentliggjorte artikler, en længere række rapporter, og en rimelig stor samling studenter-projekt-rapporter. Rerencer hertil gives siden.
For hver af de ovenfor omtalte facetter findes der specifikke formelle teknikker ved hvis hjælp man hjælpes til effektivt formelt at modellere de uformelt beskrevne forhold. Ja: Man kan mao. beskrive domænets ``ubeslutsomhed'', dets internt og eksternt bestemte ikke-determinisme (``skal jeg nu gøre det eller det eller ... eller det'', hhv. ``stillet overfor flere muligheder for næste aktion, hvorledes udtrykke den tilfældige aktion der vælges, selekteres ?'').
Jeg har, mao., valgt, i de fleste eksempler, blot at antyde uformelle beskrivelser. At bringe helt realistiske eksempler -- når citerede dokumenter udmærket illusterer sådanne -- vil være urealistisk i nærværnede notat's sammenhæng. De ville simpelthen fylde for meget.
Mange andre forhold vedrørende domæne-beskrivelser kan anføres. Vi vil slutte af med:
Fysikerne, siden Nikolaj Kopernikus', Isaac Newton's, etc.'s dage, har beskrevet de mekanisk-fysiske, specielt de planetær-mekaniske forhold (celestial mechanics), og har på grundlag af disse beskrivelser skabt teorier, formuleret i den af disse fysikere (og siden af andre) skabte matematik. Det var deres primære hensigt Disse og mange fysikere siden dem, har ikke haft andet behov end at forstå. De har ikke alle haft det ønske også ingeniørmæssigt at kunne udnytte eventuelt opdagede lovmæssigheder. Således har vi idag altruistiske teorier indenfor elektro-fysik, atom-fysik, kemi, biologi, mmm.
Og sligt kunne vi også forholde os. For at uddanne folk indenfor sundheds-sektoren, finans-verdenen, transport-væsenet, mmm., kunne det dog være rart med stramme, konsistente, og relativt komplette beskrivelser -- også gerne sådanne ved hvis hjælp man bedre, intuitivt kan forstå en matematisk teori, sådan som f.eks. gymnasiaster lærer at forklare, forudsige mekaniske forhold's opførsel vha. den simple Newton'ske fysik.
Så vi kunne stoppe her. Ved domæne-beskrivelser -- for hvert område. Og vi bør vel engagere os i et stort anlagt 50-100 års projekt, der kunne have som mål at opstille omfattende teori-dannelser for bl.a. de infra-struktur-komponenter der er omtalt tidligere i dette notat.i skal vende tilbage hertil i Afsnit 7.
Men vi vil mere end det. Hvad dette er omtales i Afsnit 6.
Hvem skal udforske sådanne infra-struktur-teorier ? Vort svar er: Det for øjeblikket mest rimelige udgangspunkt for en sådan infra-struktur-forskning synes at ligge i datalogien i bredere forstand. Det er i, eller fra datalogien vi finder, hhv. kan hente de metoder: Principper, teknikker og værktøj der idag er bedst egnede til sådanne studier. Det er i den datalogiske forskning at de nutidige studier heri finder sted. Som bredere beskrevet i Afsnit 6, tilkommer klart metoder fra matematikken, fra det vi ville kalde den anvendte matematik. Men alene den, den anvendte matematik, er idag ikke nok: Den klassiske matematik kan ikke beskrive de forhold -- såsom `samtidighed', `typer', oma. -- sådan som den nutidige datalogi kan det.
I takt med at samarbejdet med de akademiske discipliner, der tradtionelt ``ligger nærmest'' det enkelte, udforskede genstands-område udbygges -- den medicinske videnskab mhp. studier af sundshedssektoren, osv. -- i samme eller stigende takt, kan denne genstands-område-videnskab ``selv'' overtage hoved-arbejdet.
Ligesom den anvendte matematik ikke kun dyrkes på akademiske, universitets-institutter af sligt navn, men også, f.eks. i de fleste ingeniør-teknisk/videnskabelige institutter: Vandbygning (Hydraulik), Bærende Konstruktioner, Aeronautics, Elektro-magnetisk Feltteori, mmfl., på samme måde kan man forestille sig at forsknings-institutter indenfor sådanne genstands-områder som Trafik & Transport, Byggeri, Produktion, Økonomi, Handels-``videnskab'', oma., ``overtog'' deres del af infra-struktur-forskningen.
At opstille domæne-beskrivelser kan retfærdiggøres alene udfra ønsket om ``til fulde'' at forstå domænet, eventuelt herunder, som videnskabs-person at ville udvikle en teori for domænet. Men man kan, som vi skal komme ind på i Afsnit 8, også ønske at bruge domæne-analyse- og beskrivelses-arbejdet som grundlag for en institution's, et firma's, ``business process (re-)engineering''.
Endelig er der en tredie grund til at engagere sig i det ofte omfattende arbejde med at opstille en domæne-beskrivelse, nemlig som grundlag for krav-definitions-arbejdet -- henimod udvikling, installation og brug af et større programmel-system. Dette sidste vil vi beskæftige os med i dette afsnit.
Hvor en domæne-beskrivelse alene beskriver domænet, infra-struktur-komponenten (``institutionen'', firmaet, o.lign.) -- uden at nævne, overhovedet, krav til eventuelt programmel -- mao.: Hvor domæne-beskrivelsen alene beskriver ``verden som den er'', tjener en krav-definition til at beskrive ``verden som man ønsker den'' (efter udvikling og installation af ønsket, dvs. krav-defineret, programmel). En krav-definition fastlægger, mao., hvad det er man forventer af det ønskede programmel (ikke hvorledes det skal implementeres).
Ved `maskine' forstår vi ``summen'' af det maskinel og programmel, der skal til for at løse en krav-definition, dvs.: Maskinen er det brugeren ``ser''.tex2html_deferred
Vi opdeler en(hver) krav-definition i tre dele:
I det flg. skal vi nærmere præcisere ovenstående sikkert lidt for abstrakte formuleringer.
Domæne-beskrivelser har identificeret en lang række forhold i deres genstands-område: Basale, teknologi-understøttende, ledelse- & organisation, almene (retledende) og legale (disciplinære) regler mv., menneskelig opførsel, oa.
Indførelse af datamatik skyldes ønsket om at understøtte, eventuelt at automatisere, visse af disse forhold. Disse ønsker kan være begrundet, f.eks., i en kombination af ét eller flere flg. ``meta-krav'':
Vi har listet ovenstående ``trivialitet'', dels for at introducere det pragmatiske ``meta-krav'' begreb, dels for at begrunde begrebet domæne-krav.
Vi skal, i Afsnit 6.1.5, fundere nærmere over begrebet meta-krav.
Vi skal i de flg. mange afsnit give eksempler herpå.
Der er en række domæne-krav-definitions-teknikker under hvis brug man mere systematisk kan komme frem til domæne-kravene. Disse inkluderer:
I det flg. skal vi se nærmere på disse teknikker.
Specifikt startes der ud med en præcis afgrænsning af hvem der er at betragte som brugere, og hvem der er at betragte som interessenter iøvrigt.
EKSEMPEL 14
`Projektion', som princip og som teknik, med baggrund i de stringente metoder for domæne-beskrivelse, hvad enten de er uformelle eller formelle -- men som ikke kan vises i dette notat -- præciseres vha. af en række anvisninger, uformelle såvelsom formelle.
Hvor det basale i et domæne måtte tillade mange forskellige manifestationer af et fænomen kan det tænkes at krav reducerer disse til nogle få, f.eks. netop én. Hvor den understøttende teknologi tilsvarende måtte tillade mange forskellige manifestationer kan tilsvarende reduktion tænkes. Hvis der stilles krav til understøttelse af ledelses- & organisations-funktioner, som måske ``før'', i domæne-beskrivelsen, var løst skitserede, og/eller tillod mange mindre formaliserede interaktioner mellem ledere og de ledede, kan man forestille sig en ``stramning'' til at bestemte daglige, rutine-mæssige ledelses-forhold underlettes vha. præcise spille-regler som maskinen da skal overvåge (monitor) om de finder sted, og i givet fald, gennem styring (control), sikrer at de finder sted. Vejledende og disciplinære forskrifter (regler) er klart et område hvor datamatisering kan understøtte, subsidiært automatisere -- bl.a. gennem indføring af ét eller flere domæne-specifikke ``regel- & rutine-skripts'' (sprog). Og endelig udgør menneskelig opførsel, specifikt vores mere eller mindre manglende, stadige/ustadige evne til regel-ret at følge intentioner, forskrifter, et område hvor krav til lettelse, kontrol (overvågning) og styring vha. datamaten, kan sikre smidigere afvikling af typisk monotone, og/eller fejl-typiske, og/eller sikkerheds-kritiske arbejds-opgaver.
I Eksempel 15 skal vi alene set på et simpelt, oplagt krav-emne.
EKSEMPEL 15
En problem-beskrivelse består af flg. ``arkivalier'': Annamnese, analyser, diagnostik, behandlings-plan (medikation, operativt indgreb, mv.), observationer (i forb. med behandlings-planens gennemførelse [eller manglende sådanne]), ...samt andre ``arkivalier''. Herefter flgr. nærmere beskrivelser af arten, formen, indholdet af og de aktioner der kan udføres af det sundheds-faglige personale på de forskellige former for ``arkivalier'', hvem disse måtte tilflyde, mmm.
Enhver problem-del's problem-beskrivelse (hvad enten denne direkte tilhører et ``øverste'' hoved-problem, eller tilhører et deraf ``afledet'' under-problem) kan betragtes som knyttet til en tilsvarende, ``fritstående'' process. Denne process svarer til at en række sundheds-faglige personer varetager denne problem-del, og dermed at eventuelt andre, derfra forskellige, men gerne overlappende grupper af sundheds-faglige personer varetager hver sin under-problem-del.
En EPJ skal således tillade ikke-delt, dvs. samtidig læse-tilgang til hele EPJ'en, men med egen, beskyttet, skrive-, dvs. opdaterings-tilgang til den bestemte under-del. Overordnet kan der udføres flg. aktioner på en EPJ: (1) Oprettelse af en hel ny EPJ, (2) erstatning af én hoved-problem-del med en ny (evt. en modifikation af en tidligere erstattet, og dermed ``hobet'') problem-del, (3) oprettelse af en (ny, frisk) under-problem-del (som derfor, til en begyndelse, hverken vil have under-problemer eller ``erstatninger''), osv. Ved erstatning ``fryses'' et billede af hele EPJ'en, og dette samt en angivelse af hvor i denne EPJ ``man kom fra'', dvs. en ``identifikation'' af rette plads i hierarkiet af eventuelle under-problemer, udgør del (v): Den komponent i en problem-del, der repræsenterer en forkastet, dvs. ``tidligere'' problem-del.
Og meget mere. Ovenstående EPJ beskrivelse er sikkert altfor stram til at mange kan forstå den. Beskrivelse skal derfor understøttes vha. abstrakte, generiske, såvelsom konkrete, ``øjebliks-billed''-tegninger, diagrammer, mv.
[SLUT PÅ EKSEMPEL 15]
`Instantiering', som princip og som teknik, med baggrund i de stringente metoder for domæne-beskrivelse, hvad enten de er uformelle eller formelle -- men som ikke kan vises i dette notat -- præciseres vha. af en række anvisninger, uformelle såvelsom formelle.
De faciliteter, der således repræsenterer en `udvidelse' i forhold til domænet, var typisk ikke mulige i domænet. Der kan væ forskellige grunder hertil. (1) Enten (for de tilfælde hvor de repræsenterer funktioner), fordi det ikke var menneskeligt eller på anden vis (mekaniskt) muligt at beregne (det ville tage for lang tid, år, for et menneske at beregne). (2) Eller (for de tilfælde de repræsenterer søgning i endog meget store informantions-mængder), det er fordi sådanne mængder ikke er menneskeligt overskuelige. (3) Eller (for de tilfælde de repræsenterer visualisering, typisk af multi-variabel information [dvs. information med mange, 10-20 dimensioner]), det er fordi det ikke er menneskeligt muligt at ``skrue'' på 10-20 indstillinger ``samtidigt''.
EKSEMPEL 16
Problemet med Eksempel 16 er, at det faktisk, i realiteten, er et polynomisk ``svært'' problem: At den ønskede beregning -- om der f.eks. yderligere bedes om hurtigste vej med færrest skift mellem befordrings-midler således at rejse-strækninger kortere end 6 timer altid ligger i dagtimerne 8 morgen til 20 aften -- at beregnings-tiden for dette problem vil vokse så kraftigt at man i realiteten ofte nøjes med sådanne rejseruter der ligger indenfor en bred ``avenue'' omkring den direkte, sfærisk korteste vej mellem a og b.
Det næste eksempel (Eksempel 17) ``snerter'' i samme retning.
EKSEMPEL 17
`Udvidelse', som princip og som teknik, med baggrund i de stringente metoder for domæne-beskrivelse, hvad enten de er uformelle eller formelle -- men som ikke kan vises i dette notat -- præciseres vha. af en række anvisninger, uformelle såvelsom formelle.
Der er mao. tale om to tilsyneladende forskellige klasser af funktioner: De der oprindeligt initialiserer tilstande, og der der ``vedligeholder'' dem, ``opdaterer'' dem i takt med ændringer i deres ``modpart ude i domænet'' !
EKSEMPEL 18
`Initialisering', som princip og som teknik, med baggrund i de stringente metoder for domæne-beskrivelse, hvad enten de er uformelle eller formelle -- men som ikke kan vises i dette notat -- præciseres vha. af en række anvisninger, uformelle såvelsom formelle.
Ovenfor er blot fremdraget fire hoved-teknikker for en systematiseret afledning, under interaktion med projicerede interesse-grupper, af domæne-krav. Andre ``aflednings''-teknikker kan identificeres.
EKSEMPEL 19
EKSEMPEL 20
Det generelle EPJ vindue består af et unikt vindues-navn, en basis tekst, én eller flere éntydigt navngivne ikoner, som enten er simple ikoner, eller vindues-ikoner, eller ``rullegardiner'', og nul, én eller flere éntydigt navngivne tabeller. En simpel ikon består af et ikon-navn og en ikon-værdi. (Ikon-navnet er unikt indenfor et bestemt vindue.) Et vindues-ikon består af et vindues-ikon-navn og en vindues-ikon-værdi, som er et generelt EPJ vindue. Et rullegardin består, i sin grund-status, af et enkelt rullegardin-ikon, som så består af et rullegardin-navn og en rullegardin-værdi. En tabel består af et tabel-navn (der er unikt indenfor et vindue), en tekst, og to eller flere felter. Et felt består af et feltnavn der er unikt indenfor tabellen, en felt-tekst, og en felt-værdi. En felt-værdi kan enten være ``tom'', dvs. uudfyldt, eller (kan blive udfyldt med) en felt-værdi. En ikon-værdi er enten ``slukket'' eller ``tændt'' (``off'' eller ``on'', ikke-``klikket'' eller ``klikket''). Ikon-navnet skal, af vindues-designere vælges således at det antyder denne's to-værdi status. Eksempler kunne være: han/hun-køn, eller ambulant/indlagt. Når ikonen er ``slukket'' er ikon-navnet illumineret med sin ``default'', som designeren bestemmer. [1] en vindues-ikon-værdi er i den ikke-``klikkede'' tilstand det ikke-illuminerede vindues-ikon-navn. I den ``klikkede'' tilstand ændres status (værdi) til at åbne et nyt vindue (mao. rekursion) med samme navn som vindues-ikon-navnet. Et rullegardin-ikon-værdi er -- i den ikke-``klikkede'' tilstand -- det ikke-illuminerede rullegardin-ikon-navn. I den ``klikkede'' tilstand ændres status til at vise en liste: ``rullegardinet''. Denne liste ``fjernes'' ved et dobbelt-klik på rullegardin-ikonet. Listens elementer er enten simple-ikoner, eller vindues-ikoner, eller er yderligere rullegardin-ikoner. Disse kan klikkes som øvrige ikoner.
Vindues-designeren starter med en ``tom'' vindues-design skabelon. Denne er indrammet med meta-ikoner, én for hver type (ikke meta-) ikon og for tabeller og for disses felter. Ved at klikke disse meta-ikoner ``åbnes'' en grafisk størrelse af den benævnte art. Denne kan flyttes til en ønsket, eller en temporær vindues-position. Designeren skal nu navngive den, forsyne den med tekst, og kan nu vælge, før eller siden, at videre definere den (som for ikke-simple ikoner). Designeren kan om-placere (``flytte'') ikoner, tabeller, rullegardin lister, felter, eller ikon-åbnede vinduer ved at flytte disse. Designeren kan forsyne et felt med en type angivelse: Tekst, heltal, naturligt tal, rationelt tal, oa. Bemærk at en rullegardin-listes elementer kan være ikoner og tabeller af forskellig art. I det ovenstående har vi overhovedet ikke nævnt de hermed konstruerede vinduers relation til EPJ'er ! Det kommer nu. Alle navne, al tekst og de feltværdier med hvilke brugeren kan udfylde tabeller skal være udvalgt fra en liste af sådanne navne og felt-værdi-typer som er designet mere generelt, f.eks. ved dels at være en del af et lands' sundhedsfaglige vokabular, og dels at være separat krav-definerederede. Hermed ``forbindes'' de pågældende ikoners og felters status direkte til størrelser, dvs. variable, i de programmel-procedurer til hvilket et vindue siden knyttes. Dette sidste anvises siden. ... [SLUT PÅ EKSEMPEL 20]
Eksempel 20 (netop afsluttet ovenfor) illustrerer, gennem sin både uformelle og formelle fremstilling -- vil vi gerne fremhæve -- nytten af den formelle del: Det blir' li'som ``nemmere'' at sikre det vi kalder reference-mæssig gennemskuelighed, her illustreret ved at ``ethvert sted en ikon kan forekomme kan enhver sådan type ikon-værdi forekomme''.
EKSEMPEL 21
Tilsvarende maskinel kan tænkes i forbindelse med medicinering oma.
EKSEMPEL 22
EKSEMPEL 23
EKSEMPEL 24
EKSEMPEL 25
EKSEMPEL 26
Et krav er et maskin-krav hvis det alene omhandler forhold omkring den programmelle og/eller maskinelle realisering af domæne- og/eller grænseflade-krav.tex2html_deferred
Vi kan identificere flg. kategorier og under-kategorier af maskin-krav:
Både domæne- og grænseflade-krav kategorierne var mindre nuancerede. Kategoriseringerne dér er nyere og repræsenterer nyere indsigt. Maskin-kravs nuanceringen er, i den henseende, bedre etableret.
EKSEMPEL 27
EKSEMPEL 28
Ved lagerforbrug forstås der her den samlede mængde lagerplads som sådan (eventuelt, ie. konceptuelt, fler-kopieret) information optager.
EKSEMPEL 29
EKSEMPEL 30
Man bemærker den stedse stigende ``vaghed'' i ovenstående maskin-krav-definitioner.
De to første begreber: Pålidelighed og fejl-tolerance hører, som vi skal se, tildels sammen.
EKSEMPEL 31
Pålideligheds-problematikken er en kompliceret størrelse: Der er et stort spektrum af kilder til upålidelighed. Det er både en kunst, et håndværk, en disciplin, en logik, og en videnskab at kunne mestre et sligt spektrum.
Her antages pålidelighed f.eks. (typisk) udtrykt i form af middel-tid mellem fejl. Når fejlen så indtræder antages det da at denne, eller disse, fejl detekteres hvorefter en fejl-rettende funktion træder i kraft for at sikre at systemet stadig ``fungerer'', omend, for visse typer fejl, med eventuel nedsat ydeevne (mere begrænsede afhængigheds-mål).
EKSEMPEL 32
Fejl-sikkerheds-problematikken er en kompliceret størrelse: Det kæmpe store spektrum af kilder til upålidelighed og de mange mere eller mindre ad-hoc'e, mere eller mindre systematiske måder man sikre sig imod fejl, betinger dette. Det er således både en kunst, et håndværk, en disciplin, en logik, og en videnskab at kunne mestre et sligt spektrum.
En ``nærværenheds''-krav-definition kan således formuleres i form af det antal timer per døgn systemet skal være ``tilstede''. Bemærk sondringen mellem pålidelighed og nær- dvs. tilstede-værenhed: Sidst nævnte skal gælde per døgn, før nævnte skal gælde akkumuleret over alle døgn for de tidsperioder hvor systemer skal være nærværende.
EKSEMPEL 33
Dog kan man specificere grænser for akceptabel degradering af systemets ``svartider'' mv. i tilfælde af at særlige funktioner udføres. I denne karakteristik ligger også at den funktion, der eventuelt kan afholde andre brugere fra rimeligt stadigt at benytte systemet, kan være den at systemet ``overbelastes''.
EKSEMPEL 34
Et system siges nu at være totalt sikkert hvis ikke-autoriserede brugere, under ``forsøg'' på at tilgå ikke-autoriserede dele af systemet, (i) ikke kan finde ud af hvad systemet tilbyder af funktionalitet mv., (ii) ikke kan finde ud af hvorledes systemet iøvrigt ``virker'' (hvorledes det er implementeret, kodet), og (iii) endelig ikke véd om han véd !
Mao.: Systemet skal ``fingere'' en vis troværdighed, skal ``lade som om'', osv., men alligevel ej !
Som definition er den OK; som grundlag for kriterier for afprøvning om et system er mere eller mindre sikkert, et det OK; men giver i realiteten ingen retningslinier for implementering. Det er desuden tvivlsomt om man kan implementere totalt sikre systemer. Men som ``rettesnor'' kan ovenstående ``idealiserede'' karakteristik være nyttig. Bemærk forskellen (dvs. sondringen) mellem tilgængelighed og sikkerhed.
EKSEMPEL 35
Der er mao. indført et begreb: ``en log-bog''. Under brug af programmel-systemet skal eksekvering af en række ``nøgle''-procedurer føre til optegnelser i denne log-bog. Disse ``nøgle''-procedurer og disse ``log-optegnelser'' skal da være af en sådan art, at de berører, hhv. udsiger noget om, sådanne system-opførsler, der så igen, afhængigt af ``log-optegnelsernes'' værdi (de specifikke data som bliver optegnet), indikerer god eller dårlig system-opførsel, forventede eller ikke forventede system-reaktioner (indikatorer såsom: svartiders længde, lager-forbrug, kø-længde for access til visse serielt brugbare ressourcer, resultat af ``på skrømt'' udførte procedurer -- hvor disse resultater kendes på forhånd -- men hvor ``afvigende'' resultater kan forventes som følge af mulige system-problemer, etc.). Antagelsen er nu at man kan identificere sådanne ``nøgle''-procedurer og sådanne tilhørende indikatorer at deres regelmæssige overvågning kan hjælpe med til, ``før ulykken sker'', at forudsige mulige fejl.
Forebyggende vedligehold kendes, typisk fra maskinel, hvis opførsel kan ændres som følge af materiel ``nedslidning''. Programmel ``nedslides'' ikke. Men, typisk aht. forbedrende vedlighold kan man måle hvorledes system-belastning (``brug'') muligvis måtte indvirke på svar-tider, lager-forbrug, mv. Det er en kunst og et håndværk at identificere og at instrumentere passende log-bog procedurer etcetera !
Man kan tale om tre former for platforme:
For visse systemer, typisk alment kommercielle, såsom MS Word, kan der være sammenfald mellem de tre platforme. For andre systemer, som f.eks. programmel til satellitter, kan de tre platforme være tre vidt forskellige: Til eksempel et Sun arbejds-stations-baseret Linux system, den rum-baserede mikro-datamat, hhv. de i f.eks. i Houston, Texas, baserede satellit-sporende datamater.
Et generelt platforms-krav, der i en vis forstand også (dvs. istedet) kunne rubriceres under ``anden ind/ud-datering'', nævnes før de tre specikke system-platfome.
EKSEMPEL 36
EKSEMPEL 37
Eksempler på genstands-område omfatter bl.a. de nedenfor beskrevne.
EKSEMPEL 38
EKSEMPEL 39
EKSEMPEL 40
EKSEMPEL 41
I hele dette afsnit vedr. krav skal vi primært berøre sådanne krav som klienten direkte måtte ønske at fremsætte. Derudover kan komme krav der mere er udsprunget af udviklernes ønsker, eller som er ``anden ordens, afledede'' krav. Vedligeholds-krav kunne siges eventuelt at medføre krav om modularitet, og korrektheds-krav kunne siges eventuelt at medføre krav om afprøvning (``test'').
Standard eksemplet på et meta-krav er forventningen om at systemet er lyde- og fejlfrit: At det opfylder krav-definitionen og at det passer ind i domænet. Dette krav burde egentligt være så selvfølgeligt at det ``bare'' kan antages. Men virkeligheden er desværre den at man kan stille mærkværdige afhængigheds-krav som at der højst må væren én fejl per 10.000 linjers kode (!), eller der højst optræder én fejl per 12.000 person-timers brug !
Klienter indforskriver programmel ofte som et led i deres ønske om bedre lønsomhed for deres firma. At udtrykke, som et krav til det ønskede programmel, at det skal gøre firmaet mere lønsomt betragter vi her som et meta-krav. Det er ikke et krav der direkte kan omsættes til programmel-specifikation (design). Det er ``for luftigt'', for generelt. Det har intet med de dele af domænet som vi normalt kan beskrive. Det er et grundlæggende problem: At udtrykke de forhold hvori, hvorpå et firma's lønsomhed består, hhv. beror. Vi har i begyndelsen af Afsnit 6.1.1 listet nogle af de meta-krav der sædvanligvis formuleres.
Vi kan ikke, idag, præcist indkredse alle aspekter ved meta-kravs-begrebet, men gør her opmærksom på at klienter ofte blander de to forhold sammen: Intentionelt opfyldelige domæne-krav med kun meget indirekte opfyldelige meta-krav.
Meta-krav er mao. krav, der dels antager en beskrivelse af domænet der som regel ikke foreligger, og dels antager at emnet (de refererer til) er beregneligt.
Vi gentager, i forkortet udgave, de meta-krav der er anført i Afsnit 6.1.1, samt kommenterer disse:
Det er et meta-krav om man definerer produktvitets-forøgelse, f.eks. i form af afviklede kunde-transaktioner per sags-behandler.
Her slutter vi vores lange krav-definitions Odyssé. Meget mere kunne siges. Det som er sagt (skrevet) illustrerer til fulde kompleksiteten af krav-definitions-processen og dens resultater.
Der findes nu en lang række metoder, principper, teknikker og tildels værktøj, der assisterer i den videre udvikling, fra krav-definitioner via programmel-specifikationer til kode.
Vi skal blot illustrere nogle nutidige begreber: Arkitektur, Program Organisation & Struktur, Modularitet, Objekter, UML og OMG.
Mht. sondringen mellem Arkitektur og Program Organisation & Struktur blot dette. For typisk sikkerheds-ukritiske, dvs. typisk sædvanlige administrative EDB systemer ``tackler'' udvikleren først arkitektur-aspektet, siden organisations- & struktur-aspektet. For kritisk fejl-tolererende systemer ``tackler'' man ofte disse to i omvendt følge !
Vi har forsømt i dette notat (men ikke i vores sædvanlige skrifter og forelæsnings-noter) at sondre mellem udvikling af systemer -- hvorved forstås maskinel + programmel, og programmel alene. Hvor vi i det tidligere alene skrev programmel, kan læseren, stille og roligt indsætte: ``maskine plus programmel'' !
Ved `arkitektur' skal vi her forstå den del af en (system cum) programmel-specifikation der varetager implementeringen af alle domæne- og visse (om ikke alle) grænseflade-krav.
Ved `program organisation & struktur' skal vi her forstå den del af en (system cum) programmel-specifikation der varetager implementeringen af visse (om nogen) grænesflade- og alle maskin-krav.
Modularitet, som begreb, har forhåbentligt været ledende i alle beskrivelser, fra domæne, via krav, til (system cum) programmel.
Ved modularitet forstås en tekstuel afgræsning af en beskrivelse således at denne, på op til maksimalt 2-3 sider A4 ark, beskriver en ``sammenhørende'' mængde fænomener: information indeholdt i, funktioner over, begivenheder involverende og opførsler af processer for disse.
Ved et objekt forstås et instantieret modul, en størrelse der, til illustration, kan forestilles at være en process, med egen tilstand, under udførelse samtidigt med andre processer (dvs. objekter) med hvilke det eventuelt kan udveksle information (f.eks. gennem meddelelser).
Ikke alt i en aktuel dagligdag er objekter, men noget er. Når vi fra domæne-beskrivelser via krav-definitioner og programmel-arkitektur når frem til program organisation & struktur, da er det at det virkelig har vist sig, siden Simula'67 (1967), at modularisering og objekter kan være endda overordentligt nyttige programmel-størrelser.
UML er en idag, 2001, meget ``fashionabel'' måde at anskue programmel-udvikling på. Dog besidder, réelt set, UML ikke nye revolutionerende tanker udover f.eks. sådanne som allerede var gængse i lang tid før fremkomsten af UML. Statechart har været brugt nogen tid før UML, hvori det også er ``indlejret''. Tilsvarende for ``Message Sequence Charts'', Petri Net, oa.
Når det er sagt at modularisering og objekter er nyttige ihvertfald i mellem-trin af programmel-specifikation (-design), så skal der også her ``advares'' mod visse ``ny-religiøse'' tendenser omkring UML. Årtiers dybe viden om konstruktion af og teorier for endda overordentligt nyttige, abstrakte specifikations- såvelsom konkrete programmerings-sprog synes i stor grad at være gået ``hen over hovedet'' på UML: Mange, de fleste, abstrakte specifikations- og konkrete programmerings-sprog har i årtier ``tilbudt'' objekt-orientering på et langt sikrere grundlag end UML gør det idag. UML savner derudover flg. endda overordentligt vigtige egenskaber: (i) Det har ingen sikker semantik, (ii) det har ikke noget reelt abstraktions-begreb, (iii) man kan ikke rimeligt logisk ræssonere over UML diagrammer (mm.), og (iv) UML har ingen implementations-relation: Dvs., man kan ikke vide om et stykke Java kode repræsenterer en korrekt implementering (realisation) af en UML specifikation. UML specifikationer har det med at specificere design i ét med krav-definition. Mao., UML specifikationer sammenblander domæne-beskrivelse, krav-definition og programmel-specifikation.
OMG (``Object Management Group'') leverer en seriøst udarbejdet og nyttig samling definitioner af en lang række ``services'' der forventes, og/eller som har vist sig, at være nyttige i mange forskellige sammenhænge. OMG's definitioner bygger, som navnet antyder, på objekt-orientering.
Trods de måske mere kritiske bemærkninger omkring UML, skal man ikke blankt forkaste objekt-orientering. Men man skal ej heller tro at objekt-orientering tilbyder et ``cure all'', eller at det bliver sidste, endelige, definitive svar på programmel-ingeniørens trængsler.
Der kommer nye ``fashions'', nye tider. Og vi kan forvente, som det dog har vist sig, at mere professionelt uddannede programmel-ingeniører, i stedse stigende takt vil optage de mere formelle metoder, principper, teknikker og værktøj.
Vi har i dette stor-afsnit skitseret overgang fra domæne-beskrivelse til krav-definition, og fra disse til programmel-specifikation. En stor ``mundfuld'' !
Det fremføres ofte at krav til stadighed ændrer sig -- så hvorfor være så nøje, som her anført, med krav-definitions-fasen ? Svaret herpå er selvflg. ganske enkelt: Det er en illusion at tro at krav til stadighed ændrer sig -- ihvertfald ikke domæne-krav. Domæne-krav udtrykkes, som antydet, vha. domæne-termer, og disse er utroligt stabile. De ændrer sig meget lidt, kun en gang hvert andet årti ! Det er teknologien, ved hvis hjælp vi implementerer (realiserer) krav, der ændrer sig, og dermed er det i bedste fald højst grænseflade- og maskin-krav der ændrer sig. Bemærk dog vores måde at definere de forskellige facetter af maskin-krav på. Deres definition gør, om man, i sine oprindelige, specifikke maskin-krav, følger definitionerne (karakteristikkerne), at selv disse kun ændres kvantitativt, ikke kvalitativt.
Men ``nye'' domæne-funktioner, der førhen ikke var reelt beregnelige, bliver nu tilgængelige, er mulige, via datamaten: Banker, forsikring og kredit-institutioner tilbyder nye services, og alle disse er udtrykt vha. gængse domæne-termer.
Mao. det kan betale sig nøje at forstå domænet, for derved har man garderet sig mod at nye domæne-krav eventuelt skulle ``vælte båden'' ved signifikant at kræve fundamentalt nye programmel-arkitekturer, organisationer & strukturer. Ved at sikre at de basale programmel-arkitekturer, organisationer & strukturer reflekterer basale egenskaber ved domænet, hhv. de fundamentale maskin-kravs kategorier (effektivitet, afhængighed, vedligehold, etc.), sikrer man sig mod en eventuel, dvs. ellers nødvendig ændring i programmel-arkitekturer, organisationer & strukturer. Lignende betragtninger gør sig gældende for grænseflade-krav og deres deraf afledte programmel-arkitekturer, organisationer & strukturer.
Ved informatik forstås en konfluens, en ``sammensmeltning'', af matematiske og datalogiske discipliner sammen med deres brug ved udvikling af datamatik til bestemte anvendelser -- såsom f.eks. datamatik til infra-struktur-komponenter.
Ligesom bio-teknik er teknologi, der løser problemer af biologisk art, og som derfor bygger på biologi (som en lære), således er informations-teknologien (IT) informatikkens teknologiske modsvarighed. I Danmark bruger man til stadighed begrebet IT, hvor man som oftest mener informatik; men man sondrer klart mellem biologi og bio-teknologi. Dette skyldes sikkert mediernes ``dims''-begejstring: Fascinationen med informations-teknologiens materielle univers i hvilket ``fremskridt'' måles kvantitativt: Større ydeevne (hukommelse, lagerplads, ``Giga-bytes''), mindre pris, mindre volumen (plads), hurtigere udførelse. Istedet burde man snarere beskæftige sig med informatikkens kvalitative og intellektuelle univers: Bedre EDB løsninger: Venligere tilgang til data-systemerne, større affinitet til genstands-området, korrekt (fejlfri) data behandling, mv.
Sammensmeltningen, der nævnes ovenfor, beror (i) bl.a. på informatik-ingeniørens benyttelse af lingvistiske elementer: Beskrivelse af fænomener; (ii) disses ``nær-filosofiske'' udskillelse (identifikation og afgrænsning; ``hvad kan beskrives'' [hvad kan erkendes]) fra et større genstands-område; (iii) sondring mellem pragmatik, semantik og syntaks -- samt (iv) på at dette sker indenfor en ellers stringent, matematisk verden, samtidig med at det, som kan krav-defineres, skal kunne beregnes. Domæne-beskrivelser er ikke bundet af `beregnelighed'. Så der er mao. lagt op til en ``spændende'' overgang fra det bredere spektrum af domæne-beskrivelser (inkluderende ikke-beregnelige såvelsom beregnelige modeller af fænomener) til et smallere spektrum af nødvendigvis beregnelige krav-definitioner. Overgangen er ikke, i traditionel forstand, ingeniørmæssig.
Hvor elektronik-, maskin-, bygnings- og kemi-ingeniørens fag-discipliner eksisterer i kraft af, fokuserer og bygger på, natur-videnskabelige fænomener, er dette ikke tilfældet for informatik-ingeniøren: Dennes verden bygger på, er begrænset alene af matematikkens og meta-matematikkens verden.
Begrebet `beregnelig' er tidligere i dette notat fremført og anvendt. Det er ikke alt der kan beregnes. Og selvom en ting kan beregnes, selvom denne ting kan formuleres klart, logisk, er det ikke sikkert at en beregning er praktisk mulig.
Det er således ikke muligt, for et vilkårligt generelt anvendeligt programmerings-sprog, at konstruere en programmerings-sprogs--oversætter (compiler) der, givet et vilkårligt, syntaktisk velformet program, kan afgøre om dette program går ind i en uendelig løkke når det ligger til grund for datamat-eksekveringer, mao. om det aldrig stopper.
Et andet aspekt ``skiller'' programmel-teknologi fra anden teknologi. Vi tager som eksempel på en sådan anden teknologi den elektroniske (mm.) teknologi, der indgår i konstruktion af datamaskiner. Lidt slag-ords-agtigt kunne man mene: Der opstår hvert 5te eller ca. år en ny datamat-teknologi og denne nye teknologi bruges på at løse det samme problem: At konstruere (fremstille) datamaskiner. I kontrast hertil bruges - i informatikken -- den samme ``intellektuelle `tænke' teknologi'': Matematik, til, hele tiden, at løse nye problemer !
``Moralen'' af dette (og de foregående) afsnit er at informatik, læren om og praksis af informatik, udgør en hel ny ingeniørmæssig disciplin: At man langt fra har forstået at kommunikere en lang række budskaber til klienterne: Hvad der kan beregnes, hvorledes problemer (domæne- og krav-problematikken) kommunikeres mellem klient og informatik-leverandører. Mao., at vi langt fra har forstået hvorledes klienter og informatik-leverandører bedst kan arbejde sammen med henblik på en rimelig (optimal) udnyttelse af informatikkens muligheder.
Der henvises, til indledning, til Afsnit 1.6. Visse forhold, der er nævnt i Afsnit 1.6, vil ikke blive gentaget her.
Det er fremført at en væsentlig årsag til de mange såkaldte ``EDB-skandaler'' vi jævnligt læser om skyldes klientens top-ledelses' manglende ``opbakning'', herunder forståelse for de videre konsekvenser af at indføre informatik.
Opstilling, det ``lange'', nøjagtige, omhyggelige, detaljerede, tilbundsgående arbejde med at opstille de multi-perspektiverede, fler-facetterede domæne-beskrivelser, medfører, helt naturligt, et ret så nyt, afklaret syn på den virksomhed, den offentlige administration, det private firma, som domæne-beskrivelsen omhandler. Dette ny-syn, processen hermed, medfører ofte, resulterer ofte i, et presserende ønske at omgøre, at redefinere virksomhedens måde at arbejde på. Domæne-beskrivelserne resulterer som oftest i en skarpere forståelse af virksomhedens mangfoldige fænomener, i dets ``opførsler'', ``begivenheder''. Sådanne, mere nuancerede, mere ``objektive'' forståelser medfører naturligt ønsket at omgøre institutionens arbejdsgange, som ofte ret så radikalt. Datalogiens, informatikkens, begrebs-verden, dens iboende trang til abstraktion, konceptualisering, overføres på sædvanlige genstands-områders som oftest ret så konkrete begrebs-verden. Alt dette åbner muligheden for at tilføre sædvanlige, ``klassiske'' genstands-områder's begrebs-verden nye, mere abstrakte, som oftest dermed mere generelt anvendelige, begreber, og dermed at lade disse ``styre'' basale forhold i et klassisk genstands-område.
Vort næste eksempel viser hvorledes telekommunikation og dermed fordelte (distribuerede) og samtidige beregninger muliggør at et ``ældgammelt'' begreb: Godstogs-rangering (marshalling) indenfor dertil særligt indrettede godstogs rangér-terræner (marshalling yards), muligvis bør, dvs. potentielt helt kan, ``erstattes'' af distribueret rangering (shunting) indenfor de allerede eksisterende banegårde.
EKSEMPEL 42
Omrangeringen kan beskrives, abstrakt, som følger: En `ind'-sekvens of godsvogns-stammer omdannes til en `ud'-mængde af godsvogns-stammer således der eksisterer en én-til-én korrelation mellem godsvogne i `ind'- og `ud'-stammer.
Konkret forestiller man sig rangér-terrænet som bestående af et indgangs-spor, en ``pukkel'', og en udfletning fra denne ``pukkel'' til en vifte af ud-rangérings-spor, der så igen samles (ind-flettes) til et udgangs-spor. Enhver `ind'-godsvogns-stamme føres henover ``puklen'' hvorfra de enkelte, afkoblede vogne ``falder'' ned mod én af `ud'-godsvogns-stammerne -- dirigeret imod en sådan vha. tilsvarende foreskrevet indstilling af de mange spor-skifter der muliggør viften af ud-rangérings-spor. `Ud'-stammerne køres siden ``væk'' fra rangér-terrænet -- hvorefter enhver godsvogn nu potentielt er på vej til næste destination.
I ovenstående traditionelle realisering af enhver bestemt godsvogns' sammensatte rejse, over ofte meget store afstande mellem virkårlige to stationer, bestemmer, implementerer, opholdet på et rangér-terræn (under nøje overvågning og styring af rangér-terræn-sporskifter, rangér-planer og personale), det som passagerer selv sørger for, når de skifter tog på en station: Ved, ved egen kraft, drevet af en ``indre, privat'' plan, at vandre (haste, eller løbe) fra én perron til en anden. De fleste stationer er passager-stationer. Meget få af disse har eget rangér-terræn. Regions-centrale rangér-terræner ``deles'' mellem mange lokale stationer. Traditionen har medført at godsvogns-stammer og dermed godsvogne har opholdt sig i endda overordentligt lange perioder på de fleste rangér-terræner. Man har taget den med ro: Der har ikke, i de nationale jernbane-selskabers monopol-periode, været nogen særlig motivation for at fremskynde om-rangering.
Idéen er nu, i en vis forstand, at lade lokal-stationer udføre al form for godsvogns-rangering: Afkobling, shunting, midlertidigt, kortere ophold på et godsvogns-sidespor, fulgt af shunting og sluttelig tilkobling til et ``næste'' godstog. Istedet for en central, ``off-line'' omrangering sker sådanne nu distribueret, med mulighed for meget snævre tids-begrænsninger for afkobling, shunting, midlertidigt ophold, shunting, og tilkobling.
For at muliggøre dette, herunder specielt at muliggøre hurtigere om-rangering, kræves det nu at hvor der før var et vist, mindre antal rangér-terræner, at enhver almindelig station foretager om-rangering baseret på meddelelser og planer der ``løbende indløber''. Der kræves ikke nogen særlig ``pukkel'', ingen ``vifte'', etc., blot at der er et rimeligt enkelt to-vejs-net af side--spor, et rangér-lokomotiv, samt passende lokal ledelse: Overvågning (monitoring) og styring (control). De, til stadighed ``indløbende'' meddelelser og planer, kræver passende telekommunikations-systemer. Ledelse af, og selve om-rangérings-arbejdet kræver datamatiseret understøttelse, og dette (det datamatiserede arbejde) genererer siden nye meddelelser og planer -- og disse sendes ``videre'': ``Op og ned'' ad linjen.
Måske de store godstogs-rangér-terræner's tid er måske forbi, men omstillingen kræver stor ledelses-forståelse, forberedelse og opbakning. [SLUT PÅ EKSEMPEL 42]
Eksemplet ovenfor viser at nye begrebs-dannelser kan lede til endda overordentligt signifikant nedsatte omkostninger såvelsom tilsvarende nedsatte gods-transport & ekspeditions-tider.
Vort næste eksempel viser, dog, hvorledes ny teknologi, medfører relativt nye koncepter.
EKSEMPEL 43
Indførelse af nye, basale begreber i et klassisk genstands-område kræver, som oftest, omstilling: Fra top-ledelse helt ud i de yderste led af virksomheden.
Og her er det at ``tingene'' begynder at gå galt: Som oftest rekvirerer (akcepterer) top-ledelsen (at) nye informatik-systemer (indføres). Men, som oftests er samme top-ledelse ikke indstillet på at sådanne informatik-systemer medfører ``omstilling: Fra top-ledelse helt ud i de yderste led af virksomheden.'' Og når en sådan ``forberedthed, villighed, åbenhed'' ikke ``sanses'', i dybden, af top-ledelsen, så skal det gå galt.
Mange, om ikke alle de nutidige, seneste, såkaldte EDB-skandaler, kan henføres, i det væsentligste, til denne omfattende, basale `uforberedthed'. Mao.: Ledelsen, der reelt set har beordret en omfattende domæne-beskrivelse, kan ikke ``leve op til dennes konsekvenser''.
Vi ser ingen anden løsning på dette basale problem end at man, informatik-leverandøren i særdeleshed, fra en tidligste begyndelse -- fra før domæne-beskrivelse -- sikrer sig at rekvirentens top-ledelse genuint, ærligt, er forberedt på og er moden til ``forandring''; at den har viljen og magten til at gennemføre nødvendige forandringer.
Hensigten med dette notat er at påpege at en omhyggeligt og detaljeret gennemført domæne-beskrivelse kan danne grundlag for en sober, troværdig ``business process re-engineering'' -- og dermed danne et teknisk grundlag for forandrings-ledelse. Kun en troværdigt udtømmende virksomheds-, dvs. domæne-beskrivelse kan sikre rimelige estimater af hvad det vil kræve at omgøre en virksomheds' organisation og ledelse ud i alle led.
I forbindelse med udvikling af visse typer store programmel-systemer for visse typer infra-struktur-komponenter (eller dele deraf) kan det være enten nødvendigt eller formålstjenligt at klient og udvikler indgår i et snævert, dog klient-betalt samarbejde således at domæne-beskrivelse, krav-definition og programmel-specifikation (inklusive aktuel kode) udvikles samtidigt, måske følgende én eller anden form for ``spiral''-process.tex2html_deferred
Mao.: Der udvikles ikke først en mere eller mindre komplet domæne-beskrivelse, dernæst en mere eller mindre komplet krav-definition før programmellet (specifikation mm.) udvikles. Istedet kan man forestille sig at et ``råt-skitseret prototype-programmel-system'' hurtigt etableres på grundlag af tilsvarende ``råt-skitserede'' domæne-bekrivelser og krav-definitioner. Klient og udvikler (kunde og leverandør) ``afprøver'' nu sammen denne ``prototype'' (der sikkert blot har nogle meget få, måske blot ``antydede'' funktioner). Denne ``afprøvning'' kan f.eks. have til hensigt, at validere (i) ``mest betydende'' dele af den gensidige domæne-forståelse, (ii) tilvarende ``mest betydende'' dele af krav-definitionen, samt (iii) ``mest betydende'' dele af programmellet, herunder dets grænsefladen til brugerne. Dernæst itereres domæne-beskrivelse, krav-definition, og programmel-specifikation (inklusive aktuel kode) med yderligere trinvise validerende afprøvninger.
Bemærk at vi egentligt ikke har opgivet vore triptych, blot omfortolket dens ``udførelse'' !
Typisk kunne man ønske at anvende den ovenfor beskrevne ``spiral''-model i situationer hvor klienten er villig til f.eks. fast-pris-aftaler for hver iteration uden på forhånd fastsatte mål, men med akcept af at visse forventningers ambitions-niveau eventuelt ``neddrosles'' (eller ``opskrues''). Sådanne situationer kunne forestilles relevante for udvikling af sådanne informatik-systemer hvor klienten, dels har stor tillid til programmel-udviklings-firmaet, dels ønsker, gennem et snævert samarbejde i alle faser, at afprøve egne forestillinger om domænet, og af krav, samt eventuelt at eksperimentere med forskellige ``business re-engineering'' modeller, eller måske blot at indføre disse, dvs. forandrings-ledelsen, sukcessivt for derved at sikre en bedre, mere smidig institutionel akcept.
Fordi man, i Lego klodser, kan bygge en legetøjsbro, er det langt fra sikkert at man egner sig til at blive bygnings-ingeniør, endsige brobygger. Fordi man tilsyneladende kan ``hakke'' et Visual Basic program sammen, for slet ikke at tale om blot at lave web sider eller programmere Linux system-funktioner, er det slet ikke spor sikkert at man egner sig til at forestå udvikling af administrative systemer til arbejds-anvisning, elektroniske patient-journaler (EPJ), mmm. Man har ihvertfald ikke godtgjort det. Der skal mere til. Dette notat antyder at den professionelle data-ingeniør cum programmør cum informatik-ingeniør skal beherske mange discipliner. Vi kan nævne en række discipliner indenfor datalogi som ikke har været berørt før, men som der er bred enighed om at en professionel datalog (cum data-ingeniør cum programmør cum informatik-ingeniør) skal beherske:
Ovenstående er blot et mindre udpluk. Og så har jeg slet ikke nævnt de kalkyler og teori-dannelser der ligger nærmest dette notats emne !
Disse og mange andre del-emner indenfor datalogi udgør den professionelle datalogs' teknisk/videnskabelige ballast. Dertil kommer flere andre emner der er vigtige for projekt- og produkt-ledelse.
Man bemærker at vi ikke har nævnt sådanne ``populære'', og for mange nyttige emner som f.eks. objekt-orienteret analyse og modellering, herunder UML. OO er en del, udspringer, af de før nævnte, mere formelle discipliner -- og UML er blot en nutidig teknologi. Den vil sikkert hedde noget andet om 10 år -- ligesom man for 10 år siden fylkedes omkring andre etiketter og slagord.
Moralen af dette under-afsnit er at langt de fleste af hverdagens programmel-huse (i Danmark og andetsteds) idag ikke besidder den fornødne viden om de ovenfor opregnede emner, endsige behersker dem til den grad det her skønnes nødvendigt.
Dagens kandidater fra kemi-, elektronik-, bygnings- og maskin-retningerne ansættes, i den udstrækning de ansættes indenfor deres klassiske fag, i virksomheder hvis ledelse tilsvarende har en klassisk dannelse indenfor samme disciplin: Stort set læst (``tyret over'') de samme lærebøger -- ihvertfald indenfor enkelt-fagenes grund-discipliner.
Men indenfor programmering, i programmel-huse, og især typisk for de virksomheder der engang startede som elektronik-virksomheder, men som (oftest umærkeligt, og især for ledelsen ikke til fulde forstået), gled over i programmering, datamatik, indenfor disse virksomheder (og det er stort set langt, langt de fleste, de berømmelige 99%), dér er ledelsen ikke datalogisk disciplineret, har ikke den fornødne pli ! Katastrofen udebliver som regel ej heller.
Resultatet af ovenstående: Fra dilletantisk til, i bedste fald, amatøragtig programmering, udebliver ej. Store programmel-udviklings-projekter savner den fornødne professionalisme. Det går, for en tid. Og så indhenter fortidens synder firmaet. Vedligehold af arkaisk programmel ``koster det hvide ud af øjnene''; man evner ikke at ``dreje om på en tallerken'' og kan ikke hurtigt reagere på konkurrence fra nyere firmaer med inkrementalt bedre (læs: yngre, nyere) uddannede folk; de bedste folk ``skrider'' (``siver'') til de bedre, mere lovende firmaer, og en altfor ømtålelig del af firmaets ekspertise forsvinder sammen med disse folk. Det hele ender med lavest fællesnævner -- istedet for største fællesfold.
De dog ikke helt så få idag vel-uddannede dataloger, som kan de mere formelle, de mere stringente metoder, som forventer at programmel-udvikling f.eks. flgr. det, der er skitseret i nærværende notat, disse dataloger ``drukner'' i de større IT firmaers stab: Deres viden bliver på langt nær udnyttet. Et stort potentiale går tabt.
Imens er de seriøse datalogiske uddannelses-steder nødt til at fastholde kvaliteten, til ikke at bøje sig for ``popular demand'', men at fortsætte med at uddanne den næste generation af kandidater til højeste, faglige niveau. Alt andet ville være uansvarligt. Det er ikke svært at lære de nye metoder. Store grupper kandiderer hvert år med en fast forankring heri.
Så hvordan kan vi opnå stabilitet, sikre de lange linjer -- trods eventuel ``udsivning'' af hvad man før betragtede som nøglepersonale ? Hvordan kan vi sikre en professionel, troværdig programmel-industri ?
Foruden at sikre at alle ledende, dvs. at 80% af de professionelle ansatte er akademisk-trænede på og til dagens højeste niveau, bør man også sikre at firmaet, institutionen, programmel-huset:
Det vi oftest ser idag er firmaer, der forvirret ``jagter'' de seneste ``trends'', uden dybere at have reflekteret over deres egen, særlige kvalifikationer.
Medvirkende til at sikre medarbejdernes loyalitet er at ledelsen sikrer at udviklings-projekterne har kvalitet. Til projekt-kvalitet medregner vi flg.:
Programmel-udvikling kunne, med stor fordel, ``kopiere'' andre ingeniør-discipliners ``studie/eksperiment/anvendelses'' paradigme i hvert afsnit af udvikling:
Ressource-, f.eks. person-måned-mæssigt, udsiger erfaringen, fordeler de tre paradigme-komponenter sig som én-til-tre-til-ni: 1:3:9 !
Medvirkende til at sikre medarbejdernes loyalitet er at ledelsen sikrer at de udviklede produkter har kvalitet. Til produkt-kvalitet medregner vi flg.:
Det siger sig selv at vores insistering på en dyb forankring i domænet -- intim forståelse, klart erkendt ``ekspert''-kunnen -- er med til at sikre ovenstående seriøsitet og troværdighed, til en begyndelse, samt at leverandør-firmaets løbende videre-udforskning af genstands-området er med til at vedligeholde projekt- og produkt-kvaliteterne.
Vi har fremstillet arbejdsgange og mellem- og slut-resultater af en meget omfattende, detaljeret og ``nøjeregnende'' programmel-udviklings-process. Vi har antydet at denne, i den form vi selv bruger den, dvs. også med det indhold hvori vi underviser deri, udover de mange uformelle, dog stringente og præcise udviklings-faser, -afsnit og -trin, også indeholder formelle, matematisk baserede sådanne komponenter. Vi har faktisk antydet at det netop er denne side af den fremstillede, nyere, klasse af programmel-udviklings-metoder, der betinger deres nyttigste brug. Vi har mao. antydet at det er muligt -- og literaturen godtgør, at der er belæg for denne påstand -- at udvikle programmel til en langt højere standard end det idag almindeligvis kendes: At vi kan komme langt tættere på at indforskrive programmel vi kan have tillid til, som i langt højere grad end det idag erfares, opfylder kundens og brugernes behov og forventninger; at de ikke er ``fyldt med fejl''; at de ``stille og roligt'' kan udvides til også at rumme nye, domæne-beslægtede funktioner; at de udvikles til tid og kost; oma.
Vi har også kommenteret denne metodes relation til begrebet forandrings-ledelse, herunder ``business process (re-)engineering''. Og vi har endelig kommenteret visse sociologiske og psykologiske aspekter ved sådanne, nyere metoders mere udbredte akcept.
Dette afsnit lister publikationer og rapporter, der dækker diverse infra-strukturers' domæne-modellering.
Jeg tillader mig alene at henvise til egen produktion. Der er, selvflg., en langt videre literatur -- som de nedenfor refererede publikationer og rapporter henviser til. Listen af mine egne publikationer mm. skal således tjene til at de læsere af dette notat, som ikke er bekendt hermed, kan erfare at der bag dette notat ligger snart 30 års seriøst arbejde. I Appendiks Afsnit A bringer jeg mit CV. Heraf fremgår yderligere ``tillids-skabende'' forhold.
Publikationer der dækker de metode-mæssige forhold ved udvikling af store programmel-systemer:
Det kan synes særegent at bringe eksempler på tilsyneladende ``ganske almindelige beskrivelser'' af ``ganske almindelige anvendelses-domæner''. Men måske disse beskrivelser ikke er så almindelige endda: Dels mangler de som regel, for ikke at sige altid, i udvikling af programmel og dermed fra dets dokumentation, dels er der faktisk ikke særlige mange, for ikke at sige ingen sådanne, tilgænglige beskrivelser. Mao.: Man udvikler, rask væk, store programmel-systemer uden at have godgjort for andre, til eksempel klienten, endsige sig selv, at man véd noget om domænet. Man ville vel ikke udvikle mekanisk udstyr om man ikke kunne godtgøre professionalisme, f.eks. gennem en akkrediteret uddannelse i de mekaniske fag. Tilsvarende for elektro-teknik, elektronik, kemi, bygnings-væsen: At man kender fagets basale lovmæssigheder oma. Etablering og dokumentation af domæne-beskrivelser skal derfor sikre denne tillid.
De anvendelses-domæner vi vil illustrere er flg.:
Nu kan vi jo ikke sådan lige beskrive ``alt'' i hvert af disse domæner. Istedet fokuserer vi på blot at antyde hvad det er der skal beskrives. Dvs. vi bringer blot en kort synopsis og råskitser (jvf. omtale af disse begreber Side ). Andetsteds bringer vi større sådanne fortællende beskrivelser. Dog, Eksempel 4 antyder en mere tilfredsstillende, detaljeret (udtømmende) beskrivelse.
Der er andre eksempler for hvilke vi ikke bringer særskilte afsnit:
Og så fremdeles: ``The sky's the limit''.
Fælles for alle eksempler, ovenfor, og i de flg. afsnit, er at vi starter med at stille spørgsmålet:
hvor x er een blandt: en jernbane (DSB, f.eks.), logistik, handel, en finans-verden, en sundheds-sektor, et ``flow system'', fly trafik, en lufthavn, et universitet, turisme.
Andre eksempler kunne nævnes.
Vort jernbane-domæne består af flg. entiteter: Et spor-net, tog, disses trafik, køreplaner, passager, og gods. Disse, deres aktiviteter og interaktion, beskrives nedenfor.
Essensen i vort jernbane-domæne er at passagerer (med billetter) og gods (iflg. fragtbreve) transporteres af tog, ad linjer, mellem stationer, efter mere eller mindre faste køreplaner, og til pris.
En flg. essens af vort jernbane-domæne er at tog afsendes til tid, at tog-trafik overvåges med henblik på sikkerhed, passager-komfort, fragt-sikkerhed, og punktlighed, og at det hele sker rimeligt optimalt, indenfor budget og uden altfor mange drifts-uregelmæssigheder.
Andre flg. essensser af vort jernbane-domæne er at dets ansatte trives: Regelmæssigt modtager deres rettelige løn, udnyttes efter evne, kunnen, uden ``hast-&-jag''-induceret ``stress'', og under hensyn til hvile-, fridags- og ferie-bestemmelser.
Et jernbane-spor-net består af stationer og linjer: Mindst to stationer og mindst een linje. Stationer og linjer består af spor-enheder. En linje forbinder eksakt to distinkte stationer. Enhver linje har et unikt navn. Enhver spor-enhed besidder sammenføjnings-punkter (konnektorer). Spor-enheder er enten lineære (og har da to distinkte konnektorer), eller er sporskifter (og har da tre distinkte konnektorer), eller er almindelige, simple spor-kryds (og har da fire distinkte konnektorer), eller er skiftelige spor-kryds (og har da fire distinkte konnektorer), eller er .... En linje består af en sammenføjet sekvens af een eller flere lineære spor-enheder (således at to på hverandre følgende spor-enheder i en linje deler eet sammenføjnings-punkt. For ethvert sammenføjnings-punkt er der højst to spor-enheder der deler dette sammenføjnings-punkt.
En spor-enhed tillader bevægelse af et tog i een eller flere retninger. Lad k,k' angive en lineær spor-enhed's to konnektorer. Da er det principielt muligt for et tog (en togvogn) at bevæge sig i enten retning (k,k') eller i retning (k',k). For et sporskifte, med tre konnektorer: k,k',k'' (hvor vi antager at k angiver det sammenføjnings-punkt fra hvilke man kan bevæge enten i retning mod k' eller mod k''), da er flg. bevægelses-retninger principielt mulige: (k,k'), (k,k''), (k',k) og (k'',k). Ved en spor-enheds tilstand forstås mængden af alle de bevægelses-retninger der er aktuelt mulige. For en lineær spor-enhed kan en sådan tilstand enten være [] (spor-enheden er lukket for trafik, eller [(k,k')], eller [(k',k)], eller [(k,k'),(k',k)] (spor-enheden er åben for trafik i begge retninger). For et spor-skifte kan flg. tilstande være mulige: [], eller [(k,k')], eller [(k',k)], eller [(k,k'')], eller [(k'',k)], eller [(k,k'),(k',k)], eller [(k,k''),(k'',k)], eller (for særlige sporskifter) [(k,k'),(k',k),(k'',k)], eller [(k,k'),(k'',k)], eller [(k',k),(k'',k)]. Vi siger at mængden af alle en spor-enhed's mulige tilstand angiver dets tilstands-rum. Man kan, mao., tale om en spor-enhed's øjeblikkelige tilstand, og om at spor-enheden kan skifte tilstand. Hvad det er der bevirker en spor-enhed's tilstands-skift siges der her ikke noget om !
Ovenstående beskriver alene et spor-nets basale forhold.
Vha. disse begreber definerer vi nu yderlige begreber.
En rute er en sekvens af forbundne (ie. sammenføjede) spor-enheder ``med samt'', for hver spor-enhed, en bevægelses-retning således at disse ``hænger sammen'' i samme retning. En åben rute er en rute som har alle sine spor-enheder's bevægelses-retning i den pågældende spor-enhed's øjeblikkelige, dvs. nuværende tilstand.
En station definerer nul, een eller flere, som regel mindst een perron- og nul, een eller flere side-linjer (``tracks'' og ``sidings'', hvor disse `-linjer' ikke må forveksles med linjer mellem stationer). Perron-linjer muliggør på- og af-stigning af passagerer
Det er nu muligt at definere de linjer (ud fra en station) der kan nås (dvs. for hvilket der er en intern stations-rute) fra en perron- eller en side-linje, hhv. de perron- og side-linjer der kan nås fra en vilkårlig linje ind til den pågældende station.
Og så fremdeles.
Vi abstraherer et tog ved en rute og en unik tog-identifikation. Senere tilkommer der evt. flere tog-attributter. Vi kan nu tale om en tog-bevægelse. Der er syv mulige tog-bevægelser, idet beskrivelserne alene henholder sig til spor-enheder, og disse betragtes her som diskrete størrelser. Vi abstraherer således fra positioner relativt til et sammenføjnings-punkt. De syv tog-bevægelser er som følger: (i) Toget optager samme rute i begyndelsen som i slutningen af sin bevægelse. (ii-iii) Toget ``kaprer'' en ny spor-enhed; dvs. føjer en sådan til sin rute, enten i den ene eller den anden retning. (iv-v) Toget ``gir' slip'' på, forlader, en spor-enhed, dvs. ``fjerner'' en sådan fra sin rute, enten i den ene eller den anden retning. (vi-vii) Eller toget både ``kaprer'' og forlader en spor-enhed, enten i den ene eller den anden retning.
Til et hvert tidspunkt opererer nul, eet eller flere, men et endeligt antal tog på et net. Mellem to, på hinanden ``tætte'', tidspunkter er det muligt, dels at nogle eller alle togene bevæger sig, at ``gamle'' tog går ud af drift, og/eller at ``nye'' tog sættes i drift. Samtidig hermed er det muligt at spor-nettet ændrer tilstand.
Trafik er nu en funktion fra tid over i kombinationer af spor-net og nul, eet eller flere togs' positioner (dvs. ruter).
Vi har ikke i ovenstående, basale, beskrivelse taget hensyn til (i) om to eller flere tog optager overlappende ruter (herunder er stødt ind i hverandre); (ii) om deres ``underliggende'' rute er åben eller lukket, eller om visse af dens spor-enheder er tilsvarende; (iii) osv.
Men vi foreskriver, som muligvis refutérbare påstande, at ``Vorherre kaster ikke terninger:'' (I) At et tog der til to tidspunkter er registreret i respektive trafikker ikke til et tidspunkt mellem disse to ikke er således registreret. Mao. der er ingen spøgelses-tog. (II) At to, eller flere, tog der, til et tidspunkt, bevæger sig langs en rute, ikke til ``næste'' tidspunkt er ``ombyttede''. (Her skal, forståeligvis begreberne næste tidspunkt, ombyttede, oa. defineres.)
Og så fremdeles.
Ved et stations-besøg forstås et begreb der indeholder flg. attributter: Tog-identifikation, ankomst-tid, stations-navn, og afgangs-tid. (Ved en uden-stop-rejse forstås, foruden en tog-identifikation, en simpel sekvens der starter og slutter med respektive stations-besøg og som ``ind-imellem'' består af et navn på en linje der forbinder de to stationer for respektive stations-besøg, således at ankomst-tid til den anden station står i et rimeligt forhold til den mellem-liggende linje's længde og øvrige [ikke her berørte] attributter.) Ved en rejse forstås, foruden en tog-identifikation, en sekvens der starter og slutter med respektive stations-besøg og som ``ind-imellem'' består af en alternerende sekvens af linje-navne og stations-besøg, begyndende og afsluttende med et linje-navn.
Ved en almindelig, passagér-orienteret køreplan forstås, foruden en topologisk beskrivelse af et spor-net, her en beskrivelse, struktureret som ovenfor angivet, af nul, een eller flere rejser, således at alle tog-navne er unikke og iøvrigt begrænset af sådanne begrænsninger som f.eks. de at rejse-tider er kommensurable med afstande, at visse tog's ankomster ``synkroniserer'' med andre tog's afgange, etc.
Passagerer forespørger om rejse-muligheder og forespørger om, eller stiller betingelser (tider, priser, mv., korteste, hurtigste rute, mmm.), køber og afbestiller billetter og plads-reservationer, stiger på tog, billeteres eller rejser ``sort'', rejser forkert, for langt, ændrer tute undervejs, oma.
Mennesker og firmaer sender fragt med godstoge: Forespørger om fragt-muligheder og forespørger om, eller stiller betingelser (tider, priser, mv., korteste, hurtigste rute, mmm.), køber, afbestiller og ændrer fragt-plads, indleverer godset, får fragt-brev, forespørger om igangværende fragt-transporter (``sporer'' indleveret fragt), modtager meddelelse om ankommet gods, afhenter gods, og betaler eventuelle gebyrer.
Jernbane-personale planlægger fremtidig drift, langsigtet (næste år, næste sæson), ``mellemsigtet'' (allokering af stab og vogne til næste uges eller dags' trafik), og kortsigtet (sikrer afsendelse af tog til tiden, overvåger trafikken og foretager eventuelt ``sidste-minut'' justeringer, etc.). Jernbane-personale sikrer at materiel (rullende og stationært [signaler mv.]) er drifts-sikkert. Og jernbane-personale står for oprettelse (nedlæggelse) af nye (gamle) linjer, stationer, og services, herunder disses planlægning og konstruktion.
Meget mere kunne siges, og meget af det er beskrevet i [5,49,,8,45,,50,51,25,39,39].
Ovenstående beskrivelser er blot råskitser.
Der er givet er et specifikt jernbane-domæne, dvs. et jernbane-system. Det er givet i form af et spornet, en stab, rullende materiel (vogne af forskellig art), og en fortid -- i form af tidligere, inklusive seneste, års statisitk.
Forfatteren til nærværende notat deltager i en fire års periode i årene 2000-2005 i et EU projekt: AMORE: Algorithmic Methods for Optimising Railways in Europe. I projektet undersøges en meget lang række operations-analytiske planlægnings-problemer, svarende til nedenstående krav: 1, 3, 5, 6, 8, 10, 12, og 14. Jeg skal derfor, med henvisning til AMORE-projektets web side, ***, undlade at detaljere de specifikke optimalitets-kriterier.
Der optælles 17 råskitse eksempler på krav til programmel der understøtter planlægning og drift af fragmenter af dette specifikke jernbane-system.
Der er specifikt givet det seneste kalender-års passager-statistik: Hvor mange der aktuelt rejste, hvorfra og hvortil, og til hvilke tider, og på hvilken klasse og pris. Der er også givet spørgsmål og svar i forbindelse med en statistisk udvalgt rundspørge der giver troværdige indikationer af hvorledes ``det seneste kalender-års passager-statistik'' ville (dvs. kunne) have været såfremt der netop havde været tog til de tider de adspurgte (evt. ellers) ville have rejst til, hhv. for.
Kravet der nu stilles er at udvikle et køreplan-planlægning-system. Som ind-data skal dette system have information om spornettet, rullende stab, hypotetisk (idéelt set) tilgængelig stab, den ovennævnte passager-togs statistik, samt rundspørge. Som ud-data skal systemet levere en køreplan der skal opfylde de forventninger om passager-trafik som ind-data indikerer. Køreplanen skal være optimal mht. flg. kriterier: ... osv. ...
Én af pointerne, ved at bringe eksempler på råskitse-domæne-krav-definitioner, er at vise at krav-definitionerne ``stort set'' alene forholder sig til den tidligere anførte domæne-beskrivelse -- og at, hvor den ikke gør så, dvs. bruger domæne-termer, der ikke er nævnt tidligere, at dér er det en ``smal sag'' at rette op på disse mangler, disse undladelser, i domæne-beskrivelsen.
En anden af pointerne er at vise hvorledes domæne-egenskaber der optræder i definitioner for ét sæt krav også optræder i definitioner andre, derfra tilsyneladende ``meget forskellige'' krav-definitions-sæt.
Vort logistik-domæne består af flg. entiteter: Et transport-netværk, eet eller flere transport-firmaer, een eller flere sendere og modtagere af fragt, samt af eet eller flere logistik-firmaer. Disse, deres aktiviteter og interaktion, beskrives separat nedenfor.
Essensen i vort logistik-domæne er at kunder sender og modtager fragt, at denne fragt transporteres af transport-firmaers fartøjer, fra et udgangs-knudepunkt i et transport-netværk via ruter mellem knudepunkter og via sådanne knudepunkter -- hvor sådan fragt eventuelt omlades -- til et slut-knudepunkt, at fartøjer rejser efter faste fartplaner, og at logistik-firmaer arrangerer, for kunder, og i samarbejde med transport-firmaer, sådan transport af fragt -- symboliseret ved såkaldte fragt-breve (Engelsk: ``Bill-of-Ladings'').
Transport-netværk er sammensat af eet eller flere separate transport-del-netværk, eet eller flere for hver af flg. transport-medier: Biler, tog, skibe og fly. Vi abstraherer fra typen af transport-medie. Ved et transport-medie forstås således enten en bil (bus, taxi, lastbil, mfl.), eller et tog (passagertog, godstog, eller blandet tog), eller et skib (passager-skib, fragt-skib, eller blandet), eller et fly (passagerfly, fragtfly, eller blandet). Istedet for det lange ord `transport-medie' skal vi i det flg. alene bruge termen fartøj. Vi abstraherer også fra bilers mulige stoppesteder (bus-stoppested, taxi holdeplads, lastbils-omlade-plads, etc.), stationer, havne og lufthavne, og bruger istedet fælles-termen: knudepunkt. Herved kan vi også enklere lade to eller flere fartøj typers' knudepunkter være sammenfaldende. Og endelig kan vi ved en simpel rute forstå enten en vej (mellem to stoppe-steder), en jernbane-linje (mellem to stationer), en søvej (mellem to havne), og en luft-korridor (mellem to lufthavne). Knudepunkter og simple ruter har distinkte navne. Simple ruter har alle længde-attributten.
Et transport-netværk består således af to eller flere knudepunkter og een eller flere simple ruter som forbinder disse knudepunkter. Mao., vi ``ligner'' et transport-netværk ved en simpel ikke-orienteret graf. Dog tillader vi, aht. senere brug, at vi kan analysere et knudepunkt til, foruden sit unikke navn, at have een eller flere af attributterne: Stoppe-sted, station, havn, og lufthavn; og en simpel rute til, foruden sit unikke navn, at have eksakt een af attributterne: Vej, linje, søvej, og luft-korridor. Vi tillader således at par knudepunkter kan være forbundet af nul, een eller flere, distinkt navngivne simple ruter.
Til et fartøj knyttes dels statiske attributter: Transport-kapacitet, f.eks. udtrykt i antal 21 fods containere fartøjet kan transportere, dels dets dynamiske attributter: Dets last, dvs. hvilket antal det, til ethvert givet tidspunkt aktuelt transporterer, og, for hver sådan container, en sådan kontainers yderligere attributter: fragtbrev, position på fartøjet, mm. (Se nedenfor.)
En transport-virksomhed abstraheres ved flg. to forhold: Et antal eentydigt navngivne (og attributerede) fartøjer og en fartplan. En fartplan angiver, for hvert (operativt) fartøj (dvs. fartøjer fra en delmænge, eventuel hele transport-virksomhedens ``flåde'', af fartøjer) deres ruter, ankomst- og afgangs-tider, samt fartøjets statiske attributter. En fartplan ``strækker sig ud i tid'': Dette (``udstræknings''-begreb) kan være udtrykt f.eks. ved at angive et modul, en rejse frem og tilbage, samt at modulet gentages (modulært), f.eks. hver anden måned, dag, time, eller tilsv.
Transport-virksomheder korresponderer med logistik-firmaer: Underretter dem om dets fartøjer og disses fartplaner: tider, priser, betingelser, mv. Transport-virksomheder korresponderer med sine fartøjer: Véd hvor de er, hvornår de ankommer til knudepunkter, hvilken fragt der venter på dem i knudepunkter, hvad der skal losses, hvad der skal lastes, osv. Transport-virksomheder korresponderer således også med knudepunkter.
Sendere afsender gods. Modtager modtager gods. Sendere henvender sig til et logistik-firma. Informerer om godsets art, modtagers adresse (mv.), og forespørger om mulige forsendelses-vilkår: korteste, eller hurtigste, eller billigste, eller ``sikreste'' rute, afsendelses-tider, priser, forsikring, og evt. øvrige vilkår. Sendere beslutter sig for afsendelse: Leverer godset, modtager kopi af fragtbrev, og betaler eventuelt for transporten.
Et fragtbrev anskues her meget generelt: Som et papir- (eller elektronisk-) dokument der beskriver godsets art, afsenders og modtagers navne, adresser mv., transport-ruten: Fra og via hvilke knudepunkter og simple ruter, med hvilke transport-virksomheders' fartøjer, til hvilke tider, til hvilken priser (afsenders og modtagers evt. gebyrer, afgifter, mv.), oplysninger vedr. forsikring, hvorledes modtager adviseres, oma.
Modtagere adviseres om en forsendelses modtagelse af og hos et logistik-firma. Modtager henvender sig til dette, får godset leveret (mod behørig legitimation og dokumentation, f.eks. en kopi af godsets fragtbrev som enten afsender eller logistik-firmaet tidligere har fremsendt), og evt. mod en vis betaling (herunder evt. told oa. gebyrer).
Logistik-firmaer arrangerer forsendelse af fragt, ofte over vilkårlige ruter. Logistik-firmaer kender til transport-virksomhedernes fart-planer, betingelser, priser, mv. Logistik-firmaer modtager forespørgsler fra afsendere og modtagere af fragt, modtager fragt der skal forsendes fra afsendere, afleverer fragt til knude-punkter, afleverer fragt der er modtaget i knude-punkter til modtagere, og sporer hvor fragt er. Hvor ændringer i aktuel afvikling af fartøjers trafik betinger det, foretager logistik-firmaer ændringer i fragt-breve.
Meget mere kunne siges. Men nok er sagt til at opnå vort mål: At illustrere behovet for at beskrive, og at antyde det mulige omfang af beskrivelser af logistik-domæner.
Vi har ikke, endnu, fokuseret nævneværdigt på arten af og indholdet i det gensidige ``samtale-transaktioner'' der finder sted mellem sendere af fragt og logistik-firmaer, mellem logistik-firmaer og transport-virksomheder, mellem transport-virksomheder og deres fartøjer, mellem de tre sidste rolle-havere og knudepunkter, etc.
Afsnit B.3 vil komme ind herpå. Vi henviser især til vores betragtninger i Afsnit B.3.6 og i begyndelsen af Afsnit B.3.7.
Der optælles 15 eksempler på krav til programmel er understøtter planlægning og drift af fragmenter af et logistik-system:
Vort handels-domæne består af flg. entiteter: Varer, tjeneste-ydelser og betalinger, kunder, detail-handlere, grossister, og fremstillings-virksomheder, samt distribution. Disse, deres aktiviteter og interaktion, beskrives separat nedenfor.
Essensen i vort handels-domæne er at varer købes og sælges, at kunder efterspørger, køber og returnerer varer hos, respektive til detail-handlere; at detail-handlere efterspørger, køber og returnerer varer hos, respektive til grossister; og at grossister sluttelig efterspørger, køber og returnerer varer hos, respektive til fremstillings-virksomheder. Vi skal ikke her se nærmere på levering, distribution, af varer. Vi anskuer dette som en funktion (funktions-klynge) der hører til under logistik. Detail-handlere og grossister optræder således både i køber- og sælger-roller, kunder alene som købere, og fremstillings-virksomheder, i denne sammenhæng, alene som sælgere.
Essensen i vort E-handels-domæne er dels at ovenævnte forhold undstøttes vha. informatik: At efterspørgsel kan ske via nettet, understøttet af ``elektroniske'', typisk web-baserede kataloger; at ordre--afgivning, ordre-akcept (konfirmering), fakturering og betaling ligeledes kan ske via nettet; og så fremdeles.
Essensen i vort E-handels-domæne er desuden at udvide handels-begrebet med både et agent og et mægler begreb, samt at understøtte, eventuelt automatisere disse. Ved en agent forstås en mekanisme (en person eller en datamatiseret process), der agerer på vegne af en kunde, detail-handel, grossist eller fremstillings-virksomhed. Agenter interagerer med enten købere, sælgere, agenter eller mæglere. Ved en mægler forstås en mekanisme (en person eller en datamatiseret process), der bringer potentielle købere, sælgere, agenter, eller andre mæglere sammen med det formål at formidle en handel.
Essensen i det forneden indførte E-forretnings-begreb er (1) at omfortolke `handel' til `forretning'; og (2) at udvide og omfortolke kunde, detail-handel, grossist og fremstillings-virksomheds entiteterne til først at indføre ``det offentlige'' (O): Statlige, amtlige, amts-kommunale og kommunale institutioner; dernæst -- måske arbitrært -- at gruppere detail-handel, grossist og fremstillings-virksomheder sammen med andre private virksomheder i en såkaldt privat `forretnings-gruppe' (P), og kunder i gruppen af borgere (B). Mao. at ``definere'' (at anskue) `forretning' som udtrykt gennem een eller flere transaktioner mellem enkelt entiteter indenfor hver af de tre grupper, hvor vi, i optællingen der nu flgr., ved ordningen X2Y antyder at X tager initiativet til en følge af een eller flere transaktioner med Y: O2O, O2P, O2B, P2O, P2P, P2B, B2O, B2P, og B2B.
Vi skal ikke sondre mellem de to former for handels-entiteter: varer og tjeneste-ydelser. Ved en vare forstår vi en fysisk manifestérbar størrelse, af fysisk art, optagende plads i rummet, noget der kan forbruges, enten éngangs-brug (som f.eks. fødevarer eller energi), eller genbrugelig, men typisk med en vis begrænset levetid (kan nedslides, som f.eks. en bog, en bil, et sæt tøj). En vare kan købes og skifter da hænder: I det ene øjeblik er varen hos sælger, i det næste hos køber som netop har betalt for varen. Ved en tjenesteydelse forstår vi en oftest ikke-manifestérbar størrelse, af ikke-fysisk art, optagende ``plads'', ikke i rum, men typisk i tid ! Noget der enten bliver forbrugt, i samme tid, som et teater-besøg, eller som efter en første, tids-mæssig periode, et interval, hvori tjeneste-ydelsen leveres, som f.eks. konsulent-bistand, kan ``genbruges'': Modtageren af tjeneste-ydelsen er blevet mere vidende, og bruger den nye viden, ``igen-og-igen''. Også her betales der for tjeneste-ydelsen, muligvis i afdrag.
Mao.: Varer og tjeneste-ydelser kommer i forskellige former, der er varer af type A, af type B, etc., type C, og der er tjeneste-ydelser af type H, af type J, etc., type K, Til hver type er der en betalings-pris. Denne kan afhænge af formen for leverance. Som regel køber man kun eet ``eksemplar'' af en tjeneste-ydelse, og da for en bestemt periode, et bestemt tids-interval. Men man kan købe indtil flere ``eksemplarer'' af en vare, nogle leveret nu, andre siden. Der kan så ydes mængde-rabat, mv.
Til varer og tjeneste-ydelser kan man således lad svare et katalog over art, leverance-betingelser og priser.
En ``forsynings-kæde'' (``a supply chain'') er et aggregat af én eller flere kunder (men det er tilstrækkelgt blot at tale om én kunde); nul eller én detail-handel; nul, én eller flere grossister, hvor disse er ordnede i en følge: lokal-grossist der leverer til detail-handel (eller kunde), mellem-handels grossister der leverer til andre sådanne eller lokal-grossister, og én fremstillings-virksomhed. Mao., kunder kan forestilles at købe direkte fra grossist eller fra fremstillings-virksomhed (``fabriks-udsalg'').
Relationen mellem på hverandre følgende led i forsynings-kæden er køber/sælger relationen. Køber kan henvende sig til sælger med flg. ``transaktioner'': (i) forespørgsel, (iii) ordre, (vi) leverings-akcept, (viii) betaling, (ix) reparations-indlevering og (xi) klage (retur). Sælger kan henvende sig til køber med flg. ``transaktioner'': (ii) tilbud, (iv) konfirmation, (v) leverance, (vii) faktura, (x) reparations-ydelse, og (xii) refundering. Her antyder de romerske numeraler en mulig sekventiering af disse inter-agerende transaktioner. Desuden kan sælger henvende sig til købere med (ii') tilbud, der ikke var en flg. af en (i) forespørgsel: Postkasse-reklame-sager o.lign.
Læseren kan selv modificere ovenstående til ``bedre'' at passe på tjeneste-ydelses-konceptet.
Ovenstående var formuleret sådan som vi opfatter begrebet ``klassisk varehandel''.
Vi gentager: Ved en agent forstås en mekanisme (en person eller en datamatiseret process), der agerer på vegne af en kunde, detail-handel, grossist eller fremstillings-virksomhed. Agenter interagerer med enten købere, sælgere, agenter eller mæglere.
I ``klassisk varehandel'' kan man bede sin nabo om at handle for én. Naboen er da éns agent. Og en detail-handler kan reklamere gennem TV, radio, i aviser, eller gennem ``tele-marketing'': Mål-rettet telefon-salg. TV-stationen, radio-stationen, avisen, hhv. tele-marketing-firmaet (der yder en tjeneste) er da detail-handlerens agent.
Vi gentager: Ved en mægler forstås en mekanisme (en person eller en datamatiseret process), der bringer potentielle købere, sælgere, agenter, eller andre mæglere sammen med det formål at formidle en handel.
I ``klassisk forretning'' kan en konstellation af købere og sælgere i fællesskab, men typisk urelaterede, tids- og steds-uafhængigt af hverandre, engagere en mægler, til eksempel et firma der bringer disse parter (købere og sælgere) sammen med henblik på design og konstruktion af f.eks. et nøgleklart kraft/varme-værk.
Vi opfordrer læseren til selv at eventuelt omfortolke eller revidere den tidligere anførte liste af køber/sælger transaktioner således at den er tilpasset agenter og mæglere.
Hidtil har vi antaget en forsynings-kæde der blot involverede private virksomheder (detail-handlere, grossister, fremstillings-virksomheder (fabrikker), agenter, og mæglere), hhv. borgere. Og vi har set på transaktioner mellem disse to parter (B2P, P2B, og P2P).
Vi skal nu udvide transaktions-begrebet til, foruden `handel' (med varer og tjeneste-ydelser) også at omfatte `forretning' i bredeste forstand, samt endelig også at involvere det offentlige: Stat, amt og kommune (O). Vi skal nedenstående forsøge antyde hvad vi forstår ved et ``udvidet transaktions-begreb''.
Vi lader ovenstående ``stå for sig selv'', og overlader til læseren at ``boble'' videre.
Vi har skitseret et bredt spektrum af handels og forretnings-begreber.
Hvad vi ikke har nævnt er de ``samtale-transaktioner'', de, med et moderne begreb hentet fra lingvistikken, ``speech acts'', som udøves af partnerne i en handels-transaktion, stort set ligegylding hvilken af de ovenfor antydede. Vi har ej heller nævnt de former for ræssonnementer partnerne hver for sig, men under indflydelse af ``samtalerne'', foretager -- specielt de modal-logikker der her bringes i brug: Temporale, epistemiske, deontiske, oma.
Med udgangs-punkt i netop de just ovenfor antydede ``speech act''-teorier og modal-logikker, med udgang i disse, er det så at vi mener at kunne tilføre emnet E-forretning nogle dimensioner som går langt ud over dagens E-handels-trivialiteter. Mao.: Kun veltrænede dataloger cum informatikere kan virkelig ``løfte'' brugen af IT.
Der optælles 11 eksempler på krav til programmel er understøtter planlægning og drift af fragmenter af et E-forretnings-system:
Vort finans-sektor-domæne består, ``udpluks-vist'', af flg. entiteter: Kunder, banker, kredit-anstalter, børsmæglere & børser, forsikrings-virksomheder, og kredit-korts-virksomheder. Disse, deres aktiviteter og interaktion, beskrives nedenfor.
Essensen i vort finans-sektor-domæne er at penge (generelt: værdi-papirer cum værdi-instrumenter) ``skifter hænder'': Indsættes på lønkonti, hæves derfra, enten som rede penge, eller overføres til låne- og spare-konti, eller til køb af værdi-papirer, eller til betaling af forsikrings-præmier, eller indsættes på dertil egnede konti fra salg af værdi-papirer, eller modtaget som flg. af udbetalt forsikring, og meget, meget andet.
En afledet essens ved vort finans-sektor-domæne er at kunder og finans-virksomeheder har financiel nytte heraf: Får sikkerhed og rimeligt afkast af indsatte midler, hhv. opnår en rimelig profit, herunder at enhver financiel tjeneste, på, for kunderne rimelig vis, bidrager til firmaernes indtjening (``value added services'') -- for derved at sikre disse virksomheders stabilitet og dermed tjener kundens sikkerhed.
Aht. det flg. skitserer vi her spektret af værdi-papirer, også kaldet værdi-instrumenter: Rede penge (i diverse valutaer), checks, kreditkorts-``slips'', skøder, pantebreve, gældsbreve, obligationer, aktier, optioner, etc. Ethvert værdi-papir har en handels-værdi (evt. forsk. købs-, hhv. salgs-værdier). Sådanne værdier ændrer sig løbende, har en kurs.
Der er forsk. typer banker: De hvor Du og jeg har vores lønkonti, sætter penge ind (på sådanne eller spare eller andre konti), hæver dem, låner penge (får kasse-kredit), etc. Og der er andre typper banker: Investerings-banker, kredit-banker (i forb. med f.eks. huslån oa.), etc.
For den for os almindeligste type bank anføres: En kunde kan have indtil flere konti. Enhver konto har et unikt nummer. Flere kunder kan dele samme konto. En konto kan oprettes, ``fryses'', og nedlægges; der kan indsættes indskud på, og hæves beløb fra en konti; man kan anmode om et konto-udtog, dvs. en liste over ``seneste'' bvægelser på en konto. Banken kan tilskrive renter til en positiv, og hæve renter fra en negativ konto. Kombinationer af hævning fra og indskud på konti svarer til overførsel mellem konti. Disse kan inludere ``konti'' i andre financielle institutioner: Forsikrings-anstalter, børs-mæglere, mv.
Og meget andet.
Der er flg. fire ``størrelser'' at tage hensyn til her: Et aftryk af et kredit-kort, to banker, sælger's, hhv. køber's, og en ``clearing''-central.
Et kredit-kort udtrykker at dets ejer (køber) har en ``vis kredit'' i den financielle virksomhed der står bag kortet: En bank eller tilsv. Vha. et kredit-kort kan man ``effektuere'' betaling for en handsel. Købers kredit-kort ``aftrykkes'' af sælger, salgs-beøb, dato, sælgers og købers identitiet (dvs. underskrifter) registreres på kortet. Sælger's kopi af aftrykket præsenteres i sælgers bank. Sælgers bank videre-sender denne kopi til den ``clearing''-central der er agent for kredit-kort-firmaet og de to banker. Registrering (dvs. ``clearing'') betyder at købers bak påtager sig skyld og derved står inde for at det anførte beløb hæves fra en dertil designeret køber-konto og overføres til en dertil designeret sælger-konto.
Det ``bagved-liggende'' kredit-kort-firma anfører overførsel, dvs. transaktionen ved næste konto-udtog.
Og meget andet.
Børs-sektoren handler med værdi-papirer.
Ejere (dvs. sælgere) af disse præsenterer ønsker (tilbud) om salg -- til en børs-mægler -- ved, f.eks. at angive navn og type på værdi-papiret, antal (styk) der ønskes solgt, salgs/tilbuds-perioden, samt et ``spænd'': absolut laveste pris for eventuelt salg, hhv. akceptabel ``højeste'' pris til hvilken et salg ubetinget kan finde sted -- idet sælger forventer at børs-mægler så vidt muligt sælger til denne pris, eller gerne højere, men akcepterer salg blot over minimum pris hvis `markedet' så betinger.
Købere af værdi-papirer præsenterer ønsker (tilbud) om køb -- til en børs-mægler -- ved, f.eks. at angive navn og type på værdi-papiret, antal (styk) der ønskes købt, købs/tilbuds-perioden, samt et ``spænd'': absolut højeste pris for eventuelt køb, hhv. akceptabel ``laveste'' pris til hvilken et køb ubetinget kan finde sted -- idet køber forventer at børs-mægler så vidt muligt køber til denne pris, eller gerne lavere, men akcepterer køb blot over minimum pris hvis `markedet' så betinger.
En børs-mægler ``bruger'' nu børsen som et instrument til at tilgodese dets kunder -- der jo typisk vil være en blanding af sælgere og købere -- og børsens andre børs-mægleres købende og sælgende kunder.
Og meget andet.
Der er her tale om forskellige former for forsikrings-anstalter: livs-, pensions-, syge-, familie- (hus, brand, indbo (tyveri, røveri), mm.), arbejdsløsheds-, risiko-, oma. forsikrings-anstalter.
Ved en forsikring forstås * * * ... Mere tilkommer siden
En forsikring kan tegnes (oprettes) eller opsiges, jævnlige forsikrings-præmier indbetales, og en forsikring kan nedlægges -- hvorefter en evt. ``balance'', alt efter forsikrings-typen, kan udbetales. Krav på forsikrings-godtgørelse kan rejses, afvises, justeres og evt. honoreres. Forsikrings-præmier kan forhøjes eller nedsættes.
Overførsler af penge-beløb finder, som regel, sted, mellem nærmere designerede bank-konti og forsikrings--konti.
Og meget andet.
Der optælles 7 eksempler på krav til programmel er understøtter planlægning og drift af fragmenter af et finans-system:
Vort ``flow''-system-domæne består af flg. entiteter: Produktions-ressourcer (mennesker, maskiner, penge), materialer, planer for brug af (produktions- og materiale-) ressourcer, og disse planers udførelse vha. mennesker, maskiner, penge og materialer.
Én måde at anskue essensen i vort ``flow''-system-domæne er at tale om projekter og produktion. Vi skal her anskue disse to begreber som værende identiske: Projekter producerer ``resultater'', dvs. fremstiller manifestérbare produkter eller yder mere eller mindre manifestérbar service (konsulentbistand).
Produktion, gennemførelse af dele af et projekt, forstås som en process.
Essensen i vort ``flow''-system-domæne er at produktion sker ved at diverse produktions-ressourcer bringes sammen og samlet ``påtrykkes'' materiale-ressourcer, ogat denne ``påtrykning'' derved omvandler disse materiale-ressourcer til mellem- eller slut-produkter. Produkter er blot en form for ressource.
Materiale-ressourcer er typisk sådanne ressourcer som kun kan bruges (kun kan ``processes'') éngang. Tilsvarende for de financielle produktions-ressourcer. Maskin- og menneske-ressourcer, i modsætning hertil, kan genbruges, som oftest serielt, én efter én.
Eksempler på materiale-ressource-type: jern (I-, H-, oa. profil jern-bjælker, stål-plader, mv.), træ (planker, lister, finer-plader, mv.), olie (petroleum, benzin, terpentin, mv.), ilt, etc.
Materiale-ressourcer har attributter, og til attributter kan der knyttes værdier og indikatorer (f.eks. værdi-intervaller).
Eksempler på materiale-attributter: Stål's jern, krom, nikkel oa. metal-egenskaber. En træbjælke's mål-, vand-, harpiks-, oa. egenskaber. Eksempler på attribut-værdier: 18% krom indhold, 8% nikkel indhold, 3 fod 4 tommer, etc.
Ved en engangs-forbrugbar produktions-ressource forstås typisk sådanne som tid, energi og klar- og rengørings-ressourcer (vand, ilt, boreolie). Ingen af disse er materiale-ressourcer: De indgår ikke i resultatet af en produktion-process.
Ved en flergangs-forbrugbar produktions-ressource forstås et rum (bygning: kontor, fabrik), maskine eller et menneske.
Eksempler på maskiner: Sav, høvl, bor, mv.; katalysator (tårn), bunsen-brænder, mv.
Produktions-ressourcer påtrykkes materiale-ressourcer efter en eller anden ``mønster''. Nogle serielt, andre parallelt: Materiale-ressourcerne m, m', ..., m'' bearbejdes først af produktions-ressource p, dernæst af produktions-ressource p', etcetera, p''. Eller produktions-ressourcerne q, q', ..., q'' bearbejder samtidigt respektive materiale-ressource-mængder mm, mm', ..., mm''.
En produktions-plan er at ligne ved en orienteret, acyklisk graf hvis éntydigt navngivne knudepunkter står for hver sin bestemte (atomiske, eller enkelt-) bearbejdnings-process vha. en bestemt produktions-ressource, og hvis annoterede kanter står for materiale-ressourcer: én kant, én bestemt type materiale-ressource af bestemte attribut-værdier.
Ved produktions-planlægning forstås konstruktionen af en produktions-plan: En graf. Produktions-planlægning fastlægger, mao., hvilke knudepunkter produktions-grafen skal have, hvilke bestemte produktions-ressourcer der skal knyttes til hvilke knudepunkter, hvilke bestemte materiale-ressourcer der skal knyttes til hvilke kanter.
Til knudepunkter kan man knytte estimater eller aktuel forbrugt process-tid, energi, mmm. Til kanter kan man knytte tid for, og arten af distribution af de til en kant knyttede materiale-ressourcer mellem kantens to knudepunkter.
Ved produktions-udførelse, dvs. ved produktion forstås nu en mængde sekventierede og parallelle bearbejdnings-processer således at disse kan siges at svare til en fortolkning af en produktions-plan: Så-at-sige en ``eksekvering'' baseret på en graf. Enten eksisterende, på forhånd fastlagt, eller ikke-eksisterende, men, som, alt efter produktionen ``skrider frem'', bliver defineret ved denne produktion.
Da grafen er acyklisk vil der være mindst ét knudepunkt som ingen ind-kanter har. Disse knudepunkter har, som regel, ud-kanter, og disse knudepunkter svarer til initiering af respektive første bearbejdnings-processer. Der vil også være mindst ét knudepunkt som ingen ud-kanter har. Disse knudepunkter har, som regel, indd-kanter, og disse knudepunkter svarer til afslutning af respektive sidste bearbejdnings-processer.
En virksomhed besidder typisk flere enheder af hver ressource. Og samme virksomhed engagerer sig typisk i produktion af én eller flere produkter. Til enhver tid er en bestemt mængde ressourcer knyttet (``bundet'') til produktion af et bestemt (antal) produkt(er).
Ved ressource-ledelse forstås nu planlægning af produktions-planer og overvågning og styring af produktion efter sådanne planer således at ressource-forbrug ``følger'' på forhånd udarbejdede produktions-planer.
Vi har skitseret væsentlige elementer ved produktion, produktions-planlægning, de dertil knyttede resssourcer, deres planlægning og brug. Vi har fokuseret entydigt på produktion af manifestérbare produkter. Men, mener vi, man kan udskifte ordet produkt med service, produktion med projekt, og -- med trivielle andre justeringer af begrebs-apparatet (materiale-ressource, produktions-ressource, etc.) -- derved opnå at begrebet en plan kan overføres til også at ``gælde'' for service-ydende projekter.
Bemærk at vi ikke har taget særlig notits af ressource-distributions- (i betydning transport-) problematikken. Vi anskuer produktions- og transport-problematikkerne for ``ortogonale''. Og vi mener at en forenklet variant af logistik-problematikken -- således som behandlet i Afsnit B.2 -- kan tilføres (kan ``skrues'' på) produktions-problematikken (``mere-eller-mindre'') uafhængigt af denne.
Der optælles 10 eksempler på krav til programmel er understøtter planlægning og drift af fragmenter af et projekt- cum produktions-planlægnings- og eksekverings-system:
Vor sundheds-sektor-domæne består af flg. entiteter: Borgere (raske eller potentielt syge), privat praktiserende læger, sundheds-sygeplejersker, apoteker, klinikker af forskellig at (fysio-terapeuter, kiropraktikere, m.fl.), klinisk analyse laboratorier, hospitaler, rekonvalescent centre, den farmaceutiske industri, den mediko-tekniske industri, sygeforsikrings-anstalter, samt det offentliges overvågning og styring af denne sektor, i Danmark gennem Sundhedsstyrelsen, Statens Seruminstitut, Lægemiddelstyrelsen, og Sundhedsministeriet. Disse, deres aktiviteter og interaktion, beskrives separat nedenfor.
Essensen i vor sundheds-sektor-domæne er at borgerne bliver syge og skal helbredes: At borgerne ``går til lægen'', undergår klinisk analyse (får taget blodprøver, Röntgen billeder, MR-skanninger, elektro-kardio-grammer, mm.), henter medicin på apoteket, får besøg af den lokale sundheds-sygeplejerske, kommer på hospitalet, blir' behandlet af fysioterapeuter og kiropraktorer, kommer på rekonvalescens, oa.
Der er, mao., tale om et ``flow'' (en rute-føring) af mennesker, materialer (medicin, bandage, krykker, mm.), information (recepter, syge-journaler, mm.), og styre-signaler.
* * * ... Materiale forventes udarbejdet til næste version
* * * ... Materiale forventes udarbejdet til næste version
* * * ... Materiale forventes udarbejdet til næste version
Der optælles 10 eksempler på krav til programmel er understøtter planlægning og drift af fragmenter af et sundheds-sektor-system:
This document was generated using the LaTeX2HTML translator Version 99.1 release (March 30, 1999)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 infra
The translation was initiated by Dines Bjorner on 2001-11-18