SE517033C2 - Systemplattform för kommunikationssystem - Google Patents

Description

517 033 i i 2 medger rutiner för generering av nya objekttyper utan1nodifiering av operativsystemets kärna.

I US 5,421,015 beskrivs ett objektorienterat databehand- lingssystem, innefattande en.utvidgningsbar objekttypuppsättning och en motsvarande uppsättning objekthanterare.

Redogörelse för uppfinningen.

Ett allmänt huvudsyfte med uppfinningen är att för ett kommunikationssystem effektivisera hanteringen av ett systems tilläggsfunktioner, dvs. de delar av systemet som är valfria, marknadsberoende eller som levereras till en kund efter det att det system som tillhandahåller bastjänsterna har levererats.

Ett mera bestämt syfte är att uppnå denna effektivisering genom att möjliggöra modifiering och utvidgning av de av ett system tillhandahàllna tjänsterna utan att behöva ändra mjukvaran hos de funktioner som redan har implementerats och levererats. _ Dessa och andra syften, som.kommer att framgå fortsättnings- vis, har uppnåtts genom de i patentkraven angivna kännetecknen.

Vid en systemplattform av inledningsvis definierat slag är det översta skiktet implementerat med basobjekt och utvidgnings- objekt. Basobjekten är objekttyper, som med en eller flera däri ingående metoder implementerar basfunktioner, som kan behöva utvidgas i framtiden och utvidgningsobjekten är objekttyper som med en eller flera däri ingående metoder möjliggör implementering av'utvidgningsfunktioner, sonlutgör utvidgningar till basfunktio- nerna. Varje basobjekttyp är konstruerad för en särskild uppgift, som kan utföras med minimal koordinering med andra basobjekt.

Utvidgningsobjekten är konstruerade för att medge tillägg av nya tjänster och modifiering och utvidgning av befintliga tjänster utan att ändra mjukvaran hos de tjänster, som redan har implemen- terats och levererats. Utvidgningsobjekten kan även innefatta objekttyper som implementerar utvidgningsfunktioner, vilka utgör utvidgningar till utvidgningsfunktionerna, och även objekttyper som implementerar interaktionshanterande utvidgningsfunktioner, vilka hanterar interaktion mellan tilläggstjänster.

Utvidgningsobjekten möjliggör introduktion av utvidgningar i ett system i drift, vilka binds dynamiskt till basobjekt som ; u u - n. 517 oss- ~ skall modifieras.

Utvidgningarna är konfigurerbara, dvs. möjliggör att i runtime lägga till och avlägsna systemets modifieringar på ett generellt sätt utan att konstruktören själv behöver konstruera kod för själva aktiveringen/avaktiveringen av utvidgningen, vilket sköts av plattformen.

Beteendet hos ingående objekttyper definieras genom att beskriva beteendet hos varje däri ingående metod som en ändlig tillstándsmaskin. Denna tillstándsmaskin består av ett ändligt antal tillstånd och övergångar mellan dessa tillstånd, där koden som definierar metoden exekveras. Utvidgningarna tillförs vid tillstånden, där de då tar över exekveringskontrollen och returnerar den, efter att ha avslutat sin egen exekvering, till en annan eller samma utvidgningspunkt.

Det enligt uppfinningen.angivna utvidgningskonceptet har ett antal värdefulla egenskaper. Det är ett finkornigt sätt att göra modifieringar genom att det inte är nödvändigt att överrida hela metoder, vilket är den nækanism, som finns tillgänglig i de flesta objektorienterade formalismer. I stället kan överridandet ske i vissa utvidgningspunkter inuti metoder. Utvidgningskon- ceptet utgör ett ramverk för att ta hand om den komplicitet som förorsakas av införande av många tilläggsfunktioner i ett fárdigutvecklat och levererat system. Detta möjliggörs genom att beskriva de modifikationer som förorsakas av varje utvidgning separat, varpå utvidgningarna kan i sin tur koordineras när sådant behov föreligger. Sådana koordineringar mellan tilläggs- funktioner uttrycks även som separata utvidgningar, i detta fall son1utvidgningar till tilläggsfunktionerna. Detta gör det möjligt att hantera systemets valbara delar och deras beroenden på ett modulärt sätt.

Figurbeskrivning.

Uppfinningen skall nu beskrivas närmare med hänvisning till bifogade ritningar, på vilka I fig. 1 schematiskt åskådliggör en systemplattform för ett telekommunikationssystem, som kan tillhandahålla abonnenttjäns- CSI", 517 033 - - ' ' " o n ; o u n ø | o ~ n n» 4 fig. 2 är en bild avsedd att illustrera sambandet mellan begrepp, som används vid utvidgningskonceptet enligt uppfin- ningen, fig. 3 åskådliggör utvidgningskonceptet i en översiktsvy, fig. 4-6 visar exempel på en specifikation, en realisering, resp. en utvidgningsvy av ett basobjekt, fig. 7-9 visar exempel på en specifikation, en realisering, resp. en utvidgningsvy av ett utvidgningsobjekt, fig. 10 är en vy avsedd att ge en sammanfattande översikt av relationerna mellan begreppen basobjekt, utvidgningsobjekt, och utvidgningsvy, liksom objekttypspecifikation, -realisering och -implementation, fig. 11-14 är vyer, som visar exempel, som åskådliggör användning av utvidgningsmekanismen, varvid fig. 11 visar ett ovillkorat utvidgningsfall, fig. 12 visar ett villkorat utvidgningsfall, ' fig. 13 visar ett fall innebärande en händelse-utvidgning, fig. 14 visar ett fall med flera utvidgningar vid sama utvidgningspunkt.

Föredragna utföringsformer.

Med hänvisning till fig. 1 innehåller en systemplattfor¶1för ett telekommunikationssystem ett antal funktioner, eller skikt.

Dessa skikt kan allmänt beskrivas såsom innehållande ett operativsystem i ett undre skikt 102, en därpå belägen applika- tionsplattform 104 innehållande lämpliga telekommunikationsab- straktioner i form av resursobjekt, samt därpå ett skikt 106 innehållande önskade applikationer i form av bas- och tilläggs- funktioner vilka tillhandahåller bas- och tilläggstjänster, Fortsättningsvis komer begreppet "kategori" att användas för att definiera olika typer av objekt, som ingår i skiktet 106.

En "kategori" karakteriserar närmare bestämt ett objekt syntak- tiskt, men karakteriserar också dess plats och funktion i systemets arkitektur. Nedan närmare beskrivna objekttyper av två kategorier benämnda BASE resp. EXTENSION, ingår i en implementa- tion av skiktet 106. Instanser av dessa objekt komer nedan att benämnas basobjekt resp. utvidgningsobjekt. 517 oss ~ ~ *näts- 5 Vidare förekommer nedan ett begrepp "händelser", eller "events", som används som benämning på utsändning av asynkrona meddelanden. Objekt kan begära övervakning av en "händelse" och därpå vänta på den. Händelser deklareras i en "EVENTS"-sektion i beskrivningen av en objekttyp. I skiktet 106 drivs beteendet av händelser, dvs. objekten reagerar på mottagning av asynkrona meddelanden. Händelser genereras ofta som resultat av att ett meddelande anländer på en interprocess-kommunikationslänk till en process, i vilken objektet exekverar. Med process avses här ett program under exekvering. Nedan kommer även benämningen exekveringstråd att användas för en exekveringsbana i en.process.

