ATONA VA ANA 2.0 A NETWORK ANALYSIS - …maxwell.sze.hu/docs/l17.pdf · program UML osztály -...

ÍRTA Katona Éva Elektromágneses Terek Laboratórium 2008. november

KONZULENS Dr. Kuczmann Miklós, PhD Egyetemi docens

TANULMÁNYOK Széchenyi István Egyetem Műszaki Tudományi Kar

Jedlik Ányos Gépész-, Informatikai és Villamosmérnöki Intézet

Mérnök Informatikus (BSc) III. évfolyam Villamosmérnöki (BSc) I. évfolyam

E-MAIL [email protected] WEB http://maxwell.sze.hu/~vica

KATONA ÉVA

ANA 2.0 ADVANCED NETWORK ANALYSIS

ANA – ADVANCED NETWORK ANALYSIS

- 2 -

TARTALOMJEGYZÉK

1. BEVEZETÉS ............................................................................................. 4

2. VÁLTOZÁSOK A PROGRAM STRUKTÚRÁLIS FELÉPÍTÉSÉBEN ........................ 6

2.1. ANACOMPONENTPROTOTYPE CSOMAG .......................................... 7

2.2. ANADOCUENT CSOMAG................................................................ 8

2.3. ANALYSIS CSOMAG........................................................................ 8

2.4. DATA CSOMAG ............................................................................10

2.5. GUI (GRAPHICAL USER INTERFACE) CSOMAG .............................10

2.6. HELPERS CSOMAG .......................................................................14

2.7. LOADER CSOMAG.........................................................................20

2.8. SETTINGS CSOMAG ......................................................................20

2.9. WORKSHEET CSOMAG..................................................................21

2.10. XMLTOOLS CSOMAG.................................................................28

3. ÚJRATERVEZÉS (REFACTORING)............................................................29

3.1. KOMPONENS – HIERARCHIA.........................................................29

3.1.1. ANACOMPONENT ..........................................................31

3.1.2. NODE.............................................................................32

3.1.3. CONNECTION ..................................................................34

3.2. INTERACTION MANAGMENT ........................................................35

3.3. TRANSZFORMÁCIÓK ....................................................................39

4. TERVEZÉSI MINTÁK (DESIGN PATTERNS) ..............................................42

4.1. SINGLETON TERVEZÉSI MINTA .....................................................42

4.2. REGISTRY PATTERN....................................................................43

4.3. MVC (MODEL VIEW CONTROLLER) PATTERN .............................43


- 3 -

5. HÁLÓZATOK SZERKESZTÉSE ...................................................................44

5.1. KOMPONENSEK BESZÚRÁSA, SZELEKCIÓK ...................................44

5.2. VEZETÉKEZÉS, KOMPONENSEK ÖSSZEKÖTÉSE..............................46

5.3. KOMPONENSEK ÉRTÉKEINEK BEÁLLÍTÁSA ...................................47

6. ANALÍZIS ..............................................................................................48

6.1. BESZÚRHATÓ KOMPONENSEK, KARAKTERISZTIKÁK......................48

6.1.1. KIRCHHOFF – HÁLÓZATOK KOMPONENSEI........................48

6.1.2. JELFOLYAM – HÁLÓZATOK KOMPONENSEI .......................55

6.2. CSOMÓPONTI POTENCIÁLOK MÓDSZERE ........................................58

6.2.1. CSOMÓPONTI POTENCIÁLOK, MÁTRIX – EGYENLET ...........55

6.2.2. EGY PÉLDA MEGOLDÁSÁNAK LEVEZETÉSE.......................61

7. KONKLÚZIÓ ...........................................................................................68

BIBLIOGRÁFIA............................................................................................69


- 4 -

1. BEVEZETÉS

A dolgozat témája egy JAVA nyelven írt hálózatanalízis program, ami rendelkezik egy felhasználóbarát grafikus felülettel (1.1. ÁBRA), és megvalósítja az összes olyan megszokott kényelmi funkciót, amit a többi hálózatanalizáló program is implementál. Továbbá az objektum-orientált fejlesztésnek köszönhetően kihasználja a JAVA nyelv optimális tulajdonságait, a forráskód logikailag szétkülönítethető csomagokra és osztályokra bontását, valamint a nyelv hordozhatóságából és architektúrafüggetlenségéből következő platformfüggetlenséget, amiből következően a program az összes, a JAVA által támogatott operációs rendszer alatt használható.

Az programot ANA (Advanced Network Analysis) névre kereszteltem. Fejlesztését 2008. februárjában kezdtem. Azóta a grafikus felhasználói felület jelentős része és a legtöbb kényelmi funkció implementálása, továbbá az első analízis pont, a csomóponti potenciálok, a komponenseken eső feszültségek és folyó áramok, valamint a teljesítményeik számításának integrálása is befejeződött.

A dolgozat a 2008 tavaszi ANA 1.0 – Advanced Network Analysis című dolgozat folytatása. Az előző dolgozat témája a program felhasználói, szakterületi, funkcionális és nem funkcionális követelményeinek feltárása, valamint a felhasználói felület alapjainak bemutatása.

A nyár folyamán a program struktúrája újratervezés és átalakítás alá került. A régi megvalósítás helyett számos területen optimálisabb megoldások implentációja történt. Változások történtek a komponensek felépítésében,

1.1. ÁBRA: A PROGRAM GRAFIKUS FELHASZNÁLÓI FELÜLETE


- 5 -

megjelenítésében és tárolásában, valamint a transzformációkban és a szerkesztőfelület eseménykezelésben. A dolgozat első fele ezeket az újításokat tárja fel, majd a második rész az első integrált analízis pontok alapjait és implementációját.


- 6 -

2. VÁLTOZÁSOK A PROGRAM STRUKTÚRÁLIS FELÉPÍTÉSÉBEN

Egy nagyobb program elkészítésekor törekedni kell az áttekinthető, könnyen módosítható, és továbbfejleszthető kód előállítására. Ennek eléréséez a programokat megfelelően tagolni kell. A tagolásnak már az objektumorientált modellezés és a programtervezés szintjén meg kell nyilvánulnia. Az összetartozó osztályokat ezért – a modell és a működés szerint – csomagokba kell szervezni. A csomagokból képezhető egy magas szintű zárt egység.

Minden csomag egy önálló névteret vezet be, amelyben egyedivé teszi a benne található osztályok szerkezetét. A csomag alkalmas a hozzáférési kategóriák kezelésére, és a csomagszintű hozzáférési kategóriával definiált osztályok, interfészek, metódusok csak a csomagon belül lesznek elérhetőek.

A csomagoknak nyelvi szinten a fordítási egységek (osztályok, interfészek) adnak konkrét tartalmat. Egy csomaghoz tartozó fordítási egységben található a csomag forráskódja. Ez a csomagszerkezet hierarchikus – hasonlóan az állományok könyvtárszerkezetben való elhelyezéséhez – így a csomagok között logikai alá-fölérendeltségi viszony is előfordulhat. Ekkor alcsomagnak nevezzük a csomagban található másik csomagot. Minden csomag teszőleges számú alcsomagot tartalmazhat [13].

Az újratervezés során megváltoztak az osztályok feladatai és felépítése. Számos osztály új vagy kiegészített tevékenységet lát el az előző verzióban szereplő osztályokhoz képest, továbbá számos nagyobb terjedelmű osztály, kisebb logikailag elkülöníthető osztályok létrehozását indokolta. Ennek köszönhetően megváltoztak az osztályok közötti logikai összefüggések és kapcsolatok, ezért a forráskód csomagokra tagolását is át kellett alakítani új, a jelenlegi logikai egységeknek megfelelő modulok hierarchiájára [8].

Ez a fejezet az új csomag-hierarchia fő egységeit írja le (2.1. ÁBRA) a program UML osztály - diagramjainak illusztrálásával, továbbá az osztályok által megvalósított legfontosabb funciókat foglalja össze [10 - 16], [19].

2.1. ÁBRA: AZ ÚJ CSOMAG-HIERARCHIA FŐ EGYSÉGEI


- 7 -

2.1. ANACOMPONENTPROTOTYPE CSOMAG

A programban a hálózatok minden komponenséhez tartozik egy prototípus, ami tartalmazza a komponens tulajdonságait (pl. azonosító, név, ikon), beállításait (pl. típus, érték, láthatóság) és a felhasználói felületen megjelnő grafikus képét. Különböző XML (Extensible Markup Language) fájlok tárolják a komponensek ezen attribútumait.

A fejlesztés során az XML használat mellett szólt, hogy az XML dokumentumok közönséges szöveges állományok, melyek könnyen, akár egy egyszerű szövegszerkesztővel is szerkeszthetőek, tovbábbá a programon belül önálló, külön egységket alkotnak (LÁSD 2.4. FEJEZET), így az általuk tárolt adatok könnyen, a programba való belenyúlás nélkül módosíthatóak. Ez azért volt fontos, mert a komponenseken kívül, a grafikus felhasználói felület főbb komponensei (menük, eszköztárak) is XML fájlokban tárolt attribútomok alapján épülnek fel (LÁSD 2.6. FEJEZET), így például egy új menüpont hozzáaadása a program módosítása nélkül megtehető.

Az XML fájlokban tárolt prototípus listát és a prototípusokat az ’ANAComponentPrototypeStore’ osztály validálja, és ha megfelelő a szintaktika akkor az alábbi osztályok meghívásával betölti a komponenseket.

A tulajdonságok, beállítások és a grafiuks képek az ’ANAComponentPrototype’ osztály metódusain keresztül érhetők el. Minden prototípus – objektum ezen osztály egy példánya. Az objektumok felépítése az alábbi osztályok segítségével történik.

Az ’ANAComponentShapeFactory’ osztály felépíti a megadott alakzatokból a komponensek grafikus képeit. Az ’ANAComponentPrototypeFactory’ osztály pedig felépíti az egyes prototípusok objektumait, beállítja a tulajdonságaikat és az attribútumaikat az XML fájlokban tároltak alapján, valamint az előző osztály hívásával létrehozza és tárolja a grafikus objektumaikat (2.1.1. ÁBRA).

2.1.1. ÁBRA: ANACOMPONENTPROTOTYPE CSOMAG


- 8 -

2.2. ANADOCUMENT CSOMAG

A program által szerkesztett hálózatok mentését segítik elő az ’ANADocument’ csomag osztályai (2.2.1. ÁBRA). A hálózatok tulajdonságait XML file-ok tárolják és egy zip file-ba lesz kimenthető a szerkesztett hálózat ’*.ana’ file kiterjesztéssel. Ez a csomag és az általa megvalósítandó funkciók jelenleg is fejlesztés alatt állnak.

2.3. ANALYSIS CSOMAG

Az analízis funkciók implementálása a garfikus felhasználói felület újratervezése és átalakítása után kezdődött idén szeptemberben. Az ’Analysis’ csomag tárolja az analízis pontok logikailag különválasztható csomagjait és ezekben a megvalósító osztályokat (2.3.1. ÁBRA).

