Tervez és menedzsment-támogató rendszer rétegelt hálózati architektúrákhoz

Tervez és menedzsment-támogató rendszer rétegelt hálózati architektúrákhoz TDK dolgozat 2000.

Szerz k:

Király Csaba, V. évf., m szaki informatika szak

Pándi Zsolt, V. évf., m szaki informatika szak

Kálmán Barnabás, V. évf., m szaki informatika szak

Konzulens: Dr. Do Van Tien, Híradástechnika tanszék

TERVEZ

ÉS MENEDZSMENT-TÁMOGATÓ RENDSZER RÉTEGELT HÁLÓZATI ARCHITEKTÚRÁKHOZ

2

TERVEZ

1

BEVEZET ............................................................................................................................................ 5 1.1

2


A DOLGOZAT FEJEZETEINEK TARTALMA.............................................................................................. 6

A TERVEZ

RENDSZEREKKEL SZEMBEN TÁMASZTOTT KÖVETELMÉNYEK.................... 7

2.1 TERVEZ RENDSZEREK TULAJDONSÁGAI ............................................................................................. 7 2.2 RÉSZLETES ELEMZÉS .......................................................................................................................... 7 2.2.1 Algoritmusok ................................................................................................................................. 7 2.2.2 Megjelenítés, elemzés..................................................................................................................... 8 2.2.3 Dokumentálás................................................................................................................................ 8 2.2.4 Adatok........................................................................................................................................... 8 2.2.5 Csoportmunka ............................................................................................................................... 9 3

A RENDSZERTERV EL KÉSZÍTÉSE.............................................................................................. 11 3.1 3.2 3.3

4

A TERVEZ 4.1 4.2 4.3

5

ALAPFOGALMAK .............................................................................................................................. 11 A DOMAIN MODEL........................................................................................................................... 11 A DOKUMENTÁLÁS TÁMOGATÁSÁNAK MEGVALÓSÍTÁSA ................................................................... 12 RENDSZER SZERKEZETE......................................................................................... 15

A PLANNING CONTROL RÉSZEGYSÉG ................................................................................................ 16 AZ OPTIMISATION CORE................................................................................................................... 17 A MANAGEMENT AGENT.................................................................................................................. 17

A HÁLÓZATMODELL ....................................................................................................................... 19 5.1 A LOGIKAI SZERKEZET ..................................................................................................................... 19 5.1.1 A réteg fogalma ........................................................................................................................... 19 5.1.2 A rétegek logikai szerkezete ......................................................................................................... 21 5.1.3 Rétegek közötti kapcsolatok ábrázolása........................................................................................ 22 5.1.4 Típusok definiálása...................................................................................................................... 23 5.1.5 Összefoglalás............................................................................................................................... 24 5.2 HÁLÓZATMODELL REPREZENTÁCIÓK ................................................................................................ 24 5.2.1 Relációs adatbázis reprezentáció ................................................................................................. 25 5.2.2 A hálózatmodell memóriabeli reprezentációja .............................................................................. 26

6

ALKALMAZÁSI PÉLDÁK.................................................................................................................. 29 6.1 6.2 6.3

ELS PÉLDA: FORGALMI TERVEZÉS ................................................................................................... 29 MÁSODIK PÉLDA: ATM HÁLÓZATON VC ELVEZETÉS KONFIGURÁCIÓS SZINT LEÍRÁSA...................... 31 HARMADIK PÉLDA: ATM TERVEZÉS ................................................................................................. 33

7

ÖSSZEGZÉS......................................................................................................................................... 37

8

SZÓJEGYZÉK ..................................................................................................................................... 39

9

IRODALOMJEGYZÉK ....................................................................................................................... 41

1

TERVEZ


2

TERVEZ


Kivonat Dolgozatunk témája egy hálózattervez rendszer szerkezetének bemutatása, amelyet napjainkban egyre széleskör bben alkalmazott szoftver-technológiák (UML, CORBA) segítségével terveztünk meg. A rendszer kialakítása lehet vé teszi a hálózattervezés és a hálózatmenedzsment egymással együttm köd , online kezelését. Mivel a rendszer a rétegelt hálózatmodell alkalmazására épül,ezért széleskör en alkalmazható a legkülönfélébb hálózati környezetekben.

A rendszer kialakításakor kiindulási alapul szolgált a BME Híradástechnika tanszékén hosszú ideje fejlesztett és alkalmazott XPlanet tervez i rendszer, amelynek megismerése, a használata során szerzett tapasztalatok, illetve a benne felhalmozott tudás nagyban hozzájárultak eredményeinkhez. Köszönetet mondunk a rendszer fejleszt inek támogatásukért.

3

TERVEZ


4

TERVEZ


1 Bevezet Az egyre újabb technológiákra épül hálózatok számtalan új szolgáltatást nyújtanak felhasználóiknak és hatékony, költségkímél er forrás-elosztási lehet ségeket biztosítanak üzemeltet iknek. Ezen új hálózati technológiák hatékony telepítése és m ködtetése változatos feladatokat jelent a hálózattervezési módszerek és rendszerek alkotói számára.

A hálózattervez rendszereket az új technológiák bevezetésér l való döntések támogatására és az alternatív stratégiák értékelésére alkalmazzák. A távközlés napjainkban egyre változó fogalomrendszere, a gyors technológiai változások, a forgalom méretének, típusának és eloszlásának változásai, valamint a m ködtetési költségek beruházási költségekhez viszonyított egyre nagyobb aránya alapvet változtatásokat tesz szükségessé a hálózattervez rendszerek által alkalmazott megközelítésben [1]. Így az új technológiákra specializált tervez rendszerek fejlesztéséhez szükséges id t egyre inkább rövidíteni kell. E probléma egy lehetséges megoldása, hogy a tervez rendszerek kiaknázzák az egyesített hálózatmodellek, mint pl. a rétegelt modell [3] nyújtotta el nyöket. Ezek a modellek ugyanis lehet séget adnak a menedzsment kérdések kezelésére.

A menedzsment szempontjából a hálózat nem más, mint er források és szolgáltatások konfigurációjának leírása a menedzsment tervben. A hálózati er források és a berendezések közötti leképezéseket a menedzsment szabványok szabályozzák. Mivel ez a leírás csak az üzemeltetéshez kapcsolódik, ezért nem elégséges a tervezési feladatokhoz. Más absztrakt hálózati és forgalmi modellekre van tehát szükség, amikor a hálózati architektúrák költségeit kell optimalizálni (kapacitástervezés vagy topológiai tervezés esetében). A tervez és menedzsment rendszer közötti online együttm ködés kialakítása érdekében a tervezéshez használt absztrakt modelleknek tartalmazniuk kell a hálózatnak a menedzsment célokra használt, er forrás-konfigurációs leírását is.

Az önkonfiguráló hálózatok témaköre [2] tehát fontos kérdés, amellyel számolnia kell egy tervez rendszer készít jének. Pl. egy ATM (SDH, WDM) fölött összekötött IP routerekb l álló hálózati architektúra könnyedén átkonfigurálható az aktuális forgalmi igények függvényében akár automatikusan, akár küls beavatkozással. Az átkonfigurálás akár meghatározott id közönként is végrehajtható. Mivel az új hálózati alkalmazások megjelenésével a hálózati forgalom értékelése és el rejelzése egyre nehezebbé válik, a mérés alapú hálózattervezés és –konfigurálás szerepe egyre fontosabb. Egy hatékony hálózattervez rendszernek tehát képesnek kell lennie a hálózat menedzsment rendszerével való online együttm ködésre. Egészen mostanáig ez az együttm ködés az említett rendszerek között javarészt offline módon történt, annak ellenére, hogy a hálózattervez és optimalizáló tevékenységeket a menedzsment rendszer részeként szokás definiálni.

Az elosztott objektum-technológiák, mint pl. a CORBA (Common Object Request Broker Architecture) alkalmazásával lehet vé válik ennek a problémának a kezelése. Több nemzetközi szervezet (OMG, TINA-C, TmForum) is elkezdte menedzsment szabványok objektum-orientált és CORBA alapú megvalósítását [5]. A tervez rendszer CORBA alapú megvalósítása lehet vé teszi az együttm ködést ezen szabványokat támogató menedzsment-rendszerekkel is.

Dolgozatunkban egy hálózattervez rendszer szerkezetének kialakítását t zzük ki célul, amelyet napjainkban egyre széleskör bben alkalmazott szoftver-technológiák segítségével tervezünk meg. El ször a tervez i rendszerek problémakörét elemezzük, és egy olyan általánosan alkalmazható tervez i keretrendszert állítunk össze, amely elvileg bármilyen témájú specifikus tervezési munka hatékony támogatására alkalmas. Ezek után a

5

TERVEZ


hálózattervezés fel l közelítjük meg a kit zött feladatot. Tervez i rendszerünket egy olyan hálózat modellel egészítjük ki, amely alkalmas a valós hálózattervezési feladatok során felmerül , a hálózatra jellemz adatok összességét a közöttük lev összefüggések meg rzésével hatékonyan tárolni.

1.1 A dolgozat fejezeteinek tartalma Az el bb elmondottaknak megfelel en a dolgozat felépítése a következ . •

Az els fejezet a bevezet t tartalmazza.

•

A második fejezetben a tervez rendszerekkel szemben fellép követelmények meghatározásával és elemzésével foglalkozunk, problémákat vetünk fel a témakörben.

•

A harmadik fejezetben az elengedhetetlen fogalmi tisztázás után elvi megoldásokat mutatunk be az el z fejezetben felvetett problémákra a formálódó rendszer általánosságának megtartásával.

•

A negyedik fejezet részletesen tárgyalja a tervez i keretrendszer megvalósításának részleteit.

•

Az ötödik fejezetben a hálózatmodell irányából közelítjük meg témánkat, és bemutatunk egy sokoldalú reprezentációt, amellyel kiegészítve általános célú tervez i rendszerünket végre összeáll a kép.

•

A hatodik fejezet példáival megpróbáljuk igazolni, hogy az alkalmazott hálózatreprezentáció segítségével sokféle feladatot le lehet írni.

•

A hetedik fejezetben összefoglaljuk és röviden értékeljük munkánkat.