Varje exekveringstråd har sin egen stack och programräknare, men alla trådar i samma process delar på samma processdata (heap).

Varje basobjekttyp är konstruerad för att utföra en särskild uppgift, såsom hantering av uppställning av ett koppel i ett telefonisystem. När en sådan uppgift skall utföras skapas en instans av basobjekttypen. Detta objekt har därpå kontroll över hur uppgiften utförs. Detaljer på lägre nivåer, såsom hur resurser manipuleras för att utföra uppgiften, hanteras genonlatt basobjektet skickar ut metodanrop till objekt av andra kategori- er, t.ex. av kategorien "EVENTGENERATOR". Objekttyper av denna kategori representerar resurser'eller grundläggande tjänster, som anropas och som underrättar sina användare genom att generera events, dvs. händelser.

Basobjekttyper' är avsedda att konstrueras så att deras respektive uppgifter kan utföras med minimal koordinering med andra uppgifter som pågår i systemet, dvs. med minimal koordine- ring mellan basobjekt. Detta återspeglas i egenskaperna hos bas- och.utvidgningskategorierna: varje basobjekt exekveras i en semi- parallell s.k. exekveringstråd, varken bas- eller utvidgningsob- jekt kan ha några utifrån,anropbara metoder och de kan inte generera några händelser. Dessa egenskaper kommer att beskrivas närmare nedan.

En annan betydelsefull aspekt av bas- och utvidgnings- kategorierna är att de stödjer ett utvidgningskoncept, som tillåter att ett systems beteende kan modifieras och utvidgas utan att det är nödvändigt att ändra systemets existerande 5,, m 6 implementering. I stället uppnås modifiering och utvidgning av beteendet genom laddning av enbart utvidgningarna i systemet.

Dessa kommer då att med hjälp av utvidgningskonceptet indirekt modifiera systemets beteende genom att ta över exekveringskon- trollen i vissa förutbestämda utvidgningspunkter.

Baskategorien skall användas för objekttyper, som implemen- terar basfunktionalitet, vilken kan behöva utvidgas i framtiden, s.k.basfunktioner.Utvidgningskategorienanvändsförcflflekttyper som implementerar utvidgningar till dessa basfunktioner, s.k. utvidgningsfunktioner.

Beteendet hos en objekttyp definieras genom att beskriva beteendet hos varje metod som en ändlig tillståndsmaskin genom användning av ett specifikt konstruktionsspräk för objekt- modellering, fortsättningsvis hänvisat till som "konstruktions- språket". En sådan ändlig tillstándsmaskin består av ett ändligt antal tillstånd och övergångar mellan dessa tillstånd, där kod exekveras som övergångsaktioner. De mest naturliga punkterna för att tillföra utvidgningar, utvidgningspunkterna, är därför tillstànden. En utvidgning kan konstrueras att ta över exekve- ringskontrollen i en utvidgningspunkt och returnera kontrollen till en annan, eller sama utvidgningspunkt i samma metod. Ur denna synpunkt kan utvidgningar betraktas som tillägg av nya tillstånd och. tillståndsövergángar till en tillståndsmaskin.

Dessa tillstånd och tillståndsövergàngar modifierar då denna tillstàndsmaskins existerande tillständsövergángar.

Alla tillstànd i en metod kan alltid användas som utvidg- ningspunkter, men det är även möjligt att explicit specificera en utvidgningspunkt utan att introducera ett nytt tillstånd, en s.k. explicit benämnd utvidgningspunkt.

Utvidgningspunkter klassificeras efter om de tillåter ut- vidgningar från punkten, terminering av utvidgningar vid punkten eller om de kan användas för båda ändamàlen. För dessa punkter komer fortsättningsvis följande benämningar att användas. - Övertagningspunkter (TOP - Take Over Point), som är utvidgningspunkter där exekveringskontrollen kan överföras till en utvidgningsmetod hos ett utvidgningsobjekt.

- Fortsättningspunkter (COP - Continuation Point), som är 51, 032, ::.:::f~:ïï:::æ 7 utvidgningspunkter där exekveringskontrollen kan àterföras fràn en utvidgningsmetod. - Övertagnings- och fortsättningspunkter (TOP COP - Take Over and Continuation Point), som är utvidgningspunkter, som kan användas både som övertagningspunkt och fortsättningspunkt.

Från början (default) är alla tillstånd i ett objekt övertagnings- och fortsättningspunkterx Detta kan. emellertid ändras i objekttypspecifikationen om det föreligger ett behov av att göra begränsningar som måste hälla för alla utvidgningar.

Samma slags utvidgningar kan även göras i utvidgningsvyer, ett koncept som kommer att beskrivas närmare nedan.

Utvidgningskonceptet medger också definiering av utvidg- ningar till utvidgningar. Utvidgningar kan i själva verket definieras på ett godtyckligt antal nivåer' med skapande av kedjor, eller skikt av utvidgningar. Därför är det nödvändigt att definiera en vokabulär så att det är möjligt att skilja mellan t.ex. den "översta" utvidgningen i en utvidgningskedja och hela kedjan av utvidgningar.

Begreppet "basobjekt" används för att indikera det objekt som omfattar den ursprungliga, outvidgade basfunktionen. Om det finns risk för missförstånd används benämningen "ursprungligt basobjekt".

Utvidgningar hänvisas till såsom "utvidgningsobjekt".

Begreppet närmaste bas (immediate base) hänför sig till ett basobjekt eller ett utvidgningsobjekt varifrån en utvidgning börjar, dvs. en utvidgning tar över från sin närmaste bas.

Den mer generella benämningen bas kommer att användas för att avse hela kedjan av utvidgningar, innefattande det ursprung- -liga basobjektet, till vilket ett visst utvidgningsobjekt bildar utvidgning. Om det finns risk för missförstånd används benäm- ningen "hela basen". r Det ovan sagda illustreras i fig. 2 där ett objekt 202, "Base0bject", är det ursprungliga basobjektet. Till basobjektet 202 kan utvidgningsobjekt 204 och 206, "Extension Objectl" resp.

"Extension Objectz", knytas. Utvidgningsobjektet 206 utgör den närmaste basen för ett ytterligare utvidgningsobjekt 208, "Ex- tensionObject2l“. Basobjektet 202 och utvidgningsobjektet 206 utgör bas för utvidgningsobjektet 208.

En specifikation för ett utvidgningsobjekt definierar vid vilka utvidgningspunkter i utvidgningsobjektet som utvidgningen antas ta över kontrollen och vid vilka utvidgningspunkter det kan áterlämna kontrollen. När ett utvidgningsobjekt erhåller kontroll, är det en förutdefinierad utvidgningsmetod, EXTENSION METHOD, som startar exekveringen. Runtime-systemet tar hand om skapande av utvidgningsobjekt och invokering av deras utvidg- ningsmetoder vid de angivna utvidgningspunkterna.

