A formális nyelvek szerepe a távközlési szoftverek fejlesztésében

Harmatné Medve Anna <medve@almos.vein.hu>

Veszprémi Egyetem Információs Rendszerek Tanszék

Tarnay Katalin Dr. <tarnayk@almos.vein.hu>

Veszprémi Egyetem Információs Rendszerek Tanszék

Előadásomban bemutatom a távközlési szoftverek fejlesztésében hatékonyan alkalmazható formális nyelveket, éspedig az SDL (Specification and Description Language) specifikáló és leíró nyelvet, a rendszerelemek közti üzenetváltást idősor diagramokkal leíró MSC (Message Sequence Chart) nyelvet, ASN.1 (Abstract Syntax Notation One) adatdefiníciós nyelvet, a tesztelés tesztkészleteit specifikáló TTCN (Tree and Tabular Combined Notation) nyelvet, valamint ezen formális nyelvek fő jellemzőit, majd összehasonlítom a formális nyelveken alapuló rendszerfejlesztés menetét a hagyományos rendszerfejlesztés technológiáival. Végül bemutatok egy, a formális nyelveket alklamazó rendszerfejlesztési technológiát és ennek Case eszközét.

In this article we will demonstrate the application of modern methods in the telecommunication software development. The first stage of design is defining the requirements and specifications in text format, followed by formal specifications. The formal specification defines the system in general as communicating finite-state machines. Its language is SDL (Specification and Description Language). The message exchange among the system components can be characterized by time sequence diagram, its language is MSC (Message Sequence Chart). Test suits of the conformance test are derived from the formal specification. We specify the set of tests with TTCN (Tree and Tabular Combined Notation). Data revealed during the survey is given in ASN.1., which could be incorporated into SDL and TTNC specifications. Design is followed by the implementation phase, these days mainly C++ or Java is used for programming. The completed system is tested on two levels. First basic software tests re conducted, followed by the conformance test, when the implemented system is compared to the formal specification.

The application of the formal methods reduces the life-cycle of the system, makes implementation more reliable and makes more unambiguous the relation between specific elements of the system. The application of these methods enables automation of system implementation.

There are CASE tools available for generating automatically the final product from validated and tested SDL specifications

1. Rendszerfejlesztés és formális módszerek

A szoftverfejlesztés komplex feladat, amelyre többféle módszertant vezettek be és egyes fáziasit automatizálták. A módszertanok megkönnyítik a kommunikációt a projektvezetés és a fejlesztő tagok között, ellenben az ábrázolásmódok hiányosságai a kész rendszer minőségét esetlegessé teszik.

A rendszer vizsgálatára is kiható hiányosság, hogy nem elég mély az ábrázolások szintje még a programtervekben sem, így a rendszer működésének teljes részletezése csak a megvalósítás fázisában készül el, a megvalósítás konkrét programozási környezetének implementációi szerint.

A másik probléma, hogy az ábrázolásmódok többsége nem veszi figyelembe a rendszer dinamikus viselkedését, a program a rendszer absztrakciója lesz, és a rendszer helyesnek vélt működését valójában a statikus részek jól tervezett tesztelésével tudjuk csak ellenőrizni.

A valóságban a rendszer dinamikus viselkedésének jósága csak az implementálás után derül ki, ami a valós idejű és elosztott rendszereknél nagyon kritikus fejlesztési paramétereket eredményez. A statisztika szerint [15], a rendszerfejlesztés költségeinek 45% az elemzés, tervezés és megvalósítás szakaszokra, 55% a tesztelés és implementálás szakaszokra jut.

Az új technológiák [1], mint az OO, CASE, mesterséges intelligencia, elosztott komponensek megjelenése a módszertanok fejlődésére azzal hatott, hogy megjelentek és folyamatosan fejlődnek az új technológia fogalomrendszerére támaszkodó szigorú elméleti hátterek a formális módszerek gyűjtőnévvel [2], amelyek az említett hiányosságokat pótolják.

Az új módszerek matematikai alapjain ábrázolható a rendszer dinamikus viselkedése, valamint lehetővé válik a megvalósítás tervezésének a validálása, a megvalósítás konkrét programozási környezetétől függetlenül.