•

A nyolcadik fejezet tartalmazza azon fogalmak meghatározásait, amelyeket a dolgozatban végig használunk (és el ször a harmadik fejezet hivatkozik rájuk).

•

A kilencedik fejezet a felhasznált és tanulmányozott irodalmat sorolja fel.

6

általános valamint

TERVEZ


2 A tervez rendszerekkel szemben támasztott követelmények Dolgozatunk els részében részletesen megvizsgáljuk azokat a szempontokat, amelyek befolyásolják egy tervez rendszer szerkezetének kialakítását, és vázoljuk a felmerül problémák leküzdésére kidolgozott megoldások elvi menetét. A kés bbiekben aztán ezekb l származtatjuk majd rendszerünk különböz funkcionális elemeit.

2.1 Tervez rendszerek tulajdonságai Melyek egy jó tervez rendszer ismérvei? Elképzelésünk szerint az ideális rendszer •

segíti a tervez munkáját azzal, hogy a már bevált tervezési módszereket képes automatikusan alkalmazni, s t, az egyes tervezési fázisokban alkalmazott algoritmusokat képes összekapcsolni, kombinálni is,

•

egységes felületet nyújt új tervezési módszereknek a rendszerbe illesztéséhez, ezáltal programozói oldalról is megkönnyíti a b vítést, és sokoldalú eszközzé válik,

•

képes a tervezés pillanatnyi eredményeit áttekinthet formában megjeleníteni, illetve elemezni ket különböz szempontok szerint, ezáltal támogatva a munka értékelését,

•

biztosítja a munka során létrejött részeredmények, illetve a tervezés végeredményének dokumentálását és nyomonkövethet ségét,

•

képes rendszeren kívüli forrásokból származó adatok felhasználására, illetve a tervezési eredményeknek más rendszerek számára történ rendelkezésre bocsátására,

•

támogatja a csapatmunkát, lehet vé téve ezzel a feladatok megosztását; illetve egy hierarchikus rendszer kialakítását, ahol az eltér szintekhez különböz felel sségek tartoznak, és a fontos döntéseket csak egy adott hierarchiaszinten lehet meghozni,

•

lehet séget ad a rutinszer en ismétl d komplex tervezési folyamatok automatikus futtatására, ezen keresztül lehet vé téve a valós idej menedzsment rendszerekkel való együttm ködést,

•

általános modellezési technikára épül, és ezáltal lehet vé teszi, hogy a legkülönfélébb környezetekben alkalmazható legyen, lehet leg minimális adaptációval (amely nem érinti a szerkezeti részeket, legfeljebb új algoritmusok implementálásával, vagy új technológiák rendszerbeli leképezésével jár).

E listát tekinthetjük egyben célkit zéseink felsorolásának is, ugyanis ezen szempontok azok, amelyeknek minél nagyobb mérték érvényesülésére törekszünk majd a rendszer kialakítása során jelentkez döntéshelyzetekben.

2.2 Részletes elemzés A rendszer fontosabb részei közül néhányat kiragadunk, amelyek a tervezésnél nagy hangsúlyt kaptak a korábban említett szempontok érvényesítése miatt.

2.2.1 Algoritmusok A rendszer rugalmas b víthet sége megköveteli, hogy a tervezési módszereket megvalósító algoritmusok rendszerbe kapcsolására kialakítsunk valamilyen jól meghatározott interfészt. A kapcsolódásnak két fontos aspektusát különböztethetjük meg:

7

TERVEZ


•

A futtatható algoritmus és a futtatás körülményeinek tárolása.

•

Adatcsere a rendszerrel az algoritmus futása közben.

2.2.2 Megjelenítés, elemzés A keretrendszernek biztosítania kell a különböz megjelenítések GUI felülete számára valamilyen általános interfészt, a minél rugalmasabb használhatóság érdekében. A GUI futtatását célszer a lokális gépen biztosítani (kivéve, pl. ha X Windowra épül a megoldás), ezzel a megoldással ugyanis a rendszer terhelése jobban eloszlik. (Meg kell azonban jegyeznünk, hogy a terhelés jelentékeny részét nem a grafikus megjelenítés m veletigénye jelenti majd.)

A megjelenítést és elemzést végz programrészek felfoghatók az el z megjelen algoritmusok általánosításaként is.

pontban

2.2.3 Dokumentálás Kiemelt jelent séggel kezeljük, mivel több szempontból is fontosnak tartjuk. Ezek a szempontok röviden: •

A tervezések reprodukálhatósága (Azaz: megadott kiindulási modellb l a végrehajtott tervezési folyamat lépésinek és paramétereinek ismeretében el kell tudni állítani a korábban megkapott eredményt, bizonyos korlátozásokkal. Ez utóbbi megjegyzés azt jelenti, hogy randomizált algoritmusok használata esetén nem garantálható a korábbival mindenben megegyez végeredmény.)

•

A modellek „életútja” követhet a bevitelükt l kezdve minden tervezési lépésen át (meghatározhatónak kell lennie, hogy egy adott modell hogyan jelent meg a rendszerben és kit l származik)

•

Az alkalmazott paraméterek dokumentálása lehet vé teszi új tervezési metódusok kialakítását (a gyakran alkalmazott tervezési eljárások újrahasznosíthatók lesznek).

2.2.4 Adatok A rendszer mindenképp megköveteli több adatformátum támogatását. Ez megoldható adat konverterekkel. A rendszeren belül azonban az adatokat valamilyen formátumban tárolni kell. Itt a két alapvet lehet ség az adatbázis és a szöveges állomány. A döntés nem egyértelm , hiszen az adatok világa jelent s átalakulásokon megy keresztül napjainkban:

•

Adatok hatékony tárolására jelenleg az adatbázis-technológiák (Relációs, OO) az elfogadottak. Ezek gyorsabb, egyszer bb feldolgozást tesznek lehet vé. A rendszerben alkalmazott bels adatábrázolás megváltoztatása is egyszer bb, mivel az adatbázis kérések eltakarják az adatbázis használója el l ezeket.

•

Az algoritmusok számára gyors, hatékony hozzáférést kell biztosítanunk a memóriában található adatokhoz. Itt az OO megközelítés t nik a legel nyösebbnek, az algoritmusok így hozzáférhetnek az egyedi elemekhez.

•

Adatok átadására, adatcserére egyre többen a folytonos szöveg alapú XML-t használják. Az XML technológia azonban most tart az „univerzális megoldás” korszakában, használata ezért talán még körültekint bb vizsgálatot igényel.

8

TERVEZ


2.2.5 Csoportmunka A csoportmunka támogatásakor el kell dönteni, hogy minél nagyobb rálátást szeretnénk biztosítani a többi tervez munkájára, vagy elrejtjük a felesleges részleteket a végeredményekre koncentrálva. A tervezés szempontjából hasznos lehet, ha a rendszer megköveteli világos felel sségi körök kialakítását a feladatok emberekhez rendelésével. De vajon miért érdemes mindezt rendszeren belül megoldani? •

Mert integrált adatcsere lehet ségeket biztosít,

•

integrált verziókezelést biztosít,

•

és integrált felel sségi köröket biztosít.

9

TERVEZ


10

TERVEZ


3 A rendszerterv el készítése 3.1 Alapfogalmak Ahhoz, hogy egységesen írhassuk le a fentebb vázolt problémák megoldását, elengedhetetlen néhány, a rendszerben megjelen fogalom pontos definiálása. Az OO szemléletet követjük a rendszer kialakítása során, így a most definiálandó entitások tulajdonképpen a rendszerben megjelen fontosabb objektumok vázlatos körülírásának is tekinthet k. A fogalmakat angol nevükkel definiáljuk, hogy a kés bbiekben bemutatott diagramokon követhet k legyenek a megfelelések. A fogalmak egy részének értelmezése kézenfekv , mindazonáltal szükség van a pontos meghatározásukra, amelyet a 8. fejezetben gy jtöttünk össze. Ezzel az volt a szándékunk, hogy a dolgozat olvasása közben bármikor fellapozható legyen a lista. Logikailag azonban itt helyezkedne el a fogalmak listája, így a továbbhaladás el tt javasoljuk annak áttekintését.

3.2 A Domain Model Az általunk definiált fogalmak felhasználásával felvázolunk egy nagyvonalú képet a rendszer elképzelt m ködésér l, amely segít a leképezend folyamatok kezelésében.

Hálózatmodell importálása Hálózatmodell exportálása Hálózatmodell módosítása

Új session nyitása

Tervezõ Metódus futtatása Session lezárása Metódus beillesztése

Új metódus készítése

Metódus írása

Metódus készítése session alapján

Felhasználók felvétele

Adminisztr.

1. ábra: Vázlatos use-case diagram

Tervezési feladatot több tervez csoport (group) is végezhet egyszerre. Egy tervez csoport néhány tervez b l (user), és egy csoportvezet b l áll. A tervez k az egyes tervezési részfeladatok optimalizálásával foglalkoznak, a csoportvezet pedig koordinálja a tervezési folyamatot, illetve a felel s kulcsfontosságú döntésekért, és a tervezési folyamat átfogó értékelésének elkészítéséért. Egy tervezési feladat megoldása során a csoportvezet a tervez k rendelkezésére bocsájt egy (vagy több) modellt (model), amelyen a tervez k dolgozhatnak. Egy tervez egy modellb l kiindulva terveket készít (ez a session segítségével követhet ). A tervek három f részb l állnak: tartalmazzák a kiindulási modellt, a tervezés során felhasznált tervezési 11

TERVEZ


metódusokat (method) a szükséges paraméterekkel (parameters) együtt, illetve az eredményként kapott modellt esetleg valamilyen értékeléssel (pl. szimulációs eredmény, költség számítás, stb.) (evaluation) együtt. A tervez k a tervezés folyamata közben szabadon alkalmazhatnak egymás után különböz tervez algoritmusokat tetsz leges paraméterekkel. (Nyilván az értelmes m veletek vezetnek csak értékelhet eredményhez, és ezt valamilyen minimális szinten ellen rizni is kell.) A tervez k eredményeit a csoportvezet min síti, és határozza meg azt is, melyek azok a tervek, amelyek eredményét más tervez k kiindulási modellként használhatják. Ugyancsak dönt egy jónak bizonyuló tervezési metódus elfogadásáról.