Såsom framgått av ovanstående kan även utvidgningsobjekt i sin tur erhålla utvidgningar. Utvidgningsmetoder anropas alltså alltid implicit från en basmetod eller från en annan utvidgnings- metod.

Ett utvidgningsobjekt har access till attribut och metoder hos det utvidgade objektet, dvs. det basobjekt eller det utvidgningsobjekt, son1utvidgningen tar över kontrollen från. Det finns emellertid några sätt att begränsa denna access. För det första är det endast de attribut och metoder, som är deklarerade i en objekttypspecifikation, som kan accessas. Attribut och metoder som är deklarerade endast i en realisering är inte tillgängliga för utvidgningar. I specifikationen är det vidare möjligt att definiera accessrestriktioner för' varje utvidg- ningspunkt, genom att definiera att endast en viss deluppsättning av attributen och metoderna i specifikationen är tillgängliga för de utvidgningar som tar över kontrollen i en viss utvidgnings- punkt.

Objekttypspecifikationen för ett utvidgningsbart objekt fungerar sålunda som ett gränssnitt som begränsar mängden information som är synlig och tillgänglig för utvidgningar av detta.basobjekt. Det finns emellertid ett extra.gränssnittsskikt, som används tillsamans med,utvidgningskonceptet, och detta är det gränssnitt, som definieras av utvidgningsvyerna. En utvidg- ningsvy definierar en deluppsättning av information i specifika- tionen av ett utvidgningsbart objekt, som skall kunna accessas av de utvidgningar som använder vyn.

Fig. 3 åskådliggör utvidgningsprincipen. I fig. 3 represen- terar ett block 302 specifikationen av ett basobjekt, och ett ø u v . »o 517 oss :aza-ïšglšï-ffi* 9 block 304 specifikationen.av ett utvidgningsobjekt. Specifikatio- nen 302 innehåller en grundmetod, "BODY", representerad av ett block 306 i vilket en ändlig tillstàndsmaskin 308 med fyra tillstånd antyds. Dessa tillstànd innefattar två utvidgnings- punkter sl och s2. Utvidgningspunkterna sl och s2 är i en utvidgningsvy, indikerad.med ett block 310, deklarerade som över- tagningspunkt resp. fortsättningspunkt, indikerat genon1"TOP sl;" resp. "COP s2;". Ett block 312 representerar en ytterligare metod "Method ml" i specifikationen av basobjektet genom en antydd ändlig tillstàndsmaskin med fem tillstånd.

Specifikationen 304 av utvidgningsobjektet innehåller en utvidgningsmetod "EXTENSION METHOD extl", som i ett block 314 åskådliggörs såsom innehållande en ändlig tillstàndsmaskin med tre tillstånd innefattande ett starttillstånd t och ett sluttill- stånd s2. I ett block 316 antyds en.ytterligare utvidgningsmetod, "METHOD ext2", såsom innehållande fyra tillstånd.

Utvidgningspunkterna sl och s2 âr synliga från utvidgnings- objektet genonzutvidgningsvyn 310. När metoden 308 hos basobjekt- et när tillståndet sl kopplar exekveringskontrollen över till utvidgningsmetoden extl, indikerat med pil 318. Utvidgnings- metoden extl börjar exekvera från sitt ursprungstillstånd t. När slutligen exekveringen når tillståndet s2 i utvidgningen, kopplar kontrollen tillbaka enligt pil 320 till basen, som fortsätter sin exekvering från tillståndet s2. Detta sköts av runtimesystemet, dvs. konstruktören av utvidgningen behöver inte hantera detta explicit i sin kod, annat än vid en deklaration i utvidgningen.

Kategorien BASE är, såsom nämnts tidigare, den objekttyp- kategori sonlanvänds för modellering av basfunktioner, funktioner vilka kan utvidgas senare. Basobjekt har vissa speciella egenskaper. En betydelsefull egenskap är att exekveringen av ett basobjekt alltid sker i en~semi-parallell styrtråd. Detta är naturligt eftersom ändamålet med ett basobjekt är att utföra en uppgift som kan äga rum oberoende av andra uppgifter som kan pågå parallellt i systemet. Under exekvering kan objektet inträda i vänttillstånd, vilka är tillstånd där exekvering inställs tills vidare och styrningen övergår till en annan tråd. Exekveringen återupptas när en viss händelse, som avvaktas i vånttillstándet n u u . nu u 517 033 '::fIII=' 10 mottages.

I ett användarperspektiv kan denna egenskap uppnås genom att skapa en.ny basobjektinstans i den aktuella exekveringstráden och schemalägga grundmetoden "BODY" hos denna basobjektinstans för senare exekvering i en ny tråd. En trådomkoppling sker när den först aktuella tråden inträder i ett vänttillstånd. I detta steg får den nyskapade tråden en chans att starta exekvering. Det kan emellertid finns andra trådar i processen, som också är färdiga att starta exekvering, så det finns ingen garanti för att den nya tråden kommer att starta exekveringen i just detta ögonblick. Den enda garantin är att den kommer att påbörja exekvering så småningom.

I samband med skapandet av den nya tråden returneras en referens till den nyskapade objektinstansen. Denna referens kan senare användas för synkronisering med terminering av den skapade tråden, genom att avvakta den händelse som alltid uppträder när en tråd terminerar. Referensen kan även användas som ett argument eller lagras i ett attribut, men den skall inte användas för något annat ändamål.

En annan 'viktig egenskap hos basobjekten är att deras attribut och metoder är dolda för alla andra objekt med undantag av deras utvidgningsobjekt.

För ett basobjekt kan det finnas både en specifikation och en realiseringsbeskrivning, båda innehållande beteendebeskriv- ningar med användning av konstruktionsspráket. Ändamålet med specifikationen är huvudsakligen att verka som en gränssnittsbe- skrivning av basobjektet. Det finns olika slags klienter till ett basobjekt för vilka denna specifikation är relevant.

För det första finns det utvidgningsobjekten, som utvidgar basobjektets beteende. För dessa verkar specifikationen som en gränssnittsbeskrivning son\visar'tillstånd, attribut och1netoder, som är tillgängliga för utvidgningarna. Ytterligare accessbe- gränsningar kan även införas för utvidgningar genom den utvidg- ningsvy de använder, men de kan aldrig accessa mer än vad som visas i basobjektets specifikation.

För det andra definierar specifikationen det gränssnitt mot klientobjekten som behöver skapa instanser av basobjektet. Detta v v-v- . s nu t. 517 oss Iš. ll gränssnitt definieras av metoder hos basobjekttypen. De avgör vilka parametrar som kan användas vid skapande av den nya instansen när en ny exekveringstràd skall skapas enligt vad som ovan beskrivits.

