SE504860C2 - Referensmodell för gränssnitt - Google Patents

Description

504 860 idag ett antal problem.

Om konstruktören behöver veta mer om gränssnittet än vad som framgår av gränssnittsbeskrivningen måste han idag titta efter hur andra användare använt gränssnittet. Detta kan dock vara felaktigt använt, eller kanske är förutsättningarna an- norlunda.

Konstruktören kan också titta i det andra programmet för att se hur funktionerna konstruerats. Detta strider emeller- tid mot hela principen att använda gränssnitt. Om det andra programmet ändras utan att dess konstruktör vet att användarpro- grammet har tagit fasta på vissa egenheter i det andra program- mets konstruktion, är det inte alls säkert att det kommer att fungera längre.

Om konstruktören av användarprogrammet vill prova sitt program och dess användning av gränssnittet, kan han köra det tillsammans med en tillgänglig version av det andra programmet.

När konstruktören lyckats få de båda programmen att fungera tillsamans, visar dock detta endast att hans program fungerar ihop med just detta specifika utförande av det andra programmet.

Om det andra programmet uppdateras, eller byts ut mot ett annat program, som erbjuder sama funktioner, är det inte alls säkert att det fungerar längre.

Användarprogrammets konstruktör kan kanske också få problem med det andra programmet, som innebär att det kan vara svårt att generera vissa felfall. Det kan t.ex. helt enkelt vara sä, att några av felen aldrig kan inträffa i det andra program- met, sä som det i det aktuella fallet blivit utfört. Om kon- struktören då skriver en egen enkel variant av det andra pro- grammet finns det stor risk för att han också bygger in sina egna missuppfattningar om hur gränssnittet fungerar.

Några av problemen i samband med konstruktion av gräns- snitt kan sammanfattas enligt följande: - Det saknas i allmänhet semantiska definitioner av gränssnitt. I den mån de finns är de sällan kompletta och sällan strikt definierade, vilket gäller särskilt för sådana förlopp, som avviker från normalfallet.

- Det saknas oftast testprogram för den som använt ett gränssnitt, som kan verifiera att denna användning alltid är korrekt, oberoende av interna förändringar i det samarbetande 504 860 3 programet, så länge inte själva gränssnittet berörs.

- Ett enstaka program~kan därför inte certifieras självständigt utan bara tillsammans med specifika utgåvor av samarbetande program. Varje gång ett program ändras måste inte bara det, utan även alla samarbetande program omcertifieras.

Av EP 474,339 framgår en teknik för att tillhandahålla ett klientgränssnitt för ett objektorienterat anrop av en appli- kation. Man vill undvika problem med att användare tidigare vid heterogena nätverk varit tvungna att använda det speciella gränssnitt som varje enskild applikation har krävt. Avsikten är att àstadkoma interaktion av processer på ett objektorienterat sätt. Klientapplikationer kan anropa andra applikationer genom sändning av globalt igenkända meddelanden med parametrar. Man använder en klient/server-modell i vilken en klient genererar önskemål och en server svarar på önskemålen.

EP 540,166 anger en teknik vid ett objektorienterat distribuerat system baserat på en klient/server-modell. Närmare bestämt rör det sig om att en klientprocess skall bestämma huruvida två objektlimplementerade av en första respektive andra serverprocess är ekvivalenta, varvid objektorienterade gräns- snitt är anordnade för att manipulera respektive objekt. Detta skall ske i samband med objektorienterad programmering vid ett distribuerat datorsystem.

I EP 278,317 beskrivs en teknik för att hindra en process i ett klientprocessystem att accessa data i ett klient- cacheminne, som har modifierats i en server. Nämnda data har accessats i servern och sänts till klienten. Servern innehåller en permanent datafil på en disk och har ett cacheminne, som utnyttjas av serverns lokala processorer. Klientprocesser kan dock accessa filen under utnyttjande av serverns och klientens cacheminnen. Filblock från disken lagras i serverns cacheminne och klienten mottar via nätet filblock från detta och lagrar blocken i klientcacheminnet. Datablocken i det senare testas sedan med avseende på validiteten i klientprocessen och om data befinns vara giltiga, accessas de från klientcacheminnet.

I JP 5-11983 anges en metod för att verifiera gräns- snitt mellan program i olika deklarativa språk. I organ för att framställa en gränssnittsdefinierande fil inmatas en defini- tionsinformation, som definierar ett gränssnitt mellan program 504 860 4 svarande mot olika deskriptiva språk, för att framställa en definitionsfil för ett interprogramgränssnitt. I konsistenskon- trollorgan inmatas en programdeskriptiv språkkällfil och en interprogramgränssnitt definierande fil för kontroll av gräns- snittkonsistens. Organ finnes vidare för att automatiskt korri- gera interprogramgränssnittet baserat på resultatet av konsis- tenskontrollen.

I JP 63-86030 beskrivs ett system för länkning mellan olika programmeringsspråk. En CPU innefattar en C-programmodul, en prologtolkande modul, samt en snabb nodaccessmodul såsom funktionsdelar. CPU n innehåller även en gemensam dataarea till- samans med en prologstack, en stor databas, samt en informa- tionsbas säkrade i ett föreskrivet minnesutrymme. Dataöverför- ingsstyrning utförs mellan dessa moduler genom den gemensamma dataarean och två exklusiva stackar.

I JP 62-293347 beskrivs ett utvecklingssystem för att koppla ihop program med olika programmeringsspråk.

I EP 498 130 beskrivs en metod för att verifiera kompa- tibiliteten mellan programmoduler, som kommunicerar med varandra i ett datorsystem. Varje komponent av ett flertal interagerande systemkomponenter är associerad med en versionsidentifierare.

Versionsidentifieraren lagras i ett av de andra komponenterna accesserbart ställe. Varje komponent läser oberoende Versionsi- dentifieraren hos varje annan komponent med vilken den mäste interagera och jämför detta värde med ett internlagrat kompati- bilitetsregister för att bestämma om den andra komponenten satisfierar kraven på kompatibilitet med den verifierande kompo- nenten. En komponent som upptäcker en inkompatibilitet signale- rar ett fel till systemet.

I EP 495 279 anges en metod för kommunikation mellan tvâ objektorienterade program skrivna i olika programmerings- språk. En generell sändmeddelandefunktion är anordnad mellan de båda programmen för att styra utbytet av meddelanden. För att uppnå detta har den generella sändmeddelandefunktionen access till en beskrivning av klasserna i det andra datorprogrammet.

Vid uppnàdd access till en sådan beskrivning kan den generiska sändmeddelandefunktionen effektivt överföra meddelanden mellan de olika datorprogrammen och även åstadkomma möjlighet till skapande av nya objekt. 504 860 5 I EP 371 942 beskrivs ett gränssnitt mellan applikation och databashanterare. Ett gränssnittsystem innefattar ett fler- tal tillämpningsprogramgränssnitt i form av en uppsättning realtidstjänster vilka tillhandahåller en förkompilatorutveckla- re med all funktionalitet som krävs för att kommunicera med en databaskärna i realtid.

I EP 371 941 beskrivs ett gränssnitt mellan applikatio- ner skrivna i olika programmeringsspråk och databashanterare eller liknande. För var och en av ett flertal funktioner, som stöds av mjukvaran, definieras ett generiskt applikationspro- gramgränssnitt eller ingàngspunkt, som har ett flertal paramet- rar i en konsistent form, som krävs av systemet för att exekvera funktionen. Varje ingángspunkt kan anropas av ett applikations- program skrivet i nàgot av ett flertal språk och transformerar anropets parametrar till konsistent generisk form för exekvering av mjukvarusystemfunktionen_ I EP 343 682 beskrivs en metod för utveckling och testning av mjukvara. Konstruktion och test är direkt kopplade till varandra pá så sätt att under konstruktionsförloppet kon- struktionsdata automatiskt kan utnyttjas vid testen.

I EP 315 493 beskrivs ett virtuellt gränssnitt som gör mjukvara oberoende av datormiljön, dvs. hårdvaran, operativsys- temet osv. Systemet innefattar ett flertal processer för ut-Å förande av en eller flera uppgifter, som krävs av tillämpnings- mjukvaran i en eller flera distribuerade processorer hos en heterogen eller "mål"-dator. I realtid förbehandlas programkod hos tillämpningsmjukvaran, kompileras och länkas med system- gränssnittmoduler för att skapa kod, som är exekverbar av ett operativsystem hos máldatorn. Den exekverbara koden, som in- nefattar ett antal funktionella anrop till processerna, körs av operativsystemet för att medge att processerna skall kunna utföra de åtgärder som krävs av tillämpningsmjukvaran.

I US 5 045 994 beskrivs en metod för emulering vid utveckling och testning av stora programsystem. En emulerings- systemomgivning används, som simulerar det verkliga in-/utgàngs- gränssnittet hos tillämpningssystemet. I denna omgivning skapar användaren in-/uttransaktioner för senare exekvering av tillämp- ningssystemet i en skärmdriven, automatiserad mod, som är obe- roende av och vid sidan av tillämpningssystemet. 504 860 6 I "Facilitating Mixed Language Programming in Dis- tributed Systems", Roger Hayes and Richard D Schlichting, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING VOL. SE-13, NO. 12, Dec. 1987, page 1254-1264 beskrivs en metod för att tillåta procedur- anrop mellan olika programmeringsspråk i samma program. Den baserar sig på tillförsel av ett generellt, på avstånd beläget proceduranropssystem för varje språk, och användning av ett typsystem för beskrivning av procedurgränssnitt, liksom data som skall överföras mellan procedurerna. Genom definiering av stan- dardmappningar för varje programmeringsspråk, kan dataomvand- lingar som krävs för tvärspråkanrop åstadkommas, automatiskt i de flesta fall, genom aktiva agenter som ingår i gränssnittet mellan programkomponenter skrivna i olika språk.

Redogörelse för uppfinningen.

Ett allmänt syfte med uppfinningen är att fullständigt kunna definiera ett gränssnitts funktion - dvs. ange en refe- rensmodell för gränssnittet - och att sedan använda denna defi- nition för att certifiera program med avseende på hur de har använt eller erbjudit detta gränssnitt. När interaktionen över ett gränssnitt mellan två programvaruenheter är fastställd, skall uppfinningen medge beskrivning av denna interaktion och ett stöd för att säkerställa att definitionen av interaktionen blir komplett och konsistent.

Ett ytterligare syfte är att ange ett sätt att möjlig- göra provning av ett gränssnitts funktion tillsammans med en programvara, som skall interagera med annan programvara via gränssnittet. Ännu ett syfte är att åstadkomma en referensmodell för ett gränssnitt, som möjliggör att programmen pà gränssnittets båda sidor kan erhålla mer information om motpartens beteende än vad som framgår av den syntaktiska definitionen av gränssnittet.

Närmare bestämt skall denna information innehålla också en semantisk definition, som beskriver vilka beteenden som kan förväntas av motparten och i vilken utsträckning motpartens åtgärder måste kontrolleras.