A hálózatmenedzsment rendszer is egyfajta automatizált felhasználóként (tervez ként) tud csatlakozni a rendszerhez, az általa gy jtött forgalmi statisztikák bemen adatként állnak rendelkezésre. Ezen bemen adatokkal egy automatikus tervezés zajlik le, amelynek eredményét értelmezve a menedzsment rendszer képes a hálózatban szükséges konfigurációs beállításokat elvégezni.

3.3 A dokumentálás támogatásának megvalósítása A session fogalmát azért vezettük be, hogy segítségével biztosítható legyen a tervezési feladatok automatikus dokumentációja és a tervezés folyamatának reprodukálhatósága. A session fogja össze a tervezési folyamat lépéseit, beleértve a meghozott döntéseket is. Egy session olyan tevékenységeket fog össze, melyeket a tervez egy modellb l kiindulva végez. A sessiont a tervez zárja le, lezárás után tovább nem folytatható. Egy tervez egyszerre több sessionben is dolgozhat, egy modellb l több session is kiindulhat. Új session nyitásához tehát ki kell választani egy hálózatmodellt. Ez után a tervez lépésekben haladhat tovább. Egy új lépés azonban nem feltétlenül az el z lépés végeredményére épül. Lehet, hogy vissza kell lépni egy korábban keletkezett hálózatmodellhez. Könnyen látható, hogy az így definiált session egy fát alkot, melynek élei a lépések, pontjai hálózatmodellek, gyökere pedig a kiinduló hálózatmodell.” A m veleteknek két fajtája van:

•

tervezési metódus futtatása

•

kézi módosítás, amely esetben a tervez a hálózatmodellt nem algoritmikus eszközökkel szabja át.

Ez utóbbi sajnos nehezebben követhet , és a modellbe illesztése sem egyértelm . A lehet ségek elemzése után amellett döntöttünk, hogy a kézi módosítást a rendszer által a konkrét tervezési folyamattól függetlenül biztosított lehet ségnek tekintjük. Ekkor a kézi módosítást leíró adatok (amelyek biztosítják annak reprodukálhatóságát) a rendszer számára strukturálatlanul kerülnek tárolásra, és ezen adatok értelmezésének és rendelkezésre bocsátásának felel ssége a módosítható objektumokhoz fog tartozni. Ezért a session dokumentáció idevágó részének elkészítése is a módosított objektum felel ssége lesz.

12

TERVEZ


session

Hálózatmodellek

4. 2.

3.

1.

2. ábra: Egy képzeletbeli session-fa

Egy nyitott session fájának minden csomópontjában érvényes hivatkozások vannak modellekre, így minden részeredménye elérhet , és a fa minden egyes csomópontból tovább építhet . A lezárt sessiont viszont már nem lehet megváltoztatni, és csak azokra a részeredményekre vannak érvényes hivatkozásai, amelyeket a tervez kérésére archivált a rendszer, az összes többi részeredmény (hálózatmodell) automatikusan törl dik a session lezárásakor. Kívánságra azonban a lezárt session hiányzó részeredményei is reprodukálhatók, csak a tárolási hely megtakarítása miatt törl dnek. Mind a reprodukálás, mind a dokumentálás megvalósítható a session segítségével az alábbi módszerrel. A csomópontok listáját a létrehozásuk sorrendjében kell feldolgozni. Minden csomópontnál a rámutató élt kell megkérni, hogy készíse el saját dokumentációját. Az él (a végrehajtott m velet) szöveges indoklása szintén csatolható. Ezután, ha létezik, akkor a m velet eredményeként létrejött modellt kell a dokumentációhoz csatolni, a hozzá kapcsolódó értékelésekkel együtt. Ez a leírás csupán azt feltételezi a rendszerbeli objektumokról, hogy önmagukról szöveges információkat és jellemz ket tartalmaznak, és ezt kérésre vissza tudják adni. Természetesen a dokumentálás folyamata közben a felhasználónak is lehet séget kell biztosítani arra, hogy további szöveges megjegyzéseket f zzön a készül dokumentumhoz. Még további tanulmányozást igényel azonban az automatikus tervezés ezen mechanizmuson alapuló megvalósítása.

A csomópontleírók információtartalma a fentiek szerint a következ : ♦ csomópont sorszáma ♦ link egy hálózatmodellre, amely lehet ideiglenes modell, végleges modell, vagy üresen is állhat, ha egy lezárt session közbüls csomópontját vizsgáljuk ♦ élek sorszámai, amelyek azt jelzik, hogy mely éleken kiindulva lehet az adott csomópontból továbbhaladni ♦ ♦ ♦ ♦ ♦

Az egyes élleírók (step) pedig a következ ket tartalmazzák: él sorszáma, amely megegyezik a végpontjának sorszámával az él kiindulási pontjának sorszáma az él által képviselt metódus azonosítója, ami üresen marad kézi módosításnál az él által képviselt kézi módosítást leíró azonosító (vagy akár a módosítást leíró metaadat), ami üresen marad metódus alkalmazásánál a tervezési lépés opcionális szöveges indoklása

13

TERVEZ


Szeretnénk még egyszer felhívni a figyelmet arra, hogy a session ilyen módon történ értelmezése nem feltételez semmit a modellek bels szerkezetér l, így akár egy teljesen általános célú tervez rendszer m ködése is elképzelhet az el bb elmondottak alapján.

14

TERVEZ


4 A tervez rendszer szerkezete Miután összefoglaltuk a rendszerrel szemben támasztott követelményeket, és az ezekb l származó feladatok megoldásának elvi menetét, rátérünk az eddigiek alapján kialakított szerkezetre, amelyet a 3. ábra mutat be. A következ kben részletesen áttekintjük a m ködését.

USER INTERFACE Model Administration

CORBA

Planning Administration

Management Administration

Planning Method Administration

CORBA

CORBA

CORBA CORBA

Planning Control

Documentation

Optimisation Core

MODEL STORE

Methods and Algorithms

Network management system

Management Agent

Network

Network Models

PERSISTENCE LAYER

3. ábra: A tervez rendszer blokkdiagramja

A Persistence Layer nev funkcionális blokk feladata, hogy adatraktárként kezelje a rendszerben a perzisztenciával (élettartamával, láthatóságával, illetve memória- vagy adatbázisbeli elhelyezkedésével) kapcsolatos feladatokat. Ebben az adatraktárban tárolódnak a tervezési feladatok adatai, a tervezési algoritmusok és metódusok, a hálózatmodellek és a rendszer felhasználóinak adatai. A Persistence Layerben különböz azonosítási és hozzáférési szinteket lehet kialakítani támogatva ezzel a tervezési feladatok felosztását és szervezését a különböz tervez k között. A Management Agent interface-t biztosít a tervez rendszer és a kommunikációs hálózat menedzsment rendszere között. Ezen keresztül lehet a menedzsment rendszer segítségével a hálózatban mért forgalmi adatokat összegy jteni. Ezek a mérési eredmények is az adatraktárban tárolódnak. A Management Agent emellett képes ez utóbbi részegység aktiválásával a legfrissebb forgalmi méréseknek megfelel optimális hálózati konfiguráció kiszámoltatására is, az Optimisation Core számítási eredményei alapján pedig a menedzsment rendszerrel együttm ködve el tudja végezni a hálózat átkonfigurálását. A rendszer mindezek mellett a hagyományos, offline tervezést is támogatja, van ugyanis egy User Interface-e, amely a tervez k számára biztosít hozzáférést. A rendszerbe való belépés egy felhasználói azonosítást is magában foglal, amit l kezdve a tervez által végrehajtott tervezési lépéseket a Planning Control részegység dokumentálja. Ennek a feladata továbbá az egyes tervezési feladatok kezelése is.

Egyes részegységek között a kommunikáció a CORBA run-time környezetében történik. Ezt a 3. ábra mutatja. Más esetekben viszont a CORBA környezet megkerülése javasolt, mivel a hálózatmodellek átadása nagy mennyiség adatmozgást igényel, és ez hatékonyságromlást okozhat.

A következ részben az eddig felsorolt funkcionális egységek közül a három legfontosabbat vizsgáljuk meg részletesebben.

15

TERVEZ


0..*

Profile

0..*

0..*

1

User Group

AuthenticationManager

newSession() selectSession() selectModell() selectMethod() run()

0..*

login()

id : string name : string

0..*

1 addMember() removeMember()

1..*

getName() setName()

User Interface

1 1

0..*

1

0..*

SessionDirectory

ManualModification

open : boolean getOpenSessions() getClosedSessions() getSessions() getSessionsFromModel() getSessionForModel()

1

0..*

Session

0..*

0..*

getRoot() close() saveM() step() getSteps() getStates() getDocumentation() 1 1..*

0..*

getDocumentation() 0..1 1 Step

1 0..*

0..*

State 1

0..1 0..*

1 ParameterDescription 1 0..1

1 0..1

Evaluator

Evaluation 0..*

0..*

0..* Algorithm

0..*

Parameter

0..1

1

1

PlanningMethod getDocumentation()

0..1 0..1

getModel() 1 getNextSteps() getPrevStep() getDocumentation()

1

getMethod() getMethodList() getAlgorithm() getAlgorithmList() run()

0..* getMethod() getParameters() getNextState() getPrevState() getExplanation() getDocumentation() getModification()

1

Planning Control

Execution

1

1

getDocumentation()

0..*

Optimization Core

1

Model getDocumentation() 0..* 1

1

ModelDirectory 1

getModel() getModification() getModels() getModelList()

Model Store

4. ábra: A tervez rendszer magjának UML diagramja