Ett annat ändamål med specifikationen är att ge en hög- nivábeskrivning av basobjekttypens beteende med utelämnande av implementationsdetaljer som är onödiga för uppnàende av för- ståelse av objekttypens funktion, Den höga abstraktionsniván ástadkommes delvis genom ett abstraktionsskikt som skapas av en underliggande objektlogik, som används av basobjektet, men även genom lokala metoder i basobjektet som omfattar användningen av objektlogiken. En rimlig abstraktionsnivå i en specifikation kan vara att visa basobjektets vänttillstànd i specifikationen och kanske vissa utvalda icke-vänttillstánd, som är fundamentala för förståelse av' basobjektets funktion. Koden för att exekvera mellan de visade tillstånden kan därpå införas i lokala metoder som deklareras, men ej nödvändigtvis beteendespecificeras, i specifikationen.

När det skall avgöras vad som skall visas i specifikationen och inte, måste hänsyn även tas till vilka delar av objekttypen som kan underkastas utvidgningar i framtiden. Den mest utvidg- ningsbara specifikationstaktiken är att visa alla tillstånd, både vänttillstànd.och icke-vänttillstánd, och alla explicit namngivna utvidgningspunkter, i specifikationen av BODY-metoden och att endast inkapsla en aktionskod son1används vid tillståndsövergång- ar, i lokala metoder. Om det á andra sidan avgörs att vissa delar av beteendet ej behöver vara utvidgningsbara, kan dessa delar i sin helhet införas i lokala metoder. Dessa lokala metoder kan därpå definieras antingen i specifikationen eller realiseringen eller t.o.m. på implementationsnivån. Om de skall anropas från specifikationen, mäste de emellertid deklareras i specifikatio- nen. Ãndamålet med objekttyprealiseringar är att de skall användas för de delar av basobjekten som inte behöver, eller kan vara utvidgningsbara, och som ej är nödvändiga att visa i specifikationen för att skapa en högnivåbeskrivning, men där en definition med ett konstruktionsspràk föredras i stället för av u.. n I n - .n 517 033 *zfiiiïf 12 användning av implementationsspråk:direkt. Definitioner av lokala metoder som inkapslar aktionskod kan placeras här. I en realise- ring är det även. möjligt att hoppa över i specifikationen ingående beteendedefinitioner, och ge en mera detaljerad definition. En sådan nydefinierad beteendedefinition bör utgöra en förfining av beteendespecifikation, sonnges i specifikationen.

Det bör framhållas att attribut eller tillstånd som finns definierade eller deklarerade i en realise- inga metoder, ring kommer att vara tillgängliga för utvidgningar av denna objekttyp. Det är endast informationen i obj ekttypspecifikationen som är synlig för utvidgningarna.

Det är även möjligt att specificera hela basobjektet med användning endast av en specifikation i konstruktionsspråket, och ingen realisering i detta språk. I detta fall kan implementa- tionsspråket användas för att definiera vissa av de aktionsmeto- der som anropas i specifikationen, där så är lämpligt. Över- vakning, "MONITOR", och stoppa övervakning, "STOP MONITOR", av händelser måste antingen i specifikationen eller i realiseringen. Om "skapande/- emellertid utföras i konstruktionsspråket borttagning" av objekt utförs i konstruktionsspråket måste likaledes motsvarande meddelande "avlägsna/ny" för samma objekt utföras i konstruktionsspråket, antingen i specifikationen eller realiseringen. Onldäremot skapande/borttagningwitförs i implemen- tationsspråket, måste även motsvarande avlägsna/ny utföras i implementationsspráket.

För grundmetoden (BODY) hos objektet är det obligatoriskt att ge en beteendedefinition med konstruktionsspråket i specifi- kationen, även om denna definition kan tillåtas vara ganska enkel, och kan överridas i realiseringen. För andra metoder i basobjekt är, som nämnts, användningen av konstruktionsspråket valfri. f I fig. 4 och 5 ges exempel på specifikation resp. reali- sering av ett objekt "theBase" av basobjekttyp.

I den i fig. 4 visade specifikationen har från rad 12 beteendet hos grundmetoden, "BODY'method“, definierats. Metoderna "methodl" och "method2“, och "CONSTRUCTOR", har emellertid endast deklarerats, från rad 7. CONSTRUCTOR är en metod som exekveras o ø u - .n 517 oss šïï: %;%ï::=- Ilšï-ífêïë 13 när en instans av en objekttyp skapas.

I den i fig. 5 visade realiseringen definieras från rad 2 beteendet hos metoderna "CONSTRUCTOR", "methodl" och "method2".

Grundmetoden anges vara som den i specifikationen, rad 22.

Såsonlnämnts tidigare tjänar specifikationen.av'basobjektty- pen.sonnen.gränssnittsbeskrivning för dess klienter. Utvidgnings- vyer utgör även ett slags gränssnittsbeskrivningar. De används för att ytterligare begränsa accessen till ett utvidgningsbart objekt för deras utvidgningar. Ändamålet med att ha ett extra gränssnittsskikt är att uppnå viss ytterligare kontroll över vilka utvidgningar som kan göras till ett visst objekt. Olika utvidgningsvyer kan skapas för olika ändamål. Om exempelvis en viss vy är konstruerad för användning av faktureringsfunktioner och statistikfunktioner kan det vara tillräckligt att visa enbart en liten delsats av det utvidgade objektets tillstånd och attribut. En annan användning är att definiera olika vyer för olika delar av en funktion så att användningen av en utvidgning av en viss vy innebär att endast en viss funktion hos det utvidgade objektet modifieras. Detta och liknande information kan vara av värde när man undersöker vilka koordinationer mellan tilläggsfunktioner som kan vara nödvändiga att implementera när en ny tilläggsfunktion introduceras i systemet.

Ett basobjekt kan således ha flera olika utvidgningsvyer.

Varje utvidgningsobjekt är emellertid.konstruerat för en särskild utvidgningsvy. Utvidgningsvyerna används endast under konstruk- tionsfasen, för olika analysändamål, och existerar inte som separata enheter i runtime-omgivningen.

I fig. 6 visas exempel på en utvidgningsvy av objektet theBase av basobjekttyp i fig. 4. En utvidgningsvy används för att skapa begränsade vyer av specifikationer av utvidgningsbara objekt. Utvidgningsvyer kan inte definiera någon information som inte redan finns tillgänglig i basobjektet. De kan endast tillföra ytterligare begränsningar och dölja information, som redan är synlig i basobjektet. Begränsningar som redan finns specificerade i basobjektet kan ej övverridas.

I utvidgningsvyn ges först en lista av metoder och attribut »nu uuu øuu n u n uu uu uu u uu p u u u u uu u u u uu ~ u un u u u u ucuu o o v u uu :uu uu; uu uuo uu u u un uu u u, u u uu u u u . u uu u u v = e == v== m: :nu u: 14 i basobjektet, som skall vara möjliga att nå genom utvidgningar, jfr. raderna 3-6 i fig. 6. Denna lista definierar en delsats av attribut och metoder som existerar i basobjektet. Därpå listas de utvidgningspunkter som skall finnas tillgängliga för utvidg- ningarna. För varje utvidgningspunkt i vyn specificeras följande information: - Utvidgningspunktens namn, jfr. rad 7, 11, 15 resp. 18 i fig. 6: TOP WAIT STATE, TOP COP STATE, TOP STATE resp. COP STATE.