A hierarchiában a gyökérkönyvtárban található az ’Analysis’ absztrakt osztály, mely szülő osztálya az összes analízis osztálynak. A leszármaztatott osztályok ezen osztály ’start()’ és ’finish()’ metódusát definiálják felül, melyek segítségével a program tudja, hogy mely tevékenységeket kell megvalósítania egy analízis pont elindításakor és befejezésekor.

Az objektumorientált fejlesztés során az öröklődés és a többalakúság nagyon fontos szempont. Az ősosztályok összehangolják a leszármazott osztályok működését, vagyis definiálják a közös műveleteket és megadják a szabványos üzenetek prototípusait. Ezzel egy egységben kezelhető osztályhierarchiát adhatnak a programozó kezébe. Az osztályhierarchia legtetején szereplő osztályok szerepe általában az, hogy a leszármazottaknak előírja, hogy milyen üzenetekre válaszoljon. A leszármazott osztályokból létrehozott példányok a „keresd az őst” elvnek megfelelően megkeresik a hozzájuk tartozó üzenet végrehajtásának definícióját. Sokszor azonban az osztályszerkezet tetején álló osztály – a fejlesztendő feladatból kifolyólag – csak egy elméleti fogalom, vagyis csak teljesen általános fogalmakkal írható le, azaz hiányoznak belőle a konkrétumok.

Az ilyen általános érvényű osztályokhoz absztrakt osztályokat definiálunk. Az absztrakt osztályokban – és csakis itt – megadhatunk absztrakt metódusokat is. Az absztrakt metódusok törzs nélküli metódus deklarációk. A metódusokat a leszármazott osztályokban kötelező felüldefiniálni, megvalósítani [13].

2.2.1. ÁBRA: ANADOCUMENT CSOMAG


- 9 -

Minden analízis pont alcsomagában található egy ’Interactions’ alcsomag (2.3.1. ÁBRA), mely a szerkesztői felület adott analízis ponthoz tartozó interakcióit valósítja meg (pl. csomóponti potenciáloknál a különböző értékek megjelenítése a dialógus ablakban, a felületen történő egérkattintás esemény célja (komponens vagy vezeték) alapján). Az interakciókezelés az egyik legfontosabb újratervezett modul, melyet a 3.2. FEJEZET egy külön tárgyal.

2.3.1. ÁBRA: ANALYSIS CSOMAG


- 10 -

2.4. DATA CSOMAG

A ’Data’ csomag (2.4.1. ÁBRA) logikailag szétválasztható alcsomagokra osztottan tárolja a programhoz tartozó XML file-okat.

Az ’ANAComponents’ alcsomag tartalmazza a komponensek XML file-jainak szintaktikai deklarációját tartalmazó ’ANAComponent.dtd’ file-t, valamint a komponens listát tartalmazó ’ANAComponents.xml’ file-t, valamint a jelfolyam-, és a Kirchhoff – típusú hálózatok komponenseinek XML file-jait tartalmazó ’Network’ és ’System’ alcsomagokat.

A ’*.dtd’ kiterjesztésű fájlok dokumentum típus deklarációk (Document Type Declarations).

Egy XML dokumentum elején megadható, hogy az adott dokumentum milyen típusú, vagyis milyen elemek és entity-hivatkozások szerepelhetnek benne. A DTD-kben vannak felsorolva az elemtípusok, megadva az elemek tartalmára vonatkozó szabályokat; és az entity deklarációk.

A DTD segítségével a dokumentum ellenőrizhető, a benne leírt szabályokat egy XML editor segítségével be lehet tartatni.

A ’Dialogs’ alcsomag a dialógus ablakok adatait és összetevőit tartalmazó XML file-okat tárolja, az ’Images’ mappa a menük és az eszköztárak felépítéséhez szükséges képeket, végül az utolsó két alcsomag a ’Menus’ és ’ToolBars’ alcsomag a menük és eszköztárak metaadatait tartalmazza.

2.5. GUI (GRAPHICAL USER INTERFACE) CSOMAG

A ’GUI’ csomag tárolja a grafikus felhasználói felület objektumait logikailag szétválasztható alcsomagokra osztottan (2.5.1. ÁBRA).

2.4.1. ÁBRA: A DATA CSOMAG ÉS ALCSOMAGJAI


- 11 -

A ’Dialogs’ alcsomag tárolja a különböző dialógus ablakok objektumait (2.5.2. ÁBRA). Az objektumokat az XML file-okból a ’DialogFactory’ osztály (LÁSD 2.6 FEJEZET) építi fel.

A ’MainWindow’ alcsomag (2.5.3. ÁBRA) a program főablakának legnagyobb összetevőit tartalmazza, az objektumok draggeléséhez (egérrel való vonszolás) szükséges felületet megvalósító ’ComponentDragPane’ osztályt, a program betöltésekor megjelelenő felületet megvalósító ’WelcomePanel’ osztályt, valamint a főablak összes objektumát példányosító ’MainWindow’ osztályt.

2.5.1. ÁBRA: A GUI CSOMAG ALCSOMAGJAI

2.5.2. ÁBRA: GUI/DIALOGS CSOMAG


- 12 -

A ’Menus’ (2.5.4. ÁBRA), ’ToolBars’ (2.5.5. ÁBRA) és ’StatusBar’ (2.5.6. ÁBRA) alcsomagok tárolják a program különböző eszköztárait, menüit és az állapotsort megvalósító osztályokat, végül a ’Worksheets’ alcsomag (2.5.7. ÁBRA) tárolja a programon belül futó összes munkalap kezelését irányító ’Worksheets’ osztályt.

2.5.3. ÁBRA: GUI/MAINWINDOW CSOMAG


- 13 -

2.5.4. ÁBRA: GUI/MENUS CSOMAG

2.5.5. ÁBRA: GUI/TOOLBARS CSOMAG

2.5.6. ÁBRA: GUI/STATUSBAR CSOMAG


- 14 -

2.6. HELPERS CSOMAG

A program számos segéd osztályt használ futás közben. Ezek az osztályok találhatóak a ’Helpers’ csomagban az adott funkcióknak megfelelően logikailag elkülönítetten (2.6.1. ÁBRA).

Az ’Analysis’ (2.6.2. ÁBRA) alcsomag reprezentálja az analízis pontok futtatásához szükséges segédfunkciókat. Itt találhatóak meg a matematikai segédeszközök, a mátrixműveleteket (szorzás, konjugált képzés, inverzmátrix képzés, Gauss – Jordan – elimináció) végző osztályok, valamint a hálózat felépítését és a csomópontok létrehozását segítő ’LogicalNode’ és ’NodeModel’ osztályok.

2.5.7. ÁBRA: GUI/WORKSHEETS CSOMAG

2.6.1. ÁBRA: HELPERS CSOMAG ALCOMAGJAI


- 15 -

A ’GUI’ csomag tartalmazza az ’Adapters’ (2.6.3. ÁBRA), ’Factories’ (2.6.4. ÁBRA), ’Graphics’ (2.6.5. ÁBRA) és ’Wrappers’ (2.6.6. ÁBRA) alcsomagokat.

Az ’Adapters’ (2.6.3. ÁBRA) alcsomag tartalmazza többek között azt az osztályt, amely a ’Swing’ eseménykezelését segíti oly módon, hogy számos ’listener’ interface-t implementál üres metódusokkal. A specifikus eseménykezelő osztályok pedig ezen metódusok közül definiálják felül azokat amelyeket az adott feladat megkíván.

2.6.2. ÁBRA: HELPERS/ANALYSIS CSOMAG


- 16 -

2.6.3. ÁBRA: HELPERS/GUI/ADAPTERS CSOMAG


- 17 -

A ’Wrappers’ (2.6.4. ÁBRA) alcsomag osztályai a grafikus felület elemeinek (menü, eszköztár) nyújtanak egy olyan interfészt, amelyen keresztül azok egyszerűen, futási időben módosíthatóak.

A ’Factories’ alcsomag (2.6.5. ÁBRA) azokat az osztályokat tartalmazza, melyek az XML fájlokból felépítik a fájloknak megfelelő objektumokat, végül a ’Graphics’ csomag (2.6.6. ÁBRA) pár interfészt és absztrakt osztályt foglal egységbe, amik a különböző grafikus funkciókat (pl. komponensek transzformációi) segítik.

2.6.5. ÁBRA: HELPERS/GUI/FACTORIES CSOMAG

2.6.4. ÁBRA: HELPERS/GUI/WRAPPERS CSOMAG


- 18 -

2.6.6. ÁBRA: HELPERS/GUI/GRAPHICS CSOMAG


- 19 -

Végül a ’Utilities’ alcsomag (2.6.7. ÁBRA) tárolja a program egyéb segítő funkcióit végző osztályokat, mint például az időkezelést végző ’DateTimeUtils’ osztályt, a képek betöltését egyszerűen lehetővé tevő ’ImageLoader’ osztályt, vagy az ’ObjectConverter’ osztályt, ami a beállítások XML file-ban való tárolásához szukséges objektumokat alakítja sztringgé, illetve betöltéskor a sztringeket objektumokká.

Az ’OSDetector’ osztály az operációs rendszer detektálásában vállal szerepet, konstansai között vannak generikus és specifikált operációs rendszer típust jelölő konstansok (pl. OS_MAC_OS, OS_MAC_OS_X), amelyek úgy vannak definiálva, hogy a specifikus konstansok a generikus konstansokkal bitszintű “és” művelettel összekapcsolva true értéket adnak.

A ’ResourceLoader’ osztály bármilyen erőforrás betöltésére képes a JAR (Java ARchieve) file-ból. A JAR fájl egy olyan ZIP fájl, amely a java osztályokat és a hozzájuk tartozó metaadatokat tartalmazza.

2.6.6. ÁBRA: HELPERS/UTILITIES CSOMAG


- 20 -

A program nagyobb és fontosabb objektumainak referenciáit a ’Refs’ osztály szolgáltatja, ami segíti ezen objektumok egyszerűbb elérését.

2.7. LOADER CSOMAG

A ’Loader’ csomag (2.7.1. ÁBRA) tartalmazza a program futtatható osztályát, az ’ANA’ osztályt, ami betölti és megjeleníti a grafikus felhasználói interfészt, majd betölti a hálózati elemeket.

2.8. SETTINGS CSOMAG

A ’Settings’ csomag (2.8.1. ÁBRA) a beállítások eltárolásáért és betöltéséért felelős osztályokat tartalmazza, az alapbeállítások a ’Settings’ osztály statikus ’Setting’ típusú ’defaultSettings’ tömbjében tároltak szerint jönnek létre.

A program beállításait az ’ANASettings’ osztály kezeli, amely a ’SetingsManager’ osztály leszármazottja. Az ’ANASettings’ azzal a funkcióval bővíti ki a ’SettingsManager’ osztályt, hogy képes betölteni és elmenteni a beállításokat egy XML fájlba.