Ett ytterligare syfte med uppfinningen är att möjlig- göra certifiering av en programvaruenhet, dvs. visa att den fungerar korrekt, även med avseende på samarbete med andra 504 860 7 program via gränssnitt, genom att ange särskilda testprogram, som korrekt återger hela det tillåtna beteendemönstret hos det samarbetande programmet, men i övrigt inte avslöjar något om dess inre struktur.

Enligt en första aspekt innefattar uppfinningen ett sätt att skapa en referensmodell för ett gränssnitt. Detta sker genom att skapa ett första och ett andra hjälpprogram, där det första hjälpprogrammet är ett modellprogram, som simulerar an- vändning av gränssnittet, och det andra hjälpprogrammet är ett modellprogram, som simulerar att det erbjuder funktionerna i gränssnittet. De båda programmen kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de kon- trollerar att ett program på andra sidan gränssnittet ej gör något otillåtet.

Enligt en andra aspekt innefattar uppfinningen ett mjukvarusystem för exekvering i dator, bildande en referensmo- dell för ett gränssnitt. Referensmodellen innehåller första och andra hjälpprogram, där det första hjälpprogrammet är ett mo- dellprogram, som simulerar användning av gränssnittet, och det andra hjälpprogrammet år ett modellprogram, som simulerar att det erbjuder funktionerna i gränssnittet. De båda programmen kan utföra samtliga möjliga och tillåtna operationer över gränssnit- tet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillåtet.

Enligt en tredje aspekt innefattar uppfinningen ett sätt att möjliggöra provning av ett gränssnitts funktion till- sammans med en programvara, som skall interagera med en annan programvara via gränssnittet. Tillsammans med gränssnittet skapas ett första och ett andra hjälpprogram. Det första hjälp- programmet är ett modellprogram, som simulerar sådan användning av gränssnittet att tillsammans med gränssnittet programvara kan provas, vars funktionalitet skall erbjudas via gränssnittet. Det andra hjälpprogrammet är ett modellprogram, som simulerar sådant erbjudande av funktionerna i gränssnittet att tillsammans med gränssnittet programvara kan provas, som skall utnyttja via gränssnittet erbjudna funktioner. De båda hjälpprogrammen kon- strueras så att de kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de vid utprovning av själva hjälpprogrammen, eller vid nämnda provning av gräns- 504 860 8 snittets funktion tillsammans med en programvara, kontrollerar att den med gränssnittet provade programvaran ej gör något otillàtet.

Enligt en fjärde aspekt innefattar uppfinningen ett sätt att möjliggöra provning av ett gränssnitts funktion till- sammans med programvara, vars funktionalitet skall erbjudas annan programvara via gränssnittet. Tillsammans med gränssnittet skapas ett hjälpprogram, som simulerar sådan användning av gränssnittet att tillsammans med gränssnittet nämnda programvara kan provas. Hjälpprogrammet är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att den med gränssnittet provade programvaran ej gör nägot otillåtet.

Enligt en femte aspekt innefattar uppfinningen ett sätt att möjliggöra provning av ett gränssnitts funktion tillsammans med programvara, som skall utnyttja via gränssnittet erbjudna funktioner från annan programvara. Tillsammans med gränssnittet skapas ett hjälpprogram, som simulerar sàdant erbjudande av funktionerna i gränssnittet att tillsammans med gränssnittet nämnda programvara kan provas. Hjälpprogrammet är sä konstruerat att det kan hantera samtliga möjliga och tillåtna operationer det mottager över gränssnittet och ge tillbaka samtliga möjliga responser, samtidigt som det kontrollerar att programmet under provning inte använder gränssnittet pä ett otillàtet sätt.

Enligt en sjätte aspekt innefattar uppfinningen ett sätt att skapa en referensmodell för ett kommunikationssystem, i vilket programvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt frän dessa programvaror av ett gräns- snitt mot respektive programvara. Ett första och ett andra hjälpprogram konstrueras, där det första hjälpprogrammet repre- senterar programvaror, som kommunicerar med varandra via pro- tokollet, och bäde kan agera anropande och svarande i kommu- nikationen. Det andra hjälpprogrammet representerar protokollet.

Det första hjälpprogrammet skapas så att det kan agera som både anropande instans och svarande instans i kommunikationen. De båda instanserna kan utföra samtliga möjliga och tillåtna opera- tioner över gränssnittet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillàtet.

Enligt en sjunde aspekt innefattar uppfinningen ett 504 860 9 mjukvarusystem för exekvering i dator och bildande en referens- modell för ett kommunikationssystem, i vilket programvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från dessa programvaror av ett gränssnitt mot respektive pro- gramvara. Referensmodellen innefattar första och andra hjälppro- gram, där det första hjälpprogrammet representerar programvaror, som kommunicerar med varandra via protokollet, och både kan agera anropande och svarande i kommunikationen. Det andra hjälp- programmet representerar protokollet, varvid det första hjälp- programmet kan agera som både anropande instans och svarande instans i kommunikationen. De båda instanserna kan utföra samt- liga möjliga och tillåtna operationer över gränssnittet, samti- digt som de kontrollerar att ett program på andra sidan gräns- snittet ej gör något otillåtet.

Enligt en åttonde aspekt innefattar uppfinningen ett sätt att skapa en referensmodell, som i ett kommunikationssys- tem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive an- vändarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarprogramvara, som skall kunna kommunicera med befintliga användarprogramvaror. Ett första och ett andra hjälpprogram skapas, där det första hjälpprogrammet simulerar en användarprogramvaras användning av gränssnittet, och det andra hjälpprogrammet simulerar protokollets funktioner. De båda hjälpprogrammen kan utföra samtliga möjliga och tillåtna opera- tioner över gränssnittet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillåtet.

Enligt en nionde aspekt innefattar uppfinningen ett mjukvarusystem för exekvering i dator och bildande en referens- modell, som i ett kommunikationssystem, i vilket användarpro- gramvaror skall kunna kommunicera med varandra via ett proto- koll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarpro- gramvara, som skall kunna kommunicera med befintliga användar- programvaror. Ett första hjälpprogram simulerar en användar- programvaras användning av gränssnittet, och ett andra hjälppro- gram simulerar protokollets funktioner. De båda hjälpprogrammen kan utföra samtliga möjliga och tillåtna operationer över gräns- snittet, samtidigt som de kontrollerar att ett program på andra 504 860 10 sidan gränssnittet ej gör något otillátet.

Enligt en tionde aspekt innefattar uppfinningen ett sätt att med en referensmodell av nyss nämnt slag prova ny anvàndarprogramvara, varvid den nya användarprogramvaran bringas i kommunikationsförbindelse med det första hjälpprogrammet via det andra hjälpprogrammet, varpå operationer tillhandahållna i de båda hjälpprogrammen exekveras.

Enligt en elfte aspekt innefattar uppfinningen ett sätt att skapa en referensmodell, som i ett kommunikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogram- vara av ett motsvarande gränssnitt, möjliggör provning av ny protokollprogramvara. Ett hjälpprogram skapas, som simulerar sådan användning av gränssnittet av en anvàndarprogramvara att tillsammans med gränssnittet ny protokollprogramvara kan provas.

Hjälpprogrammet är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att med gränssnittet provad interproto- kollprogramvara ej gör något otillátet.

Enligt en tolfte aspekt innefattar uppfinningen ett mjukvarusystem för exekvering i dator, och bildande en referens- modell, som i ett kommunikationssystem, i vilket användarpro- gramvaror skall kunna kommunicera med varandra via ett proto- koll, som är skilt från respektive anvàndarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny protokollpro- gramvara. Referensmodellen innefattar ett hjälpprogram, som simulerar sådan användning av gränssnittet av en användarpro- gramvara att tillsammans med gränssnittet ny protokollprogram- vara kan provas, och som är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att med gränssnittet provad protokollprogramvara ej gör något otillátet.

Enligt en trettonde aspekt innefattar uppfinningen ett sätt att med en referensmodell av nyss nämnt slag prova ny protokollprogramvara, genom att bringa två kopior av hjälppro- grammet i kommunikationsförbindelse med varandra via den nya programvaran och exekvera i de två kopiorna tillhandahållna operationer.

Enligt en fjortonde aspekt innefattar uppfinningen ett 504 860 ll sätt att skapa en referensmodell, som i ett kommunikationssys- tem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt frän respektive an- vändarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarprogramvara. Ett hjälpprogram skapas, som simulerar sådant erbjudande av protokollets funktioner via gränssnittet att tillsammans med gränssnittet ny användarpro- gramvara kan provas. Hjälpprogrammet är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gräns- snittet, samtidigt som det kontrollerar att ett program pá andra sidan gränssnittet ej gör nàgot otillàtet.

Enligt en femtonde aspekt innefattar uppfinningen ett mjukvarusystem för exekvering i dator, och bildande en referens- modell, som i ett kommunikationssystem, i vilket användarpro- gramvaror skall kunna kommunicera med varandra via ett proto- koll, som är skilt frán respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarpro- gramvara. Ett hjälpprogram simulerar sådant erbjudande av pro- tokollets funktioner via gränssnittet att tillsammans med gräns- snittet ny användarprogramvara kan provas, och är sà konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att ett pro- gram pá andra sidan gränssnittet ej gör nágot otillàtet.

Enligt en sextonde aspekt innefattar uppfinningen ett sätt att prova ny användarprogramvara med referensmodell av nyss nämnt slag. Provningen av den nya användarprogramvaran sker genom att bringa två kopior av denna i kommunikationsförbindelse med varandra via hjälpprogrammet och exekvera i detta tillhanda- hållna operationer.

Utföringsformer av de olika aspekterna har erhállit de i respektive underkrav angivna kännetecknen.

Med en referensmodell för ett gränssnitt avses bl.a. att ett gränssnitt definieras såväl syntaktiskt som semantiskt.

Hela referensmodellen är exekverbar.

Konstruktionen av ett gränssnitt innebär, förutom att programvaran för själva gränssnittet tas fram, även att hjälp- programmen kons trueras .

Det första hjälpprogrammet utformas som en komplett an- vändare av gränssnittet omfattande samtliga tillåtna använd- 504 860 l2 ningsfall. Det andra hjälpprogrammet hanterar samtliga använd- ningsfall och visar vad som ur gränssnittets perspektiv skall hända i det program, som i praktiken skall erbjuda gränssnittets funktionalitet. Hjálpprogrammen är lika synliga som gränssnit- tet, de innehåller den kompletta informationen om gränssnittet.

Hjálpprogrammen hanteras alltid tillsammans med gränssnittet, de uppdateras och levereras tillsammans.

Av hjälpprogrammen och gränssnittet kan man alltid göra en exekverbar enhet. De båda hjälpprogrammen skall bevaka varan- dra, så att de ger felutskrifter om det andra programmet skulle göra något otillàtet. Detta användes först under utprovningen av hjälpprogrammen och senare när endera hjälpprogrammet användes som provningsverktyg.

