TŐZSDEI STRATÉGIÁK TESZTELÉSÉHEZ VALÓ GRIDES KERETRENDSZER FEJLESZTÉSE

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "TŐZSDEI STRATÉGIÁK TESZTELÉSÉHEZ VALÓ GRIDES KERETRENDSZER FEJLESZTÉSE"

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Irányítástechnika és Informatika Tanszék Sali Dániel Attila TŐZSDEI STRATÉGIÁK TESZTELÉSÉHEZ VALÓ GRIDES KERETRENDSZER FEJLESZTÉSE KONZULENS Kápolnai Richárd Péter BUDAPEST, 2010

2 HALLGATÓI NYILATKOZAT Alulírott Sali Dániel Attila, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök, stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy autentikált felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. A teljes szöveg közzététele dékáni engedéllyel titkosított diplomatervekre nem vonatkozik. Kelt: Budapest, december Sali Dániel Attila

3 Tartalomjegyzék Tartalomjegyzék... 3 Összefoglaló... 5 Abstract Bevezetés Idősorelemzés és backtesting A technikai elemzés Kereskedési stratégiák A Backtesting A backtesting célja A backtesting korlátai Backtesting rendszerek Paraméterek vizsgálata Az elkészített rendszer Célkitűzések Választott megoldások A pénzügyi modell A szimuláció motorja Felhasználótól elvárt komponensek Alkalmazásfejlesztés grid rendszerekre A grid, mint szolgáltatás Alkalmazások gridesítése Az EGEE Grid biztonsága A Saleve keretrendszer Fejlesztés a Saleve keretrendszer használatával A Saleve keretrendszer továbbfejlesztése Rendszerintegráció A backtesting keretrendszer elemei A felhasználói kezelőfelület... 42

4 5.1.2 A Saleve kliens Saleve feladatok (jobok) létrehozása A grid jobok futása, eredmények begyűjtése Az implementált rendszer tesztelése, értékelése Továbbfejlesztési lehetőségek Köszönetnyilvánítás Irodalomjegyzék Függelék... 57

5 Összefoglaló A diplomaterv célja egy olyan tőzsdei kereskedési stratégiaelemző programozói kertrendszer létrehozása, mely lehetővé teszi a fejlesztő számára új stratégiák létrehozását és szimulációját, és segíti a fejlesztőt a stratégia optimális paraméterezésének meghatározásában. Az elkészített és bemutatott rendszer különlegessége, hogy a kereskedési stratégia szimulációját nem a felhasználó számítógépén hajtja végre, hanem ehhez egy grid infrastruktúrát használ. A diplomaterv az idősorelemzés pénzügyi hátterének bemutatásával kezdődik, majd leírásra kerül a szimulációt végző szoftverkomponens. Ismertetve lesz egy Saleve nevű keretrendszer, mely nagyban megkönnyíti a grid infrastruktúra használatát. Ez a Saleve keretrendszer továbbfejlesztésre került a diplomamunkában. Ezt követően prezentálva lesz a teljes rendszer, bemutatva azt, hogyan lett a szimulációs motor integrálva a kliens-szerver alapú, grides háttérrel rendelkező keretbe. Végül egy felhasználói leírás következik, mellyel a rendszer működése ellenőrizhető, illetve javaslatok szerepelnek a rendszer továbbfejlesztésének irányait illetően. 5

6 Abstract The objective of the thesis is to create a stock trading simulation framework, which allows a developer to create and simulate new trading strategies, and to help the trader to determine the optimal parameters of a trading strategy. The specialty of the developed system is the possibility to use a grid infrastructure as a back-end on which the calculations of the trading simulations are executed. The thesis starts with the introduction of the financial theory behind the backtesting procedure, and continues with the presentation of the simulation engine. A framework named Saleve will be presented, which greatly eased the burdens associated with the use of a grid back-end infrastructure. This framework is upgraded in the thesis. Consequently, the entire backtesting framework is presented, emphasizing on the integration of the simulation engine into the client-server architecture of the gridsupported framework. Finally, a user s guide is given in the form of a testing manuscript, and suggestions are given regarding to possible enhancements and developments of the backtesting framework. 6

7 1 Bevezetés A tőzsdei kereskedés során kereskedési stratégiájának kialakításához egy befektető két alapvető elemzési módszert alkalmazhat: A fundamentális elemzés a részvények piaci és belső, tényleges értéke közötti eltérést keresi, feltételezi, hogy van olyan a részvénnyel kapcsolatos információ, melyet a részvény ára nem tükröz, hogy ezt kihasználva érjen el profitot a kereskedés során. A technikai elemzés ezzel szemben feltételezi, hogy a piac nem tökéletesen hatékony, és bizonyos minták ismétlődnek, tehát olykor a részvény jövőbeli árfolyamát a múltbéli árfolyamának elemzésével lehet megbecsülni. Dolgozatomban egy olyan, saját fejlesztésű, technikai elemzéshez használható eszközt mutatok be, mely különböző, a kereskedő által megadott kereskedési stratégiát képes historikus tőzsdei árfolyam-idősorokon szimulálni. A szimuláció lehetőséget teremt az eltérő elveken működő, eltérő komplexitású, különböző paraméterekkel futtatott stratégiák összehasonlítására, a legeredményesebb stratégia kiválasztására. A vizsgált stratégiák komplexitása, és az egyes stratégiák elemzésénél alkalmazott nagyméretű paramétertér nagy számítási kapacitást igényel a szimuláció során. Ezért a diplomamunkám során egy olyan rendszert fejlesztettem, mely a számításokat egy elosztott, nagy teljesítményű számítási szolgáltatás, egy Grid rendszer felhasználásával végzi. Azonban egy Grid rendszer használata olyan speciális szakismereteket igényel, melyek nem várhatóak el egy pénzügyi matematikai beállítottsággal rendelkező, algoritmikusan gondolkodni tudó, alapszinten programozni képes elemző felhasználótól. Ezért a diplomamunkaként elkészített rendszer célja, hogy egy keretet biztosítson a felhasználónak, hogy elvégezhesse szimulációit, anélkül, hogy a szimulációt ténylegesen futtató rendszer programozását és használatát meg kellene ismernie. A következőkben a diplomatervet pénzügyi oldalról közelítem, részletesebben bemutatom az idősorelemzés módszertanát, a jelentősebb portfólió kereskedési stratégiákat. Ez után a keretrendszer informatikai alapjait mutatom be, a Grid szolgáltatás felhasználását alkalmazásfejlesztői nézőpontból. A pénzügyi és 7

8 informatikai megközelítéseket egységbe foglalom, bemutatom, hogyan épül fel egy egész rendszer a diplomatervemben a két megközelítésből. Végezetül a rendszer kritikai elemzése következik, elemzem, hogy mennyire teljesíti a legfontosabb támasztott követelményt, hogy egy informatikai szaktudás nélküli felhasználó is képes legyen a rendszer segítségével nagyteljesítményű számító rendszereket felhasználva tőzsdei kereskedési stratégiák szimulációjára. Értékelem, hogy a diplomatervem milyen mértékben teljesíti a kiírásban felsorolt feladatokat és javaslatokat teszek a rendszer továbbfejlesztésére. 8

9 2 Idősorelemzés és backtesting 2.1 A technikai elemzés A tőzsdei spekulációk során a technikai elemzést alkalmazó befektetők elfogadják azt a tézist, hogy nem képesek tökéletesen meghatározni egy értékpapír belső értékét, azaz az értékpapírt kibocsájtó vállalat értékét. Ehhez a spekulálónak meg kell ismernie a vállalat eredményeit, gazdasági folyamatait, az iparágban levő hasonló vállalatokat, a vállalat környezetét. Mindezen információk beszerzése, naprakészen tartása komoly erőfeszítéseket, sok időt és jó információforrásokat igényel. A technikai elemzés során ezzel szemben az elemzést végző egy alapvető hipotézist fogad el: a piac nem tökéletesen hatékony, és bizonyos minták nagy eséllyel ismétlődnek. A technikai elemzés során tehát az értékpapírok historikus idősoraiban próbálunk meg ismert és felismerhető helyzeteket keresni, mivel előzetes ismereteink vannak a várható reakcióról, s ezt a feltételezést kihasználva tudunk nyereségesen kereskedni. Egy ilyen technikai elemzést végez el a Portfolio.hu (a forrásban meg nem nevezett) szerzője [1]: Az es szintek által jelzett sávból fölfelé tört ki az amerikai index, és a sáv által jelzett emelkedést már többé kevésbe abszolválta is az S&P500. Az ellenállás az 1230 pontos lokális csúcs, amely áttörése megerősítené az emelkedő trendet. 9

10 ábra A Portfolio.hu elemzésénél használt idősor Ha értelmezzük az idézetet, akkor megfigyelhető, hogy az elemző felismert egy ismert mintát ( az ellenállás az 1230 pontos lokális csúcs ), melyből ismeretei és múltbéli tapasztalatai alapján következtetést von le a várható jövőbeli árfolyamértékre. (Mely szerint, ha áttöri az index az 1230 pontos határt, akkor további emelkedés várható.) 2.2 Kereskedési stratégiák Ezek alapján egy technikai elemzést alkalmazó befektető tőzsdei stratégiáját úgy adhatjuk meg, hogy figyeli a jelenlegi árfolyamot felismerhető minták és helyzetek után kutatva, majd amennyiben sikeresen felismer egy mintát, végrehajtja a minta által meghatározott kereskedési cselekményt (vesz vagy elad értékpapírt). Az eljárást ismerve bizonyára felmerül az olvasóban a kérdés, hogy mégis milyen mintákat keressen a befektető, és milyen cselekményeket végezzen a minták felismerése esetén. Egy kereskedési stratégia ezeket a mintákat és cselekményeket határozza meg. Technikai elemzésen alapuló kereskedési stratégiából megszámlálhatatlan sokat alkottak az idők során, azonban ezek jellemzően könnyen meghatározható mintákat figyelnek. Eltérés elsősorban a mintavétel időtartalmában és hosszában van, illetve a stratégiatípusokon belül a konkrét paraméterezésben található. Néhány ismertebb stratégia [2]: 10

11 Mozgóátlag-átlépések [3]: Az elemző meghatároz egy hosszú és egy rövidtávú mozgóátlag-ablak méretet (legyen N és n), azt figyeli, hogy hogyan viszonyul az értékpapír rövidtávú árfolyamátlaga az elmúlt N nap nyitó/záró árfolyamainak átlagához. Amennyiben a rövidtávú árfolyam-átlag konzisztensen a hosszú távú átlag felett helyezkedik el, úgy egy növekvő trend állapítható meg, azaz érdemes vásárolni az értékpapírból, vagy kivárni az eladással. Ennek a kereskedési stratégiának a jellemző paraméterei a két átlag-ablak nagysága, napban megadva. Kitörés árfolyamsávból [2]: Amennyiben az elemző azt érzékeli, hogy az árfolyam kis ingadozással egy adott érték körüli sávban tartózkodik, úgy meghatároz egy alsó és egy felső korlátot. Ha meghaladja a felső értéket az árfolyam, azt vételi jelként kezeli: 2.2. ábra Kitörés árfolyamsávból. Forrás: Tradetrek.com Ennél a stratégiának a jellemző paraméterei a sávot meghatározó árfolyam-ingadozás nagysága és a sáv minimális hossza. Rés kereskedés ( Gap trading ) [4]: Azokat a helyzeteket figyeli, amikor a napi nyitóárfolyam magasabb, mint az előző napi záró árfolyam. Egy ilyen rést felismerve követi a nyitás utáni első óra árfolyammozgását, amennyiben később meghaladja ezt a sávot az árfolyam, akkor vesz az értékpapírból, ha a sáv az árfolyam alá süllyed, akkor eladja papírjait. 11

12 Ennél a stratégiának a jellemző paramétere a nyitás utáni kivárás hossza (általában 1 óra), illetve a sáv szélessége. Bár ezek a technikai kereskedési stratégiák egyszerű, beazonosításhoz kis számítást igénylő mintákat használnak, mégis eredményesebbek lehetnek a véletlenszerű kereskedésnél. Egy ilyen elemzést ír le a Journal of Finance 1992 decembberi száma, ahol mozgóátlag-átlépéses és a sávkitöréses stratégia eredményességét mutatták ki [5]. 2.3 A Backtesting Mivel, mint ahogy azt az előző pontban bemutattam, egy spekuláns számára többféle stratégia áll rendelkezésre, széles tartományban megadható paraméterekkel, ezért szükség van egy módszerre, mellyel ki lehet választani a befektetési környezethez legjobban illő stratégiát. Kiindulva a technikai elemzés azon feltételezéseiből, hogy az egyes értékpapírok árfolyamaiban ismétlődő minták szerepelnek, célszerű lenne a stratégiákat ismert, múltbéli árfolyamokon vizsgálni. A stratégiákat azonos historikus idősor adatokon futtatva, szimulációt végezve lehetőséget teremt arra, hogy a stratégiák eredményességét összevessük. Ezt a szimulációt nevezi az angol szakirodalom backtesting-nek. Az a hipotézisünk, hogy az a stratégia, amelyik jól teljesít korábbi adatokon, a minták ismétlődése miatt a jövőben is jól fog teljesíteni A backtesting célja A jól teljesít jelző a pénzügyi világban nem csak az abszolút értelemben magas hozamot elérő stratégiát jellemzi, hanem az elérhető hozamot jellemzi a vállalt kockázathoz hasonlítva, tehát egy stratégia akkor teljesít jól, ha azonos kockázati szinten a szinthez tartozó átlagnál magasabb hozamot biztosít, vagy egy adott várható hozamszintet alacsonyabb kockázati szint mellett képes elérni. A kockázat a pénzügyi világban a hozamértékek szórásának nagyságát jelenti, azaz a kis kockázatú értékpapírok árfolyama kevésbé ingadozik, mint a nagy kockázatú értékpapírok árfolyama. A stratégia szimuláció tehát nem csak arra alkalmas, hogy meghatározza az adott stratégiával a múltban milyen hozamok lettek volna elérhetőek, hanem a stratégia alkalmazásának kockázata is mérhető. A backtesting szimulációt nem csak tőzsdei stratégiák értékeléséhez alkalmazzák, hanem a pénzügyi szektorban gyakran használt kockáztatott érték mutató 12

