NO311117B1 - Programvarestruktur for telekommunikasjonssvitsjesystemer - Google Patents

Description

Oppfinnelsens bakgrunn

En del av denne beskrivelse av denne patentsøknad inneholder materiale som er underlagt copyright-beskyttelse. Eieren av denne copyright motsetter seg ikke at noen faksimilereprodu-serer patentsøknaden eller patentfremstillingen, slik denne fremgår hos patentmyndighetene, patentarkivet eller regist-rene, men reserverer seg forøvrig tilhørende copyright-rettigheter.

Oppfinnelsen område

Den foreliggende oppfinnelse vedrører telekommunikasjonssvitsjesystemer og mer spesielt utviklingen og strukturen av prosesstyreprogramvare for telekommunikasjonssvitsjesystemer.

Beskrivelse av relatert teknikk

Utviklingen av programvarearkitekturoppbygninger og anven-delsesprogrammer for telekommunikasjonssvitsjesystemer som styres av lagret program, har historisk sett utgjort en komplisert og tidkrevende oppgave. Prosessen krever mange trinn som strekker seg fra utviklingen av de funksjonelle spesifikasjoner som definerer operasjonen og innbyrdes sam-virkning mellom de tjenester som skal utøves, til testingen av den aktuelle kode i sanntid i maskinvaren, i hvilken systemet skal kjøres. Utviklingen av slike programvarearkitekturer har også krevd den innbyrdes påvirkning av et antall forskjellige utviklere som arbeider under forskjellige synsvinkler hva angår utviklingen og krever koordinering av et antall aktiviteter ved hvert trinn langs den vei som utviklingen skrider frem. Således vil det å markedsføre nye programvaresystemer som skal implementere funksjoner og trekk som er pådrevet av brukerkrav, vært meget dyrt og en slik arbeidskrevende og tidskrevende prosess at på det tids-punkt systemene har blitt konstruert, utviklet, testet og implementert kommersielt i markedet, har brukerkravene ofte

endret seg til enda nyere forespørsler.

En av hovedbetraktningene i forbindelse med utviklingen av et hvilket som helst programvaresystem, går ut på selektering av den programmeringsmetode som skal benyttes ved konstruksjonen av systemet. Velkjente tidligere programme-ringsteknikker innen denne art omfatter: prosessorientert programmering med språk av typen "ADA" eller "PASCAL", objektorientert programmering med språk av typen "C++" eller "SMALLTALK", samt deklarativ programmering med språk av typen "PROLOG" eller "LISP". Ingen av disse språk inneholder det fulle sett av trekk som er ønskelig for utvikling av te-lekommunikasjonssvitsjeprogramvare. F.eks. skaffer det pro-sessorienterte programmeringsspråkkonsept en god forståelse og en god definisjon av det subjekt som skal programmeres, men det gir meget begrenset understøttelse for strukturering og definering av handlinger eller predikeringer innenfor prosessen. Under programmering av handlingene i en prosess, er konstruktøren pålagt å tilføre et stort antall individuelle detaljer til applikasjonsprogramvaren. På lignende måte, mens Pascal/ADA-genereringen av programmeringsspråk gir noe understøttelse for definisjon og håndtering av data, er programmereren fremdeles pålagt å gjøre en god del arbeid på et detaljert nivå, hvilket har lite å gjøre med den aktuelle applikasjon som blir produsert.

Selv de siste objektorienterte programmeringsmetoder omfatter begrensninger. Slike objektorienterte metoder for programmering har konsentrert seg om forskjellige teknikker for å definere og få innebygget i seg objekter, samt om hvordan objektene skal dokumenteres. Selv om disse teknikker innebærer et betydelig bidrag i tilfellet av utvikling av programmer som inneholder et stort antall objekter som skal defineres og håndteres, vil mange problemer relatert til klarhet og struktur opptre når et program selv defineres som et objekt .

I forbindelse med prosesstyreprogrammer, f.eks. slike som vedrører telekommunikasjonssystemer, vil imidlertid program-enheten alltid være det subjekt som utfører handlinger og dirigerer aktivitetene i systemet. Objektene i et telekommu-nikasjonsprosessprogramsystem omfatter hovedsakelig to typer: 1) alle slike programsystemer har interne objekter definert ved datatermer som programmet opererer på. Disse objekter representerer programvaresystemets realitet og dataene utgjør det statiske bilde av den reelle verden som programmene manipulerer 2) alle samtidssysterner og prosesstyresystemer opererer imidlertid også på dynamiske objekter utenfor program-systemene. Eksempler på slike dynamiske objekter er bilder på en fremviserskjerm eller telefoner og fjernlinjer i et telekommunikasjonssystem. Disse programsystemer vil også omfatte de dynamiske objekter slik de representeres ved data-obj ektene.

Den objektorienterte programmeringsteknikk vedrørende inn-kapslende handlinger sammen med data samt definering av alt sammen som et objekt, innebærer en utpreget fordel dersom programmet er en rutine som har tett tilknytning til sine objekter. Eksempler på slike rutiner finnes i presentasjons-systemer for fremviserskjermer, samt i linjegrensesnittdele-ne av et telekommunikasjonssystem. Imidlertid, dersom styreprogrammene i et slikt prosesstyreprogramvaresystem alle blir definert som objekter, blir det også fremskaffet visse negative virkninger. For det første blir styreprogrammene fragmentert, og det blir nødvendig med meget komplekse inte-raksjoner og relasjoner mellom objektene. Et slikt resultat krever en overliggende styrestruktur, og i forbindelse med kjente objektbaserte telekommunikasjonssystemer har det vært nødvendig med komplekse C.C.I.T.T. spesifikasjonsdesignspråk ("Specification Design Language" SDL) flytdiagram for å be-skrive slike styrestrukturer. Dessuten er de dynamiske relasjoner mellom objektene fremdeles meget vanskelige å beskri-ve og å forstå selv ved bruken av slike flytdiagrammer. For det annet, når ingen enheter i styreprogramvaresystemet blir definert som et subjekt, vil enhver forklarende modell i seg selv bli defekt. Programhandlingene, hvilket innebærer de tilhørende predikater, blir buntet sammen med objektene, hvilket innebærer at både objektene og handlingene blir meget vanskelige å lokalisere. Dette gjør det nesten umulig å organisere handlingene i prosesstyresystemene i logiske grupper. Videre vil konstruktørene ikke være i stand til å strukturere applikasjoner på en naturlig måte som ville være høyst forståelig for enhver som beskuet organisasjonen, samt lett for konstruktører å arbeide med.

Den siste generasjon av deklarative programmeringsspråk, f.eks. PROLOG og LISP er meget effektive og reduserer arbei-det for programvarekonstruksjon og programmering fordi: (a) all programmering kan foretas i symbolsk form, og (b) kon-septet vedrørende predikater og et helt nytt sett av kraft-fulle instruksjoner er inkludert i disse språk. Bruken av disse språk reduserer dramatisk både antallet detaljer som en programmerer trenger å konsentrere seg om, samt betyd-ningen av programinnkapsling. Den virkelige ulempe ved bruken av deklarative språk i prosesstyring og sanntidssyste-mer, f.eks. som telekommunikasjonssvitsjesystemer som styres av lagrede programmer, er deres utilstrekkelige sanntids-ytelser og deres manglende evne til å håndtere parallellkjø-ring.

Mange av de nyere deklarative eller objektorienterte programmeringsspråk er blitt benyttet for å tillate programme-rere å utføre raske prototyper vedrørende funksjoner eller programmer. Raske prototypeteknikker innebærer en flerhet av anerkjente fordeler som strekker seg fra muligheten for inkremental konstruksjon og utvikling av applikasjon eller et system. Potensielt kostbare konstruksjonsfeil kan detekteres og korrigeres tidligere i utviklingsprosessen, individuelle aspekter ved et system kan implementeres og testes meget raskt, langvarige tester og/eller implementeringsfaser kan unngås, samt raske prototypeutviklinger tillater konstruktø-rene å utforske et antall valgmuligheter hva angår en applikasjon eller funksjon. Mange andre fordeler hva angår proto-typefremskaffelse finnes også.

Raske prototypeteknikker innebærer fordeler også hva angår

telekommunikasjonssystemer. Inntil nå har imidlertid teknik-kene hatt en flerhet av ulemper på grunn av sanntidsegenska-pen hos de prosessaktiviteter som finner sted i telekommunikasjonssystemene og den parallelle egenskap hos disse operasjoner. Systemet ifølge den foreliggende oppfinnelse innbefatter visse aspekter som utvider tidligere kjente prototy-pemetoder og egenskaper, slik at rask prototypetesting ef-fektivt kan benyttes i forbindelse med telekommunikasjonssystemer. Eksperimenter innenfor bruken av prototypeteknikker i forbindelse med telekommunikasjonssystemer er omtalt i "Using Prolog for Rapid Prototyping of Telecommunication Systems", J.L. Armstrong og M.C. Williams, Seventh International Conference on Software Engineering for Telecommunication Switching Systems, 3-6. juli 1989, Bournemouth, samt i "Experiments with Programming Languages and Techniques for

Telecommunications Applications", B. Dacker, N. Elshiewg, P. Hedeland, C-W. Welin, M. Williams, Sixth International Conference on Software Engineering for Telecommunication Switching Systems, 14-18. april 1986, Eindhoven.

Utviklingene av det deklarative språk ERLANG har i det ve-sentlige løst disse to problemer og tillater introduksjonen av prosesstyrekonsept i den verden som knytter seg til deklarative språk. Basiskonseptene vedrørende nevnte ERLANG språk er omtalt i artikkelen "ERLANG: An Experimental Te-lephony Programming Language", Proceedings, XIII International Switching Symposium, vol. III, side 48 (1990). En mer detaljert behandling finnes i "Erlang User<1>s Guide & Refe-rence Manual" samt i "Erlang BIF Guide". Bruken av et slikt språk muliggjør konstruksjonen av programvarebaserte prosesstyresystemer i sanntid i henhold til systemet ifølge den foreliggende oppfinnelse.

foreliggende oppfinnelse.

Sammenfatning av oppfinnelsen

Systemet omfatter ifølge den foreliggende oppfinnelse en oppbygning av deklarativt språk til bruk ved programmerte prosesstyresystemer, f.eks. telekommunikasjonssvitsjesystemer. Språkoppbygningen omfatter naturlige språkelementer omfattende et subjekt, representert ved prosessen for handlinger, et predikat, representert ved predikatene for det deklarative språk definert som programprosedyrer, samt et objekt, representert ved data og enheter fra den reelle verden definert i symbolsk form og innlemmet i objektprosesse-ne.

Systemet ifølge den foreliggende oppfinnelse kan omfatte en fremgangsmåte for konstruksjon av prototypeprogramvare for telekommunikasjonssvitsjesystemer omfattende prosedyrene for forberedelse av funksjonelle spesifikasjoner og deretter av-bilding av disse funksjonelle spesifikasjoner direkte på brukeren og de nettverksfunksjonene enheter under bruk av den deklarative språkoppbygning ifølge den foreliggende oppfinnelse .

Slik det raskt vil oppfattes av en gjennomsnittsfagmann innenfor dette tekniske område, kan prinsippene og aspektene ved den foreliggende oppfinnelse fordelaktig benyttes i forbindelse med andre programvaresysterner og i forbindelse med en flerhet av andre datamaskin- og prosess-styreapplikasjoner i tillegg til telekommunikasjonssvitsjesystemer.

Kort omtale av tegningsfigurene

For å kunne forstå den foreliggende oppfinnelse samt ytterligere hensikter og fordeler med denne, skal det vises til den følgende beskrivelse tatt i forbindelse med de vedføyde tegningsfigurer.