Vid konstruktion av ett program, som använder ett gränssnitt, kan konstruktören studera det första hjälpprogram- met, där det eller de anvàndningsfall som skall användas finns.

Vidare kan han öka sin förståelse för hur det program, som erbjuder gränssnittets tjänster fungerar. De skall alla i prin- cip fungera som det andra hjälpprogrammet.

När sedan detta program skall provas, skapas en exe- kverbar enhet tillsammans med gränssnittet och det andra hjälp- programmet. Denna konfiguration ger följande fördelar: - Det andra hjälpprogrammet är alltid tillgängligt, det levereras ju med gränssnittet.

- Det andra hjälpprogrammet fungerar, det är ju refe- rens för varje konstruktion, som skall erbjuda gränssnittets funktioner.

- Det andra hjälpprogrammet är avgränsat, det är ju redan konfigurerat, det kräver inte ett ytterligare program, som i sin tur kräver ännu ett program, osv.

- Det andra hjälpprogrammet kommer att ge tydliga fel- utskrifter vid felaktig användning av gränssnittet, även i de fall där andra program, som erbjuder gränssnittets tjänster skulle kunna vara förlåtande.

Vid konstruktion av ett program som skall erbjuda gränssnittets funktioner, kan man av det första hjälpprogrammet se vilka möjliga användningsfall som finns. Alla dessa måste man kunna hantera. Däremot kan man lugnt utgå ifrån att ett använ- darprogram inte kommer att gå utöver dessa användningsfall - det 594 860' 13 upptäcks när användarprogrammet testas tillsammans med det andra hjälpprogrammet.

Dessutom behöver man inte föra in alla de möjliga sätt, som det andra hjälpprogrammet hanterar dessa pà. Sålunda kan kanske exempelvis vissa felsituationer, som finns beskrivna i gränssnittet, aldrig uppträda i den nu aktuella konstruktionen. Även om varje anvåndarprogram måste vara berett pá alla tänkbara felfall, behöver ju inte alla felfall kunna inträffa i just det aktuella utförandet.

Vid utprovning av det nya programmet skapas en exekver- bar enhet tillsammans med det första hjälpprogrammet och gräns- snittet. Alla användningsfall i det första hjälpprogrammet exekveras, och man får exekvering av all funktionalitet. Det första hjälpprogrammet kontrollerar varje reaktion från det andra programmet.

Med hjälp av en s.k. täckningsgradsmätare kan man se vilka kodpartier i ett nytt program som genomlöpts och vilka som inte genomlöpts. Kod som inte är associerad med något annat gränssnitt och som inte genomlöpts, kan med fog misstänkas vara felaktig.

Figgrbeskrivning.

Uppfinningen skall nu beskrivas närmare med hänvisning till bifogade ritningar, på vilka fig. 1 åskådliggör ett enkelt utföringsexempel av uppfinningen med hjälp av ett flödesschema, fig. 2 i blockschemaform är avsedd att utgöra underlag för diskussion av problem, som kan uppstå i en telefonväxel på grund av förekomsten av många olika inkommande och utgående ledningsprotokoll, fig. 3 visar samma blockschema som i fig. 2, men med tillfogande av hjälpprogram enligt uppfinningen, som möjliggör att problemen kan hanteras, fig. 4 är ett flödesschema avsett att åskådliggöra hur olika operationer i en telefonväxel, exemplifierade såsom in- gående i ett vanligt telefonsamtal, kan köras och övervakas av hjälpprogrammen enligt uppfinningen, samt fig. 5-10 med utgångspunkt från det i fig. 4 visade ex- emplet tjänar till att åskådliggöra vad uppfinningen generellt 504 860 14 kan innebära i olika användningsfall.

Föredragna utföringsformer.

Enligt en viktig aspekt av uppfinningen utgöres den av en referensmodell för ett gränssnitt, avsedd att användas vid definition och provning av gränssnittets funktion tillsammans med programvara, som skall interagera med annan programvara via gränssnittet. Denna referensmodell innehåller ett första och ett andra hjälpprogram, där det första hjälpprogrammet är ett mo- dellprogram, som simulerar användning av gränssnittet, och det andra hjälpprogrammet är ett modellprogram, som simulerar att det erbjuder funktionerna i gränssnittet. De båda programmen är därvid så konstruerade att de kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de kon- trollerar att det andra programmet ej gör något otillåtet.

Beskrivningen av de olika utföringsexempel av referens- modellens funktion som anges nedan är mestadels för enkelhetens skull så utförd att den anger interaktion av de båda hjälppro- grammen med varandra via gränssnittet, ett arbetssätt av refe- rensmodellen som endast används vid certifiering av hjälppro- grammen.

För att inse referensmodellens funktion vid provning av en ny programvara pà endera sidan av gränssnittet, får man tänka sig denna programvara såsom "ersättande" hjälpprogramet på samma sida, eftersom det är den andra sidans hjälpprogram som i sådant fall är verksamt. Det sålunda "ersatta“ hjälpprogrammet har normalt ingen funktion vid den sålunda aktuella provningen, men kan användas som förklaringsmodell om och när fel visar sig.

I en del fall vore det kanske till och med tänkbart med en marknadsimplementation av referensmodellen som omfattar endast endera hjälpprogrammet, dvs. endast hjälpprogrammet som simulerar användning av gränssnittet eller endast hjälpprogram- met som simulerar erbjudande av gränssnittet, om funktionen hos det erbjudande resp. användande hjälpprogrammet är trivial eller ointressant för praktiska tillämpningar. För provning av det i modellen ingående hjälpprogrammet vid modellens konstruktion kunde dock därvid även en provningsversion av modellen kunna skapas enbart för denna provning och för detta ändamål även in- nehálla det kompletterande hjälpprogramet. 504 860 15 I en del fall kan det också vara tänkbart att det andra, dvs erbjudande hjälpprogramet innehåller alla funktio- ner, som ett gränssnittet erbjudande program behöver. Då kan det andra hjälpprogrammet vara det program, som erbjuder funktioner- na även i det färdiga systemet. I så fall skall det andra hjälp- programmet utformas så att kontrollrutinerna för att upptäcka otillåtna operationer är bortstyrbara. Dessa behövs ju inte i ett utprovat och idriftsatt system, där de bara skulle förbruka processorkapacitet.

Med hänvisning till fig. 1 skall nu ett enkelt utför- ingsexempel av uppfinningen beskrivas. Som bakgrund skall först åtgärder i en tänkt situation beskrivas, som grundar sig på teknikens hittillsvarande ståndpunkt.

Ett program, fortsättningsvis benämnt PROG, behöver ett buffertomràde för tillfällig lagring av data. Ett buffertomràde är en resurs som ägs av operativsystemet, fortsättningsvis benämnt OS.

PROG måste då via ett gränssnitt mot OS begära tillgång till detta buffertomràde.

Antag att PROG skrivs i programmeringsspråket "C". En typisk handbok i "C" skulle ge följande gränssnittsbeskrivning; "char *malloc (storlek) Belägger ett sammanhängande buffertomràde om storlek bytes, en pekare till början av det belagda området returneras om beläggningen lyckades, i annat fall returneras en null-peka- re." Man finner också följande: "void free (pekare) Fristàller ett buffertomràde som pekas ut av pekare, och som tidigare belagts med ett malloc-anrop." För en erfaren programmerare anses detta vara fullt tillräcklig information.

Följande kommer dock att visa att denna information är långtifrån tillräcklig: - Antag att malloc returnerar en null-pekare. Detta innebär att programmet PROG inte får tillgång till det begärda buffertomràdet. Beroende på operativsystemets inre konstruktion kan endera av följande fortsättningar vara möjliga; 1) Försök igen, detta var tillfälligt. 504 860 16 2) Det går inte att komma vidare, PROG måste avslutas på ett kontrollerat sätt, för att avlasta operativsystemet. 3) Man behöver inte göra någonting, operativsystemet kan omöjligt fungera utan buffertområden och hela systemet kommer strax att krascha.

- Om PROG glömmer att friställa buffertområdet med free, kommer det då att gå förlorat? - Vad händer om PROG gör free med en pekare, som pekar någon annanstans än på ett tidigare, med malloc erhållet buf- fertomráde? 1) Ingenting. Operativsystemet upptäcker misstaget och när PROG så småningom avslutas, friställs alla buffertområden som PROG använt men glömt att friställa. 2) Operativsystemet litar på PROG, vilket kan ge helt oförutsägbara konsekvenser.

- Vad händer om PROG begär ett buffertområde med stor- leken O? Behöver ett sådant buffertområde friställas? I praktiken kommer konstruktören av programmet PROG att gissa sig till hur operativsystemet fungerar och när PROG är färdigskrivet, så kan han/hon exekvera PROG tillsammans med ett operativsystem och eventuella felgissningar kan rättas till - det är detta som brukar kallas avlusning. Problemet med denna process är dock att det enda som säkerställts är att PROG funge- rar som avsett med just denna version av operativsystemet. Om PROG skall användas med ett annat operativsystem, eller en nyare version av det gamla, måste man återigen verifiera och eventu- ellt korrigera PROG.

Det är inte ens säkert att alla funktioner kan testas.

Det är sålunda i allmänhet ytterst svårt att förmå ett operativ- system att svara "slut på buffertomràde" i just det ögonblick man önskar. Den som önskar prova sitt program med avseende pá brist på buffertområde, måste därför själv skriva ett testpro- gram som simulerar operativsystemets åtgärder i detta fall.

Problemet med ett sådant testprogram är att det måste nykonstru- eras. Om man hittar fel, tror man gärna att det är testprogram- met som är fel och korrigerar det istället. Därför vet man ju faktiskt inte, när allt tycks fungera, om testprogrammet upp- träder som ett verkligt operativsystem skulle göra. 504 860 17 Så långt har vi enbart studerat PROG-konstruktörens problem. Men även en konstruktör av ett operativsystem mäste ju kunna verifiera att ett nytt, uppdaterat operativsystem inte skapar problem för användarprogrammen. Det kanske inte räcker att verifiera att PROG fungerar tillsammans med det nya opera- tivsystemet. PROG kanske inte ens använder just den funktion som förändrats.

Här skall nu ges en beskrivning av hur det ifrågavaran- de minnesallokeringsgränssnittet skulle kunna se ut med tillämp- ning av uppfinningen.

Enligt uppfinningen, och med hänvisning till flödes- schemat i fig. 1, är det med 1 betecknade gränssnittet konstrue- rat tillsammans med ett modellprogram A, som simulerar använd- ning av gränssnittet, och ett modellprogram B, som simulerar att det erbjuder funktionerna i gränssnittet. Modellprogrammens A och B funktionssätt àskádliggörs närmare bestämt med det ifråga- varande flödesschemat.

