Újrafelhasználhatóság a protokolltervezésben+
Medve Anna, Papp András, Dr. Tarnay Katalin
Veszprémi Egyetem, Információs Rendszerek Tanszék
Abstract
Az újrafelhasználás-orientált fejlesztés alkalmazhatóságát mutatjuk be
a protokollfejlesztés formális nyelvi környezetében, valamint újrafelhasználás
elvének alkalmazását egy funkcióbővítés esetén.
Kulcsszavak: Újrafelhasználhatóság, SDL, MSC,
protokollfejlesztés
Bevezetés
A protokoll technológia folyamata - hasonlóan egy átlagos szoftveréhez - nem más, mint tervezés, megvalósítás, verifikálás, validálás, tesztelés lépések összessége. A távközlési szoftverek területén, és általában a valós idejű rendszerek esetében, igen nagy jelentősége van a megbízhatóságnak, mivel a tervezés/implementálás és validálás során feltárt hibák kijavításának költsége igen magas, ezért a cél a fejlesztéshez szükséges idő és a költségek lehető legtöbb helyen és módon történő csökkentése. A formális specifikáció beiktatása a megvalósítás elé, valamint a formális nyelvek alkalmazása [3] a tervezésre eredményesnek bizonyult. A formális specifikációnak van két nagyon fontos előnye: egyrészt jóval érthetőbben, világosabban mutatja be a specifikált rendszert, másrészt az így készített leírásokban sokkal könnyebben és hamarabb fellelhetők a hibák. A kilencvenes évek második felében, a szoftverfejlesztésben előtérbe került az újrafelhasználás elve. Cikkünkben bemutatjuk a protokolltervezés világát és az újrafelhasználás elvének alkalmazhatóságát a protokollfejlesztés formális nyelvi eszközeivel, majd egy esettanulmányban mutatjuk beazt.
Újrafelhasználás-orientált fejlesztés
A szoftverfejlesztési folyamatok többségében megtalálható a szoftverek újrafelhasználása. A projekten dolgozók ismernek olyan tervezést vagy akár kódot, amely hasonlít a kívánthoz, és a követelményeknek megfelelően módosítva felhasználják. Mindezt a gyors szoftverfejlesztés reményében, vagy az implementálás után keletkező új rendszerfunkciók automatizálása és a rendszerhez való illesztése érdekében már nem csak gyakorolják a fejlesztők, hanem megjelentek az újrafelhasználáson alapúló szoftverfejlesztési módszertanok, mint pl. a komponens alapú szoftvertervezés. Az újrafelhasználás-orientált fejlesztés költségei a komponensek integrációja és a rendszer validálása szakaszokban nagymértékben függ, a komponenselemzés és a követelménymódosítás szakaszok eredményeinek jóságától. Ugyanakkor a komponenskönyvtárak karbantartása és felhasználhatósága, valamint, a komponensek megtalálása és adaptálása további hatékonyság és költségnövelő probléma lehet. Az újrafelhasználás-orientált fejlesztés főképp a szakterület-specifikus nyelvek alkalmazása esetén járható sikeresen, a tervezési minták keretrendszerének kialakításával.[7] A kilencvenes évek második felében újabb fejlesztési paradigmák nyelvi és módszertani háttereit dolgozták ki, amelyek valójában építenek az újrafelhasználás-orientált fejlesztés elvére, mint pl. a minta alapú, a generator alapú, az adaptív, és az aspektus orientált fejlesztés elméletei. Alkalmazásukat a formális nyelvek fejlesztő környezetei támogatják.
Protokolltervezés formális módszerekkel
A formális nyelvek alkalmazásának hatékonysága a távközlési szoftverek fejlesztésében [3] nagymértékben függ a rendszertervezés és fejlesztő-környezet kölcsönhatásaitól.
Az 1. ábrán látható protokollfejlesztés menete:
1. ábra A
protokoll technológia folyamata
Az 1. ábrán jól látható, hogy a fejlesztés lépései nem különíthetőek el egymástól szervesen, hiszen a visszacsatolásoknak köszönhetően van olyan feladat, amelyet többször is végre kell hajtani, míg a kívánt eredményt el nem érjük.
Nézzük meg, mi is a legfontosabb különbség egy "átlagos szoftver" és egy protokoll tervezése között. A protokollok tulajdonképpen nem mások, mint két kommunikáló fél közti szabályok, amelyek az információcsere mikéntjét határozzák meg. Erre különböző szabványok vannak, amelyeket a protokoll tervezők be kell, hogy tartsanak. A másik fontos eltérés már az interfész specifikáció során is említett tény, amely a protokoll tervezéskor kiemelt szerepet kap.
2. ábra A protokollok és interfészek elhelyezkedése
A protokollok esetén a ki és bemenetek adottak a kapcsolódási pontokon (2. ábra), pont amiatt, hogy - ha arra van szükség, - az adott protokoll bármikor másikra cserélhető legyen. A funkcionális elemek rétegekbe szervezésével, és a rétegek közötti jól meghatározott szerepű interfészekkel a protokollok tervezése egyértelművé válhat.[1]
Mivel a valós-idejű rendszerek - s így a szintén ide tartozó protokollok - 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. Ezért fontos tehát egy olyan módszer kidolgozása [2, 5], amely segít a tervezésben résztvevőknek a dolgok egyszerűsítésében, miközben a minőség is ellenőrzés alatt tartható.
Bár a szoftverfejlesztés gazdag irodalommal rendelkezik [7], csak néhány foglalkozik közülük a valós idejű rendszerekkel [17]. Mivel a legtöbb minőséggel kapcsolatos probléma a rendszer viselkedésének bonyolultságából ered, a keresett módszer kritikus pontja 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. Ezen a folyamaton könnyít az a tény is, hogy a funkcionális tervezés elgondolásainak nagy részét hatékonyan be lehet építeni az implementációba, valamint az is, hogy a módszer használható útmutatókkal rendelkezik az implementációs tervezéshez.
A funkcionális tervezés segítésére hozta létre a CCITT (Comité Consultatif International Télégraphique at Téléphonique - Nemzetközi Távíró- és Telefon-tanácsadó Bizottság) az SDL (Specification and Description Language) formális specifikáló és leíró nyelvet. 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. A fejlesztés teljes folyamatát lefedő formális nyelvek szabványát találjuk a [8, 9, 10, 11, 12, 13, 14] irodalmakban, és ezek alkalmazását a [3] irja le. További irodalmak ebben a témában: [18, 19, 20, 21, 22]. Mivel az SDL a tervezésközpontúságot tartja szem előtt, megfelel a fenti kritériumoknak, ezen felül objektum-orientált képessége megadja a lehetőséget a komponálás és újrafelhasználás megvalósítására a tervezés szintjén. A tervezés-központú rendszerek készítésének lehetősége emeli ki ezt a módszert a többi közül.
SDL és MSC rövid ismertetése
A formális specifikáció lényege, hogy a rendszer elemeit és azok
viselkedését egy meghatározott szimbólumrendszer segítségével ábrázoljuk, majd
az így kapott leírást ellenőrizzük (verifikáljuk és validáljuk). A
következő lépésekben a tesztelés fázisainak automatizálásával (tesztesetek,
tesztcélok meghatározása, tesztsorozatok generálása) kapjuk a kód létrehozására
alkalmas implementációt, melyből végül automatikus generálással
elkészítjük a futtatható, hibamentes kódot. A specifikációknak megfelelő
szoftver előállítása a CASE eszközöknek köszönhetően akár több
forrásnyelvi környezetre is történhet (ezek sokféleségét csak a beépített
kódgenerátorok száma korlátozhatja). Az általunk is használt, formális
specifikációt alkalmazó leírónyelvek az MSC és az SDL, ezért a következő
fejezetek könnyebb érthetősége miatt nézzük meg ezek rövid ismertetését
[16].
3. ábra Az MSC diagram
Az MSC (Message Sequence Chart
- idősor diagram) nyelvet a rendszerkomponensek közti interakciók
leírására használják. Az MSC diagrammok (3. ábra) üzenet-folyamok formájában
ábrázolják a rendszer kommunikációját, így biztosítva annak áttekinthető,
világos leírását. Használatával jól modellezhető a rendszer időbeni
viselkedése, csak úgy, mint a környezet és a részrendszerek közti üzenetváltások.
A rendszer minden egyes elemét egy instance tengely ábrázolja. Az
MSC-beli instance-ok (példányok) az SDL (melyről a következő
bekezdésben lesz szó) processzeinek felelnek meg. A példányok három jól
elkülöníthető részből állnak: kezdő- és végszimbólumokból,
valamint az ezeket összekötő tengelyekből. E két utóbbi alkotja a
példány testét, míg a kommunikáció során használt üzeneteket az instance-ok
eseményterülete, azaz maga a tengely tartalmazza. Az üzenetek irányát -
értelemszerűen - a példányokhoz kapcsolódó nyilak iránya határozza meg. Az
üzenet küldése és fogadása (egy példányon belül) nem kell, hogy egy időben
történjen, a sorrendet az időtengely mentén való elhelyezkedésük határozza
meg. Az idő múlását fentről lefelé ábrázoljuk, ennek mértékegysége határozatlan,
igazából csak az időrendiség a fontos. Az instance-szal kapcsolatos
további eseményeket (időzítők, állapotátmenetek, feltételek) szintén
a példányok tengelyein ábrázoljuk.
Az SDL (Specification and Description Language - specifikáló és leíró nyelv) olyan formális szintaktikájú és szemantikájú leíró nyelv, amelyet a valós idejű, elosztott rendszerek - ezen belül is legfőképpen a kommunikáló rendszerek - leírására dolgoztak ki.
4. ábra Az SDL rendszer és blokk diagram
Használata során egyaránt lehetőség van a szöveges és a grafikus leírás alkalmazására. Az SDL alkalmas a rendszer szerkezetének, viselkedésének illetve az adatok szerkezetének együttes ábrázolására. Ipari használata széles körben elterjedt, és olyan kereskedelmi és nyilvános fejlesztőkörnyezetek támogatják, mint az SDT, Object-GEODE vagy a Cinderella.
Az SDL rendszerek hierarchia szerint blokkokba oszthatóak (4. ábra). Minden blokk blokkok illetve processzek halmazát tartalmazhatja. A rendszer viselkedése egymással kommunikáló kiterjesztett véges automatákkal modellezhető, minden egyes automatának pedig egy processz feleltethető meg. Az SDL processszek párhuzamosan futnak, és egymással jelek segítségével, aszinkron módon kommunikálnak. Az adatszerkezetek leírására az SDL előre definiált (beépített), illetve ezekből származtatott típusokat kínál, de lehetőség van absztrakt adattípusok használatára is. Az objektum orientált nyelvekhez hasonlóan az SDL is alkalmas a blokkok, processzek és jelek paraméteres definiálására. Az SDL legnagyobb előnye, hogy maga a specifikáció alkalmas szimulátorban és validátorban való futtatásra. Az elosztott rendszerek ilyetén való, implementálás előtti ellenőrzése (pl. holtpontmentesség szempontjából) nagy mértékben megkönnyíti a tervezési hibák korai fázisban történő felfedezését és kijavítását. Fontos megemlíteni, hogy az SDL lehetőséget nyújt a specifikációból automatikusan elkészíthető, futtatható kód előállítására.
Az SDL objektum orientált technológia jellegéből fakad egy másik, a szoftvertervezésben igencsak jól használható előnye: az újrafelhasználhatóság. Ez nem csak magának a kódnak az újrahasznosítására vonatkozik, hanem az adott módszer használata és a tervezés során korábban már hasznosnak ítélt tapasztalatokéra is. Az újrafelhasználással újabb, fontos előnyre tehetünk szert: rövidebb idő alatt megbízhatóbb és robosztusabb szoftvereket hozhatunk létre. Az újrafelhasználásnak - melynek tipikus példája a funkcióbővítés - különböző szintjei lehetségesek (a komponensektől kezdve az egész szerkezet felhasználásáig). Azonban a nagyobb részek használata sokkal összetettebb, bonyolultabb feladat, így jóval nagyobb figyelmet igényel, viszont ekkor lényegesen kevesebb a megvalósítandó új funkció. Ha a másik oldalról nézzük a dolgokat, a komponensek általában valamilyen rész- vagy célfeladatot hajtanak részre, így (felépítésüknél fogva) egyszerűbben beágyazhatóak a már meglévő rendszerekbe.
Az újrafelhasználhatóság elvének alkalmazhatósága SDL-ben, funkcióbővítés esetén.
Célunk a rendszer új funkciókkal való felruházása. A szoftver fejlesztése, karbantartása során nemcsak a kód optimalizálására van szükség, hanem az időközben felmerülő programhibák, hiányosságok kiküszöbölésére, illetve megszüntetésére is. Ilyen esetekben egy normál program bővítésekor az olykor több százezer soros programkódba kell belenyúlni, ami - ismerjük el - nem könnyű dolog. Jelen esetben azonban lehetőség van magának az SDL specifikációnak a bővítésére, amelyből aztán a szükséges programkódot újra lehet generálni. Ennek a legkézenfekvőbb módja az, hogy az új funkciókat a már fentebb ismertetett MSC segítségével megtervezzük, majd az adott SDL leíráshoz illesztjük oly módon, hogy az új ne befolyásolja károsan a már meglevő viselkedést.
A
következő alfejezet F. Khendek és D. Vincent Enriching SDL
Specifications with MSCs
című munkája alapján készült [4].
Az SDL funkcióbővítés elméleti háttere
Ennek eldöntéséhez azonban szükségünk van annak a definíciónak az ismeretére, mely segítségével meg tudjuk állapítani, hogy a két (az alap és a bővített) SDL specifikáció hogyan viszonyul egymáshoz. Ez pedig nem más, mint a viselkedés megmaradásának definíciója. Ez nagyjából annyit jelent, hogy ha S1 és S2 SDL leírások, akkor S2 kiegészíti S1-et akkor és csak akkor, ha S2 azokat a viselkedéseket produkálja a bejövő jelek hatására, mint S1 a környezettel való kommunikációja során, és nem következik be semmilyen nem-determinisztikus viselkedés. Más szóval S2 használható ugyanott, ahol addig S1, legfeljebb S2 több lehetőséget enged meg (elvileg ez nem okoz gondot, hiszen csak olyan jeleket kaphat, amelyeket S1 is le kell, hogy tudjon kezelni). A bővítés legegyszerűbb módja az, ha a rendszer bővítését a processzek bővítésével oldjuk meg. Azonban további definíciókra van szükségünk annak eldöntéséhez, hogy meg tudjuk ítélni, hogy a bővítésük után az általuk produkált viselkedések minden esetben megfelelőek-e. Mint ismeretes, a processzek viselkedését véges állapotú automaták írják le, ezért a bővítéssel kapcsolatos definíciók is az automatákkal lesznek kapcsolatosak. Emlékeztetőül álljon itt a definíciókban szereplő jelölések meghatározása:
- P processz, s állapot esetén, az s-be beérkező jelek halmazát az Input(s) kifejezés jelenti;
- P processz, s állapot esetén, az s-be beérkező és elmentett jelek halmazát a Save(s) kifejezés jelenti;
- P processz, s állapot, i bemenet esetén, az s-be beérkező i jel hatására végbemenő állapotátmenet során a kimenő jelek halmazát az Output(s, i) kifejezés jelenti, ahol a kimenő jelek elválasztására a '.'-ot használjuk;
- P processz, s állapot, i bemenet, seq kimenet (része az Output(s, i) halmaznak) esetén, az s-be beérkező i jel hatására végbemenő állapotátmenet során, seq kimenet mellett elérhető állapotok halmazát a NextState(s, i, seq) kifejezés jelenti; Fontos megjegyezni, hogy az SDL-ben lehetőség van arra, hogy adott bemenet esetén más-más kimenetek felhasználásával különböző állapotokba kerülhessünk. Erre az any kulcsszó nyújt lehetőséget.
- seq1 és seq2 kimenetek esetén, seq2 kibővíti seq1-et akkor és csak akkor, ha seq1 előtagja seq2-nek, például 1.1.0.1 kibővíti 1.1-et.
Ezek után pedig következzenek a megfelelő bővítések definíciói:
Állapotbővítés:
s1, s2 állapotok, s2 kibővíti s1-et akkor és csak akkor, ha:
-
Input(s1)
része Input(s2)-nek
-
Save(s1)
része Save (s2)-nek
-
minden i eleme
Input(s1), minden seq1 eleme Output(s1, i)-re
létezik seq2 eleme Output(s2, i)-nek úgy, hogy:
-
seq2
kibővíti seq1-et és
-
minden s2'
eleme NextState(s2, i, seq2)-re létezik s1'
eleme NextState(s1, i, seq1)-nek úgy, hogy s2'
kibővítse s1'-t
-
minden i eleme
Input(s1), minden seq2 eleme Output(s2, i)-re
létezik seq1 eleme Output(s1, i)-nek úgy, hogy:
-
seq2
kibővíti seq1-et és
-
minden s2'
eleme NextState(s2, i, seq2)-re létezik s1'
eleme NextState(s1, i, seq1)-nek úgy, hogy s2'
kibővítse s1'-t
Processzbővítés:
P1, P2 processzek, P2 kibővíti P1-et akkor és csak akkor, ha Initial(P2) kibővíti Initial(P1)-et, ahol Initial(P1) és Initial(P2) P1 és P2 processzek kezdeti állapotai.
A könnyebb áttekinthetőség és megértés miatt vegyük szemügyre a következő ábrákat (6. és 7. ábrák), amelyeken példát látunk arra, hogy P2 hogyan bővíti ki P1-et, illetve arra, hogy P4 hogyan és miért nem bővíti ki P3-at.
5. ábra Példa arra, hogy P2 processz hogyan bővíti P1-et
6. ábra Példa arra, hogy P4 miért nem bővíti
P3-at
A fentiek jelölések, definíciók és ábrák figyelembe vételével már lehetőségünk nyílik arra, hogy egyértelműen el tudjuk dönteni a kiegészítés kérdését.
A funkcióbővítés során felmerülő
lehetséges problémák
Az SDL specifikáció bővítése azonban újabb problémákat vet fel. Nyilvánvaló, hogy a bővítés lehetőségét nem korlátozhatjuk azzal, hogy az új funkció megvalósítását csak már meglévő elemekből (processzekből, csatornákból, jelekből stb.) építhetjük fel. Ezért - a legtöbb esetben - elkerülhetetlen, hogy új elemeket kelljen felhasználnunk. Amíg csak meglevő processzek közt közlekedő új jelekre van szükségünk, addig elegendő ezek deklarálása. Ha azonban új processzekre is szükségünk van (az MSC bővítés újakat is tartalmaz), világosan meg kell határoznunk ezek pontos elhelyezkedését, valamint kapcsolatukat a már meglevőkkel (összekötő csatornák, jelutak, a rajtuk közlekedő jelek stb.). Az itt felsorolt lépések jelentik az elméleti funkcióbővítés lépéseinek SDL/GR-ben történő gyakorlati megvalósítását.
Esettanulmány
A pre-paid kártyás mobiltelefonok pénzkiadó automatán keresztüli feltöltésének lehetősége eredetileg nem szerepelt a gép funkciói közt, ezért ennek a lehetőségnek a megvalósításával fogom a funkcióbővítés lehetőségét bemutatni. Akárcsak az eredeti, bővíteni kívánt rendszer tervezése során, itt is fontos, hogy betartsuk a protokoll fejlesztés lépéseit. Mivel ezek (elemzés, követelményspecifikációk megadása) megegyeznek a korábbi munkánkban leírtakkal [23], ezek részletezésére itt már nem térnénk ki, inkább a "tervezés" lépést vesszük egy kicsit jobban szemügyre. A fejlesztő környezet a Telelogic TAU 4.1-es SDL csomagja.[6]
A mobiljegy-feltöltés funkció a Műveletek, azon belül is az Egyéb műveletek menüpontba, az Egyenleglekérdezés és az Átutalás lehetőségek mellé fog kerülni. A fent felsorolt funkciókat a vezérlő valósítja meg, ezért a feltöltés megvalósításához szükséges állapotok egy része a vezérlőben már létező állapotok közül kerül ki, míg a maradék újonnan létrehozott állapot lesz. A mobiljegy-feltöltést a 7. számú MSC ábra valósítja meg.
Ahhoz, hogy az MSC-ben megvalósított új funkciót megfelelő módon tudjuk illeszteni a már meglevő SDL viselkedésmintához, az egyik szükséges feltétel az, hogy az MSC ábrán a kezdő- és végállapotok neve megegyezzen a már kész SDL ábra megfelelő állapotneveivel. A fenti kitétel teljesülése esetén könnyen meghatározhatjuk a kiegészítés pontos helyét, ennek hiánya esetén viszont nem tudunk vele mit kezdeni, hiszen a már eleve adott SDL rendszer sosem kerül olyan állapotba, amelyből az MSC-ben vázolt funkció indulni tudna