13 (Value at Risk, VaR) számításával és szimulálásával a pénzügyi intézmények értékelhetik a kockázatkezelésüket. Az intézmények által használt VaR modellek backtest-tel történő értékelését írja le a Federal Reserve (az Egyesült Államok nemzeti bankjának) egyik tanulmánya [6] A backtesting korlátai Mint minden szimulációnál, a historikus idősorokat alkalmazó szimulációknál is figyelni kell arra, hogy a szimuláció csak addig szolgáltat reális értékeket, amíg a szimulált tevékenység nem befolyásolja számottevően a szimuláció környezetét. Ez a kereskedési stratégiák elemzése esetén azt jelenti, hogy addig lesz értékelhető a szimuláció eredménye, amíg a stratégia követése során végrehajtott kereskedések nem befolyásolnák az árfolyamot olyannyira, hogy a kereskedés után a historikus árfolyam már nem tükrözné hűen a kialakult piaci árfolyamot. Ez akkor következhet be, ha a szimulált stratégia olyan volumenű kereskedést végez, melynek hatására a valóságban a piac az árfolyam elmozdításával reagálna. Az ilyen stratégiák bonyolultabban szimulálhatóak, ezektől eltekintünk, hiszen a kisbefektető szemszögéből egy nagy forgalmú piacon az árfolyamra való hatás elhanyagolható. Historikus idősorokon végzett szimuláció esetében egy másik jelenségre is fontos ügyelni: Ha egy olyan adathalmazt használunk, mely több évre visszamenőleg tartalmazza egy adott cég árfolyamait, az implicit módon azt a többletinformációt tartalmazza, hogy az adott cég fennmaradt az évek során. Tehát, ha mondjuk az S&P 500 [7] indexben szereplő részvények árfolyamait használjuk fel, akkor a stratégiánk eredményesebbnek mutatkozhat, mint a valóságban lenne, ahol nem csak az 500 legjelentősebb, legerősebb amerikai vállalat részvényeivel lehet kereskedni. Ezt a torzító hatást nevezi az angol szakirodalom survivorship biasnek [8] [9]. Ügyelni kell még arra is, hogy amennyiben részvényárfolyamokat használunk idősorelemzéshez, az árfolyamértékek osztalék kifizetés (és más változások, pl. feldarabolás) után korrigálva legyenek, különben az osztalék kifizetés napján egy hirtelen, meg nem magyarázható árfolyamesés lenne az idősorban. A legtöbb, historikus tőzsdei árfolyamokat közlő weboldal már korrigált értékeket biztosít a felhasználók számára. A korrekció pontos és szabványos számítását a Chicago Booth egyetem Center for Research in Security Prices kutatóintézete dolgozta ki [10]. 13

14 2.4 Backtesting rendszerek Bár az egyszerű kereskedési stratégia-szimulációk nem alkalmaznak bonyolult számításokat, mégis a backtesting a számítógépek megjelenésével vált széleskörűen alkalmazott eszközzé. Az első szimulációt végezni képes elemzőrendszert, a ProfitTaker-t Louis B. Mendelsohn fejlesztette ki személyi számítógépekhez 1983-ban [11]. Napjainkban több, egyéni befektetők számára fejlesztett, kereskedelmi forgalomban levő backtesting-re képes rendszer van, ezek közül mutatnám be a jelentősebbeket: Tradecision [12]: Lehetőséget ad stratégiák szimulációjára egyes részvények árfolyamát használva, a stratégiák szabadon paraméterezhetőek és új stratégia hozható létre egy saját programozási nyelv használatával. Nem képes portfóliók kereskedelmét szimulálni. Ára: $1195 től. MultiCharts [13]: Az általam ismert legmodernebb backtesting-re képes szoftver, képes portfóliókkal is kereskedni. Egyszerűbb stratégiák programozhatóak, az eszköz saját, nem teljes értékű programozási nyelve segítségével. Lehetőséget ad automatizált kereskedelemre brókercégekhez csatlakozó szoftverkomponensek segítségével. Ára: $1497-től. AmiBroker [14]: Szintén egy nagy tudású portfólió elemző szoftver, képes portfóliókat kezelni a kereskedési szimulációk során. Lehetőséget ad saját stratégiák fejlesztésére egy C-hez hasonló programozási nyelv használatával. Ára: $279 Ashkon StockPredictor: Egy alapszintű elemző szoftver, nem képes portfólió elemzésre, csak egyedi részvények árfolyamaival képes szimulációkat végezni. Beépített stratégiákat tartalmaz, melyeket paraméterezni enged. A historikus idősorokon végzett szimuláció értéke nem csak a szimulátoron és az alkalmazott stratégián múlik, hanem kulcsfontosságú az idősor információtartalma, melyet a szimuláció során használunk. Jelenleg szabadon hozzáférhetőek a Budapesti Értéktőzsdén [15] és a jelentősebb nemzetközi tőzsdéken [16] jegyzett részvények historikus árfolyamindexei az elmúlt évtizedekre. Ezek a historikus árfolyamindexek 14

15 napi felbontásúak, nyitó- és záró árat, napi minimum és maximum árat, illetve a forgalom nagyságát tartalmazzák. Ilyen napi felbontású árfolyamadatokkal már lehetséges értékelhető szimulációkat végezni, azonban csak olyan stratégiákat lehet elemezni, melyek kereskedési frekvenciája napi kereskedésnél alacsonyabb. Ezek a stratégiák jellemzően inkább hosszú távú trendeket keresnek. Egy mozgóátlagokat vizsgáló stratégia elemezhető ilyen adatsoron, de egy gap-trading (lásd 2.2) stratégia nem alkalmazható, mert szükség lenne nap közbeni árfolyamértékekre is. Nagyobb felbontású árfolyamadatok is elérhetőek az Interneten, például a Portfolio.hu valós időben még a 5 legjobb ajánlatot is elérhetővé teszi a könyvből egy adott értékpapírra [17], de ennek a szolgáltatásnak a díja magas. Ilyen, szinte teljes információhalmazon viszont minden stratégiát ki lehet próbálni, mert minden olyan információ a rendelkezésünkre áll, ami valós kereskedés esetén is elérhető. A listán szereplő szoftvereknek csak a fele képes portfóliók kezelésére, és e szoftverekhez is csak korlátozott mértékben, egy új, redukált funkcionalitású programozási nyelv megtanulása árán lehet új kereskedés stratégiát hozzáadni. Ahogy azt dolgozatom bevezetésében is kifejtettem, a diplomatervem célja egy olyan backtesting rendszer fejlesztése, melyhez a felhasználó könnyen fejleszthet saját stratégiát. A felsorolt szoftverek mind a kliens számítógépén végzik a szimulációt, ez egyszerű számítások és durvább, napi felbontású adathalmaz esetén még elfogadható, gyors megoldás, de amennyiben egy komplex stratégiát kellene tesztelnünk valós felbontású (az összes tranzakciót és a legjobb n ajánlatot tartalmazó) adatsoron, sok, eltérő paramétert megadva a stratégiához, akkor egy személyi számítógép számítási kapacitása nem lesz elegendő. 2.5 Paraméterek vizsgálata A szimulációs eljárások során az adott eljárást több paraméter figyelembevételével végzik. Minden ilyen paraméternek van egy értékkészlete, mely olyan paraméter-értékeket tartalmaz, melyeket érdemes lehet a szimulációnál használni. A paraméterek értékkészleteinek Descartes-szorzata a paramétertér, a tér pontjai olyan paraméter-érték vektorok, melyek minden paramétertípusból tartalmaznak egy, az értelmezési tartományon belüli értéket. A szimulációt végzők célja lehet, hogy meghatározzák az egyes paraméterek azon értékeit, azaz a paramétertér azon pontjait, melyekre a szimuláció értékelésük szerint optimális eredményt szolgáltat. Egy 15

16 szimuláció paraméterterének vizsgálatát és például az optimális paramétertér-pont meghatározását nevezi az angol szakirodalom parameter study-nak. A kereskedési stratégiák eredményessége is nagyban függ a stratégiák alkalmazásánál használt paraméterektől, hiszen például a hosszú- és rövidtávú mozgóátlagokat figyelő stratégia érzékenységét és jelzési gyakoriságát meghatározza az átlagok időintervalluma, ha rövid időintervallumot (3-5 nap) választunk a rövidtávú átlag alapjának, akkor várhatóan gyakrabban metszik egymást az átlagértékek és keletkezik vételi vagy eladási jel. Tehát a kereskedési stratégiák paraméterezésének vizsgálata is egy parameter study feladat. A diplomamunkám során elkészített rendszernek célja volt, hogy a felhasználó a rendszer alkalmazásával vizsgálhassa egyes paraméterezések, paramétertér-pontok eredményességét úgy, hogy meghatározza a szimuláció paraméterterét, és az egyes paramétertér-pontokhoz tartozó eredményeket összeveti. 16

17 3 Az elkészített rendszer Az 2.4. fejezet végén felvetett két problémára (nincs jelenleg a piacon alapvető programozási ismeretekkel tetszőlegesen bővíthető backtesting rendszer, illetve, hogy a meglévő rendszerek nem alkalmasak nagy számításigényű szimulációk elvégzésére) kívánok megoldást kínálni a diplomamunkaként általam fejlesztett keretrendszerrel. 3.1 Célkitűzések A diplomamunka során fejlesztendő rendszerrel szemben az alábbi kritériumokat állítottuk fel: 1. Mivel a fejlesztendő rendszer keretrendszer, ezért legfontosabb funkciója, hogy a felhasználó képes legyen saját, vizsgálandó stratégiát definiálni, egy széles körben ismert programozási nyelvet használva, anélkül, hogy a rendszer teljes forráskódját ismernie kellene, 2. A felhasználó az általa választott idősorokon futtathassa az általa megírt kereskedési stratégiákat, a rendszer képes legyen az idősorok betöltésére és felhasználására, 3. A felhasználó tetszőleges, általa megadott paraméterekkel futtathassa a szimulációt, hogy megállapíthassa az adott idősorhoz a választott stratégia számára legeredményesebb paraméterhalmazt, 4. A keretrendszer által elvégzett elemzés eredményeit a felhasználó az általa választott módon értékelhesse ki, amennyiben az egyszerűbb mutatóknál (hozam) több információt szeretne az elemzésből kinyerni, 5. A keretrendszer egyszerű beállítások elvégzésével az elemzést nagy számításteljesítményű környezetben, egy gridben végezhesse, hogy lehetséges legyen egyszerre több szimulációt futtatni, illetve egy stratégiát különböző paraméter értékekkel vizsgálni, az optimális paramétereket keresve. A diplomatervem elkészítését megelőző kutatómunkám során kerestem olyan rendszert, mely teljesíti ezeket a feltételeket, de nyilvánosan elérhető ilyen rendszert nem találtam, ezért van alapom feltételezni, hogy az általam fejlesztett rendszer új és egyedi. 17

18 3.2 Választott megoldások Ahhoz, hogy a felhasználónak lehetősége legyen saját fejlesztésű stratégiákat kipróbálnia a keretrendszerrel, szükséges volt legelőször a felhasználónak nyújtott felületet specifikálni, azaz azt megadni, hogyan fog az ő programja illeszkedni a keretrendszerbe. Meg kellett határozni, hogy milyen szolgáltatásokat biztosít a fejlesztett stratégia számára a keretrendszer, illetve a keretrendszer mit vár el a stratégiától, hogyan tudja a stratégia jelezni a vételi és eladási tranzakciót. A diplomamunkám során fejlesztett keretrendszernek nem volt célja, hogy a kereskedelmi forgalomban kapható szoftverek minden tudásával rendelkezzen, hiszen ehhez nagyon kevés lett volna a rendelkezésre álló idő, inkább az újdonságok, más rendszerekben nem létező funkciók implementálása volt a cél. Ezért egy egyszerűsített pénzügyi modellt alkalmaztam a diplomamunkámban. Mivel a valós idejű árfolyam idősorok nagyon sokba kerülnek, és az alkalmazott modell sem használná fel a többlet információt a szabadon hozzáférhető, napi felbontású historikus adatsorokhoz képest, ezért a munkám során az ingyenesen elérhető, kevésbé részletes historikus adatsorokat használtam A pénzügyi modell A pénzügyi modell határozza meg, hogy milyen környezetet biztosít a keretrendszer a felhasználó stratégiájának, a stratégia milyen információk alapján hozhatja meg a vételi vagy eladási döntéseket egy adott pillanatban. Az általam használt modellben a kereskedés leggyakrabban naponként történik, a nyitó árfolyamot figyelembe véve, mert a rendelkezésemre álló idősorok napi felbontásúak. Azért kell a nyitó árfolyamot használni, mert a valóságban is csak a kereskedési nap végére lesz ismert a záróárfolyam, elméleti hiba lenne a kereskedés során ismertnek feltételezni az értékét. Mivel a fejlesztett rendszertől elvárás, hogy ne csak egy részvény kereskedelmét irányító stratégia szimulációjára legyen képes, hanem egy több részvényből álló portfólió kezelését tudja szimulálni, ezért a rendszernek nem csak egy adott részvény árfolyamának idősorára van szüksége, hanem a portfólióba választható összes részvény historikus adatsorát igényli. Erről a 2. célkitűzés értelmében a felhasználónak kell gondoskodnia. A diplomatervem fejlesztése során, teszteléshez az S&P 500-ban [7], az 18