I det föreliggande exemplet startas först modellpro- grammet B med en angiven totalt tillgänglig area, som inled- ningsvis anges som ospärrad. Det är vidare utfört att sedan vänta på att någon skall begära area. När sedan modellprogrammet A startas kommer det att enligt pil 2 via gränssnittet 1 begära tillgång, pil 4, till ett buffertomräde, vars förekomst simule- ras såsom att det ägs av modellprogrammet B. Begäran 4 fram- ställs genom anropet malloc(storlek), där begreppet "storlek" är en parameter, som anger storleken hos det begärda buffertom- rådet, och som värdesätts vid uppstart av A.

Steg 6 innebär en kontroll av att det inte är fråga om ett förnyat försök att belägga buffertarean, trots att det före- gående misslyckats på grund av spärr. Om det senare är fallet slutar flödet i steg 8. I annat fall leder flödet till steg 10, som innehåller en spärr mot att användarprogrammet skall kunna begära ett buffertomräde med storleken 0. Om en sådan begäran indikeras slutar flödet i steg 12. I annat fall leder flödet till steg 14, som fastställer om det finns en ledig area. Om inte markeras spärr i steg 16, som leder till att en null-pekare returneras, pil 18, till programmet A. Om area finns tillgänglig beläggs den i steg 20 och malloc=pekare returneras, pil 22, till program A. Efter användning av arean returneras den till pro- 504 860 18 grammet B med free(pekare), pil 24. Detta leder till steg 26 i modellprogrammet B, där det kontrolleras att rätt area återläm- nats. Om detta ej är fallet markeras fel i steg 28. I annat fall friställs arean i steg 30. Det hela avslutas, pil 32, i program A. Modellprogrammet B stoppas när det buffertanvändande program- met har avslutat sin exekvering. Dä kontrolleras att all utläm- nad buffertarea har àterlämnats, om inte, ges en felutskrift.

Båda modellprogrammen A och B har registrerat vad som inträffat under exekveringen.

Gränssnittet skulle naturligtvis också innehålla opera- tioner för att skriva och läsa i buffertarean. Dà de inte bidrar till förklaring av uppfinningen i det föreliggande sammanhanget har de utelämnats.

Ur den i fig. 1 visade referensmodellen kan följande slutsatser dras om gränssnittet.

Ur användarprogrammets A synvinkel: - Det är inte tillàtet för en användare, som redan fått spärr vid malloc-anrop, att försöka pà nytt, jfr. steg 6.

- Det är inte tillåtet att begära buffert av storleken = 0, jfr. steg 10.

- Arean måste returneras med free. Free får bara an- vändas för areor som erhållits med malloc och som inte redan har returnerats, jfr. pil 24.

Ur det bufferthanterande programmets B synvinkel; - Begärda buffertareor är alltid större än 0, jfr. steg 10.

- Pekaren som kommer med free behöver inte kontrolle- ras.

- Anvándarprogrammet kommer att returnera erhållen buffertarea.

Om användarprogrammet skulle bryta mot dessa regler, upptäcks detta när det provas mot modellprogram B.

Referensmodellen för gränssnitt är tillämpbar också på mer komplexa gränssnitt. Som exempel skall nu visas hur det tillämpas pá ett protokoll. I det följande skall med hänvisning till fig. 2 och 3 en diskussion ges av problem, som kan uppstå vid hantering av ett system för publika telefonväxlar, och av hur sådana problem principiellt kan lösas med uppfinningen.

Syftet med en telefonväxel kan sägas vara att koppla 504 860 19 ihop en inkommande förbindelse, med en annan, utgående förbin- delse.

För att ställa upp förbindelsen behövs det protokoll för överföring av styrinformation, t.ex. vilken destination man önskar nå (telefonnumret). Av historiska och tekniska skäl finns det ett stort antal olika sådana protokoll, antytt med Pl, P2 ...Pn i fig. 2. Ett av de mera välkända, som kan antas vara t.ex. Pl i fig. 2, är det som används för en vanlig knappvalste- lefon, där tonsignaler pá talledningen talar om vilket numer man önskar nå. Ett annat välkänt exempel, som kan antas vara t.ex. P2 i fig. 2, är fingerskivssignalering, där siffrorna representeras av avbrottspulstág. Siffran 4 representeras t.ex. av fyra avbrottspulser i en följd.

Antag att man ringer frán en fingerskivsapparat, in- kommande samtal enligt pil 46 i fig. 2, till en apparat för tonval, utgående samtal enligt pil 48. Det kan t.ex. röra sig om ett samtal till en företagsväxel med direktval, där internnumret överföres fràn den publika växeln till företagsväxeln just i form av tonkoder.

Detta betyder att det behövs ett program, antytt med block 50 i fig. 2, som kan räkna konsekutiva avbrottspulser, och ett annat program, antytt med block 52 i fig. 2, som kan över- sätta en siffra till en tonkod och skicka ut detta pà ledningen.

För att programmen 50 och 52 skall kunna kommunicera med varan- dra måste de ha ett gemensamt "sprák" - ett protokoll - som de kan förmedla sig med. I detta språk användes inte sådana begrepp som avbrottspuls eller tonkod. Det finns därför i alla telefon- växlar ett internt protokoll, antytt med linje 54 i fig. 2, som alla tänkbara ledningsprotokoll kan översättas till eller fràn.

Om man nu vill introducera ytterligare ett protokoll i en sådan här telefonväxel, så mäste man se till att detta nya protokoll kan samarbeta med vilket som helst av de befintliga protokollen. Dessutom måste man säkerställa att alla de befint- liga protokollen kan samverka med det nya protokollet. Komplex- iteten att konstruera ytterligare ett protokoll ökar således i takt med antalet redan befintliga protokoll.

I fallet enligt fig. 2 kan internprotokollet 54 be- traktas som ett gränssnitt av det slag, som uppfinningen be- fattar sig med. Om man infogar referensmodellen enligt uppfin- 504 860 20 ningen erhåller man en konfiguration som den som visas i fig. 3.

