1. ENTWICKLUNG EINES FRAMEWORKS ZUM
AUTOMATISIERTEN HANDEL
EINES MULTI-BROKER-PAMM-ACCOUNTS
Abschlussarbeit
zur Erlangung des akademischen Grades
Bachelor of Science (B.Sc.)
an der
Hochschule f¨ur Technik und Wirtschaft Berlin
Fachbereich Wirtschaftswissenschaften II
Studiengang Angewandte Informatik
1. Pr¨ufer: Prof. Dr.-Ing. Thomas Schwotzer
2. Pr¨ufer: Prof. Dr.-Ing. R¨uger Oßwald
Eingereicht von
Sascha Jonas
21. April 2011
© Copyright 2011 Sascha Jonas. Alle Rechte vorbehalten.

3. 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

5. Inhaltsverzeichnis
Abbildungsverzeichnis vi
1 Einleitung 1
1.1 Abriss ¨uber die historische Entwicklung des Devisenmarkts . . . . . . . . . . . . 1
1.2 Der Devisenmarkt heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 PAMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Grundlagen 5
2.1 Grundlagen des Devisenhandels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Modularisierung in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Die OSGi Service Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Eclipse RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Anforderungsanalyse 21
3.1 Markt¨ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Entwurf 29
4.1 System-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Implementierung 35
5.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Software-Test 45
6.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 GUI-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6. INHALTSVERZEICHNIS vi
6.4 Ergebniss von GUI- und Funktionstests . . . . . . . . . . . . . . . . . . . . . . . 47
6.5 Skalierbarkeits-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7 Fazit 49
7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 R¨uckblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Literaturverzeichnis 50
A Glossar 55
B JFace Data Binding 57
C Abbildungen 59
D Tabellen 71
E Installationsanleitung 75
F Eigenst¨andigkeitserkl¨arung 77