19 500 legjelentősebb amerikai részvényt tömörítő indexben szereplő részvények adatsorait használom. A kereskedelmi forgalomban kapható backtesting rendszerek a felhasználó stratégiájától vételi és eladási jelek előállítását követelik meg, ahogy a szimuláció halad előre az időben. Egy ilyen jel egy adott mennyiségű részvény eladását vagy vételét jelenti. A diplomamunkámban használt pénzügyi modell azonban nem közvetlenül vételi és eladási jelek előállítását kéri a stratégiától, hanem ezen egyszerűsítve azt várja el, hogy minden kereskedési napon a felhasználó stratégiája minden részvényt egy általa tetszőlegesen választott pontszámmal értékeljen. A rendszer ez után kiválasztja az n (megadható paraméter) legnagyobb pontszámot kapott részvényt, és egyenlő értékben vásárol belőlük a portfólióba, a rendelkezésre álló készpénzből. A következő kereskedési nap előtt eladja a rendszer az összes portfólióban levő részvényt, majd újraértékelteti az új kereskedési napon az aznapi nyitóárfolyam szerint a rendelkezésre álló részvényeket. Ezt a folyamatot a következő ábra illusztrálja: Felhasználó stratégiája Paraméterek Napi árfolyamok Portfólió Pontszámok Részvények pontozása Vásárlás az n legjobb pontszámú részvényből Napi árfolyamok Portfólió Készpénz Új kereskedési nap Napi árfolyamok Portfólió Készpénz Portfólió részvényeinek eladása Portfólió frissítése, tranzakciók és a portfólió értékének mentése 3.1. ábra A szimuláció lépései 19

20 3.3 A szimuláció motorja A szimuláció motorja Java programozási nyelven íródott, fő feladata a fent említett szimulációs eljárás implementálása, és egy interfész biztosítása a programozó felhasználó számára, hogy új kereskedési stratégiát implementálhasson. Ez a motor nagyban épül a diplomatervezés első féléve során elkészített, csak a felhasználó számítógépén futó backtesting keretrendszerre, felhasználja annak adatszerkezetét, és az ott kipróbált bővítési interfészt alkalmazza a mostani rendszerben is. Az újdonság a mostani rendszer motorjában, hogy nem közvetlenül a felhasználói kezelőfelülethez kapcsolódik, nincs szoros kohézió, hanem önmagában fut majd egy grid rendszer számítási csomópontján. Ebből kifolyólag úgy kellett megírni, hogy minden szükséges bemeneti adatról feltételezhető, hogy lokálisan elérhető, és az eredményt is egy lokális fájlba írja. A szimulációs motort alkotó fontosabb osztályok és a közöttük levő kapcsolatok láthatóak a 3.2 ábrán, az UML osztálydiagramon. 20

21 3.2. ábra A motor osztálydiagramja 21

22 A szimuláció motorjának fejlesztését a belső adatszerkezet definiálásával kezdtem, a rendelkezésre álló adatsorok adataiból kiindulva. Az adatszerkezet az alábbi entitásokból áll: DailyData: Egy részvény napi árfolyamadatát (nyitó-, maximum-, minimumés osztalék-kifizetéssel korrigált záróárfolyamot) tartalmazó entitásosztály. Stock: Egy részvényt reprezentáló entitásosztály, tartalmazza a részvény kódját és a részvény adatsorát, mint DailyData-k dátumindexelt tömbjét. StockData: Egy idősort reprezentáló osztály, tartalmazza az idősor nevét (pl.: S&P 500), az idősor kezdő- és végdátumát,a tartalmazott napok számát és egy név-stock hash-táblát, hogy név alapján gyorsan hozzá lehessen férni a részvény objektumhoz. StockDataFactory: Az idősorok betöltéséhez használt interfész, mely lehetővé teszi, hogy többféle forrásból származó idősorokat egységesen tudjuk memóriába tölteni. CSVStockDataFactory: Implementálja a StockDataFactory interfészt, az számomra rendelkezésre álló, CSV fájlokban található idősorokat olvassa fel, hoz létre StockData objektumot. Parameter: A felhasználó által specifkált, egy elemző algoritmusnak átadott paramétert jelképez. A paraméternek van egy kódja, mely azonosítja funkcióját a rendszerben, egy leírása, mely a felhasználónak szól, egy minimális és egy maximális, lebegőpontos értéke, illetve egy lépésköz két érték között, hogy a paraméter értéktartománya diszkrét legyen. ParamValue: Egy paraméter egy konkrét értékét tartalmazó osztály. Portfolio: Egy befektetői részvényportfóliót reprezentál, mely tartalmazza a birtokolt részvényösszetételt, a rendelkezésre álló készpénzt és a portfólió összértékét. Ez az osztály tartalmazza a részvények adásvételét implementáló metódusokat: o buystock: Az adott napon vesz az adott részvényből a megadott darabszámot, amennyiben van elég készpénz. o sellstock: Elad az adott napon az adott részvényből a megadott darabszámot, készpénzre váltva értéküket. 22

23 o liquidate: Eladja az adott napon az összes birtokolt részvényt, készpénzre váltva értéküket. o addstocks: Eladja az összes birtokolt részvényt, majd a megadott részvényekből vásárol, egyenlő értékben, a teljes rendelkezésre álló készpénzt elhasználva. PortfolioState: A portfólió értékét tárolja egy adott napon, a szimuláció eredményét ezen osztály egy listája adja. Transaction: A Portfolio osztály feljegyzi a kereskedési műveletek során végrehajtott tranzakciókat, egy tranzakció a kereskedés időpontját, kereskedett részvény nevét, a kereskedett mennyiséget és értéket, illetve a kereskedés után a portfólió értékét. Backtest: A felhasználó által megadható stratégia ősosztálya, használata a fejezetben kerül leírásra. Engine: A szimulációs motor belépési pontja, betölti az idősorokat és a felhasználó által megadott stratégiát, létrehozza a számításokat végző szálakat, végül összeállítja az eredményt. EngineThread: A szimuláció számításait végző szál, a Thread osztály leszármazottja. Ezeket az osztályokat használhatja a felhasználó ahhoz, hogy a backtest algoritmusát kifejlessze, a pontos interfészek később kerülnek leírásra. 23

24 A szimulációs motor futás közbeni működése a következő UML szekvencia diagramon látható: 3.3. ábra A szimuláció futása A szimulációs motor belépési pontja az Engine osztály, az elemzést az idősor adatok betöltésével és a felhasználó általadott backtest algoritmusosztály futás közbeni példányosításával kezdi (a createbacktest() függvény argumentuma a létrehozandó osztály class fájlja). Az idősor adatok betöltéséhez a StockDataFactory egy leszármazottját (jelen esetben a CSVStockDataFactory -t) használja. A szimulációs motor a vizsgálandó paramétertér-pontokat egy bemeneti feladatleíró fájlból tölti be, minden pont vizsgálatához egy új futási szálat (EngineThread osztály, amely a Java Thread osztályának leszármazottja) hozva létre. Minden kereskedési napra (a kereskedési periódus hossza paraméterként megadandó, a kezelőfelületen beállítható) az alábbi lépéseket végzi egy létrehozott futási szál: 1. A felhasználó által megadott algoritmustól egy pontszámot kér minden egyes részvényhez, az adott napra. Minél magasabb a pontszám, annál nagyobb valószínűséggel kerül bele a részvény a portfólióba. 24

25 2. A felhasználó által megadott n legmagasabb pontszámú részvényekből egyenlő értékben vesz, az addstocks függvényt meghívva. Mivel a rendszer nem foglalkozik a tranzakció költségeivel, ezért minden kereskedési nap eladja az összes birtokolt részvényt és újakat vásárol helyette. A tranzakciókat egy listában rögzíti Felhasználótól elvárt komponensek A felhasználó feladata a backtest algoritmus kifejlesztése, az általa fejlesztett algoritmusnak a Backtest osztály leszármazottjának kell lennie. Implementálnia kell a score() függvényt, mely paraméterként megkapja az értékelendő részvény nevét, a StockData betöltött idősort, a felhasználó által a felületen beállított paraméterek listáját és a kereskedési napot. A függvény visszatérési értéke a részvényre adott pontszám. Az implementált osztályt a felhasználónak le kell fordítania, és JAR archívumba tömörítve kell a rendszer számára elérhetővé tennie. Egy ilyen, felhasználó által fejlesztett Backtest leszármazott osztályra található példa a 3.2 ábrán, BacktestRandom névvel. Ez a stratégia minden kereskedési napon, minden részvénynek egy véletlenszerűen választott pontszámot ad. Ennél az egyszerű stratégiánál egy megalapozottabb, a diplomamunka fejlesztése során implementált stratégiát írok le a 6. fejezetben. 25

26 4 Alkalmazásfejlesztés grid rendszerekre A diplomamunkám során fejlesztett tőzsdei backtesting keretrendszer különlegessége, hogy egyszerű beállítások elvégzésével a szimulációs számítást egy grid szolgáltatás igénybevételével képes elvégezni. A következőkben leírom, hogy pontosan mit takar a grid szolgáltatás, hogyan képest ezt a szolgáltatást az alkalmazásfejlesztő igénybe venni. A fejezet végén bemutatok egy olyan, a tanszéken fejlesztett keretrendszert, mely nagyban megkönnyíti az alkalmazásfejlesztést különböző grid rendszererekre. 4.1 A grid, mint szolgáltatás A grid szó az angol electrical grid kifejezésből származik, mely elektromos hálózatot jelent. Ennek az oka az, hogy az informatikusok egy általánosan hozzáférhető, nagy rendelkezésre állású számítási infrastruktúrát akartak létrehozni, melyet a felhasználók, hasonlóan az elektromos hálózathoz, közműként tudnak használni számítási feladataik elvégzéséhez. Ez a közmű jellegű használat köszön vissza a utility grid modellben, mely szerint a grid szolgáltatás nyújtásának a feladata kevés számú erre specializált szervezet dolga, melyek 24/7 ezzel foglalkoznak. A modellben a felhasználók száma és a használati célok és területek száma jelentősen meghaladja az erőforrást biztosító szervezetek számát. Napjaink földrészeken átnyúló gridjeit általában több tíz nemzeti szervezet együttműködése hozta létre. Egy ilyen nemzeti szervezet általában egy nagyobb számítógép-hálózatot üzemeltet, sok, a számításokat végző, egységes konfigurációval rendelkező worker node számítógépekkel (számítási csomópontokkal), nagykapacitású háttértár rendszerekkel. Ezeket a szervezeteket nagysebességű kutatói gerinchálózat köti össze (pl. a GEANT). Így egy grid hálózat több ezer számítógép számítási és tárolókapacitását képes egyesíteni, például az idén zárult EGEE projekt [18] végére 150 ezer CPU állt a Grid felhasználóinak rendelkezésére. A földrajzilag elosztott hardver réteget egy, a felhasználók számára egységes rendszert láttató szoftveres köztesréteg fogja össze, mely végrehajtja a felhasználó számítási feladatait, kezeli az erőforrásokat és adminisztrálja a felhasználásukat. 26