Denna referensmodell innefattar dels ett modellprogram A, som representerar en uppringande part ("A-sida" enligt gängse språk- bruk inom telekommunikationsvärlden), och dels ett modellprogram B, som representerar den uppringda parten (“B-sida"). En väsent- lig sak skiljer dock detta exempel från det föregående, nämligen att den ena modellen upplever den andra via internprotokollet, och att gränssnittet mot andra sidan därför är gränssnittet mot internprotokollet. A- och B-modellerna är utförda på ett sådant sätt att de kan utföra samtliga möjliga och tillåtna operationer över internprotokollet 54, samtidigt som de kontrollerar att det inte förekommer några otillåtna operationer över gränssnittet.

För att dessa kontroller skall kunna utföras vid gränssnittet ersätts internprotokollet av en internprotokollmodell, som då dessutom innehåller programvarurutiner för att upptäcka eventu- ella otillåtna operationer.

Med den i fig. 3 visade konfigurationen går det att "ringa", dvs. ställa upp ett koppel, mellan A och B, men däremot inte att samtala, vilket styrs av ett annat gränssnitt. Men det går också att "ringa" ut frán A på något av protokollen P1-Pn, likaväl som det går att ta emot ett "samtal" i B.

Modellprogrammen A och B kräver ingen egen maskinvara, de är rena programvaruenheter. De skall alltid vara tillgängliga tillsamans med internprotokollet 54. Om man till exempel har gjort färdigt ett inkommande protokoll Px, skall man genast kunna köra det mot B-modellen.

A-modellen skall kunna allt som ett inkommande pro- tokoll kan göra. B-modellen skall kunna allt, som ett utgående protokoll kan göra och som kan förmedlas på internprotokollet 54. Detta innebär att: - ett utgående protokoll, t.ex. P2 måste vara berett på att hantera allt som A-modellen kan åstadkomma, vilket innebär att det antingen skall kunna skicka vidare, eller avvisa, dvs. meddela "kan inte göra det". I och med att detta utgående pro- tokoll P2 kan hantera allt som A-modellen utsätter det för, kan inget annat inkommande protokoll överraska det med ny, tidigare oprovad eller oförutsedd funktionalitet. - ett inkommande protokoll, t ex. P2, måste vara berett på att det utgående protokollet, t.ex. P1, inte kan hantera 504 8601 21 funktioner som finns i P2. Om exempelvis det ifrågavarande inkomande protokollet P2 är avsett för knappvalstelefon, funge- rar àteruppringning om det utgående protokollet också är P2, men om man ringer ett långväga samtal t.ex, ut mot utgående pro- tokollet P1, så kommer det att visa sig att Pl inte har denna funktion. Detta måste då P2 på den inkommande sidan vara berett på. B-modellen skall kunna uppträda antingen som om den har eller som om den inte har återuppringning. - ett inkommande protokoll, t.ex. P2, kan ha funktio- ner, som inte hanteras av internprotokollet. Detta skall då framgå av A-modellen, som ju då inte skall hantera dessa funk- tioner. V Figur 4 är ett flödesschema avsett att åskådliggöra hur olika operationer i en telefonväxel enligt fig. 2 och 3, ex- emplifierade såsom exekverade i ett vanligt telefonsamtal, kan köras och övervakas mellan en modell A' av en A-abonnent, och en modell B' av en B-abonnent, vilka är anslutna till ett intern- protokoll 55 via varsitt gränssnitt 56 resp. 58.

I exemplet speglas därvid ett mindre antal användnings- fall för A- och B-sidan, som vart och ett kommer att särskilt framhållas när det dyker upp. I ett verkligt internprotokoll finns det många fler signaler mellan de båda sidorna, och många fler saker som kan inträffa inte bara på A- resp. B-sidorna utan även i internprotokollet, men detta har skalats bort för att exemplet därigenom skall bli mer överskådligt. Särskilt intern- protokollet har förenklats. Det realiseras också med programvara och har i ett realistiskt fall egna händelser - det kan t.ex. meddela ena sidan att det har förlorat kontakten med den andra sidan.

I sammanhanget förtjänar en av de för uppfinningen väsentliga egenskaperna att framhållas. Detta är att ingen av abonnentmodellerna har en aning om huruvida motparten på den andra sidan av internprotokollet 55 också är en modell eller om det är något av de ”riktiga” protokollen Pl-Pn. Ehuru den nedan- stående beskrivningen av de i fig. 4 uppträdande flödena för enkelhetens skull i huvudsak är upplagd såsom att det är A'- och B'-modellerna som kommunicerar via internprotokollet 55, innebär detta inte att det rör sig om ett förlopp, utan om två helt oberoende, händelsevis sammanflätade förlopp. Dessa förlopp, 504 860 22 nämligen ett A'-förlopp och ett B'-förlopp, är "kliniskt" åtskilda.

B'-modellen startas med parametrar Tbl, Tb2 och Tb3 värdesatta, samt en status tilldelad för B'-abonnenten, och börjar med att vänta på att det skall komma ett anrop, markerat vid 60. Tbl anger hur läng tid uppkopplingen skall ta. Tb2 anger hur lång tid det sedan skall ta före B'-svar, men kan också ange att B' inte svarar alls. Tb3 anger hur länge det sedan skall dröja innan B' skall lägga på. B'-abonnentens status är upp- tagen, ledig eller spärr.

A'-modellen startas, markerat vid 62, med parametrar Tal och Ta2 värdesatta. Tal anger hur läng tid A'-modellen väntar på ett svar från andra sidan innan den lägger på och Ta2 anger hur länge A'-modellen skall stanna i samtalsläge innan den lägger på.

Internprotokollet startas om utförandet så kräver, för att det skall kunna förmedla meddelanden mellan de båda sidorna.

Internprotokollet tar inte i detta exempel några egna initiativ.

I ett annat, mera komplicerat exempel, skulle man dock kunna tänka sig att det startas med en parameter, som anger efter hur lång tid efter uppstart som internprotokollet till båda sidor meddelar att förbindelsen har avbrutits, varefter de båda sidor- na på kontrollerat sätt får koppla ner.

En väntande modell avbryter sin väntan när det kommer ett meddelande från andra sidan, och följer då istället detta meddelande. I samband härmed, och för full förståelse av den nedanstående beskrivningen, är det därvid viktigt att inse att varje meddelande har tre delar, nämligen vad den sändande sidan vill, vad internprotokollet förmedlar, resp. hur den mottagande sidan tolkar det.

A'-modellen börjar med en begäran om uppsättning av koppel, pil 64, som via signal "sänd anrop" i internprotokollet, pil 66, leder till ett anrop, pil 68, mot B'-modellen. Denna avbryter sin väntan och börjar, vid 70, mäta ut tiden Tbl. Efter denna tid fortsätter B'-modellen enligt den abonnentstatus, som enligt ovan àsattes vid uppstarten.

Om B'-abonnentens status är upptagen eller spärr, stoppas B'-modellens förlopp, markerat vid 72, och via signal "upptagen" resp. "spärr" i internprotokollet, pilar 74 resp. 76, 504 860 23 tolkar A'-modellen meddelandet som "sänd upptagetton", pil 78, resp. "sänd spärrton", pil 80. A'-modellen skall naturligtvis inte sända någon ton - det kan den inte. Däremot skulle ett verkligt protokoll i detta läge sända en ton. A'-modellens förlopp stoppas, markerat vid 82.

Förloppen 68, 74, 78 och 68, 76, 80 representerar första och andra användningsfall för A-sidan, nämligen att B- sidan vid anrop frán A-sidan ger "upptaget" resp. "spärr" till- baka.

Om B'-abonnentens status är ledig, sänds signal "upp~ koppling klar" i internprotokollet, pil 84, mot A-sidan, som av A'-modellen tolkas som "sänd rington" pil 86. Inte heller här kan naturligtvis A'-modellen sända någon ton. Såsom vid ovan beskrivna fall med "sänd upptagetton" och "sänd spärrton" rör det sig här bara om en beskrivning, som ger förslag på vad som skulle kunna göras i ett riktigt protokoll. Om det finns rington i sammanhanget, så är det nu den skall sändas. B'-modellen börjar samtidigt, markerat vid 88, mäta ut tiden Tb2, och A'- modellen börjar, markerat vid 90, mäta ut tiden Tal.

Efter den av parametern Tb2 fastställda tiden skickar B'-modellen svar mot A'-modellen, pil 92, som av internproto- kollet förmedlas som "B-svar", pil 94, och av A'-modellen tolkas som "stoppa rington", pil 96. A'-modellen avbryter utmätningen av tiden Tal och startar istället utmätning av tiden Ta2, marke- rat vid 98, efter det begäran utförts.

A'-modellen lägger pà, markerat med pil 100, antingen efter den av parametern Tal fastställda tiden för väntan på svar fràn andra sidan, eller efter den av parametern Ta2 fastställda tiden för samtalsläge, beroende pá vilken av de båda tidmät- ningarna, som är aktiv.

Förloppen 84, 86, 90 och 92, 94, 96, 98 representerar tredje resp. fjärde användningsfall för A-sidan, nämligen att, när A-sidan anropar, B-sidan är ledig men svarar inte, resp. B- sidan svarar men lägger inte på. På motsvarande sätt uppträder här första och andra användningsfall för B-sidan, nämligen att A-sidan sätter upp ett koppel, men lägger pà igen innan B-sidan har svarat, resp. lägger på efter det B-sidan har svarat.

I samband med utsändning av meddelandet B-svar, pil 94, börjar B'-modellen mäta ut tiden Tb3, markerat vid 102. Efter 5o4 s6o 24 det denna tid förflutit lägger B'-modellen på, markerat med pil 104. Detta representerar ett femte användningsfall för A-sidan, nämligen att när A-sidan anropar, svarar B och lägger sedan pá.

På motsvarande sätt uppträder här ett tredje användningsfall för B-sidan, nämligen att A-sidan sätter upp ett koppel, men lägger inte på innan B-sidan lagt på.

Av ovanstående beskrivning med hänvisning till fig. 4 kan man härleda några semantiska regler, t.ex. att: - A-sidan inte kan koppla ner förrän B-sidan returnerat status, - varken A-sidan eller B-sidan får skicka något ytter- ligare meddelande efter spärr/upptaget, - B-svar får bara sändas efter B-ledig.

För A'-modellen sker nedkoppling till stopp via signal "A-nedkoppling" i internprotokollet enligt pil 106, signal till B-sidan med begäran om kvitteringsmeddelande enligt pil 108 och motsvarande kvitteringsmeddelande "nedkoppling" enligt pil 110 från B-sidan, signal "B klar" i internprotokollet enligt pil 112, samt pil 114 till stopp 113. För B'-modellen sker nedkopp- lingen via signal "B-nedkoppling" i internprotokollet enligt pil 116, signal till A-sidan med begäran om kvitteringsmeddelande enligt pil 118 och motsvarande kvitteringmeddelande "nedkopp- ling" enligt pil 120 från A-sidan, signal "A klar" enligt pil 122 i internprotokollet, samt pil 124 till stopp 125.

Av ovanstående framgår att ingen sida får koppla ner utan att försäkra sig om att den andra sidan har kvitterat detta. Ehuru ej visat kan man även tänka sig att lägga in var- dera en fördröjning mellan stegen 108 och 110 resp. mellan stegen 118 och 120.

Med utgångspunkt från det i fig. 4 visade exemplet skall nu en närmare analys ske av vad uppfinningen generellt kan innebära när det rör sig om kommunikationsfall.

Antag först att det rör sig om ett komplett linjegräns- snitt i en publik telefonstation. Fig. 4 kan vidare med uteläm- nande av alla detaljer ritas om på det i fig. 5 visade sättet.

Man erhåller då något som kan betecknas som en referensmodell bestående av tre komponenter, nämligen förutom A'- och B'-model- lerna även en internprotokollmodell I, med gränssnittet 56 beläget mellan A'-modellen och I-modellen, samt gränssnittet 58 504 860 25 beläget mellan I-modellen och B'-modellen.

Om man nu studerar I-modellen närmare finner man föl- jande.

I det allra enklaste fallet exekverar A'och B', eller de applikationer som de representerar, på samma processor i samma lokalstation. Det kan röra sig om ett lokalt telefonsam- tal.

Som bekant är det emellertid inte någon större skillnad mot att ringa till en telefon på andra sidan jordklotet. I detta fallet representerar samma I-modell delar av hela jordens tele- fonnät, ett ytterst komplext tekniskt system. Mängden gränssnitt som ett sådant internationellt telefonsamtal passerar på sin väg är svindlande även för en erfaren konstruktör av telefoninät.

Internprotokollmodellen I är dock en hanterlig abstrakt modell även i fallet ett komplext lángdistanskoppel.

Vidare är det ju så att samma telefon skall kunna användas såväl för att ringa upp med, som för att ta emot sam- tal. Sett ur denna synpunkt är det ingen som helst skillnad mellan A'- och B'-modellerna, de är två individer av exakt samma typ. De kan därför här för den fortsatta diskussionens skull, och för att åskådliggöra det uppfinningsmässiga sambandet med andra utföringsformer, såsom de enligt fig. 1 och 3, benämnas A"1 resp. A"2, Av samma skäl kan I-modellen döpas om till B" och fig. 5 transformeras till den i fig. 6 visade formen. Som synes sammanfaller då de två gränssnittslinjerna i figur 5 åter till ett enda gränssnitt, vilket det i själva verket är.

Eftersom enligt ovan A"l kan anses ekvivalent med A"2, kan de med hänvisning till fig. 7 slås ihop till A". Man ser då att resultatet blir den enligt uppfinningen definierade gräns- snittsreferensmodellen, där A" kan betecknas som ett första hjälpprogram, som simulerar användning av gränssnittet, och B" kan betecknas som ett andra hjälpprogram, som simulerar att det erbjuder funktionerna i gränssnittet, på så sätt att de båda programmen kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de kontrollerar att det andra programmet ej gör något otillåtet. Vid utföringsformen enligt fig. 4 bildar då alltså "A'-modellen" och "B'-modellen" tillsam- mans det första hjälpprogrammet, och internprotokollmodellen 55 det andra hjälpprogrammet. Gränssnitten 56 och 58 är i själva 504 860 26 verket samma gränssnitt, nämligen det för vilket referensmodel- len enligt uppfinningen är avsedd.

Den ovan àskàdliggjorda ekvivalensen kan, i ett vidare perspektiv, tolkas som följer: A-sidan överför information till B-sidan och àterfàr den vid ett senare tillfälle. Om det är en och samma A-individ är B en minnesfunktion enligt vad som är fallet vid utförings- formen enligt fig. 1. Om det rör sig om två A-individer är B en kommunikationsfunktion, såsom exempelvis i fig. 4.

Vad som kan abstraheras bort i denna modell - och detta är betydelsefullt - är hur B-sidan internt hanterar informatio- nen. Ur modellen Azs synvinkel märks det inte någon skillnad om B-sidan bara tar emot meddelandet som det kommer, för att sedan lämna tillbaka det oförändrat, eller förändrat pà det sätt gränssnittet föreskriver, eller om B-sidan t.ex. krypterar meddelandet, delar upp det i lagom stora paket, skickar ut det pà en förbindelse osv., för att sedan ta emot paketen, sätta ihop dem till ett meddelande, dekryptera detta och lämna till- baka det till A.

I det fall att det andra hjälpprogrammet representerar ett protokoll kan tre användningsfall för referensmodellen uppträda enligt följande: 1) Användning av ett kommunikationsgränssnitt, jfr. fig. 8.

I detta fall skall provning ske av en ny version a"1 av användarprogramvara tillsammans med gränssnittet, vilken får representera den ena A-individen. a"l skall via det "andra hjälpprogrammet“ B" kunna "ringa" till den andra A-individen A"2, som i sin egenskap av "första hjälpprogram" skall kunna bli uppringd av den nya programvaran. Användningsfallet inkluderar även det fall där A"2 ringer upp a"l. 2) Konstruktion av ett nytt kommunikationssystem, jfr. fig. 9.