4.1 A Planning Control részegység A Planning Control részegység osztálydiagramját a 4. ábra mutatja be. Viselkedését a következ kben tárgyaljuk. A Model osztály a hálózat egy absztrakt modelljét írja le, amely a rétegelt megközelítésen [3] alapul, így képes különböz hálózati architektúrák, illetve a tervezés pillanatnyi állapotának egyidej leírására. A tervezési folyamat lépéseit a Session osztály rögzíti, amely a korábbiaknak megfelel en egyetlen tervezési feladathoz kapcsolódik. A Session osztály a Step és State osztályokat használja fel a faépítéshez, emellett az általa leírt tervezési folyamathoz kapcsolódó szöveges információkat is tartalmaz. A PlanningMethod és ManualModification osztályok írják le azt a transzformációt, amelyet a tervezési folyamat egy lépésében végrehajtottak a hálózatmodellen. A transzformáció paraméterei Parameter típusú objektumokban tárolódnak, amelyek a metódusok és értékel k nem modell típusú bemen paramétereit írják le. Az Evaluation osztály szöveges és numerikus jelleg adatok halmazát fogja egybe, amelyek egy adott hálózatmodellt értékelnek adott kritériumok szerint. Ennek az osztálynak a példányai mindig egy modellhez csatlakoznak.

A User Interface-en keresztül tudják a tervez k kiadni parancsaikat és irányítani a tervezési folyamatot. A rendszerbe egy csoport tagjaként való bejelentkezés után a tervez válogathat a csoport sessionjei és modelljei között, megnyithat egy új sessiont valamelyik modellb l kiindulva, folytathatja a tervezési munkát valamelyik saját nyitott sessionben, vagy esetleg bezárhat egy ilyet. Ezeket a tevékenységeket a User Interface fordítja le rendszerbeli eseményekre, és mindegyiknek van egy megfelel je a Session osztály metódusai között.

16

TERVEZ


4.2 Az Optimisation Core A 4. ábra tartalmazza az Optimisation Core bels szerkezetét is. Ez a részegység felel s a különböz tervezési algoritmusok tárolásáért és végrehajtásáért. A tervezési problémákat bonyolultságuk miatt rendszerint részfeladatokra bontják, de ez a felbontás még ugyanazon probléma esetén is általában többféleképpen oldható meg. A tervezés különböz fázisaiban gyakran alkalmazott algoritmus-kombinációk metódusokként tárolódnak. A hasonló elven felépül értékel k szintén itt tárolódnak. A használat megkönnyítése érdekében a metódusok és értékel k nem modell típusú bemeneti paramétereinek alapértelmezés szerinti értékeit, értéktartományait és jelentéseit is itt rögzítjük. Az Execution osztály a rendszeren belüli interface a többi részegység felé.

4.3 A Management Agent A Management Agent egyel re csak funkcionális specifikáció szintjén létezik, pontos szerkezetét még nem terveztük meg. Feladatai a következ k: •

kommunikáció biztosítása a kapcsolódó hálózat menedzsment rendszerével valamely szabványos felületen keresztül (pl. SNMP, vagy Q interface),

•

konfigurálható id közönként a hálózat állapotát leíró adatok összegy jtése a menedzsment rendszerrel együttm ködve,

•

a halózat legutolsó ismert állapota alapján automatikus tervezési folyamat lefuttatása a hálózat optimális konfigurációjának meghatározására,

•

az automatikus tervezési folyamat eredménye alapján a szükséges konfigurációs módosítások végrehajtása a menedzsment rendszer segítségével.

17

TERVEZ


18

TERVEZ


5 A hálózatmodell A tervez i keretrendszer áttekintése után most a hálózatok modellezésével fogunk foglalkozni. Az általános modellezési megfontolásokból kiindulva több lépésben specifikáljuk egy sokoldalú hálózatmodell tulajdonságait, majd rátérünk megvalósításának részleteire is. Mint minden modellezési feladatnál, itt is sok szempontot figyelembe véve kell megalkotnunk modellünket. A modellezés folyamata alapvet en két elkülöníthet feladatra bontható: •

a modell logikai szerkezetének megalkotására

•

a logikai szerkezet alapján különböz reprezentációk kidolgozására

5.1 A logikai szerkezet A modell logikai szerkezetének kidolgozása el tt el kell döntenünk, hogy a valóságot milyen részletességgel szeretnénk leképezni. Esetünkben azt nem könny (és talán nem is lenne szerencsés) megmondani, hogy mi az, amit már nem akarunk „látni” a valóságból. A modell felhasználási területei (tervezés, megvalósítás, menedzsment, létez hálózatok leírása) azonban meghatározzák, hogy mi az, amit mindenképp tartalmaznia kell.

Mivel hálózatmodelleket els sorban hálózattervezési lépések kiinduló adataként és eredményeként használunk, fontos, hogy a logikai szerkezet a tervez által ismert teljes hálózati képet le tudja írni. A modell absztrakciós szintjét nem kötjük meg, az lehet pl. csak az igények leírása, de lehet a megvalósítandó/megvalósított hálózat igen részletes képe is. A tervezés során - mivel azt általában nem egy lépésben tesszük – egyre finomabb hálózatmodelleket állítunk el . Err l részletesebben írtunk a tervezés dokumentálásával foglalkozó fejezetben (3.3). Célul t ztük ki menedzsment rendszerek támogatását is. Célunk megvalósításához biztosítanunk kell, hogy a modell tartalmazhasson minden, a menedzsment számára fontos információt. Ehhez elengedhetetlen, hogy minden eszköznek meglegyen a saját képe a modellben, és itt lehet séget adjunk tetsz leges számú konfigurációs paraméter felvételére.

A hálózat logikai modelljének megalkotásakor az általunk ismert hálózatmodellekre, hálózati technológiákra, valamint hálózattervezési módszerekre támaszkodhattunk. Mivel tanulmányaink során az XPlanet rendszer rétegelt hálózatleírását [3] és e rendszerben megvalósított algoritmusokat ismertük meg, jelent s mértékben erre támaszkodtunk. Igyekeztünk azonban nem a konkrét rendszerb l, hanem annak alapelveib l kiindulni.

5.1.1 A réteg fogalma Egy hálózat megfelel reprezentálásához a rétegelt hálózati szemléletb l indultunk ki, mely szerint egy hálózatmodell több rétegb l áll. A modell minden rétegének van egy típusa. A típusokat nem tekintjük a modell részének, de a modell csak a típusok ismeretében értelmezhet . Építészeti analógiával jól megvilágítható a réteg és a rétegtípus szerepe: Tekintsük példaként egy épület tervdokumentációját. Ez több, egymással összefügg rajzból áll. Mindegyik önállóan is értelmes (pl. a gépészeti tervr l leolvasható a vízvezeték rendszer), mégis az épületet a rajzok (rétegek) csak együtt modellezik. Ahhoz azonban hogy egy réteget értelmezzünk, ismernünk kell a megfelel jelöléseket, melyek jelentése nem része a tervnek. A jelentést a „gépészeti terv” név és a mögötte álló jelölésszabvány hordozza. Ez

19

TERVEZ


tehát az a szabályrendszer, ami alapján értelmezni tudjuk a rajzot (típus alatt ezentúl ezt a szabályrendszert értjük). A rétegek ábrázolásában vannak közös elemek, melyek segítségével hatékony, a tervezést és a tervek tárolását segít eszközök készíthet k. Itt nem kell semmi bonyolult dologra gondolni, elég, ha azt vesszük, hogy minden réteget két dimenzióban ábrázolunk, megadjuk a méretarányt, amiben készült, stb. Eszközként pedig említhetjük a rajzasztalt, a különböz sablonokat, vagy akár a vonalzót, a pausz papírt is. Persze gondolhatunk a rétegeket használó számítógépes építészprogramokra is. Ezek a közös elemek azonban az általánosság megszorítását jelent megkötések is lehetnek egyben. Ezzel kapcsolatban két alapvet kérdés merül fel: •

Le lehet-e vele írni mindazt, amit modellezni szeretnénk?

•

Milyen bonyolultsággal lehet leírni?

Bár az els kérdés els re fontosabbnak t nik, a második talán még nagyobb figyelmet érdemel, hiszen ett l függhet az átláthatóság, a tárolás nehézsége, és az algoritmusok bonyolultsága is.

A rétegek közötti kapcsolatoknak szintén megvan a jelölése, értelmezésük azonban nem része a tervnek. Azonos méretarány esetén például a két tervet a megfelel illesztési pontnál megfelel irányítással egymásra helyezve adódnak a kapcsolatok. Azt azonban, hogy ez két egymás fölötti szinten vagy egy szinten van, csak az ábrák címe tartalmazza. Feltehetjük a kérdést, hogy miért van szükség mindezekre a rétegekre, miért nem ábrázoljuk az egészet egyben. A választ leginkább a modellezéssel elérni kívánt célok alapján adhatjuk meg: •

Akár a valóságban már létez épületet (hálózatot) akarjuk modellezni, akár egy újat akarunk megtervezni, nincs az az ember, aki minden részletéhez megfelel en értene. Így a feladatot fel kell osztani valahogy.

•

A modellt azért készítjük, hogy az alapján dolgozhassunk (beleértve a tervezést és a kivitelezést is). Ha a modellt fel tudjuk bontani viszonylag független részekre, akkor tervezéskor elég az információk egy sz k részhalmazát ismernünk.

A független részek másik el nye, hogy átalakításkor jobban átláthatók a módosítás hatásai. Összefoglalva tehát a rétegek kialakításakor a következ figyelembe vennünk:

szempontokat kell

•

Hogyan ábrázoljunk egy réteget?

•

Ez milyen megkötéseket és milyen el nyöket jelent hálózatok modellezése során?

•

Hogyan ábrázoljuk a rétegek közötti kapcsolatokat?

•

Mennyire kötjük meg ezek értelmezését?

•

Kinek a feladata a réteg típusok definiálása?

•

Milyen módszerekkel, milyen formában definiálható egy új réteg típus?

•

Ki definiálja a különböz típusú rétegek közötti kapcsolatok értelmezését?

20

TERVEZ


5.1.2 A rétegek logikai szerkezete 5.1.2.1 Az alapgráf

Egy réteg szerkezetét — az eddig általunk megismert technológiák és modellek alapján — egy gráffal ábrázoljuk. A gráf minden elemére (pontjaira és éleire) és magára a rétegre is címkéket lehet elhelyezni. Kapacitás:16

Hely: B város Kapacitás:8

Hely: A város Kapacitás:8 Hely: C város Kapacitás:8 Kapacitás:8

Kapacitás:16 Hely: D város

5. ábra: Egy alapgráf a kapcsolódó címkékkel együtt