27 Ahhoz, hogy a grid, mint infrastruktúra vízió megvalósulhasson, a létrejövő grid szolgáltatásnak az alábbi öt kérdésre [19] kell kielégítő választ találnia: 1. Erőforrás-megosztás: Ahogy az elektromos hálózat felhasználói is osztozkodnak a hálózat kapacitásán, úgy kell a grid felhasználói között is megosztani a grid erőforrásait. Az erőforrások rugalmas kezeléséhez szükséges, hogy a felhasználók számára fizikailag különböző helyeken levő, eltérő hardverkonfigurációjú erőforrások egységesen jelenjenek meg. Az igazságos használat érdekében biztosítani kell, hogy minden felhasználó csak a szükséges mennyiségű erőforrást foglalhassa le. Az azonos céllal, hasonló igényekkel rendelkező felhasználók virtuális szervezeteket (VO-kat) alkotnak. A VO-k erőforrás kezelési szolgáltatásokat biztosítanak, a szervezet tagjai használhatják a VO által rendelkezésre bocsátott erőforrásokat. A magyar kutatók és hallgatók az EGEE-ben a Hungrid VO alá tartoznak,, de egy felhasználó több VO tagja is lehet. 2. Biztonságos hozzáférés: Mivel a grid egy globális, szorosan integrált hálózat, több ezer felhasználóval, egy vírus vagy egy rosszindulatú felhasználó hatalmas károkat okozhat a rendszerben, tönkretehet erőforrásokat és mások munkáit. Ezért egy átgondolt biztonságpolitika létrehozása és alkalmazása elengedhetetlen a grid biztonságos üzemeltetéséhez. A gridek biztonságpolitikája tanúsítvány alapú, a felhasználónak egy X.509-es szabványnak megfelelő, akármilyen elfogadott CA (Certificate Authority) által a felhasználó számára kiállított, korlátozott érvényességi idejű tanúsítvánnyal kell rendelkeznie ahhoz, hogy a VO szolgáltatásait használhassa. A tanúsítványok alkalmazásával lehetséges a felhasználók engedélyezése (authorisation), mely eldönti, hogy mely felhasználók férhetnek hozzá a rendszerhez, és a hitelesítés (authentication), mely egyértelműen és letagadhatatlanul azonosítja be a felhasználót. 3. Erőforrás-használat: Mint ahogy az áramszolgáltató díjat számláz a fogyasztónak a szolgáltatásaiért, a grid is számláz a szolgáltatás használatáért a felhasználóknak. Ez kereskedelmi gridek esetén ténylegesen fizetendő számla lehet, kutatási hálózatok esetében általában egyezmények rögzítik az engedélyezett használat mértékét. 27

28 4. A távolság átka: Mivel a gridben az egyes alhálózatokat akár óceánok választhatják el egymástól, és mivel a felhasználó számításai a gridben bármely számítási csomóponton futhatnak, ezért olyan esetekben előnyös gridet alkalmazni, amikor az elosztott számítás nyeresége meghaladja a az adat eljuttatásához szükséges időveszteséget. Ez a szállítási idő a grid alhálózatait összekötő nagysebességű kutatói gerinchálózatoknak köszönhetően egyre inkább elhanyagolható lesz az feladatütemezés miatti sorbanállási időhöz és a végrehajtási időhöz viszonyítva. 5. Nyitott szabványok: A nemzeti és nemzetközi hálózatok gridbe egyesítéséhez egységes és nyitott szabványok szükségesek, hogy képesek legyenek egymás erőforrásainak megismerésére és használatára. Az egységes és szabványos köztesréteg-szoftverek a gridek felhasználói számára és alkalmazásfejlesztői számára is lehetővé teszik, hogy a globálisan szétterülő hardvert elfedve, egy nagy és több erőforrást tartalmazó szolgáltatást használhassanak. Napjaink legelterjedtebb grid köztesrétege a Globus [20], mely megvalósítja az Open Grid Forum [21] szervezet által kidolgozott Open Grid Services Architecture [22] rendszerintegrációs szabványt. 4.2 Alkalmazások gridesítése A következőkben megmutatom, hogy milyen főbb lépéseket kell a fejlesztőnek elvégeznie, hogy alkalmazása egy grid szolgáltatásait vehesse igénybe. A példát az EGEE Griden [18] mutatom be, mely az európai, nemzeti, akadémiai grideket egyesítve egy pán-európai, tudományos célokra használható gridet hozott létre. Dolgozatomban Grid néven az EGEE Grid-et fogom ezentúl érteni. Jelenleg a projekt folytatásában, a European Grid Infrastructure-ban [23] vesznek részt magyar grid hálózatok (a KFKI- RMKI, a SZTAKI, a BME és az ELTE hálózata), de ennek a nemzetközi gridnek eleme a CERN LHC kísérlete is. A diplomamunkám fejlesztése során is ezt a grid hálózatot vettem igénybe, specifikusan a magyar VO szervezet, a Hungrid [24] szolgáltatásait Az EGEE Grid biztonsága Minden, a Gridet használó felhasználónak és fejlesztőnek ismernie kell a Grid biztonsági mechanizmusait, mivel ezek mindig jelen vannak a használat során. A Grid 28

29 tervezői nagy hangsúlyt fektettek a rendszer biztonságára, mert illetéktelen felhasználók hatalmas károkat okozhatnak a rendszerben, a projekt bukását jelenthetik. Az EGEE Grid az AAA szolgáltatásokat (authorization, authentication, accounting) egy, a nyilvános kulcsú titkosításon alapuló tanúsítványrendszerrel biztosítja. A rendszer központi elemei a Certificate Authority-k (CA-k), a tanúsító hatóságok, melyeket mindenki hitelesnek ismer el, és minden, általuk tanúsított felhasználó jogosan használja a rendszert. A tanúsítványok olyan fájlok, melyek egyértelműen és hitelesen beazonosítják a tulajdonost, és a hitelességet szavatoló CA-t, amely kiállította a tanúsítványt. Ez a gyakorlatban annyit jelent, hogy egy felhasználói tanúsítvány áll a felhasználó adataiból, publikus kulcsából és a CA digitális aláírásából, ahogy ezt a 4.2. ábra mutatja. Bárki, aki rendelkezik a tanúsítvánnyal, el tud járni a felhasználó nevében. Felmerül a kérdés, hogyan tud például a Grid erőforrás brókere a felhasználó nevében eljárni úgy, hogy ne legyen szükség az autentikációhoz a felhasználó privát kulcsának ismeretére, mivel azt a felhasználó nem szeretné megosztani. A grid felhasználója létrehozhat egy ún. proxy-t, amely egy speciális, rövid ideig érvényes tanúsítvány és egy privát kulcs pár, a tanúsítvány tartalmazza a proxy publikus kulcsát. A proxy tanúsítványát a felhasználó írja alá saját privát kulcsával, így a proxy a felhasználó jogosultságaival rendelkezhet. A proxy arra jó, hogy segítségével a felhasználó nevében korlátozottan járhatnak el a szolgáltatások, úgy, hogy a felhasználó kulcsát nem kell odaadni, mégis ellenőrizhető a proxy tanúsítvány hitelessége a kiállító láncot ellenőrizve: A proxy titkos kulcsával aláírtakat a proxy nyilvános kulcsával lehet ellenőrizni, a proxy nyilvános kulcsát tartalmazó tanúsítványt a felhasználó nyilvános kulcsával, amelyet pedig a hitelesnek tekintett CA nyilvános kulcsával. Ez lánc a gyakorlatban ennél hosszabb is lehet, a proxy-k újabb proxy-kat hozhatnak létre, ez látható a 4.1. ábrán ábra Tanúsítványlánc Forrás: [32] 29

30 4.2. ábra X.509 tanúsítvány A Grides alkalmazásfejlesztés során nem csak a Griden való futtatás miatti technikai változtatásokra kell figyelni, hanem már a fejlesztés kezdetétől fogva figyelmbe kell venni a Grid használatának sajátosságait. Akkor célszerű egy alkalmazást felkészíteni Grid használatára, ha a végzett számítások valamilyen módon (paramétertér-felosztással, funkciók szerinti felosztással, pipeline szervezéssel) jól párhuzamosíthatóak, így kihasználható több CPU kapacitása is, és kevés kommunikáció szükséges a párhuzamosan futó szálak (grides feladatok) között. Nem érdemes viszont olyan alkalmazást Griden futtatni, mely garantált válaszidőt követel meg, mivel a Grid feladatütemezése, biztonsági funkciói és adatmozgatási szolgáltatásai mind meghatározhatatlan késleltetést okoznak a beküldött számítási feladat futásában. A Gridet használni kívánó alkalmazásnak a számításait egy Grides feladat (job) formájában kell beküldenie a Grid feladatütemezőjének. Ehhez a Grid felhasználói felületét, a Grid UI-t (Grid User Interface) használhatja, amely jellemzően egy, az Internetről elérhető szerver, melyhez a VO biztosít hozzáférést a felhasználó számára. A feladatbeküldés és az eredmény megszerzésének a folyamata a következőképpen zajlik [26]: 30

31 2. A tanúsító hatóságtól (CA-tól) kapott tanúsítványa segítségével egy 12 óráig érvényes ideiglenes tanúsítványt hoz létre, mellyel a nevében eljárhatnak a különböző szolgáltató ágensek. Virtual Organization Membership Service (VOMS), a Grid 8. A felhasználó felhasználóit azonosítja és programja letölti kezeli az IS-ről a feladat eredményét. 1. A felhasználó bejelentkezik a Grid UI szszámítógépre. 5. A felhasználó 3. A felhasználó létrehoz egy új alkalmazása létrehozza bejegyzést a a beküldendő feladatot, logikai fájl egy feladatleíró fájlban katalógusban megadja az (LFC) a argumentumait és a benagyméretű és kimeneti fájlokat, bemeneti fájlnak, majd az ideiglenes majd feltölti a tanúsítványával magát tárolóba (Storage azonosítva beküldi az Element, SE) a erőforrás brókernek. fájlt. Erőforrás bróker Információs szolgáltatás (IS) 4. A bróker lekérdezi az információs szolgáltatást (IS), hogy milyen a feladat igényeinek megfelelő szabad erőforrások vannak. 6. A bróker elküldi a feladatot a számítást végző egységre (Computing Element, CE). 8. Az eredményt regisztrálja az IS-nél. Computing Element (CE) 7. A feladat letölti az SEről a nagy bemeneti Storage (SE) Element fájlt. 4.3 ábra: Feladatkezelés az EGEE Gridben. 31

32 A feladatbeküldés folyamata, mint ahogy az ábrán is látszik, egy több lépéses, többszereplős, hosszú folyamat, ezt kell a felhasználónak automatizálnia, ha gridet használó programot fejleszt. Szerencsére megismertem a Saleve keretrendszert, mely támogatást ad a grides feladatkezelésben a fejlesztőnek, nekem nem kellett foglalkoznom azzal, hogy a számítások elvégzése tulajdonképpen hol történik. Azonban a nagyméretű adatok kezelésével a Saleve eredetileg nem foglalkozik, így továbbra is maradnak grides feladatok. 4.3 A Saleve keretrendszer A Saleve nyílt forráskódú keretrendszert [27] a BME Irányítástechnikai és Informatikai Tanszékén fejlesztették, abból a célból, hogy megkönnyítse az alkalmazásfejlesztők feladatát, amennyiben nagy teljesítményű számítási szolgáltatást akarnak felhasználni. A keretrendszert úgy tervezték, hogy elfedje a fejlesztők elől a számítást végző infrastruktúrát, a fejlesztőnek mindössze a számítások részekre bontása és a számítás implementálása a feladata, nem kell törődnie a grides feladatkezeléssel, biztonságpolitikával, elég csak egy tanúsítványt beszereznie és a keretrendszernek rendelkezésére bocsátania. A Saleve keretrendszert a leggyakrabban alkalmazott párhuzamosítási technika, a parameter study (paraméterelemzés) támogatására készítették fel, a felhasználónak a számításainak paraméterterét fel kell darabolnia, az így kapott egyes paraméterhalmazokkal végzendő számításokból hoz létre grid feladatot a keretrendszer. A Saleve keretrendszer egy kliens-szerver architektúrát használ, a kliens feladata a paramétertér felosztása és az elvégzendő számítás definiálása: 4.4 ábra A paramétertér feldarabolása. Forrás: [28] 32

33 A szerver feladata pedig a számítások elvégzése az adott paraméterhalmazzal a rendelkezésre álló infrastruktúrán: 4.5 ábra A szerver végrehajtja a feladatot. Forrás: [28] Az elvégzett feladatok eredményét a szerver összegyűjti, és elküldi a kliensnek: egyesíti őket: 4.6 ábra A szerver összegyűjti a feladatok eredményét. Forrás: [28] Végül a kliens összegyűjti a szerver által visszaküldött részeredményeket és 4.7 ábra A kliens összeállítja a végső eredményt a részeredményekből. [28] A Saleve rendszer jelentős előnye még, hogy többféle számítási infrastruktúrát használhat (glite, Condor vagy SZTAKI Desktop Grid), az egyes infrastruktúrák sajátosságait becsatlakozó modulok kezelik, így a keretrendszert újabb infrastruktúrák kezelésére is fel lehet készíteni, illetve a felhasználó alkalmazása könnyen átalakítható egy másik infrastruktúra használatára. Amennyiben nem áll rendelkezésre egyetlen grid infrastruktúra sem, a kliens komponens képes a feladatok lokális gépen, több szálon való futtatására, ekkor a szerver komponensre nincs szükség. A diplomamunkám elkészítése során a glite becsatlakozót használtam, hogy feladataimat az EGEE-n tudjam futtatni. 33