A megvalósítás terve a rendszer teljes mélységű formális leírása, amely a rendszer elemeinek és viselkedésének szimbólumokkal való ábrázolása oly módon, hogy a fejlesztést támogató és a forráskódot automatikusan generáló Case eszközök fejleszthetők. Ezáltal a jól megszerkesztett és ellenőrzött specifikáció alapján akár több programozási nyelvre is előállítjuk a futtatható kódot.

A validálás ciklikus folyamat, amely során a rendszer formális leírását ellenőrizzük és vetjük össze a rendszer követelményeivel. A validálás folyamatát segíti a kölcsönhatások áttekinthetőbb ábrázolására szerkesztett formális nyelv alkalmazása a dinamikus viselkedés problémás részeinek ábrázolásában és vizsgálatában. A validálás után a tesztelés fázisainak automatizálásával kapjuk a kód generálására alkalmas implementálható terméket. Az automatizált teszteléshez szükséges a validált formális leírás, amelyből generáljuk részben a tesztcélokat és teszteseteket, valamint az erre a célra szerkesztett formális nyelven tesztsorozatot szerkesztünk.

Az elmondottakból kitűnik, hogy a fejlesztésben a formális módszerek egyik lényeges célja a specifikáló, leíró és tesztelő folyamatok formális nyelveken való megfogalmazása, amelyből hibátlan automatizálható forráskódot állíthatunk elő, akár több forrásnyelvi környezetre is.

1. Formális nyelvek

A formális nyelvek több családja létezik, többségükre jellemző:

• egy korábban kidolgozott alapelmélet (például a halmazelmélet, a hirközlő rendszerek, az egyetemes algebra elméletei);

• egy megkülönböztetett terület (például az adatbáziskezelés, valós idejű rendszerek, protokollok);

• egy kutatói és felhasználói közösség, gyakran különböző területeken vagy kutató helyeken szétszóródva.

Egy rendszer specifikálásában különböző szempontokat kell érvényesíteni, mint a szerkezet, a kapcsolatok, látható viselkedés vagy az alkalmazott algotitmusok. Számos formális nyelv maga az ábrázolt rendszer típusának a leíró nyelve, mint a folyamat vagy adatleírók, vagy az állapotleíró automaták; az információ csere megtörténhet adatmegosztással, szinkron-, vagy aszinkron jelek kommunikációjával, függvény- vagy eljáráshívással. Ilyenek általában a szabványosítások, amelyeket a protokollok, a valós idejű rendszerek, adattranszformációk leírására szerkesztettek. Jellemzőjük, hogy könnyebb a módszertan és fejlesztőeszközök kialakítása, de beszükitík a választás lehetőségét egy adott technológiai szintre.

Más formális nyelvek a matematikai elvre korlátozódnak és nem javasolnak rendszerszemléletet, a matematika és logika kifejezésmódjával szabadabb ábrázolást tesz lehetővé, azonban ez elméletileg előny, mert a gyakorlatban nagyon komplex modellek születnek módszeres tervezés nélkül. Ez vezetett a speciális módszerek paradigmáinak újraalkotására, némelyeket megőrizve, másokat általánosítva. [2]

1. SDL (Specification and Description Language)

Az ITU (International Telecomunication Union) Z.100, Z.105, Z.107 és Z109 ajánlásai alapján fejlesztették[4]. Folyamatosan fejlesztik, 1996-2000 között jelentősen kiterjedt az alkalmazása, már nemcsak a távközlés alkalmazza, legújabb verziója [9,19] az SDL2000 alkalmas tetszőleges valós idejű, interaktív elosztott rendszer formális leírására. Jellemzi az objektum-orientáltság, a távoli eljáráshívás, a tesztelhetőség, hatékonyság. Alkalmas a specifikálandó rendszer szerkezetének és viselkedésének együttes leírására. Alkalmazását megkönnyíti az egymásnak kölcsönösen megfeleltethető grafikus és szöveges nyelvi implementációja.