Figur 1 er et blokkdiagram som illustrerer anvendelsen av systemet ifølge den foreliggende oppfinnelse like overfor utviklingen av prototype-programvare for styring av telekom-munikasj onssvitsj emaskiner. Figur 2 er et blokkdiagram over de trinn som benyttes ved utviklingen av prototype-programvare. Figur 3 er et flytdiagram som anskueliggjør programvareutvikling i henhold til systemet ifølge den foreliggende oppfinnelse . Figur 4 er et flytdiagram som anskueliggjør trinnene vedrø-rende spesifisering av tjenesteaspektene ved telekommunikasjons programvareutviklingen i henhold til oppfinnelsen. Figur 5 er et flytdiagram som viser spesifikasjonen av de funksjonelle nettverksaspekter ved utviklingen av telekommu-nikasjonsprogramvare i henhold til oppfinnelsen. Figur 6 er et blokkdiagram som viser avbildningen av funksjonelle enheter fra en funksjonell spesifikasjon til pro-gramvaresystemstrukturen i henhold til oppfinnelsen. Figur 7 er et blokkdiagram som viser avbildningen av funksjonelle enheter i tilfelle av et nettverk fra spesifikasjonen til programvaresysternet i henhold til den foreliggende oppfinnelse. Figur 8 er et blokkdiagram som viser den totale arkitektur av programvare for et telekommunikasjonssvitsjesystem konstruert i henhold til den foreliggende oppfinnelse. Figur 9 er et blokkdiagram som viser telekommunikasjonspro-gramvaresystemarkitekturen ifølge den foreliggende oppfinnelse . Figur 10 er et blokkdiagram som viser måten trafikkdelen i en brukermodul bygges opp hierarkiisk ifølge den foreliggende oppfinnelse. Figur 11 er et blokkdiagram som alternativt viser en data-håndteringsoperasjon innenfor arkitekturen av programvaresystemet ifølge den foreliggende oppfinnelse. Figur 12 er et blokkdiagram som viser oppkallingssidesepara-sjonsaspektet ifølge den foreliggende oppfinnelse. Figur 13 er et diagram som viser interaksjonen ved oppkal-lingssidene ifølge den foreliggende oppfinnelse. Figurene 14 - 16 er diagrammer som viser forskjellige aspekter ved implementeringen av funksjonelle trekk innenfor det foreliggende system. Figur 17 er et blokkdiagram som viser en fullstendig utvik-lingsomgivelse innenfor hvilket det foreliggende system for prototyping kan funksjonere. Figur 18 er et blokkdiagram som viser visse forskjeller mellom systemet ifølge den foreliggende oppfinnelse og visse andre kjente systemer.

Detaljert beskrivelse

Systemet ifølge den foreliggende oppfinnelse omfatter mange forskjellige relaterte aspekter omfattende en programme-rings språkstruktur som spesielt er tilpasset for bruk i programvaren for sanntidsprosessystemer, f.eks. telekommunikasjonssystemer, en metodologi som benyttes for forberedelse av prototypeprogramvare som benyttes i telekommunikasjons-svitsjer, samt en programmeringsarkitektur og programkonst-ruksjonsverktøy for telekommunikasjonssvitsjesystemer. Hvert av disse forskjellige aspekter ifølge den foreliggende oppfinnelse og deres innbyrdes relasjon vil i det følgende bli diskutert både hva angår deres teoretiske og teknologiske bakgrunn samt deres bruk i et praktisk, operativt programvaresystem.

Procrramvarekonstruksionsmetodikk

Som beskrevet tidligere omfatter hver av de velkjente programmeringsmetoder vedrørende prosessorientert programmering, objektorientert programmering samt programmering med deklarativt språk, visse iboende ulemper når de benyttes i forbindelse med sanntidsprosesstyreomgivelser, f.eks. slike som finnes i telekommunikasjonssvitsjesystemer. Programme-ringskonstruksjonsmetodene for slike sanntidsprosesser som benyttes i systemet ifølge den foreliggende oppfinnelse, omfatter muligheter til å håndtere sanntidsbehandling og ut-øvelse samt parallelloperasjoner, ved utnyttelse av et robust deklarativt språk med en ny språkkonstruksjonsteknikk for fremskaffelse av klare og lett forståelige applikasjons-orienterte programvarearkitekturer.

Språkkonstruksjonsteknikken ifølge systemet i henhold til

den foreliggende oppfinnelse er karakterisert ved bruken av de tre naturlige språkelementer omfattende subjekt, predikat og objekt. Subjektet er representert ved prosessen vedrøren-de handlinger, mens predikatet er representert ved predikatene av det deklarative språk definert som programprosedyrer. Objektet er representert ved data og fysiske enheter, f.eks. telekommunikasjonsfjernlinjer og telefoner, av hvilket alt er definert i symbolsk form og innlemmet i en objektprosess. Den foreliggende teknikk gjør det mulig ikke bare for en programvarekonstruktør å konsentrere seg om å

definere de forskjellige enheter i den applikasjonsstruktur som blir konstruert, men oppmuntrer sterk til dette. Bruken av de tre basiselementer av det menneskelige språk tillater at det skapes en modell som ikke bare er kraftfull, men også klar og lett å forstå. Dessuten kan den foreliggende språk-konstruks jon også betraktes som et paradigma av aktive subjekter ("PACS").

Ved det foreliggende system blir et subjekt definert som en sekvens eller et antall sekvenser av predikater og blir karakterisert ved de handlinger som den er i stand til å utfø-re. Dette skaffer en kraftfull mekanisme for strukturering av alle funksjoner i grupper for å danne naturlige og lett forståelige enheter innenfor programvaren. Bruken av prosesskonseptet løser et stort antall sanntidsproblemer og dessuten understøtter det innføringen av språkelementet relatert til "subjekt" ved konstruksjonen av datamaskinpro-grammeringsspråk. Ved det foreliggende system blir en sub-jektprosess betegnet og spesifisert med hensyn til sitt innhold av handling på en måte i likhet med den måte som individer, f.eks. murere, mekanikere eller snekkere, blir betegnet og definert i den virkelige verden. Dette muliggjør den naturlige spesifikasjon av relasjoner mellom handlinger. F.eks., i et PBX programvaresystem, er dette aspekt kjent som tjenesteinteraksjon, som ved benyttelsen av den foreliggende metodikk blir en naturlig del av den foreliggende spesifikasjon. En grundig kjennskap til den reelle applikasjon er imidlertid nødvendig for å definere de egentlige subjekter for en applikasjon eller tjeneste. Det foreliggende konsept understøtter også anstrengelsen vedrørende bevegelse av fokuseringen av programvareutviklingen fra lavnivåimplemen-teringsdetaljer mot totale applikasjoner og løsninger på brukerdefinerte problemer.

Subjekter kan defineres ifølge den foreliggende oppfinnelse ved et hvilket som helst unntatt det laveste nivå av abstraksjon innenfor konstruktørens konseptualisering av det system eller den applikasjon som utvikles. Veci det høyeste nivå av abstraksjon foreligger det et subjekt /som definerer og stykker opp hele funksjonaliteten av systemet. Subjektet på høyeste nivå som fremskaffer den totale styresekvens og flyt for systemet, kan sammenlignes med et hovedprogram eller en rutine som benyttes i forbindelse med tradisjonelle programmeringsspråk. Ved dette aspekt ved systemet ifølge oppfinnelsen omfatter subjekter en sekvens av subjekt, predikat og objektprosesser, eller en sekvens av bare predikat og objektprosesser for definisjon av et fullt sett av aktiviteter som.danner en del av nevnte subjekt.

Eksempler på funksjoner eller aktiviteter som kan defineres som subjekter innenfor det foreliggende system, omfatter,

men er ikke begrenset til: (a) aktivisering av et telekommunikasjonssvitsjesystem, og (b) forespørsel ved et telekommunikasjonssystem hva angår hvilke tjenester som er tilgjengelige i systemet. Det skal forstås at et subjekt som er definert som en sekvens eller et antall sekvenser av predikater, kan fortolkes som aktiviteter, eller styrestrømmer, innenfor brukerdelen av den trekkmodul som håndterer et spesielt aspekt av et trekk, slik dette vil bli beskrevet i det følgen-de under det avsnitt som er relatert til "forbedret prototypeteknologi" og "programvarearkitektur og teknologi" aspektene ved den foreliggende oppfinnelse. Det som følger umid-delbart er et eksempelsett på "pseudo-kode" som kan brukes i systemet ifølge den foreliggende oppfinnelse for å definere et subjekt.

Predikatene som brukes av subjektene, blir definert i systemet ifølge den foreliggende oppfinnelse enten ved basisin-struksjoner eller ved hjelp av formasjonen av nye predikater ved definisjon av programrutiner betegnet som prosedyrer. Hver prosedyre kan være spesialisert og unik for et spesielt subjekt, eller den kan være generalisert og bli brukt av mange forskjellige subjekter. Hver prosedyre er også kjennetegnet ved sin handling. Bruken av prosedyrer i en lagorientert arkitektur slik det predikeres i det deklarative språk introduserer en i virkeligheten ubegrenset mulighet for he-ving av abstraksjonsnivået og økning av kraften i toppnivå-språket. En basisregel som bør benyttes ved konstruksjon av denne type av system, bør innebære at antallet prosedyrer holdes lavt nok til at systemet blir lett å forstå og vedli-keholde . Et predikat bør betraktes som en diskret prosedyre i forbindelse med f.eks. tallanalyse. Selv om predikatet kunne utføre en komplett oppgave, så må det alltid være meget klart. På det laveste nivå kan et predikat omfatte ing-enting annet enn en eneste deklarerende språksetning. Det skal også forstås at predikatene som brukes i forbindelse med språkkonstruksjonsaspektet ifølge oppfinnelsen, blir representert som predikater i et deklarerende språk og definert som programprosedyrer i applikasjonsoperativsystemet ("Application Operating System" AOS), slik dette vil bli beskrevet i det følgende under kapittelet relatert til "programvarearkitektur og teknologi"-aspektet for oppfinnelsen.

Den foreliggende metode kan sammenlignes med den kjente C++ måte å fremskaffe det iboende av hele eller deler av et program. I dette tilfelle vil imidlertid både de reelle objekter og predikatene bli betegnet objekter, og handlingene eller predikatene blir alltid tett sammenbundet med de reelle objekter. Dette blir gjort i C++ for å fremskaffe innkapsling. Imidlertid vil behovet for innkapsling ikke være på langt nær så viktig når det benyttes deklarative språk som når det benyttes objektorienterte språk. Den svake sammenkobling mellom handlinger i forhold til objekter, som i C++ innebærer markert kontraproduktivitet hva angår fremskaffelsen av en funksjonell struktur som er lett å forstå. På den annen side vil den foreliggende metode gjøre det mulig å fremskaffe bare predikater eller handlinger som understøtter skapelsen av en klar funksjonell struktur. Slike funksjonelle strukturer vil da være lette å forstå og dette er alltid av stor betydning i forbindelse med konstruksjonen av pro-sesstyreprogramvaresystemer.

Et objekt i henhold til det foreliggende system blir definert som en prosess inneholdende data og/eller enheter relatert til den reelle verden i symbolsk form buntet sammen med tett relaterte handlinger. Dette gjør det mulig å inkludere i objektprosessen en hvilken som helst handling som er tett knyttet til objektet og ikke har vital betydning hva angår logikkstrukturen hos predikater. Slike rutiner innbefatter f.eks. rutiner for skanning av status for ytre objekter, be-regning av rutiner som alltid utføres for et visst objekt, samt rutiner for fremvisning av noe på en skjerm. Således vil hovedfordelen hva angår objektorienterte metoder, f.eks. C++, bli benyttet i henhold til det foreliggende system. Det vil imidlertid være av stor viktighet at subjekter og objekter ikke blir innbyrdes blandet med hverandre, fordi de beg-ge blir implementert som prosesser. Prosessen blir definert som en implementeringsteknologi, og subjekter, predikater og objekter utgjør alle prosessenheter i applikasjonsarkitektu-ren. Dersom en rutine ikke er tett koblet til dataobjektet, så bør den separeres ut som en predikert prosess. Metoder som benyttes til å overta og å innlemme andre objekter, kan introduseres etter behov, slik dette er kjent innen denne form for teknologi. I denne sammenheng bør et predikat, dersom det er stort eller komplekst, i stedet struktureres som et subjekt.

