Az elosztott és valós idejû rendszerek tervezése SDL -ben


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

apapp@irt.vein.hu

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

medve@almos.vein.hu


A hálózatok mindennapos életben való megjelenése és rohamléptékû terjedése egyre nagyobb terhet ró a tervezõkre, hiszen nem elég, hogy a tervezés olcsó, hatékony és gyors kell legyen, hanem a rendszer hibátlanul és a felhasználói követelményeknek megfelelõen kell müködjön. Elõtérbe kerülnek a validálás eszközei és egyre fontosabb szempont az újrafelhasználhatóság és az automatizált kódolás lehetõsége is. Az SDL (Specification and Description Language) formális nyelv alkalmazásával érvényesülnek a fenti követelmények. Habár az SDL-t a telekommunikációs rendszerek tervezésére fejlesztették ki, a nyelv mai fejlettségi szintjén alkalmassá vált tetszõleges valós idejû, interaktív elosztott rendszer formális nyelven való megfogalmazására és validálására. Az elõadás során egy esettanulmány szemlélteti a valós idejû és elosztott rendszerek tervezését az SDL fejlesztõi környezetében.

Kulcsszavak: protokolltervezés, elosztott és valós idejû rendszerek tervezése, SDL


Mivel a valós-idejû rendszerek alkalmazási területe a mindennapi életben fokozatosan növekszik, a velük szemben támasztott minõségi elvárások egyre fontosabbak mind az egyének, mind a cégek és a társadalom számára. Ugyanakkor a megnövekedett igények a rendszerek bonyolultabbá válásához is vezettek, megnehezítve ezzel a kitûzött minõség elérését. Mivel a legtöbb minõséggel kapcsolatos probléma a rendszer viselkedésének bonyolultságából ered, kell egy módszer, [17] amellyel megadható egy olyan formális definíció meghatározása, amely érthetõen és tömören fogalmazza meg a funkcionális viselkedést, s amely ezen felül a megvalósítás módjától függetlenül értelmezhetõ, vizsgálható. A funkcionális tervezés a kiindulási pont a minõség meghatározásakor, mert már a tervezés kezdeti szakaszában segíti megérteni a rendszer viselkedését. Szintén ez az alapja az implementációs tervezésnek is, ahol a funkcionális terv felhasználásával történik a megvalósítás, mi több a funkcionális tervezés elgondolásainak nagy részét hatékonyan be lehet építeni az implementációba. A CCITT (Comité Consultatif International Télégraphique at Téléphonique – Nemzetközi Távközlési Egyesület a mai ITU-T) [3] létrehozta az SDL-t (Specification and Description Language – specifikáló és leíró nyelv) a funkcionális tervezés segítésére. Ez egy nemzetközileg szabványosított nyelv, amelyet számos esetben sikerrel alkalmaztak a kis vezérlõ egységek fejlesztésétõl kezdve a nagyon bonyolult kommunikációs rendszerekéig. . Az SDL objektum-orientált képessége megadja a lehetõséget a komponálás és az újrafelhasználás megvalósítására a tervezés szintjén. Az SDL által nyújtott hierarchikus felépítés, az egymásba ágyazott rendszerek tervezésének lehetõsége, a verziókövetés egyszerûbb lehetõsége, az automatikus kódgenerálás (kb. 85-90 %-a a teljes programnak), a validálás, valamint ennek visszacsatolhatósága (mely tovább javítja a már amúgy is igen magas mértékû automatizáltságot) mind-mind az SDL mellett szól, s amely biztosítja a „praktikus fejlesztõi hozzáállást”.