5.1.2.2 Címkék

Minden címkének van neve és értéke. Mind a név, mind az érték tetsz leges szöveg lehet. A gráf egy eleméhez egy névvel legfeljebb egy címke csatolható. A címke értékét (az XML definíciójához hasonlóan) szöveges formátumú adatként definiáltuk, mivel ennek el nyeit többre tartjuk hátrányainál. Err l b vebben [9] alatt olvashatunk. Azt, hogy pl. a szöveget egész számként vagy sztringként kell értelmezni, nem az adat, hanem annak értelmezése, a réteg típusa határozza meg. (XML esetén ezt a DTD vagy az XML Schema hordozza). 5.1.2.3 Rétegtípus

Az így kialakított szerkezet sok általunk ismert technológiájú hálózat leírására alkalmas. Egy réteg értelmezéséhez azonban szükségünk van további információkra is melyeket egy rétegtípus tartalmaz. Ez meghatározza a következ ket: •

Gráf pontjainak értelmezése: a gráf egy pontja jelenthet pl. egy ATM kapcsolót, de lehet egy igényforrás is.

•

Pontokhoz kapcsolható címkék nevei, típusai és azok jelentése: egy címkével leírhatjuk pl. egy kapcsoló kapacitását, míg egy másikat a földrajzi pozíció kijelölésére használhatunk.

•

Gráf éleinek jelentése: az értelmezéshez hozzátartozik az is, hogy az élek irányítottak-e vagy sem. Elképzelhet lenne olyan réteg is melyet vegyes gráfokkal lehet szemléletesen leírni. Legtöbb esetben azonban ezek leírhatók speciális irányított gráfokként is, ezért az egyszer ség kedvéért egyel re tiltjuk a vegyes gráfok használatát.

•

Élekhez kapcsolható címkék nevei, típusai és azok jelentése: egy címke tartalmazhat olyan egyszer (ám a tervezés számára fontos) információt, mint a kábelköteg kapacitása, de tartalmazhatja egy lista formájában a kábel fizikai nyomvonalát is.

21

TERVEZ


5.1.2.4 Kiegészít gráfok

Az eddig definiált szerkezettel egy er s, sokféle hálózatot ábrázolni képes réteg leírást kapunk. Néhány konkrét példát megvizsgálva azonban jól látható, hogy érdemes még egy ábrázolási lehet séget bevezetni. Megengedjük olyan gráfok használatát is, melyeknek csomópontjai a réteg gráfjának pontjai és élei, élei pedig tetsz legesen felvehet k. Ezeket kiegészít gráfoknak nevezzük. Minden ilyen gráfot egy névvel kell ellátni, értelmezését pedig szintén a réteg típusa tartalmazza. Ilyen gráfok használhatók pl. csomópont-hierarchia, SDH struktúrák ábrázolására, iker elvezetések összerendelésére. : Csomópont hierarchia

: SDH struktúra

Hely: B város Hely: A város

Hely: D város

Hely: E város Hely: C város

6. ábra: Csomópont hierarchia és SDH gy r ábrázolása

Könnyen belátható, hogy a kiegészít gráfokkal a leírás ereje nem változott. Egy “x” nev gráfot pl. ábrázolhatunk úgy is, hogy pontjait (melyek a réteg gráfjának lehetnek pontjai és élei is) megszámozzuk, majd ezek mindegyikéhez felveszünk egy „x” nev címkét a megfelel sorszámmal. Ezek után minden ponthoz felveszünk egy „x szomszédai” nev címkét, melybe beírjuk a szomszédos pontok sorszámainak listáját. Nem árt azonban, ha az ábrázolás fogalmilag is közel áll a valósághoz, mivel ez megkönnyítheti a modell használatát és ábrázolását is.

Megengedünk még egy apró, ám hasznos kiegészítést. Egy kiegészít gráf pontjaihoz már eddig is definiálhattunk címkéket, éleire vonatkozó információkat azonban csak elég nehézkesen lehetett tárolni. Megengedjük ezért címkék megadását a kiegészít gráf éleire is.

5.1.3 Rétegek közötti kapcsolatok ábrázolása A fejezet címe tulajdonképpen két jól elkülöníthet fogalmat takar. Meg kell ugyanis különbözetnünk rétegek közötti kapcsolatokat és rétegek elemei közötti kapcsolatokat: •

A modell rétegei között definiálhatunk egy alá-fölé rendeltségi viszonyt. Hálózatok esetében megszokott, hogy egy technológiával több, egymástól független technológia számára nyújtunk szolgáltatást. Más esetekben egy réteg több réteg szolgáltatásait is használhatja. Ezekre mutat egy-egy példát a 7. ábra.

22

TERVEZ


ATM

VCC

SDH

VPC

WDM

ATM 7. ábra: Modellek rétegei közötti hierarchia

•

Ezt a gráfot a rétegek hierarchiájának nevezzük. A gráf csak irányított éleket tartalmazhat. A hierarchia elnevezés nem teljesen pontos, hiszen nem kötjük ki, hogy a gráf körmentes legyen. Nem tudunk azonban olyan példát mondani ahol a rétegeket kört tartalmazva definiálnánk, így ezt az elnevezést használjuk. A gráf éleihez a szokásos módon megengedjük címkék kapcsolását is.

•

Egy hálózat modellezéséhez ábrázolnunk kell a különböz rétegek elemei (pontjai és élei) közötti kapcsolatokat is. Ezek a kapcsolatok jelenthetnek pl. szakaszolást, alternatív utakat, osztott elvezetést, berendezések kapcsolódását stb. Szemléletes ábrázolást kaphatunk, ha az ilyen összefüggéseket is egy gráffal ábrázoljuk. Ez mind az algoritmusok, mind a modellt használó ember számára gyorsan követhet vé teszi a kapcsolatokat.

•

A gráf, mellyel ezt megvalósítjuk, nagyon hasonlít egy kiegészít gráfra. Mivel azonban ez a gráf nem egy réteghez köt dik, pontjai bármelyik réteg gráfjának élei és pontjai lehetnek. Élei ugyanúgy címkézhet k, mint egy kiegészít gráf élei. A máshol el forduló gráfélekt l való egyértelm megkülönböztetés érdekében ezeket az éleket ezentúl piros éleknek nevezzük. Ezt a gráfot az elemek hierarchiájának nevezzük.

Felmerülhet a kérdés, hogy milyen kapcsolat van a rétegek hierarchiája és az elemek hierarchiája között. Mivel az utóbbit tekinthetjük az el bbit kiegészít részletes információnak, egy megkötést fogalmazhatunk meg. Ha két réteg elemei között létezik él, akkor a két réteg között is kell élnek léteznie.

5.1.4 Típusok definiálása A típusok a tervez rendszer részét képezik. Definiálásuk így nem a rendszert használó tervez k, hanem a rendszert b vít fejleszt k feladata. Új típus definiálására csak a tervez rendszer funkcióinak b vítésekor lehet szükség. Ilyen lehet új technológia bevezetése, vagy egy technológia új, esetleg részletesebb ábrázolásának kidolgozása. Szemléletünk szerint a rétegnek nincs típusa. Csupán azt lehet megmondani, hogy megfelel-e egy típusnak egy adott réteg, vagy nem. Ennek a szemléletnek és a címkék használatának el nyét akkor láthatjuk, ha a rendszer fejlesztését tartjuk szem el tt: •

Létez típusok b vítése új címkékkel könnyen megoldható.

•

A régi típus (és így a régi rendszer is) értelmezheti az új adatot, ha eltekintünk a régi típusban nem definiált címkékt l.

•

Az új típus is értelmezheti a régi adatot, ha az új típusban bevezetett címkék opcionálisak.

23

TERVEZ


5.1.5 Összefoglalás Végezetül foglaljuk össze a kialakított logikai adatszerkezetet és a rétegtípus tartalmát. 5.1.5.1 A logikai adatszerkezet ábrázolása Logikai modell Réteg Réteg

Rétegek hierarchiája

Címke Címke Név Érték Címke Név Címke Érték Név Érték Név Érték

Él Él

Címke Címke Címke Név Érték Címke Név Érték Név Érték Név Érték

Alapgráf Alapgráf Pont Pont Pont Címke Pont Címke Címke Név Érték

Címke Név Érték Érték Címke Név Címke Név Érték Érték Címke Név Érték Név Érték Név Érték

Él Él Címke Él Címke

Címke Címke Név Érték Címke Név Érték Címke Név Név Érték Érték Címke Név Érték Név Érték Név Érték

Elemek hierarchiája Piros él Piros él

Kiegészít gráf gráf Kiegészít Kiegészít gráf Kiegészít gráf Él Él Él Él Él Él Címke Él Címke Címke Címke Címke Él Címke Név Érték Név Címke Név Érték Érték

Címke Címke Címke Név Érték Címke Név Érték Érték Név Név Érték

Címke Érték Név Érték Érték Név Címke Címke Név Érték Név Érték Címke Név Név Érték Címke Név Érték Név Érték Név Érték

8. ábra: A logikai modell szerkezete

5.1.5.2 Rétegtípus tartalma

♦ Típus neve ♦ Típus verziója: ezt az információt a típus neve is tartalmazhatná, a rendszer fejleszthet ségét szem el tt tartva érdemes azonban külön megadni • Kötelez , megengedett és tiltott címkék neve Ezek értelmezése, értékkészlete ♦ Alapgráf pontjainak értelmezése • Kötelez , megengedett és tiltott címkék neve Ezek értelmezése, értékkészlete ♦ Alapgráf éleinek értelmezése • Kötelez , megengedett és tiltott címkék neve Ezek értelmezése, értékkészlete ♦ Kötelez , megengedett és tiltott kiegészít gráfok neve • Éleinek értelmezése Kötelez , megengedett és tiltott címkék neve • Ezek értelmezése, értékkészlete

5.2 Hálózatmodell reprezentációk A korábban felvázolt logikai modellnek céljainktól függ en más-más reprezentációt érdemes választanunk.

24

TERVEZ


