TILLRÄCKLIGT utvecklad teknologi kan likna magi. Trollkarlens hatt, mjölnarens kvarn och sekreterarens dator är alla lika häpnadsväckande för den oinvigde. Men det finns en viktig skillnad: vi litar på att kvarnens konstruktörer har begripit hur hjulen ska snurra. Den som använder magi däremot riskerar oväntade och oönskade resultat då en trollkarl inte alltid är herre över sin konst.

På detta sätt kan man med fog klassa datorer som trolltyg. Hackern är vår tids häxmästare som frambesvärjer fantastiska och förfärande ting utan att förstå dem. Datorsystem styr nu allt från telefonväxlar till flygplan och kärnkraftverk trots att ingen, inte ens deras skapare, kan redogöra för varför och under vilka förutsättningar de fungerar.

Modell och verklighet

Vi informationsingenjörer däremot arbetar i bästa fall med ofullständiga och tvetydiga ritningar. Oftast skruvar vi snabbt ihop ett system och vill kompensera bristen på planering med en grundlig utprovning. Men tidiga flygturer kan lätt sluta i Gripen-gropen. Funktionsfel kan inte förutsägas och när de yttrar sig i den lakoniska dödsrosslingen "system error" blir det ett styvt jobb att spåra orsaken och ett sisyfosarbete att åtgärda den, eftersom varje förändring kan rubba andra delar av systemet.

I datorernas barndom var minnet mycket litet och programmen följaktligen små och få. Programmerarna satte en ära i att hålla hela system i huvudet och dödade lusar, programfel, genom att tänka djupt och länge. Idag innehåller den enklaste persondator miljontals programinstruktioner och fortfarande försöker vi avlusa i sådana intellektuella maratonlopp. Anledningen är att det saknas effektiva alternativ. Vi vet inte hur ritningar och modeller ska se ut för att vara till riktig hjälp. När vi kan göra sådana för rymdraketer, järnvägsbroar och pacemakers, varför går de inte att göra för datorsystem?

Tanke och materia

En rimligare förklaring är att informationsteknologin behandlar immateriella konstruktioner som inte låter sig beskrivas med välkända mekaniska egenskaper som vridmoment och friktion. När datorerna arbetar är deras fysiska attribut oviktiga, det intressanta är deras beteende. Men exakt vad menas med "beteende" och i vilka termer kan det göras begripligt? Man vill gärna tänka på det materiellt: knappar trycks in, lampor tänds, signaler åker genom ledningar. Eller man kan se det antropomorfiskt: datorn tror, maskinen vill, systemet surar. Men de materiella liknelserna är för begränsade och antropomorfin för vag för att vara ritningsunderlag.

I vanliga ingenjörsdiscipliner sätter materien en gräns för storlek och uppbyggnad; datorsystemens "beteenden" begränsas bara av programmerarnas uppfinningsrikedom. Så länge vi inte ens har en terminologi för att beskriva dem kan vi inte hoppas på att bygga dem ingenjörsmässigt.

Tillräckligt utvecklad teknologi kan likna magi...

Form och funktion

I andra fall söker forskningen nya vägar. Så kräver exempelvis AXE-telefonernas stjärnor och fyrkanter ett kvalitativt snarare än kvantitativt resonemang, där det viktiga är hur funktionerna kan användas och kombineras och inte hur hårt knapparna kan tryckas in. Man vill kunna uttrycka egenskaper som "när abonnenten har beställt vidarekoppling kommer inkommande samtal att skickas vidare" utan att lämna utrymme för olika tolkningar. Därmed blir telefonens funktioner tillgängliga för en logisk analys, som kan avslöja att telefonen blir obrukbar om den vidarekopplas till sig själv eller att telefonväckning inte fungerar om man har vidarekoppling. Funktionsbeskrivningen är alltså en slags modell som används för att förutsäga beteendet.

Forskningsproblemen här är att definiera logiska språk och metoder där resonemangen blir enkla, helst så enkla att till och med en dator kan utföra delar av dem. En bärande idé för att hantera stora beskrivningar är att sammanföra funktionerna i grupper som kan analyseras separat. Men för att de ska vara ritningar i ingenjörskonstens mening måste det också gå att bygga efter dem. Detta är särskilt svårt för distribuerade system, alltså system som består av flera samverkande delar på olika platser. Systemets form och uppdelning i komponenter bildar en struktur medan dess funktionsgrupper bildar en annan. En funktion kan beröra flera komponenter och en komponent kan i sin tur bidra till flera funktioner.

Först de senaste åren har resultaten från denna forskning börjat visa sig. I modern systemutveckling insisterar man på en begriplig struktur för både form och funktion. Nya språk tvingar programmerarna att ange hur olika programdelar kan kombineras för att undvika att de sätts ihop på fel sätt. Vid säkerhetskritiska tilllämpningar i kärnkraftsverk krävs en logisk analys som bevisar att beteendet är acceptabelt. Men övergången från kaotisk till välordnad produktion är inte smärtfri. Den inskränker ju friheten för alla våra dataexperter och programmeringskonstnärer.

Datorerna har kommit för att stanna men deras svartkonst kan vi klara oss utan. Som så ofta förut bygger ingenjören hus där magikern brutit mark. Och det som nu är trollkarlens hatt blir mjölnarens kvarn för våra barn.

Joachim Parrow

är född 1956 i Uppsala. Han disputerade 1986 i datorteknik vid Uppsala universitet där han också blev docent 1990 och adjungerad professor 1992. Efter gästforskarvistelse i Edinburgh 1986-89 arbetade han på Swedish Institute of Computer Science i Kista som ledare för forskningsgruppen i formell konstruktionsmetodik. 1994 utnämndes Joachim Parrow till professor vid KTH.