Az ITU (International Telecomunication Union) Z.100, Z.105, Z.107 és Z109 ajánlásai alapján fejlesztették [3]. A grafikus és szöveges változatát is 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. 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 jelutakon. (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.

Az SDL alkalmazásának feltétele, hogy elemezzük a specifikálandó rendszer müködését, határozzuk meg a felhasználói és rendszerkövetelményeket, majd ezután tudjuk a rendszert SDL hierarchiákba szervezni, és specifikálni a komunikációs útvonalakat és a kommunikáló automatákat. Terjedelmi okokból az elemzés dokumentálására nem, csak a követelmények meghatározására térünk ki.


Esettanulmány 1.: a rendszer mûködésének elemzése és a felhasználói követelmények feltérképezése

Az esettanulmányban egy pénzkiadó automatát modellezünk, mivel a bankautomaták kivétel nélkül olyan hálózatok részei melyek egyidejûleg több felhasználó és egy központ közötti kommunikációt tesznek lehetõvé. Azért választottuk az OTP pénzkiadó automatát az esettanulmány tárgyává, mert elterjedésük alapján müködésüket ismertnek tekinthetjük, így nagyobb figyelemmel öszponrosíthat az olvasó a kommunikációs események és elemeik meghatározására és az SDL jellemzõire.

A rendszer rövid leírása a kommunikációs események felsorolásával:

Az automatához lépve az elsõ feladat a kártya behelyezése, aminek hatására megkezdõdik a kapcsolatfelvétel a bankkal. A hirdetések futását nem lehet megszakítani, és a kártyát is csak akkor fogadja el a gép, ha éppen nem fut reklám. Az elsõ választási lehetõség során meg kell adnunk a használni kívánt nyelvet, majd pedig az azonosítás hitelesítéséhez a PIN kódot. Abban az esetben, ha az ellenõrzés sikertelen volt, még kétszer próbálkozhatunk. A harmadik hibás kód megadása után a gép elnyeli a kártyát. Ha jó kódot adtunk meg – tehát az ellenõrzés sikeres volt -, a mûvelet kiválasztása követkzik. A választási lehetõségek annak függvényében változnak, hogy milyen típusú az automata (például nincs borítékkiadó nyílás, ezért nincs pénzbetételre lehetõség), illetve hogy egyszerre hányan próbálnak meg ugyanahhoz a számlához hozzáférni (ketten nem módosíthatják egyszerre a számlát – konzisztencia megõrzése miatt). A képernyõn megjelenõ utasítások követésével adható meg a kívánt mûvelet, ezután következik a tranzakció tényleges végrehajtása. Az automata elõször a kártyát, majd a pénzt és/vagy a nyugtát adja ki. Amíg a kártyát (és a pénzt) el nem vesszük, a gép sípolással figyelmeztet, hogy ott ne felejtsük valamelyiket.

Esettanulmány 2.: A rendszer követelmények feltérképezése

A kommunikáló egységek:A pénzkezelõ automata a végrehajtó egységei szerint több részre bontható. Eszerint megkülönböztetjük a kártyaolvasót, a pénzkezelõt, a monitort és a nyomtatót. Ezek azok a részek, amelyek a felhasználó által is ismertek, de ezeken kívül még más, fõleg vezérlõ feladatot ellátó egysége is van az automatának. Az ilyen alkotóelemekbõl álló gép a valóságban és a modellben egyaránt alkalmas egyenleglekérdezésre, átutalásra (elõzetes szerzõdés megkötése után), pénzfelvételre, és egyes esetekben pénzbefizetésre is. Mivel az automata a rendszer vevõ oldali részét képezi, az adó oldalnak a bank feleltethetõ meg. A bankot alkotó rendszer fizikailag egy egységnek tekinthetõ (mivel egy helyen helyezkedik el), valójában azonban ez is több részre bontható. Így megkülönböztetjük a központi vezérlõt (amely tovább bontható egy tranzakció-kezelõre és egy listakezelõre) és magát az adatbankot (ami szintén két részbõl áll, ezek pedig a szolgáltatás –jogosultság ellenõrzése és a szolgáltatás mögötti adatbázis mûveletek összessége).

A központi vezérlõ és a bank egy helyen található, ezért ezek összekötése a legegyszerûbb módon, vezetékezéssel valósítható meg, míg az automaták és a központi vezérlõ összekapcsolása a távolságtól és a természeti adottságoktól függõen lehet szintén vezetékes, illetve vezeték nélküli (például mûholdas, mikrohullámú stb.). Most, hogy már ismerjük a kommunikáló összetevõket, nézzük meg egyenként ezek feladatait:

A monitor tartja a kapcsolatot a felhasználó és a gép között, ugyanis ezen jelennek meg a kérdések, választási lehetõségek, mellyel az általunk kívánt mûveletet tudjuk kiválasztani. Ez az összeköttetés egyirányú

A nyomtató feladata, hogy a kijelölt mûvelet után a bizonylatot kinyomtassa, ugyanis ez tartalmazza a tranzakció helyét, idõpontját, fajtáját, a bankkártya számát valamint az összeget. A kommunikáció itt is egyirányú.

A pénzkezelõ egység egyszerre több feladatot is ellát. Az egyik ezek közül a pénz kezelése, ami valójában csak a kiadását jelenti, mert a betétel – amely egyben a második tevékenység, amit elvégez – nem közvetlenül pénz, hanem borítékos formában történik. Itt már szükség van a kétirányú kapcsolatra. A borítékok a gépek kiürítése után jutnak a bankba, és a pénz majd csak a tartalmuk ellenõrzése után kerül a számlára.

A kártyaolvasó a kártya adatainak kiolvasását hajtja végre. Bár ez a legfontosabb feladata, azért van neki még egy, bár ezzel a felhasználók (szerencséjükre) nem sokat találkoznak. Ez pedig nem más, mint a kártya elnyelése. Ez olyan esetekben fordulhat elõ, mint például rossz PIN kód megadása, lejárt kártya használata, vagy ha nem vesszük el idõben a kártyát (biztonsági ok). Ennél az egységnél is szükséges a kétirányú kapcsolat megléte.

A tranzakció-kezelõ feladata a kapcsolat tartása az automata és a bank között. Ez fõleg az egyik irányból érkezõ adatok továbbítását jelenti a másik irányba (tehát itt is elengedhetetlen a kétirányú kapcsolat). Ha azonban a feladata ilyen egyszerû volna, megkérdõjelezhetõ lenne a szükségessége. Szerencsére azonban nem így van, hiszen van olyan eset, amikor nem változatlanul kell az adatokat továbbküldeni. Ez olyankor fordul elõ, amikor egyszerre több számlatulajdonos akar hozzáférni különbözõ kártyával ugyanahhoz a számlához. Ez persze nem engedhetõ meg, hiszen például ugyanazt a pénzt egyszerre csak egy ember veheti fel. Emiatt ez az elem szoros kapcsolatban kell, hogy álljon a központi vezérlõ másik elemével, a listakezelõvel.

A listakezelõ szerepe igen egyszerû: az éppen használatban levõ számlákat, és a hozzájuk tartozó kártyákat tartja nyilván. Ez úgy valósul meg, hogy létrehoz az adatbázisában egy számlaszámot, mögötte pedig felsorolja azokat a kártyákat, amelyek használatban vannak.

Abban az esetben, ha valamelyik felhasználó végez, az általa használt kártya száma lekerül a listáról, és ha az az utolsó volt, megszûnik a hozzá tartozó számlaszám bejegyzése is. Fontos megemlíteni, hogy ha egyszerre többen férnek hozzá egy számlához, és az a felhasználó fejezi be elõször a tevékenységét, aki teljes körû hozzáféréssel rendelkezett a számlához, akkor a következõ felhasználó – annak ellenére, hogy már nem elsõként fog a számlához hozzáférni – ismét teljes hozzáférést fog kapni.

Az ellenõrzés a hozzáférések jogosultságának ellenõrzését végzi. A kapott kártyaszámot összeveti az általunk beírt PIN kóddal, majd eldönti, hogy jó vagy rossz-e a kód.

Végül az utolsó egysége az adatbázis-rendszer, mely adatbázismûvleteket végzi, kezeli az egyes számlaszámokat, valamint a rajtuk levõ összegeket. Szintén a feladatai közé tartozik a beérkezõ mûveletek végrehajtása, valamint a tranzakciók során bekövetkezõ egyenlegváltozások bejegyzése az adatbázisba. A jelen esettanulmányban ez a mûködés nincs kiolgozva, az adatbázis-rendszerrel csak kommunikálunk

Az elosztott müködés jellemzõi: A központi vezérlõ segítségével lehetõség nyílik arra, hogy egyetlen bankhoz egyszerre több automata is csatlakozhasson, és eközben nem fordulhat elõ olyan eset, hogy egyszerre többen módosítják az adatbázis ugyanazon részét. Azonban az automaták a város illetve az ország területén elszórtan helyezkednek el, így a területi adottságok miatt nem valósítható meg, hogy mindegyikük oly módon csatlakozzon a bankhoz (azon belül is a központi vezérlõhöz), amely a meghibásodást teljes mértékben kizárná. Ezért a rendszert fel kell készíteni az olyan esetekre, amelyek során adatvesztés állhat elõ. A bank célja, hogy a hálózat úgy mûködjön, hogy gond esetén õt semmi, a felhasználót pedig minél kisebb kár érje.

A lehetséges kommunikációs zavarok: következõ részben áttekintjük, hogy a rendszer egyes részein adott irányban milyen kommunikációs problémák adódhatnak, valamint hogy azok milyen következményekkel járnak.

  1. megszakad a kapcsolat a felhasználó és az automata között

Ez akkor fordulhat elõ, ha az elõre definiált idõ alatt a felhasználó nem nyom meg semmilyen gombot sem. Ekkor lejár az idõzítõ, és az automata elnyeli a kártyát. Ennek az az oka, hogy ha valami miatt õrizetlenül maradna a kártya, akkor nehogy vissza lehessen élni vele.

Ha a felhasználó nem veszi el a rendelkezésére álló idõ alatt a kiadott kártyát – és pénzfelvétel esetén a pénzét –, akkor az elõzõhöz hasonlóan visszahúzásra kerül a kártya (vagy a pénz).

  1. megszakad a kapcsolat az automata és a központi vezérlõ között

A bankban (pontosabban az adatbázisban) nem történik változás, ugyanis nem jut el odáig a kérés (a központi vezérlõ nem nyugtázza az igény vételét). Az automata idõzítõje lejár, ekkor elõre meghatározott számú próbálkozást hajt még végre, s ha ezek sem járnak sikerrel, törli a tranzakciót, értesíti a felhasználót a hibáról, és kiadja a kártyát.

A tranzakció sikeresen megtörtént, a szükséges egyenlegmódosítások megtörténtek, azonban ennek ténye nem jut el az automatáig. A központi vezérlõ idõzítõje lejár, néhányszor újrapróbálkozik, majd sikertelen esetben feladja a próbálkozást. Közben az automata idõzítõje is lejár,

Itt léphet fel az elsõ igazi probléma: nem tudja az automata, hogy sikerült-e mûvelet, azaz például kiadhatja-e a pénzt vagy sem. Úgy járunk el, hogy a bankot nem éri kár, a kártyatulajdonost csak ideiglenesen.

  1. megszakad a kapcsolat a központi vezérlõ és a bank között

Mivel a központi vezérlõ és a bank ugyanabban az épületben, ezenfelül ugyanabban a teremben van, esetleg az egész egy géppel van megvalósítva, annak a valószínûsége, hogy köztük a kapcsolat megszakad, minimális. Itt nincs meg annak a lehetõsége, hogy például egy útbontás során elvágják az összekötõ kábeleket, ezért a köztük lévõ adatvesztést nem vizsgálnám.


Esettanulmány 3.: az SDL tervezésének bemutatása

Most, hogy már ismerjük a rendszer egyes részeinek feladatát, illetve azt, hogy mire kell figyelni a helyes mûködés eléréséhez a fenti rendszer tervezésekor, áttekintjük az SDL megvalósítás során alkalmazott hierarchia-szinteket, valamint azt, hogy miért is van ezekre szükség.

Rendszerkövetelmények csoportosítása:

Összetett rendszerek tervezésekor fontos szerep jut a különbözõ hierarchia-szinteknek, hiszen segítségükkel a tervezõ a különbözõ funkciók vagy kommunikációs események szerint csoportosítani tudja a tervezendõ rendszer egyes elemeit.. A könnyebb átláthatóság mellett a másik fõ szempont a már kész, megtervezett elemek újrafelhasználhatósága. Ennek olyankor van szerepe, mikor a rendszert olyan funkcióval szeretnénk kiegészíteni, amelyhez hasonlót, esetleg megegyezõt már terveztünk. Például a fenti esettanulmány megvalósításánál a zárolt mûveletekhez való hozzáférés megvalósításakor elegendõ volt a már elkészített, minden mûveletet engedélyezõ folyamatot módosítani, a változtatás pedig csak a tiltott tranzakciók törlését jelentette. A rendszer további funkciókkal való bõvítése is hasonlóan gyorsan elvégezhetõ, hiszen elegendõ lesz az új mûvelet meghatározása, valamint a választhatóságának beállítása az engedélyezett mûveletek között.


  1. rendszer szint

A hierarchia legfelsõ fokán az SDL-ben a specifikálandó objektumot teljes egészében jelképezõ rendszer áll, amely tulajdonképpen a valós világ vizsgált része. Rendszerbõl csak egy van. Mindaz, ami nem tartozik a rendszerhez, annak környezetét alkotja, errõl a környezetrõl rendszerünk feltételezi, hogy ismeri az SDL-t, vagyis SDL-szerûen viselkedik..


2. ábra Az ATM rendszer SDL rendszerdiagramja

A rendszert egy téglalap jelöli bal felsõ sarkában a rendszer nevével a system kulcsszó után. A téglalap élein kívül van a rendszer környezete, a téglalapban a rendszer részeit ábrázoló blokk-kölcsönhatás, amely a blokkokból és az õket egymással és a környezettel összekötõ csatornákból áll.A rendszerszintû deklarációbant adjuk meg a rendszerre vonatkozó adattípusokat, jeleket és jellistákat. Az esettanulmányban az ATM nevû rendszer kommunikáló automatáit funkciók szerint csoportosítottuk a Bank, a KozpontiVezerlo és az Automata blokkokban.

  1. blokk szint

A hierarchia következõ fokán a blokkszint található. Minden egyes blokk a rendszer egy alrendszerének vagy funkciójának feleltethetõ meg. A processz-kölcsönhatással adjuk meg azt, hogy milyen és hány processzbõl áll, azokat milyen módon kötik össze a jelutak, valamint, hogy a jelutak hogyan kapcsolódnak a blokkhoz vezetõ csatornákhoz. Szintén itt kell megadni a blokkon belüli típus, jel, jellista stb. deklarációkat.

A rendszerhez hasonlóan a blokkot is egy téglalap jelöli, bal felsõ sarkában a blokk nevével a block kulcsszó után. A rendszerszintû deklaráció helyen itt a blokkszintû deklaráció következik.

Az Automata blokk processz-kölcsönhatás diagramját a KartyaOlvaso, a PenzKezelo, a Monitor, a Nyomtato és a Vezerlo processzek alkotják a közöttük lévõ jelutakkal, valamint a jelutak kapcsolódási pontjával a csatornákhoz, amelyek a blokkot a többi blokkal összekötik

Minden típust, jelet és jellistát, amit blokkszinten használunk és nem a rendszerszinttõl örököltünk, itt kell megadni. A szerver oldali blokkok automatái a bank-mûveleteket tartalmazó Bank blokk egymással kommunikáló automatái ( az Ellenorzes és AdatBazis processzek) és az elosztott komunikációt vezérlõ KozpontiVezerlo blokk automatái ( TranzakcioKezelo, ListaKezelo)

3. ábra Az ATM rendszer kliens oldali funkcióit megvalósítóAutomata blokk SDL blokkdiagramja

  1. processz szint

A legalsó szinten a processz szinten az automaták állapotátmeneteit ábrázoljuk.

A processzekkel adjuk meg a rendszer dinamikus ábrázolását. A processzek környezetükkel jelutakon és, ha szükséges, csatornákon keresztül kommunikálnak jelek segítségével. Tehát a processznek képesnek kell lennie jelek fogadására és küldésére.


Az elõzõekhez hasonlóan a processzt is egy téglalap jelöli, bal felsõ sarkában a processz nevével a process kulcsszó után. Processz-szinten, ha jól dolgoztunk, már nem kell deklarálni jeleket és adattípusokat mert örököljük a felsõbb szintekrõl. Ezen a szinten deklaráljuk a változókat, az idõzítõket és eljárásokat.

4. ábra Az ATM rendszerAutomata blokkjának Vezerlo automatáját leíró SDL processz diagram hetedik lapja (pénzkiadást vezérlõ állapotátmenet ).



Az automaták viselkedését a processzgráffal kell megadni, amelyben szimbólumok jelõlik a bemenõ- és kimenõ jeleket, az akciókat (értékadás, eljáráshívás), a feltételek vizsgálatát, az állapotokat. Ezek egymás utáni sorrendjét az õket összekötõ nyíl határozza meg.

Az Automata blokk processzeinek felsorolásban megadtuk (2. blokk szint) a Vezerlo processzt és a 4. ábrán egy részletét láthatjuk A Vezerlo processz használatát a tervezés során felmerülõ idõzitési problémák tették indokolttá, nem felhasználói követelményeket, hanem rendszer követelményeket valósít meg. A pénzkiadó automata egyes elemei önálló mûködésre nem képesek, hiszen mindegyikük valamilyen külsõ (kliens és/vagy szerver oldali) jel hatására aktivizálódik, amelyek vezérlését és idõzítését a Vezerlo automata látja el. Az idõzítéssel az adatvesztést minimalizáljuk, segítségével az adatok újraküldésének szükségességérõl lehet dönteni. A pénzkiadó automata elemeinek vezérlésével csökkenthetõ a kliens-szerver közötti adatküldések száma, mely az adatoknak az igényelt szolgáltatás szerinti gyûjtögetésével oldható meg. Az adatbevitel során a felhasználó kérdés-felelet formájában adja meg, mit szeretne csinálni. Ebben az esetben az adatok soros módon kerülnek bevitelre, tehát egyszerre csak egy jel érkezik. Amikor az általa bekövetkezõ állapotváltozás lezajlik, csak akkor jön a következõ kérdés, és vele együtt a következõ válasz, azaz bemenet. Ellenben a szerver oldalon a Kozponti_Vezerlo funkció, egymással egy idõben, más szóval párhuzamosan érkezõ jel fogadására is alkalmas kell, hogy legyen. Ilyenkor az egyik jel feldolgozásra kerül, azonban a másikat a késõbbi felhasználásig el kell tárolni.

Az SDL processz-példányokkal valósítja meg a több azonos funkciójú kliens ( több pénzkiadó automata) modellezését, amelyek párhuzamos kiszolgálásához a szerver oldali modellben a jelek eltárolása-felhasználása mûvelettel gerjeszthetõ az állapotátmenet az ígényelt szolgáltatásnak megfelelõ osztott adatbázis-hozzáféréshez.

A mellékletben látható az esettanulmány teljes SDL leírása, a rendszerkövetelmények alapján jól követhetõ az elosztott rendszer kommunikációjának specifikációja.

További feladat az adatstruktúrák megadása. Az SDL megengedi a validálás idejéig halasztani a struktúrák megadását, ezzel több környezetre alkalmazható a specifikáció.


Ö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.

Az esettanulmányban láthattuk, hogy a feltérképezett felhasználói követelményekbõl rendszerezéssel és a kommunikáció optimalizálásával nyerhetõk a rendszerkövetelmények, amelyek alapján az SDL hierarchia elemek szerkeszthetõk, továbbfejlesztés esetén igen gyorsan és olcsón csak az érintett részek módosítása, kiegészítése szükséges.


Irodalomjegyzék

[1] ITU-T Recommendation Z.100 (1993): „CCITT Specification and Description Language (SDL)” including Annex F (formal definition) – scheduled for issue in 2000.

[2] ITU-T Recommendation Z.105 (1995) „SDL Combined with ASN.1 modules (SDL/ASN.1)”

[3] ITU-T Recommendation Z.107 (1999/11) „SDL with embedded ASN.1 (SDL/ASN.1)”

[4] ITU-T Recommendation Z.109 (1999/11) „SDL Combined with UML (SDL/UML)”

[5] Dr. Tarnay Katalin, Harmatné Medve Anna : A formális nyelvek szerepe a távközlési szoftverek fejlesztésében, Networkshop 2001

[6] www.telelogic.com/solutions

[7] www.etsi.org

[8] Andrew S. Tannenbaum: Számítógép hálózatok, Prentice-Hall International Ltd, 1999

[9] http://www.iec.org/tutorials/ttcn/index.html

[10] www.itu.org


Melléklet - Az esettanulmány SDL terve.


28