I detta fall är B-individen, här betecknad b", ett nytt kommunikationssystem, som skall provas tillsammans med gräns- snittet av det "första hjälpprogrammet“ bestående av de båda A- individerna A"l och A"2. Det nya kommunikationssystemet b" ska klara av att A"l och A"2 skall kunna "ringa" till varandra på alla tänkbara sätt. 504 860 27 3) Kommunikation inom en användare, jfr. fig. 10.

I detta fall får de tvâ A-individerna ersättas av en "uppringande" del a"l resp. en "svarande" del a"2 av en ny användarprogramvara, som skall provas tillsammans med gränssnit- tet av det "andra hjälpprogrammet" B". I själva verket rör det sig alltså om en och samma nya programvarufunktion, som "ringer upp" en kopia av sig själv och överför information.

De två kopiorna a"l och a"2 kommunicerar med varandra på ett sätt, som inte nödvändigtvis behöver vara begripligt för något annat program. Vad man i denna konfiguration vill verifie- ra, är att de förstár varandra också när meddelanden har passe- rat B, och där t.ex. underkastats viss modifikation med avseende på sitt innehåll. För att konstruera och certifiera programvara som kommunicerar med sig själv, behövs det således en B-modell för själva kommunikationen. Denna B-modell representerar det allra enklaste sättet att genomföra denna kommunikation.

Ett utföringsexempel av hur metoden enligt uppfinningen kan används rent praktiskt kommer nu att beskrivas närmare nedan.

Utgángspunkt är ett mycket enkelt gränssnitt, som specificerats på traditionellt sätt, och avsikten är att närmare studera vad som händer när definitionen av gränssnittet stramas upp med en referensmodell.

I ett system för det paneuropeiska digitala mobiltele- fonsystemet GSM är det möjligt för en abonnent i ett nät att lämna detta nät och bege sig in i täckningsomràdet för ett annat nät och där erhålla samma betjäning som i sitt hemmanät. I ett och samma land kan det finnas flera, vanligen konkurrerande nätoperatörer, som med sina nät täcker samma geografiska område.

Olika operatörer har därför olika samarbetspartners för att erbjuda den egna gruppen av abonnenter bästa möjliga täckning även utanför det egna hemma-området. Abonnenter tillhörande icke samarbetande nät skall däremot avvisas dels av konkurrensskäl, dels därför att de inte kan debiteras om det inte finns ett sam- arbetsavtal, som reglerar detta. Om således en främmande abon- nent begär betjäning, måste man avgöra om denna abonnent tillhör en samarbetande nätoperatör eller ej, för att kunna fastställa om betjäning skall erbjudas eller avvisas. Den abonnent, som begär betjäning identifierar sig bl.a. med en PLMN-parameter 504 860 28 (PLMN = Public Land Mobile Network), som anger vilken nátopera- tör abonnenten tillhör. Vi skall nu avgöra om det egna nätet samarbetar med den således angivna operatören.

Denna funktion erbjudes över det gränssnitt, som här har valts som exempel.

Före en närmare presentation av programvara må det framhållas att referensmodellmetodiken enligt uppfinningen inte är knuten till någon särskild datormiljö. De programvaror som här beskrivs kommer därför att vara neutrala med avseende pá programspråk, operativsystem, datorkonfiguration m.m. Närmare bestämt är de, för att underlätta förståelsen, skrivna i s.k. pseudokod, som bygger pà intuitiv förståelse.

Den syntaktiska definitionen av gränssnittet har föl- jande utseende i pseudokod: begin P1mn_interface_definition: type GsmPimnResuit is ENUMERATED GsmPlmnValidMS := 0, GsmP1mnUnVa1idMS := l.

GsmPimnDBNfau1t := 99 end_typ6: use EXTERNAL definition of type GsmP1mnId; method checkVa1idMS (Plmn is of type GsmP1mnId) RETURNS a value of type GsmP1mnResuit; end P1mn_interface_definition: Gränssnittet definierar med metoden checkValidMS en möjlighet att få reda pä om en mobilabonnent (MS) tillhör ett samarbetande PLMN. Mobilabonnentens PLMN anges i den medföljande parametern Plmn, som har formatet GsmPlmnId. Svaret på frågan ges i returvärdet, som är av typen GsmPlmnResult.

Resultatet kan vara endera av dessa tre. GsmPlmnValidMS innebär att abonnenten kan erbjudas betjäning. GsmPlmnUnValidMS innebär (fastän det inte tydligt framgår här) att abonnenten skall avvisas. Det tredje alternativet, GsmPlmnDBNfault, innebär att tyvärr kan inget svar ges. DBNfault antyder fel i databasen.

GsmPlmnId definieras någon annanstans. Det finns alltså 504 860 29 en definition, som vi kan och ska använda, men vi bryr oss inte om hur den egentligen ser ut. Vi kan använda oss av en autentisk definition, men vi kan också hitta på en egen.

Principerna för referensmodellen kan tillämpas pà detta gränssnitt enligt följande. Det enligt uppfinningen definierade första hjälpprogrammet kan ha följande utseende: begin auxi1iary_program_l; deciarez result is of type GsmP1mnResu1t: Pimn is of type GsmP1mnId: end deciare begin program; Pimn := read_parameter: /*This is a startup parameter*/ result := checkVaiidM5 (Pimn); switch on result if GSmP1mnVaiidMS: print ("P1mn is accepted. service may be offered">; break; ii GsmP1mnUnVaiidMS: print ("P1mn is black listed, MS must not be registered as a visitor"): break: if GsmP1mnDBNfau1t: print ("Data Base is inoperative">; break: end_switch; end auxi1iary_program_l: Det enligt uppfinningen definierade andra hjälpprogram- met kan ha följande utseende: begin auxiiiary_program_2: 504 860 30 decïarez va1ue_1 is op type integer; va1ue_2 is of type GsmP1mnId, EXTERNAL definition: number_of_requests is of type integer: return vaiue of checkvaïidMS is of type GsmP1mnResu1t.

EXTERNAL definition; end deciare: begin program; number_of_requests := 0 ; va1ue_1 := read_parameter; /* vaiue_l indicates what resuit that wiii be returned : */ /* 0 means that every Pimn is vaiid */ /* 1 means that every Pimn is unvaiid */ /* 2 means that the Pimn shaii be compared to a Pimn */ /* vaiue given as a parameter */ /* 99 means that the result shaii indicate Data Base fauit*/ if vaiue_l = 2 then va1ue_2 ;= read_parameter: end_if: whiie true do wait for checkva1idMS ( Pimn_va1ue ). when received do print ("P1mn "\va1ue of P1mn_va1ue\" in checkVaiidMS"); switch on vaiue_l if 0; return GsmP1mnva1idMS: if 1: return GsmP1mnUnva1idMS: if 2: if Pimn = vaiue_2 then return GsmP1mnva1idMS eise return GsmP1mnUnVa1idMS end_if: if 99:if number_of_requests = 0 then return GsmP1mnDBNfauit; 504 860 31 eße print ("Do not repeat request to an unoperative Data Base"); ex1t_program; end_1f: if other: print ("Parameter error“): ex1t_program: end_sw1tch: end_d0: end_wh11e: end aux111ary_program_2: Dessutom behövs det en definition av GsmPlmnId, forma- tet pà Plmn-angivelsen. Denna definition är en del av ett annat gränssnitt, och man kan tänka sig tre olika fall: 1) Det finns en färdig korrekt definition, som beskri- ver det autentiska formatet för en Plmn-angivelse. År den lätt- hanterlig kan vi använda den. (Det riktiga formatet för Plmn_är tre+tvà siffror.) 2) Det finns en referensmodell även för gränssnittet GsmPlmnId. I sä fall använder vi förutom gänssnittet GsmPlmnId dess andra hjälpprogram. 3) Det finns bara själva gränssnittet, dvs. det faktum att formattypen heter GsmPlmnId. Dà mäste man ta fram också en egen definition av GsmPlmnId. Den kan i princip se ut hur som helst, man kan säga att Plmn anges med en siffra eller en text- sträng. Denna definition användes så länge det inte finns en definition av typ 1) eller 2).

Vi har därmed en komplett referensmodell. Den används enligt följande.

A) Det finns nu också en semantisk modell av gränssnit- tet. Det första hjälpprogrammet visar en typisk användning av gränssnittet. Man skulle faktiskt kunna kopiera in det som en mall i ett användarprogram. Av hjälpprogrammet framgår den semantiska icke-regeln att gränssnittet inte tar ställning till 504 860 32 om abonnenten skall erbjudas betjäning eller ej om besked ej kan ges, det får användande program själv ta ställning till.

Det andra hjälpprogrammet innehåller en semantisk regel: Det säger att om man har fått GsmPlmnDBNfault, så får man som användare inte försöka igen. För det program som erbjuder gränssnittet betyder detta att om databasen - eller vad det nu är som krånglar - tillåter att man försöker igen, så är det det erbjudande programmet som försöker igen och först när det gett upp svarar det med GsmPlmnDBNfault. På det viset blir det alltid meningslöst för det användande programmet att försöka igen.

B) Ett nykonstruerat användarprogram skall provas.

Detta anropar gränssnittet vars funktioner nu erbjuds av det andra hjälpprogrammet. Vi inser följande fördelar med att an- vända detta hjälpprogram framför ett program som i en systemapp- likation erbjuder detta gränssnitt: - Det finns ett fungerande och lättillgängligt hjälp- program tillsammans med gränssnittet. Systemapplikationen, om det alls finns en exekverbar sådan, är avsevärt mer komplicerad och därför kanske inte helt felfri.

- Man behöver inte konfigurera upp en hel databas för att genomföra provet. De flesta fel man skulle hitta skulle nog bero på att man konfigurerat upp databasen fel, eller fel i pro- grammet, som använder databasen. I ett sådant läge är det lätt hänt att man missar fel i det egna programmet.

- Har man ändå lyckats konfigurera upp databasen så att den fungerar, så är det inte helt trivialt att få det att sluta fungera, dvs. ge svaret GsmPlmnDBNfault.

- Hjälpprogrammet skriver ut vilken Plmn det är man frågar på. Om angivelsen förvanskats på vägen, så kan detta upptäckas när hjälpprogrammet skriver ut vilket Plmn som man kontrollerar. Skulle förfrågan upprepas i ett och samma förlopp - i och för sig inte förbjudet, men onödigt - så upptäcker man det också.

C) Ett nykonstruerat program, som erbjuder gränssnittet skall provas. Det konfigureras upp tillsammans med gränssnittet och det första hjälpprogrammet. Detta kan sedan enkelt ställa frågor mot databasprogrammet, om Plmn-värdet är acceptabelt.

Skulle detta göras med hjälp av rena systemapplikationer, så skulle man i princip behöva ett helt mobiltelefonisystem. Det 504 860 33 första hjälpprogrammet borde vara lätt styrbart, så att man snabbt kan köra det med ett stort antal olika Plmn-värden.

Uppfinningen har en rad viktiga fördelar.