1. Kidolgozhatunk tárolásra optimalizált reprezentációt. Erre a célra egy relációs adatbázisbeli ábrázolást készítettünk. 2. Hálózattervezés közben és algoritmusok kidolgozásakor olyan reprezentációra van szükség, mely el segíti algoritmusok gyors implementációját, hatékony megvalósítását. Ez természetesen egy memóriában megvalósítható reprezentáció. Választásunk az objektum orientált megoldásra esett. 3. Megjelenítéshez grafikus reprezentáció kidolgozása szükséges. Ennek részleteivel dolgozatunkban nem foglalkozunk. 4. Hálózatmodellek átvitelére érdemes valamilyen jól strukturált reprezentációt alkalmazni. Erre alkalmas lehet egy XML alapú leírás, de más strukturált adatábrázolások is elképzelhet k. Az XML tag-ek és attribútumok definiálásával dolgozatunkban nem foglalkozunk.

5.2.1 Relációs adatbázis reprezentáció 5.2.1.1 Az ábrázolás kialakításának szempontjai

Az adatbázis reprezentáció célja természetesen az adatok perzisztens tárolása. Jól ismert azonban az a tény, hogy azonos adatszerkezet többféleképpen leírható relációs adatbázissal, és ezek hatékonysága a használni kívánt lekérdezések jellegét l függ. Mivel az adatbázist csupán adattárolásra használjuk, lekérdezéseink célja az adatok betöltése lesz. Tudjuk, hogy az adatbázis használata során nem akarjuk sem a címkéket, sem a pontokat és az éleket egyenként kezelni. Arra van tehát szükségünk, hogy teljes rétegeket, gráfokat tudjunk betölteni (úgy, hogy a címkéknek esetleg csak egy adott részhalmazát töltjük be) a réteg méretét l független számú nem egymásba ágyazott SQL utasítással. 5.2.1.2 A táblák szerkezete

A táblák szerkezetét a 9. ábra mutatja be, melyet érdemes összevetni a logikai adatszerkezetet ábrázoló 8. ábra tartalmával. Az ábrát két részre osztottuk az átláthatóság kedvéért. Bal oldala a rétegek közötti kapcsolatokat, míg jobb oldala a rétegek leírását mutatja. A Rétegek, Pontok, Élek táblák mindkét oldalon megjelennek, az adatbázisban azonban természetesen ezek csak egyszer szerepelnek.

25

TERVEZ


Rél címke Név Érték Rél

Rétegek hierarchiája

Rétegek

Réteg címke Név Érték Réteg

Réteg id

Rél id Kezd pont Végpont

Eél címke Név Érték Eél

Elemek hierarchiája Eél id Kp pont_e Kezd pont Réteg Vp pont_e Végpont Réteg

Rétegek Réteg id

KGráf id Név Réteg

Pont címke

Pontok

Pontok

Név Érték Pont Réteg

Pont id Réteg

Pont id Réteg

Élek Él címke

Él id Kezd pont Végpont Réteg

Kiegészít gráfok

Élek

Név Érték Él Réteg

Él id Kezd pont Végpont Réteg

KÉlek Kél id Kp pont_e Kezd pont Vp pont_e Végpont KGráf (Réteg) KÉl címke Név Érték Kél KGráf (Réteg)

9. ábra: Az adatbázis tábláinak szerkezete

A hatékony lekérdezések érdekében bevezetett redundáns információkat a táblákban d lt bet kkel jelöltük. E célból több táblában (Élek, Pont címke, Él címke) elhelyeztük a réteg azonosítóját is. A kiegészít gráfok száma azonban várhatóan viszonylag alacsony lesz, és csak a réteg típusától függ. Így meggondolandó, hogy a gráfokat egyenként (esetleg egymásba ágyazott SELECT utasításokkal) kérdezzük le, vagy használjunk itt is réteg azonosítót. Ezért az ábrán zárójelben tüntettük fel a réteg azonosítóját. Várható az Elemek hierarchiájának két réteg közötti részgráfjának lekérdezése is, ezért ebben a táblában is elhelyeztük a réteg azonosítót.

Definíciónk szerint az Elemek hierarchiájának és a Kiegészít gráfoknak pontjai két táblából (Pontok, Élek) is kikerülhetnek. A kapcsolatok megoldására itt két lehet séget tanulmányoztunk:

•

A Pont id és Él id értékeket diszjunkttá tesszük

•

Külön mez bevezetésével jelezzük, hogy mihez kapcsolódik (Kp pont-e?, Vp pont-e?).

A második ábrázolás mellett döntöttünk, mivel így támogatjuk olyan lekérdezések gyors végrehajtását, melyek megadják, hogy a kezd pont és végpont a rétegnek éle vagy pontja-e. (Az ábrában ezt a megoldást egy kis karikával és a rá mutató nyíllal jelöltük.) Végül meg kell említenünk, hogy az Elemek hierarchiájának minden élét hozzárendelhettük volna a Rétegek hierarchiájának egy éléhez, ezt azonban a két táblában található réteg azonosítók már tartalmazzák. A bemutatott adatbázis csupán egy hálózatmodell ábrázolására szolgál. Rendszerünkben ezt természetesen kiegészítjük magasabb szint információkkal. Ilyen lehet a hálózatmodellek, a felhasználók azonosítója, a kimentéskor használt rétegtípus megjelölése.

5.2.2 A hálózatmodell memóriabeli reprezentációja 5.2.2.1 Az ábrázolás kialakításának szempontjai

•

Könny legyen b víteni. Új technológiák bevezetése ne okozzon gondot.

26

TERVEZ


•

Támogasson automatikus konzisztencia ellen rzést.

•

Legyen hatékony. Nagy hálózatok modelljein is elfogadható sebességgel, és ésszer tárigénnyel fussanak a tervez algoritmusok.

•

A tervez algoritmusok kényelmesen használhassák.

•

Támogassa a tervez algoritmusok általánosítását és újrahasznosítását.

Ezen szempontok alapján a hálózatmodell memóriabeli reprezentációjára az objektum orientált módszert választottunk. 5.2.2.2 Gráfok ábrázolása

A gráfok sokszor felbukkannak a hálózatmodellben (rétegek, algráfok, rétegek közötti gráfok) s t, azon kívül is (session). Az implementáció megválasztásánál különösen oda kell figyelni a hatékonyságra és a kényelmes használhatóságra. Gráfok reprezentációjára léteznek kész megoldások. Különösen a generikus programozási paradigma szerint készült megoldások t nnek alkalmasnak céljainkra, mivel nagyon rugalmas alkalmazást tesznek lehet vé, és viszonylag (a dinamikus polimorfizmushoz képest) gyors kód generálható bel lük. Ez a fordítási idej polimorfizmusnak és a lightweight object optimalizationnek köszönhet en nem kevésbé hatékony, mint pl. a hagyományos Fortran implementáció [12].

Implementációk: Boost Graph Library (BGL) [10], LEDA [11] Mind a BGL mind a LEDA tetszõleges objektumokból épített gráfokat képes kezelni. Tartalmaznak alapvet gráfalgoritmusokat, például topologikus rendezést, minimális feszítõfa keresést, maximális folyam keresést, stb. Képesek egymás ábrázolásait kezelni (legalábbis a BGL a LEDÁ-ét), úgyhogy akár keverni is lehet a könyvtárak szolgáltatásait egy programon belül. Ez még kényelmesebbé teszi az új algoritmusok fejlesztését. 5.2.2.3 Állandó és ideiglenes címkék

A címkéket az adatbázisban való ábrázolás megvalósításaként vezettük be. Az állandó címkék jelennek meg az adatbázisban. Ezekre lehet névvel is hivatkozni, meg speciális lekérdez függvényekkel is. Az állandó címkéket a memóriában az interpretációjuknak megfelel en célszer tárolni, így hozzáféréskor nem kell konverziót végezni. Ezen forma elérése speciális tagfüggvényekkel is lehetséges. A beállításuk viszont csak speciális metódusokon keresztül történhet, mert a konzisztencia ellen rzés így valósítható meg egyszer en. Az ideiglenes címkék nem jelennek meg az adatbázisban, csak arra valók, hogy az algoritmusok készít i ideiglenes változókat rendeljenek az objektumokhoz. Ezekre csak a nevükkel lehet hivatkozni, tartalmuk kötetlen.

Az objektumok adatbázisból való létrehozásakor nem is kell feltétlenül tudni a tárolt objektum típusát, elegend , ha a címkehalmaza kompatibilis a betöltend objektummal. Ilymódon az osztályok közötti konverzió már az adatbázisból való betöltéskor megvalósítható, és ezáltal sok felesleges adat mozgatása elkerülhet . (Például egy bonyolult rétegen végrehajtandó összefügg ség vizsgálathoz a réteg betölthet mint csupasz gráf. A járulékos adatokat nem egyszer en figyelmen kívül hagyjuk, hanem ki sem olvassuk az adatbázisból.)

27

TERVEZ


28

TERVEZ


6 Alkalmazási példák A következ kben tekintsünk néhány példát annak bemutatására, hogy a rendszerben alkalmazott hálózatmodellel hogyan lehet a tervezési lépések számára leírni a szükséges bemeneti adatokat, és hogyan lehet ábrázolni az általuk visszaadott eredményeket oly módon, hogy ezeket kés bb más tervezési lépések bemeneteként, vagy a tervezési folyamat dokumentálásaként, esetleg berendezésekre lebontott konfigurációs paraméterek listájaként felhasználhassuk. A példák során a modelleknek csak a probléma szempontjából lényeges részeit mutatjuk be, nem pedig a teljes szerkezetet, hogy áttekinthet bbek és jobban nyomonkövethet k legyenek a megfeleltetések.

6.1 Els példa: forgalmi tervezés A példában kiindulási adatként ismert a forgalmi mátrix, amely a három csomópont közötti igényeket írja le. A forgalmi mátrix nem szimmetrikus, ezért ebben a rétegben irányított gráffal reprezentálhatjuk a különböz csomópontok közötti igényeket. Két csomópont között az egyik irányban fellép forgalmi igény mértékét a megfelel élen egy címkével jelezhetjük. Ugyanezen rétegben egy másik részgráffal leírható a csomópontok közötti hierarchia, amely szerint most az A és C pontok primer központokat jelölnek, a B pont pedig egy szekunder, illetve tranzit központ. (Megjegyzés: a példákban el forduló ábrákon a címkéknek általában vagy csak a nevei, vagy csak az értékei szerepelnek, értelemszer en.)