Minden megnyitott munkalaphoz külön ’SettingsManager’ példány tartozik, amely a munkalap aktiválásakor szinkronizálja az ’ANASettings’ objektumot. Ha a program egy beállítását megváltoztatjuk, pl. menüből vagy egy eszköztárból, akkor az adott beállítás először az ’ANASettings’ objektumban változik meg, majd a GUI szinkronizálja az aktív munkalap ’SettingsManager’ példányát is.

A Settings osztály tárolja a program alapértelmezett beállításait (’Setting’ objektumait). Minden egyes ’Setting’ objektum tartalmaz egy flaget arra vonatkozóan, hogy őt kell-e szinkronizálni, vagy sem.

2.7.1. ÁBRA: LOADER CSOMAG


- 21 -

2.9. WORKSHEET CSOMAG

A ’Worksheet’ csomag (2.9.1. ÁBRA) a munkalapok összetevőit és felépítését megvalósító osztályokat tartalmazza, továbbá egy munkalap minden elemét összefogó ’Worksheet’ osztályt.

2.8.1. ÁBRA: SETTINGS CSOMAG

2.9.1. ÁBRA: WORKSHEET CSOMAG CSOMAGJAI


- 22 -

Ezen belül a ’Graph’ csomag (2.9.2. ÁBRA) tartalmazza a hálózat gráfjának felépítését reprezentáló ’Graph’ osztályt és tartalmazza a ’Components’ alcsomagot (2.9.2. ÁBRA), amiben a gráf komponenseit reprezentáló osztályok találhatóak.

2.9.2. ÁBRA: WORKSHEET/GRAPH CSOMAG


- 23 -

Az abstract ’GraphComponent’ osztály tárolja a gráfkomponensek alaptípúsait, melyek a következők lehetnek: PIN (a komponensek kivezetései), COMPONENTGRAPHIC (a komponensek grafiuks képei), ANACOMPONENT (komponensek elemeit összefogó osztály), JUNCTION (csomópont), CONNECTION (vezeték) és LABEL (címke). A ’GraphComponent’ osztály leszármazottja a ’InteractiveComponent’ osztály, mely tartalmazza a komponsek egymással szembeni prioritásait egy hálózatban, továbbá az ebből származó objektumok képesek a grafikus felületen interakciókat kiváltani (LÁSD 3.2. FEJEZET). Ebből az osztályból származik le a ’GraphicalComponent’ osztály mely a transzformálhatóságot és a megjeleníthetőséget biztosítja. A csomag tartalmazza továbbá a ’Subscription’ osztályt, melynek segítségével az interaktív komponensek feliratkozhatnak interakciók kiváltására. A ’Subscription’ osztály példányai prioritásokkal rendelkeznek és tárolják a megfelelő komponensek geometriai tulajdonságait, amelyek az interakciók detektálására szolgálnak. A komponens hierarchia felépítése és a ’Subscription’-ök is az újratervezett modulok közé tartoznak, így ezekkel a témákkal is külön fejezetek foglalkoznak.

A ’Graph’ csomagon belül, az ’ANAComponent’ csomagban (2.9.4. ÁBRA) találhatóak meg a program komponenseit reprezentáló osztályok (LÁSD 3.1.1. FEJEZET). A ’Connection’ (2.9.3. ÁBRA) és a ’Node’ (2.9.5. ÁBRA) csomagokban pedig a vezetékeket és a csomópontokat előállító és kezelő osztályok (LÁSD

3.1.2. ÉS 3.1.3. FEJEZET).

2.9.3. ÁBRA: WORKSHEET/GRAPH/COMPONENTS/CONNECTION CSOMAG


- 24 -

2.9.4. ÁBRA: WORKSHEET/GRAPH/COMPONENTS/ANACOMPONENT CSOMAG


- 25 -

A ’Graphics’ csomag (2.9.6. ÁBRA) tárolja a ’DrawArea’ osztályt, ami a rajzfelületet és a rajzfelületre való rajzolást biztosítja, a ’Grid’ osztályt, mely megvalósítja a rácsfelület kirajzolását a szerkesztő felületre, valamint az egérmutató illesztését a rácspontokra, végül a ’Transformer’ osztályt, mely a komponensek transzformációit hajtja végre.

2.9.5. ÁBRA: WORKSHEET/GRAPH/COMPONENTS/NODE CSOMAG


- 26 -

A ’GUI’ csomag (2.9.7. ÁBRA) osztályai megvalósítják a szerkesztő felület egérrel való görgethetőségét, valamint a ’Logger’ ablakot, ami a program számos tevékenységét jeleníti meg.

2.9.6. ÁBRA: WORKSHEET/GRAPHICS CSOMAG

2.9.7. ÁBRA: WORKSHEET/GUI CSOMAG


- 27 -

Az ’Interactions’ csomag (2.9.8. ÁBRA) tartalmazza a szerkesztő felület interakció kezelését segítő osztályokat. Ezek az osztályok is az újratervezett részekhez tartoznak, így a részleteit külön fejezet tárgyalja.

2.9.8. ÁBRA: WORKSHEET/INTERACTIONS CSOMAG


- 28 -

2.10. XMLTOOLS CSOMAG

Az ’XMLTools’ csomag (2.10.1. ÁBRA) az XML file-ok betöltésének feladatát látja el. A Java API (Application Programming Interface) alapértelmezett XML feldolgozóját (’Parser’) használja. Ez a ’Parser’ validáló típusú, azaz csak olyan XML file-ok feldolgozását végzi el, amelyek tökéletesen megfelelnek az XML szabványainak és az opcionálisan jelenlévő doctype deklarációnak.

A használt XML file-okhoz saját készítésű doctype deklarációk tartoznak, melyek a JAR-ban találhatóak. Ezek eléréséhez saját entitás feloldó (entity resolver) osztály létezik (’DTDResolver’).

A ’Parser’ osztály az XML file-okat a ’TreeFactory’ ’DefaultHandler’ osztályt felüldefiniáló osztály segítségével dolgozza fel, és egy ’Tag’ és ’PCData’ objektumokból álló fát készít, amely reprezentálja az XML dokumentumot. Ez a fa később a ’Child’ ősosztály és ennek leszármazottjainak (’Tag’,’PCData’) metódusaival könnyen bejárható.

A ’Tag’ osztály egy XML taget, a ’PCData’ osztály pedig szöveges adatot reprezentál [9].

2.10.1. ÁBRA: XMLTOOLS CSOMAG


- 29 -

3. ÚJRATERVEZÉS (REFACTORING)

Az újratervezés (refactoring) az a folyamat, amelnyek során úgy változtatunk meg egy szoftverrendszert, hogy nem változik meg a kód viselkedése, de javul annak belső szerkezete. Ez a kód kitisztításának olyan fegyelmezett módja, ami minimálisra csökkenti a programhibák bekerülésének esélyét. Lényegében az újratervezés során egy már megírt kód felépítését javítjuk.

Újratervezés nélkül előbb-utóbb elkerülhetetlenül romlik a program szerkezete. Ahogy a programozók megváltoztatják a kódot – rövid távú célok megvalósítása érdekében, vagy a kód szerkezetének teljes átalakítása nélkül -, a kód elveszíti eredeti szerkezetét, és nehezebb lesz felismerni azt a kódot olvasva. Az újratervezés a kód rendbetétele: azért végezzük, hogy eltávolítsunk olyan darabokat, amelyek nem megfelelő helyen vannak. A kód szerkezetének összekuszálódása halmozott károkkal jár: minél nehezebb átlátni a kód szerkezetét, annál nehezebb módosítani a programot, és annál gyorsabban romlik. A rendszeres újratervezés segít formában tartani a kódot.

Az újratervezésnél megváltozik a munkafolyamatok egyensúlya: tervezést nem kizárólag a munka elején végzünk, hanem a fejlesztés során folyamatosan. A rendszer építése során jövünk rá, hogyan javítható a szerkezet, és ez olyan felépítéshez vezet, ami a további fejlesztés során is megfelelő marad [18 (3.1. ábra)].

Az alábbi fejezet tárgyalja az újratervezett csomagokat.

3.1. KOMPONENS - HIERARCHIA

A komponens - hierarchia újratervezését azért kellett véghez vinni, mert a program korábbi verziója kezdetleges megoldásokat használt, melyek sok később felmerülő igényt technikailag nem tudtak kielégíteni.

Az új komponens – hierarchia egy konzisztensen felépített jól struktúrált model (3.1.1. ÁBRA).

3.1. ÁBRA: MARTIN FOWLER: REFACTORING


- 30 -

A ’GraphComponent’ osztály minden hálózatban szereplő komponens vagy egyéb objektum ősosztálya. Egyedi azonosítókért felelős, valamint különböző objektumokat megkülönböztető típus konstansokat tartalmazza. Ebből az osztályból közvetlenül származik az ’ANAComponent’ osztály.

Az ’InteractiveComponent’ osztály a ’GraphComponent’ osztály leszármazottja. Deklarálja a különböző objektumokinterakciós prioritását és lehetővé teszi ennek lekérdezését, valamint tárol egy ’Subscription’ osztály referenciát (lásd később). Összefoglalva tehát a leszármazottjai számára lehetővé teszi interakciók kiváltását.

3.1.1. ÁBRA: A KOMPONENSEK HIERARCHIÁJA


- 31 -

A ’GraphicalComponent’ osztály az ’InteractiveComponent’ osztályból származik és egyetlen absztrakt metódust vezet be, amely egy ’Transformable’ interfészt (LÁSD 3.3. FEJEZET) megvalósító osztály elérését teszi lehetővé. Az ebből az osztályból származó osztályok megjelennek a rajzfelületen.

3.1.1. ANACOMPONENT

A ’Graph’ csomagon belüli ’ANAComponent’ csomag (3.1.1.1. ÁBRA) fűzi össze azokat a logikailag szorosan összetartozó osztályokat, amelyekből a hálózatokban felhasználható komponensek állnak.

3.1.1.1. ÁBRA: AZ ‘ANACOMPONENT’ CSOMAG ÉS OSZTÁLYAI


- 32 -

Az ’ANAComponent’ osztály az alapvető adatokat és refernciákat tartalmazza egy adott komponensről. A teljesség igénye nélkül, az attribútumokat, a prototípus referenciáját, a cimke tartalmát és a komponens grafikáit (’ANAComponentGraphic’).

Az ’ANAComponentGraphic’ osztály megvalósítja a ’Transformable’ interface-t, amely olyan metódusokat deklarál, amely a célobjektum geometriai transzformációit teszi lehetővé. Mivel egy komponens több grafikát is tartalmazhat (pl. vezérelt források primer és szekunder kapuja) és minden grafikához egyedi alkatrészlábak (’Pin’ objektumok, LÁSD 3.1.2. FEJEZET) tartoznak, ezért az alkatrészlábak nyilvántartását is ez az osztály végzi.