34 4.3.1 Fejlesztés a Saleve keretrendszer használatával Alkalmazásfejlesztői szemszögből a keretrendszer használata a keretrendszer telepítése után rendkívül egyszerű. A keretrendszer C++-ban íródott, egyelőre csak C++ alkalmazásokat lehet fejleszteni a segítségével, de már készül Java-s interfész is. A fejlesztőnek egy olyan C++ forrásfájlt kell mindössze létrehoznia, amely az alábbi elemeket tartalmazza: 1. Hivatkozást a saleve.h forrásra. 2. Egy void saleve_span() függvényt, mely a fejlesztő elképzelésének megfelelően felbontja a paraméterteret paraméterhalmazokra. A függvény törzsében végig kell iterálni a paraméterhalmazokon, átadva egy-egy halmaz elemeit egy-egy saleve_addinstance() hívásnak egy konstans string formájában. A saleve_addinstance() létrehoz egy számítási szálat, mely majd elvégzi a felhasználó számításait a bemeneti argumentumban kapott paraméterhalmazon. Bemeneti fájlokat, melyeket minden számítási példány megkap (a végrehajtás helyén lokálisan elérhető lesz minden példány számára), a saleve_addinputfile() függvénnyel lehet megadni. Hasonlóképpen kimeneti fájlokat, melyek a futás végén a kliensre másolódnak vissza, a saleve_addoutputfile()függvényhívással lehet meghatározni. 3. Egy int saleve_main(int argc, char** argv)függvényt, mely hasonlóan a C/C++-os névrokonához, a program érdemi részét, a számítást tartalmazza. Az argv argumentumban megkapja a saleve_addinstance() argumentumait, a számítás paraméterhalmazát. 4. Egy void saleve_sum()függvényt, mely a szervertől visszakapott részeredményeket összegzi. Érdemes megjegyezni, hogy bár ezek a függvények egy forrásfájlban lehetnek, a saleve_span() és a saleve_sum() a kliens számítógépen fut, a saleve_main() pedig grides háttér esetén a CE egyik worker node-ján. Ezért fejlesztéskor ügyelni kell arra, hogy nem lehet globális változók használatával 34

35 kommunikálni a függvények között, azt csak az említett paraméterátadások alkalmazásával lehet. A forrásfájlt a keretrendszer által biztosított salevecc fordító scripttel kell lefordítani. A keletkező futtatható fájl egyben a Saleve kliens és tartalmazza a számítást is. A kliens elküldi a létrehozott számítási szálak részleteit, az adatokat, és önmagát a szervernek A Saleve keretrendszer továbbfejlesztése A diplomamunkám során elkészített backtesting keretrendszer használatához historikus részvényárfolyam idősorokra volt szükségem, ezek CSV fájlok formájában voltak elérhetőek. Egy három éves időtartam árfolyamértékei egy részvényre kb. 30 KByte-os fájlt jelentett, az S&P 500 index részvényeinek idősorai tehát kb. 15 MByte méretű állományhalmazt alkottak, ez még tömörítve is több, mint 5 MByte. Amennyiben ennél is hosszabb időintervallumra, még több részvénnyel szeretnék szimulációt végezni, az idősorok mérete 100 MByte-os nagyságrendű is lehet akár. A backtesting keretrendszer ezeket a CSV fájlokat egy ZIP fájlba tömörítve kezeli, ezt a ZIP fájlt juttatom el a szimulációs számításokat végző grid gépekre a Saleve keretrendszer saleve_addinputfile() függvénye segítségével. Ez egy 20 MByte-nál nagyobb ZIP fájl esetén, a glite infrastruktúra használata esetében problémát okoz, emiatt fejlesztéseket kellett, hogy végezzek a keretrendszeren, amely nem volt felkészítve nagy fájlok fogadására. A probléma okának megértéséhez azonban jobban meg kell ismerni a Saleve működését. Amikor saleve_addinstance() hívással létrehozunk egy új számítási példányt, akkor a keretrendszer glite modulja egy grides feladatot (job-ot) hoz létre a lefordított program futtatásakor. Ahogy az a 4.2 ábra 3. lépésében le van írva, a job beküldésekor egy feladatleírót kell készíteni, mely, mint ahogy az a 4.7 ábrán látható, tartalmazza a worker node-on végrehajtandó bináris fájl nevét (Executable), a parancssori argumentumait (Arguments), a be- és kimeneteli fájlokat (InputSandbox, OutputSandbox), valamint a feladat futtatásához szükséges erőforrás követelményeket (Requirements). Ezt a feladatleírót a Saleve glite modulja állítja elő automatikusan. 35

36 [ Rank = -other.gluecestateestimatedresponsetime; AllowZippedISB = true; VirtualOrganisation = "hungrid"; glitemyproxyserver = "grid153.kfki.hu"; Executable = "wrapper.sh"; InputSandbox = { "/home/vakond1/opt_largefile/saleve/var/saleve/2/thesis", "/home/vakond1/opt_largefile/saleve/var/saleve/2/arguments.txt", "/home/vakond1/opt_largefile/saleve/share/saleve/wrapper.sh", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_0.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_1.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_2.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_3.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_4.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_5.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_6.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_7.zip", "/home/vakond1/opt_largefile/saleve/var/saleve/2/job1_8.zip" }; Requirements = other.gluehostoperatingsystemrelease >= 5.0; JobType = "Parametric"; Parameters = 10; ParameterStart = 1; ParameterStep = 1; Arguments = "\"thesis\" arguments.txt _PARAM_ saleve_outputsandbox_param_.tar.gz \"job1_0out.zip\" \"job1_1out.zip\" \"job1_2out.zip\" \"job1_3out.zip\" \"job1_4out.zip\" \"job1_5out.zip\" \"job1_6out.zip\" \"job1_7out.zip\" \"job1_8out.zip\""; OutputSandbox = { "stdout.thesis._param_", "stderr.thesis._param_", "saleve_outputsandbox_param_.tar.gz", "saleve.log._param_"}; ] 4.8 ábra Feladatleíró Ez a feladatleíró, ahogy a 4.7 ábrán is látható (a _PARAM_ karaktersorozatok miatt), parametrikus, azaz az összes, a Saleve szerver által létrehozott futási szál (grid job) ezt a feladatleírót kapja, de majd futás közben helyettesítődik be a _PARAM_ helyére a job sorszáma. A glite modul a futás környezetének beállítása után (a feladatleíró JDL fájl első 4 sora a 4.7 ábrán) a végrehajtandó parancsnak nem a felhasználó által lefordított Saleve klienst adja meg, hanem egy burkoló shell script-et (wrapper.sh), mely elvégzi az egyes feladatok felparaméterezését a sorszám szerint (a glite helyettesíti be a _PARAM_-ot). Az InputSandbox-ba a modul megadja a Saleve kliens nevét és egy, a modul által létrehozott, a saleve_addinstance()-nak átadott argumentumokat tartalmazó, arguments.txt nevű listát, a burkoló wrapper.sh scriptet, majd végül felsorolja a saleve_addinputfile()-hívásokkal megadott bemeneti fájlokat, melyek egy-egy grid feladat (job) bemenetei lesznek. Mivel a 36

37 saleve_addinputfile() mindegyik futási szálnak eljuttatja a bemeneti paramétert, ezért a paraméteres feladatleíróban mindegyik feladat bemeneti állományai szerepelni fognak. Az Arguments sorban átadódik a wrapper.sh-nak az argumentumokat tartalmazó lista, a job sorszámát tartalmazó paraméter és az OutputSandbox elemei nek archívuma, illetve a saleve_addoutputfile()-al megadott kimeneti fájlok nevei. Végül az OutputSandbox-ba írja a rendszer a fájlba írt standard output és error fájl neveit, a kimeneti fájlokat tömörítő archívum nevét és a Saleve kliens által megadott kimeneti fájlok neveit. A probléma abból adódik, hogy az általam fejlesztett backtesting rendszernél a Saleve eddigi működése szerint az idősorokat tartalmazó ZIP fájl is az InputSandbox listába kerül, viszont a bemeneti és kimeneti fájlok mérete limitálva van 10 MByte-ra [29]. A problémát úgy oldottam fel, hogy mikor glite/serviceadapter_glite.cpp forrásfájlban a rendszer végigiterál a kapott bemeneti fájlokon, hogy hozzáadja őket az InputSandbox-hoz, akkor ellenőrzöm, hogy nagyobb-e az input fájl, mint 1 MByte. Ha igen, akkor egy system() C++ függvényhívással (mely végrehajta az argumentumában megadott rendszerhívást) meghívom a glite köztesréteg lcg-cr rendszerparancsát. Az lcg-cr parancssori utasítás egy megadott fájlt feltölt az argumentumban megadott grides társzolgáltatásra (Storage Element-re), és visszaadja a fájl globálisan egyedi azonosítóját, mely alapján később visszamásolható az SE-ről a fájl. Ezt a globálisan egyedi azonosítót (guid-et) beleírom a feladatleíróba, a DataRequirements blokkba [30], egy új InputData sorba, például: DataRequirements = { [ InputData= {"guid:437b7b23-4a6a-11d7-87e7-9c101f8c8b70"}; DataCatalogType = "DLI"; DataCatalog = "http://lfc.hpc.iit.bme.hu"; ] }; 4.9 ábra DataRequirements blokk Az így megadott InputData fájlokat a glite köztesréteg a feladat végrehajtása előtt automatikusan letölti a worker node-ra a SE-ből. A kimeneti fájlokkal nincs ilyen probléma, mivel a szimuláció eredménye (a portfólió értékének idősora) 37

38 nagyságrendekkel kisebb, mint a bemenet, azokat vissza lehet juttatni a Saleve szervernek az OutputSandbox-ban utaztatva, majd onnan visszaküldésre kerül a klienshez a Saleve saját szállítási mechanizmusaival. A Saleve keretrendszer glite modulján elvégzett fejlesztésem után így néz ki a modul által, a kliens által beküldött feladat feldolgozása során létrehozott parametrikus JDL feladatleíró: [ Rank = -other.gluecestateestimatedresponsetime; AllowZippedISB = true; VirtualOrganisation = "hungrid"; glitemyproxyserver = "grid153.kfki.hu"; Executable = "wrapper.sh"; InputSandbox = { "/home/vakond1/opt_largefile/saleve/var/saleve/2/thesis", "/home/vakond1/opt_largefile/saleve/var/saleve/2/arguments.txt", "/home/vakond1/opt_largefile/saleve/share/saleve/wrapper.sh"}; Requirements = other.gluehostoperatingsystemrelease >= 5.0; JobType = "Parametric"; Parameters = 10; ParameterStart = 1; ParameterStep = 1; Arguments = "\"thesis\" arguments.txt _PARAM_ saleve_outputsandbox_param_.tar.gz \"job1_0out.zip\" \"job1_1out.zip\" \"job1_2out.zip\" \"job1_3out.zip\" \"job1_4out.zip\" \"job1_5out.zip\" \"job1_6out.zip\" \"job1_7out.zip\" \"job1_8out.zip\""; OutputSandbox = { "stdout.thesis._param_", "stderr.thesis._param_", "saleve_outputsandbox_param_.tar.gz", "saleve.log._param_"}; DataRequirements = {[ InputData = "guid:b14a5bad-dc2f-c356-c ", "guid:8c8c503e-c42e-8f7a-32d953be", "guid:3e3edcc5-d e1a", "guid:2258bada-de50-d826-7ea66414", "guid:4cf13b76-5da4-5c54-f4496bc1", "guid:6667a0d5-b9da-f102-c40c1d58", "guid:8384b991-b9e0-a1de-b19789e1", "guid:11a b4a-80f6-42a95bca", "guid:d7767cbc-9829-e50f-48d414ac"}; DataCatalogType = "DLI"; DataCatalog = "http://lfc.hpc.iit.bme.hu"; ]}; ] 4.10 ábra Módosított feladatleíró A legfontosabb megfigyelhető különbség, hogy a bemeneti fájlok (mivel jelen esetben az archívumok tartalmazzák a nagyméretű idősorokat is) nem az InputSandbox-ba kerültek, hanem egy külön DataRequirements blokk jött létre, ahová a nagyméretű fájlok kerülnek. 38

39 5. Rendszerintegráció A diplomatervezés első félévében elkészítettem a tőzsdei kereskedési stratégia szimulációs keretrendszer első, csak a felhasználó számítógépén futó változatát. A második félév kitűzött célja, hogy a szimulációs számításokat ne a felhasználó számítógépe, hanem egy grid infrastruktúra végezze, azt jelentette, hogy az első félév során megírt szimulációs motortnak a grid egy távoli, ismeretlen worker node-ján kell futnia. A 3.1 Célkitűzések c. fejezetben leírtak szerint ezt a váltás úgy kellett végrehajtani, hogy a felhasználó továbbra is könnyen, a megszokott kezelőfelülettel tudja használni a rendszert, a saját stratégia fejlesztésénél ne kelljen tekintettel lennie a szimulációt végrehajtó infrastruktúrára. A diplomamunkám során fejlesztendő rendszernek tehát adottak voltak a követelmények külvilággal érintkező interfészek számára, a felhasználó oldaláról a kezelőfelület formájában, a rendszer oldaláról pedig a szimulációs motor ki- és bemeneteinek formájában. A kihívást az jelentette, hogy hogyan jut el a felhasználó által a saját számítógépén futó kezelőfelületen megadott stratégia, idősor és vizsgálandó paramétertér a szimulációs motorhoz a grid rendszer számítási csomópontjaiban, illetve az, hogy a számítás eredménye hogyan kerül vissza a felhasználóhoz és végül hogyan kerül kiértékelésre a felhasználó igényeinek megfelelően. Meg kellett azt is határozni, hogyan bontja fel a rendszer a felhasználó által megadott paramétertér vizsgálatát részfeladatokra, hogy lesz ezekből a feladatokból griden futó feladat, hogy ezek a feladatok milyen be- és kimenettel rendelkeznek. A grides háttér elfedésére a 4.3 pontban már ismertettem egy alkalmas eszközt, a Saleve keretrendszert, a diplomamunkám során ezt a keretrendszert használva építettem fel az általam fejlesztett backtesting keretrendszert. A Saleve keretrendszer alkalmazható volt a felhasználó számítógépe és a grid közötti információszállításra, de ezen felül ki kellett dolgozni, hogyan lehet egy szimulációs motor futtatást Saleve feladatba csomagolni, azaz áttételesen hogyan lehet egy grides job-ot definiálni a szimulációs motor futtatásához. A Saleve keretrendszer szerepét az általam fejlesztett rendszerben a következő ábra mutatja be, mely áttekintő képet ad a backtesting keretrendszer felépítéséről: 39