Det skal også forstås at det aspekt som er representert ved data og enheter knyttet til den reelle verden ved språk-konstruks jonsaspektet ifølge den foreliggende oppfinnelse, kan fortolkes som aksessdelen slik det vil bli beskrevet i det følgende i forbindelse med det avsnitt som vedrører "programvarearkitektur og teknologi"-aspektet ved oppfinnelsen. I den forbindelse utfører brukerdelen et predikat, eller en prosedyre, hvilket er en ordre til aksessdelen om å utføre en spesiell oppgave. Denne ordre er ikke avhengig av hvorvidt den aktuelle enhet som tilhører den reelle verden, er konstruert. Det innebærer at ordren kan gå ut på å infor-mere aksessen om aktuelle betingelser vedrørende samtalen, f.eks. en innkommende samtale, nummeret på den oppkallende del, f.eks. 12345, samt kategorien av den innkommende del, f.eks. en operatør. Dersom aksessen er en analog bilinje, så vil den sannsynligvis være i stand til bare å generere et ringesignal innenfor nevnte aksessaspekt. Imidlertid, dersom aksessaspektet er en spesiell eller moderne telefon og omfatter en fremviser, så vil nummer 12345 kunne vises på fremviseren sammen med en eventuell indikasjon av operatør-kategori.

Programvarestrukturmetodikken ifølge den foreliggende oppfinnelse understøtter i sterk grad hos programvarekonstruk-tørenes og programmerernes bevegelse bort fra implementeringsdetaljer og mot økt kjennskap til og fokus på selve applikasjonen. Den muliggjør fremskaffelsen av klar og lett forståelig applikasjonsorientert programvarearkitekturer, selv når applikasjonene innbefatter meget kompliserte prosesser og logikker. Teknikken ifølge den foreliggende oppfinnelse gjør at programvaren lett kan vedlikeholdes og for-bedres ved tilføyelse av funksjoner, slik dette vil bli ytterligere eksemplifisert i det følgende i forbindelse med beskrivelsen av andre sider eller aspekter ved den foreliggende oppfinnelse.

Forbedret prototypeteknologi for utvikling av programvare til bruk i telekommunikasjonssvitsiessystemer

Systemet ifølge den foreliggende oppfinnelse kan brukes for utvikling og evaluering av tilstanden knyttet til området programvarearkitekturer eller telekommunikasjonssvitsjesystemer, og spesielt for fremskaffelse av en nyttig prototype-basis for utvikling av nye applikasjoner eller utvidelser av slik programvare. Programmeringsparadigmaet som brukes ved det foreliggende system, tilhører det for deklarativ programmering, slik dette vil bli omtalt i det følgende, og det operativsystem som benyttes, spesielt tilpasset for under-støttelse av telekonununikasjonsapplikasjoner. F.eks. er ope-rativsystemet blitt utvidet til å innbefatte feilgjenvinning per anrop.

Utviklingen av telekonununikasjonssvitsjeprogramvare blir stadig mer markedsdirigert. Med økende hyppighet blir appli-kasjonseksperter involvert i programvarearkitekturkonstruk-sjoner for å forenkle håndteringen av salgsnyheter gjennom hele utviklingskjeden. Dette innebærer at nyheter eller trekk ved produktspesifikasjonene blir avbildet på aktuelle trekkmoduler i programvarearkitekturen. Dette vil i virkeligheten innebære innføring av en markedsregulert tilnærmel-se inn i programvareutviklingen.

Prototypekommunikasjonssvitsjesystemarkitektur og svitsje-systemprogramvare innbefatter løsningen av meget komplekse problemer og nødvendiggjør verifikasjonen av resultatene av praktiske eksperimenter på et meget tidlig stadium. Prototy-pefasen er delt inn i sykler, idet hver av disse definerer objektiver hvori en syklus inneholder et begrenset antall trekk som blir fullt implementer og hver suksessiv syklus introduserer nye trekk. Slike prototyper representerer rea-listiske systemer selv om de er begrenset hva angår sin funksjonalitet. Prototyper kan ha sanntidskarakteristikker og programvarekvaliteter som kan sammenlignes med reelle produkter. De danner en stabil basis for byggingen av ytterligere prototyper, samt for implementeringen av operativ programvare.

Prototypeprosessen er en meget viktig fase ved forberedelsen av en total arbeidsmodell og tillater konstruktøren å gjøre brukeren til primærmidtpunktet. På figur 1 er det vist et blokkdiagram som anskueliggjør den prosess hvori brukbarhe-ten 21 av det foreslåtte system blir evaluert ut i fra stu-dium av brukerne og deres krav 22, fulgt av en brukergrense-snittssimulering/test 23 som tilveiebringer starten til ar-beidspremissene for prototypen. Deretter blir selve prototypeprosessen 24 implementert. Denne prosess gjør bruk av den nye programvareteknologi 25 for prototypeoppbygning av nye applikasjoner 26 for å kunne oppnå omhyggelig bearbeidede kravspesifikasjoner for produktutvikling 28, samt for å produsere kvalifiserte innganger til standardiserte organisa-sjoner. En ytterligere fordel som oppnås, går ut på at med forholdsvis liten innsats kan disse prototyper utvikles til et endelig, operativt produkt.

I praksis vil prototyper for nye applikasjoner eller trekk bli konstruert, implementert og deretter testet på en koope-rativ brukerarbeidsplass. Den aktuelle arbeidsmodell for konstruksjon av prototypen er vist på figur 2, og den endelig modell er kjennetegnet ved at den rommer hvert trekk i en trekkmodul. Figur 2 anskueliggjør de tilsvarende dokumenter som må fremskaffes under spesifikasjons- og konstruk-sjonsfasene, hvilket innbefatter en trekkspesifikasjon 31 som omfatter både en funksjonell spesifikasjon 32 og en testspesifikasjon 33. Fra trekkspesifikasjonen 31 går man inn i en trekk-konstruksjon og verifikasjonsfase 34, hvilket omfatter forberedelsen av en strukturell spesifikasjon 35, en flerhet av deklarative språkmoduler 36, samt en verifika-sjonsmodul 37 som blir benyttet for å fremskaffe en verifi-kasjonslogg 38. Endelig blir en systemtestfase 39 utført og avsluttet.

På figur 3 er det vist et flytdiagram som anskueliggjør den totale oversikt over de multiple trinn ved utviklingen av en prototypeprogramvare i henhold til det foreliggende system. Som tidligere omtalt, går startoppgaven ved fremskaffelse av en prototype ut på å forberede spesifikasjonen. Ved henvisningstall 41 er det symbolisert det første trinn av den tre-trinnsmetodikk som foreskrives av C.C.I.T.T. standardprose-dyrene. Mer spesielt er disse teknikker vist i C.C.I.T.T. spesifikasjoner 1.130 (Method for Characterization of Telecommunications Services), Q.65 (Detailed Description of Sta-ge 2), samt 1.310 (ISDN Network Functional Principles), idet hver av disse herved er innlemmet som referanse. Dette starttrinn tilrettelegger forberedelsen for en totalbeskri-velse eller spesifikasjon av applikasjonen fra brukerens synsvinkel. Deretter ved henvisningstall 42, blir det forberedt et rå-utkast av de forskjellige subjekter som skal innlemmes i den deklarative språkkonstruksjon som er omtalt tidligere for hver bruker. Dette innebærer identifikasjonen av både start- og avslutningsbrukersekvenser som danner de aktuelle subjekter. Deretter, ved 43, benytter systemet et ytterligere spesifikasjonstrinn, trinn 2 av den tretrinnsme-todikk som er fremsatt i de tidligere identifiserte C.C.I.T.T. prosedyrer, innbefattende identifikasjonen av funksjonelle enheter. Deretter, ved 44, blir funksjonelle enheter avbildet, og unike og felles predikater blir identi-fisert i henhold til den tidligere omtalte fremgangsmåte vedrørende det deklarative språk. Under dette trinn blir brukersekvenser representert i ett eller flere subjekter og de forskjellige funksjoner blir strukturert og/eller grup-pert på en naturlig og lett forståelig måte. Endelig, ved 45, blir hver av enhetene fra den reelle verden representert som objekter. F.eks. blir aksessekvenser representert under bruk av objekter, selv om de internt er strukturert som subjekter .

Vedrørende en ytterligere forklaring av prototypeteknikken ifølge den foreliggende oppfinnelse, så viser figur 4 trinn 1 spesifikasjonen vedrørende tjenesteaspektet ved den funksjonelle spesifikasjon. Dette er den prosedyre innenfor hvilken den totale beskrivelse blir forberedt ut i fra brukerens synsvinkel. Slik det fremgår av figur 4, kan tjenes-ten allerede eksistere i et spesielt trinn 51, og som reaksjon på en brukers forespørsel 52, vil den kunne kreve en funksjonell handling 53. Resultatet av en slik funksjonell handling ved 53, vil kunne produsere et utsignal som trigger et brukersvar ved 54, og en selektering av en spesiell tilstand 55. Imidlertid, vil den funksjonelle handling ved 53 også kunne ta form av en nettverk/brukerforespørsel 56 som initierer en nettverk/brukerrespons 57 som resulterer i en funksjonell komponent 58. Utsignalet fra komponenten 58 vil kunne fremskaffe ytterligere funksjonelle handlinger 59, sammen med et brukersvar 60 som fører systemet til en intern tilstand 61.

På lignende måte vil trinn 2 prosedyren hva angår generering av den funksjonelle spesifikasjon være knyttet til de funksjonelle nettverksaspekter, f.eks. identifikasjonen av funksjonelle enheter og informasjonsstrømmene i systemet. Slik det fremgår av figur 5, er en flerhet av funksjonelle enheter FE1-FEn, 62-65 innbyrdes forbundet med det funksjonelle komponentaspekt ved nettverket 66. Hver av disse funksjonelle komponenter er i stand til å utveksle meldinger med andre funksjonelle komponenter, slik at det forekommer en komplett informasjonsstrøm i de forskjellige komponenter i systemet, for sammenkobling av enhetene til et funksjonelt nettverk. F.eks. vil en meldingsforespørsel som er sendt ved 66a fra den funksjonelle enhet 62 bli mottatt ved 67 for den funksjonelle enhet 63. Som en reaksjon på dette, vil sistnevnte videreføre en meldingsforespørsel fra 68 til 69 ved den funksjonelle enhet 64, som på sin side videresender en melding fra 71 til reseptor 72 i den funksjonelle enhet 65. Deretter vil et svar som er generert i den funksjonelle enhet 65 bli ført videre ved hjelp av meldingssvar fra 73-74 og fra 75-76 og 77-78 via de funksjonelle enheter 64 og 63, nemlig til den funksjonelle enhet 62 som fremskaffer en respons ved 79 til den opprinnelige forespørsel.

På figur 6 er det vist et illustrerende diagram over den måte på hvilken de funksjonelle enheter i tilfelle av lokal, dvs. ikke-nettverkstilkoblede, telekommunikasjoner blir avbildet på programstrukturen. Det er der vist hvordan de funksjonelle enheter FE1-FE4 omfattende spesifikasjonsstrukturen 81 blir avbildet på programstrukturen i henhold til den foreliggende oppfinnelse 82. Slik det ses på figuren, er to telefonapparater 83a og 83b innbyrdes forbundet med pro-gramvarestrukturen ved hjelp av aksess 84a og 84b. Hver av aksessene oppfører seg som objekter innenfor programvare-strukturen. På lignende måte er aksessene 84a og 84b innbyrdes forbundet ved hjelp av en bruker A enhet 85a og en bruker B enhet 85b, som danner subjektene i programstrukturen ifølge den foreliggende oppfinnelse, samtidig som de, slik det kan ses på figur 6, er aksess/objektuavhengige.

På figur 7 er det vist på et lignende illustrativt diagram den måte på hvilken de funksjonelle enheter blir avbildet i tilfelle av nettverksrelaterte telekommunikasjoner. Her er det vist den måte på hvilken de funksjonelle enheter FE1-FE4 hos spesifikasjonsstrukturen 81 blir avbildet på programstrukturen 82. Også her er telefonapparatene 83a og 83b forbundet henholdsvis til aksess A 84a og aksess B 84b. På lignende måte danner også en bruker A enhet 85a og en bruker B 85b separate subjekter i programstrukturen, hvilke er aksess/obj ektuavhengige . Dessuten foreligger det et ytterligere nettverksavhengig subjekt 86 sammen med et generisk nett-verkssubjekt 87. Hver av disse inneholder en nettverksbruker A 86a, 87a og en nettverksbruker B 86b, 87b. Dessuten kobler en nettverksprotokoll 88 sammen en nettverksaksess A enhet 89 og en nettverksaksess B enhet 90.