A komponens grafikák alakzatokból (’ANAComponentShape’) épülnek fel, amelyek szintén megvalósítják a ’Transformable’ interface-t. Az ’ANAComponentGraphic’ osztály ezeket az alakzatokat együttesen transzformálja.

Az ’ANAComponentShape’ a ’TransformableShape’ osztályból származik, ami lehetővé teszi a JAVA alap alakzatainak egyszerű saját középponthoz és egy tetszőleges ponthoz viszonyított transzformációját (LÁSD 3.3 FEJEZET). Minden ’ANAComponentShape’ rendelkezik egyéni kitöltőszínnel, vonalszínnel, vonalvastagsággal, stb.

A komponensek attribútumait az ’ANAComponentAttribute’ osztály kezeli. Az attribútumok beállítása és lekérdezése ezen az osztályon keresztül történik. Minden attribútum rendelkezik típussal, azonosítóval, névvel és értékkel.

3.1.2. NODE

A ’Node’ csomagban (2.9.5. ÁBRA) azok az osztályok találhatóak amelyek logikialag és/vagy grafikailag csomópontokat reprezentálnak a gráfban vagy a rajzfelületen. Minden ilyen osztály őse a ’Node’ osztály, amely egy logikai csomópontot reprezentál, nyilvántartja a hozzá kapcsolódó vezetékeket, valamint definiál három absztrakt metódust, amelyek lehetővé teszik a csomópont rajzfelületen lévő pozíciójának lekérdezését, valamint lekérdezését is, hogy a csomópont megfelelően van-e csatlakoztatva a hálózathoz. A ’Node’ osztály a ’GraphicalComponent’ leszármazottja, tehát képes interakciókat kiváltani és elkérhető tőle egy transzformálható komponens.

A ’Junction’ osztály a ’Node’ osztály leszármazottja és a vezetékek közti töréspontokat reprezentálja.

A ’Pin’ absztrakt osztály szintén a ’Node’ osztály leszármazottja és a komponensek lábait reprezentálja. Azért absztrakt, mert ez az osztály még nem definiálja a pin alakját, ami lehet pontszerű, vagy egyéb alakzat (’NodePoint’ és ’NodeShape’). A ’Pin’ osztály polaritással és egyéni címkével rendelkezik, valamint két belső, belőle származó osztályt definiál (3.1.2.1. ÁBRA).


- 33 -

A ’Pin.Point’ belső osztály egy pontszerű alkatrészlábat ír le, amelynek a ’Transformable’ adattagja egy ’NodePoint’ objektum. A ’NodePoint’ objektum egy olyan ’TransformablePoint’ (LÁSD 3.3. FEJEZET) leszármazott, amelyen ha transzformációkat hajtunk végre, invalidálja a csomóponthoz kapcsolódó vezetékek grafikus leírását. Erre azért van szükség, mert a programban a rajzolás gyorsításának érdekében gyorsítótárazza a vezetékek alakzatát, amelyet érvényteleníti kell, ha a vezeték valamely végpontját például eltoljuk a rajzfelületen.

A ’Pin.Circle’ belső osztály egy kör alakú alkatrészlábat reprezentál, amire a jelfolyam hálózatok bizonyos komponenseinél van szükség (pl. összegző -, és szorzócsomópont) amelyekhez előre nem meghatározott számú vezeték kapcsolódhat (3.1.2.2. ÁBRA). Ennek a ’Transformable’ adattagja a ’NodeShape’, amely az előbb leírt okok miatt szükséges.

3.1.2.1. ÁBRA: A ‘PIN’ OSZTÁLY ÉS BELSŐ OSZTÁLYAI

3.1.2.2. ÁBRA: PÉLDA AZ ÖSSZEGZŐCSOMÓPONTOKRA


- 34 -

3.1.3. CONNECTION

A ’Connection’ osztály (3.1.3.1. ÁBRA) egy vezetéket reprezentál amely két ’Node’ objektum között teremt logikai kapcsolatot. Ez az osztály felelős a vezeték grafikájának legenerálásáért is, továbbá tárolja a végpontjainak referenciáját és egyéb metódusokat is biztosít, mint például a ’getSnappingPoint()’ metódus, amelyet egy koordináta paraméter megadásával meghívva, visszakapjuk azt a pontot, amely eleme a vezeték egyenesének és legközelebb esik az argumentum koordinátájához. Ez a metódus például a vezetékezéshez szükséges, amikor egy vezetéket szeretnénk bekötni egy másik vezetékbe.

3.1.3.1. ÁBRA: A ‘PIN’ OSZTÁLY ÉS BELSŐ OSZTÁLYAI


- 35 -

3.2. INTERACTION MANAGMENT

A második programrész amit teljesen újra kellett tervezni, az a szerkesztőfelület interakcióinak kezelése. Erre azért volt szükség, mert rengeteg komplex interakciót kell kezelni (mint például komponensek kijelölése, draggelése, törlése, összekötése) és a korábbi megközelítés ezt nem tette lehetővé. Moduláris, könnyen bővíthető interakciók kezelésére volt szükség.

E gondolkodásmd eredménye lett az ’Interaction’ (3.2.1. ÁBRA), az ’InteractionManager’ (3.2.2. ÁBRA), az ’InteractionMode’ (3.2.4. ÁBRA), az ’InteractionConstants’ (3.2.5. ÁBRA), az ’InteractionTrigger’ és a ’Subscription’ osztály, valamint az ’Implementations’ csomag (3.2.6. ÁBRA) és osztályai, melyek az ’Interaction’ osztályt kiterjesztve, interakciókat implementálnak.

Az ’InteractionManager’ osztály (3.2.2. ÁBRA) kezeli a ’Swing’ (a JAVA egy alapértelmezett osztálykönyvtára, amely tartalmazza a grafikus felhasználói felület előállítására alkalmas osztályokat, melyekkel gazdag grafikai megoldások és interaktivitások veihetők a fejlesztendő alkalmazásokba) nyers eseményeit, valamint a komponensek által beregisztrált ’Subscription’ osztályt. Egy-egy nyers esemény érkezésekor végigiterál a beregisztrált ’Subscription’ osztályokon, és megállapítja, hogy az adott eseményre bekövetkező interakciót melyik ’Subscription’ által képviselt objektumon kell végrehajtani. Minden ’Subscription’ biztosít az ’InteractionManager’ számára egy geometriai alakzatot. Egérkattintás esetén például, az ’InteractionManager’ megvizsgálja, hogy a kattintás koordinátája mely ’Subscription’-ök geometriai formájába esik bele. Ha több ilyen is van, akkor a ’Subscription’-ök prioritása (LÁSD ’INTERACTIVECOMPONENT’, 3.1. FEJEZET) dönti el, hogy melyik ’Subscription’ továbbítódik az ’Interaction’ felé.

3.2.1. ÁBRA: AZ ‘INTERACTION’ OSZTÁLY


- 36 -

A cél ’Subscripton’ megahatározása után a nyers esemény és egyéb aktuális változók értéke (például interakciós mód (3.2.4. ÁBRA), vagy triggerek) alapján az ’InteractionManager’ összeállít egy bitvektort, ami a végrehajtandó interakciók kiválasztásához szükséges.

Ezután az ’InteractionManager’ végigiterál a berigisztrált ’Interaction’ objektumokon, és megnézi (’matches()’ metódus segítségével), hogy azok előredefiniált szignatúrája illik-e az előbb felépített bitvektorra. Amennyiben igen, akkor az aktuális szignatúrát, a nyers eseményt, valamint a cél ’Subscription’-t átadva meghívja az ’Interaction’ osztály ’excecute()’ metódusát.

Egy konkrét interakció implementációja a következő módon történik. Egy új osztályt létrehozva az ’Interaction’ osztályt kell leszármaztatni és a konstruktorban az ’Interaction’ osztály metódusainak segítségével meg kell határozni az interakciók futtatásához szükséges feltételeket.

3.2.1. ÁBRA: AZ ‘INTERACTIONMANAGER’ OSZTÁLY


- 37 -

Egy interakció akkor futhat le, ha minden szükséges feltétel teljesül (’addNecessaryConditions()’ metódus) és legalább egy elégséges feltétel is teljesül (’addSufficientConditions()’ metódus) valamint a szükséges kizáró feltételek (’addNecessaryExclusiveConditions()’ metódus) közül legalább egy nem teljesül és végül az elégséges kizáró feltételek (’addSufficientExclusiveConditions()’ metódus) közül egyik sem teljesül (3.2.1. ÁBRA).

Az interakció által végrehajtandó feladatokat az ’excecute()’ metódus felüldefiniálásával deklarálhatjuk.

Egy konkrét példa a programból:

public ClickSelect() { addNecessaryCondition(EVENT_MOUSE_CLICK); addNecessaryCondition(MOUSE_BUTTON_LEFT); addNecessaryCondition(MODE_CLICK_SELECTION); addSufficientExclusiveCondition(DESTINATION_EMPTY); }

A fenti példa (3.2.3. ÁBRA ) a komponensek kijelölésére szolgáló interakció feltételeit állítja be, melyek a következők:

− szükséges feltétel: egér kattintás esemény − szükséges feltétel: az esemény a bal gombbal történjen − szükséges feltétel: az aktuális interakciós mód legyen

‘CLICK_SELECTION’ − kizáró elégséges feltétel: a kattintás üres terülteten történik

A fenti példa alapján jól látható, hogy a különböző feltételek azonsításához konstansokat definiál a program, ezek tárolására szolgál az ’InteractionConstants’ (3.2.5. ÁBRA) osztály. Bizonyos interakciók csak akkor hajtódhatnak végre, ha az ’InteractionManager’ a megfelelő interakciós módban van. Ezek reprezentálására szolgál az ’InteractionMode’ enum osztály (3.2.4. ÁBRA). Ez a megoldás lehetővé teszi az interakciók kategorizálását (pl. kijelölés, vezetékezés, analízis).

3.2.3. ÁBRA: EGY INTERAKCIÓ PÉLDÁJA

3.2.4. ÁBRA: ‘INTERACTIONMODE’ ENUM OSZTÁLY


- 38 -

Léteznek olyan interakciók is, amelyek kiváltásához összetett eseménysorozat bekövetkezése szükséges (3.2.6. ÁBRA). Ennek lehetővé tételére szükséges az ’InteractionTriggers’ enum osztály. Az előkészítő esemény beállítja az adott triggert, majd a kiváltó esemény a trigger jelenléte esetén kiváltja az interakciót magát.

3.2.4. ÁBRA: ‘INTERACTIONCONSTANTS’ KONSTANSAI

3.2.6. ÁBRA: ‘IMPLEMENTATIONS’ CSOMAG ÉS OSZTÁLYAI


- 39 -

3.3. TRANSZFORMÁCIÓK

Az előző implementáció során kiderült, hogy a JAVA alaposztályai (’AffineTransform’) nem tesznek lehetővé közvetlen módon tetszőleges pont körül végzett transzformációkat és az egymás után lévő transzformációk sorrendje nem konzisztens. Azaz, ha például forgatás után végzünk eltolást, akkor az eltolás az eredeti koordináta-rendszer szerint történik. Ez a működés természetesen nem hibás, csak a program elképzelt struktrújába nem illett bele.