Genom uppfinningen blir gränssnitt fullständigt defini- erade, dvs. såväl syntaktiskt som semantiskt. Semantiken blir formellt och exakt definierad.

Ett gränssnitt, där semantiken bara beskrivs verbalt, eller inte alls, kräver erfarenhet av den konstruktör som skall använda det. Det kan därvid röra sig om erfarenhet, som erhålles genom experiment eller misstag och ändå inte säkert är vare sig korrekt eller fullständig, och som dessutom kanske inte enkelt kan meddelas andra konstruktörer.

Om emellertid gränssnittet är försett med modellprogram enligt uppfinningen, finns all kunskap knuten till gränssnittet och den som använder gränssnittet vet att han/hon har all nöd- vàndig kunskap om detta. Dessutom vet användaren att alla andra konstruktörer har samma kunskap om gränssnittet. Detta innebär att man inte behöver ta hänsyn till att motparten kan ha gjort en annan tolkning av semantiken och att man därför hela tiden mäste kontrollera att motparten inte gör något som man själv tolkar som otillátet. Sådana kontroller kostar både konstruk- tionsansträngning och exekveringstid när gränssnittet används.

Med hjälp av gränssnittsmodellerna kan man göra en formell certifiering av en programvaruenhet, sett från de gräns- snitt som den använder och dem den erbjuder. Denna certifiering göres oberoende av alla de olika versioner, varianter, utgåvor och kombinationer av programvaruenheter som bestyckar, eller kan komma att bestycka, andra sidan av gränssnitten.

En programvaruenhet, en gång med denna metod certifie- rad, förblir certifierad. Den behöver aldrig certifieras om därför att omgivningen förändrats. Programvaruenheten kan leve- reras med referensmodellprogrammen och vem som helst kan exe- kvera dessa. Certifieringsprotokoll behövs inte, certifieringen kan upprepas när helst så önskas.

När denna metod används, levereras modellprogrammen ut tillsammmans med gränssnittet. Modellprogrammen gör det lättare för kunden att använda gränssnittet.

I andra fall levereras inte modellprogrammen, men då har de använts vid certifiering av annan levererad programvara, 504 860 34 och då hänvisar man i sitt certifieringsprotokoll till att denna programvara har kvalitetssäkrats med hjälp av modellprogram.

Claims (58)

594 860 35 Patentkrav.

1. Sätt att skapa en referensmodell för ett gränssnitt, kännetecknat av att ett första och ett andra hjälpprogram kon- strueras, där det första hjälpprogrammet är ett modellprogram, som simulerar användning av gränssnittet, och det andra hjälp- programmet är ett modellprogram, som simulerar att det erbjuder funktionerna i gränssnittet, på så sätt att de båda programmen kan utföra samtliga möjliga och tillåtna operationer över gräns- snittet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillàtet.

2. Sätt enligt krav 1, kännetecknat av att de båda programmen konstrueras, underhålls och levereras tillsammans med gränssnittet.

3. Sätt enligt krav 1 eller 2, kännetecknat av att det första hjälpprogrammet utformas som en komplett användare av gränssnittet, omfattande samtliga tillåtna användningsfall, och att det andra hjälpprogrammet utformas att kunna hantera samt- liga användningsfall och kunna generera samtliga tänkbara resul- tat, även fel, som kan uppstå vid hantering av användningsfallen och som är definierade i gränssnittet, samt visa vad som skall hända i ett program av ett visst utförande, som i praktiken skall erbjuda gränssnittets funktionalitet.

4. Sätt enligt något av föregående patentkrav, känne- tecknat av att de första och andra hjälpprogrammen utformas att vara lika synliga som gränssnittet och innehåller en komplett information om, och definition av gränssnittet.

5. Sätt enligt något av föregående patentkrav, känne- tecknat av att de första och andra hjälpprogrammen tillsammans med gränssnittet utformas så att de bildar en exekverbar enhet.

6. Sätt enligt något av föregående patentkrav, känne- tecknat av att de första och andra hjälpprogrammen utformas så att de bevakar ett program på andra sidan gränssnittet för att ge felutskrifter om detta program skulle göra något otillàtet.

7. Mjukvarusystem för exekvering i dator, bildande en referensmodell för ett gränssnitt, kännetecknat av att referens- modellen innehåller ett första och ett andra hjälpprogram, där det första hjälpprogrammet är ett modellprogram, som simulerar användning av gränssnittet, och det andra hjälpprogrammet är ett modellprogram, som simulerar att det erbjuder funktionerna i 504 860 36 gränssnittet, pà så sätt att de bàda programmen kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de kontrollerar att ett program pà andra sidan gränssnittet ej gör nàgot otillátet.

8. Mjukvarusystem enligt krav 7, kännetecknat av att den medger konstruktion, underhåll och leverans av de båda programmen tillsammans med gränssnittet.

9. Mjukvarusystem enligt krav 8, kännetecknat av att den medger certifiering av ett nykonstruerat eller modifierat program, som utnyttjar eller erbjuder gränssnittet, med hjälp av gränssnittet och modellprogrammet pà motstáende sida av gräns- snittet.

10. Mjukvarusystem enligt krav 9, kännetecknat av att om alla användningsfall eller hanteringar av användningsfall genomlöpts i modellprogrammet utan att nàgot otillåtet rapporte- rats så är det nykonstruerade eller modifierade programmet certifierat med avseende pà användningen eller erbjudandet av gränssnittet, så som gränssnittet föreligger.

11. Mjukvarusystem enligt krav 10, kännetecknat av att i certifieringen ingår även att kontrollera att alla av gräns- snittet berörda programsekvenser i programmet under certifiering genomlöpts, för att säkerställa att det inte finns dold, ospeci- ficerad funktionalitet.

12. Mjukvarusystem enligt krav 10 eller 11, känneteck- nat av att den möjliggör certifiering av en enskild programvaru- enhet i dess gränssnitt, oberoende av hur andra programvaruen- heter i samma system utförs och hanteras.

13. Mjukvarusystem enligt något av krav 7-12, känne- tecknat av att det första hjälpprogrammet är utformat som en komplett användare av gränssnittet omfattande samtliga tillàtna användningsfall, och att det andra hjälpprogrammet är utformat att hantera samtliga användningsfall och visa vad som skall hända i ett program, som i praktiken skall erbjuda gränssnittets funktionalitet.

14. Mjukvarusystem enligt något av krav 7-13, känne- tecknat av att de första och andra hjälpprogrammen är lika synliga som gränssnittet och innehåller en komplett information om gränssnittet.

15. Mjukvarusystem enligt något av krav 7-14, känne- 504 860 37 tecknat av att de första och andra hjälpprogrammen tillsammans med gränssnittet bildar en exekverbar enhet.

16. Mjukvarusystem enligt något av krav 7-15, känne- tecknat av att de första och andra hjälpprogrammen är utformade att bevaka program på andra sidan gränssnittet för att ge fel- utskrifter om ett sådant program skulle göra något otillátet.

17. Sätt att möjliggöra provning av ett gränssnitts funktion tillsammans med en programvara, som skall interagera med en annan programvara via gränssnittet, kännetecknat av att tillsammans med gränssnittet skapas ett första och ett andra hjälpprogram, där det första hjälpprogrammet är ett modellpro- gram, som simulerar sådan användning av gränssnittet att till- sammans med gränssnittet programvara kan provas, vars funktiona- litet skall erbjudas via gränssnittet, och det andra hjälppro- grammet är ett modellprogram, som simulerar sådant erbjudande av funktionerna i gränssnittet att tillsammans med gränssnittet programvara kan provas, som skall utnyttja via gränssnittet erbjudna funktioner, varvid de båda hjälpprogrammen konstrueras så att de kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de vid utprovning av själva hjälpprogrammen, eller vid nämnda provning av gränssnittets funktion tillsammans med en programvara, kontrollerar att den med gränssnittet provade programvaran ej gör något otillátet.

18. Sätt enligt krav 17, kännetecknat av att de båda hjälpprogrammen konstrueras, underhålls och levereras tillsam- mans med gränssnittet.

19. Sätt enligt krav 17 eller 18, kännetecknat av att det första hjälpprogrammet utformas som en komplett användare av gränssnittet omfattande samtliga tillåtna användningsfall, och att det andra hjälpprogrammet utformas att hantera samtliga användningsfall och visa vad som skall hända i programvara, som i praktiken skall erbjuda gränssnittets funktionalitet.

20. Sätt enligt något av krav 17-19, kännetecknat av att de första och andra hjälpprogrammen utformas att vara lika synliga som gränssnittet och innehåller en komplett information om, och definition av gränssnittet.

21. Sätt enligt något av krav 17-20, kännetecknat av att de första och andra hjälpprogrammen tillsammans med gräns- snittet utformas så att de bildar en exekverbar enhet. 504 860 38

22. Sätt enligt något av krav 17-21, kännetecknat av att de första och andra hjälpprogrammen utformas så att de bevakar den med gränssnittet provade programvaran för att ge felutskrifter om denna skulle göra något otillàtet.

23. Sätt att möjliggöra provning av ett gränssnitts funktion tillsammans med programvara, vars funktionalitet skall erbjudas annan programvara via gränssnittet, kännetecknat av att tillsammans med gränssnittet skapas ett hjälpprogram, som simu- lerar sådan användning av gränssnittet att tillsammans med gränssnittet nämnda programvara kan provas, och som är så kon- struerat att det kan utföra samtliga möjliga och tillåtna opera- tioner över gränssnittet, samtidigt som det kontrollerar att den med gränssnittet provade programvaran ej gör något otillàtet.

24. Sätt enligt krav 23, kännetecknat av att hjälppro- grammet konstrueras, underhålls och levereras tillsammans med gränssnittet.

25. Sätt enligt krav 23 eller 24, kännetecknat av att hjälpprogrammet utformas som en komplett användare av gränssnit- tet omfattande samtliga tillåtna användningsfall.

26. Sätt enligt något av krav 23-25, kännetecknat av att hjälpprogrammet utformas att vara lika synligt som gräns- snittet. I

27. Sätt enligt något av krav 23-26, kännetecknat av att hjälpprogrammet tillsammans med gränssnittet utformas så att de tillsammans med ett program under provning bildar en hanter- lig exekverbar enhet, och det genom hjälpprogrammet är möjligt att via gränssnittet initiera och styra förlopp i programmet som skall provas.

28. Sätt enligt något av krav 23-27, kännetecknat av att hjälpprogrammet utformas så att det bevakar den med gräns- snittet provade programvaran för att ge felutskrifter om denna skulle göra något otillàtet.

29. Sätt att möjliggöra provning av ett gränssnitts funktion tillsammans med programvara, som skall utnyttja via gränssnittet erbjudna funktioner från annan programvara, känne- tecknat av att tillsammans med gränssnittet skapas ett hjälppro- gram, som simulerar sådant erbjudande av funktionerna i gräns- snittet att tillsammans med gränssnittet nämnda programvara kan provas, och som är så konstruerat att det kan hantera samtliga 504 860 39 möjliga och tillåtna operationer det mottager över gränssnittet och ge tillbaka samtliga möjliga responser, samtidigt som det kontrollerar att programmet under provning inte använder gräns- snittet på ett otillåtet sätt.