Ved prototypesystemet ifølge den foreliggende oppfinnelse blir prosesskonseptet brukt til å modellere driftstidsstruk-tur samtalemodellen for applikasjonen, samtidig som prosesser blir samtidig utvekslet med hverandre. En prosess blir aktiv på grunn av et eksternt stimuli/signal, og etter å ha utført den aktuelle kode, vil en prosess forbli i en viss definert tilstand. En slik modell passer meget bra til egen-skapene hos applikasjonen, i og med at det foreligger mange parallelle samtaler og idet hver samtale trigger et antall operasj onssekvenser.

Generelt, deler systemet opp samtalemodellen på samme måte som den funksjonelle modell i spesifikasjonen blir oppdelt. Slik det fremgår av figur 12, har hver av de funksjonelle trekkmoduler 90 forskjellige enheter 160 og for brukere 161, og i tillegg til disse moduler er også linje-/terminalinnretningene 162 separat modellert. Således, slik det fremgår av figur 12, for hver side av en samtale blir det tillagt separate prosesser for: (a) hver maskinvareinnretning (driver prosess 163), (b) hver type av linje (aksessprosess 164), samt (c) hver part i en samtale (brukerprosess 165).

Nettverkstrekk så vel som et frittstående PBX trekk, bør

være veltilpasset, fordi de allerede er plassert i den funksjonelle modell i spesifikasjonsarbeidsfåsene, samtidig som separate samtalesider er representert ved forskjellige enheter. Det blir derfor valgt et splittet syn for samtalestyring, noe som resulterer i to samtalesider, idet hver av

disse har sine egne sett av prosesser. Splittet samtalestyring omfatter også den ytterligere fordel at det totale antall av tilstander blir redusert i betydelig grad. Splittet samtalestyring krever i mange tilfeller forhandling-er/kommunikasjon mellom samtalesidene før beslutninger blir fattet. Således vil kommunikasjonen mellom sidene bli under-

støttet av en protokoll på høyt nivå som skjuler meldingen idet denne passerer gjennom prosessorene.

Slik det vil bli omtalt i ytterligere detalj i det følgende, er systemprogramvarearkitekturen delt opp i forskjellige lag. Dette gir tydelige fordeler, f.eks. vedrørende: 1) applikasjonen blir uavhengig av de selekterte operasjonssystemer, 2) applikasjonen blir uavhengig av den selekterte CPU maskinvare, samt av telekonununikas jons-maskinvaren, og 3) fordelingen av prosessorer blir skjult fra applikasjonen.

Den lagorienterte struktur ifølge systemarkitekturen er vist på figur 8 hvor et applikasjonslag 91, et applikasjonsoperasjonssystemlag 92, samt et basisoperasjonssystemlag 93 omfatter programvaresystemet. Applikasjonslagkoden er avgren-set for at applikasjonsprogramvarestrukturen kan modellere, så nøyaktig som mulig, den operasjonsrelaterte driftstidsom-givelse. Applikasjonslaget 91 omfatter en flerhet av uav-hengige oppgavemoduler 89 som reflekterer de salgsrelaterte obj ekter/trekk som tidligere er definert under spesifikasjonsarbeidsfasen. Disse oppgavemoduler blir ytterligere underdelt i brukermoduler 94, aksessmoduler 95 og drivermoduler 96. Hver brukermodul 94 håndterer de aksessuavhengige aspekter ved et trekk, dvs. trafikkstyredelen av et trekk. Hver aksessmodul 95 håndterer terminalkarakteristikker og start/avslutning av individuelle samtalesesjoner. Hver drivermodul 96 håndterer koding av logikksignaler til bitstrøm-mer til maskinvaren og dekodingen av bitstrømmer og logikksignaler fra maskinvaren. Disse oppgavemoduler 89 beskriver det komplette sett av funksjoner eller trekk for enten (a) telefonoppgavene, innbefattende signaleringsprotokoller, (b) overvåkningsoppgavene, eller (c) interaksjonen mellom trekk. Et obligatorisk trekk ved det foreliggende system er basis-samtalesekvensen.

Applikasjonslaget 91 ifølge systemet omfatter også et appli-kas jonsbibliotek 97. Applikasjonsbiblioteket 97 for komponenter innebærer et kraftfullt verktøy for konstruktører og utviklere, hvilket hever nivået for applikasjonskonstruk-sjon. Det inneholder funksjoner som blir hyppig brukt ved konstruksjon av trekk. Hver av disse funksjoner kan identi-fiseres i spesifikasjonsfasen for hver ny applikasjon og er innlemmet i systemet, uten behov for egentlig programmering av de detaljer som er nødvendige for å gjøre funksjonaliteten operativ.

Idet det fremdeles vises til figur 8, ses det her at appli-kas jonsbiblioteket 97 omfatter, f.eks., funksjoner som hyppig benyttes ved konstruksjon av trekk. Funksjoner kan iden-tifiseres under spesifikasjonsfasen, og da også rett og slett bli brukt på nytt under arbeidsfasen. Funksjonene ved applikasjonsbiblioteket 97 kan meget vel innbefatte funksjonalitet på en flerhet av samtalesider, hvilket er i kontrast til de begrensninger som vedrører funksjonene for applikasjonsoperasjonssystemet. Det følgende er en liste over funksjoner som kan innlemmes i applikasjonsbiblioteket 97:

(a) svar samtale,

(b) kontroller samtale,

(c) tilkoble samtale,

(d) frakoble samtale,

(e) fordel samtaler,

(f) tilslutt samtale,

(g) slå sammen samtale,

(h) køplasser samtale,

(i) gjenkobling,

(j) omruting av samtale,

(k) gjenoppta samtale,

(1) tilbakekall samtale,

(m) innfang parter,

(n) oppsett samtale,

(o) splitt samtale, og

(p) opphør samtale.

Dessuten vil funksjoner knyttet til applikasjonsbiblioteket 97 også kunne defineres for trekk av typen overvåkning.

Laget 92 vedrørende applikasjonsoperasjonssystemet (AOS) i systemarkitekturen, som også er vist på figur 8, skaffer støttefunksjoner til applikasjonslaget 91 og hjelper utviklere til å unngå duplisering av kode ved et antall forskjellige trekk. Det assisterer også i å tillate applikasjonspro-grammering å finne sted ved et så høyt nivå for abstraksjon som mulig, ved også her å skjule implementeringsdetaljer fra applikasjonskonstruktøren. Nevnte AOS lag 92 har to primære funksjonsgrupper, en verktøykasse 98 og et sett med generiske funksjoner 99. Verktøykassen 98 skaffer funksjoner med generelt formål like overfor applikasjonslaget 91, og omfatter f.eks. følgende funksjoner: (a) kommunikasjon mellom parter, (b) svitsjing, (c) køordning, (d) tidtagning, (e) samtalehistorie, (f) nummeranalyse, samt (g) konfigurasjonsovervåkning. De generiske funksjoner i nevnte AOS-lag 92 skaffer de mekanismer som er nødvendige for å utføre brukermodulene 94 og aksessmodulene 95 som inneholdes i trekkmodulene 90.

Operasjonssysternet ved telekommunikasjonssystemer utgjør vanligvis enkle driftstidsordrer med knapt noe mer funksjonalitet enn evnen til å sende meldinger mellom parter i systemet, laste inn kode, utføre I/O-operasjoner. Dette innebærer ofte, i forbindelse med telekommunikasjonssystemer, at det er vanskeligere å overvåke distribusjon, gjenoppstarting eller andre operasjons/prosedyremekanismer enn det er å kode funksjonaliteten hos et spesielt trekk eller en spesiell applikasjon. Løsningen ifølge operasjonssysternet til den foreliggende oppfinnelse, slik dette fremgår av figur 8, går ut på i stedet å fremskaffe et basisoperasjonssystem 93 som er mer tilpasset de som er tilgjengelige ved standard tids-delte systemer, men som også inneholder de ytterligere grunnord og funksjoner som er nødvendige spesielt for telekommunikasjoner. Noen eksempler på slike funksjoner omfatter:

(a) generiske funksjoner for drivere 102,

(b) initieringsfunksjoner 103,

(c) databaselagring og gjenfinnings-

funksjoner 104,

(d) innretningsallokering 105, og deallokerings

funksjoner,

(e) feilgjenvinningsfunksjoner 106,

(f) svitsjhåndtering basert på svitsjgruppe-abstraksjonen, og (g) skjuling av realiteten av en distribuert arkitektur og aktuelle konfigurasjoner.

Standard grunnord for meldinger som passerer gjennom prosesser, prosessopplegg, I/O-forbindelser til maskinvare, osv., foreligger selvsagt også, sammen med et styreprogrampane1. Basisoperasjonssystemet ("BOS") 93 ifølge den foreliggende oppfinnelse hever nivået for programmering, men bidrar også til å gjøre systemet feiltolerant. Nevnte BOS 93 bibeholder informasjon om hvilke ressurser som er blitt allokert til applikasjonsprosesser, og også om hvilke prosesser som er bundet sammen i en transaksjon. Således, når en feil opp-står, enten på grunn av en programfeil eller fordi et sam-virkende knutepunkt svikter, vil nevnte BOS 93 være i stand til å avslutte den oppkoblede prosess og restaurere ressur-sene. En virkning av dette er at det tillater feilgjenvinning per anrop. En annen fordel går ut på at det skaffes en meget robust testomgivelse for utvikling av ny applikasjons-programvare. Dessuten, ved det foreliggende system, vil derfor maskinvare- og programvareteil bare påvirke de transak-sjoner hvori de opptrer, og systemet kan reorganiseres og ombeordres på en effektiv og oversiktlig måte.

Slik det er beskrevet tidligere, vil programmering av både prototypesysterner og sanntidsoperasjonssystemer i henhold

til den foreliggende oppfinnelse benytte seg av et deklarativt språk, f.eks. språket ERLANG, konstruert i henhold til paradigmaet for aktive subjekter omtalt tidligere. Ved valg av ERLANG for dette formål, blir språkene LISP, PROLOG og

PARLOG undersøkt. Undersøkelsen indikerte behovet for ytterligere konstruksjoner for håndtering av parallellisme, sann-tidsoperasjoner og andre karakteristikker som er spesielle for telekommunikasjonssvitsjesystemer. Selv den spesielle klasse av logikkspråk som er i stand til å håndtere parallellisme, f.eks. PARLOG, tilsvarende PARLOG og andre, omfatter fremdeles ikke tilstrekkelig samtidighets-granularitet til at en asynkron telefonprosess kan representeres ved en eneste prosess i språket. ERLANG prosesserer de ønskede trekk av både PROLOG og PARLOG, men med samtidighet og feil-gjenvinningskonstruksjoner bygget inn i selve språket. Slik det vil fremgå av en oversikt over de tidligere innlemmede referanser vedrørende ERLANG, så innbefatter ERLANG-karakteristikkene av høynivåsymbolisme, en mønstertilpas-ningssyntaks, enkle styrestrukturer, høynivådatastrukturer, understøttelse for feildetektering og korrigering, lett-vekt sprosesser samt meldingsoverføring.

Ved implementeringen av prototypesystemet ifølge den foreliggende oppfinnelse kan prototypeomgivelsen omfatte standard arbeidsstasjoner som drives under UNIX operativsyste-met. Utviklingsområdet i arbeidsstasjonene kan innbefatte et brukergrensesnitt som innbefatter X-Windows, arkiver med me-nybasert aksess, versjonsovervåkning, teksteditorer som arbeider under UNIX, dokumentpreparering via rammegenerator, samt kommunikasjon via elektronisk post. Dessuten innbefatter prototypestøttesystemet verktøy for spesifikasjonsfasen samt for fremtidig konstruksjon og verifikasjonsfaser. Verk-tøy som er felles for disse arbeidsfaser omfatter browsere, selekterte synsfelt, hyperteksteditorer, søkemulighet i et dokument, mellom dokumenter i den samme arbeidsfase, og sø-kemulighet mellom spesifikasjonen og den endelige kode.