Matematikai alapja [16, 8] a kiterjesztett véges automata (EFSM) modell, amely a rendszer működését gerjesztés-válasz módon határozza meg.

EFSM = (S, I, O, A, V, P, s_0, f_s,i,p ), ahol az S az állapotok véges halmaza, I a bemenetek véges halmaza, O a kimenetek véges halmaza, A az akciók véges halmaza, V a változók véges halmaza, P a predikátumok véges halmaza, s₀ a kezdő állapot, f_s,i,p az állapotátmenet függvény. A bemenetek és kimenetek kommunikációs események, amelyek az automata és környezete között zajlanak. Az akciók a bemenetek változókra gyakorolt hatását adják meg, míg a változók a predikátumok alapján hatnak az állapotátmenetben. Az automata tényleges viselkedését az f_s,i,p állapotátmenet függvény írja le. Ez definiálja azt, hogy egy adott s_k állapotból az automata valamely i bemenő jel hatására a p feltétel mellett mely a akciót hajtja végre, mi lesz a kimenő o jel és mi az s_k+1 a következő állapot.

A rendszer több egymással és a rendszerkörnyezettel kommunikáló automatából áll, ahol a kommunikáció jelekkel történik a FIFO elven működő csatornákon és jelútakon. (lásd 1. ábra )

1. ábra: Kommunikációs útvonalak és jelölésük

A teljes rendszer viselkedését az egyes automaták viselkedésének összessége határozza meg. Formálisan az automaták viselkedését a viselkedés-gráffal adhatjuk meg. Funkció szerint hierarchiába szervezve az egymással kommunikáló automatákat, a leírást a rendszer, blokk és processz hierarchiaszintek jellemzik.

A processz maga a véges állapotú automata, a rendszer müködését a processz diagrammokkal adjuk meg. A processzek a rendszer keletkezésekor vagy egy másik processz hatására keletkezhetnek, egyszerre több példányban is. Minden egyes processz egyetlen bemeneti sorral rendelkezik. Bonyolultabb esetekben a rendszerblokkok alrendszerekre bomlanak, ezek újabb blokkokat és alrendszereket tartalmazhatnak

Például ha egy végberendezés adatait kell továbbítani, és (rész)rendszernek tekintjük az adást lebonyolító egységet, az Inres protokollal modellezhetjük és a rendszer ábrázolását valamint az adó blokk ábrázolását a 2. ábra, az adás folyamat müködésének egy részét a 3. ábra diagramja specifikálja.

2. ábra: Az Inres adó oldali SDL rendszer diagramja és a Station_Ini blokk diagramja

3. ábra: Az adó Initiator process diagram-lap SDL nyelven

Az adást lebonyolító adó Station_Ini blokk két processzt tartalmaz, egy adó és egy kódoló processzt. A 2.4 ábrán látható részlet az adó működését a várakozó és a kapcsolt állapotban írja le

A grafikus leírás szövegessé konvertálható, ennek egyik előnye, hogy az egyes SDL fejlesztő eszközök között hordozható. Szövegdobozokban adjuk meg a változó és típus deklarációkat, amelyek a hierarchia szülő-gyermek ág vonalán öröklődnek. Absztrakt és paraméterezett adattípusok szerkeszthetők és újradefiniálhatók; az osztály típus és szimbólum[9] egy hivatkozást jelent azokra a típusokra, amelyek attributumai és müűködési tulajdonságai az osztálytípust jellemzik. Az SDL-2000 bővítése értelmezi az ASN.1 adatleíró struktúrákat.

1. MSC (Message Sequence Chart)

Az MSC egy grafikus és szöveges nyelv különböző rendszerkomponensek közötti kölcsönhatások leírására az ITU-T Z.120-as szabványa definiált [3]. A grafikus megjelenítés átláthatóvá teszi a rendszer viselkedését. Az MSC alkalmazási területei [10] az interfész specifikációk, kommunikációs folyamatok általános célú specifikációi, SDL specifikációk konzisztencia vizsgálata, tesztesetek specifikációja és dokumentálása, OO tervezés analizátora. MSC-vel jól modellezhető a rendszer időbeni viselkedése, valamint a rendszer komponensei és a környezet üzenetváltásainak sorozata. A 4. ábra az adó sikeres kapcsolatfelvételének MSC idősor diagramját ábrázolja.

