Upload
sascha-jonas
View
90
Download
2
Embed Size (px)
Citation preview
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 fur Technik und Wirtschaft Berlin
Fachbereich Wirtschaftswissenschaften II
Studiengang Angewandte Informatik
1. Prufer: Prof. Dr.-Ing. Thomas Schwotzer
2. Prufer: Prof. Dr.-Ing. Ruger 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 Marktubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Ruckblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Eigenstandigkeitserklarung 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 Aktivitatsdiagramm fur 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 fur ein Sammelkonto, und das Ziel dieser Arbeit erlautert.
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 Wahrungssystem neu geordnet werden. Zur
Kontrolle des neuen Wahrungssystems wurden die auch heute noch existierenden Institutio-
nen Weltbank und International Wahrungsfonds (IWF) geschaffen. Im Zentrum des Bretton-
Woods-Abkommens stand der US-Dollar, der als Leitwahrung dienen sollte. Fur die Wahrungen
der teilnehmenden Staaten wurde ein fixes Wechselverhaltnis zum US-Dollar festgelegt. Dieses
Wechselverhaltnis durfte nur 1% um den festgelegten Wert schwanken. Die Zentralbanken der
jeweiligen Lander 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 gewahrleisten.
Die USA hatte in den 70er Jahren im Zuge des Vietnamkrieges mit großen Staatsdefiziten
zu kampfen, was das Vertrauen in den US-Dollar stark dampfte. Die Olkrise von 1973 fuhrte
schließlich zum endgultigen Zerbrechen des Bretton-Woods-Abkommens.
Seitdem wurde die Bindung von Wahrungen an Gold aufgegeben. Der Wechselkurs der
meisten Wahrungen wird nun durch den Handel an den Devisenmarkten 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
Devisenmarkten gehandelt wird.
KAPITEL 1. EINLEITUNG 3
1.2 Der Devisenmarkt heute
Der Devisenmarkt, oder auch Forex -Markt2, ist der globale Markt, auf dem Wahrungen gehan-
delt werden. Er ist an keinen festen Borsenplatz gebunden, da er außerborslich3 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 groß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 Wahrungen angegeben und so besteht ein Devisengeschaft auch
immer aus dem gleichzeitigen Kauf und Verkauf von unterschiedlichen Wahrungen. Wurde man
zum Beispiel auf eine positive Entwicklung des Euro gegenuber dem US-Dollar setzen und eine
sogenannte Long-Position im EUR/USD eroffnen, dann wurde 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 Wahrungsrisiken abzusichern. Zentralbanken
agieren um nationale Interessen zu sichern und Investoren spekulieren um Renditeziele zu er-
reichen.
Seit kurzem ist es auch Privatanlegern moglich, am Devisenhandel teilzunehmen, da Broker4
durch sogenanntes Leverage die Mindesteinlage (fur ein Minimum-Lot) stark verringert haben.
Die Positionsgroßen fur ein Devisengeschaft waren fruher 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, moglich. Die Hohe des Leverage,
auch Hebel genannt, sagt aus wie viel Margin auf einem Konto fur ein Devisengeschaft hinterlegt
sein muss. Bei einem Leverage von 1:100 und einer Positionsgroße von 1 Lot mussten 1.000$
statt 100.000$ als Margin hinterlegt sein.
Niedrige Margin-Anforderungen, hohe Volalitat und die Moglichkeit Kauf-(Long) und
Verkaufspositionen (Short) zu eroffnen, machen diesen Markt so interessant.
2Forex-Markt steht fur Foreign Exchange Market
3“over the counter”
- OTC
4Broker unterhalten Geschaftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. DeutscheBank, einer der großten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf.
KAPITEL 1. EINLEITUNG 4
1.3 PAMM
Vermogensverwalter und Devisenhandler verwalten eine Vielzahl von Kundenkonten. Um ein
Devisengeschaft (Trade) nun nicht fur jedes verwaltetete Konto von Hand ausfuhren zu mussen,
wurde das Percent Allocation Management Module (PAMM) entwickelt.
Kaufe1 LotEUR/USD
PAMM-Technologie
Portfolioanteilin %
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, abhangig von deren Anteil am Gesamtvermogen, automatisch aufgeteilt. Dabei wird
selbstverstandlich auch berucksichtigt, dass die Kundenkonten in unterschiedlichen Wahrun-
gen vorliegen konnen. Dazu wird der aktuelle Wechselkurs zum US-Dollar ermittelt und eine
Umrechnung von Fremdwahrungskonten in US-Dollar-Konten vorgenommen.
Diese Technologie wird inzwischen von vielen Brokern bereitgestellt. Jedoch gibt es zur
Zeit keine Moglichkeit, Konten von unterschiedlichen Brokern zu einem PAMM-Konto zusam-
menzufassen. Ein Grund fur die Verteilung von Kundengeldern auf mehrere Broker konnte 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 ausgewahlter 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 Verfugung stellen, um einen oder mehrere PAMM-
Accounts zu verwalten und den Handel von Devisen durchzufuhren.
Aufbauend auf diesem Framework wird eine prototypische Anwendung entwickelt, die es
ermoglicht, automatisierte Handelssysteme zu erstellen, und mit diesen den PAMM-Account zu
handeln.
Kapitel 2
Grundlagen
Dieses Kapitel beschreibt im ersten Teil die fachlichen Grundlagen fur den automatisierten
und computergestutzten 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 fur den Server gewahlt. Um
die Vorteile von OSGi auch auf Clientseite nutzen zu konnen, hat sich der Autor fur 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 fur 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 dafur Charts, Chart-Pattern1 und Indikatoren.
Zum Handel von Devisen konnen beide Analyseformen kombiniert werden, im Rahmen dieser
Arbeit erstellte Handelssysteme werden sich jedoch auf die technische Analyse beschranken.
2.1.1 Bildung eines Candlestick Charts
Zu den verbreiteten Chartformen gehort 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
hangt von der Art des Indikators ab, von Indikatoren zur Berechnung benotigt.
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, wahrend der Linienchart nur die Close-Preise durch Linien miteinander verbindet.
Im Devisenhandel haben sich verschiedene Zeitebenen etabliert auf deren Basis gehandelt
wird. Die gangigsten Zeitebenen sind 1 Minute, 5 Minuten, 15 Minuten, 30 Minuten, 1 Stunde,
4 Stunden, 1 Tag, 5 Tage und 1 Monat, wobei Wochenenden nicht berucksichtigt werden.
2.1.2 Tickdaten
Durch den regen Handel an den Devisenmarkten konnen sich Wechselkurse in volatilen Markten
mehrmals in der Sekunde andern. Diese Preisanderungen werden als Ticks bezeichnet. Ein Tick
gibt also immer den Wechselkurs einer bestimmten Wahrung zu einer bestimmten Zeit an.
Bei Wechselkursen wird zwischen Bid - und Ask -Preisen unterschieden. Eroffnet man eine
Long-Position (Buy), dann wird diese Position zum Ask-Preis eroffnet. Schließt man diese Po-
sition oder eroffnet eine Short-Position (Sell), so geschieht dies zum Bid-Preis. Zwischen Ask-
und Bid-Preis liegt immer eine Differenz, die je nach Marktsituation, Wahrung und Broker
unterschiedlich sein kann. Diese Differenz wird Spread genannt und ist die Gebuhr, die Broker
fur ihre Dienste verlangen. Der Spread liegt bei den Hauptwahrungen, auch Majors genannt,
meist zwischen einem und vier Pips.
Ein Tick besteht also genaugenommen aus zwei Preisen, dem Bid- und dem Ask-Preis. Fur
Indikatoren und Charts werden meist Bid-Preise verwendet, da diese bei Ask-Preisen durch
marktabhangige Spreads verfalscht wurden.
2.1.3 Indikatoren
Indikatoren sind Werkzeuge zur statistischen Analyse von Borsendaten. Indikatoren konnen un-
terteilt werden in trendfolgende Indikatoren, Oszillatoren und sonstige Indikatoren. Indikatoren
werden, fur den aktuellen Candlestick, bei jedem Tick neu berechnet. Fur 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) gehort 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 = 1M
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 fur den Candlestick, dessen Preis zur Berechnung
genommen wird3. Zu den gewichteten gleitenden Durchschnitten gehort zum Beispiel der expo-
nentiell geglattete Moving Average (EMA), bei dem Kurse der jungsten Vergangenheit starker
gewichtet sind als altere Kurse. Dazu wird der Faktor α verwendet, mit α = 2M+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=2der vorletzte Candlestick usw.
KAPITEL 2. GRUNDLAGEN 8
Moving Averages glatten das”Rauschen“ des Marktes, sie erleichtern das Erkennen von
Trends und werden oftmals zum Glatten der Werte anderer Indikatoren benutzt.
Moving Averages konnen so interpretiert werden, dass es sich um einen Aufwartstrend
handelt, wenn sich die Candlesticks uber dem Moving Average befinden und ansonsten um
einen Abwartstrend. Ein Uber- bzw. Unterschreiten des Moving Average, wurde dann einen
Trendwechsel signalisieren. Eine weitere Moglichkeit 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 Aufwartstrend und
ansonsten um einen Abwartstrend (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) gehort 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 Aufwartstrend und ein
fallender MACD, unter der Mittellinie, wird als Abwartstrend interpretiert. Als Trendwechsel
werden das Kreuzen der Mittel- oder Signallinie und Divergenzen4 gedeutet.
Zum Abschluss sei erwahnt, dass Indikatoren nur Hinweise auf mogliche Ereignisse geben
konnen. Da es sich um statistische Analysen handelt, treffen von Indikatoren signalisierte
Ereignisse nur mit einer gewissen Wahrscheinlichkeit ein. Bei den oben erwahnten 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) ausgefuhrt. Eine Pending Order kann nur unter bestimmten
Voraussetzungen angelegt werden und wird zu einem vorher festgelegten Kurs (Pending Entry)
ausgefuhrt.
Market Orders werden verwendet, wenn der Zeitpunkt fur die Eroffnung eines Trades
wichtiger ist, als der Preis zu dem er eroffnet wird. Bei Pending Orders ist der Zeitpunkt,
wann der Trade eroffnet wird, nicht so wichtig. Dieser Ordertyp wird z.B. bei dem Handel von
Ausbruchen aus Seitwartsmarkten oder bei wichtigen Nachrichten verwendet. Hier werden dann
Kauf- und Verkausorder uber bzw. unter der bisherigen Range platziert und der Trader lasst
sich dann”einstoppen“:
4Beispiel: In der Abbildung 2.2 ist der MACD-Wert vom November 2007 geringer als der MACD-Wert vomDezember 2004, wahrend der Close-Preis vom Dezember 2004 geringer als der vom November 2007 ist. Chartbildund Indikatorbild unterscheiden sich, was als Divergenz bezeichnet wird.
KAPITEL 2. GRUNDLAGEN 9
Ordertyp Entry-Preis Stop-Preis Limit-Preis
Buy (Market Entry) Ask <Bid >AskBuy Limit (Pending Entry) <Ask <Pending Entry >Pending EntryBuy Stop (Pending Entry) >Ask <Pending Entry >Pending Entry
Sell (Market Entry) Bid >Ask <BidSell Limit (Pending Entry) >Bid >Pending Entry <Pending EntrySell Stop (Pending Entry) <Bid >Pending Entry <Pending Entry
Tabelle 2.1: Ordertypen und Voraussetzungen
Fur beide Ordertypen konnen ein Stop, dient der automatischen Verlustbegrenzung, und ein
Limit, dient der automatischen Gewinnmitnahme, gesetzt werden. Beispiel: Soll eine Kauforder
ausgefuhrt werden, so geschieht dies zum Ask-Preis, der Stop musste dann unter dem Bid-Preis
und das Limit uber dem Ask-Preis liegen. Erreicht der Marktpreis entweder Stop oder Limit,
wurde die Position automatisch geschlossen werden. Alle Voraussetzungen fur die einzelnen
Ordertypen konnen in der Tabelle 2.1 nachgelesen werden.
Jeder Trade wird als einzelne Position behandelt und ist unabhangig von anderen Trades.
Damit ist es moglich, gleichzeitig Long und Short zu sein, was im Devisenhandel gangige 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 gefuhrt werden. In
Reaktion auf die Finanzkrise wurde in den USA, durch die National Finance Authority (NFA),
eine andere Regelung eingefuhrt. Aufgrund der NFA Compliance Rule 2-43(b), ist hier nur eine
Position pro Wahrungspaar 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 eroffnet wurde. Es
ist also innerhalb eines US-Kontos nicht mehr moglich, gleichzeitig Long und Short zu sein. Dies
kann umgangen werden, indem ein Konto fur Long- und ein anderes Konto fur Short-Trades
genutzt wird.
Auch das Setzen von Stop- und Limit-Preis ist - bei US-Brokern - nicht mehr moglich, kann
aber durch das Setzen entsprechender Entry-Orders ersetzt werden. So konnten z.B. fur 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 konnen. Die im Rahmen dieser Arbeit erstellte
Anwendung wird US-Konten somit nicht voll unterstutzen.
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-Betrage gibt. Die Preisanderungen 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{sekundareWahrung/Kontowahrung}) · (Lots) · 100.000$
In dem folgenden Beispiel wurde eine Long-Position6 im EUR/GBP bei 0,8431 geoffnet und bei
0,8442 geschlossen:
Kontowahrung: USD gehandelte Wahrung: EUR/GBPprimare Wahrung (Base): EUR sekundare Wahrung (Quote): GBPPreis {sekundare Wahrung / Kontowahrung} (GBP/USD): 1,6108Open: 0,8431 Close: 0,8442Pips: 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 fur 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 geoffnet wurden. Bei einem PAMM-Trade wird es also eher
Regel als Ausnahme sein, dass die Einzeltrades zu verschiedenen Preisen geoffnet wurden. Das
liegt zum einen daran, dass Broker leicht unterschiedliche Preis-Feeds haben konnen. Zum
anderen handelt es sich bei dem Devisenmarkt um einen sehr volatilen Markt, bei dem sich
Wahrungskurse sehr schnell andern konnen.
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, wahrend
andere Einzeltrades noch offen sind.
Damit steht der endgultige Gewinn oder Verlust fur einen PAMM-Trade erst fest, wenn alle
Einzeltrades geschlossen wurden. Um nicht den laufenden Gewinn/Verlust fur jeden Einzeltrade
eines PAMM-Trades auszurechnen, wird ein - nach Lotgroße gewichteter - Durchschnittspreis
fur den Open-Preis eingefuhrt:
gewichteter Open-Preis= (Lot1·Open1)+(Lot2·Open2)+...+(Lotn·Openn)Lot1+Lot2+...+Lotn
,
dabei steht n fur die Anzahl der Einzeltrades in einem PAMM-Trade. Anhand dieses Preises,
der gesamten Lotgroße und dem aktuellen Devisenkurs, kann der aktuelle Gewinn- und Verlust
fur einen PAMM-Trade leicht berechnet werden.
5Wenn die sekundare Wahrung gleich der Kontowahrung ist, gilt: Gewinn/Verlust=(Pips)*(Lots)*100.000$.
6Bei einer Short-Position, wurde sich die Anzahl der Pips mit Pips = Open− Close berechnen.
KAPITEL 2. GRUNDLAGEN 11
2.1.6 Lotberechnung
Wie im letzten Unterkapitel ersichtlich wurde, hangt der Gewinn/Verlust eines Trades im großen
Maße von der Lotgroße ab. Die Anzahl der Lots muss auch als einziger Parameter beim Eroffnen
eines Trades angegeben werden. Doch wie bestimmt man die Lotgroß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 Kontogroße). Das Risiko wird mit dem Setzen des Stop-
Preises festgelegt, bei dem ein moglicher Verlust realisiert wird. Sind Stop-Preis und damit die
Entfernung vom Entry in Pips bekannt, kann die im letzten Unterkapitel erwahnte Formel
benutzt werden, um die Lotgroße zu bestimmen.
Eingeschrankt wird die Lotgroße und damit eine genaue Realisierung des Risikos pro Trade,
nur durch die Anzahl der erlaubten Nachkommastellen7. Im Kontext eines PAMM-Kontos fuhrt
dies dazu, dass ein PAMM-Trade im Allgemeinen nicht gleichmaßig auf alle im PAMM-Konto
zusammengefassten Einzelkonten verteilt werden kann. Meistens wird eine optimale Aufsplit-
tung des PAMM-Trades in Einzeltrades nicht moglich sein, da die fur das Einzelkonto berech-
nete Lotgroß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-
standig den Handel durchfuhren. Sie haben ein beliebig komplexes Regelwerk, in dem Kriterien
fur die Eroffnung 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 konnen vom
Anwender vor dem Starten des Systems festgelegt werden.
Automatisierte Handelssysteme bieten den Vorteil, dass sie rund um die Uhr die Markte
analysieren und handeln konnen, ohne emotionale oder psychologische Schwachen. Sie werden
weder durch Angst, noch durch Gier oder Mudigkeit beeinflusst.
Ein weiterer Vorteil ist, dass automatisierte Handelssysteme nicht nur auf aktuelle De-
visendaten, sondern auch auf historische Daten angewendet werden konnen. Mit diesem, als
Backtesting bekannten, Verfahren lassen sie sich nicht nur auf technische Funktionalitat, son-
dern auch auf mogliche Profitabilitat testen.
Inzwischen unterstutzt jeder Broker das Erstellen von automatischen Handelssystemen, je-
doch verwendet auch jeder Broker dafur eine andere Software, sodass automatische Handelssys-
teme nur mit Programmieraufwand portiert werden konnen. 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 nachsten 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 Einfuhrung des objektorientierten Paradigmas, unterstutzten Programmiersprachen
die Modularisierung nur rudimentar. 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 Einfuhrung der objektorientierten Programmiersprachen, wurde das Konzept der
Modularisierung starker 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 konnen. 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 ausdrucken.
Durch das import-Statement kann angegeben werden, welche anderen Komponenten es benutzt,
aber nicht welche Klassen es fur die Benutzung durch andere Komponenten exportiert.
In Java werden weiterhin Klassen auf Sprachebene mit Hilfe von Packages hierarchisch
strukturiert. Dabei lasst sich zwar die Sichtbarkeit von Klassen auf Packageebene einschranken,
fur eine echte Komponentenbildung ist dies aber unzureichend. Die interne Implementierung
ist dadurch nicht ausreichend geschutzt und uber eine einfache Typumwandlung erreichbar.
OSGi ist eine auf Java basierende Plattform und erweitert Java um die Moglichkeit, echte
Komponenten zu entwickeln. Bei OSGi ist die Implementierung einer Komponente durch einen
separaten Class-Loader geschutzt, außerdem ist es hier moglich, explizit Abhangigkeiten, zu
exportierende Elemente und Schnittstellen zu definieren. Dies soll im nachsten 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 gegrundet. Ihre Aufgabe ist es, die Programmierschnittstellen und
Testfalle [OSGa,OSGb] fur die OSGi Service Platform zu spezifizieren.
Die OSGi Service Platform ist ein dynamisches Modulsystem fur Java. Es handelt sich um
eine javabasierte Softwareplattform, die die dynamische Integration und das Fernmanagement
von Softwarekomponenten (Bundles) und Diensten (Services) ermoglicht. Bundles und Services
konnen 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 fur
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 zusammenhangende Einheit von Klassen und Ressourcen, die
unabhangig von anderen Bundles im OSGi Framework installiert und deinstalliert werden
kann [WHKL08]. Ublicherweise wird fur 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 Zustanden befinden:
� INSTALLED: Das Bundle wurde erfolgreich auf der OSGI-Plattform installiert.
KAPITEL 2. GRUNDLAGEN 14
� RESOLVED: Alle Abhangigkeiten (siehe Bundle Manifest) des Bundles konnten aufgelost
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 lauft 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 ausfuhrlich im Kapitel 3.2 des OSGi-Core-
Compendium [OSGa] beschrieben. Listing 2.1 zeigt den Ausschnitt eines gultigen 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 mussen. Alle anderen Header sind optional.
Das bedeutet, dass Bundles auch in mehreren und unterschiedlichen Versionen auf der OSGi
Plattform installiert sein konnen.
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 konnen Abhangigkeiten wie benotigte 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 konnen 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 konnen, 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 konnen Service-Abhangigkeiten in einer
XML-Datei beschrieben werden. Das Auflosen von Service-Abhangigkeiten wird dann durch
die Service Component Runtime realisiert. Beide Ansatze 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 erlautert werden soll. Der Event Admin Service basiert auf dem”publish-
<<class>>Event
<<service>>Event Admin
<<service>>Event Handler
Event Consumerimpl 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 fur 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 reprasentiert 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 fur
ein gultiges Topic ware”de/pammtrader/api“, wobei Wildcards erlaubt sind. Properties sind
HashMaps, wobei der Schlussel ein String-Objekt ist und der dazu gehorige Wert ein beliebiges
Java-Objekt sein kann.
2.4 Eclipse RCP
Die Eclipse Rich Client Plattform8 (RCP) ist eine Plattform fur 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 fur eine Rich Client
Plattform, indem alle Abhangigkeiten zu IDE-spezifischen Elementen entfernt und viele Teile
des Benutzerinterfaces fur die Anpassung durch den Entwickler geoffnet wurden. Die Abbildung
2.5 zeigt einige wichtige Komponenten der Eclipse RCP:
� Equinox ist eine vollstandige Implementierung der OSGi Plattform Spezifikation, er-
weitert um fur Eclipse RCP-Anwendungen benotigte 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 fur das Branding der Anwendung und Startparameter definiert.
� Das Standard Widget Toolkit (SWT) ist eine low-level Grafikbibliothek, welche
die Standard Bedienelemente wie Listen, Menus, Schriftarten und Farben zur Verfugung
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 fur eine Vielzahl von Betriebssystemen verfugbar. 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 fur viele gangige 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 fur Databinding und Preferences und bildet
damit die Basis des Eclipse UI.
� Eclipse Update, genauer Eclipse p2, erlaubt es einen Update-Mechanismus fur eine
RCP-Anwendung zu implementieren. Damit lasst sich nicht nur die Anwendung auf dem
neuesten Stand halten, es ist auch moglich neue Features zu installieren. Updates konnen
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 fur Erweiterungen (Extensions) durch andere
Plug-ins. Diese Extensions konnen Implementierungen von Interfaces sein, aber auch Daten
wie z.B. Icons oder Text. Fur 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 Verfugung stellen muss.
Extension Points und Extensions werden von der Extension Registry verwaltet und sind
verfugbar, sobald das dazugehorige 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
fur einen Ecplipse RCP-Entwickler einfach, sich in eine bestehende Anwendung einzuarbeiten
bzw. diese zu erweitern.
Listing 2.2 zeigt den Ausschnitt aus einer gultigen 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 unterstutzt explizit das Trennen von Datenmodell, Zugriff auf das Datenmodell
und Prasentation 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 fur 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 Zeitgrunden verzichtet werden. Es wird der Vollstandigkeit 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 gewahren. 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 verknupft 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 gehorigen IWorkben-
chadaptern.
Andert sich das Datenmodell, dann mussen die UI-Elemente, mit der Hilfe von Listenern,
daruber 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 fur den Handel
von Devisen dar. Sie soll die Broker-APIs kapseln und deren Funktionalitaten mit einem ein-
heitlichen Benutzerinterface zu Verfugung stellen. Weiterhin soll Sie es ermoglichen Einzelkon-
ten, die bei unterschiedlichen Brokern liegen konnen, zu einem PAMM-Konto zusammenzu-
fassen. Diese PAMM-Konten sollen dann manuell oder mit Hilfe von automatischen Handelssys-
temen gehandelt werden konnen.
Um diese Ziele zu erreichen, wird im ersten Teil dieses Kapitels ermittelt, was Broker an APIs
zur Verfugung stellen. Daraus werden die funktionalen und nicht-funktionalen Anforderungen
an die Software abgeleitet, die im zweiten Teil formuliert werden.
3.1 Marktubersicht
3.1.1 Broker-APIs
Nach einer Recherche bei gangigen Forex-Brokern (siehe Tabelle D.1 auf Seite 71) zeigte sich,
dass deren APIs in 3 Arten gegliedert sind:
Zum einen unterstutzen 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-Funktionalitaten getrennt - in einer eigenen
API zu finden ist. Als Programmiersprachen, werden C++ und/oder Java unterstutzt.
3.1.1.1 FIX-Protokoll
Das FIX-Protokoll1 ist ein Nachrichtenstandard, der speziell fur den Handel von Wertpapieren
in Echtzeit entwickelt wurde. Das FIX-Protokoll ist offen und frei verfugbar 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 konnen 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 konnen aber auch, nach dem FIX-XML Standard, in XML-Form sein.
Zu den Session-Nachrichten gehoren unter anderem Logon-, Heartbeat- und Logout-
Nachrichten. Zu den Anwendungsnachrichten gehoren 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 naturlich am Broker, inwieweit er
alle Moglichkeiten unterstutzt.
Das FIX-Protokoll ist der Quasi-Standard, fur den Handel an allen großen Borsenplatzen
dieser Welt, wobei die Versionen 4.2 und 4.4 noch weit verbreitet sind.
Von den untersuchten Brokern unterstutzen, bis auf OEC und Gain Capital, alle Broker
dieses Protokoll. Dadurch wahre es optimal fur ein Broker-ubergreifendes Programm zum De-
visenhandel. Es ist allerdings nur fur institutionelle Trader gedacht. So verlangen die Broker,
welche das FIX-Protokoll unterstutzen, entweder hohe Lizenzgebuhren und dazu monatliche
Gebuhren oder es wird ein Konto mit einer hohen Mindestgroße fur das Kontoguthaben ver-
langt. Ohne diese Voraussetzungen zu erfullen, ließen sich auch keine Testprogramme erstellen.
Aus diesem Grund wurde fur diese Arbeit darauf verzichtet, das FIX-Protokoll zu imple-
menteren.
3.1.1.2 Zugriff auf Handelsfunktionalitaten
Alle untersuchten Broker unterstutzen 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 Eroffnen 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 konnen also auch erst gesetzt
werden, nachdem der Trade geoffnet wurde. Als Antwort werden vom Broker, bei Erfolg, drei
Executionreports, ein Positionreport und ein Collateralreport versendet, die alle auch ausge-
wertet werden mussen.
Bei Dukascopy hingegen muss nur eine Methode aufgerufen werden, wobei hier direkt Stop-
und Limit-Preis gesetzt werden konnen. Als Anwort erhalt man vom Broker nur eine auszuwer-
tende Nachricht.
Dies und die folgenden Merkmale mussen bei der Planung der Anwendung berucksichtigt
werden, da diese nur Funktionalitaten 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
konnen auch noch zusatzliche 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 unterstutzten Wahrungspaare.
Diese reicht von 35 bis zu uber 100 Wahrungspaaren. 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, mussen sie fur jedes Wahrungspaar abboniert
werden. Die Tickdaten werden dann unter Benutzung der Push-Technologie verteilt. Teilweise
mussen diese auch abboniert sein, um den Handel uber die API zu ermoglichen.
Der Zugriff auf History-Daten ist meist nur eingeschrankt moglich. Sie konnen meist nur
uber ein extra API oder uber das FIX-API abgefragt werden. Die Verfugbarkeit von Preisdaten
schwankt stark in der Genauigkeit der Daten. So sind teilweise nur Daten auf Tagesbasis fur
einen großeren Zeitraum und genauere Daten wie z.B. auf Minutenbasis nur fur einen kurzen
Zeitraum verfugbar.
Das ist insbesondere fur automatische Handelssysteme, wenn sie auf vergangene Zeitraume
getestet werden sollen, aber auch fur Indikatoren, die einen großen Zeitraum analysieren, von
Bedeutung. Hier werden moglichst genaue Daten fur einen moglichst großen Zeitraum benotigt,
im Falle des Backtesting der Handelssysteme am besten Tickdaten.
Weiterhin muss berucksichtigt werden, dass sich Broker in unterschiedlichen Zeitzonen
befinden konnen, was zu unterschiedlichen Daten fur den gleichen Zeitraum fuhrt. So ist es
moglich, dass ein Broker auch Daten fur Sonntage offeriert, obwohl der Handel erst am Montag
um 0 Uhr beginnt.
Zusammenfassend muss eine einheitliche Losung gefunden werden, bei der ein moglichst
umfangreicher Zugriff auf historische Preisdaten gegeben ist. Diese Losung sollte unabhangig
von einem Broker sein.
Hier gibt es zum einen die Moglichkeit auf externe Anbieter von History-Daten zuruckzu-
greifen. Anbieter wie Google oder Yahoo offerieren Borsendaten kostenlos uber eine einfache
API, mit der Daten als csv-Dateien exportiert werden konnen. Diese Daten sind allerdings um
15-Minuten verzogert und damit fur 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-Borsendaten zu einem Preis von ca. 100$ im Monat an, was je nach Paket
und Anbieter differiert.
Eine weitere Moglichkeit ist das Aufbauen einer eigenen Datenbasis. Dazu konnten History-
Daten von einem kostenlosen Anbieter heruntergeladen werden - am besten am Wochenende,
KAPITEL 3. ANFORDERUNGSANALYSE 24
wenn die Borsen geschlossen sind - und dann mit Hilfe der Tickdaten, die jeder Broker ubermit-
telt, gepflegt werden. Diese Losung hat den Vorteil, dass sie Broker-ubergreifend funktioniert -
damit keine Abhangigkeiten aufweist - und keine Kosten durch externe Datendienste enstehen.
Bei Hard- oder Softwareproblemen oder bei Ausfall der Internetverbindung kann es jedoch zu
Lucken in der Datenbasis kommen.
Die letzte Losungsvariante soll im Rahmen dieser Arbeit verwirklicht werden.
3.1.1.4 Zugriff auf Indikatoren
FXCM und Dukascopy unterstutzen als einziges den Zugriff auf Indikatoren-Daten bzw. das
Erstellen von eigenen Indikatoren uber APIs.
Bei FXCM konnen Indikatoren-Daten uber das Order2Go SDK abgefragt werden und
mit Hilfe eines Indicator SDK eigene Indikatoren erstellt werden. Als Programmiersprache
wird hierfur Lua verwendet. Bei Dukascopy werden Indikatoren in Java erstellt und mussen
das IIndicator-Interface implementieren. Beide bieten eine Vielzahl von fertigen Standard-
Indikatoren und unterstutzen damit das Erstellen von automatischen Handelssystemen.
Zusammenfassend fehlt auch hier eine einheitliche und Broker ubergreifende Losung, zu-
mindest was die APIs der Broker betrifft. Aus diesem Grund wurde sich, im Rahmen dieser
Arbeit entschieden, eine eigene Basis fur das Erstellen von Indikatoren und damit auch fur das
Erstellen von automatischen Handelssystemen zu schaffen.
3.1.2 Unterstutzte Software
Um den Devisenhandel mit Hilfe automatisierter Handelssysteme zu ermoglichen, unterstutzen
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 fur den Devisenhandel. Sie werden in funktionale-
und nicht-funktionale Anforderungen unterteilt.
3.2.1 Funktionale Anforderungen
Die Anwendung ist in die Aufgabenbereiche: unterstutzte Wahrungspaare, 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 fur die Wahrungspaare wurde dabei weggelassen.
KAPITEL 3. ANFORDERUNGSANALYSE 25
3.2.1.1 Wahrungspaare
Es ergeben sich folgende zu erfullende Muss-Kriterien fur Wahrungspaare:
� unterstutzte Wahrungspaare:
Beschreibung: Es sollen die Wahrungspaare EUR/USD, GBP/USD, AUD/USD und
NZD/USD unterstutzt werden. Indikatoren und Handelssysteme mussen Zugriff auf his-
torische Preisdaten, aller auf Seite 5 im Kapitel 2.1.1 erwahnten Zeitebenen, und auf
aktuelle Tickdaten dieser Wahrungspaare haben. Diese Daten sollen kostenneutral zur
Verfugung stehen.
� Wahrungspaare anzeigen:
Beschreibung: Es muss eine Liste geben, in der aktuelle Bid- und Ask-Preise angezeigt
werden.
Es ergeben sich folgende wunschenswerte Kann-Kriterien fur die Wahrungspaare:
� unterstutzte Wahrungspaare:
Beschreibung: Es sollten weitere Wahrungspaare unterstutzt werden.
3.2.1.2 Kontoverwaltung
Es ergeben sich folgende zu erfullende Muss-Kriterien fur die Kontoverwaltung:
� PAMM-Konto anlegen:
Beschreibung: Es muss eine Funktion geben um PAMM-Konten anzulegen. Als Eingabe
wird ein Name benotigt, der im System eindeutig sein muss.
Nachbedingung: Konto wurde angelegt.
� PAMM-Konto loschen:
Vorbedingung: Es durfen keine Trades in dem PAMM-Konto offen sein.
Beschreibung: Es muss eine Funktion geben um PAMM-Konten und darin enthaltene
Einzelkonten zu loschen.
Nachbedingung: PAMM-Konto und Einzelkonten wurden geloscht.
� PAMM-Konten anzeigen:
Beschreibung: PAMM-Konten und darin enthaltene Einzelkonten werden in einer Liste
angezeigt.
� Einzelkonto anlegen:
Vorbedingung: Es wurde ein PAMM-Konto ausgewahlt. Im Einzelkonto sind keine Trades
offen.
Beschreibung: Ein Einzelkonto kann angelegt werden, dazu muss ein PAMM-Konto
ausgewahlt werden. Außerdem mussen ein Broker ausgewahlt und die Zugangsdaten
eingegeben werden.
KAPITEL 3. ANFORDERUNGSANALYSE 26
Nachbedingung: Einzelkonto wurde angelegt und dem PAMM-Konto hinzugefugt. Kon-
tostatus wird auf Offline gesetzt.
� Einzelkonto loschen:
Vorbedingung: Es wurde ein Einzelkonto ausgewahlt. Im Einzelkonto sind keine Trades
offen.
Beschreibung: Es muss eine Funktion geben um Einzelkonten zu loschen.
Nachbedingung: Das Einzelkonto wurde geloscht und aus dem PAMM-Konto entfernt.
Es ergeben sich folgende wunschenswerte Kann-Kriterien fur die Kontoverwaltung:
� Kontowahrungen:
Es sollten als Kontowahrung fur Einzelkonten nicht nur US-Dollar, sondern auch weitere
Wahrungen unterstutzt werden.
� PAMM-Konten andern:
Es sollte die Moglichkeit geben, den Namen von PAMM-Konten zu andern.
� Einzelkonto andern:
Es sollte die Moglichkeit geben, die Daten von Einzelkonten zu andern.
3.2.1.3 Tradeverwaltung
Es ergeben sich folgende zu erfullende Muss-Kriterien fur die Tradeverwaltung:
� PAMM-Trade erstellen:
Vorbedingung: Es wurde ein PAMM-Konto ausgewahlt. Das PAMM-Konto enthalt
Einzelkonten, die alle online sein mussen.
Beschreibung: Das System generiert fur alle im PAMM-Konto enthaltenen Einzelkonten,
entsprechend dem Guthaben, jeweils einen Trade und lost ihn aus. Es mussen alle auf
Seite 8 im Abschnitt 2.1.4 aufgefuhrten Ordertypen unterstutzt werden.
Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde ausgefuhrt.
� PAMM-Trade schliessen:
Vorbedingung: Es wurde ein PAMM-Trade ausgewahlt, der offen ist.
Beschreibung: Es werden der PAMM-Trade und alle dazu gehorigen Einzeltrades
geschlossen.
Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde geschlossen.
� PAMM-Trades anzeigen:
Vorbedingung: Es wurde ein PAMM-Konto ausgewahlt.
Beschreibung: Es werden alle zum Konto gehorenden 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 ausgewahlt, der offen ist.
Beschreibung: Stop- und Limit-Preis konnen gesetzt werden, wenn sie die auf der Seite 8
in der Tabelle 2.1 aufgefuhrten Bedingungen erfullen.
Nachbedingung: Stop- und Limit-Preis werden beim PAMM-Trade und bei allen dazu
gehorigen Einzeltrades gesetzt.
3.2.1.4 automatische Handelssysteme
Es ergeben sich folgende zu erfullende Muss-Kriterien fur automatische Handelssysteme:
� Indikator erstellen:
Beschreibung: Es muss eine Moglichkeit geben, Indikatoren zu erstellen. Der Indikator
verfugt uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigen-
schaften, die vom Handelsystem gesetzt werden mussen. Diese Eigenschaften konnen vom
Typ: String, Integer, Double und Boolean sein. Fur jede Eigenschaft konnen minimale und
maximale Werte festgelegt werden. Außerdem muss der Indikator eine Eingabemoglichkeit
fur mindestens ein Wahrungspaar und fur eine Zeitebene besitzen.
Nachbedingung: Der Indikator wird zum Programm hinzugefugt und kann von Handelssys-
temen genutzt werden.
� Handelssystem erstellen:
Vorbedingung: Das Handelssystem hat Zugriff auf benotigte Indikatoren.
Beschreibung: Es muss eine Moglichkeit geben Handelssysteme, zu erstellen und zum Pro-
gramm hinzuzufugen. Das Handelssystem verfugt uber eine Beschreibung, einen Namen
und hat eine beliebige Anzahl von Eigenschaften, die vom Benutzer beim Starten geset-
zt werden konnen. Diese Eigenschaften konnen vom Typ: String, Integer, Double und
Boolean sein. Fur jede Eigenschaft konnen minimale und maximale Werte festgelegt wer-
den.
Nachbedingung: Das Handelssystem wird zum Programm hinzugefugt und ist vom Be-
nutzer auswahlbar.
� 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
Wahrungspaare und eine Zeitebene ausgewahlt.
Beschreibung: Es muss eine Moglichkeit geben, ein Handelssysteme zu starten, welches
dann mit dem automatischen Handel beginnt.
Nachbedingung: Das Handelssystem wird vom Programm mit den ausgewahlten Parame-
tern gestartet und erhalt, genau wie davon benutzte Indikatoren, Zugriff auf aktuelle und
historische Preisdaten.
KAPITEL 3. ANFORDERUNGSANALYSE 28
� Handelssystem stoppen:
Vorbedingung: Es wurde ein Handelssystem ausgewahlt.
Beschreibung: Es muss eine Moglichkeit geben, Handelssysteme zu stoppen.
Nachbedingung: Das Handelssystem wird gestoppt.
� laufende Handelssysteme anzeigen:
Beschreibung: Es muss eine Moglichkeit geben, alle laufenden Handelssysteme anzuzeigen.
Es ergeben sich folgende wunschenswerte Kann-Kriterien fur automatische Handelssysteme:
� Handelssystem andern:
Es sollte die Moglichkeit 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 fur die History berechnen,
um die von Indikatoren und Handelssystemen benotigten Daten zur Verfugung stellen
zu konnen. Diese Funktionen, genauso wie die automatischen Handelssysteme, mussen
moglichst 24 Stunden am Tag ohne Unterbrechung laufen.
� Mehrbenutzerfahig:
Die Anwendung soll in dem Sinne mehrere Benutzer unterstutzen, dass gleichzeitig
mehrere Benutzer mit dem gleichen Datenbestand arbeiten konnen, ohne dass es ein
Login gibt. Alle Benutzer arbeiten also mit den gleichen Rechten, den gleichen Daten und
sind vom System nicht unterscheidbar.
� Verschlusselung der Datenubertragung:
Auf eine Verschlusselung der Kommunikation wird verzichtet.
3.2.3 Abgrenzungskriterium
Die Anwendung ist hauptsachlich gedacht als Plattform fur automatische Handelssysteme und
hat als Zielgruppe erfahrene Trader. Diese sollen zwar die Moglichkeit 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 fur den Entwurf der Anwendungs- und Systemarchitektur entscheidend sind. So mussen
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 Losungsansatze vorgestellt und diskutiert.
4.1 System-Architektur
Aus den Anforderungen an die Anwendungen ergab sich, dass einige Komponenten moglichst
ohne Unterbrechung laufen sollen. Außerdem soll die Anwendung mehrbenutzerfahig sein und
den Zugriff auf die Systeme der Broker ermoglichen.
Eine Trennung in Client und Server ist dafur die beste Losung. Daraus ergibt sich eine so-
genannte Mehrschichten-Architektur, die sich aus Prasentationsschicht, Datenhaltungsschicht,
der Schicht fur die Geschaftslogik und einer Schicht fur 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 fur die Prasentation und Validierung zustandig und entlastet damit
den Server. Die Geschaftslogikschicht 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 geschutzt, da kein direkter Zugriff von
außen moglich 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 konnen. Außerdem ergeben sich wiederverwendbare Komponenten, z.B. fur
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. Fur 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 ausgelost werden. So konnen z.B. Einzelkonten on- oder offline gehen und
Trades nach dem Erreichen bestimmter Ziele automatisch geschlossen oder von automatischen
Handelssystemen ausgelost werden. Die Anwendung hat weiterhin nur indirekten Einfluss auf
die externen Systeme der Broker. So kann sie zwar Trades und Orders auslosen, wird aber
durch Events erst spater uber die Ausfuhrung informiert. Trades und Konten konnen sich damit
in verschiedenen Zustanden befinden, die berucksichtigt werden mussen. 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 Vorgangen die Transak-
tionen benotigen. Aktionen die PAMM-Trades oder PAMM-Konten betreffen, mussen in Ganze
auf allen dazugehorigen Einzel-Trades bzw. -Konten ausgefuhrt werden. Im Gegensatz zu in-
ternen Datenbanken gibt es jedoch bei externen Systemen nicht die Moglichkeit in Fehlerfallen
ein Rollback durchzufuhren.
Das muss bei der Implementierung berucksichtigt werden. Es muss damit vor jeder Aktion
gepruft werden, ob benotigte Komponenten sich in einem fehlerfreiem Zustand befinden. Sind
z.B. die von einer Aktion betroffenen Konten nicht online oder verfugbar, dann muss diese
abgebrochen werden.
4.1.3 System-Umgebung
Die Anwendung wird fur MS-Windows entwickelt, sollte allerdings moglichst leicht auf an-
dere Betriebssysteme portierbar sein. Es wurde sich deshalb fur die Programmiersprache Java
entschieden, da sie plattformunabhangig ist und man - mit dem Java Native Interface (JNI) -
auch auf C-Bibliotheken zugreifen konnte.
An dieser Stelle sei erwahnt, dass Java fur Echtzeit-Anwendungen oft kritisch betrachtet
wird. Dies liegt daran, dass es unter Java keine Moglichkeit 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 halt 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 konnen 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 musste die Anwendung in Langzeittests untersucht und optimiert werden, um optimale
Einstellungen zu finden. Aus Zeitgrunden 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 konnten die fur 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 Losung gefunden, da sie
zum Einspielen von Erweiterungen nicht gestoppt werden muss und als Modulsystem diese An-
forderung explizit unterstutzt. Sie bildet die Grundlage fur die Serveranwendung, wahrend 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 Entitaten 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 benotigt
wird. So besteht z.B. ein PAMM-Trade aus vielen einzelnen Trades und damit eine Aktion zum
Speichern auch aus einzelnen Speicheroperationen, die gemeinsam ausgefuhrt und abgeschlossen
werden mussen. Nur dann ist die Konsistenz und Integritat der Daten gewahrleistet.
1Der Begriff der Order wird ab hier in zwei verschiedenen Zusammenhangen verwendet. Eine Order ist zumeinen ein Auftrag an das System, einen offenen Trade zu andern oder zu schließen. Zum Anderen kann ein Tradevom Typ: Pending Order oder Market Order sein.
KAPITEL 4. ENTWURF 32
Damit eignen sich insbesondere relationale Datenbanken fur die Benutzung als Speicherlo-
sung. Diese sind durch den Einsatz von Index- und Caching-Mechanismen, anderen Losungen
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 konnen.
Aus diesem Grund, wird sich fur eine relationale Datenbank als Speicherlosung entschieden,
genauer MySQL mit der Speicher Engine: InnoDB2. Die Wahl fiel hierbei auf die InnoDB, da
sie im Gegensatz zu MyISAM Transaktionen unterstutzt.
4.2.2 Parameterdaten fur 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 lasst. Eine Moglichkeit ware das Umwandeln der Parameter-Daten
in einen String, wobei die einzelnen Parameter durch einen Delimeter getrennt sind. Eine weitere
Moglichkeit ware das Umwandeln in Binardaten und das Abspeichern als BLOB3.
Da diese Daten dann Key-Value-Paare darstellen, konnte 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 Datensatzen
wurde sich eine Datenbank nur fur die Parameter-Daten der Handelssysteme allerdings nicht
lohnen.
Es wurde sich schliesslich fur das Speichern als serialisierte Objekte entschieden, da keine
besonderen Anforderungen vorliegen, die den Einsatz von anderen Speicherformen rechtfertigen
wurden.
4.2.3 Tick- und Bardaten
Wie bereits beschrieben, werden die fur Bars4 benotigten 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 benotigt.
Eine Besonderheit ist, dass z.B. Indikatoren immer Zugriff auf die aktuellen und die his-
torischen Daten fur einen bestimmten Zeitraum benotigen. 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 Binardaten, siehe [MySa].
4Anstatt Candlestick wird ab jetzt der Begriff Bar verwendet. Beide stellen Container fur die Preise: Open,High, Low und Close dar und konnen 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 fur
die letzten 4 Bars zu berechnen, mussten 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, ware allerdings eine denkbar
langsame Losung, bei ca. 100.000 Ticks pro Tag, pro Wahrungspaar.
Eine einfachere und effizientere Losung ist das Berechnen der Bars anhand der laufenden
Tickdaten. Dabei wird, um bei den Tagesbars zu bleiben, fur jeden Tag um 0 Uhr ein neuer
Bar erstellt und der alte Bar gespeichert. Der neue Bar speichert bei Eroffnung den aktuellen
Marktpreis als Open-, High-, Low- und Close-Preis. Bei jedem Tick wird der Close-Preis gesetzt
und gepruft ob ggf. auch High und Low neu gesetzt werden mussen. Da diese Operationen im
Arbeitsspeicher ablaufen, sind Sie sehr schnell, auch der Speicherverbrauch ist sehr gering. Das
wird fur alle geforderten Zeitebenen und Wahrungspaare gemacht. Diese Bar-Daten konnten in
einer Datenbank gespeichert werden.
Alternativ konnten Tickdaten in Dateiform gespeichert und verschiedene Losungen, wie
z.B. Apache Hadoop (Eine Implementierung, des von Google veroffentlichten Map-Reduce-
Verfahrens), der Rapidminer von Rapid-I oder die Programmiersprache R verwendet werden
(siehe [Apab], [Whi10], [Rap] und [R F]). Diese sind fur die Analyse großer Datenmengen
optimiert. Aus Zeitgrunden konnten sie jedoch nicht mehr evaluiert werden.
Aus Performancegrunden wird deshalb eine Speicherlosung auf Dateibasis einer Datenbank-
losung vorgezogen. Dazu wird fur jedes Wahrungspaar ein Ordner angelegt und darin fur jede
Zeitebene eine Datei angelegt. In der Datei werden die Bar-Daten, nach Datum sortiert, in Form
von Binardaten gespeichert. (Mit dieser Losung kann auf Indizes verzichtet werden, außer-
dem belegen Binardateien weniger Speicherplatz als Textdateien.) Als Zugriffsmethode wird
die NIO-API gewahlt, 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) unterstutzt. Durch Locking-Mechanismen muss die Integritat und Konsistenz
der Daten sichergestellt werden.
4.3 Kommunikationsprotokoll
Als Mittel fur die Kommunikation zwischen Client und Server wurde sich fur ein asynchrones
Kommunikationsprotokoll entschieden. Diese beruhen auf dem Versenden von Nachrichten und
eignen sich insbesondere fur Ereignis gesteuerte Systeme und fur langer laufende Operatio-
nen, wenn die zu ubertragenden Daten nicht sehr groß sind. Außerdem lasst sich synchrone
Kommunikation - also der Aufruf von entfernten Methoden - mit temporaren Warteschlangen
simulieren.
KAPITEL 4. ENTWURF 34
Als Framework wurde sich fur 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
clusterfahig und unterstutzt Transaktionen. Tritt z.B. beim Abholen einer Nachricht ein Fehler
auf, so bleibt diese beim Message-Broker und kann erneut abgeholt werden.
Als weitere Moglichkeiten, 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-Auftragen und Sta-
tusanderungen in Form von Events verteilt. Die Events werden in TradingsystemEvent, Ac-
countEvent und OrderEvent unterschieden und uber unterschiedliche Topics publiziert. Die
jeweiligen Auspragungen 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 fur 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-
sprunglichen Objekte wurde verzichtet2, um die Kommunikation unabhangig von Java zu halten
(Der verwendete JMS-Broker erlaubt auch C++, C#, Ruby, Perl, Python und PHP-Clients).
JMS-To-Event stellt daraus das ursprungliche Event wieder her und publiziert es auf Client-
seite. Dadurch kann das Kommunikationsprotokoll fur das Verteilen von Events jederzeit aus-
getauscht werden.
1Auf die Darstellung des Logging-Dienstes wurde aus Grunden der Ubersichtlichkeit verzichtet, da er vonfast jeder Komponente verwendet wird.
2Das gilt auch fur 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 fur ein Trade-Closed-Event
Das Listing 5.1 zeigt beispielhaft ein Event, das beim Schließen eines Einzeltrades ausgelost
wird. Das Event enthalt eine Hashmap und ein Topic. Die Hashmap(Listing 5.1, Zeilen 1-4)
enthalt das ausgeloste Event und dazu gehorige Daten.
In diesem Beispiel wird nur die ID des zum Event gehorigen 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) lasst
sich ermitteln, dass es sich bei dem geschlossenen Trade um einen Trade fur 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 fur die Verteilung von Events und Tick-Daten zustandig 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 Auftragen an den Server. In den folgenden Un-
terkapiteln, wird die Benutzeroberflache des Clients kurz naher erlautert.
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 ware”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
temporare 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 tragt sich die Anwendung als
Empfanger 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 Benutzeroberflache (siehe Abbildung 5.2) wurde nach der Workbench-Metapher3 gestal-
tet und ist in Menuzeile, Toolbar und Hauptfenster unterteilt. Die in den Usecases definierten
Aktionen konnen entweder uber Kontextmenus, Menuzeile oder Toolbar ausgelost werden. Diese
Aktionen sind meist nur erlaubt, wenn ein dazu passendes Element ausgewahlt wurde. So muss
z.B. um einen Trade auszulosen ein PAMM-Konto ausgewahlt werden. Das Hauptfenster ist un-
terteilt in Symbolubersicht, Kontenubersicht, Tradeubersicht und einer Ubersicht aller laufend-
en automatischen Handelssysteme.
3siehe [Rei09] Seite 52ff
KAPITEL 5. IMPLEMENTIERUNG 38
5.2.2.1 Symbolubersicht
Die Symbolubersicht soll dem Benutzer eine Marktubersicht geben und zeigt alle handelbaren
Wahrungspaare, mit aktuellen Bid- und Ask-Preisen. Symbole konnen der Liste hinzugefugt
und aus ihr entfernt werden.
5.2.2.2 Kontenubersicht
Die Kontenubersicht stellt PAMM-Konten und darin enthaltene Einzelkonten in einer
Baumubersicht dar. Hier konnen PAMM- und Einzelkonten angelegt und geloscht werden.
Außerdem konnen PAMM-Trades ausgelost werden, allerdings nur wenn alle darin enthalte-
nen Einzelkonten online sind. Einzelkonten werden mit einem roten Symbol, wenn sie offline
sind, oder mit einem grunen Symbol, wenn sie online sind, dargestellt.
5.2.2.3 Tradeubersicht
In der Tradeubersicht werden nach PAMM-Konten getrennt offene und bereits geschlossene
PAMM-Trades angezeigt. Sie wird durch einen Doppelklick auf ein PAMM-Konto in der Kon-
tenubersicht geoffnet. Bei offenen Trades konnen nachtraglich Stop- und Limit-Preis gesetzt
bzw. geandert werden. Weiterhin konnen 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 konnen hier gestartet und gestoppt
werden. Um ein Handelssystem zu starten, wird ein Wizard (siehe Abbildung 5.3) geoffnet.
Auf der ersten Seite wird das Handelssystem ausgewahlt und allgemein gultige Parameter, also
Wahrungspaar, Zeitebene und Konto, eingegeben. Die nachste Seite wird anhand der vom Han-
delssystem vorgegebenen Parameter erstellt. Es werden automatisch, fur Java-Basisdatentypen
(außer Boolean), Eingabefelder und fur Parameter mit vorgegebenen Auswahlmoglichkeiten
KAPITEL 5. IMPLEMENTIERUNG 39
(inklusive Boolean) Dropdown-Listen erstellt. Der Wizard uberpruft die Eingaben auf Validi-
tat, fuhrt 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 enthalt zusatzlich 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 fur ein Einzelkonto dieses Brokers besteht.
Der Bundle-Activator erstellt beim Start des Bundles ServiceTracker fur 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 enthalt,
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 Wahrungspaar uber die eigene
Klasse Instrument ab, was hier entsprechend umgewandelt wird.
KAPITEL 5. IMPLEMENTIERUNG 40
Jedes Einzelkonto wird Broker-spezifisch abgebildet, stellt unabhangig von anderen Konten
eine Verbindung zum Broker her und bleibt aus Performancegrunden immer verbunden. Sie leit-
en die Auftrage des API-Controller an den Broker weiter und publizieren uber Events wie, wann
und ob diese Auftrage 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
Kontogrosse zu gewahrleisten. Jedes Einzelkonto verarbeitet Auftrage 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 gewahlt und veroffentlicht 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 konnen, wird die Aus-
fallsicherheit dieses Dienstes erhoht.
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
ladt er Trade und Kontodaten vom DAO-Service. Er ist der Mediator zwischen Client-Auftragen
und Broker-API-Controller. Wird z.B. ein PAMM-Trade ausgelost, 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 moglichen
Zustande, 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
dazugehorigen Einzelkonten den Status auf offline.
In dem Aktivitatsdiagramm (Abbildung C.11, Seite 68) wird exemplarisch das Verarbeiten
eines neuen PAMM-Trades5 dargestellt. Hier werden die einzelnen Vorgange bei der Verar-
beitung und das Auslosen von Events gezeigt, aus Platzgrunden 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 erfullt
KAPITEL 5. IMPLEMENTIERUNG 41
5.3.3 Account-, Trade-DAO-Service
Wird ein neuer Trade oder ein neues Konto erstellt, so wird das dazugehorige Java-Objekt uber
ein entsprechendes Event verteilt. Der DAO-Service registriert sich als Eventhandler und nimmt
selbstandig das Speichern dieser Objekte vor, weiterhin verarbeitet er Anderungen von Trade-
und Kontozustanden und speichert sie ab.
Die Verbindung zum SQL-Server wird uber einen Connectionpool6 hergestellt. Dieser halt
immer eine einstellbare Anzahl von Verbindungen offen und offnet bei Bedarf weitere Verbin-
dungen bzw. schließt diese wieder bei Nichtbenutzung. Dadurch muss nicht fur jeden SQL-Befehl
eine Verbindung aufgebaut werden, was relative lange dauern kann und die Performance be-
eintrachtigen wurde. SQL-Befehle werden in Rahmen von Transaktionen, um Integritat und
Konsistenz der Daten sicherzustellen abgesetzt. Dazu werden Prepared Statements benutzt,
um die Performance zu erhohen.
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, fur die in
den Anforderungen genannten Wahrungspaare 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 durchgefuhrt. Wird der
aktuelle Bar von anderen Komponenten benotigt, so wird eine Kopie dieses Bar als Antwort
ubermittelt, wahrend 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 zuruckgesetzt 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 moglich, 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 konnen 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. Fur die Berechnung werden
die benotigten Bardaten im Arbeitsspeicher gehalten und mit Hilfe der Tickdaten selbstandig
gepflegt, was auch in der Klasse Indicator geregelt ist.
5.3.6 Handelssysteme
Handelssysteme konnen eine Vielzahl von Einstellungs-Parametern haben. Fur die Parameter
und das Handelssystem wurden Java-Annotationen definiert. Die Methoden zum Setzen dieser
Parameter und die Klasse des Handelssystems mussen durch Java-Annotationen gekennzeichnet
werden. In der Annotation werden die zur Beschreibung des Parameters benotigten 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 fur eine Methode
Handelssysteme (siehe Seite 70) konnen 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 Losung hat den Vorteil, dass jed-
KAPITEL 5. IMPLEMENTIERUNG 43
erzeit neue Handelssysteme zu einem Bundle hinzugefugt werden konnen, 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 fur 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 konnen uber die OSGi-Konsole installiert werden. Diese Bundles konnen 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 fur ein Handelssystem
Zum Abschluss zeigt das Listing 5.7 einen Ausschnitt aus einem Handelssystem. Bei jedem Tick
pruft das System, ob sich schneller und langsamer Moving Average gekreuzt haben und erofnet
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 fur ein Handelssystem
Kapitel 6
Software-Test
In Rahmen von Tests sollte uberpruft werden, ob die Anwendung die in der Anforderungs-
analyse ermittelten funktionalen Anforderungen erfullt. Dazu wurden Tests der grafischen Be-
nutzeroberflache (GUI) und Funktionstests automatisiert durchgefuhrt. In GUI-Tests wurden
die wesentlichen Funktionen des Benutzerinfaces und die korrekte Ausfuhrung auf Clientseite
betrachtet. Im Rahmen der Funktionstests, wurden die Schnittstellen der Serverkomponenten
untersucht und wie die einzelnen Komponenten auf die Ausfuhrung reagieren. Außerdem wur-
den Skalierbarkeits-Tests durchgefuhrt um Hardwareanforderungen abzuschatzen.
In diesem Kapitel, wird der Entwurf der zu automatisierenden Tests, Ausfuhrung und Ergeb-
nisse der Tests beschrieben. Die Testfalle entsprechen den Anwendungsfallen, 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 ausgefuhrt. Client-, Server-Anwendung, JMS-Broker und MySQL-Server
liefen wahrend 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 ausgefuhrt.
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 fuhren 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 Testfalle auch lauffahig,
wenn die Benutzeroberflache um weitere UI-Elemente erweitert wird. Sie unterscheiden sich
KAPITEL 6. SOFTWARE-TEST 46
dadurch, dass beim WindowTester der erste Testlauf manuell ausgefuhrt 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 unterstutzt 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 auslosbar sein und einen entsprechenden Request an
den Server senden. Dieser muss die Aufgabe bearbeiten und Fehler- bzw. Erfolgsmeldungen
zurucksenden, die vom Client verarbeitet und auf der Benutzeroberflache 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 Durchfuhrung
Um die Tests vorzubereiten musste der Login-Dialog deaktiviert werden, da er vor der Applica-
tion startet und damit auch vor SWTBot. Fur die Durchfuhrung der Tests wurde ein Projekt fur
ein SWTBot Test-Plugin erstellt. Bei der Erstellung der Testfalle musste dann berucksichtigt
werden, dass Ergebnisse erst nach einer gewissen Zeit vorliegen, da alle Methodenaufrufe zum
Erstellen/Loschen 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 benotigte 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
Menu anklickt und in das sich offnende Dialogfenster entsprechende Daten eingibt.
6.3 Funktionstests
Die Serverkomponenten wurden im Rahmen von Funktionstests als JUnit-Tests durchgefuhrt.
Hier wurde die korrekte Ausfuhrung von Funktionsaufrufen in Form von Blackbox-Tests
uberpruft. Das heisst, dass die Schnittstellen-Methoden der Komponenten aufgerufen und deren
Ruckgabewerte beziehungsweise das Auslosen von Events gepruft wurde. Ausserdem wurde das
korrekte Abspeichern uber”pruft. So mussen z.B. nach dem Erstellen eines PAMM-Kontos ein
Event ausgelost 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 Loschen von Einzel-
und PAMM-Konten noch nicht gepruft werden. Als schwerwiegender stellte sich heraus, dass
der Handel von mehreren FXCM-Konten auf einem Rechner, zumindest mit der derzeitigen
Implementierung, nicht mehr moglich ist. So lasst sich seit dem Update der API vom 1.4.2011
nur noch das erste FXCM-Konto handeln. Werden weitere FXCM-Konten hinzugefugt, so stellen
diese zwar eine Verbindung zum Broker her, ein Ausfuhren von Trades ist jedoch nicht moglich
und wird mit einer Fehlermeldung vom Broker quittiert. Aus Zeitgrunden konnte nicht mehr
ermittelt werden, inwieweit sich dieses Problem beheben lasst.
6.5 Skalierbarkeits-Test
Im Rahmen von Skalierbarkeitstests wurde uberpruft, wie sich der Ressourcenverbrauch des
Server-Systems mit steigender Anzahl von Konten verandert. 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 fur Arbeitsspeicher und Threads in
einem Zeitraum von 5 Minuten ermittelt. Auf strichprobenartiges Messen wurde verzichtet, da
der Garbage Collector die Messungen verfalscht hatte.
Die bei den Tests ermittelten Werte skalieren linear, da jedes Konto unabhagig von an-
deren Konten eine Verbindung zum Broker herstellt und damit auch gleich viele Threads und
Arbeitsspeicher benotigt. Auffallig ist der dreimal so hohe Verbrauch von Arbeitsspeicher bei
Dukascopy-Konten, im Vergleich mit FXCM-Konten. So muss fur 5 Dukascopy-Konten Ar-
beitsspeicher von ca. 150 MB und bei FXCM-Konten in Hohe von ca. 50 MB kalkuliert werden.
Außerdem benotigen 5 Dukascopy-Konten mit 140 Threads ca. 100 Threads mehr als FXCM-
Konten. Der Unterschied lasst sich damit erklaren, dass die Dukascopy-API verschiedene Funk-
tionialitaten zum automatisierten Handel mitbringt, wahrend die FXCM-API ausschliesslich
KAPITEL 6. SOFTWARE-TEST 48
Handelsfunktionalitaten beinhaltet. Hier zeigte sich, dass diese APIs nur fur den Handel von
Einzelkonten optimiert sind.
In weiteren Tests musste die Ausfuhrungszeit 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 musste 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 mogliche Erweiterungen und zusatzliche 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
konnen.
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 bewahrt 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 eingeschrankt erreicht. Aus Zeitgrunden konnten weiterhin die
Kann-Kriterien nicht mehr erfullt werden.
7.2 Ruckblick
Die im Rahmen der Entwurfsphase getroffenen Entscheidungen wurden fur ein System getrof-
fen, das aus einem Anwendungsserver und gegebenenfalls einem Datenbankserver besteht. Sie
wurden aus der Absicht getroffen, die Daten so nah wie moglich bei der Anwendung (und damit
die Latenz gering) zu halten und eine hohe Performance zu erreichen.
Bei steigenden Anforderungen ist es moglich, dass diese Losungen nicht so skalieren wie
es gewunscht oder erforderlich ist. Weiterhin wird man um die Ausfallsicherheit zu erhohen
zentralisierte und clusterfahige Losungen bevorzugen. In diesen Fallen sollten die erwahnten
KAPITEL 7. FAZIT 50
alternativen Losungsansatze in Betracht gezogen werden. Insbesondere scheint hier die Losung
fur 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, mussten die
Probleme beseitigt und Ausfallsicherheit sowie Sicherheit der Daten erhoht 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 konnen.
Weiterhin wunschenswert wahre das Anzeigen von Charts und Indikatoren, z.B. mit Hilfe
des Business Intelligence and Reporting Tools von Eclipse (BIRT Project, [Ecla]). Ausserdem
sollte eine Moglichkeit 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 Finanzmarkte. FinanzBuch Verlag,
Munchen, 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 Devisenmarkten: Eine Anleitung fur die
Praxis unter Berucksichtigung 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] Wutherich, G. ; Hartmann, N. ; Kolb, B. ; Lubken, 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: Eroffnungskurs fur eine Long-Position und Schlusskurs fur 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: Eroffnungskurs fur eine Short-Position und Schlusskurs fur eine Long-Position.
Broker: Broker unterhalten Geschaftsbeziehungen zu Großbanken, oder sind selber eine
Großbank (z.B. Deutsche Bank, einer der groß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 fur Foreign Exchange, also den Devisenhandel.
Indikator: Ein Indikator ist ein Werkzeug der Chartanalyse zur statistischen Analyse von
Borsendaten.
Interbankenmarkt: Der Interbankenmarkt ist der Markt auf dem Banken unter anderem
Devisen handeln.
Majors: Unter Majors werden die meistgehandelten Wahrungspaare 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 Abkurzung von Percent Allocation Management Module und ist ein
Kozept fur ein Sammelkonto.
ANHANG A. GLOSSAR 56
Pip: Entspricht meist der vierten Nachkommastelle des Wechselkurses und ist die Maßeinheit
fur 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 Gebuhr die
Broker fur die Ausfuhrung eines Trades verlangen.
Tick: Ein Tick gibt immer den Bid- und Ask-Preis einer bestimmten Wahrung zu einer be-
stimmten Zeit an.
Trade: Steht fur eine Long- oder Short-Position.
Anhang B
JFace Data Binding
JFace Data Binding1 bietet eine weitere Moglichkeit um Datenmodell und UI-Elemente
miteinander zu verknupfen. 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 mussen fur Datenmodell-Objekt und UI-Element sogenannte
Observables erstellt werden, dass sind Objekte, die bei Veranderungen ein Ereignis auslosen.
Unterstutzt werden Datenmodell-Objekte, bei denen es sich um Beans, Objekte die den
PropertyChangeSupport gemaß 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 fur POJOs, dass
getter- und setter-Methoden, fur die zu uberwachenden Eigenschaften des Objekts, immer dem
Schema:
{get|set}+<Eigenschaftsname(beginnend mit Großbuchstaben)>
entsprechen mussen, z.B. getFirstName(), fur die Eigenschaft: firstName.
Listing B.1: Beispiel fur 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). Fur das Binding konnen verschiedene Update-
1vgl. [Ebe]
ANHANG B. JFACE DATA BINDING 58
Strategien, Konverter2 und Validierer, z.B. um nur Werte großer null zuzulassen, festgelegt
werden.
Das ganze Potential des JFace Data Bindings lasst sich im Zusammenspiel mit dem Eclipse
Modelling Framework (EMF) ausnutzen, da hiermit passende Modellklassen und Factories
erzeugt werden konnen.
2Fur einfache Konvertierungen, z.B. von String-Werten zu Integer-Werten, verwendet JFace Data Bindingautomatisch 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
Ben
utze
r
PA
MM
-Kon
to e
rste
llen
PA
MM
-Kon
to lö
sche
n
Bed
ingu
ng:
kein
e of
fene
n T
rade
s vo
rhan
den
Ein
zelk
onto
ers
telle
nzu
PA
MM
-Kon
to h
inzu
füge
n<
<in
clud
e>>
Ein
zelk
onto
lösc
hen
aus
PA
MM
-Kon
to e
ntfe
rnen
<<
incl
ude>
>
PA
MM
-Kon
to a
usw
ähle
n
<<
incl
ude>
>
Bro
kera
pi a
usw
ähle
n
<<
incl
ude>
>
Ab
bil
du
ng
C.2
:U
seca
seD
iagra
mm
-K
onto
verw
alt
ung
ANHANG C. ABBILDUNGEN 61
Ben
utze
r/H
ande
ls-
syst
em
Neu
en T
rade
ers
telle
n
PA
MM
-Kon
to a
usw
ähle
n
<<
incl
ude>
>
Tra
de s
chlie
ssen
Prü
fe P
AM
M-K
onto
<<
incl
ude>
>
Offe
ne T
rade
s an
zeig
en
Ges
chlo
ssen
e T
rade
s an
zeig
en
<<
incl
ude>
>
<<
incl
ude>
>
Tra
de a
usw
ähle
nS
top
setz
en
Lim
it se
tzen
<<
incl
ude>
>
<<
incl
ude>
>
<<
incl
ude>
><
<in
clud
e>>
Ab
bil
du
ng
C.3
:U
seca
seD
iagra
mm
-T
rad
ever
walt
un
g
ANHANG C. ABBILDUNGEN 62
Hand
elssy
stem
star
ten
Hand
elssy
stem
stop
pen
Zugr
iff au
f Ind
ikato
ren
Zugr
iff au
f hist
orisc
he C
hartd
aten
PAM
M-K
onto
aus
wähle
n
<<inc
lude>
>
Hand
elssy
stem
aus
wähle
n
<<inc
lude>
>
Hand
elssy
stem
<<inc
lude>
>
<<inc
lude>
>
<<inc
lude>
>
Zugr
iff au
f live
Cha
rtdat
en
<<inc
lude>
>
Zugr
iff au
f PAM
M-K
onto
<<inc
lude>
>
Hand
elssy
stem
eins
telle
n (E
igens
chaf
ten)
<<inc
lude>
>
System
Benutzer
<<inc
lude>
>
<<inc
lude>
>
Indi
kato
r ers
telle
n
Ab
bil
du
ng
C.4
:U
seca
seD
iagra
mm
-H
an
del
ssyst
eme
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
Acc
ount
stat
usac
coun
tID
acco
untT
ype
nam
e
PA
MM
Acc
ount
ist e
in
Sin
gleA
ccou
ntha
t1.
.m0.
.n
user
nam
e
pass
wor
d
acco
untN
umbe
r
acco
untH
olde
r
bala
nce
equi
ty
brok
erA
PI
Trad
e
mag
icN
umbe
r
trade
Type
sym
bol
take
Pro
fitst
opLo
ss
requ
este
dVol
ume
fille
dVol
ume
stat
us
erro
rMes
sage
ist e
in
PA
MM
Trad
eS
ingl
eTra
de
wei
ghte
dOpe
nPric
e
wei
ghte
dClo
seP
rice
hat
open
Tim
e
clos
eTim
e
open
Pric
e
clos
ePric
eha
t1.
.m0.
.n
1..m
0..n
sing
leA
ccou
ntID
pam
mA
ccou
ntID
stop
Loss
Ord
er
orde
rTyp
e
acco
untID
trade
ID
orde
rID
take
Pro
fit
orde
rSta
tus
erro
rMes
sage
Ab
bil
du
ng
C.7
:E
RM
-Dia
gra
mm
:D
ate
nty
pen
(Tei
l1)
ANHANG C. ABBILDUNGEN 65
Tick
bidask
symbol
date
volume
Bar
symbol
openDate
lastUpdate
open high
low
closetimeframe
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
*
Ab
bil
du
ng
C.9
:K
lass
end
iagra
mm
-D
ate
nty
pen
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
BrokerDatenbank-Server
Handelssystem-ControllerITradingSystemController
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_REJECTEDauslösen
enthält Einzelkonten?
Einzelkontenonline?
ja
nein
PAMM_TRADE_ERRORauslösen
nein
Berechne Gesamtvermögen
nein
Fehler
Einzeltradevolumenberechnen
Einzeltrades erstellen
SINGLE_TRADE_CREATEDauslösen
API-Controller
Transformationder Daten
Weiterleiten des Tradesan Einzelkonten
Senden des Tradeszum Broker
ok
Einzelkonten
ja
ja
TRADE_RECEIVEDauslösen
FehlerFehler
SINGLE_TRADE_ERRORauslösen
SEND_TO_BROKERauslösen
ok
Abbildung C.11: Aktivitatsdiagramm fur 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>>
APIServiceenthält die Keys
für die Hashmapsder 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: IntegerAnzahl von Indikatorwerten
-shift: Integer0 = 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-
terstutzte
Sprachen
Zugriff auf
Preisdaten
Webseite
Deutsche
Bank
ja, aber Konto
mit mind. 25.000$
Guthaben notig
Plattform
wurde von
FXCM
lizensiert
siehe FXCM www.dbfx.com
Dukascopy ja, aber Konto mit
mind. 100.000$
Guthaben notig
Version 4.4
Java in SDK integri-
ert, Daten auf 10
Sekunden-Basis
reichen bis 2003
zuruck
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
fur kommerzielle
Anwendungen
verfugbar ist.
www.fxcm.com
GAIN Capi-
tal
nein SOAP-
Interface
TCP/IP Socket-
Interface, keine
genaueren Infos
verfugbar
www.forex.com
- Fortsetzung nachste Seite -
ANHANG D. TABELLEN 72
Broker FIX-Support SDK - un-
terstutzte
Sprachen
Zugriff auf
Preisdaten
Webseite
Interactive
Brokers
ja, 500$ Lizen-
zgebuhr zzgl.
100$ monatlich
Version 4.4
C++, Java stark begrenzter
Zeitraum: z.B.
Minutenbars nur
fur die letzten 2
Tage
www.interactive
brokers.com
MB Trading ja, nach FIX
Gateway Zertfi-
fierungstest und
Lizenzgebuhr 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
verfugbar
www.openecry
.com
ANHANG D. TABELLEN 73
Tab
elle
D.2
:S
oft
ware
Ub
ersi
cht
Hers
tell
er
Nam
eW
eb
seit
eP
rogra
mm
iers
pra
che
verf
ugb
are
His
tory
Inte
ract
ive
Dat
a
eSig
nal
ww
w.e
sign
al.c
omeS
ign
al
Form
ula
Scr
ipt,
ein
eE
r-
wei
teru
ng
von
Jav
aS
crip
t
Tic
kd
ate
nb
iszu
40
Tage.
Intr
ad
ay-D
ate
n
bis
2007,
au
fT
ages
basi
sb
is1983
Met
aQu
otes
Sof
twar
e
Met
atra
der
4w
ww
.mql4
.com
mql4
,ei
ne
funkti
on
ale
Sp
rach
em
itC
-
ah
nli
cher
Syst
ax
vom
Bro
ker
ab
han
gig
Met
aQu
otes
Sof
twar
e
Met
atra
der
5w
ww
.mql5
.com
mql5
,ei
ne
ob
jekto
rien
tier
teS
pra
che
vom
Bro
ker
ab
han
gig
Mu
ltiC
har
ts,
LL
C
Mu
ltiC
har
tsw
ww
.mu
ltic
har
ts
.com
Easy
Lan
gu
age
unte
rstu
tzt
ver
sch
ied
ene
Date
nfe
eds
Tra
deS
tati
on
Sec
uri
ties
Tra
de
Sta
tion
ww
w.t
rad
esta
tion
.com
Easy
Lan
gu
age,
ein
efu
nkti
on
ale
Sp
rach
e,d
iean
die
natu
rlic
he
Sp
rach
e
an
gel
ehnt
ist
Intr
ad
ay-D
ate
nau
fM
inu
tenb
asi
s,d
ieb
is
2002
od
erb
is2007
zuru
ckre
ichen
Anhang E
Installationsanleitung
In diesem Kapitel werden die einzelnen Installationsschritte beschrieben. Die dazu benotigten
Dateien, sowie Sourcecode und diese Arbeit als pdf-Datei finden sich auf der beiliegenden
CD. Zur Durchfuhrung 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 fur 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 nachstes mussen 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 fur ein Demokonto des
Brokers Dukascopy. Sollten die Zugangsdaten nicht mehr gultig 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 ladt 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 benotigte 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
Eigenstandigkeitserklarung
Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit
Entwicklung eines Frameworks zum automatisiertenHandel eines Multi-Broker-PAMM-Accounts
selbststandig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst
habe. Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderen Prufungsbehorde
vorgelegt.
Berlin, den 21.4.2011