For spesifikasjonsarbeidsfasen skaffer støttessystemet gra-fiske verktøy, verktøy for statisk og dynamisk modellering, samt maler. For konstruksjons- og verifikasjonsarbeidsfåsene er det viktigste verktøy ERLANG-systemet som understøtter følgende funksjoner: (a) utføring av en trekkmodul og simulering av

maskinvareknutepunkter,

(b) søking etter trinn for individuelle

funksjoner,

(c) spionering på alle kommunikasjoner til en

spesiell prosess,

(d) undersøkelse av prosesstrukturer, dvs. beslutning om hvilke prosesser som skal opphøre, hvordan prosesser blir forbundet for feilgjenvinningsformål, osv., (e) undersøkelse av prosessglobale variabler, og (f) rekompilering av kode på sparket og introduksjon av dette i det operative driftstidssystem.

Støttesystemet vil i tillegg skaffe interaktive grafikk, database og annet verktøy.

Forskjellige trekk kan velges hva angår testobjekter ved evalueringen av prototypeteknologien. Slike trekk blir konstruert i henhold til de funksjonelle spesifikasjoner for en moderne PBX, f.eks. av typen Ericsson MD 110 og omfatter følgende trekk: basissamtale, basisnettverkssamtale, basis-trådløs samtale, samtalelinjeidentifikasjon, trepartstjenes-ter, formidling av samtaler, operatørutvidelse, samtalefull-byrdelse ved opptatt/intet svar, operatørgjenoppkalling samt forstyrrelse.

Slik det er omtalt tidligere, vil den lagorienterte løsning innenfor programvarearkitekturen, sammen med den intime avbildning av den funksjonelle struktur i spesifikasjonene, gjøre det mulig å ha et eneste individ til å utføre hele trekk-konstruksjonen og implementeringen. Dette individ kan også være ansvarlig for funksjonsspesifikasjonsarbeidsfasen, hvilken således gjør det mulig for programvarekonstruktører å bli reelle applikasjonskonstruktører med deres fokusering på kunder og sistnevntes krav. Dette vil dessuten tillate at de laveste lag i arkitekturen blir tatt hånd om av system-konstruktører som er mer spesielt inneforstått med den oppgave .

Den intime avbildning av programvarearktitekturen til den funksjonelle struktur gjør arbeidsmodellen meget enkel. Som en konsekvens vil antallet dokumenter som blir fremskaffet ifølge det foreliggende system, bli redusert i vesentlig grad. Videre vil noen dokumenter i prototypen kunne genere-res automatisk. Dessuten vil en måling av konstruksjonsef-fektiviteten sammenlignet med nåværende systemer indikere i det minste én økning i effektivitet på opptil ti ganger. Reduksjonen i antallet personer som er involvert i konstruksjonen og verifikasjonen av et spesifikt trekk ved prototy-peprogramvaren, blir redusert til ett individ, hvilket gir et antall fordeler, innbefattende fjerningen av lange vente-perioder og reduksjonen av føringstider. En ytterligere fordel går ut på mer nøyaktig programvareplanlegging.

Konstruksjonen av oppgave-, trekk- eller styringsmoduler i det foreliggende system er forholdsvis lett og likevel in-tellektuelt stimulerende på grunn av et antall faktorer. F.eks. korresponderer den verbale tekst i funksjonsspesifi-kasjonen med koden i trekkmodulen, hvilket derved forbedrer kode- og trekkforståelsen. Dessuten er programmene små av størrelse og oversiktlige under bruk av språkkvaliteter, i likhet med tilpasning, listehåndtering og rekursive funksjoner. Videre er en konstruksjon inkremental og interaktiv, og prosessen tillater strukturert vekst. Lapping er ikke nød-vendig i det foreliggende system, fordi programmer kan rekompileres på sparket, og fordi repeterte verifikasjoner av trekk eller av deler derav kan fullføres automatisk bare ved hjelp av testfilaktivisering. Sluttelig kan data fremvises på et høyt symbolsk nivå, idet det ikke er nødvendig å ta kapasitetsproblemer under konstruksjonen med i betraktning-en, og idet det foreligger atskillig færre dokumenter å forberede .

Slik det kan ses fra den hittil fremførte beskrivelse av prototypeteknikken ifølge den foreliggende oppfinnelse, er det arkitekturelle arbeid basert på genuin kjennskap til brukerapplikasjonen. Dette gjør det mulig å skape et begrenset antall av veldefinerte enheter i en lagorientert konstruksjon. Systemet begrenser enhetene og definerer strengt deres funksjonelle innhold, i stedet for å kreve utvikling av ytterligere metoder for hvordan objektene skal dokumenteres og ivaretas. Kombinasjonen av denne arkitektur, som er relativt lett å forstå og håndtere, med en sanntidsdeklara-tiv språkkonstruksjon slik det er omtalt tidligere, reduserer i stor grad mengden av arbeid påkrevd for å implementere nye tjenester og trekk i et telekommunikasjonssvitsjesystem. Det gjør det også mulig å utføre sanntidstesting av nye tjenester og trekk ved implementering av avanserte prototyper,

før de introduseres i større skala på markedet. Teknikken ifølge den foreliggende oppfinnelse gjør det mulig å bevege arbeidsvolumet vekk fra implementeringsproblemene, og den tillater konsentrasjon på kundebehov og på utviklingen av nye og mer avanserte tjenester.

Proqramvarearkitektur og teknologi

Slik det er omtalt tidligere i forbindelse med figur 8, er programvaresystemarkitekturen ifølge den foreliggende oppfinnelse lagorientert og omfatter et applikasjonslag 91, et applikasjonsoperasjonssystemlag 92, samt et basisoperasjonssystemlag 93. Dessuten mottar et implementeringslag 101 den lagorienterte programvarearkitektur. Applikasjonslaget 91 omfatter et applikasjonsbibliotek 97 med en flerhet av oppgavemoduler 89. Hver oppgavemodul 89 omfatter en brukermodul 94, en aksessmodul 95 og en drivermodul 96. Applikasjonsoperasjonssystemlaget 92 omfatter en verktøykasse 98 og et sett av generiske funksjoner 99. Basisoperasjonssystemlaget 93 omfatter generiske funksjoner for drivere 102, syste-moppstarting og gjenoppstartingsfunksjoner 103, databaselagring og gjenvinningsfunksjoner 104, generiske funksjoner for innretningsallokering/deallokering 105, samt feilgjenvinningsfunksjoner 106. Implementeringen i blokk 101 omfatter et deklarativt programspråksystem 107, f.eks. ERLANG, et ma-skinvareoperativsystem ("OS") 108, en sentral prosesserings-enhet ("CPU") 109, samt telekommunikasjonssvitsjemaskinvare 110.

På figur 9 er det vist en annen utgave av den lagorienterte programvarearkitektur ifølge den foreliggende oppfinnelse,

hvor applikasjonen omfatter de høyeste lag, dvs. de som ligger tettest opptil applikasjonsspesifikasjonen. De andre lag representerer dypere lag av implementering, som befinner seg tettere opp til den fysiske maskin som bearbeider programvaren. Det fremgår at applikasjonen omfatter applikasjonslaget 91, som omfatter applikasjonsbiblioteket 97 og applikasjonsoperasjonssystemlaget 92. Applikasjonslaget 91 gir en oversikt som tilsvarer måten applikasjonen ble spesifisert til å begynne med. Applikasjonslaget 91 er også isolert fra basis-operas jonssys ternet og systemarkitekturen, ved hjelp av app-likas jonsoperasjonssystemlaget 92. Applikasjonsoperasjonssystemlaget 92 skaffer støttefunksjoner for applikasjonslaget 91 for å unngå reproduksjon av kode i flere forskjellige oppgaver eller trekk, å heve applikasjonsprogrammeringen til et så høyt nivå av abstraksjon som mulig, samt til å isolere applikasjonskonstruktøren fra implementeringsdetaljer. Internt er applikasjonslaget 91 underdelt i et antall uavheng-ige oppgavemoduler 89 som funksjonelt kan betraktes som en kombinasjon av trekkmodul 90 og overvåkningsmoduler 111. Hver av disse to typer av moduler, trekkmoduler 90 og overvåkningsmoduler 111, er meget like hverandre og fullt under-delbare i bruker (samtalehåndtering) moduler 112a-112b, aksess- (linjehåndtering) moduler 113a-113b, samt drivermoduler 114a-114b. Trekkmodulene 90 og overvåkningsmodulene 111 beskriver sammen det komplette sett av trekk eller oppgaver i systemet. En oppgave kan f.eks. omfatte en telefonoppgave og selve overvåkningshandlingen, dvs. hvordan det skal inte-raktiviseres med andre trekk, signaleringsprotokoller, osv. "Basissamtalen" er å betrakte som et obligatorisk trekk som alltid må innlemmes i systemet. Oppgavemoduler 89 kan for en spesiell oppgave inneholde bare trekkmoduler 90 eller for en

annen oppgave, bare overvåkningsmoduler ill. I andre tilfeller kan imidlertid en oppgavemodul 89 omfatte både trekkmoduler 90 og overvåkningsmoduler 111.

Brukermodulen 112a i en trekkmodul 90 kan f.eks. styre basissamtalen samt hvilke som helst andre trekk. Den styrer oppsettingen og overvåkningen av samtaler på en linjeproto-kolluavhengig måte. F.eks. kan en brukermodul 112a inneholde: (a) en initierende del som initierer initial-dataene som trekket trenger for å kunne utføre oppgaver, f.eks. fremskaffelsen av unike datafelter, tilleggelsen av klar-gjøringsdata til slike felt og lignende, (b) en brukerprosedyredel som definerer bruker prosedyresyntaksen og meningen, og tillegger klargjøringsverdier, og (c) en trafikkdel som definerer hvordan trekket arbeider.

Overvåkningsmodulene har tilsvarende strukturerte brukermoduler 112b, aksessmoduler 113b og drivermoduler 114b.

Trafikkdelen av trekket er delt slik at det foreligger én samtaleside (beskuelse) for hver part med sitt eget sett av tilstander separat fra den andre samtaleside. Dette vil i stor grad redusere det totale antall av nødvendige samtale-tilstander, idet de gjenværende tilstander utgjør naturlige brukertilstander som kan allokeres i fremtiden. Trafikkpar-ten for hver brukermodul 112a er bygget opp hierarkisk fra et toppnivå. Slik det fremgår av figur 10, kommer alle ytre og indre stimuli inn på dette toppnivå for å nå den tilstand/hendelsesdrevne logikk omfattende hendelse og undertilstandsfunksjoner 117. Det er fra dette toppnivå at den passende fase 171 blir oppkalt, med det resultat at fasen gir initiering av den neste tilstand eller undertilstand, samt tillegg/fjerning av parter i samtalen. Denne konstruksjon skaffer konstruktøren et godt overblikk over hele trekket bare ved å lese dette toppnivå.

Hendelses- og undertilstandsfunksjonene er de eneste deler av brukermodulen som er synlige for andre brukermoduler i systemet. De innbefatter muligheten for interaksjon med en første samtalehåndteringsmodul ved definisjon av hendelses-eller undertilstandsfunksjoner som tar over styringen og returnerer den heretter. F.eks. vil loggetrekk alltid returne-re styringen etter at trekket har komplettert utførelsen. De generiske støttefunksjoner for tilstand/hendelseshåndtering blir fremskaffet av applikasjonsoperasjonssystemet 92.

En fase 171 er i stor utstrekning en kombinasjon av funk-sjonssamtaler som er adressert til enten dens eget lokale bibliotek 172, applikasjonsbiblioteket 97 eller til applikasjonsoperasjonssystemet 92. Etter komplettering av en fase 171 blir et resultat 173 returnert til toppnivået. Eksempler på fasejobber omfatter: (a) analyse av adresseinformasjon, (b) kontroll vedrørende autoriteter, (c) forespørsler til andre parter, (d) svar på forespørsler av andre parter, (e) svitsjeoperasjoner, samt (f) kommandoer til å ta over en linje. Den hierarkiske struktur som benyttes i trafikkdelene av applikasjonslaget, er vist på figur 10. Her er det vist hvordan forskjellige funksjoner blir oppkalt fra forskjellige biblioteker og operasjonssystemer for å kunne implementere trafikkfunksjonene.