4. ábra: A sikeres kapcsolatfelvétel MSC diagramja

Minden rendszerkomponenst egy instance tengely ábrázol. Az instance-ok(példányok) az SDL nyelvben a folyamat, eljárás, szolgáltatás entitásainak felelnek meg. Az instance jellemzői a kezdet-, tengely-, és végszimbólumok. Az instance teste a tengely és vég szimbólum együtt, a tengelyszimbólumhoz kapcsolódó rész az eseményterület, amely tartalmazza az üzeneteket is. Az üzenetek a kommunikációs eseményeket írják le, grafikusan a küldő- és fogadó instance közötti nyíl az üzenet szimbóluma, az üzenet küldése és fogadása két különböző aszinkron esemény. Az instance-ra vonatkozó további eseményeket a tengelyére helyezett akciók, időzítők és feltételek alkotják.

Nincs általános időtengely egy MSC ábrán, az instance tengelyek mentén, fentről lefelé tekintjük az idő haladását, amelyre az időlépték nem meghatározott, minden esemény ideje az összes instance tengely mentén folyamatos, az értékes információ az idősor szerep.

A nagy rendszerek MSC leírását megadhatjuk globális állapotok leírásával, amelyeket köztes állapotokra bonthatunk, majd az MSC leírásokat egyesítjük egy globális feltételrendszer mellett. Ennek eszköze a HMSC, amely egy irányított gráf az MSC leírások összefűzésére. Hátránya a paraméterátadás hiánya.

Az MSC diagramok hasznosak a protokollok teszteseteinek meghatározásánál, ui. ha ugyanazt a változó és adattípus jelöléseket használjuk átjárhatóvá válik a szöveg és ábra specifikáció a tesztcél szintjén.

1. TTCN (Tree and Tabular Combined Notation)

A TTCN, amelyet az ITU-T X.292-es [13] szabványában ajánl, egy informális jelölésrendszert vezet be implementációk konformancia teszteléséhez, mely legjobban OSI modellt követő protokollok absztrakt tesztkészleteinek elkészítéséhez használható. Az absztrakt tesztkészlet a tesztesetek, –opcionálisan- speciális tesztmódszerekhez tartozó tesztlépések halmazából és az ezekhez szükséges komponensekből, deklarációkból áll, generálása a tesztcélokból történik.

A TTCN-el történő tesztelés során a teszt alatt álló implementáció (IUT) fekete doboznak tekintendő, mely interfészeken, ún. PCO-kon keresztül kommunikál környezetével. Minden PCO két korlátlan FIFO (first-in-first-out) sorral rendelkezik, egy a bemeneti események küldéséhez, egy pedig a rendszertől kapott jelek fogadásához. Feladatuk a rendszer vezérlése és megfigyelése, a definiált interfészeken keresztül, mely protokollok esetén ASP-k és PDU-k küldését illetve fogadását jelenti. A tesztelés során az IUT tesztesemények sorozatára adott válaszait vizsgáljuk.

A TTCN-ben felépített tesztkészlet [20] tartalmazza a tesztlépések referenciáit a PICS és PIXIT dokumentumokban; a deklarációs részt, amelyben megadja a kommunikációs üzeneteket, változókat, időzítőket, adatstruktúrákat és a fekete doboz interfészeket; a korlátok részt, melyben adottak a vizsgálathoz szükséges adatok, korlátok (megadhatók az ASN.1 adatleíró nyelvben); és a dinamikus viselkedés leírását, amely a tesztesetek és tesztlépések konkrét viselkedésének leírása viselkedési fákkal ábrázolva.

Mind a tesztesetek, mind a tesztlépések, mind pedig a default viselkedés a viselkedési fával, vagy azzal ekvivalens táblázattal adható meg, amelyek származtathatók, részben automatikusan az SDL specifikációkból.

A fa levelein ítéletet kell hoznunk. Ezek az ítéletek szabják meg a teszt kimenetét, tehát, hogy az IUT az elvártnak megfelelően viselkedett vagy sem.