B

B

forg.

forg. forg.

forg.

A

C forg.

A

C

forg.

10. ábra: A forgalmi mátrix reprezentációja és a csomópont-hierarchiát leíró kiegészít gráf

Ez a réteg minden adatot tartalmaz ahhoz, ami egy forgalmi tervezést végz algoritmus futtatásához szükséges. Képzeletben elvégezve a forgalmi algoritmus lépéseit például a következ topológiai gráfot kaphatjuk. B’

A’

C’

11. ábra: Az áramköröket leíró gráf

29

TERVEZ


Az áramköröket leíró gráfnak már nincsenek irányított élei, mivel az áramköri mátrix szimmetrikus. Ahhoz azonban, hogy a forgalmi elvezetés teljes eredményét leírhassuk, szükség van a piros élekre is, amelyek két réteg közötti megfeleltetéseket jeleznek élek és pontok között. A piros élek segítségével tehát leírhatjuk, hogy az egyes igények mely útvonalakon lesznek elvezetve. Minden egyéb szükséges információ leírható a piros élekhez kapcsolt címkék segítségével. A következ táblázat összefoglalja a forgalmi tervezés során felvett piros éleket címkéikkel együtt. (Illetve ezek közül csak azokat, amelyek az élek közötti megfeleltetéseket írják le.) piros él kezd és végpontja AB A’B’ BA A’B’ BC B’C’ CB B’C’ AC A’C’ AC A’B’ AC B’C’ CA A’C’ CA B’C’ CA A’B’

útvonal sorszáma 1. 1. 1. 1. 1. 2. 2. 1. 2. 2.

a mutatott él helye az úton 1. 1. 1. 1. 1. 1. 2. 1. 1. 2.

B

A

C

B’

A’

C’

12. ábra: Egy példa a piros élek felvételére

Tekintsük például a C és A pontok között ebben az irányban jelentkez igényt (12. ábra). Ez két úton lett elvezetve, az els út a közvetlen kapcsolat, azaz az A’C’, egyetlen élb l álló útvonal, a második pedig a B’C’ és A’B’ élekb l ebben a sorrendben felépül alternatív, a megadott csomóponti hierarchia figyelembe vételével kialakított útvonal.

30

TERVEZ


6.2 Második példa: ATM hálózaton VC elvezetés konfigurációs szint leírása Ebben a példában bemutatjuk, hogy hogyan használhatjuk a rétegelt modell sokoldalúságát a címkékkel ellátott gráfreprezentáció segítségével ki egy valószer hálózat részletes, a berendezéseket és azok konfigurációját is tartalmazó leírására.

A 13. ábra egy ATM hálózat egy részletét mutatja. A kis táblák az ATM kapcsolók konfigurációs táblázatának a nyilakkal jelzett VC-re vonatkozó részeit tartalmazzák. Más színnel jelöltük meg azokat a kacsolókat, ahol csak VP kapcsolás történik. A következ kben a megjelölt VC elvezetésének modellbeli reprezentációját fogjuk bemutatni. in out 2/1/50 3/2/50

in out 1/2/50 2/3/51

in out 1/0/100 2/1/50

in 3/3/51

out 4/4/51 in 1/6/52

in 1/4/51

out 2/1/31

out 2/6/52

13. ábra: ATM mintahálózat

A modell VCC rétegében a kérdéses VC egyetlen irányított gráfélként jelenik meg, amely az A-val és I-vel jelölt két el fizet i csatlakozási pont között található. F

A

B

H

D

I

G

14. ábra: A mintahálózat modelljének VCC rétege

A modell következ rétegében a VC-t már szakaszokra bontjuk, és elvezetjük különböz VPC-ken keresztül. (Az algoritmikus részleteket nem érintve feltételezzük, hogy a VC elvezetése a következ ábrán látható VPC-ket érinti.) F’

A’

B’

H’

D’

G’

15. ábra: A mintahálózat modelljének VPC rétege

31

I’

TERVEZ


Azt, hogy a vizsgált VCC-t az el bbi ábrán látható VPC-ken keresztül vezettük el, megint a piros élek segítségével tudjuk leírni, amelyek közül a gráféleket összerendel ket az áttekinthet ség kedvéért ismét egy táblázatban adjuk meg. piros él kezd és VPC sorszáma végpontja a VCC elvezetésében AI A’B’ 1. AI B’F’ 2. AI F’G’ 3. AI G’H’ 4. AI H’I’ 5.

VCI a VPCben 100 50 51 52 31

A piros élekhez kapcsolt címkék most a piros él által mutatott VPC-nek a VCC elvezetésénél létrejött útban elfoglalt helyét jelzik, illetve azt, hogy az adott VPC-ben a VCC cellái milyen VCI-vel fognak utazni. Az itt érintett csomópontokban biztosan VP/VC kapcsolásra lesz szükség. Végül a modell utolsó rétege az ATM link réteg, amelyben már konkrét berendezések közötti kábelezést lehet leírni. Ennek a reprezentációnak a számunkra most lényeges részét a 16. ábra mutatja be. 1 F”

C” 3

2 A”

2 E”

B” 2 1 D”

H”

3

4 1

1

G”

I” 2

2

16. ábra: A mintahálózat modelljének fizikai rétege

Az ábrán egy gráfél tulajdonképpen egy kábelnek és egyben egy VPL-nek is megfelel. Az egyes linkekhez két címkét kapcsolunk, amelyek megmondják, hogy a kiindulási csomópontban és a végcsomópontban található berendezések mely portjaira kell kötni a link által reprezentált kábelt. (Mivel esetünkben szimmetrikusak a linkek, ezért irányítatlan élekkel ábrázoltuk ket. A két végpont közül kiindulásinak tekinthetjük például a kisebb azonosítóval rendelkez t, de ez a megkülönböztetés hangsúlyozottan nem jelent irányt.) A csomópontokban szükséges berendezéseket a csomópontokhoz kapcsolt címkék segítségével jellemezhetjük. A két utolsóként ábrázolt réteg között is szükségünk lesz piros élekre, amelyekkel az el z rétegben megjelent VPC-k VPL-ekben történ elvezetését írhatjuk le. A teljesség kedvéért közöljük ezt a gráféleket összerendel piros éleket tartalmazó táblázatot is.

32

TERVEZ


piros él kezd és VPL sorszáma végpontja a VPC elvezetésében A’B’ A”B” 1. B’F’ B”C” 1. B’F’ C”F” 2. F’G’ E”F” 1. F’G’ E”G” 2. G’H’ G”H” 1. H’I’ H”I” 1.

VPI a VPLben 0 1 2 3 4 6 1

Az egy VPC elvezetésénél közbüls pozícióban lev csomópontokban elegend VP kapcsolás is, nincs szükség a komplexebb VP/VC kapcsolásra. Minden további magyarázat nélkül látható, hogy a modellb l el állítható a kiindulási mintahálózat szükséges konfigurációs beállításainak listája, ugyanakkor a hálózat bármelyik rétege is könnyen hozzáférhet , és a tervezési metódusok számára is értelmezhet formában áll rendelkezésre.

6.3 Harmadik példa: ATM tervezés Utolsó példánkban egy (meglehet sen egyszer ) ATM tervezési folyamat modellezését fogjuk végigkövetni az igények ábrázolásától kezdve egészen a fizikai rétegig. Az igényeket leíró mátrixok (egy a kapcsolt, egy pedig az állandó igényeknek) gráfreprezentációját kiindulásképpen felrajzoltuk (17. ábra).

kapcsolt

kapcsolt

állandó

állandó

B

C

kapcsolt

kapcsolt

kapcsolt

kapcsolt

kapcsolt

állandó

kapcsolt

állandó

A

D kapcsolt

kapcsolt

17. ábra: Igényréteg

Az egyes gráfélek címkéivel tudjuk egymástól megkülönböztetni a kapcsolt, illetve az állandó igényeket. Természetesen a forgalom egyéb paraméterei további címkék segítségével leírhatók, amelyeket azonban az ábrán nem tüntettünk fel. A következ rétegben megtörténik az igények VCC-kre történ leképezése. Itt meg kell jegyeznünk, hogy csak a PVC-k jelennek meg, ugyanis csak az állandó igényeknek lehet

33

TERVEZ


konkrét VCC-ket megfeleltetni, az SVC-kre csak a VPC-kben történ tartalékolással tudunk felkészülni, ugyanis ezek pontos száma el re nem ismert. B’

C’

A’

D’

kapacitás-

18. ábra: VCC réteg

A két réteg közötti piros éleket úgy vesszük fel, hogy az el z rétegbeli állandó igényeknek egy-egy VCC-t feleltetünk meg a VCC rétegben feltéve, hogy minden egyes állandó igényt ki lehet elégíteni egyetlen VCC-vel. A piros élek címkéit az el z példában bemutatotthoz hasonlóan töltjük ki. (A táblázatot ezúttal azonban mell zzük.) A tervezés következ lépésében a VCC rétegben található VCC-ket, illetve az igényrétegben található kapcsolt igényeket kell a VPC rétegben megfeleltetni. Tegyük fel, hogy a tervez algoritmus futtatása a következ eredményt adta. B”

C”

A”

D” 19. ábra: VPC réteg

Most egy olyan helyzet állt el , amikor úgy kell felvennünk piros éleket a modell rétegei között, hogy azok nem csak „szomszédos” rétegeket fognak összekötni. Egyrészt ugyanis a VCC rétegb l indulnak piros élek, amelyek a VPC rétegben fognak végz dni, másrészt pedig a kapcsolt igényeket leíró, igényrétegbeli élek is közvetlenül a VPC rétegbe fognak leképez dni. Érdekessége miatt lássuk tehát az élek között újonnan felvett piros éleket összefoglaló táblázatot.

34

TERVEZ


piros él kezd és végpontja A’B’ A”B”/1 AB/kapcsolt A”B”/2 B’A’ B”A”/1 BA/kapcsolt B”A”/2 B’C’ B”C”/1 BC/kapcsolt B”C”/2 C’B’ C”B”/1 CB/kapcsolt C”B”/2 AC A”C” CA C”A” CD C”D” DC D”C” AD A”D” DA D”A”