40 5.1. ábra Rendszerterv 40

alkalmazásfejlesztő környezete

alkalmazásfejlesztő környezete A HunGrid infrastruktúra és alkalmazásfejlesztő környezete Gergely Sipos sipos@sztaki.hu MTA SZTAKI Hungarian Academy of Sciences www.lpds.sztaki.hu www.eu-egee.org egee EGEE-II INFSO-RI-031688 Tartalom

Részletesebben

Diplomatervezés 1 (BMEVIIIM914)

Diplomatervezés 1 (BMEVIIIM914) Diplomatervezés 1 (BMEVIIIM914) T zsdei stratégiák teszteléséhez való grides keretrendszer fejlesztés Sali Dániel Attila M0EPW3 Mérnök Informatikus MSc. II.évf. vakond1@gmail.com Konzulens: Kápolnai Richárd

Részletesebben

Titkosítás NetWare környezetben

Titkosítás NetWare környezetben 1 Nyílt kulcsú titkosítás titkos nyilvános nyilvános titkos kulcs kulcs kulcs kulcs Nyilvános, bárki által hozzáférhető csatorna Nyílt szöveg C k (m) Titkosított szöveg Titkosított szöveg D k (M) Nyílt

Részletesebben

HunGrid Grid technológiák hozzáférési lehetőségei az intézetben

HunGrid Grid technológiák hozzáférési lehetőségei az intézetben HunGrid Grid technológiák hozzáférési lehetőségei az intézetben Kővári Kálmán Számítógép Hálózati Központ (SZHK) Részecske és Magfizikai Kutató Intézet, Budapest Simonyi-nap 2007. október 18. Budapest

Részletesebben

Projekt beszámoló. NEWSIT News basedearlywarning System forintradaytrading: Hír alapú Korai Figyelmeztető Rendszer Napon belüli Kereskedéshez

Projekt beszámoló. NEWSIT News basedearlywarning System forintradaytrading: Hír alapú Korai Figyelmeztető Rendszer Napon belüli Kereskedéshez Projekt beszámoló Projekt azonosítója: Projektgazda neve: Projekt címe: DAOP-1.3.1-12-2012-0080 Pénzügyi Innovációs Iroda Kft. NEWSIT News basedearlywarning System forintradaytrading: Hír alapú Korai Figyelmeztető

Részletesebben

Vezetői információs rendszerek

Vezetői információs rendszerek Vezetői információs rendszerek Kiadott anyag: Vállalat és információk Elekes Edit, 2015. E-mail: elekes.edit@eng.unideb.hu Anyagok: eng.unideb.hu/userdir/vezetoi_inf_rd 1 A vállalat, mint információs rendszer

Részletesebben

BetBulls Opciós Portfolió Manager

BetBulls Opciós Portfolió Manager BetBulls Opciós Portfolió Manager Ennek a modulnak a célja, hogy ügyfeleinknek lehetőséget biztosítson virtuális számlanyitásra és részvény, valamint opciós pozíciók vásárlására, eladására a naponta frissülő,

Részletesebben

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese

Részletesebben

TELJESÍTÉNYMÉRÉS FELHŐ ALAPÚ KÖRNYEZETBEN AZURE CLOUD ANALÍZIS

TELJESÍTÉNYMÉRÉS FELHŐ ALAPÚ KÖRNYEZETBEN AZURE CLOUD ANALÍZIS TELJESÍTÉNYMÉRÉS FELHŐ ALAPÚ KÖRNYEZETBEN AZURE CLOUD ANALÍZIS Hartung István BME Irányítástechnika és Informatika Tanszék TEMATIKA Cloud definíció, típusok, megvalósítási modellek Rövid Azure cloud bemutatás

Részletesebben

Gyakorlati tudnivalók

Gyakorlati tudnivalók Gyakorlati tudnivalók grid tanúsítványok megszerzéséről é ő és a Magyarországról használható EGEE típusú gridek (HunGrid, VOCE, SEEGRID, GILDA) eléréséről MTA SZTAKI Laboratory of Parallel and Distributed

Részletesebben

ÜGYFÉL OLDALI BEÁLLÍTÁSOK KÉZIKÖNYVE

ÜGYFÉL OLDALI BEÁLLÍTÁSOK KÉZIKÖNYVE ÜGYFÉL OLDALI BEÁLLÍTÁSOK KÉZIKÖNYVE Felhasználói leírás E-HATÁROZAT 2012 - verzió 1.2 Érvényes: 2012. május 24-től. Azonosító: ehatarozat_ugyfél_ beallitasok_kezikonyv_felh_v1.2_20120524_tol 1/15 1 Tartalom

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

Részletesebben

IP alapú távközlés. Virtuális magánhálózatok (VPN)

IP alapú távközlés. Virtuális magánhálózatok (VPN) IP alapú távközlés Virtuális magánhálózatok (VPN) Jellemzők Virtual Private Network VPN Publikus hálózatokon is használható Több telephelyes cégek hálózatai biztonságosan összeköthetők Olcsóbb megoldás,

Részletesebben

TŐZSDEJÁTÉK FELHASZNÁLÓI KÉZIKÖNYV

TŐZSDEJÁTÉK FELHASZNÁLÓI KÉZIKÖNYV TŐZSDEJÁTÉK FELHASZNÁLÓI KÉZIKÖNYV BEVEZETŐ A Tőzsdejáték az Magyar Nemzeti Bank (MNB) és a Budapesti Értéktőzsde (BÉT) által közösen működtetett a tőzsdei kereskedést egyszerűsített körülmények közt bemutató,

Részletesebben

Iman 3.0 szoftverdokumentáció

Iman 3.0 szoftverdokumentáció Melléklet: Az iman3 program előzetes leírása. Iman 3.0 szoftverdokumentáció Tartalomjegyzék 1. Az Iman rendszer...2 1.1. Modulok...2 1.2. Modulok részletes leírása...2 1.2.1. Iman.exe...2 1.2.2. Interpreter.dll...3

Részletesebben

Széchenyi Kereskedelmi Bank Zrt. 1

Széchenyi Kereskedelmi Bank Zrt. 1 Széchenyi Kereskedelmi Bank Zrt. 1 Bemutatkozás Burány Gábor 2014-től SZÉCHENYI Kereskedelmi Bank Zrt. Befektetési Szolgáltatások, vezető üzletkötő 2008-2013 Strategon Értékpapír Zrt. üzletkötő, határidős

Részletesebben

Worldwide LHC Computing Grid

Worldwide LHC Computing Grid Worldwide LHC Computing Grid Új modell a tudományos informatikában Hernáth Szabolcs hernath@mail.kfki.hu MTA KFKI RMKI www.eu-egee.org Tartalomjegyzék 1. Miért Grid? LHC adattárolás és -feldolgozás Computing

Részletesebben

Szerelőműhely nyilvántartás Rendszerterv

Szerelőműhely nyilvántartás Rendszerterv Szerelőműhely nyilvántartás Rendszerterv Készítette: Ballagi Pordány Dániel Árpád EHA: BAQSAAI.ELTE E-mail: dballagi@yahoo.com 1. oldal Tartalomjegyzék A szoftver...3 Funkciók:...3 Projekt költségei, időbeosztása...4

Részletesebben

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények 1. sz. melléklet MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS A) Műszaki követelmények A körkereső szoftvernek (a továbbiakban Szoftver) az alábbi követelményeknek kell megfelelnie

Részletesebben

A technikai elemzések értelmezése

A technikai elemzések értelmezése A technikai elemzések értelmezése A technikai elemzések értelmezése 1. Technikai Elemzés (Technical Analysis) 6. Gyakorlat Technikai elemzés értelmezése Mi az a technikai elemzés (TA)? A piaci mozgásokat

Részletesebben

"A tízezer mérföldes utazás is egyetlen lépéssel kezdődik."

A tízezer mérföldes utazás is egyetlen lépéssel kezdődik. "A tízezert mérföldes utazás is egyetlen lépéssel kezdődik dik." A BINB INSYS Előadók: Kornafeld Ádám SYS PROJEKT Ádám MTA SZTAKI kadam@sztaki.hu Kovács Attila ELTE IK attila@compalg.inf.elte.hu Társszerzők:

Részletesebben

TERC V.I.P. hardverkulcs regisztráció

TERC V.I.P. hardverkulcs regisztráció TERC V.I.P. hardverkulcs regisztráció 2014. második félévétől kezdődően a TERC V.I.P. költségvetés-készítő program hardverkulcsát regisztrálniuk kell a felhasználóknak azon a számítógépen, melyeken futtatni

Részletesebben

Fiáth Attila Nagy Balázs Tóth Péter Dóczi Szilvia Dinya Mariann

Fiáth Attila Nagy Balázs Tóth Péter Dóczi Szilvia Dinya Mariann Fiáth Attila Nagy Balázs Tóth Péter Dóczi Szilvia Dinya Mariann Egységes kockázatkezelési módszertan kialakítása a villamosenergia-ipari átviteli rendszerirányító társaságnál A felelős vállalatirányítás

Részletesebben

Verifikáció és validáció Általános bevezető

Verifikáció és validáció Általános bevezető Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának

Részletesebben

Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt

Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt segédlet A Szilipet programok az adatok tárolásához Firebird adatbázis szervert használnak. Hálózatos

Részletesebben

P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához. Rendszerterv. Sipos Gergely sipos@sztaki.

P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához. Rendszerterv. Sipos Gergely sipos@sztaki. P-GRADE fejlesztőkörnyezet és Jini alapú GRID integrálása PVM programok végrehajtásához Rendszerterv Sipos Gergely sipos@sztaki.hu Lovas Róbert rlovas@sztaki.hu MTA SZTAKI, 2003 Tartalomjegyzék 1. Bevezetés...

Részletesebben

Segesdi Dániel. OpenNebula. Virtualizációs technológiák és alkalmazásaik BMEVIMIAV89. 2011 ősz

Segesdi Dániel. OpenNebula. Virtualizációs technológiák és alkalmazásaik BMEVIMIAV89. 2011 ősz Segesdi Dániel OpenNebula Virtualizációs technológiák és alkalmazásaik BMEVIMIAV89 2011 ősz OpenNebula Előszó A feladatom az OpenNebula nyílt forráskódú cloud management eszköz megismerése, mely egységes

Részletesebben

2012.06.01.-2012.08.02.

2012.06.01.-2012.08.02. A NÖVEKEDÉSI ESZKÖZALAPOK TELJESÍTMÉNYE A PANNÓNIA NAVIGÁTOR SZOLGÁLTATÁS ÁLTAL HASZNÁLT PARAMÉTEREK TÜKRÉBEN 202.06.0.-202.08.02. EGYSÉG PRO EURÓ ALAPÚ BEFEKTETÉSI ÉLETBIZTOSÍTÁS : 202. augusztus 06.

Részletesebben

Biztonság a glite-ban

Biztonság a glite-ban Biztonság a glite-ban www.eu-egee.org INFSO-RI-222667 Mi a Grid biztonság? A Grid probléma lehetővé tenni koordinált erőforrás megosztást és probléma megoldást dinamikus több szervezeti egységből álló

Részletesebben

Pénz-és kockázatkezelés

Pénz-és kockázatkezelés Pénz-és kockázatkezelés X-Trade Brokers Magyarországi Fióktelepe Soós Róbert Egy befektetési stratégia elemei 1. Meg kell határozni a belépési és zárási pozíciókat. 2. Pénz-és kockázatkezelés 3. Pszichológia

Részletesebben

Informatika. 3. Az informatika felhasználási területei és gazdasági hatásai

Informatika. 3. Az informatika felhasználási területei és gazdasági hatásai Informatika 1. Hírek, információk, adatok. Kommunikáció. Definiálja a következő fogalmakat: Információ Hír Adat Kommunikáció Ismertesse a kommunikáció modelljét. 2. A számítástechnika története az ENIAC-ig

Részletesebben

A GeoEasy telepítése. Tartalomjegyzék. Hardver, szoftver igények. GeoEasy telepítése. GeoEasy V2.05+ Geodéziai Feldolgozó Program