Ezért történt az alábbi osztályok létrehozása, melyek a ’Transformable’ interface (3.3.1. ÁBRA) és azt ezt implementáló ’TransformablePoint’ és ’TransformableShape’ osztályok.

Az interface rögzíti a transzformációs metódust, például forgatás (’rotate()’), tükrözés (’flip()’), valamint tartalmaz pár ezekhez kapcsolódó konstanst is.

3.3.1. ÁBRA: TRANSFORMABLE INTERFACE


- 40 -

A ’TransformablePoint’ osztály (3.3.2. ÁBRA) egy szabadon transzformálható pontot reprezentál, mely a JAVA beépített ’Point2D.Double’ osztályából származik és természetesen megvalósítja a ’Transformable’ interface-t. Működése a következő. Egy ’TransformablePoint’ objektum öt fontos adatot tárol egyszerre, az eredeti pont és eltolás koordinátáját, a valaha végzett összes transzformáció összesített mátrixát, valamint az ennek megfelelő gyorsítótárazott aktuális pozíciót és eltolást.

3.3.2. ÁBRA: TRANSFORMABLEPOINT OSZTÁLY


- 41 -

A ’TransformablePoint’ osztályból származik a ’TransformableShape’ osztály (3.3.3. ÁBRA), ami ennél fogva szintén megvalósítja a ’Transformable’ interface-t. Működése annyiban egészíti ki a ’TransformablePoint’ osztályt, hogy eltárol egy eredeti és egy aktuális alakzatot is.

3.3.3. ÁBRA: TRANSFORMABLESHAPE OSZTÁLY


- 42 -

4. TERVEZÉSI MINTÁK (DESIGN PATTERNS)

Az optimális fejlesztés érdekében a program felhasznál számos tervezési mintát (design pattern), melyek gyakran felmerülő problémák megoldására szolgáltatnak jól bevált, széles körben alkalmazott megoldásokat [17].

4.1. SINGLETON TERVEZÉSI MINTA

A ’Singleton’ tervezési minta olyan objektumok létrehozását teszik lehetővé, melyek az egész programon belül egyetlen-egy példányban léteznek. A programon belül ilyen például a ’MainWindow’, az ’ANASettings’ (4.1.1. ÁBRA) és az ’ANAComponentPrototypeStore’ osztályok.

Ennek a mintának többféle megoldása létezik. A program az ún. privátkonstruktoros implementációt használja (4.1.2. ÁBRA), melynek lényege, hogy az egyetlen objektumot az osztályban lévő statikus metóduson keresztül érhetjük el, melyet egy statikus adattag tárol. Az egyetlen objektum létrehozása, a statikus metódus első hívásakor történik a privát konstruktoron keresztül, mely által így az osztály kívűlről nem példányosítható.

// SINGLETON DESIGN PATTERN STUFF private static class SingletonHolder { private final static ANASettings instance = new ANASettings(); } public static ANASettings getInstance() { return SingletonHolder.instance; }

4.1.1. ÁBRA: ‘ANASETTINGS’ OSZTÁLY

4.1.2. ÁBRA: ‘ANASETTINGS’ SINGLETON DESIGN PATERN


- 43 -

4.2. REGISTRY PATTERN

Ez a tervezési minta részben magába foglalhatja a ’Singleton’ tervezési mintát is, hiszen bizonyos esetekben a ’Registry’ tervezési mintának pont az a szerepe, hogy egy az egész programon belül elérhető beállítás jegyzéket biztosítson. A beállítás jegyzékben írhatóak és lekérdezhetőek az adatok.

A programban példa erre a pattern-re az ’ANASettings’ osztály, mely biztosítja a beállítás jegyzéket és megvalósítja a ’Singleton’ tervezési mintát. További ’Registry’ objektumokat használ a program a munkalapok lokális tulajdonságainak tárolására. Ezek nyilvánvalóan nem ’Singleton’ osztályok.

4.3. MVC (MODEL VIEW CONTROLLER) PATTERN

Az MVC minta az adatmodel, a felhasználói interface, illetve a program logika elszeparálásában nyújt segítséget.

Ennek megvalósítása a programon belül a ’Swing’ használatával teljesül, illetve egy magasabb absztrakciós szintet képvisel a felhasználói interface elemeinek betöltése XML file-okból.


- 44 -

5. HÁLÓZATOK SZERKESZTÉSE

A következő fejezet a hálózatok szerkesztését mutatja be a program segítségével. A programban szerkeszthetők jelfolyam-, és Kirchhoff - típusú hálózatok egyaránt. A program indítása után választható ki egy dialógus ablakban, hogy milyen típusú munkalapot szeretnénk létrehozni.

5.1. KOMPONENSEK BESZÚRÁSA, SZELEKCIÓK

A munkalap megnyitása után a komponenseket beszúrhatjuk menüből és eszköztárból is. Mindkét munkalapon a komponensek típusai a munkalap típusától függően dinamikusan változnak a menüben és az eszköztárban is (5.1.1. ÁBRA, 5.1.2. ÁBRA).

Az eszköztárból való beszúrás draggeléssel (egérrel való vonszolás) történik. Egér kattintás után a beszúrandó komponens képén az eszköztáron, a komponens képe megjelenik az eszköztár felett és az egér segítségével húzható le a szerkesztő felületre (5.1.3. ÁBRA).

Ha az ’alt’ billentyűt nyomva tartjuk a komponens draggelése alatt, akkor a komponens nem fog illeszkedni a grid rácspontokhoz, ha nem, akkor automatikusan illeszkedik a komponens kivezetése az elengedéshez számított legközelebbi grid rácsponthoz.

5.1.1. ÁBRA: KIRCHHOFF - TÍPUSÚ HÁLÓZAT KOMPONENSEK BESZÚRÁSA MENÜBŐL

5.1.2. ÁBRA: JELFOLYAM - HÁLÓZAT KOMPONENSEK BESZÚRÁSA MENÜBŐL


- 45 -

A program alapvetően három logikai módot tartalmaz, a kijelölés (’SELECTING’), a vezetékezés (’WIRING’) és az analízis (’ANALYZING’) módokat.

Az alapértelmezett mód a kijelölés mód. Egy komponens kijelölhető egy szimpla bal egér klikkeléssel. Több komponenst lépésről - lépésre a ’ctrl’ billentyű nyomvatartása közben jelölhetünk ki, továbbá az összes komponenst az egér bal gombjának nyomvatartása és húzása közben keletkező téglalap segítségével jelölhetünk ki (5.1.4. ÁBRA).

Továbbá ha egy komponens, egy vezeték, egy csomópont, vagy egy pin fölé visszük az egér kurzort, akkor a megfelelő komponens körül megjelenik egy vörös, szagatott vonalú kijelölés, amíg az egér fölötte tartózkodik (5.1.5. ÁBRA).

5.1.3. ÁBRA: KOMPONENS DRAGGELÉSE MENÜBŐL

5.1.4. ÁBRA: AZ EGÉSZ HÁLÓZAT KIJELÖLÉSE

5.1.5. ÁBRA: PILLANATNYI KIJELÖLÉS AZ EGÉRREL


- 46 -

5.2. VEZETÉKEZÉS, KOMPONENSEK ÖSSZEKÖTÉSE

Ha befejeztük a komponensek elhelyezését a szerkesztő felületen, akkor a komponensek vezetékkel való összekötése következik. Ezt két helyről tehetjük meg, vagy bekapcsoljuk az eszköztáron szereplő vezetékezés gombot, így ’wiring’ módba jutunk a programon belül, vagy a hálózaton belül egy komponens lábára kattintva ’instant wiring’ módba kerülünk.

A két opció között az alapvető különbség, hogy míg ’wiring’ módban bárhonnan indíthatunk vezetékezést, addig ’instant wiring’ módban csak a komponensek pinjeiből, továbbá csomópontokból indíthatunk. Továbbá míg a ’wiring’ mód kikapcsolása az eszköztáron ismételt kattintással történik és futása alatt az összes többi szerkesztő opció tiltott, addig az ’instant wiring’ mód a vezetékezés befejeztével, vagy a rajzfelületen való kattintással automatikusan kikapcsol.

Az egérmutató alatt vörös, szaggatott vonallal kiemelődnek azok a területek, amelyekből vezeték indítható (5.2.1. ÁBRA). Ha először kattintunk a kiindulásként szánt pontra, szaggatott vonalként megjelenik a vezeték a kurzor és a kezdőpont között. Második kattintással tehetjük le a vezetéket a kívánt helyre (szintén vörös, szaggatott), vagy létrehozhatunk egy töréspontot a kattintás helyén, amely új kiindulópontként is funkcinálhat a továbbiakban.

A vezetékezés más programokkal ellentétben nem csak függőleges és vízszintes irányban történhet, hanem bármelyik irányba rajzolható vezeték.

5.2.1. ÁBRA: VEZETÉKEZÉS


- 47 -

A szerkesztő felületen opcionálisan bekapcsolható az egér kurzor pozícióját követő két nagy egymást keresztező szaggatott vonal, melyek keresztmetszete, az egér aktuális pozíciója (5.2.1. ÁBRA).

5.3. KOMPONENSEK ÉRTÉKEINEK BEÁLLÍTÁSA

A vezetékezés befejezése után következik a komponensek értékeinek beállítása. Ezt egy pop-up ablakban tehetjük meg, amely a megfelelő komponens képén való dupla bal kattintás után jelenik meg a szerkesztő felület felett (5.3.1. ÁBRA).

Minden komponens rendelkezik alapértelmezett értékkel, amit az ’ANAComponentAttribute’ osztály tárol. Az alapértelmezett érték megváltoztatása után az új értéket eltárolja az ’ANAComponentAttribute’ és ezután már a megváltoztatott értéket láthatjuk a dialógusablakban.

Az értékek beállítása után a kiválasztott analízis pontra kattintva az analízis mód automatikusan elindul.

5.3.1. ÁBRA: EGY KOMPONENS ÉRTÉKÉNEK BEÁLLÍTÁSA


- 48 -

6. ANALÍZIS

A következő fejezet bemutatja a hálózatokba integrálható komponenseket, továbbá az első implementált analízis csomagot, és ennek alapjait, melynek segítségével Kirchhoff – típusú hálózatokban kiszámolhatók a csomóponti potenciálok, a komponenseken folyó áramok és a rajtuk eső feszültségek, továbbá az egyes komponensek teljesítményei is.

6.1. BESZÚRHATÓ KOMPONENSEK, KARAKTERISZTIKÁK

6.1.1. KIRCHHOFF – TÍPUSÚ HÁLÓZATOK KOMPONENSEI

