FI109069B - Ohjelmistorakenne tietoliikennekytkentäjärjestelmiä varten - Google Patents

Description

, 109069

Ohjelmistorakenne tietoliikennekytkentäjärjestelmiä varten

Keksinnön tausta

Osa tämän patenttiasiakirjan selityksestä käsittää materiaalia, joka on tekijänoikeussuojan alaista. Tekijänoikeuden haltijalla ei ole mitään sitä 5 vastaan, että patenttiasiakirjoja tai patenttiselitystä jäljennetään faksimilen avulla sellaisina, kuin ne ovat patentti- ja tavaramerkkivirastossa, patenttitieto-kannassa tai -arkistoissa, mutta muutoin kaikki oikeudet pidätetään.

Keksinnön ala

Keksintö liittyy tietoliikenteen kytkentäjärjestelmiin ja erityisesti 10 tietoliikenteen kytkentäjärjestelmiin tarkoitettujen prosessinohjausohjelmistojen kehittämiseen ja rakenteeseen.

Tekniikan tason kuvaus

Ohjelmiston arkkitehtuurirakenteiden ja sovellusohjelmien kehittäminen tallennetun ohjelman ohjaamia tietoliikenteen kytkentäjärjestelynä varten 15 on ollut historiallisesti mutkikas ja aikaa vievä tehtävä. Prosessi vaatii monia vaiheita ulottuen toteutettavien palveluiden toiminnan ja vuorovaikutuksen määrittelevien toiminnallisten spesifikaatioiden kehittämisestä itse reaali-aikaisen koodin testaamiseen laitteistossa, jossa järjestelmää on määrä .:· käyttää. Tällaisten ohjelmistoarkkitehtuurien kehittäminen on vaatinut myös 20 lukuisien eri kehittelijöiden, joista kukin työskentelee kehityksen eri kohteiden ··.·. parissa, vuorovaikutusta, joka vaatii monien toimintojen koordinointia kussakin vaiheessa kehitysprosessin kulussa. Uusien ohjelmistojärjestelmien tuominen markkinoille käyttäjän kysynnästä lähteneiden toimintojen ja piirteiden « · » *·’ * toteuttamiseksi on siten ollut hyvin kallista ja niin vaivalloinen ja aikaa vievä 25 prosessi, että siihen mennessä, kun järjestelmät on suunniteltu, kehitetty, testattu ja toteutettu kaupallisesti markkinoilla, käyttäjän tarpeet ovat usein muuttuneet vielä uudemmiksi vaatimuksiksi.