VPC sorszáma az elvezetésben 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1.

VCI a VPC-ben 1 1-20 1 1-15 1 1-17 1 1-23 1-11 1-9 1-12 1-11 1-4 1-3

Az élek természetesen egyedi azonosítóval rendelkeznek a rendszerben, ugyanis két pont között egy irányban futó több párhuzamos él esetén a táblázatban egyértelm en fel kell tüntetnünk, hogy pontosan melyik éleket feleltetjük meg egymásnak. Ebben a példában viszont az egyedi azonosítók elhagyása miatt „/” jellel jelöltük a megkülönböztet jegyet, amelyre tehát a rendszerben nincsen szükség.

Az utolsó réteg a fizikai réteg, amelyben az egyes VPC-k leképez dnek fizikai linkekre (VPL-ekre). Az itt felvett piros éleket tartalmazó táblázatot az el z példához hasonlóan kell felvenni, az eredményül kapott gráfot a 20. ábra mutatja be.

B”’

C”’

A”’

D”’ 20. ábra: Fizikai réteg

Ezen a szinten az utolsó lépést végrehajtó algoritmus egy megfelel berendezéslista alapján már képes meghatározni a hálózat megvalósításának eszközigényét is. Azt, hogy a fizikai rétegben a gráf elemei milyen valós eszközöknek felelnek meg, a hozzájuk csatolt címkékkel jelezhetjük. Pl. Az A”’ csomóponthoz hozzákapcsolhatunk egy címkét, amely jelzi, hogy egy ATM kapcsolóról van szó, egy másikat, amely esetleg a kapcsoló típusáról tartalmaz információt, egy harmadikat, amely leírja, hogy hány portra van szükség a kapcsolóban, stb. Az egyes élekhez csatolt címkékb l egyrészt kiderülhet, hogy azok milyen típusú kábelt reprezentálnak, másrészt arról is tartalmazhatnak információt, hogy a berendezések melyik csatlakozási pontjához kell kapcsolni ket.

35

TERVEZ


A tervezés végeredményének azonban nem csupán a fizikai réteget tekintjük, hiszen ez önmagában nem tartalmaz elegend információt az igényeket kielégít rendszer létrehozásához. A tervezés végeredménye az egész hálózatmodell az igény, VCC, VPC és fizikai rétegekkel, az ezek között felvett piros élekkel és az egyes gráfelemekhez kapcsolt címkékkel együtt. Ez ugyanis az az adathalmaz, amely minden olyan tulajdonságát leírja a hálózatnak, amely a tervezés és a konfiguráció szempontjából fontos.

36

TERVEZ


7 Összegzés Dolgozatunkban specifikáltuk egy korszer technológiák alkalmazásával megtervezett hálózattervez i rendszer szerkezetét. Bemutattunk egy sokoldalúan alkalmazható, mégis áttekinthet szerkezet tervez i rendszer koncepciót (és a hozzá kapcsolódó UML leírás egy részét), amely a session fogalmának bevezetése által képes a tervezési folyamatok automatikus dokumentálásának támogatására és reprodukálhatóságuk biztosítására. Ezt követ en rendszerünket a hálózattervezés témakörében alkalmazva kiegészítettük azt egy, a rétegelt hálózatmodellre épül , címkékkel ellátott gráfokat használó hálózatmodellel. Ennek a modellnek az alkalmazásával a hálózattervezés során felmerül adatok a közöttük lev összefüggések meg rzésével tárolhatók az igényekt l kezdve a berendezések konfigurációjáig. Ezt kihasználva lehet ség nyílik majd a hálózatmenedzsment rendszerekkel történ online együttm ködésre. A modell sokoldalúságának köszönhet en a legkülönfélébb tervezési feladatok megoldására alkalmazható a megfelel algoritmusok implementálásával, amit néhány példa bemutatásával próbáltunk meg igazolni.

A tervez i rendszer implementálása folyamatban van, és már elkészült egy modellfüggetlen implementáció a keretrendszer m ködésének bemutatására. Hátra van még a menedzsment rendszerekkel történ együttm ködés részletes kidolgozása, illetve a modell és az azzal dolgozó algoritmuskészlet egy részének implementálása.

37

TERVEZ


38

TERVEZ


8 Szójegyzék Model: Tulajdonképpen egy rétegelt hálózatmodell néhány, a rendszer m ködése szempontjából fontos adminisztratív jelleg adattal kiegészítve.

Session: A tervezési folyamat teljes érték dokumentációja, amely tartalmazza (referenciaként) a tervezés során kiindulási pontnak tekintett hálózatmodellt, a tervezés során alkalmazott lépéseket, azok sorrendjének és az esetleges elágazásoknak egy fában történ ábrázolásával, valamint a tervezési lépések fájában a csomópontokban eredményül kapott hálózatmodell(eke)t. Emellett kiegészül még a készít és csoportja azonosítójával, illetve néhány, a használhatóságot segít szöveges jelleg kommenttel.

Method: A tervezés során használt algoritmusok (melyek ezen a szinten egyel re nem jelennek meg önálló elemként) egyetlen tervezési folyamatba foglalását végz szerepl . Tulajdonképpen az egymástól jól elkülönül tervezési fázisokban gyakran, rutinszer en alkalmazott algoritmusok egymásutánját fogja össze. Épít kövei tehát az algoritmusok. A metódus egy hálózatmodell és néhány tetsz leges, de nem modell típusú bemen paraméterb l készít egy új hálózatmodellt. A rendszer felületén a metódusok egyel re atomi entitásokként jelennek meg.

Evaluation: Gyakorlatilag a Methoddal állítható párhuzamba, csupán egyetlen eltérés van, az eredménye nem egy újabb hálózatmodell, hanem egy szöveges jelleg adathalmaz, amely meghatározott szempontok alapján min síti az adott modellt. Tartalmazza (referenciaként) az értékelés alapjául szolgáló hálózatmodellt, a felhasznált Evaluatort (ami tulajdonképpen az értékelési szempontok metódusszer leképezése a rendszerbe), annak az értékelés során alkalmazott paraméterezését, valamint az eredményül kapott adatokat.

Step: A tervezési folyamatban szerepl egyetlen tervezési lépés dokumentációja, az adott lépésben használt metódus (, amely lehet akár a hálózatmodell kézi módosítása), és az alkalmazott paraméterek találhatók meg benne. Evaluator: Speciális metódus, amely egy hálózatmodellb l kiindulva nem egy másik hálózatmodellt állít el , hanem a kiindulási modell meghatározott szempontok szerinti min sítését. A min sítés szempontjait ugyancsak algoritmusok testesítik meg a rendszerben. Parameters: A metódusok és értékel k (esetleges) nem hálózatmodell jelleg bemeneti adatait leíró szerepl .

Default parameters: A metódusok és értékel k (esetleges) nem hálózatmodell jelleg bemeneti adatainak összes lehetséges értékeit, illetve azok értelmezését és leggyakrabban használt értékeit leíró szerepl .

User: A felhasználók személyes adatait, illetve jogosultságait tárolja, tulajdonképpen az egyes valós szerepl k rendszerbeli megfelel je. Group: A valós tervez csoport rendszerbeli leképezése. Egybefogja a tervez csoport tagjait, közös terveit. Létrehozásakor egyetlen tagja van, a létrehozója. Profile: A felhasználó bejelentkezésekor egy ilyen objektum jön létre, amely közvetlen interface lesz a felhasználó, illetve a rendszer között a bejelentkezés id tartama alatt. (Biztonsági megfontolásokból érdemes ezt a funkciót különválasztani a User objektumtól.) Egy adott felhasználó egy adott csoportban végzett tevékenységéhez köt dik. Authentication manager: Bejelentkezéskor azonosítja a valós felhasználóhoz tartozó User objektumot, illetve létrehozza a szükséges Profile objektumot. Ez utóbbit csoportváltáskor is megteszi.

39

TERVEZ


40

TERVEZ


9 Irodalomjegyzék [1]

Bharat Doshi and P. Harshavardhana, “Broadband Network Infrastructure of the Future: Roles of Network Design Tools in Technology Deployment Strategies”, IEEE Communications Magazine, May 1998, pp. 60-71

[2]

W. D. Grover, “Self-Organizing Broadband Transport Networks”, Proceedings of the IEEE, October 1997, pp. 1582-1611

[3]

L. Jereb, T. V. Do, G. I. Rózsa, “Flexible Planning of Telecommunications Networks Based on Layered Network Model", the 6th International Conference on Telecommunication Systems, Modelling and Analysis, March, 1998, Nashville, USA

[4]

B. Oestereich,”Developing software with UML: Object-oriented analysis and design in practice”, Addison-Wesley, 1999

[5]

G. Pavlou, “Using Distributed Object Technologies in Telecommunications Network Management”, IEEE Journal on Selected Areas in Communications, May 2000, pp. 644-653

[6]

J. Rumbaugh, Jacobson, Booch, “Unified Modeling Language”, Addison-Wesley, 1997

[7]

J. Siegel, “CORBA Fundamentals and Programming”, John Wiley & Sons, 1996

[8]

T. V. Do, B. Kálmán, Cs. Király, Zs. Pándi, “A Tool for the Service Planning and Management of Multi-layer Networks”, Networks2000 Conference, Toronto, 2000

[9]

Bert Bos, XML in 10 points, http://www.w3.org/XML/1999/XML-in-10-points

[10]

Boost Graph Library (BGL), http://www.boost.org/libs/graph/docs/, (azel tt Generic Component Library (GGCL), http://www.lsc.nd.edu/research/ggcl/) Lie-Quan Lee, Jeremy G. Siek, and Andrew Lumsdaine. The generic graph component library. In Proceedings OOPSLA'99, 1999

[11]

Algorithmic Solutions Software GmbH, LEDA graph library, http://www.mpisb.mpg.de/LEDA/

[12]

The Generic Graph Component Library http://www.lsc.nd.edu/research/ggcl/performance.php3

41

Performance

Results,

Tervez és menedzsment-támogató rendszer rétegelt hálózati architektúrákhoz

Recommend Documents