A koncentrált paraméterű hálózatok generátort, ellenállást, induktivitást, kapacitást és ágak közötti csatolást tartalmaznak. Ahhoz, hogy a hálózatban áramok folyjanak, feszültségek lépjenek fel az szükséges, hogy a hálózatban egy, vagy több energiaforrás legyen [2].

A FESZÜLTSÉGFORRÁS olyan kétpólus (6.1.1.1. ÁBRA), amelynek feszültsége az ismert

us = us(t) (6.1.1-1)

forrásfeszültség, az ÁRAMFORRÁS pedig olyan kétpólus (6.1.1.1. ÁBRA), amelynek árama az ismert

is = is (t) (6.1.1-2)

forrásáram, tehát karakterisztikájuk:

u = us (6.1.1-3)

és

i = is . (6.1.1-4)

A források által (a hálózat többi részéből) felvett teljesítmény (itt u és ireferenciairánya azonos)

p = usi (6.1.1-5)

ill.

p = isu (6.1.1-6)

lehet pozitív is és negatív is, a források vagy fogyasztanak vagy termelnek, ezek aktív komponensek [4].


- 49 -

A RÖVIDZÁR olyan kétpólus, amelynek feszültsége nulla, a SZAKADÁS pedig olyan kétpólus, amelynek árama nulla, karakterisztikájuk:

rövidzár:

u = 0 , (6.1.1-7)

szakadás:

i = 0 . (6.1.1-8)

A rövidzár és a szakadás a feszültség-, és áramforrások elfajuló esetei. A rövidzár tekinthető speciális feszültségforrásnak (us = 0) , vagy spaciális

ellenállásnak (R = 0) . A szakadás tekinthető spaeciális áramforrásnak(is = 0) vagy speciális ellenállásnak (G = 0) . Így a programban, ha rövidzárat vagy

szakadást szeretnénk a hálózatba integrálni, akkor ezt egy us = 0 V értékű feszültségforrásal vagy egy is = 0 A értékű áramforrással tehetjük meg.

A rövidzár és a szakadás által felvett teljesítmény

p = 0 , (6.1.1-9)

ezek passzív és ezen belül nonenergikus kétpólusok.

A lineáris ELLENÁLLÁS olyan kétpólus (6.1.1.2. ÁBRA), amelynek feszültsége és árama arányos (Ohm törvénye):

u = Ri , (6.1.1-10)

vagy

i = Gu , (6.10.1-11)

ahol R az ellenállás rezisztanciája, G pedig a konduktanciája, és

G =

1R

. (6.10.1-12)

6.1.1.1. ÁBRA: FESZÜLTSÉG-, ÉS ÁRAMFORRÁS KÉPE A PROGRAMBAN


- 50 -

A lineáris ellenállás által felvett teljesítmény

p = Ri2 (6.1.1-13)

vagy

p = Gu2 , (6.1.1-14)

a felvett teljesítmény pozitív, ha R > 0 , vagyis a (pozitív) ellenállás mindig fogyasztó, tehát passzív kétpólus [4].

Elemi komponensek összekapcsolásával egyszerű kétpólusokhoz juthatunk. A két legfontosabb a FESZÜLTSÉGGENERÁTOR vagy THÉVENIN - GENERÁTOR (6.1.1.3. ÁBRA), amelynek karakterisztikája

u = Ri + us (6.1.1-15)

és az ÁRAMGENERÁTOR vagy NORTON – GENERÁTOR (6.1.1.4. ÁBRA), amelynek karakterisztikája

i = Gu + is . (6.1.1-16)

6.1.1.2. ÁBRA: ELLENÁLLÁS KÉPE A PROGRAMBAN

6.1.1.3. ÁBRA: THÉVENIN - GENERÁTOR KÉPE A PROGRAMBAN

6.1.1.4. ÁBRA: NORTON - GENERÁTOR KÉPE A PROGRAMBAN


- 51 -

Az 1 :n áttételű IDEÁLIS TRANSZFORMÁTOR (IT) két csatolt lineáris rezisztív kétpólus, amelynek egyik karakterisztikája

u1 = nu2 , (6.1.1-17)

i2 = −ni1 . (6.1.1-18)

Az n áttétel lehet pozitív vagy negatív. Az IT (6.1.1.5. ÁBRA) passzív, sőt nonenergikus komponens, ugyanis az IT által a hálózatból felvett teljesítény

p = u1i1 + u2i2 = (nu2 )i1 + u2 (−ni1 ) = 0 . (6.1.1-19)

A VEZÉRELT FORRÁSOK olyan csatolt kétpólusok, amelyek egyik kapujának (primer vagy szekunder) feszültsége vagy árama meghatározza a másik kapu (primer vagy szekunder) feszültségét vagy áramát.

A FESZÜLTSÉGVEZÉRELT FESZÜLTSÉGFORRÁS (6.1.1.6. ÁBRA) jellemzője a µfeszültségforrási tényező. Ennek karakterisztikája

i1 = 0 , (6.1.1-20)

u2 = µu1 . (6.1.1-21)

6.1.1.5. ÁBRA: IDEÁLIS TRANSZFORMÁTOR KÉPE A PROGRAMBAN

6.1.1.6. ÁBRA: FESZÜLTSÉGVEZÉRELT FESZÜLTSÉGFORRÁS KÉPE A PROGRAMBAN


- 52 -

A FESZÜLTSÉGVEZÉRELT ÁRAMFORRÁS (6.1.1.7. ÁBRA) jellemzője a g átviteli konduktancia. Ennek karakterisztikája

i1 = 0 , (6.1.1-22)

i2 = gu1 . (6.1.1-23)

Az ÁRAMVEZÉRELT FESZÜLTSÉGFORRÁS (6.1.1.8. ÁBRA) jellemzője az r átviteli rezisztancia. Ennek karakterisztikája

u1 = 0 , (6.1.1-24)

u2 = ri1 . (6.1.1-25)

Az ÁRAMVEZÉRELT ÁRAMFORRÁS (6.1.1.9. ÁBRA) jellemzője az αáramerősítési tényező. Ennek karakterisztikája

u1 = 0 , (6.1.1-26)

i2 = αi1 . (6.1.1-27)

6.1.1.7. ÁBRA: FESZÜLTSÉGVEZÉRELT ÁRAMFORRÁS KÉPE A PROGRAMBAN

6.1.1.8. ÁBRA: ÁRAMVEZÉRELT FESZÜLTSÉGFORRÁS KÉPE A PROGRAMBAN

6.1.1.9. ÁBRA: ÁRAMVEZÉRELT ÁRAMFORRÁS KÉPE A PROGRAMBAN


- 53 -

A vezérelt források aktív komponensek. A µ , g , r és α vezérlési paraméterek pozitív vagy negatív állandók, invariáns esetben az idő függvényei [3].

A vezérelt forrás (FF, FÁ, ÁF, ÁÁ) által felvett teljesítmény

p = u1i1 + u2i2 = µu1i2 , gu1u2 , ri1i2 , α i1u2 . (6.1.1-28)

Az IDEÁLIS (MŰVELETI) ERŐSÍTŐ (6.1.1.10. ÁBRA) a feszültségvezérelt feszültségforrás határesete végtelen feszültségerősítés esetén. Az ideális erősítő egyetlen karakterisztikája

u1 = 0 , (6.1.1-29)

i1 = 0 . (6.1.1-30)

Az ideális erősítő aktív komponens.

A GIRÁTOR (6.1.1.11. ÁBRA) két karakterisztikája

u1 = −ri2 , u2 = ri1 ; (6.1.1-31)

vagy

i1 = gu2 , i2 = −gu1 ; (6.1.1-32)

ahol r a girációs rezisztancia, g a girációs konduktancia és

g = 1

r. (6.1.1-33)

A girátor nonenergikus, tehát a hálózatból felvett teljesítménye azonosan nulla.

6.1.1.10. ÁBRA: AZ IDEÁLIS ERŐSÍTŐ KÉPE A PROGRAMBAN

6.1.1.11. ÁBRA: AZ IDEÁLIS ERŐSÍTŐ KÉPE A PROGRAMBAN

A lineáris invariáns KONDENZÁTOR egy olyan kétpólus (6.1.1.12. ÁBRA), amelynek karakterisztikája

iC = C uC , (6.1.1-34)

azaz

iC (t) = C

duC (t)dt

, (6.1.1-35)

ahol C a kondenzátor időben állandó kapacitása.

A lineáris invariáns TEKERCS egy olyan kétpólus (6.1.1.13. ÁBRA), amelynek karakterisztikája

uL = LiL , (6.1.1-36)

azaz

uL (t) = L

diL (t)dt

, (6.1.1-37)

ahol L a tekercs időben állandó induktivitása.

A lineáris invariáns kondenzátor, ill. tekercs által felvett teljesítmény

pC = uCiC = CuC uC =ddt

12CuC

2⎛⎝⎜

⎞⎠⎟

, (6.1.1-38)

pL = uLiL = LiLiL =ddt

12LiL

2⎛⎝⎜

⎞⎠⎟

. (6.1.1-39)

6.1.1.12. ÁBRA: A KONDENZÁTOR KÉPE A PROGRAMBAN

6.1.1.13. ÁBRA: A TEKERCS KÉPE A PROGRAMBAN


- 55 -

6.1.2. JELFOLYAM – HÁLÓZATOK KOMPONENSEI

Egy hálózat komponensek összekapcsolásából áll. Minden kompoenensnek (hálózati elemnek) egy vagy több bemenete és egy vagy több kimenete lehet. A bemenet(ek) és a kimenet(ek) közti kapcsolatot a komponens karakterisztikája adja meg, ami egy függvénykapcsolat a komponens bemeneti változója (változói) és kimeneti változója (változói) között, pl. megadja a kimeneti változót a bemeneti változó függvényében. A hálózat bemenetére a gerjesztést kapcsoljuk, kimenetén pedig a választ várjuk [1].

A programban a jelfolyam – hálózatokba a következő jellegzetetes komponensek integrálhatók.

A FORRÁS (6.1.2.1. ÁBRA) a hálózat bemenetét, gerjesztését reprezentálja, egyetlen változója az

s = s(t) (6.1.2-1)

folytonos idejű jel, illetve

s = s[k] (6.1.2-2)

diszkrét idejű jel, bemenete nincs.

A NYELŐ (6.1.2.2. ÁBRA) a hálózat kimenetét, válaszát reprezentálja, bemeneti változója a keresett

y = y(t) (6.1.2-3)

folytonos idejű jel, illetve

y = y[k] (6.1.2-4)

diszkrét idejű jel, kimenete nincs.

6.1.2.1. ÁBRA: A FORRÁS KÉPE A PROGRAMBAN

6.1.2.2. ÁBRA: A NYELŐ KÉPE A PROGRAMBAN


- 56 -

Az ÖSSZEGZŐCSOMÓPONT (6.1.2.3. ÁBRA) kimenetén a bemenetére érkező jelek összessége jelenik meg, azaz

y(t) = si (t)

i∑ , (6.1.2-5)

vagy

y[k] = si[k]

i∑ . (6.1.2-6)