För utvidgningspunkter som är tillstånd, ges nyckelorden STATE resp. WAIT STATE i namnet. För explicit namngivna utvidgnings- punkter ges ingen sådan information. Vidare innehåller namnet typen av utvidgningspunkt: övertagningspunkt TOP, fortsätt- ningspunkt COP eller övertagnings- och fortsättningspunkt TOP COP anges. Som tidigare nämnts är frán.början alla utvidgningspunkter i basobjektet av typen övertagnings- och fortsättningspunkt. Här kan en utvidgningspunkt begränsas att tillåta användning endast som övertagningspunkt eller endast som fortsättningspunkt. Om grundinställningen skall användas måste ändock nyckelordet TOP COP ges.

- För varje övertagningspunkt finns det en lista av attribut och metoder i basobjektet som kommer att finnas tillgängliga för utvidgningsmetoderna som startar från den specificerade övertag-' ningspunkten, jfr. rad 9, 12-13, resp. 16 i fig. 6. Denna lista utgör en deluppsättning av attribut och metoder, som listas i början av utvidgningsvyn.

- För varje övertagningspunkt ges en lista av tillåtna fortsättningspunkter COPs, jfr. rad 8 i fig. 6. Denna information används för att avgöra vid vilka utvidgningspunkter en utvidgning som tar över kontrollen i den aktuella övertagningspunkten tillåts fortsätta.

- För varje övertagningspunkt anges typen av uttryck som används för avgrening i basobjektets tillstànd. Detta är endast relevant för icke-vänta-tillstånd.

Det är inte möjligt att hänvisa till lokala variabler hos metoder i basobjektet i en utvidgningsvy. .

Eftersom utvidgningskonceptet medger även utvidgningar till utvidgningar, kan utvidgningsvyer skapas både för basobjekt och f. anno 517 oss 15 för utvidgningsobjekt.

För utvidgningsobjekt gäller samma begränsningar som för basobjekt. Deras medlemmar kan inte accessas av några andra objekt än deras utvidgningar. Även för utvidgningsobjekt kan både en specifikation och en realisering ges. För utvidgningsmetoden hos ett utvidgningsobj ekt är det obligatoriskt att ge en beteendedefinition med konstruk- tionsspràket i specifikationen, ehuru denna definition tilláts vara ganska enkel, och den kan överridas i realiseringen. För andra metoder i utvidgningsobjekten är användning av konstruk- tionsspràket valfri.

I fig. 7, 8 och 9 ges exempel pá en specifikation av ett objekt av utvidgningstyp, "theExtObj", objekt, resp. en utvidgningsvy av objektet i fråga.

Utvidgningar är inkapslade i objekt av kategorien EXTENSION.

Specifikationen av ett utvidgningsobjekt, jfr. fig. 7, rar vilken vy som utvidgningsobjektet använder, jfr. rad 3, vid vilka EXTENSION METHOD kontrollen, jfr. rad 8, samt prioritetsklassen för utvidgnings- en realisering av sama definie- övertagningspunkter dess tar över metoden, jfr. rad 7. Flera olika utvidgningsobjekt kan använda samma vy av ett basobjekt. Multipla utvidgningar kan t.o.m. starta från samma utvidgningspunkt i sama objekt.

Metoderna i ett utvidgningsobjekt exekveras alltid i sama trád som basobjektet. All övervakning av händelser som företas i basobjektet är vidare även giltig i utvidgningsmetoden.

Utvidgningsmetoden kan med andra ord mottaga händelser som har förutsatt att händelsegeneratorns övervakats i basobjektet, identitet har gjorts tillgänglig för utvidgningsmetoden via en vy.

Tillstànden i specifikationerna för EXTENSION METHODS kan användas som övertagnings-:och fortsättningspunkter, på sama sätt som tillstànd i basobjekten. Realiseringarna av utvidgningsmetoderna, jfr. fig. 8, kan pá samma sätt tillföra fler tillstànd, jfr. rad 2 och 8, specifikationen av BODY-metoderna hos men återigen är de inte tillgängliga för några utvidgningar.

Ytterligare utvidgningar till utvidgningsobjektet theExtObj kan göras enligt vad som antyds i den endast i form av en stome p | o ø nu 517 oss :; u: 16 presenterade utvidgningsvyn i fig. 9.

Fig. 10 ger' en sammanfattande översikt av relationerna mellan begreppen basobj ekt , utvidgningsobj ekt , och utvidgningsvy, liksonlobjekttypspecifikation, -realisering och -implementation.

I fig. 10 indikerar ett stapelblock 1002 specifikation 1004 och realisering 1006 i ett konstruktionssprák, 1008 i ett målspråk. På samma sätt indikerar ett stapelblock 1010 specifikation 1012 och realisering 1014 i ett konstruktionsspråk, samt implementation samt implementation 1016 i ett målspråk.

Specifikationen 1004 av basobjektet utgör en specifikation på en lämpligt hög abstraktionsnivå som kan användas för att erhålla en total förståelse av objekttypens funktion. Specifika- tionen innehåller både attribut och metodsignaturdeklarationer liksom beteendespecifikationer av (en delsats av) metoder. Alla tillstànd som visas i beteendespecifikationen av BODY-metoden kan användas av utvidgningar.

Realiseringen 1006 av basobjektet har en mera detaljerad beskrivning av objekttypens beteende. Den kan överrida beteende- definitioner av metoder i obj ekttypspecifikationen. Realiseringen kan även definiera beteendet hos deklarerade metoder men ej beteende specificerat i specifikationen. Nya attribut och metoder, som är lokala för realiseringen kan tillföras. Informa- tionen som tillförts i realiseringen är ej tillgänglig för utvidgningar. En specifikation kan ha fler än en realisering.

Implementationen 1008 av basobjekttypen i nálspråk är en fullständig implementation av objekttypen. Den består av genererad och, valfritt, manuellt skriven källkod för màlspråket (C++). De genererade delarna garanterar att implementationen är förberedd för utvidgningar enligt objekttypspecifikationen.

Implementationskoden genereras med användning av objekttyp- specifikationen och, valfritt, en eller flera av realiseringarna av objekttypen i konstruktionsspråket.

Vid 1018 och 1020 indikeras utvidgningsvyer av basobjekttyp- specifikationen 1004. Det kan finnas flera vyer av samma objekttypspecifikation, men varje vy är alltid konstruerad för exakt en objekttypspecifikation. Nya vyer kan skapas utan att påverkabasobjektspecifikationen,-realiseringeneller-implemen- - v~_- e. uv-o 517 053 17 tationen. Basobjekttypspecifikationen.1004 och dess vyer 1018 och 1020 används vid konstruktion av utvidgningsobjekttyper.