7. Abbildungsverzeichnis
1.1 Percent Allocation Management Module (PAMM) . . . . . . . . . . . . . . . . . 4
2.1 Candlestick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Candlestick-Chart mit Moving Average und MACD . . . . . . . . . . . . . . . . 7
2.3 Bundle Lebenszyklus (Quelle: [wikc]) . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Event Admin Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Komponenten der Eclipse RCP Plattform. . . . . . . . . . . . . . . . . . . . . . . 17
5.1 FxTrader Client - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 FxTrader Client - GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 FxTrader Handelssysteme - Eingabe von Parametern . . . . . . . . . . . . . . . . 38
C.1 Sequenzdiagramm - Content Provider . . . . . . . . . . . . . . . . . . . . . . . . 59
C.2 Usecase Diagramm - Kontoverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 60
C.3 Usecase Diagramm - Tradeverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 61
C.4 Usecase Diagramm - Handelssysteme . . . . . . . . . . . . . . . . . . . . . . . . . 62
C.5 Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
C.6 Verteilungsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
C.7 ERM-Diagramm: Datentypen (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . . 64
C.8 ERM-Diagramm: Datentypen (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . . 65
C.9 Klassendiagramm - Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
C.10 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
C.11 Aktivit¨atsdiagramm f¨ur einen PAMM-Trade . . . . . . . . . . . . . . . . . . . . . 68
C.12 Klassendiagramm Server-Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 69
C.13 Klassendiagramm - Indikatoren und Handelssysteme . . . . . . . . . . . . . . . . 70

9. Kapitel 1
Einleitung
In diesem Kapitel wird auf die historische Entwicklung und die aktuelle Situation des De-
visenmarkts eingegangen. Im Anschluss werden das Percent Allocation Management Module
(PAMM), ein Konzept f¨ur ein Sammelkonto, und das Ziel dieser Arbeit erl¨autert.
1.1 Abriss ¨uber die historische Entwicklung des Devisen-
markts
Mit dem Bretton-Woods-Abkommen1
, das am 22.07.1944 von 44 Staaten in Bretton Woods,
USA beschlossen wurde, sollte das internationale W¨ahrungssystem neu geordnet werden. Zur
Kontrolle des neuen W¨ahrungssystems wurden die auch heute noch existierenden Institutio-
nen Weltbank und International W¨ahrungsfonds (IWF) geschaffen. Im Zentrum des Bretton-
Woods-Abkommens stand der US-Dollar, der als Leitw¨ahrung dienen sollte. F¨ur die W¨ahrungen
der teilnehmenden Staaten wurde ein fixes Wechselverh¨altnis zum US-Dollar festgelegt. Dieses
Wechselverh¨altnis durfte nur 1% um den festgelegten Wert schwanken. Die Zentralbanken der
jeweiligen L¨ander verpflichteten sich dazu, durch Ihre Geldpolitik und durch Eingriffe am De-
visenmarkt diese fixen Wechselkurse zu halten.
Ein weiterer Bestandteil des Abkommens war die enge Bindung des US-Dollar an Gold. Der
Kurs wurde auf 35 Dollar je Feinunze Gold festgelegt, wobei sich die Federal Reserve Bank of
New York (FED) verpflichtete, den fixen Wechselkurs von US-Dollar in Gold zu gew¨ahrleisten.
Die USA hatte in den 70er Jahren im Zuge des Vietnamkrieges mit großen Staatsdefiziten
zu k¨ampfen, was das Vertrauen in den US-Dollar stark d¨ampfte. Die ¨Olkrise von 1973 f¨uhrte
schließlich zum endg¨ultigen Zerbrechen des Bretton-Woods-Abkommens.
Seitdem wurde die Bindung von W¨ahrungen an Gold aufgegeben. Der Wechselkurs der
meisten W¨ahrungen wird nun durch den Handel an den Devisenm¨arkten und die Geldpoli-
1vgl. [Och04] 23ff

10. KAPITEL 1. EINLEITUNG 2
tik der Zentralbanken bestimmt. Eine Ausnahme bildet z.B. der chinesische Yuan, der mit
sehr geringem Spielraum an die Entwicklung des US-Dollar gekoppelt ist und nicht an den
Devisenm¨arkten gehandelt wird.

11. KAPITEL 1. EINLEITUNG 3
1.2 Der Devisenmarkt heute
Der Devisenmarkt, oder auch Forex-Markt2
, ist der globale Markt, auf dem W¨ahrungen gehan-
delt werden. Er ist an keinen festen B¨orsenplatz gebunden, da er außerb¨orslich3
durch den
Interbankenmarkt gebildet wird und ist aufgrund der unterschiedlichen Zeitzonen 24 Stunden
am Tag und 5 Tage in der Woche offen.
Der Devisenmarkt ist der gr¨oßte Finanzmarkt der Welt, mit einem durchschnittlichen Ta-
gesumsatz von 4.000 Milliarden US-Dollar [Mon]. Der Devisenkurs wird immer als Wechselkurs
zwischen zwei unterschiedlichen W¨ahrungen angegeben und so besteht ein Devisengesch¨aft auch
immer aus dem gleichzeitigen Kauf und Verkauf von unterschiedlichen W¨ahrungen. W¨urde man
zum Beispiel auf eine positive Entwicklung des Euro gegen¨uber dem US-Dollar setzen und eine
sogenannte Long-Position im EUR/USD er¨offnen, dann w¨urde man gleichzeitig Euro kaufen
und US-Dollar verkaufen.
Der Devisenmarkt wird durch den Handel verschiedener Akteure mit sehr unterschiedlichen
Zielen bestimmt. International agierende Unternehmen, wie z.B. IBM oder Porsche, unterhal-
ten eine eigene Forex-Abteilung, um sich gegen W¨ahrungsrisiken abzusichern. Zentralbanken
agieren um nationale Interessen zu sichern und Investoren spekulieren um Renditeziele zu er-
reichen.
Seit kurzem ist es auch Privatanlegern m¨oglich, am Devisenhandel teilzunehmen, da Broker4
durch sogenanntes Leverage die Mindesteinlage (f¨ur ein Minimum-Lot) stark verringert haben.
Die Positionsgr¨oßen f¨ur ein Devisengesch¨aft waren fr¨uher ein Vielfaches von einem Lot. Unter
einem Lot werden meist 100.000$ verstanden.
Seit einiger Zeit ist ¨uber Broker aber auch der Handel von Mini-Lot, also einem Vielfachen
von 0.1 Lot, und Micro-Lot, einem Vielfachen von 0.01 Lot, m¨oglich. Die H¨ohe des Leverage,
auch Hebel genannt, sagt aus wie viel Margin auf einem Konto f¨ur ein Devisengesch¨aft hinterlegt
sein muss. Bei einem Leverage von 1:100 und einer Positionsgr¨oße von 1 Lot m¨ussten 1.000$
statt 100.000$ als Margin hinterlegt sein.
Niedrige Margin-Anforderungen, hohe Volalit¨at und die M¨oglichkeit Kauf-(Long) und
Verkaufspositionen (Short) zu er¨offnen, machen diesen Markt so interessant.
2Forex-Markt steht f¨ur Foreign Exchange Market
3“over the counter
”
- OTC
4Broker unterhalten Gesch¨aftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. Deutsche
Bank, einer der gr¨oßten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf.

12. KAPITEL 1. EINLEITUNG 4
1.3 PAMM
Verm¨ogensverwalter und Devisenh¨andler verwalten eine Vielzahl von Kundenkonten. Um ein
Devisengesch¨aft (Trade) nun nicht f¨ur jedes verwaltetete Konto von Hand ausf¨uhren zu m¨ussen,
wurde das Percent Allocation Management Module (PAMM) entwickelt.
Kaufe
1 Lot
EUR/USD
PAMM-Technologie
Portfolioanteil
in %
angepasste
Positionsgröße
Einzelkonten
200.000 $
300.000 $
500.000 $
20%
30%
50%
0.2 Lot
0.3 Lot
0.5 Lot
Abbildung 1.1: Percent Allocation Management Module (PAMM)
Wie die Abbildung 1.1 zeigt, wird mittels PAMM eine Transaktion auf alle verwalteten
Konten, abh¨angig von deren Anteil am Gesamtverm¨ogen, automatisch aufgeteilt. Dabei wird
selbstverst¨andlich auch ber¨ucksichtigt, dass die Kundenkonten in unterschiedlichen W¨ahrun-
gen vorliegen k¨onnen. Dazu wird der aktuelle Wechselkurs zum US-Dollar ermittelt und eine
Umrechnung von Fremdw¨ahrungskonten in US-Dollar-Konten vorgenommen.
Diese Technologie wird inzwischen von vielen Brokern bereitgestellt. Jedoch gibt es zur
Zeit keine M¨oglichkeit, Konten von unterschiedlichen Brokern zu einem PAMM-Konto zusam-
menzufassen. Ein Grund f¨ur die Verteilung von Kundengeldern auf mehrere Broker k¨onnte die
Risikoabsicherung sein. So sind zum Beispiel Einlagen bei in Großbritannien residierenden Bro-
ker mit bis zu 50.000 GBP (ca. 60.000 Euro) versichert und bei in der Schweiz residierenden
Broker mit bis zu 100.000 CHF (ca. 80.000 Euro).
1.4 Zielsetzung
Ziel dieser Arbeit ist es, ein Framework zu entwickeln, das die APIs ausgew¨ahlter Broker kapselt,
um Konten dieser Broker zu einem PAMM-Account zusammenzufassen.
Das Framework soll modular aufgebaut und leicht um weitere APIs erweiterbar sein. Außer-
dem soll es wohlgeformte Schnittstellen zur Verf¨ugung stellen, um einen oder mehrere PAMM-
Accounts zu verwalten und den Handel von Devisen durchzuf¨uhren.
Aufbauend auf diesem Framework wird eine prototypische Anwendung entwickelt, die es
erm¨oglicht, automatisierte Handelssysteme zu erstellen, und mit diesen den PAMM-Account zu
handeln.

13. Kapitel 2
Grundlagen
Dieses Kapitel beschreibt im ersten Teil die fachlichen Grundlagen f¨ur den automatisierten
und computergest¨utzten Handel von Devisen. Aufgrund der formulierten Zielsetzung, dass die
Software leicht um weitere Broker-API‘s, Indikatoren und automatische Handelssysteme erwei-
terbar sein muss, wurde die OSGi Service Plattform die Grundlage f¨ur den Server gew¨ahlt. Um
die Vorteile von OSGi auch auf Clientseite nutzen zu k¨onnen, hat sich der Autor f¨ur die Eclipse
Rich Client Platform (RCP) entschieden. Beide Technologien werden im zweiten Teil dieses
Kapitels untersucht.
2.1 Grundlagen des Devisenhandels
Im Devisenhandel wird zwischen der fundamentalen und der technischen Analyse unterschieden.
In der fundamentalen Analyse werden Handelsentscheidungen anhand von Fundamentaldaten
wie z.B. dem Preisindex f¨ur die Lebenshaltung (CPI) oder dem Bruttoinlandsprodukt getroffen.
Der technische Analyst hingegen trifft seine Handelsentscheidungen anhand von aktuellen
und vergangenen Wechselkursen, in der Annahme, dass fundamentale Daten bereits eingepreist
seien, und benutzt daf¨ur Charts, Chart-Pattern1
und Indikatoren.
Zum Handel von Devisen k¨onnen beide Analyseformen kombiniert werden, im Rahmen dieser
Arbeit erstellte Handelssysteme werden sich jedoch auf die technische Analyse beschr¨anken.
2.1.1 Bildung eines Candlestick Charts
Zu den verbreiteten Chartformen geh¨ort der Candlestickchart. Zur Bildung eines Candlesticks
(siehe Abbildung 2.1) werden die in einem bestimmten Zeitraum aufgetretenen Ticks analysiert.
Der Candlestick bildet dann nur das Maxima (High), das Minima (Low), den Preis zu Beginn
(Open) und den Preis zum Ende (Close) dieses Zeitraums ab. Diese vier Preisdaten und die
1siehe [Wikb] und [Wika]

14. KAPITEL 2. GRUNDLAGEN 6
High
Low
Open
Close
Abbildung 2.1: Candlestick
Anzahl der in diesem Zeitraum gehandelten Lots (Volumen) werden alle oder teilweise, das
h¨angt von der Art des Indikators ab, von Indikatoren zur Berechnung ben¨otigt.
Weitere Chartformen sind der Balkenchart und der Linienchart. Der Balkenchart stellt wie
der Candlestickchart(siehe Abbildung 2.2): Open, High, Low und Close, nur in einer anderen
Form, dar, w¨ahrend der Linienchart nur die Close-Preise durch Linien miteinander verbindet.
Im Devisenhandel haben sich verschiedene Zeitebenen etabliert auf deren Basis gehandelt
wird. Die g¨angigsten Zeitebenen sind 1 Minute, 5 Minuten, 15 Minuten, 30 Minuten, 1 Stunde,
4 Stunden, 1 Tag, 5 Tage und 1 Monat, wobei Wochenenden nicht ber¨ucksichtigt werden.
2.1.2 Tickdaten
Durch den regen Handel an den Devisenm¨arkten k¨onnen sich Wechselkurse in volatilen M¨arkten
mehrmals in der Sekunde ¨andern. Diese Preis¨anderungen werden als Ticks bezeichnet. Ein Tick
gibt also immer den Wechselkurs einer bestimmten W¨ahrung zu einer bestimmten Zeit an.
Bei Wechselkursen wird zwischen Bid- und Ask-Preisen unterschieden. Er¨offnet man eine
Long-Position (Buy), dann wird diese Position zum Ask-Preis er¨offnet. Schließt man diese Po-
sition oder er¨offnet eine Short-Position (Sell), so geschieht dies zum Bid-Preis. Zwischen Ask-
und Bid-Preis liegt immer eine Differenz, die je nach Marktsituation, W¨ahrung und Broker
unterschiedlich sein kann. Diese Differenz wird Spread genannt und ist die Geb¨uhr, die Broker
f¨ur ihre Dienste verlangen. Der Spread liegt bei den Hauptw¨ahrungen, auch Majors genannt,
meist zwischen einem und vier Pips.
Ein Tick besteht also genaugenommen aus zwei Preisen, dem Bid- und dem Ask-Preis. F¨ur
Indikatoren und Charts werden meist Bid-Preise verwendet, da diese bei Ask-Preisen durch
marktabh¨angige Spreads verf¨alscht w¨urden.
2.1.3 Indikatoren
Indikatoren sind Werkzeuge zur statistischen Analyse von B¨orsendaten. Indikatoren k¨onnen un-
terteilt werden in trendfolgende Indikatoren, Oszillatoren und sonstige Indikatoren. Indikatoren
werden, f¨ur den aktuellen Candlestick, bei jedem Tick neu berechnet. F¨ur die Analyse werden
jedoch nur Indikatorenwerte von bereits abgeschlossenen Candlesticks verwendet.

15. KAPITEL 2. GRUNDLAGEN 7
12 EMA
26 EMA
Signallinie
Mittellinie
MACD
1
Abbildung 2.2: Candlestick-Chart mit Moving Average und MACD
Der gleitende Durchschnitt [eSib] (Moving Average) geh¨ort zu den trendfolgenden Indika-
toren:
”
Es ist seine Aufgabe, zu signalisieren, dass ein neuer Trend begonnen hat oder dass
ein alter Trend geendet oder sich umgekehrt hat.“2
. Der Moving Average wird meist mit den
Close-Preisen gebildet, kann unter anderem aber auch vom Mittelwert ((Low+High)/2) gebildet
werden.
Moving Averages werden in gewichtet und ungewichtet unterschieden. Beim simplen Moving
Average (SMA), wird jeder Preis gleich gewichtet, sodass sich folgende Formel ergibt:
SMA0 = 1
M
M
n=0
Preisn,
wobei M die Periode des Moving Average und damit die Anzahl der zur Berechnung einbezoge-
nen Candlesticks darstellt. Die Variable n steht f¨ur den Candlestick, dessen Preis zur Berechnung
genommen wird3
. Zu den gewichteten gleitenden Durchschnitten geh¨ort zum Beispiel der expo-
nentiell gegl¨attete Moving Average (EMA), bei dem Kurse der j¨ungsten Vergangenheit st¨arker
gewichtet sind als ¨altere Kurse. Dazu wird der Faktor α verwendet, mit α = 2
M+1 , wodurch
sich die folgende Formel ergibt:
EMA0 = (Preis0 · α) + (SMA1 · (1 − α)),
2siehe [Mur06] S. 203ff
3n=0 ist der aktuelle Candlestick (dessen Preis sich bei jedem Tick ¨andert), n=1 der letzte Candlestick, n=2
der vorletzte Candlestick usw.

16. KAPITEL 2. GRUNDLAGEN 8
Moving Averages gl¨atten das
”
Rauschen“ des Marktes, sie erleichtern das Erkennen von
Trends und werden oftmals zum Gl¨atten der Werte anderer Indikatoren benutzt.
Moving Averages k¨onnen so interpretiert werden, dass es sich um einen Aufw¨artstrend
handelt, wenn sich die Candlesticks ¨uber dem Moving Average befinden und ansonsten um
einen Abw¨artstrend. Ein ¨Uber- bzw. Unterschreiten des Moving Average, w¨urde dann einen
Trendwechsel signalisieren. Eine weitere M¨oglichkeit ist es, zwei Moving Averages, einen
langsamen und einen schnellen, zu verwenden. Befindet sich der schnelle Moving Average (12er
EMA) ¨uber dem langsamen (26er EMA), dann handelt es sich um einen Aufw¨artstrend und
ansonsten um einen Abw¨artstrend (siehe Abbildung 2.2). Das kreuzen der beiden Moving Av-
erages zeigt den Trendwechsel an (siehe den mit 1 markierten Kreis in Abbildung 2.2).
Oszillatoren sind Indikatoren, deren Werte entweder um die Mittellinie oder zwischen fest-
gelegten Werten, meist zwischen 0 und 100, schwanken. Der Moving Average Convergence
Divergence Indikator [eSia] (MACD) geh¨ort zu der Gruppe der Oszillatoren und berechnet
den Abstand zwischen zwei Moving Averages (meist 12er und 26er EMA) und eine Signallinie
(meist 9er EMA). Ein steigender MACD, ¨uber der Mittellinie, wird als Aufw¨artstrend und ein
fallender MACD, unter der Mittellinie, wird als Abw¨artstrend interpretiert. Als Trendwechsel
werden das Kreuzen der Mittel- oder Signallinie und Divergenzen4
gedeutet.
Zum Abschluss sei erw¨ahnt, dass Indikatoren nur Hinweise auf m¨ogliche Ereignisse geben
k¨onnen. Da es sich um statistische Analysen handelt, treffen von Indikatoren signalisierte
Ereignisse nur mit einer gewissen Wahrscheinlichkeit ein. Bei den oben erw¨ahnten Indikatoren
handelt es sich weiterhin um Indikatoren, die dem Markt
”
hinterherlaufen“, das heisst, dass
eine Marktbewegung auch bereits abgeschlossen sein kann und ein Neueinstieg in den Markt
nicht mehr profitabel ist.
2.1.4 Ordertypen
Ein einzelner Handel von Devisen wird als Order oder Trade bezeichnet. Es wird zwischen
Market Order und Pending Order unterschieden. Eine Market Order wird sofort und zum ak-
tuellen Marktpreis (Market Entry) ausgef¨uhrt. Eine Pending Order kann nur unter bestimmten
Voraussetzungen angelegt werden und wird zu einem vorher festgelegten Kurs (Pending Entry)
ausgef¨uhrt.
Market Orders werden verwendet, wenn der Zeitpunkt f¨ur die Er¨offnung eines Trades
wichtiger ist, als der Preis zu dem er er¨offnet wird. Bei Pending Orders ist der Zeitpunkt,
wann der Trade er¨offnet wird, nicht so wichtig. Dieser Ordertyp wird z.B. bei dem Handel von
Ausbr¨uchen aus Seitw¨artsm¨arkten oder bei wichtigen Nachrichten verwendet. Hier werden dann
Kauf- und Verkausorder ¨uber bzw. unter der bisherigen Range platziert und der Trader l¨asst
sich dann
”
einstoppen“:
4Beispiel: In der Abbildung 2.2 ist der MACD-Wert vom November 2007 geringer als der MACD-Wert vom
Dezember 2004, w¨ahrend der Close-Preis vom Dezember 2004 geringer als der vom November 2007 ist. Chartbild
und Indikatorbild unterscheiden sich, was als Divergenz bezeichnet wird.

17. KAPITEL 2. GRUNDLAGEN 9
Ordertyp Entry-Preis Stop-Preis Limit-Preis
Buy (Market Entry) Ask <Bid >Ask
Buy Limit (Pending Entry) <Ask <Pending Entry >Pending Entry
Buy Stop (Pending Entry) >Ask <Pending Entry >Pending Entry
Sell (Market Entry) Bid >Ask <Bid
Sell Limit (Pending Entry) >Bid >Pending Entry <Pending Entry
Sell Stop (Pending Entry) <Bid >Pending Entry <Pending Entry
Tabelle 2.1: Ordertypen und Voraussetzungen
F¨ur beide Ordertypen k¨onnen ein Stop, dient der automatischen Verlustbegrenzung, und ein
Limit, dient der automatischen Gewinnmitnahme, gesetzt werden. Beispiel: Soll eine Kauforder
ausgef¨uhrt werden, so geschieht dies zum Ask-Preis, der Stop m¨usste dann unter dem Bid-Preis
und das Limit ¨uber dem Ask-Preis liegen. Erreicht der Marktpreis entweder Stop oder Limit,
w¨urde die Position automatisch geschlossen werden. Alle Voraussetzungen f¨ur die einzelnen
Ordertypen k¨onnen in der Tabelle 2.1 nachgelesen werden.
Jeder Trade wird als einzelne Position behandelt und ist unabh¨angig von anderen Trades.
Damit ist es m¨oglich, gleichzeitig Long und Short zu sein, was im Devisenhandel g¨angige Praxis
ist und wird zum einen zur Risikoabsicherung benutzt. Auf der anderen Seite kann es zum
Beispiel bei Handelssystemen, die auf unterschiedlichen Zeitebenen agieren, zu gleichzeitigen
Long- und Short-Trades kommen.
Eine Ausnahme bilden hier Konten, die bei einem Broker in den USA gef¨uhrt werden. In
Reaktion auf die Finanzkrise wurde in den USA, durch die National Finance Authority (NFA),
eine andere Regelung eingef¨uhrt. Aufgrund der NFA Compliance Rule 2-43(b), ist hier nur eine
Position pro W¨ahrungspaar erlaubt. Die Konsequenz davon ist, dass ein neuer Short-Trade einen
bestehenden Long-Trade ganz oder teilweise schließt. Damit wird aus einer Long-Position mit
1,0 Lot eine Long-Position mit 0,5 Lot, wenn eine Short-Position mit 0,5 Lot er¨offnet wurde. Es
ist also innerhalb eines US-Kontos nicht mehr m¨oglich, gleichzeitig Long und Short zu sein. Dies
kann umgangen werden, indem ein Konto f¨ur Long- und ein anderes Konto f¨ur Short-Trades
genutzt wird.
Auch das Setzen von Stop- und Limit-Preis ist - bei US-Brokern - nicht mehr m¨oglich, kann
aber durch das Setzen entsprechender Entry-Orders ersetzt werden. So k¨onnten z.B. f¨ur einen
Long-Trade, eine Sell-Limit- und eine Sell-Stop-Order, anstatt eines Stop- und Limit-Preises,
benutzt werden.
Das bedeutet, dass Konten bei US-Broker und Konten bei Broker außerhalb der USA,
nicht in einem PAMM-Konto gemischt werden k¨onnen. Die im Rahmen dieser Arbeit erstellte
Anwendung wird US-Konten somit nicht voll unterst¨utzen.
2.1.5 Gewinn- und Verlustberechnung
Alle Wechselkurse werden auf mindestens 4 Nachkommastellen genau angegeben. Eine Aus-
nahme bilden z.B. Wechselkurse in denen der Japanische Yen (JPY) enthalten ist, da es im

18. KAPITEL 2. GRUNDLAGEN 10
JPY keine Cent-Betr¨age gibt. Die Preis¨anderungen werden in Pips gemessen, wobei ein Pip der
vierten Nachkommastelle also 0,0001 bzw. 0,01 im JPY entspricht.
In dem nachfolgenden Beispiel soll nun dargelegt werden, wie Gewinne oder Verluste bei
Trades berechnet werden. Die allgemeine Formel5
lautet:
Gewinn/V erlust = (Pips) · (Preis{sekund¨areW ¨ahrung/Kontow¨ahrung}) · (Lots) · 100.000$
In dem folgenden Beispiel wurde eine Long-Position6
im EUR/GBP bei 0,8431 ge¨offnet und bei
0,8442 geschlossen:
Kontow¨ahrung: USD gehandelte W¨ahrung: EUR/GBP
prim¨are W¨ahrung (Base): EUR sekund¨are W¨ahrung (Quote): GBP
Preis {sekund¨are W¨ahrung / Kontow¨ahrung} (GBP/USD): 1,6108
Open: 0,8431 Close: 0,8442
Pips: Close - Open = 0,8442-0,8431 = 0,0011 gehandelte Lots: 1
Gewinn/V erlust = (0, 0011) · (1, 6108) · (1) · 100.000$ = 177, 19$.
Im Kontext eines Trades f¨ur ein PAMM-Konto (PAMM-Trade) ist die Gewinn- und Verlust-
berechnung etwas schwieriger. Ein PAMM-Trade besteht aus vielen Einzeltrades, die bei ver-
schiedenen Konten und Broker ge¨offnet wurden. Bei einem PAMM-Trade wird es also eher
Regel als Ausnahme sein, dass die Einzeltrades zu verschiedenen Preisen ge¨offnet wurden. Das
liegt zum einen daran, dass Broker leicht unterschiedliche Preis-Feeds haben k¨onnen. Zum
anderen handelt es sich bei dem Devisenmarkt um einen sehr volatilen Markt, bei dem sich
W¨ahrungskurse sehr schnell ¨andern k¨onnen.
Es kann aufgrund der unterschiedlichen Preis-Feeds auch dazu kommen, dass ein Einzeltrade
bei einem Broker schon den Limit- oder Stop-Preis erreicht hat und geschlossen wurde, w¨ahrend
andere Einzeltrades noch offen sind.
Damit steht der endg¨ultige Gewinn oder Verlust f¨ur einen PAMM-Trade erst fest, wenn alle
Einzeltrades geschlossen wurden. Um nicht den laufenden Gewinn/Verlust f¨ur jeden Einzeltrade
eines PAMM-Trades auszurechnen, wird ein - nach Lotgr¨oße gewichteter - Durchschnittspreis
f¨ur den Open-Preis eingef¨uhrt:
gewichteter Open-Preis=(Lot1·Open1)+(Lot2·Open2)+...+(Lotn·Openn)
Lot1+Lot2+...+Lotn
,
dabei steht n f¨ur die Anzahl der Einzeltrades in einem PAMM-Trade. Anhand dieses Preises,
der gesamten Lotgr¨oße und dem aktuellen Devisenkurs, kann der aktuelle Gewinn- und Verlust
f¨ur einen PAMM-Trade leicht berechnet werden.
5Wenn die sekund¨are W¨ahrung gleich der Kontow¨ahrung ist, gilt: Gewinn/Verlust=(Pips)*(Lots)*100.000$.
6Bei einer Short-Position, w¨urde sich die Anzahl der Pips mit Pips = Open − Close berechnen.

19. KAPITEL 2. GRUNDLAGEN 11
2.1.6 Lotberechnung
Wie im letzten Unterkapitel ersichtlich wurde, h¨angt der Gewinn/Verlust eines Trades im großen
Maße von der Lotgr¨oße ab. Die Anzahl der Lots muss auch als einziger Parameter beim Er¨offnen
eines Trades angegeben werden. Doch wie bestimmt man die Lotgr¨oße?
Vor jedem Trade sollte festgelegt werden, wie groß das Risiko pro Trade sein soll (Ein guter
Wert liegt hier meist zwischen 1-3% der Kontogr¨oße). Das Risiko wird mit dem Setzen des Stop-
Preises festgelegt, bei dem ein m¨oglicher Verlust realisiert wird. Sind Stop-Preis und damit die
Entfernung vom Entry in Pips bekannt, kann die im letzten Unterkapitel erw¨ahnte Formel
benutzt werden, um die Lotgr¨oße zu bestimmen.
Eingeschr¨ankt wird die Lotgr¨oße und damit eine genaue Realisierung des Risikos pro Trade,
nur durch die Anzahl der erlaubten Nachkommastellen7
. Im Kontext eines PAMM-Kontos f¨uhrt
dies dazu, dass ein PAMM-Trade im Allgemeinen nicht gleichm¨aßig auf alle im PAMM-Konto
zusammengefassten Einzelkonten verteilt werden kann. Meistens wird eine optimale Aufsplit-
tung des PAMM-Trades in Einzeltrades nicht m¨oglich sein, da die f¨ur das Einzelkonto berech-
nete Lotgr¨oße auf- oder abgerundet werden muss, wodurch sich wiederum das Einzel- und
Gesamtrisiko des Trades ¨andert.
2.1.7 Automatische Handelssysteme
Automatisierte Handelssysteme sind autonome Systeme, die anhand von Indikatoren und/oder
Chartformationen, die Entscheidungen zum Kauf oder Verkauf von Devisen treffen und selb-
st¨andig den Handel durchf¨uhren. Sie haben ein beliebig komplexes Regelwerk, in dem Kriterien
f¨ur die Er¨offnung und das Schließen eines Trades, das Risiko pro Trade und die Stop- und
Limit-Berechnung festgelegt sind. Diese Werte sind meist nicht statisch, sondern k¨onnen vom
Anwender vor dem Starten des Systems festgelegt werden.
Automatisierte Handelssysteme bieten den Vorteil, dass sie rund um die Uhr die M¨arkte
analysieren und handeln k¨onnen, ohne emotionale oder psychologische Schw¨achen. Sie werden
weder durch Angst, noch durch Gier oder M¨udigkeit beeinflusst.
Ein weiterer Vorteil ist, dass automatisierte Handelssysteme nicht nur auf aktuelle De-
visendaten, sondern auch auf historische Daten angewendet werden k¨onnen. Mit diesem, als
Backtesting bekannten, Verfahren lassen sie sich nicht nur auf technische Funktionalit¨at, son-
dern auch auf m¨ogliche Profitabilit¨at testen.
Inzwischen unterst¨utzt jeder Broker das Erstellen von automatischen Handelssystemen, je-
doch verwendet auch jeder Broker daf¨ur eine andere Software, sodass automatische Handelssys-
teme nur mit Programmieraufwand portiert werden k¨onnen. Dies soll im Kapitel 3 genauer
untersucht werden.
7Zwei Nachkommastellen bei Micro-Lot-Konten und eine Nachkommastelle bei Mini-Lot-Konten

20. KAPITEL 2. GRUNDLAGEN 12
2.2 Modularisierung in Java
Dieses Unterkapitel soll verdeutlichen, was Modularisierung bedeutet und wie dieses
Architektur-Konzept in Java umgesetzt wird, bevor im n¨achsten Unterkapitel - mit OSGi - eine
modulare System-Plattform vorgestellt wird. Der klassische Modularisierungsbegriff lautet:
”
... Modularisierung bezeichnet ... die Aufteilung eines Softwaresystems in ¨uberschaubare
Einzelteile, die jeweils einen abgeschlossenen Aufgabenbereich umfassen und untereinander
mittels wohldefinierter Schnittstellen miteinander verbunden sind. [Rei09]“.
Bis zur Einf¨uhrung des objektorientierten Paradigmas, unterst¨utzten Programmiersprachen
die Modularisierung nur rudiment¨ar. Computerprogramme konnten nur durch Funktionen und
Prozeduren strukturiert werden und hatten damit eher monolithischen Charakter. Sie waren
schwieriger zu testen, schwieriger zu erweitern und schlechter wartbar.
Mit der Einf¨uhrung der objektorientierten Programmiersprachen, wurde das Konzept der
Modularisierung st¨arker verankert und um den Begriff der Komponente erweitert. Eine Kom-
ponente wird definiert als eine Einheit zur Komposition, d.h. sie wird nur als ganzes spezifiziert,
implementiert und eingesetzt. Eine Komponente besitzt fest spezifierte Schnittstellen, durch die
die Verwendung der Komponente geregelt ist.
Eine Komponenten-basierte Anwendung ist eine Komposition von Komponenten, wobei
einzelne Komponenten entweder durch komplett neue Implementierungen oder neue Versio-
nen aktueller Implementierungen ausgetauscht werden k¨onnen. Die einzelnen Komponenten
einer Komponentenbasierten Anwendung sind durch deren Schnittstellen gekoppelt, wobei
die konkrete Implementierung der Schnittstellen dem Benutzer der Komponente durch die
Kapselung verborgen ist. Komponenten bieten den Vorteil, dass sie wiederverwendbar und gut
testbar sind.
In Java lassen sich Beziehungen zwischen Komponenten nur unidirektional ausdr¨ucken.
Durch das import-Statement kann angegeben werden, welche anderen Komponenten es benutzt,
aber nicht welche Klassen es f¨ur die Benutzung durch andere Komponenten exportiert.
In Java werden weiterhin Klassen auf Sprachebene mit Hilfe von Packages hierarchisch
strukturiert. Dabei l¨asst sich zwar die Sichtbarkeit von Klassen auf Packageebene einschr¨anken,
f¨ur eine echte Komponentenbildung ist dies aber unzureichend. Die interne Implementierung
ist dadurch nicht ausreichend gesch¨utzt und ¨uber eine einfache Typumwandlung erreichbar.
OSGi ist eine auf Java basierende Plattform und erweitert Java um die M¨oglichkeit, echte
Komponenten zu entwickeln. Bei OSGi ist die Implementierung einer Komponente durch einen
separaten Class-Loader gesch¨utzt, außerdem ist es hier m¨oglich, explizit Abh¨angigkeiten, zu
exportierende Elemente und Schnittstellen zu definieren. Dies soll im n¨achsten Unterkapitel
genauer untersucht werden.

21. KAPITEL 2. GRUNDLAGEN 13
2.3 Die OSGi Service Plattform
Die OSGi Alliance, ein Konsortium von Technologieunternehmen, ist eine non-profit Orga-
nisation und wurde 1999 gegr¨undet. Ihre Aufgabe ist es, die Programmierschnittstellen und
Testf¨alle [OSGa,OSGb] f¨ur die OSGi Service Platform zu spezifizieren.
Die OSGi Service Platform ist ein dynamisches Modulsystem f¨ur Java. Es handelt sich um
eine javabasierte Softwareplattform, die die dynamische Integration und das Fernmanagement
von Softwarekomponenten (Bundles) und Diensten (Services) erm¨oglicht. Bundles und Services
k¨onnen zur Laufzeit in der Serviceplattform installiert und deinstalliert, aktualisiert, gestoppt
und gestartet werden, ohne dass die Plattform als Ganzes angehalten bzw. neu gestartet werden
muss [WHKL08].
Es gibt eine Referenzimplementierung von der OSGi Alliance, diese ist jedoch nicht f¨ur
den Produktiveinsatz gedacht. Hervorzuheben sei hier die Implementierung durch das Eclipse
Equinox Projekt, welche Open Source ist und die Grundlage von Eclipse seit Version 3.0 bildet.
Weitere Implementierungen sind z.B. Apache Felix und Knopflerfish.
2.3.1 OSGi Bundles
Das fundamentale Konzept der OSGi Service Plattform ist die Modularisierung. In der OSGI-
Terminologie werden diese Module als Bundles bezeichnet. Unter einem Bundle versteht man
eine fachlich oder technisch zusammenh¨angende Einheit von Klassen und Ressourcen, die
unabh¨angig von anderen Bundles im OSGi Framework installiert und deinstalliert werden
kann [WHKL08]. ¨Ublicherweise wird f¨ur Bundles die Dateiendung
”
.jar“ verwendet. Von einer
normalen JAR-Datei unterscheidet sich ein Bundle nur durch ein Bundle Manifest.
INSTALLED
RESOLVED
UNINSTALLED
STARTING
ACTIVE
STOPPING
Start
Stop
Abbildung 2.3: Bundle Lebenszyklus (Quelle: [wikc])
Die Abbildung 2.3 zeigt den Lebenszyklus eines Bundles. Jedes Bundle kann sich in sechs
verschiedenen Zust¨anden befinden:
ˆ INSTALLED: Das Bundle wurde erfolgreich auf der OSGI-Plattform installiert.

22. KAPITEL 2. GRUNDLAGEN 14
ˆ RESOLVED: Alle Abh¨angigkeiten (siehe Bundle Manifest) des Bundles konnten aufgel¨ost
werden. Das Bundle ist bereit gestartet zu werden oder wurde gerade gestoppt.
ˆ STARTING: Die start-Methode des Bundle-Activators wurde aufgerufen aber noch nicht
abgeschlossen.
ˆ ACTIVE: Das Bundle l¨auft und die start-Methode des Bundle-Activators wurde erfolgre-
ich abgeschlossen.
ˆ STOPPING: Die stop-Methode des Bundle-Activators wurde aufgerufen aber noch nicht
abgeschlossen.
ˆ UNINSTALLED: Das Bundle wurde deinstalliert.
Im Eclipse-Umfeld wird meist von Plug-ins anstatt von Bundles gesprochen. Beide Begriffe
beschreiben allerdings ein und dasselbe Konzept und werden synonym verwendet.
2.3.1.1 Das Bundle Manifest
Jedes Bundle wird ¨uber seine Manifest-Datei und darin definierte Manifest-Header beschrieben.
Das Bundle Manifest befindet sich in der JAR-Datei des Bundles unter dem Namen META-
INF/MANIFEST.MF. Die Manifest-Header werden ausf¨uhrlich im Kapitel 3.2 des OSGi-Core-
Compendium [OSGa] beschrieben. Listing 2.1 zeigt den Ausschnitt eines g¨ultigen Bundle Man-
ifest.
1 Bundle -Name: API -Interfaces
2 Bundle - SymbolicName : de.pammtrader.core.api.interfaces
3 Bundle -Activator: de.pammtrader.core.api.interfaces.Activator
4 Bundle -Version: 0.1.0
5 Bundle - RequiredExecutionEnvironment : JavaSE -1.6
6 Import -Package:
7 de.pammtrader.core.account.interfaces;version="[0.1.0 ,1.0.0)"
8 Export -Package: de.pammtrader.core.api.interfaces;version="0.1.0"
9 Require -Bundle: de.pammtrader.core.api.fxcm;bundle -version="0.1.0"
Listing 2.1: MANIFEST.MF
Bundles werden innerhalb der OSGi Service Plattform durch ihren symbolischen Namen
und ihrer Versionsnummer eindeutig identifiziert (Listing 2.1: Zeilen 2, 4). Diese beiden Felder,
sind auch die einzigen Header die gesetzt werden m¨ussen. Alle anderen Header sind optional.
Das bedeutet, dass Bundles auch in mehreren und unterschiedlichen Versionen auf der OSGi
Plattform installiert sein k¨onnen.
In der Manifest-Datei kann ein Bundle-Activator angegeben werden (Listing 2.1: Zeile
3). Dieser Bundle-Activator muss das Interface BundleActivator und dessen start- und stop-
Methode implementieren. Er ist mit der main-Methode aus Java-Programmen vergleichbar.
Weiterhin k¨onnen Abh¨angigkeiten wie ben¨otigte Java-Packages und Bundles definiert und
explizit Java-Packages exportiert werden (Listing 2.1: Zeilen 6-9). Damit wird eine weitere

23. KAPITEL 2. GRUNDLAGEN 15
Besonderheit von OSGi klar: Es kann nur auf Java-Packages anderer Bundles zugegriffen wer-
den, die diese auch exportieren.
2.3.2 OSGi Services
Mit der Hilfe von Services werden Bundles dynamisch durch das
”
publish, find and bind model“
lose gekoppelt. Ein Service ist ein Java-Objekt, das unter einem oder unter mehreren Java-
Interfaces bei der Service-Registry angemeldet ist. Bundles k¨onnen Services registrieren, nach
Services suchen und sich benachrichtigen lassen wenn sich Services anmelden, abmelden oder
aktualisert wurden. [OSGa]
Da Services sich zu beliebigen Zeitpunkten bei der Service-Registry registrieren und dereg-
istrieren k¨onnen, gilt es, dies bei der Benutzung von Services zu beachten. Um den Umgang
mit Services zu vereinfachen, wurden der Service-Tracker und Declarative Services geschaffen.
Bei einem Service-Tracker handelt es sich um eine Hilfsklasse, die den Zugriff auf die Service-
Registry kapselt und das An- und Abmelden von Services mit einem spezifischen Interfacena-
men ¨uberwacht. Mit der Hilfe von Declarative Services k¨onnen Service-Abh¨angigkeiten in einer
XML-Datei beschrieben werden. Das Aufl¨osen von Service-Abh¨angigkeiten wird dann durch
die Service Component Runtime realisiert. Beide Ans¨atze werden genauer im OSGi Service
Compendium [OSGb] beschrieben.
2.3.2.1 Event Admin Service
Im OSGi Service Compendium [OSGb] werden eine Reihe von Diensten spezifiziert. Die im
Rahmen dieser Arbeit erstellte Anwendung benutzt unter anderem den Event Admin Service,
weswegen dieser hier erl¨autert werden soll. Der Event Admin Service basiert auf dem
”
publish-
<<class>>
Event
<<service>>
Event Admin
<<service>>
Event Handler
Event Consumer
impl EventHandler
Event Publisher
1 0..n
Abbildung 2.4: Event Admin Service
subscribe model“ und erlaubt die systemweite Kommunikation zwischen Bundles. Abbildung
2.4 stellt den Event Admin Service schematisch dar: Event Publisher benutzen die postEvent-

24. KAPITEL 2. GRUNDLAGEN 16
Methode des Event Admin Service zum asynchronen bzw. dessen sendEvent-Methode zum
synchronen Versenden von Events.
Alle Bundles, die sich f¨ur ein Topic und dessen Events interessieren, registrieren sich nun
nicht beim Event Admin Service als Listener. Stattdessen implementieren sie das Interface
EventHandler, registrieren sich als Dienst, ¨ubergeben als Service-Property das Topic und werden
vom Event Admin Service ¨uber Events informiert. Dieses Design Pattern wird Whiteboard-
Pattern genannt.
Ein Event wird repr¨asentiert durch ein org.osgi.service.event.Event Objekt und hat die zwei
Attribute: Topic und Properties. Topics sind String Objekte und case-sensitive. Ein Beispiel f¨ur
ein g¨ultiges Topic w¨are
”
de/pammtrader/api“, wobei Wildcards erlaubt sind. Properties sind
HashMaps, wobei der Schl¨ussel ein String-Objekt ist und der dazu geh¨orige Wert ein beliebiges
Java-Objekt sein kann.
2.4 Eclipse RCP
Die Eclipse Rich Client Plattform8
(RCP) ist eine Plattform f¨ur modulare Desktopanwendun-
gen und basiert auf OSGi. Sie ist entstanden aus der Eclipse IDE und deren Versionssprung
auf Version 3.0. Die Entwicklung von Eclipse 3.0 bildete die Grundlage f¨ur eine Rich Client
Plattform, indem alle Abh¨angigkeiten zu IDE-spezifischen Elementen entfernt und viele Teile
des Benutzerinterfaces f¨ur die Anpassung durch den Entwickler ge¨offnet wurden. Die Abbildung
2.5 zeigt einige wichtige Komponenten der Eclipse RCP:
ˆ Equinox ist eine vollst¨andige Implementierung der OSGi Plattform Spezifikation, er-
weitert um f¨ur Eclipse RCP-Anwendungen ben¨otigte Komponenten, wie z.B. Extension
Registry, Applications und Products, die in der Abbildung 2.5 unter der Eclipse Core
Runtime zusammengefasst sind.
ˆ Jede Eclipse RCP-Anwendung definiert mindestens eine Application. Applications wer-
den mit Hilfe von Extensions definiert, die auf eine Klasse verweist, welche das Interface
IApplication implementiert. Diese Klasse ist vergleichbar mit der main-Methode aus Java-
Anwendungen und startet die Eclipse RCP Anwendung.
ˆ Ein Product ist eine Konfigurationsdatei in der die Eclipse RCP-Anwendung beschrieben
wird. Hier werden die Plug-ins, die die Anwendung bilden, aufgelistet und konfiguriert,
Icons und Bilder f¨ur das Branding der Anwendung und Startparameter definiert.
ˆ Das Standard Widget Toolkit (SWT) ist eine low-level Grafikbibliothek, welche
die Standard Bedienelemente wie Listen, Men¨us, Schriftarten und Farben zur Verf¨ugung
stellt und die nativen UI-Widgets des zugrunde liegenden Betriebssystems kapselt. SWT
8siehe [MLA10] S. 7ff

25. KAPITEL 2. GRUNDLAGEN 17
Abbildung 2.5: Komponenten der Eclipse RCP Plattform9
.
ist f¨ur eine Vielzahl von Betriebssystemen verf¨ugbar. Damit sind Anwendungen, die SWT
verwenden, sehr leicht portierbar und immer im Look & Feel des Betriebssystems auf dem
sie laufen.
ˆ JFace ist ein User Interface Toolkit (UI), mit Klassen f¨ur viele g¨angige Aufgaben in
der UI-Programmierung, das designt wurde mit dem SWT zusammenzuarbeiten, ohne
es zu kapseln. Es beinhaltet Komponenten wie Bild- und Schriftarten-Register, Dialoge,
Wizards, Actions, Views und Frameworks f¨ur Databinding und Preferences und bildet
damit die Basis des Eclipse UI.
ˆ Eclipse Update, genauer Eclipse p2, erlaubt es einen Update-Mechanismus f¨ur eine
RCP-Anwendung zu implementieren. Damit l¨asst sich nicht nur die Anwendung auf dem
neuesten Stand halten, es ist auch m¨oglich neue Features zu installieren. Updates k¨onnen
dann automatisch oder durch Benutzerinteraktion installiert werden.
Eine Eclipse RCP Anwendung besteht also immer aus einem oder mehreren Plugins und wird
zusammen mit seiner Laufzeitumgebung ausgeliefert.
2.4.1 Extensions
Ein Plug-in ist von einem Bundle nur durch die plugin.xml zu unterscheiden, die sich im Root-
Ordner des Plug-ins befindet und optional ist. In dieser Datei werden Extensions und Extension-
Points deklariert.
9Quelle: http://www.ralfebert.de/rcpbuch/overview/

26. KAPITEL 2. GRUNDLAGEN 18
Mit Extension Points10
¨offnen sich Plug-ins f¨ur Erweiterungen (Extensions) durch andere
Plug-ins. Diese Extensions k¨onnen Implementierungen von Interfaces sein, aber auch Daten
wie z.B. Icons oder Text. F¨ur jeden Extension-Point wird, mit Hilfe der Eclipse IDE, ein XML
Schema-Dokument (XSD-Datei) hinterlegt, in dem beschrieben wird, welche Daten eine Exten-
sion zur Verf¨ugung stellen muss.
Extension Points und Extensions werden von der Extension Registry verwaltet und sind
verf¨ugbar, sobald das dazugeh¨orige Plug-in den Status
”
resolved“ hat. Extensions werden bei
der Extension Registry abgefragt und nach dem
”
lazy-loading“ Prinzip bei Bedarf geladen.
Extensions sind ein fundamentales Konzept in der Entwicklung von Eclipse-RCP Anwen-
dungen. So sind UI-Elemente wie Views, Editoren und Perspektiven vom Entwickler erstellte
Extensions, zu von der Ecplipse RCP bereitgestellten Extension Points. Da diese Elemente in
nur einer Datei (und nicht z.B. auf mehrere Java-Klassen verteilt) beschrieben werden, ist es
f¨ur einen Ecplipse RCP-Entwickler einfach, sich in eine bestehende Anwendung einzuarbeiten
bzw. diese zu erweitern.
Listing 2.2 zeigt den Ausschnitt aus einer g¨ultigen plugin.xml, in der eine Application (Zeilen
1-8) und eine View (Zeilen 9-14) deklariert werden.
1 <extension id="application"
2 point="org.eclipse.core.runtime. applications ">
3 <application >
4 <run
5 class="de.fxsolution.client. Application">
6 </run >
7 </application >
8 </extension >
9 <extension point="org.eclipse.ui.views">
10 <view
11 class="...ui. singleaccount . AccountList "
12 id="de.fxsolution.client.ui. AccountList "
13 name=" AccountList ">
14 </view >
15 ...
Listing 2.2: plugin.xml
2.4.2 Synchronisation von Datenmodell mit UI-Elementen
Eclipse RCP unterst¨utzt explizit das Trennen von Datenmodell, Zugriff auf das Datenmodell
und Pr¨asentation des Datenmodells (MVC-Pattern). Diese Trennung in Komponenten hat den
Vorteil, dass die jeweilige Implementierung an sich ¨andernde Anforderungen angepasst werden
kann, ohne dass dies Konsequenzen f¨ur die anderen Komponenten haben muss. Damit wird die
Anwendung besser struktiert und ist leichter wart- und testbar.
10siehe [MLA10] S. 390ff

27. KAPITEL 2. GRUNDLAGEN 19
Um das Datenmodell zu kapseln und mit dem Benutzerinterface zu synchronisieren, bietet
die Eclipse RCP zum einen das, aus der Android Entwicklung bekannte, Konzept des Content
Providers und das JFace Data Binding Framework an. Beide Konzepte wurden evaluiert, jedoch
wird nur der Content-Provider genutzt. Auf die Verwendung des JFace Data Binding Framework
musste aus Zeitgr¨unden verzichtet werden. Es wird der Vollst¨andigkeit halber im Anhang auf
der Seite 57 vorgestellt.
2.4.2.1 Content Provider
Content Provider11
sind Klassen, die ein spezifisches Interface, aus dem Package
org.eclipse.jface.viewers, implementieren und Zugriff auf Daten gew¨ahren. Content Provider
bieten den Vorteil, dass sie sehr leicht zu implementieren sind.
Die Abbildung C.1 auf Seite 59 zeigt am Beispiel eines TreeViewers, wie ein UI-Element mit
einem Contentprovider verkn¨upft wird und wie dieses Element, mit Hilfe der Methode getChil-
dren(), Daten bezieht. Ein TreeViewer ist eine Komponente, die Elemente in einer Baumstruk-
tur, ¨ahnlich dem Windows Explorer, anzeigt und bezieht Daten entweder von einem ITreeCon-
tentProvider oder von einem BaseWorkbenchContentprovider und dazu geh¨origen IWorkben-
chadaptern.
¨Andert sich das Datenmodell, dann m¨ussen die UI-Elemente, mit der Hilfe von Listenern,
dar¨uber informiert und die Daten erneut vom Content Provider geladen werden.
11siehe [MLA10] S. 73ff

29. Kapitel 3
Anforderungsanalyse
Die im Rahmen dieser Arbeit entwickelte Anwendung stellt einen Prototyp f¨ur den Handel
von Devisen dar. Sie soll die Broker-APIs kapseln und deren Funktionalit¨aten mit einem ein-
heitlichen Benutzerinterface zu Verf¨ugung stellen. Weiterhin soll Sie es erm¨oglichen Einzelkon-
ten, die bei unterschiedlichen Brokern liegen k¨onnen, zu einem PAMM-Konto zusammenzu-
fassen. Diese PAMM-Konten sollen dann manuell oder mit Hilfe von automatischen Handelssys-
temen gehandelt werden k¨onnen.
Um diese Ziele zu erreichen, wird im ersten Teil dieses Kapitels ermittelt, was Broker an APIs
zur Verf¨ugung stellen. Daraus werden die funktionalen und nicht-funktionalen Anforderungen
an die Software abgeleitet, die im zweiten Teil formuliert werden.
3.1 Markt¨ubersicht
3.1.1 Broker-APIs
Nach einer Recherche bei g¨angigen Forex-Brokern (siehe Tabelle D.1 auf Seite 71) zeigte sich,
dass deren APIs in 3 Arten gegliedert sind:
Zum einen unterst¨utzen die meisten Broker das Financial Information eXchange (FIX)-
Protokoll. Alle untersuchten Broker bieten weiterhin eigene APIs an, wobei der Zugriff auf
historische Preisdaten meist - von den reinen Trade-Funktionalit¨aten getrennt - in einer eigenen
API zu finden ist. Als Programmiersprachen, werden C++ und/oder Java unterst¨utzt.
3.1.1.1 FIX-Protokoll
Das FIX-Protokoll1
ist ein Nachrichtenstandard, der speziell f¨ur den Handel von Wertpapieren
in Echtzeit entwickelt wurde. Das FIX-Protokoll ist offen und frei verf¨ugbar und liegt aktuell
in der Version 5.0 Service Pack 2 vor. Es ist komplett Nachrichtenbasiert und definiert eine
1vgl. [FP]

30. KAPITEL 3. ANFORDERUNGSANALYSE 22
Reihe von Nachrichten, die in Session- und Anwendungsnachrichten unterteilt sind, und darin
erlaubte Felder.
Diese Nachrichten k¨onnen zum einen in reiner Textform vorliegen, wobei ein Feld wie folgt
aufgebaut sein muss:
< TAG >=< V ALUE >< DELIMITER > z.B.:
”
8=FIX.4.4;“.
Sie k¨onnen aber auch, nach dem FIX-XML Standard, in XML-Form sein.
Zu den Session-Nachrichten geh¨oren unter anderem Logon-, Heartbeat- und Logout-
Nachrichten. Zu den Anwendungsnachrichten geh¨oren z.B. Nachrichten die zum ¨Offnen,
Schließen oder ¨Andern eines Trades versendet werden aber auch um Tickdaten zu abon-
nieren oder um History-Daten abzufragen. Dabei liegt es nat¨urlich am Broker, inwieweit er
alle M¨oglichkeiten unterst¨utzt.
Das FIX-Protokoll ist der Quasi-Standard, f¨ur den Handel an allen großen B¨orsenpl¨atzen
dieser Welt, wobei die Versionen 4.2 und 4.4 noch weit verbreitet sind.
Von den untersuchten Brokern unterst¨utzen, bis auf OEC und Gain Capital, alle Broker
dieses Protokoll. Dadurch w¨ahre es optimal f¨ur ein Broker-¨ubergreifendes Programm zum De-
visenhandel. Es ist allerdings nur f¨ur institutionelle Trader gedacht. So verlangen die Broker,
welche das FIX-Protokoll unterst¨utzen, entweder hohe Lizenzgeb¨uhren und dazu monatliche
Geb¨uhren oder es wird ein Konto mit einer hohen Mindestgr¨oße f¨ur das Kontoguthaben ver-
langt. Ohne diese Voraussetzungen zu erf¨ullen, ließen sich auch keine Testprogramme erstellen.
Aus diesem Grund wurde f¨ur diese Arbeit darauf verzichtet, das FIX-Protokoll zu imple-
menteren.
3.1.1.2 Zugriff auf Handelsfunktionalit¨aten
Alle untersuchten Broker unterst¨utzen den Handel von Devisen ¨uber eine eigene API. Die APIs
sind dabei sehr unterschiedlich. Sie reichen von dem komplett auf Nachrichten basierten FIX-
API, ¨uber den entfernten Aufruf von Methoden (RPC), bis zu einer Mischung aus beiden.
So bietet z.B. FXCM eine Java-API an, welche das FIX-API in entsprechende Java-Klassen
kapselt und damit komplett auf Nachrichten basiert. Zum Er¨offnen eines Trades muss hier
eine Nachricht verschickt werden, wobei zum Setzen eines Stop- und Limit-Preises jeweils eine
weitere Nachricht versendet werden muss. Stop- und Limit-Preis k¨onnen also auch erst gesetzt
werden, nachdem der Trade ge¨offnet wurde. Als Antwort werden vom Broker, bei Erfolg, drei
Executionreports, ein Positionreport und ein Collateralreport versendet, die alle auch ausge-
wertet werden m¨ussen.
Bei Dukascopy hingegen muss nur eine Methode aufgerufen werden, wobei hier direkt Stop-
und Limit-Preis gesetzt werden k¨onnen. Als Anwort erh¨alt man vom Broker nur eine auszuwer-
tende Nachricht.
Dies und die folgenden Merkmale m¨ussen bei der Planung der Anwendung ber¨ucksichtigt
werden, da diese nur Funktionalit¨aten haben kann, die alle Broker anbieten.

31. KAPITEL 3. ANFORDERUNGSANALYSE 23
Alle APIs erlauben die auf Seite 8 im Abschnitt 2.1.4 aufgelisteten Ordertypen. Teilweise
k¨onnen auch noch zus¨atzliche Ordertypen verwendet werden, wie z.B. der Trailing Stop. Hier
wird der Stop-Preis, beim Erreichen von bestimmten Zielen, automatisch nachgezogen.
Von Broker zu Broker unterschiedlich, ist auch die Anzahl der unterst¨utzten W¨ahrungspaare.
Diese reicht von 35 bis zu ¨uber 100 W¨ahrungspaaren. Alle Broker erlauben den Handel der
sogenannten Majors, also EUR/USD, GBP/USD, AUD/USD, NZD/USD, USD/CHF und
USD/JPY.
3.1.1.3 Zugriff auf Preisdaten
Alle Broker, bis auf Dukascopy, unterscheiden zwischen Tick-Daten und dem Zugriff auf History-
Daten. Die Tick-Daten werden ¨uber das eigene Trade-API und, falls vorhanden, ¨uber das
FIX-API angeboten. Um Tickdaten zu erhalten, m¨ussen sie f¨ur jedes W¨ahrungspaar abboniert
werden. Die Tickdaten werden dann unter Benutzung der Push-Technologie verteilt. Teilweise
m¨ussen diese auch abboniert sein, um den Handel ¨uber die API zu erm¨oglichen.
Der Zugriff auf History-Daten ist meist nur eingeschr¨ankt m¨oglich. Sie k¨onnen meist nur
¨uber ein extra API oder ¨uber das FIX-API abgefragt werden. Die Verf¨ugbarkeit von Preisdaten
schwankt stark in der Genauigkeit der Daten. So sind teilweise nur Daten auf Tagesbasis f¨ur
einen gr¨oßeren Zeitraum und genauere Daten wie z.B. auf Minutenbasis nur f¨ur einen kurzen
Zeitraum verf¨ugbar.
Das ist insbesondere f¨ur automatische Handelssysteme, wenn sie auf vergangene Zeitr¨aume
getestet werden sollen, aber auch f¨ur Indikatoren, die einen großen Zeitraum analysieren, von
Bedeutung. Hier werden m¨oglichst genaue Daten f¨ur einen m¨oglichst großen Zeitraum ben¨otigt,
im Falle des Backtesting der Handelssysteme am besten Tickdaten.
Weiterhin muss ber¨ucksichtigt werden, dass sich Broker in unterschiedlichen Zeitzonen
befinden k¨onnen, was zu unterschiedlichen Daten f¨ur den gleichen Zeitraum f¨uhrt. So ist es
m¨oglich, dass ein Broker auch Daten f¨ur Sonntage offeriert, obwohl der Handel erst am Montag
um 0 Uhr beginnt.
Zusammenfassend muss eine einheitliche L¨osung gefunden werden, bei der ein m¨oglichst
umfangreicher Zugriff auf historische Preisdaten gegeben ist. Diese L¨osung sollte unabh¨angig
von einem Broker sein.
Hier gibt es zum einen die M¨oglichkeit auf externe Anbieter von History-Daten zur¨uckzu-
greifen. Anbieter wie Google oder Yahoo offerieren B¨orsendaten kostenlos ¨uber eine einfache
API, mit der Daten als csv-Dateien exportiert werden k¨onnen. Diese Daten sind allerdings um
15-Minuten verz¨ogert und damit f¨ur den Live-Handel nicht brauchbar. Andere Anbieter wie
z.B. eSignal (www.esignal.com), netdania (www.netdania.com) oder iqfeed (www.iqfeed.net)
bieten Live-Forex-B¨orsendaten zu einem Preis von ca. 100$ im Monat an, was je nach Paket
und Anbieter differiert.
Eine weitere M¨oglichkeit ist das Aufbauen einer eigenen Datenbasis. Dazu k¨onnten History-
Daten von einem kostenlosen Anbieter heruntergeladen werden - am besten am Wochenende,

32. KAPITEL 3. ANFORDERUNGSANALYSE 24
wenn die B¨orsen geschlossen sind - und dann mit Hilfe der Tickdaten, die jeder Broker ¨ubermit-
telt, gepflegt werden. Diese L¨osung hat den Vorteil, dass sie Broker-¨ubergreifend funktioniert -
damit keine Abh¨angigkeiten aufweist - und keine Kosten durch externe Datendienste enstehen.
Bei Hard- oder Softwareproblemen oder bei Ausfall der Internetverbindung kann es jedoch zu
L¨ucken in der Datenbasis kommen.
Die letzte L¨osungsvariante soll im Rahmen dieser Arbeit verwirklicht werden.
3.1.1.4 Zugriff auf Indikatoren
FXCM und Dukascopy unterst¨utzen als einziges den Zugriff auf Indikatoren-Daten bzw. das
Erstellen von eigenen Indikatoren ¨uber APIs.
Bei FXCM k¨onnen Indikatoren-Daten ¨uber das Order2Go SDK abgefragt werden und
mit Hilfe eines Indicator SDK eigene Indikatoren erstellt werden. Als Programmiersprache
wird hierf¨ur Lua verwendet. Bei Dukascopy werden Indikatoren in Java erstellt und m¨ussen
das IIndicator-Interface implementieren. Beide bieten eine Vielzahl von fertigen Standard-
Indikatoren und unterst¨utzen damit das Erstellen von automatischen Handelssystemen.
Zusammenfassend fehlt auch hier eine einheitliche und Broker ¨ubergreifende L¨osung, zu-
mindest was die APIs der Broker betrifft. Aus diesem Grund wurde sich, im Rahmen dieser
Arbeit entschieden, eine eigene Basis f¨ur das Erstellen von Indikatoren und damit auch f¨ur das
Erstellen von automatischen Handelssystemen zu schaffen.
3.1.2 Unterst¨utzte Software
Um den Devisenhandel mit Hilfe automatisierter Handelssysteme zu erm¨oglichen, unterst¨utzen
die meisten Broker die Software externer Anbieter. Diese reichen von kostenloser und durchaus
empfehlenswerter Software wie den Metatrader von MetaQuotes Software, bis hin zu profess-
ioneller Chartsoftware von eSignal. Weitere Informationen finden sich hierzu in der Tabelle D.2
auf Seite 73.
3.2 Zielbestimmung
Die Anforderungen an die Software ergeben sich aus dem letzten Unterkapitel und aus den
allgemeinen Anforderungen an eine Software f¨ur den Devisenhandel. Sie werden in funktionale-
und nicht-funktionale Anforderungen unterteilt.
3.2.1 Funktionale Anforderungen
Die Anwendung ist in die Aufgabenbereiche: unterst¨utzte W¨ahrungspaare, Kontoverwaltung,
Tradeverwaltung und automatische Handelssysteme unterteilt. Die jeweiligen Anforderungen
finden sich in den folgenden Unterkaptiteln und in Form von Usecase-Diagrammen auf den
Seiten 60 - 62. Das Diagramm f¨ur die W¨ahrungspaare wurde dabei weggelassen.

33. KAPITEL 3. ANFORDERUNGSANALYSE 25
3.2.1.1 W¨ahrungspaare
Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur W¨ahrungspaare:
ˆ unterst¨utzte W¨ahrungspaare:
Beschreibung: Es sollen die W¨ahrungspaare EUR/USD, GBP/USD, AUD/USD und
NZD/USD unterst¨utzt werden. Indikatoren und Handelssysteme m¨ussen Zugriff auf his-
torische Preisdaten, aller auf Seite 5 im Kapitel 2.1.1 erw¨ahnten Zeitebenen, und auf
aktuelle Tickdaten dieser W¨ahrungspaare haben. Diese Daten sollen kostenneutral zur
Verf¨ugung stehen.
ˆ W¨ahrungspaare anzeigen:
Beschreibung: Es muss eine Liste geben, in der aktuelle Bid- und Ask-Preise angezeigt
werden.
Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur die W¨ahrungspaare:
ˆ unterst¨utzte W¨ahrungspaare:
Beschreibung: Es sollten weitere W¨ahrungspaare unterst¨utzt werden.
3.2.1.2 Kontoverwaltung
Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur die Kontoverwaltung:
ˆ PAMM-Konto anlegen:
Beschreibung: Es muss eine Funktion geben um PAMM-Konten anzulegen. Als Eingabe
wird ein Name ben¨otigt, der im System eindeutig sein muss.
Nachbedingung: Konto wurde angelegt.
ˆ PAMM-Konto l¨oschen:
Vorbedingung: Es d¨urfen keine Trades in dem PAMM-Konto offen sein.
Beschreibung: Es muss eine Funktion geben um PAMM-Konten und darin enthaltene
Einzelkonten zu l¨oschen.
Nachbedingung: PAMM-Konto und Einzelkonten wurden gel¨oscht.
ˆ PAMM-Konten anzeigen:
Beschreibung: PAMM-Konten und darin enthaltene Einzelkonten werden in einer Liste
angezeigt.
ˆ Einzelkonto anlegen:
Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Im Einzelkonto sind keine Trades
offen.
Beschreibung: Ein Einzelkonto kann angelegt werden, dazu muss ein PAMM-Konto
ausgew¨ahlt werden. Außerdem m¨ussen ein Broker ausgew¨ahlt und die Zugangsdaten
eingegeben werden.

34. KAPITEL 3. ANFORDERUNGSANALYSE 26
Nachbedingung: Einzelkonto wurde angelegt und dem PAMM-Konto hinzugef¨ugt. Kon-
tostatus wird auf Offline gesetzt.
ˆ Einzelkonto l¨oschen:
Vorbedingung: Es wurde ein Einzelkonto ausgew¨ahlt. Im Einzelkonto sind keine Trades
offen.
Beschreibung: Es muss eine Funktion geben um Einzelkonten zu l¨oschen.
Nachbedingung: Das Einzelkonto wurde gel¨oscht und aus dem PAMM-Konto entfernt.
Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur die Kontoverwaltung:
ˆ Kontow¨ahrungen:
Es sollten als Kontow¨ahrung f¨ur Einzelkonten nicht nur US-Dollar, sondern auch weitere
W¨ahrungen unterst¨utzt werden.
ˆ PAMM-Konten ¨andern:
Es sollte die M¨oglichkeit geben, den Namen von PAMM-Konten zu ¨andern.
ˆ Einzelkonto ¨andern:
Es sollte die M¨oglichkeit geben, die Daten von Einzelkonten zu ¨andern.
3.2.1.3 Tradeverwaltung
Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur die Tradeverwaltung:
ˆ PAMM-Trade erstellen:
Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt. Das PAMM-Konto enth¨alt
Einzelkonten, die alle online sein m¨ussen.
Beschreibung: Das System generiert f¨ur alle im PAMM-Konto enthaltenen Einzelkonten,
entsprechend dem Guthaben, jeweils einen Trade und l¨ost ihn aus. Es m¨ussen alle auf
Seite 8 im Abschnitt 2.1.4 aufgef¨uhrten Ordertypen unterst¨utzt werden.
Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde ausgef¨uhrt.
ˆ PAMM-Trade schliessen:
Vorbedingung: Es wurde ein PAMM-Trade ausgew¨ahlt, der offen ist.
Beschreibung: Es werden der PAMM-Trade und alle dazu geh¨origen Einzeltrades
geschlossen.
Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde geschlossen.
ˆ PAMM-Trades anzeigen:
Vorbedingung: Es wurde ein PAMM-Konto ausgew¨ahlt.
Beschreibung: Es werden alle zum Konto geh¨orenden PAMM-Trades gezeigt, getrennt in
offene und bereits geschlossene Trades.

35. KAPITEL 3. ANFORDERUNGSANALYSE 27
ˆ Stop- und/oder Limit-Preis setzen:
Vorbedingung: Es wurde ein PAMM-Trade ausgew¨ahlt, der offen ist.
Beschreibung: Stop- und Limit-Preis k¨onnen gesetzt werden, wenn sie die auf der Seite 8
in der Tabelle 2.1 aufgef¨uhrten Bedingungen erf¨ullen.
Nachbedingung: Stop- und Limit-Preis werden beim PAMM-Trade und bei allen dazu
geh¨origen Einzeltrades gesetzt.
3.2.1.4 automatische Handelssysteme
Es ergeben sich folgende zu erf¨ullende Muss-Kriterien f¨ur automatische Handelssysteme:
ˆ Indikator erstellen:
Beschreibung: Es muss eine M¨oglichkeit geben, Indikatoren zu erstellen. Der Indikator
verf¨ugt ¨uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigen-
schaften, die vom Handelsystem gesetzt werden m¨ussen. Diese Eigenschaften k¨onnen vom
Typ: String, Integer, Double und Boolean sein. F¨ur jede Eigenschaft k¨onnen minimale und
maximale Werte festgelegt werden. Außerdem muss der Indikator eine Eingabem¨oglichkeit
f¨ur mindestens ein W¨ahrungspaar und f¨ur eine Zeitebene besitzen.
Nachbedingung: Der Indikator wird zum Programm hinzugef¨ugt und kann von Handelssys-
temen genutzt werden.
ˆ Handelssystem erstellen:
Vorbedingung: Das Handelssystem hat Zugriff auf ben¨otigte Indikatoren.
Beschreibung: Es muss eine M¨oglichkeit geben Handelssysteme, zu erstellen und zum Pro-
gramm hinzuzuf¨ugen. Das Handelssystem verf¨ugt ¨uber eine Beschreibung, einen Namen
und hat eine beliebige Anzahl von Eigenschaften, die vom Benutzer beim Starten geset-
zt werden k¨onnen. Diese Eigenschaften k¨onnen vom Typ: String, Integer, Double und
Boolean sein. F¨ur jede Eigenschaft k¨onnen minimale und maximale Werte festgelegt wer-
den.
Nachbedingung: Das Handelssystem wird zum Programm hinzugef¨ugt und ist vom Be-
nutzer ausw¨ahlbar.
ˆ Handelssystem starten:
Vorbedingung: Die vom Handelssystem geforderten Eigenschaften wurden vom Be-
nutzer mit validen Werten gesetzt und es wurde ein PAMM-Konto, ein oder mehrere
W¨ahrungspaare und eine Zeitebene ausgew¨ahlt.
Beschreibung: Es muss eine M¨oglichkeit geben, ein Handelssysteme zu starten, welches
dann mit dem automatischen Handel beginnt.
Nachbedingung: Das Handelssystem wird vom Programm mit den ausgew¨ahlten Parame-
tern gestartet und erh¨alt, genau wie davon benutzte Indikatoren, Zugriff auf aktuelle und
historische Preisdaten.

36. KAPITEL 3. ANFORDERUNGSANALYSE 28
ˆ Handelssystem stoppen:
Vorbedingung: Es wurde ein Handelssystem ausgew¨ahlt.
Beschreibung: Es muss eine M¨oglichkeit geben, Handelssysteme zu stoppen.
Nachbedingung: Das Handelssystem wird gestoppt.
ˆ laufende Handelssysteme anzeigen:
Beschreibung: Es muss eine M¨oglichkeit geben, alle laufenden Handelssysteme anzuzeigen.
Es ergeben sich folgende w¨unschenswerte Kann-Kriterien f¨ur automatische Handelssysteme:
ˆ Handelssystem ¨andern:
Es sollte die M¨oglichkeit geben, die Eingabe-Parameter bereits laufender Handelssysteme
zu ¨andern.
3.2.2 Nicht-Funktionale Anforderungen
ˆ Hintergrundfunktionen:
Die Anwendung muss die Tickdaten aufzeichnen und die Daten f¨ur die History berechnen,
um die von Indikatoren und Handelssystemen ben¨otigten Daten zur Verf¨ugung stellen
zu k¨onnen. Diese Funktionen, genauso wie die automatischen Handelssysteme, m¨ussen
m¨oglichst 24 Stunden am Tag ohne Unterbrechung laufen.
ˆ Mehrbenutzerf¨ahig:
Die Anwendung soll in dem Sinne mehrere Benutzer unterst¨utzen, dass gleichzeitig
mehrere Benutzer mit dem gleichen Datenbestand arbeiten k¨onnen, ohne dass es ein
Login gibt. Alle Benutzer arbeiten also mit den gleichen Rechten, den gleichen Daten und
sind vom System nicht unterscheidbar.
ˆ Verschl¨usselung der Daten¨ubertragung:
Auf eine Verschl¨usselung der Kommunikation wird verzichtet.
3.2.3 Abgrenzungskriterium
Die Anwendung ist haupts¨achlich gedacht als Plattform f¨ur automatische Handelssysteme und
hat als Zielgruppe erfahrene Trader. Diese sollen zwar die M¨oglichkeit haben in Trades einzu-
greifen und selber zu traden. Auf die Anzeige von Charts wird jedoch verzichtet.

37. Kapitel 4
Entwurf
Aus den im letzten Kapitel ermittelten Anforderungen ergeben sich eine Reihe von Fragen,
die f¨ur den Entwurf der Anwendungs- und Systemarchitektur entscheidend sind. So m¨ussen
eine Reihe verschiedener Aspekte beachtet werden, die unter anderem die Datenspeicherung,
die Transaktionsbehandlung, die Integration der Broker-APIs, die Verteilung der Systembe-
standteile und die Kommunikation der Kompenenten untereinander betreffen.
Dieses Kapitel widmet sich dem Entwurf der Anwendung unter den genannten Gesichts-
punkten, dabei werden verschiedene L¨osungsans¨atze vorgestellt und diskutiert.
4.1 System-Architektur
Aus den Anforderungen an die Anwendungen ergab sich, dass einige Komponenten m¨oglichst
ohne Unterbrechung laufen sollen. Außerdem soll die Anwendung mehrbenutzerf¨ahig sein und
den Zugriff auf die Systeme der Broker erm¨oglichen.
Eine Trennung in Client und Server ist daf¨ur die beste L¨osung. Daraus ergibt sich eine so-
genannte Mehrschichten-Architektur, die sich aus Pr¨asentationsschicht, Datenhaltungsschicht,
der Schicht f¨ur die Gesch¨aftslogik und einer Schicht f¨ur die Einbindung der Broker-APIs zusam-
mensetzt. In den Abbildungen C.5 und C.6, auf den Seiten 63 bis 63, werden die Schichtenar-
chitektur und die Verteilung der Systeme schematisch dargestellt.
Der Client ist hier nur f¨ur die Pr¨asentation und Validierung zust¨andig und entlastet damit
den Server. Die Gesch¨aftslogikschicht wird auf den Server ausgelagert. Sie agiert als Fassade
und kapselt den Zugriff auf die Broker-APIs und auf die Datenschicht. Sie ist der Vermittler
zwischen dem eigenen System und den Broker-Systemen und vereinheitlicht die Datenmodelle
durch Transformation der zu ¨ubermittelnden Daten.
Durch die Trennung in Schichten ergeben sich eine Reihe von Vorteilen. Zum einen ist der
Zugriff auf die Daten und auf die externen Systeme gesch¨utzt, da kein direkter Zugriff von
außen m¨oglich ist. Zum anderen skaliert die Anwendung sehr gut, da die einzelnen Schichten
logisch voneinander getrennt sind und somit ¨uber mehrere Datenbank- sowie Anwendungsser-

38. KAPITEL 4. ENTWURF 30
ver verteilt werden k¨onnen. Außerdem ergeben sich wiederverwendbare Komponenten, z.B. f¨ur
den Zugriff auf Daten oder die Kommunikation zwischen Client und Server. Der Datenzugriff
erfolgt ¨uber Data Access Objects (DAOs), die den Zugriff ¨uber Schnittstellen kapseln und
deren Implementierung damit leicht austauschbar ist. F¨ur das Verteilen von Daten - zwischen
Client und Server - werden Data Transfer Objects (DTOs) verwendet, die nur Daten und keine
Anwendungslogik enthalten.
4.1.1
”
Event-Driven-Architecture“
Die Anwendung muss auf eine Vielzahl von verschiedenen Events reagieren, die von externen
und internen Systemen ausgel¨ost werden. So k¨onnen z.B. Einzelkonten on- oder offline gehen und
Trades nach dem Erreichen bestimmter Ziele automatisch geschlossen oder von automatischen
Handelssystemen ausgel¨ost werden. Die Anwendung hat weiterhin nur indirekten Einfluss auf
die externen Systeme der Broker. So kann sie zwar Trades und Orders ausl¨osen, wird aber
durch Events erst sp¨ater ¨uber die Ausf¨uhrung informiert. Trades und Konten k¨onnen sich damit
in verschiedenen Zust¨anden befinden, die ber¨ucksichtigt werden m¨ussen. Eine solche System-
Architektur wird als
”
Event-Driven“ bezeichnet.
4.1.2 Transaktionen in einer Mehrschichten-Architektur
Problematisch ist die Einbindung der externen Systeme, im Kontext von Vorg¨angen die Transak-
tionen ben¨otigen. Aktionen die PAMM-Trades oder PAMM-Konten betreffen, m¨ussen in G¨anze
auf allen dazugeh¨origen Einzel-Trades bzw. -Konten ausgef¨uhrt werden. Im Gegensatz zu in-
ternen Datenbanken gibt es jedoch bei externen Systemen nicht die M¨oglichkeit in Fehlerf¨allen
ein Rollback durchzuf¨uhren.
Das muss bei der Implementierung ber¨ucksichtigt werden. Es muss damit vor jeder Aktion
gepr¨uft werden, ob ben¨otigte Komponenten sich in einem fehlerfreiem Zustand befinden. Sind
z.B. die von einer Aktion betroffenen Konten nicht online oder verf¨ugbar, dann muss diese
abgebrochen werden.
4.1.3 System-Umgebung
Die Anwendung wird f¨ur MS-Windows entwickelt, sollte allerdings m¨oglichst leicht auf an-
dere Betriebssysteme portierbar sein. Es wurde sich deshalb f¨ur die Programmiersprache Java
entschieden, da sie plattformunabh¨angig ist und man - mit dem Java Native Interface (JNI) -
auch auf C-Bibliotheken zugreifen k¨onnte.
An dieser Stelle sei erw¨ahnt, dass Java f¨ur Echtzeit-Anwendungen oft kritisch betrachtet
wird. Dies liegt daran, dass es unter Java keine M¨oglichkeit gibt, Objekte selbst aus dem Speicher
zu entfernen. Diese Aufgabe ¨ubernimmt der Garbage Collector, ein vollautomatischer Speicher-
manager. Hierbei kann es zu Full-Garbage-Collections und damit sehr langen Pausen kommen.
(Eine Full-Garbage-Collection h¨alt das System komplett an (stop-the-world, Mark-and-Sweep-

39. KAPITEL 4. ENTWURF 31
Algorithmus), um die Objekte zu analysieren und Speicher freizugeben und zu kompaktieren.)
Diese langen Pausen k¨onnen unvorhersehbar eintreffen und in Ihrer Dauer, zumindest beim
Standard-Garbage-Collector, nicht beeinflusst werden. Um das Ziel von vorhersagbaren und
konstant kurzen Pausen zu erreichen, wurde von Sun der Garbage First (G1) Collector en-
twickelt.
Hier m¨usste die Anwendung in Langzeittests untersucht und optimiert werden, um optimale
Einstellungen zu finden. Aus Zeitgr¨unden konnte das zwar nicht mehr genauer untersucht wer-
den, es sei aber auf die Artikelreihe
”
Memory Management“ im Java Magazin verwiesen, die mit
der Ausgabe 3.2010 beginnt. Weitere Ansatzpunkte k¨onnten die f¨ur kommerzielle Anwendungen
gedachten Java-Echtzeit-Plattformen: Java Real-Time System von Sun, WebSphere Real Time
von IBM oder JRockit von Oracle sein (siehe [Orac], [IBM] und [Orab]).
4.1.4 System–Plattform
Wie bereits beschrieben, muss die Anwendung leicht um weitere Indikatoren und Handelssys-
teme erweiterbar sein. Mit der OSGi Plattform, wurde eine optimale L¨osung gefunden, da sie
zum Einspielen von Erweiterungen nicht gestoppt werden muss und als Modulsystem diese An-
forderung explizit unterst¨utzt. Sie bildet die Grundlage f¨ur die Serveranwendung, w¨ahrend die
Clientanwendung auf Eclipse RCP basiert.
4.2 Datenspeicherung
Das Datenmodell wurde aus den Erkenntnissen der vorherigen Kapitel extrahiert und ist in
Form eines Entity-Relationship-Modells (ERM) auf den Seiten 64 und 65 dargestellt. Um die
Beziehungen zwischen den Entit¨aten besser zu kennzeichen, wurde, in Abweichung zu Chen,
die
”
ist ein“-Beziehung mit einer gestrichelten Linie markiert.
Das Datenmodell stellt unterschiedliche technische Anforderungen, an das Persistieren der
Daten. Diese sollen in den nachfolgenden Unterkapiteln diskutiert werden.
4.2.1 Trade-, Order- und Kontodaten
Bei den Trade-, Order1
- und Kontodaten handelt es sich um gut strukturierte Daten, die leicht
zu normalisieren sind. Einzige Besonderheit ist, dass eine Transaktionsbehandlung ben¨otigt
wird. So besteht z.B. ein PAMM-Trade aus vielen einzelnen Trades und damit eine Aktion zum
Speichern auch aus einzelnen Speicheroperationen, die gemeinsam ausgef¨uhrt und abgeschlossen
werden m¨ussen. Nur dann ist die Konsistenz und Integrit¨at der Daten gew¨ahrleistet.
1Der Begriff der Order wird ab hier in zwei verschiedenen Zusammenh¨angen verwendet. Eine Order ist zum
einen ein Auftrag an das System, einen offenen Trade zu ¨andern oder zu schließen. Zum Anderen kann ein Trade
vom Typ: Pending Order oder Market Order sein.

40. KAPITEL 4. ENTWURF 32
Damit eignen sich insbesondere relationale Datenbanken f¨ur die Benutzung als Speicherl¨o-
sung. Diese sind durch den Einsatz von Index- und Caching-Mechanismen, anderen L¨osungen
wie z.B. dem Datei-basierten Speichern ¨uberlegen und bieten meist eine Transaktionsverwal-
tung. Weiterhin skalieren Datenbanken sehr gut mit wachsenden Anforderungen, da Sie auf
extra Rechner verlagert und geclustert werden k¨onnen.
Aus diesem Grund, wird sich f¨ur eine relationale Datenbank als Speicherl¨osung entschieden,
genauer MySQL mit der Speicher Engine: InnoDB2
. Die Wahl fiel hierbei auf die InnoDB, da
sie im Gegensatz zu MyISAM Transaktionen unterst¨utzt.
4.2.2 Parameterdaten f¨ur automatische Handelssysteme
Die automatischen Handelssysteme haben eine unterschiedliche Anzahl von Einstellungspara-
metern, mit einem vorgegeben Satz von unterschiedlichen Basis-Datentypen. Diese Parameter
werden im Diagramm C.8 als payload bezeichnet.
Das Problem ist hier, dass sich eine von System zu System unterschiedliche Anzahl der
Einstellungsparameter mit jeweils unterschiedlichen Datentypen nicht so einfach in einer rela-
tionalen Datenbank abbilden l¨asst. Eine M¨oglichkeit w¨are das Umwandeln der Parameter-Daten
in einen String, wobei die einzelnen Parameter durch einen Delimeter getrennt sind. Eine weitere
M¨oglichkeit w¨are das Umwandeln in Bin¨ardaten und das Abspeichern als BLOB3
.
Da diese Daten dann Key-Value-Paare darstellen, k¨onnte auch das Verwenden darauf spezial-
isierter Key-Value- oder auch NoSQL-DB genannten Datenbanken, wie z.B. BerkleyDB, Mon-
goDB oder CouchDB, in Betracht gezogen werden. Bei der geringen Anzahl von Datens¨atzen
w¨urde sich eine Datenbank nur f¨ur die Parameter-Daten der Handelssysteme allerdings nicht
lohnen.
Es wurde sich schliesslich f¨ur das Speichern als serialisierte Objekte entschieden, da keine
besonderen Anforderungen vorliegen, die den Einsatz von anderen Speicherformen rechtfertigen
w¨urden.
4.2.3 Tick- und Bardaten
Wie bereits beschrieben, werden die f¨ur Bars4
ben¨otigten Preise: Open, High, Low und Close
aus der Analyse von Rohdaten, den Tick-Daten, gewonnen. Diese Daten werden von den au-
tomatischen Handelssystemen und den Indikatoren ben¨otigt.
Eine Besonderheit ist, dass z.B. Indikatoren immer Zugriff auf die aktuellen und die his-
torischen Daten f¨ur einen bestimmten Zeitraum ben¨otigen. So braucht ein 200er Moving Aver-
age auf Tagesbasis immer Zugriff auf die letzten 199 Tagesbars und auf den aktuellen Tagesbar,
2siehe [MySb]
3BLOB (binary large object) ist ein MySQL-Datentyp zum Abspeichern von Bin¨ardaten, siehe [MySa].
4Anstatt Candlestick wird ab jetzt der Begriff Bar verwendet. Beide stellen Container f¨ur die Preise: Open,
High, Low und Close dar und k¨onnen deshalb in diesem Kontext synonym verwendet werden.

41. KAPITEL 4. ENTWURF 33
um den aktuellen Moving Average zu berechnen. Um ad hoc die Moving Average Werte f¨ur
die letzten 4 Bars zu berechnen, m¨ussten also die Tickdaten der letzten 204 Tage ausgewertet
werden.
Nun ist es kein Problem die Tick-Daten in einer relationalen Datenbank zu speichern. Da-
raus dann mit Hilfe von SQL-Abfragen die Bars zu extrahieren, w¨are allerdings eine denkbar
langsame L¨osung, bei ca. 100.000 Ticks pro Tag, pro W¨ahrungspaar.
Eine einfachere und effizientere L¨osung ist das Berechnen der Bars anhand der laufenden
Tickdaten. Dabei wird, um bei den Tagesbars zu bleiben, f¨ur jeden Tag um 0 Uhr ein neuer
Bar erstellt und der alte Bar gespeichert. Der neue Bar speichert bei Er¨offnung den aktuellen
Marktpreis als Open-, High-, Low- und Close-Preis. Bei jedem Tick wird der Close-Preis gesetzt
und gepr¨uft ob ggf. auch High und Low neu gesetzt werden m¨ussen. Da diese Operationen im
Arbeitsspeicher ablaufen, sind Sie sehr schnell, auch der Speicherverbrauch ist sehr gering. Das
wird f¨ur alle geforderten Zeitebenen und W¨ahrungspaare gemacht. Diese Bar-Daten k¨onnten in
einer Datenbank gespeichert werden.
Alternativ k¨onnten Tickdaten in Dateiform gespeichert und verschiedene L¨osungen, wie
z.B. Apache Hadoop (Eine Implementierung, des von Google ver¨offentlichten Map-Reduce-
Verfahrens), der Rapidminer von Rapid-I oder die Programmiersprache R verwendet werden
(siehe [Apab], [Whi10], [Rap] und [R F]). Diese sind f¨ur die Analyse großer Datenmengen
optimiert. Aus Zeitgr¨unden konnten sie jedoch nicht mehr evaluiert werden.
Aus Performancegr¨unden wird deshalb eine Speicherl¨osung auf Dateibasis einer Datenbank-
l¨osung vorgezogen. Dazu wird f¨ur jedes W¨ahrungspaar ein Ordner angelegt und darin f¨ur jede
Zeitebene eine Datei angelegt. In der Datei werden die Bar-Daten, nach Datum sortiert, in Form
von Bin¨ardaten gespeichert. (Mit dieser L¨osung kann auf Indizes verzichtet werden, außer-
dem belegen Bin¨ardateien weniger Speicherplatz als Textdateien.) Als Zugriffsmethode wird
die NIO-API gew¨ahlt, da diese performanter als die IO-API ist. Beide sind Java-APIs zum
Lesen/Schreiben von Daten aus/in Dateien oder Sockets, wobei NIO erst seit dem JDK 1.4
eingesetzt werden kann und unter anderem Locking (Sperrt den Zugriff auf eine Datei durch
andere Prozesse) unterst¨utzt. Durch Locking-Mechanismen muss die Integrit¨at und Konsistenz
der Daten sichergestellt werden.
4.3 Kommunikationsprotokoll
Als Mittel f¨ur die Kommunikation zwischen Client und Server wurde sich f¨ur ein asynchrones
Kommunikationsprotokoll entschieden. Diese beruhen auf dem Versenden von Nachrichten und
eignen sich insbesondere f¨ur Ereignis gesteuerte Systeme und f¨ur l¨anger laufende Operatio-
nen, wenn die zu ¨ubertragenden Daten nicht sehr groß sind. Außerdem l¨asst sich synchrone
Kommunikation - also der Aufruf von entfernten Methoden - mit tempor¨aren Warteschlangen
simulieren.

42. KAPITEL 4. ENTWURF 34
Als Framework wurde sich f¨ur den Java Messaging Service5
(JMS) entschieden. JMS seria-
lisiert die Nachrichten, im Gegensatz zu XML-Protokollen wie dem synchronen SOAP, die vom
Nachrichten-Broker je nach Anwendungszweck persistiert werden. JMS skaliert sehr gut, ist
clusterf¨ahig und unterst¨utzt Transaktionen. Tritt z.B. beim Abholen einer Nachricht ein Fehler
auf, so bleibt diese beim Message-Broker und kann erneut abgeholt werden.
Als weitere M¨oglichkeiten, wurden Apache MINA und insbesondere das JBoss Netty-Project,
in Verbindung mit Google Protobuf (Serialisiert Daten in einem besonders kompakten Format.),
in Betracht gezogen (siehe [Apac], [JBo] und [Gooa]). Beide werden als hoch performant be-
trachtet. So ergeben sich bei Netty in Verbindung mit Google Protobuf, Nachrichten die einen
geringeren Speicherverbrauch als JMS-Nachrichten haben und schneller serialisiert und deseri-
alisiert werden6
. Aufgrund des hohen Implementierungsaufwands wurde jedoch JMS bevorzugt.
5siehe [Apaa] und [Abt10] Seite 281 ff.
6siehe [eis], ein aufgrund vorhandenem Source-Code nachvollziehbarer Vergleich zwischen Protobuf-, XML-
und Java-Serialisierung

43. Kapitel 5
Implementierung
Die im Rahmen dieser Arbeit erstellte Anwendung ist eine verteilte, komponentenbasierte An-
wendung. Die einzelnen Komponenten sind durch Schnittstellen und den Event-Admin-Service
lose gekoppelt (siehe Komponenten-Diagramm1
, Seite 67). In diesem Kapitel wird die Anwen-
dung und die Implementierung der wichtigsten Komponenten beschrieben.
5.1 Events
Mit Hilfe des Event-Admin-Service werden Ergebnisse von Client-Auftr¨agen und Sta-
tus¨anderungen in Form von Events verteilt. Die Events werden in TradingsystemEvent, Ac-
countEvent und OrderEvent unterschieden und ¨uber unterschiedliche Topics publiziert. Die
jeweiligen Auspr¨agungen wurden in Form von Enumerations abgebildet (siehe Klassendiagramm
C.9, Seite 66).
Die Events werden auf Serverseite publiziert, dabei regeln die Komponenten Event-To-JMS
und JMS-To-Event die ¨Ubermittlung an den Client. Es werden allerdings nur die f¨ur den Client
wichtigen Events ¨ubertragen.
Event-To-JMS registriert sich als Eventhandler und wandelt alle im Event enthaltenen
Objekte in DTOs um, die nur aus Basisdatentypen bestehen. Auf das Serialisieren der ur-
spr¨unglichen Objekte wurde verzichtet2
, um die Kommunikation unabh¨angig von Java zu halten
(Der verwendete JMS-Broker erlaubt auch C++, C#, Ruby, Perl, Python und PHP-Clients).
JMS-To-Event stellt daraus das urspr¨ungliche Event wieder her und publiziert es auf Client-
seite. Dadurch kann das Kommunikationsprotokoll f¨ur das Verteilen von Events jederzeit aus-
getauscht werden.
1Auf die Darstellung des Logging-Dienstes wurde aus Gr¨unden der ¨Ubersichtlichkeit verzichtet, da er von
fast jeder Komponente verwendet wird.
2Das gilt auch f¨ur vom Client ubertragene Order und an den Client ¨ubersandte Tick-Daten

44. KAPITEL 5. IMPLEMENTIERUNG 36
1 HashMap <String , Object > eventProperties = new HashMap <String , Object >();
2 eventProperties .put(APIService.ORDER_EVENT ,OrderEvent. TRADE_CLOSED );
3 eventProperties .put(APIService.SINGLE_ACCOUNT_ID ,accountID );
4 eventProperties .put(APIService.EVENT_DATE , new Date(System. currentTimeMillis ()));
5 Event event = new Event("de/pammtrader/core/api/ single_order /FXCM", eventProperties )
Listing 5.1: Beispiel f¨ur ein Trade-Closed-Event
Das Listing 5.1 zeigt beispielhaft ein Event, das beim Schließen eines Einzeltrades ausgel¨ost
wird. Das Event enth¨alt eine Hashmap und ein Topic. Die Hashmap(Listing 5.1, Zeilen 1-4)
enth¨alt das ausgel¨oste Event und dazu geh¨orige Daten.
In diesem Beispiel wird nur die ID des zum Event geh¨origen Objekts ¨ubermittelt. Bei Events
wo Java-Objekte neu erstellt wurden, ist das komplette Java-Objekt in der Hashmap enthalten,
also bei neuen Trades, Orders und neuen Konten. Anhand des Topics (Listing 5.1, Zeile 5) l¨asst
sich ermitteln, dass es sich bei dem geschlossenen Trade um einen Trade f¨ur ein Einzelkonto
beim Broker FXCM handelt.
5.2 Client
Der Client basiert auf der Eclipse RCP. Er besteht zum einen aus den Komponenten JMS-To-
Event und JSM-To-Tick, die f¨ur die Verteilung von Events und Tick-Daten zust¨andig sind. Zum
anderen aus dem Controller und GUI-Elementen. Die GUI-Elemente implementieren die Inter-
faces IAccountListener und/oder ITickListener und registrieren sich als Dienste (Whiteboard-
Pattern) um ¨uber das Eintreffen von Trade-, Konto- und Tickdaten informiert zu werden. Liegen
neue Daten vor, so greifen sie darauf ¨uber Content-Provider zu.
Der Controller implementiert das Interface IAccountDAO und dient dem Zugriff auf Trade-
und Konto-Daten und dem Absetzen von Auftr¨agen an den Server. In den folgenden Un-
terkapiteln, wird die Benutzeroberfl¨ache des Clients kurz n¨aher erl¨autert.
5.2.1 Login-Ansicht
Abbildung 5.1: FxTrader Client - Login
Nach dem Start der Client-Anwendung ¨offnet sich als erstes das Login-Fenster (siehe Abbil-
dung 5.1). Hier muss die Server-Adresse inklusive des Ports vom JMS-Broker angegeben werden.

45. KAPITEL 5. IMPLEMENTIERUNG 37
Bei einer lokalen Installation w¨are
”
localhost:61616“ ein valider Wert, wenn der Standardport
benutzt wird.
Konnte die Verbindung zum Server hergestellt werden, dann initialisiert die Anwendung
Kontodaten, Tradedaten und Handelssystemdaten. Dazu wird ein RPC simuliert, indem eine
tempor¨are Warteschlange (Queue) erzeugt wird. Im Nachrichten-Header
”
JMSReplyTo“ wird
dieser als Anwort-Queue gesetzt und dem Server bei der Anfrage ¨ubermittelt. Nachdem der
Server geantwortet hat, werden die Daten initialisiert. Dann tr¨agt sich die Anwendung als
Empf¨anger von Tickdaten und Events in die entsprechenden Topics ein, und startet die Haup-
tansicht.
5.2.2 Hauptansicht
Symbolübersicht
Kontenübersicht
Handelssysteme
Tradeübersicht
Abbildung 5.2: FxTrader Client - GUI
Die Benutzerober߬ache (siehe Abbildung 5.2) wurde nach der Workbench-Metapher3
gestal-
tet und ist in Men¨uzeile, Toolbar und Hauptfenster unterteilt. Die in den Usecases definierten
Aktionen k¨onnen entweder ¨uber Kontextmen¨us, Men¨uzeile oder Toolbar ausgel¨ost werden. Diese
Aktionen sind meist nur erlaubt, wenn ein dazu passendes Element ausgew¨ahlt wurde. So muss
z.B. um einen Trade auszul¨osen ein PAMM-Konto ausgew¨ahlt werden. Das Hauptfenster ist un-
terteilt in Symbol¨ubersicht, Konten¨ubersicht, Trade¨ubersicht und einer ¨Ubersicht aller laufend-
en automatischen Handelssysteme.
3siehe [Rei09] Seite 52ff

46. KAPITEL 5. IMPLEMENTIERUNG 38
5.2.2.1 Symbol¨ubersicht
Die Symbol¨ubersicht soll dem Benutzer eine Markt¨ubersicht geben und zeigt alle handelbaren
W¨ahrungspaare, mit aktuellen Bid- und Ask-Preisen. Symbole k¨onnen der Liste hinzugef¨ugt
und aus ihr entfernt werden.
5.2.2.2 Konten¨ubersicht
Die Konten¨ubersicht stellt PAMM-Konten und darin enthaltene Einzelkonten in einer
Baum¨ubersicht dar. Hier k¨onnen PAMM- und Einzelkonten angelegt und gel¨oscht werden.
Außerdem k¨onnen PAMM-Trades ausgel¨ost werden, allerdings nur wenn alle darin enthalte-
nen Einzelkonten online sind. Einzelkonten werden mit einem roten Symbol, wenn sie offline
sind, oder mit einem gr¨unen Symbol, wenn sie online sind, dargestellt.
5.2.2.3 Trade¨ubersicht
In der Trade¨ubersicht werden nach PAMM-Konten getrennt offene und bereits geschlossene
PAMM-Trades angezeigt. Sie wird durch einen Doppelklick auf ein PAMM-Konto in der Kon-
ten¨ubersicht ge¨offnet. Bei offenen Trades k¨onnen nachtr¨aglich Stop- und Limit-Preis gesetzt
bzw. ge¨andert werden. Weiterhin k¨onnen hier Trades geschlossen werden.
5.2.2.4 Automatische Handelssysteme
Hinweise für den Benutzer
Abbildung 5.3: FxTrader Handelssysteme - Eingabe von Parametern
Diese ¨Ubersicht zeigt alle offenen Handelssysteme an, sie k¨onnen hier gestartet und gestoppt
werden. Um ein Handelssystem zu starten, wird ein Wizard (siehe Abbildung 5.3) ge¨offnet.
Auf der ersten Seite wird das Handelssystem ausgew¨ahlt und allgemein g¨ultige Parameter, also
W¨ahrungspaar, Zeitebene und Konto, eingegeben. Die n¨achste Seite wird anhand der vom Han-
delssystem vorgegebenen Parameter erstellt. Es werden automatisch, f¨ur Java-Basisdatentypen
(außer Boolean), Eingabefelder und f¨ur Parameter mit vorgegebenen Auswahlm¨oglichkeiten

47. KAPITEL 5. IMPLEMENTIERUNG 39
(inklusive Boolean) Dropdown-Listen erstellt. Der Wizard ¨uberpr¨uft die Eingaben auf Validi-
t¨at, f¨uhrt die Konvertierung durch und gibt dem Benutzer verschiedene Hilfestellungen in Form
von Popup-Meldungen und Hinweisen im oberen Bereich.
Sind alle Einstellungen valide, dann kann der Wizard abgeschlossen und die Daten an den
Server gesendet werden. Der Server initialisiert und startet dann das Handelssystem.
5.3 Server
Der Server basiert auf OSGi, siehe Komponentendiagramm C.10, Seite 67. Die Server-
Komponenten werden jeweilig in Form von Bundles ausgeliefert, dabei sind Schnittstellen und
Implementierung getrennt. Die Schnittstellen der Server-Komponenten finden sich in Klassendi-
agrammen auf den Seiten 69 und 70, letztere enth¨alt zus¨atzlich die Klassen der Handelssysteme
und Indikatoren. In diesem Kapitel wird auf die Implementierung eingegangen.
Anmerkung: Der im Diagramm C.10 gezeigte JMS-Broker wird in Form eines Bundles aus-
geliefert. Hier wird nur ein Objekt vom Typ
”
org.apache.activemq.broker.BrokerService“ ini-
tialisiert und der Dienst gestartet, auf eine weitere Beschreibung wird deshalb verzichtet.
5.3.1 Broker-APIs
Die APIs der Broker Dukascopy und FXCM wurden implementiert. Sie werden jeweils in einem
OSGi-Bundle ausgeliefert, das aus Bundle-Activator, API-Controller, der Broker-API und einer
Klasse f¨ur ein Einzelkonto dieses Brokers besteht.
Der Bundle-Activator erstellt beim Start des Bundles ServiceTracker f¨ur LogService, Event-
admin und ITickReceiver (siehe Listing 5.2, Zeilen 2-4). API-Controller und Konten greifen ¨uber
entsprechende Methoden auf diese Services zu, um zu loggen und um Events und Tickdaten
zu versenden. Weiterhin initialisiert er den API-Controller und registriert ihn als Dienst unter
dem Interface APIService (siehe Listing 5.2, Zeilen 5-10).
1 ServiceTracker tickListenerTracker = new ServiceTracker
2 (context , ITickReceiver .class.getName (), null );
3 tickListenerTracker .open ();
4 DukascopyAPIService dukascopyApi = new DukascopyAPIService ();
5 Dictionary <String , String > properties = new ...
6 properties.put(APIService.BROKER_API , DukascopyAPIService . SERVICENAME );
7 bundleContext . registerService (APIService.class.getName (), dukascopyApi , properties );
Listing 5.2: Ausschnitt aus Bundle-Activator einer Broker-API
Beim Registrieren wird eine Service-Property ¨ubergeben, die den Namen des Broker enth¨alt,
dadurch lassen sich die Broker-Dienste nach Namen filtern. Der API-Controller fungiert als Fas-
sade, erstellt Einzelkonten und steuert den Zugriff darauf. Er vermittelt durch Transformation
der Daten, zwischen dem eigenen System und dem Broker-System. So versteht z.B. Dukascopy
unter einem Lot nicht 100.000$ sondern 1.000.000$ und bildet ein W¨ahrungspaar ¨uber die eigene
Klasse Instrument ab, was hier entsprechend umgewandelt wird.

48. KAPITEL 5. IMPLEMENTIERUNG 40
Jedes Einzelkonto wird Broker-spezifisch abgebildet, stellt unabh¨angig von anderen Konten
eine Verbindung zum Broker her und bleibt aus Performancegr¨unden immer verbunden. Sie leit-
en die Auftr¨age des API-Controller an den Broker weiter und publizieren ¨uber Events wie, wann
und ob diese Auftr¨age abgewickelt wurden. Außerdem publizieren Sie sofort das ¨Andern von
Konto- und Tradestatus und das aktuelle Kontoguthaben. Das Kontoguthaben wird allerdings
in einem Intervall von 10 Sekunden publiziert. Erst mit dem Publizieren des Kontoguthabens
wird dieses Konto als online betrachtet, um die korrekte Verteilung von PAMM-Trades nach
Kontogr¨osse zu gew¨ahrleisten. Jedes Einzelkonto verarbeitet Auftr¨age ¨uber einen eigenen
”
Sin-
gleThreadExecutor“4
, dadurch wird der API-Controller nicht blockiert.
Jedes Einzelkonto kann weiterhin als Publisher von Tick-Daten fungieren, was im
Komponenten-Diagramm (Seite 67) als Live-Datafeed-Publisher dargestellt wird. Der Publisher
wird durch den PAMM-Controller gew¨ahlt und ver¨offentlicht Tickdaten, an alle Dienste, die
sich unter dem Interface ITicklistener angemeldet haben, nach dem Whiteboard-Pattern. Geht
das Einzelkonto offline, dann findet eine Neuwahl des Publisher durch den PAMM-Controller
statt. Da alle Einzelkonten, egal welcher Broker, als Publisher fungieren k¨onnen, wird die Aus-
fallsicherheit dieses Dienstes erh¨oht.
5.3.2 PAMM-Controller
Der PAMM-Controller implementiert die Interfaces EventHandler, IPAMMAccountController
und IPAMMTradeController und registriert sich als Dienst unter diesen Interfaces. Beim Starten
l¨adt er Trade und Kontodaten vom DAO-Service. Er ist der Mediator zwischen Client-Auftr¨agen
und Broker-API-Controller. Wird z.B. ein PAMM-Trade ausgel¨ost, dann splittet er diesen in
Einzeltrades auf und verteilt sie an die entsprechenden Broker-API-Controller. Er verwaltet die
PAMM-Konten, Einzelkonten, PAMM-Trades und Einzeltrades. Er pflegt die jeweilig m¨oglichen
Zust¨ande, also OrderStatus, AccountStatus, Tradestatus, indem er Events auswertet, genauer
AccountEvents und OrderEvents (siehe Klassendiagramm, Seite 66).
Der PAMM-Controller erstellt einen ServiceTracker um das Registrieren und Deregistrieren
von Broker-API-Controllern zu ¨uberwachen. Geht ein solcher Controller online, dann initialisert
er diesen mit Konto- und Trade-Daten. Geht ein Controller offline, dann setzt er bei allen
dazugeh¨origen Einzelkonten den Status auf offline.
In dem Aktivit¨atsdiagramm (Abbildung C.11, Seite 68) wird exemplarisch das Verarbeiten
eines neuen PAMM-Trades5
dargestellt. Hier werden die einzelnen Vorg¨ange bei der Verar-
beitung und das Ausl¨osen von Events gezeigt, aus Platzgr¨unden musste auf das Darstellen der
Bearbeitung von Events verzichtet werden.
4siehe [Oraa]
5Unter der Vorbedingung, dass der Trade die in Tabelle 2.1 auf Seite 9 dargestellten Bedingungen erf¨ullt

49. KAPITEL 5. IMPLEMENTIERUNG 41
5.3.3 Account-, Trade-DAO-Service
Wird ein neuer Trade oder ein neues Konto erstellt, so wird das dazugeh¨orige Java-Objekt ¨uber
ein entsprechendes Event verteilt. Der DAO-Service registriert sich als Eventhandler und nimmt
selbst¨andig das Speichern dieser Objekte vor, weiterhin verarbeitet er ¨Anderungen von Trade-
und Kontozust¨anden und speichert sie ab.
Die Verbindung zum SQL-Server wird ¨uber einen Connectionpool6
hergestellt. Dieser h¨alt
immer eine einstellbare Anzahl von Verbindungen offen und ¨offnet bei Bedarf weitere Verbin-
dungen bzw. schließt diese wieder bei Nichtbenutzung. Dadurch muss nicht f¨ur jeden SQL-Befehl
eine Verbindung aufgebaut werden, was relative lange dauern kann und die Performance be-
eintr¨achtigen w¨urde. SQL-Befehle werden in Rahmen von Transaktionen, um Integrit¨at und
Konsistenz der Daten sicherzustellen abgesetzt. Dazu werden Prepared Statements benutzt,
um die Performance zu erh¨ohen.
5.3.4 History-Provider
1 FileChannel output = new RandomAccessFile (getFilename (bar), "rw"). getChannel ();
2 long start = output.size()- BAR_SIZE_IN_BYTES ;
3 FileLock lock = output.lock(start ,BAR_SIZE_IN_BYTES , false );
4 ByteBuffer mapByteBuffer = output.map(FileChannel.MapMode.READ_WRITE , start , BAR_SIZE_IN_BYTES );
5 mapByteBuffer .putLong(bar.getOpenDate (). getTime ());
6 ...
7 mapByteBuffer .flip ();
8 output.position(output.size()- BAR_SIZE_IN_BYTES );
9 output.write( mapByteBuffer );
10 output.close ();
Listing 5.3: Updaten eines Bars mit der NIO-API
Der History-Provider ist ein Dienst zum Bereitstellen von historischen Preisdaten, f¨ur die in
den Anforderungen genannten W¨ahrungspaare und Zeitebenen. Er implementiert die Interfaces
IBarProvider und ITickReceiver.
Der History-Provider baut die History-Daten anhand der Tickdaten auf, wie im vorherigen
Kapitel beschrieben. Der letzte Bar befindet sich immer im Arbeitsspeicher und wird durch
die Tickdaten aktualisiert, dabei wird alle 10 Sekunden ein Backup durchgef¨uhrt. Wird der
aktuelle Bar von anderen Komponenten ben¨otigt, so wird eine Kopie dieses Bar als Antwort
¨ubermittelt, w¨ahrend History-Daten aus der Datei geladen werden.
Das Listing 5.3 zeigt exemplarisch das Updaten des letzten Bars, der sich immer am Ende
der Datei befindet. Im Unterschied zur IO-API, erfolgt der Zugriff auf Dateien ¨uber Channels.
Ein Bar belegt 48 Bytes, also werden die letzten 48 Bytes zum exklusiven Schreiben/Lesen
geblockt. Der Bar wird dann in Form von Bytes in einen Buffer geschrieben. Zum Schluss
wird die Position des Buffers auf 0 zur¨uckgesetzt und der Buffer in die Datei geschrieben.
6siehe [Comb] und [Coma]

50. KAPITEL 5. IMPLEMENTIERUNG 42
Durch das Schließen des Channels wird die Datei wieder freigegeben. Durch das Locking von
Dateiabschnitten ist es m¨oglich, gleichzeitig in die Datei zu schreiben und daraus zu lesen, ohne
dass sich diese Prozesse behindern.
5.3.5 Indikatoren
Indikatoren (siehe Seite 70) erweitern die abstrakte Klasse Indicator und werden zusammen in
einem Bundle ausgeliefert. Um neue Indikatoren zu installieren, muss dieses Bundle geupdatet
werden. Indikatoren k¨onnen nur ¨uber statische Methoden der Klasse Indicators bezogen werden.
Die Klasse Indicator implementiert das Interface ITickReceiver und ruft bei jedem neuen
Tick die abstrakte Methode
”
calculateIndicator“ auf. Hier findet dann die Berechnung des
aktuellen Indikatorwertes statt. Wird ein Indikator gestartet, so bezieht er History-Daten vom
IBarProvider und beginnt mit der Berechnung der Indikatorenwerte. F¨ur die Berechnung werden
die ben¨otigten Bardaten im Arbeitsspeicher gehalten und mit Hilfe der Tickdaten selbst¨andig
gepflegt, was auch in der Klasse Indicator geregelt ist.
5.3.6 Handelssysteme
Handelssysteme k¨onnen eine Vielzahl von Einstellungs-Parametern haben. F¨ur die Parameter
und das Handelssystem wurden Java-Annotationen definiert. Die Methoden zum Setzen dieser
Parameter und die Klasse des Handelssystems m¨ussen durch Java-Annotationen gekennzeichnet
werden. In der Annotation werden die zur Beschreibung des Parameters ben¨otigten Werte und
etwaige Standardwerte festgelegt (siehe Listing 5.4). In der Annotation der Klasse wird der
Name und die Beschreibung des Handelssystem festgelegt.
1 @Retention( RetentionPolicy .RUNTIME ) @Target( value=METHOD )
2 public @interface ITradingSystemInputParam {
3 String InputParametername ();
4 String InputDescription () default "";
5 String [] AllowedStringValues () default {""};
6 int MinValue () default Integer.MIN_VALUE;
7 int MaxValue () default Integer.MAX_VALUE; }
Listing 5.4: Annotation f¨ur eine Methode
Handelssysteme (siehe Seite 70) k¨onnen in unterschiedlichen Bundles ausgeliefert werden, die
ein oder mehrere Handelssysteme und eine Factory enthalten. Handelssysteme implementieren
das Interface ITradingsystem und werden durch die Factory erzeugt, die das Interface ITrad-
ingSystemFactory implementiert und sich als Service registriert.
Die Factory analysiert beim Starten des Bundles die darin enthaltenen Java-Klassen und
generiert daraus die TradingSystemDescription. Zum Analysieren wird die Java-Reflection-Api
benutzt. Listing 5.5 zeigt ausschnittsweise wie alle Methoden der Klasse untersucht werden
und daraus die Systembeschreibung generiert wird. Diese L¨osung hat den Vorteil, dass jed-

51. KAPITEL 5. IMPLEMENTIERUNG 43
erzeit neue Handelssysteme zu einem Bundle hinzugef¨ugt werden k¨onnen, ohne dass weitere
Konfigurationen notwendig sind.
1 Class <?> clazz = bundle.loadClass( fullClassName ); ...
2 Method [] methods = clazz.getMethods ();
3 for(Method method : methods)
4 {
5 if(method. isAnnotationPresent ( ITradingSystemInputParam .class ))
6 {
7 ITradingSystemInputParam methodAnnotation = method. getAnnotation
8 ( ITradingSystemInputParam .class );
9 TradingSystemParameterDescription param = new TradingSystemParameterDescription
10 (method.getName (), inputType , methodAnnotation . InputParametername (),
11 methodAnnotation . InputDescription ());
12 ...
Listing 5.5: Annotation f¨ur eine Methode
Der TradingSystemController implementiert das Interface ITradingSystemController und
¨uberwacht sich an-/abmeldende ITradingSystemFactories, um die Beschreibung zu laden und
systemweit zu publizieren. Mit Hilfe dieser Beschreibung kann dann auf Clientseite der Wizard
generiert werden. Der TradingSystemController initialisiert, startet und stoppt die Handelssys-
teme. Beim Starten des Handelssystems ¨ubergibt er den ITradingSystemContext, ¨uber den das
Handelssystem auf PAMM-Konto und History-Daten zugreift.
5.3.6.1 Installieren von Handelssystemen
Bundles k¨onnen ¨uber die OSGi-Konsole installiert werden. Diese Bundles k¨onnen auf der Fest-
platte des Rechners oder z.B. auf einem Webserver liegen. Das Listing 5.6 zeigt das Installieren
und Starten eines Handelssystems, dessen JAR-Datei sich auf der lokalen Festplatte befindet.
1 osgi > install file:c: Pfad_zur_Datei de. tradingSystem .jar
2 Bundle id is 38
3 osgi > start 38
4 Starting de. tradingSystem
Listing 5.6: Handelssysteme installieren
5.3.6.2 Beispiel f¨ur ein Handelssystem
Zum Abschluss zeigt das Listing 5.7 einen Ausschnitt aus einem Handelssystem. Bei jedem Tick
pr¨uft das System, ob sich schneller und langsamer Moving Average gekreuzt haben und er¨ofnet
gegebenenfalls eine neue Position.

52. KAPITEL 5. IMPLEMENTIERUNG 44
1 MovingAverage slowAVG = Indicators. MovingAverage (Timeframe.D1 , Symbol.EURUSD ,
2 200, "SMA", 2);
3 MovingAverage fastAVG = Indicators. MovingAverage (Timeframe.D1 , Symbol.EURUSD ,
4 50, "SMA", 2);
5 public void onUpdate(Tick tick)
6 {
7 List <PAMMTrade > tradeList = context. getOpenTrades (Symbol.EURUSD );
8 if(tradeList != null && tradeList.size ()==0)
9 {
10 if(fastAVG.getValue (1)< slowAVG.getValue (1) &&
11 fastAVG.getValue (2)> slowAVG.getValue (2))
12 {
13 Bar actualBar = context.getBar(Symbol.EURUSD , Timeframe.D1);
14 double closePrice = actualBar.getClose ();
15
16 context.openTrade(magicNumber , TradeType.SELL , Symbol.EURUSD ,
17 1, closePrice -0.01 , closePrice +0.01 , closePrice );
18 } ...
Listing 5.7: Beispiel f¨ur ein Handelssystem