Tetszőleges számú bemenete lehet és egyetlen kimenete van. Az összegzőcsomópontoknál tehát összekapcsolási kényszer áll fenn, melynek teljesülni kell.

A LINEÁRIS ERŐSÍTŐ (6.1.2.4. ÁBRA) olyan lineáris komponens, amelynek karakterisztikája

y(t) = Ks(t) , (6.1.2-7)

vagy

y[k] = Ks[k] , (6.1.2-8)

ahol K egy időtől független konstans (erősítés), tehát az erősítő invariáns elem. Ha K <1, akkor csillapításról beszélünk. Ha K az idő ismert függvénye

(K(t) vagy K[k]) , akkor variáns erősítőről van szó.

A KÉSLELTETŐ (6.1.2.5. ÁBRA) olyan diszkrét idejű hálózati elem, amely a bemenetére érkező diszkrét idejű jelet egy ütemmel késlelteti, de a kieneti jel és a bementi jel értéke megyegyezik. Ez memóriával bíró, ún. dinamikus elem.

6.1.2.3. ÁBRA: AZ ÖSSZEGZŐCSOMÓPONT KÉPE A PROGRAMBAN

6.1.2.4. ÁBRA: AZ ERŐSÍTŐ KÉPE A PROGRAMBAN


- 57 -

Az INTEGRÁTOR (6.1.2.6. ÁBRA) olyan folytonos idejű hálózati elem, amelynek kimenetén a bemenetén érkező folytonos idejű jel integrálja jelenik meg. Az integrátor a folytonos idejű hálózatok dinamikus eleme.

Az NEMLINEÁRIS ERŐSÍTŐ (6.1.2.7. ÁBRA) olyan komponens, melynek karakterisztikája nemlineáris, bemenete és kimenete között az

η = φ{ξ} (6.1.2-9)

kapcsolat áll fenn, ahol ξ a nemlineáris erősítő bemeneti jele, η pedig a

kimeneti jele, φ{⋅}pedig egy nemlineáris függvénykapcsolat.

A SZORZÓCSOMÓPONT (6.1.2.8. ÁBRA) kimenetén a bemenetére érkező jelek szorzata jelenik meg

, y(t) = si (t)

i∏ (6.1.2-10)

vagy

y[k] = si[k]i∏ . (6.1.2-11)

6.1.2.5. ÁBRA: AZ KÉSLELTETŐ KÉPE A PROGRAMBAN

6.1.2.6. ÁBRA: AZ INTEGRÁTOR KÉPE A PROGRAMBAN

6.1.2.7. ÁBRA: AZ NEMLINEÁRIS ERŐSÍTŐ KÉPE A PROGRAMBAN


- 58 -

6.2. CSOMÓPONTI POTENCIÁLOK MÓDSZERE

A következő fejezet bemutatja az első implementált hálózat analízis opciót, a csomóponti potenciálok számításának módszerét, melynek segítségével kiszámolhatók egy hálózat komponensein folyó áramok, eső feszültségek és a teljesítmények. A fejezet egy, a programmal megoldott illusztrált példával zárul.

6.2.1. CSOMÓPONTI POTENCIÁLOK, MÁTRIX – EGYENLET

Egy Kirchhoff - típusú hálózat b számú csatolatlan, vagy csatolt kétpólus összekapcsolásából áll. A csomópontok számát r +1 jelöli, a csomópontok sorszáma i = 0, 1, 2, ..., r ; az r = 0 sorszámú a báziscsomópont.

A k -adik kétpólushoz ik áram és uk feszültséget rendelünk

(k = 1, 2, ..., b) , referenciairányukat egyezőnek választjuk: az irány mindig a kétpólus első pinjétől a második pinjéig mutat. Egy hálózat valamennyi kétpólusának áramát, ill. feszültségét egy-egy b - dimenziós i ill. u vektorban tároljuk.

A kétpólusok árama és feszültsége között azok karakterisztikája teremt kapcsolatot (LÁSD 6.1. FEJEZET). Csatolatlan kétpólusok mindegyikére egy egyenlet vonatkozik, m számú csatolt kétpólusra pedig m számú független egyenlet. A kétpólusokra vonatkozó karakterisztikák összessége b számú független egyenletet jelent [4].

A hálózat struktúráját egyértelműen jellemzi A csomóponti mátrixa.

Ennek j - edik sora megfelel a j - edik csomópontnak ( j = 1, 2, ..., r) , k - adik oszlopa megfelel a k - adik kétpólusnak (k = 1, 2, ..., b) .

Az Ajk mátrixelem értéke +1, −1 vagy 0 lehet, ha a j - edik

csomóponthoz, a k - adik kétpólus:

− első pinje csatlakozik Ajk = +1 ,

− második pinje csatlakozik Ajk = −1 , (6.2.1-1)

− egyik pólusa sem csatlakozik Ajk = 0 ,

tehát a +1 a „honnan”, a −1 a „hova” referenciának felel meg, a j = 0sorszámú báziscsomópontnak nem felel meg sor.

6.1.2.8. ÁBRA: A SZORZÓCSOMÓPONT ERŐSÍTŐ KÉPE A PROGRAMBAN


- 59 -

Az Amátrix minden oszlopában mindig egy +1 és egy −1 áll, a többi elem

értéke nulla. Ha a kétpólus valamelyik pinje a báziscsomóponthoz kapcsolódik, akkor abban az oszlopban csak egyetlen elem értéke nem nulla (hiszen a báziscsomópontotnak nem felel meg sor a mátrixban). A csomóponti mátrix ismeretében a hálózat struktúrája már rekonstruálható [5-6].

Particionáljuk a csomóponti mátrixot a kétpólusok jellege szerint:

A = AU

AI

AR

AC

AL

⎡⎣⎢

⎤⎦⎥ , (6.2.1-2)

ahol AU

a feszültségforrás(ok) csomóponti mátrixa, AI az áramforrás(ok)

csomóponti mátrixa, AR

az ellenállás(ok) csomóponti mátrixa, AC

a

kondenzátor(ok) csomóponti mátrixa és AL

végül a tekercs(ek) csomóponti

mátrixa.

A hálózatra vonatkozó áramtörvények egy fundamentális rendszere, ill. a feszültségek kifejezése a csomóponti potenciálokkal

Ai = 0 , (6.2.1-3)

u = ATϕ (6.2.1-4)

alakban fogalmazható meg a csomóponti mátrix ismeretében.

A folyamatos idejű (FI) lineáris invariáns hálózatra az állapotváltozós leírás normálalakja:

x = A ' x + Bs,y = Cx + Ds

. (6.2.1-5)

Az itt szereplő A mátrixot vesszővel különböztetjük meg az A csomóponti

mátrixtól [4].

Az x állapotvektor a kondenzátorok uCk feszültségéből és a tekercsek iLkáramából alkotott uC és iL vektorok összessége, az s forrásvektor az uskforrásfeszültségekből és az isk forrásáramokból alkotott us és is vektorok összesége:

x =uciL

⎡

⎣⎢⎢

⎤

⎦⎥⎥

, (6.2.1-6)

s =usis

⎡

⎣⎢⎢

⎤

⎦⎥⎥

. (6.2.1-7)


- 60 -

A kondenzátorok és a tekercsek karakterisztikáinak összessége

iC = CuC , (6.2.1-8)

uL = L iL (6.2.1-9)

alakban foglalható össze.

A lineáris rezisztív komponenensek összessége admittancia -karakterisztikával jellemezhető, amely a következő alakban írható fel:

iR = GuR . (6.2.1-10)

Írjuk fel a (3) és (4) egyenleteket a karakterisztikák behelyettesítésével:

AUiU + A

Iis + AR

GuR + ACC uC + A

LiL = 0 , (6.2.1-11)

us = AUT ϕ , (6.2.1-12)

uI = AITϕ , (6.2.1-13)

uR = ARTϕ , (6.2.1-14)

uC = ACT ϕ , (6.2.1-15)

uL = ALTϕ . (6.2.1-16)

Ezekből adódik a programban felhasznált és implementált mátrix -egyenlet:

0 AUT 0 0

AU

ARGA

RT A

CC 0

0 ACT 0 0

0 ALT 0 −L

⎡

⎣

⎢⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥⎥

iUϕ

1

uciL

⎡

⎣

⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥

=

0 0

0 −AL

1C

0

0 0

⎡

⎣

⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥

uciL

⎡

⎣⎢⎢

⎤

⎦⎥⎥+

1U

0

0 −AI

0 0

0 0

⎡

⎣

⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥

usis

⎡

⎣⎢⎢

⎤

⎦⎥⎥

(6.2.1-17)

A lineáris egyenletrendszer megoldásával megkapjuk uC és

iL kifejezését

uC és iL , valamint us és is függvényeként, vagyis az állapotegyenlet normálalakját.

Ha az egyenletrendszer nem megoldható, a hálózat nemreguláris. Kiadódik iU és ϕ normálalakja is. A választ jelentő más változók (pl. iR vagy

uJ ) normálalakja a (11) alapján már könnyen kifejezhető [4].


- 61 -

6.2.2. EGY PÉLDA MEGOLDÁSÁNAK BEMUTATÁSA

A következő fejezet egy a programból kiemelt példa levezetését mutatja be. A példa bemutatja a programba integrált példa hálózatban a kiszámolt és leveztett csomóponti potenciálokat, továbbá a hálózat komponensein eső feszültségeket és folyó áramokat, valmint a komponensek teljesítményeit.

Továbbá betekintést ad az analízis pont implementációjába, melyhez az ’Analysis’ (2.3. FEJEZET, 6.2.2.2. ÁBRA) és a ’Helpers/Analysis’ (2.6. FEJEZET, 6.2.2.1. ÁBRA) csomagokban található osztályok kapcsolódnak.

6.2.2.1. ÁBRA: A ‘HELPERS/ANALYSIS’ CSOMAG ÉS OSZTÁLYAI


- 62 -

6.2.2.2. ÁBRA: AZ ‘ANALYSIS’ CSOMAG ÉS OSZTÁLYAI


- 63 -

A következő rezisztív hálózaton kersztül vezetjük végig a fejezet a csomóponti potenciálok, a kétpólusokon eső feszültségek és folyó áramok kiszámítását [7].

Az analízis pont elindítása után a program felépíti a hálózat csomóponti mátrixát, ami a következő alakban néz ki a behelyettesített értékekkel:

R2 R3 R4 R1 I U

A =−1 1 0 00 −1 1 −11 0 0 1

00−1

100

⎡

⎣

⎢⎢⎢

⎤

⎦

⎥⎥⎥

ϕ1

ϕ2

ϕ3

A csomópontok meghatározása a ’NodeModel’ és a ’LogicalNode’ osztály segítségével történik.