Az ETSI a kommunikációs protokollok terén az ISO/IEC 9646 TSS specifikációját további ajánlásokkal egészíti ki, amely szabályrendszert ad kommunikációs protokollok tesztkészlet struktúrájának felépítésére. A tesztkészlet struktúra szabályok követésének azért van jelentősége, mert az újabb ETSI szabványok SDL, MSC és TTCN leírásokat is tartalmaznak.

1. ASN.1 (Abstract Syntax Notation One)

Az ASN.1 ( Abstract Syntax Notation One) nyelv egységesített adattípus deklarációt alkalmazva az egyes specifikációk átjárhatóvá válnak a tervezés, a validálás és a tesztgenerálás fázisaiban,. Az ASN.1 nemzetközileg szabványosított [11] jelölésrendszer adattípusok formális leírására, eredetileg az OSI alkalmazási rétegéhez tartozó protokollok adatstruktúráinak definiálására fejlesztették ki.

A nyelv alkalmas adattípusok (data type), értékek (values), korlátok (constraints) kódolására. Nem programozási nyelv, végrehajtható utasításokat nem tartalmaz [12]. A kódolás feladata a modulokkal leírt adatspecifikáció olyan formába hozása, hogy egyértelműen azonosítható legyen a vételi oldalon. Ehhez a szabvány három szabályhalmazt definiál, éspedig a típusok és a típusból leszármaztatható értékek reprezentációi (basic encoding rules), az opcionális mezőt (canonical encoding rules) valamint az azonos típusú mezőt (distinguished encoding rules) tartalmazó struktúrák szerkesztésére. A kódolási szabályokat az X.690-es szabvány [5] tartalmazza.

Példa az INRES szolgálati primítivek adatleírására ASN.1 modulban:

INRES datatype Module DEFINITIONS ::=

Sequencenumber ::= ENUMERATED {0,1};

ISDUType ::= ENUMERATED {ISDU};

IPDUType::= ENUMERATED { CR, CC, DR, DT, AK};

SimplePDUType ::= IPDUType;

DTPDUType ::= SEQUENCE {

Id IPDUType DEFAULT DT;

NUM Sequencenumber;

Data ISDUType};

AKPDUType ::= SEQUENCE {

Id IPDUType DEFAULT AK;

Num Sequencenumber };

MSDUType ::= CHOICE {

cr SimplePDUType DEFAULT CR

cc SimplePDUType DEFAULT CC;

dr SimplePDUType DEFAULT DR;

dt DTPDUType;

ak AKPDUType;}

END

6. Formális nyelvek egymásra épülése a rendszerfejlesztésben

Célszerű az, hogy a rendszer viselkedését SDL-ben úgy írjuk le, hogy az üzenetváltáshoz ASN.1-es adattípusokat használjunk [21], mivel a TTCN eleve megengedi az ASN.1 típusdefiniálást. Az ASN.1-es deklarációkat a fordító lefordítja SDL-es típusra, gyorsítja és egyszerűsíti az átjárást a TTCN modulokkal a validálás és teszteset generálás folyamataiban. A fejlesztők 2002 –ig az XML/ASN.1 fordítót ígérik [22].

A 6. ábra szemlélteti a rendszer életciklusaiban alkalmazható formális nyelvek kapcsolatát, és azt az egységesítési folyamatot, amely jelentősen növeli a fejlesztés hatékonyságát és egyben kiterjeszti a formális nyelvek alkalmazását az ipari automatizálás több területére[14, 18].

3. Rendszerfejlesztés folyamata formális módszertannal

A formális módszertannal fejlesztve, (7. ábra) a rendszerfejlesztés elemzés fázisában a rendszer feltárására – a követelmények elemzésére és specifikálására - az objektum-orientált tervezést alkalmazzuk. Célszerű az Unified Modeling Language (UML) alkalmazása, amelynek elterjedt irodalma van.

Az elemzés során az UML nyelvvel együtt alkalmazzuk az MSC nyelvet, az objektumok viselkedésének feltárására és ábrázolására.