A GeoEasy telepítése. Tartalomjegyzék. Hardver, szoftver igények. GeoEasy telepítése. GeoEasy V2.05+ Geodéziai Feldolgozó Program A GeoEasy telepítése GeoEasy V2.05+ Geodéziai Feldolgozó Program (c)digikom Kft. 1997-2010 Tartalomjegyzék Hardver, szoftver igények GeoEasy telepítése A hardverkulcs Hálózatos hardverkulcs A GeoEasy indítása

Részletesebben

Miért jó nekünk kutatóknak a felhő? Kacsuk Péter MTA SZTAKI

Miért jó nekünk kutatóknak a felhő? Kacsuk Péter MTA SZTAKI Miért jó nekünk kutatóknak a felhő? Kacsuk Péter MTA SZTAKI Szolgáltatások halmaza: o Erőforrások, alkalmazások, eszközök o Nagy méretű, heterogén, gazdaságos, mobil, zöld El van takarva, hogy o Hol van

Részletesebben

Szkriptnyelvek. 1. UNIX shell

Szkriptnyelvek. 1. UNIX shell Szkriptnyelvek 1. UNIX shell Szkriptek futtatása Parancsértelmez ő shell script neve paraméterek shell script neve paraméterek Ebben az esetben a szkript tartalmazza a parancsértelmezőt: #!/bin/bash Szkriptek

Részletesebben

A felhőről általában. Kacsuk Péter MTA SZTAKI

A felhőről általában. Kacsuk Péter MTA SZTAKI A felhőről általában Kacsuk Péter MTA SZTAKI Miért fontos a felhő? (I) Problémák, ha az infrastruktúra még nem létezik Az ötletek megvalósításához szükséges idő Kutatás a felhők előtt 1. Van egy jó ötlet

Részletesebben

Oktatási cloud használata

Oktatási cloud használata Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnikai és Információs Rendszerek Tanszék Oktatási cloud használata Készítette: Tóth Áron (BME MIT), 2013. A segédlet célja a tanszéki oktatási cloud

Részletesebben

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft Flash és PHP kommunikáció Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft A lehetőségek FlashVars External Interface Loadvars XML SOAP Socket AMF AMFphp PHPObject Flash Vars Flash verziótól függetlenül

Részletesebben

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja.

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja. A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja. A hálózat kettő vagy több egymással összekapcsolt számítógép, amelyek között adatforgalom

Részletesebben

Szolgáltatás Orientált Architektúra a MAVIR-nál

Szolgáltatás Orientált Architektúra a MAVIR-nál Szolgáltatás Orientált Architektúra a MAVIR-nál Sajner Zsuzsanna Accenture Sztráda Gyula MAVIR ZRt. FIO 2009. szeptember 10. Tartalomjegyzék 2 Mi a Szolgáltatás Orientált Architektúra? A SOA bevezetés

Részletesebben

MICROSOFT DYNAMICS NAV RENDSZER SAAS MODELLBEN

MICROSOFT DYNAMICS NAV RENDSZER SAAS MODELLBEN Az ERP bevezetések 30%-a amiatt hiúsul meg, mert a bevezetést tervező vállalat nem tudja előteremteni az igényeinek megfelelő ERP rendszer bevezetéséhez szükséges erőforrást, vagy úgy gondolja, hogy az

Részletesebben

A GeoEasy telepítése. Tartalomjegyzék. Hardver, szoftver igények. GeoEasy telepítése. GeoEasy V2.05 Geodéziai Feldolgozó Program

A GeoEasy telepítése. Tartalomjegyzék. Hardver, szoftver igények. GeoEasy telepítése. GeoEasy V2.05 Geodéziai Feldolgozó Program A GeoEasy telepítése GeoEasy V2.05 Geodéziai Feldolgozó Program (c)digikom Kft. 1997-2008 Tartalomjegyzék Hardver, szoftver igények GeoEasy telepítése A hardverkulcs Hálózatos hardverkulcs A GeoEasy indítása

Részletesebben

Digitális aláíró program telepítése az ERA rendszeren

Digitális aláíró program telepítése az ERA rendszeren Digitális aláíró program telepítése az ERA rendszeren Az ERA felületen a digitális aláírásokat a Ponte webes digitális aláíró program (Ponte WDAP) segítségével lehet létrehozni, amely egy ActiveX alapú,

Részletesebben

A CAPICOM ActiveX komponens telepítésének és használatának leírása Windows7 operációs rendszer és Internet Explorer 8-es verziójú böngésző esetén

A CAPICOM ActiveX komponens telepítésének és használatának leírása Windows7 operációs rendszer és Internet Explorer 8-es verziójú böngésző esetén A CAPICOM ActiveX komponens telepítésének és használatának leírása Windows7 operációs rendszer és Internet Explorer 8-es verziójú böngésző esetén Tartalomjegyzék 1. A CAPICOM ACTIVEX KOMPONENS TELEPÍTÉSE...3

Részletesebben

2012.05.17.-2012.07.19.

2012.05.17.-2012.07.19. A NÖVEKEDÉSI ESZKÖZALAPOK TELJESÍTMÉNYE A PANNÓNIA NAVIGÁTOR SZOLGÁLTATÁS ÁLTAL HASZNÁLT PARAMÉTEREK TÜKRÉBEN 2012.05.17.-2012.07.19. EGYSÉG EURÓ ALAPÚ BEFEKTETÉSI ÉLETBIZTOSÍTÁS : 2012. július 23. 1.

Részletesebben

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

Részletesebben

MTA Cloud Use cases MTA Cloud workshop. Hernáth Szabolcs MTA WIGNER FK

MTA Cloud Use cases MTA Cloud workshop. Hernáth Szabolcs MTA WIGNER FK MTA Cloud Use cases MTA Cloud workshop Hernáth Szabolcs MTA WIGNER FK IT felhasználás dimenziói Felhasználók száma / jellege Kapacitás mérete / jellege Számítási feladat / szoftverkörnyezet Adatok mérete

Részletesebben

Podoski Péter és Zabb László

Podoski Péter és Zabb László Podoski Péter és Zabb László Bevezető Algoritmus-vizualizáció témakörében végeztünk kutatásokat és fejlesztéseket Felmértük a manapság ismert eszközök előnyeit és hiányosságait Kidolgoztunk egy saját megjelenítő

Részletesebben

Java I. A Java programozási nyelv

Java I. A Java programozási nyelv Java I. A Java programozási nyelv története,, alapvető jellemzői Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 02. 12. Java I.: Történet, jellemzők, JDK JAVA1 / 1 Egy kis történelem

Részletesebben

Swing Charting Játék az idővel (2.)

Swing Charting Játék az idővel (2.) Swing Charting Játék az idővel (2.) A megelőző cikkben olyan árfolyam ábrázolási és elemzési módszereket ismertettem, ahol az idő nem lineárisan, hanem az árfolyammozgás jelentősége alapján jelent meg.

Részletesebben

Könyvtári címkéző munkahely

Könyvtári címkéző munkahely Könyvtári címkéző munkahely Tartalomjegyzék A RENDSZER HARDVER ELEMEI...3 1 RFID CÍMKÉK... 3 2 RFID ASZTALI OLVASÓ... 3 A RENDSZER SZOFTVER ELEMEI... 4 1 KÖNYV CÍMKÉZŐ MUNKAÁLLOMÁS... 4 2 A PC- S SZOFTVEREK

Részletesebben

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan Telepítés internetről A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan Új szolgáltatásunk keretén belül, olyan lehetőséget kínálunk a TERC VIP költségvetéskészítő program

Részletesebben

Az internet az egész világot behálózó számítógép-hálózat.

Az internet az egész világot behálózó számítógép-hálózat. Az internet az egész világot behálózó számítógép-hálózat. A mai internet elődjét a 60-as években az Egyesült Államok hadseregének megbízásából fejlesztették ki, és ARPANet-nek keresztelték. Kifejlesztésének

Részletesebben

ISO 9001 kockázat értékelés és integrált irányítási rendszerek

ISO 9001 kockázat értékelés és integrált irányítási rendszerek BUSINESS ASSURANCE ISO 9001 kockázat értékelés és integrált irányítási rendszerek XXII. Nemzeti Minőségügyi Konferencia jzr SAFER, SMARTER, GREENER DNV GL A jövőre összpontosít A holnap sikeres vállalkozásai

Részletesebben

Modell alapú tesztelés mobil környezetben

Modell alapú tesztelés mobil környezetben Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed

Részletesebben

OE-NIK 2010/11 ősz OE-NIK. 2010. ősz

OE-NIK 2010/11 ősz OE-NIK. 2010. ősz 2010/11 ősz 1. Word / Excel 2. Solver 3. ZH 4. Windows 5. Windows 6. ZH 7. HTML 8. HTML 9. ZH 10. Adatszerkezetek, változók, tömbök 11. Számábrázolási kérdések 12. ZH 13. Pótlás A Windows felhasználói

Részletesebben

Kulcs Számla frissítés

Kulcs Számla frissítés Kulcs Számla frissítés Megjelenés dátuma: 2010. március 29. Elszámolási időszakos számlák Környezetvédelmi Termékdíj változás Szerződésekből bizonylat kiállítás Automatikus adatmentési lehetőség Készpénzfizetési

Részletesebben

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA AZ INFORMATIKAI PLATFORMON

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA AZ INFORMATIKAI PLATFORMON DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA AZ INFORMATIKAI PLATFORMON 2013. 08. 12 Készítette: FGSZ Zrt. Informatika és Hírközlés Informatikai Szolgáltatások Folyamatirányítás Az FGSZ Zrt. elkötelezett az informatikai

Részletesebben

C++ programozási nyelv

C++ programozási nyelv C++ programozási nyelv Gyakorlat - 8. hét Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2004. november A C++ programozási nyelv Soós Sándor 1/12 Tartalomjegyzék Miért

Részletesebben

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon

Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Magic xpi 4.0 vadonatúj Architektúrája Gigaspaces alapokon Mi az IMDG? Nem memóriában futó relációs adatbázis NoSQL hagyományos relációs adatbázis Más fajta adat tárolás Az összes adat RAM-ban van, osztott

Részletesebben

A DIPLOMAMUNKA FORMAI KÖVETELMÉNYEI JAVASLAT