: Eräs tärkeimmistä näkökohdista minkä tahansa ohjelmisto- .··[ järjestelmän kehityksessä on järjestelmän konstruoinnissa käytettävän V 30 ohjelmointimenetelmän valinta. Tunnettuihin tekniikan tason ohjelmointi- • · · v : menetelmiin sisältyvät: prosessisuuntautunut ohjelmointi sellaisilla kielillä, ' · ’' · kuten "ADA" tai "PASCAL", oliosuuntautunut (objektisuuntautunut) ohjelmointi sellaisilla kielillä, kuten "C++" tai "SMALLTALK" ja deklaratiivinen ohjelmointi sellaisilla kielillä, kuten "PROLOG" ja "LISP". Mikään näistä kielistä ei sisällä 35 täyttä valikoimaa piirteitä, jotka ovat toivottavia tietoliikennekytkinohjelmiston 2 109069 kehittämisessä. Esimerkiksi prosessisuuntautunut ohjelmointikieli mahdollistaa ohjelmoitavan asian hyvän ymmärtämisen ja hyvän määrittelyn mutta antaa hyvin rajoitetun tuen strukturoinnille ja toimintojen ja predikaattien määrittelylle prosessissa. Kun suunnittelija ohjelmoi prosessissa olevia toimintoja, häntä 5 vaaditaan antamaan suuri määrä yksittäisiä yksityiskohtia sovellusohjelmistoon. Samalla tavoin, kun ohjelmointikielten PASCAL/ADA-sukupolvi toisaalta antaa jonkin verran tukea datan määrittelylle ja käsittelylle, ohjelmoijalta vaaditaan edelleen suurta työmäärää yksityiskohtatasolla, jolla on hyvin vähän tekemistä itse tuotettavan todellisen sovelluksen kanssa.

10 Myös viimeisimmillä oliosuuntautuneilla ohjelmointimenetelmillä on rajoituksensa. Nämä oliosuuntautuneet ohjelmointimenetelmät ovat keskittyneet erilaisiin menetelmiin määritellä ja periyttää objekteja sekä siihen, kuinka dokumentoida objekteja. Vaikka nämä menetelmät auttavat merkittävästi siinä tapauksessa, että kehitetään ohjelmia, jotka käsittävät 15 suuren määrän määriteltäviä ja käsiteltäviä objekteja, esiintyy monia selvyyteen ja rakenteeseen liittyviä ongelmia, kun ohjelma itse määritellään objektiksi.

Prosessinohjausohjelmissa, esimerkiksi tietoliikennejärjestelmiin tarkoitetuissa, ohjelmakokonaisuus on kuitenkin aina subjekti, joka toimii ja | ·:· 20 suuntaa toimintaa järjestelmässä. Tietoliikenteen prosessinohjausjärjestel- ! ; v; mässä objektit ovat kahta perustyyppiä: (1) Kaikilla tällaisilla ohjelmajärjestelmillä on sisäiset objektit, jotka ,··,·. on määritelty sen datan suhteen, jonka pohjalta ohjelmat toimivat. Nämä objektit ovat ohjelmistojärjestelmien todellisuutta, ja data on staattinen kuva v ’ 25 reaalimaailmasta, jota ohjelmat muokkaavat.

(2) Kaikki reaaliaikaiset järjestelmät ja prosessinohjausjärjestelmät :. 'i toimivat kuitenkin myös pohjautuen ja vaikuttaen dynaamisiin objekteihin ohjelmajärjestelmien ulkopuolella. Esimerkkejä tällaisista dynaamisista : objekteista ovat kuvat näyttöruudulla tai puhelimet tai yhdysjohdot tieto- .*••,30 liikennejärjestelmässä. Nämä ohjelmajärjestelmät sisältävät myös dynaamisia objekteja dataobjektien edustamina.

v : Oliosuuntautuneen ohjelmoinnin menetelmä kapseloida toimintoja yhdessä datan kanssa ja määritellä kaikki tämä objektiksi, on selvä etu, jos ohjelma on rutiini, joka liittyy läheisesti sen objekteihin. Esimerkkejä tällaisista 35 rutiineista löytyy näyttökuvapinnan esitysjärjestelmistä samoin kuin tieto- 3 109069 liikennejärjestelmän linjaliitäntäosista. Jos ohjausohjelmat tällaisessa prosessinohjauksen ohjelmistojärjestelmässä määritellään kaikki objekteiksi, tuotetaan kuitenkin tiettyjä negatiivisia vaikutuksia. Ensinnäkin ohjausohjelmista tulee rikkonaisia, ja hyvin mutkikkaat vuorovaikutukset ja 5 suhteet objektien välillä tulevat välttämättömiksi. Tällainen tulos vaatii päällysohjausrakenteen, ja tunnetuissa olioperustaisissa tietoliikennejärjestelmissä mutkikkaita CCITT:n spesifikaatiosuunnittelukielen (SDL) vuokaavioita on vaadittu kuvaamaan tällaisia ohjausrakenteita. Lisäksi dynaamiset suhteet objektien välillä ovat silti hyvin vaikeita kuvata ja 10 ymmärtää myös käytettäessä tällaisia vuokaavioita. Toiseksi, kun mitään kokonaisuuksia ohjausohjelmistojärjestelmässä ei määritellä subjektiksi, mistä tahansa selittävästä mallista tulee luonnostaan puutteellinen. Ohjelman toiminnot, toisin sanoen sen predikaatit, tulevat niputetuiksi yhteen objektien kanssa tehden siten sekä objekteista että toiminnoista hyvin vaikeasti 15 paikallistettavia. Tämä tekee miltei mahdottomaksi prosessinohjausjärjes-telmässä olevien toimintojen organisoimisen loogisiksi ryhmiksi. Lisäksi suunnittelijat eivät pysty strukturoimaan sovelluksia luonnollisella tavalla, joka olisi hyvin ymmärrettävissä kenelle tahansa, joka tarkastelee organisointia, ja jonka kanssa suunnittelijoiden olisi helppo työskennellä.

··· 20 Deklaratiivisten ohjelmointikielten viimeisin sukupolvi, kuten esimer- ; *. . kiksi PROLOG ja LISP, on hyvin tehokas ja vähentää ohjelmistosuunnittelun ja ohjelmoinnin työtä, koska: (a) kaikki ohjelmointi voidaan tehdä symbolisessa muodossa ja (b) predikaattien käsite ja kokonainen uusi sarja tehokkaita käskyjä on sisällytetty noihin kieliin. Tällaisten kielten käyttö vähentää ’ 25 dramaattisesti sekä niiden yksityiskohtien määrää, joista ohjelmoijan tarvitsee huolehtia, että ohjelman kapseloinnin tärkeyttä. Todellinen haitta :.*‘i deklaratiivisten kielten käytössä prosessinohjaukseen tai reaaliaikaisiin järjestelmiin, kuten tallennetun ohjelman ohjaamiin tietoliikenteen kytkentä-: järjestelmiin, on niiden riittämätön reaaliaikainen suoritustehoja niiden kyvyttö- .···’ 30 myys käsitellä rinnakkaisuutta.

Monia uudemmista deklaratiivisista tai oliosuuntautuneista ohjel-: mointikielistä on käytetty antamaan ohjelmoijille mahdollisuus suorittaa ”**· toimintojen tai ohjelmien nopea prototyypinkehittely. Nopeilla proto- tyypinkehittelymenetelmillä on lukuisia tunnustettuja etuja, jotka ovat lähtöisin 35 siitä, että pystytään suunnittelemaan ja kehittelemään sovellusta tai 4 109069 järjestelmää lisäystyyppisesti. Mahdollisesti kalliit suunnitteluvirheet voidaan havaita ja korjata aikaisemmin kehitysprosessissa, järjestelmän yksittäiset puolet voidaan toteuttaa ja testata hyvin nopeasti, pitkät testaus- ja/tai toteutusvaiheet voidaan välttää ja nopea prototyypinkehittely antaa 5 suunnittelijoille mahdollisuuden tutkia lukuisia vaihtoehtoja suhteessa sovellukseen tai toimintoon. Myös monia muita etuja prototyypinkehittelyä ajatellen on nähtävissä.

Nopeilla prototyypinkehittelymenetelmillä on etuja myös tietoliikennejärjestelmien yhteydessä. Tähän asti menetelmillä on kuitenkin 10 ollut useita haittapuolia johtuen tietoliikennejärjestelmissä esiintyvien käsittelytapahtumien reaaliaikaisuudesta ja näiden operaatioiden rinnakkaisesta luonteesta. Keksinnön järjestelmä sisältää tiettyjä puolia, jotka laajentavat aikaisemmin tunnettuja prototyypinkehittelymenetelmiä ja kykyä siihen, että nopeaa prototyypinkehittelyä voidaan käyttää tehokkaasti tieto-15 liikennejärjestelmien yhteydessä. Prototyypinkehittelymenetelmien kokeiluja tietoliikennejärjestelmien yhteydessä on kuvattu julkaisussa "Using Prolog for Rapid Prototyping of Telecommunication Systems", J.L. Armstrong ja M.C. Williams, Seventh International Conference on Software Engineering for Telecommunication Switching Systems, July 3-6, 1989, Bournemouth, sekä ·:· 20 julkaisussa "Experiments with Languages and Techniques for Tele-;v. communications Applications", B. Dacker, N. Elshiewg, P. Hedeland, C-W Welin, M. Williams, Sixth International Conference on Software Engineering J·.·. on Telecommunication Switching Systems, April 14-18, 1986, Eindhoven, jotka näin liitetään tähän selitykseen viittauksella.

' 25 Deklaratiivisen ERLANG-kielen kehittäminen on olennaisesti ratkaissut nämä ongelmat mahdollistaen prosessinohjauskonseptin tuomisen :.’*i deklaratiivisten kielten maailmaan. ERLANG-kielen perusteet on kuvattu • · · artikkelissa "ERLANG: An Experimental Telephony Programming Language", .·. : Proceedings, XIII International Switching Symposium, Voi. Ill, s. 48 (1990), , * · ‘ 30 joka näin liitetään tähän selitykseen viittauksella. Yksityiskohtaisempi käsittely löytyy julkaisuista "Erlang User's Guide and Reference Manual" ja "Erlang BIF * Guide", jotka on sisällytetty tähän liitteenä A. Tämän kielen käyttö mahdollistaa reaaliaikaisten prosessinohjausohjelmistojärjestelmien konstruoinnin keksinnön järjestelmän mukaisesti.

35 5 109069

Keksinnön yhteenveto

Keksinnön kohteena järjestelmä sisältää deklaratiivisen kieli-rakenteen, joka on tarkoitettu käytettäväksi prosessinohjausjärjestelmien, kuten esimerkiksi tietoliikennekytkentäjärjestelmien, ohjelmoinnissa. Kielira-5 kenne sisältää luonnollisen kielen elementtejä mukaan lukien subjektin, jota edustaa toimintojen prosessi, predikaatin, jota edustavat ohjelmaprose-duureiksi määritellyt deklaratiivisen kielen predikaatit, ja objektin, jota edustavat data ja tosimaailman oliot määriteltyinä symbolisessa muodossa ja objektiprosesseihin sisältyvinä.

10 Kuten tämän erikoisalan tavallinen ammattilainen helposti havait see, keksinnön periaatteita ja kohteita voitaisiin käyttää hyväksi muissa ohjelmistojärjestelmissä ja lukuisissa muissa tietokone- ja prosessinohjaus-sovelluksissa tietoliikenteen kytkentäjärjestelmien lisäksi.

Piirustusten lyhyt kuvaus 15 Keksinnön ja sen muiden tarkoitusten ja etujen ymmärtämiseksi viitataan nyt seuraavaan kuvaukseen yhdessä liittyvien piirustusten kanssa, joista: kuvio 1 on lohkokaavio, joka kuvaa keksinnön järjestelmän sovelta-mistä tietoliikenteen kytkentälaitteiden ohjaukseen tarkoitetun prototyyppi-20 ohjelmiston kehittämiseen, • ·«· ·♦.·. kuvio 2 on prototyyppiohjelmiston kehittämisessä käytettyjen vaihei- den lohkokaavio, . ! kuvio 3 on vuokaavio, joka kuvaa keksinnön järjestelmän mukaista ohjelmiston kehittämistä, *·’ * 25 kuvio 4 on vuokaavio, joka kuvaa keksinnön mukaisen tietoliikenne ohjelmiston kehityksen palveluaspektien spesifiointia, • » kuvio 5 on vuokaavio, joka kuvaa keksinnön mukaisen tietoliikenne-* ” ’: ohjelmiston kehityksen toiminnallisten verkkoaspektien spesifiointia, , · ’ ; kuvio 6 on lohkokaavio, joka esittää toiminnallisten kokonaisuuksien 30 kuvaamista keksinnön mukaisesti toiminnallisesta spesifikaatiosta ohjelmisto-'; · järjestelmärakenteeseen, : kuvio 7 on lohkokaavio, joka esittää toiminnallisten kokonaisuuksien ·:·: kuvaamista verkon tapauksessa keksinnön mukaisesti spesifikaatiosta ohjel mistojärjestelmään, 6 109069 kuvio 8 on lohkokaavio, joka kuvaa tietoliikenteen kytkentäjärjestel-mään tarkoitetun, keksinnön mukaisesti konstruoidun ohjelmiston kokonaisarkkitehtuuria, kuvio 9 on lohkokaavio, joka kuvaa keksinnön tietoliikenneohjel-5 mistojärjestelmän arkkitehtuuria, kuvio 10 on lohkokaavio, joka kuvaa tapaa, jolla käyttäjämoduulin liikenneosa rakennetaan hierarkkisesti keksinnössä, kuvio 11 on lohkokaavio, joka kuvaa vaihtoehtoisesti datankäsittely-toimintaa keksinnön ohjelmistojärjestelmän arkkitehtuurissa, 10 kuvio 12 on lohkokaavio, joka kuvaa keksinnön puheluosapuolen erotusaspektia, kuvio 13 on lohkokaavio, joka kuvaa puheluosapuolten vuorovaikutusta esillä olevassa järjestelmässä, kuviot 14-16 ovat piirroksia, jotka kuvaavat toiminnallisten piirtei-15 den toteutuksen eri aspekteja esillä olevassa järjestelmässä, kuvio 17 on lohkokaavio, joka esittää kokonaiskehitysympäristöä, jossa esillä oleva prototyypinkehittelyyn tarkoitettu järjestelmä voi toimia, sekä kuvio 18 on lohkokaavio, joka kuvaa tiettyjä eroja keksinnön järjes-telmän ja tiettyjen muiden tunnettujen järjestelmien välillä.

•:. 20 Yksityiskohtainen kuvaus ··.·. Keksinnön järjestelmä käsittää ohjelmointikielen rakenteen, joka on sovitettu erityisesti käytettäväksi reaaliaikaisten prosessinohjausjärjestelmien, ; kuten tietoliikennejärjestelmien, ohjelmistoissa. Keksintöä tarkastellaan alla sen teoreettisen ja teknologisen perustan suhteen samoin kuin tarkastellaan * * * ' 25 sen käyttöä käytännössä toteutetussa toimivassa ohjelmistojärjestelmässä. Ohjelmiston konstruoinnin metodologia • ·

Kuten edellä on todettu, kukin hyvin tunnetuista ohjelmointimenetel-mistä, prosessisuuntautunut ohjelmointi, oliosuuntautunut ohjelmointi ja : deklaratiiviseen kieleen perustuva ohjelmointi, sisältää tiettyjä niille ominaisia 30 haittoja, kun sitä sovelletaan reaaliaikaiseen prosessinohjausympäristöön, » · kuten esimerkiksi sellaiseen, joka esiintyy tietoliikenteen kytkentä-järjestel-: missä. Keksinnön järjestelmässä käytetyt ohjelmoinnin konstruointi- menetelmät tällaisille reaaliaikaisille prosesseille sisältävät kyvyn käsitellä reaaliaikaista toimintaa ja suoritusta sekä toimintojen rinnakkaisuutta käyttä-35 mällä karkeaa deklaratiivista kieltä, jossa on uusi kielenkonstruointimenetelmä, 7 109069 tuottamaan selviä ja helposti ymmärrettäviä sovellussuuntautuneita ohjelmisto-arkkitehtuureja.

Keksinnön järjestelmän kielenkonstruointimenetelmälle on tunnusomaista kolmen luonnollisen kielen elementin, subjektin, predikaatin ja objektin 5 käyttö. Subjektia edustaa toimintojen prosessi, kun taas predikaattia edustavat ohjelmaproseduureiksi määritellyt deklaratiivisen kielen predikaatit. Objektia edustavat data ja reaalimaailman oliot, kuten tietoliikenneyhdysjohdot ja puhelimet, jotka kaikki määritellään symbolisessa muodossa ja sisältyvät objektiprosessiin. Esillä oleva menetelmä ei ainoastaan mahdollista sitä, että 10 ohjelmistosuunnittelija keskittyy konstruoitavassa sovellusrakenteessa olevien eri kokonaisuuksien määrittämiseen, vaan se rohkaisee siihen voimakkaasti. Ihmisen kielen kolmen peruselementin käyttö mahdollistaa sellaisen mallin luomisen, joka ei ole ainoastaan tehokas vaan myös selvä ja helposti ymmärrettävä. Lisäksi esillä oleva kielen rakenne voidaan nähdä myös 15 aktiivisten subjektien paradigmana ("PACS").

Esillä olevassa järjestelmässä subjekti määritellään predikaattien sekvenssiksi tai useiksi sekvensseiksi, ja sille ovat tunnusomaisia toiminnot, jotka se pystyy suorittamaan. Tämä antaa tehokkaan mekanismin kaikkien toimintojen strukturoimiseen ryhmiksi, jotta voidaan muodostaa luonnollisia ja « .:. 20 helposti ymmärrettäviä kokonaisuuksia ohjelmistoon. Prosessikonseptin käyttö * V, ratkaisee suuren määrän reaaliaikaisuuden ongelmia, ja se tukee lisäksi kielen ; "subjekti-elementin" tuomista tietokoneohjelmointikielten konstruointiin. Esillä j. ;* olevassa järjestelmässä subjektiprosessi nimetään ja spesifioidaan sen I · | •‘ ·/ toimintasisällön suhteen samalla tavoin kuin yksilöt, kuten muurarit, asentajat v : 25 tai kirvesmiehet, nimetään ja määritellään reaalimaailmassa. Tämä mahdollistaa toimintojen välisten suhteiden luonnollisen määrittelyn. Esimerkiksi V*i vaiheohjelmistojärjestelmässä tämä aspekti tunnetaan palveluvuoro-vaikutuksena, josta esillä olevan metodologian käytössä tulee subjektimääritte- . lyn luonnollinen osa. Oikeiden subjektien määrittelemiseksi sovellusta tai » · · 30 palvelua varten tarvitaan kuitenkin todellisen sovelluksen perinpohjainen * * ’;·* tuntemus. Subjektikonsepti tukee myös pyrkimystä siirtää ohjelmistokehityksen polttopistettä alatason toteutusyksityiskohdista kohti kokonaissovelluksia ja ·:··: ratkaisuja käyttäjän määrittelemiin ongelmiin.

Subjekteja voidaan esillä olevassa järjestelmässä määritellä kaikilla 35 muilla paitsi alimmalla abstraktiotasolla suunnittelijan käsitteellistäessä 8 109069 kehitettävää järjestelmää tai sovellusta. Korkeimmalla abstraktiotasolla on subjekti, joka määrittelee ja purkaa järjestelmän koko toiminnan. Korkeimman tason subjekti, joka antaa järjestelmälle kokonaisohjaussekvenssin ja kulun, on sukua pääohjelmalle tai -rutiinille, jota käytetään perinteisissä ohjelmointi-5 kielissä. Keksinnön järjestelmän tässä kohteessa subjektit sisältävät subjektin, predikaatin ja objektiprosessien sekvenssin tai ainoastaan predikaatin ja objektiprosessien sekvenssin täyden sarjan toimintoja, jotka muodostavat osan tuosta subjektista, määrittelemiseksi.

Esimerkkeihin funktioista tai toiminnoista, jotka voitaisiin määritellä 10 subjekteiksi esillä olevassa järjestelmässä, sisältyvät niihin rajoittumatta: (a) tietoliikenteen kytkentäjärjestelmän aktivointi ja (b) sen kysyminen tietoliikennejärjestelmältä, mitä palveluita järjestelmässä on käytettävissä. On ymmärrettävä, että subjekti, joka määritellään useiden predikaattisekvenssien sekvenssiksi, voitaisiin tulkita toiminnoiksi tai ohjauskuluiksi piirremoduulin, 15 joka käsittelee piirteen tiettyä aspektia, käyttäjäosassa. Välittömästi tämän jälkeen esitetty on näytejakso "pseudokoodia", jota voitaisiin käyttää keksinnön järjestelmässä subjektin määrittelyyn.

• • i * « i t » * · ♦ • · « t • * « * · • · « I » t » · • * ' · · • * * » · * · « » * f · * » t • * • · s t < · I » » 9 109069 CSubject Definition> <Export/Import Predicate Declarations> <Description of the Interface> <Initiation Part> <Initiation of.default data, user procedures, test procedures, used user suffixes and timers, e.g.> 5 CUser sequences, PACS step 1 > ACTIVATION, DEACTIVATION and

REGISTRATION

activate (FromUser.UserState,UsersParticipated,UserData)-> <activate predicate 1> <common predicate x> ,|q <activate predicate N> <deactivate(FromUser,UserState,UsersParticipated, UserData) -> <common predicate y> <deactive predicate x> <common predicate N> 15 register(FromUser,UserState,UsersParticipated,UserData) -> <register predicate 1> <common predicate z> <register predicate N> • .:. 20

J**' CUser sequences, PACS step 1 > INTERROGATION

; interrogate(FromUser,UserState,UsersParticipated,UserData) ->

Cinterrogate predicate 1> : ·' Ccommon predicate z> : 25 Cinterrogate predicate N>

j’.J CUser sequences, PACS step 1 > INVOCATION

*t>* userInvocation(UserState, InteractingState,UsersParticipated,

UserData) -> • ^ Ccontinue in user 1 operation> .... 30 interactingInvocationl(UserState, InteractingState,

UsersParticipated,UserData) -> ... Ccontinue in user 2 operation> ....: interactingInvocation2(UserState, InteractingState,

UsersParticipated,UserData) ->

Ccontinue in user 3 operation> 35 109069 CUser sequences, PACS seep 1> OPERATION CUSER 1, PACS seep 2> user 1(UserSCate,InteractingsCate,UsersParCicipaced,UserData)-> <user 1 predicate 1> (common predicate x> (user 1 predicate N> 5 CUSER 2, PACS step 2> user2(UserState, Inter actingState,UsersParticipated,UserData)-> (user 1 predicate i> (common predicate x> 10 (user 1 predicate N> CUSER 3, FACS step 2> user2(UserSTate,InteractingState,UsersParticipated,UserData)->

Cuser 1 predicate 1>

Ccommon predicate x> 15

Cuser 1 predicate N> CUser sequences, PACS step 1 ^EXCEPTIONS . ·.. aecivationException(UserScate,InteractingStace, . . UsersParticipated.UserData) ->

CactivacionException predicate 1>

Ccommon predicate x> • · • · · [ CactivacionException predicate N> *·* * 25 deactivationException(UserState,InteractingState,

UsersParticipated.UserData) -> . . CdeactivationException predicate 1> ·. ·; Ccommon predicate y> ,·, ; CdeactivationException predicate N> ® 1991 Telefonaktiebolaget L M Ericsson „ 109069

Subjektien käyttämät predikaatit määritellään keksinnön järjestelmässä joko peruskäskyillä tai muodostamalla uudet predikaatit määrittelemällä ohjelmarutiinit, joihin viitataan proseduureina. Kukin proseduuri voi olla jollekin erityiselle subjektille erityinen ja yksinomainen tai se voi olla yleistetty, ja 5 monet eri subjektit voivat sitä käyttää. Kullekin proseduurille on myös luonteenomaista sen toiminta. Proseduurien käyttö predikaatteina kerrostetussa arkkitehtuurissa deklaratiivisessa kielessä johtaa virtuaalisesti rajoittamattomaan mahdollisuuteen kohottaa abstraktiotasoa ja kasvattaa ylätason kielen tehoa. Eräänä perussääntönä, jota tulisi käyttää suunnitelit) taessa tämäntyyppistä järjestelmää, tulisi olla proseduurien lukumäärän pitäminen riittävän pienenä, niin että pidetään järjestelmä helposti ymmärrettävänä ja hallittavana. Predikaatin tulisi olla tarkasteltavissa diskreettinä proseduurina, esimerkiksi numeroanalyysinä. Vaikka predikaatti voi suorittaa mutkikkaan tehtävän, sen täytyy aina olla hyvin selvä. Alimmalla 15 tasolla predikaatti voisi käsittää niinkin vähän kuin yhden ainoan deklaratiivisen kielen lauseen. Tulisi myös ymmärtää, että keksinnön kieli-rakennekohteessa käytetyt predikaatit esitetään predikaatteina deklaratiivisessa kielessä ja määritellään ohjelmaproseduureina sovelluksen ; ’ *.. käyttöjärjestelmässä (AOS).

’ ·:· 20 Esillä olevaa menetelmää voidaan verrata tunnettuun C++-tapaan ;v: varustaa koko ohjelma tai osa ohjelmasta perimyksellä. Siinä tapauksessa kuitenkin sekä reaalisia objekteja että predikaatteja kutsutaan objekteiksi, ja J·.·, toiminnot tai predikaatit sidotaan aina läheisesti todellisiin objekteihin. Tämä \.I tehdään C++:ssa kapseloinnin aikaansaamiseksi. Tarve kapseloinnille ei *·’ ' 25 kuitenkaan ole läheskään yhtä tärkeä käytettäessä deklaratiivisia kieliä kuin käytettäessä oliosuuntautuneita kieliä. Toimintojen heikko sitoutuminen objek-:. ’i teihin, kuten C++:ssa, on suuressa määrin vastakkaisesti vaikuttava helposti ymmärrettävän toiminnallisen rakenteen tuottamiselle. Esillä oleva menetelmä .·. : toisaalta mahdollistaa ainoastaan predikaattien tai toimintojen perimyksen, .*··! 30 mikä tukee selvän toiminnallisen rakenteen luomista. Toiminnalliset rakenteet ovat sitten helppoja ymmärtää, ja tämä on aina hyvin tärkeää prosessinohja-: uksen ohjelmistojärjestelmien konstruoinnissa.

Keksinnössä objekti määritellään prosessina, joka sisältää dataa ja/tai reaalimaailman olioita symbolisessa muodossa niputettuina yhteen niihin 35 läheisesti liittyvien toimintojen kanssa. Tämä tekee mahdolliseksi sisällyttää 12 109069 objektiprosessiin mitkä tahansa toiminnot, jotka ovat objektiin läheisesti sidottuja eivätkä ole elintärkeitä predikaattien loogiselle rakenteelle. Tällaiset rutiinit sisältävät esimerkiksi rutiinit ulkoisten objektien tilan skannaamiseksi, laskentarutiinit, jotka suoritetaan aina tietylle objektille, ja rutiinit jonkin asian 5 näyttämiseksi kuvapinnalla. Oliosuuntautuneiden menetelmien, kuten C++:n, pääasiallista etua käytetään siten hyväksi esillä olevassa järjestelmässä. On kuitenkin hyvin tärkeää, että subjekteja ja objekteja ei sekoiteta keskenään, koska ne on molemmat toteutettu prosesseina. Prosessi on toteutus-teknologia, ja subjektit, predikaatit ja objektit ovat kaikki prosessiolioita 10 sovellusarkkitehtuurissa. Jos rutiini ei ole kytketty tiukasti dataobjektiin, se tulisi erottaa predikaattiprosessiksi. Perimykseen ja muiden objektien sisällyttämiseen käytettyjä menetelmiä voidaan tuoda mukaan tarvittaessa, kuten tässä teknologiassa on hyvin tunnettua. Niinpä, jos predikaatti on suuri tai mutkikas, se tulisi strukturoida sen sijaan subjektiksi.

15 Tulisi myös ymmärtää, että datan ja reaalimaailman olioiden edustama aspekti keksinnön kielenkonstruointikohteessa voidaan tulkita liittymäosaksi. Siinä yhteydessä käyttäjäosa suorittaa predikaatin tai proseduurin, joka on käsky liittymäosalle suorittaa erityinen tehtävä. Tämä käsky ei ole riippuvainen siitä, kuinka todellinen reaalimaailman olio on ' ··♦ 20 suunniteltu. Toisin sanoen käsky voisi olla informoida liittymää puhelun todellisista ehdoista, esim. tuleva puhelu, kutsuvan tilaajan numero, esim.

12 345, ja tulevan puhelun osapuolen kategoria, esim. puhelunvälittäjä. Jos j-.i' liittymä on analoginen alaliittymä, niin todennäköisesti olisi mahdollista ainoastaan kehittää soittosignaali tuossa liittymämuodossa. Jos liittymämuoto ‘‘’25 kuitenkin on toimiennepuhelin, ja siinä on näyttö, niin numero 12 345 voitaisiin näyttää näytöllä yhdessä mahdollisen puhelunvälittäjäkategorian osoittamisen kanssa.

Keksinnön ohjelmistorakennemetodologia tukee voimakkaasti . ·. : ohjelmistosuunnittelijoiden ja ohjelmoijien siirtymistä pois toteutuksen yksityis- ,···[ 30 kohdista kohti lisääntyvää tietämystä sovelluksesta itsestään ja siihen keskittymistä. Se mahdollistaa selvien ja helposti ymmärrettävien sovellus-v · suuntautuneiden ohjelmistoarkkitehtuurien luomisen myös silloin, kun sovellukset pitävät sisällään hyvin mutkikkaita prosesseja ja logiikkaa. Keksinnön menetelmä tekee ohjelmistosta helposti hallittavan ja korjattavan 35 lisäämällä toimintoja.

13 109069

Parannettu prototyypinkehittelyteknologia tietoliikennekytkentäjärjestel-missä käytettäväksi tarkoitetun ohjelmiston kehittämistä varten

Keksinnön järjestelmää voidaan käyttää tietoliikenteen kytkentä-järjesteimiin tarkoitettujen tekniikan tason ohjelmistoarkkitehtuurien 5 kehittämiseen ja arvioimiseen sekä erityisesti käyttökelpoisen prototyypin-kehittelyperustan tuottamiseen uusien sovellusten ja laajennusten kehittämiseksi tällaisiin ohjelmistoihin. Esillä olevassa järjestelmässä käytetty ohjelmointiparadigma on deklaratiivisen ohjelmoinnin paradigma, kuten edellä esitettiin, ja käytetty käyttöjärjestelmä on sovitettu erityisesti tukemaan 10 tietoliikennesovelluksia. Käyttöjärjestelmä on esimerkiksi laajennettu sisältämään puhelukohtainen vianoikaisu.

Tietoliikenteen kytkentäohjelmiston kehittämisestä on tulossa enemmän ja enemmän markkinoiden ohjaama. Yhä useammin sovellus-asiantuntijat tulevat mukaan ohjelmistoarkkitehtuurin suunnitteluun myynti-15 piirteiden käsittelyn yksinkertaistamiseksi kautta koko kehittelyketjun. Toisin sanoen tuotespesifikaatioissa olevat piirteet kuvataan todellisiin piirre-moduuleihin ohjelmistoarkkitehtuurissa. Tämä tuo itse asiassa markkinalähtöisen lähestymistavan ohjelmiston kehittämiseen.

Tietoliikenteen kytkentäjärjestelmien arkkitehtuuriin ja kytkentä- * ··· 20 järjestelmien ohjelmiston prototyypinkehittelyyn kietoutuu hyvin mutkikkaiden ongelmien ratkaiseminen, ja se edellyttää välttämättä käytännön koetulosten : ·. verifiointia aikaisessa vaiheessa. Prototyypinkehittely on jaettu jaksoihin, joista kullakin on omat määritellyt tavoitteensa, jolloin yksi jakso sisältää rajoitetun määrän piirteitä, jotka toteutetaan täysin, ja kukin sen jälkeen seuraava jakso ’·* ’ 25 tuo mukaan uusia piirteitä. Tällaiset prototyypit edustavat todellisia järjestelmiä, vaikka ne ovat toiminnaltaan rajoitettuja. Prototyypeillä voi olla reaaliaikaisia piirteitä ja ohjelmisto-ominaisuuksia, jotka ovat verrattavissa todelliseen tuotteeseen. Ne muodostavat vakaan perustan uusien prototyyp-. ·. : pien rakentamiselle ja käyttöohjelmiston toteuttamiselle.

,··* 30 Prototyypinkehittelyprosessi on hyvin tärkeä vaihe koko toiminta- mallin valmistelussa ja mahdollistaa sen, että suunnittelijat tekevät käyttäjästä huomion pääasiallisen keskipisteen. Kuviossa 1 on esitetty lohkokaavio, joka "*·" kuvaa prosessia, jossa ehdotetun järjestelmän käytettävyyttä 21 arvioidaan lähtien käyttäjien tutkimuksesta ja heidän vaatimuksistaan 22, mitä seuraa 35 käyttäjärajapinnan simulointi/testaus 23, joka antaa prototyypin ensimmäiset „ 109069 14 ke h ittely p u i tteet. Seuraavaksi toteutetaan itse prototyypinkehittelyprosessi 24.

Tämä prosessi käyttää hyväksi uutta ohjelmistoteknologiaa 25 uusien sovellutusten 26 prototyypinkehittelyyn, jotta kehitetään perusteellisesti tarkastellut vaatimusspesifikaatiot tuotekehittelyä 28 varten sekä kelvolliseksi 5 todettujen annettavien tietojen tuottamiseksi standardointiorganisaatioille 27. Aikaansaatuna lisäetuna on, että nämä prototyypit voidaan suhteellisen vähäisin ponnistuksin kehittää lopulliseksi toimivaksi tuotteeksi.

Käytännössä uusien sovellusten tai piirteiden prototyypit suunnitellaan, toteutetaan ja sitten testataan yhteistyötä tekevän käyttäjän luona.

10 Todellinen toimintamalli prototyypin konstruoimiseksi on esitetty kuviossa 2, ja lopulliselle mallille on tunnusomaista kunkin piirteen rajaaminen piirre-moduuliin. Kuvio 2 kuvaa vastaavia dokumentteja, jotka täytyy tuottaa spesifioinnin ja suunnitteluvaiheiden aikana, joihin dokumentteihin sisältyy piirrespesifikaatio 31, joka käsittää sekä toiminnallisen spesifikaation 32 että 15 testausspesifikaation 33. Piirrespesifikaatiosta 31 tullaan piirteen suunnitteluja verifiointivaiheeseen 34, joka sisältää rakenteellisen spesifikaation 35, useiden deklaratiivisen kielen moduuleiden 36 ja verifikaatiomoduulin 37, jota I käytetään tuottamaan verifiointiloki 38, laatimisen. Lopuksi käynnistetään ja . ’ ·.. suoritetaan loppuun järjestelmätestausvaihe 39.

’ 20 Viitaten seuraavaksi kuvioon 3 siinä on esitetty vuokaavio, joka kuvaa yleiskatsauksena useita vaiheita esillä olevan järjestelmän mukaisessa ·,·,·. prototyyppiohjelmiston kehityksessä. Kuten edellä on osoitettu, aloitustehtävä !. ! prototyyppiä tuotettaessa on laatia spesifikaatio. Kohdassa 41 käytetään CC ITT: n standardiproseduureissa määritellyn kolmivaiheisen metodologian ’♦' * 25 ensimmäistä vaihetta. Tarkemmin sanoen nämä menetelmät on esitetty CCITT-spesifikaatioissa 1.130 (Method for Characterization of Tele- • · communications Services), Q.65 (Detailed Description of Stage 2) ja 1.310 (ISDN Network Functional Principles), joista kukin näin liitetään tähän : viittauksella. Tällä aloitusvaiheella saadaan aikaan sovelluksen yleiskuvaus tai 30 spesifikaatio käyttäjän näkökulmasta. Seuraavaksi kohdassa 42 laaditaan edellä esitettyyn deklaratiiviseen kielirakenteeseen sisällytettävien eri v : subjektien karkea layout kullekin käyttäjälle. Tämä pitää sisällään sekä lähtö- ·:··: että päätekäyttäjäsekvenssien, jotka muodostavat todelliset subjektit, spesifioinnin. Sen jälkeen kohdassa 43 järjestelmä suorittaa toisen spesifiointi-35 vaiheen, edellä nimetyissä CClTT-proseduureissa esitetyn kolmivaiheisen 15 109069 metodologian vaiheen 2, joka käsittää toiminnallisten kokonaisuuksien identifioinnin. Seuraavaksi vaiheessa 44 toiminnalliset kokonaisuudet kuvataan, ja yksittäiset ja yleiset predikaatit identifioidaan edellä esitetyn deklaratiivisen kielen lähestymistavan mukaisesti. Tässä vaiheessa käyttäjäsekvenssit esite-5 tään subjekteissa, ja eri toiminnot strukturoidaan ja/tai ryhmitetään luonnollisella ja helposti ymmärrettävällä tavalla. Lopuksi kohdassa 45 kukin reaalimaailman olioista esitetään objektina. Esimerkiksi liittymäsekvenssit esitetään käyttäen objekteja, vaikka ne voivat olla sisäisesti subjekteiksi strukturoituja.

10 Keksinnön prototyypinkehittelymenetelmän selittämiseksi edelleen kuvio 4 kuvaa toiminnallisen spesifikaation palveluaspektin vaiheen 1 spesifiointia. Tämä on proseduuri, jossa laaditaan yleiskuvaus käyttäjän näkökulmasta. Kuten kuviossa 4 on esitetty, palvelu voi jo olla erityisessä tilassa 51, ja vasteena käyttäjäkyselylle 52 se voi vaatia funktionaalisen toiminnon 53.

15 Tuloksena tästä funktionaalisesta toiminnosta kohdassa 53 voi olla anto, joka Hipaisee käyttäjän vastauksen kohdassa 54 ja erityisen tilan 55 valinnan. Funktionaalinen toiminto kohdassa 53 voi kuitenkin olla verkko/käyttäjäkyselyn 56 muodossa, joka herättää verkko/käyttäjävastauksen 57, jonka tuloksena on funktionaalinen komponentti 58. Komponentin 58 anto voi tuottaa edelleen 20 funktionaaliset toiminnot 59 yhdessä käyttäjävastauksen 60 kanssa, joka • \ ·. saattaa järjestelmän sisäiseen tilaan 61.

!. ! Samalla tavoin vaiheen 2 toiminnallisen spesifikaation kehittämis- ;. proseduuri koskee funktionaalisia verkkoaspekteja, kuten esimerkiksi järjestelmän toiminnallisten kokonaisuuksien ja informaatiovirtojen identifi-'·' ’ 25 ointia. Kuten voidaan nähdä kuviosta 5, useita toiminnallisia kokonaisuuksia (FE1 - FEn) 62-65 liitetään toisiinsa verkon funktionaalisella komponent- • · :,’-i tiaspektilla 66. Kukin näistä funktionaalisista komponenteista pystyy ·*”: vaihtamaan sanomia toisten funktionaalisten komponenttien kanssa, niin että • ‘ ; järjestelmän eri komponenteissa on täydellinen informaatiovirta kokonaisuuk-30 sien yhdistämiseksi toimivaan verkkoon. Esimerkiksi kohdassa 66a ;· toiminnallisesta kokonaisuudesta 62 lähetetyn sanomakyselyn vastaanottaa kohdassa 67 toiminnallinen kokonaisuus 63. Vasteena tälle se siirtää ·;· : sanomakyselyn edelleen kohdasta 68 kohtaan 69 toiminnallisessa kokonaisuudessa 64, joka vuorostaan siirtää sanoman edelleen kohdasta 71 35 vastaanottimelle 72 toiminnallisessa kokonaisuudessa 65. Sen jälkeen 1R 109069 16 toiminnallisessa kokonaisuudessa 65 kehitetty vastaus viestitetään sanomavastausten väleillä 73 - 74, 75 - 76 ja 77 - 78 avulla toiminnallisten kokonaisuuksien 64 ja 63 kautta toiminnalliselle kokonaisuudelle 62, joka antaa kohdassa 79 vastauksen alkuperäiseen kyselyyn.

5 Kuviossa 6 on seuraavaksi esitetty havainnollistava piirros tavasta, jolla toiminnalliset kokonaisuudet paikallisen, ts. ei-verkotetun, tietoliikenteen tapauksessa kuvataan ohjelmarakenteeseen. Siinä esitetään, kuinka toiminnalliset kokonaisuudet FE1 - FE4, jotka sisältävät spesifikaatiorakenteen 81, kuvataan ohjelmarakenteeseen keksinnön 82 mukaisesti. Kuten voidaan 10 nähdä, kaksi puhelinlaitetta 83a ja 83b on kytketty vastaavasti ohjelmisto-rakenteeseen liittymän 84a ja liittymän 84b avulla. Kumpikin liittymistä toimii objektina ohjelmistorakenteessa. Samalla tavoin liittymät 84a ja 84b on kytketty toisiinsa käyttäjän A olion 85 ja käyttäjän B olion 85B avulla, jotka muodostavat subjektit keksinnön ohjelmarakenteessa ja ovat, kuten voidaan 15 nähdä kuviosta 6, liittymä/objektiriippumattomia.

Viitaten seuraavaksi kuvioon 7 siinä on esitetty samanlainen havainnollistava piirros, joka kuvaa tapaa, jolla toiminnalliset kokonaisuudet kuvataan verkotetun tietoliikenteen tapauksessa. Siinä on kuvattu tapa, jolla spesifikaatiorakenteen 81 toiminnalliset kokonaisuudet FE1 - FE4 kuvataan • 20 ohjelmarakenteeseen 82. Puhelinlaitteet 83a ja 83b on jälleen kytketty ··]’·, vastaavasti liittymään Aja liittymään B, vastaavasti 84a ja 84b. Samalla tavoin !. ! käyttäjän A olio 85a ja käyttäjän B olio 85b muodostavat jälleen ; ohjelmarakenteessa erilliset subjektit, jotka ovat liittymä/objektiriippumattomia.

: Lisäksi siinä on vielä verkkoriippuvainen subjekti 86 yhdessä geneerisen ’·* * 25 verkkosubjektin 87 kanssa. Kumpikin näistä sisältää verkkokäyttäjän A, 86a, 87a, ja verkkokäyttäjän B, 86b, 87b. Lisäksi verkkokäytäntö 88 kytkee toisiinsa * · :‘ · verkkoliittymän A olion 89 ja verkkoliittymän B olion 90.

·]": Keksinnön prototyypinkehittelyjärjestelmässä prosessikonseptia / ; käytetään mallintamaan sovelluksen ajoaikarakenteista puhelumallia, jossa 30 prosesseja suoritetaan rinnakkaisesti toistensa kanssa. Prosessi tulee ·;* aktiiviseksi johtuen ulkoisesta ärsykkeestä/signaalista, ja konekielisen koodin suorittamisen jälkeen prosessi jää tiettyyn määritettyyn tilaan. Tällainen malli ·:·*: sopii hyvin sovelluksen luonteeseen sikäli, että esiintyy monia rinnakkaisia puheluita ja kukin puhelu Hipaisee useita toimenpidesekvenssejä.

j 17 109069

Yleisesti ottaen järjestelmä jakaa puhelumallin samalla tavoin kuin toiminnallinen malli spesifikaatiossa jaetaan. Viitaten seuraavaksi kuvioon 12 mallinnetaan erikseen myös toiminnalliset piirremoduulit 90, joista kullakin on eri oliot liittymille 160 ja käyttäjille 161, sekä näiden moduuleiden lisäksi 5 linja/päätelaitteet 162. Siten, kuten kuviossa 12 havainnollistetaan, puhelun kummallekin osapuolelle osoitetaan erilliset prosessit (a) kullekin laitteistoon kuuluvalle laitteelle (ohjainprosessi 163), (b) kullekin linjatyypille (liittymä-prosessi 164) ja (c) kullekin osapuolelle puhelussa (käyttäjäprosessi 165).

Verkotuspiirteiden samoin kuin yksittäisen vaihteen piirteiden täytyy 10 olla hyvin sovitettuja, ja erillisiä puheluosapuolia edustavat eri kokonaisuudet, koska ne on jo sijoitettu toiminnalliseen malliin spesifikaatiotyövaiheissa. Siksi puhelunohjaukselle on valittu jaettu tarkastelu, mistä seuraa kaksi puheluosa-puolta, joista kummallakin on oma sarja prosesseja. Jaettu puhelunohjaus sisältää myös sen lisäedun, että tilojen kokonaismäärä pienenee merkittävästi.

15 Jaettu puhelunohjaus vaatii monissa tapauksissa neuvotteluja/kommunikointia puheluosapuolten välillä ennen päätöksentekoa. Kommunikointia osapuolten välillä tukee siten korkean tason käytäntö, joka kätkee sanoman, kun se kulkee prosessoreiden välillä.

*. Kuten alla yksityiskohtaisemmassa tarkastelussa tullaan esittä- • 20 mään, järjestelmän ohjelmistoarkkitehtuuri on jaettu useisiin kerroksiin. Tämä ! ” tarjoaa selviä etuja, kuten tosiasiat, että: ; (1) sovellus tulee riippumattomaksi valituista käyttöjärjestelmistä, ;t (2) sovellus tulee riippumattomaksi valitusta CPU-laitteistosta ja : .* tietoliikennelaitteistosta sekä v : 25 (3) prosessoreiden jakautuminen on sovellukselta kätketty.

Järjestelmäarkkitehtuurin kerrostettu rakenne on esitetty kuviossa :\i 8, jossa sovelluskerros 91, sovelluskäyttöjärjestelmäkerros 92 ja peruskäyttö- järjestelmäkerros 93 muodostavat ohjelmistojärjestelmän. Sovelluskerroksen . koodia on rajoitettu, jotta sovellusohjelmiston rakenne voi mallintaa niin 30 läheisesti kuin mahdollista käytön ajoaikaympäristöä. Sovelluskerros 91 *;·* sisältää jonkin määrän riippumattomia tehtävämoduuleita 89, jotka heijastavat myyntiobjekteja/piirteitä, jotka on aikaisemmin määritelty spesifiointityö-·:··· vaiheissa. Tehtävämoduulit 89 on edelleen jaettu käyttäjämoduuleiksi 94, liittymämoduuleiksi 95 ja ohjainmoduuleiksi 96. Kukin käyttäjämoduuli 94 35 käsittelee piirteen liittymäriippumattomia aspekteja, ts. piirteen liikenteen- 18 109069 ohjausosaa. Kukin liittymämoduuli 95 käsittelee päätteen ominaisuuksia ja yksittäisten puheluistuntojen lähtö/päätekohtia. Kukin ohjainmoduuli 96 käsittelee loogisten signaalien koodausta bittivirroiksi laitteistolle ja laitteistolta tulevien bittivirtojen ja signaalien dekoodausta. Nämä tehtävämoduulit 89 5 kuvaavat täydellistä sarjaa toimintoja tai piirteitä joko (a) puhelintehtäville, mukaan lukien signalointikäytännöt, (b) hallintatehtäville tai (c) piirteiden väliselle vuorovaikutukselle. Esillä olevan järjestelmän eräs pakollinen piirre on peruspuhelusekvenssi.

Järjestelmän sovelluskerros 91 sisältää myös sovelluskirjaston 97.

10 Komponenttien sovelluskirjasto 97 muodostaa suunnittelijoille ja kehittelijöille tehokkaan työkalun, joka nostaa sovellussuunnittelun tasoa. Se sisältää toimintoja, joita käytetään usein piirteitä suunniteltaessa. Kukin näistä toiminnoista voi olla identifioitu spesifiointivaiheessa kullekin uudelle sovellukselle, ja se voidaan sisällyttää järjestelmään, ilman että tarvitsee 15 todella ohjelmoida yksityiskohtia, jotka vaaditaan toiminnan saamiseksi käyttökuntoon.

Viitaten edelleen kuvioon 8 sovelluskirjasto 97 sisältää esimerkiksi toimintoja, joita käytetään usein piirteitä suunniteltaessa. Toiminnot voidaan identifioida spesifiointivaiheessa, ja niitä voidaan sitten yksinkertaisesti käyttää ’ 20 uudelleen työskentelyvaiheessa. Sovelluskirjaston 97 toiminnot voivat hyvin IT! pitää sisällään toimintaa useita puheluosapuolia koskien vastakohtana rajoituksille siinä suhteessa mitä tulee sovelluskäyttöjärjestelmän toimintoihin.

; Seuraava on lista toiminnoista, jotka voivat sisältyä sovelluskirjastoon 97: ί V (a) Vastaa puheluun.

* * · v : 25 (b) Tarkista puhelu.

(c) Yhdistä puhelu.

:’ ·.: (d) Katkaise puhelu.

(e) Jakele puhelut.

(f) Liitä puhelu.

30 (g) Lomita puhelu.

' . (h) Aseta puhelu jonoon.

(i) Linkitä uudelleen.

....: (j) Reititä puhelu uudelleen.

(k) Palauta puhelu.

35 (I) Käännä puhelu.

1β 109069 (m) Pidä osapuolet.

(n) Muodosta puhelu.

(o) Jaa puhelu.

(p) Keskeytä puhelu.

5 Lisäksi sovelluskirjaston 97 toimintoja voi olla määritelty myös hallintatyyppisille piirteille.

Järjestelmäarkkitehtuurin sovelluskäyttöjärjestelmäkerros 92 (AOS), joka on myös esitetty kuviossa 8, antaa tukitoiminnot sovelluskerrokselle 91 ja auttaa kehittelijöitä välttämään koodin toisintamista useissa eri piirteissä. Se 10 auttaa myös sikäli, että se mahdollistaa sovellusohjelmoinnin tapahtumisen niin korkealla abstraktiotasolla kuin mahdollista kätkemällä jälleen toteutusyksityiskohdat sovelluksen suunnittelijalta. AOS-kerroksessa 92 on kaksi pääasiallista toimintoryhmää, työkalusarja 98 ja sarja geneerisiä toimintoja 99. Työkalusarja 98 antaa sovelluskerrokselle 91 yleiskäyttöiset 15 toiminnot, joihin sisältyvät esimerkiksi seuraavat toiminnot: (a) osapuolten keskinäinen kommunikointi, (b) kytkentä, (c) jonotus, (d) ajastus, (e) puhelun historia, (f) numeroanalyysi ja (g) konfiguraationhallinta. Geneeriset toiminnot 98 AOS-kerroksessa 92 antavat mekanismit, jotka ovat välttämättömiä \ suoritettaessa piirremoduuleihin 90 sisältyvät käyttäjämoduulit 94 ja ’ 20 liittymämoduulit 95.

Tietoliikennejärjestelmien käyttöjärjestelmät ovat tavallisesti yksin-; kertaisia ajoajan ohjausohjelmia, joissa on toimintaa vähän enemmän kuin ;* kyky lähettää sanomia järjestelmän osien välillä, ladata koodia, suorittaa • ·* l/O-toimintoja ja niin edelleen. Tämä tarkoittaa tietoliikennejärjestelmissä usein «·» v : 25 sitä, että on vaikeampaa hallita jakelua, uudelleenaloituksia tai muita käytöllisiä/proseduraalisia mekanismeja, kuin on koodata tietyn erityisen piirteen tai sovelluksen toimintaa. Keksinnön käyttöjärjestelmän, joka on kuvattu kuviossa 8, lähestymistapana on sen sijaan muodostaa perus- • · · käyttöjärjestelmä 93, joka on enemmän sukua niille, joita on saatavilla 30 normaaleissa osituskäyttöjärjestelmissä, mutta joka sisältää myös lisä- * » *·;·* primitiivejä ja toimintoja, joita tarvitaan erityisesti tietoliikenteessä. Eräitä esimerkkejä tällaisista toiminnoista ovat: •: · · · (a) geneeriset toiminnot ohjaimille 102, (b) alustustoiminnot 103, 35 (c) tietokannan tallennus- ja hakutoiminnot 104, 20 109069 (d) laitteen allokointi/deallokointitoiminnot 105, (e) virheenoikaisutoiminnot 106, (f) kytkimen käsittely perustuen kytkinryhmäabstraktioon sekä (g) hajautetun arkkitehtuurin ja todellisten konfiguraatioiden todelli-5 suuden kätkeminen.

Standardiprimitiivit viestitykselle prosessien välillä, prosessinajoitus, l/O-yhteydet laitteistoon jne. ovat myös luonnollisesti mukana yhdessä ohjaus-ohjelmapaneelin kanssa. Keksinnön peruskäyttöjärjestelmä ("BOS") 93 kohottaa ohjelmoinnin tasoa mutta on myös mukana tekemässä järjestelmästä 10 vikasietoisen. BOS 93 ylläpitää informaatiota siitä, mitkä resurssit on allokoitu sovellusprosesseille, ja myös siitä, mitkä prosessit on liitetty yhteen tapahtumassa. Siten, kun vika ilmenee joko johtuen ohjelmointivirheestä tai koska yhteistyöhön osallistuva solmu vikaantuu, BOS 93 pystyy päättämään kytketyt prosessit ja palauttamaan resurssit. Tämän eräänä vaikutuksena on, että se 15 mahdollistaa puhelukohtaisen virheenoikaisun. Toisena etuna on, että se saa aikaan hyvin vankan testiympäristön uusien sovellusten ohjelmiston kehittämiselle. Siksi esillä olevassa järjestelmässä laitteisto- ja ohjelmistoviat lisäksi vaikuttavat ainoastaan tapahtumiin, joissa ne ilmenevät, ja järjestelmä voidaan organisoida ja järjestää uudelleen tehokkaasti ja järjestyneestä * 20 Kuten edellä on todettu, sekä keksinnön mukaiset prototyyppi- järjestelmät että reaaliaikaiset käyttöjärjestelmät käyttävät deklaratiivista kieltä, kuten esimerkiksi ERLANG-kieltä, joka on konstruoitu edellä tarkastellun I * · j aktiivisten subjektien paradigman mukaisesti. Valittaessa ERLANG tähän : tarkoitukseen tutkittiin kieliä LISP, PROLOG ja PARLOG. Tutkimus osoitti v : 25 tarpeen lisärakenteelle rinnakkaisuuden, reaaliaikaisten operaatioiden ja muiden erityisesti tietoliikennekytkentäjärjestelmille ominaisten piirteiden käsittelemiseksi. Myöskään erityinen loogisten kielten luokka, joka pystyy ·"*: käsittelemään rinnakkaisuutta, kuten PARLOG, rinnakkainen PARLOG ja muut, ei vielä sisällä rinnakkaisuuden riittävää hienojakoisuutta, jotta / 30 asynkroninen puhelinprosessi voitaisiin esittää yhdellä ainoalla prosessilla ···* kielessä. ERLANG:illa on sekä PROLOG:in että PARLOG:in haluttavat piirteet i ‘‘: mutta rinnakkaisuus ja virheenoikaisurakenteet rakennettuina kieleen itseensä. Kuten ilmenee edellä esitettyyn sisällytettyjen ERLANG-viittausten tarkastelusta, ERLANG sisältää korkeatasoisen symbolisuuden piirteet, mallin-35 sovitussyntaksin, yksinkertaiset ohjausrakenteet, korkeatasoiset data- 21 109069 rakenteet, tuen virheenilmaisulle ja -korjaukselle, kevyet prosessit ja viestityksen.

Keksinnön prototyypinkehittelyjärjestelmän toteutuksessa proto-tyypinkehittely-ympäristö voi sisältää normaalit työasemat, joita käytetään 5 UNIX-käyttöjärjestelmällä. Kehitysympäristö työasemilla voi sisältää X-Windowsin sisältävän käyttäjärajapinnan, arkistot, joihin on menupohjainen pääsy, versionhallinnan, UNIX:in alaisina toimivat tekstieditorit, dokumentin laatimisen kehysvalmistimen avulla ja kommunikoinnin sähköpostin kautta.

Lisäksi prototyypinkehittelyn tukijärjestelmä sisältää työkalut spesifiointi-10 vaihetta varten sekä myös tulevia suunnittelu- ja verifiointivaiheita varten. Työkalut, jotka ovat yhteisiä näille työvaiheille, käsittävät selaimen, valitut näkymät, hypertekstieditorit sekä jäljitettävyyden dokumentin sisällä ja dokumenttien välillä samassa työvaiheessa sekä jäljitettävyyden spesifikaation ja lopullisen koodin välillä.

15 Spesifikaatiotyövaiheessa tukijärjestelmä antaa graafiset työkalut, työkalut staattista ja dynaamista mallintamista varten sekä kaavaimet. Suunnittelu- ja verifiointityövaiheissa tärkein työkalu on ERLANG-järjestelmä, joka tukee seuraavia avuja: (a) piirremoduulin ja laitteistosolmujen simuloinnin suorittaminen, • · * ' . 20 (b) yksittäisten toimintojen vaiheiden jäljittäminen, * f (c) kaiken erityiselle prosessille suuntautuvan kommunikaation ; ·' tarkkailu, »« · : (d) prosessirakenteiden tutkiminen, ts. sen määrittäminen, mitkä i prosessit on keskeytetty, kuinka prosessit on linkitetty virheenoikaisu- v : 25 tarkoituksia varten, jne., (e) prosessin globaalien muuttujien tutkiminen ja :*·,· (f) koodin kääntäminen uudelleen välittömästi ja sen vieminen • 0 käytön ajoaikajärjestelmälle.

/ _ Tukijärjestelmä tarjoaa lisäksi käyttöön interaktiivisen grafiikan, ; "· 30 tietokannan ja muita työkaluja.

: Erilaisia piirteitä voidaan valita testauskohteiksi prototyypinkehittely- * teknologian arvioinnissa. Tällaiset piirteet suunnitellaan nykyaikaisen vaihteen, kuten esimerkiksi Ericsson MD 110, toiminnallisten spesifikaatioiden mukaan, ja niihin sisältyvät seuraavat piirteet: peruspuhelu, perusverkkopuhelu, 35 langaton peruspuhelu, kutsuvan linjan tunnistus, kolmen osapuolen palvelut, 109069 22 puhelun siirto, puhelunvälittäjän suorittama alanumerokytkentä, puhelun päättäminen varattu/ei vastaa -tilanteessa, puhelunvälittäjän toistokutsu ja rinnalle kytkeytyminen.

Kuten edellä on esitetty, kerrostuva rakenne ohjelmistoarkkitehtuu-5 rissa yhdessä tarkan toiminnallisen rakenteen kuvauksen kanssa spesifikaatioissa mahdollistavat sen, että yksi ainoa henkilö suorittaa koko piirresuunnittelun ja -toteutuksen. Tämä henkilö voi myös olla vastuussa toiminnon spesifikaatiotyövaiheesta, jolloin tehdään mahdolliseksi, että ohjelmistosuunnittelijoista tulee todellisia sovellussuunnittelijoita, joiden 10 huomion keskipiste on asiakkaissa ja heidän vaatimuksissaan. Tämä sallii edelleen sen, että arkkitehtuurissa olevista alemmista kerroksista huolehtivat järjestelmäsuunnittelijat, jotka soveltuvat erityisesti tehtävään.

Ohjelmistoarkkitehtuurin tarkka kuvaus toiminnalliseen rakenteeseen tekee työskentelymallista hyvin yksinkertaisen. Tämän seurauksena 15 nykyisen järjestelmän tuottama dokumenttimäärä pienenee huomattavasti.

Lisäksi jotkin dokumentit prototyypille voidaan kehittää automaattisesti. Sitä paitsi suunnittelutehokkuuden mittaaminen tekemällä vertailu nykyisiin järjestelmiin osoittaa tehokkuudessa kasvun, joka voi olla jopa kymmenkertainen. Prototyyppiohjelmiston jonkin erityisen piirteen suunnittelussa ja

• I I

‘ . 20 verifioinnissa mukana olevien henkilöiden määrä pienenee yhteen henkilöön, ;; ·; mikä tarjoaa lukuisia etuja mukaan lukien pitkien odotusjaksojen häviämisen ja ; viivytysten vähenemisen. Eräs lisäetu on tarkempi ohjelmiston suunnittelu.

: Tehtävä-, piirre- tai hallintamoduulien suunnittelu esillä olevassa i järjestelmässä on suhteellisen helppoa ja silti älyllisesti kiihottavaa johtuen v : 25 erilaisten tekijöiden määrästä. Esimerkiksi toiminnallisen spesifikaation verbaalinen teksti vastaa koodia piirremoduulissa, mikä parantaa koodin ja :*·,· piirteen ymmärtämistä. Lisäksi ohjelmat ovat kooltaan pieniä ja » · .*·. tarkasteltavissa käyttäen kielen ominaisuuksia, kuten sovittamista, listan- / _ käsittelyä ja rekursiivisia toimintoja. Lisäksi suunnittelu on lisäystyyppistä ja

> t I

30 interaktiivista, ja prosessi ottaa huomioon strukturoidun kasvun. Paikkaamista ei tarvita esillä olevassa järjestelmässä, koska ohjelmat voidaan kääntää uudelleen välittömästi ja koska piirteiden tai niiden osien toistettu verifiointi on automaattista ja suoritetaan pelkästään aktivoimalla testaustiedosto. Lopuksi data voidaan näyttää hyvin symbolisella tasolla, ei ole tarpeen tarkastella 23 109069 kapasiteettiongelmia suunnittelun aikana ja dokumentaation laatimista on paljon vähemmän.

Kuten keksinnön prototyypinkehittelymenetelmän edellä olevasta kuvauksesta voi nähdä, arkkitehtuurityö perustuu aitoon tietämykseen 5 käyttäjän sovelluksesta. Tämä tekee mahdolliseksi, että luodaan rajoitettu määrä hyvin määriteltyjä kokonaisuuksia kerrostettuun rakenteeseen. Järjestelmä rajoittaa kokonaisuudet ja määrittelee tarkasti niiden toiminnallisen sisällön, sen sijaan että vaatisi lisämenetelmien kehittämistä siihen, kuinka dokumentoida ja periyttää objektit. Tuon arkkitehtuurin, joka on suhteellisen 10 helppo ymmärtää ja käsitellä, yhdistäminen edellä esitetyllä tavalla reaaliaikaiseen deklaratiiviseen kielirakenteeseen vähentää suuresti työmäärää, joka tarvitaan toteuttamaan uudet palvelut ja piirteet tietoliikenteen kytkentäjärjestelmässä. Se tekee myös mahdolliseksi uusien palveluiden ja piirteiden testaamisen tosi elämässä toteuttamalla kehittyneet prototyypit 15 ennen niiden viemistä suuressa mittakaavassa markkinoille. Keksinnön menetelmä mahdollistaa työn volyymin siirtämisen pois toteutusongelmista, ja se sallii keskittymisen asiakkaan tarpeisiin ja uusien ja kehittyneempien palveluiden kehittämiseen.

Ohjelmistoarkkitehtuuri ja -teknologia • «4 . 20 Kuten edellä kuvion 8 yhteydessä todettiin, keksinnön ohjelmisto- järjestelmän arkkitehtuuri on kerrostettu ja sisältää sovelluskerroksen 91, • · • ·’ sovelluskäyttöjärjestelmäkerroksen 92 ja peruskäyttöjärjestelmäkerroksen 93.

V Lisäksi toteutuskerros 101 vastaanottaa kerrostetun ohjelmistoarkkitehtuurin.

i Sovelluskerros 91 sisältää sovelluskirjaston 97, jossa on useita tehtävä- ν' · 25 moduuleita 89. Kukin tehtävämoduuli 89 sisältää käyttäjämoduulin 94, liittymämoduulin 95 ja ohjainmoduulin 96. Sovelluskäyttöjärjestelmäkerros 92 sisältää työkalusarjan 98 ja sarjan geneerisiä toimintoja 99. Peruskäyttö-.*··. järjestelmäkerros 93 sisältää geneerisiä toimintoja ohjaimille 102, järjestelmän käynnistys- ja uudelleenkäynnistystoiminnot 103, tietokannan tallennus- ja

• * I

’· *·* 30 hakutoiminnot 104, geneeriset toiminnat laiteallokoinnille/deallokoinnille 105 ja virheenoikaisutoiminnot 106. Toteutus lohkossa 101 sisältää deklaratiivisen ohjelmointikielijärjestelmän 107, kuten ERLANG:in, laitteistokäyttöjärjestelmän ....: ("OS") 108, keskusyksikön ("CPU") 109 ja tietoliikennekytkinlaitteiston 110.

Viitaten nyt kuvioon 9 siinä on esitetty eräs toinen näkökulma 35 keksinnön kerrostetusta ohjelmistoarkkitehtuurista, jossa sovellus muodostaa 24 109069 korkeimmat kerrokset, ts. lähinnä sovellusspesifikaatiota olevat. Muut kerrokset edustavat toteutuksen syvempiä kerroksia, jotka ovat lähempänä ohjelmistoa käyttävää fyysistä laitetta. Kuten nähdään, sovellus muodostuu sovelluskerroksesta 91, joka sisältää sovelluskirjaston 97 ja sovelluskäyttö-5 järjestelmäkerroksen 92. Sovelluskerros 91 esittää näkymän, joka vastaa tapaa, jolla sovellus alunperin spesifioitiin. Sovelluskerros 91 on myös erotettu peruskäyttöjärjestelmästä ja järjestelmäarkkitehtuurissa sovelluskäyttöjärjes-telmäkerroksella 92. Sovelluskäyttöjärjestelmäkerros 92 antaa tukitoiminnot sovelluskerrokselle 91, jotta vältetään koodin tuottaminen useissa eri 10 tehtävissä ja piirteissä, nostetaan sovellusohjelmointi niin korkealle abstraktiotasolle kuin mahdollista ja erotetaan sovellussuunnittelija toteutus-yksityiskohdista. Sisäisesti sovelluskerros 91 on jaettu useisiin riippumattomiin tehtävämoduuleihin 89, jotka voidaan nähdä toiminnallisesti piirremoduulien 90 ja hallintamoduulien 111 yhdistelmänä. Kukin näistä kahta tyyppiä olevista 15 moduuleista, piirremoduuleista 90 ja hallintamoduuleista 11, on toisiinsa nähden hyvin samankaltainen ja jaettu täysin käyttäjä(puhelunkäsittely)moduu-leihin 112a-b, liittymä (linjankäsittely) -moduuleihin 113a-b ja ohjainmoduu-leihin 114a-b. Piirremoduulit 90 ja hallintamoduulit 111 kuvaavat yhdessä . täydellisen sarjan piirteitä tai tehtäviä järjestelmässä. Tehtävä voi käsittää ** " 20 esimerkiksi puhelin- ja hallintatehtävän itsensä, ts. kuinka toimia vuoro-vaikutuksessa muiden piirteiden, signalointikäytäntöjen jne. kanssa.

.· V "Peruspuhelu" katsotaan pakolliseksi piirteeksi, jonka täytyy aina sisältyä : \: järjestelmään. Tehtävämoduulit 89 voivat jollekin erityiselle tehtävälle sisältää j V ainoastaan piirremoduuleja 90 tai jollekin toiselle tehtävälle ainoastaan ;T: 25 hallintamoduuleja 111. Toisissa tapauksissa tehtävämoduuli 89 voi kuitenkin sisältää sekä piirremoduuleita 90 että hallintamoduuleita 111.

: Piirremoduulin 90 käyttäjämoduuli 112a esimerkiksi ohjaa perus- .·'·] puhelua yhtä hyvin kuin mitä tahansa muitakin piirteitä. Se ohjaa puheluiden *" muodostusta ja valvontaa linjakäytännöstä riippumattomalla tavalla. Käyttäjä-30 moduuli 112a voisi sisältää esimerkiksi: I I » (a) alustusosan, joka määrittelee piirteen tehtävien suorittamiseksi ,··*, tarvitseman alkudatan, esimerkiksi yksilöllisten datakenttien luomisen, oletus- * · t , ] (: datan osoittamisen näihin kenttiin ja vastaavan, (b) käyttäjäproseduuriosan, joka määrittelee käyttäjäproseduurin 35 syntaksin ja merkityksen ja osoittaa oletusarvot, sekä 25 109069 (c) liikenneosan, joka määrittelee, kuinka piirre toimii.

Hallintamoduuleilla 111 on samalla tavoin strukturoidut käyttäjä-moduulit 112b, liittymämoduulit 113b ja ohjainmoduulit 114b.

Piirteen liikenneosa on jaettu siten, että kutakin osapuolta varten on 5 yksi puhelun puoli (näkymä), jolla on oma toisesta puhelun puolesta riippumaton joukko tiloja. Tämä vähentää huomattavasti tarpeellisten puhelutilojen kokonaismäärää jäljelle jäävien tilojen ollessa luonnollisia käyttäjätiloja, jotka voidaan piirteessä allokoida. Kunkin käyttäjämoduulin 112a liikenneosa on rakennettu hierarkkisesti ylätasolta. Kuten kuviossa 10 on kuvattu, kaikki 10 ulkoiset ja sisäiset ärsykkeet tulevat tälle ylätasolle, jotta päästään tila/tapahtumaohjautuvaan logiikkaan, joka muodostuu tapahtuma- ja alitilatoi-minnoista 170. Juuri tältä ylätasolta kutsutaan sopivaa vaihetta 171 vaiheen tuloksen ollessa seuraavan tilan tai alitilan alustaminen sekä myös osapuolten lisääminen/poistaminen puhelussa. Tällä rakenteella annetaan suunnittelijalle 15 vain tätä ylätasoa lukemalla hyvä yleiskuva koko piirteestä.

Tapahtuma- ja alitilatoiminnot ovat käyttäjämoduulin ainoat osat, jotka ovat järjestelmässä muille käyttäjämoduuleille näkyvissä. Niihin sisältyy mahdollisuus toimia vuorovaikutuksessa ensimmäisen puhelunkäsittely-moduulin kanssa määrittelemällä tapahtuma- tai alitilatoiminnot, jotka ottavat ‘ . 20 huolehtiakseen ohjauksesta ja palauttavat sen sen jälkeen. Esimerkiksi kirjauspiirteet palauttavat aina ohjauksen sen jälkeen kun piirre on päättänyt ;t ;* suorituksen. Geneeriset tukitoiminnot tila/tapahtumakäsittelylle tuottaa j ·' sovelluskäyttöjärjestelmä 92.

: Vaihe 171 on suuressa määrin yhdistelmä toimintokutsuja, jotka on v ·’ 25 osoitettu joko sen omalle paikalliskirjastolle 172, sovelluskirjastolle 97 tai sovelluskäyttöjärjestelmälle 92. Vaiheen 171 loppuun suorittamisen jälkeen tulos 173 palautetaan ylätasolle. Vaihetehtäviin sisältyvät esimerkiksi: (a) .···. osoiteinformaation analyysi, (b) valtuuksien tarkastukset, (c) kyselyt muille osapuolille, (d) muiden osapuolten vastaukset kyselyihin, (e) kytkinoperaatiot ’· 30 ja (f) komennot linjan varaamiseksi. Sovelluskerroksen liikenneosuuksissa käytetty hierarkkinen rakenne on kuvattu kuviossa 10. Siinä on esitetty, kuinka eri toimintoja kutsutaan eri kirjastoista ja käyttöjärjestelmistä liikenne-....: toimintojen toteuttamiseksi.

Keksinnön järjestelmän komponenttien rakenne on esitetty vaihto-35 ehtoisessa muodossa jälleen kuviossa 11. Siinä on kuvattu, että 26 109069 ί liittymämoduulit 113a, b ohjaavat piirteiden linjariippuvia osia. Kullekin linjapäätetyypille ja niille piirteille, joilla on linjariippuvia osia, on yksilöllinen liittymämoduuli. Esimerkkeihin linjapäätteistä sisältyvät analogiset/digitaa-liset/ISDN-päätteet ja analogiset/digitaaliset/ISDN-yhdysjohdot perus- ja 5 lisäpalveluille. Kukin liittymämoduuli 113 käsittelee käytännön semanttista osaa kullekin erityiselle laitetyypille. Liittymämoduuli edustaa myös käyttäjä-moduuliin 112 päin suuntautuvaa laiteriippumatonta käytäntöä. Tämä käytäntö on puhtaasti toiminnallinen ja riippumaton linjapäätetyypistä. Kukin liittymä-moduuli 113a, b sisältää: 10 (a) alustusosan, joka asettaa oletusdatan kunkinhetkiselle linjalle, aktivoi laitteiston ja alkuasettaa päätteen sopivaan tilaan, sekä (b) liikenneosan, joka huolehtii liikennetapahtumien vuoronannosta ja käsittelystä.

Liittymämoduulin 113 rakenne eroaa hiukan käyttäjämoduulin 112 15 rakenteesta. Liittymämoduulin 113 ylätaso on jaettu kahteen pienempään osaan, nimittäin vuoronanto-osaan ja tapahtumankäsittelyosaan. Vuoronanto-osan tarkoituksena on jalostaa tulevat tapahtumat käsittelemällä/ muuttamalla linjalta tai toiselta osapuolelta tulevat signaalit sisäiseksi joukoksi tapahtumia ennen niiden syöttämistä tapahtumankäsittelyosalle. Tämä esikäsittely ' . 20 tehdään sanomien vastaanoton, sanomadatan ja päätetilojen suhteen.

Tapahtumankäsittelyosa on samanlainen kuin käyttäjämoduulin ylätaso.

;* Tyypillisiin vaihetehtäviin liittymämoduulissa 113 sisältyvät: • ' (a) useiden puheluliittymämahdollisuuksien käsittely, : V (b) puhelunetenemissanomien osoittaminen käyttäjälle, 25 (c) linjapäätekäytännön semanttisen osan käsittely, (d) numero-, proseduuri- ja suffiksianalyysin suorittaminen sekä (e) puhelunkäsittelyiden luominen ja yhteistoiminta niiden kanssa.

··. Ohjainmoduulit 114a, b voidaan nähdä rajapinnaksi laitteistoon. Ne ,· # käsittelevät linjakäytännön laitteisto-osan, ts. piirteiden syntaksiosuuden.

'* ·’ 30 Ohjainmoduuli 114 dekoodaa laitteiston linjasignaalit/bittivirrat ja antaa ne symbolisessa muodossa sopivalle liittymämoduulille 113. Ohjainmoduuli 114 koodaa myös liittymämoduulilta 113 tulevat symboliset signaalit laitteisto-signaaleiksi. Käyttöjärjestelmässä on tapahtuman/signaalinkäsittelyä varten myös geneerisiä ohjaintukitoimintoja, jotka periytyvät, kun moduuli käynniste- 27 109069 tään. Ne voidaan katsoa käyttömekanismeiksi signaalinsiirrolle laitteiston ja ohjelmiston välillä. Kutakin pääte/laitetyyppiä varten on yksi ohjainmoduuli.

Tähän järjestelmään sisältyy jokin määrä hallintamoduuleja 111, joissa on sarja erityyppisiä hallintatoimintoja mukaan lukien muun muassa (a) 5 vianhallinta, (b) konfiguraationhallinta, (c) laskutuksen hallinta, (d) suorituskyvyn hallinta ja (e) turvallisuushallinta.

Hallintamoduulit 111 käsittelevät hallintapiirteet samalla tavoin kuin piirremoduulit 90 määrittelevät ja toteuttavat puhelinpiirteet. Hallintamoduuli voi käsitellä yhtä ainoaa hallintatoimintatyyppiä tai useampaa kuin yhtä 10 hallintatoimintoa. Hallintamoduulit 111 muodostuvat vastaavasti hallinnan käyttäjämoduuleista 112b, hallinnan liittymämoduuleista 113b ja hallinnan ohjainmoduuleista 114b, jotka on kuvattu kuvioissa 9 ja 11. Piirremoduulin 90 toimintatavan kanssa samalla tavalla hallinnan ohjainmoduuli 114b käsittelee hallintakäytännön syntaktisen osan ja hallinnan liittymämoduuli 113b on 15 vastuussa hallintakäytännön semanttiselle osalle. Lopuksi hallintamoduulit toimivat vuorovaikutuksessa piirremoduulien 90 kanssa seuraavasti: (a) tietokannan kautta konfiguraatiokomentoja varten, (b) raportti/sanomavastaanottimina kirjauspiirteelle sekä (c) tietokannan kautta ja suoraan laitteiston kanssa linjanhallintaa : ’* 20 varten.

Vielä kuvioon 11 viitaten, lohkokaavio ei kuvaa ainoastaan ohjelmistoarkkitehtuurin, jollainen on esitetty myös kuviossa 8, eri : komponenttien konfiguraatiota, vaan osoittaa myös vuorovaikutuksen • komponenttien välillä. Piirremoduuli 90 luo piirreyksilölliset datakentät 121 :’i‘: 25 sopivaan BOS-tietokantaan sekä osoittaa formaatit ja rajoittaa oletusdata-arvot 122 sen alustusosan aikana, kuten on kuvattu kohdissa 122 ja 123.

: Hallintamoduuli 111 luo sen alustusosakomennot ja -parametrit viittaamalla .···! luokkadatakenttiin 124, kuten on kuvattu kohdassa 125. Nämä tallennetaan '·' konfiguraatiotietokantaan 104 yhdessä sen kanssa, että haetaan 30 luokkadatakentän 124 rajat ja pääsyvaltuutukset. Kun hallintamoduulin 111 ohjaimelle 114b saadaan komento kohdassa 128, komentoanalysaattori . ·: . analysoi komennon kohdassa 127, ja valtuutus käyttää komentoa tarkistetaan.

Lisäksi kohdissa 127 ja 128 määritetään, ovatko annetut parametrit

I I

luokkadatakenttään 124 tallennettujen arvorajojen sisällä. Kun komento 35 hyväksytään, kunkinhetkinen hallintapiirre sallii pääsyn asianomaiseen 28 109069 yksilöön, ja käyttäjämoduuli 112b voi operoida sopivaa piirreyksilöllistä datakenttää 131 ja ottaa sen vastaan, kuten on kuvattu kohdissa 132 ja 133. Näihin operaatiohin voivat sisältyä upotus-, muutos-, tulostus- ja poisto-operaatiot.

5 Lähemmin tarkasteltuna piirremoduulin 90 käyttäjämoduulissa 112a oleva alustusosa, kun se alustetaan, kutsuu proseduuria "create_field" AOS-kerroksessa 92. Tämä proseduuri alustaa oletusdatan alaliittymäluokkadatan 121 BOS-tietokantaan 104 käytettäväksi attribuuttia (tai parametria) "intrusion_cat_A" (ts. palvelun tai tilaavan osapuolen kategorian, A-tilaaja, 10 kutsut aloittaa rinnalle kytkeytyminen) varten. Osoitettu formaatti tai rajat tälle datalle tallennetaan myös tietokantaan 104.

Kun suoritetaan liikenneosa piirremoduulin 90 käyttäjämoduulissa 112a ja kun testataan intrusion_cat_A, kutsutaan proseduuria check AOS-kerroksessa 92. Tämä proseduuri tarkistaa ensiksi, onko kyseessä olevalla 15 käyttäjällä yksilökategoria "intrusion_cat_A":lle ohjelmoituna yksilöllisen alaliittymän tietokantaan 131. Jos on, käytetään tätä kategoriaa. Muutoin käytetään alaliittymäluokkatietokannan 121 kohdassa 122 määriteltyä oletusdataa.

Hallintamoduulin 111 käyttäjämoduulissa 112b oleva alustusosa luo ' . 20 käyttämällä AOS-kerroksen 92 proseduuria referenssit 125 konfiguraatio- luokkadataan 124 kullekin attribuutille tai parametrille, joka on määritelty ·' ·' alaliittymäluokan oletusdatassa 122.

: \: Kun hallintamoduulin 111 liittymämoduulissa 113b vastaanotetaan : hallintaoperaatio, niin arvioidaan kunkinhetkisen operaation kelpoisuus :T: 25 yhdessä käyttäjän valtuutuksen kanssa käyttää operaatiota. Kun hallintaoperaation kelpoisuus on todettu, se viedään käyttäjämoduulille 112b.

Jos hallintaoperaation oli määrä luoda "intrusion_cat_ A:lle" liittymälle "12 345" * · .···. dataenttä, jossa on arvo "kyllä", niin tapahtuu seuraavaa: käyttäjämoduuli '* 112b kutsuu käyttäen AOS-kerroksen 92 proseduuria alaliittymäluokassa 121 :· 'ί 30 olevan oletusdatan 122 saadakseen datakentän senhetkisen formaatin parametrille "intrusion_cat_A". Jos arvo "kyllä" on kelvollinen tässä formaatissa, niin proseduuria AOS-kerroksessa 92 kutsutaan yksilöllisen alaliittymädatan 131 liittymälle "12 345" päivittämiseksi arvolla "kyllä". Jos hallintaoperaation oli määrä saada datakenttä "intrusion_cat_A" alaliittymälle 29 109069 "12 345", niin kutsutaan AOS-kerroksen proseduuria, joka noutaa 133 yksilöllisen alaliittymädatan 131 senhetkisen arvon.

Hallintapiirre voi vastaanottaa annon myös esimerkiksi piirteen kirjausdatalta. Hallintapiirre merkitsee silloin tietyt tapahtumat ja valitut 5 puhelinpiirteet, ja kun nämä tapahtumat tapahtuvat, puhelinpiirre vedostaa standardisanomat asianomaiselle hallintapiirteelle. Komennot käsittelee tämä hallintamoduuli 111, joka vuorostaan päättää: (a) tulisiko vastaanotettu data heittää pois vai ei, (b) milloin annon tulisi taphtua, 10 (c) mikä data on määrä antaa, (d) antodatan formaatin sekä (e) osoitteen, johon antodata tulee lähettää.

Hallintamoduulit 111 voidaan tavoittaa joko paikallisista päätteistä tai verkonhallintakeskuksesta.

15 Sovellusdata jaetaan kahteen tyyppiin, staattiseen dataan ja dynaamiseen dataan. Kaikki data on tallennettu fyysisesti tietokantoihin, joita hallitsee peruskäyttöjärjestelmä 93, ja kukin edellä kuvatuista datanäkymistä näkyy sovelluskerroksesta 91. Staattinen data on dataa, joka elää pidempään kuin yhden puhelun ajan. Staattisen datan elinikä voi olla lyhyt, esim. yksi : ’* 20 päivä; datan elinikä riippuu siitä, mille piirteelle data kuuluu, ja suurin osa tästä datasta ei normaalisti säily järjestelmäkatkoksen yli tai pidempään, missä ·' V tapauksessa data pysyy hengissä, kunnes sitä muutetaan komennolla tai se • '.· palautetaan varmistusvälineestä järjestelmäkatkoksen jälkeen. Esimerkkejä • lyhyen eliniän datasta ovat soittopyyntöinformaatio tai follow me -data, kun :V: 25 taas esimerkkejä pitkän eliniän datasta ovat numerosarjat, käyttäjälle sallitut pääsyt eri piirteisiin (palveluluokka), käyttäjän aktivoimat piirteet, piirteeseen .·. : liittyvä data ja niin edelleen.

.*··’ Tiettyä tyyppiä oleva data kuuluu joko objektien luokkaan tai yliluokkaan, jossa luokka voidaan nähdä tietyksi käyttäjätyypiksi. Tällä :.‘*i 30 datatyypillä on nimi, oletusarvo, määritelty formaatti, sallittu arvoväli ja : informaatio siitä, onko se palautettava järjestelmäkatkoksen jälkeen vai ei. Kun oliot luodaan, ne liittyvät luokkaan; yksilöolioita luotaessa ne perivät : asiaankuuluvan luokkadatan. Tavallisia luokkadatatyyppejä ovat: alaliittymäluokkadata 121, konfiguraatioluokkadata 124, puhelunvälittäjä-35 luokkadata, määränpääluokkadata, reittiluokkadata ja yhdysjohtoluokkadata.

30 109069

Luokkien ja luokan yksilöiden löytämiseksi esillä olevaan järjestelmään sisältyvät analyysitaulukot. Nämä ovat datataulukoita, jotka johdetaan tai joita muutetaan luotaessa tai muutettaessa luokkia ja/tai luokan yksilöitä.

Puheluihin liittyvä dynaaminen data on dataa, joka kuolee, kun 5 puhelu on päättynyt. Tyypillinen dynaaminen data sisältää viitteitä puhelun osapuolten välillä, puhelun historiaa (ts. suorittavat piirteet, aikaisemmat kytkennät jne.) ja puhelun tiloja. Dynaamista dataa voi muokata ainoastaan objekti/prosessi itse, ja siihen on pääsy datan nimen avulla. Staattiselle datalle pääsy sen sijaan saadaan käyttäjäviitteellä yhdessä datanimen kanssa.

10 Sovelluskäyttöjärjestelmäkerros 92, taso piirremoduulit 90 ja hallintamoduulit 111 sisältävän sovelluskerroksen alapuolella, on myös kuvattu kuviossa 11. Sovelluskäyttöjärjestelmäkerroksen 92 tarkoituksena on erottaa toteutusyksityiskohdat sovelluskerroksesta ja kohottaa sillä tavoin sovellus-suunnitteluun liittyvää abstraktiotasoa. Rajapinta käyttöjärjestelmään on 15 yleinen ja pitää sisällään sen, että sovelluskäyttöjärjestelmäkerros 92 jää vaikutusten ulkopuolelle suhteessa sisäisiin muutoksiin ja järjestelmän laitteistoon sisältyviin käyttöjärjestelmätoimintoihin. Sovelluskäyttöjärjestelmä-kerros 92, joka on kuvattu kuviossa 8, sisältää kaksi päätoimintoryhmää . käsittäen työkalusarjan 98 ja geneeriset toiminnot 99. Sovelluskäyttö- : ‘‘ 20 järjestelmän työkalusarja 98 antaa yleiskäyttöiset toiminnot sovelluskerrokselle 91. Tyypillisiä toimintoja, joita voi sisältyä sovelluskäyttöjärjestelmän .· V työkalusarjaan 98, ovat: (a) osapuolten välinen komunikointi, (b) osapuolen : V käsittely, (c) kytkintoiminnat, (d) jononkäsittely, (e) ajoitus, (f) historiankäsittely, (g) datakentän käsittely, (h) numeronkäsittely, (i) proseduurinkäsittely ja (j) 25 hallinnankäsittely.

Viitaten edelleen kuvioon 8, sovelluskäyttöjärjestelmän 92 : geneeriset toiminnot 99 muodostavat tukitoiminnot tapahtuma/alitilakäsittelyä .·.·[ ja uusiin tiloihin tulemista varten. Geneeriset toiminnot 99 voidaan nähdä sovelluskerroksen moottorina. Kun tapahtuma tai alitila tapahtuu, geneeristen 30 toimintojen 99 antamat tukitoiminnot yrittävät sovittaa tätä tapahtumaa tai alitilaa, mukaan lukien sen parametrit, järjestelmän käyttäjämoduuleihin 112 . · · ·, (tai liittymämoduuleihin 113) kiinteässä järjestyksessä. Jos tapahtuma tai alitila ' . koskee käyttäjää, sovitusta yritetään käyttäjämoduuleihin 112 piirrelistan mukaisesti. Jos tapahtuma koskee liittymää, sovitusta yritetään liittymä-35 moduuleihin 113 liittymäpiirrelistan mukaisesti. Kun käyttäjämoduuli 112 tai si 109069 liittymämoduuli 113, jossa on yhteensopiva tapahtuma, on löydetty, tätä moduulia kutsutaan ja vastaava toiminto suoritetaan. Jos käyttäjää koskevalla tapahtumalla tai alitilalla ei ole yhteensopivaa tapahtumaa tai alitilaa, puhelu keskeytetään. Jos liittymää koskevalla tapahtumalla ei ole yhteensopivaa 5 tapahtumaa, tapahtuma jätetään huomiotta.

Sovelluskäyttöjärjestelmä 92 sisältää myös sisäänrakennettuja toimintoja uusiin tiloihin tulemista varten, jotka voivat suuntautua joko käyttäjämoduuliin tai liittymämoduuliin. "Uusi tila" voi käsittää: (a) uuden tilan, 10 (b) alitilan ennen tulemista annettuun uuteen tilaan, (c) uuden tilan yhdessä osapuolten lisäämisen tai poistamisen kanssa, (d) kunkinhetkisen tilan tai (e) poistumisen puhelu/ei-tilasta.

15 Puhelumallin määrittelyssä on valittu prosessikonsepti mallinta maan sovelluksen ajoaikarakennetta. Termi prosessi tässä yhteydessä käytettynä tarkoittaa komentojen peräkkäistä suorittamista yhdessä niihin liittyvän datajoukon kanssa. Prosesseja voidaan suorittaa samanaikaisesti, ja prosessi tulee aktiiviseksi, ts. suorituksen alaiseksi, johtuen ulkoisista : 20 ärsykkeistä/signaalista. Prosessi on aina tietyssä määritellyssä tilassa, kun ··.: suoritus päätetään. Kaikki nämä prosessikonseptin tunnusmerkit sopivat : V erittäin hyvin yhteen tietoliikennesovellusten, ts. monien rinnakkaisten : puheluiden, joista kukin muodostuu yhdestä tai useammasta operaatio- \ sekvenssistä, kanssa. Prosessikonseptia tukevat sekä laajennettu käyttö- 25 järjestelmä että keksinnön erityisesti luotu ohjelmointikieli, kuten edellä on kuvattu.

.·. : Esillä olevassa järjestelmässä prosessien laajuutta rajataan samalla tavoin kuin sovelluskoodia rajataan, jotta saadaan mahdollisimman täydellinen ’ yhteensopivuus sovellusrakenteen ja ajoaikarakenteen välille. Kuten kuviossa : 30 12 on esitetty, sovelluskoodi on modularisoitu mahdollisimman lähelle toiminnallisen spesifikaation objekteja. Tämä rakenne johtaa yhden prosessin oletukseen kullekin laitteiston laitteelle ohjainprosessissa, kullekin linjatyypille liittymäprosessissa ja kullekin osapuolelle käyttäjäprosessissa.

Koska verkotuspiirteiden ja erillisten tietoliikennekytkentäpiirteiden 35 tulisi olla hyvin yhteensopivia, esillä oleva järjestelmä käyttää jaettua 32 109069 näkökulmaa puhelunohjauksen toteutukselle. Tämä tarkoittaa sitä, että on kaksi puhelun osapuolta, joista kummallakin on oma joukko prosesseja. Jaetun puhelunohjauksen pääasiallisiin etuihin sisältyvät seuraavat: (a) Tilojen kokonaismäärä pienenee merkittävästi. Tilakonseptia 5 käytetään vähentämään sovelluskoodin mutkikkuutta, ja se on sinänsä hyvin haluttava konsepti. Keskitetyissä puhelumalleissa tilojen lukumäärä pyrkii kasvamaan hallitsemattomaksi, koska tiloja täytyy soveltaa yhdistettyihin konfiguraatioihin, joissa on useita osapuolia.

(b) Osapuolet ovat hyvin toisistaan erotettuja, kun kullakin on oma 10 tilansa ja historiansa. Kun puhelu palautuu alkuperäiseen puhelu- konfiguraatioon, normaalisti kahden osapuolen puheluun, data kullekin puhelun osapuolelle on edelleen voimassa. Jaettu puhelunohjaus vaatii monissa tapauksissa neuvottelua ja kommunikointia puhelun osapuolten välillä, ennen kuin päätöksiä voidaan tehdä. Kommunikointia osapuolten välillä 15 tukee korkean tason käytäntö, joka antaa käyttöön viestinnän prosessien välillä. Ainakin kolmea eri kommunikointitilannetta voidaan tukea: (a) sanoman lähetys ilman kuittausta, (b) sanoman lähetys kuittauksen kanssa sekä (c) sanoman lähetys ja lisäinformaatiopyyntö kuittauksen kanssa.

: " 20 Kullekin näistä kommunikointityypeistä voi olla neljä sanomatyyppiä: (a) tiedotussanoma, jota käytetään sanomien lähettämiseen, kun ei • t · : V odoteta kuittaussanomaa, (b) kyselysanoma, jota käytetään sanomien lähettämiseen, kun odotetaan kuittaussanomaa, 25 (c) verifiointisanoma, jota käytetään lisäinformaation pyytämiseen ennen kuin annetaan vastaussanoma, sekä ,·. ; (d) vastaussanoma, joka on kuittaussanoma aikaisempaan kysely- • ·« sanomaan.

':** Kuvio 12 kuvaa sitä, mitä on tarkasteltu edellä prototyyppi- 30 vaihdekytkentäjärjestelmälle tarkoitetun erityisen toteutuksen yhteydessä.

: “ ’: Kuvio 12 kuvaa käytäntöjä, jotka täytyy toteuttaa ja joita täytyy käyttää hyväksi puheluosapuolten välisen kommunikoinnin, jota jaetun puhelunohjauksen ' . paradigma edellyttää, aikaansaamiseksi. Kommunikointia osapuolten välillä tukee ensinnäkin korkean tason käytäntö 180 viestitykselle käyttäjältä 35 käyttäjälle. Muut alemman tason käytännöt tukevat kommunikoinnin viemistä 33 109069 päätökseen laitteiston tasolla sekä ketjun varmistusta. Käyttäjä/liittymä-käytäntö 181 huolehtii kommunikoinnista käyttäjäprosessin 165 ja liittymä-prosessin 164 välillä. Liittymä/ohjainkäytäntö 182 huolehtii kommunikoinnista liittymäprosessin 164 ja ohjainprosessin 163 väillä. Lopuksi laitteisto/ohjain-5 käytäntö 183 huolehtii kommunikoinnista ohjainprosessin 163 ja yksittäisten laitteistoyksiköiden 184 välillä.

Kuvio 13 kuvaa puhelumalliesimerkkiä peruspuhelulle esittäen käyttäjäprosessit 165a, b, liittymäprosessit 164a, b ja ohjainprosessit 163a, b, joita on kuvattu yksi kummallekin peruspuhelun kahdesta eri osapuolesta.

10 Laitteisto ilmaisee, milloin puhelu aloitetaan, ja lähettää signaalibittivirran ohjainprosessilleen. Ohjain 163 muuttaa sitten signaalibittivirran symboliseen muotoon ja lähettää sanoman omalle liittymäprosessilleen 164, joka odottaa osoiteinformaatiota kutsutulle osapuolelle, vastaanottaa ja analysoi sen sekä muuttaa sen loogiseksi yksilölliseksi viitteeksi kutsutulle osapuolelle. Kun tämä 15 työ on saatettu loppuun, liittymäprosessi 164 alustaa käyttäjäprosessin 165 omalle puheluosapuolelleen ja lähettää sille muodostussanoman. Käyttäjäprosessi 165 allokoi loogisen yksilöllisen viitteen kutsutulle osapuolelle. Sitten se alustaa käyttäjäprosessin 165b tälle kutsutulle osapuolelle , ja pyytää sen käyttäjäprosessia 165a muodostamaan puhelun. Käyttäjä- : ” 20 prosessi 165b kutsutulle osapuolelle pyytää liittymäprosessia 164b tälle osapuolelle varaamaan tilaajan ja yhdistämään itsensä tähän käyttäjäproses-: siin 165b. Sitten lähetetään takaisin kuittaussanoma lähtöpuolen käyttäjä- • prosessille 165a, ja täydellinen puhelumalli peruspuhelulle on silloin tehty valmiiksi.

25 Seuraavaksi viitataan kuvioon 14, jossa on esitetty kuvaus puhelumallille puheluita varten, jotka sisältävät kolme osapuolta. Kysely- : puhelulle 187 tai kun puhelunvälittäjä muodostaa puhelun toisen puolen, • ♦» liittymäprosessi 191a pysäköi ensimmäisen puhelun 188 ja muodostaa :* identtisen sarjan prosesseja (käyttäjä 192a - käyttäjä 192c - liittymä 191c -\'·· 30 ohjain 190c) tälle uudelle puhelulle 189. Liittymäprosessi 191a yhdistetään sitten kahteen sarjaan prosesseja 188, 189, yhteen kummallekin puhelulle.

, j*, Seuraavaksi viitataan kuvioon 15, jossa on esitetty puhelumallin ‘ kuvaus monen osapuolen puhelulle. Monen osapuolen puheluissa tavallista puheluosapuolen prosessiketjua käytetään kullekin osanottajalle. Vastakkai-35 sella puhelun puolella on yksi yleinen tavallinen palvelukäyttäjäprosessi 195.

34 109069

Siinä ei ole lainkaan yhdistettyjä liittymäprosesseja, ja niinpä tämä konfiguraatio saa sen näyttämään sarjalta tavallisia kahden osapuolen puheluita kunkin osanottajan puolelta.

Seuraavaksi viitataan kuvioon 16, jossa on esitetty puhelumallin 5 kuvaus uudelleenkutsulle puhelunvälittäjälle. Uudelleenkutsussa puhelunvälittäjälle uusi puheluosapuoli yhdistetään alkuperäisen puhelun kummastakin käyttäjästä 200a, b yhteen puhelunvälittäjäkäyttäjään 201a, b kummallakin puhelun puolella. Piirteitä suunniteltaessa puhelumalli täytyy pitää mielessä, ja edellä kuvioiden 13-16 yhteydessä esitetty filosofia ja esimerkit voidaan 10 nähdä ohjenuoraksi laadittaessa puhelumalleja tulevia skenaarioita varten. Ideaalisesti tulisi tavoitella mallia, joka sopii hyvin soveliuskonseptiin ja joka on i helposti sovitettavissa todennäköisiin uusiin tiloihin sovelluskuvassa.

Keksinnön järjestelmässä käytetty ohjelmointikieli on laajennettu deklaratiivinen kieli, joka pystyy toteuttamaan rinnakkaisuuden yhdessä reaali-15 aikaisten toimintojen kanssa. ERLANG-kieli sisältää nämä välttämättömät piirteet, joista eräitä ovat esimerkiksi seuraavat: (a) korkean tason datarakenteet, kuten listat ja monikot LISP:istä tai PROLOG:ista dynaamisen muistinhallinnan tukemina, . (b) korkean tason symbolinen ohjelmointi, joka antaa saman- : " 20 tyyppisen tehokkaan ohjelmankehityksen kuin LISP, • · · ··" (c) suoritus mallinsovituksen avulla ja yksinkertaiset ohjaus- : *.*’ rakenteet, jotka antavat lyhyt- ja selvätyylisen ohjelmoinnin, • · · i (d) moduulit, joita käytetään apuna suurten ohjelmajärjestemien strukturoimisessa, 25 (e) prosessit, prosessinhallinta ja viestintä, jotka tukevat saman aikaisuutta ja reaaliaikaista toimintaa, : (f) tuki virheenilmaisulle ja virheenkorjaukselle, mikä mahdollistaa .’··[ vankkojen järjestelmien suunnittelun, joissa on esimerkiksi puhelukohtainen virheenoikaisu, sekä ; 30 (h) läheinen vastaavuus SDL:n, CCITT:n suositteleman spesifiointi- kielen kanssa.

.···, Alla on esitetty havainnollistamistarkoituksessa eräitä peruspuhelun ’ ; toteutuksesta otettuja koodiesimerkkejä. Seuraava on esimerkki tapah-tuma/tilatasolta, jossa on vastaanotettu viisi parametria sisältävä muodostus-35 sanoma. Tapahtuman sovitus on toteutettu piirrelistan mukaisesti piirremo- « 109069 35 duuleille. Muilla piirteillä on ollut mahdollisuus olla vuorovaikutuksessa tapahtuman kanssa, mutta yksikään ei ole tehnyt sitä. Viimeistä sovitusta yritetään peruspuhelumoduuliin, kuten alla on esitetty: 1 # secup( Self,_, Idle,[Self],[CallType.no_name] ) —> 5 case call_start_up( Self,CallType ) { barred —> abort( blocked ); ok —> state( call_started ); complete( Partner) —> state(call_started,add( Partner. )); }.

10 2 # setup( Self,_, Idle, [Sei f], [CallType,Name] ) —> case establish_cal1( Self,CallType,Name ) ( barred —> abort( blocked ); yes(Partner) —>state(call_started, seizure, add(Partner)); }· 15 99 # setup (_,_,_,_,_) —> cont inue.

® 1991 Telefonaktiebolaget L M Ericsson ‘ . 20 Tapahtuu mallinsovitus, jossa sovitusta vastaanotetun • · · muodostussanoman suhteen yritetään ensiksi käsittäen kaikki parametrit ; samanaikaisesti ensimmäiseen peruspuhelunmuodostuslauseeseen. Jos : V esiintyy yhteensopivuus, sovelletaan tätä toiminnon määrittelyä. Jos toiminto ei M · : .·’ ole yhteensopiva, sovitusta yritetään seuraavaan lauseeseen ja niin edelleen.

:T: 25 Jos yhteensopivuutta parametreihin ei ole, ohjaus annetaan takaisin moottorille. Koska peruspuhelu on viimeinen piirre piirrelistassa, puhelu tässä tapauksessa keskeytettäisiin. Esimerkkejä korkea tason symbolisesta .*··, ohjelmoinnista voidaan visualisoida toimintonimillä ja parametrinimillä muodostuslauseessa. Ohjelmistosuunnittelija voi valita minkä tahansa pituisia ’· ’> 30 sopivia nimiä.

11« \..J Korkean tason datarakenteet tulevat muodostuslauseen parametrin [CallType, No_Name] mukana, joka on lista, joka edustaa datarakennetta kahdella muuttujalla. Esillä olevassa järjestelmässä on yksinkertaiset puhelunohjausrakenteet, joissa on itse asiassa kaiken kaikkiaan hyvin harvoja 35 tällaisia ohjausrakenteita. Edellä esitetyssä esimerkissä on ainoastaan kaksi „ 109069 ohjausrakennetta, nimittäin case ja continue. Case-käsky on kuitenkin tärkein ohjausrakennekäsky. Alla on esitetty vaihetasolta esimerkki, jossa oletetaan, että ensimmäinen muodostuslause edellä esitetyssä esimerkissä on yhteensopiva vastaanotetun sanoman kanssa. Tässä lauseessa call_start_up (Self, 5 CallType) kutsutaan toimintoa call.

1 # call_start_up( Self,CallType ) —> case check( call_allowed,Self ) { no —> notify( release(barred),Self), "barred; yes —> remember( call_direction,caller_A ), 10 notify( setup_aclc(normal),Self ), "ok ® 1991 Telefonakciebolaget L M Ericsson

Kun lausetta call_start_up vuorostaan sovitetaan, ensimmäinen 15 toiminto call on AOS-toiminto check/2, jossa on kaksi parametria. Tätä toimintoa arvioidaan ja tulos palautetaan toiminnolle call_start_up, joka suorittaa tehtävänsä kutsumalla paria muuta AOS-toimintoa ja palauttamalla tuloksen puhelunmuodostustoiminnolle.

• t Eräs sisäänrakennettujen reaaliaikaisten järjestelmien, joihin : .'*20 tietoliikennejärjestelmät kuuluvat, kehittämisessä luonteenomainen ongelma • · · on, että niissä on aina mukana kaksi tietokonetta. Niissä on isäntätietokone, ·* ·’ tavallisesti VAX, IBM tai jokin muu vastaava tietokone, jossa ohjelmankehitys • · · : tapahtuu, sekä kohdetietokone, kuten esimerkiksi Ericssonin AXE-SPC-tieto- I < · : V liikennekytkentäjärjestelmässä käytetyt erikoistuneet APN- tai APZ-:T: 25 prosessorit, jossa ohjelmat suoritetaan käyttöjärjestelmässä. Tämä merkitsee väistämättä sitä, että tulee olemaan pitkä läpimenoaika ohjelmoinnin isäntätietokoneessa tapahtuvan kehittämisen ja editoinnin ja kohdekoneessa • · .···. tapahtuvan testaamisen välillä. Keksinnön järjestelmässä nämä toiminnot on ’·* kuitenkin yhdistetty. Eräiden muokkaustoimenpiteiden avulla työasema ja sen 30 tietokone ohjaavat linjarajapintamoduulia ("LIM"), ja siten yhdistetään isäntä-ja kohdetietokoneiden toiminnot, niin että editointi-suoritusjaksoon käytetty aika itse asiassa sillä tavoin eliminoituu. Kuten kuviosa 17 on kuvattu, .,,,: tällaisessa suunnittelu/suorituskonfiguraatiossa on lukuisia etuja.

Kuten kuviossa 18 on kuvattu, eräs tunnettu työskentelymalli 35 sisältää olennaisesti suuremman määrän vaiheita verrattuna keksinnön 37 109069 järjestelmään. Siinä voidaan nähdä, kuinka piirteet sisältyvät suureen määrään lohkoja 141 verrattuna keksinnön yksinkertaiseen symbolitehtävämoduuliin 142. Spesifioinnin ja koodauksen, joka johtaa lopulliseen toimivaan ohjelmistojärjestelmään, vaiheissa on siten huomattavaa yksinkertaistamista.

5 Korkeampi ohjelmiston laatu on vielä eräs etu, joka juontaa alkunsa esillä olevasta järjestelmästä. Esillä olevan järjestelmän lukuisia aspekteja on toteutettu ja testattu ja on määritetty niiden suunnittelutehokkuus aikaisempaan tunnettuun tietoliikennejärjestelmään verrattuna. Suunnittelu-tehokkuustestien tuloksena on, että esillä oleva järjestelmä toimii paremmin 10 kuin tunnettu järjestelmä jokaiselle testatulle piirteelle. Lisäksi piirteen suunnitteluun, toteutukseen, verifiointiin ja dokumentointiin vaadittu keskimääräinen aika esillä olevaa järjestelmää käyttäen on paljon pienempi kuin tunnetussa järjestelmässä vaadittu aika.

Nämä tehokkuustekijät yhdistettyinä siihen tosiasiaan, että 15 suunnittelijan ei tarvitse esillä olevassa järjestelmässä odottaa toisen suunnittelijan työtä ennen oman koodinsa verifiointia, merkitsevät sitä, että ohjelmistonkehitys voi tapahtua suunnitellusti ja oikeassa järjestyksessä. Esillä oleva järjestelmä tuottaa ohjelmiston, jossa on selvä hierarkia, joka käsittää yksittäisiä, jo verifioituja rakennuspalikoita, mikä tekee koko järjestelmän : " 20 näkemisen ja ymmärtämisen helpoksi. Lisäksi esillä oleva järjestelmä < · · ···: mahdollistaa koodin verifioinnin itsenäisesti ja lisäystyyppisesti, ja tämä antaa : työkalut virheenoikaisulle ja koodianalyysille. Kuten aikaisemmin on lyhyesti : mainittu, sekä piirteen suunnittelussa että verifioinnissa mukana olevien : henkilöiden määrä voidaan vähentää yhteen ainoaan henkilöön, jolla tavoin 25 vähennetään odotus- ja ohjausaikaa. Esillä oleva järjestelmä myös mahdollistaa suunnittelun verifioinnin tekemisen ennen toiminnallista : testausta.

* I I

.·.·[ Pääasiallisiin tekijöihin, jotka tekevät kiinnostavaksi ja helpoksi '1' suunnitella piirremoduuleita käyttäen keksinnön järjestelmää, sisältyy se :.'·ί 30 tosiasia, että toiminnallisen spesifikaation verbaalinen teksti vastaa koodia piirremoduulissa, mikä parantaa sekä koodin että piirteen ymmärtämistä. Lisäksi ohjelmat voidaan tehdä pieniksi ja helposti tarkasteltaviksi käyttämällä ' . kielen sellaisia ominaisuuksia kuin sovittaminen, listankäsittely ja rekursiiviset « t toiminnot. Suunnittelu kehittyy lisäystyyppisesti ja interaktiivisesti ja 35 mahdollistaa strukturoidun kasvun. Siksi paikkaaminen ei ole tarpeen tai edes 38 109069 mahdollista, koska ohjelmat voidaan kääntää uudelleen välittömästi. Piirteen tai sen osien toistettu verifiointi on automaattista, ts. se tapahtuu pelkästään aktivoimalla testaustiedosto, ja data voidaan näyttää hyvin symbolisella tasolla. Lisäksi ei ole tarpeen tarkastella kapasiteettiongelmia suunnittelun 5 aikana, kirjoitettavana on paljon vähemmän dokumentteja ja suunnittelija voi verifioida koko piirteen, ennen kuin se vapautetaan todella käyttöön. Ohjelmiston laatu paranee huomattavasti, mikä puolestaan tuottaa paremman tyydytyksen suunnittelijoille.

Useimmat edellä mainitut tehokkuustekijät pätevät myös, kun 10 lisätään uutta toimintaa järjestelmään. Toiminnan lisääminen on ekvivalenttista sen kanssa, että järjestelmään lisätään uusi piirremoduuli. Tämä piirremoduuli joko sisältää täysin uutta toimintaa, joka lisätään peruspuhelumoduuliin, tai jo olemassa olevan toiminnan korvaamisen peruspuhelumoduulin yläpuolella olevaan piirremoduuliin.

15 Monet edellä mainituista tehokkuustekijöistä pätevät myös suunniteltaessa piirrettä hajautetussa suunnitteluympäristössä. Tärkeimpiin näistä sisältyy se tosiasia, että kehittäminen jaetaan pieniin ja täydellisiin piirremoduuleihin. Suunnittelijasta tulee piirrettään luodessaan muista . suunnittelijoista riippumaton. Lisäksi kapeat rajapinnat tekevät koordinaatio- ·' ” 20 tarpeen hyvin vähäiseksi. Ainoat välttämättömät lähtötiedot piirteen suunnittelijalle ovat toiminnon spesifikaatio sekä järjestelmäkirjaston ja : sovelluskäyttöjärjestelmän työkalusarjan senhetkiset versiot. Lisäksi vuoro- vaikutuksen piirteiden välillä, ts. järjestyksen, jossa piirteitä kutsutaan, ratkaisevat käyttöproseduurit, ja vuorovaikutukset voidaan testata yhdessä 25 ainoassa paikassa.

Kuten keksinnön järjestelmän tarkastelusta voidaan nähdä, ,·. : ohjelmistokielen rakenteessa, joka mahdollistaa ohjelmistoprototyyppien • t · toteutuksen, on lukuisia etuja. Lisäksi voidaan helposti nähdä, että järjestelmä ';** on helposti sovitettavissa muihin prosessinohjausjärjestelmäsovelluksiin.

• · ·'.’·· 30 Näin ollen uskotaan, että keksinnön toiminta ja rakenne ovat edellä :‘‘T esitetyn kuvauksen perusteella selviä. Kun edellä esitetyt ja kuvatut menetelmä, laite ja järjestelmä on luonnehdittu parhaina pidetyiksi, on helposti ' . nähtävissä, että erilaisia muutoksia ja muunnelmia voidaan tehdä niihin poikkeamatta keksinnön hengestä ja sen seuraavissa patenttivaatimuksissa 35 määritellyissä puitteissa pysyen.

Claims (5)

39 109069

1. Tietoliikenneohjelmointijärjestelmä tietoliikennejärjestelmään tallennettavan ja osana prosessinohjausjärjestelmää toimivan deklaratiivisen 5 ohjelman kehittämiseksi, joka tietoliikenneohjelmointijärjestelmä on tunnettu siitä, että se käsittää ohjelmointivälineet deklaratiivista ohjelmointikieltä käyttävän tieto-liikenneohjelmistoarkkitehtuurin luomiseksi, joka deklaratiivinen ohjelmointikieli käsittää 10 toimintoja sisältävän prosessin edustaman subjektin, predikaatin, jota edustavat deklaratiivisen kielen predikaatit, jotka määritellään diskreeteiksi ohjelmaproseduureiksi, sekä objektin, jota edustavat data ja reaalimaailman oliot symbolisessa muodossa määriteltyinä, 15 joka prosessiohjausjärjestelmä käsittää lisäksi liityntävälineet fyysiseksi liittymiseksi mainittuun tietoliikenneohjelmointijärjestelmään liityntä-linjojen kautta.

2. Patenttivaatimuksen 1 mukainen tietoliikenneohjelmointijärjes-telmä, tunnettu siitä, että subjekti käsittää predikaattisekvenssin ja että : *·· 20 sille ovat tunnusomaisia toiminnot, jotka se pystyy suorittamaan.

3. Patenttivaatimuksen 1 mukainen tietoliikenneohjelmointijärjes-telmä, tunnettu siitä, että mainittu predikaatti on spesialisoitu ;' · ’: käytettäväksi ainoastaan yhden mainitun subjektin yhteydessä.

4. Patenttivaatimuksen 1 mukainen tietoliikenneohjelmointi- » » 25 järjestelmä, tunnettu siitä, että mainittu predikaatti on yleinen ja saatavissa käyttöön minkä tahansa aktiivisen subjektin yhteydessä.

. . 5. Patenttivaatimuksen 1 mukainen tietoliikenneohjelmointi- järjestelmä, tunnettu siitä, että mainittu objekti on toteutettu objekti- * i !‘ prosessina, joka sisältää siihen liittyviä toimintoja. 30 I k t * * k l f i * » * » * ί 1 t 40 109069