Strukturen av komponentene i systemet ifølge den foreliggende oppfinnelse er på nytt anskueliggjort på figur 11, og her på en alternativ måte. Her er det vist at aksessmodulene 113a, 113b styrer de linjeavhengige deler av trekkene. Det foreligger en unik aksessmodul for hver type linjeterminal, og for de trekk som har linjeavhengige deler. Eksempler på linjeterminaler omfatter analog/digital/ISDN telefontermina-ler og analog/digital/ISDN fjernlinjer for basis- og supple-mentærtjenester. Hver aksessmodul 113 håndterer den semantiske del av en protokoll for hver spesifikk type maskinvare. Aksessmodulen presenterer også en innretningsuavhengig protokoll som er dirigert mot brukermodulen 112. Denne protokoll er rent funksjonell og uavhengig av linjeterminalty-pen. Hver aksessmodul 113a, 113b omfatter: (a) en initierende del som innstiller klargjorte data for den aktuelle linje, aktiviserer maskinvaren og tilbakestiller terminalen til en passende tilstand, og (b) en trafikkdel som har til oppgave å fordele og håndtere trafikkhendelser.

Strukturen for aksessmodulen 113 er noe forskjellig fra den til brukermodulen 112. toppnivået på aksessmodulen 113 er delt inn i to mindre deler, nemlig fordelingsdelen og hen-delseshåndteringsdelen. Hensikten med fordelings- eller av-sendelsesdelen er å raffinere innkommende hendelser ved pro-sessering/oversettelse av signaler som kommer fra linjen eller fra den annen part til et internt sett av hendelser før disse mates inn i en hendelseshåndteringsdel. Denne for-håndsprosessering utføres med hensyn til mottatte meldinger, meldingsdata og terminaltilstander. Hendelseshåndteringsde-len ligner på toppnivået i brukermodulen. Typiske fasejobber i aksessmodulen 113 omfatter: (a) håndteringen av flere samtaleaksess-muligheter, (b) indikeringen av samtaleprosessmeldinger til

brukeren,

(c) håndteringen av den semantiske del av

linj eterminalprotokollen,

(d) utførelse av nummer-, prosedyre- og

suffiksanalyse, og

(e) fremskaffelse og samvirke med samtale-håndterere.

Drivermodulene 114a, 114b kan ses på som et grensesnitt mot maskinvaren. De håndterer maskinvaredelen av linjeprotokol-len, dvs. syntaksdelen av trekkene. Drivermodulen 114 deko-der maskinvarelinjesignaler/bitstrømmer og leverer disse i symbolsk form til den passende aksessmodul 113. Drivermodulen 114 koder også symbolske signaler fra aksessmodulen 113 til maskinvaresignaler. Det foreligger også generiske dri-verstøttefunksjoner for hendelse/signalhåndtering i operasjonssystemet som blir overtatt eller initiert ved oppstar-ting av modulen. De kan betraktes som driftsmekanismene for signaloverføringen mellom maskinvare og programvare. Det foreligger én drivermodul for hver type av termi-nal/maskinvare. Innlemmet i systemet finnes også en flerhet av overvåkningsmoduler som gir et sett av forskjellige typer overvåkningsfunksjoner, innbefattende: (a) feilovervåkning, (b) konfigurasjonsovervåkning, (c) bokholderiovervåkning, (d) utførelsesovervåkning, samt (e) sikkerhetsovervåkning, blant andre.

Overvåkningstrekk blir håndtert av overvåkningsmoduler 111 på samme måte som trekkmodulene 90 definerer og implemente-rer telefontrekk. En overvåkningsmodul kan håndtere en eneste type, av eller flere enn én, overvåkningsfunksjon. Overvåkningsmoduler 111 er sammensatt av overvåkningsbrukermodu-ler 112b, overvåkningsaksessmoduler 113b, samt overvåknings-drivermoduler 114b, slik dette henholdsvis er vist på figurene 9 og 11. I likhet med den måte som trekkmodulen 90 drives på, håndterer overvåkningsdrivermodulen 114b den syntak-tiske del av overvåkningsprotokollen, og overvåkningsaksess-modulen 113b er ansvarlig for den semantiske del av overvåkningsprotokollen. Sluttelig bedriver overvåkningsmodulen 111 interaksjon med trekkmodulene 90 som følger: (a) via databasen for konfigurasjonskommandoer, (b) som rapport/meldingsmottakere for loggings

trekk, og

(c) via databasen og direkte med maskinvaren for linj eovervåkning.

Ved fornyet henvisning til figur 11 viser blokkdiagrammet her ikke bare konfigurasjonen over de forskjellige komponenter i programvarearkitekturen, slik dette også er vist på figur 8, men indikerer også interaksjonen mellom, og blant hver av, komponentene. Trekkmodulen 90 skaffer trekkunike datafelter 121 i den passende BOS database 104, og tillegger formater og begrenser klargjøringsdataverdier 122 under dennes initierende del slik dette er vist ved henvisningstall 122 og ved 123. Overvåkningsmodulen 111 fremskaffer under sin initierende del kommandoer og parametere ved å henvise til klassedatafelter 124 som vist ved 125. Disse blir lagret i konfigurasjonsdatabasen 104 sammen med det gjenfunnede klassedatafelt 124 hva angår begrensninger og aksessautori-teter. Ved mottakelse av en kommando ved 128 i driveren 114b i en overvåkningsmodul 111, blir kommandoen analysert av en kommandoanalysator ved 127, og autoriteten med hensyn til bruken av kommandoen blir kontrollert. Videre, ved 127 og 128, blir det bestemt hvorvidt de gitte parametere ligger innenfor de verdigrenser som er lagret i klassedatafeltet 124. Når kommandoen blir akseptert, vil det passende individ få tillatelse til aksess ved hjelp av det aktuelle overvåkningstrekk, og det passende trekkunike datafelt 131 kan be-tjenes og mottas av brukermodulen 112b slik dette er vist 132 og 133. Slike operasjoner kan innbefatte innføring, endring, utskrift og fjerning av operasjoner.

Mer spesielt vil den initierende del i brukermodulen 112a av trekkmodulen 190, når denne er initiert, kalle opp en prosedyre "lag felt" i AOS laget 92. Denne prosedyre initierer at klargjøringsdataene i BOS databasen 104 for utvidelsesklassedata 121, kan benyttes for attributtet (eller parameteren) " intrusion_cat_A" (dvs. tjenestesamtaler, eller kategori, for startparten, nemlig A parten, for initiering av forstyrrelse) . Det tillatte format eller grenser for disse data blir også lagret i databasen 104.

Ved utførelse av trafikkdelen i brukermodulen 112a av trekkmodulen 90, og under testing av forstyrrelse av kategori A, vil en prosedyrekontroll i AOS laget 92 bli oppkalt. Denne prosedyre vil først kontrollere hvorvidt den involverte bruker har en individuell kategori for det ''intrusion_cat_A'<1 >som er programmert inn i den individuelle utvidelsesdatabase 131. Dersom så er tilfelle, vil denne kategori bli benyttet. Hvis ikke vil klargjøringsdataene spesifisert i 122 av utvi-delsesklassedatabasen 121 bli benyttet.

Den initierende del i brukermodulen 112b av overvåkningsmodulen 111 vil, ved initiering, ved hjelp av en AOS lag 92 prosedyre, fremskaffe referanser 95 i konfigurasjonsklasse-dataene 124 for hver attributt eller parameter som er definert i utvidelsesklasseklargjøringsdataene 122.

Når en overvåkningsoperasjon blir mottatt i aksessmodulen 113b i overvåkningsmodulen 111, så vil den aktuelle opera-sjon blir ugyldiggjort sammen med overvåkningsbrukers auto-ritet for å bruke operasjonen. Når overvåkningsoperasjonen er funnet å være gyldig, blir den deretter ført til brukermodulen 112b. Dersom overvåkningsoperasjonen skulle fremskaffe et datafelt for '<1>intrusion_cat_A'' for binummer "12345" med verdien "ja", så vil følgende finne sted: brukermodulen 112b vil ved hjelp av en AOS lag 92 prosedyre kalle opp klargjøringsdataene 122 i utvidelsesklassen 121 for å innhente det aktuelle format av datafeltet, nemlig " intrusion_cat_A'<1> parameteren. Dersom verdien "ja" er gyldig i dette format, så vil prosedyren i AOS laget 92 bli oppkalt for oppdatering av de individuelle utvidelsesdata 131 for bilinje "12345" med verdi "ja". Dersom overvåknings-operas j onen gikk ut på å fremskaffe datafeltet <1>'intru-sion_cat_AM for bilinje "12345", så vil en AOS lag prosedyre bli oppkalt, hvilket innhenter 133, den aktuelle verdi i de individuelle utvidelsesdataer 131.

Et overvåkningstrekk kan også motta et utvidelsessignal fra f.eks. trekk loggedata. Overvåkningstrekket vil da abonnere på visse hendelser og selektere telefontrekk og når disse

hendelser finner sted, vil telefontrekkene overføre standard meldinger til de passende overvåkningstrekk. Kommandoer blir

deretter håndtert av denne overvåkningsmodul 111 som på sin side beslutter: (a) hvorvidt mottatte data skal eller ikke skal

kastes vekk,

(b) når et utsignal skal finne sted,

(c) hvilke data som skal føres ut,

(d) formatet for utdataene, og

(e) den adresse som utdata skal sendes til.

Overvåkningsmodulen 111 kan nås enten fra lokale terminaler, eller fra et nettverksovervåkningssenter.

Applikasjonsdata blir inndelt i to typer, nemlig statiske data og dynamiske data. Alle data blir fysisk lagret i data-baser som overvåkes av basisoperasjonssystemet 93, og hver av oversiktene over de data som er beskrevet tidligere blir beskuet fra applikasjonslaget 91. Statiske data omfatter data som lever lenger enn én samtale. Levetiden for statiske data kan være kort, f.eks. én dag, mens levetiden for de data som er avhengig av hvilke trekk som eier dataene og de fleste slike data, vil ikke normalt overleve et systemsammenbrudd, i hvilket tilfelle dataene holdes i live inntil det forekommer en forandring ved hjelp av kommando eller restaurering fra backup-media etter systemsammenbrudd. Eksempler på data med kort levetid omfatter ring tilbake informasjon eller følg meg data, mens eksempler på data med lang levetid omfatter nummerserier, tillatte trekkaksesser for brukere (klasse av tjenester), brukeraktiviserte trekk, trekkrelaterte data, osv.

Dataene av en viss type tilhører enten en klasse med objekter eller en superklasse hvori en klasse kan ses på som en viss brukertype. Denne datatype har et navn, en klargjør-ingsverdi, et spesifisert format, et tillatt verdiintervall, samt informasjon om hvorvidt eller ikke den skal restaureres etter systemsammenbrudd. Individer får tilknytning til en klasse ved opprettelse, idet de ved momentariseringen av de individuelle enheter får overtatt de passende klassedata. Klargjøringsdataverdien kan deretter endres for hvert av in-dividene. Typiske klassedata omfatter: utvidelsesklassedata 121, konfigurasjonsklassedata 124, operatørklassedata, des-tinasjonsklassedata, ruteklassedata og fjernlinjeklassedata. For å finne disse klasseindivider, er analysetabeller innlemmet i det foreliggende system. Disse omfatter datatabel-ler utledet eller endret ved fremskaffelse av eller endring av klasser og/eller klasseindivider.

Dynamiske data omfatter data, tilknyttet samtaler, som dør når samtalen blir avsluttet. Typiske dynamiske data omfatter referanser mellom parter i samtalen, samtalehistorie (f.eks. utøvende trekk, tidligere forbindelser osv.), samt samtale-tilstander. Dynamiske data kan bare manipuleres ved selve objektet/prosessen og aksess oppnås via datanavnet. For statiske data blir derimot aksess oppnådd for eierreferansen i kombinasjon med datanavn.