A DIPLOMAMUNKA FORMAI KÖVETELMÉNYEI JAVASLAT A DIPLOMAMUNKA FORMAI KÖVETELMÉNYEI JAVASLAT A diplomamunka kötelező részei (bekötési sorrendben) 1. Fedőlap - Bal felső sarokban a kiíró tanszék megnevezése (ha két tanszékkel együttműködve dolgozzuk

Részletesebben

KÉPZÉSI PROGRAM. GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02. Szolnok

KÉPZÉSI PROGRAM. GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02. Szolnok KÉPZÉSI PROGRAM GAZDASÁGI INFORMATIKUS OKJ azonosító: 54 481 02 Szolnok 2015 KÉPZÉSI PROGRAM A képzési program Megnevezése Gazdasági informatikus OKJ azonosító 54 481 02 A képzés során megszerezhető kompetenciák

Részletesebben

Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010 A NÖVÉNYTERMESZTÉSI ÁGAZATOK ÖKONÓMIÁJA

Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010 A NÖVÉNYTERMESZTÉSI ÁGAZATOK ÖKONÓMIÁJA Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010 A NÖVÉNYTERMESZTÉSI ÁGAZATOK ÖKONÓMIÁJA 11. Előadás Az üzleti terv tartalmi követelményei Az üzleti terv tartalmi követelményei

Részletesebben

DLM PULSE - PREDIKTÍV TÁRGYALÁS TÁMOGATÓ ALKALMAZÁS DLM PULSE

DLM PULSE - PREDIKTÍV TÁRGYALÁS TÁMOGATÓ ALKALMAZÁS DLM PULSE DLM PULSE - PREDIKTÍV TÁRGYALÁS TÁMOGATÓ ALKALMAZÁS DLM PULSE A DLM Pulse innovatív testbeszéd kiértékelő megoldás virtuális tanácsadóként segíti az értékesítő munkáját az üzleti tárgyalás során. Könnyen

Részletesebben

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet Konfiguráció menedzsment bevezetési tapasztalatok Vinczellér Gábor AAM Technologies Kft. Tartalom 2 Bevezetés Tipikus konfigurációs adatbázis kialakítási projekt Adatbázis szerkezet Adatbázis feltöltés

Részletesebben

Területi elemzések. Budapest, 2015. április

Területi elemzések. Budapest, 2015. április TeIR Területi elemzések Felhasználói útmutató Budapest, 2015. április Tartalomjegyzék 1. BEVEZETŐ... 3 2. AZ ELEMZÉSBEN SZEREPLŐ MUTATÓ KIVÁLASZTÁSA... 4 3. AZ ELEMZÉSI FELTÉTELEK DEFINIÁLÁSA... 5 3.1.

Részletesebben

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA A REGIONÁLIS BOOKING PLATFORMON

DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA A REGIONÁLIS BOOKING PLATFORMON DIGITÁLIS TANÚSÍTVÁNY HASZNÁLATA A REGIONÁLIS BOOKING PLATFORMON 2013. 10. 09 Készítette: FGSZ Zrt. Informatika és Hírközlés Informatikai Szolgáltatások Folyamatirányítás Az FGSZ Zrt. elkötelezett az informatikai

Részletesebben

Saját Subversion tároló üzemeltetése i. Saját Subversion tároló üzemeltetése

Saját Subversion tároló üzemeltetése i. Saját Subversion tároló üzemeltetése i Saját Subversion tároló üzemeltetése ii KÖZREMŰKÖDŐK CÍM : Saját Subversion tároló üzemeltetése TEVÉKENYSÉG NÉV DÁTUM ALÁÍRÁS ÍRTA Jeszenszky, Péter 2014. február 16. VERZIÓTÖRTÉNET VERZIÓ DÁTUM LEÍRÁS

Részletesebben

2011.11.29. JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése

2011.11.29. JUnit. JUnit használata. IDE támogatás. Parancssori használat. Teszt készítése. Teszt készítése Tartalom Integrált fejlesztés Java platformon JUnit JUnit használata Tesztelési technikák Demo 2 A specifikáció alapján teszteljük a program egyes részeit, klasszikus V-modell szerint Minden olyan metódust,

Részletesebben

FEGYVERNEKI SÁNDOR, Valószínűség-sZÁMÍTÁs És MATEMATIKAI

FEGYVERNEKI SÁNDOR, Valószínűség-sZÁMÍTÁs És MATEMATIKAI FEGYVERNEKI SÁNDOR, Valószínűség-sZÁMÍTÁs És MATEMATIKAI statisztika 10 X. SZIMULÁCIÓ 1. VÉLETLEN számok A véletlen számok fontos szerepet játszanak a véletlen helyzetek generálásában (pénzérme, dobókocka,

Részletesebben

JavaScript Web AppBuilder használata

JavaScript Web AppBuilder használata JavaScript Web AppBuilder használata Kiss András Esri Magyarország Kft. 2015. október 8. Az ArcGIS Platform lehetővé teszi a Web GIS-t Térinformatika elérése bárhonnan Desktop Web Eszköz Egyszerű Egységes

Részletesebben

Felhő rendszerek és felhő föderációk. Kacsuk Péter MTA SZTAKI

Felhő rendszerek és felhő föderációk. Kacsuk Péter MTA SZTAKI Felhő rendszerek és felhő föderációk Kacsuk Péter MTA SZTAKI Számítási felhő Egy technológia, amely segíti a nagy számítási- és tárolási kapacitás menedzselését A felhasználóknak skálázhatóságot, magas

Részletesebben

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata Kutatási beszámoló a Pro Progressio Alapítvány számára Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Mérnök informatika szak Orvosi készülékekben használható modern

Részletesebben

2011.10.17.-2011.11.03.

2011.10.17.-2011.11.03. A NÖVEKEDÉSI ESZKÖZALAPOK TELJESÍTMÉNYE A PANNÓNIA NAVIGÁTOR SZOLGÁLTATÁS ÁLTAL HASZNÁLT PARAMÉTEREK TÜKRÉBEN 20.0.7.-20..03. EGYSÉG PRO EURÓ ALAPÚ BEFEKTETÉSI ÉLETBIZTOSÍTÁS : 20. november 7. . Használati

Részletesebben

Használati útmutató a Székács Elemér Szakközépiskola WLAN hálózatához

Használati útmutató a Székács Elemér Szakközépiskola WLAN hálózatához Használati útmutató a Székács Elemér Szakközépiskola WLAN hálózatához Készítette: Szentgyörgyi Attila Turcsányi Tamás Web: http://www.wyonair.com E-mail: 2008. november 8. TARTALOMJEGYZÉK TARTALOMJEGYZÉK

Részletesebben

2010.06.05. Pénz és tőkepiac. Intézményrendszer és a szolgáltatások. Befektetési szolgáltatási tevékenységek

2010.06.05. Pénz és tőkepiac. Intézményrendszer és a szolgáltatások. Befektetési szolgáltatási tevékenységek Pénz és tőkepiac Intézményrendszer és a szolgáltatások Befektetési vállalkozások - Értékpapír bizományos - Értékpapír kereskedő - Értékpapír befektetési társaság Befektetési szolgáltatók Működési engedélyezésük

Részletesebben

SZAKDOLGOZAT ÓBUDAI EGYETEM. Neumann János Informatikai kar Alba Regia Egyetemi Központ

SZAKDOLGOZAT ÓBUDAI EGYETEM. Neumann János Informatikai kar Alba Regia Egyetemi Központ ÓBUDAI EGYETEM Neumann János Informatikai kar Alba Regia Egyetemi Központ SZAKDOLGOZAT OE-NIK Hallgató neve: Berencsi Gergő Zsolt 2010. Törzskönyvi száma: T 000123/FI38878/S-N Tartalomjegyzék Tartalmi

Részletesebben

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb. SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.hu Mesterséges intelligencia oktatás a DE Informatikai

Részletesebben

Dokumentáció. 1. Beadandó feladat

Dokumentáció. 1. Beadandó feladat Ballai Brigitta XG3077 gittacska91@gmail.com 2013.11.25. Dokumentáció 1. Beadandó feladat Feladat : A feladat egy kellően bonyolult osztálystruktúra megtervezése és implementálása Java nyelven. Minimális

Részletesebben

BYOD. Bring Your Own Device

BYOD. Bring Your Own Device BYOD Bring Your Own Device BYOD Bring Your Own Device vagyis Hozd magaddal a saját eszközöd Magyarországon a táblagépek és az okostelefonok gyors terjedésével és azzal, hogy hazánkban is számos üzleti

Részletesebben

A japán gyertyák használata

A japán gyertyák használata A japán gyertyák használata www.elemzeskozpont.hu Mire használható ez az ebook? Az ebook-ban ismertetésre kerülő anyag szükséges az elemzeskozpont.hu weboldalon megjelenő technikai elemzések értelmezéséhez.

Részletesebben

Készítette: Trosztel Mátyás Konzulens: Hajós Gergely

Készítette: Trosztel Mátyás Konzulens: Hajós Gergely Készítette: Trosztel Mátyás Konzulens: Hajós Gergely Monte Carlo Markov Chain MCMC során egy megfelelően konstruált Markov-lánc segítségével mintákat generálunk. Ezek eloszlása követi a céleloszlást. A

Részletesebben

A FileZilla program beállítása az első belépés alkalmával

A FileZilla program beállítása az első belépés alkalmával 6. A záróvizsga-jegyzőkönyv készítése A záróvizsga-jegyzőkönyveketa Karok többsége a jegyzőkönyvkészítésre Dr. Tánczos László által kifejlesztett Access alkalmazás használatával készíti el. A záróvizsga-jegyzőkönyv

Részletesebben

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg.

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. KIINDULÁS Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg. Programozás III Az egyszerűség kedvéért mindegyiket a nevük alapján regisztráljuk,

Részletesebben

Rekurzió. Dr. Iványi Péter

Rekurzió. Dr. Iványi Péter Rekurzió Dr. Iványi Péter 1 Függvényhívás void f3(int a3) { printf( %d,a3); } void f2(int a2) { f3(a2); a2 = (a2+1); } void f1() { int a1 = 1; int b1; b1 = f2(a1); } 2 Függvényhívás void f3(int a3) { printf(

Részletesebben

Elemzések, fundamentális elemzés

Elemzések, fundamentális elemzés Elemzések, fundamentális elemzés Előadó: Mester Péter elemző peter.mester@quaestor.hu CÉL Bármilyen fundamentális elemzés is akad a kezünkbe, értsük és megértsük TARTALOM A fundamentális elemzés alapjai

Részletesebben

Programozás C++ -ban 2007/7

Programozás C++ -ban 2007/7 Programozás C++ -ban 2007/7 1. Másoló konstruktor Az egyik legnehezebben érthető fogalom C++ -ban a másoló konstruktor, vagy angolul "copy-constructor". Ez a konstruktor fontos szerepet játszik az argumentum

Részletesebben

Alapfogalmak. Biztonság. Biztonsági támadások Biztonsági célok

Alapfogalmak. Biztonság. Biztonsági támadások Biztonsági célok Alapfogalmak Biztonság Biztonsági támadások Biztonsági célok Biztonsági szolgáltatások Védelmi módszerek Hálózati fenyegetettség Biztonságos kommunikáció Kriptográfia SSL/TSL IPSec Támadási folyamatok

Részletesebben

Széchenyi István Egyetem. Programozás III. Varjasi Norbert varjasin@sze.hu

Széchenyi István Egyetem. Programozás III. Varjasi Norbert varjasin@sze.hu Programozás III. Varjasi Norbert varjasin@sze.hu 1 A java virtuális gép (JVM) Képzeletbei, ideális számítógép. Szoftveresen megvalósított működési környezet. (az op. rendszer egy folyamata). Feladata:

Részletesebben

Feladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. Például (bemenet/pelda.

Feladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. Például (bemenet/pelda. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. BEDTACI.ELTE Programozás 3ice@3ice.hu 11. csoport Feladat Madarak életének kutatásával foglalkozó szakemberek különböző településen különböző madárfaj

Részletesebben

KERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS

KERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS KERESKEDELMI AJÁNLAT BUDAÖRSI VÁROSFEJLESZTŐ KFT. RÉSZÉRE KERETRENDSZERBEN KIALAKÍTOTT - PROJEKT MENEDZSMENT FUNKCIONALITÁS BEVEZETÉSÉRE ÉS TÁMOGATÁSÁRA 1 TARTALOMJEGYZÉK Vezetői Összefoglaló...3 Projekt

Részletesebben

OCSP Stapling. Az SSL kapcsolatok sebességének növelése Apache, IIS és NginX szerverek esetén 1(10)

OCSP Stapling. Az SSL kapcsolatok sebességének növelése Apache, IIS és NginX szerverek esetén 1(10) OCSP Stapling Az SSL kapcsolatok sebességének növelése Apache, IIS és NginX szerverek esetén 1(10) 1. Tartalomjegyzék 1. Tartalomjegyzék... 2 2. Bevezető... 3 3. OCSP Stapling támogatással rendelkező webszerverek...

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Enabling Grids for E-sciencE. Grid bevezető. http://grid.kfki.hu/hungrid/ http://grid.ik.bme.hu/ http://web.eu-egi.eu/ www.eu-egee.org INFSO-RI-222667

Enabling Grids for E-sciencE. Grid bevezető. http://grid.kfki.hu/hungrid/ http://grid.ik.bme.hu/ http://web.eu-egi.eu/ www.eu-egee.org INFSO-RI-222667 Grid bevezető http://grid.kfki.hu/hungrid/ http://grid.ik.bme.hu/ http://web.eu-egi.eu/ www.eu-egee.org Mi a grid? Számítógépek, speciális eszközök, tárkapacitások, és szolgáltatások összessége, melyek

Részletesebben

GráfRajz fejlesztői dokumentáció

GráfRajz fejlesztői dokumentáció GráfRajz Követelmények: A GráfRajz gráfokat jelenít meg grafikus eszközökkel. A gráfot többféleképpen lehet a programba betölteni. A program a gráfokat egyedi fájl szerkezetben tárolja. A fájlokból betölthetőek

Részletesebben

A feladatok megoldásához felhasználandó annotációk leírásait az alábbi URL-en találja meg: http://junit.sourceforge.net/javadoc/

A feladatok megoldásához felhasználandó annotációk leírásait az alábbi URL-en találja meg: http://junit.sourceforge.net/javadoc/ BME Irányítástechnika és Informatika Tanszék Szoftver labor 3. 2011. Java JUnit labor Készítette: Budai Péter, BME IIT, 2011. A feladatok megoldása előtt mindenképp ajánlatos végigolvasni és lépésről lépésre

Részletesebben

E-learning tananyagfejlesztő képzés tematika oktatott modulok

E-learning tananyagfejlesztő képzés tematika oktatott modulok E-learning tananyagfejlesztő képzés tematika oktatott modulok 1142-06 - Számítógépkezelés, szoftverhasználat, munkaszervezés o Hardvert üzemeltet, szoftvert telepít o Irodai programcsomagot egyedi és integrált

Részletesebben

FELHŐ és a MAINFRAME. Irmes Sándor

FELHŐ és a MAINFRAME. Irmes Sándor FELHŐ és a MAINFRAME Irmes Sándor Változik az üzleti környezet Zavaró tényezők viharában Gartner: nexus of forces (összehangolt erőterek) Social: Mindenhol elérhető kapcsolattartás, egyre gazdagabb tartalommal

Részletesebben

Hibadetektáló rendszer légtechnikai berendezések számára

Hibadetektáló rendszer légtechnikai berendezések számára Hibadetektáló rendszer légtechnikai berendezések számára Tudományos Diákköri Konferencia A feladatunk Légtechnikai berendezések Monitorozás Hibadetektálás Újrataníthatóság A megvalósítás Mozgásérzékelő

Részletesebben

Biztonságos mobilalkalmazás-fejlesztés a gyakorlatban. A CryptTalk fejlesztése során alkalmazott módszerek. Dr. Barabás Péter Arenim Technologies

Biztonságos mobilalkalmazás-fejlesztés a gyakorlatban. A CryptTalk fejlesztése során alkalmazott módszerek. Dr. Barabás Péter Arenim Technologies Biztonságos mobilalkalmazás-fejlesztés a gyakorlatban A CryptTalk fejlesztése során alkalmazott módszerek Dr. Barabás Péter Arenim Technologies Agenda CryptTalk Hálózati kommunikáció Authentikált kérések

Részletesebben