Specifikationen 1012 av utvidgningsobjekttypen specificerar utvidgningsobjektet.pá samma höga abstraktionsnivà souxspecifika- tionen av basobjekttypen. Även realiseringen 1014 och implementa- tionen 1016 av utvidgningsobjekttypen förekommer pà samma sätt som för basobjekttypen.

Varje specifikation för utvidgningsobjekttypen konstrueras alltid med användning av exakt en utvidgningsvy 1022. Analogt med förhållandet vid basobjekttyper kan för en utvidgningsobjekttyp en eller flera utvidgningsvyer definieras.

Kod i mälspràket (C++) kan genereras för objekttypspecifikationer och -realiseringar. Allarmetoder, innefattande CONSTRUCTORq BODY samt utvidgningsmetoder i specifikationen måste upprepas i realise- Beträffande kodgenerering kan följande nämnas. ringen. Varje realisering av basobjekttyp och varje realisering av utvidgningsobjekttyp måste följa följande regler: - Varje metodsignatur (the mechodname dompaormalzxrguments [RETURNS dmmyype] part) som anges i specifikationen måste alltid existera även i realiseringen. Detta krav kan uppfyllas pà ett av nedan beskrivna sätt.

Med signatur avses här ett begrepp som identifierar det avsedda elementet, här en metod, genom att ange dess namn, typ av argument samt typ av returvärde.

