SJ
Hochgeladen vonSascha Jonas
1,441 aufrufe

Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PAMM-Accounts

Diese Arbeit entwickelt ein Framework für den automatisierten Handel von Multi-Broker-PAMM-Accounts, das auf den Grundlagen des Devisenhandels und der Anforderungen an automatisierte Handelssysteme basiert. Ein Konzept für den gleichzeitigen Handel mehrerer Konten wird vorgestellt und in einer prototypischen Anwendung realisiert. Die Arbeit umfasst die Analyse, den Entwurf, die Implementierung und Tests der Softwarelösung.

Präsentation einbetten

Downloaden Sie, um offline zu lesen
ENTWICKLUNG EINES FRAMEWORKS ZUM AUTOMATISIERTEN HANDEL EINES MULTI-BROKER-PAMM-ACCOUNTS Abschlussarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) an der Hochschule f¨ur Technik und Wirtschaft Berlin Fachbereich Wirtschaftswissenschaften II Studiengang Angewandte Informatik 1. Pr¨ufer: Prof. Dr.-Ing. Thomas Schwotzer 2. Pr¨ufer: Prof. Dr.-Ing. R¨uger Oßwald Eingereicht von Sascha Jonas 21. April 2011 © Copyright 2011 Sascha Jonas. Alle Rechte vorbehalten.
iii Kurzzusammenfassung In Laufe der letzten Jahren wurde der Handel von Devisen und insbesondere der automatisierte Handel von Devisen immer interessanter. Im Rahmen dieser Arbeit werden die Grundlagen des Devisenhandels und die Anfordererungen an eine Anwendung zum automatisierten Handel von Devisen erarbeitet. Weit- erhin wird ein Konzept zum gleichzeitigen Handel mehrerer Konten vorgestellt. Basierend auf diesen Erkenntnissen wird eine prototypische Anwendung konzipiert und realisiert. Stichworte: Automatische Handelssysteme, Devisenhandel, Forex, PAMM-Konto
Inhaltsverzeichnis Abbildungsverzeichnis vi 1 Einleitung 1 1.1 Abriss ¨uber die historische Entwicklung des Devisenmarkts . . . . . . . . . . . . 1 1.2 Der Devisenmarkt heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 PAMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Grundlagen 5 2.1 Grundlagen des Devisenhandels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Modularisierung in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Die OSGi Service Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Eclipse RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 Anforderungsanalyse 21 3.1 Markt¨ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4 Entwurf 29 4.1 System-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5 Implementierung 35 5.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6 Software-Test 45 6.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2 GUI-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.3 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
INHALTSVERZEICHNIS vi 6.4 Ergebniss von GUI- und Funktionstests . . . . . . . . . . . . . . . . . . . . . . . 47 6.5 Skalierbarkeits-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7 Fazit 49 7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.2 R¨uckblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Literaturverzeichnis 50 A Glossar 55 B JFace Data Binding 57 C Abbildungen 59 D Tabellen 71 E Installationsanleitung 75 F Eigenst¨andigkeitserkl¨arung 77
Abbildungsverzeichnis 1.1 Percent Allocation Management Module (PAMM) . . . . . . . . . . . . . . . . . 4 2.1 Candlestick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Candlestick-Chart mit Moving Average und MACD . . . . . . . . . . . . . . . . 7 2.3 Bundle Lebenszyklus (Quelle: [wikc]) . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Event Admin Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5 Komponenten der Eclipse RCP Plattform. . . . . . . . . . . . . . . . . . . . . . . 17 5.1 FxTrader Client - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 FxTrader Client - GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 FxTrader Handelssysteme - Eingabe von Parametern . . . . . . . . . . . . . . . . 38 C.1 Sequenzdiagramm - Content Provider . . . . . . . . . . . . . . . . . . . . . . . . 59 C.2 Usecase Diagramm - Kontoverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 60 C.3 Usecase Diagramm - Tradeverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 61 C.4 Usecase Diagramm - Handelssysteme . . . . . . . . . . . . . . . . . . . . . . . . . 62 C.5 Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.6 Verteilungsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.7 ERM-Diagramm: Datentypen (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . . 64 C.8 ERM-Diagramm: Datentypen (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . . 65 C.9 Klassendiagramm - Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 C.10 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 C.11 Aktivit¨atsdiagramm f¨ur einen PAMM-Trade . . . . . . . . . . . . . . . . . . . . . 68 C.12 Klassendiagramm Server-Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 69 C.13 Klassendiagramm - Indikatoren und Handelssysteme . . . . . . . . . . . . . . . . 70
Kapitel 1 Einleitung In diesem Kapitel wird auf die historische Entwicklung und die aktuelle Situation des De- visenmarkts eingegangen. Im Anschluss werden das Percent Allocation Management Module (PAMM), ein Konzept f¨ur ein Sammelkonto, und das Ziel dieser Arbeit erl¨autert. 1.1 Abriss ¨uber die historische Entwicklung des Devisen- markts Mit dem Bretton-Woods-Abkommen1 , das am 22.07.1944 von 44 Staaten in Bretton Woods, USA beschlossen wurde, sollte das internationale W¨ahrungssystem neu geordnet werden. Zur Kontrolle des neuen W¨ahrungssystems wurden die auch heute noch existierenden Institutio- nen Weltbank und International W¨ahrungsfonds (IWF) geschaffen. Im Zentrum des Bretton- Woods-Abkommens stand der US-Dollar, der als Leitw¨ahrung dienen sollte. F¨ur die W¨ahrungen der teilnehmenden Staaten wurde ein fixes Wechselverh¨altnis zum US-Dollar festgelegt. Dieses Wechselverh¨altnis durfte nur 1% um den festgelegten Wert schwanken. Die Zentralbanken der jeweiligen L¨ander verpflichteten sich dazu, durch Ihre Geldpolitik und durch Eingriffe am De- visenmarkt diese fixen Wechselkurse zu halten. Ein weiterer Bestandteil des Abkommens war die enge Bindung des US-Dollar an Gold. Der Kurs wurde auf 35 Dollar je Feinunze Gold festgelegt, wobei sich die Federal Reserve Bank of New York (FED) verpflichtete, den fixen Wechselkurs von US-Dollar in Gold zu gew¨ahrleisten. Die USA hatte in den 70er Jahren im Zuge des Vietnamkrieges mit großen Staatsdefiziten zu k¨ampfen, was das Vertrauen in den US-Dollar stark d¨ampfte. Die ¨Olkrise von 1973 f¨uhrte schließlich zum endg¨ultigen Zerbrechen des Bretton-Woods-Abkommens. Seitdem wurde die Bindung von W¨ahrungen an Gold aufgegeben. Der Wechselkurs der meisten W¨ahrungen wird nun durch den Handel an den Devisenm¨arkten und die Geldpoli- 1vgl. [Och04] 23ff
KAPITEL 1. EINLEITUNG 2 tik der Zentralbanken bestimmt. Eine Ausnahme bildet z.B. der chinesische Yuan, der mit sehr geringem Spielraum an die Entwicklung des US-Dollar gekoppelt ist und nicht an den Devisenm¨arkten gehandelt wird.
KAPITEL 1. EINLEITUNG 3 1.2 Der Devisenmarkt heute Der Devisenmarkt, oder auch Forex-Markt2 , ist der globale Markt, auf dem W¨ahrungen gehan- delt werden. Er ist an keinen festen B¨orsenplatz gebunden, da er außerb¨orslich3 durch den Interbankenmarkt gebildet wird und ist aufgrund der unterschiedlichen Zeitzonen 24 Stunden am Tag und 5 Tage in der Woche offen. Der Devisenmarkt ist der gr¨oßte Finanzmarkt der Welt, mit einem durchschnittlichen Ta- gesumsatz von 4.000 Milliarden US-Dollar [Mon]. Der Devisenkurs wird immer als Wechselkurs zwischen zwei unterschiedlichen W¨ahrungen angegeben und so besteht ein Devisengesch¨aft auch immer aus dem gleichzeitigen Kauf und Verkauf von unterschiedlichen W¨ahrungen. W¨urde man zum Beispiel auf eine positive Entwicklung des Euro gegen¨uber dem US-Dollar setzen und eine sogenannte Long-Position im EUR/USD er¨offnen, dann w¨urde man gleichzeitig Euro kaufen und US-Dollar verkaufen. Der Devisenmarkt wird durch den Handel verschiedener Akteure mit sehr unterschiedlichen Zielen bestimmt. International agierende Unternehmen, wie z.B. IBM oder Porsche, unterhal- ten eine eigene Forex-Abteilung, um sich gegen W¨ahrungsrisiken abzusichern. Zentralbanken agieren um nationale Interessen zu sichern und Investoren spekulieren um Renditeziele zu er- reichen. Seit kurzem ist es auch Privatanlegern m¨oglich, am Devisenhandel teilzunehmen, da Broker4 durch sogenanntes Leverage die Mindesteinlage (f¨ur ein Minimum-Lot) stark verringert haben. Die Positionsgr¨oßen f¨ur ein Devisengesch¨aft waren fr¨uher ein Vielfaches von einem Lot. Unter einem Lot werden meist 100.000$ verstanden. Seit einiger Zeit ist ¨uber Broker aber auch der Handel von Mini-Lot, also einem Vielfachen von 0.1 Lot, und Micro-Lot, einem Vielfachen von 0.01 Lot, m¨oglich. Die H¨ohe des Leverage, auch Hebel genannt, sagt aus wie viel Margin auf einem Konto f¨ur ein Devisengesch¨aft hinterlegt sein muss. Bei einem Leverage von 1:100 und einer Positionsgr¨oße von 1 Lot m¨ussten 1.000$ statt 100.000$ als Margin hinterlegt sein. Niedrige Margin-Anforderungen, hohe Volalit¨at und die M¨oglichkeit Kauf-(Long) und Verkaufspositionen (Short) zu er¨offnen, machen diesen Markt so interessant. 2Forex-Markt steht f¨ur Foreign Exchange Market 3“over the counter ” - OTC 4Broker unterhalten Gesch¨aftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. Deutsche Bank, einer der gr¨oßten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf.
KAPITEL 1. EINLEITUNG 4 1.3 PAMM Verm¨ogensverwalter und Devisenh¨andler verwalten eine Vielzahl von Kundenkonten. Um ein Devisengesch¨aft (Trade) nun nicht f¨ur jedes verwaltetete Konto von Hand ausf¨uhren zu m¨ussen, wurde das Percent Allocation Management Module (PAMM) entwickelt. Kaufe 1 Lot EUR/USD PAMM-Technologie Portfolioanteil in % angepasste Positionsgröße Einzelkonten 200.000 $ 300.000 $ 500.000 $ 20% 30% 50% 0.2 Lot 0.3 Lot 0.5 Lot Abbildung 1.1: Percent Allocation Management Module (PAMM) Wie die Abbildung 1.1 zeigt, wird mittels PAMM eine Transaktion auf alle verwalteten Konten, abh¨angig von deren Anteil am Gesamtverm¨ogen, automatisch aufgeteilt. Dabei wird selbstverst¨andlich auch ber¨ucksichtigt, dass die Kundenkonten in unterschiedlichen W¨ahrun- gen vorliegen k¨onnen. Dazu wird der aktuelle Wechselkurs zum US-Dollar ermittelt und eine Umrechnung von Fremdw¨ahrungskonten in US-Dollar-Konten vorgenommen. Diese Technologie wird inzwischen von vielen Brokern bereitgestellt. Jedoch gibt es zur Zeit keine M¨oglichkeit, Konten von unterschiedlichen Brokern zu einem PAMM-Konto zusam- menzufassen. Ein Grund f¨ur die Verteilung von Kundengeldern auf mehrere Broker k¨onnte die Risikoabsicherung sein. So sind zum Beispiel Einlagen bei in Großbritannien residierenden Bro- ker mit bis zu 50.000 GBP (ca. 60.000 Euro) versichert und bei in der Schweiz residierenden Broker mit bis zu 100.000 CHF (ca. 80.000 Euro). 1.4 Zielsetzung Ziel dieser Arbeit ist es, ein Framework zu entwickeln, das die APIs ausgew¨ahlter Broker kapselt, um Konten dieser Broker zu einem PAMM-Account zusammenzufassen. Das Framework soll modular aufgebaut und leicht um weitere APIs erweiterbar sein. Außer- dem soll es wohlgeformte Schnittstellen zur Verf¨ugung stellen, um einen oder mehrere PAMM- Accounts zu verwalten und den Handel von Devisen durchzuf¨uhren. Aufbauend auf diesem Framework wird eine prototypische Anwendung entwickelt, die es erm¨oglicht, automatisierte Handelssysteme zu erstellen, und mit diesen den PAMM-Account zu handeln.
Kapitel 2 Grundlagen Dieses Kapitel beschreibt im ersten Teil die fachlichen Grundlagen f¨ur den automatisierten und computergest¨utzten Handel von Devisen. Aufgrund der formulierten Zielsetzung, dass die Software leicht um weitere Broker-API‘s, Indikatoren und automatische Handelssysteme erwei- terbar sein muss, wurde die OSGi Service Plattform die Grundlage f¨ur den Server gew¨ahlt. Um die Vorteile von OSGi auch auf Clientseite nutzen zu k¨onnen, hat sich der Autor f¨ur die Eclipse Rich Client Platform (RCP) entschieden. Beide Technologien werden im zweiten Teil dieses Kapitels untersucht. 2.1 Grundlagen des Devisenhandels Im Devisenhandel wird zwischen der fundamentalen und der technischen Analyse unterschieden. In der fundamentalen Analyse werden Handelsentscheidungen anhand von Fundamentaldaten wie z.B. dem Preisindex f¨ur die Lebenshaltung (CPI) oder dem Bruttoinlandsprodukt getroffen. Der technische Analyst hingegen trifft seine Handelsentscheidungen anhand von aktuellen und vergangenen Wechselkursen, in der Annahme, dass fundamentale Daten bereits eingepreist seien, und benutzt daf¨ur Charts, Chart-Pattern1 und Indikatoren. Zum Handel von Devisen k¨onnen beide Analyseformen kombiniert werden, im Rahmen dieser Arbeit erstellte Handelssysteme werden sich jedoch auf die technische Analyse beschr¨anken. 2.1.1 Bildung eines Candlestick Charts Zu den verbreiteten Chartformen geh¨ort der Candlestickchart. Zur Bildung eines Candlesticks (siehe Abbildung 2.1) werden die in einem bestimmten Zeitraum aufgetretenen Ticks analysiert. Der Candlestick bildet dann nur das Maxima (High), das Minima (Low), den Preis zu Beginn (Open) und den Preis zum Ende (Close) dieses Zeitraums ab. Diese vier Preisdaten und die 1siehe [Wikb] und [Wika]
KAPITEL 2. GRUNDLAGEN 6 High Low Open Close Abbildung 2.1: Candlestick Anzahl der in diesem Zeitraum gehandelten Lots (Volumen) werden alle oder teilweise, das h¨angt von der Art des Indikators ab, von Indikatoren zur Berechnung ben¨otigt. Weitere Chartformen sind der Balkenchart und der Linienchart. Der Balkenchart stellt wie der Candlestickchart(siehe Abbildung 2.2): Open, High, Low und Close, nur in einer anderen Form, dar, w¨ahrend der Linienchart nur die Close-Preise durch Linien miteinander verbindet. Im Devisenhandel haben sich verschiedene Zeitebenen etabliert auf deren Basis gehandelt wird. Die g¨angigsten Zeitebenen sind 1 Minute, 5 Minuten, 15 Minuten, 30 Minuten, 1 Stunde, 4 Stunden, 1 Tag, 5 Tage und 1 Monat, wobei Wochenenden nicht ber¨ucksichtigt werden. 2.1.2 Tickdaten Durch den regen Handel an den Devisenm¨arkten k¨onnen sich Wechselkurse in volatilen M¨arkten mehrmals in der Sekunde ¨andern. Diese Preis¨anderungen werden als Ticks bezeichnet. Ein Tick gibt also immer den Wechselkurs einer bestimmten W¨ahrung zu einer bestimmten Zeit an. Bei Wechselkursen wird zwischen Bid- und Ask-Preisen unterschieden. Er¨offnet man eine Long-Position (Buy), dann wird diese Position zum Ask-Preis er¨offnet. Schließt man diese Po- sition oder er¨offnet eine Short-Position (Sell), so geschieht dies zum Bid-Preis. Zwischen Ask- und Bid-Preis liegt immer eine Differenz, die je nach Marktsituation, W¨ahrung und Broker unterschiedlich sein kann. Diese Differenz wird Spread genannt und ist die Geb¨uhr, die Broker f¨ur ihre Dienste verlangen. Der Spread liegt bei den Hauptw¨ahrungen, auch Majors genannt, meist zwischen einem und vier Pips. Ein Tick besteht also genaugenommen aus zwei Preisen, dem Bid- und dem Ask-Preis. F¨ur Indikatoren und Charts werden meist Bid-Preise verwendet, da diese bei Ask-Preisen durch marktabh¨angige Spreads verf¨alscht w¨urden. 2.1.3 Indikatoren Indikatoren sind Werkzeuge zur statistischen Analyse von B¨orsendaten. Indikatoren k¨onnen un- terteilt werden in trendfolgende Indikatoren, Oszillatoren und sonstige Indikatoren. Indikatoren werden, f¨ur den aktuellen Candlestick, bei jedem Tick neu berechnet. F¨ur die Analyse werden jedoch nur Indikatorenwerte von bereits abgeschlossenen Candlesticks verwendet.
KAPITEL 2. GRUNDLAGEN 7 12 EMA 26 EMA Signallinie Mittellinie MACD 1 Abbildung 2.2: Candlestick-Chart mit Moving Average und MACD Der gleitende Durchschnitt [eSib] (Moving Average) geh¨ort zu den trendfolgenden Indika- toren: ” Es ist seine Aufgabe, zu signalisieren, dass ein neuer Trend begonnen hat oder dass ein alter Trend geendet oder sich umgekehrt hat.“2 . Der Moving Average wird meist mit den Close-Preisen gebildet, kann unter anderem aber auch vom Mittelwert ((Low+High)/2) gebildet werden. Moving Averages werden in gewichtet und ungewichtet unterschieden. Beim simplen Moving Average (SMA), wird jeder Preis gleich gewichtet, sodass sich folgende Formel ergibt: SMA0 = 1 M M n=0 Preisn, wobei M die Periode des Moving Average und damit die Anzahl der zur Berechnung einbezoge- nen Candlesticks darstellt. Die Variable n steht f¨ur den Candlestick, dessen Preis zur Berechnung genommen wird3 . Zu den gewichteten gleitenden Durchschnitten geh¨ort zum Beispiel der expo- nentiell gegl¨attete Moving Average (EMA), bei dem Kurse der j¨ungsten Vergangenheit st¨arker gewichtet sind als ¨altere Kurse. Dazu wird der Faktor α verwendet, mit α = 2 M+1 , wodurch sich die folgende Formel ergibt: EMA0 = (Preis0 · α) + (SMA1 · (1 − α)), 2siehe [Mur06] S. 203ff 3n=0 ist der aktuelle Candlestick (dessen Preis sich bei jedem Tick ¨andert), n=1 der letzte Candlestick, n=2 der vorletzte Candlestick usw.
KAPITEL 2. GRUNDLAGEN 8 Moving Averages gl¨atten das ” Rauschen“ des Marktes, sie erleichtern das Erkennen von Trends und werden oftmals zum Gl¨atten der Werte anderer Indikatoren benutzt. Moving Averages k¨onnen so interpretiert werden, dass es sich um einen Aufw¨artstrend handelt, wenn sich die Candlesticks ¨uber dem Moving Average befinden und ansonsten um einen Abw¨artstrend. Ein ¨Uber- bzw. Unterschreiten des Moving Average, w¨urde dann einen Trendwechsel signalisieren. Eine weitere M¨oglichkeit ist es, zwei Moving Averages, einen langsamen und einen schnellen, zu verwenden. Befindet sich der schnelle Moving Average (12er EMA) ¨uber dem langsamen (26er EMA), dann handelt es sich um einen Aufw¨artstrend und ansonsten um einen Abw¨artstrend (siehe Abbildung 2.2). Das kreuzen der beiden Moving Av- erages zeigt den Trendwechsel an (siehe den mit 1 markierten Kreis in Abbildung 2.2). Oszillatoren sind Indikatoren, deren Werte entweder um die Mittellinie oder zwischen fest- gelegten Werten, meist zwischen 0 und 100, schwanken. Der Moving Average Convergence Divergence Indikator [eSia] (MACD) geh¨ort zu der Gruppe der Oszillatoren und berechnet den Abstand zwischen zwei Moving Averages (meist 12er und 26er EMA) und eine Signallinie (meist 9er EMA). Ein steigender MACD, ¨uber der Mittellinie, wird als Aufw¨artstrend und ein fallender MACD, unter der Mittellinie, wird als Abw¨artstrend interpretiert. Als Trendwechsel werden das Kreuzen der Mittel- oder Signallinie und Divergenzen4 gedeutet. Zum Abschluss sei erw¨ahnt, dass Indikatoren nur Hinweise auf m¨ogliche Ereignisse geben k¨onnen. Da es sich um statistische Analysen handelt, treffen von Indikatoren signalisierte Ereignisse nur mit einer gewissen Wahrscheinlichkeit ein. Bei den oben erw¨ahnten Indikatoren handelt es sich weiterhin um Indikatoren, die dem Markt ” hinterherlaufen“, das heisst, dass eine Marktbewegung auch bereits abgeschlossen sein kann und ein Neueinstieg in den Markt nicht mehr profitabel ist. 2.1.4 Ordertypen Ein einzelner Handel von Devisen wird als Order oder Trade bezeichnet. Es wird zwischen Market Order und Pending Order unterschieden. Eine Market Order wird sofort und zum ak- tuellen Marktpreis (Market Entry) ausgef¨uhrt. Eine Pending Order kann nur unter bestimmten Voraussetzungen angelegt werden und wird zu einem vorher festgelegten Kurs (Pending Entry) ausgef¨uhrt. Market Orders werden verwendet, wenn der Zeitpunkt f¨ur die Er¨offnung eines Trades wichtiger ist, als der Preis zu dem er er¨offnet wird. Bei Pending Orders ist der Zeitpunkt, wann der Trade er¨offnet wird, nicht so wichtig. Dieser Ordertyp wird z.B. bei dem Handel von Ausbr¨uchen aus Seitw¨artsm¨arkten oder bei wichtigen Nachrichten verwendet. Hier werden dann Kauf- und Verkausorder ¨uber bzw. unter der bisherigen Range platziert und der Trader l¨asst sich dann ” einstoppen“: 4Beispiel: In der Abbildung 2.2 ist der MACD-Wert vom November 2007 geringer als der MACD-Wert vom Dezember 2004, w¨ahrend der Close-Preis vom Dezember 2004 geringer als der vom November 2007 ist. Chartbild und Indikatorbild unterscheiden sich, was als Divergenz bezeichnet wird.
KAPITEL 2. GRUNDLAGEN 9 Ordertyp Entry-Preis Stop-Preis Limit-Preis Buy (Market Entry) Ask <Bid >Ask Buy Limit (Pending Entry) <Ask <Pending Entry >Pending Entry Buy Stop (Pending Entry) >Ask <Pending Entry >Pending Entry Sell (Market Entry) Bid >Ask <Bid Sell Limit (Pending Entry) >Bid >Pending Entry <Pending Entry Sell Stop (Pending Entry) <Bid >Pending Entry <Pending Entry Tabelle 2.1: Ordertypen und Voraussetzungen F¨ur beide Ordertypen k¨onnen ein Stop, dient der automatischen Verlustbegrenzung, und ein Limit, dient der automatischen Gewinnmitnahme, gesetzt werden. Beispiel: Soll eine Kauforder ausgef¨uhrt werden, so geschieht dies zum Ask-Preis, der Stop m¨usste dann unter dem Bid-Preis und das Limit ¨uber dem Ask-Preis liegen. Erreicht der Marktpreis entweder Stop oder Limit, w¨urde die Position automatisch geschlossen werden. Alle Voraussetzungen f¨ur die einzelnen Ordertypen k¨onnen in der Tabelle 2.1 nachgelesen werden. Jeder Trade wird als einzelne Position behandelt und ist unabh¨angig von anderen Trades. Damit ist es m¨oglich, gleichzeitig Long und Short zu sein, was im Devisenhandel g¨angige Praxis ist und wird zum einen zur Risikoabsicherung benutzt. Auf der anderen Seite kann es zum Beispiel bei Handelssystemen, die auf unterschiedlichen Zeitebenen agieren, zu gleichzeitigen Long- und Short-Trades kommen. Eine Ausnahme bilden hier Konten, die bei einem Broker in den USA gef¨uhrt werden. In Reaktion auf die Finanzkrise wurde in den USA, durch die National Finance Authority (NFA), eine andere Regelung eingef¨uhrt. Aufgrund der NFA Compliance Rule 2-43(b), ist hier nur eine Position pro W¨ahrungspaar erlaubt. Die Konsequenz davon ist, dass ein neuer Short-Trade einen bestehenden Long-Trade ganz oder teilweise schließt. Damit wird aus einer Long-Position mit 1,0 Lot eine Long-Position mit 0,5 Lot, wenn eine Short-Position mit 0,5 Lot er¨offnet wurde. Es ist also innerhalb eines US-Kontos nicht mehr m¨oglich, gleichzeitig Long und Short zu sein. Dies kann umgangen werden, indem ein Konto f¨ur Long- und ein anderes Konto f¨ur Short-Trades genutzt wird. Auch das Setzen von Stop- und Limit-Preis ist - bei US-Brokern - nicht mehr m¨oglich, kann aber durch das Setzen entsprechender Entry-Orders ersetzt werden. So k¨onnten z.B. f¨ur einen Long-Trade, eine Sell-Limit- und eine Sell-Stop-Order, anstatt eines Stop- und Limit-Preises, benutzt werden. Das bedeutet, dass Konten bei US-Broker und Konten bei Broker außerhalb der USA, nicht in einem PAMM-Konto gemischt werden k¨onnen. Die im Rahmen dieser Arbeit erstellte Anwendung wird US-Konten somit nicht voll unterst¨utzen. 2.1.5 Gewinn- und Verlustberechnung Alle Wechselkurse werden auf mindestens 4 Nachkommastellen genau angegeben. Eine Aus- nahme bilden z.B. Wechselkurse in denen der Japanische Yen (JPY) enthalten ist, da es im
KAPITEL 2. GRUNDLAGEN 10 JPY keine Cent-Betr¨age gibt. Die Preis¨anderungen werden in Pips gemessen, wobei ein Pip der vierten Nachkommastelle also 0,0001 bzw. 0,01 im JPY entspricht. In dem nachfolgenden Beispiel soll nun dargelegt werden, wie Gewinne oder Verluste bei Trades berechnet werden. Die allgemeine Formel5 lautet: Gewinn/V erlust = (Pips) · (Preis{sekund¨areW ¨ahrung/Kontow¨ahrung}) · (Lots) · 100.000$ In dem folgenden Beispiel wurde eine Long-Position6 im EUR/GBP bei 0,8431 ge¨offnet und bei 0,8442 geschlossen: Kontow¨ahrung: USD gehandelte W¨ahrung: EUR/GBP prim¨are W¨ahrung (Base): EUR sekund¨are W¨ahrung (Quote): GBP Preis {sekund¨are W¨ahrung / Kontow¨ahrung} (GBP/USD): 1,6108 Open: 0,8431 Close: 0,8442 Pips: Close - Open = 0,8442-0,8431 = 0,0011 gehandelte Lots: 1 Gewinn/V erlust = (0, 0011) · (1, 6108) · (1) · 100.000$ = 177, 19$. Im Kontext eines Trades f¨ur ein PAMM-Konto (PAMM-Trade) ist die Gewinn- und Verlust- berechnung etwas schwieriger. Ein PAMM-Trade besteht aus vielen Einzeltrades, die bei ver- schiedenen Konten und Broker ge¨offnet wurden. Bei einem PAMM-Trade wird es also eher Regel als Ausnahme sein, dass die Einzeltrades zu verschiedenen Preisen ge¨offnet wurden. Das liegt zum einen daran, dass Broker leicht unterschiedliche Preis-Feeds haben k¨onnen. Zum anderen handelt es sich bei dem Devisenmarkt um einen sehr volatilen Markt, bei dem sich W¨ahrungskurse sehr schnell ¨andern k¨onnen. Es kann aufgrund der unterschiedlichen Preis-Feeds auch dazu kommen, dass ein Einzeltrade bei einem Broker schon den Limit- oder Stop-Preis erreicht hat und geschlossen wurde, w¨ahrend andere Einzeltrades noch offen sind. Damit steht der endg¨ultige Gewinn oder Verlust f¨ur einen PAMM-Trade erst fest, wenn alle Einzeltrades geschlossen wurden. Um nicht den laufenden Gewinn/Verlust f¨ur jeden Einzeltrade eines PAMM-Trades auszurechnen, wird ein - nach Lotgr¨oße gewichteter - Durchschnittspreis f¨ur den Open-Preis eingef¨uhrt: gewichteter Open-Preis=(Lot1·Open1)+(Lot2·Open2)+...+(Lotn·Openn) Lot1+Lot2+...+Lotn , dabei steht n f¨ur die Anzahl der Einzeltrades in einem PAMM-Trade. Anhand dieses Preises, der gesamten Lotgr¨oße und dem aktuellen Devisenkurs, kann der aktuelle Gewinn- und Verlust f¨ur einen PAMM-Trade leicht berechnet werden. 5Wenn die sekund¨are W¨ahrung gleich der Kontow¨ahrung ist, gilt: Gewinn/Verlust=(Pips)*(Lots)*100.000$. 6Bei einer Short-Position, w¨urde sich die Anzahl der Pips mit Pips = Open − Close berechnen.
KAPITEL 2. GRUNDLAGEN 11 2.1.6 Lotberechnung Wie im letzten Unterkapitel ersichtlich wurde, h¨angt der Gewinn/Verlust eines Trades im großen Maße von der Lotgr¨oße ab. Die Anzahl der Lots muss auch als einziger Parameter beim Er¨offnen eines Trades angegeben werden. Doch wie bestimmt man die Lotgr¨oße? Vor jedem Trade sollte festgelegt werden, wie groß das Risiko pro Trade sein soll (Ein guter Wert liegt hier meist zwischen 1-3% der Kontogr¨oße). Das Risiko wird mit dem Setzen des Stop- Preises festgelegt, bei dem ein m¨oglicher Verlust realisiert wird. Sind Stop-Preis und damit die Entfernung vom Entry in Pips bekannt, kann die im letzten Unterkapitel erw¨ahnte Formel benutzt werden, um die Lotgr¨oße zu bestimmen. Eingeschr¨ankt wird die Lotgr¨oße und damit eine genaue Realisierung des Risikos pro Trade, nur durch die Anzahl der erlaubten Nachkommastellen7 . Im Kontext eines PAMM-Kontos f¨uhrt dies dazu, dass ein PAMM-Trade im Allgemeinen nicht gleichm¨aßig auf alle im PAMM-Konto zusammengefassten Einzelkonten verteilt werden kann. Meistens wird eine optimale Aufsplit- tung des PAMM-Trades in Einzeltrades nicht m¨oglich sein, da die f¨ur das Einzelkonto berech- nete Lotgr¨oße auf- oder abgerundet werden muss, wodurch sich wiederum das Einzel- und Gesamtrisiko des Trades ¨andert. 2.1.7 Automatische Handelssysteme Automatisierte Handelssysteme sind autonome Systeme, die anhand von Indikatoren und/oder Chartformationen, die Entscheidungen zum Kauf oder Verkauf von Devisen treffen und selb- st¨andig den Handel durchf¨uhren. Sie haben ein beliebig komplexes Regelwerk, in dem Kriterien f¨ur die Er¨offnung und das Schließen eines Trades, das Risiko pro Trade und die Stop- und Limit-Berechnung festgelegt sind. Diese Werte sind meist nicht statisch, sondern k¨onnen vom Anwender vor dem Starten des Systems festgelegt werden. Automatisierte Handelssysteme bieten den Vorteil, dass sie rund um die Uhr die M¨arkte analysieren und handeln k¨onnen, ohne emotionale oder psychologische Schw¨achen. Sie werden weder durch Angst, noch durch Gier oder M¨udigkeit beeinflusst. Ein weiterer Vorteil ist, dass automatisierte Handelssysteme nicht nur auf aktuelle De- visendaten, sondern auch auf historische Daten angewendet werden k¨onnen. Mit diesem, als Backtesting bekannten, Verfahren lassen sie sich nicht nur auf technische Funktionalit¨at, son- dern auch auf m¨ogliche Profitabilit¨at testen. Inzwischen unterst¨utzt jeder Broker das Erstellen von automatischen Handelssystemen, je- doch verwendet auch jeder Broker daf¨ur eine andere Software, sodass automatische Handelssys- teme nur mit Programmieraufwand portiert werden k¨onnen. Dies soll im Kapitel 3 genauer untersucht werden. 7Zwei Nachkommastellen bei Micro-Lot-Konten und eine Nachkommastelle bei Mini-Lot-Konten
KAPITEL 2. GRUNDLAGEN 12 2.2 Modularisierung in Java Dieses Unterkapitel soll verdeutlichen, was Modularisierung bedeutet und wie dieses Architektur-Konzept in Java umgesetzt wird, bevor im n¨achsten Unterkapitel - mit OSGi - eine modulare System-Plattform vorgestellt wird. Der klassische Modularisierungsbegriff lautet: ” ... Modularisierung bezeichnet ... die Aufteilung eines Softwaresystems in ¨uberschaubare Einzelteile, die jeweils einen abgeschlossenen Aufgabenbereich umfassen und untereinander mittels wohldefinierter Schnittstellen miteinander verbunden sind. [Rei09]“. Bis zur Einf¨uhrung des objektorientierten Paradigmas, unterst¨utzten Programmiersprachen die Modularisierung nur rudiment¨ar. Computerprogramme konnten nur durch Funktionen und Prozeduren strukturiert werden und hatten damit eher monolithischen Charakter. Sie waren schwieriger zu testen, schwieriger zu erweitern und schlechter wartbar. Mit der Einf¨uhrung der objektorientierten Programmiersprachen, wurde das Konzept der Modularisierung st¨arker verankert und um den Begriff der Komponente erweitert. Eine Kom- ponente wird definiert als eine Einheit zur Komposition, d.h. sie wird nur als ganzes spezifiziert, implementiert und eingesetzt. Eine Komponente besitzt fest spezifierte Schnittstellen, durch die die Verwendung der Komponente geregelt ist. Eine Komponenten-basierte Anwendung ist eine Komposition von Komponenten, wobei einzelne Komponenten entweder durch komplett neue Implementierungen oder neue Versio- nen aktueller Implementierungen ausgetauscht werden k¨onnen. Die einzelnen Komponenten einer Komponentenbasierten Anwendung sind durch deren Schnittstellen gekoppelt, wobei die konkrete Implementierung der Schnittstellen dem Benutzer der Komponente durch die Kapselung verborgen ist. Komponenten bieten den Vorteil, dass sie wiederverwendbar und gut testbar sind. In Java lassen sich Beziehungen zwischen Komponenten nur unidirektional ausdr¨ucken. Durch das import-Statement kann angegeben werden, welche anderen Komponenten es benutzt, aber nicht welche Klassen es f¨ur die Benutzung durch andere Komponenten exportiert. In Java werden weiterhin Klassen auf Sprachebene mit Hilfe von Packages hierarchisch strukturiert. Dabei l¨asst sich zwar die Sichtbarkeit von Klassen auf Packageebene einschr¨anken, f¨ur eine echte Komponentenbildung ist dies aber unzureichend. Die interne Implementierung ist dadurch nicht ausreichend gesch¨utzt und ¨uber eine einfache Typumwandlung erreichbar. OSGi ist eine auf Java basierende Plattform und erweitert Java um die M¨oglichkeit, echte Komponenten zu entwickeln. Bei OSGi ist die Implementierung einer Komponente durch einen separaten Class-Loader gesch¨utzt, außerdem ist es hier m¨oglich, explizit Abh¨angigkeiten, zu exportierende Elemente und Schnittstellen zu definieren. Dies soll im n¨achsten Unterkapitel genauer untersucht werden.
KAPITEL 2. GRUNDLAGEN 13 2.3 Die OSGi Service Plattform Die OSGi Alliance, ein Konsortium von Technologieunternehmen, ist eine non-profit Orga- nisation und wurde 1999 gegr¨undet. Ihre Aufgabe ist es, die Programmierschnittstellen und Testf¨alle [OSGa,OSGb] f¨ur die OSGi Service Platform zu spezifizieren. Die OSGi Service Platform ist ein dynamisches Modulsystem f¨ur Java. Es handelt sich um eine javabasierte Softwareplattform, die die dynamische Integration und das Fernmanagement von Softwarekomponenten (Bundles) und Diensten (Services) erm¨oglicht. Bundles und Services k¨onnen zur Laufzeit in der Serviceplattform installiert und deinstalliert, aktualisiert, gestoppt und gestartet werden, ohne dass die Plattform als Ganzes angehalten bzw. neu gestartet werden muss [WHKL08]. Es gibt eine Referenzimplementierung von der OSGi Alliance, diese ist jedoch nicht f¨ur den Produktiveinsatz gedacht. Hervorzuheben sei hier die Implementierung durch das Eclipse Equinox Projekt, welche Open Source ist und die Grundlage von Eclipse seit Version 3.0 bildet. Weitere Implementierungen sind z.B. Apache Felix und Knopflerfish. 2.3.1 OSGi Bundles Das fundamentale Konzept der OSGi Service Plattform ist die Modularisierung. In der OSGI- Terminologie werden diese Module als Bundles bezeichnet. Unter einem Bundle versteht man eine fachlich oder technisch zusammenh¨angende Einheit von Klassen und Ressourcen, die unabh¨angig von anderen Bundles im OSGi Framework installiert und deinstalliert werden kann [WHKL08]. ¨Ublicherweise wird f¨ur Bundles die Dateiendung ” .jar“ verwendet. Von einer normalen JAR-Datei unterscheidet sich ein Bundle nur durch ein Bundle Manifest. INSTALLED RESOLVED UNINSTALLED STARTING ACTIVE STOPPING Start Stop Abbildung 2.3: Bundle Lebenszyklus (Quelle: [wikc]) Die Abbildung 2.3 zeigt den Lebenszyklus eines Bundles. Jedes Bundle kann sich in sechs verschiedenen Zust¨anden befinden: ˆ INSTALLED: Das Bundle wurde erfolgreich auf der OSGI-Plattform installiert.
KAPITEL 2. GRUNDLAGEN 14 ˆ RESOLVED: Alle Abh¨angigkeiten (siehe Bundle Manifest) des Bundles konnten aufgel¨ost werden. Das Bundle ist bereit gestartet zu werden oder wurde gerade gestoppt. ˆ STARTING: Die start-Methode des Bundle-Activators wurde aufgerufen aber noch nicht abgeschlossen. ˆ ACTIVE: Das Bundle l¨auft und die start-Methode des Bundle-Activators wurde erfolgre- ich abgeschlossen. ˆ STOPPING: Die stop-Methode des Bundle-Activators wurde aufgerufen aber noch nicht abgeschlossen. ˆ UNINSTALLED: Das Bundle wurde deinstalliert. Im Eclipse-Umfeld wird meist von Plug-ins anstatt von Bundles gesprochen. Beide Begriffe beschreiben allerdings ein und dasselbe Konzept und werden synonym verwendet. 2.3.1.1 Das Bundle Manifest Jedes Bundle wird ¨uber seine Manifest-Datei und darin definierte Manifest-Header beschrieben. Das Bundle Manifest befindet sich in der JAR-Datei des Bundles unter dem Namen META- INF/MANIFEST.MF. Die Manifest-Header werden ausf¨uhrlich im Kapitel 3.2 des OSGi-Core- Compendium [OSGa] beschrieben. Listing 2.1 zeigt den Ausschnitt eines g¨ultigen Bundle Man- ifest. 1 Bundle -Name: API -Interfaces 2 Bundle - SymbolicName : de.pammtrader.core.api.interfaces 3 Bundle -Activator: de.pammtrader.core.api.interfaces.Activator 4 Bundle -Version: 0.1.0 5 Bundle - RequiredExecutionEnvironment : JavaSE -1.6 6 Import -Package: 7 de.pammtrader.core.account.interfaces;version="[0.1.0 ,1.0.0)" 8 Export -Package: de.pammtrader.core.api.interfaces;version="0.1.0" 9 Require -Bundle: de.pammtrader.core.api.fxcm;bundle -version="0.1.0" Listing 2.1: MANIFEST.MF Bundles werden innerhalb der OSGi Service Plattform durch ihren symbolischen Namen und ihrer Versionsnummer eindeutig identifiziert (Listing 2.1: Zeilen 2, 4). Diese beiden Felder, sind auch die einzigen Header die gesetzt werden m¨ussen. Alle anderen Header sind optional. Das bedeutet, dass Bundles auch in mehreren und unterschiedlichen Versionen auf der OSGi Plattform installiert sein k¨onnen. In der Manifest-Datei kann ein Bundle-Activator angegeben werden (Listing 2.1: Zeile 3). Dieser Bundle-Activator muss das Interface BundleActivator und dessen start- und stop- Methode implementieren. Er ist mit der main-Methode aus Java-Programmen vergleichbar. Weiterhin k¨onnen Abh¨angigkeiten wie ben¨otigte Java-Packages und Bundles definiert und explizit Java-Packages exportiert werden (Listing 2.1: Zeilen 6-9). Damit wird eine weitere
KAPITEL 2. GRUNDLAGEN 15 Besonderheit von OSGi klar: Es kann nur auf Java-Packages anderer Bundles zugegriffen wer- den, die diese auch exportieren. 2.3.2 OSGi Services Mit der Hilfe von Services werden Bundles dynamisch durch das ” publish, find and bind model“ lose gekoppelt. Ein Service ist ein Java-Objekt, das unter einem oder unter mehreren Java- Interfaces bei der Service-Registry angemeldet ist. Bundles k¨onnen Services registrieren, nach Services suchen und sich benachrichtigen lassen wenn sich Services anmelden, abmelden oder aktualisert wurden. [OSGa] Da Services sich zu beliebigen Zeitpunkten bei der Service-Registry registrieren und dereg- istrieren k¨onnen, gilt es, dies bei der Benutzung von Services zu beachten. Um den Umgang mit Services zu vereinfachen, wurden der Service-Tracker und Declarative Services geschaffen. Bei einem Service-Tracker handelt es sich um eine Hilfsklasse, die den Zugriff auf die Service- Registry kapselt und das An- und Abmelden von Services mit einem spezifischen Interfacena- men ¨uberwacht. Mit der Hilfe von Declarative Services k¨onnen Service-Abh¨angigkeiten in einer XML-Datei beschrieben werden. Das Aufl¨osen von Service-Abh¨angigkeiten wird dann durch die Service Component Runtime realisiert. Beide Ans¨atze werden genauer im OSGi Service Compendium [OSGb] beschrieben. 2.3.2.1 Event Admin Service Im OSGi Service Compendium [OSGb] werden eine Reihe von Diensten spezifiziert. Die im Rahmen dieser Arbeit erstellte Anwendung benutzt unter anderem den Event Admin Service, weswegen dieser hier erl¨autert werden soll. Der Event Admin Service basiert auf dem ” publish- <<class>> Event <<service>> Event Admin <<service>> Event Handler Event Consumer impl EventHandler Event Publisher 1 0..n Abbildung 2.4: Event Admin Service subscribe model“ und erlaubt die systemweite Kommunikation zwischen Bundles. Abbildung 2.4 stellt den Event Admin Service schematisch dar: Event Publisher benutzen die postEvent-
KAPITEL 2. GRUNDLAGEN 16 Methode des Event Admin Service zum asynchronen bzw. dessen sendEvent-Methode zum synchronen Versenden von Events. Alle Bundles, die sich f¨ur ein Topic und dessen Events interessieren, registrieren sich nun nicht beim Event Admin Service als Listener. Stattdessen implementieren sie das Interface EventHandler, registrieren sich als Dienst, ¨ubergeben als Service-Property das Topic und werden vom Event Admin Service ¨uber Events informiert. Dieses Design Pattern wird Whiteboard- Pattern genannt. Ein Event wird repr¨asentiert durch ein org.osgi.service.event.Event Objekt und hat die zwei Attribute: Topic und Properties. Topics sind String Objekte und case-sensitive. Ein Beispiel f¨ur ein g¨ultiges Topic w¨are ” de/pammtrader/api“, wobei Wildcards erlaubt sind. Properties sind HashMaps, wobei der Schl¨ussel ein String-Objekt ist und der dazu geh¨orige Wert ein beliebiges Java-Objekt sein kann. 2.4 Eclipse RCP Die Eclipse Rich Client Plattform8 (RCP) ist eine Plattform f¨ur modulare Desktopanwendun- gen und basiert auf OSGi. Sie ist entstanden aus der Eclipse IDE und deren Versionssprung auf Version 3.0. Die Entwicklung von Eclipse 3.0 bildete die Grundlage f¨ur eine Rich Client Plattform, indem alle Abh¨angigkeiten zu IDE-spezifischen Elementen entfernt und viele Teile des Benutzerinterfaces f¨ur die Anpassung durch den Entwickler ge¨offnet wurden. Die Abbildung 2.5 zeigt einige wichtige Komponenten der Eclipse RCP: ˆ Equinox ist eine vollst¨andige Implementierung der OSGi Plattform Spezifikation, er- weitert um f¨ur Eclipse RCP-Anwendungen ben¨otigte Komponenten, wie z.B. Extension Registry, Applications und Products, die in der Abbildung 2.5 unter der Eclipse Core Runtime zusammengefasst sind. ˆ Jede Eclipse RCP-Anwendung definiert mindestens eine Application. Applications wer- den mit Hilfe von Extensions definiert, die auf eine Klasse verweist, welche das Interface IApplication implementiert. Diese Klasse ist vergleichbar mit der main-Methode aus Java- Anwendungen und startet die Eclipse RCP Anwendung. ˆ Ein Product ist eine Konfigurationsdatei in der die Eclipse RCP-Anwendung beschrieben wird. Hier werden die Plug-ins, die die Anwendung bilden, aufgelistet und konfiguriert, Icons und Bilder f¨ur das Branding der Anwendung und Startparameter definiert. ˆ Das Standard Widget Toolkit (SWT) ist eine low-level Grafikbibliothek, welche die Standard Bedienelemente wie Listen, Men¨us, Schriftarten und Farben zur Verf¨ugung stellt und die nativen UI-Widgets des zugrunde liegenden Betriebssystems kapselt. SWT 8siehe [MLA10] S. 7ff
KAPITEL 2. GRUNDLAGEN 17 Abbildung 2.5: Komponenten der Eclipse RCP Plattform9 . ist f¨ur eine Vielzahl von Betriebssystemen verf¨ugbar. Damit sind Anwendungen, die SWT verwenden, sehr leicht portierbar und immer im Look & Feel des Betriebssystems auf dem sie laufen. ˆ JFace ist ein User Interface Toolkit (UI), mit Klassen f¨ur viele g¨angige Aufgaben in der UI-Programmierung, das designt wurde mit dem SWT zusammenzuarbeiten, ohne es zu kapseln. Es beinhaltet Komponenten wie Bild- und Schriftarten-Register, Dialoge, Wizards, Actions, Views und Frameworks f¨ur Databinding und Preferences und bildet damit die Basis des Eclipse UI. ˆ Eclipse Update, genauer Eclipse p2, erlaubt es einen Update-Mechanismus f¨ur eine RCP-Anwendung zu implementieren. Damit l¨asst sich nicht nur die Anwendung auf dem neuesten Stand halten, es ist auch m¨oglich neue Features zu installieren. Updates k¨onnen dann automatisch oder durch Benutzerinteraktion installiert werden. Eine Eclipse RCP Anwendung besteht also immer aus einem oder mehreren Plugins und wird zusammen mit seiner Laufzeitumgebung ausgeliefert. 2.4.1 Extensions Ein Plug-in ist von einem Bundle nur durch die plugin.xml zu unterscheiden, die sich im Root- Ordner des Plug-ins befindet und optional ist. In dieser Datei werden Extensions und Extension- Points deklariert. 9Quelle: http://www.ralfebert.de/rcpbuch/overview/
KAPITEL 2. GRUNDLAGEN 18 Mit Extension Points10 ¨offnen sich Plug-ins f¨ur Erweiterungen (Extensions) durch andere Plug-ins. Diese Extensions k¨onnen Implementierungen von Interfaces sein, aber auch Daten wie z.B. Icons oder Text. F¨ur jeden Extension-Point wird, mit Hilfe der Eclipse IDE, ein XML Schema-Dokument (XSD-Datei) hinterlegt, in dem beschrieben wird, welche Daten eine Exten- sion zur Verf¨ugung stellen muss. Extension Points und Extensions werden von der Extension Registry verwaltet und sind verf¨ugbar, sobald das dazugeh¨orige Plug-in den Status ” resolved“ hat. Extensions werden bei der Extension Registry abgefragt und nach dem ” lazy-loading“ Prinzip bei Bedarf geladen. Extensions sind ein fundamentales Konzept in der Entwicklung von Eclipse-RCP Anwen- dungen. So sind UI-Elemente wie Views, Editoren und Perspektiven vom Entwickler erstellte Extensions, zu von der Ecplipse RCP bereitgestellten Extension Points. Da diese Elemente in nur einer Datei (und nicht z.B. auf mehrere Java-Klassen verteilt) beschrieben werden, ist es f¨ur einen Ecplipse RCP-Entwickler einfach, sich in eine bestehende Anwendung einzuarbeiten bzw. diese zu erweitern. Listing 2.2 zeigt den Ausschnitt aus einer g¨ultigen plugin.xml, in der eine Application (Zeilen 1-8) und eine View (Zeilen 9-14) deklariert werden. 1 <extension id="application" 2 point="org.eclipse.core.runtime. applications "> 3 <application > 4 <run 5 class="de.fxsolution.client. Application"> 6 </run > 7 </application > 8 </extension > 9 <extension point="org.eclipse.ui.views"> 10 <view 11 class="...ui. singleaccount . AccountList " 12 id="de.fxsolution.client.ui. AccountList " 13 name=" AccountList "> 14 </view > 15 ... Listing 2.2: plugin.xml 2.4.2 Synchronisation von Datenmodell mit UI-Elementen Eclipse RCP unterst¨utzt explizit das Trennen von Datenmodell, Zugriff auf das Datenmodell und Pr¨asentation des Datenmodells (MVC-Pattern). Diese Trennung in Komponenten hat den Vorteil, dass die jeweilige Implementierung an sich ¨andernde Anforderungen angepasst werden kann, ohne dass dies Konsequenzen f¨ur die anderen Komponenten haben muss. Damit wird die Anwendung besser struktiert und ist leichter wart- und testbar. 10siehe [MLA10] S. 390ff
KAPITEL 2. GRUNDLAGEN 19 Um das Datenmodell zu kapseln und mit dem Benutzerinterface zu synchronisieren, bietet die Eclipse RCP zum einen das, aus der Android Entwicklung bekannte, Konzept des Content Providers und das JFace Data Binding Framework an. Beide Konzepte wurden evaluiert, jedoch wird nur der Content-Provider genutzt. Auf die Verwendung des JFace Data Binding Framework musste aus Zeitgr¨unden verzichtet werden. Es wird der Vollst¨andigkeit halber im Anhang auf der Seite 57 vorgestellt. 2.4.2.1 Content Provider Content Provider11 sind Klassen, die ein spezifisches Interface, aus dem Package org.eclipse.jface.viewers, implementieren und Zugriff auf Daten gew¨ahren. Content Provider bieten den Vorteil, dass sie sehr leicht zu implementieren sind. Die Abbildung C.1 auf Seite 59 zeigt am Beispiel eines TreeViewers, wie ein UI-Element mit einem Contentprovider verkn¨upft wird und wie dieses Element, mit Hilfe der Methode getChil- dren(), Daten bezieht. Ein TreeViewer ist eine Komponente, die Elemente in einer Baumstruk- tur, ¨ahnlich dem Windows Explorer, anzeigt und bezieht Daten entweder von einem ITreeCon- tentProvider oder von einem BaseWorkbenchContentprovider und dazu geh¨origen IWorkben- chadaptern. ¨Andert sich das Datenmodell, dann m¨ussen die UI-Elemente, mit der Hilfe von Listenern, dar¨uber informiert und die Daten erneut vom Content Provider geladen werden. 11siehe [MLA10] S. 73ff
Kapitel 3 Anforderungsanalyse Die im Rahmen dieser Arbeit entwickelte Anwendung stellt einen Prototyp f¨ur den Handel von Devisen dar. Sie soll die Broker-APIs kapseln und deren Funktionalit¨aten mit einem ein- heitlichen Benutzerinterface zu Verf¨ugung stellen. Weiterhin soll Sie es erm¨oglichen Einzelkon- ten, die bei unterschiedlichen Brokern liegen k¨onnen, zu einem PAMM-Konto zusammenzu- fassen. Diese PAMM-Konten sollen dann manuell oder mit Hilfe von automatischen Handelssys- temen gehandelt werden k¨onnen. Um diese Ziele zu erreichen, wird im ersten Teil dieses Kapitels ermittelt, was Broker an APIs zur Verf¨ugung stellen. Daraus werden die funktionalen und nicht-funktionalen Anforderungen an die Software abgeleitet, die im zweiten Teil formuliert werden. 3.1 Markt¨ubersicht 3.1.1 Broker-APIs Nach einer Recherche bei g¨angigen Forex-Brokern (siehe Tabelle D.1 auf Seite 71) zeigte sich, dass deren APIs in 3 Arten gegliedert sind: Zum einen unterst¨utzen die meisten Broker das Financial Information eXchange (FIX)- Protokoll. Alle untersuchten Broker bieten weiterhin eigene APIs an, wobei der Zugriff auf historische Preisdaten meist - von den reinen Trade-Funktionalit¨aten getrennt - in einer eigenen API zu finden ist. Als Programmiersprachen, werden C++ und/oder Java unterst¨utzt. 3.1.1.1 FIX-Protokoll Das FIX-Protokoll1 ist ein Nachrichtenstandard, der speziell f¨ur den Handel von Wertpapieren in Echtzeit entwickelt wurde. Das FIX-Protokoll ist offen und frei verf¨ugbar und liegt aktuell in der Version 5.0 Service Pack 2 vor. Es ist komplett Nachrichtenbasiert und definiert eine 1vgl. [FP]
KAPITEL 3. ANFORDERUNGSANALYSE 22 Reihe von Nachrichten, die in Session- und Anwendungsnachrichten unterteilt sind, und darin erlaubte Felder. Diese Nachrichten k¨onnen zum einen in reiner Textform vorliegen, wobei ein Feld wie folgt aufgebaut sein muss: < TAG >=< V ALUE >< DELIMITER > z.B.: ” 8=FIX.4.4;“. Sie k¨onnen aber auch, nach dem FIX-XML Standard, in XML-Form sein. Zu den Session-Nachrichten geh¨oren unter anderem Logon-, Heartbeat- und Logout- Nachrichten. Zu den Anwendungsnachrichten geh¨oren z.B. Nachrichten die zum ¨Offnen, Schließen oder ¨Andern eines Trades versendet werden aber auch um Tickdaten zu abon- nieren oder um History-Daten abzufragen. Dabei liegt es nat¨urlich am Broker, inwieweit er alle M¨oglichkeiten unterst¨utzt. Das FIX-Protokoll ist der Quasi-Standard, f¨ur den Handel an allen großen B¨orsenpl¨atzen dieser Welt, wobei die Versionen 4.2 und 4.4 noch weit verbreitet sind. Von den untersuchten Brokern unterst¨utzen, bis auf OEC und Gain Capital, alle Broker dieses Protokoll. Dadurch w¨ahre es optimal f¨ur ein Broker-¨ubergreifendes Programm zum De- visenhandel. Es ist allerdings nur f¨ur institutionelle Trader gedacht. So verlangen die Broker, welche das FIX-Protokoll unterst¨utzen, entweder hohe Lizenzgeb¨uhren und dazu monatliche Geb¨uhren oder es wird ein Konto mit einer hohen Mindestgr¨oße f¨ur das Kontoguthaben ver- langt. Ohne diese Voraussetzungen zu erf¨ullen, ließen sich auch keine Testprogramme erstellen. Aus diesem Grund wurde f¨ur diese Arbeit darauf verzichtet, das FIX-Protokoll zu imple- menteren. 3.1.1.2 Zugriff auf Handelsfunktionalit¨aten Alle untersuchten Broker unterst¨utzen den Handel von Devisen ¨uber eine eigene API. Die APIs sind dabei sehr unterschiedlich. Sie reichen von dem komplett auf Nachrichten basierten FIX- API, ¨uber den entfernten Aufruf von Methoden (RPC), bis zu einer Mischung aus beiden. So bietet z.B. FXCM eine Java-API an, welche das FIX-API in entsprechende Java-Klassen kapselt und damit komplett auf Nachrichten basiert. Zum Er¨offnen eines Trades muss hier eine Nachricht verschickt werden, wobei zum Setzen eines Stop- und Limit-Preises jeweils eine weitere Nachricht versendet werden muss. Stop- und Limit-Preis k¨onnen also auch erst gesetzt werden, nachdem der Trade ge¨offnet wurde. Als Antwort werden vom Broker, bei Erfolg, drei Executionreports, ein Positionreport und ein Collateralreport versendet, die alle auch ausge- wertet werden m¨ussen. Bei Dukascopy hingegen muss nur eine Methode aufgerufen werden, wobei hier direkt Stop- und Limit-Preis gesetzt werden k¨onnen. Als Anwort erh¨alt man vom Broker nur eine auszuwer- tende Nachricht. Dies und die folgenden Merkmale m¨ussen bei der Planung der Anwendung ber¨ucksichtigt werden, da diese nur Funktionalit¨aten haben kann, die alle Broker anbieten.
KAPITEL 3. ANFORDERUNGSANALYSE 23 Alle APIs erlauben die auf Seite 8 im Abschnitt 2.1.4 aufgelisteten Ordertypen. Teilweise k¨onnen auch noch zus¨atzliche Ordertypen verwendet werden, wie z.B. der Trailing Stop. Hier wird der Stop-Preis, beim Erreichen von bestimmten Zielen, automatisch nachgezogen. Von Broker zu Broker unterschiedlich, ist auch die Anzahl der unterst¨utzten W¨ahrungspaare. Diese reicht von 35 bis zu ¨uber 100 W¨ahrungspaaren. Alle Broker erlauben den Handel der sogenannten Majors, also EUR/USD, GBP/USD, AUD/USD, NZD/USD, USD/CHF und USD/JPY. 3.1.1.3 Zugriff auf Preisdaten Alle Broker, bis auf Dukascopy, unterscheiden zwischen Tick-Daten und dem Zugriff auf History- Daten. Die Tick-Daten werden ¨uber das eigene Trade-API und, falls vorhanden, ¨uber das FIX-API angeboten. Um Tickdaten zu erhalten, m¨ussen sie f¨ur jedes W¨ahrungspaar abboniert werden. Die Tickdaten werden dann unter Benutzung der Push-Technologie verteilt. Teilweise m¨ussen diese auch abboniert sein, um den Handel ¨uber die API zu erm¨oglichen. Der Zugriff auf History-Daten ist meist nur eingeschr¨ankt m¨oglich. Sie k¨onnen meist nur ¨uber ein extra API oder ¨uber das FIX-API abgefragt werden. Die Verf¨ugbarkeit von Preisdaten schwankt stark in der Genauigkeit der Daten. So sind teilweise nur Daten auf Tagesbasis f¨ur einen gr¨oßeren Zeitraum und genauere Daten wie z.B. auf Minutenbasis nur f¨ur einen kurzen Zeitraum verf¨ugbar. Das ist insbesondere f¨ur automatische Handelssysteme, wenn sie auf vergangene Zeitr¨aume getestet werden sollen, aber auch f¨ur Indikatoren, die einen großen Zeitraum analysieren, von Bedeutung. Hier werden m¨oglichst genaue Daten f¨ur einen m¨oglichst großen Zeitraum ben¨otigt, im Falle des Backtesting der Handelssysteme am besten Tickdaten. Weiterhin muss ber¨ucksichtigt werden, dass sich Broker in unterschiedlichen Zeitzonen befinden k¨onnen, was zu unterschiedlichen Daten f¨ur den gleichen Zeitraum f¨uhrt. So ist es m¨oglich, dass ein Broker auch Daten f¨ur Sonntage offeriert, obwohl der Handel erst am Montag um 0 Uhr beginnt. Zusammenfassend muss eine einheitliche L¨osung gefunden werden, bei der ein m¨oglichst umfangreicher Zugriff auf historische Preisdaten gegeben ist. Diese L¨osung sollte unabh¨angig von einem Broker sein. Hier gibt es zum einen die M¨oglichkeit auf externe Anbieter von History-Daten zur¨uckzu- greifen. Anbieter wie Google oder Yahoo offerieren B¨orsendaten kostenlos ¨uber eine einfache API, mit der Daten als csv-Dateien exportiert werden k¨onnen. Diese Daten sind allerdings um 15-Minuten verz¨ogert und damit f¨ur den Live-Handel nicht brauchbar. Andere Anbieter wie z.B. eSignal (www.esignal.com), netdania (www.netdania.com) oder iqfeed (www.iqfeed.net) bieten Live-Forex-B¨orsendaten zu einem Preis von ca. 100$ im Monat an, was je nach Paket und Anbieter differiert. Eine weitere M¨oglichkeit ist das Aufbauen einer eigenen Datenbasis. Dazu k¨onnten History- Daten von einem kostenlosen Anbieter heruntergeladen werden - am besten am Wochenende,
KAPITEL 3. ANFORDERUNGSANALYSE 24 wenn die B¨orsen geschlossen sind - und dann mit Hilfe der Tickdaten, die jeder Broker ¨ubermit- telt, gepflegt werden. Diese L¨osung hat den Vorteil, dass sie Broker-¨ubergreifend funktioniert - damit keine Abh¨angigkeiten aufweist - und keine Kosten durch externe Datendienste enstehen. Bei Hard- oder Softwareproblemen oder bei Ausfall der Internetverbindung kann es jedoch zu L¨ucken in der Datenbasis kommen. Die letzte L¨osungsvariante soll im Rahmen dieser Arbeit verwirklicht werden. 3.1.1.4 Zugriff auf Indikatoren FXCM und Dukascopy unterst¨utzen als einziges den Zugriff auf Indikatoren-Daten bzw. das Erstellen von eigenen Indikatoren ¨uber APIs. Bei FXCM k¨onnen Indikatoren-Daten ¨uber das Order2Go SDK abgefragt werden und mit Hilfe eines Indicator SDK eigene Indikatoren erstellt werden. Als Programmiersprache wird hierf¨ur Lua verwendet. Bei Dukascopy werden Indikatoren in Java erstellt und m¨ussen das IIndicator-Interface implementieren. Beide bieten eine Vielzahl von fertigen Standard- Indikatoren und unterst¨utzen damit das Erstellen von automatischen Handelssystemen. Zusammenfassend fehlt auch hier eine einheitliche und Broker ¨ubergreifende L¨osung, zu- mindest was die APIs der Broker betrifft. Aus diesem Grund wurde sich, im Rahmen dieser Arbeit entschieden, eine eigene Basis f¨ur das Erstellen von Indikatoren und damit auch f¨ur das Erstellen von automatischen Handelssystemen zu schaffen. 3.1.2 Unterst¨utzte Software Um den Devisenhandel mit Hilfe automatisierter Handelssysteme zu erm¨oglichen, unterst¨utzen die meisten Broker die Software externer Anbieter. Diese reichen von kostenloser und durchaus empfehlenswerter Software wie den Metatrader von MetaQuotes Software, bis hin zu profess- ioneller Chartsoftware von eSignal. Weitere Informationen finden sich hierzu in der Tabelle D.2 auf Seite 73. 3.2 Zielbestimmung Die Anforderungen an die Software ergeben sich aus dem letzten Unterkapitel und aus den allgemeinen Anforderungen an eine Software f¨ur den Devisenhandel. Sie werden in funktionale- und nicht-funktionale Anforderungen unterteilt. 3.2.1 Funktionale Anforderungen Die Anwendung ist in die Aufgabenbereiche: unterst¨utzte W¨ahrungspaare, Kontoverwaltung, Tradeverwaltung und automatische Handelssysteme unterteilt. Die jeweiligen Anforderungen finden sich in den folgenden Unterkaptiteln und in Form von Usecase-Diagrammen auf den Seiten 60 - 62. Das Diagramm f¨ur die W¨ahrungspaare wurde dabei weggelassen.
KAPITEL 3. ANFORDERUNGSANALYSE 25 3.2.1.1 W¨ahrungspaare Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur W¨ahrungspaare: ˆ unterst¨utzte W¨ahrungspaare: Beschreibung: Es sollen die W¨ahrungspaare EUR/USD, GBP/USD, AUD/USD und NZD/USD unterst¨utzt werden. Indikatoren und Handelssysteme m¨ussen Zugriff auf his- torische Preisdaten, aller auf Seite 5 im Kapitel 2.1.1 erw¨ahnten Zeitebenen, und auf aktuelle Tickdaten dieser W¨ahrungspaare haben. Diese Daten sollen kostenneutral zur Verf¨ugung stehen. ˆ W¨ahrungspaare anzeigen: Beschreibung: Es muss eine Liste geben, in der aktuelle Bid- und Ask-Preise angezeigt werden. Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur die W¨ahrungspaare: ˆ unterst¨utzte W¨ahrungspaare: Beschreibung: Es sollten weitere W¨ahrungspaare unterst¨utzt werden. 3.2.1.2 Kontoverwaltung Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur die Kontoverwaltung: ˆ PAMM-Konto anlegen: Beschreibung: Es muss eine Funktion geben um PAMM-Konten anzulegen. Als Eingabe wird ein Name ben¨otigt, der im System eindeutig sein muss. Nachbedingung: Konto wurde angelegt. ˆ PAMM-Konto l¨oschen: Vorbedingung: Es d¨urfen keine Trades in dem PAMM-Konto offen sein. Beschreibung: Es muss eine Funktion geben um PAMM-Konten und darin enthaltene Einzelkonten zu l¨oschen. Nachbedingung: PAMM-Konto und Einzelkonten wurden gel¨oscht. ˆ PAMM-Konten anzeigen: Beschreibung: PAMM-Konten und darin enthaltene Einzelkonten werden in einer Liste angezeigt. ˆ Einzelkonto anlegen: Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Im Einzelkonto sind keine Trades offen. Beschreibung: Ein Einzelkonto kann angelegt werden, dazu muss ein PAMM-Konto ausgew¨ahlt werden. Außerdem m¨ussen ein Broker ausgew¨ahlt und die Zugangsdaten eingegeben werden.
KAPITEL 3. ANFORDERUNGSANALYSE 26 Nachbedingung: Einzelkonto wurde angelegt und dem PAMM-Konto hinzugef¨ugt. Kon- tostatus wird auf Offline gesetzt. ˆ Einzelkonto l¨oschen: Vorbedingung: Es wurde ein Einzelkonto ausgew¨ahlt. Im Einzelkonto sind keine Trades offen. Beschreibung: Es muss eine Funktion geben um Einzelkonten zu l¨oschen. Nachbedingung: Das Einzelkonto wurde gel¨oscht und aus dem PAMM-Konto entfernt. Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur die Kontoverwaltung: ˆ Kontow¨ahrungen: Es sollten als Kontow¨ahrung f¨ur Einzelkonten nicht nur US-Dollar, sondern auch weitere W¨ahrungen unterst¨utzt werden. ˆ PAMM-Konten ¨andern: Es sollte die M¨oglichkeit geben, den Namen von PAMM-Konten zu ¨andern. ˆ Einzelkonto ¨andern: Es sollte die M¨oglichkeit geben, die Daten von Einzelkonten zu ¨andern. 3.2.1.3 Tradeverwaltung Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur die Tradeverwaltung: ˆ PAMM-Trade erstellen: Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Das PAMM-Konto enth¨alt Einzelkonten, die alle online sein m¨ussen. Beschreibung: Das System generiert f¨ur alle im PAMM-Konto enthaltenen Einzelkonten, entsprechend dem Guthaben, jeweils einen Trade und l¨ost ihn aus. Es m¨ussen alle auf Seite 8 im Abschnitt 2.1.4 aufgef¨uhrten Ordertypen unterst¨utzt werden. Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde ausgef¨uhrt. ˆ PAMM-Trade schliessen: Vorbedingung: Es wurde ein PAMM-Trade ausgew¨ahlt, der offen ist. Beschreibung: Es werden der PAMM-Trade und alle dazu geh¨origen Einzeltrades geschlossen. Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde geschlossen. ˆ PAMM-Trades anzeigen: Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Beschreibung: Es werden alle zum Konto geh¨orenden PAMM-Trades gezeigt, getrennt in offene und bereits geschlossene Trades.
KAPITEL 3. ANFORDERUNGSANALYSE 27 ˆ Stop- und/oder Limit-Preis setzen: Vorbedingung: Es wurde ein PAMM-Trade ausgew¨ahlt, der offen ist. Beschreibung: Stop- und Limit-Preis k¨onnen gesetzt werden, wenn sie die auf der Seite 8 in der Tabelle 2.1 aufgef¨uhrten Bedingungen erf¨ullen. Nachbedingung: Stop- und Limit-Preis werden beim PAMM-Trade und bei allen dazu geh¨origen Einzeltrades gesetzt. 3.2.1.4 automatische Handelssysteme Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur automatische Handelssysteme: ˆ Indikator erstellen: Beschreibung: Es muss eine M¨oglichkeit geben, Indikatoren zu erstellen. Der Indikator verf¨ugt ¨uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigen- schaften, die vom Handelsystem gesetzt werden m¨ussen. Diese Eigenschaften k¨onnen vom Typ: String, Integer, Double und Boolean sein. F¨ur jede Eigenschaft k¨onnen minimale und maximale Werte festgelegt werden. Außerdem muss der Indikator eine Eingabem¨oglichkeit f¨ur mindestens ein W¨ahrungspaar und f¨ur eine Zeitebene besitzen. Nachbedingung: Der Indikator wird zum Programm hinzugef¨ugt und kann von Handelssys- temen genutzt werden. ˆ Handelssystem erstellen: Vorbedingung: Das Handelssystem hat Zugriff auf ben¨otigte Indikatoren. Beschreibung: Es muss eine M¨oglichkeit geben Handelssysteme, zu erstellen und zum Pro- gramm hinzuzuf¨ugen. Das Handelssystem verf¨ugt ¨uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigenschaften, die vom Benutzer beim Starten geset- zt werden k¨onnen. Diese Eigenschaften k¨onnen vom Typ: String, Integer, Double und Boolean sein. F¨ur jede Eigenschaft k¨onnen minimale und maximale Werte festgelegt wer- den. Nachbedingung: Das Handelssystem wird zum Programm hinzugef¨ugt und ist vom Be- nutzer ausw¨ahlbar. ˆ Handelssystem starten: Vorbedingung: Die vom Handelssystem geforderten Eigenschaften wurden vom Be- nutzer mit validen Werten gesetzt und es wurde ein PAMM-Konto, ein oder mehrere W¨ahrungspaare und eine Zeitebene ausgew¨ahlt. Beschreibung: Es muss eine M¨oglichkeit geben, ein Handelssysteme zu starten, welches dann mit dem automatischen Handel beginnt. Nachbedingung: Das Handelssystem wird vom Programm mit den ausgew¨ahlten Parame- tern gestartet und erh¨alt, genau wie davon benutzte Indikatoren, Zugriff auf aktuelle und historische Preisdaten.
KAPITEL 3. ANFORDERUNGSANALYSE 28 ˆ Handelssystem stoppen: Vorbedingung: Es wurde ein Handelssystem ausgew¨ahlt. Beschreibung: Es muss eine M¨oglichkeit geben, Handelssysteme zu stoppen. Nachbedingung: Das Handelssystem wird gestoppt. ˆ laufende Handelssysteme anzeigen: Beschreibung: Es muss eine M¨oglichkeit geben, alle laufenden Handelssysteme anzuzeigen. Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur automatische Handelssysteme: ˆ Handelssystem ¨andern: Es sollte die M¨oglichkeit geben, die Eingabe-Parameter bereits laufender Handelssysteme zu ¨andern. 3.2.2 Nicht-Funktionale Anforderungen ˆ Hintergrundfunktionen: Die Anwendung muss die Tickdaten aufzeichnen und die Daten f¨ur die History berechnen, um die von Indikatoren und Handelssystemen ben¨otigten Daten zur Verf¨ugung stellen zu k¨onnen. Diese Funktionen, genauso wie die automatischen Handelssysteme, m¨ussen m¨oglichst 24 Stunden am Tag ohne Unterbrechung laufen. ˆ Mehrbenutzerf¨ahig: Die Anwendung soll in dem Sinne mehrere Benutzer unterst¨utzen, dass gleichzeitig mehrere Benutzer mit dem gleichen Datenbestand arbeiten k¨onnen, ohne dass es ein Login gibt. Alle Benutzer arbeiten also mit den gleichen Rechten, den gleichen Daten und sind vom System nicht unterscheidbar. ˆ Verschl¨usselung der Daten¨ubertragung: Auf eine Verschl¨usselung der Kommunikation wird verzichtet. 3.2.3 Abgrenzungskriterium Die Anwendung ist haupts¨achlich gedacht als Plattform f¨ur automatische Handelssysteme und hat als Zielgruppe erfahrene Trader. Diese sollen zwar die M¨oglichkeit haben in Trades einzu- greifen und selber zu traden. Auf die Anzeige von Charts wird jedoch verzichtet.
Kapitel 4 Entwurf Aus den im letzten Kapitel ermittelten Anforderungen ergeben sich eine Reihe von Fragen, die f¨ur den Entwurf der Anwendungs- und Systemarchitektur entscheidend sind. So m¨ussen eine Reihe verschiedener Aspekte beachtet werden, die unter anderem die Datenspeicherung, die Transaktionsbehandlung, die Integration der Broker-APIs, die Verteilung der Systembe- standteile und die Kommunikation der Kompenenten untereinander betreffen. Dieses Kapitel widmet sich dem Entwurf der Anwendung unter den genannten Gesichts- punkten, dabei werden verschiedene L¨osungsans¨atze vorgestellt und diskutiert. 4.1 System-Architektur Aus den Anforderungen an die Anwendungen ergab sich, dass einige Komponenten m¨oglichst ohne Unterbrechung laufen sollen. Außerdem soll die Anwendung mehrbenutzerf¨ahig sein und den Zugriff auf die Systeme der Broker erm¨oglichen. Eine Trennung in Client und Server ist daf¨ur die beste L¨osung. Daraus ergibt sich eine so- genannte Mehrschichten-Architektur, die sich aus Pr¨asentationsschicht, Datenhaltungsschicht, der Schicht f¨ur die Gesch¨aftslogik und einer Schicht f¨ur die Einbindung der Broker-APIs zusam- mensetzt. In den Abbildungen C.5 und C.6, auf den Seiten 63 bis 63, werden die Schichtenar- chitektur und die Verteilung der Systeme schematisch dargestellt. Der Client ist hier nur f¨ur die Pr¨asentation und Validierung zust¨andig und entlastet damit den Server. Die Gesch¨aftslogikschicht wird auf den Server ausgelagert. Sie agiert als Fassade und kapselt den Zugriff auf die Broker-APIs und auf die Datenschicht. Sie ist der Vermittler zwischen dem eigenen System und den Broker-Systemen und vereinheitlicht die Datenmodelle durch Transformation der zu ¨ubermittelnden Daten. Durch die Trennung in Schichten ergeben sich eine Reihe von Vorteilen. Zum einen ist der Zugriff auf die Daten und auf die externen Systeme gesch¨utzt, da kein direkter Zugriff von außen m¨oglich ist. Zum anderen skaliert die Anwendung sehr gut, da die einzelnen Schichten logisch voneinander getrennt sind und somit ¨uber mehrere Datenbank- sowie Anwendungsser-
KAPITEL 4. ENTWURF 30 ver verteilt werden k¨onnen. Außerdem ergeben sich wiederverwendbare Komponenten, z.B. f¨ur den Zugriff auf Daten oder die Kommunikation zwischen Client und Server. Der Datenzugriff erfolgt ¨uber Data Access Objects (DAOs), die den Zugriff ¨uber Schnittstellen kapseln und deren Implementierung damit leicht austauschbar ist. F¨ur das Verteilen von Daten - zwischen Client und Server - werden Data Transfer Objects (DTOs) verwendet, die nur Daten und keine Anwendungslogik enthalten. 4.1.1 ” Event-Driven-Architecture“ Die Anwendung muss auf eine Vielzahl von verschiedenen Events reagieren, die von externen und internen Systemen ausgel¨ost werden. So k¨onnen z.B. Einzelkonten on- oder offline gehen und Trades nach dem Erreichen bestimmter Ziele automatisch geschlossen oder von automatischen Handelssystemen ausgel¨ost werden. Die Anwendung hat weiterhin nur indirekten Einfluss auf die externen Systeme der Broker. So kann sie zwar Trades und Orders ausl¨osen, wird aber durch Events erst sp¨ater ¨uber die Ausf¨uhrung informiert. Trades und Konten k¨onnen sich damit in verschiedenen Zust¨anden befinden, die ber¨ucksichtigt werden m¨ussen. Eine solche System- Architektur wird als ” Event-Driven“ bezeichnet. 4.1.2 Transaktionen in einer Mehrschichten-Architektur Problematisch ist die Einbindung der externen Systeme, im Kontext von Vorg¨angen die Transak- tionen ben¨otigen. Aktionen die PAMM-Trades oder PAMM-Konten betreffen, m¨ussen in G¨anze auf allen dazugeh¨origen Einzel-Trades bzw. -Konten ausgef¨uhrt werden. Im Gegensatz zu in- ternen Datenbanken gibt es jedoch bei externen Systemen nicht die M¨oglichkeit in Fehlerf¨allen ein Rollback durchzuf¨uhren. Das muss bei der Implementierung ber¨ucksichtigt werden. Es muss damit vor jeder Aktion gepr¨uft werden, ob ben¨otigte Komponenten sich in einem fehlerfreiem Zustand befinden. Sind z.B. die von einer Aktion betroffenen Konten nicht online oder verf¨ugbar, dann muss diese abgebrochen werden. 4.1.3 System-Umgebung Die Anwendung wird f¨ur MS-Windows entwickelt, sollte allerdings m¨oglichst leicht auf an- dere Betriebssysteme portierbar sein. Es wurde sich deshalb f¨ur die Programmiersprache Java entschieden, da sie plattformunabh¨angig ist und man - mit dem Java Native Interface (JNI) - auch auf C-Bibliotheken zugreifen k¨onnte. An dieser Stelle sei erw¨ahnt, dass Java f¨ur Echtzeit-Anwendungen oft kritisch betrachtet wird. Dies liegt daran, dass es unter Java keine M¨oglichkeit gibt, Objekte selbst aus dem Speicher zu entfernen. Diese Aufgabe ¨ubernimmt der Garbage Collector, ein vollautomatischer Speicher- manager. Hierbei kann es zu Full-Garbage-Collections und damit sehr langen Pausen kommen. (Eine Full-Garbage-Collection h¨alt das System komplett an (stop-the-world, Mark-and-Sweep-
KAPITEL 4. ENTWURF 31 Algorithmus), um die Objekte zu analysieren und Speicher freizugeben und zu kompaktieren.) Diese langen Pausen k¨onnen unvorhersehbar eintreffen und in Ihrer Dauer, zumindest beim Standard-Garbage-Collector, nicht beeinflusst werden. Um das Ziel von vorhersagbaren und konstant kurzen Pausen zu erreichen, wurde von Sun der Garbage First (G1) Collector en- twickelt. Hier m¨usste die Anwendung in Langzeittests untersucht und optimiert werden, um optimale Einstellungen zu finden. Aus Zeitgr¨unden konnte das zwar nicht mehr genauer untersucht wer- den, es sei aber auf die Artikelreihe ” Memory Management“ im Java Magazin verwiesen, die mit der Ausgabe 3.2010 beginnt. Weitere Ansatzpunkte k¨onnten die f¨ur kommerzielle Anwendungen gedachten Java-Echtzeit-Plattformen: Java Real-Time System von Sun, WebSphere Real Time von IBM oder JRockit von Oracle sein (siehe [Orac], [IBM] und [Orab]). 4.1.4 System–Plattform Wie bereits beschrieben, muss die Anwendung leicht um weitere Indikatoren und Handelssys- teme erweiterbar sein. Mit der OSGi Plattform, wurde eine optimale L¨osung gefunden, da sie zum Einspielen von Erweiterungen nicht gestoppt werden muss und als Modulsystem diese An- forderung explizit unterst¨utzt. Sie bildet die Grundlage f¨ur die Serveranwendung, w¨ahrend die Clientanwendung auf Eclipse RCP basiert. 4.2 Datenspeicherung Das Datenmodell wurde aus den Erkenntnissen der vorherigen Kapitel extrahiert und ist in Form eines Entity-Relationship-Modells (ERM) auf den Seiten 64 und 65 dargestellt. Um die Beziehungen zwischen den Entit¨aten besser zu kennzeichen, wurde, in Abweichung zu Chen, die ” ist ein“-Beziehung mit einer gestrichelten Linie markiert. Das Datenmodell stellt unterschiedliche technische Anforderungen, an das Persistieren der Daten. Diese sollen in den nachfolgenden Unterkapiteln diskutiert werden. 4.2.1 Trade-, Order- und Kontodaten Bei den Trade-, Order1 - und Kontodaten handelt es sich um gut strukturierte Daten, die leicht zu normalisieren sind. Einzige Besonderheit ist, dass eine Transaktionsbehandlung ben¨otigt wird. So besteht z.B. ein PAMM-Trade aus vielen einzelnen Trades und damit eine Aktion zum Speichern auch aus einzelnen Speicheroperationen, die gemeinsam ausgef¨uhrt und abgeschlossen werden m¨ussen. Nur dann ist die Konsistenz und Integrit¨at der Daten gew¨ahrleistet. 1Der Begriff der Order wird ab hier in zwei verschiedenen Zusammenh¨angen verwendet. Eine Order ist zum einen ein Auftrag an das System, einen offenen Trade zu ¨andern oder zu schließen. Zum Anderen kann ein Trade vom Typ: Pending Order oder Market Order sein.
KAPITEL 4. ENTWURF 32 Damit eignen sich insbesondere relationale Datenbanken f¨ur die Benutzung als Speicherl¨o- sung. Diese sind durch den Einsatz von Index- und Caching-Mechanismen, anderen L¨osungen wie z.B. dem Datei-basierten Speichern ¨uberlegen und bieten meist eine Transaktionsverwal- tung. Weiterhin skalieren Datenbanken sehr gut mit wachsenden Anforderungen, da Sie auf extra Rechner verlagert und geclustert werden k¨onnen. Aus diesem Grund, wird sich f¨ur eine relationale Datenbank als Speicherl¨osung entschieden, genauer MySQL mit der Speicher Engine: InnoDB2 . Die Wahl fiel hierbei auf die InnoDB, da sie im Gegensatz zu MyISAM Transaktionen unterst¨utzt. 4.2.2 Parameterdaten f¨ur automatische Handelssysteme Die automatischen Handelssysteme haben eine unterschiedliche Anzahl von Einstellungspara- metern, mit einem vorgegeben Satz von unterschiedlichen Basis-Datentypen. Diese Parameter werden im Diagramm C.8 als payload bezeichnet. Das Problem ist hier, dass sich eine von System zu System unterschiedliche Anzahl der Einstellungsparameter mit jeweils unterschiedlichen Datentypen nicht so einfach in einer rela- tionalen Datenbank abbilden l¨asst. Eine M¨oglichkeit w¨are das Umwandeln der Parameter-Daten in einen String, wobei die einzelnen Parameter durch einen Delimeter getrennt sind. Eine weitere M¨oglichkeit w¨are das Umwandeln in Bin¨ardaten und das Abspeichern als BLOB3 . Da diese Daten dann Key-Value-Paare darstellen, k¨onnte auch das Verwenden darauf spezial- isierter Key-Value- oder auch NoSQL-DB genannten Datenbanken, wie z.B. BerkleyDB, Mon- goDB oder CouchDB, in Betracht gezogen werden. Bei der geringen Anzahl von Datens¨atzen w¨urde sich eine Datenbank nur f¨ur die Parameter-Daten der Handelssysteme allerdings nicht lohnen. Es wurde sich schliesslich f¨ur das Speichern als serialisierte Objekte entschieden, da keine besonderen Anforderungen vorliegen, die den Einsatz von anderen Speicherformen rechtfertigen w¨urden. 4.2.3 Tick- und Bardaten Wie bereits beschrieben, werden die f¨ur Bars4 ben¨otigten Preise: Open, High, Low und Close aus der Analyse von Rohdaten, den Tick-Daten, gewonnen. Diese Daten werden von den au- tomatischen Handelssystemen und den Indikatoren ben¨otigt. Eine Besonderheit ist, dass z.B. Indikatoren immer Zugriff auf die aktuellen und die his- torischen Daten f¨ur einen bestimmten Zeitraum ben¨otigen. So braucht ein 200er Moving Aver- age auf Tagesbasis immer Zugriff auf die letzten 199 Tagesbars und auf den aktuellen Tagesbar, 2siehe [MySb] 3BLOB (binary large object) ist ein MySQL-Datentyp zum Abspeichern von Bin¨ardaten, siehe [MySa]. 4Anstatt Candlestick wird ab jetzt der Begriff Bar verwendet. Beide stellen Container f¨ur die Preise: Open, High, Low und Close dar und k¨onnen deshalb in diesem Kontext synonym verwendet werden.
KAPITEL 4. ENTWURF 33 um den aktuellen Moving Average zu berechnen. Um ad hoc die Moving Average Werte f¨ur die letzten 4 Bars zu berechnen, m¨ussten also die Tickdaten der letzten 204 Tage ausgewertet werden. Nun ist es kein Problem die Tick-Daten in einer relationalen Datenbank zu speichern. Da- raus dann mit Hilfe von SQL-Abfragen die Bars zu extrahieren, w¨are allerdings eine denkbar langsame L¨osung, bei ca. 100.000 Ticks pro Tag, pro W¨ahrungspaar. Eine einfachere und effizientere L¨osung ist das Berechnen der Bars anhand der laufenden Tickdaten. Dabei wird, um bei den Tagesbars zu bleiben, f¨ur jeden Tag um 0 Uhr ein neuer Bar erstellt und der alte Bar gespeichert. Der neue Bar speichert bei Er¨offnung den aktuellen Marktpreis als Open-, High-, Low- und Close-Preis. Bei jedem Tick wird der Close-Preis gesetzt und gepr¨uft ob ggf. auch High und Low neu gesetzt werden m¨ussen. Da diese Operationen im Arbeitsspeicher ablaufen, sind Sie sehr schnell, auch der Speicherverbrauch ist sehr gering. Das wird f¨ur alle geforderten Zeitebenen und W¨ahrungspaare gemacht. Diese Bar-Daten k¨onnten in einer Datenbank gespeichert werden. Alternativ k¨onnten Tickdaten in Dateiform gespeichert und verschiedene L¨osungen, wie z.B. Apache Hadoop (Eine Implementierung, des von Google ver¨offentlichten Map-Reduce- Verfahrens), der Rapidminer von Rapid-I oder die Programmiersprache R verwendet werden (siehe [Apab], [Whi10], [Rap] und [R F]). Diese sind f¨ur die Analyse großer Datenmengen optimiert. Aus Zeitgr¨unden konnten sie jedoch nicht mehr evaluiert werden. Aus Performancegr¨unden wird deshalb eine Speicherl¨osung auf Dateibasis einer Datenbank- l¨osung vorgezogen. Dazu wird f¨ur jedes W¨ahrungspaar ein Ordner angelegt und darin f¨ur jede Zeitebene eine Datei angelegt. In der Datei werden die Bar-Daten, nach Datum sortiert, in Form von Bin¨ardaten gespeichert. (Mit dieser L¨osung kann auf Indizes verzichtet werden, außer- dem belegen Bin¨ardateien weniger Speicherplatz als Textdateien.) Als Zugriffsmethode wird die NIO-API gew¨ahlt, da diese performanter als die IO-API ist. Beide sind Java-APIs zum Lesen/Schreiben von Daten aus/in Dateien oder Sockets, wobei NIO erst seit dem JDK 1.4 eingesetzt werden kann und unter anderem Locking (Sperrt den Zugriff auf eine Datei durch andere Prozesse) unterst¨utzt. Durch Locking-Mechanismen muss die Integrit¨at und Konsistenz der Daten sichergestellt werden. 4.3 Kommunikationsprotokoll Als Mittel f¨ur die Kommunikation zwischen Client und Server wurde sich f¨ur ein asynchrones Kommunikationsprotokoll entschieden. Diese beruhen auf dem Versenden von Nachrichten und eignen sich insbesondere f¨ur Ereignis gesteuerte Systeme und f¨ur l¨anger laufende Operatio- nen, wenn die zu ¨ubertragenden Daten nicht sehr groß sind. Außerdem l¨asst sich synchrone Kommunikation - also der Aufruf von entfernten Methoden - mit tempor¨aren Warteschlangen simulieren.
KAPITEL 4. ENTWURF 34 Als Framework wurde sich f¨ur den Java Messaging Service5 (JMS) entschieden. JMS seria- lisiert die Nachrichten, im Gegensatz zu XML-Protokollen wie dem synchronen SOAP, die vom Nachrichten-Broker je nach Anwendungszweck persistiert werden. JMS skaliert sehr gut, ist clusterf¨ahig und unterst¨utzt Transaktionen. Tritt z.B. beim Abholen einer Nachricht ein Fehler auf, so bleibt diese beim Message-Broker und kann erneut abgeholt werden. Als weitere M¨oglichkeiten, wurden Apache MINA und insbesondere das JBoss Netty-Project, in Verbindung mit Google Protobuf (Serialisiert Daten in einem besonders kompakten Format.), in Betracht gezogen (siehe [Apac], [JBo] und [Gooa]). Beide werden als hoch performant be- trachtet. So ergeben sich bei Netty in Verbindung mit Google Protobuf, Nachrichten die einen geringeren Speicherverbrauch als JMS-Nachrichten haben und schneller serialisiert und deseri- alisiert werden6 . Aufgrund des hohen Implementierungsaufwands wurde jedoch JMS bevorzugt. 5siehe [Apaa] und [Abt10] Seite 281 ff. 6siehe [eis], ein aufgrund vorhandenem Source-Code nachvollziehbarer Vergleich zwischen Protobuf-, XML- und Java-Serialisierung
Kapitel 5 Implementierung Die im Rahmen dieser Arbeit erstellte Anwendung ist eine verteilte, komponentenbasierte An- wendung. Die einzelnen Komponenten sind durch Schnittstellen und den Event-Admin-Service lose gekoppelt (siehe Komponenten-Diagramm1 , Seite 67). In diesem Kapitel wird die Anwen- dung und die Implementierung der wichtigsten Komponenten beschrieben. 5.1 Events Mit Hilfe des Event-Admin-Service werden Ergebnisse von Client-Auftr¨agen und Sta- tus¨anderungen in Form von Events verteilt. Die Events werden in TradingsystemEvent, Ac- countEvent und OrderEvent unterschieden und ¨uber unterschiedliche Topics publiziert. Die jeweiligen Auspr¨agungen wurden in Form von Enumerations abgebildet (siehe Klassendiagramm C.9, Seite 66). Die Events werden auf Serverseite publiziert, dabei regeln die Komponenten Event-To-JMS und JMS-To-Event die ¨Ubermittlung an den Client. Es werden allerdings nur die f¨ur den Client wichtigen Events ¨ubertragen. Event-To-JMS registriert sich als Eventhandler und wandelt alle im Event enthaltenen Objekte in DTOs um, die nur aus Basisdatentypen bestehen. Auf das Serialisieren der ur- spr¨unglichen Objekte wurde verzichtet2 , um die Kommunikation unabh¨angig von Java zu halten (Der verwendete JMS-Broker erlaubt auch C++, C#, Ruby, Perl, Python und PHP-Clients). JMS-To-Event stellt daraus das urspr¨ungliche Event wieder her und publiziert es auf Client- seite. Dadurch kann das Kommunikationsprotokoll f¨ur das Verteilen von Events jederzeit aus- getauscht werden. 1Auf die Darstellung des Logging-Dienstes wurde aus Gr¨unden der ¨Ubersichtlichkeit verzichtet, da er von fast jeder Komponente verwendet wird. 2Das gilt auch f¨ur vom Client ubertragene Order und an den Client ¨ubersandte Tick-Daten
KAPITEL 5. IMPLEMENTIERUNG 36 1 HashMap <String , Object > eventProperties = new HashMap <String , Object >(); 2 eventProperties .put(APIService.ORDER_EVENT ,OrderEvent. TRADE_CLOSED ); 3 eventProperties .put(APIService.SINGLE_ACCOUNT_ID ,accountID ); 4 eventProperties .put(APIService.EVENT_DATE , new Date(System. currentTimeMillis ())); 5 Event event = new Event("de/pammtrader/core/api/ single_order /FXCM", eventProperties ) Listing 5.1: Beispiel f¨ur ein Trade-Closed-Event Das Listing 5.1 zeigt beispielhaft ein Event, das beim Schließen eines Einzeltrades ausgel¨ost wird. Das Event enth¨alt eine Hashmap und ein Topic. Die Hashmap(Listing 5.1, Zeilen 1-4) enth¨alt das ausgel¨oste Event und dazu geh¨orige Daten. In diesem Beispiel wird nur die ID des zum Event geh¨origen Objekts ¨ubermittelt. Bei Events wo Java-Objekte neu erstellt wurden, ist das komplette Java-Objekt in der Hashmap enthalten, also bei neuen Trades, Orders und neuen Konten. Anhand des Topics (Listing 5.1, Zeile 5) l¨asst sich ermitteln, dass es sich bei dem geschlossenen Trade um einen Trade f¨ur ein Einzelkonto beim Broker FXCM handelt. 5.2 Client Der Client basiert auf der Eclipse RCP. Er besteht zum einen aus den Komponenten JMS-To- Event und JSM-To-Tick, die f¨ur die Verteilung von Events und Tick-Daten zust¨andig sind. Zum anderen aus dem Controller und GUI-Elementen. Die GUI-Elemente implementieren die Inter- faces IAccountListener und/oder ITickListener und registrieren sich als Dienste (Whiteboard- Pattern) um ¨uber das Eintreffen von Trade-, Konto- und Tickdaten informiert zu werden. Liegen neue Daten vor, so greifen sie darauf ¨uber Content-Provider zu. Der Controller implementiert das Interface IAccountDAO und dient dem Zugriff auf Trade- und Konto-Daten und dem Absetzen von Auftr¨agen an den Server. In den folgenden Un- terkapiteln, wird die Benutzeroberfl¨ache des Clients kurz n¨aher erl¨autert. 5.2.1 Login-Ansicht Abbildung 5.1: FxTrader Client - Login Nach dem Start der Client-Anwendung ¨offnet sich als erstes das Login-Fenster (siehe Abbil- dung 5.1). Hier muss die Server-Adresse inklusive des Ports vom JMS-Broker angegeben werden.
KAPITEL 5. IMPLEMENTIERUNG 37 Bei einer lokalen Installation w¨are ” localhost:61616“ ein valider Wert, wenn der Standardport benutzt wird. Konnte die Verbindung zum Server hergestellt werden, dann initialisiert die Anwendung Kontodaten, Tradedaten und Handelssystemdaten. Dazu wird ein RPC simuliert, indem eine tempor¨are Warteschlange (Queue) erzeugt wird. Im Nachrichten-Header ” JMSReplyTo“ wird dieser als Anwort-Queue gesetzt und dem Server bei der Anfrage ¨ubermittelt. Nachdem der Server geantwortet hat, werden die Daten initialisiert. Dann tr¨agt sich die Anwendung als Empf¨anger von Tickdaten und Events in die entsprechenden Topics ein, und startet die Haup- tansicht. 5.2.2 Hauptansicht Symbolübersicht Kontenübersicht Handelssysteme Tradeübersicht Abbildung 5.2: FxTrader Client - GUI Die Benutzeroberfl¨ache (siehe Abbildung 5.2) wurde nach der Workbench-Metapher3 gestal- tet und ist in Men¨uzeile, Toolbar und Hauptfenster unterteilt. Die in den Usecases definierten Aktionen k¨onnen entweder ¨uber Kontextmen¨us, Men¨uzeile oder Toolbar ausgel¨ost werden. Diese Aktionen sind meist nur erlaubt, wenn ein dazu passendes Element ausgew¨ahlt wurde. So muss z.B. um einen Trade auszul¨osen ein PAMM-Konto ausgew¨ahlt werden. Das Hauptfenster ist un- terteilt in Symbol¨ubersicht, Konten¨ubersicht, Trade¨ubersicht und einer ¨Ubersicht aller laufend- en automatischen Handelssysteme. 3siehe [Rei09] Seite 52ff
KAPITEL 5. IMPLEMENTIERUNG 38 5.2.2.1 Symbol¨ubersicht Die Symbol¨ubersicht soll dem Benutzer eine Markt¨ubersicht geben und zeigt alle handelbaren W¨ahrungspaare, mit aktuellen Bid- und Ask-Preisen. Symbole k¨onnen der Liste hinzugef¨ugt und aus ihr entfernt werden. 5.2.2.2 Konten¨ubersicht Die Konten¨ubersicht stellt PAMM-Konten und darin enthaltene Einzelkonten in einer Baum¨ubersicht dar. Hier k¨onnen PAMM- und Einzelkonten angelegt und gel¨oscht werden. Außerdem k¨onnen PAMM-Trades ausgel¨ost werden, allerdings nur wenn alle darin enthalte- nen Einzelkonten online sind. Einzelkonten werden mit einem roten Symbol, wenn sie offline sind, oder mit einem gr¨unen Symbol, wenn sie online sind, dargestellt. 5.2.2.3 Trade¨ubersicht In der Trade¨ubersicht werden nach PAMM-Konten getrennt offene und bereits geschlossene PAMM-Trades angezeigt. Sie wird durch einen Doppelklick auf ein PAMM-Konto in der Kon- ten¨ubersicht ge¨offnet. Bei offenen Trades k¨onnen nachtr¨aglich Stop- und Limit-Preis gesetzt bzw. ge¨andert werden. Weiterhin k¨onnen hier Trades geschlossen werden. 5.2.2.4 Automatische Handelssysteme Hinweise für den Benutzer Abbildung 5.3: FxTrader Handelssysteme - Eingabe von Parametern Diese ¨Ubersicht zeigt alle offenen Handelssysteme an, sie k¨onnen hier gestartet und gestoppt werden. Um ein Handelssystem zu starten, wird ein Wizard (siehe Abbildung 5.3) ge¨offnet. Auf der ersten Seite wird das Handelssystem ausgew¨ahlt und allgemein g¨ultige Parameter, also W¨ahrungspaar, Zeitebene und Konto, eingegeben. Die n¨achste Seite wird anhand der vom Han- delssystem vorgegebenen Parameter erstellt. Es werden automatisch, f¨ur Java-Basisdatentypen (außer Boolean), Eingabefelder und f¨ur Parameter mit vorgegebenen Auswahlm¨oglichkeiten
KAPITEL 5. IMPLEMENTIERUNG 39 (inklusive Boolean) Dropdown-Listen erstellt. Der Wizard ¨uberpr¨uft die Eingaben auf Validi- t¨at, f¨uhrt die Konvertierung durch und gibt dem Benutzer verschiedene Hilfestellungen in Form von Popup-Meldungen und Hinweisen im oberen Bereich. Sind alle Einstellungen valide, dann kann der Wizard abgeschlossen und die Daten an den Server gesendet werden. Der Server initialisiert und startet dann das Handelssystem. 5.3 Server Der Server basiert auf OSGi, siehe Komponentendiagramm C.10, Seite 67. Die Server- Komponenten werden jeweilig in Form von Bundles ausgeliefert, dabei sind Schnittstellen und Implementierung getrennt. Die Schnittstellen der Server-Komponenten finden sich in Klassendi- agrammen auf den Seiten 69 und 70, letztere enth¨alt zus¨atzlich die Klassen der Handelssysteme und Indikatoren. In diesem Kapitel wird auf die Implementierung eingegangen. Anmerkung: Der im Diagramm C.10 gezeigte JMS-Broker wird in Form eines Bundles aus- geliefert. Hier wird nur ein Objekt vom Typ ” org.apache.activemq.broker.BrokerService“ ini- tialisiert und der Dienst gestartet, auf eine weitere Beschreibung wird deshalb verzichtet. 5.3.1 Broker-APIs Die APIs der Broker Dukascopy und FXCM wurden implementiert. Sie werden jeweils in einem OSGi-Bundle ausgeliefert, das aus Bundle-Activator, API-Controller, der Broker-API und einer Klasse f¨ur ein Einzelkonto dieses Brokers besteht. Der Bundle-Activator erstellt beim Start des Bundles ServiceTracker f¨ur LogService, Event- admin und ITickReceiver (siehe Listing 5.2, Zeilen 2-4). API-Controller und Konten greifen ¨uber entsprechende Methoden auf diese Services zu, um zu loggen und um Events und Tickdaten zu versenden. Weiterhin initialisiert er den API-Controller und registriert ihn als Dienst unter dem Interface APIService (siehe Listing 5.2, Zeilen 5-10). 1 ServiceTracker tickListenerTracker = new ServiceTracker 2 (context , ITickReceiver .class.getName (), null ); 3 tickListenerTracker .open (); 4 DukascopyAPIService dukascopyApi = new DukascopyAPIService (); 5 Dictionary <String , String > properties = new ... 6 properties.put(APIService.BROKER_API , DukascopyAPIService . SERVICENAME ); 7 bundleContext . registerService (APIService.class.getName (), dukascopyApi , properties ); Listing 5.2: Ausschnitt aus Bundle-Activator einer Broker-API Beim Registrieren wird eine Service-Property ¨ubergeben, die den Namen des Broker enth¨alt, dadurch lassen sich die Broker-Dienste nach Namen filtern. Der API-Controller fungiert als Fas- sade, erstellt Einzelkonten und steuert den Zugriff darauf. Er vermittelt durch Transformation der Daten, zwischen dem eigenen System und dem Broker-System. So versteht z.B. Dukascopy unter einem Lot nicht 100.000$ sondern 1.000.000$ und bildet ein W¨ahrungspaar ¨uber die eigene Klasse Instrument ab, was hier entsprechend umgewandelt wird.
KAPITEL 5. IMPLEMENTIERUNG 40 Jedes Einzelkonto wird Broker-spezifisch abgebildet, stellt unabh¨angig von anderen Konten eine Verbindung zum Broker her und bleibt aus Performancegr¨unden immer verbunden. Sie leit- en die Auftr¨age des API-Controller an den Broker weiter und publizieren ¨uber Events wie, wann und ob diese Auftr¨age abgewickelt wurden. Außerdem publizieren Sie sofort das ¨Andern von Konto- und Tradestatus und das aktuelle Kontoguthaben. Das Kontoguthaben wird allerdings in einem Intervall von 10 Sekunden publiziert. Erst mit dem Publizieren des Kontoguthabens wird dieses Konto als online betrachtet, um die korrekte Verteilung von PAMM-Trades nach Kontogr¨osse zu gew¨ahrleisten. Jedes Einzelkonto verarbeitet Auftr¨age ¨uber einen eigenen ” Sin- gleThreadExecutor“4 , dadurch wird der API-Controller nicht blockiert. Jedes Einzelkonto kann weiterhin als Publisher von Tick-Daten fungieren, was im Komponenten-Diagramm (Seite 67) als Live-Datafeed-Publisher dargestellt wird. Der Publisher wird durch den PAMM-Controller gew¨ahlt und ver¨offentlicht Tickdaten, an alle Dienste, die sich unter dem Interface ITicklistener angemeldet haben, nach dem Whiteboard-Pattern. Geht das Einzelkonto offline, dann findet eine Neuwahl des Publisher durch den PAMM-Controller statt. Da alle Einzelkonten, egal welcher Broker, als Publisher fungieren k¨onnen, wird die Aus- fallsicherheit dieses Dienstes erh¨oht. 5.3.2 PAMM-Controller Der PAMM-Controller implementiert die Interfaces EventHandler, IPAMMAccountController und IPAMMTradeController und registriert sich als Dienst unter diesen Interfaces. Beim Starten l¨adt er Trade und Kontodaten vom DAO-Service. Er ist der Mediator zwischen Client-Auftr¨agen und Broker-API-Controller. Wird z.B. ein PAMM-Trade ausgel¨ost, dann splittet er diesen in Einzeltrades auf und verteilt sie an die entsprechenden Broker-API-Controller. Er verwaltet die PAMM-Konten, Einzelkonten, PAMM-Trades und Einzeltrades. Er pflegt die jeweilig m¨oglichen Zust¨ande, also OrderStatus, AccountStatus, Tradestatus, indem er Events auswertet, genauer AccountEvents und OrderEvents (siehe Klassendiagramm, Seite 66). Der PAMM-Controller erstellt einen ServiceTracker um das Registrieren und Deregistrieren von Broker-API-Controllern zu ¨uberwachen. Geht ein solcher Controller online, dann initialisert er diesen mit Konto- und Trade-Daten. Geht ein Controller offline, dann setzt er bei allen dazugeh¨origen Einzelkonten den Status auf offline. In dem Aktivit¨atsdiagramm (Abbildung C.11, Seite 68) wird exemplarisch das Verarbeiten eines neuen PAMM-Trades5 dargestellt. Hier werden die einzelnen Vorg¨ange bei der Verar- beitung und das Ausl¨osen von Events gezeigt, aus Platzgr¨unden musste auf das Darstellen der Bearbeitung von Events verzichtet werden. 4siehe [Oraa] 5Unter der Vorbedingung, dass der Trade die in Tabelle 2.1 auf Seite 9 dargestellten Bedingungen erf¨ullt
KAPITEL 5. IMPLEMENTIERUNG 41 5.3.3 Account-, Trade-DAO-Service Wird ein neuer Trade oder ein neues Konto erstellt, so wird das dazugeh¨orige Java-Objekt ¨uber ein entsprechendes Event verteilt. Der DAO-Service registriert sich als Eventhandler und nimmt selbst¨andig das Speichern dieser Objekte vor, weiterhin verarbeitet er ¨Anderungen von Trade- und Kontozust¨anden und speichert sie ab. Die Verbindung zum SQL-Server wird ¨uber einen Connectionpool6 hergestellt. Dieser h¨alt immer eine einstellbare Anzahl von Verbindungen offen und ¨offnet bei Bedarf weitere Verbin- dungen bzw. schließt diese wieder bei Nichtbenutzung. Dadurch muss nicht f¨ur jeden SQL-Befehl eine Verbindung aufgebaut werden, was relative lange dauern kann und die Performance be- eintr¨achtigen w¨urde. SQL-Befehle werden in Rahmen von Transaktionen, um Integrit¨at und Konsistenz der Daten sicherzustellen abgesetzt. Dazu werden Prepared Statements benutzt, um die Performance zu erh¨ohen. 5.3.4 History-Provider 1 FileChannel output = new RandomAccessFile (getFilename (bar), "rw"). getChannel (); 2 long start = output.size()- BAR_SIZE_IN_BYTES ; 3 FileLock lock = output.lock(start ,BAR_SIZE_IN_BYTES , false ); 4 ByteBuffer mapByteBuffer = output.map(FileChannel.MapMode.READ_WRITE , start , BAR_SIZE_IN_BYTES ); 5 mapByteBuffer .putLong(bar.getOpenDate (). getTime ()); 6 ... 7 mapByteBuffer .flip (); 8 output.position(output.size()- BAR_SIZE_IN_BYTES ); 9 output.write( mapByteBuffer ); 10 output.close (); Listing 5.3: Updaten eines Bars mit der NIO-API Der History-Provider ist ein Dienst zum Bereitstellen von historischen Preisdaten, f¨ur die in den Anforderungen genannten W¨ahrungspaare und Zeitebenen. Er implementiert die Interfaces IBarProvider und ITickReceiver. Der History-Provider baut die History-Daten anhand der Tickdaten auf, wie im vorherigen Kapitel beschrieben. Der letzte Bar befindet sich immer im Arbeitsspeicher und wird durch die Tickdaten aktualisiert, dabei wird alle 10 Sekunden ein Backup durchgef¨uhrt. Wird der aktuelle Bar von anderen Komponenten ben¨otigt, so wird eine Kopie dieses Bar als Antwort ¨ubermittelt, w¨ahrend History-Daten aus der Datei geladen werden. Das Listing 5.3 zeigt exemplarisch das Updaten des letzten Bars, der sich immer am Ende der Datei befindet. Im Unterschied zur IO-API, erfolgt der Zugriff auf Dateien ¨uber Channels. Ein Bar belegt 48 Bytes, also werden die letzten 48 Bytes zum exklusiven Schreiben/Lesen geblockt. Der Bar wird dann in Form von Bytes in einen Buffer geschrieben. Zum Schluss wird die Position des Buffers auf 0 zur¨uckgesetzt und der Buffer in die Datei geschrieben. 6siehe [Comb] und [Coma]
KAPITEL 5. IMPLEMENTIERUNG 42 Durch das Schließen des Channels wird die Datei wieder freigegeben. Durch das Locking von Dateiabschnitten ist es m¨oglich, gleichzeitig in die Datei zu schreiben und daraus zu lesen, ohne dass sich diese Prozesse behindern. 5.3.5 Indikatoren Indikatoren (siehe Seite 70) erweitern die abstrakte Klasse Indicator und werden zusammen in einem Bundle ausgeliefert. Um neue Indikatoren zu installieren, muss dieses Bundle geupdatet werden. Indikatoren k¨onnen nur ¨uber statische Methoden der Klasse Indicators bezogen werden. Die Klasse Indicator implementiert das Interface ITickReceiver und ruft bei jedem neuen Tick die abstrakte Methode ” calculateIndicator“ auf. Hier findet dann die Berechnung des aktuellen Indikatorwertes statt. Wird ein Indikator gestartet, so bezieht er History-Daten vom IBarProvider und beginnt mit der Berechnung der Indikatorenwerte. F¨ur die Berechnung werden die ben¨otigten Bardaten im Arbeitsspeicher gehalten und mit Hilfe der Tickdaten selbst¨andig gepflegt, was auch in der Klasse Indicator geregelt ist. 5.3.6 Handelssysteme Handelssysteme k¨onnen eine Vielzahl von Einstellungs-Parametern haben. F¨ur die Parameter und das Handelssystem wurden Java-Annotationen definiert. Die Methoden zum Setzen dieser Parameter und die Klasse des Handelssystems m¨ussen durch Java-Annotationen gekennzeichnet werden. In der Annotation werden die zur Beschreibung des Parameters ben¨otigten Werte und etwaige Standardwerte festgelegt (siehe Listing 5.4). In der Annotation der Klasse wird der Name und die Beschreibung des Handelssystem festgelegt. 1 @Retention( RetentionPolicy .RUNTIME ) @Target( value=METHOD ) 2 public @interface ITradingSystemInputParam { 3 String InputParametername (); 4 String InputDescription () default ""; 5 String [] AllowedStringValues () default {""}; 6 int MinValue () default Integer.MIN_VALUE; 7 int MaxValue () default Integer.MAX_VALUE; } Listing 5.4: Annotation f¨ur eine Methode Handelssysteme (siehe Seite 70) k¨onnen in unterschiedlichen Bundles ausgeliefert werden, die ein oder mehrere Handelssysteme und eine Factory enthalten. Handelssysteme implementieren das Interface ITradingsystem und werden durch die Factory erzeugt, die das Interface ITrad- ingSystemFactory implementiert und sich als Service registriert. Die Factory analysiert beim Starten des Bundles die darin enthaltenen Java-Klassen und generiert daraus die TradingSystemDescription. Zum Analysieren wird die Java-Reflection-Api benutzt. Listing 5.5 zeigt ausschnittsweise wie alle Methoden der Klasse untersucht werden und daraus die Systembeschreibung generiert wird. Diese L¨osung hat den Vorteil, dass jed-
KAPITEL 5. IMPLEMENTIERUNG 43 erzeit neue Handelssysteme zu einem Bundle hinzugef¨ugt werden k¨onnen, ohne dass weitere Konfigurationen notwendig sind. 1 Class <?> clazz = bundle.loadClass( fullClassName ); ... 2 Method [] methods = clazz.getMethods (); 3 for(Method method : methods) 4 { 5 if(method. isAnnotationPresent ( ITradingSystemInputParam .class )) 6 { 7 ITradingSystemInputParam methodAnnotation = method. getAnnotation 8 ( ITradingSystemInputParam .class ); 9 TradingSystemParameterDescription param = new TradingSystemParameterDescription 10 (method.getName (), inputType , methodAnnotation . InputParametername (), 11 methodAnnotation . InputDescription ()); 12 ... Listing 5.5: Annotation f¨ur eine Methode Der TradingSystemController implementiert das Interface ITradingSystemController und ¨uberwacht sich an-/abmeldende ITradingSystemFactories, um die Beschreibung zu laden und systemweit zu publizieren. Mit Hilfe dieser Beschreibung kann dann auf Clientseite der Wizard generiert werden. Der TradingSystemController initialisiert, startet und stoppt die Handelssys- teme. Beim Starten des Handelssystems ¨ubergibt er den ITradingSystemContext, ¨uber den das Handelssystem auf PAMM-Konto und History-Daten zugreift. 5.3.6.1 Installieren von Handelssystemen Bundles k¨onnen ¨uber die OSGi-Konsole installiert werden. Diese Bundles k¨onnen auf der Fest- platte des Rechners oder z.B. auf einem Webserver liegen. Das Listing 5.6 zeigt das Installieren und Starten eines Handelssystems, dessen JAR-Datei sich auf der lokalen Festplatte befindet. 1 osgi > install file:c: Pfad_zur_Datei de. tradingSystem .jar 2 Bundle id is 38 3 osgi > start 38 4 Starting de. tradingSystem Listing 5.6: Handelssysteme installieren 5.3.6.2 Beispiel f¨ur ein Handelssystem Zum Abschluss zeigt das Listing 5.7 einen Ausschnitt aus einem Handelssystem. Bei jedem Tick pr¨uft das System, ob sich schneller und langsamer Moving Average gekreuzt haben und er¨ofnet gegebenenfalls eine neue Position.
KAPITEL 5. IMPLEMENTIERUNG 44 1 MovingAverage slowAVG = Indicators. MovingAverage (Timeframe.D1 , Symbol.EURUSD , 2 200, "SMA", 2); 3 MovingAverage fastAVG = Indicators. MovingAverage (Timeframe.D1 , Symbol.EURUSD , 4 50, "SMA", 2); 5 public void onUpdate(Tick tick) 6 { 7 List <PAMMTrade > tradeList = context. getOpenTrades (Symbol.EURUSD ); 8 if(tradeList != null && tradeList.size ()==0) 9 { 10 if(fastAVG.getValue (1)< slowAVG.getValue (1) && 11 fastAVG.getValue (2)> slowAVG.getValue (2)) 12 { 13 Bar actualBar = context.getBar(Symbol.EURUSD , Timeframe.D1); 14 double closePrice = actualBar.getClose (); 15 16 context.openTrade(magicNumber , TradeType.SELL , Symbol.EURUSD , 17 1, closePrice -0.01 , closePrice +0.01 , closePrice ); 18 } ... Listing 5.7: Beispiel f¨ur ein Handelssystem
Kapitel 6 Software-Test In Rahmen von Tests sollte ¨uberpr¨uft werden, ob die Anwendung die in der Anforderungs- analyse ermittelten funktionalen Anforderungen erf¨ullt. Dazu wurden Tests der grafischen Be- nutzeroberfl¨ache (GUI) und Funktionstests automatisiert durchgef¨uhrt. In GUI-Tests wurden die wesentlichen Funktionen des Benutzerinfaces und die korrekte Ausf¨uhrung auf Clientseite betrachtet. Im Rahmen der Funktionstests, wurden die Schnittstellen der Serverkomponenten untersucht und wie die einzelnen Komponenten auf die Ausf¨uhrung reagieren. Außerdem wur- den Skalierbarkeits-Tests durchgef¨uhrt um Hardwareanforderungen abzusch¨atzen. In diesem Kapitel, wird der Entwurf der zu automatisierenden Tests, Ausf¨uhrung und Ergeb- nisse der Tests beschrieben. Die Testf¨alle entsprechen den Anwendungsf¨allen, die in der An- forderungsanalyse ermittelt wurden. 6.1 Testumgebung Die Tests wurden auf einem Rechner mit einem Intel Core i7-860 Prozessor und 8GB RAM unter Windows 7 x64 ausgef¨uhrt. Client-, Server-Anwendung, JMS-Broker und MySQL-Server liefen w¨ahrend der Tests auf diesem Rechner. Als JMS-Broker wurden ActiveMQ in der Version 5.4.2 und MySQL in der Version 5.1 verwendet. Die Tests wurden unter Eclipse 3.6 als JUnit- Plugin-Test bzw. als SWTBot-Test ausgef¨uhrt. 6.2 GUI-Test Zum Testen des GUI wurden der WindowTester Pro [Goob] von Google und SWTBot (siehe [Eclb], [Rei09] Seite 217ff) von Eclipse evaluiert. Beide sind kostenlos einsetzbar und erlauben das externe Testen von SWT-Anwendungen, d.h. sie agieren wie ein Benutzer und f¨uhren Aktio- nen durch Anklicken von UI-Objekten aus. Sie identifizieren die einzelnen UI-Elemente anhand von IDs und Labels, also nicht anhand ihrer Position. Dadurch bleiben Testf¨alle auch lauff¨ahig, wenn die Benutzeroberfl¨ache um weitere UI-Elemente erweitert wird. Sie unterscheiden sich
KAPITEL 6. SOFTWARE-TEST 46 dadurch, dass beim WindowTester der erste Testlauf manuell ausgef¨uhrt und dabei aufgezeich- net wird. Beim SWT-Bot muss der Tester einen JUnit-Test programmieren. Zum Testen eignete sich schliesslich nur der SWTBot, da die zu testende Anwendung auch JFace-Dialoge benutzt, die vom WindowTester nicht unterst¨utzt werden. 6.2.1 Testobjekte Im Rahmen von GUI-Tests, wird das gesamte System getestet. Testobjekte sind zum einen das GUI des Clients, aber auch das Zusammenspiel zwischen Client- und Serverkomponenten. Ein Anwendungsfall muss ¨uber das GUI ausl¨osbar sein und einen entsprechenden Request an den Server senden. Dieser muss die Aufgabe bearbeiten und Fehler- bzw. Erfolgsmeldungen zur¨ucksenden, die vom Client verarbeitet und auf der Benutzeroberfl¨ache dargestellt werden. Ein Test gilt als bestanden, wenn als Ergebnis des Funktionsaufrufs vom Server ein entsprechendes Event empfangen, vom Controller umgesesetzt und in der GUI angezeigt wurde. Ein Test gilt, nach einem Timeout von 5 Sekunden, als nicht bestanden, wenn ein Element vom SWTBot nicht gefunden wurde bzw. der Server nicht wie erwartet geantwortet hat. 6.2.2 Durchf¨uhrung Um die Tests vorzubereiten musste der Login-Dialog deaktiviert werden, da er vor der Applica- tion startet und damit auch vor SWTBot. F¨ur die Durchf¨uhrung der Tests wurde ein Projekt f¨ur ein SWTBot Test-Plugin erstellt. Bei der Erstellung der Testf¨alle musste dann ber¨ucksichtigt werden, dass Ergebnisse erst nach einer gewissen Zeit vorliegen, da alle Methodenaufrufe zum Erstellen/L¨oschen von Konten, Trades etc. asynchron sind. 1 public CreateAccountTest (String accountName) 2 { this.accountName = accountName ; } 3 @BeforeClass 4 public static void setup () 5 { this.bot = new SWTWorkbenchBot (); } 6 @Parameterized .Parameters 7 public static List <Object []> data () 8 { return Arrays.asList(new Object [][] {{"test1"}, {"test2"}}); } 9 @Test 10 public void canCreatePAMM () throws Exception { 11 bot.menu("Konten"). menu("PAMM erstellen"). click (); 12 bot.shell("Erstelle PAMM"); 13 SWTBotText textField1 = bot. textWithLabel ("Name:"); 14 textField1.setText(accountName ); 15 bot.button("OK"). click (); 16 } Listing 6.1: SWTBot-Test - Testfall: Erstellen eines PAMM-Kontos Das Listing 6.1 zeigt ausschnittsweise den Testfall: PAMM-Konto erstellen. Vor jedem Test- lauf werden eventuell ben¨otigte Objekte wie z.B. der SWTBot oder Testobjekte initialisiert.
KAPITEL 6. SOFTWARE-TEST 47 Der eigentliche Testlauf (siehe Zeilen 12-19) geht dann wie ein Benutzer vor, indem er das Men¨u anklickt und in das sich ¨offnende Dialogfenster entsprechende Daten eingibt. 6.3 Funktionstests Die Serverkomponenten wurden im Rahmen von Funktionstests als JUnit-Tests durchgef¨uhrt. Hier wurde die korrekte Ausf¨uhrung von Funktionsaufrufen in Form von Blackbox-Tests ¨uberpr¨uft. Das heisst, dass die Schnittstellen-Methoden der Komponenten aufgerufen und deren R¨uckgabewerte beziehungsweise das Ausl¨osen von Events gepr¨uft wurde. Ausserdem wurde das korrekte Abspeichern uber”pruft. So m¨ussen z.B. nach dem Erstellen eines PAMM-Kontos ein Event ausgel¨ost und die Kontodaten in der Datenbank gespeichert werden. 6.4 Ergebniss von GUI- und Funktionstests Im Rahmen der Tests stellte sich heraus, dass die Vorbedingungen zum L¨oschen von Einzel- und PAMM-Konten noch nicht gepr¨uft werden. Als schwerwiegender stellte sich heraus, dass der Handel von mehreren FXCM-Konten auf einem Rechner, zumindest mit der derzeitigen Implementierung, nicht mehr m¨oglich ist. So l¨asst sich seit dem Update der API vom 1.4.2011 nur noch das erste FXCM-Konto handeln. Werden weitere FXCM-Konten hinzugef¨ugt, so stellen diese zwar eine Verbindung zum Broker her, ein Ausf¨uhren von Trades ist jedoch nicht m¨oglich und wird mit einer Fehlermeldung vom Broker quittiert. Aus Zeitgr¨unden konnte nicht mehr ermittelt werden, inwieweit sich dieses Problem beheben l¨asst. 6.5 Skalierbarkeits-Test Im Rahmen von Skalierbarkeitstests wurde ¨uberpr¨uft, wie sich der Ressourcenverbrauch des Server-Systems mit steigender Anzahl von Konten ver¨andert. Dazu wurden der Server ohne Einzelkonten und mit 1, 2 und 5 Einzelkonten gestartet. Nach einer Warmlaufphase von einer Minute, wurden jeweils der Maximal- und Minimal-Wert f¨ur Arbeitsspeicher und Threads in einem Zeitraum von 5 Minuten ermittelt. Auf strichprobenartiges Messen wurde verzichtet, da der Garbage Collector die Messungen verf¨alscht h¨atte. Die bei den Tests ermittelten Werte skalieren linear, da jedes Konto unabh¨agig von an- deren Konten eine Verbindung zum Broker herstellt und damit auch gleich viele Threads und Arbeitsspeicher ben¨otigt. Auff¨allig ist der dreimal so hohe Verbrauch von Arbeitsspeicher bei Dukascopy-Konten, im Vergleich mit FXCM-Konten. So muss f¨ur 5 Dukascopy-Konten Ar- beitsspeicher von ca. 150 MB und bei FXCM-Konten in H¨ohe von ca. 50 MB kalkuliert werden. Außerdem ben¨otigen 5 Dukascopy-Konten mit 140 Threads ca. 100 Threads mehr als FXCM- Konten. Der Unterschied l¨asst sich damit erkl¨aren, dass die Dukascopy-API verschiedene Funk- tionialit¨aten zum automatisierten Handel mitbringt, w¨ahrend die FXCM-API ausschliesslich
KAPITEL 6. SOFTWARE-TEST 48 Handelsfunktionalit¨aten beinhaltet. Hier zeigte sich, dass diese APIs nur f¨ur den Handel von Einzelkonten optimiert sind. In weiteren Tests m¨usste die Ausf¨uhrungszeit untersucht werden und wie es sich auswirkt, wenn pro Broker nur eine Verbindung hergestellt wird bzw. wenn mehrere Konten des selben Brokers zu Gruppen zusammengefasst werden und diese Gruppen sich jeweils eine Verbindung teilen. Diese Verbindung m¨usste dann allerdings bei jeder Transaktion auf- und wieder abgebaut werden, da pro Broker-Verbindung nur ein Konto gehandelt werden kann.
Kapitel 7 Fazit Abschließend werden die Ergebnisse der vorliegenden Arbeit vorgestellt. Des Weiteren gibt es einen Ausblick auf m¨ogliche Erweiterungen und zus¨atzliche Untersuchungen. 7.1 Ergebnisse Ziel der Arbeit war es, eine Umgebung zum automatisiertem Handel von PAMM-Konten zu schaffen. Dieses PAMM-Konto sollte Einzelkonten von unterschiedlichen Brokern beinhalten k¨onnen. Dazu wurde eine Komponentenbasierte Client-Server-Anwendung entwickelt und die Java- APIs der Broker FXCM und Dukascopy eingebunden. OSGi und Eclipse RCP bilden die Grund- lage der ”´Event-Driven-Systemarchitektur“, die sich sehr gut bew¨ahrt hat. Die einzelnen Kom- ponenten wurden in unterschiedliche OSGi-Bundles aufgeteilt, die ¨uber Schnittstellen und den Event-Service lose gekoppelt und damit leicht erweiterbar bzw. austauschbar sind. Das Ziel einer leicht erweiterbaren Plattform wurde also erreicht, aufgrund der neu aufge- tretenen Probleme bei FXCM wurde das Ziel mehrere Konten unterschiedlicher Broker gle- ichzeitig zu handeln jedoch nur eingeschr¨ankt erreicht. Aus Zeitgr¨unden konnten weiterhin die Kann-Kriterien nicht mehr erf¨ullt werden. 7.2 R¨uckblick Die im Rahmen der Entwurfsphase getroffenen Entscheidungen wurden f¨ur ein System getrof- fen, das aus einem Anwendungsserver und gegebenenfalls einem Datenbankserver besteht. Sie wurden aus der Absicht getroffen, die Daten so nah wie m¨oglich bei der Anwendung (und damit die Latenz gering) zu halten und eine hohe Performance zu erreichen. Bei steigenden Anforderungen ist es m¨oglich, dass diese L¨osungen nicht so skalieren wie es gew¨unscht oder erforderlich ist. Weiterhin wird man um die Ausfallsicherheit zu erh¨ohen zentralisierte und clusterf¨ahige L¨osungen bevorzugen. In diesen F¨allen sollten die erw¨ahnten
KAPITEL 7. FAZIT 50 alternativen L¨osungsans¨atze in Betracht gezogen werden. Insbesondere scheint hier die L¨osung f¨ur die Ermittlung und Pflege der History-Daten problematisch, da sie einen Single Point of Failure darstellt. 7.3 Ausblick Um die im Rahmen dieser Arbeit entwicklelte Anwendung marktreif zu machen, m¨ussten die Probleme beseitigt und Ausfallsicherheit sowie Sicherheit der Daten erh¨oht werden. Desweiteren sollte das FIX-Protokoll in Betracht gezogen werden, da hier die Anbindungen an die Broker, durch eine eigene Implementierung, besser auf die individuellen Anforderungen zugeschnitten werden k¨onnen. Weiterhin w¨unschenswert w¨ahre das Anzeigen von Charts und Indikatoren, z.B. mit Hilfe des Business Intelligence and Reporting Tools von Eclipse (BIRT Project, [Ecla]). Ausserdem sollte eine M¨oglichkeit geschaffen werden, um Handelssysteme und Indikatoren direkt ¨uber die Anwendung zu erstellen, oder diese aus anderen Brokerprogrammen zu konvertieren.
Literaturverzeichnis [Abt10] Abts, Dietmar: Masterkurs Client/Server - Programmierung mit Java. Vieweg+Teubner, 2010 [Apaa] Apache Software Foundation: Apache - ActiveMQ. http://activemq. apache.org/, Abruf: 21.12.2010 [Apab] Apache Software Foundation: Apache - Hadoop. http://hadoop.apache. org, Abruf: 22.12.2010 [Apac] Apache Software Foundation: Apache - MINA Project. http://mina. apache.org/ [Coma] Commons, Apache: Database Connection Pool API. http://commons.apache. org/dbcp/apidocs/org/apache/commons/dbcp/package-summary.html [Comb] Commons, Apache: Java Class GenericObjectPool. http://commons.apache.org/ pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html [Ebe] Ebert, Ralf: RCP Buch - JFace Data Binding. http://www.ralfebert.de/ rcpbuch/jface_data_binding/, Abruf: 27.03.2011 [Ecla] Eclipse Foundation: BIRT Project. http://www.eclipse.org/birt/phoenix/ intro/ [Eclb] Eclipse Foundation: SWTBot. http://www.eclipse.org/swtbot/ [eis] eishay: Protobuf with option optimize for SPEED. http://www.eishay.com/ 2008/11/protobuf-with-option-optimize-for-speed.html [eSia] eSignal: KnowledgeBase: Technical Analysis Dictionary - MACD. http://kb. esignal.com, Abruf: 13.03.2011 [eSib] eSignal: KnowledgeBase: Technical Analysis Dictionary - Moving Average. http: //kb.esignal.com, Abruf: 13.03.2011 [FP] FIX Protocol, Ltd: FIX Protocoll - Industry-Driven Messaging Standard. http: //www.fixprotocol.org/, Abruf: 28.03.2011
LITERATURVERZEICHNIS 52 [Gooa] Google: Google - Protocol Buffers. http://code.google.com/p/protobuf/ [Goob] Google: WindowTester Pro. http://code.google.com/intl/de-DE/ javadevtools/wintester/html/index.html [IBM] IBM: WebSphere Real Time . http://www-01.ibm.com/software/webservers/ realtime/ [JBo] JBoss Community: JBoss - Netty Project. http://www.jboss.org/netty.html [MLA10] McAffer, J. ; Lemieux, J.-M. ; Aniszczyk, C.: Eclipse Rich Client Platform, Second Edition. Addison-Wesley, 2010 [Mon] Monetary and Economic Department, Triennial Central Bank Survey: For- eign exchange and derivatives market activity in April 2010. http://www.bis. org/publ/rpfx10.pdf?noframes=1, Abruf: 03.01.2011 [Mur06] Murphy, John J.: Technische Analyse der Finanzm¨arkte. FinanzBuch Verlag, M¨unchen, 2006 [MySa] MySQL: Referenzhandbuch : Kapitel 11.4.3. Die Spaltentypen BLOB und TEXT. http://dev.mysql.com/doc/refman/5.1/de/blob.html [MySb] MySQL: Referenzhandbuch : Kapitel 14.2. InnoDB-Tabellen. http://dev.mysql. com/doc/refman/5.1/de/innodb.html [Och04] Ochynski, Dr. W.: Strategien an den Devisenm¨arkten: Eine Anleitung f¨ur die Praxis unter Ber¨ucksichtigung der Euro-Besonderheiten. Betriebswirtschaftlicher Verlag Dr. Th. Gabler/GWV Fachverlage GMBH, Wiesbaden, 2004 [Oraa] Oracle: Java Class Executors. http://download.oracle.com/javase/1.5.0/ docs/api/java/util/concurrent/Executors.html [Orab] Oracle: JRockit. http://download.oracle.com/docs/cd/E13150_01/jrockit_ jvm/jrockit/docs30/index.html [Orac] Oracle: Sun Java Real-Time System. http://java.sun.com/javase/ technologies/realtime/index.jsp [OSGa] OSGi Alliance: OSGi Release 4.2 Core Specification. http://www.osgi.org/ Download/File?url=/download/r4v42/r4.core.pdf, Abruf: 28.12.2010 [OSGb] OSGi Alliance: OSGi Release 4.2 Service Compendium. http://www.osgi.org/ Download/File?url=/download/r4v42/r4.cmpn.pdf, Abruf: 28.12.2010 [R F] R Foundation: The R Project for Statistical Computing. http://www. r-project.org, Abruf: 06.04.2011
LITERATURVERZEICHNIS 53 [Rap] Rapid-i: Rapid Miner. http://www.rapid-i.com, Abruf: 06.04.2011 [Rei09] Reichert, S.: Eclipse RCP im Unternehmenseinsatz. dpunkt.verlag, Heidelberg, 2009 [Whi10] White, Tom: Hadoop - The Definitive Guide. O’Reilly, 2010 [WHKL08] W¨utherich, G. ; Hartmann, N. ; Kolb, B. ; L¨ubken, M.: Die OSGi Service Platform. dpunkt.verlag, Heidelberg, 2008 [Wika] Wikipedia: Candlestick pattern. http://en.wikipedia.org/wiki/Candlestick_ pattern, Abruf: 13.03.2011 [Wikb] Wikipedia: Chart pattern. http://en.wikipedia.org/wiki/Chart_pattern, Abruf: 13.03.2011 [wikc] wikipedia: OSGi Bundle Life-Cycle. http://en.wikipedia.org/wiki/OSGi
Anhang A Glossar Ask: Er¨offnungskurs f¨ur eine Long-Position und Schlusskurs f¨ur eine Short-Position. Bar: Ein Bar ist eine Darstellungsform von High-, Low-, Open- und Close-Preis eines be- stimmten Zeitraums in einem Chart. Im Kontext der Datenspeicherung wird Bar synonym zum Begriff des Candlesticks benutzt. Bid: Er¨offnungskurs f¨ur eine Short-Position und Schlusskurs f¨ur eine Long-Position. Broker: Broker unterhalten Gesch¨aftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. Deutsche Bank, einer der gr¨oßten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf. Candlestick: Eine Darstellungsform von Preisen in einem Chart, siehe Bar. Forex: Forex, steht f¨ur Foreign Exchange, also den Devisenhandel. Indikator: Ein Indikator ist ein Werkzeug der Chartanalyse zur statistischen Analyse von B¨orsendaten. Interbankenmarkt: Der Interbankenmarkt ist der Markt auf dem Banken unter anderem Devisen handeln. Majors: Unter Majors werden die meistgehandelten W¨ahrungspaare verstanden, also EUR/USD, GBP/USD, AUD/USD und NZD/USD. Long-Position: Ist eine Kauforder, mit der auf steigende Kurse gesetzt wird. PAMM: PAMM ist die Abk¨urzung von Percent Allocation Management Module und ist ein Kozept f¨ur ein Sammelkonto.
ANHANG A. GLOSSAR 56 Pip: Entspricht meist der vierten Nachkommastelle des Wechselkurses und ist die Maßeinheit f¨ur Kursbewegungen. Short-Position: Ist eine Verkaufsauforder, mit der auf fallende Kurse gesetzt wird. Spread: Der Spread ist die Differenz zwischen Bid und Ask und entspricht der Geb¨uhr die Broker f¨ur die Ausf¨uhrung eines Trades verlangen. Tick: Ein Tick gibt immer den Bid- und Ask-Preis einer bestimmten W¨ahrung zu einer be- stimmten Zeit an. Trade: Steht f¨ur eine Long- oder Short-Position.
Anhang B JFace Data Binding JFace Data Binding1 bietet eine weitere M¨oglichkeit um Datenmodell und UI-Elemente miteinander zu verkn¨upfen. Im Gegensatz zum Content Provider kann hier auf den Einsatz von eigenen Listener-Objekten verzichtet werden, da das Framework die Synchronisierung au- tomatisch ¨ubernehmen kann. Dazu m¨ussen f¨ur Datenmodell-Objekt und UI-Element sogenannte Observables erstellt werden, dass sind Objekte, die bei Ver¨anderungen ein Ereignis ausl¨osen. Unterst¨utzt werden Datenmodell-Objekte, bei denen es sich um Beans, Objekte die den PropertyChangeSupport gem¨aß der Java Bean Spezifikation implementieren, oder um POJOs (plain old java objects) handelt. Entsprechende Observables werden dann mit Hilfe der Fac- tories: BeansObservables oder PojoObservables erzeugt. Das bedeutet auch f¨ur POJOs, dass getter- und setter-Methoden, f¨ur die zu ¨uberwachenden Eigenschaften des Objekts, immer dem Schema: {get|set}+<Eigenschaftsname(beginnend mit Großbuchstaben)> entsprechen m¨ussen, z.B. getFirstName(), f¨ur die Eigenschaft: firstName. Listing B.1: Beispiel f¨ur ein Binding zwischen Text-Element und DatenModell-Objekt 1 Person person = new Person ... 2 Text firstNameText = new Text ... 3 DataBindingContext bindingContext = new DataBindingContext (); 4 IObservableValue widgetValue = SWTObservables . 5 observeText(firstNameText , SWT.Modify ); 6 IObservableValue modelValue = BeansObservables . 7 observeValue (person , "firstName"); 8 bindingContext .bindValue(widgetValue , modelValue ); ¨Uber ein Binding, das vom DatabindingContext verwaltet wird, werden zwei Observables miteinander verbunden (siehe Listing B.1). F¨ur das Binding k¨onnen verschiedene Update- 1vgl. [Ebe]
ANHANG B. JFACE DATA BINDING 58 Strategien, Konverter2 und Validierer, z.B. um nur Werte gr¨oßer null zuzulassen, festgelegt werden. Das ganze Potential des JFace Data Bindings l¨asst sich im Zusammenspiel mit dem Eclipse Modelling Framework (EMF) ausnutzen, da hiermit passende Modellklassen und Factories erzeugt werden k¨onnen. 2F¨ur einfache Konvertierungen, z.B. von String-Werten zu Integer-Werten, verwendet JFace Data Binding automatisch einen passenden Konverter.
Anhang C Abbildungen /Benutzer /AccountView /TreeViewer /ContentProvider new setContentProvider() setInput(PAMMAccountList) getChildren(PAMMAccountList) Klickt auf ein '+' in der TreeView getChildren(Einzelkonten) Abbildung C.1: Sequenzdiagramm - Content Provider
ANHANG C. ABBILDUNGEN 60 Benutzer PAMM-Kontoerstellen PAMM-Kontolöschen Bedingung: keineoffenenTradesvorhanden EinzelkontoerstellenzuPAMM-Kontohinzufügen<<include>> Einzelkontolöschen ausPAMM-Kontoentfernen <<include>> PAMM-Kontoauswählen <<include>> Brokerapiauswählen <<include>> AbbildungC.2:UsecaseDiagramm-Kontoverwaltung
ANHANG C. ABBILDUNGEN 61 Benutzer/ Handels- system NeuenTradeerstellen PAMM-Kontoauswählen <<include>> Tradeschliessen PrüfePAMM-Konto <<include>> OffeneTradesanzeigen GeschlosseneTradesanzeigen <<include>> <<include>> TradeauswählenStopsetzen Limitsetzen <<include>> <<include>> <<include>><<include>> AbbildungC.3:UsecaseDiagramm-Tradeverwaltung
ANHANG C. ABBILDUNGEN 62 Handelssystemstarten Handelssystemstoppen ZugriffaufIndikatoren ZugriffaufhistorischeChartdaten PAMM-Kontoauswählen <<include>> Handelssystemauswählen <<include>> Handelssystem <<include>> <<include>> <<include>> ZugriffaufliveChartdaten <<include>> ZugriffaufPAMM-Konto<<include>> Handelssystemeinstellen(Eigenschaften) <<include>> System Benutzer <<include>> <<include>> Indikatorerstellen AbbildungC.4:UsecaseDiagramm-Handelssysteme
ANHANG C. ABBILDUNGEN 63 Datenhaltungsschicht Logikschicht Präsentationsschicht externe Systeme Abbildung C.5: Schichten-Architektur Anwendungsserver Broker Externe Clients Interner Client Datenhaltungsserver Abbildung C.6: Verteilungsdiagramm
ANHANG C. ABBILDUNGEN 64 Account statusaccountID accountType name PAMMAccount istein SingleAccounthat 1..m0..n username password accountNumber accountHolder balance equity brokerAPI Trade magicNumber tradeType symbol takeProfit stopLoss requestedVolume filledVolume status errorMessage istein PAMMTradeSingleTrade weightedOpenPrice weightedClosePrice hat openTime closeTime openPrice closePrice hat 1..m0..n 1..m 0..n singleAccountID pammAccountID stopLoss Order orderType accountID tradeID orderIDtakeProfit orderStatus errorMessage AbbildungC.7:ERM-Diagramm:Datentypen(Teil1)
ANHANG C. ABBILDUNGEN 65 Tick bid ask symbol date volume Bar symbol openDate lastUpdate open high low close timeframe TradingSystem id payLoad Abbildung C.8: ERM-Diagramm: Datentypen (Teil 2)
ANHANG C. ABBILDUNGEN 66 <<enumeration>> Symbol +EURUSD +GBPUSD +NZDUSD +AUDUSD -baseCurrency:String -quoteCurrency:String -pipValueInDollar:double -pipValue:double -pipScale:int +valueOf(value:int):Symbol +fromString(symbolString:String):Symbol +fromStringWithDelimeter(symbolString:String):Symbol +inList(symbolString:boolean):boolean <<enumeration>> OrderStatus +CREATED +SEND_TO_SERVER +RECEIVED +SEND_TO_BROKER +FINISHED +REJECTED +valueOf(value:int):OrderStatus <<enumeration>> AccountType +PAMM_ACCOUNT +SINGLE_ACCOUNT_LIVE +SINGLE_ACCOUNT_DEMO +valueOf(value:int):AccountType <<enumeration>> OrderType +SET_SL +SET_TP +SET_SL_TP +CLOSE_TRADE +valueOf(value:int):AccountType <<enumeration>> TradeType +BUY +SELL +BUYLIMIT +BUYSTOP +SELLLIMIT +SELLSTOP +valueOf(value:int):AccountType <<enumeration>> AccountStatus +ONLINE +OFFLINE +RECONNECTING +AUTHENTICATION_FAILED +ERROR +DELETED +RELOGGING +PARTIALLY_ONLINE +NOT_ACK +valueOf(value:int):AccountType <<enumeration>> Timeframe +TICK +M1 +M5 +M15 +M30 +H1 +H4 +D1 +W1 +MN +valueOf(value:int):AccountType <<enumeration>> TradeStatus +CREATED +RECEIVED +SEND_TO_SERVER +SEND_TO_BROKER +ACCEPTED +PARTIALLY_FILLED +FILLED +PARTIALLY_CLOSED +CLOSED +CANCELED +REJECTED +valueOf(value:int):AccountType <<enumeration>> TradingSystemEvent +STARTED +STOPPED +valueOf(value:int):AccountType <<enumeration>> AccountEvent +CREATED +ONLINE +OFFLINE +RECONNECTING +OPEN_TRADE_LIST +CHANGED +DELETED +AUTHENTICATION_FAILED +ERROR +ALREADY_EXIST +ACCOUNT_UPDATE +LOGIN_ERROR +valueOf(value:int):AccountType <<enumeration>> OrderEvent +ORDER_RECEIVED +ORDER_SEND_TO_BROKER +ORDER_FINISHED +ODER_REJECTED +TRADE_CREATED +TRADE_RECEIVED +PENDING_ORDER_ACCEPTED +PENDING_ORDER_CANCELLED +TRADE_SEND_TO_BROKER +TRADE_PARTIALLY_FILLED +TRADE_FILLED +TRADE_CHANGED +TRADE_PARTIALLY_CLOSED +TRADE_CLOSED +TRADE_REJECTED +TRADE_CANCELED +ERROR +TRADE_ALREADY_EXIST +valueOf(value:int):AccountType Order -orderID:String -accountID:String -tradeID:String -takeProfit:Double -stopLoss:Double -orderStatus:OrderStatus -orderType:OrderType -errorMessage:String Bar -symbol:Symbol -openDate:Date -lastUpdate:Date -open:Double -high:Double -low:Double -close:Double -volume:Double -timeframe:Timeframe Tick -symbol:Symbol -date:Date -bid:Double -ask:Double -volume:Double <<abstract>> Account -accountID:String -name:String -balance:Double -equity:Double -status:AccountStatus -accountType:AccountType PAMMAccount SingleAccount -userName:String -password:String -accountHolder:String -accountNumber -brokerAPI:String 1 * <<abstract>> Trade -status:TradeStatus -tradeType:TradeType -symbol:Symbol -takeProfit:Double -stopLoss:Double -requestedVolume:Double -magicNumber:int -errorMessage:String SingleTrade -singleAccountID:String -openTime:Date -closeTime:Date -openPrice:Double -closePrice:Date PAMMTrade -PAMMAccountID:String -weightedOpenPrice:Double -weightedClosePrice:Double 1 * 1 * AbbildungC.9:Klassendiagramm-Datentypen
ANHANG C. ABBILDUNGEN 67 Server Clients Account-, Trade-DAO-Service Indikatoren Live-Datafeed-Publisher Broker- API IAccountController ITradeController benutzt Service: stellt Service zur Verfügung: ITickListener PAMM-Controller IPAMMAccountController, IPAMMTradeController History-Provider IBarProvider Event-Admin-Service Handelssysteme ITradingSystemFactory Client-Task-Dispatcher Broker Datenbank-Server Handelssystem-Controller ITradingSystemController MySQL Event-To-JMS Tick-To-JMS Event-Admin-ServiceJMS-To-Event JMS-Broker (ActiveMQ) JDBC TCP/IP Controller GUI JMS-TO-TICK IAccountListener ITickreceiver ITickreceiver ITickreceiver ITickreceiver IAccountDAO Abbildung C.10: Komponentendiagramm
ANHANG C. ABBILDUNGEN 68 PAMM-Controller Event-Service PAMM-Konto vorhanden? TRADE_REJECTED auslösen enthält Einzelkonten? Einzelkonten online? ja nein PAMM_TRADE_ERROR auslösen nein Berechne Gesamtvermögen nein Fehler Einzeltradevolumen berechnen Einzeltrades erstellen SINGLE_TRADE_CREATED auslösen API-Controller Transformation der Daten Weiterleiten des Trades an Einzelkonten Senden des Trades zum Broker ok Einzelkonten ja ja TRADE_RECEIVED auslösen Fehler Fehler SINGLE_TRADE_ERROR auslösen SEND_TO_BROKER auslösen ok Abbildung C.11: Aktivit¨atsdiagramm f¨ur einen PAMM-Trade
ANHANG C. ABBILDUNGEN 69 <<interface>> IAccountController +addAccount(account:SingleAccount): void +getAccountList(): List<String> +changeAccount(account:SingleAccount): void +removeAccount(singleAccountID:String): void <<interface>> IPAMMAccountController +addAccount(account:SingleAccount): void +getAccountList(): List<SingleAccount> +changeAccount(account:SingleAccount): void +removeAccount(singleAccountID:String,pammAccountID:String): void +addPAMMAccount(PAMMAccount:pammAccount): void +getPAMMAccountList(): List<PAMMAccount> +getPAMMAccount(pammAccountID:String): PAMMAccount +changePAMMAccount(pamm:PAMMAccount): void +removePAMMAccount(pammAccountID:String): void <<interface>> IPAMMTradeController +getOpenTrades(pammAccountID:String): List<PAMMTrade> +getTradeHistory(pammAccountID:String): List<PAMMTrade> +openTrade(pammTrade:PAMMTrade): void +processOrder(order:Order ): void <<interface>> ITradeController +getOpenTrades(singleAccount:SingleAccount): List<SingleTrade> +getClosedTrades(singleAccount:SingleAccount): List<SingleTrade> +openTrade(singleTrade:SingleTrade): void +submitOrder(order:Order): void <<interface>> IBarProvider +getBars(symbol:Symbol,timeframe:Timeframe,count:int): List<Bar> +getBar(symbol:Symbol,timeframe:Timeframe,shift:int): Bar +getBar(symbol:Symbol,timeframe:Timeframe): Bar <<interface>> ITickReceiver +SYMBOL: String +TICK: String +onTick(tick:Tick): void <<interface>> IAccountDAO +saveSingleAccount(singleAccount:SingleAccount): void +savePAMMAccount(pammAccount:PAMMAccount): void +loadPAMMAccount(pammAccountID:String): PAMMAccount +loadPAMMAccounts(): List<PAMMAccount> <<interface>> ITradeDAO +savePAMMTrade(pammTrade:PAMMTrade): void +loadPAMMTradeByTradeID(pammTradeID:String): PAMMTrade +loadPAMMTradeByAccountID(pammAccountID:String): List<PAMMTrade> +loadPAMMTrades(): List<PAMMTrade> +saveSingleTrade(singleTrade:SingleTrade): void +loadSingleTrades(): List<SingleTrade> +loadSingleTrades(pammTradeID:String): List<SingleTrade> +saveOrder(order:Order): void +loadOrder(orderID:String): Order +loadOrders(): List<Order> <<interface>> APIService enthält die Keys für die Hashmaps der DTOs +PAMM_ACCOUNT_ID: String +SINGLE_ACCOUNT_ID: String +TRADE_ID: String +TRADE: String +ORDER_ID: String +ORDER: String +TICKET: String +ORDER_EVENT: String +MESSAGE: String +CLOSE_PRICE: String +OPEN_PRICE: String +OPEN_TIME: String +PROFIT_LOSS: String +FILLED_LOTS: String +ACCOUNT_EVENT: String +OPEN_TRADE_LIST: String +EVENT_DATE: String +EQUITY: String +BALANCE: String +STOP_LOSS: String +TAKE_PROFIT: String +ACCOUNT: String +TRADING_SYSTEM_EVENT: String +SYSTEM_ID: String +TRADING_SYSTEM_INPUT: String Abbildung C.12: Klassendiagramm Server-Interfaces
ANHANG C. ABBILDUNGEN 70 <<interface>> ITradingsystem +initialize(symbol:Symbol[],timeframe:Timeframe): void +getMagicNumber(): int[] +onUpdate(tick:Tick): void +onStart(context :ITradingSystemContext ): void +onStop(): void<<interface>> ITradingSystemContext +getPammAccountName(): String +getBalance(): double +getEquity(): double +getClosedTrades(symbol:Symbol): List<PAMMTrade> +getOpenTrades(symbol:Symbol): List<PAMMTrade> +getTrade(tradeID:String): PAMMTrade +getTrade(symbol:Symbol,magicNumber:int): PAMMTrade +registerTradeListener(listener:OrderListener): void +unregisterTradeListener(): void +openTrade(magic:int,tradeType:TradeType,symbol:Symbol, volume:double,takeProfit:double,stopLoss:double, requestedOpenPrice:double): void +processOrder(order:Order): void +getBar(symbol:Symbol,timeframe:Timeframe): Bar +getBar(symbol:Symbol,timeframe:Timeframe,shift:int): Bar +log(level:int,message:String): void <<interface>> ITradingSystemController +startSystem(dto:TradingSystemInputDTO): void +stopSystem(systemID:String): void +getTradingSystemDescriptions(): List<TradingSystemDescription> +getRunningSystems(): List<TradingSystemInputDTO> <<interface>> ITradingSystemFactory +getTradingSystemDescriptions(): List<TradingSystemDescription> +getInstance(dto:TradingSystemInputDTO): ITradingsystem <<interface>> OrderListener +onOrderEvent(event:OrderEvent,orderID:String, pammTradeID:String): void <<enumeration>> InputType +BOOL +DOUBLE +INTEGER +STRING TradingSystemParameterDescription -methodName: String -inputType: InputType -allowedStringValues: String[] -inputParametername: String -inputDescription: String -minValue: Integer -maxValue: Integer TradingSystemDescription -className: String -systemName: String -description: String -parameterList: List<TradingSystemParameterDescription> <<imlements ITickReceiver, ITradingSystemContext, EventHandler>> TradingSystemContextImpl -system: ITradingsystem -orderListener: OrderListener -symbolArray: Symbol[] -pammAccountID: String +handleEvent(event:Event): void +onTick(tick:Tick): void <<abstract, implements ITickReceiver>> Indicator -timeframe: Timeframe -symbol: Symbol -barList: List<Bar> -history: Integer Anzahl von Indikatorwerten -shift: Integer 0 = aktueller Bar, 1 = letzter Bar -started: boolean #Indicator(timeframe:Timeframe,symbol:Symbol, shift:int,context:BundleContext): Indicator #start(): void +<<abstract>> getName(): String +<<abstract>> getDescription(): String #<<abstract>> calculateIndicator(): void +onTick(tick:Tick): void MovingAverage -period: Integer -method: Integer -maxPeriod: Integer -minPeriod: Integer +getValue(shift:Integer): Double Indicators +MovingAverage(timeframe:Timeframe,symbol:Symbol, period:Integer,method:String, shift:Integer): MovingAverage const Abbildung C.13: Klassendiagramm - Indikatoren und Handelssysteme
Anhang D Tabellen Tabelle D.1: Broker ¨Ubersicht Broker FIX-Support SDK - un- terst¨utzte Sprachen Zugriff auf Preisdaten Webseite Deutsche Bank ja, aber Konto mit mind. 25.000$ Guthaben n¨otig Plattform wurde von FXCM lizensiert siehe FXCM www.dbfx.com Dukascopy ja, aber Konto mit mind. 100.000$ Guthaben n¨otig Version 4.4 Java in SDK integri- ert, Daten auf 10 Sekunden-Basis reichen bis 2003 zur¨uck www.dukascopy .com FXCM ja, aber Konto mit mind. 50.000$ Guthaben erforder- lich Version 4.4 Order2Go: VB, C++, Delphi, JAVA Trad- ing API ¨uber Order2Go und extra SDK, das nur f¨ur kommerzielle Anwendungen verf¨ugbar ist. www.fxcm.com GAIN Capi- tal nein SOAP- Interface TCP/IP Socket- Interface, keine genaueren Infos verf¨ugbar www.forex.com - Fortsetzung n¨achste Seite -
ANHANG D. TABELLEN 72 Broker FIX-Support SDK - un- terst¨utzte Sprachen Zugriff auf Preisdaten Webseite Interactive Brokers ja, 500$ Lizen- zgeb¨uhr zzgl. 100$ monatlich Version 4.4 C++, Java stark begrenzter Zeitraum: z.B. Minutenbars nur f¨ur die letzten 2 Tage www.interactive brokers.com MB Trading ja, nach FIX Gateway Zertfi- fierungstest und Lizenzgeb¨uhr von 250$ zzgl. 50$ monatlich Version 4.4 MBT SDK: VB, C Quote API bzw. ¨uber MBT SDK Tagesbasis - bis zu 10 Jahre. Minutenbasis - bis zu einem Jahr. www.mbtrading .com OEC nein API: .Net 2.0 COM API C++, Delphi nur auf Tagesbasis verf¨ugbar www.openecry .com
ANHANG D. TABELLEN 73 TabelleD.2:Software¨Ubersicht HerstellerNameWebseiteProgrammierspracheverf¨ugbareHistory Interactive Data eSignalwww.esignal.comeSignalFormulaScript,eineEr- weiterungvonJavaScript Tickdatenbiszu40Tage.Intraday-Daten bis2007,aufTagesbasisbis1983 MetaQuotes Software Metatrader4www.mql4.commql4,einefunktionaleSprachemitC- ¨ahnlicherSystax vomBrokerabh¨angig MetaQuotes Software Metatrader5www.mql5.commql5,eineobjektorientierteSprachevomBrokerabh¨angig MultiCharts, LLC MultiChartswww.multicharts .com EasyLanguageunterst¨utztverschiedeneDatenfeeds TradeStation Securities TradeStationwww.tradestation .com EasyLanguage,einefunktionale Sprache,dieandienat¨urlicheSprache angelehntist Intraday-DatenaufMinutenbasis,diebis 2002oderbis2007zur¨uckreichen
Anhang E Installationsanleitung In diesem Kapitel werden die einzelnen Installationsschritte beschrieben. Die dazu ben¨otigten Dateien, sowie Sourcecode und diese Arbeit als pdf-Datei finden sich auf der beiliegenden CD. Zur Durchf¨uhrung der folgenden Schritte muss der Programme-Ordner in ein beliebiges, beschreibares Verzeichnis kopiert werden. Der darin befindliche Client-Ordner kann als einziges auf einen anderen Rechner kopiert werden. 1. Datenbank einrichten: Die Einstellungen f¨ur den Datenbank-Server sind in der Datei ” /Programme/sql.properties“ geregelt. Zur Zeit ist hier ein Datenbank Server der HTW-Berlin eingetragen. Sollte der nicht erreichbar sein, dann muss mit Hilfe der Datei ” /database.sql“ eine Datenbank angelegt und die Properties-Datei entsprechend angepasst werden. 2. History-Daten herunterladen: Als n¨achstes m¨ussen die aktuellen History-Daten heruntergeladen werden. Dazu befindet sich im Ordner Programme die Datei ” historyLoad- er.properties“. In dieser Text-Datei befinden sich die Zugangsdaten f¨ur ein Demokonto des Brokers Dukascopy. Sollten die Zugangsdaten nicht mehr g¨ultig sein, dann muss ein neues Kon- to eingerichtet und eingetragen werden (siehe http://www.dukascopy.com/swiss/english/ forex/demo_fx_account/). Jetz kann das Programm eclipse.exe, das sich im Ordner ” /pro- gramme/historyloader/historyLoader“ befindet aufgerufen werden. Diese Programm l¨adt die letzten 2000 Bars der Majors und speichert sie im Ordner ” /pro- gramme/history“ ab. 3. Abschluss: Damit ist die Einrichtung soweit abgeschlossen. Jetzt muss als erstes der Server gestartet werden, die dazu ben¨otigte Datei heißt ” pammtrader server.exe“ und befindet sich im Ordner ” /programme/server/pammtrader“. Ist der Server gestartet, dann kann die Client- Anwendung ” /programme/client/fxsolution/fxsolution.exe“ gestartet werden. FXCM-Konten lassen sich auf der Webseite: http://www.fxcm.com/ demo-account-country.jsp anlegen, es funktionieren allerdings nur Konten die mit ”´EUD“ beginnen.
Anhang F Eigenst¨andigkeitserkl¨arung Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PAMM-Accounts selbstst¨andig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst habe. Die Arbeit wurde bisher in gleicher oder ¨ahnlicher Form keiner anderen Pr¨ufungsbeh¨orde vorgelegt. Berlin, den 21.4.2011

Weitere ähnliche Inhalte

PDF
agorum core-benutzer-handbuch-6 4-0
vonagorum Software GmbH
 
PDF
Informationsvisualisierung Im Semantic Web1
vonbrisvegas1
 
PDF
Laz Infos Svn0082
vonguestd7366e5
 
PDF
SPSS: Praxis-Leitfaden
vonRené Reineke
 
PDF
Handbuch CONSIDEO Modeler V 5.0
vonDetlef Kahrs
 
PDF
Master thesis pascal_mueller01
vonguest39ce4e
 
PDF
Agorum core-administrations-handbuch-6 4-0a
vonagorum Software GmbH
 
PDF
Handbuch
vonguest4b239d5b
 
agorum core-benutzer-handbuch-6 4-0
vonagorum Software GmbH
 
Informationsvisualisierung Im Semantic Web1
vonbrisvegas1
 
Laz Infos Svn0082
vonguestd7366e5
 
SPSS: Praxis-Leitfaden
vonRené Reineke
 
Handbuch CONSIDEO Modeler V 5.0
vonDetlef Kahrs
 
Master thesis pascal_mueller01
vonguest39ce4e
 
Agorum core-administrations-handbuch-6 4-0a
vonagorum Software GmbH
 
Handbuch
vonguest4b239d5b
 

Was ist angesagt?

PDF
Evaluierungsmodell
vononeduphine
 
PDF
Praxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
vonguestadcc8ae
 
PDF
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
vonadesso AG
 
PDF
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
vonFrank Oellien
 
PDF
Leseprobe: Deutsches Redmine Buch zur Anwendung und Administration
vonClaudia Meindl
 
PDF
Fi Fi Webserver Hardwaredokumentation
vonguest0ac90f
 
PDF
Diplomarbeit
vonMarkus Möller
 
PDF
Mocek Thesis
vonguest127397c
 
PDF
Manual kalypso risk_de_v2.0.1
vonMurtuja Alam
 
PDF
InDesign CS6 Seminar
vonSven Brencher
 
Evaluierungsmodell
vononeduphine
 
Praxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
vonguestadcc8ae
 
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
vonadesso AG
 
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
vonFrank Oellien
 
Leseprobe: Deutsches Redmine Buch zur Anwendung und Administration
vonClaudia Meindl
 
Fi Fi Webserver Hardwaredokumentation
vonguest0ac90f
 
Diplomarbeit
vonMarkus Möller
 
Mocek Thesis
vonguest127397c
 
Manual kalypso risk_de_v2.0.1
vonMurtuja Alam
 
InDesign CS6 Seminar
vonSven Brencher
 

Andere mochten auch

PDF
Mobile Motion
vonimatics Software GmbH
 
PPT
Stragegien der Täter
vonZartbitter_eV
 
PPT
Eqr und dqr be pä netzwerken b
vonWolfgang Gross
 
PPT
EQR und DQR für die BePä Netzwerker 25-04-2011
vonWolfgang Gross
 
PDF
Ablauf UnternehmensCheck
vonulrichboldt
 
PPT
Steel art образцы
vonlogalla
 
PDF
Graphisads- 360 Degr
vonAabhishek Gupta
 
ODP
Vor dem vortrag
vonIna Arendt
 
PPT
Das Grünbuch der Stadt Zürich
vonGrün Stadt Zürich
 
PPTX
Content Is King Lehr-Lern-Inhalte erstellen und nutzen e-learning up 2012
vonFrederic Matthe
 
PDF
Iris Klaßen: Professionelles Studierendenmarketing
vonStefanie Kollenberg, Raabe Verlag
 
PDF
Biblioteksledermøde & DRs Kulturarvsprojekt
vonTobias Golodnoff
 
PDF
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
vonteena77
 
PPT
The biggest Mystery - Das Geheimnis der Welt- Energie
vonGerold Szonn
 
PDF
Social Media Workshop mensch & arbeit
vonKirche 2.0
 
PPT
Steuerliche Behandlung von Photovoltaikanlagen
vonSNWPSTB
 
PDF
Document Driven Development
vonlichtkind
 
PDF
Präsentation umlaufsperren
vonWolfgang Gross
 
PPT
Deutsch
vonmaddycardenas
 
PPT
Fbeltern1
vonDidi Klement
 
Mobile Motion
vonimatics Software GmbH
 
Stragegien der Täter
vonZartbitter_eV
 
Eqr und dqr be pä netzwerken b
vonWolfgang Gross
 
EQR und DQR für die BePä Netzwerker 25-04-2011
vonWolfgang Gross
 
Ablauf UnternehmensCheck
vonulrichboldt
 
Steel art образцы
vonlogalla
 
Graphisads- 360 Degr
vonAabhishek Gupta
 
Vor dem vortrag
vonIna Arendt
 
Das Grünbuch der Stadt Zürich
vonGrün Stadt Zürich
 
Content Is King Lehr-Lern-Inhalte erstellen und nutzen e-learning up 2012
vonFrederic Matthe
 
Iris Klaßen: Professionelles Studierendenmarketing
vonStefanie Kollenberg, Raabe Verlag
 
Biblioteksledermøde & DRs Kulturarvsprojekt
vonTobias Golodnoff
 
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
vonteena77
 
The biggest Mystery - Das Geheimnis der Welt- Energie
vonGerold Szonn
 
Social Media Workshop mensch & arbeit
vonKirche 2.0
 
Steuerliche Behandlung von Photovoltaikanlagen
vonSNWPSTB
 
Document Driven Development
vonlichtkind
 
Präsentation umlaufsperren
vonWolfgang Gross
 
Deutsch
vonmaddycardenas
 
Fbeltern1
vonDidi Klement
 

Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PAMM-Accounts

  • 1.
    ENTWICKLUNG EINES FRAMEWORKSZUM AUTOMATISIERTEN HANDEL EINES MULTI-BROKER-PAMM-ACCOUNTS Abschlussarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) an der Hochschule f¨ur Technik und Wirtschaft Berlin Fachbereich Wirtschaftswissenschaften II Studiengang Angewandte Informatik 1. Pr¨ufer: Prof. Dr.-Ing. Thomas Schwotzer 2. Pr¨ufer: Prof. Dr.-Ing. R¨uger Oßwald Eingereicht von Sascha Jonas 21. April 2011 © Copyright 2011 Sascha Jonas. Alle Rechte vorbehalten.
  • 3.
    iii Kurzzusammenfassung In Laufe derletzten Jahren wurde der Handel von Devisen und insbesondere der automatisierte Handel von Devisen immer interessanter. Im Rahmen dieser Arbeit werden die Grundlagen des Devisenhandels und die Anfordererungen an eine Anwendung zum automatisierten Handel von Devisen erarbeitet. Weit- erhin wird ein Konzept zum gleichzeitigen Handel mehrerer Konten vorgestellt. Basierend auf diesen Erkenntnissen wird eine prototypische Anwendung konzipiert und realisiert. Stichworte: Automatische Handelssysteme, Devisenhandel, Forex, PAMM-Konto
  • 5.
    Inhaltsverzeichnis Abbildungsverzeichnis vi 1 Einleitung1 1.1 Abriss ¨uber die historische Entwicklung des Devisenmarkts . . . . . . . . . . . . 1 1.2 Der Devisenmarkt heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 PAMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Grundlagen 5 2.1 Grundlagen des Devisenhandels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Modularisierung in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Die OSGi Service Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Eclipse RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 Anforderungsanalyse 21 3.1 Markt¨ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4 Entwurf 29 4.1 System-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5 Implementierung 35 5.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6 Software-Test 45 6.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2 GUI-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.3 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
  • 6.
    INHALTSVERZEICHNIS vi 6.4 Ergebnissvon GUI- und Funktionstests . . . . . . . . . . . . . . . . . . . . . . . 47 6.5 Skalierbarkeits-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7 Fazit 49 7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.2 R¨uckblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Literaturverzeichnis 50 A Glossar 55 B JFace Data Binding 57 C Abbildungen 59 D Tabellen 71 E Installationsanleitung 75 F Eigenst¨andigkeitserkl¨arung 77
  • 7.
    Abbildungsverzeichnis 1.1 Percent AllocationManagement Module (PAMM) . . . . . . . . . . . . . . . . . 4 2.1 Candlestick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Candlestick-Chart mit Moving Average und MACD . . . . . . . . . . . . . . . . 7 2.3 Bundle Lebenszyklus (Quelle: [wikc]) . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Event Admin Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5 Komponenten der Eclipse RCP Plattform. . . . . . . . . . . . . . . . . . . . . . . 17 5.1 FxTrader Client - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 FxTrader Client - GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 FxTrader Handelssysteme - Eingabe von Parametern . . . . . . . . . . . . . . . . 38 C.1 Sequenzdiagramm - Content Provider . . . . . . . . . . . . . . . . . . . . . . . . 59 C.2 Usecase Diagramm - Kontoverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 60 C.3 Usecase Diagramm - Tradeverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 61 C.4 Usecase Diagramm - Handelssysteme . . . . . . . . . . . . . . . . . . . . . . . . . 62 C.5 Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.6 Verteilungsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 C.7 ERM-Diagramm: Datentypen (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . . 64 C.8 ERM-Diagramm: Datentypen (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . . 65 C.9 Klassendiagramm - Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 C.10 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 C.11 Aktivit¨atsdiagramm f¨ur einen PAMM-Trade . . . . . . . . . . . . . . . . . . . . . 68 C.12 Klassendiagramm Server-Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 69 C.13 Klassendiagramm - Indikatoren und Handelssysteme . . . . . . . . . . . . . . . . 70
  • 9.
    Kapitel 1 Einleitung In diesemKapitel wird auf die historische Entwicklung und die aktuelle Situation des De- visenmarkts eingegangen. Im Anschluss werden das Percent Allocation Management Module (PAMM), ein Konzept f¨ur ein Sammelkonto, und das Ziel dieser Arbeit erl¨autert. 1.1 Abriss ¨uber die historische Entwicklung des Devisen- markts Mit dem Bretton-Woods-Abkommen1 , das am 22.07.1944 von 44 Staaten in Bretton Woods, USA beschlossen wurde, sollte das internationale W¨ahrungssystem neu geordnet werden. Zur Kontrolle des neuen W¨ahrungssystems wurden die auch heute noch existierenden Institutio- nen Weltbank und International W¨ahrungsfonds (IWF) geschaffen. Im Zentrum des Bretton- Woods-Abkommens stand der US-Dollar, der als Leitw¨ahrung dienen sollte. F¨ur die W¨ahrungen der teilnehmenden Staaten wurde ein fixes Wechselverh¨altnis zum US-Dollar festgelegt. Dieses Wechselverh¨altnis durfte nur 1% um den festgelegten Wert schwanken. Die Zentralbanken der jeweiligen L¨ander verpflichteten sich dazu, durch Ihre Geldpolitik und durch Eingriffe am De- visenmarkt diese fixen Wechselkurse zu halten. Ein weiterer Bestandteil des Abkommens war die enge Bindung des US-Dollar an Gold. Der Kurs wurde auf 35 Dollar je Feinunze Gold festgelegt, wobei sich die Federal Reserve Bank of New York (FED) verpflichtete, den fixen Wechselkurs von US-Dollar in Gold zu gew¨ahrleisten. Die USA hatte in den 70er Jahren im Zuge des Vietnamkrieges mit großen Staatsdefiziten zu k¨ampfen, was das Vertrauen in den US-Dollar stark d¨ampfte. Die ¨Olkrise von 1973 f¨uhrte schließlich zum endg¨ultigen Zerbrechen des Bretton-Woods-Abkommens. Seitdem wurde die Bindung von W¨ahrungen an Gold aufgegeben. Der Wechselkurs der meisten W¨ahrungen wird nun durch den Handel an den Devisenm¨arkten und die Geldpoli- 1vgl. [Och04] 23ff
  • 10.
    KAPITEL 1. EINLEITUNG2 tik der Zentralbanken bestimmt. Eine Ausnahme bildet z.B. der chinesische Yuan, der mit sehr geringem Spielraum an die Entwicklung des US-Dollar gekoppelt ist und nicht an den Devisenm¨arkten gehandelt wird.
  • 11.
    KAPITEL 1. EINLEITUNG3 1.2 Der Devisenmarkt heute Der Devisenmarkt, oder auch Forex-Markt2 , ist der globale Markt, auf dem W¨ahrungen gehan- delt werden. Er ist an keinen festen B¨orsenplatz gebunden, da er außerb¨orslich3 durch den Interbankenmarkt gebildet wird und ist aufgrund der unterschiedlichen Zeitzonen 24 Stunden am Tag und 5 Tage in der Woche offen. Der Devisenmarkt ist der gr¨oßte Finanzmarkt der Welt, mit einem durchschnittlichen Ta- gesumsatz von 4.000 Milliarden US-Dollar [Mon]. Der Devisenkurs wird immer als Wechselkurs zwischen zwei unterschiedlichen W¨ahrungen angegeben und so besteht ein Devisengesch¨aft auch immer aus dem gleichzeitigen Kauf und Verkauf von unterschiedlichen W¨ahrungen. W¨urde man zum Beispiel auf eine positive Entwicklung des Euro gegen¨uber dem US-Dollar setzen und eine sogenannte Long-Position im EUR/USD er¨offnen, dann w¨urde man gleichzeitig Euro kaufen und US-Dollar verkaufen. Der Devisenmarkt wird durch den Handel verschiedener Akteure mit sehr unterschiedlichen Zielen bestimmt. International agierende Unternehmen, wie z.B. IBM oder Porsche, unterhal- ten eine eigene Forex-Abteilung, um sich gegen W¨ahrungsrisiken abzusichern. Zentralbanken agieren um nationale Interessen zu sichern und Investoren spekulieren um Renditeziele zu er- reichen. Seit kurzem ist es auch Privatanlegern m¨oglich, am Devisenhandel teilzunehmen, da Broker4 durch sogenanntes Leverage die Mindesteinlage (f¨ur ein Minimum-Lot) stark verringert haben. Die Positionsgr¨oßen f¨ur ein Devisengesch¨aft waren fr¨uher ein Vielfaches von einem Lot. Unter einem Lot werden meist 100.000$ verstanden. Seit einiger Zeit ist ¨uber Broker aber auch der Handel von Mini-Lot, also einem Vielfachen von 0.1 Lot, und Micro-Lot, einem Vielfachen von 0.01 Lot, m¨oglich. Die H¨ohe des Leverage, auch Hebel genannt, sagt aus wie viel Margin auf einem Konto f¨ur ein Devisengesch¨aft hinterlegt sein muss. Bei einem Leverage von 1:100 und einer Positionsgr¨oße von 1 Lot m¨ussten 1.000$ statt 100.000$ als Margin hinterlegt sein. Niedrige Margin-Anforderungen, hohe Volalit¨at und die M¨oglichkeit Kauf-(Long) und Verkaufspositionen (Short) zu er¨offnen, machen diesen Markt so interessant. 2Forex-Markt steht f¨ur Foreign Exchange Market 3“over the counter ” - OTC 4Broker unterhalten Gesch¨aftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. Deutsche Bank, einer der gr¨oßten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf.
  • 12.
    KAPITEL 1. EINLEITUNG4 1.3 PAMM Verm¨ogensverwalter und Devisenh¨andler verwalten eine Vielzahl von Kundenkonten. Um ein Devisengesch¨aft (Trade) nun nicht f¨ur jedes verwaltetete Konto von Hand ausf¨uhren zu m¨ussen, wurde das Percent Allocation Management Module (PAMM) entwickelt. Kaufe 1 Lot EUR/USD PAMM-Technologie Portfolioanteil in % angepasste Positionsgröße Einzelkonten 200.000 $ 300.000 $ 500.000 $ 20% 30% 50% 0.2 Lot 0.3 Lot 0.5 Lot Abbildung 1.1: Percent Allocation Management Module (PAMM) Wie die Abbildung 1.1 zeigt, wird mittels PAMM eine Transaktion auf alle verwalteten Konten, abh¨angig von deren Anteil am Gesamtverm¨ogen, automatisch aufgeteilt. Dabei wird selbstverst¨andlich auch ber¨ucksichtigt, dass die Kundenkonten in unterschiedlichen W¨ahrun- gen vorliegen k¨onnen. Dazu wird der aktuelle Wechselkurs zum US-Dollar ermittelt und eine Umrechnung von Fremdw¨ahrungskonten in US-Dollar-Konten vorgenommen. Diese Technologie wird inzwischen von vielen Brokern bereitgestellt. Jedoch gibt es zur Zeit keine M¨oglichkeit, Konten von unterschiedlichen Brokern zu einem PAMM-Konto zusam- menzufassen. Ein Grund f¨ur die Verteilung von Kundengeldern auf mehrere Broker k¨onnte die Risikoabsicherung sein. So sind zum Beispiel Einlagen bei in Großbritannien residierenden Bro- ker mit bis zu 50.000 GBP (ca. 60.000 Euro) versichert und bei in der Schweiz residierenden Broker mit bis zu 100.000 CHF (ca. 80.000 Euro). 1.4 Zielsetzung Ziel dieser Arbeit ist es, ein Framework zu entwickeln, das die APIs ausgew¨ahlter Broker kapselt, um Konten dieser Broker zu einem PAMM-Account zusammenzufassen. Das Framework soll modular aufgebaut und leicht um weitere APIs erweiterbar sein. Außer- dem soll es wohlgeformte Schnittstellen zur Verf¨ugung stellen, um einen oder mehrere PAMM- Accounts zu verwalten und den Handel von Devisen durchzuf¨uhren. Aufbauend auf diesem Framework wird eine prototypische Anwendung entwickelt, die es erm¨oglicht, automatisierte Handelssysteme zu erstellen, und mit diesen den PAMM-Account zu handeln.
  • 13.
    Kapitel 2 Grundlagen Dieses Kapitelbeschreibt im ersten Teil die fachlichen Grundlagen f¨ur den automatisierten und computergest¨utzten Handel von Devisen. Aufgrund der formulierten Zielsetzung, dass die Software leicht um weitere Broker-API‘s, Indikatoren und automatische Handelssysteme erwei- terbar sein muss, wurde die OSGi Service Plattform die Grundlage f¨ur den Server gew¨ahlt. Um die Vorteile von OSGi auch auf Clientseite nutzen zu k¨onnen, hat sich der Autor f¨ur die Eclipse Rich Client Platform (RCP) entschieden. Beide Technologien werden im zweiten Teil dieses Kapitels untersucht. 2.1 Grundlagen des Devisenhandels Im Devisenhandel wird zwischen der fundamentalen und der technischen Analyse unterschieden. In der fundamentalen Analyse werden Handelsentscheidungen anhand von Fundamentaldaten wie z.B. dem Preisindex f¨ur die Lebenshaltung (CPI) oder dem Bruttoinlandsprodukt getroffen. Der technische Analyst hingegen trifft seine Handelsentscheidungen anhand von aktuellen und vergangenen Wechselkursen, in der Annahme, dass fundamentale Daten bereits eingepreist seien, und benutzt daf¨ur Charts, Chart-Pattern1 und Indikatoren. Zum Handel von Devisen k¨onnen beide Analyseformen kombiniert werden, im Rahmen dieser Arbeit erstellte Handelssysteme werden sich jedoch auf die technische Analyse beschr¨anken. 2.1.1 Bildung eines Candlestick Charts Zu den verbreiteten Chartformen geh¨ort der Candlestickchart. Zur Bildung eines Candlesticks (siehe Abbildung 2.1) werden die in einem bestimmten Zeitraum aufgetretenen Ticks analysiert. Der Candlestick bildet dann nur das Maxima (High), das Minima (Low), den Preis zu Beginn (Open) und den Preis zum Ende (Close) dieses Zeitraums ab. Diese vier Preisdaten und die 1siehe [Wikb] und [Wika]
  • 14.
    KAPITEL 2. GRUNDLAGEN6 High Low Open Close Abbildung 2.1: Candlestick Anzahl der in diesem Zeitraum gehandelten Lots (Volumen) werden alle oder teilweise, das h¨angt von der Art des Indikators ab, von Indikatoren zur Berechnung ben¨otigt. Weitere Chartformen sind der Balkenchart und der Linienchart. Der Balkenchart stellt wie der Candlestickchart(siehe Abbildung 2.2): Open, High, Low und Close, nur in einer anderen Form, dar, w¨ahrend der Linienchart nur die Close-Preise durch Linien miteinander verbindet. Im Devisenhandel haben sich verschiedene Zeitebenen etabliert auf deren Basis gehandelt wird. Die g¨angigsten Zeitebenen sind 1 Minute, 5 Minuten, 15 Minuten, 30 Minuten, 1 Stunde, 4 Stunden, 1 Tag, 5 Tage und 1 Monat, wobei Wochenenden nicht ber¨ucksichtigt werden. 2.1.2 Tickdaten Durch den regen Handel an den Devisenm¨arkten k¨onnen sich Wechselkurse in volatilen M¨arkten mehrmals in der Sekunde ¨andern. Diese Preis¨anderungen werden als Ticks bezeichnet. Ein Tick gibt also immer den Wechselkurs einer bestimmten W¨ahrung zu einer bestimmten Zeit an. Bei Wechselkursen wird zwischen Bid- und Ask-Preisen unterschieden. Er¨offnet man eine Long-Position (Buy), dann wird diese Position zum Ask-Preis er¨offnet. Schließt man diese Po- sition oder er¨offnet eine Short-Position (Sell), so geschieht dies zum Bid-Preis. Zwischen Ask- und Bid-Preis liegt immer eine Differenz, die je nach Marktsituation, W¨ahrung und Broker unterschiedlich sein kann. Diese Differenz wird Spread genannt und ist die Geb¨uhr, die Broker f¨ur ihre Dienste verlangen. Der Spread liegt bei den Hauptw¨ahrungen, auch Majors genannt, meist zwischen einem und vier Pips. Ein Tick besteht also genaugenommen aus zwei Preisen, dem Bid- und dem Ask-Preis. F¨ur Indikatoren und Charts werden meist Bid-Preise verwendet, da diese bei Ask-Preisen durch marktabh¨angige Spreads verf¨alscht w¨urden. 2.1.3 Indikatoren Indikatoren sind Werkzeuge zur statistischen Analyse von B¨orsendaten. Indikatoren k¨onnen un- terteilt werden in trendfolgende Indikatoren, Oszillatoren und sonstige Indikatoren. Indikatoren werden, f¨ur den aktuellen Candlestick, bei jedem Tick neu berechnet. F¨ur die Analyse werden jedoch nur Indikatorenwerte von bereits abgeschlossenen Candlesticks verwendet.
  • 15.
    KAPITEL 2. GRUNDLAGEN7 12 EMA 26 EMA Signallinie Mittellinie MACD 1 Abbildung 2.2: Candlestick-Chart mit Moving Average und MACD Der gleitende Durchschnitt [eSib] (Moving Average) geh¨ort zu den trendfolgenden Indika- toren: ” Es ist seine Aufgabe, zu signalisieren, dass ein neuer Trend begonnen hat oder dass ein alter Trend geendet oder sich umgekehrt hat.“2 . Der Moving Average wird meist mit den Close-Preisen gebildet, kann unter anderem aber auch vom Mittelwert ((Low+High)/2) gebildet werden. Moving Averages werden in gewichtet und ungewichtet unterschieden. Beim simplen Moving Average (SMA), wird jeder Preis gleich gewichtet, sodass sich folgende Formel ergibt: SMA0 = 1 M M n=0 Preisn, wobei M die Periode des Moving Average und damit die Anzahl der zur Berechnung einbezoge- nen Candlesticks darstellt. Die Variable n steht f¨ur den Candlestick, dessen Preis zur Berechnung genommen wird3 . Zu den gewichteten gleitenden Durchschnitten geh¨ort zum Beispiel der expo- nentiell gegl¨attete Moving Average (EMA), bei dem Kurse der j¨ungsten Vergangenheit st¨arker gewichtet sind als ¨altere Kurse. Dazu wird der Faktor α verwendet, mit α = 2 M+1 , wodurch sich die folgende Formel ergibt: EMA0 = (Preis0 · α) + (SMA1 · (1 − α)), 2siehe [Mur06] S. 203ff 3n=0 ist der aktuelle Candlestick (dessen Preis sich bei jedem Tick ¨andert), n=1 der letzte Candlestick, n=2 der vorletzte Candlestick usw.
  • 16.
    KAPITEL 2. GRUNDLAGEN8 Moving Averages gl¨atten das ” Rauschen“ des Marktes, sie erleichtern das Erkennen von Trends und werden oftmals zum Gl¨atten der Werte anderer Indikatoren benutzt. Moving Averages k¨onnen so interpretiert werden, dass es sich um einen Aufw¨artstrend handelt, wenn sich die Candlesticks ¨uber dem Moving Average befinden und ansonsten um einen Abw¨artstrend. Ein ¨Uber- bzw. Unterschreiten des Moving Average, w¨urde dann einen Trendwechsel signalisieren. Eine weitere M¨oglichkeit ist es, zwei Moving Averages, einen langsamen und einen schnellen, zu verwenden. Befindet sich der schnelle Moving Average (12er EMA) ¨uber dem langsamen (26er EMA), dann handelt es sich um einen Aufw¨artstrend und ansonsten um einen Abw¨artstrend (siehe Abbildung 2.2). Das kreuzen der beiden Moving Av- erages zeigt den Trendwechsel an (siehe den mit 1 markierten Kreis in Abbildung 2.2). Oszillatoren sind Indikatoren, deren Werte entweder um die Mittellinie oder zwischen fest- gelegten Werten, meist zwischen 0 und 100, schwanken. Der Moving Average Convergence Divergence Indikator [eSia] (MACD) geh¨ort zu der Gruppe der Oszillatoren und berechnet den Abstand zwischen zwei Moving Averages (meist 12er und 26er EMA) und eine Signallinie (meist 9er EMA). Ein steigender MACD, ¨uber der Mittellinie, wird als Aufw¨artstrend und ein fallender MACD, unter der Mittellinie, wird als Abw¨artstrend interpretiert. Als Trendwechsel werden das Kreuzen der Mittel- oder Signallinie und Divergenzen4 gedeutet. Zum Abschluss sei erw¨ahnt, dass Indikatoren nur Hinweise auf m¨ogliche Ereignisse geben k¨onnen. Da es sich um statistische Analysen handelt, treffen von Indikatoren signalisierte Ereignisse nur mit einer gewissen Wahrscheinlichkeit ein. Bei den oben erw¨ahnten Indikatoren handelt es sich weiterhin um Indikatoren, die dem Markt ” hinterherlaufen“, das heisst, dass eine Marktbewegung auch bereits abgeschlossen sein kann und ein Neueinstieg in den Markt nicht mehr profitabel ist. 2.1.4 Ordertypen Ein einzelner Handel von Devisen wird als Order oder Trade bezeichnet. Es wird zwischen Market Order und Pending Order unterschieden. Eine Market Order wird sofort und zum ak- tuellen Marktpreis (Market Entry) ausgef¨uhrt. Eine Pending Order kann nur unter bestimmten Voraussetzungen angelegt werden und wird zu einem vorher festgelegten Kurs (Pending Entry) ausgef¨uhrt. Market Orders werden verwendet, wenn der Zeitpunkt f¨ur die Er¨offnung eines Trades wichtiger ist, als der Preis zu dem er er¨offnet wird. Bei Pending Orders ist der Zeitpunkt, wann der Trade er¨offnet wird, nicht so wichtig. Dieser Ordertyp wird z.B. bei dem Handel von Ausbr¨uchen aus Seitw¨artsm¨arkten oder bei wichtigen Nachrichten verwendet. Hier werden dann Kauf- und Verkausorder ¨uber bzw. unter der bisherigen Range platziert und der Trader l¨asst sich dann ” einstoppen“: 4Beispiel: In der Abbildung 2.2 ist der MACD-Wert vom November 2007 geringer als der MACD-Wert vom Dezember 2004, w¨ahrend der Close-Preis vom Dezember 2004 geringer als der vom November 2007 ist. Chartbild und Indikatorbild unterscheiden sich, was als Divergenz bezeichnet wird.
  • 17.
    KAPITEL 2. GRUNDLAGEN9 Ordertyp Entry-Preis Stop-Preis Limit-Preis Buy (Market Entry) Ask <Bid >Ask Buy Limit (Pending Entry) <Ask <Pending Entry >Pending Entry Buy Stop (Pending Entry) >Ask <Pending Entry >Pending Entry Sell (Market Entry) Bid >Ask <Bid Sell Limit (Pending Entry) >Bid >Pending Entry <Pending Entry Sell Stop (Pending Entry) <Bid >Pending Entry <Pending Entry Tabelle 2.1: Ordertypen und Voraussetzungen F¨ur beide Ordertypen k¨onnen ein Stop, dient der automatischen Verlustbegrenzung, und ein Limit, dient der automatischen Gewinnmitnahme, gesetzt werden. Beispiel: Soll eine Kauforder ausgef¨uhrt werden, so geschieht dies zum Ask-Preis, der Stop m¨usste dann unter dem Bid-Preis und das Limit ¨uber dem Ask-Preis liegen. Erreicht der Marktpreis entweder Stop oder Limit, w¨urde die Position automatisch geschlossen werden. Alle Voraussetzungen f¨ur die einzelnen Ordertypen k¨onnen in der Tabelle 2.1 nachgelesen werden. Jeder Trade wird als einzelne Position behandelt und ist unabh¨angig von anderen Trades. Damit ist es m¨oglich, gleichzeitig Long und Short zu sein, was im Devisenhandel g¨angige Praxis ist und wird zum einen zur Risikoabsicherung benutzt. Auf der anderen Seite kann es zum Beispiel bei Handelssystemen, die auf unterschiedlichen Zeitebenen agieren, zu gleichzeitigen Long- und Short-Trades kommen. Eine Ausnahme bilden hier Konten, die bei einem Broker in den USA gef¨uhrt werden. In Reaktion auf die Finanzkrise wurde in den USA, durch die National Finance Authority (NFA), eine andere Regelung eingef¨uhrt. Aufgrund der NFA Compliance Rule 2-43(b), ist hier nur eine Position pro W¨ahrungspaar erlaubt. Die Konsequenz davon ist, dass ein neuer Short-Trade einen bestehenden Long-Trade ganz oder teilweise schließt. Damit wird aus einer Long-Position mit 1,0 Lot eine Long-Position mit 0,5 Lot, wenn eine Short-Position mit 0,5 Lot er¨offnet wurde. Es ist also innerhalb eines US-Kontos nicht mehr m¨oglich, gleichzeitig Long und Short zu sein. Dies kann umgangen werden, indem ein Konto f¨ur Long- und ein anderes Konto f¨ur Short-Trades genutzt wird. Auch das Setzen von Stop- und Limit-Preis ist - bei US-Brokern - nicht mehr m¨oglich, kann aber durch das Setzen entsprechender Entry-Orders ersetzt werden. So k¨onnten z.B. f¨ur einen Long-Trade, eine Sell-Limit- und eine Sell-Stop-Order, anstatt eines Stop- und Limit-Preises, benutzt werden. Das bedeutet, dass Konten bei US-Broker und Konten bei Broker außerhalb der USA, nicht in einem PAMM-Konto gemischt werden k¨onnen. Die im Rahmen dieser Arbeit erstellte Anwendung wird US-Konten somit nicht voll unterst¨utzen. 2.1.5 Gewinn- und Verlustberechnung Alle Wechselkurse werden auf mindestens 4 Nachkommastellen genau angegeben. Eine Aus- nahme bilden z.B. Wechselkurse in denen der Japanische Yen (JPY) enthalten ist, da es im
  • 18.
    KAPITEL 2. GRUNDLAGEN10 JPY keine Cent-Betr¨age gibt. Die Preis¨anderungen werden in Pips gemessen, wobei ein Pip der vierten Nachkommastelle also 0,0001 bzw. 0,01 im JPY entspricht. In dem nachfolgenden Beispiel soll nun dargelegt werden, wie Gewinne oder Verluste bei Trades berechnet werden. Die allgemeine Formel5 lautet: Gewinn/V erlust = (Pips) · (Preis{sekund¨areW ¨ahrung/Kontow¨ahrung}) · (Lots) · 100.000$ In dem folgenden Beispiel wurde eine Long-Position6 im EUR/GBP bei 0,8431 ge¨offnet und bei 0,8442 geschlossen: Kontow¨ahrung: USD gehandelte W¨ahrung: EUR/GBP prim¨are W¨ahrung (Base): EUR sekund¨are W¨ahrung (Quote): GBP Preis {sekund¨are W¨ahrung / Kontow¨ahrung} (GBP/USD): 1,6108 Open: 0,8431 Close: 0,8442 Pips: Close - Open = 0,8442-0,8431 = 0,0011 gehandelte Lots: 1 Gewinn/V erlust = (0, 0011) · (1, 6108) · (1) · 100.000$ = 177, 19$. Im Kontext eines Trades f¨ur ein PAMM-Konto (PAMM-Trade) ist die Gewinn- und Verlust- berechnung etwas schwieriger. Ein PAMM-Trade besteht aus vielen Einzeltrades, die bei ver- schiedenen Konten und Broker ge¨offnet wurden. Bei einem PAMM-Trade wird es also eher Regel als Ausnahme sein, dass die Einzeltrades zu verschiedenen Preisen ge¨offnet wurden. Das liegt zum einen daran, dass Broker leicht unterschiedliche Preis-Feeds haben k¨onnen. Zum anderen handelt es sich bei dem Devisenmarkt um einen sehr volatilen Markt, bei dem sich W¨ahrungskurse sehr schnell ¨andern k¨onnen. Es kann aufgrund der unterschiedlichen Preis-Feeds auch dazu kommen, dass ein Einzeltrade bei einem Broker schon den Limit- oder Stop-Preis erreicht hat und geschlossen wurde, w¨ahrend andere Einzeltrades noch offen sind. Damit steht der endg¨ultige Gewinn oder Verlust f¨ur einen PAMM-Trade erst fest, wenn alle Einzeltrades geschlossen wurden. Um nicht den laufenden Gewinn/Verlust f¨ur jeden Einzeltrade eines PAMM-Trades auszurechnen, wird ein - nach Lotgr¨oße gewichteter - Durchschnittspreis f¨ur den Open-Preis eingef¨uhrt: gewichteter Open-Preis=(Lot1·Open1)+(Lot2·Open2)+...+(Lotn·Openn) Lot1+Lot2+...+Lotn , dabei steht n f¨ur die Anzahl der Einzeltrades in einem PAMM-Trade. Anhand dieses Preises, der gesamten Lotgr¨oße und dem aktuellen Devisenkurs, kann der aktuelle Gewinn- und Verlust f¨ur einen PAMM-Trade leicht berechnet werden. 5Wenn die sekund¨are W¨ahrung gleich der Kontow¨ahrung ist, gilt: Gewinn/Verlust=(Pips)*(Lots)*100.000$. 6Bei einer Short-Position, w¨urde sich die Anzahl der Pips mit Pips = Open − Close berechnen.
  • 19.
    KAPITEL 2. GRUNDLAGEN11 2.1.6 Lotberechnung Wie im letzten Unterkapitel ersichtlich wurde, h¨angt der Gewinn/Verlust eines Trades im großen Maße von der Lotgr¨oße ab. Die Anzahl der Lots muss auch als einziger Parameter beim Er¨offnen eines Trades angegeben werden. Doch wie bestimmt man die Lotgr¨oße? Vor jedem Trade sollte festgelegt werden, wie groß das Risiko pro Trade sein soll (Ein guter Wert liegt hier meist zwischen 1-3% der Kontogr¨oße). Das Risiko wird mit dem Setzen des Stop- Preises festgelegt, bei dem ein m¨oglicher Verlust realisiert wird. Sind Stop-Preis und damit die Entfernung vom Entry in Pips bekannt, kann die im letzten Unterkapitel erw¨ahnte Formel benutzt werden, um die Lotgr¨oße zu bestimmen. Eingeschr¨ankt wird die Lotgr¨oße und damit eine genaue Realisierung des Risikos pro Trade, nur durch die Anzahl der erlaubten Nachkommastellen7 . Im Kontext eines PAMM-Kontos f¨uhrt dies dazu, dass ein PAMM-Trade im Allgemeinen nicht gleichm¨aßig auf alle im PAMM-Konto zusammengefassten Einzelkonten verteilt werden kann. Meistens wird eine optimale Aufsplit- tung des PAMM-Trades in Einzeltrades nicht m¨oglich sein, da die f¨ur das Einzelkonto berech- nete Lotgr¨oße auf- oder abgerundet werden muss, wodurch sich wiederum das Einzel- und Gesamtrisiko des Trades ¨andert. 2.1.7 Automatische Handelssysteme Automatisierte Handelssysteme sind autonome Systeme, die anhand von Indikatoren und/oder Chartformationen, die Entscheidungen zum Kauf oder Verkauf von Devisen treffen und selb- st¨andig den Handel durchf¨uhren. Sie haben ein beliebig komplexes Regelwerk, in dem Kriterien f¨ur die Er¨offnung und das Schließen eines Trades, das Risiko pro Trade und die Stop- und Limit-Berechnung festgelegt sind. Diese Werte sind meist nicht statisch, sondern k¨onnen vom Anwender vor dem Starten des Systems festgelegt werden. Automatisierte Handelssysteme bieten den Vorteil, dass sie rund um die Uhr die M¨arkte analysieren und handeln k¨onnen, ohne emotionale oder psychologische Schw¨achen. Sie werden weder durch Angst, noch durch Gier oder M¨udigkeit beeinflusst. Ein weiterer Vorteil ist, dass automatisierte Handelssysteme nicht nur auf aktuelle De- visendaten, sondern auch auf historische Daten angewendet werden k¨onnen. Mit diesem, als Backtesting bekannten, Verfahren lassen sie sich nicht nur auf technische Funktionalit¨at, son- dern auch auf m¨ogliche Profitabilit¨at testen. Inzwischen unterst¨utzt jeder Broker das Erstellen von automatischen Handelssystemen, je- doch verwendet auch jeder Broker daf¨ur eine andere Software, sodass automatische Handelssys- teme nur mit Programmieraufwand portiert werden k¨onnen. Dies soll im Kapitel 3 genauer untersucht werden. 7Zwei Nachkommastellen bei Micro-Lot-Konten und eine Nachkommastelle bei Mini-Lot-Konten
  • 20.
    KAPITEL 2. GRUNDLAGEN12 2.2 Modularisierung in Java Dieses Unterkapitel soll verdeutlichen, was Modularisierung bedeutet und wie dieses Architektur-Konzept in Java umgesetzt wird, bevor im n¨achsten Unterkapitel - mit OSGi - eine modulare System-Plattform vorgestellt wird. Der klassische Modularisierungsbegriff lautet: ” ... Modularisierung bezeichnet ... die Aufteilung eines Softwaresystems in ¨uberschaubare Einzelteile, die jeweils einen abgeschlossenen Aufgabenbereich umfassen und untereinander mittels wohldefinierter Schnittstellen miteinander verbunden sind. [Rei09]“. Bis zur Einf¨uhrung des objektorientierten Paradigmas, unterst¨utzten Programmiersprachen die Modularisierung nur rudiment¨ar. Computerprogramme konnten nur durch Funktionen und Prozeduren strukturiert werden und hatten damit eher monolithischen Charakter. Sie waren schwieriger zu testen, schwieriger zu erweitern und schlechter wartbar. Mit der Einf¨uhrung der objektorientierten Programmiersprachen, wurde das Konzept der Modularisierung st¨arker verankert und um den Begriff der Komponente erweitert. Eine Kom- ponente wird definiert als eine Einheit zur Komposition, d.h. sie wird nur als ganzes spezifiziert, implementiert und eingesetzt. Eine Komponente besitzt fest spezifierte Schnittstellen, durch die die Verwendung der Komponente geregelt ist. Eine Komponenten-basierte Anwendung ist eine Komposition von Komponenten, wobei einzelne Komponenten entweder durch komplett neue Implementierungen oder neue Versio- nen aktueller Implementierungen ausgetauscht werden k¨onnen. Die einzelnen Komponenten einer Komponentenbasierten Anwendung sind durch deren Schnittstellen gekoppelt, wobei die konkrete Implementierung der Schnittstellen dem Benutzer der Komponente durch die Kapselung verborgen ist. Komponenten bieten den Vorteil, dass sie wiederverwendbar und gut testbar sind. In Java lassen sich Beziehungen zwischen Komponenten nur unidirektional ausdr¨ucken. Durch das import-Statement kann angegeben werden, welche anderen Komponenten es benutzt, aber nicht welche Klassen es f¨ur die Benutzung durch andere Komponenten exportiert. In Java werden weiterhin Klassen auf Sprachebene mit Hilfe von Packages hierarchisch strukturiert. Dabei l¨asst sich zwar die Sichtbarkeit von Klassen auf Packageebene einschr¨anken, f¨ur eine echte Komponentenbildung ist dies aber unzureichend. Die interne Implementierung ist dadurch nicht ausreichend gesch¨utzt und ¨uber eine einfache Typumwandlung erreichbar. OSGi ist eine auf Java basierende Plattform und erweitert Java um die M¨oglichkeit, echte Komponenten zu entwickeln. Bei OSGi ist die Implementierung einer Komponente durch einen separaten Class-Loader gesch¨utzt, außerdem ist es hier m¨oglich, explizit Abh¨angigkeiten, zu exportierende Elemente und Schnittstellen zu definieren. Dies soll im n¨achsten Unterkapitel genauer untersucht werden.
  • 21.
    KAPITEL 2. GRUNDLAGEN13 2.3 Die OSGi Service Plattform Die OSGi Alliance, ein Konsortium von Technologieunternehmen, ist eine non-profit Orga- nisation und wurde 1999 gegr¨undet. Ihre Aufgabe ist es, die Programmierschnittstellen und Testf¨alle [OSGa,OSGb] f¨ur die OSGi Service Platform zu spezifizieren. Die OSGi Service Platform ist ein dynamisches Modulsystem f¨ur Java. Es handelt sich um eine javabasierte Softwareplattform, die die dynamische Integration und das Fernmanagement von Softwarekomponenten (Bundles) und Diensten (Services) erm¨oglicht. Bundles und Services k¨onnen zur Laufzeit in der Serviceplattform installiert und deinstalliert, aktualisiert, gestoppt und gestartet werden, ohne dass die Plattform als Ganzes angehalten bzw. neu gestartet werden muss [WHKL08]. Es gibt eine Referenzimplementierung von der OSGi Alliance, diese ist jedoch nicht f¨ur den Produktiveinsatz gedacht. Hervorzuheben sei hier die Implementierung durch das Eclipse Equinox Projekt, welche Open Source ist und die Grundlage von Eclipse seit Version 3.0 bildet. Weitere Implementierungen sind z.B. Apache Felix und Knopflerfish. 2.3.1 OSGi Bundles Das fundamentale Konzept der OSGi Service Plattform ist die Modularisierung. In der OSGI- Terminologie werden diese Module als Bundles bezeichnet. Unter einem Bundle versteht man eine fachlich oder technisch zusammenh¨angende Einheit von Klassen und Ressourcen, die unabh¨angig von anderen Bundles im OSGi Framework installiert und deinstalliert werden kann [WHKL08]. ¨Ublicherweise wird f¨ur Bundles die Dateiendung ” .jar“ verwendet. Von einer normalen JAR-Datei unterscheidet sich ein Bundle nur durch ein Bundle Manifest. INSTALLED RESOLVED UNINSTALLED STARTING ACTIVE STOPPING Start Stop Abbildung 2.3: Bundle Lebenszyklus (Quelle: [wikc]) Die Abbildung 2.3 zeigt den Lebenszyklus eines Bundles. Jedes Bundle kann sich in sechs verschiedenen Zust¨anden befinden: ˆ INSTALLED: Das Bundle wurde erfolgreich auf der OSGI-Plattform installiert.
  • 22.
    KAPITEL 2. GRUNDLAGEN14 ˆ RESOLVED: Alle Abh¨angigkeiten (siehe Bundle Manifest) des Bundles konnten aufgel¨ost werden. Das Bundle ist bereit gestartet zu werden oder wurde gerade gestoppt. ˆ STARTING: Die start-Methode des Bundle-Activators wurde aufgerufen aber noch nicht abgeschlossen. ˆ ACTIVE: Das Bundle l¨auft und die start-Methode des Bundle-Activators wurde erfolgre- ich abgeschlossen. ˆ STOPPING: Die stop-Methode des Bundle-Activators wurde aufgerufen aber noch nicht abgeschlossen. ˆ UNINSTALLED: Das Bundle wurde deinstalliert. Im Eclipse-Umfeld wird meist von Plug-ins anstatt von Bundles gesprochen. Beide Begriffe beschreiben allerdings ein und dasselbe Konzept und werden synonym verwendet. 2.3.1.1 Das Bundle Manifest Jedes Bundle wird ¨uber seine Manifest-Datei und darin definierte Manifest-Header beschrieben. Das Bundle Manifest befindet sich in der JAR-Datei des Bundles unter dem Namen META- INF/MANIFEST.MF. Die Manifest-Header werden ausf¨uhrlich im Kapitel 3.2 des OSGi-Core- Compendium [OSGa] beschrieben. Listing 2.1 zeigt den Ausschnitt eines g¨ultigen Bundle Man- ifest. 1 Bundle -Name: API -Interfaces 2 Bundle - SymbolicName : de.pammtrader.core.api.interfaces 3 Bundle -Activator: de.pammtrader.core.api.interfaces.Activator 4 Bundle -Version: 0.1.0 5 Bundle - RequiredExecutionEnvironment : JavaSE -1.6 6 Import -Package: 7 de.pammtrader.core.account.interfaces;version="[0.1.0 ,1.0.0)" 8 Export -Package: de.pammtrader.core.api.interfaces;version="0.1.0" 9 Require -Bundle: de.pammtrader.core.api.fxcm;bundle -version="0.1.0" Listing 2.1: MANIFEST.MF Bundles werden innerhalb der OSGi Service Plattform durch ihren symbolischen Namen und ihrer Versionsnummer eindeutig identifiziert (Listing 2.1: Zeilen 2, 4). Diese beiden Felder, sind auch die einzigen Header die gesetzt werden m¨ussen. Alle anderen Header sind optional. Das bedeutet, dass Bundles auch in mehreren und unterschiedlichen Versionen auf der OSGi Plattform installiert sein k¨onnen. In der Manifest-Datei kann ein Bundle-Activator angegeben werden (Listing 2.1: Zeile 3). Dieser Bundle-Activator muss das Interface BundleActivator und dessen start- und stop- Methode implementieren. Er ist mit der main-Methode aus Java-Programmen vergleichbar. Weiterhin k¨onnen Abh¨angigkeiten wie ben¨otigte Java-Packages und Bundles definiert und explizit Java-Packages exportiert werden (Listing 2.1: Zeilen 6-9). Damit wird eine weitere
  • 23.
    KAPITEL 2. GRUNDLAGEN15 Besonderheit von OSGi klar: Es kann nur auf Java-Packages anderer Bundles zugegriffen wer- den, die diese auch exportieren. 2.3.2 OSGi Services Mit der Hilfe von Services werden Bundles dynamisch durch das ” publish, find and bind model“ lose gekoppelt. Ein Service ist ein Java-Objekt, das unter einem oder unter mehreren Java- Interfaces bei der Service-Registry angemeldet ist. Bundles k¨onnen Services registrieren, nach Services suchen und sich benachrichtigen lassen wenn sich Services anmelden, abmelden oder aktualisert wurden. [OSGa] Da Services sich zu beliebigen Zeitpunkten bei der Service-Registry registrieren und dereg- istrieren k¨onnen, gilt es, dies bei der Benutzung von Services zu beachten. Um den Umgang mit Services zu vereinfachen, wurden der Service-Tracker und Declarative Services geschaffen. Bei einem Service-Tracker handelt es sich um eine Hilfsklasse, die den Zugriff auf die Service- Registry kapselt und das An- und Abmelden von Services mit einem spezifischen Interfacena- men ¨uberwacht. Mit der Hilfe von Declarative Services k¨onnen Service-Abh¨angigkeiten in einer XML-Datei beschrieben werden. Das Aufl¨osen von Service-Abh¨angigkeiten wird dann durch die Service Component Runtime realisiert. Beide Ans¨atze werden genauer im OSGi Service Compendium [OSGb] beschrieben. 2.3.2.1 Event Admin Service Im OSGi Service Compendium [OSGb] werden eine Reihe von Diensten spezifiziert. Die im Rahmen dieser Arbeit erstellte Anwendung benutzt unter anderem den Event Admin Service, weswegen dieser hier erl¨autert werden soll. Der Event Admin Service basiert auf dem ” publish- <<class>> Event <<service>> Event Admin <<service>> Event Handler Event Consumer impl EventHandler Event Publisher 1 0..n Abbildung 2.4: Event Admin Service subscribe model“ und erlaubt die systemweite Kommunikation zwischen Bundles. Abbildung 2.4 stellt den Event Admin Service schematisch dar: Event Publisher benutzen die postEvent-
  • 24.
    KAPITEL 2. GRUNDLAGEN16 Methode des Event Admin Service zum asynchronen bzw. dessen sendEvent-Methode zum synchronen Versenden von Events. Alle Bundles, die sich f¨ur ein Topic und dessen Events interessieren, registrieren sich nun nicht beim Event Admin Service als Listener. Stattdessen implementieren sie das Interface EventHandler, registrieren sich als Dienst, ¨ubergeben als Service-Property das Topic und werden vom Event Admin Service ¨uber Events informiert. Dieses Design Pattern wird Whiteboard- Pattern genannt. Ein Event wird repr¨asentiert durch ein org.osgi.service.event.Event Objekt und hat die zwei Attribute: Topic und Properties. Topics sind String Objekte und case-sensitive. Ein Beispiel f¨ur ein g¨ultiges Topic w¨are ” de/pammtrader/api“, wobei Wildcards erlaubt sind. Properties sind HashMaps, wobei der Schl¨ussel ein String-Objekt ist und der dazu geh¨orige Wert ein beliebiges Java-Objekt sein kann. 2.4 Eclipse RCP Die Eclipse Rich Client Plattform8 (RCP) ist eine Plattform f¨ur modulare Desktopanwendun- gen und basiert auf OSGi. Sie ist entstanden aus der Eclipse IDE und deren Versionssprung auf Version 3.0. Die Entwicklung von Eclipse 3.0 bildete die Grundlage f¨ur eine Rich Client Plattform, indem alle Abh¨angigkeiten zu IDE-spezifischen Elementen entfernt und viele Teile des Benutzerinterfaces f¨ur die Anpassung durch den Entwickler ge¨offnet wurden. Die Abbildung 2.5 zeigt einige wichtige Komponenten der Eclipse RCP: ˆ Equinox ist eine vollst¨andige Implementierung der OSGi Plattform Spezifikation, er- weitert um f¨ur Eclipse RCP-Anwendungen ben¨otigte Komponenten, wie z.B. Extension Registry, Applications und Products, die in der Abbildung 2.5 unter der Eclipse Core Runtime zusammengefasst sind. ˆ Jede Eclipse RCP-Anwendung definiert mindestens eine Application. Applications wer- den mit Hilfe von Extensions definiert, die auf eine Klasse verweist, welche das Interface IApplication implementiert. Diese Klasse ist vergleichbar mit der main-Methode aus Java- Anwendungen und startet die Eclipse RCP Anwendung. ˆ Ein Product ist eine Konfigurationsdatei in der die Eclipse RCP-Anwendung beschrieben wird. Hier werden die Plug-ins, die die Anwendung bilden, aufgelistet und konfiguriert, Icons und Bilder f¨ur das Branding der Anwendung und Startparameter definiert. ˆ Das Standard Widget Toolkit (SWT) ist eine low-level Grafikbibliothek, welche die Standard Bedienelemente wie Listen, Men¨us, Schriftarten und Farben zur Verf¨ugung stellt und die nativen UI-Widgets des zugrunde liegenden Betriebssystems kapselt. SWT 8siehe [MLA10] S. 7ff
  • 25.
    KAPITEL 2. GRUNDLAGEN17 Abbildung 2.5: Komponenten der Eclipse RCP Plattform9 . ist f¨ur eine Vielzahl von Betriebssystemen verf¨ugbar. Damit sind Anwendungen, die SWT verwenden, sehr leicht portierbar und immer im Look & Feel des Betriebssystems auf dem sie laufen. ˆ JFace ist ein User Interface Toolkit (UI), mit Klassen f¨ur viele g¨angige Aufgaben in der UI-Programmierung, das designt wurde mit dem SWT zusammenzuarbeiten, ohne es zu kapseln. Es beinhaltet Komponenten wie Bild- und Schriftarten-Register, Dialoge, Wizards, Actions, Views und Frameworks f¨ur Databinding und Preferences und bildet damit die Basis des Eclipse UI. ˆ Eclipse Update, genauer Eclipse p2, erlaubt es einen Update-Mechanismus f¨ur eine RCP-Anwendung zu implementieren. Damit l¨asst sich nicht nur die Anwendung auf dem neuesten Stand halten, es ist auch m¨oglich neue Features zu installieren. Updates k¨onnen dann automatisch oder durch Benutzerinteraktion installiert werden. Eine Eclipse RCP Anwendung besteht also immer aus einem oder mehreren Plugins und wird zusammen mit seiner Laufzeitumgebung ausgeliefert. 2.4.1 Extensions Ein Plug-in ist von einem Bundle nur durch die plugin.xml zu unterscheiden, die sich im Root- Ordner des Plug-ins befindet und optional ist. In dieser Datei werden Extensions und Extension- Points deklariert. 9Quelle: http://www.ralfebert.de/rcpbuch/overview/
  • 26.
    KAPITEL 2. GRUNDLAGEN18 Mit Extension Points10 ¨offnen sich Plug-ins f¨ur Erweiterungen (Extensions) durch andere Plug-ins. Diese Extensions k¨onnen Implementierungen von Interfaces sein, aber auch Daten wie z.B. Icons oder Text. F¨ur jeden Extension-Point wird, mit Hilfe der Eclipse IDE, ein XML Schema-Dokument (XSD-Datei) hinterlegt, in dem beschrieben wird, welche Daten eine Exten- sion zur Verf¨ugung stellen muss. Extension Points und Extensions werden von der Extension Registry verwaltet und sind verf¨ugbar, sobald das dazugeh¨orige Plug-in den Status ” resolved“ hat. Extensions werden bei der Extension Registry abgefragt und nach dem ” lazy-loading“ Prinzip bei Bedarf geladen. Extensions sind ein fundamentales Konzept in der Entwicklung von Eclipse-RCP Anwen- dungen. So sind UI-Elemente wie Views, Editoren und Perspektiven vom Entwickler erstellte Extensions, zu von der Ecplipse RCP bereitgestellten Extension Points. Da diese Elemente in nur einer Datei (und nicht z.B. auf mehrere Java-Klassen verteilt) beschrieben werden, ist es f¨ur einen Ecplipse RCP-Entwickler einfach, sich in eine bestehende Anwendung einzuarbeiten bzw. diese zu erweitern. Listing 2.2 zeigt den Ausschnitt aus einer g¨ultigen plugin.xml, in der eine Application (Zeilen 1-8) und eine View (Zeilen 9-14) deklariert werden. 1 <extension id="application" 2 point="org.eclipse.core.runtime. applications "> 3 <application > 4 <run 5 class="de.fxsolution.client. Application"> 6 </run > 7 </application > 8 </extension > 9 <extension point="org.eclipse.ui.views"> 10 <view 11 class="...ui. singleaccount . AccountList " 12 id="de.fxsolution.client.ui. AccountList " 13 name=" AccountList "> 14 </view > 15 ... Listing 2.2: plugin.xml 2.4.2 Synchronisation von Datenmodell mit UI-Elementen Eclipse RCP unterst¨utzt explizit das Trennen von Datenmodell, Zugriff auf das Datenmodell und Pr¨asentation des Datenmodells (MVC-Pattern). Diese Trennung in Komponenten hat den Vorteil, dass die jeweilige Implementierung an sich ¨andernde Anforderungen angepasst werden kann, ohne dass dies Konsequenzen f¨ur die anderen Komponenten haben muss. Damit wird die Anwendung besser struktiert und ist leichter wart- und testbar. 10siehe [MLA10] S. 390ff
  • 27.
    KAPITEL 2. GRUNDLAGEN19 Um das Datenmodell zu kapseln und mit dem Benutzerinterface zu synchronisieren, bietet die Eclipse RCP zum einen das, aus der Android Entwicklung bekannte, Konzept des Content Providers und das JFace Data Binding Framework an. Beide Konzepte wurden evaluiert, jedoch wird nur der Content-Provider genutzt. Auf die Verwendung des JFace Data Binding Framework musste aus Zeitgr¨unden verzichtet werden. Es wird der Vollst¨andigkeit halber im Anhang auf der Seite 57 vorgestellt. 2.4.2.1 Content Provider Content Provider11 sind Klassen, die ein spezifisches Interface, aus dem Package org.eclipse.jface.viewers, implementieren und Zugriff auf Daten gew¨ahren. Content Provider bieten den Vorteil, dass sie sehr leicht zu implementieren sind. Die Abbildung C.1 auf Seite 59 zeigt am Beispiel eines TreeViewers, wie ein UI-Element mit einem Contentprovider verkn¨upft wird und wie dieses Element, mit Hilfe der Methode getChil- dren(), Daten bezieht. Ein TreeViewer ist eine Komponente, die Elemente in einer Baumstruk- tur, ¨ahnlich dem Windows Explorer, anzeigt und bezieht Daten entweder von einem ITreeCon- tentProvider oder von einem BaseWorkbenchContentprovider und dazu geh¨origen IWorkben- chadaptern. ¨Andert sich das Datenmodell, dann m¨ussen die UI-Elemente, mit der Hilfe von Listenern, dar¨uber informiert und die Daten erneut vom Content Provider geladen werden. 11siehe [MLA10] S. 73ff
  • 29.
    Kapitel 3 Anforderungsanalyse Die imRahmen dieser Arbeit entwickelte Anwendung stellt einen Prototyp f¨ur den Handel von Devisen dar. Sie soll die Broker-APIs kapseln und deren Funktionalit¨aten mit einem ein- heitlichen Benutzerinterface zu Verf¨ugung stellen. Weiterhin soll Sie es erm¨oglichen Einzelkon- ten, die bei unterschiedlichen Brokern liegen k¨onnen, zu einem PAMM-Konto zusammenzu- fassen. Diese PAMM-Konten sollen dann manuell oder mit Hilfe von automatischen Handelssys- temen gehandelt werden k¨onnen. Um diese Ziele zu erreichen, wird im ersten Teil dieses Kapitels ermittelt, was Broker an APIs zur Verf¨ugung stellen. Daraus werden die funktionalen und nicht-funktionalen Anforderungen an die Software abgeleitet, die im zweiten Teil formuliert werden. 3.1 Markt¨ubersicht 3.1.1 Broker-APIs Nach einer Recherche bei g¨angigen Forex-Brokern (siehe Tabelle D.1 auf Seite 71) zeigte sich, dass deren APIs in 3 Arten gegliedert sind: Zum einen unterst¨utzen die meisten Broker das Financial Information eXchange (FIX)- Protokoll. Alle untersuchten Broker bieten weiterhin eigene APIs an, wobei der Zugriff auf historische Preisdaten meist - von den reinen Trade-Funktionalit¨aten getrennt - in einer eigenen API zu finden ist. Als Programmiersprachen, werden C++ und/oder Java unterst¨utzt. 3.1.1.1 FIX-Protokoll Das FIX-Protokoll1 ist ein Nachrichtenstandard, der speziell f¨ur den Handel von Wertpapieren in Echtzeit entwickelt wurde. Das FIX-Protokoll ist offen und frei verf¨ugbar und liegt aktuell in der Version 5.0 Service Pack 2 vor. Es ist komplett Nachrichtenbasiert und definiert eine 1vgl. [FP]
  • 30.
    KAPITEL 3. ANFORDERUNGSANALYSE22 Reihe von Nachrichten, die in Session- und Anwendungsnachrichten unterteilt sind, und darin erlaubte Felder. Diese Nachrichten k¨onnen zum einen in reiner Textform vorliegen, wobei ein Feld wie folgt aufgebaut sein muss: < TAG >=< V ALUE >< DELIMITER > z.B.: ” 8=FIX.4.4;“. Sie k¨onnen aber auch, nach dem FIX-XML Standard, in XML-Form sein. Zu den Session-Nachrichten geh¨oren unter anderem Logon-, Heartbeat- und Logout- Nachrichten. Zu den Anwendungsnachrichten geh¨oren z.B. Nachrichten die zum ¨Offnen, Schließen oder ¨Andern eines Trades versendet werden aber auch um Tickdaten zu abon- nieren oder um History-Daten abzufragen. Dabei liegt es nat¨urlich am Broker, inwieweit er alle M¨oglichkeiten unterst¨utzt. Das FIX-Protokoll ist der Quasi-Standard, f¨ur den Handel an allen großen B¨orsenpl¨atzen dieser Welt, wobei die Versionen 4.2 und 4.4 noch weit verbreitet sind. Von den untersuchten Brokern unterst¨utzen, bis auf OEC und Gain Capital, alle Broker dieses Protokoll. Dadurch w¨ahre es optimal f¨ur ein Broker-¨ubergreifendes Programm zum De- visenhandel. Es ist allerdings nur f¨ur institutionelle Trader gedacht. So verlangen die Broker, welche das FIX-Protokoll unterst¨utzen, entweder hohe Lizenzgeb¨uhren und dazu monatliche Geb¨uhren oder es wird ein Konto mit einer hohen Mindestgr¨oße f¨ur das Kontoguthaben ver- langt. Ohne diese Voraussetzungen zu erf¨ullen, ließen sich auch keine Testprogramme erstellen. Aus diesem Grund wurde f¨ur diese Arbeit darauf verzichtet, das FIX-Protokoll zu imple- menteren. 3.1.1.2 Zugriff auf Handelsfunktionalit¨aten Alle untersuchten Broker unterst¨utzen den Handel von Devisen ¨uber eine eigene API. Die APIs sind dabei sehr unterschiedlich. Sie reichen von dem komplett auf Nachrichten basierten FIX- API, ¨uber den entfernten Aufruf von Methoden (RPC), bis zu einer Mischung aus beiden. So bietet z.B. FXCM eine Java-API an, welche das FIX-API in entsprechende Java-Klassen kapselt und damit komplett auf Nachrichten basiert. Zum Er¨offnen eines Trades muss hier eine Nachricht verschickt werden, wobei zum Setzen eines Stop- und Limit-Preises jeweils eine weitere Nachricht versendet werden muss. Stop- und Limit-Preis k¨onnen also auch erst gesetzt werden, nachdem der Trade ge¨offnet wurde. Als Antwort werden vom Broker, bei Erfolg, drei Executionreports, ein Positionreport und ein Collateralreport versendet, die alle auch ausge- wertet werden m¨ussen. Bei Dukascopy hingegen muss nur eine Methode aufgerufen werden, wobei hier direkt Stop- und Limit-Preis gesetzt werden k¨onnen. Als Anwort erh¨alt man vom Broker nur eine auszuwer- tende Nachricht. Dies und die folgenden Merkmale m¨ussen bei der Planung der Anwendung ber¨ucksichtigt werden, da diese nur Funktionalit¨aten haben kann, die alle Broker anbieten.
  • 31.
    KAPITEL 3. ANFORDERUNGSANALYSE23 Alle APIs erlauben die auf Seite 8 im Abschnitt 2.1.4 aufgelisteten Ordertypen. Teilweise k¨onnen auch noch zus¨atzliche Ordertypen verwendet werden, wie z.B. der Trailing Stop. Hier wird der Stop-Preis, beim Erreichen von bestimmten Zielen, automatisch nachgezogen. Von Broker zu Broker unterschiedlich, ist auch die Anzahl der unterst¨utzten W¨ahrungspaare. Diese reicht von 35 bis zu ¨uber 100 W¨ahrungspaaren. Alle Broker erlauben den Handel der sogenannten Majors, also EUR/USD, GBP/USD, AUD/USD, NZD/USD, USD/CHF und USD/JPY. 3.1.1.3 Zugriff auf Preisdaten Alle Broker, bis auf Dukascopy, unterscheiden zwischen Tick-Daten und dem Zugriff auf History- Daten. Die Tick-Daten werden ¨uber das eigene Trade-API und, falls vorhanden, ¨uber das FIX-API angeboten. Um Tickdaten zu erhalten, m¨ussen sie f¨ur jedes W¨ahrungspaar abboniert werden. Die Tickdaten werden dann unter Benutzung der Push-Technologie verteilt. Teilweise m¨ussen diese auch abboniert sein, um den Handel ¨uber die API zu erm¨oglichen. Der Zugriff auf History-Daten ist meist nur eingeschr¨ankt m¨oglich. Sie k¨onnen meist nur ¨uber ein extra API oder ¨uber das FIX-API abgefragt werden. Die Verf¨ugbarkeit von Preisdaten schwankt stark in der Genauigkeit der Daten. So sind teilweise nur Daten auf Tagesbasis f¨ur einen gr¨oßeren Zeitraum und genauere Daten wie z.B. auf Minutenbasis nur f¨ur einen kurzen Zeitraum verf¨ugbar. Das ist insbesondere f¨ur automatische Handelssysteme, wenn sie auf vergangene Zeitr¨aume getestet werden sollen, aber auch f¨ur Indikatoren, die einen großen Zeitraum analysieren, von Bedeutung. Hier werden m¨oglichst genaue Daten f¨ur einen m¨oglichst großen Zeitraum ben¨otigt, im Falle des Backtesting der Handelssysteme am besten Tickdaten. Weiterhin muss ber¨ucksichtigt werden, dass sich Broker in unterschiedlichen Zeitzonen befinden k¨onnen, was zu unterschiedlichen Daten f¨ur den gleichen Zeitraum f¨uhrt. So ist es m¨oglich, dass ein Broker auch Daten f¨ur Sonntage offeriert, obwohl der Handel erst am Montag um 0 Uhr beginnt. Zusammenfassend muss eine einheitliche L¨osung gefunden werden, bei der ein m¨oglichst umfangreicher Zugriff auf historische Preisdaten gegeben ist. Diese L¨osung sollte unabh¨angig von einem Broker sein. Hier gibt es zum einen die M¨oglichkeit auf externe Anbieter von History-Daten zur¨uckzu- greifen. Anbieter wie Google oder Yahoo offerieren B¨orsendaten kostenlos ¨uber eine einfache API, mit der Daten als csv-Dateien exportiert werden k¨onnen. Diese Daten sind allerdings um 15-Minuten verz¨ogert und damit f¨ur den Live-Handel nicht brauchbar. Andere Anbieter wie z.B. eSignal (www.esignal.com), netdania (www.netdania.com) oder iqfeed (www.iqfeed.net) bieten Live-Forex-B¨orsendaten zu einem Preis von ca. 100$ im Monat an, was je nach Paket und Anbieter differiert. Eine weitere M¨oglichkeit ist das Aufbauen einer eigenen Datenbasis. Dazu k¨onnten History- Daten von einem kostenlosen Anbieter heruntergeladen werden - am besten am Wochenende,
  • 32.
    KAPITEL 3. ANFORDERUNGSANALYSE24 wenn die B¨orsen geschlossen sind - und dann mit Hilfe der Tickdaten, die jeder Broker ¨ubermit- telt, gepflegt werden. Diese L¨osung hat den Vorteil, dass sie Broker-¨ubergreifend funktioniert - damit keine Abh¨angigkeiten aufweist - und keine Kosten durch externe Datendienste enstehen. Bei Hard- oder Softwareproblemen oder bei Ausfall der Internetverbindung kann es jedoch zu L¨ucken in der Datenbasis kommen. Die letzte L¨osungsvariante soll im Rahmen dieser Arbeit verwirklicht werden. 3.1.1.4 Zugriff auf Indikatoren FXCM und Dukascopy unterst¨utzen als einziges den Zugriff auf Indikatoren-Daten bzw. das Erstellen von eigenen Indikatoren ¨uber APIs. Bei FXCM k¨onnen Indikatoren-Daten ¨uber das Order2Go SDK abgefragt werden und mit Hilfe eines Indicator SDK eigene Indikatoren erstellt werden. Als Programmiersprache wird hierf¨ur Lua verwendet. Bei Dukascopy werden Indikatoren in Java erstellt und m¨ussen das IIndicator-Interface implementieren. Beide bieten eine Vielzahl von fertigen Standard- Indikatoren und unterst¨utzen damit das Erstellen von automatischen Handelssystemen. Zusammenfassend fehlt auch hier eine einheitliche und Broker ¨ubergreifende L¨osung, zu- mindest was die APIs der Broker betrifft. Aus diesem Grund wurde sich, im Rahmen dieser Arbeit entschieden, eine eigene Basis f¨ur das Erstellen von Indikatoren und damit auch f¨ur das Erstellen von automatischen Handelssystemen zu schaffen. 3.1.2 Unterst¨utzte Software Um den Devisenhandel mit Hilfe automatisierter Handelssysteme zu erm¨oglichen, unterst¨utzen die meisten Broker die Software externer Anbieter. Diese reichen von kostenloser und durchaus empfehlenswerter Software wie den Metatrader von MetaQuotes Software, bis hin zu profess- ioneller Chartsoftware von eSignal. Weitere Informationen finden sich hierzu in der Tabelle D.2 auf Seite 73. 3.2 Zielbestimmung Die Anforderungen an die Software ergeben sich aus dem letzten Unterkapitel und aus den allgemeinen Anforderungen an eine Software f¨ur den Devisenhandel. Sie werden in funktionale- und nicht-funktionale Anforderungen unterteilt. 3.2.1 Funktionale Anforderungen Die Anwendung ist in die Aufgabenbereiche: unterst¨utzte W¨ahrungspaare, Kontoverwaltung, Tradeverwaltung und automatische Handelssysteme unterteilt. Die jeweiligen Anforderungen finden sich in den folgenden Unterkaptiteln und in Form von Usecase-Diagrammen auf den Seiten 60 - 62. Das Diagramm f¨ur die W¨ahrungspaare wurde dabei weggelassen.
  • 33.
    KAPITEL 3. ANFORDERUNGSANALYSE25 3.2.1.1 W¨ahrungspaare Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur W¨ahrungspaare: ˆ unterst¨utzte W¨ahrungspaare: Beschreibung: Es sollen die W¨ahrungspaare EUR/USD, GBP/USD, AUD/USD und NZD/USD unterst¨utzt werden. Indikatoren und Handelssysteme m¨ussen Zugriff auf his- torische Preisdaten, aller auf Seite 5 im Kapitel 2.1.1 erw¨ahnten Zeitebenen, und auf aktuelle Tickdaten dieser W¨ahrungspaare haben. Diese Daten sollen kostenneutral zur Verf¨ugung stehen. ˆ W¨ahrungspaare anzeigen: Beschreibung: Es muss eine Liste geben, in der aktuelle Bid- und Ask-Preise angezeigt werden. Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur die W¨ahrungspaare: ˆ unterst¨utzte W¨ahrungspaare: Beschreibung: Es sollten weitere W¨ahrungspaare unterst¨utzt werden. 3.2.1.2 Kontoverwaltung Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur die Kontoverwaltung: ˆ PAMM-Konto anlegen: Beschreibung: Es muss eine Funktion geben um PAMM-Konten anzulegen. Als Eingabe wird ein Name ben¨otigt, der im System eindeutig sein muss. Nachbedingung: Konto wurde angelegt. ˆ PAMM-Konto l¨oschen: Vorbedingung: Es d¨urfen keine Trades in dem PAMM-Konto offen sein. Beschreibung: Es muss eine Funktion geben um PAMM-Konten und darin enthaltene Einzelkonten zu l¨oschen. Nachbedingung: PAMM-Konto und Einzelkonten wurden gel¨oscht. ˆ PAMM-Konten anzeigen: Beschreibung: PAMM-Konten und darin enthaltene Einzelkonten werden in einer Liste angezeigt. ˆ Einzelkonto anlegen: Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Im Einzelkonto sind keine Trades offen. Beschreibung: Ein Einzelkonto kann angelegt werden, dazu muss ein PAMM-Konto ausgew¨ahlt werden. Außerdem m¨ussen ein Broker ausgew¨ahlt und die Zugangsdaten eingegeben werden.
  • 34.
    KAPITEL 3. ANFORDERUNGSANALYSE26 Nachbedingung: Einzelkonto wurde angelegt und dem PAMM-Konto hinzugef¨ugt. Kon- tostatus wird auf Offline gesetzt. ˆ Einzelkonto l¨oschen: Vorbedingung: Es wurde ein Einzelkonto ausgew¨ahlt. Im Einzelkonto sind keine Trades offen. Beschreibung: Es muss eine Funktion geben um Einzelkonten zu l¨oschen. Nachbedingung: Das Einzelkonto wurde gel¨oscht und aus dem PAMM-Konto entfernt. Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur die Kontoverwaltung: ˆ Kontow¨ahrungen: Es sollten als Kontow¨ahrung f¨ur Einzelkonten nicht nur US-Dollar, sondern auch weitere W¨ahrungen unterst¨utzt werden. ˆ PAMM-Konten ¨andern: Es sollte die M¨oglichkeit geben, den Namen von PAMM-Konten zu ¨andern. ˆ Einzelkonto ¨andern: Es sollte die M¨oglichkeit geben, die Daten von Einzelkonten zu ¨andern. 3.2.1.3 Tradeverwaltung Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur die Tradeverwaltung: ˆ PAMM-Trade erstellen: Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Das PAMM-Konto enth¨alt Einzelkonten, die alle online sein m¨ussen. Beschreibung: Das System generiert f¨ur alle im PAMM-Konto enthaltenen Einzelkonten, entsprechend dem Guthaben, jeweils einen Trade und l¨ost ihn aus. Es m¨ussen alle auf Seite 8 im Abschnitt 2.1.4 aufgef¨uhrten Ordertypen unterst¨utzt werden. Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde ausgef¨uhrt. ˆ PAMM-Trade schliessen: Vorbedingung: Es wurde ein PAMM-Trade ausgew¨ahlt, der offen ist. Beschreibung: Es werden der PAMM-Trade und alle dazu geh¨origen Einzeltrades geschlossen. Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde geschlossen. ˆ PAMM-Trades anzeigen: Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Beschreibung: Es werden alle zum Konto geh¨orenden PAMM-Trades gezeigt, getrennt in offene und bereits geschlossene Trades.
  • 35.
    KAPITEL 3. ANFORDERUNGSANALYSE27 ˆ Stop- und/oder Limit-Preis setzen: Vorbedingung: Es wurde ein PAMM-Trade ausgew¨ahlt, der offen ist. Beschreibung: Stop- und Limit-Preis k¨onnen gesetzt werden, wenn sie die auf der Seite 8 in der Tabelle 2.1 aufgef¨uhrten Bedingungen erf¨ullen. Nachbedingung: Stop- und Limit-Preis werden beim PAMM-Trade und bei allen dazu geh¨origen Einzeltrades gesetzt. 3.2.1.4 automatische Handelssysteme Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur automatische Handelssysteme: ˆ Indikator erstellen: Beschreibung: Es muss eine M¨oglichkeit geben, Indikatoren zu erstellen. Der Indikator verf¨ugt ¨uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigen- schaften, die vom Handelsystem gesetzt werden m¨ussen. Diese Eigenschaften k¨onnen vom Typ: String, Integer, Double und Boolean sein. F¨ur jede Eigenschaft k¨onnen minimale und maximale Werte festgelegt werden. Außerdem muss der Indikator eine Eingabem¨oglichkeit f¨ur mindestens ein W¨ahrungspaar und f¨ur eine Zeitebene besitzen. Nachbedingung: Der Indikator wird zum Programm hinzugef¨ugt und kann von Handelssys- temen genutzt werden. ˆ Handelssystem erstellen: Vorbedingung: Das Handelssystem hat Zugriff auf ben¨otigte Indikatoren. Beschreibung: Es muss eine M¨oglichkeit geben Handelssysteme, zu erstellen und zum Pro- gramm hinzuzuf¨ugen. Das Handelssystem verf¨ugt ¨uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigenschaften, die vom Benutzer beim Starten geset- zt werden k¨onnen. Diese Eigenschaften k¨onnen vom Typ: String, Integer, Double und Boolean sein. F¨ur jede Eigenschaft k¨onnen minimale und maximale Werte festgelegt wer- den. Nachbedingung: Das Handelssystem wird zum Programm hinzugef¨ugt und ist vom Be- nutzer ausw¨ahlbar. ˆ Handelssystem starten: Vorbedingung: Die vom Handelssystem geforderten Eigenschaften wurden vom Be- nutzer mit validen Werten gesetzt und es wurde ein PAMM-Konto, ein oder mehrere W¨ahrungspaare und eine Zeitebene ausgew¨ahlt. Beschreibung: Es muss eine M¨oglichkeit geben, ein Handelssysteme zu starten, welches dann mit dem automatischen Handel beginnt. Nachbedingung: Das Handelssystem wird vom Programm mit den ausgew¨ahlten Parame- tern gestartet und erh¨alt, genau wie davon benutzte Indikatoren, Zugriff auf aktuelle und historische Preisdaten.
  • 36.
    KAPITEL 3. ANFORDERUNGSANALYSE28 ˆ Handelssystem stoppen: Vorbedingung: Es wurde ein Handelssystem ausgew¨ahlt. Beschreibung: Es muss eine M¨oglichkeit geben, Handelssysteme zu stoppen. Nachbedingung: Das Handelssystem wird gestoppt. ˆ laufende Handelssysteme anzeigen: Beschreibung: Es muss eine M¨oglichkeit geben, alle laufenden Handelssysteme anzuzeigen. Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur automatische Handelssysteme: ˆ Handelssystem ¨andern: Es sollte die M¨oglichkeit geben, die Eingabe-Parameter bereits laufender Handelssysteme zu ¨andern. 3.2.2 Nicht-Funktionale Anforderungen ˆ Hintergrundfunktionen: Die Anwendung muss die Tickdaten aufzeichnen und die Daten f¨ur die History berechnen, um die von Indikatoren und Handelssystemen ben¨otigten Daten zur Verf¨ugung stellen zu k¨onnen. Diese Funktionen, genauso wie die automatischen Handelssysteme, m¨ussen m¨oglichst 24 Stunden am Tag ohne Unterbrechung laufen. ˆ Mehrbenutzerf¨ahig: Die Anwendung soll in dem Sinne mehrere Benutzer unterst¨utzen, dass gleichzeitig mehrere Benutzer mit dem gleichen Datenbestand arbeiten k¨onnen, ohne dass es ein Login gibt. Alle Benutzer arbeiten also mit den gleichen Rechten, den gleichen Daten und sind vom System nicht unterscheidbar. ˆ Verschl¨usselung der Daten¨ubertragung: Auf eine Verschl¨usselung der Kommunikation wird verzichtet. 3.2.3 Abgrenzungskriterium Die Anwendung ist haupts¨achlich gedacht als Plattform f¨ur automatische Handelssysteme und hat als Zielgruppe erfahrene Trader. Diese sollen zwar die M¨oglichkeit haben in Trades einzu- greifen und selber zu traden. Auf die Anzeige von Charts wird jedoch verzichtet.
  • 37.
    Kapitel 4 Entwurf Aus denim letzten Kapitel ermittelten Anforderungen ergeben sich eine Reihe von Fragen, die f¨ur den Entwurf der Anwendungs- und Systemarchitektur entscheidend sind. So m¨ussen eine Reihe verschiedener Aspekte beachtet werden, die unter anderem die Datenspeicherung, die Transaktionsbehandlung, die Integration der Broker-APIs, die Verteilung der Systembe- standteile und die Kommunikation der Kompenenten untereinander betreffen. Dieses Kapitel widmet sich dem Entwurf der Anwendung unter den genannten Gesichts- punkten, dabei werden verschiedene L¨osungsans¨atze vorgestellt und diskutiert. 4.1 System-Architektur Aus den Anforderungen an die Anwendungen ergab sich, dass einige Komponenten m¨oglichst ohne Unterbrechung laufen sollen. Außerdem soll die Anwendung mehrbenutzerf¨ahig sein und den Zugriff auf die Systeme der Broker erm¨oglichen. Eine Trennung in Client und Server ist daf¨ur die beste L¨osung. Daraus ergibt sich eine so- genannte Mehrschichten-Architektur, die sich aus Pr¨asentationsschicht, Datenhaltungsschicht, der Schicht f¨ur die Gesch¨aftslogik und einer Schicht f¨ur die Einbindung der Broker-APIs zusam- mensetzt. In den Abbildungen C.5 und C.6, auf den Seiten 63 bis 63, werden die Schichtenar- chitektur und die Verteilung der Systeme schematisch dargestellt. Der Client ist hier nur f¨ur die Pr¨asentation und Validierung zust¨andig und entlastet damit den Server. Die Gesch¨aftslogikschicht wird auf den Server ausgelagert. Sie agiert als Fassade und kapselt den Zugriff auf die Broker-APIs und auf die Datenschicht. Sie ist der Vermittler zwischen dem eigenen System und den Broker-Systemen und vereinheitlicht die Datenmodelle durch Transformation der zu ¨ubermittelnden Daten. Durch die Trennung in Schichten ergeben sich eine Reihe von Vorteilen. Zum einen ist der Zugriff auf die Daten und auf die externen Systeme gesch¨utzt, da kein direkter Zugriff von außen m¨oglich ist. Zum anderen skaliert die Anwendung sehr gut, da die einzelnen Schichten logisch voneinander getrennt sind und somit ¨uber mehrere Datenbank- sowie Anwendungsser-
  • 38.
    KAPITEL 4. ENTWURF30 ver verteilt werden k¨onnen. Außerdem ergeben sich wiederverwendbare Komponenten, z.B. f¨ur den Zugriff auf Daten oder die Kommunikation zwischen Client und Server. Der Datenzugriff erfolgt ¨uber Data Access Objects (DAOs), die den Zugriff ¨uber Schnittstellen kapseln und deren Implementierung damit leicht austauschbar ist. F¨ur das Verteilen von Daten - zwischen Client und Server - werden Data Transfer Objects (DTOs) verwendet, die nur Daten und keine Anwendungslogik enthalten. 4.1.1 ” Event-Driven-Architecture“ Die Anwendung muss auf eine Vielzahl von verschiedenen Events reagieren, die von externen und internen Systemen ausgel¨ost werden. So k¨onnen z.B. Einzelkonten on- oder offline gehen und Trades nach dem Erreichen bestimmter Ziele automatisch geschlossen oder von automatischen Handelssystemen ausgel¨ost werden. Die Anwendung hat weiterhin nur indirekten Einfluss auf die externen Systeme der Broker. So kann sie zwar Trades und Orders ausl¨osen, wird aber durch Events erst sp¨ater ¨uber die Ausf¨uhrung informiert. Trades und Konten k¨onnen sich damit in verschiedenen Zust¨anden befinden, die ber¨ucksichtigt werden m¨ussen. Eine solche System- Architektur wird als ” Event-Driven“ bezeichnet. 4.1.2 Transaktionen in einer Mehrschichten-Architektur Problematisch ist die Einbindung der externen Systeme, im Kontext von Vorg¨angen die Transak- tionen ben¨otigen. Aktionen die PAMM-Trades oder PAMM-Konten betreffen, m¨ussen in G¨anze auf allen dazugeh¨origen Einzel-Trades bzw. -Konten ausgef¨uhrt werden. Im Gegensatz zu in- ternen Datenbanken gibt es jedoch bei externen Systemen nicht die M¨oglichkeit in Fehlerf¨allen ein Rollback durchzuf¨uhren. Das muss bei der Implementierung ber¨ucksichtigt werden. Es muss damit vor jeder Aktion gepr¨uft werden, ob ben¨otigte Komponenten sich in einem fehlerfreiem Zustand befinden. Sind z.B. die von einer Aktion betroffenen Konten nicht online oder verf¨ugbar, dann muss diese abgebrochen werden. 4.1.3 System-Umgebung Die Anwendung wird f¨ur MS-Windows entwickelt, sollte allerdings m¨oglichst leicht auf an- dere Betriebssysteme portierbar sein. Es wurde sich deshalb f¨ur die Programmiersprache Java entschieden, da sie plattformunabh¨angig ist und man - mit dem Java Native Interface (JNI) - auch auf C-Bibliotheken zugreifen k¨onnte. An dieser Stelle sei erw¨ahnt, dass Java f¨ur Echtzeit-Anwendungen oft kritisch betrachtet wird. Dies liegt daran, dass es unter Java keine M¨oglichkeit gibt, Objekte selbst aus dem Speicher zu entfernen. Diese Aufgabe ¨ubernimmt der Garbage Collector, ein vollautomatischer Speicher- manager. Hierbei kann es zu Full-Garbage-Collections und damit sehr langen Pausen kommen. (Eine Full-Garbage-Collection h¨alt das System komplett an (stop-the-world, Mark-and-Sweep-
  • 39.
    KAPITEL 4. ENTWURF31 Algorithmus), um die Objekte zu analysieren und Speicher freizugeben und zu kompaktieren.) Diese langen Pausen k¨onnen unvorhersehbar eintreffen und in Ihrer Dauer, zumindest beim Standard-Garbage-Collector, nicht beeinflusst werden. Um das Ziel von vorhersagbaren und konstant kurzen Pausen zu erreichen, wurde von Sun der Garbage First (G1) Collector en- twickelt. Hier m¨usste die Anwendung in Langzeittests untersucht und optimiert werden, um optimale Einstellungen zu finden. Aus Zeitgr¨unden konnte das zwar nicht mehr genauer untersucht wer- den, es sei aber auf die Artikelreihe ” Memory Management“ im Java Magazin verwiesen, die mit der Ausgabe 3.2010 beginnt. Weitere Ansatzpunkte k¨onnten die f¨ur kommerzielle Anwendungen gedachten Java-Echtzeit-Plattformen: Java Real-Time System von Sun, WebSphere Real Time von IBM oder JRockit von Oracle sein (siehe [Orac], [IBM] und [Orab]). 4.1.4 System–Plattform Wie bereits beschrieben, muss die Anwendung leicht um weitere Indikatoren und Handelssys- teme erweiterbar sein. Mit der OSGi Plattform, wurde eine optimale L¨osung gefunden, da sie zum Einspielen von Erweiterungen nicht gestoppt werden muss und als Modulsystem diese An- forderung explizit unterst¨utzt. Sie bildet die Grundlage f¨ur die Serveranwendung, w¨ahrend die Clientanwendung auf Eclipse RCP basiert. 4.2 Datenspeicherung Das Datenmodell wurde aus den Erkenntnissen der vorherigen Kapitel extrahiert und ist in Form eines Entity-Relationship-Modells (ERM) auf den Seiten 64 und 65 dargestellt. Um die Beziehungen zwischen den Entit¨aten besser zu kennzeichen, wurde, in Abweichung zu Chen, die ” ist ein“-Beziehung mit einer gestrichelten Linie markiert. Das Datenmodell stellt unterschiedliche technische Anforderungen, an das Persistieren der Daten. Diese sollen in den nachfolgenden Unterkapiteln diskutiert werden. 4.2.1 Trade-, Order- und Kontodaten Bei den Trade-, Order1 - und Kontodaten handelt es sich um gut strukturierte Daten, die leicht zu normalisieren sind. Einzige Besonderheit ist, dass eine Transaktionsbehandlung ben¨otigt wird. So besteht z.B. ein PAMM-Trade aus vielen einzelnen Trades und damit eine Aktion zum Speichern auch aus einzelnen Speicheroperationen, die gemeinsam ausgef¨uhrt und abgeschlossen werden m¨ussen. Nur dann ist die Konsistenz und Integrit¨at der Daten gew¨ahrleistet. 1Der Begriff der Order wird ab hier in zwei verschiedenen Zusammenh¨angen verwendet. Eine Order ist zum einen ein Auftrag an das System, einen offenen Trade zu ¨andern oder zu schließen. Zum Anderen kann ein Trade vom Typ: Pending Order oder Market Order sein.
  • 40.
    KAPITEL 4. ENTWURF32 Damit eignen sich insbesondere relationale Datenbanken f¨ur die Benutzung als Speicherl¨o- sung. Diese sind durch den Einsatz von Index- und Caching-Mechanismen, anderen L¨osungen wie z.B. dem Datei-basierten Speichern ¨uberlegen und bieten meist eine Transaktionsverwal- tung. Weiterhin skalieren Datenbanken sehr gut mit wachsenden Anforderungen, da Sie auf extra Rechner verlagert und geclustert werden k¨onnen. Aus diesem Grund, wird sich f¨ur eine relationale Datenbank als Speicherl¨osung entschieden, genauer MySQL mit der Speicher Engine: InnoDB2 . Die Wahl fiel hierbei auf die InnoDB, da sie im Gegensatz zu MyISAM Transaktionen unterst¨utzt. 4.2.2 Parameterdaten f¨ur automatische Handelssysteme Die automatischen Handelssysteme haben eine unterschiedliche Anzahl von Einstellungspara- metern, mit einem vorgegeben Satz von unterschiedlichen Basis-Datentypen. Diese Parameter werden im Diagramm C.8 als payload bezeichnet. Das Problem ist hier, dass sich eine von System zu System unterschiedliche Anzahl der Einstellungsparameter mit jeweils unterschiedlichen Datentypen nicht so einfach in einer rela- tionalen Datenbank abbilden l¨asst. Eine M¨oglichkeit w¨are das Umwandeln der Parameter-Daten in einen String, wobei die einzelnen Parameter durch einen Delimeter getrennt sind. Eine weitere M¨oglichkeit w¨are das Umwandeln in Bin¨ardaten und das Abspeichern als BLOB3 . Da diese Daten dann Key-Value-Paare darstellen, k¨onnte auch das Verwenden darauf spezial- isierter Key-Value- oder auch NoSQL-DB genannten Datenbanken, wie z.B. BerkleyDB, Mon- goDB oder CouchDB, in Betracht gezogen werden. Bei der geringen Anzahl von Datens¨atzen w¨urde sich eine Datenbank nur f¨ur die Parameter-Daten der Handelssysteme allerdings nicht lohnen. Es wurde sich schliesslich f¨ur das Speichern als serialisierte Objekte entschieden, da keine besonderen Anforderungen vorliegen, die den Einsatz von anderen Speicherformen rechtfertigen w¨urden. 4.2.3 Tick- und Bardaten Wie bereits beschrieben, werden die f¨ur Bars4 ben¨otigten Preise: Open, High, Low und Close aus der Analyse von Rohdaten, den Tick-Daten, gewonnen. Diese Daten werden von den au- tomatischen Handelssystemen und den Indikatoren ben¨otigt. Eine Besonderheit ist, dass z.B. Indikatoren immer Zugriff auf die aktuellen und die his- torischen Daten f¨ur einen bestimmten Zeitraum ben¨otigen. So braucht ein 200er Moving Aver- age auf Tagesbasis immer Zugriff auf die letzten 199 Tagesbars und auf den aktuellen Tagesbar, 2siehe [MySb] 3BLOB (binary large object) ist ein MySQL-Datentyp zum Abspeichern von Bin¨ardaten, siehe [MySa]. 4Anstatt Candlestick wird ab jetzt der Begriff Bar verwendet. Beide stellen Container f¨ur die Preise: Open, High, Low und Close dar und k¨onnen deshalb in diesem Kontext synonym verwendet werden.
  • 41.
    KAPITEL 4. ENTWURF33 um den aktuellen Moving Average zu berechnen. Um ad hoc die Moving Average Werte f¨ur die letzten 4 Bars zu berechnen, m¨ussten also die Tickdaten der letzten 204 Tage ausgewertet werden. Nun ist es kein Problem die Tick-Daten in einer relationalen Datenbank zu speichern. Da- raus dann mit Hilfe von SQL-Abfragen die Bars zu extrahieren, w¨are allerdings eine denkbar langsame L¨osung, bei ca. 100.000 Ticks pro Tag, pro W¨ahrungspaar. Eine einfachere und effizientere L¨osung ist das Berechnen der Bars anhand der laufenden Tickdaten. Dabei wird, um bei den Tagesbars zu bleiben, f¨ur jeden Tag um 0 Uhr ein neuer Bar erstellt und der alte Bar gespeichert. Der neue Bar speichert bei Er¨offnung den aktuellen Marktpreis als Open-, High-, Low- und Close-Preis. Bei jedem Tick wird der Close-Preis gesetzt und gepr¨uft ob ggf. auch High und Low neu gesetzt werden m¨ussen. Da diese Operationen im Arbeitsspeicher ablaufen, sind Sie sehr schnell, auch der Speicherverbrauch ist sehr gering. Das wird f¨ur alle geforderten Zeitebenen und W¨ahrungspaare gemacht. Diese Bar-Daten k¨onnten in einer Datenbank gespeichert werden. Alternativ k¨onnten Tickdaten in Dateiform gespeichert und verschiedene L¨osungen, wie z.B. Apache Hadoop (Eine Implementierung, des von Google ver¨offentlichten Map-Reduce- Verfahrens), der Rapidminer von Rapid-I oder die Programmiersprache R verwendet werden (siehe [Apab], [Whi10], [Rap] und [R F]). Diese sind f¨ur die Analyse großer Datenmengen optimiert. Aus Zeitgr¨unden konnten sie jedoch nicht mehr evaluiert werden. Aus Performancegr¨unden wird deshalb eine Speicherl¨osung auf Dateibasis einer Datenbank- l¨osung vorgezogen. Dazu wird f¨ur jedes W¨ahrungspaar ein Ordner angelegt und darin f¨ur jede Zeitebene eine Datei angelegt. In der Datei werden die Bar-Daten, nach Datum sortiert, in Form von Bin¨ardaten gespeichert. (Mit dieser L¨osung kann auf Indizes verzichtet werden, außer- dem belegen Bin¨ardateien weniger Speicherplatz als Textdateien.) Als Zugriffsmethode wird die NIO-API gew¨ahlt, da diese performanter als die IO-API ist. Beide sind Java-APIs zum Lesen/Schreiben von Daten aus/in Dateien oder Sockets, wobei NIO erst seit dem JDK 1.4 eingesetzt werden kann und unter anderem Locking (Sperrt den Zugriff auf eine Datei durch andere Prozesse) unterst¨utzt. Durch Locking-Mechanismen muss die Integrit¨at und Konsistenz der Daten sichergestellt werden. 4.3 Kommunikationsprotokoll Als Mittel f¨ur die Kommunikation zwischen Client und Server wurde sich f¨ur ein asynchrones Kommunikationsprotokoll entschieden. Diese beruhen auf dem Versenden von Nachrichten und eignen sich insbesondere f¨ur Ereignis gesteuerte Systeme und f¨ur l¨anger laufende Operatio- nen, wenn die zu ¨ubertragenden Daten nicht sehr groß sind. Außerdem l¨asst sich synchrone Kommunikation - also der Aufruf von entfernten Methoden - mit tempor¨aren Warteschlangen simulieren.
  • 42.
    KAPITEL 4. ENTWURF34 Als Framework wurde sich f¨ur den Java Messaging Service5 (JMS) entschieden. JMS seria- lisiert die Nachrichten, im Gegensatz zu XML-Protokollen wie dem synchronen SOAP, die vom Nachrichten-Broker je nach Anwendungszweck persistiert werden. JMS skaliert sehr gut, ist clusterf¨ahig und unterst¨utzt Transaktionen. Tritt z.B. beim Abholen einer Nachricht ein Fehler auf, so bleibt diese beim Message-Broker und kann erneut abgeholt werden. Als weitere M¨oglichkeiten, wurden Apache MINA und insbesondere das JBoss Netty-Project, in Verbindung mit Google Protobuf (Serialisiert Daten in einem besonders kompakten Format.), in Betracht gezogen (siehe [Apac], [JBo] und [Gooa]). Beide werden als hoch performant be- trachtet. So ergeben sich bei Netty in Verbindung mit Google Protobuf, Nachrichten die einen geringeren Speicherverbrauch als JMS-Nachrichten haben und schneller serialisiert und deseri- alisiert werden6 . Aufgrund des hohen Implementierungsaufwands wurde jedoch JMS bevorzugt. 5siehe [Apaa] und [Abt10] Seite 281 ff. 6siehe [eis], ein aufgrund vorhandenem Source-Code nachvollziehbarer Vergleich zwischen Protobuf-, XML- und Java-Serialisierung
  • 43.
    Kapitel 5 Implementierung Die imRahmen dieser Arbeit erstellte Anwendung ist eine verteilte, komponentenbasierte An- wendung. Die einzelnen Komponenten sind durch Schnittstellen und den Event-Admin-Service lose gekoppelt (siehe Komponenten-Diagramm1 , Seite 67). In diesem Kapitel wird die Anwen- dung und die Implementierung der wichtigsten Komponenten beschrieben. 5.1 Events Mit Hilfe des Event-Admin-Service werden Ergebnisse von Client-Auftr¨agen und Sta- tus¨anderungen in Form von Events verteilt. Die Events werden in TradingsystemEvent, Ac- countEvent und OrderEvent unterschieden und ¨uber unterschiedliche Topics publiziert. Die jeweiligen Auspr¨agungen wurden in Form von Enumerations abgebildet (siehe Klassendiagramm C.9, Seite 66). Die Events werden auf Serverseite publiziert, dabei regeln die Komponenten Event-To-JMS und JMS-To-Event die ¨Ubermittlung an den Client. Es werden allerdings nur die f¨ur den Client wichtigen Events ¨ubertragen. Event-To-JMS registriert sich als Eventhandler und wandelt alle im Event enthaltenen Objekte in DTOs um, die nur aus Basisdatentypen bestehen. Auf das Serialisieren der ur- spr¨unglichen Objekte wurde verzichtet2 , um die Kommunikation unabh¨angig von Java zu halten (Der verwendete JMS-Broker erlaubt auch C++, C#, Ruby, Perl, Python und PHP-Clients). JMS-To-Event stellt daraus das urspr¨ungliche Event wieder her und publiziert es auf Client- seite. Dadurch kann das Kommunikationsprotokoll f¨ur das Verteilen von Events jederzeit aus- getauscht werden. 1Auf die Darstellung des Logging-Dienstes wurde aus Gr¨unden der ¨Ubersichtlichkeit verzichtet, da er von fast jeder Komponente verwendet wird. 2Das gilt auch f¨ur vom Client ubertragene Order und an den Client ¨ubersandte Tick-Daten
  • 44.
    KAPITEL 5. IMPLEMENTIERUNG36 1 HashMap <String , Object > eventProperties = new HashMap <String , Object >(); 2 eventProperties .put(APIService.ORDER_EVENT ,OrderEvent. TRADE_CLOSED ); 3 eventProperties .put(APIService.SINGLE_ACCOUNT_ID ,accountID ); 4 eventProperties .put(APIService.EVENT_DATE , new Date(System. currentTimeMillis ())); 5 Event event = new Event("de/pammtrader/core/api/ single_order /FXCM", eventProperties ) Listing 5.1: Beispiel f¨ur ein Trade-Closed-Event Das Listing 5.1 zeigt beispielhaft ein Event, das beim Schließen eines Einzeltrades ausgel¨ost wird. Das Event enth¨alt eine Hashmap und ein Topic. Die Hashmap(Listing 5.1, Zeilen 1-4) enth¨alt das ausgel¨oste Event und dazu geh¨orige Daten. In diesem Beispiel wird nur die ID des zum Event geh¨origen Objekts ¨ubermittelt. Bei Events wo Java-Objekte neu erstellt wurden, ist das komplette Java-Objekt in der Hashmap enthalten, also bei neuen Trades, Orders und neuen Konten. Anhand des Topics (Listing 5.1, Zeile 5) l¨asst sich ermitteln, dass es sich bei dem geschlossenen Trade um einen Trade f¨ur ein Einzelkonto beim Broker FXCM handelt. 5.2 Client Der Client basiert auf der Eclipse RCP. Er besteht zum einen aus den Komponenten JMS-To- Event und JSM-To-Tick, die f¨ur die Verteilung von Events und Tick-Daten zust¨andig sind. Zum anderen aus dem Controller und GUI-Elementen. Die GUI-Elemente implementieren die Inter- faces IAccountListener und/oder ITickListener und registrieren sich als Dienste (Whiteboard- Pattern) um ¨uber das Eintreffen von Trade-, Konto- und Tickdaten informiert zu werden. Liegen neue Daten vor, so greifen sie darauf ¨uber Content-Provider zu. Der Controller implementiert das Interface IAccountDAO und dient dem Zugriff auf Trade- und Konto-Daten und dem Absetzen von Auftr¨agen an den Server. In den folgenden Un- terkapiteln, wird die Benutzeroberfl¨ache des Clients kurz n¨aher erl¨autert. 5.2.1 Login-Ansicht Abbildung 5.1: FxTrader Client - Login Nach dem Start der Client-Anwendung ¨offnet sich als erstes das Login-Fenster (siehe Abbil- dung 5.1). Hier muss die Server-Adresse inklusive des Ports vom JMS-Broker angegeben werden.
  • 45.
    KAPITEL 5. IMPLEMENTIERUNG37 Bei einer lokalen Installation w¨are ” localhost:61616“ ein valider Wert, wenn der Standardport benutzt wird. Konnte die Verbindung zum Server hergestellt werden, dann initialisiert die Anwendung Kontodaten, Tradedaten und Handelssystemdaten. Dazu wird ein RPC simuliert, indem eine tempor¨are Warteschlange (Queue) erzeugt wird. Im Nachrichten-Header ” JMSReplyTo“ wird dieser als Anwort-Queue gesetzt und dem Server bei der Anfrage ¨ubermittelt. Nachdem der Server geantwortet hat, werden die Daten initialisiert. Dann tr¨agt sich die Anwendung als Empf¨anger von Tickdaten und Events in die entsprechenden Topics ein, und startet die Haup- tansicht. 5.2.2 Hauptansicht Symbolübersicht Kontenübersicht Handelssysteme Tradeübersicht Abbildung 5.2: FxTrader Client - GUI Die Benutzeroberfl¨ache (siehe Abbildung 5.2) wurde nach der Workbench-Metapher3 gestal- tet und ist in Men¨uzeile, Toolbar und Hauptfenster unterteilt. Die in den Usecases definierten Aktionen k¨onnen entweder ¨uber Kontextmen¨us, Men¨uzeile oder Toolbar ausgel¨ost werden. Diese Aktionen sind meist nur erlaubt, wenn ein dazu passendes Element ausgew¨ahlt wurde. So muss z.B. um einen Trade auszul¨osen ein PAMM-Konto ausgew¨ahlt werden. Das Hauptfenster ist un- terteilt in Symbol¨ubersicht, Konten¨ubersicht, Trade¨ubersicht und einer ¨Ubersicht aller laufend- en automatischen Handelssysteme. 3siehe [Rei09] Seite 52ff
  • 46.
    KAPITEL 5. IMPLEMENTIERUNG38 5.2.2.1 Symbol¨ubersicht Die Symbol¨ubersicht soll dem Benutzer eine Markt¨ubersicht geben und zeigt alle handelbaren W¨ahrungspaare, mit aktuellen Bid- und Ask-Preisen. Symbole k¨onnen der Liste hinzugef¨ugt und aus ihr entfernt werden. 5.2.2.2 Konten¨ubersicht Die Konten¨ubersicht stellt PAMM-Konten und darin enthaltene Einzelkonten in einer Baum¨ubersicht dar. Hier k¨onnen PAMM- und Einzelkonten angelegt und gel¨oscht werden. Außerdem k¨onnen PAMM-Trades ausgel¨ost werden, allerdings nur wenn alle darin enthalte- nen Einzelkonten online sind. Einzelkonten werden mit einem roten Symbol, wenn sie offline sind, oder mit einem gr¨unen Symbol, wenn sie online sind, dargestellt. 5.2.2.3 Trade¨ubersicht In der Trade¨ubersicht werden nach PAMM-Konten getrennt offene und bereits geschlossene PAMM-Trades angezeigt. Sie wird durch einen Doppelklick auf ein PAMM-Konto in der Kon- ten¨ubersicht ge¨offnet. Bei offenen Trades k¨onnen nachtr¨aglich Stop- und Limit-Preis gesetzt bzw. ge¨andert werden. Weiterhin k¨onnen hier Trades geschlossen werden. 5.2.2.4 Automatische Handelssysteme Hinweise für den Benutzer Abbildung 5.3: FxTrader Handelssysteme - Eingabe von Parametern Diese ¨Ubersicht zeigt alle offenen Handelssysteme an, sie k¨onnen hier gestartet und gestoppt werden. Um ein Handelssystem zu starten, wird ein Wizard (siehe Abbildung 5.3) ge¨offnet. Auf der ersten Seite wird das Handelssystem ausgew¨ahlt und allgemein g¨ultige Parameter, also W¨ahrungspaar, Zeitebene und Konto, eingegeben. Die n¨achste Seite wird anhand der vom Han- delssystem vorgegebenen Parameter erstellt. Es werden automatisch, f¨ur Java-Basisdatentypen (außer Boolean), Eingabefelder und f¨ur Parameter mit vorgegebenen Auswahlm¨oglichkeiten
  • 47.
    KAPITEL 5. IMPLEMENTIERUNG39 (inklusive Boolean) Dropdown-Listen erstellt. Der Wizard ¨uberpr¨uft die Eingaben auf Validi- t¨at, f¨uhrt die Konvertierung durch und gibt dem Benutzer verschiedene Hilfestellungen in Form von Popup-Meldungen und Hinweisen im oberen Bereich. Sind alle Einstellungen valide, dann kann der Wizard abgeschlossen und die Daten an den Server gesendet werden. Der Server initialisiert und startet dann das Handelssystem. 5.3 Server Der Server basiert auf OSGi, siehe Komponentendiagramm C.10, Seite 67. Die Server- Komponenten werden jeweilig in Form von Bundles ausgeliefert, dabei sind Schnittstellen und Implementierung getrennt. Die Schnittstellen der Server-Komponenten finden sich in Klassendi- agrammen auf den Seiten 69 und 70, letztere enth¨alt zus¨atzlich die Klassen der Handelssysteme und Indikatoren. In diesem Kapitel wird auf die Implementierung eingegangen. Anmerkung: Der im Diagramm C.10 gezeigte JMS-Broker wird in Form eines Bundles aus- geliefert. Hier wird nur ein Objekt vom Typ ” org.apache.activemq.broker.BrokerService“ ini- tialisiert und der Dienst gestartet, auf eine weitere Beschreibung wird deshalb verzichtet. 5.3.1 Broker-APIs Die APIs der Broker Dukascopy und FXCM wurden implementiert. Sie werden jeweils in einem OSGi-Bundle ausgeliefert, das aus Bundle-Activator, API-Controller, der Broker-API und einer Klasse f¨ur ein Einzelkonto dieses Brokers besteht. Der Bundle-Activator erstellt beim Start des Bundles ServiceTracker f¨ur LogService, Event- admin und ITickReceiver (siehe Listing 5.2, Zeilen 2-4). API-Controller und Konten greifen ¨uber entsprechende Methoden auf diese Services zu, um zu loggen und um Events und Tickdaten zu versenden. Weiterhin initialisiert er den API-Controller und registriert ihn als Dienst unter dem Interface APIService (siehe Listing 5.2, Zeilen 5-10). 1 ServiceTracker tickListenerTracker = new ServiceTracker 2 (context , ITickReceiver .class.getName (), null ); 3 tickListenerTracker .open (); 4 DukascopyAPIService dukascopyApi = new DukascopyAPIService (); 5 Dictionary <String , String > properties = new ... 6 properties.put(APIService.BROKER_API , DukascopyAPIService . SERVICENAME ); 7 bundleContext . registerService (APIService.class.getName (), dukascopyApi , properties ); Listing 5.2: Ausschnitt aus Bundle-Activator einer Broker-API Beim Registrieren wird eine Service-Property ¨ubergeben, die den Namen des Broker enth¨alt, dadurch lassen sich die Broker-Dienste nach Namen filtern. Der API-Controller fungiert als Fas- sade, erstellt Einzelkonten und steuert den Zugriff darauf. Er vermittelt durch Transformation der Daten, zwischen dem eigenen System und dem Broker-System. So versteht z.B. Dukascopy unter einem Lot nicht 100.000$ sondern 1.000.000$ und bildet ein W¨ahrungspaar ¨uber die eigene Klasse Instrument ab, was hier entsprechend umgewandelt wird.
  • 48.
    KAPITEL 5. IMPLEMENTIERUNG40 Jedes Einzelkonto wird Broker-spezifisch abgebildet, stellt unabh¨angig von anderen Konten eine Verbindung zum Broker her und bleibt aus Performancegr¨unden immer verbunden. Sie leit- en die Auftr¨age des API-Controller an den Broker weiter und publizieren ¨uber Events wie, wann und ob diese Auftr¨age abgewickelt wurden. Außerdem publizieren Sie sofort das ¨Andern von Konto- und Tradestatus und das aktuelle Kontoguthaben. Das Kontoguthaben wird allerdings in einem Intervall von 10 Sekunden publiziert. Erst mit dem Publizieren des Kontoguthabens wird dieses Konto als online betrachtet, um die korrekte Verteilung von PAMM-Trades nach Kontogr¨osse zu gew¨ahrleisten. Jedes Einzelkonto verarbeitet Auftr¨age ¨uber einen eigenen ” Sin- gleThreadExecutor“4 , dadurch wird der API-Controller nicht blockiert. Jedes Einzelkonto kann weiterhin als Publisher von Tick-Daten fungieren, was im Komponenten-Diagramm (Seite 67) als Live-Datafeed-Publisher dargestellt wird. Der Publisher wird durch den PAMM-Controller gew¨ahlt und ver¨offentlicht Tickdaten, an alle Dienste, die sich unter dem Interface ITicklistener angemeldet haben, nach dem Whiteboard-Pattern. Geht das Einzelkonto offline, dann findet eine Neuwahl des Publisher durch den PAMM-Controller statt. Da alle Einzelkonten, egal welcher Broker, als Publisher fungieren k¨onnen, wird die Aus- fallsicherheit dieses Dienstes erh¨oht. 5.3.2 PAMM-Controller Der PAMM-Controller implementiert die Interfaces EventHandler, IPAMMAccountController und IPAMMTradeController und registriert sich als Dienst unter diesen Interfaces. Beim Starten l¨adt er Trade und Kontodaten vom DAO-Service. Er ist der Mediator zwischen Client-Auftr¨agen und Broker-API-Controller. Wird z.B. ein PAMM-Trade ausgel¨ost, dann splittet er diesen in Einzeltrades auf und verteilt sie an die entsprechenden Broker-API-Controller. Er verwaltet die PAMM-Konten, Einzelkonten, PAMM-Trades und Einzeltrades. Er pflegt die jeweilig m¨oglichen Zust¨ande, also OrderStatus, AccountStatus, Tradestatus, indem er Events auswertet, genauer AccountEvents und OrderEvents (siehe Klassendiagramm, Seite 66). Der PAMM-Controller erstellt einen ServiceTracker um das Registrieren und Deregistrieren von Broker-API-Controllern zu ¨uberwachen. Geht ein solcher Controller online, dann initialisert er diesen mit Konto- und Trade-Daten. Geht ein Controller offline, dann setzt er bei allen dazugeh¨origen Einzelkonten den Status auf offline. In dem Aktivit¨atsdiagramm (Abbildung C.11, Seite 68) wird exemplarisch das Verarbeiten eines neuen PAMM-Trades5 dargestellt. Hier werden die einzelnen Vorg¨ange bei der Verar- beitung und das Ausl¨osen von Events gezeigt, aus Platzgr¨unden musste auf das Darstellen der Bearbeitung von Events verzichtet werden. 4siehe [Oraa] 5Unter der Vorbedingung, dass der Trade die in Tabelle 2.1 auf Seite 9 dargestellten Bedingungen erf¨ullt
  • 49.
    KAPITEL 5. IMPLEMENTIERUNG41 5.3.3 Account-, Trade-DAO-Service Wird ein neuer Trade oder ein neues Konto erstellt, so wird das dazugeh¨orige Java-Objekt ¨uber ein entsprechendes Event verteilt. Der DAO-Service registriert sich als Eventhandler und nimmt selbst¨andig das Speichern dieser Objekte vor, weiterhin verarbeitet er ¨Anderungen von Trade- und Kontozust¨anden und speichert sie ab. Die Verbindung zum SQL-Server wird ¨uber einen Connectionpool6 hergestellt. Dieser h¨alt immer eine einstellbare Anzahl von Verbindungen offen und ¨offnet bei Bedarf weitere Verbin- dungen bzw. schließt diese wieder bei Nichtbenutzung. Dadurch muss nicht f¨ur jeden SQL-Befehl eine Verbindung aufgebaut werden, was relative lange dauern kann und die Performance be- eintr¨achtigen w¨urde. SQL-Befehle werden in Rahmen von Transaktionen, um Integrit¨at und Konsistenz der Daten sicherzustellen abgesetzt. Dazu werden Prepared Statements benutzt, um die Performance zu erh¨ohen. 5.3.4 History-Provider 1 FileChannel output = new RandomAccessFile (getFilename (bar), "rw"). getChannel (); 2 long start = output.size()- BAR_SIZE_IN_BYTES ; 3 FileLock lock = output.lock(start ,BAR_SIZE_IN_BYTES , false ); 4 ByteBuffer mapByteBuffer = output.map(FileChannel.MapMode.READ_WRITE , start , BAR_SIZE_IN_BYTES ); 5 mapByteBuffer .putLong(bar.getOpenDate (). getTime ()); 6 ... 7 mapByteBuffer .flip (); 8 output.position(output.size()- BAR_SIZE_IN_BYTES ); 9 output.write( mapByteBuffer ); 10 output.close (); Listing 5.3: Updaten eines Bars mit der NIO-API Der History-Provider ist ein Dienst zum Bereitstellen von historischen Preisdaten, f¨ur die in den Anforderungen genannten W¨ahrungspaare und Zeitebenen. Er implementiert die Interfaces IBarProvider und ITickReceiver. Der History-Provider baut die History-Daten anhand der Tickdaten auf, wie im vorherigen Kapitel beschrieben. Der letzte Bar befindet sich immer im Arbeitsspeicher und wird durch die Tickdaten aktualisiert, dabei wird alle 10 Sekunden ein Backup durchgef¨uhrt. Wird der aktuelle Bar von anderen Komponenten ben¨otigt, so wird eine Kopie dieses Bar als Antwort ¨ubermittelt, w¨ahrend History-Daten aus der Datei geladen werden. Das Listing 5.3 zeigt exemplarisch das Updaten des letzten Bars, der sich immer am Ende der Datei befindet. Im Unterschied zur IO-API, erfolgt der Zugriff auf Dateien ¨uber Channels. Ein Bar belegt 48 Bytes, also werden die letzten 48 Bytes zum exklusiven Schreiben/Lesen geblockt. Der Bar wird dann in Form von Bytes in einen Buffer geschrieben. Zum Schluss wird die Position des Buffers auf 0 zur¨uckgesetzt und der Buffer in die Datei geschrieben. 6siehe [Comb] und [Coma]
  • 50.
    KAPITEL 5. IMPLEMENTIERUNG42 Durch das Schließen des Channels wird die Datei wieder freigegeben. Durch das Locking von Dateiabschnitten ist es m¨oglich, gleichzeitig in die Datei zu schreiben und daraus zu lesen, ohne dass sich diese Prozesse behindern. 5.3.5 Indikatoren Indikatoren (siehe Seite 70) erweitern die abstrakte Klasse Indicator und werden zusammen in einem Bundle ausgeliefert. Um neue Indikatoren zu installieren, muss dieses Bundle geupdatet werden. Indikatoren k¨onnen nur ¨uber statische Methoden der Klasse Indicators bezogen werden. Die Klasse Indicator implementiert das Interface ITickReceiver und ruft bei jedem neuen Tick die abstrakte Methode ” calculateIndicator“ auf. Hier findet dann die Berechnung des aktuellen Indikatorwertes statt. Wird ein Indikator gestartet, so bezieht er History-Daten vom IBarProvider und beginnt mit der Berechnung der Indikatorenwerte. F¨ur die Berechnung werden die ben¨otigten Bardaten im Arbeitsspeicher gehalten und mit Hilfe der Tickdaten selbst¨andig gepflegt, was auch in der Klasse Indicator geregelt ist. 5.3.6 Handelssysteme Handelssysteme k¨onnen eine Vielzahl von Einstellungs-Parametern haben. F¨ur die Parameter und das Handelssystem wurden Java-Annotationen definiert. Die Methoden zum Setzen dieser Parameter und die Klasse des Handelssystems m¨ussen durch Java-Annotationen gekennzeichnet werden. In der Annotation werden die zur Beschreibung des Parameters ben¨otigten Werte und etwaige Standardwerte festgelegt (siehe Listing 5.4). In der Annotation der Klasse wird der Name und die Beschreibung des Handelssystem festgelegt. 1 @Retention( RetentionPolicy .RUNTIME ) @Target( value=METHOD ) 2 public @interface ITradingSystemInputParam { 3 String InputParametername (); 4 String InputDescription () default ""; 5 String [] AllowedStringValues () default {""}; 6 int MinValue () default Integer.MIN_VALUE; 7 int MaxValue () default Integer.MAX_VALUE; } Listing 5.4: Annotation f¨ur eine Methode Handelssysteme (siehe Seite 70) k¨onnen in unterschiedlichen Bundles ausgeliefert werden, die ein oder mehrere Handelssysteme und eine Factory enthalten. Handelssysteme implementieren das Interface ITradingsystem und werden durch die Factory erzeugt, die das Interface ITrad- ingSystemFactory implementiert und sich als Service registriert. Die Factory analysiert beim Starten des Bundles die darin enthaltenen Java-Klassen und generiert daraus die TradingSystemDescription. Zum Analysieren wird die Java-Reflection-Api benutzt. Listing 5.5 zeigt ausschnittsweise wie alle Methoden der Klasse untersucht werden und daraus die Systembeschreibung generiert wird. Diese L¨osung hat den Vorteil, dass jed-
  • 51.
    KAPITEL 5. IMPLEMENTIERUNG43 erzeit neue Handelssysteme zu einem Bundle hinzugef¨ugt werden k¨onnen, ohne dass weitere Konfigurationen notwendig sind. 1 Class <?> clazz = bundle.loadClass( fullClassName ); ... 2 Method [] methods = clazz.getMethods (); 3 for(Method method : methods) 4 { 5 if(method. isAnnotationPresent ( ITradingSystemInputParam .class )) 6 { 7 ITradingSystemInputParam methodAnnotation = method. getAnnotation 8 ( ITradingSystemInputParam .class ); 9 TradingSystemParameterDescription param = new TradingSystemParameterDescription 10 (method.getName (), inputType , methodAnnotation . InputParametername (), 11 methodAnnotation . InputDescription ()); 12 ... Listing 5.5: Annotation f¨ur eine Methode Der TradingSystemController implementiert das Interface ITradingSystemController und ¨uberwacht sich an-/abmeldende ITradingSystemFactories, um die Beschreibung zu laden und systemweit zu publizieren. Mit Hilfe dieser Beschreibung kann dann auf Clientseite der Wizard generiert werden. Der TradingSystemController initialisiert, startet und stoppt die Handelssys- teme. Beim Starten des Handelssystems ¨ubergibt er den ITradingSystemContext, ¨uber den das Handelssystem auf PAMM-Konto und History-Daten zugreift. 5.3.6.1 Installieren von Handelssystemen Bundles k¨onnen ¨uber die OSGi-Konsole installiert werden. Diese Bundles k¨onnen auf der Fest- platte des Rechners oder z.B. auf einem Webserver liegen. Das Listing 5.6 zeigt das Installieren und Starten eines Handelssystems, dessen JAR-Datei sich auf der lokalen Festplatte befindet. 1 osgi > install file:c: Pfad_zur_Datei de. tradingSystem .jar 2 Bundle id is 38 3 osgi > start 38 4 Starting de. tradingSystem Listing 5.6: Handelssysteme installieren 5.3.6.2 Beispiel f¨ur ein Handelssystem Zum Abschluss zeigt das Listing 5.7 einen Ausschnitt aus einem Handelssystem. Bei jedem Tick pr¨uft das System, ob sich schneller und langsamer Moving Average gekreuzt haben und er¨ofnet gegebenenfalls eine neue Position.
  • 52.
    KAPITEL 5. IMPLEMENTIERUNG44 1 MovingAverage slowAVG = Indicators. MovingAverage (Timeframe.D1 , Symbol.EURUSD , 2 200, "SMA", 2); 3 MovingAverage fastAVG = Indicators. MovingAverage (Timeframe.D1 , Symbol.EURUSD , 4 50, "SMA", 2); 5 public void onUpdate(Tick tick) 6 { 7 List <PAMMTrade > tradeList = context. getOpenTrades (Symbol.EURUSD ); 8 if(tradeList != null && tradeList.size ()==0) 9 { 10 if(fastAVG.getValue (1)< slowAVG.getValue (1) && 11 fastAVG.getValue (2)> slowAVG.getValue (2)) 12 { 13 Bar actualBar = context.getBar(Symbol.EURUSD , Timeframe.D1); 14 double closePrice = actualBar.getClose (); 15 16 context.openTrade(magicNumber , TradeType.SELL , Symbol.EURUSD , 17 1, closePrice -0.01 , closePrice +0.01 , closePrice ); 18 } ... Listing 5.7: Beispiel f¨ur ein Handelssystem
  • 53.
    Kapitel 6 Software-Test In Rahmenvon Tests sollte ¨uberpr¨uft werden, ob die Anwendung die in der Anforderungs- analyse ermittelten funktionalen Anforderungen erf¨ullt. Dazu wurden Tests der grafischen Be- nutzeroberfl¨ache (GUI) und Funktionstests automatisiert durchgef¨uhrt. In GUI-Tests wurden die wesentlichen Funktionen des Benutzerinfaces und die korrekte Ausf¨uhrung auf Clientseite betrachtet. Im Rahmen der Funktionstests, wurden die Schnittstellen der Serverkomponenten untersucht und wie die einzelnen Komponenten auf die Ausf¨uhrung reagieren. Außerdem wur- den Skalierbarkeits-Tests durchgef¨uhrt um Hardwareanforderungen abzusch¨atzen. In diesem Kapitel, wird der Entwurf der zu automatisierenden Tests, Ausf¨uhrung und Ergeb- nisse der Tests beschrieben. Die Testf¨alle entsprechen den Anwendungsf¨allen, die in der An- forderungsanalyse ermittelt wurden. 6.1 Testumgebung Die Tests wurden auf einem Rechner mit einem Intel Core i7-860 Prozessor und 8GB RAM unter Windows 7 x64 ausgef¨uhrt. Client-, Server-Anwendung, JMS-Broker und MySQL-Server liefen w¨ahrend der Tests auf diesem Rechner. Als JMS-Broker wurden ActiveMQ in der Version 5.4.2 und MySQL in der Version 5.1 verwendet. Die Tests wurden unter Eclipse 3.6 als JUnit- Plugin-Test bzw. als SWTBot-Test ausgef¨uhrt. 6.2 GUI-Test Zum Testen des GUI wurden der WindowTester Pro [Goob] von Google und SWTBot (siehe [Eclb], [Rei09] Seite 217ff) von Eclipse evaluiert. Beide sind kostenlos einsetzbar und erlauben das externe Testen von SWT-Anwendungen, d.h. sie agieren wie ein Benutzer und f¨uhren Aktio- nen durch Anklicken von UI-Objekten aus. Sie identifizieren die einzelnen UI-Elemente anhand von IDs und Labels, also nicht anhand ihrer Position. Dadurch bleiben Testf¨alle auch lauff¨ahig, wenn die Benutzeroberfl¨ache um weitere UI-Elemente erweitert wird. Sie unterscheiden sich
  • 54.
    KAPITEL 6. SOFTWARE-TEST46 dadurch, dass beim WindowTester der erste Testlauf manuell ausgef¨uhrt und dabei aufgezeich- net wird. Beim SWT-Bot muss der Tester einen JUnit-Test programmieren. Zum Testen eignete sich schliesslich nur der SWTBot, da die zu testende Anwendung auch JFace-Dialoge benutzt, die vom WindowTester nicht unterst¨utzt werden. 6.2.1 Testobjekte Im Rahmen von GUI-Tests, wird das gesamte System getestet. Testobjekte sind zum einen das GUI des Clients, aber auch das Zusammenspiel zwischen Client- und Serverkomponenten. Ein Anwendungsfall muss ¨uber das GUI ausl¨osbar sein und einen entsprechenden Request an den Server senden. Dieser muss die Aufgabe bearbeiten und Fehler- bzw. Erfolgsmeldungen zur¨ucksenden, die vom Client verarbeitet und auf der Benutzeroberfl¨ache dargestellt werden. Ein Test gilt als bestanden, wenn als Ergebnis des Funktionsaufrufs vom Server ein entsprechendes Event empfangen, vom Controller umgesesetzt und in der GUI angezeigt wurde. Ein Test gilt, nach einem Timeout von 5 Sekunden, als nicht bestanden, wenn ein Element vom SWTBot nicht gefunden wurde bzw. der Server nicht wie erwartet geantwortet hat. 6.2.2 Durchf¨uhrung Um die Tests vorzubereiten musste der Login-Dialog deaktiviert werden, da er vor der Applica- tion startet und damit auch vor SWTBot. F¨ur die Durchf¨uhrung der Tests wurde ein Projekt f¨ur ein SWTBot Test-Plugin erstellt. Bei der Erstellung der Testf¨alle musste dann ber¨ucksichtigt werden, dass Ergebnisse erst nach einer gewissen Zeit vorliegen, da alle Methodenaufrufe zum Erstellen/L¨oschen von Konten, Trades etc. asynchron sind. 1 public CreateAccountTest (String accountName) 2 { this.accountName = accountName ; } 3 @BeforeClass 4 public static void setup () 5 { this.bot = new SWTWorkbenchBot (); } 6 @Parameterized .Parameters 7 public static List <Object []> data () 8 { return Arrays.asList(new Object [][] {{"test1"}, {"test2"}}); } 9 @Test 10 public void canCreatePAMM () throws Exception { 11 bot.menu("Konten"). menu("PAMM erstellen"). click (); 12 bot.shell("Erstelle PAMM"); 13 SWTBotText textField1 = bot. textWithLabel ("Name:"); 14 textField1.setText(accountName ); 15 bot.button("OK"). click (); 16 } Listing 6.1: SWTBot-Test - Testfall: Erstellen eines PAMM-Kontos Das Listing 6.1 zeigt ausschnittsweise den Testfall: PAMM-Konto erstellen. Vor jedem Test- lauf werden eventuell ben¨otigte Objekte wie z.B. der SWTBot oder Testobjekte initialisiert.
  • 55.
    KAPITEL 6. SOFTWARE-TEST47 Der eigentliche Testlauf (siehe Zeilen 12-19) geht dann wie ein Benutzer vor, indem er das Men¨u anklickt und in das sich ¨offnende Dialogfenster entsprechende Daten eingibt. 6.3 Funktionstests Die Serverkomponenten wurden im Rahmen von Funktionstests als JUnit-Tests durchgef¨uhrt. Hier wurde die korrekte Ausf¨uhrung von Funktionsaufrufen in Form von Blackbox-Tests ¨uberpr¨uft. Das heisst, dass die Schnittstellen-Methoden der Komponenten aufgerufen und deren R¨uckgabewerte beziehungsweise das Ausl¨osen von Events gepr¨uft wurde. Ausserdem wurde das korrekte Abspeichern uber”pruft. So m¨ussen z.B. nach dem Erstellen eines PAMM-Kontos ein Event ausgel¨ost und die Kontodaten in der Datenbank gespeichert werden. 6.4 Ergebniss von GUI- und Funktionstests Im Rahmen der Tests stellte sich heraus, dass die Vorbedingungen zum L¨oschen von Einzel- und PAMM-Konten noch nicht gepr¨uft werden. Als schwerwiegender stellte sich heraus, dass der Handel von mehreren FXCM-Konten auf einem Rechner, zumindest mit der derzeitigen Implementierung, nicht mehr m¨oglich ist. So l¨asst sich seit dem Update der API vom 1.4.2011 nur noch das erste FXCM-Konto handeln. Werden weitere FXCM-Konten hinzugef¨ugt, so stellen diese zwar eine Verbindung zum Broker her, ein Ausf¨uhren von Trades ist jedoch nicht m¨oglich und wird mit einer Fehlermeldung vom Broker quittiert. Aus Zeitgr¨unden konnte nicht mehr ermittelt werden, inwieweit sich dieses Problem beheben l¨asst. 6.5 Skalierbarkeits-Test Im Rahmen von Skalierbarkeitstests wurde ¨uberpr¨uft, wie sich der Ressourcenverbrauch des Server-Systems mit steigender Anzahl von Konten ver¨andert. Dazu wurden der Server ohne Einzelkonten und mit 1, 2 und 5 Einzelkonten gestartet. Nach einer Warmlaufphase von einer Minute, wurden jeweils der Maximal- und Minimal-Wert f¨ur Arbeitsspeicher und Threads in einem Zeitraum von 5 Minuten ermittelt. Auf strichprobenartiges Messen wurde verzichtet, da der Garbage Collector die Messungen verf¨alscht h¨atte. Die bei den Tests ermittelten Werte skalieren linear, da jedes Konto unabh¨agig von an- deren Konten eine Verbindung zum Broker herstellt und damit auch gleich viele Threads und Arbeitsspeicher ben¨otigt. Auff¨allig ist der dreimal so hohe Verbrauch von Arbeitsspeicher bei Dukascopy-Konten, im Vergleich mit FXCM-Konten. So muss f¨ur 5 Dukascopy-Konten Ar- beitsspeicher von ca. 150 MB und bei FXCM-Konten in H¨ohe von ca. 50 MB kalkuliert werden. Außerdem ben¨otigen 5 Dukascopy-Konten mit 140 Threads ca. 100 Threads mehr als FXCM- Konten. Der Unterschied l¨asst sich damit erkl¨aren, dass die Dukascopy-API verschiedene Funk- tionialit¨aten zum automatisierten Handel mitbringt, w¨ahrend die FXCM-API ausschliesslich
  • 56.
    KAPITEL 6. SOFTWARE-TEST48 Handelsfunktionalit¨aten beinhaltet. Hier zeigte sich, dass diese APIs nur f¨ur den Handel von Einzelkonten optimiert sind. In weiteren Tests m¨usste die Ausf¨uhrungszeit untersucht werden und wie es sich auswirkt, wenn pro Broker nur eine Verbindung hergestellt wird bzw. wenn mehrere Konten des selben Brokers zu Gruppen zusammengefasst werden und diese Gruppen sich jeweils eine Verbindung teilen. Diese Verbindung m¨usste dann allerdings bei jeder Transaktion auf- und wieder abgebaut werden, da pro Broker-Verbindung nur ein Konto gehandelt werden kann.
  • 57.
    Kapitel 7 Fazit Abschließend werdendie Ergebnisse der vorliegenden Arbeit vorgestellt. Des Weiteren gibt es einen Ausblick auf m¨ogliche Erweiterungen und zus¨atzliche Untersuchungen. 7.1 Ergebnisse Ziel der Arbeit war es, eine Umgebung zum automatisiertem Handel von PAMM-Konten zu schaffen. Dieses PAMM-Konto sollte Einzelkonten von unterschiedlichen Brokern beinhalten k¨onnen. Dazu wurde eine Komponentenbasierte Client-Server-Anwendung entwickelt und die Java- APIs der Broker FXCM und Dukascopy eingebunden. OSGi und Eclipse RCP bilden die Grund- lage der ”´Event-Driven-Systemarchitektur“, die sich sehr gut bew¨ahrt hat. Die einzelnen Kom- ponenten wurden in unterschiedliche OSGi-Bundles aufgeteilt, die ¨uber Schnittstellen und den Event-Service lose gekoppelt und damit leicht erweiterbar bzw. austauschbar sind. Das Ziel einer leicht erweiterbaren Plattform wurde also erreicht, aufgrund der neu aufge- tretenen Probleme bei FXCM wurde das Ziel mehrere Konten unterschiedlicher Broker gle- ichzeitig zu handeln jedoch nur eingeschr¨ankt erreicht. Aus Zeitgr¨unden konnten weiterhin die Kann-Kriterien nicht mehr erf¨ullt werden. 7.2 R¨uckblick Die im Rahmen der Entwurfsphase getroffenen Entscheidungen wurden f¨ur ein System getrof- fen, das aus einem Anwendungsserver und gegebenenfalls einem Datenbankserver besteht. Sie wurden aus der Absicht getroffen, die Daten so nah wie m¨oglich bei der Anwendung (und damit die Latenz gering) zu halten und eine hohe Performance zu erreichen. Bei steigenden Anforderungen ist es m¨oglich, dass diese L¨osungen nicht so skalieren wie es gew¨unscht oder erforderlich ist. Weiterhin wird man um die Ausfallsicherheit zu erh¨ohen zentralisierte und clusterf¨ahige L¨osungen bevorzugen. In diesen F¨allen sollten die erw¨ahnten
  • 58.
    KAPITEL 7. FAZIT50 alternativen L¨osungsans¨atze in Betracht gezogen werden. Insbesondere scheint hier die L¨osung f¨ur die Ermittlung und Pflege der History-Daten problematisch, da sie einen Single Point of Failure darstellt. 7.3 Ausblick Um die im Rahmen dieser Arbeit entwicklelte Anwendung marktreif zu machen, m¨ussten die Probleme beseitigt und Ausfallsicherheit sowie Sicherheit der Daten erh¨oht werden. Desweiteren sollte das FIX-Protokoll in Betracht gezogen werden, da hier die Anbindungen an die Broker, durch eine eigene Implementierung, besser auf die individuellen Anforderungen zugeschnitten werden k¨onnen. Weiterhin w¨unschenswert w¨ahre das Anzeigen von Charts und Indikatoren, z.B. mit Hilfe des Business Intelligence and Reporting Tools von Eclipse (BIRT Project, [Ecla]). Ausserdem sollte eine M¨oglichkeit geschaffen werden, um Handelssysteme und Indikatoren direkt ¨uber die Anwendung zu erstellen, oder diese aus anderen Brokerprogrammen zu konvertieren.
  • 59.
    Literaturverzeichnis [Abt10] Abts, Dietmar:Masterkurs Client/Server - Programmierung mit Java. Vieweg+Teubner, 2010 [Apaa] Apache Software Foundation: Apache - ActiveMQ. http://activemq. apache.org/, Abruf: 21.12.2010 [Apab] Apache Software Foundation: Apache - Hadoop. http://hadoop.apache. org, Abruf: 22.12.2010 [Apac] Apache Software Foundation: Apache - MINA Project. http://mina. apache.org/ [Coma] Commons, Apache: Database Connection Pool API. http://commons.apache. org/dbcp/apidocs/org/apache/commons/dbcp/package-summary.html [Comb] Commons, Apache: Java Class GenericObjectPool. http://commons.apache.org/ pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html [Ebe] Ebert, Ralf: RCP Buch - JFace Data Binding. http://www.ralfebert.de/ rcpbuch/jface_data_binding/, Abruf: 27.03.2011 [Ecla] Eclipse Foundation: BIRT Project. http://www.eclipse.org/birt/phoenix/ intro/ [Eclb] Eclipse Foundation: SWTBot. http://www.eclipse.org/swtbot/ [eis] eishay: Protobuf with option optimize for SPEED. http://www.eishay.com/ 2008/11/protobuf-with-option-optimize-for-speed.html [eSia] eSignal: KnowledgeBase: Technical Analysis Dictionary - MACD. http://kb. esignal.com, Abruf: 13.03.2011 [eSib] eSignal: KnowledgeBase: Technical Analysis Dictionary - Moving Average. http: //kb.esignal.com, Abruf: 13.03.2011 [FP] FIX Protocol, Ltd: FIX Protocoll - Industry-Driven Messaging Standard. http: //www.fixprotocol.org/, Abruf: 28.03.2011
  • 60.
    LITERATURVERZEICHNIS 52 [Gooa] Google:Google - Protocol Buffers. http://code.google.com/p/protobuf/ [Goob] Google: WindowTester Pro. http://code.google.com/intl/de-DE/ javadevtools/wintester/html/index.html [IBM] IBM: WebSphere Real Time . http://www-01.ibm.com/software/webservers/ realtime/ [JBo] JBoss Community: JBoss - Netty Project. http://www.jboss.org/netty.html [MLA10] McAffer, J. ; Lemieux, J.-M. ; Aniszczyk, C.: Eclipse Rich Client Platform, Second Edition. Addison-Wesley, 2010 [Mon] Monetary and Economic Department, Triennial Central Bank Survey: For- eign exchange and derivatives market activity in April 2010. http://www.bis. org/publ/rpfx10.pdf?noframes=1, Abruf: 03.01.2011 [Mur06] Murphy, John J.: Technische Analyse der Finanzm¨arkte. FinanzBuch Verlag, M¨unchen, 2006 [MySa] MySQL: Referenzhandbuch : Kapitel 11.4.3. Die Spaltentypen BLOB und TEXT. http://dev.mysql.com/doc/refman/5.1/de/blob.html [MySb] MySQL: Referenzhandbuch : Kapitel 14.2. InnoDB-Tabellen. http://dev.mysql. com/doc/refman/5.1/de/innodb.html [Och04] Ochynski, Dr. W.: Strategien an den Devisenm¨arkten: Eine Anleitung f¨ur die Praxis unter Ber¨ucksichtigung der Euro-Besonderheiten. Betriebswirtschaftlicher Verlag Dr. Th. Gabler/GWV Fachverlage GMBH, Wiesbaden, 2004 [Oraa] Oracle: Java Class Executors. http://download.oracle.com/javase/1.5.0/ docs/api/java/util/concurrent/Executors.html [Orab] Oracle: JRockit. http://download.oracle.com/docs/cd/E13150_01/jrockit_ jvm/jrockit/docs30/index.html [Orac] Oracle: Sun Java Real-Time System. http://java.sun.com/javase/ technologies/realtime/index.jsp [OSGa] OSGi Alliance: OSGi Release 4.2 Core Specification. http://www.osgi.org/ Download/File?url=/download/r4v42/r4.core.pdf, Abruf: 28.12.2010 [OSGb] OSGi Alliance: OSGi Release 4.2 Service Compendium. http://www.osgi.org/ Download/File?url=/download/r4v42/r4.cmpn.pdf, Abruf: 28.12.2010 [R F] R Foundation: The R Project for Statistical Computing. http://www. r-project.org, Abruf: 06.04.2011
  • 61.
    LITERATURVERZEICHNIS 53 [Rap] Rapid-i:Rapid Miner. http://www.rapid-i.com, Abruf: 06.04.2011 [Rei09] Reichert, S.: Eclipse RCP im Unternehmenseinsatz. dpunkt.verlag, Heidelberg, 2009 [Whi10] White, Tom: Hadoop - The Definitive Guide. O’Reilly, 2010 [WHKL08] W¨utherich, G. ; Hartmann, N. ; Kolb, B. ; L¨ubken, M.: Die OSGi Service Platform. dpunkt.verlag, Heidelberg, 2008 [Wika] Wikipedia: Candlestick pattern. http://en.wikipedia.org/wiki/Candlestick_ pattern, Abruf: 13.03.2011 [Wikb] Wikipedia: Chart pattern. http://en.wikipedia.org/wiki/Chart_pattern, Abruf: 13.03.2011 [wikc] wikipedia: OSGi Bundle Life-Cycle. http://en.wikipedia.org/wiki/OSGi
  • 63.
    Anhang A Glossar Ask: Er¨offnungskursf¨ur eine Long-Position und Schlusskurs f¨ur eine Short-Position. Bar: Ein Bar ist eine Darstellungsform von High-, Low-, Open- und Close-Preis eines be- stimmten Zeitraums in einem Chart. Im Kontext der Datenspeicherung wird Bar synonym zum Begriff des Candlesticks benutzt. Bid: Er¨offnungskurs f¨ur eine Short-Position und Schlusskurs f¨ur eine Long-Position. Broker: Broker unterhalten Gesch¨aftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. Deutsche Bank, einer der gr¨oßten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf. Candlestick: Eine Darstellungsform von Preisen in einem Chart, siehe Bar. Forex: Forex, steht f¨ur Foreign Exchange, also den Devisenhandel. Indikator: Ein Indikator ist ein Werkzeug der Chartanalyse zur statistischen Analyse von B¨orsendaten. Interbankenmarkt: Der Interbankenmarkt ist der Markt auf dem Banken unter anderem Devisen handeln. Majors: Unter Majors werden die meistgehandelten W¨ahrungspaare verstanden, also EUR/USD, GBP/USD, AUD/USD und NZD/USD. Long-Position: Ist eine Kauforder, mit der auf steigende Kurse gesetzt wird. PAMM: PAMM ist die Abk¨urzung von Percent Allocation Management Module und ist ein Kozept f¨ur ein Sammelkonto.
  • 64.
    ANHANG A. GLOSSAR56 Pip: Entspricht meist der vierten Nachkommastelle des Wechselkurses und ist die Maßeinheit f¨ur Kursbewegungen. Short-Position: Ist eine Verkaufsauforder, mit der auf fallende Kurse gesetzt wird. Spread: Der Spread ist die Differenz zwischen Bid und Ask und entspricht der Geb¨uhr die Broker f¨ur die Ausf¨uhrung eines Trades verlangen. Tick: Ein Tick gibt immer den Bid- und Ask-Preis einer bestimmten W¨ahrung zu einer be- stimmten Zeit an. Trade: Steht f¨ur eine Long- oder Short-Position.
  • 65.
    Anhang B JFace DataBinding JFace Data Binding1 bietet eine weitere M¨oglichkeit um Datenmodell und UI-Elemente miteinander zu verkn¨upfen. Im Gegensatz zum Content Provider kann hier auf den Einsatz von eigenen Listener-Objekten verzichtet werden, da das Framework die Synchronisierung au- tomatisch ¨ubernehmen kann. Dazu m¨ussen f¨ur Datenmodell-Objekt und UI-Element sogenannte Observables erstellt werden, dass sind Objekte, die bei Ver¨anderungen ein Ereignis ausl¨osen. Unterst¨utzt werden Datenmodell-Objekte, bei denen es sich um Beans, Objekte die den PropertyChangeSupport gem¨aß der Java Bean Spezifikation implementieren, oder um POJOs (plain old java objects) handelt. Entsprechende Observables werden dann mit Hilfe der Fac- tories: BeansObservables oder PojoObservables erzeugt. Das bedeutet auch f¨ur POJOs, dass getter- und setter-Methoden, f¨ur die zu ¨uberwachenden Eigenschaften des Objekts, immer dem Schema: {get|set}+<Eigenschaftsname(beginnend mit Großbuchstaben)> entsprechen m¨ussen, z.B. getFirstName(), f¨ur die Eigenschaft: firstName. Listing B.1: Beispiel f¨ur ein Binding zwischen Text-Element und DatenModell-Objekt 1 Person person = new Person ... 2 Text firstNameText = new Text ... 3 DataBindingContext bindingContext = new DataBindingContext (); 4 IObservableValue widgetValue = SWTObservables . 5 observeText(firstNameText , SWT.Modify ); 6 IObservableValue modelValue = BeansObservables . 7 observeValue (person , "firstName"); 8 bindingContext .bindValue(widgetValue , modelValue ); ¨Uber ein Binding, das vom DatabindingContext verwaltet wird, werden zwei Observables miteinander verbunden (siehe Listing B.1). F¨ur das Binding k¨onnen verschiedene Update- 1vgl. [Ebe]
  • 66.
    ANHANG B. JFACEDATA BINDING 58 Strategien, Konverter2 und Validierer, z.B. um nur Werte gr¨oßer null zuzulassen, festgelegt werden. Das ganze Potential des JFace Data Bindings l¨asst sich im Zusammenspiel mit dem Eclipse Modelling Framework (EMF) ausnutzen, da hiermit passende Modellklassen und Factories erzeugt werden k¨onnen. 2F¨ur einfache Konvertierungen, z.B. von String-Werten zu Integer-Werten, verwendet JFace Data Binding automatisch einen passenden Konverter.
  • 67.
    Anhang C Abbildungen /Benutzer /AccountView/TreeViewer /ContentProvider new setContentProvider() setInput(PAMMAccountList) getChildren(PAMMAccountList) Klickt auf ein '+' in der TreeView getChildren(Einzelkonten) Abbildung C.1: Sequenzdiagramm - Content Provider
  • 68.
    ANHANG C. ABBILDUNGEN60 Benutzer PAMM-Kontoerstellen PAMM-Kontolöschen Bedingung: keineoffenenTradesvorhanden EinzelkontoerstellenzuPAMM-Kontohinzufügen<<include>> Einzelkontolöschen ausPAMM-Kontoentfernen <<include>> PAMM-Kontoauswählen <<include>> Brokerapiauswählen <<include>> AbbildungC.2:UsecaseDiagramm-Kontoverwaltung
  • 69.
    ANHANG C. ABBILDUNGEN61 Benutzer/ Handels- system NeuenTradeerstellen PAMM-Kontoauswählen <<include>> Tradeschliessen PrüfePAMM-Konto <<include>> OffeneTradesanzeigen GeschlosseneTradesanzeigen <<include>> <<include>> TradeauswählenStopsetzen Limitsetzen <<include>> <<include>> <<include>><<include>> AbbildungC.3:UsecaseDiagramm-Tradeverwaltung
  • 70.
    ANHANG C. ABBILDUNGEN62 Handelssystemstarten Handelssystemstoppen ZugriffaufIndikatoren ZugriffaufhistorischeChartdaten PAMM-Kontoauswählen <<include>> Handelssystemauswählen <<include>> Handelssystem <<include>> <<include>> <<include>> ZugriffaufliveChartdaten <<include>> ZugriffaufPAMM-Konto<<include>> Handelssystemeinstellen(Eigenschaften) <<include>> System Benutzer <<include>> <<include>> Indikatorerstellen AbbildungC.4:UsecaseDiagramm-Handelssysteme
  • 71.
    ANHANG C. ABBILDUNGEN63 Datenhaltungsschicht Logikschicht Präsentationsschicht externe Systeme Abbildung C.5: Schichten-Architektur Anwendungsserver Broker Externe Clients Interner Client Datenhaltungsserver Abbildung C.6: Verteilungsdiagramm
  • 72.
    ANHANG C. ABBILDUNGEN64 Account statusaccountID accountType name PAMMAccount istein SingleAccounthat 1..m0..n username password accountNumber accountHolder balance equity brokerAPI Trade magicNumber tradeType symbol takeProfit stopLoss requestedVolume filledVolume status errorMessage istein PAMMTradeSingleTrade weightedOpenPrice weightedClosePrice hat openTime closeTime openPrice closePrice hat 1..m0..n 1..m 0..n singleAccountID pammAccountID stopLoss Order orderType accountID tradeID orderIDtakeProfit orderStatus errorMessage AbbildungC.7:ERM-Diagramm:Datentypen(Teil1)
  • 73.
    ANHANG C. ABBILDUNGEN65 Tick bid ask symbol date volume Bar symbol openDate lastUpdate open high low close timeframe TradingSystem id payLoad Abbildung C.8: ERM-Diagramm: Datentypen (Teil 2)
  • 74.
    ANHANG C. ABBILDUNGEN66 <<enumeration>> Symbol +EURUSD +GBPUSD +NZDUSD +AUDUSD -baseCurrency:String -quoteCurrency:String -pipValueInDollar:double -pipValue:double -pipScale:int +valueOf(value:int):Symbol +fromString(symbolString:String):Symbol +fromStringWithDelimeter(symbolString:String):Symbol +inList(symbolString:boolean):boolean <<enumeration>> OrderStatus +CREATED +SEND_TO_SERVER +RECEIVED +SEND_TO_BROKER +FINISHED +REJECTED +valueOf(value:int):OrderStatus <<enumeration>> AccountType +PAMM_ACCOUNT +SINGLE_ACCOUNT_LIVE +SINGLE_ACCOUNT_DEMO +valueOf(value:int):AccountType <<enumeration>> OrderType +SET_SL +SET_TP +SET_SL_TP +CLOSE_TRADE +valueOf(value:int):AccountType <<enumeration>> TradeType +BUY +SELL +BUYLIMIT +BUYSTOP +SELLLIMIT +SELLSTOP +valueOf(value:int):AccountType <<enumeration>> AccountStatus +ONLINE +OFFLINE +RECONNECTING +AUTHENTICATION_FAILED +ERROR +DELETED +RELOGGING +PARTIALLY_ONLINE +NOT_ACK +valueOf(value:int):AccountType <<enumeration>> Timeframe +TICK +M1 +M5 +M15 +M30 +H1 +H4 +D1 +W1 +MN +valueOf(value:int):AccountType <<enumeration>> TradeStatus +CREATED +RECEIVED +SEND_TO_SERVER +SEND_TO_BROKER +ACCEPTED +PARTIALLY_FILLED +FILLED +PARTIALLY_CLOSED +CLOSED +CANCELED +REJECTED +valueOf(value:int):AccountType <<enumeration>> TradingSystemEvent +STARTED +STOPPED +valueOf(value:int):AccountType <<enumeration>> AccountEvent +CREATED +ONLINE +OFFLINE +RECONNECTING +OPEN_TRADE_LIST +CHANGED +DELETED +AUTHENTICATION_FAILED +ERROR +ALREADY_EXIST +ACCOUNT_UPDATE +LOGIN_ERROR +valueOf(value:int):AccountType <<enumeration>> OrderEvent +ORDER_RECEIVED +ORDER_SEND_TO_BROKER +ORDER_FINISHED +ODER_REJECTED +TRADE_CREATED +TRADE_RECEIVED +PENDING_ORDER_ACCEPTED +PENDING_ORDER_CANCELLED +TRADE_SEND_TO_BROKER +TRADE_PARTIALLY_FILLED +TRADE_FILLED +TRADE_CHANGED +TRADE_PARTIALLY_CLOSED +TRADE_CLOSED +TRADE_REJECTED +TRADE_CANCELED +ERROR +TRADE_ALREADY_EXIST +valueOf(value:int):AccountType Order -orderID:String -accountID:String -tradeID:String -takeProfit:Double -stopLoss:Double -orderStatus:OrderStatus -orderType:OrderType -errorMessage:String Bar -symbol:Symbol -openDate:Date -lastUpdate:Date -open:Double -high:Double -low:Double -close:Double -volume:Double -timeframe:Timeframe Tick -symbol:Symbol -date:Date -bid:Double -ask:Double -volume:Double <<abstract>> Account -accountID:String -name:String -balance:Double -equity:Double -status:AccountStatus -accountType:AccountType PAMMAccount SingleAccount -userName:String -password:String -accountHolder:String -accountNumber -brokerAPI:String 1 * <<abstract>> Trade -status:TradeStatus -tradeType:TradeType -symbol:Symbol -takeProfit:Double -stopLoss:Double -requestedVolume:Double -magicNumber:int -errorMessage:String SingleTrade -singleAccountID:String -openTime:Date -closeTime:Date -openPrice:Double -closePrice:Date PAMMTrade -PAMMAccountID:String -weightedOpenPrice:Double -weightedClosePrice:Double 1 * 1 * AbbildungC.9:Klassendiagramm-Datentypen
  • 75.
    ANHANG C. ABBILDUNGEN67 Server Clients Account-, Trade-DAO-Service Indikatoren Live-Datafeed-Publisher Broker- API IAccountController ITradeController benutzt Service: stellt Service zur Verfügung: ITickListener PAMM-Controller IPAMMAccountController, IPAMMTradeController History-Provider IBarProvider Event-Admin-Service Handelssysteme ITradingSystemFactory Client-Task-Dispatcher Broker Datenbank-Server Handelssystem-Controller ITradingSystemController MySQL Event-To-JMS Tick-To-JMS Event-Admin-ServiceJMS-To-Event JMS-Broker (ActiveMQ) JDBC TCP/IP Controller GUI JMS-TO-TICK IAccountListener ITickreceiver ITickreceiver ITickreceiver ITickreceiver IAccountDAO Abbildung C.10: Komponentendiagramm
  • 76.
    ANHANG C. ABBILDUNGEN68 PAMM-Controller Event-Service PAMM-Konto vorhanden? TRADE_REJECTED auslösen enthält Einzelkonten? Einzelkonten online? ja nein PAMM_TRADE_ERROR auslösen nein Berechne Gesamtvermögen nein Fehler Einzeltradevolumen berechnen Einzeltrades erstellen SINGLE_TRADE_CREATED auslösen API-Controller Transformation der Daten Weiterleiten des Trades an Einzelkonten Senden des Trades zum Broker ok Einzelkonten ja ja TRADE_RECEIVED auslösen Fehler Fehler SINGLE_TRADE_ERROR auslösen SEND_TO_BROKER auslösen ok Abbildung C.11: Aktivit¨atsdiagramm f¨ur einen PAMM-Trade
  • 77.
    ANHANG C. ABBILDUNGEN69 <<interface>> IAccountController +addAccount(account:SingleAccount): void +getAccountList(): List<String> +changeAccount(account:SingleAccount): void +removeAccount(singleAccountID:String): void <<interface>> IPAMMAccountController +addAccount(account:SingleAccount): void +getAccountList(): List<SingleAccount> +changeAccount(account:SingleAccount): void +removeAccount(singleAccountID:String,pammAccountID:String): void +addPAMMAccount(PAMMAccount:pammAccount): void +getPAMMAccountList(): List<PAMMAccount> +getPAMMAccount(pammAccountID:String): PAMMAccount +changePAMMAccount(pamm:PAMMAccount): void +removePAMMAccount(pammAccountID:String): void <<interface>> IPAMMTradeController +getOpenTrades(pammAccountID:String): List<PAMMTrade> +getTradeHistory(pammAccountID:String): List<PAMMTrade> +openTrade(pammTrade:PAMMTrade): void +processOrder(order:Order ): void <<interface>> ITradeController +getOpenTrades(singleAccount:SingleAccount): List<SingleTrade> +getClosedTrades(singleAccount:SingleAccount): List<SingleTrade> +openTrade(singleTrade:SingleTrade): void +submitOrder(order:Order): void <<interface>> IBarProvider +getBars(symbol:Symbol,timeframe:Timeframe,count:int): List<Bar> +getBar(symbol:Symbol,timeframe:Timeframe,shift:int): Bar +getBar(symbol:Symbol,timeframe:Timeframe): Bar <<interface>> ITickReceiver +SYMBOL: String +TICK: String +onTick(tick:Tick): void <<interface>> IAccountDAO +saveSingleAccount(singleAccount:SingleAccount): void +savePAMMAccount(pammAccount:PAMMAccount): void +loadPAMMAccount(pammAccountID:String): PAMMAccount +loadPAMMAccounts(): List<PAMMAccount> <<interface>> ITradeDAO +savePAMMTrade(pammTrade:PAMMTrade): void +loadPAMMTradeByTradeID(pammTradeID:String): PAMMTrade +loadPAMMTradeByAccountID(pammAccountID:String): List<PAMMTrade> +loadPAMMTrades(): List<PAMMTrade> +saveSingleTrade(singleTrade:SingleTrade): void +loadSingleTrades(): List<SingleTrade> +loadSingleTrades(pammTradeID:String): List<SingleTrade> +saveOrder(order:Order): void +loadOrder(orderID:String): Order +loadOrders(): List<Order> <<interface>> APIService enthält die Keys für die Hashmaps der DTOs +PAMM_ACCOUNT_ID: String +SINGLE_ACCOUNT_ID: String +TRADE_ID: String +TRADE: String +ORDER_ID: String +ORDER: String +TICKET: String +ORDER_EVENT: String +MESSAGE: String +CLOSE_PRICE: String +OPEN_PRICE: String +OPEN_TIME: String +PROFIT_LOSS: String +FILLED_LOTS: String +ACCOUNT_EVENT: String +OPEN_TRADE_LIST: String +EVENT_DATE: String +EQUITY: String +BALANCE: String +STOP_LOSS: String +TAKE_PROFIT: String +ACCOUNT: String +TRADING_SYSTEM_EVENT: String +SYSTEM_ID: String +TRADING_SYSTEM_INPUT: String Abbildung C.12: Klassendiagramm Server-Interfaces
  • 78.
    ANHANG C. ABBILDUNGEN70 <<interface>> ITradingsystem +initialize(symbol:Symbol[],timeframe:Timeframe): void +getMagicNumber(): int[] +onUpdate(tick:Tick): void +onStart(context :ITradingSystemContext ): void +onStop(): void<<interface>> ITradingSystemContext +getPammAccountName(): String +getBalance(): double +getEquity(): double +getClosedTrades(symbol:Symbol): List<PAMMTrade> +getOpenTrades(symbol:Symbol): List<PAMMTrade> +getTrade(tradeID:String): PAMMTrade +getTrade(symbol:Symbol,magicNumber:int): PAMMTrade +registerTradeListener(listener:OrderListener): void +unregisterTradeListener(): void +openTrade(magic:int,tradeType:TradeType,symbol:Symbol, volume:double,takeProfit:double,stopLoss:double, requestedOpenPrice:double): void +processOrder(order:Order): void +getBar(symbol:Symbol,timeframe:Timeframe): Bar +getBar(symbol:Symbol,timeframe:Timeframe,shift:int): Bar +log(level:int,message:String): void <<interface>> ITradingSystemController +startSystem(dto:TradingSystemInputDTO): void +stopSystem(systemID:String): void +getTradingSystemDescriptions(): List<TradingSystemDescription> +getRunningSystems(): List<TradingSystemInputDTO> <<interface>> ITradingSystemFactory +getTradingSystemDescriptions(): List<TradingSystemDescription> +getInstance(dto:TradingSystemInputDTO): ITradingsystem <<interface>> OrderListener +onOrderEvent(event:OrderEvent,orderID:String, pammTradeID:String): void <<enumeration>> InputType +BOOL +DOUBLE +INTEGER +STRING TradingSystemParameterDescription -methodName: String -inputType: InputType -allowedStringValues: String[] -inputParametername: String -inputDescription: String -minValue: Integer -maxValue: Integer TradingSystemDescription -className: String -systemName: String -description: String -parameterList: List<TradingSystemParameterDescription> <<imlements ITickReceiver, ITradingSystemContext, EventHandler>> TradingSystemContextImpl -system: ITradingsystem -orderListener: OrderListener -symbolArray: Symbol[] -pammAccountID: String +handleEvent(event:Event): void +onTick(tick:Tick): void <<abstract, implements ITickReceiver>> Indicator -timeframe: Timeframe -symbol: Symbol -barList: List<Bar> -history: Integer Anzahl von Indikatorwerten -shift: Integer 0 = aktueller Bar, 1 = letzter Bar -started: boolean #Indicator(timeframe:Timeframe,symbol:Symbol, shift:int,context:BundleContext): Indicator #start(): void +<<abstract>> getName(): String +<<abstract>> getDescription(): String #<<abstract>> calculateIndicator(): void +onTick(tick:Tick): void MovingAverage -period: Integer -method: Integer -maxPeriod: Integer -minPeriod: Integer +getValue(shift:Integer): Double Indicators +MovingAverage(timeframe:Timeframe,symbol:Symbol, period:Integer,method:String, shift:Integer): MovingAverage const Abbildung C.13: Klassendiagramm - Indikatoren und Handelssysteme
  • 79.
    Anhang D Tabellen Tabelle D.1:Broker ¨Ubersicht Broker FIX-Support SDK - un- terst¨utzte Sprachen Zugriff auf Preisdaten Webseite Deutsche Bank ja, aber Konto mit mind. 25.000$ Guthaben n¨otig Plattform wurde von FXCM lizensiert siehe FXCM www.dbfx.com Dukascopy ja, aber Konto mit mind. 100.000$ Guthaben n¨otig Version 4.4 Java in SDK integri- ert, Daten auf 10 Sekunden-Basis reichen bis 2003 zur¨uck www.dukascopy .com FXCM ja, aber Konto mit mind. 50.000$ Guthaben erforder- lich Version 4.4 Order2Go: VB, C++, Delphi, JAVA Trad- ing API ¨uber Order2Go und extra SDK, das nur f¨ur kommerzielle Anwendungen verf¨ugbar ist. www.fxcm.com GAIN Capi- tal nein SOAP- Interface TCP/IP Socket- Interface, keine genaueren Infos verf¨ugbar www.forex.com - Fortsetzung n¨achste Seite -
  • 80.
    ANHANG D. TABELLEN72 Broker FIX-Support SDK - un- terst¨utzte Sprachen Zugriff auf Preisdaten Webseite Interactive Brokers ja, 500$ Lizen- zgeb¨uhr zzgl. 100$ monatlich Version 4.4 C++, Java stark begrenzter Zeitraum: z.B. Minutenbars nur f¨ur die letzten 2 Tage www.interactive brokers.com MB Trading ja, nach FIX Gateway Zertfi- fierungstest und Lizenzgeb¨uhr von 250$ zzgl. 50$ monatlich Version 4.4 MBT SDK: VB, C Quote API bzw. ¨uber MBT SDK Tagesbasis - bis zu 10 Jahre. Minutenbasis - bis zu einem Jahr. www.mbtrading .com OEC nein API: .Net 2.0 COM API C++, Delphi nur auf Tagesbasis verf¨ugbar www.openecry .com
  • 81.
    ANHANG D. TABELLEN73 TabelleD.2:Software¨Ubersicht HerstellerNameWebseiteProgrammierspracheverf¨ugbareHistory Interactive Data eSignalwww.esignal.comeSignalFormulaScript,eineEr- weiterungvonJavaScript Tickdatenbiszu40Tage.Intraday-Daten bis2007,aufTagesbasisbis1983 MetaQuotes Software Metatrader4www.mql4.commql4,einefunktionaleSprachemitC- ¨ahnlicherSystax vomBrokerabh¨angig MetaQuotes Software Metatrader5www.mql5.commql5,eineobjektorientierteSprachevomBrokerabh¨angig MultiCharts, LLC MultiChartswww.multicharts .com EasyLanguageunterst¨utztverschiedeneDatenfeeds TradeStation Securities TradeStationwww.tradestation .com EasyLanguage,einefunktionale Sprache,dieandienat¨urlicheSprache angelehntist Intraday-DatenaufMinutenbasis,diebis 2002oderbis2007zur¨uckreichen
  • 83.
    Anhang E Installationsanleitung In diesemKapitel werden die einzelnen Installationsschritte beschrieben. Die dazu ben¨otigten Dateien, sowie Sourcecode und diese Arbeit als pdf-Datei finden sich auf der beiliegenden CD. Zur Durchf¨uhrung der folgenden Schritte muss der Programme-Ordner in ein beliebiges, beschreibares Verzeichnis kopiert werden. Der darin befindliche Client-Ordner kann als einziges auf einen anderen Rechner kopiert werden. 1. Datenbank einrichten: Die Einstellungen f¨ur den Datenbank-Server sind in der Datei ” /Programme/sql.properties“ geregelt. Zur Zeit ist hier ein Datenbank Server der HTW-Berlin eingetragen. Sollte der nicht erreichbar sein, dann muss mit Hilfe der Datei ” /database.sql“ eine Datenbank angelegt und die Properties-Datei entsprechend angepasst werden. 2. History-Daten herunterladen: Als n¨achstes m¨ussen die aktuellen History-Daten heruntergeladen werden. Dazu befindet sich im Ordner Programme die Datei ” historyLoad- er.properties“. In dieser Text-Datei befinden sich die Zugangsdaten f¨ur ein Demokonto des Brokers Dukascopy. Sollten die Zugangsdaten nicht mehr g¨ultig sein, dann muss ein neues Kon- to eingerichtet und eingetragen werden (siehe http://www.dukascopy.com/swiss/english/ forex/demo_fx_account/). Jetz kann das Programm eclipse.exe, das sich im Ordner ” /pro- gramme/historyloader/historyLoader“ befindet aufgerufen werden. Diese Programm l¨adt die letzten 2000 Bars der Majors und speichert sie im Ordner ” /pro- gramme/history“ ab. 3. Abschluss: Damit ist die Einrichtung soweit abgeschlossen. Jetzt muss als erstes der Server gestartet werden, die dazu ben¨otigte Datei heißt ” pammtrader server.exe“ und befindet sich im Ordner ” /programme/server/pammtrader“. Ist der Server gestartet, dann kann die Client- Anwendung ” /programme/client/fxsolution/fxsolution.exe“ gestartet werden. FXCM-Konten lassen sich auf der Webseite: http://www.fxcm.com/ demo-account-country.jsp anlegen, es funktionieren allerdings nur Konten die mit ”´EUD“ beginnen.
  • 85.
    Anhang F Eigenst¨andigkeitserkl¨arung Hiermit versichereich, dass ich die vorliegende Bachelorarbeit Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PAMM-Accounts selbstst¨andig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst habe. Die Arbeit wurde bisher in gleicher oder ¨ahnlicher Form keiner anderen Pr¨ufungsbeh¨orde vorgelegt. Berlin, den 21.4.2011