7. ábra: A formális módszertan alapú rendszerfejlesztés menete és fázisai

A koncepciós tervben MSC diagramokkal ábrázoljuk a rendszer eseményeit, ez konvertálható SDL-be, az elemzés során feltárt adatokat ASN.1–ben adjuk meg, amelyek így beépíthetők az SDL és TTCN specifikációkba is.

A tervezés fázisban az UML-ről áttérünk az SDL nyelvre, amely objektum orientált és absztrakt adattípusokat definiál, így a tervezés során a feladatra koncentrálhatunk, nem kell a megvalósítás programozási környezetének belső ábrázolására figyeljünk. A rendszerelemzés objektum modellje alapján megszerkesztjük az áttekintő rendszertervet (alrendszerek és funkcionális részeik hierarchikus ábrázolása), ábrázoljuk az SDL rendszer és blokk diagrammokat. A tervezés során az MSC-ben szerkesztett kölcsönhatás diagrammok szolgálnak az esettanulmány diagrammok előállítására (MSC/TTCN), amelyek az SDL diagrammok validásának fontos eszközei.

Az implementálás fázisban a tervezésben előállított tesztadatokkal elvégezzük a konformancia tesztelést. A legtöbb SDL fejlesztő eszköz tartalmazza a szintaktikai és szemantikai elemzést, a verifikálást és szimulációt, valamint a kódgenerátort, amellyel megszerkeszthető a futtatható kód különböző célú környezetre. Alkalmazásával jelentősen lecsökken a teljes szoftverfejlesztési ciklus ideje és jelentős költségcsökkenést eredményez a tervezés validálása, az automatikus forráskód generálása és tesztelése, az implementáció előtti szimuláció lehetősége.

Igen fontos szempont a formális módszertan alkalmazásában [14], hogy ha a rendszer egyes elemei nem tervezhetők SDL-ben, az objektumok tervezését tagolhatjuk a különböző jelölésrendszerek koncepciója szerint. Például ha a megvalósítandó rendszer tartalmaz Windows alapú felhasználói felületet, sokkal könnyebb megtervezni céleszközzel, vagy ha a rendszer adatbázist tartalmaz, hatékony az objektum-orientált adatmodellezés, de az adatbázis tervezésére és implementálására valamely ODBC-t támogató kereskedelmi adatbázis-kezelő rendszert kell alkalmazni. A 8. ábrán láthatjuk a rendszerfejlesztés menetét, ha a formális módszertannal együtt más módszereket vagy jelöléseket is alkalmazunk.

8. ábra: A fejlesztés menete, ha a rendszer objektumai közt alkalmazói felületek és/vagy adatbázis-interfészek is vannak.

3. Formális módszertant támogató technológiák és Case eszközök

Az egyes formális nyelvek fejlesztő környezeteként számos kereskedelmi és szabadon használható fejlesztő eszköz van forgalomban, amelyekről tájékozódhatunk a www.sdl-forum.org címen. Kevesebb azon eszközök száma, amelyek integrálják a teljes életciklus lefedéséhez szükséges formális nyelvek implementációit. Ebben az előadásban ismertetem tanszékünk távközlési szakirányának laboratóriumában alkalmazott eszközt, a Telelogic Tau 4.1 fejlesztőeszközt [14], amelyet szerte a világban közel 700 cég több mint 6000 fejlesztője alkalmaz, többnyire a telekommunikációs szektorban [9].

A Telelogic Tau 4.1 a rendszerfejlesztés teljes életciklusára tartalmaz készletet. Az UML készletében (UML Suite) egyesíti az UML grafikus jelölését a tervezés és fejlesztés SDL-es koncepcióival az SDL készletből. A TTCN készlettel egy komplett fejlesztő környezetet kapunk a fejlesztés, szimuláció és teszt fázisokra a kommunikáló alkalmazások széles skálájára.

A Telelogic Tau 4.1 fejlett projekt ellenőrző funkciókat kínál: interaktív diagramm szerkesztés; a tervezés validálása; automata teszteset generálás és teszteset szimuláció, és végrehajtása; automatikus forráskód generálás; szimuláció, amelyhez nem kell megírni a telepítő nyelvében a forráskódot.