- Om endast signaturen hos en metod anges i specifikationen kan BODY-metoden the IS BEGIN...END part) antingen utelämnas eller anges i realiseringen. (the dom_BehaviourBody, i . e .

Om.BODY-metoden utelämnas i realiseringen, genereras endast en stomme av metoden i málspráket.

- Ou1BODY-metoden.anges i realiseringen, genereras fullstän- dig kod i màlspráket. »V - Om det finns en BODY-metod redan i specifikationen, kan nyckelorden AS SPECIFICATION användas i realiseringen för att ange att BODY-metoden i realiseringen är exakt densamma som i specifikationen. Fullständig málspràkskod kommer att genereras även i detta fall. Koden komer ej att finnas tillgänglig för manuella ändringar eller tillägg. 517 oss .-. n., 18 - Om både specifikationen och realiseringen definierar en BODY-metod för sama metod, genereras fullständig kod från den i realiseringen angivna BODY-metoden. Detta innebär att det i realiseringen definierade beteendet alltid överrider det i specifikationen angivna beteendet.

Attribut angivna i. specifikationen skall. ej repeteras i realiseringen. På grund av att en nætoddefinition angiven i realiseringen helt överrider motsvarande definition i specifika- tionen, måste även lokala variabler angivna i specifikationen upprepas i realiseringen.

I det följande beskrivs med hänvisning till fig. 11-14 några exempel, som åskådliggör användning av utvidgningsmekanismen.

I fig. 11 visas exempel på en ovillkorad utvidgning.

Exemplet utgår från förutsättningen att specifikationerna av ett basobjekt resp. ett utvidgningsobjekt anges såsom visas i figuren. Vidare anges i en ej visad utvidgningsvy ett tillstånd analyzing, indikerat vid 1102, såsom TOP, och tillstånd calling, indikerade vid 1104 och 1106, såsom COP.

I allmänhet kontrolleras alla exekvering när ett tillstånd deklarerat som TOP. Om det finns en utvidgningsmetod som. utgår från ett aktuellt TOP-tillstånd, utvidgningsobjekt när anropas utvidgningsmetoden. Runtime-systemet kommer att se till att motsvarande utvidgningsobjekt har skapats någon gång före den första invokeringen av utvidgningsobjektets utvidgningsmetod. Om det inte är första gången under exekveringen av basen som utvidgningsmetoden anropas, kan den äldre instansen av utvidg- ningsobjektet användas igen. Detta objekt komer sålunda att återta sitt tillstånd mellan invokeringar av dess utvidgnings- metod under exekveringen av samma bas. Instanser av utvidgnings- objekttyper skapas för varje basobjekt, dvs. ett utvidgnings- objekt delas aldrig av två baser.

I det i fig. indikerat med pil 1108, varje gång exekveringen av basen når tillståndet 1102 analyzing. 11 angivna exemplet sker alltid övergång, till utvidgningsmetoden villkorslöst Det finns olika sätt att avsluta exekveringen av en utvidgningsmetod. För det första kan EXIT användas för att terminera exekveringen av hela exekveringstràden. För det andra 517 035 19 (TO BASE) som indikera áterlämnande av kontroll från en finns det en specifik nfijlighet, benämnd BACK används för att utvidgning till basen där den tog över kontrollen. För det tredje sluttillstånd användas, men använt i en kan ett ordinärt utvidgningsmetod, har det speciell semantik. I detta fall måste det föreligga ett COP-tillstånd i basen, som har samma namn som sluttillståndet hos utvidgningsmetoden. När exekvering når detta sluttillstånd, avbrytas, och exekvering komer att fortsätta i COP-tillståndet komer exekvering i utvidgningsmetoden att i basen.

Skillnaden mellan EXIT till tillståndet i basen varifrån utvidgningen utgick, och BACK ligger i vad som kommer att hända om fler än en utvidgning tar över kontrollen i samma TOP. När BACK används komer nästa utvidgning i tur att exekveras.

Utvidgningarna i den högsta prioritetsklassen exekveras alltid först och om det finns fler än en utvidgning i sama priori- tetsklass, exekveras de normalt i godtycklig ordning. Om det emellertid finns en interferensutvidgningsentitet som har satt en viss exekveringsordning mellan utvidgningarna, exekveras de i denna ordning. mn det sker EXIT till TOP-tillståndet i. basen varifrån exekveringen startade, komer basens TOP-tillstånd att exekveras igen med alla anslutna utvidgningar likaså exekverade igen.

I fig. 12 visas exempel på en villkorad utvidgning.

Villkorade utvidgningar är sådana, som exekveras endast om vissa villkor uppfylls. Detta fall specificeras med hjälp av ett CASE- uttryck som.hör saman med ursprungstillståndet hos utvidgnings- metoden. Exemplet utgår från förutsättningen.att specifikationer- na av ett basobjekt resp. ett utvidgningsobjekt anges såsom visas i figuren. Vidare anges i en ej visad.utvidgningsvy ett tillstånd analyzing, såsom TOP. a och,b är attribut i basobjektet.

När basobjektet når tillståndet analyzing, vid 1202, visar det sig att det finns en utvidgning som utgår från denna TOP- punkt. Utvidgningsmetoden kommer då att påbörja sin exekvering genom ett CASE-uttryck, sonlhör samman med initialtillståndet hos utvidgningsmetoden, indikerat vid 1204. Värdet hos detta uttryck används för att förgrena flödet. o u u ø n» .n 517 933 20 I detta fall rör det sig om en enkel RESULT-referens till värdet av CASE-uttrycket i basen, indikerat vid 1206. Uttrycket (a+b) indikerade grenen, indikerad vid 1208, och exekvering fortsätter i utvidgningen. Annars väljs DEFAULT-grenen, indikerad vid 1210, beräknas. Om dess värde är 3 väljs den av värdet 3 och exekveringskontrollen lämnas tillbaka till basen. Basen.màste då återvärdera CASE-uttrycket och kan därpå fortsätta med den passande grenen.

I det ovan givna exemplet var CASE-uttrycket som hör samman med ursprungstillstàndet hos utvidgningsmetoden mycket enkelt.

Men det skulle kunna utgöras av ett godtyckligt uttryck av skalär typ.

RESULT är ett nyckelord, som används för att en utvidgning skall kunna hänvisa till utfallet av ett CASE-uttryck i ett icke- vänttillstànd i basen. RESULT kan användas i varje uttryck men dess värde kan ej ändras under exekvering av hela utvidgnings- metoden.

DEFAULT gren, föreligger det ett fel. Om utvidgningsmetoden har Om det varken föreligger någon passande gren eller en gren med sama värde som basen överrider utvidgningsmetoden basen.

Om utvidgningen utgår från ett vänttillstànd i basen, måste ursprungstillstàndet hos utvidgningsmetoden likaså vara ett vänttillstànd som specificerar ytterligare händelser som det väntar på. I ett vänttillstànd samlas alla väntade tillstånd för alla utvidgningsmetoder vid denna punkt i ett enkelt WAIT-FOR- EVENT .

Fig. 13 ger exempel på en händelse-utvidgning och utgår från att specifikationerna av ett basobjekt och ett utvidgningsobjekt är som i figuren. Vidare specificeras ett tillstånd Ring;B-som TOP i en ej visad utvidgningsvy.

När basobjektet når tillståndet Ring;B, indikerat vid 1302 finner man att det finns en utvidgning som utgår från denna TOP- punkt. Runtime-systemet måste då samla information från utvidg- ningsobjektet beträffande vilka händelser som skall bevakas, och sätta saman denna information med vänttillständsinformationen i basobjektet. På detta sätt sammansatt vänttillstànd. Beroende på vilka händelser som därpå skapas och introduceras ett n n a nn n... n nu n I I I n nn n n n nn -n n n n n n nn n n n nnnn n n nn nnn nn un nn n n nn nn n v n n nu; n n n . n nn n e' n n _- f: -u :nun :s 21 uppträder, kommer antingen utvidgningen eller basen att ex- ekveras. Om Block_Ev, indikerat vid 1304, specificeras i utvidgningen, exekveras utvidgningsmetoden. Basen exekveras om Off_hook, specificerat i basen och indikerat vid 1306, mottages.

Två utvidgningar kan vänta på samma händelse, även samma händelser som basen. Utvidgningen med den högsta prioriteten kommer då att exekveras.

Utvidgningar till vänttillstànd kan ej exekvera BACK (TO BASE), de màste fortsätta till ett COP-tillstànd i basen eller EXIT. Om exekveringen av en utvidgningsmetod leder tillbaka till inledningstillstándet hos utvidgningsmetoden Start i exekveras utvidgningsmetoden igen, næn (t.ex. ovanstående exempel), denna gång avvaktas endast de i utvidgningsmetoden specificerade händelserna. Om "hela" vänttillstándet skall införas igen, måste vänttillstándet definieras som en TOP COP-punkt i basen, och "fortsätt till" TOP COP-tillståndet måste anges i utvidgnings- metoden.

Det är även möjligt att ha flera utvidgningar till en och samma TOP-punkt i basobjektet. I detta fall måste alla utvidg- ningsobjekt organiseras i en särskild prioriteringsordning och exekvering sker enligt denna prioriteringsordning, dvs. utvidg- ningsobjektet med den högsta prioriteten exekveras först. Om denna utvidgning âterlåmnar sin exekveringskontroll till basen, exekveras utvidgningsobjektet med den näst högsta prioriteten.

Om alla utvidgningar áterlämnar exekveringskontrollen, kommer även basen att exekveras. mn en utvidgningsmetod går till en fortsättningspunkt i basen komer inga fler utvidgningsmetoder att hanteras. Exekve- ringen fortgår helt enkelt i basen. Tillståndet "continued to" kan.naturligtvis ha utvidgningar. Onxdetta är fallet startar allt på nytt. r I fig. 14 ges ett exempel med tre utvidgningsmetoder m2, m3 och. m4,, indikerade 'vid 1402, 1406, och en. bas, indikerad vid 1408, med en utvidgningspunkt R, 1410, som är deklarerad som TOP COP, indikerat vid 1412.

Den första utvidgningen genomför "fortsätt till" TOP COP i 1404 resp. indikerad vid basen, indikerat med pil 1414. De två andra utvidgningsflödena u o o ø uu 517 oss ~ 22 tar över från TOP COP-tillståndet 1410, indikerat vid 1416 resp. 1418. Utvidgningsmetoden m3 återför exekveringskontrollen till basen genom att använda BACK. Om m3 har högre prioritet än m4, exekveras m3 först, följt av m4, under förutsättning att m3 áterlämnar exekveringskontrollen, indikerat vid 1420. Om m4 har högre prioritet än m3, exekveras endast m4. I detta fall har m3 aldrig någon möjlighet att exekveras på grund av att m4 aldrig återgår till basen.

Det kan även finnas objekttyper som implementerar inter- aktionshanterande utvidgningsfunktioner, vilka hanterar inter- aktion mellan tilläggsfunktioner. Användning av interaktions- tilläggsfunktioner'beskrivs t.ex. i de tidigare svenska patentan- sökningarna 93 02024-6 och 94 00209-4. De åtgärder som beskrivs i den senare ansökningen med hänvisning till de däri ingående figuerna 15a/15b såsom utförda av en basfunktion, skulle således kunna utföras med hjälp av ett interaktionshanterande utvidg- ningsobjekt. Därvid kan t.ex. det ovan med hänvisning till fig. 14 beskrivna konceptet avseende anslutning av flera utvidgningar till en och sama TOP-punkt i. ett basobjekt komma till an- vändning. Ett interaktionshanterande utvidgningsobjekt skulle sålunda kunna anslutas till samma TOP-punkt i ett basobjekt, som två utvidgningsobjekt, vilka representerar varsin av två interagerande tilläggsfunktioner. För ytterligare information avseende lösning av interaktionsproblem hänvisas till de nämnda svenska patentansökningarna.

Claims (22)

517 033 - " 23

1. Objektorienterad systemplattform för ett telekommunikationssystem, som tillhandahåller abonnenttjänster, vilken plattform innehåller ett antal funktionsskikt, ett skikt (102) med operativsystemfunktioner, en därpå belägen applikationsplattform (104) innehållande telekommunikations- abstraktioner i form av resursobjekt, samt därpå ett översta skikt (106) innehållande önskade applikationer i form av bas- och tilläggsfunktioner, som tillhandahåller bas- och tilläggstjänster, kånnetecknad av att det översta skiktet är implementerat med basobjekt (202) och utvidgningsobjekt (204, 206, 208), där basobjekten är objekttyper, som implementerar basfunktioner, som kan behöva utvidgas i framtiden, varvid varje basobjekttyp är konstruerad för en särskild uppgift, som kan utföras med minimal koordinering med andra basobjekt, utvidgningsobjekten är objekttyper som implementerar utvidgningsfunktioner, vilka utgör utvidgningar till basfunktio- nerna, och gör det möjligt att lägga till nya tjänster och modifiera och utvidga befintliga tjänster utan att ändra mjukvaran hos ett system som redan har implementerats och levererats, samt att beteendet hos bas- och utvidgningsobjekttyperna är definierat genom att beteendet hos varje ingående metod beskrivs som en ändlig tillståndsmaskin, som består av ett ändligt antal tillstånd och övergångar mellan dessa tillstånd, där koden exekveras som övergångsaktioner, varvid utvidgningarna tillförs vid tillstånden för att ta över exekveringskontrollen i en utvidgningspunkt och returnera kontrollen till en annan, eller sama utvidgningspunkt i samma metod.

2. Systemplattform enligt krav 1, kännetecknad av att bas- och utvidgningsobjekttyperna stödjer ett utvidgnings- koncept, som tillåter att systemets beteende modifieras och utvidgas, utan att det är nödvändigt att ändra systemets existerande implementering, genom laddning av endast definitioner av utvidgningarna i systemet, som indirekt modifierar systemets beteende genom att ta över exekveringskon- 517 053, 24 trollen i vissa förutbestämda utvidgningspunkter.

3. Systemplattform enligt krav 1 eller 2, kânnetecknad av att en specifikation för ett utvidgningsobjekt definierar vid vilka utvidgningspunkter i utvidgningsobjektet som utvidgningen antas ta över kontrollen och vid vilka utvidgningspunkter den kan àterlämna kontrollen.

4. Systemplattform enligt krav 3, kânnetecknad av att när ett utvidgningsobjekt tar över kontrollen startar en förutde- finierad utvidgningsmetod exekveringen.

5. Systemplattform enligt krav 3 eller 4, kânnetecknad av att ett runtime-system tar hand om skapande av utvidgningsobjekt och invokering av deras utvidgningsmetoder vid de angivna utvidgningspunkterna.

6. Systemplattform enligt nágot av krav 1-5, kânnetecknad av att ett utvidgningsobjekt har access till attribut och metoder hos det basobjekt eller det utvidgningsobjekt, som utvidgningen tar över kontrollen fràn.

7. Systemplattform enligt krav 6, kânnetecknad av att nämnda attribut och metoder endast innefattar sàdana, som är deklarerade i en objekttypspecifikation, som kan accessas.

8. Systemplattform enligt något av krav 4-7, kânnetecknad av att i objekttypspecifikationen definieras även accessrestrik- tioner för varje utvidgningspunkt, genom att definiera att endast en viss deluppsâttning av attributen och metoderna i specifikationen är tillgängliga för utvidgningar som tar över kontrollen i en viss utvidgningspunkt,

9. Systemplattform enligt nàgot av krav 2-8, kânnetecknad av att objekttypspecifikationen för ett utvidgningsbart objekt fungerar som ett gränssnitt som begränsar mängden information som är synlig och tillgänglig för utvidgningar av det utvidgningsbara objektet.

10. Systemplattform enligt krav 9, kânnetecknad av ett gränssnittsskikt, som används tillsamans med utvidgningskon- ceptet och definieras av utvidgningsvyer, som var och en definierar en deluppsâttning av information i specifikationen av ett utvidgningsbart objekt, som skall kunna accessas av de utvidgningar som använder vyn. 517 053 i 25

11. Systemplattform enligt nágot av krav 1-10, kännetecknad av att för ett basobjekt finns det en specifikation, som dels verkar som en gränssnittsbeskrivning, som visar tillstànd, attribut och metoder, som är tillgängliga för utvidgningarna, och dels definierar ett gränssnitt mot klientobjekt som behöver skapa instanser av basobjektet, vilket gränssnitt definieras av metoder hos basobjekttypen, som avgör vilka parametrar som kan användas vid skapande av den nya instansen.

12. Systemplattform enligt krav 11, kännetecknad av att specifikationen ger en högnivábeskrivning av basobjekttypens beteende med utelämnande av implementationsdetaljer som är onödiga för uppnàende av förståelse av objekttypens funktion.

13. Systemplattform enligt krav 12, kännetecknad av att till den höga abstraktionsnivàn bidrar ett abstraktionsskikt som skapas av en underliggande objektlogik, som används av basobjek- tet, samt lokala metoder i basobjektet som omfattar användning av objektlogiken.

14. Systemplattform enligt krav 13, kännetecknad av att en rimlig abstraktionsnivá i en specifikation àstadkomes genom att visa basobjektets vänttillstànd i specifikationen och eventuellt vissa utvalda icke-vänttillstànd, som är fundamentala för förståelse av basobjektets funktion, varvid kod för att exekvera mellan de visade tillstánden införs i lokala metoder som deklareras, men ej nödvändigtvis beteendespecificeras, i specifikationen.

15. Systemplattform enligt krav 14, kännetecknad av att bedömning av vad som skall visas i specifikationen innefattar hänsynstagande till vilka delar av objekttypen som kan koma att underkastas utvidgningar i framtiden.

16. Systemplattform enligt krav 15, kännetecknad av att alla tillstànd, bade vänttillstánd och icke-vänttillstànd, och alla explicit namngivna utvidgningspunkter, visas i metodspecifikationen, varvid aktionskod används vid tillstånds- övergàngar i lokala metoder.

17. Systemplattform enligt krav 15, kännetecknad av att om vissa delar av beteendet ej behöver vara utvidgningsbara, 517 oss - 26 införs dessa i sin helhet i lokala metoder, som definieras i specifikationen eller realiseringen, eller pà implementa- tionsniván.

18. Systemplattform enligt krav 17, kännetecknad av att objekttyprealisering används för delar av basobjekt som inte behöver, eller kan vara utvidgningsbara, och som ej är nödvändiga att visa i specifikationen för att skapa en hög- nivábeskrivning, men där en definition föredras i stället för användning av implementationssprák direkt.

19. Systemplattform enligt krav 18, kännetecknad av att i realiseringen ingar definitioner av lokala metoder som inför aktionskod.

20. Systemplattform enligt krav 18 eller 19, kännetecknad av att i realiseringen ges, med överhoppande av i specifika- tionen ingående beteendedefinitioner, en mera detaljerad beteendedefinition, som innebär en förfining av beteendespeci- fikationen, som ges i specifikationen.

21. Systemplattform enligt något av krav 1-20, kännetecknad av att utvidgningsobjekten även innefattar objekttyper som implementerar utvidgningsfunktioner (208), vilka utgör utvidgningar till utvidgningsfunktionerna.

22. Systemplattform enligt något av krav 1-21, kännetecknad av att utvidgningsobjekten även innefattar objekttyper som implementerar interaktionshanterande utvidgningsfunktioner, vilka hanterar interaktion mellan tilläggstjänster.