Applikasjonsoperasjonssystemlaget 92, som ligger ett nivå under applikasjonslaget, omfatter trekkmodulen 90 og overvåkningsmodulen 111, hvilket også er vist på figur 11. For-målet med applikasjonsoperasjonssystemlaget 92 er å isolere implementeringsdetaljer fra applikasjonslaget, for derved å heve det abstraksjonsnivå som har tilknytning til applika-sjonskonstruksjonen. Grensesnittet mot operasjonssystemet er generelt og innebærer at applikasjonsoperasjonssystemlaget 92 forblir upåvirket hva angår indre endringer og opera-sjonssystemfunksjoner som inneholdes i systemmaskinvaren. Applikasjonsoperasjonssystemlaget 92, slik dette er vist på figur 8, omfatter to hovedfunksjonsgrupper omfattende en verktøykasse 98 og generiske funksjoner 99. Applikasjonsope-rasjonssystemverktøykassen 98 fremskaffer funksjoner av generelt formål like overfor applikasjonslaget 91. Typiske funksjoner som kan innlemmes i applikasjonsoperasjonssystem-verktøykassen 98 innbefatter: (a) kommunikasjon mellom parter, (b) parthåndtering, (c) svitsjoperasjoner, (d) køhåndtering, (e) tidtakning, (f) historiehåndtering, (g) data-felthåndtering, (h) nummerhåndtering, (i) prosedyrehåndte-ring, og (j) administrasjonshåndtering.

Idet det ytterligere henvises til figur 8, så ses det her at applikasjonsoperasjonssystemet 92 med sine generiske funksjoner 99 fremskaffer støttefunksjoner for hendel-se/undertilstandhåndtering og for innføring av nye tilstander. De generiske funksjoner 99 kan ses på som drivinstru-mentet for applikasjonslaget. Når en hendelse eller undertilstand finner sted, vil støttefunksjonene som fremskaffes av de generiske funksjoner 99 prøve å tilpasse seg denne hendelse eller substrat, innbefattende nevntes parametere, i forhold til brukermodulene 112 (eller aksessmodulene 113) av systemet i en fiksert orden. Dersom hendelsen eller under-tilstanden vedrører en bruker, vil tilpasningen bli utprøvd på brukermodulene 112 i henhold til en trekkliste. Dersom hendelsen vedrører aksess, vil tilpasning bli prøvet ut på aksessmodulene 113 i henhold til en aksesstrekkliste. Når en brukermodul 112 eller en aksessmodul 113 med en tilpassende hendelse blir funnet, blir denne modul oppkalt og den tilsvarende funksjon blir utført. Dersom en hendelse eller en undertilstand vedrørende en bruker ikke har en tilpassende hendelse eller undertilstand, så vil oppkallingen bli koblet ned. Dersom en hendelse vedrørende aksess ikke har en tilsvarende hendelse, så vil hendelsen bli ignorert.

Applikasjonsoperasjonssystemet 92 inneholder også innebygde funksjoner for innføring av nye tilstander som enten kan være rettet mot brukermodulen eller aksessmodulen. Den "nye tilstand" kan innbefatte:

(a) en ny tilstand,

(b) en undertilstand i en gitt ny tilstand,

(c) en ny tilstand i kombinasjon med tilføyelse eller

fjerning av parter,

(d) nåværende tilstand, eller

(e) avslutt samtalen/ingen tilstand.

Ved definisjon av samtalemodellen er det valgt prosesskonseptet for å modellere kjøretidsstrukturen for applikasjonen. Begrepet prosess slik det brukes i denne sammenheng, innebærer den sekvensielle utførelse av setninger med et tilhørende sett av data. Prosessene kan utføres samtidig og en prosess blir aktiv, dvs. blir satt under utførelse, på grunn av et eksternt stimuli/signal. En prosess befinner seg alltid i en viss definert tilstand når utøvelsen er komplettert . Alle disse karakteristikker av prosesskonseptet passer meget bra med karakteristikkene for telekommunikasjonsappli-kasjoner, dvs. mange parallelle samtaler, idet hver av disse består av en eller flere operasjonssekvenser. Prosesskonseptet blir understøttet av både det utvidede operasjonssystem og det spesielt konstruerte programmeringsspråk ifølge den foreliggende oppfinnelse, slik dette er omtalt tidligere.

Ved det foreliggende system vil mengden av prosesser være begrenset, på den samme måte som applikasjonskoden er begrenset, for å kunne ha en så komplett tilpasning som mulig mellom applikasjonsstrukturen og driftstid strukturen. Slik det fremgår av figur 12 er applikasjonskoden blitt modulari-sert så nøyaktig som mulig til funksjonsspesifikasjonsobjek-tene . Denne konstruksjon fører til den antakelse at det benyttes én prosess for hver maskinvareinnretning i en driverprosess, hver type linje i en aksessprosess og hver part i en brukerprosess.

Fordi trekk relatert til nettverket og trekk relatert til telekommunikasjonssvitsjing som står alene, bør være meget veltilpasset, benyttes det ifølge den foreliggende oppfinnelse en splittet betraktning for implementering av samtalestyring. Det innebærer at det foreligger to samtalesider, idet hver av disse omfatter sitt eget sett med prosesser. Hovedfordelen med oppsplittet samtalestyring omfatter føl-gende : (a) det totale antall av tilstander blir betydelig redusert. Tilstandskonseptet blir benyttet for å redusere kompleksitet ved applikasjonskoden og blir, som sådan, et høyt ønskelig konsept. Ved sentraliserte samtalemodeller vil antallet av tilstander ha en tendens til å vokse ut av kontroll fordi tilstander må benyttes i forbindelse med kombi-nerte konfigurasjoner med mange parter.

(b) partene er vel isolerte fra hverandre, idet hver har sin egen tilstand og historie. Når en samtale returnerer til en original samtalekonfigurasjon, normalt en samtale med to parter, vil dataene for hver samtaleside fremdeles være

gyldige. Oppsplittet samtalestyring krever i mange tilfeller forhandling og kommunikasjon mellom samtalesider før det kan treffes beslutninger. Kommunikasjonene mellom sidene blir støttet av en høynivåprotokoll som fremskaffer meldinger som føres mellom prosessene. I det minste tre forskjellige kom-munikasjonssituasjoner kan støttes:

(a) meldingssending med ingen bekreftelse,

(b) meldingssending med bekreftelse, og (c) meldingssending med forespørsel for ytterligere informasjon og med bekreftelse.

For hver av disse typer av kommunikasjoner kan det foreligge fire meldingstyper: (a) en notifikasjonsmelding som blir benyttet for å sende meldinger når det ikke er forventet en bekreftelsesmelding, (b) en forespørselsmelding som blir benyttet til å sende meldinger når det forventes en bekreftelsesmelding, (c) en verifiseringsmelding som blir benyttet for å forespørre om ytterligere informasjon før det gis en svarmelding, og (d) en svarmelding som utgjør bekreftelses-meldingen til en tidligere forespurt melding.

Figur 12 illustrerer det som nå er blitt beskrevet innenfor det begrep som vedrører en spesiell implementering av et prototype BPX svitsjesystem. Figur 12 viser de protokoller som implementeres og benyttes for å effektuere kommunikasjonene mellom samtalesider som blir nødvendiggjort ved det styreparadigma som har med splittet samtale å gjøre. Kommunikasjonen mellom sidene blir understøttet for det første ved hjelp av en høynivåprotokoll 180 for meldinger som kommer fra bruker til bruker, andre lavnivåprotokoller under-støtter kompletteringen av kommunikasjoner ned til maskinva-renivået og tilbake opp gjennom kjeden. Bruker/aksessprotokollen 181 fremskaffer kommunikasjoner mellom en brukerprosess 165 og en aksessprosess 164. Aksess/driverprotokollen 182 fremskaffer kommunikasjoner mellom aksessprosessen 164 og en driverprosess 163. Sluttelig skaffer maskinvaredriverprotokollen 183 kommunikasjoner mellom en driverprosess 163 og individuelle maskinvareenheter 184.

Figur 13 viser et samtalemodelleksempel for en basissamtale, idet det vises brukerprosesser 165a, 165b, aksessprosesser 164a, 164b samt driverprosesser 163a, 163b, en for hver av de to separate samtalesider av den viste basissamtale. Maskinvaren detekterer når samtalen blir initiert og sender en signalbitstrøm til sin driverprosess. Driveren 163 vil deretter konvertere signalbitstrømmen til symbolsk form og sende en melding til sin egen aksessprosess 164, som venter på, mottar, analyserer og omformer adresseinformasjon for den

oppkalte part til den logiske individuelle referanse for den oppkalte part. Når dette arbeid er komplettert initierer aksessprosessen 164 en brukerprosess 165 for sin egen samtaleside og sender en oppsettingsmelding til nevnte. Brukerprosessen 165 allokerer den logiske individuelle referanse for den oppkalte part. Deretter vil den initiere en brukerprosess 165b for den samme oppkalte part, og spørre dennes brukerprosess 165a om å sette opp samtalen. Brukerprosessen 165b for den oppkalte part spør aksessprosessen 164b for denne part å fange inn parten, og forbinde seg selv til denne brukerprosess 165b. Deretter blir en bekreftelsesmelding

sendt tilbake til den opprinnelige sides brukerprosess 165a og den komplette samtalemodell for basissamtalen blir da satt opp.

Idet det nå skal vises til figur 14, fremgår det herfra en skisse som anskueliggjør samtalemodellen for samtaler innbefattende tre parter. For en spørresamtale 187, eller når en operatør setter opp en andre samtaleside, vil aksessprosessen 191a parkere den første samtale 188 og sette opp en lik serie med prosesser (bruker 192a - bruker 192c - aksess 191c - driver 190c) for denne nye samtale 189. Aksessprosessen 191a blir således forbundet med to serier av prosesser 188, 189, en for hver samtale.

Idet det nå henvises til figur 15, så er det her vist en an-skueliggjøring av en samtalemodell for en flerpartsamtale. Ved flerpartsamtaler blir en ordinær samtalesidekjede av prosesser benyttet for hver deltaker. På den motsatte samtaleside foreligger det en felles tjenestebrukerprosess 195. Den har ingen forbundne aksessprosesser, hvilket innebærer at denne konfigurasjon får det til å se ut som et sett av ordinære topartssamtaler fra hver deltakers samtaleside.

Ved henvisning til figur 16 fremgår det her en anskueliggjø-ring av en samtalemodell for en gjenoppkalling mot operatø-ren. Ved gjenoppkalling til operatøren foreligger det en ny samtaleside som blir koblet inn fra hver bruker 200a, 200b fra den opprinnelige samtale til en operatørbruker 201a, 201b på hver samtaleside. Ved konstruksjon av trekk må samtalemodellen huskes på, og filosofien og eksemplene som er omtalt tidligere i forbindelse med figurene 13-16 kan da betraktes som retningslinjer ved fremskaffelse av samtalemodellen for fremtidige scenarier. Ideelt bør man strebe etter en modell som passer applikasjonskonseptet bra, og som lett kan tilpasses sannsynlige nye tilstander i applikasjonsbil-det.

Det programmeringsspråk som benyttes ved systemet ifølge den foreliggende oppfinnelse, utgjør et utvidet deklarativt språk som er i stand til å implementere parallellisme sammen med sanntidsfasiliteter. Språket ERLANG innbefatter disse nødvendige karakteristikker, noen hvilke f.eks. kan være som følger: (a) høynivådatastrukturlignende lister og "tuples"

fra LISP eller PROLOG understøttet av dynamisk lagerovervåkning,

(b) høynivåsymbolsk programmering som gir den samme

type av effektiv programutvikling, f.eks. LISP,

(c) utøvelse gjennom mønstertilpasning og enkle styrestrukturer som gir en kort og klar programmeringsstil, (d) moduler, brukt som et bidrag til strukturering av

store programsystemer,

(e) prosesser, prosessovervåkning og samtidig kommunikasjonsunderstøttelse, samt sanntids-operasjoner, (f) understøttelse for feildetektering og feil-korrigering som muliggjør konstruksjon av robuste systemer, f.eks. med feilgjenvinning pr. samtale, og (g) tett tilpasning til SDL, nemlig spesifikasjons språk anbefalt av C.C.I.T.T.

