Når Sir Isaac Newton undersøger det nærmeste univers og opdager tyngdekraften oa. fænomener og så beskriver disse matematisk, ja da er det at han bedriver domæneanalyse. Beskriver det som er, eller måske snarere som synes at være. Newtons love blev ikke udviklet for siden at kunne formulere krav til mekaniske konstruktioner, men for at forstå dette nærmeste, inklusive det planetære, univers. For at kunne ``regne på det'' og forudsige effekt. Tilsvarende, før informatikeren skal udspørge kunder og brugere om hvad de forestiller sig at deres indforskrevne datamatik skal kunne yde, hvilke faciliteter det bør tilbyde -- før dette -- skal der først opstilles en teori for, en model af, domænet.
Eksempler på et lidt større, og derfor muligvis et mere interessant, domæne er: Et jernbanesystem (forestil dem DSB for 2-3 år tilbage). Hvad er DSB? Hvorfor ønsker vi at stille dette spørgsmål? For det første fordi DSB bruger datamatik. Her og der og alle vegne. For det andet fordi DSB stedse ønsker at sammenkoble denne datamatik i alt større, sammenhængende systemer for derved bedre (i) strategisk at styre sine resoursser (opgradering, nedlæggelse ``downsizing''), for bedre taktisk at planlægge disse spatialt (allokering) og tidsmæssigt (``schedulering''), og for bedre operationelt at tage disse i brug (afsending af tog, varetagelse af gods, salg af billetter, etc.). Jo mere disse mange meget forskellige begreber griber ind i hver andre, desto større et behov er der for at opnå en ``total'' forståelse. For blot tilnærmelsesvis at skitsere problematikken lad mig nævne nogle af komponenterne i en domæneteori for DSB. Vi kunne for eksempel begynde med det faste inventar: jernbanenettet. Af hensyn til signallering skal netbeskrivelsen bygges op fra de mindste dele: sporene, de ubrudte (lige eller kurvede), sporskifter, kryds, mv. Dernæst disses sammensætning til stationer og linier mellem stationer. Indenfor stationer er vi interesseret i både passager og godstrafik. Derfor skal de spor beskrives hvor passagertog holder (perroner og klargøring) og hvor godstog laster og losser gods. Også de særlige rangérarealer skal beskrives. Enkle og sammensatte sporbeskrivelser er dels statiske: Hvorledes hænger det hele sammen?, dels dynamiske: Hvorledes opfører tog sig? Beroende på tilgangsvinklen og abstraktionsniveauet beskrives signalering og tilstand af sporskifter, eller dette beskrives ikke. Det var nettet -- og der er meget at tage vare på! Så til trafikken: togs dynamiske positioner på sporlegemet. Vores beskrivelse bør ikke idealiseres: også togsammenstød skal modelleres for at vi siden kan kravspecificere, ja blot tale om det uønskelige i dette. Dernæst tilkommer så f.eks. passagersiden: rejseforespørgsler, billet og pladsreservation, køb, annullering og brug (eller ikke-brug!). Tilsvarende for gods: Hvor befinder et specifikt stykke indskrevet gods sig pt? Vi ``domæner'' videre: Regler og forskrifter for afsending af tog, for varetagelse af gods, mv. Allokering og schedulering af jernbaneresoursser: de flytbare såvelsom de stationære: de materielle såvelsom staben. Og videre igen: Udbygning eller indskrænkning af disse resoursser: Planlægning af nye tjenester, linjer, stationer, spor, tog, time tabeller, osv. Nedlæggelse af samme. Osv. Vi begynder at se billedet. Et stort system, megen naturlig tekstbeskrivelse, mange matematiske formler. Og alt dette skulle vi gerne have på plads, valideret og dokumenteret, før vi kan gå videre med DSB og tale om dets IT Strategi! Dvs. også før vi kan tale om krav til bestemt datamatik. Og for at sikre os at vi har forstået dele af hvad DSB er (``informatisk'' set) bør vi også ``lige'' have afklaret et passende antal mere teoretiske forhold såsom: ``Kirschoffs lov for jernbanedrift'': Over et passende, af problemstillingen, afledt tidsinterval bør antallet af tog der ankommer til en station, minus det antal tog der, i dette tidsinterval, afslutter deres rejse ved denne station plus de der påbegynder en rejse være lig det antal der forlader denne station i dette interval. Eller: (``Gud spiller ikke med terninger''): to tog på vej ned af en linje, f.eks. i samme retning, kan ikke pludselig byttes om (således at det tog der før var forrest nu bliver bagerst)! Eller (ingen ``spøgelsestog''): Hvis et tog er på en banestrækning til tiderne t og t', hvor f.eks. t' er blot nogle få sekunder senere end t, ja da vil toget være på denne banestrækning til enhver tid mellem t og t'.
Ovenfor har jeg alene koncentreret mig om det basale i domænet. Dertil kommer dets allerede eksisterende teknologiske understøttelse. Åbne og lukkede banestrækninger er markerede, ikke ved bomme, men bl.a. ved tilsvarende åbne eller lukkede signaler. Signaler er blot een måde teknologisk at realisere spors brugstilstande. Tilsvarende: Hvorfra véd vi om togs positioner? Måske fra optoelektriske observationer. Og også sådant udstyr kan svigte (og vi har reelt set ``spøgelsestog''). Så alt, hvad der findes af tilfældige, tidsbestemte måder at understøtte jernbanedriften på, skal ligeledes beskrives. Og vi er slet ikke kommet til datamatikken endnu.
Det er klart at beskrivelsesværktøjerne: Specifikations- og definitionssprog skal kunne meget. Meget mere end den klassiske analyse kan tilbyde. Ihvertfald tilbyde på en måde, der gør det forholdsvist enkelt at bruge og ekspressivt at læse. Fra sprogbeskrivelser skal vi gerne formelt kunne bevise en lang række egenskaber. Så beskrivelsessprogene skal forsynes, hvis de ikke allerede er logiske, med et bevissystem, osv. I den klassiske analyse, og i de varianter der udforskes i f.eks.\ adaptiv og stokastisk styreteori, kan man beskrive et togs opstart fra en station samt dets ordinære rejse ned ad sporet: langs lige strækninger, i kurver, over broer og gennem tunneller. Under alt dette forventes toget accelerere, decellerere eller køre med konstant hastighed. Men hvad nu hvis elektriciteten svigter og motoren standser, eller en ko kommer på tværs af skinnerne? Ja, her er det at datalogien kan tilbyde sprog, der tillader en logisk sammenhængende, konsekvent, komplet og konsistent beskrivelse af de mange diskrete tilstandsovergange som klassisk kontinuert analyse ikke specielt er indrettet på.
Mao.: Domæne-ingeniørarbejdet har mange facetter, betjener sig metodisk af mange principper, teknikker og værkøjer. Ved IT/DTU arbejder forskere i SEKTION FOR PROGRAMMELSYSTEMER på at udvikle domæne-modellerings-metoder. For øjeblikket påbegynder man projekter der forsøger forstå hvorledes man besvarer bl.a. flg. spørgsmål: Hvad er en Bank? (eller, for den sags skyld, en hel finansverden med bank-, forsikrings-, børsmægler- og mange relaterede tjenester). Hvad er Hovedstadens Trafik? Hvad er Lufttrafik? Hvad er en fremstillingsindustri? Det sidste er ikke bare en mindre variant af CIM (Computer Integrated Manufacturing), men omfatter en hel industri med dens (på engelsk) `suppliers, consumers, producers & traders'. Hele markedet skal med før vi opnår en troværdig model af ethvert enkelt firmas funktioner.