30. Sätt enligt krav 29, kännetecknat av att hjälppro- grammet konstrueras, underhålls och levereras tillsammans med gränssnittet.

31. Sätt enligt något av krav 29 eller 30, kännetecknat av att hjälpprogrammet utformas att hantera samtliga använd- ningsfall och visa vad som skall hända i programvara, som i praktiken skall erbjuda gränssnittets funktionalitet.

32. Sätt enligt något av krav 29-31, kännetecknat av att hjälpprogrammet utformas att vara lika synligt som gräns- snittet och innehåller en komplett information om, och defini- tion av gränssnittet.

33. Sätt enligt något av krav 29-32, kännetecknat av att hjälpprogrammet tillsammans med gränssnittet utformas så att de tillsammans med ett program under provning bildar en hanter- lig exekverbar enhet, och hjälpprogrammet fångar upp förloppet i gränssnittet och återför det till programmet som provas.

34. Sätt enligt något av krav 29-33, kännetecknat av att hjälpprogrammet utformas så att det bevakar den med gräns- snittet provade programvaran för att ge felutskrifter om denna skulle göra något otillåtet.

35. Sätt enligt något av krav 29-34, kännetecknat av att tillsammans med gränssnittet och nämnda hjälpprogram skapas ett ytterligare hjälpprogram, som simulerar sådan användning av gränssnittet att tillsammans med gränssnittet förstnämnda hjälp- program kan provas, och som är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att förstnämnda hjälpprogram ej gör något otillåtet.

36. Sätt att skapa en referensmodell för ett kommunika- tionssystem, i vilket programvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från dessa programvaror av ett gränssnitt mot respektive programvara, kännetecknat av att ett första och ett andra hjälpprogram konstrueras, där det första hjälpprogrammet representerar programvaror, som kommuni- 504 860 40 cerar med varandra via protokollet, och både kan agera anropande och svarande i kommunikationen, det andra hjälpprogramet repre- senterar protokollet, varvid det första hjälpprogrammet skapas så att det kan agera som både anropande instans och svarande instans i kommunikationen, där de båda instanserna kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillátet.

37. Sätt enligt krav 36, kännetecknat av att de båda hjälpprogrammen konstrueras, underhålls och levereras tillsam- mans med gränssnittet.

38. Sätt enligt krav 36 eller 37, kännetecknat av att det första hjälpprogrammet utformas som en komplett användare av gränssnittet omfattande samtliga tillåtna användningsfall, både i rollen som anropande instans och i rollen som svarande in- stans, och att det andra hjälpprogrammet utformas att kunna hantera samtliga användningsfall och kunna generera samtliga tänkbara resultat, även fel, som kan uppstå vid hantering av användningsfallen och som är definierade i gränssnittet, samt visa vad som skall hända i ett program av ett visst utförande, som i praktiken skall erbjuda gränssnittets funktionalitet.

39. Sätt enligt krav 36, 37 eller 38, kännetecknat av att kommunikationen mellan de båda första hjälpprograminstanser- na förmedlas av det andra hjälpprogrammet, att endast den sva- rande instansen adresseras, och att det andra hjälpprogrammet kan generera alla möjliga felfall, som ett protokoll i praktiken kan drabbas av.

40. Sätt enligt något av patentkrav 36-39, kännetecknat av att de första och andra hjälpprogrammen utformas att vara lika synliga som gränssnittet och innehåller en komplett in- formation om, och definition av gränssnittet.

41. Sätt enligt något av patentkrav 36-40, kännetecknat av att de första och andra hjälpprogrammen tillsammans med gränssnittet utformas så att de bildar en exekverbar enhet, och att de båda hjälpprogramminstanserna skapas av det första hjälp- programmet, och kommunicerar med varandra med hjälp av det andra hjälpprogrammet, via gränssnittet.

42. Sätt enligt krav 41, kännetecknat av att de första och andra hjälpprogrammen utformas så att de bevakar ett program 504 860 41 på andra sidan gränssnittet för att ge felutskrifter om detta program skulle göra något otillåtet, och att det första hjälp- programmet även kontrollerar att ett användarprogram med vilket det kommunicerar, inte gör något otillàtet.

43. Mjukvarusystem för exekvering i dator och bildande en referensmodell för ett kommunikationssystem, i vilket programvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från dessa programvaror av ett gränssnitt mot respektive programvara, kännetecknat av ett första och ett andra hjälpprogram, där det första hjälppro- grammet representerar programvaror, som kommunicerar med varan- dra via protokollet, och både kan agera anropande och svarande i kommunikationen, det andra hjälpprogrammet representerar pro- tokollet, varvid det första hjälpprogrammet kan agera som både anropande instans och svarande instans i kommunikationen, där de båda instanserna kan utföra samtliga möjliga och tillåtna opera- tioner över gränssnittet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillàtet.

44. Mjukvarusystem enligt krav 43, kännetecknat av att det medger konstruktion, underhåll och leverans av de båda programmen tillsammans med gränssnittet.

45. Mjukvarusystem enligt krav 43 eller 44, känneteck- nat av att det första hjälpprogrammet är utformat som en kom- plett användare av gränssnittet omfattande samtliga tillåtna användningsfall, både i rollen som anropande instans och i rollen som svarande instans, och att det andra hjälpprogrammet är utformat att kunna hantera samtliga användningsfall och kunna generera samtliga tänkbara resultat, även fel, som kan uppstå vid hantering av användningsfallen och som är definierade i gränssnittet, samt visa vad som skall hända i ett program av ett visst utförande, som i praktiken skall erbjuda gränssnittets funktionalitet.

46. Mjukvarusystem enligt krav 43, 44 eller 45, känne- tecknat av att kommunikationen mellan de båda första hjälppro- graminstanserna förmedlas av det andra hjälpprogrammet, att endast den svarande instansen adresseras, och att det andra hjälpprogrammet kan generera alla möjliga felfall, som ett protokoll i praktiken kan drabbas av.

47. Mjukvarusystem enligt något av patentkrav 43-46, 504 860 42 kånnetecknat av att de första och andra hjälpprogramen är utformade att vara lika synliga som gränssnittet och innehåller en komplett information om, och definition av gränssnittet.

48. Mjukvarusystem enligt något av patentkrav 43-47, kännetecknat av att de första och andra hjälpprogrammen till- sammans med gränssnittet är utformade så att de bildar en ex- ekverbar enhet, och att de båda hjälpprograminstanserna är skapade av det första hjälpprogrammet, och kommunicerar med varandra med hjälp av det andra hjälpprogrammet, via gränssnit- tet.

49. Mjukvarusystem enligt krav 48, kännetecknat av att de första och andra hjälpprogrammen är utformade så att de be- vakar ett program på andra sidan gränssnittet för att ge fel- utskrifter om detta program skulle göra något otillåtet, och att det första hjälpprogrammet även kontrollerar att ett användar- program med vilket det kommunicerar, inte gör något otillátet.

50. Sätt att skapa en referensmodell, som i ett kommu- nikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarprogramvara, som skall kunna kommunicera med befintliga användarprogramvaror, känne- tecknat av att ett första och ett andra hjälpprogram skapas, där det 'första hjälpprogrammet simulerar en användarprogramvaras an- vändning av gränssnittet, och det andra hjälpprogrammet simule- rar protokollets funktioner, på så sätt att de båda hjälppro- grammen kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillátet.

51. Mjukvarusystem för exekvering i dator och bildande en referensmodell, som i ett kommunikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarprogramvara, som skall kunna kommunicera med befintliga användarprogramvaror, känne- tecknat av 504 860 43 ett första och ett andra hjälpprogram, där det första hjälpprogrammet simulerar en användarprogramvaras användning av gränssnittet, och det andra hjälpprogrammet simulerar protokoll- ets funktioner, på så sätt att de båda hjälpprogrammen kan utföra samtliga möjliga och tillåtna operationer över gränssnit- tet, samtidigt som de kontrollerar att ett program på andra sidan gränssnittet ej gör något otillátet.

52. Sätt att med en referensmodell enligt krav 51 prova ny användarprogramvara, kännetecknat av att den nya användarpro- gramvaran bringas i kommunikationsförbindelse med det första hjälpprogrammet via det andra hjälpprogrammet, varpå operationer tillhandahållna i de båda hjälpprogrammen exekveras.

53. Sätt att skapa en referensmodell, som i ett kommu- nikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny protokollprogramvara, känne- tecknat av att ett hjälpprogram skapas, som simulerar sådan användning av gränssnittet av en användarprogramvara att tillsammans med gränssnittet ny protokollprogramvara kan provas, och som är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att med gränssnittet provad internprotokollprogramvara ej gör något otillátet.

54. Mjukvarusystem för exekvering i dator, och bildande en referensmodell, som i ett kommunikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny protokollprogramvara, känne- tecknat av hjälpprogram, som simulerar sådan användning av gräns- snittet av en användarprogramvara att tillsammans med gränssnit- tet ny protokollprogramvara kan provas, och som är så konstrue- rat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att med gräns- snittet provad protokollprogramvara ej gör nägot otillátet. 504 860 44

55. Sätt att med en referensmodell enligt krav 54 prova ny protokollprogramvara, kännetecknat av att provningen av den nya protokollprogramvaran sker genom att bringa två kopior av hjälpprogrammet i kommunikationsförbindelse med varandra via den nya programvaran och exekvera i de två kopiorna tillhandahållna operationer-

56. Sätt att skapa en referensmodell, som i ett kommu- nikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarprogramvara, känne- tecknat av att ett hjälpprogram skapas, som simulerar sådant erbjudan- de av protokollets funktioner via gränssnittet att tillsammans med gränssnittet ny användarprogramvara kan provas, och som är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att ett program på andra sidan gränssnittet ej gör något otill- låtet.

57. Mjukvarusystem för exekvering i dator, och bildande en referensmodell, som i ett kommunikationssystem, i vilket användarprogramvaror skall kunna kommunicera med varandra via ett protokoll, som är skilt från respektive användarprogramvara av ett motsvarande gränssnitt, möjliggör provning av ny användarprogramvara, känne- tecknat av ett hjälpprogram, som simulerar sådant erbjudande av protokollets funktioner via gränssnittet att tillsammans med gränssnittet ny användarprogramvara kan provas, och som är så konstruerat att det kan utföra samtliga möjliga och tillåtna operationer över gränssnittet, samtidigt som det kontrollerar att ett program på andra sidan gränssnittet ej gör något otill- låtet.

58. Sätt att prova ny anvàndarprogramvara med referens- modell enligt krav 57, kännetecknat av att provningen av den nya användarprogramvaran sker genom att bringa två kopior av denna i kommunikationsförbindelse med varandra via hjälpprogrammet och exekvera i detta tillhandahållna operationer.