A mobil IP alklamazások fejlesztésére is lehetőséget ad a Telelogic a közeljövőben. Tervezik a WAP szerver készlet beágyazását a Tau fejlesztőbe, kezdetben két szállító rétegre, az SMS a nagytávolságú kommunikációra, a Bluetooth a rövidhullámű rádiós kommunikációra.

5. Összefoglalás

A fejlesztésben a formális módszerek egyik lényeges célja a specifikáló, leíró és tesztelő folyamatok formális nyelveken való megfogalmazása, amelyből hibátlan automatizálható forráskódot állíthatunk elő, akár több forrásnyelvi környezetre is. A formális nyelvek fejlődésében az utóbbi 10 évben megjelentek azok az egységesítési szándékok és megvalósítások, amelyek jelentősen növelték az egymásba ágyazott heterogén rendszerek specifikálásának hatékonyságát és egyben kiterjeszttették a formális nyelvek alkalmazását az ipari automatizálás több területére.

A formális módszertan alkalmazása során új hatékonysági kérdések tevődtek fel, amelyek megválaszolása az oktatási és kutatási feladatainkban megoldásra vár, éspedig OO és SDL hatékony kombinálására meg kell fogalmazzunk módszereket az OO típusok megválasztására és az OO modell struktúrájára oly módon, hogy az SDL koncepciót mennél jobban támogassák.

Köszönetnyilvánítás

A cikkben ismertetett munkát az OTKA 29556 számú kutatási szerződés támogatta.

Rövidítések és fogalmak jegyzéke

ASP Abstract Service Primitive, szolgálati primitívek a kommunikáció és adatszállítás formátumait, az alábbi négy típusúak lehetnek szolgálattól függően: req – request, a felsőbb réteg ennek a segítségével kér szolgáltatást; ind – indication ez jelez a felsőbb rétegnek, ha valamilyen esemény történt, amit egy másik oldali request idézett elő; res – response a felsőbb réteg ezzel válaszol az indication-re; cnf – confirm ez jelzi, hogy a request-el kért szolgáltatás sikeresen véget ért

ASN.1 - Abstract Notation One

ETSI - European Telecommunications Standards Institute

FIFO - First In First Out

GSM- Global System for Mobile Telecommunication

HMSC - High-level Message Sequence Chart

ITU-T –International Telecommunication Union, Telecommunication Standardization Sector

IUT - Implementation Under Test, tesztelés alatt álló implementáció

MSC - Message Sequence Chart, üzenet idősor diagram

ODBC - Open DataBase Control, nyitott adatbázis interfész különböző operációs rendszerek számára

OO –Obiect Oriented

OSI –Open System Interconnection, nyitott rendszerek összekapcsolása, ISO szabvány, ITU-T is elfogadta

OTKA –Országos Tudomány és Kutatásfejlesztési Alap

PCO –Point of Control and Observation, az ATM része, az IUT megfigyelése ezeken a pontokon keresztül történik

PDU –Protocol Data Unit, protocol adategység

PICS –Protocol Implementation Conformance Statement, protokoll viselkedés megfelelése valamely szabványnak

PIXIT –Protocol Implementation eXtra Information for Testing

Protokoll –szabályrendszer, amely alapján az egyes rendszerek üzenetet cserélnek

SDL –Specification and Description Language

SMS – Short Message Service , a GSM egyik szolgáltatása, rövid üzenetek átvitelére szolgál

TSS –Test Suite Structure, tesztkészlet struktúra

TTCN –Tree and Tabular Combined Notation, formális leíró nyelv tesztkészlet generálására

UML –Unified Modelling Language, objektum elvű modellezés elterjedt nyelve, az Obiect Management Group 1997-es szabványa, létező módszerek összhatásából született

Irodalomjegyzék

További információ és levelezési cím:

Veszprémi Egyetem, Információs Rendszerek Tsz. 8201 Veszprém, Pf. 158.

Név: Harmatné Medve Anna

Teljes postai levelezési cím: 8200 Veszprém, Egyetem út. 10.

E-mail cím: medve@almos.vein.hu