Som en illustrasjon vil det i det følgende bli gitt noen ko-deeksempler, tatt fra implementeringen vedrørende basissamtalen. Følgende er et eksempel fra hendelse/tilstandnivået hvori en oppsettingsmelding innbefattende fem parametere er blitt mottatt. Tilpasning av hendelsen er blitt implementert for trekkmoduler i henhold til trekklisten. Andre trekk har hatt sjansen til å forstyrre hendelsen, men ingen gjorde det. En siste tilpasning blir forsøkt med basissamtalemodulen, slik dette er angitt som følger:

1 # setup( Seif,_, Idle, [Seif ], [CallType. no_name] )

case

call_start_up( Seif.CallType ) {

barred —> abort( blocked );

ok —> state( call_started

complete( Partner) —> state(call_started,add( Partner ) ) ;

2 # setup( Seif, ,Idle,[Seif],[CallType,Name] )

case

establish_call( Seif,CallType,Name )

barred —> abort( blocked );

yes(Partner)—>state(call_started, seizure,add(Partner));

99 # setup( , , , , )

continue.

1991 Telefonaktiebolaget L M Ericsson

Mønstertilpasning finner sted og dette innebærer at tilpasning til den mottatte oppsettingsmelding først prøves ut med innlemmelse av alle parametrene samtidig på den første basissamtale oppsettingsklausul. Dersom det foreligger en tilpasning, vil denne funksjonsdefinisjon bli benyttet. Dersom funksjonen ikke passer, vil pasning bli utprøvd på den neste klausul, osv. Dersom ingen tilpasning på parametrene foreligger, blir styringen gitt tilbake til drivkilden. Fordi basissamtalen er det siste trekk på trekklisten, så vil samtalen i dette tilfelle blir avsluttet. Eksempler på høynivå-symbolprogrammering kan visualiseres ved hjelp av de funk-sjonsoppkalte navn og for parameternavnene i oppsettings-klausulene. Passende navn av hvilken som helst lengde kan velges av programvarekonstruktøren.

Høynivådatastrukturer blir innlemmet med parameteren [Cali type, No_Name] i oppsettingsklausulen som er en liste som representerer en datastruktur med to variabler. Ved det foreliggende system foreligger det enkle samtalestyrestruktu-rer, hvori det i virkeligheten foreligger meget få slike styrestrukturer i det hele tatt. Ved det viste eksempel foreligger det bare to styrestrukturer, nemlig "case" og "continue". Setningen "case" er imidlertid den mest viktige sty-restruktursetning. I det følgende vil det bli gitt et eksempel fra fasenivået hvori det antas at den første oppsettingsklausul i det gitte eksempel er blitt tilpasset den mottatte melding. Funksjonsoppkallingen i denne klausul, "call_start_up (seif call type)", blir oppkalt.

# call_start_up( Seif,CallType )

case

check( call_allowed,Self )

no —> notifyC release(barred),Seif),

"barred;

yes —> remember( call_direction,caller_A

nocify( setup_ack(normal),Seif ),

"ok

<®> 1991 Telefonaktiebolaget L M Ericsson

Når "call_start_up" klausulen på sin side blir tilpasset, vil den første funksjonssamtale utgjøres av AOS funksjon kontroll/2, som har to parametere. Denne funksjon blir evaluert og resultatet blir returnert til "call_start_up" funksjonen, som gjør sin jobb ved å kalle opp av et par av de andre AOS funksjoner og deretter returnerer resultatet til den oppkallende oppsettingsfunksjon.

Et problem som er iboende i utviklingen av innbakte sann-tidssystemer, til hvilke telekommunikasjonssystemene tilhø-rer, går ut på at det alltid foreligger to datamaskiner. Det forekommer en vertsdatamaskin, vanligvis en VAX, IBM eller andre sammenlignbare datamaskiner, på hvilken programutvik-lingen finner sted, samt en måldatamaskin, f.eks. en APN eller APZ spesialisert prosessor som brukes i Ericsson AXE SPC telekommunikasjonssvitsjesystem, på hvilken programmene ut-føres i operasjonssystemet. Dette innebærer nødvendigvis at det vil gå lang tid mellom utvikling og editering av programmer på vertsmaskinen og testing av programmene på målmaskinen. Ved systemet ifølge den foreliggende oppfinnelse vil imidlertid disse aktiviteter være kombinert. Via noen manipulasjoner blir en linjegrensesnittsmodul ("LIM") styrt ved hjelp av en arbeidsstasjon og dennes datamaskin, og således blir funksjonene hos vertsmaskinen og målmaskinen kombinert slik at syklustiden for editering og utøvelse deretter i virkeligheten elimineres. Slik det er vist på figur 17, omfatter en konstruksjons/utøvelseskonfigurasjon en flerhet av fordeler.

Som vist på figur 18 omfatter en kjent arbeidsmodell et vesentlig stort antall trinn sammenlignet med systemet ifølge den foreliggende oppfinnelse. Det kan herfra ses hvordan trekkene rommes i et stort antall blokker 141 sammenlignet med den enkle symboloppgavemodul 142 som forekommer ifølge den foreliggende oppfinnelse. Således foreligger det en stor forenkling av trinnene vedrørende spesifikasjon og koding,

som fører til et endelig operasjonsdyktig programvaresystem.

Høyere programvarekvalitet er enda en annen fordel som skri-ver seg fra det foreliggende system. En flerhet av aspekter ifølge den foreliggende system er blitt implementert og testet for å bestemme deres konstruksjonseffektivitet i forhold til tidligere kjente telekommunikasjonssystemer. Resultatene av konstruksjonseffektivitetstestene er at det foreliggende system virker bedre enn det kjente system for hvert eneste testet trekk. Videre, i gjennomsnitt er den tid som kreves for å bruke det foreliggende system til konstruksjon, ut-øvelse, verifikasjon og dokumentasjon av et trekk, mye mindre enn den tid som kreves i forbindelse med det kjente system.

Disse effektivitetsfaktorer, sammenkoblet med det forhold at en konstruktør ikke trenger, ved det foreliggende system, å vente på en annen konstruktørs arbeid før han kan verifisere sin egen kode, innebærer at programvareutvikling kan finne sted i en planlagt og riktig ordnet sekvens. Det foreliggende system fremskaffer programvare med et klart hierarki omfattende individuelle, allerede verifiserte byggeblokker som gjør det lett å se og forstå hele systemet. Videre tillater det foreliggende system en kode å bli verifisert uavhengig og inkrementalt, og det fremskaffer verktøy for feilgjenvinning og for kodeanalyse. Som kort omtalt tidligere, vil en flerhet av personer som er involvert både når det gjelder konstruksjon og verifikasjon av trekkene, kunne reduseres til et eneste individ, hvilket innebærer redusering av ven-tetid og ledelsestid. Det foreliggende system muliggjør også planlegging og konstruksjonsverifikasjon til å kunne utføres før funksjonell testing.

Hovedfaktorene som gjør det interessant og likevel lett å konstruere trekkmoduler under anvendelse av systemet ifølge den foreliggende oppfinnelse, omfatter det faktum at den verbale tekst av den funksjonelle spesifikasjon tilsvarer koden i trekkmodulen, hvilket forbedrer forståelsen av både kode og trekk. Det skal dessuten forstås at programmer kan gjøres små og oversiktlige ved bruk av språkkvaliteter i likhet med tilpassede, listehåndterende og rekursive funksjoner. Konstruksjonen blir generert inkrementalt, og på en interaktiv måte, og tillater strukturert vekst. Kladding eller lapping blir derfor ikke nødvendig, eller til og med mulig, fordi programmer kan rekompileres på sparket. Repetert verifikasjon av et trekk eller av deler foregår derfor automatisk, dvs. bare ved testfilaktivisering, og data kan fremvises på et høyt symbolsk nivå. Dessuten er det ikke nødven-dig å ta kapasitetsproblemer under konstruksjonen med i betraktning fordi det foreligger atskillig færre dokumenter som skal skrives, og konstruktøren kan verifisere hele trekket før det blir frigitt for reelt bruk. Kvaliteten på programvaren blir i stor grad forbedret, noe som på sin side fremskaffer større tilfredsstillelse hos konstruktørene.

De fleste av de tidligere nevnte effektivitetsfaktorer gjelder også når ny funksjonalitet skal tilføyes til systemet. Tilføyelsen av funksjonalitet kan sammenlignes med tilføyel-sen av en ny trekkmodul til systemet. Denne trekkmodul kan enten inneholde fullstendig ny funksjonalitet som blir ad-dert til basissamtalemodulen, eller utgjøre en erstatning av allerede eksisterende funksjonalitet i trekkmodulen over basissamtalemodulen.

Mange av de tidligere omtalte effektivitetsfaktorer er også gyldige når det gjelder konstruksjon av et trekk i en forde-lingskonstruksjonsomgivelse. Den viktigste av disse innebærer det forhold at utvikling oppdeles i små og komplette trekkmoduler. Konstruktøren blir uavhengig av andre konst-ruktører når han skaper sitt trekk. Dessuten vil smale grensesnitt gjøre behovet for koordinering meget lite. Den eneste nødvendige innputt til trekkonstruktøren er den funksjonelle spesifikasjon, den aktuelle versjon av systembibliote-ket, samt applikasjonsoperasjonssystemverktøykassen. Sluttelig vil interaksjon mellom trekk, dvs. den orden som trekkene blir oppkalt i, bli løst ved operasjonsprosedyrer, og

interaksjonene kan testes i en eneste lokasjon.

Slik det fremgår ved eksaminering av de forskjellige aspekter ved systemet ifølge den foreliggende oppfinnelse, foreligger det en flerhet av fordeler iboende i både programvare språkstruktur en som muliggjør implementering av programva-reprototypen, så vel som i basisprogramvarearkitekturene for implementering av telekommunikasjonssvitsjesystemer. Videre vil det lett kunne ses at systemet på lett måte kan tilpasses andre prosess-styresystemapplikasjoner.

Det antas at virkemåten og oppbygningen av den foreliggende oppfinnelse er tilstrekkelig omtalt ved den forutgående beskrivelse. Selv om metoden, apparatet og systemet som vist og beskrevet er omtalt som foretrukket, så skal det forstås at forskjellige endringer og modifikasjoner kan utføres uten at man derved avviker fra den foreliggende oppfinnelses idé og område, slik oppfinnelsen er definert i de vedføyde pa-tentkrav.

Claims (5)

1. Telekonununikasjonsprogrammeringssystem for generering av et deklarativt program som skal lagres i et telekommunikasjonssystem og operere som en del av et prosesstyresystem, karakterisert ved at nevnte telekommunika-sj onsprogrammeringssystem omfatter: programmeringsmidler for å konstruere en telekommunikasjons-programvarearkitektur ved å benytte et deklarativt programmeringsspråk, nevnte programmeringsspråk omfatter: - et subjekt som er representert ved en prosess som inneholder handlinger, - et predikat, representert ved predikater i et deklarativt språk definert som diskré programprosedyrer, - et objekt som er representert ved data og fysiske enheter definert i symbolsk form, nevnte prosesstyresystem omfatter videre: - - et aksessmiddel for fysisk å aksessere nevnte telekommunikasjonsprogrammeringssystem via aksesslinjer.

2. Telekommunikasjonsprogrammeringssystem som angitt i krav 1, karakterisert ved at nevnte subjekt omfatter en sekvens av predikatet og er karakterisert ved handlingene den er i stand til å utføre.

3. Telekommunikasjonsprogrammeringssystem som angitt i krav 1, karakterisert ved at nevnte predikat er spesialisert til å brukes i forbindelse med bare et av nevnte subjekt.

4. Telekommunikasjonsprogrammeringssystem som angitt i krav 1, karakterisert ved at nevnte predikat er felles og tilgjengelig for bruk i forbindelse med hvilket som helst aktivt subjekt.

5. Telekommunikasjonsprogrammeringssystem som angitt i krav 1, karakterisert ved at nevnte objekt er implementert som en objektprosess som inneholder relaterte handlinger.