A gráf vizsgálata előtt szükséges az integritás vizsgálata, vagyis annak ellenőrzése, hogy nincsenek-e bekötetlen kétpólusok. Ez a ’Graph’ osztály ’checkIntegrity()’ metódusa segítségével történik, amely a gráfban szereplő összes ’Node’ objektum ’isProperlyConnected()’ metódusát hívja meg és végül csak akkor ad vissza ’true’ értéket, ha minden megelőző függvényhívás is ’true’ értéket adott. Az ’isProperlyConnected()’ metódus működése a ’Node’ implementációjától függ, például ’Pin’ esetén csak egy, ’Junction’ esetén viszont legalább két ’Connection’ kapcsolódását igényli.

6.2.2.3. ÁBRA: A PROGRAMMAL SZERKESZTETT PÉLDA HÁLÓZAT

AR

AI

AU


- 64 -

Az integritás ellenőrzése után a gráf vizsgálata következik, a hálózat csomópontjainak felépítése érdekében. Ez a ’NodeModel’ osztály ’reBuild()’, ’discoverPins()’, ’discoverTree()’ metódusaival történik.

A ’reBuild()’ metódus sorra veszi a gráfban szereplő komponenslábakat (pin), és meghívja rájuk a ’discoverPins()’ metódust, a logikailag az komponenslábhoz kapcsolódó egyéb komponenslábak felderítésének érdekében. A ’discoverTree()’ metódus bejárja a lábakhoz kapcsolódó vezetékeket, és összegyűjti a bejárt komponenslábakat. Végül a discoverPins() metódus viszatér egy listával, amely az összegyűjtött komponenslábakat tartalmazza. A ’reBuild()’ metódus ezen istából egy új ’LogicalNode’ objektumot hoz létre, amely így az egy logikai csomóponthoz kapcsolódó komponenslábakat tartalmazza, és rendelkezhet potenciállal, valamint egy logikai értékkel, ami azt mutatja meg, hogy az adott csomópont a földpotenciál (ϕ0 = 0 V) vagy sem. Ezután a reBuild()’ függvény veszi a következő komponenslábat és megnézi, hogy az eddig létrehozott csomópontok tartalmazzák-e már azt. Amennyiben nem, úgy új ’LogicalNode’ objektumot hoz létre.

A kapcsolódási mátrixok a felépített ’NodeModel’ segítségével a (6.2.1-1) alapján töltődnek fel.

Ezek meghatározása után az ellenállások rezisztanciáiból a program kiszámítja a diagonális konduktancia mátrixot, ahol

G = R−1,

vagyis

Gij =1Rij

.

Az adott példában szereplő ellenállások konduktancia mátrixa a következő:

G =

0.05 0 0 00 0.33 0 00 0 0.1 00 0 0 0.1

⎡

⎣

⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥

R2R3R4R1

.

A kondunktancia mátrix felépítése után a feszültségforrások forrásfeszültségeiből és az áramforrások forrásáramaiból a program felépíti a forrásvektorokat:

I s = 2 A

és

US = 100 V .


- 65 -

Mivel a példa hálózat csak ellenállásokat, feszültségforrásokat és áramforrásokat tartalmaz, ezért (6.2.1-17) - ből csak a

0 AUT

AU

ARRA

RT

⎡

⎣

⎢⎢⎢

⎤

⎦

⎥⎥⎥

iUϕ

⎡

⎣⎢⎢

⎤

⎦⎥⎥=

1E

0

0 −AI

⎡

⎣

⎢⎢

⎤

⎦

⎥⎥

usis

⎡

⎣⎢⎢

⎤

⎦⎥⎥

komponenseknek megfelelő sorokat és oszlopokat használjuk. A rész-mátrixegyenlet a példában szereplő értékek behelyettesítésével az

0 1 0 01 0.083 −0.033 −0.050 −0.033 0.233 −0.10 −0.05 −0.1 0.15

⎡

⎣

⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥

iUϕ

1

ϕ2

ϕ3

⎡

⎣

⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥

=

1 00 00 00 1

⎡

⎣

⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥

1002

⎡

⎣⎢

⎤

⎦⎥

mátrixegyenletet adja. Melyből Gauss – Jordan – elimináció segítségével számíthatjuk ki az ismeretlen potenciálokat és a feszültségforrások ismeretlen áramait.

A program saját Gauss – Jordan – eliminációs metódussal és mátrix kezelő osztályokkal rendelkezik (LÁSD 2.6. FEJEZET, 6.2.2.2. ÁBRA).

A behelyettesített egyenletből a csomóponti potenciálok vektoraként

ϕ =ϕ1

ϕ2

ϕ3

⎡

⎣

⎢⎢⎢

⎤

⎦

⎥⎥⎥=

10048

78.66

⎡

⎣

⎢⎢⎢

⎤

⎦

⎥⎥⎥

V

és a feszültségforrás (több feszültségforrásnál egy vektor) ismeretlen áramaként

IU = −2.8 A

eredményt kapjuk.

(6.2.1-13) alapján az áramforrás ismeretlen feszültsége a példában:

UI = −78.66 V

(6.1.1-5) alapján kiszámolható a feszültségforrás teljesítménye, (6.1.1-6) alapján pedig az ármaforrás teljesítménye (több forrásnál mindkét esetben vektorok), melyek a példa hálózatban szereplő értékek behelyettesítésével:

PU = −280 W

és

PJ = −157.36 W .


- 66 -

A (6.2.1-10) és (6.2.1-14) és (6.1.1-13) egyenletek alapján megkapjuk az ellenállásokon folyó áramok, eső feszültségek valamint a teljesítmények vektorát, melyek értéke itt:

UR =

UR2

UR3

UR4

UR1

⎡

⎣

⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥

=

−21.335248

30.66

⎡

⎣

⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥

V ,

I R =

IR2

IR3

IR4

IR1

⎡

⎣

⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥

=

−1.061.734.8

3.06

⎡

⎣

⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥

A

és

PR =

PR2

PR3

PR4

PR1

⎡

⎣

⎢⎢⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥⎥⎥

=

22.6189.96230.493.82

⎡

⎣

⎢⎢⎢⎢

⎤

⎦

⎥⎥⎥⎥

W .

Az analízis eredményei két dialógusablakban és a logger ablakban is nyomon követhetők a felhasználói felületen (6.2.2.4. ÁBRA).

6.2.2.4. ÁBRA: CSOMÓPONTI POTENCIÁLOK SZERKESZTŐ FELÜLET


- 67 -

Egy komponensre való kattintás után a felső dialógus ablakban megjelenik az aktuális komponens áramának, feszültségének és teljesítményének az értéke.

Egy vezetékre, vagy csomópontra való kattintás után az alsó dialógus mutatja a csomópont potenciáljának az értékét.

A logger ablakban (6.2.2.5 ÁBRA) az analízis pont lépései, továbbá a mátrixok eredményei követhetők nyomon.

6.2.2.5. ÁBRA: MÁTRIX EREDMÉNYEK A LOGGER ABLAKON


- 68 -

7. KONKLÚZIÓ

A fejlesztés kezdete után 10 hónappal a program grafikus felhasználói felületének nagy része elkészült.

Az első analízis pont implementációja után, a fő mátrixegyenlet második felének megoldása adja a következő analízis pontot, az állapotváltozós leírás számítását és a válaszjelek ábrázolását.

Ezután a következő két évben a további analízis pontok implementációja következik.


- 69 -

BIBLIOGRÁFIA

[1] DR. KUCZMANN MIKLÓS: Jelek és rendszerek, UNIVERSITAS – GYŐR KHT, GYŐR, 2005.

[2] DR. STANDEISKY ISTVÁN: Villamosságtan, UNIVERSITAS – IYŐR KHT, GYŐR,

2005. [3] SIMONYI KÁROLY, ZOMBORY LÁSZLÓ: Elméleti villamosságtan, MŰSZAKI

KÖNYVKIADÓ, BUDAPEST, 2000. [4] DR. FODOR GYÖRGY: Hálózatok és rendszerek analízise I-III, MŰEGYETEMI

KIADÓ, BUDAPEST 1997. [5] GÉHER KÁROLY, SOLYMOSI JÁNOS: Lineáris áramkörök tervezése,

TANKÖNYVKIADÓ, BUDAPEST, 1992 [6] SZÉKELY VLADIMIR, POPPE ANDRÁS: Áramkör-szimuláció a PC-n,

COMPUTERBOOKS, BUDAPEST, 1996. [7] DR. FODOR GYÖRGY: Villamosságtan példatár, NEMZETI TANKÖNYVKIADÓ,

BUDAPEST, 1998. [8] IAN SOMMERVILLE: Szoftver-rendszerek fejlesztése, PANEM KÖNYVKIADÓ,

BUDAPEST, 2002. [9] NEIL BRADLEY: Az XML - kézikönyv, SZAK KIADÓ, VESZPRÉM, 2005.

[10] ROGERS CADENHEAD: Tanuljuk meg a Java programozási nyelvet 24 óra

alatt, KISKAPU KFT, BUDAPEST, 2006.

[11] DIRK LOUIS, PETER MÜLLER: Java, PANEM KÖNYVKIADÓ, BUDAPEST, 2002.

[12] ANGSTER ERZSÉBET: Objektumorientált tervezés és programozás II. AKADÉMIAI NYOMDA, MARTONVÁSÁR, 2002.

[13] VARJASI NORBERT: Programozás III. – Objektumorientált programozás JAVA nyelven, UNIVERSITAS – GYŐR KHT, GYŐR, 2005.

[14] NYÉKINÉ G. JUDIT: JAVA 2 Útikalauz programozóknak 1.3 - A kávé, ELTE TTK HALLGATÓI ALAPÍTVÁNY, BUDAPEST, 2001.

[15] NYÉKINÉ G. JUDIT: JAVA 2 Útikalauz programozóknak 1.3 - A hab, ELTE TTK HALLGATÓI ALAPÍTVÁNY, BUDAPEST, 2001.

[16] NYÉKINÉ G. JUDIT: JAVA 2 Referencia 1.3 - A csésze, ELTE TTK HALLGATÓI ALAPÍTVÁNY, BUDAPEST, 2001.


- 70 -

[17] ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, JOHN VLISSIDES: Programtervezési minták, Újrahasznosítható elemek objektumközpontú programokhoz, KISKAPU KFT, BUDAPEST, 2004.

[18] MARTIN FOWLER, KENT BECK, JOHN BRENT, WILLIAM OPDYKE, DON ROBERTS: Refactoring – Kódjavítás újratervezéssel, KIASKAPU KFT, BUDAPEST, 2006.

[19] MARTIN FOWLER, JIM RUMBAUGH, GRADY BOOCH, IVAR JACOBSON, CRIS

KOBRYN: UML Distilled – A Brief Guide to the Standard Object Modelling Language, ADDISON – WESLEY, 2003.

ATONA VA ANA 2.0 A NETWORK ANALYSIS - …maxwell.sze.hu/docs/l17.pdf · program UML osztály -...

Documents

Transcript of ATONA VA ANA 2.0 A NETWORK ANALYSIS - …maxwell.sze.hu/docs/l17.pdf · program UML osztály -...