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

ENTWICKLUNG EINES FRAMEWORKS ZUM

AUTOMATISIERTEN HANDEL

EINES MULTI-BROKER-PAMM-ACCOUNTS

Abschlussarbeit

zur Erlangung des akademischen Grades

Bachelor of Science (B.Sc.)

an der

Hochschule fur Technik und Wirtschaft Berlin

Fachbereich Wirtschaftswissenschaften II

Studiengang Angewandte Informatik

1. Prufer: Prof. Dr.-Ing. Thomas Schwotzer

2. Prufer: Prof. Dr.-Ing. Ruger Oßwald

Eingereicht von

Sascha Jonas

21. April 2011

© Copyright 2011 Sascha Jonas. Alle Rechte vorbehalten.

iii

Kurzzusammenfassung

In Laufe der letzten Jahren wurde der Handel von Devisen und insbesondere der automatisierte

Handel von Devisen immer interessanter.

Im Rahmen dieser Arbeit werden die Grundlagen des Devisenhandels und die

Anfordererungen an eine Anwendung zum automatisierten Handel von Devisen erarbeitet. Weit-

erhin wird ein Konzept zum gleichzeitigen Handel mehrerer Konten vorgestellt. Basierend auf

diesen Erkenntnissen wird eine prototypische Anwendung konzipiert und realisiert.

Stichworte: Automatische Handelssysteme, Devisenhandel, Forex, PAMM-Konto

Inhaltsverzeichnis

Abbildungsverzeichnis vi

1 Einleitung 1

1.1 Abriss uber die historische Entwicklung des Devisenmarkts . . . . . . . . . . . . 1

1.2 Der Devisenmarkt heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 PAMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Grundlagen 5

2.1 Grundlagen des Devisenhandels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Modularisierung in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Die OSGi Service Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Eclipse RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Anforderungsanalyse 21

3.1 Marktubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Entwurf 29

4.1 System-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Implementierung 35

5.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Software-Test 45

6.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2 GUI-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

INHALTSVERZEICHNIS vi

6.4 Ergebniss von GUI- und Funktionstests . . . . . . . . . . . . . . . . . . . . . . . 47

6.5 Skalierbarkeits-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Fazit 49

7.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2 Ruckblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Literaturverzeichnis 50

A Glossar 55

B JFace Data Binding 57

C Abbildungen 59

D Tabellen 71

E Installationsanleitung 75

F Eigenstandigkeitserklarung 77

Abbildungsverzeichnis

1.1 Percent Allocation Management Module (PAMM) . . . . . . . . . . . . . . . . . 4

2.1 Candlestick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Candlestick-Chart mit Moving Average und MACD . . . . . . . . . . . . . . . . 7

2.3 Bundle Lebenszyklus (Quelle: [wikc]) . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Event Admin Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Komponenten der Eclipse RCP Plattform. . . . . . . . . . . . . . . . . . . . . . . 17

5.1 FxTrader Client - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 FxTrader Client - GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 FxTrader Handelssysteme - Eingabe von Parametern . . . . . . . . . . . . . . . . 38

C.1 Sequenzdiagramm - Content Provider . . . . . . . . . . . . . . . . . . . . . . . . 59

C.2 Usecase Diagramm - Kontoverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 60

C.3 Usecase Diagramm - Tradeverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 61

C.4 Usecase Diagramm - Handelssysteme . . . . . . . . . . . . . . . . . . . . . . . . . 62

C.5 Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

C.6 Verteilungsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

C.7 ERM-Diagramm: Datentypen (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . . 64

C.8 ERM-Diagramm: Datentypen (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . . 65

C.9 Klassendiagramm - Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C.10 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

C.11 Aktivitatsdiagramm fur einen PAMM-Trade . . . . . . . . . . . . . . . . . . . . . 68

C.12 Klassendiagramm Server-Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 69

C.13 Klassendiagramm - Indikatoren und Handelssysteme . . . . . . . . . . . . . . . . 70

Kapitel 1

Einleitung

In diesem Kapitel wird auf die historische Entwicklung und die aktuelle Situation des De-

visenmarkts eingegangen. Im Anschluss werden das Percent Allocation Management Module

(PAMM), ein Konzept fur ein Sammelkonto, und das Ziel dieser Arbeit erlautert.

1.1 Abriss uber die historische Entwicklung des Devisen-

markts

Mit dem Bretton-Woods-Abkommen1, das am 22.07.1944 von 44 Staaten in Bretton Woods,

USA beschlossen wurde, sollte das internationale Wahrungssystem neu geordnet werden. Zur

Kontrolle des neuen Wahrungssystems wurden die auch heute noch existierenden Institutio-

nen Weltbank und International Wahrungsfonds (IWF) geschaffen. Im Zentrum des Bretton-

Woods-Abkommens stand der US-Dollar, der als Leitwahrung dienen sollte. Fur die Wahrungen

der teilnehmenden Staaten wurde ein fixes Wechselverhaltnis zum US-Dollar festgelegt. Dieses

Wechselverhaltnis durfte nur 1% um den festgelegten Wert schwanken. Die Zentralbanken der

jeweiligen Lander verpflichteten sich dazu, durch Ihre Geldpolitik und durch Eingriffe am De-

visenmarkt diese fixen Wechselkurse zu halten.

Ein weiterer Bestandteil des Abkommens war die enge Bindung des US-Dollar an Gold. Der

Kurs wurde auf 35 Dollar je Feinunze Gold festgelegt, wobei sich die Federal Reserve Bank of

New York (FED) verpflichtete, den fixen Wechselkurs von US-Dollar in Gold zu gewahrleisten.

Die USA hatte in den 70er Jahren im Zuge des Vietnamkrieges mit großen Staatsdefiziten

zu kampfen, was das Vertrauen in den US-Dollar stark dampfte. Die Olkrise von 1973 fuhrte

schließlich zum endgultigen Zerbrechen des Bretton-Woods-Abkommens.

Seitdem wurde die Bindung von Wahrungen an Gold aufgegeben. Der Wechselkurs der

meisten Wahrungen wird nun durch den Handel an den Devisenmarkten und die Geldpoli-

1vgl. [Och04] 23ff

KAPITEL 1. EINLEITUNG 2

tik der Zentralbanken bestimmt. Eine Ausnahme bildet z.B. der chinesische Yuan, der mit

sehr geringem Spielraum an die Entwicklung des US-Dollar gekoppelt ist und nicht an den

Devisenmarkten gehandelt wird.


1.2 Der Devisenmarkt heute

Der Devisenmarkt, oder auch Forex -Markt2, ist der globale Markt, auf dem Wahrungen gehan-

delt werden. Er ist an keinen festen Borsenplatz gebunden, da er außerborslich3 durch den

Interbankenmarkt gebildet wird und ist aufgrund der unterschiedlichen Zeitzonen 24 Stunden

am Tag und 5 Tage in der Woche offen.

Der Devisenmarkt ist der großte Finanzmarkt der Welt, mit einem durchschnittlichen Ta-

gesumsatz von 4.000 Milliarden US-Dollar [Mon]. Der Devisenkurs wird immer als Wechselkurs

zwischen zwei unterschiedlichen Wahrungen angegeben und so besteht ein Devisengeschaft auch

immer aus dem gleichzeitigen Kauf und Verkauf von unterschiedlichen Wahrungen. Wurde man

zum Beispiel auf eine positive Entwicklung des Euro gegenuber dem US-Dollar setzen und eine

sogenannte Long-Position im EUR/USD eroffnen, dann wurde man gleichzeitig Euro kaufen

und US-Dollar verkaufen.

Der Devisenmarkt wird durch den Handel verschiedener Akteure mit sehr unterschiedlichen

Zielen bestimmt. International agierende Unternehmen, wie z.B. IBM oder Porsche, unterhal-

ten eine eigene Forex-Abteilung, um sich gegen Wahrungsrisiken abzusichern. Zentralbanken

agieren um nationale Interessen zu sichern und Investoren spekulieren um Renditeziele zu er-

reichen.

Seit kurzem ist es auch Privatanlegern moglich, am Devisenhandel teilzunehmen, da Broker4

durch sogenanntes Leverage die Mindesteinlage (fur ein Minimum-Lot) stark verringert haben.

Die Positionsgroßen fur ein Devisengeschaft waren fruher ein Vielfaches von einem Lot. Unter

einem Lot werden meist 100.000$ verstanden.

Seit einiger Zeit ist uber Broker aber auch der Handel von Mini-Lot, also einem Vielfachen

von 0.1 Lot, und Micro-Lot, einem Vielfachen von 0.01 Lot, moglich. Die Hohe des Leverage,

auch Hebel genannt, sagt aus wie viel Margin auf einem Konto fur ein Devisengeschaft hinterlegt

sein muss. Bei einem Leverage von 1:100 und einer Positionsgroße von 1 Lot mussten 1.000$

statt 100.000$ als Margin hinterlegt sein.

Niedrige Margin-Anforderungen, hohe Volalitat und die Moglichkeit Kauf-(Long) und

Verkaufspositionen (Short) zu eroffnen, machen diesen Markt so interessant.

2Forex-Markt steht fur Foreign Exchange Market

3“over the counter”

- OTC

4Broker unterhalten Geschaftsbeziehungen zu Großbanken, oder sind selber eine Großbank (z.B. DeutscheBank, einer der großten Forex-Broker), und treten als Vermittler zwischen Kunden und Interbankenmarkt auf.


1.3 PAMM

Vermogensverwalter und Devisenhandler verwalten eine Vielzahl von Kundenkonten. Um ein

Devisengeschaft (Trade) nun nicht fur jedes verwaltetete Konto von Hand ausfuhren zu mussen,

wurde das Percent Allocation Management Module (PAMM) entwickelt.

Kaufe1 LotEUR/USD

PAMM-Technologie

Portfolioanteilin %

angepasste Positionsgröße

Einzelkonten

200.000 $

300.000 $

500.000 $

20%

30%

50%

0.2 Lot

0.3 Lot

0.5 Lot

Abbildung 1.1: Percent Allocation Management Module (PAMM)

Wie die Abbildung 1.1 zeigt, wird mittels PAMM eine Transaktion auf alle verwalteten

Konten, abhangig von deren Anteil am Gesamtvermogen, automatisch aufgeteilt. Dabei wird

selbstverstandlich auch berucksichtigt, dass die Kundenkonten in unterschiedlichen Wahrun-

gen vorliegen konnen. Dazu wird der aktuelle Wechselkurs zum US-Dollar ermittelt und eine

Umrechnung von Fremdwahrungskonten in US-Dollar-Konten vorgenommen.

Diese Technologie wird inzwischen von vielen Brokern bereitgestellt. Jedoch gibt es zur

Zeit keine Moglichkeit, Konten von unterschiedlichen Brokern zu einem PAMM-Konto zusam-

menzufassen. Ein Grund fur die Verteilung von Kundengeldern auf mehrere Broker konnte die

Risikoabsicherung sein. So sind zum Beispiel Einlagen bei in Großbritannien residierenden Bro-

ker mit bis zu 50.000 GBP (ca. 60.000 Euro) versichert und bei in der Schweiz residierenden

Broker mit bis zu 100.000 CHF (ca. 80.000 Euro).

1.4 Zielsetzung

Ziel dieser Arbeit ist es, ein Framework zu entwickeln, das die APIs ausgewahlter Broker kapselt,

um Konten dieser Broker zu einem PAMM-Account zusammenzufassen.

Das Framework soll modular aufgebaut und leicht um weitere APIs erweiterbar sein. Außer-

dem soll es wohlgeformte Schnittstellen zur Verfugung stellen, um einen oder mehrere PAMM-

Accounts zu verwalten und den Handel von Devisen durchzufuhren.

Aufbauend auf diesem Framework wird eine prototypische Anwendung entwickelt, die es

ermoglicht, automatisierte Handelssysteme zu erstellen, und mit diesen den PAMM-Account zu

handeln.

Kapitel 2

Grundlagen

Dieses Kapitel beschreibt im ersten Teil die fachlichen Grundlagen fur den automatisierten

und computergestutzten Handel von Devisen. Aufgrund der formulierten Zielsetzung, dass die

Software leicht um weitere Broker-API‘s, Indikatoren und automatische Handelssysteme erwei-

terbar sein muss, wurde die OSGi Service Plattform die Grundlage fur den Server gewahlt. Um

die Vorteile von OSGi auch auf Clientseite nutzen zu konnen, hat sich der Autor fur die Eclipse

Rich Client Platform (RCP) entschieden. Beide Technologien werden im zweiten Teil dieses

Kapitels untersucht.

2.1 Grundlagen des Devisenhandels

Im Devisenhandel wird zwischen der fundamentalen und der technischen Analyse unterschieden.

In der fundamentalen Analyse werden Handelsentscheidungen anhand von Fundamentaldaten

wie z.B. dem Preisindex fur die Lebenshaltung (CPI) oder dem Bruttoinlandsprodukt getroffen.

Der technische Analyst hingegen trifft seine Handelsentscheidungen anhand von aktuellen

und vergangenen Wechselkursen, in der Annahme, dass fundamentale Daten bereits eingepreist

seien, und benutzt dafur Charts, Chart-Pattern1 und Indikatoren.

Zum Handel von Devisen konnen beide Analyseformen kombiniert werden, im Rahmen dieser

Arbeit erstellte Handelssysteme werden sich jedoch auf die technische Analyse beschranken.

2.1.1 Bildung eines Candlestick Charts

Zu den verbreiteten Chartformen gehort der Candlestickchart. Zur Bildung eines Candlesticks

(siehe Abbildung 2.1) werden die in einem bestimmten Zeitraum aufgetretenen Ticks analysiert.

Der Candlestick bildet dann nur das Maxima (High), das Minima (Low), den Preis zu Beginn

(Open) und den Preis zum Ende (Close) dieses Zeitraums ab. Diese vier Preisdaten und die

1siehe [Wikb] und [Wika]

KAPITEL 2. GRUNDLAGEN 6

High

Low

Open

Close

Abbildung 2.1: Candlestick

Anzahl der in diesem Zeitraum gehandelten Lots (Volumen) werden alle oder teilweise, das

hangt von der Art des Indikators ab, von Indikatoren zur Berechnung benotigt.

Weitere Chartformen sind der Balkenchart und der Linienchart. Der Balkenchart stellt wie

der Candlestickchart(siehe Abbildung 2.2): Open, High, Low und Close, nur in einer anderen

Form, dar, wahrend der Linienchart nur die Close-Preise durch Linien miteinander verbindet.

Im Devisenhandel haben sich verschiedene Zeitebenen etabliert auf deren Basis gehandelt

wird. Die gangigsten Zeitebenen sind 1 Minute, 5 Minuten, 15 Minuten, 30 Minuten, 1 Stunde,

4 Stunden, 1 Tag, 5 Tage und 1 Monat, wobei Wochenenden nicht berucksichtigt werden.

2.1.2 Tickdaten

Durch den regen Handel an den Devisenmarkten konnen sich Wechselkurse in volatilen Markten

mehrmals in der Sekunde andern. Diese Preisanderungen werden als Ticks bezeichnet. Ein Tick

gibt also immer den Wechselkurs einer bestimmten Wahrung zu einer bestimmten Zeit an.

Bei Wechselkursen wird zwischen Bid - und Ask -Preisen unterschieden. Eroffnet man eine

Long-Position (Buy), dann wird diese Position zum Ask-Preis eroffnet. Schließt man diese Po-

sition oder eroffnet eine Short-Position (Sell), so geschieht dies zum Bid-Preis. Zwischen Ask-

und Bid-Preis liegt immer eine Differenz, die je nach Marktsituation, Wahrung und Broker

unterschiedlich sein kann. Diese Differenz wird Spread genannt und ist die Gebuhr, die Broker

fur ihre Dienste verlangen. Der Spread liegt bei den Hauptwahrungen, auch Majors genannt,

meist zwischen einem und vier Pips.

Ein Tick besteht also genaugenommen aus zwei Preisen, dem Bid- und dem Ask-Preis. Fur

Indikatoren und Charts werden meist Bid-Preise verwendet, da diese bei Ask-Preisen durch

marktabhangige Spreads verfalscht wurden.

2.1.3 Indikatoren

Indikatoren sind Werkzeuge zur statistischen Analyse von Borsendaten. Indikatoren konnen un-

terteilt werden in trendfolgende Indikatoren, Oszillatoren und sonstige Indikatoren. Indikatoren

werden, fur den aktuellen Candlestick, bei jedem Tick neu berechnet. Fur die Analyse werden

jedoch nur Indikatorenwerte von bereits abgeschlossenen Candlesticks verwendet.


12 EMA

26 EMA

Signallinie

Mittellinie

MACD

1

Abbildung 2.2: Candlestick-Chart mit Moving Average und MACD

Der gleitende Durchschnitt [eSib] (Moving Average) gehort zu den trendfolgenden Indika-

toren:”Es ist seine Aufgabe, zu signalisieren, dass ein neuer Trend begonnen hat oder dass

ein alter Trend geendet oder sich umgekehrt hat.“2. Der Moving Average wird meist mit den

Close-Preisen gebildet, kann unter anderem aber auch vom Mittelwert ((Low+High)/2) gebildet

werden.

Moving Averages werden in gewichtet und ungewichtet unterschieden. Beim simplen Moving

Average (SMA), wird jeder Preis gleich gewichtet, sodass sich folgende Formel ergibt:

SMA0 = 1M

M∑n=0

Preisn,

wobei M die Periode des Moving Average und damit die Anzahl der zur Berechnung einbezoge-

nen Candlesticks darstellt. Die Variable n steht fur den Candlestick, dessen Preis zur Berechnung

genommen wird3. Zu den gewichteten gleitenden Durchschnitten gehort zum Beispiel der expo-

nentiell geglattete Moving Average (EMA), bei dem Kurse der jungsten Vergangenheit starker

gewichtet sind als altere Kurse. Dazu wird der Faktor α verwendet, mit α = 2M+1 , wodurch

sich die folgende Formel ergibt:

EMA0 = (Preis0 · α) + (SMA1 · (1− α)),

2siehe [Mur06] S. 203ff

3n=0 ist der aktuelle Candlestick (dessen Preis sich bei jedem Tick andert), n=1 der letzte Candlestick, n=2der vorletzte Candlestick usw.


Moving Averages glatten das”Rauschen“ des Marktes, sie erleichtern das Erkennen von

Trends und werden oftmals zum Glatten der Werte anderer Indikatoren benutzt.

Moving Averages konnen so interpretiert werden, dass es sich um einen Aufwartstrend

handelt, wenn sich die Candlesticks uber dem Moving Average befinden und ansonsten um

einen Abwartstrend. Ein Uber- bzw. Unterschreiten des Moving Average, wurde dann einen

Trendwechsel signalisieren. Eine weitere Moglichkeit ist es, zwei Moving Averages, einen

langsamen und einen schnellen, zu verwenden. Befindet sich der schnelle Moving Average (12er

EMA) uber dem langsamen (26er EMA), dann handelt es sich um einen Aufwartstrend und

ansonsten um einen Abwartstrend (siehe Abbildung 2.2). Das kreuzen der beiden Moving Av-

erages zeigt den Trendwechsel an (siehe den mit 1 markierten Kreis in Abbildung 2.2).

Oszillatoren sind Indikatoren, deren Werte entweder um die Mittellinie oder zwischen fest-

gelegten Werten, meist zwischen 0 und 100, schwanken. Der Moving Average Convergence

Divergence Indikator [eSia] (MACD) gehort zu der Gruppe der Oszillatoren und berechnet

den Abstand zwischen zwei Moving Averages (meist 12er und 26er EMA) und eine Signallinie

(meist 9er EMA). Ein steigender MACD, uber der Mittellinie, wird als Aufwartstrend und ein

fallender MACD, unter der Mittellinie, wird als Abwartstrend interpretiert. Als Trendwechsel

werden das Kreuzen der Mittel- oder Signallinie und Divergenzen4 gedeutet.

Zum Abschluss sei erwahnt, dass Indikatoren nur Hinweise auf mogliche Ereignisse geben

konnen. Da es sich um statistische Analysen handelt, treffen von Indikatoren signalisierte

Ereignisse nur mit einer gewissen Wahrscheinlichkeit ein. Bei den oben erwahnten Indikatoren

handelt es sich weiterhin um Indikatoren, die dem Markt”hinterherlaufen“, das heisst, dass

eine Marktbewegung auch bereits abgeschlossen sein kann und ein Neueinstieg in den Markt

nicht mehr profitabel ist.

2.1.4 Ordertypen

Ein einzelner Handel von Devisen wird als Order oder Trade bezeichnet. Es wird zwischen

Market Order und Pending Order unterschieden. Eine Market Order wird sofort und zum ak-

tuellen Marktpreis (Market Entry) ausgefuhrt. Eine Pending Order kann nur unter bestimmten

Voraussetzungen angelegt werden und wird zu einem vorher festgelegten Kurs (Pending Entry)

ausgefuhrt.

Market Orders werden verwendet, wenn der Zeitpunkt fur die Eroffnung eines Trades

wichtiger ist, als der Preis zu dem er eroffnet wird. Bei Pending Orders ist der Zeitpunkt,

wann der Trade eroffnet wird, nicht so wichtig. Dieser Ordertyp wird z.B. bei dem Handel von

Ausbruchen aus Seitwartsmarkten oder bei wichtigen Nachrichten verwendet. Hier werden dann

Kauf- und Verkausorder uber bzw. unter der bisherigen Range platziert und der Trader lasst

sich dann”einstoppen“:

4Beispiel: In der Abbildung 2.2 ist der MACD-Wert vom November 2007 geringer als der MACD-Wert vomDezember 2004, wahrend der Close-Preis vom Dezember 2004 geringer als der vom November 2007 ist. Chartbildund Indikatorbild unterscheiden sich, was als Divergenz bezeichnet wird.


Ordertyp Entry-Preis Stop-Preis Limit-Preis

Buy (Market Entry) Ask <Bid >AskBuy Limit (Pending Entry) <Ask <Pending Entry >Pending EntryBuy Stop (Pending Entry) >Ask <Pending Entry >Pending Entry

Sell (Market Entry) Bid >Ask <BidSell Limit (Pending Entry) >Bid >Pending Entry <Pending EntrySell Stop (Pending Entry) <Bid >Pending Entry <Pending Entry

Tabelle 2.1: Ordertypen und Voraussetzungen

Fur beide Ordertypen konnen ein Stop, dient der automatischen Verlustbegrenzung, und ein

Limit, dient der automatischen Gewinnmitnahme, gesetzt werden. Beispiel: Soll eine Kauforder

ausgefuhrt werden, so geschieht dies zum Ask-Preis, der Stop musste dann unter dem Bid-Preis

und das Limit uber dem Ask-Preis liegen. Erreicht der Marktpreis entweder Stop oder Limit,

wurde die Position automatisch geschlossen werden. Alle Voraussetzungen fur die einzelnen

Ordertypen konnen in der Tabelle 2.1 nachgelesen werden.

Jeder Trade wird als einzelne Position behandelt und ist unabhangig von anderen Trades.

Damit ist es moglich, gleichzeitig Long und Short zu sein, was im Devisenhandel gangige Praxis

ist und wird zum einen zur Risikoabsicherung benutzt. Auf der anderen Seite kann es zum

Beispiel bei Handelssystemen, die auf unterschiedlichen Zeitebenen agieren, zu gleichzeitigen

Long- und Short-Trades kommen.

Eine Ausnahme bilden hier Konten, die bei einem Broker in den USA gefuhrt werden. In

Reaktion auf die Finanzkrise wurde in den USA, durch die National Finance Authority (NFA),

eine andere Regelung eingefuhrt. Aufgrund der NFA Compliance Rule 2-43(b), ist hier nur eine

Position pro Wahrungspaar erlaubt. Die Konsequenz davon ist, dass ein neuer Short-Trade einen

bestehenden Long-Trade ganz oder teilweise schließt. Damit wird aus einer Long-Position mit

1,0 Lot eine Long-Position mit 0,5 Lot, wenn eine Short-Position mit 0,5 Lot eroffnet wurde. Es

ist also innerhalb eines US-Kontos nicht mehr moglich, gleichzeitig Long und Short zu sein. Dies

kann umgangen werden, indem ein Konto fur Long- und ein anderes Konto fur Short-Trades

genutzt wird.

Auch das Setzen von Stop- und Limit-Preis ist - bei US-Brokern - nicht mehr moglich, kann

aber durch das Setzen entsprechender Entry-Orders ersetzt werden. So konnten z.B. fur einen

Long-Trade, eine Sell-Limit- und eine Sell-Stop-Order, anstatt eines Stop- und Limit-Preises,

benutzt werden.

Das bedeutet, dass Konten bei US-Broker und Konten bei Broker außerhalb der USA,

nicht in einem PAMM-Konto gemischt werden konnen. Die im Rahmen dieser Arbeit erstellte

Anwendung wird US-Konten somit nicht voll unterstutzen.

2.1.5 Gewinn- und Verlustberechnung

Alle Wechselkurse werden auf mindestens 4 Nachkommastellen genau angegeben. Eine Aus-

nahme bilden z.B. Wechselkurse in denen der Japanische Yen (JPY) enthalten ist, da es im


JPY keine Cent-Betrage gibt. Die Preisanderungen werden in Pips gemessen, wobei ein Pip der

vierten Nachkommastelle also 0,0001 bzw. 0,01 im JPY entspricht.

In dem nachfolgenden Beispiel soll nun dargelegt werden, wie Gewinne oder Verluste bei

Trades berechnet werden. Die allgemeine Formel5 lautet:

Gewinn/V erlust = (Pips) · (Preis{sekundareWahrung/Kontowahrung}) · (Lots) · 100.000$

In dem folgenden Beispiel wurde eine Long-Position6 im EUR/GBP bei 0,8431 geoffnet und bei

0,8442 geschlossen:

Kontowahrung: USD gehandelte Wahrung: EUR/GBPprimare Wahrung (Base): EUR sekundare Wahrung (Quote): GBPPreis {sekundare Wahrung / Kontowahrung} (GBP/USD): 1,6108Open: 0,8431 Close: 0,8442Pips: Close - Open = 0,8442-0,8431 = 0,0011 gehandelte Lots: 1

Gewinn/V erlust = (0, 0011) · (1, 6108) · (1) · 100.000$ = 177, 19$.

Im Kontext eines Trades fur ein PAMM-Konto (PAMM-Trade) ist die Gewinn- und Verlust-

berechnung etwas schwieriger. Ein PAMM-Trade besteht aus vielen Einzeltrades, die bei ver-

schiedenen Konten und Broker geoffnet wurden. Bei einem PAMM-Trade wird es also eher

Regel als Ausnahme sein, dass die Einzeltrades zu verschiedenen Preisen geoffnet wurden. Das

liegt zum einen daran, dass Broker leicht unterschiedliche Preis-Feeds haben konnen. Zum

anderen handelt es sich bei dem Devisenmarkt um einen sehr volatilen Markt, bei dem sich

Wahrungskurse sehr schnell andern konnen.

Es kann aufgrund der unterschiedlichen Preis-Feeds auch dazu kommen, dass ein Einzeltrade

bei einem Broker schon den Limit- oder Stop-Preis erreicht hat und geschlossen wurde, wahrend

andere Einzeltrades noch offen sind.

Damit steht der endgultige Gewinn oder Verlust fur einen PAMM-Trade erst fest, wenn alle

Einzeltrades geschlossen wurden. Um nicht den laufenden Gewinn/Verlust fur jeden Einzeltrade

eines PAMM-Trades auszurechnen, wird ein - nach Lotgroße gewichteter - Durchschnittspreis

fur den Open-Preis eingefuhrt:

gewichteter Open-Preis= (Lot1·Open1)+(Lot2·Open2)+...+(Lotn·Openn)Lot1+Lot2+...+Lotn

,

dabei steht n fur die Anzahl der Einzeltrades in einem PAMM-Trade. Anhand dieses Preises,

der gesamten Lotgroße und dem aktuellen Devisenkurs, kann der aktuelle Gewinn- und Verlust

fur einen PAMM-Trade leicht berechnet werden.

5Wenn die sekundare Wahrung gleich der Kontowahrung ist, gilt: Gewinn/Verlust=(Pips)*(Lots)*100.000$.

6Bei einer Short-Position, wurde sich die Anzahl der Pips mit Pips = Open− Close berechnen.


2.1.6 Lotberechnung

Wie im letzten Unterkapitel ersichtlich wurde, hangt der Gewinn/Verlust eines Trades im großen

Maße von der Lotgroße ab. Die Anzahl der Lots muss auch als einziger Parameter beim Eroffnen

eines Trades angegeben werden. Doch wie bestimmt man die Lotgroße?

Vor jedem Trade sollte festgelegt werden, wie groß das Risiko pro Trade sein soll (Ein guter

Wert liegt hier meist zwischen 1-3% der Kontogroße). Das Risiko wird mit dem Setzen des Stop-

Preises festgelegt, bei dem ein moglicher Verlust realisiert wird. Sind Stop-Preis und damit die

Entfernung vom Entry in Pips bekannt, kann die im letzten Unterkapitel erwahnte Formel

benutzt werden, um die Lotgroße zu bestimmen.

Eingeschrankt wird die Lotgroße und damit eine genaue Realisierung des Risikos pro Trade,

nur durch die Anzahl der erlaubten Nachkommastellen7. Im Kontext eines PAMM-Kontos fuhrt

dies dazu, dass ein PAMM-Trade im Allgemeinen nicht gleichmaßig auf alle im PAMM-Konto

zusammengefassten Einzelkonten verteilt werden kann. Meistens wird eine optimale Aufsplit-

tung des PAMM-Trades in Einzeltrades nicht moglich sein, da die fur das Einzelkonto berech-

nete Lotgroße auf- oder abgerundet werden muss, wodurch sich wiederum das Einzel- und

Gesamtrisiko des Trades andert.

2.1.7 Automatische Handelssysteme

Automatisierte Handelssysteme sind autonome Systeme, die anhand von Indikatoren und/oder

Chartformationen, die Entscheidungen zum Kauf oder Verkauf von Devisen treffen und selb-

standig den Handel durchfuhren. Sie haben ein beliebig komplexes Regelwerk, in dem Kriterien

fur die Eroffnung und das Schließen eines Trades, das Risiko pro Trade und die Stop- und

Limit-Berechnung festgelegt sind. Diese Werte sind meist nicht statisch, sondern konnen vom

Anwender vor dem Starten des Systems festgelegt werden.

Automatisierte Handelssysteme bieten den Vorteil, dass sie rund um die Uhr die Markte

analysieren und handeln konnen, ohne emotionale oder psychologische Schwachen. Sie werden

weder durch Angst, noch durch Gier oder Mudigkeit beeinflusst.

Ein weiterer Vorteil ist, dass automatisierte Handelssysteme nicht nur auf aktuelle De-

visendaten, sondern auch auf historische Daten angewendet werden konnen. Mit diesem, als

Backtesting bekannten, Verfahren lassen sie sich nicht nur auf technische Funktionalitat, son-

dern auch auf mogliche Profitabilitat testen.

Inzwischen unterstutzt jeder Broker das Erstellen von automatischen Handelssystemen, je-

doch verwendet auch jeder Broker dafur eine andere Software, sodass automatische Handelssys-

teme nur mit Programmieraufwand portiert werden konnen. Dies soll im Kapitel 3 genauer

untersucht werden.

7Zwei Nachkommastellen bei Micro-Lot-Konten und eine Nachkommastelle bei Mini-Lot-Konten


2.2 Modularisierung in Java

Dieses Unterkapitel soll verdeutlichen, was Modularisierung bedeutet und wie dieses

Architektur-Konzept in Java umgesetzt wird, bevor im nachsten Unterkapitel - mit OSGi - eine

modulare System-Plattform vorgestellt wird. Der klassische Modularisierungsbegriff lautet:

”... Modularisierung bezeichnet ... die Aufteilung eines Softwaresystems in uberschaubare

Einzelteile, die jeweils einen abgeschlossenen Aufgabenbereich umfassen und untereinander

mittels wohldefinierter Schnittstellen miteinander verbunden sind. [Rei09]“.

Bis zur Einfuhrung des objektorientierten Paradigmas, unterstutzten Programmiersprachen

die Modularisierung nur rudimentar. Computerprogramme konnten nur durch Funktionen und

Prozeduren strukturiert werden und hatten damit eher monolithischen Charakter. Sie waren

schwieriger zu testen, schwieriger zu erweitern und schlechter wartbar.

Mit der Einfuhrung der objektorientierten Programmiersprachen, wurde das Konzept der

Modularisierung starker verankert und um den Begriff der Komponente erweitert. Eine Kom-

ponente wird definiert als eine Einheit zur Komposition, d.h. sie wird nur als ganzes spezifiziert,

implementiert und eingesetzt. Eine Komponente besitzt fest spezifierte Schnittstellen, durch die

die Verwendung der Komponente geregelt ist.

Eine Komponenten-basierte Anwendung ist eine Komposition von Komponenten, wobei

einzelne Komponenten entweder durch komplett neue Implementierungen oder neue Versio-

nen aktueller Implementierungen ausgetauscht werden konnen. Die einzelnen Komponenten

einer Komponentenbasierten Anwendung sind durch deren Schnittstellen gekoppelt, wobei

die konkrete Implementierung der Schnittstellen dem Benutzer der Komponente durch die

Kapselung verborgen ist. Komponenten bieten den Vorteil, dass sie wiederverwendbar und gut

testbar sind.

In Java lassen sich Beziehungen zwischen Komponenten nur unidirektional ausdrucken.

Durch das import-Statement kann angegeben werden, welche anderen Komponenten es benutzt,

aber nicht welche Klassen es fur die Benutzung durch andere Komponenten exportiert.

In Java werden weiterhin Klassen auf Sprachebene mit Hilfe von Packages hierarchisch

strukturiert. Dabei lasst sich zwar die Sichtbarkeit von Klassen auf Packageebene einschranken,

fur eine echte Komponentenbildung ist dies aber unzureichend. Die interne Implementierung

ist dadurch nicht ausreichend geschutzt und uber eine einfache Typumwandlung erreichbar.

OSGi ist eine auf Java basierende Plattform und erweitert Java um die Moglichkeit, echte

Komponenten zu entwickeln. Bei OSGi ist die Implementierung einer Komponente durch einen

separaten Class-Loader geschutzt, außerdem ist es hier moglich, explizit Abhangigkeiten, zu

exportierende Elemente und Schnittstellen zu definieren. Dies soll im nachsten Unterkapitel

genauer untersucht werden.


2.3 Die OSGi Service Plattform

Die OSGi Alliance, ein Konsortium von Technologieunternehmen, ist eine non-profit Orga-

nisation und wurde 1999 gegrundet. Ihre Aufgabe ist es, die Programmierschnittstellen und

Testfalle [OSGa,OSGb] fur die OSGi Service Platform zu spezifizieren.

Die OSGi Service Platform ist ein dynamisches Modulsystem fur Java. Es handelt sich um

eine javabasierte Softwareplattform, die die dynamische Integration und das Fernmanagement

von Softwarekomponenten (Bundles) und Diensten (Services) ermoglicht. Bundles und Services

konnen zur Laufzeit in der Serviceplattform installiert und deinstalliert, aktualisiert, gestoppt

und gestartet werden, ohne dass die Plattform als Ganzes angehalten bzw. neu gestartet werden

muss [WHKL08].

Es gibt eine Referenzimplementierung von der OSGi Alliance, diese ist jedoch nicht fur

den Produktiveinsatz gedacht. Hervorzuheben sei hier die Implementierung durch das Eclipse

Equinox Projekt, welche Open Source ist und die Grundlage von Eclipse seit Version 3.0 bildet.

Weitere Implementierungen sind z.B. Apache Felix und Knopflerfish.

2.3.1 OSGi Bundles

Das fundamentale Konzept der OSGi Service Plattform ist die Modularisierung. In der OSGI-

Terminologie werden diese Module als Bundles bezeichnet. Unter einem Bundle versteht man

eine fachlich oder technisch zusammenhangende Einheit von Klassen und Ressourcen, die

unabhangig von anderen Bundles im OSGi Framework installiert und deinstalliert werden

kann [WHKL08]. Ublicherweise wird fur Bundles die Dateiendung”.jar“ verwendet. Von einer

normalen JAR-Datei unterscheidet sich ein Bundle nur durch ein Bundle Manifest.

INSTALLED

RESOLVED

UNINSTALLED

STARTING

ACTIVE

STOPPING

Start

Stop

Abbildung 2.3: Bundle Lebenszyklus (Quelle: [wikc])

Die Abbildung 2.3 zeigt den Lebenszyklus eines Bundles. Jedes Bundle kann sich in sechs

verschiedenen Zustanden befinden:

� INSTALLED: Das Bundle wurde erfolgreich auf der OSGI-Plattform installiert.


� RESOLVED: Alle Abhangigkeiten (siehe Bundle Manifest) des Bundles konnten aufgelost

werden. Das Bundle ist bereit gestartet zu werden oder wurde gerade gestoppt.

� STARTING: Die start-Methode des Bundle-Activators wurde aufgerufen aber noch nicht

abgeschlossen.

� ACTIVE: Das Bundle lauft und die start-Methode des Bundle-Activators wurde erfolgre-

ich abgeschlossen.

� STOPPING: Die stop-Methode des Bundle-Activators wurde aufgerufen aber noch nicht

abgeschlossen.

� UNINSTALLED: Das Bundle wurde deinstalliert.

Im Eclipse-Umfeld wird meist von Plug-ins anstatt von Bundles gesprochen. Beide Begriffe

beschreiben allerdings ein und dasselbe Konzept und werden synonym verwendet.

2.3.1.1 Das Bundle Manifest

Jedes Bundle wird uber seine Manifest-Datei und darin definierte Manifest-Header beschrieben.

Das Bundle Manifest befindet sich in der JAR-Datei des Bundles unter dem Namen META-

INF/MANIFEST.MF. Die Manifest-Header werden ausfuhrlich im Kapitel 3.2 des OSGi-Core-

Compendium [OSGa] beschrieben. Listing 2.1 zeigt den Ausschnitt eines gultigen Bundle Man-

ifest.

1 Bundle -Name: API -Interfaces

2 Bundle -SymbolicName: de.pammtrader.core.api.interfaces

3 Bundle -Activator: de.pammtrader.core.api.interfaces.Activator

4 Bundle -Version: 0.1.0

5 Bundle -RequiredExecutionEnvironment: JavaSE -1.6

6 Import -Package:

7 de.pammtrader.core.account.interfaces;version="[0.1.0 ,1.0.0)"

8 Export -Package: de.pammtrader.core.api.interfaces;version="0.1.0"

9 Require -Bundle: de.pammtrader.core.api.fxcm;bundle -version="0.1.0"

Listing 2.1: MANIFEST.MF

Bundles werden innerhalb der OSGi Service Plattform durch ihren symbolischen Namen

und ihrer Versionsnummer eindeutig identifiziert (Listing 2.1: Zeilen 2, 4). Diese beiden Felder,

sind auch die einzigen Header die gesetzt werden mussen. Alle anderen Header sind optional.

Das bedeutet, dass Bundles auch in mehreren und unterschiedlichen Versionen auf der OSGi

Plattform installiert sein konnen.

In der Manifest-Datei kann ein Bundle-Activator angegeben werden (Listing 2.1: Zeile

3). Dieser Bundle-Activator muss das Interface BundleActivator und dessen start- und stop-

Methode implementieren. Er ist mit der main-Methode aus Java-Programmen vergleichbar.

Weiterhin konnen Abhangigkeiten wie benotigte Java-Packages und Bundles definiert und

explizit Java-Packages exportiert werden (Listing 2.1: Zeilen 6-9). Damit wird eine weitere


Besonderheit von OSGi klar: Es kann nur auf Java-Packages anderer Bundles zugegriffen wer-

den, die diese auch exportieren.

2.3.2 OSGi Services

Mit der Hilfe von Services werden Bundles dynamisch durch das”publish, find and bind model“

lose gekoppelt. Ein Service ist ein Java-Objekt, das unter einem oder unter mehreren Java-

Interfaces bei der Service-Registry angemeldet ist. Bundles konnen Services registrieren, nach

Services suchen und sich benachrichtigen lassen wenn sich Services anmelden, abmelden oder

aktualisert wurden. [OSGa]

Da Services sich zu beliebigen Zeitpunkten bei der Service-Registry registrieren und dereg-

istrieren konnen, gilt es, dies bei der Benutzung von Services zu beachten. Um den Umgang

mit Services zu vereinfachen, wurden der Service-Tracker und Declarative Services geschaffen.

Bei einem Service-Tracker handelt es sich um eine Hilfsklasse, die den Zugriff auf die Service-

Registry kapselt und das An- und Abmelden von Services mit einem spezifischen Interfacena-

men uberwacht. Mit der Hilfe von Declarative Services konnen Service-Abhangigkeiten in einer

XML-Datei beschrieben werden. Das Auflosen von Service-Abhangigkeiten wird dann durch

die Service Component Runtime realisiert. Beide Ansatze werden genauer im OSGi Service

Compendium [OSGb] beschrieben.

2.3.2.1 Event Admin Service

Im OSGi Service Compendium [OSGb] werden eine Reihe von Diensten spezifiziert. Die im

Rahmen dieser Arbeit erstellte Anwendung benutzt unter anderem den Event Admin Service,

weswegen dieser hier erlautert werden soll. Der Event Admin Service basiert auf dem”publish-

<<class>>Event

<<service>>Event Admin

<<service>>Event Handler

Event Consumerimpl EventHandler

Event Publisher

1 0..n

Abbildung 2.4: Event Admin Service

subscribe model“ und erlaubt die systemweite Kommunikation zwischen Bundles. Abbildung

2.4 stellt den Event Admin Service schematisch dar: Event Publisher benutzen die postEvent-


Methode des Event Admin Service zum asynchronen bzw. dessen sendEvent-Methode zum

synchronen Versenden von Events.

Alle Bundles, die sich fur ein Topic und dessen Events interessieren, registrieren sich nun

nicht beim Event Admin Service als Listener. Stattdessen implementieren sie das Interface

EventHandler, registrieren sich als Dienst, ubergeben als Service-Property das Topic und werden

vom Event Admin Service uber Events informiert. Dieses Design Pattern wird Whiteboard-

Pattern genannt.

Ein Event wird reprasentiert durch ein org.osgi.service.event.Event Objekt und hat die zwei

Attribute: Topic und Properties. Topics sind String Objekte und case-sensitive. Ein Beispiel fur

ein gultiges Topic ware”de/pammtrader/api“, wobei Wildcards erlaubt sind. Properties sind

HashMaps, wobei der Schlussel ein String-Objekt ist und der dazu gehorige Wert ein beliebiges

Java-Objekt sein kann.

2.4 Eclipse RCP

Die Eclipse Rich Client Plattform8 (RCP) ist eine Plattform fur modulare Desktopanwendun-

gen und basiert auf OSGi. Sie ist entstanden aus der Eclipse IDE und deren Versionssprung

auf Version 3.0. Die Entwicklung von Eclipse 3.0 bildete die Grundlage fur eine Rich Client

Plattform, indem alle Abhangigkeiten zu IDE-spezifischen Elementen entfernt und viele Teile

des Benutzerinterfaces fur die Anpassung durch den Entwickler geoffnet wurden. Die Abbildung

2.5 zeigt einige wichtige Komponenten der Eclipse RCP:

� Equinox ist eine vollstandige Implementierung der OSGi Plattform Spezifikation, er-

weitert um fur Eclipse RCP-Anwendungen benotigte Komponenten, wie z.B. Extension

Registry, Applications und Products, die in der Abbildung 2.5 unter der Eclipse Core

Runtime zusammengefasst sind.

� Jede Eclipse RCP-Anwendung definiert mindestens eine Application. Applications wer-

den mit Hilfe von Extensions definiert, die auf eine Klasse verweist, welche das Interface

IApplication implementiert. Diese Klasse ist vergleichbar mit der main-Methode aus Java-

Anwendungen und startet die Eclipse RCP Anwendung.

� Ein Product ist eine Konfigurationsdatei in der die Eclipse RCP-Anwendung beschrieben

wird. Hier werden die Plug-ins, die die Anwendung bilden, aufgelistet und konfiguriert,

Icons und Bilder fur das Branding der Anwendung und Startparameter definiert.

� Das Standard Widget Toolkit (SWT) ist eine low-level Grafikbibliothek, welche

die Standard Bedienelemente wie Listen, Menus, Schriftarten und Farben zur Verfugung

stellt und die nativen UI-Widgets des zugrunde liegenden Betriebssystems kapselt. SWT

8siehe [MLA10] S. 7ff


Abbildung 2.5: Komponenten der Eclipse RCP Plattform9.

ist fur eine Vielzahl von Betriebssystemen verfugbar. Damit sind Anwendungen, die SWT

verwenden, sehr leicht portierbar und immer im Look & Feel des Betriebssystems auf dem

sie laufen.

� JFace ist ein User Interface Toolkit (UI), mit Klassen fur viele gangige Aufgaben in

der UI-Programmierung, das designt wurde mit dem SWT zusammenzuarbeiten, ohne

es zu kapseln. Es beinhaltet Komponenten wie Bild- und Schriftarten-Register, Dialoge,

Wizards, Actions, Views und Frameworks fur Databinding und Preferences und bildet

damit die Basis des Eclipse UI.

� Eclipse Update, genauer Eclipse p2, erlaubt es einen Update-Mechanismus fur eine

RCP-Anwendung zu implementieren. Damit lasst sich nicht nur die Anwendung auf dem

neuesten Stand halten, es ist auch moglich neue Features zu installieren. Updates konnen

dann automatisch oder durch Benutzerinteraktion installiert werden.

Eine Eclipse RCP Anwendung besteht also immer aus einem oder mehreren Plugins und wird

zusammen mit seiner Laufzeitumgebung ausgeliefert.

2.4.1 Extensions

Ein Plug-in ist von einem Bundle nur durch die plugin.xml zu unterscheiden, die sich im Root-

Ordner des Plug-ins befindet und optional ist. In dieser Datei werden Extensions und Extension-

Points deklariert.

9Quelle: http://www.ralfebert.de/rcpbuch/overview/


Mit Extension Points10 offnen sich Plug-ins fur Erweiterungen (Extensions) durch andere

Plug-ins. Diese Extensions konnen Implementierungen von Interfaces sein, aber auch Daten

wie z.B. Icons oder Text. Fur jeden Extension-Point wird, mit Hilfe der Eclipse IDE, ein XML

Schema-Dokument (XSD-Datei) hinterlegt, in dem beschrieben wird, welche Daten eine Exten-

sion zur Verfugung stellen muss.

Extension Points und Extensions werden von der Extension Registry verwaltet und sind

verfugbar, sobald das dazugehorige Plug-in den Status”resolved“ hat. Extensions werden bei

der Extension Registry abgefragt und nach dem”lazy-loading“ Prinzip bei Bedarf geladen.

Extensions sind ein fundamentales Konzept in der Entwicklung von Eclipse-RCP Anwen-

dungen. So sind UI-Elemente wie Views, Editoren und Perspektiven vom Entwickler erstellte

Extensions, zu von der Ecplipse RCP bereitgestellten Extension Points. Da diese Elemente in

nur einer Datei (und nicht z.B. auf mehrere Java-Klassen verteilt) beschrieben werden, ist es

fur einen Ecplipse RCP-Entwickler einfach, sich in eine bestehende Anwendung einzuarbeiten

bzw. diese zu erweitern.

Listing 2.2 zeigt den Ausschnitt aus einer gultigen plugin.xml, in der eine Application (Zeilen

1-8) und eine View (Zeilen 9-14) deklariert werden.

1 <extension id="application"

2 point="org.eclipse.core.runtime.applications">

3 <application >

4 <run

5 class="de.fxsolution.client.Application">

6 </run >

7 </application >

8 </extension >

9 <extension point="org.eclipse.ui.views">

10 <view

11 class="...ui.singleaccount.AccountList"

12 id="de.fxsolution.client.ui.AccountList"

13 name="AccountList">

14 </view >

15 ...

Listing 2.2: plugin.xml

2.4.2 Synchronisation von Datenmodell mit UI-Elementen

Eclipse RCP unterstutzt explizit das Trennen von Datenmodell, Zugriff auf das Datenmodell

und Prasentation des Datenmodells (MVC-Pattern). Diese Trennung in Komponenten hat den

Vorteil, dass die jeweilige Implementierung an sich andernde Anforderungen angepasst werden

kann, ohne dass dies Konsequenzen fur die anderen Komponenten haben muss. Damit wird die

Anwendung besser struktiert und ist leichter wart- und testbar.



Um das Datenmodell zu kapseln und mit dem Benutzerinterface zu synchronisieren, bietet

die Eclipse RCP zum einen das, aus der Android Entwicklung bekannte, Konzept des Content

Providers und das JFace Data Binding Framework an. Beide Konzepte wurden evaluiert, jedoch

wird nur der Content-Provider genutzt. Auf die Verwendung des JFace Data Binding Framework

musste aus Zeitgrunden verzichtet werden. Es wird der Vollstandigkeit halber im Anhang auf

der Seite 57 vorgestellt.

2.4.2.1 Content Provider

Content Provider11 sind Klassen, die ein spezifisches Interface, aus dem Package

org.eclipse.jface.viewers, implementieren und Zugriff auf Daten gewahren. Content Provider

bieten den Vorteil, dass sie sehr leicht zu implementieren sind.

Die Abbildung C.1 auf Seite 59 zeigt am Beispiel eines TreeViewers, wie ein UI-Element mit

einem Contentprovider verknupft wird und wie dieses Element, mit Hilfe der Methode getChil-

dren(), Daten bezieht. Ein TreeViewer ist eine Komponente, die Elemente in einer Baumstruk-

tur, ahnlich dem Windows Explorer, anzeigt und bezieht Daten entweder von einem ITreeCon-

tentProvider oder von einem BaseWorkbenchContentprovider und dazu gehorigen IWorkben-

chadaptern.

Andert sich das Datenmodell, dann mussen die UI-Elemente, mit der Hilfe von Listenern,

daruber informiert und die Daten erneut vom Content Provider geladen werden.


Kapitel 3

Anforderungsanalyse

Die im Rahmen dieser Arbeit entwickelte Anwendung stellt einen Prototyp fur den Handel

von Devisen dar. Sie soll die Broker-APIs kapseln und deren Funktionalitaten mit einem ein-

heitlichen Benutzerinterface zu Verfugung stellen. Weiterhin soll Sie es ermoglichen Einzelkon-

ten, die bei unterschiedlichen Brokern liegen konnen, zu einem PAMM-Konto zusammenzu-

fassen. Diese PAMM-Konten sollen dann manuell oder mit Hilfe von automatischen Handelssys-

temen gehandelt werden konnen.

Um diese Ziele zu erreichen, wird im ersten Teil dieses Kapitels ermittelt, was Broker an APIs

zur Verfugung stellen. Daraus werden die funktionalen und nicht-funktionalen Anforderungen

an die Software abgeleitet, die im zweiten Teil formuliert werden.

3.1 Marktubersicht

3.1.1 Broker-APIs

Nach einer Recherche bei gangigen Forex-Brokern (siehe Tabelle D.1 auf Seite 71) zeigte sich,

dass deren APIs in 3 Arten gegliedert sind:

Zum einen unterstutzen die meisten Broker das Financial Information eXchange (FIX)-

Protokoll. Alle untersuchten Broker bieten weiterhin eigene APIs an, wobei der Zugriff auf

historische Preisdaten meist - von den reinen Trade-Funktionalitaten getrennt - in einer eigenen

API zu finden ist. Als Programmiersprachen, werden C++ und/oder Java unterstutzt.

3.1.1.1 FIX-Protokoll

Das FIX-Protokoll1 ist ein Nachrichtenstandard, der speziell fur den Handel von Wertpapieren

in Echtzeit entwickelt wurde. Das FIX-Protokoll ist offen und frei verfugbar und liegt aktuell

in der Version 5.0 Service Pack 2 vor. Es ist komplett Nachrichtenbasiert und definiert eine

1vgl. [FP]

KAPITEL 3. ANFORDERUNGSANALYSE 22

Reihe von Nachrichten, die in Session- und Anwendungsnachrichten unterteilt sind, und darin

erlaubte Felder.

Diese Nachrichten konnen zum einen in reiner Textform vorliegen, wobei ein Feld wie folgt

aufgebaut sein muss:

< TAG >=< V ALUE >< DELIMITER > z.B.:”8=FIX.4.4;“.

Sie konnen aber auch, nach dem FIX-XML Standard, in XML-Form sein.

Zu den Session-Nachrichten gehoren unter anderem Logon-, Heartbeat- und Logout-

Nachrichten. Zu den Anwendungsnachrichten gehoren z.B. Nachrichten die zum Offnen,

Schließen oder Andern eines Trades versendet werden aber auch um Tickdaten zu abon-

nieren oder um History-Daten abzufragen. Dabei liegt es naturlich am Broker, inwieweit er

alle Moglichkeiten unterstutzt.

Das FIX-Protokoll ist der Quasi-Standard, fur den Handel an allen großen Borsenplatzen

dieser Welt, wobei die Versionen 4.2 und 4.4 noch weit verbreitet sind.

Von den untersuchten Brokern unterstutzen, bis auf OEC und Gain Capital, alle Broker

dieses Protokoll. Dadurch wahre es optimal fur ein Broker-ubergreifendes Programm zum De-

visenhandel. Es ist allerdings nur fur institutionelle Trader gedacht. So verlangen die Broker,

welche das FIX-Protokoll unterstutzen, entweder hohe Lizenzgebuhren und dazu monatliche

Gebuhren oder es wird ein Konto mit einer hohen Mindestgroße fur das Kontoguthaben ver-

langt. Ohne diese Voraussetzungen zu erfullen, ließen sich auch keine Testprogramme erstellen.

Aus diesem Grund wurde fur diese Arbeit darauf verzichtet, das FIX-Protokoll zu imple-

menteren.

3.1.1.2 Zugriff auf Handelsfunktionalitaten

Alle untersuchten Broker unterstutzen den Handel von Devisen uber eine eigene API. Die APIs

sind dabei sehr unterschiedlich. Sie reichen von dem komplett auf Nachrichten basierten FIX-

API, uber den entfernten Aufruf von Methoden (RPC), bis zu einer Mischung aus beiden.

So bietet z.B. FXCM eine Java-API an, welche das FIX-API in entsprechende Java-Klassen

kapselt und damit komplett auf Nachrichten basiert. Zum Eroffnen eines Trades muss hier

eine Nachricht verschickt werden, wobei zum Setzen eines Stop- und Limit-Preises jeweils eine

weitere Nachricht versendet werden muss. Stop- und Limit-Preis konnen also auch erst gesetzt

werden, nachdem der Trade geoffnet wurde. Als Antwort werden vom Broker, bei Erfolg, drei

Executionreports, ein Positionreport und ein Collateralreport versendet, die alle auch ausge-

wertet werden mussen.

Bei Dukascopy hingegen muss nur eine Methode aufgerufen werden, wobei hier direkt Stop-

und Limit-Preis gesetzt werden konnen. Als Anwort erhalt man vom Broker nur eine auszuwer-

tende Nachricht.

Dies und die folgenden Merkmale mussen bei der Planung der Anwendung berucksichtigt

werden, da diese nur Funktionalitaten haben kann, die alle Broker anbieten.


Alle APIs erlauben die auf Seite 8 im Abschnitt 2.1.4 aufgelisteten Ordertypen. Teilweise

konnen auch noch zusatzliche Ordertypen verwendet werden, wie z.B. der Trailing Stop. Hier

wird der Stop-Preis, beim Erreichen von bestimmten Zielen, automatisch nachgezogen.

Von Broker zu Broker unterschiedlich, ist auch die Anzahl der unterstutzten Wahrungspaare.

Diese reicht von 35 bis zu uber 100 Wahrungspaaren. Alle Broker erlauben den Handel der

sogenannten Majors, also EUR/USD, GBP/USD, AUD/USD, NZD/USD, USD/CHF und

USD/JPY.

3.1.1.3 Zugriff auf Preisdaten

Alle Broker, bis auf Dukascopy, unterscheiden zwischen Tick-Daten und dem Zugriff auf History-

Daten. Die Tick-Daten werden uber das eigene Trade-API und, falls vorhanden, uber das

FIX-API angeboten. Um Tickdaten zu erhalten, mussen sie fur jedes Wahrungspaar abboniert

werden. Die Tickdaten werden dann unter Benutzung der Push-Technologie verteilt. Teilweise

mussen diese auch abboniert sein, um den Handel uber die API zu ermoglichen.

Der Zugriff auf History-Daten ist meist nur eingeschrankt moglich. Sie konnen meist nur

uber ein extra API oder uber das FIX-API abgefragt werden. Die Verfugbarkeit von Preisdaten

schwankt stark in der Genauigkeit der Daten. So sind teilweise nur Daten auf Tagesbasis fur

einen großeren Zeitraum und genauere Daten wie z.B. auf Minutenbasis nur fur einen kurzen

Zeitraum verfugbar.

Das ist insbesondere fur automatische Handelssysteme, wenn sie auf vergangene Zeitraume

getestet werden sollen, aber auch fur Indikatoren, die einen großen Zeitraum analysieren, von

Bedeutung. Hier werden moglichst genaue Daten fur einen moglichst großen Zeitraum benotigt,

im Falle des Backtesting der Handelssysteme am besten Tickdaten.

Weiterhin muss berucksichtigt werden, dass sich Broker in unterschiedlichen Zeitzonen

befinden konnen, was zu unterschiedlichen Daten fur den gleichen Zeitraum fuhrt. So ist es

moglich, dass ein Broker auch Daten fur Sonntage offeriert, obwohl der Handel erst am Montag

um 0 Uhr beginnt.

Zusammenfassend muss eine einheitliche Losung gefunden werden, bei der ein moglichst

umfangreicher Zugriff auf historische Preisdaten gegeben ist. Diese Losung sollte unabhangig

von einem Broker sein.

Hier gibt es zum einen die Moglichkeit auf externe Anbieter von History-Daten zuruckzu-

greifen. Anbieter wie Google oder Yahoo offerieren Borsendaten kostenlos uber eine einfache

API, mit der Daten als csv-Dateien exportiert werden konnen. Diese Daten sind allerdings um

15-Minuten verzogert und damit fur den Live-Handel nicht brauchbar. Andere Anbieter wie

z.B. eSignal (www.esignal.com), netdania (www.netdania.com) oder iqfeed (www.iqfeed.net)

bieten Live-Forex-Borsendaten zu einem Preis von ca. 100$ im Monat an, was je nach Paket

und Anbieter differiert.

Eine weitere Moglichkeit ist das Aufbauen einer eigenen Datenbasis. Dazu konnten History-

Daten von einem kostenlosen Anbieter heruntergeladen werden - am besten am Wochenende,


wenn die Borsen geschlossen sind - und dann mit Hilfe der Tickdaten, die jeder Broker ubermit-

telt, gepflegt werden. Diese Losung hat den Vorteil, dass sie Broker-ubergreifend funktioniert -

damit keine Abhangigkeiten aufweist - und keine Kosten durch externe Datendienste enstehen.

Bei Hard- oder Softwareproblemen oder bei Ausfall der Internetverbindung kann es jedoch zu

Lucken in der Datenbasis kommen.

Die letzte Losungsvariante soll im Rahmen dieser Arbeit verwirklicht werden.

3.1.1.4 Zugriff auf Indikatoren

FXCM und Dukascopy unterstutzen als einziges den Zugriff auf Indikatoren-Daten bzw. das

Erstellen von eigenen Indikatoren uber APIs.

Bei FXCM konnen Indikatoren-Daten uber das Order2Go SDK abgefragt werden und

mit Hilfe eines Indicator SDK eigene Indikatoren erstellt werden. Als Programmiersprache

wird hierfur Lua verwendet. Bei Dukascopy werden Indikatoren in Java erstellt und mussen

das IIndicator-Interface implementieren. Beide bieten eine Vielzahl von fertigen Standard-

Indikatoren und unterstutzen damit das Erstellen von automatischen Handelssystemen.

Zusammenfassend fehlt auch hier eine einheitliche und Broker ubergreifende Losung, zu-

mindest was die APIs der Broker betrifft. Aus diesem Grund wurde sich, im Rahmen dieser

Arbeit entschieden, eine eigene Basis fur das Erstellen von Indikatoren und damit auch fur das

Erstellen von automatischen Handelssystemen zu schaffen.

3.1.2 Unterstutzte Software

Um den Devisenhandel mit Hilfe automatisierter Handelssysteme zu ermoglichen, unterstutzen

die meisten Broker die Software externer Anbieter. Diese reichen von kostenloser und durchaus

empfehlenswerter Software wie den Metatrader von MetaQuotes Software, bis hin zu profess-

ioneller Chartsoftware von eSignal. Weitere Informationen finden sich hierzu in der Tabelle D.2

auf Seite 73.

3.2 Zielbestimmung

Die Anforderungen an die Software ergeben sich aus dem letzten Unterkapitel und aus den

allgemeinen Anforderungen an eine Software fur den Devisenhandel. Sie werden in funktionale-

und nicht-funktionale Anforderungen unterteilt.

3.2.1 Funktionale Anforderungen

Die Anwendung ist in die Aufgabenbereiche: unterstutzte Wahrungspaare, Kontoverwaltung,

Tradeverwaltung und automatische Handelssysteme unterteilt. Die jeweiligen Anforderungen

finden sich in den folgenden Unterkaptiteln und in Form von Usecase-Diagrammen auf den

Seiten 60 - 62. Das Diagramm fur die Wahrungspaare wurde dabei weggelassen.


3.2.1.1 Wahrungspaare

Es ergeben sich folgende zu erfullende Muss-Kriterien fur Wahrungspaare:

� unterstutzte Wahrungspaare:

Beschreibung: Es sollen die Wahrungspaare EUR/USD, GBP/USD, AUD/USD und

NZD/USD unterstutzt werden. Indikatoren und Handelssysteme mussen Zugriff auf his-

torische Preisdaten, aller auf Seite 5 im Kapitel 2.1.1 erwahnten Zeitebenen, und auf

aktuelle Tickdaten dieser Wahrungspaare haben. Diese Daten sollen kostenneutral zur

Verfugung stehen.

� Wahrungspaare anzeigen:

Beschreibung: Es muss eine Liste geben, in der aktuelle Bid- und Ask-Preise angezeigt

werden.

Es ergeben sich folgende wunschenswerte Kann-Kriterien fur die Wahrungspaare:

� unterstutzte Wahrungspaare:

Beschreibung: Es sollten weitere Wahrungspaare unterstutzt werden.

3.2.1.2 Kontoverwaltung

Es ergeben sich folgende zu erfullende Muss-Kriterien fur die Kontoverwaltung:

� PAMM-Konto anlegen:

Beschreibung: Es muss eine Funktion geben um PAMM-Konten anzulegen. Als Eingabe

wird ein Name benotigt, der im System eindeutig sein muss.

Nachbedingung: Konto wurde angelegt.

� PAMM-Konto loschen:

Vorbedingung: Es durfen keine Trades in dem PAMM-Konto offen sein.

Beschreibung: Es muss eine Funktion geben um PAMM-Konten und darin enthaltene

Einzelkonten zu loschen.

Nachbedingung: PAMM-Konto und Einzelkonten wurden geloscht.

� PAMM-Konten anzeigen:

Beschreibung: PAMM-Konten und darin enthaltene Einzelkonten werden in einer Liste

angezeigt.

� Einzelkonto anlegen:

Vorbedingung: Es wurde ein PAMM-Konto ausgewahlt. Im Einzelkonto sind keine Trades

offen.

Beschreibung: Ein Einzelkonto kann angelegt werden, dazu muss ein PAMM-Konto

ausgewahlt werden. Außerdem mussen ein Broker ausgewahlt und die Zugangsdaten

eingegeben werden.


Nachbedingung: Einzelkonto wurde angelegt und dem PAMM-Konto hinzugefugt. Kon-

tostatus wird auf Offline gesetzt.

� Einzelkonto loschen:

Vorbedingung: Es wurde ein Einzelkonto ausgewahlt. Im Einzelkonto sind keine Trades

offen.

Beschreibung: Es muss eine Funktion geben um Einzelkonten zu loschen.

Nachbedingung: Das Einzelkonto wurde geloscht und aus dem PAMM-Konto entfernt.

Es ergeben sich folgende wunschenswerte Kann-Kriterien fur die Kontoverwaltung:

� Kontowahrungen:

Es sollten als Kontowahrung fur Einzelkonten nicht nur US-Dollar, sondern auch weitere

Wahrungen unterstutzt werden.

� PAMM-Konten andern:

Es sollte die Moglichkeit geben, den Namen von PAMM-Konten zu andern.

� Einzelkonto andern:

Es sollte die Moglichkeit geben, die Daten von Einzelkonten zu andern.

3.2.1.3 Tradeverwaltung

Es ergeben sich folgende zu erfullende Muss-Kriterien fur die Tradeverwaltung:

� PAMM-Trade erstellen:

Vorbedingung: Es wurde ein PAMM-Konto ausgewahlt. Das PAMM-Konto enthalt

Einzelkonten, die alle online sein mussen.

Beschreibung: Das System generiert fur alle im PAMM-Konto enthaltenen Einzelkonten,

entsprechend dem Guthaben, jeweils einen Trade und lost ihn aus. Es mussen alle auf

Seite 8 im Abschnitt 2.1.4 aufgefuhrten Ordertypen unterstutzt werden.

Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde ausgefuhrt.

� PAMM-Trade schliessen:

Vorbedingung: Es wurde ein PAMM-Trade ausgewahlt, der offen ist.

Beschreibung: Es werden der PAMM-Trade und alle dazu gehorigen Einzeltrades

geschlossen.

Nachbedingung: PAMM-Trade und damit alle Einzeltrades wurde geschlossen.

� PAMM-Trades anzeigen:

Vorbedingung: Es wurde ein PAMM-Konto ausgewahlt.

Beschreibung: Es werden alle zum Konto gehorenden PAMM-Trades gezeigt, getrennt in

offene und bereits geschlossene Trades.


� Stop- und/oder Limit-Preis setzen:

Vorbedingung: Es wurde ein PAMM-Trade ausgewahlt, der offen ist.

Beschreibung: Stop- und Limit-Preis konnen gesetzt werden, wenn sie die auf der Seite 8

in der Tabelle 2.1 aufgefuhrten Bedingungen erfullen.

Nachbedingung: Stop- und Limit-Preis werden beim PAMM-Trade und bei allen dazu

gehorigen Einzeltrades gesetzt.

3.2.1.4 automatische Handelssysteme

Es ergeben sich folgende zu erfullende Muss-Kriterien fur automatische Handelssysteme:

� Indikator erstellen:

Beschreibung: Es muss eine Moglichkeit geben, Indikatoren zu erstellen. Der Indikator

verfugt uber eine Beschreibung, einen Namen und hat eine beliebige Anzahl von Eigen-

schaften, die vom Handelsystem gesetzt werden mussen. Diese Eigenschaften konnen vom

Typ: String, Integer, Double und Boolean sein. Fur jede Eigenschaft konnen minimale und

maximale Werte festgelegt werden. Außerdem muss der Indikator eine Eingabemoglichkeit

fur mindestens ein Wahrungspaar und fur eine Zeitebene besitzen.

Nachbedingung: Der Indikator wird zum Programm hinzugefugt und kann von Handelssys-

temen genutzt werden.

� Handelssystem erstellen:

Vorbedingung: Das Handelssystem hat Zugriff auf benotigte Indikatoren.

Beschreibung: Es muss eine Moglichkeit geben Handelssysteme, zu erstellen und zum Pro-

gramm hinzuzufugen. Das Handelssystem verfugt uber eine Beschreibung, einen Namen

und hat eine beliebige Anzahl von Eigenschaften, die vom Benutzer beim Starten geset-

zt werden konnen. Diese Eigenschaften konnen vom Typ: String, Integer, Double und

Boolean sein. Fur jede Eigenschaft konnen minimale und maximale Werte festgelegt wer-

den.

Nachbedingung: Das Handelssystem wird zum Programm hinzugefugt und ist vom Be-

nutzer auswahlbar.

� Handelssystem starten:

Vorbedingung: Die vom Handelssystem geforderten Eigenschaften wurden vom Be-

nutzer mit validen Werten gesetzt und es wurde ein PAMM-Konto, ein oder mehrere

Wahrungspaare und eine Zeitebene ausgewahlt.

Beschreibung: Es muss eine Moglichkeit geben, ein Handelssysteme zu starten, welches

dann mit dem automatischen Handel beginnt.

Nachbedingung: Das Handelssystem wird vom Programm mit den ausgewahlten Parame-

tern gestartet und erhalt, genau wie davon benutzte Indikatoren, Zugriff auf aktuelle und

historische Preisdaten.


� Handelssystem stoppen:

Vorbedingung: Es wurde ein Handelssystem ausgewahlt.

Beschreibung: Es muss eine Moglichkeit geben, Handelssysteme zu stoppen.

Nachbedingung: Das Handelssystem wird gestoppt.

� laufende Handelssysteme anzeigen:

Beschreibung: Es muss eine Moglichkeit geben, alle laufenden Handelssysteme anzuzeigen.

Es ergeben sich folgende wunschenswerte Kann-Kriterien fur automatische Handelssysteme:

� Handelssystem andern:

Es sollte die Moglichkeit geben, die Eingabe-Parameter bereits laufender Handelssysteme

zu andern.

3.2.2 Nicht-Funktionale Anforderungen

� Hintergrundfunktionen:

Die Anwendung muss die Tickdaten aufzeichnen und die Daten fur die History berechnen,

um die von Indikatoren und Handelssystemen benotigten Daten zur Verfugung stellen

zu konnen. Diese Funktionen, genauso wie die automatischen Handelssysteme, mussen

moglichst 24 Stunden am Tag ohne Unterbrechung laufen.

� Mehrbenutzerfahig:

Die Anwendung soll in dem Sinne mehrere Benutzer unterstutzen, dass gleichzeitig

mehrere Benutzer mit dem gleichen Datenbestand arbeiten konnen, ohne dass es ein

Login gibt. Alle Benutzer arbeiten also mit den gleichen Rechten, den gleichen Daten und

sind vom System nicht unterscheidbar.

� Verschlusselung der Datenubertragung:

Auf eine Verschlusselung der Kommunikation wird verzichtet.

3.2.3 Abgrenzungskriterium

Die Anwendung ist hauptsachlich gedacht als Plattform fur automatische Handelssysteme und

hat als Zielgruppe erfahrene Trader. Diese sollen zwar die Moglichkeit haben in Trades einzu-

greifen und selber zu traden. Auf die Anzeige von Charts wird jedoch verzichtet.

Kapitel 4

Entwurf

Aus den im letzten Kapitel ermittelten Anforderungen ergeben sich eine Reihe von Fragen,

die fur den Entwurf der Anwendungs- und Systemarchitektur entscheidend sind. So mussen

eine Reihe verschiedener Aspekte beachtet werden, die unter anderem die Datenspeicherung,

die Transaktionsbehandlung, die Integration der Broker-APIs, die Verteilung der Systembe-

standteile und die Kommunikation der Kompenenten untereinander betreffen.

Dieses Kapitel widmet sich dem Entwurf der Anwendung unter den genannten Gesichts-

punkten, dabei werden verschiedene Losungsansatze vorgestellt und diskutiert.

4.1 System-Architektur

Aus den Anforderungen an die Anwendungen ergab sich, dass einige Komponenten moglichst

ohne Unterbrechung laufen sollen. Außerdem soll die Anwendung mehrbenutzerfahig sein und

den Zugriff auf die Systeme der Broker ermoglichen.

Eine Trennung in Client und Server ist dafur die beste Losung. Daraus ergibt sich eine so-

genannte Mehrschichten-Architektur, die sich aus Prasentationsschicht, Datenhaltungsschicht,

der Schicht fur die Geschaftslogik und einer Schicht fur die Einbindung der Broker-APIs zusam-

mensetzt. In den Abbildungen C.5 und C.6, auf den Seiten 63 bis 63, werden die Schichtenar-

chitektur und die Verteilung der Systeme schematisch dargestellt.

Der Client ist hier nur fur die Prasentation und Validierung zustandig und entlastet damit

den Server. Die Geschaftslogikschicht wird auf den Server ausgelagert. Sie agiert als Fassade

und kapselt den Zugriff auf die Broker-APIs und auf die Datenschicht. Sie ist der Vermittler

zwischen dem eigenen System und den Broker-Systemen und vereinheitlicht die Datenmodelle

durch Transformation der zu ubermittelnden Daten.

Durch die Trennung in Schichten ergeben sich eine Reihe von Vorteilen. Zum einen ist der

Zugriff auf die Daten und auf die externen Systeme geschutzt, da kein direkter Zugriff von

außen moglich ist. Zum anderen skaliert die Anwendung sehr gut, da die einzelnen Schichten

logisch voneinander getrennt sind und somit uber mehrere Datenbank- sowie Anwendungsser-

KAPITEL 4. ENTWURF 30

ver verteilt werden konnen. Außerdem ergeben sich wiederverwendbare Komponenten, z.B. fur

den Zugriff auf Daten oder die Kommunikation zwischen Client und Server. Der Datenzugriff

erfolgt uber Data Access Objects (DAOs), die den Zugriff uber Schnittstellen kapseln und

deren Implementierung damit leicht austauschbar ist. Fur das Verteilen von Daten - zwischen

Client und Server - werden Data Transfer Objects (DTOs) verwendet, die nur Daten und keine

Anwendungslogik enthalten.

4.1.1”Event-Driven-Architecture“

Die Anwendung muss auf eine Vielzahl von verschiedenen Events reagieren, die von externen

und internen Systemen ausgelost werden. So konnen z.B. Einzelkonten on- oder offline gehen und

Trades nach dem Erreichen bestimmter Ziele automatisch geschlossen oder von automatischen

Handelssystemen ausgelost werden. Die Anwendung hat weiterhin nur indirekten Einfluss auf

die externen Systeme der Broker. So kann sie zwar Trades und Orders auslosen, wird aber

durch Events erst spater uber die Ausfuhrung informiert. Trades und Konten konnen sich damit

in verschiedenen Zustanden befinden, die berucksichtigt werden mussen. Eine solche System-

Architektur wird als”Event-Driven“ bezeichnet.

4.1.2 Transaktionen in einer Mehrschichten-Architektur

Problematisch ist die Einbindung der externen Systeme, im Kontext von Vorgangen die Transak-

tionen benotigen. Aktionen die PAMM-Trades oder PAMM-Konten betreffen, mussen in Ganze

auf allen dazugehorigen Einzel-Trades bzw. -Konten ausgefuhrt werden. Im Gegensatz zu in-

ternen Datenbanken gibt es jedoch bei externen Systemen nicht die Moglichkeit in Fehlerfallen

ein Rollback durchzufuhren.

Das muss bei der Implementierung berucksichtigt werden. Es muss damit vor jeder Aktion

gepruft werden, ob benotigte Komponenten sich in einem fehlerfreiem Zustand befinden. Sind

z.B. die von einer Aktion betroffenen Konten nicht online oder verfugbar, dann muss diese

abgebrochen werden.

4.1.3 System-Umgebung

Die Anwendung wird fur MS-Windows entwickelt, sollte allerdings moglichst leicht auf an-

dere Betriebssysteme portierbar sein. Es wurde sich deshalb fur die Programmiersprache Java

entschieden, da sie plattformunabhangig ist und man - mit dem Java Native Interface (JNI) -

auch auf C-Bibliotheken zugreifen konnte.

An dieser Stelle sei erwahnt, dass Java fur Echtzeit-Anwendungen oft kritisch betrachtet

wird. Dies liegt daran, dass es unter Java keine Moglichkeit gibt, Objekte selbst aus dem Speicher

zu entfernen. Diese Aufgabe ubernimmt der Garbage Collector, ein vollautomatischer Speicher-

manager. Hierbei kann es zu Full-Garbage-Collections und damit sehr langen Pausen kommen.

(Eine Full-Garbage-Collection halt das System komplett an (stop-the-world, Mark-and-Sweep-


Algorithmus), um die Objekte zu analysieren und Speicher freizugeben und zu kompaktieren.)

Diese langen Pausen konnen unvorhersehbar eintreffen und in Ihrer Dauer, zumindest beim

Standard-Garbage-Collector, nicht beeinflusst werden. Um das Ziel von vorhersagbaren und

konstant kurzen Pausen zu erreichen, wurde von Sun der Garbage First (G1) Collector en-

twickelt.

Hier musste die Anwendung in Langzeittests untersucht und optimiert werden, um optimale

Einstellungen zu finden. Aus Zeitgrunden konnte das zwar nicht mehr genauer untersucht wer-

den, es sei aber auf die Artikelreihe”Memory Management“ im Java Magazin verwiesen, die mit

der Ausgabe 3.2010 beginnt. Weitere Ansatzpunkte konnten die fur kommerzielle Anwendungen

gedachten Java-Echtzeit-Plattformen: Java Real-Time System von Sun, WebSphere Real Time

von IBM oder JRockit von Oracle sein (siehe [Orac], [IBM] und [Orab]).

4.1.4 System–Plattform

Wie bereits beschrieben, muss die Anwendung leicht um weitere Indikatoren und Handelssys-

teme erweiterbar sein. Mit der OSGi Plattform, wurde eine optimale Losung gefunden, da sie

zum Einspielen von Erweiterungen nicht gestoppt werden muss und als Modulsystem diese An-

forderung explizit unterstutzt. Sie bildet die Grundlage fur die Serveranwendung, wahrend die

Clientanwendung auf Eclipse RCP basiert.

4.2 Datenspeicherung

Das Datenmodell wurde aus den Erkenntnissen der vorherigen Kapitel extrahiert und ist in

Form eines Entity-Relationship-Modells (ERM) auf den Seiten 64 und 65 dargestellt. Um die

Beziehungen zwischen den Entitaten besser zu kennzeichen, wurde, in Abweichung zu Chen,

die”ist ein“-Beziehung mit einer gestrichelten Linie markiert.

Das Datenmodell stellt unterschiedliche technische Anforderungen, an das Persistieren der

Daten. Diese sollen in den nachfolgenden Unterkapiteln diskutiert werden.

4.2.1 Trade-, Order- und Kontodaten

Bei den Trade-, Order1- und Kontodaten handelt es sich um gut strukturierte Daten, die leicht

zu normalisieren sind. Einzige Besonderheit ist, dass eine Transaktionsbehandlung benotigt

wird. So besteht z.B. ein PAMM-Trade aus vielen einzelnen Trades und damit eine Aktion zum

Speichern auch aus einzelnen Speicheroperationen, die gemeinsam ausgefuhrt und abgeschlossen

werden mussen. Nur dann ist die Konsistenz und Integritat der Daten gewahrleistet.

1Der Begriff der Order wird ab hier in zwei verschiedenen Zusammenhangen verwendet. Eine Order ist zumeinen ein Auftrag an das System, einen offenen Trade zu andern oder zu schließen. Zum Anderen kann ein Tradevom Typ: Pending Order oder Market Order sein.


Damit eignen sich insbesondere relationale Datenbanken fur die Benutzung als Speicherlo-

sung. Diese sind durch den Einsatz von Index- und Caching-Mechanismen, anderen Losungen

wie z.B. dem Datei-basierten Speichern uberlegen und bieten meist eine Transaktionsverwal-

tung. Weiterhin skalieren Datenbanken sehr gut mit wachsenden Anforderungen, da Sie auf

extra Rechner verlagert und geclustert werden konnen.

Aus diesem Grund, wird sich fur eine relationale Datenbank als Speicherlosung entschieden,

genauer MySQL mit der Speicher Engine: InnoDB2. Die Wahl fiel hierbei auf die InnoDB, da

sie im Gegensatz zu MyISAM Transaktionen unterstutzt.

4.2.2 Parameterdaten fur automatische Handelssysteme

Die automatischen Handelssysteme haben eine unterschiedliche Anzahl von Einstellungspara-

metern, mit einem vorgegeben Satz von unterschiedlichen Basis-Datentypen. Diese Parameter

werden im Diagramm C.8 als payload bezeichnet.

Das Problem ist hier, dass sich eine von System zu System unterschiedliche Anzahl der

Einstellungsparameter mit jeweils unterschiedlichen Datentypen nicht so einfach in einer rela-

tionalen Datenbank abbilden lasst. Eine Moglichkeit ware das Umwandeln der Parameter-Daten

in einen String, wobei die einzelnen Parameter durch einen Delimeter getrennt sind. Eine weitere

Moglichkeit ware das Umwandeln in Binardaten und das Abspeichern als BLOB3.

Da diese Daten dann Key-Value-Paare darstellen, konnte auch das Verwenden darauf spezial-

isierter Key-Value- oder auch NoSQL-DB genannten Datenbanken, wie z.B. BerkleyDB, Mon-

goDB oder CouchDB, in Betracht gezogen werden. Bei der geringen Anzahl von Datensatzen

wurde sich eine Datenbank nur fur die Parameter-Daten der Handelssysteme allerdings nicht

lohnen.

Es wurde sich schliesslich fur das Speichern als serialisierte Objekte entschieden, da keine

besonderen Anforderungen vorliegen, die den Einsatz von anderen Speicherformen rechtfertigen

wurden.

4.2.3 Tick- und Bardaten

Wie bereits beschrieben, werden die fur Bars4 benotigten Preise: Open, High, Low und Close

aus der Analyse von Rohdaten, den Tick-Daten, gewonnen. Diese Daten werden von den au-

tomatischen Handelssystemen und den Indikatoren benotigt.

Eine Besonderheit ist, dass z.B. Indikatoren immer Zugriff auf die aktuellen und die his-

torischen Daten fur einen bestimmten Zeitraum benotigen. So braucht ein 200er Moving Aver-

age auf Tagesbasis immer Zugriff auf die letzten 199 Tagesbars und auf den aktuellen Tagesbar,

2siehe [MySb]

3BLOB (binary large object) ist ein MySQL-Datentyp zum Abspeichern von Binardaten, siehe [MySa].

4Anstatt Candlestick wird ab jetzt der Begriff Bar verwendet. Beide stellen Container fur die Preise: Open,High, Low und Close dar und konnen deshalb in diesem Kontext synonym verwendet werden.


um den aktuellen Moving Average zu berechnen. Um ad hoc die Moving Average Werte fur

die letzten 4 Bars zu berechnen, mussten also die Tickdaten der letzten 204 Tage ausgewertet

werden.

Nun ist es kein Problem die Tick-Daten in einer relationalen Datenbank zu speichern. Da-

raus dann mit Hilfe von SQL-Abfragen die Bars zu extrahieren, ware allerdings eine denkbar

langsame Losung, bei ca. 100.000 Ticks pro Tag, pro Wahrungspaar.

Eine einfachere und effizientere Losung ist das Berechnen der Bars anhand der laufenden

Tickdaten. Dabei wird, um bei den Tagesbars zu bleiben, fur jeden Tag um 0 Uhr ein neuer

Bar erstellt und der alte Bar gespeichert. Der neue Bar speichert bei Eroffnung den aktuellen

Marktpreis als Open-, High-, Low- und Close-Preis. Bei jedem Tick wird der Close-Preis gesetzt

und gepruft ob ggf. auch High und Low neu gesetzt werden mussen. Da diese Operationen im

Arbeitsspeicher ablaufen, sind Sie sehr schnell, auch der Speicherverbrauch ist sehr gering. Das

wird fur alle geforderten Zeitebenen und Wahrungspaare gemacht. Diese Bar-Daten konnten in

einer Datenbank gespeichert werden.

Alternativ konnten Tickdaten in Dateiform gespeichert und verschiedene Losungen, wie

z.B. Apache Hadoop (Eine Implementierung, des von Google veroffentlichten Map-Reduce-

Verfahrens), der Rapidminer von Rapid-I oder die Programmiersprache R verwendet werden

(siehe [Apab], [Whi10], [Rap] und [R F]). Diese sind fur die Analyse großer Datenmengen

optimiert. Aus Zeitgrunden konnten sie jedoch nicht mehr evaluiert werden.

Aus Performancegrunden wird deshalb eine Speicherlosung auf Dateibasis einer Datenbank-

losung vorgezogen. Dazu wird fur jedes Wahrungspaar ein Ordner angelegt und darin fur jede

Zeitebene eine Datei angelegt. In der Datei werden die Bar-Daten, nach Datum sortiert, in Form

von Binardaten gespeichert. (Mit dieser Losung kann auf Indizes verzichtet werden, außer-

dem belegen Binardateien weniger Speicherplatz als Textdateien.) Als Zugriffsmethode wird

die NIO-API gewahlt, da diese performanter als die IO-API ist. Beide sind Java-APIs zum

Lesen/Schreiben von Daten aus/in Dateien oder Sockets, wobei NIO erst seit dem JDK 1.4

eingesetzt werden kann und unter anderem Locking (Sperrt den Zugriff auf eine Datei durch

andere Prozesse) unterstutzt. Durch Locking-Mechanismen muss die Integritat und Konsistenz

der Daten sichergestellt werden.

4.3 Kommunikationsprotokoll

Als Mittel fur die Kommunikation zwischen Client und Server wurde sich fur ein asynchrones

Kommunikationsprotokoll entschieden. Diese beruhen auf dem Versenden von Nachrichten und

eignen sich insbesondere fur Ereignis gesteuerte Systeme und fur langer laufende Operatio-

nen, wenn die zu ubertragenden Daten nicht sehr groß sind. Außerdem lasst sich synchrone

Kommunikation - also der Aufruf von entfernten Methoden - mit temporaren Warteschlangen

simulieren.


Als Framework wurde sich fur den Java Messaging Service5 (JMS) entschieden. JMS seria-

lisiert die Nachrichten, im Gegensatz zu XML-Protokollen wie dem synchronen SOAP, die vom

Nachrichten-Broker je nach Anwendungszweck persistiert werden. JMS skaliert sehr gut, ist

clusterfahig und unterstutzt Transaktionen. Tritt z.B. beim Abholen einer Nachricht ein Fehler

auf, so bleibt diese beim Message-Broker und kann erneut abgeholt werden.

Als weitere Moglichkeiten, wurden Apache MINA und insbesondere das JBoss Netty-Project,

in Verbindung mit Google Protobuf (Serialisiert Daten in einem besonders kompakten Format.),

in Betracht gezogen (siehe [Apac], [JBo] und [Gooa]). Beide werden als hoch performant be-

trachtet. So ergeben sich bei Netty in Verbindung mit Google Protobuf, Nachrichten die einen

geringeren Speicherverbrauch als JMS-Nachrichten haben und schneller serialisiert und deseri-

alisiert werden6. Aufgrund des hohen Implementierungsaufwands wurde jedoch JMS bevorzugt.

5siehe [Apaa] und [Abt10] Seite 281 ff.

6siehe [eis], ein aufgrund vorhandenem Source-Code nachvollziehbarer Vergleich zwischen Protobuf-, XML-und Java-Serialisierung

Kapitel 5

Implementierung

Die im Rahmen dieser Arbeit erstellte Anwendung ist eine verteilte, komponentenbasierte An-

wendung. Die einzelnen Komponenten sind durch Schnittstellen und den Event-Admin-Service

lose gekoppelt (siehe Komponenten-Diagramm1, Seite 67). In diesem Kapitel wird die Anwen-

dung und die Implementierung der wichtigsten Komponenten beschrieben.

5.1 Events

Mit Hilfe des Event-Admin-Service werden Ergebnisse von Client-Auftragen und Sta-

tusanderungen in Form von Events verteilt. Die Events werden in TradingsystemEvent, Ac-

countEvent und OrderEvent unterschieden und uber unterschiedliche Topics publiziert. Die

jeweiligen Auspragungen wurden in Form von Enumerations abgebildet (siehe Klassendiagramm

C.9, Seite 66).

Die Events werden auf Serverseite publiziert, dabei regeln die Komponenten Event-To-JMS

und JMS-To-Event die Ubermittlung an den Client. Es werden allerdings nur die fur den Client

wichtigen Events ubertragen.

Event-To-JMS registriert sich als Eventhandler und wandelt alle im Event enthaltenen

Objekte in DTOs um, die nur aus Basisdatentypen bestehen. Auf das Serialisieren der ur-

sprunglichen Objekte wurde verzichtet2, um die Kommunikation unabhangig von Java zu halten

(Der verwendete JMS-Broker erlaubt auch C++, C#, Ruby, Perl, Python und PHP-Clients).

JMS-To-Event stellt daraus das ursprungliche Event wieder her und publiziert es auf Client-

seite. Dadurch kann das Kommunikationsprotokoll fur das Verteilen von Events jederzeit aus-

getauscht werden.

1Auf die Darstellung des Logging-Dienstes wurde aus Grunden der Ubersichtlichkeit verzichtet, da er vonfast jeder Komponente verwendet wird.

2Das gilt auch fur vom Client ubertragene Order und an den Client ubersandte Tick-Daten

KAPITEL 5. IMPLEMENTIERUNG 36

1 HashMap <String , Object > eventProperties = new HashMap <String , Object >();

2 eventProperties.put(APIService.ORDER_EVENT ,OrderEvent.TRADE_CLOSED );

3 eventProperties.put(APIService.SINGLE_ACCOUNT_ID ,accountID );

4 eventProperties.put(APIService.EVENT_DATE , new Date(System.currentTimeMillis ()));

5 Event event = new Event("de/pammtrader/core/api/single_order/FXCM", eventProperties)

Listing 5.1: Beispiel fur ein Trade-Closed-Event

Das Listing 5.1 zeigt beispielhaft ein Event, das beim Schließen eines Einzeltrades ausgelost

wird. Das Event enthalt eine Hashmap und ein Topic. Die Hashmap(Listing 5.1, Zeilen 1-4)

enthalt das ausgeloste Event und dazu gehorige Daten.

In diesem Beispiel wird nur die ID des zum Event gehorigen Objekts ubermittelt. Bei Events

wo Java-Objekte neu erstellt wurden, ist das komplette Java-Objekt in der Hashmap enthalten,

also bei neuen Trades, Orders und neuen Konten. Anhand des Topics (Listing 5.1, Zeile 5) lasst

sich ermitteln, dass es sich bei dem geschlossenen Trade um einen Trade fur ein Einzelkonto

beim Broker FXCM handelt.

5.2 Client

Der Client basiert auf der Eclipse RCP. Er besteht zum einen aus den Komponenten JMS-To-

Event und JSM-To-Tick, die fur die Verteilung von Events und Tick-Daten zustandig sind. Zum

anderen aus dem Controller und GUI-Elementen. Die GUI-Elemente implementieren die Inter-

faces IAccountListener und/oder ITickListener und registrieren sich als Dienste (Whiteboard-

Pattern) um uber das Eintreffen von Trade-, Konto- und Tickdaten informiert zu werden. Liegen

neue Daten vor, so greifen sie darauf uber Content-Provider zu.

Der Controller implementiert das Interface IAccountDAO und dient dem Zugriff auf Trade-

und Konto-Daten und dem Absetzen von Auftragen an den Server. In den folgenden Un-

terkapiteln, wird die Benutzeroberflache des Clients kurz naher erlautert.

5.2.1 Login-Ansicht

Abbildung 5.1: FxTrader Client - Login

Nach dem Start der Client-Anwendung offnet sich als erstes das Login-Fenster (siehe Abbil-

dung 5.1). Hier muss die Server-Adresse inklusive des Ports vom JMS-Broker angegeben werden.


Bei einer lokalen Installation ware”localhost:61616“ ein valider Wert, wenn der Standardport

benutzt wird.

Konnte die Verbindung zum Server hergestellt werden, dann initialisiert die Anwendung

Kontodaten, Tradedaten und Handelssystemdaten. Dazu wird ein RPC simuliert, indem eine

temporare Warteschlange (Queue) erzeugt wird. Im Nachrichten-Header”JMSReplyTo“ wird

dieser als Anwort-Queue gesetzt und dem Server bei der Anfrage ubermittelt. Nachdem der

Server geantwortet hat, werden die Daten initialisiert. Dann tragt sich die Anwendung als

Empfanger von Tickdaten und Events in die entsprechenden Topics ein, und startet die Haup-

tansicht.

5.2.2 Hauptansicht

Symbolübersicht

Kontenübersicht

Handelssysteme

Tradeübersicht

Abbildung 5.2: FxTrader Client - GUI

Die Benutzeroberflache (siehe Abbildung 5.2) wurde nach der Workbench-Metapher3 gestal-

tet und ist in Menuzeile, Toolbar und Hauptfenster unterteilt. Die in den Usecases definierten

Aktionen konnen entweder uber Kontextmenus, Menuzeile oder Toolbar ausgelost werden. Diese

Aktionen sind meist nur erlaubt, wenn ein dazu passendes Element ausgewahlt wurde. So muss

z.B. um einen Trade auszulosen ein PAMM-Konto ausgewahlt werden. Das Hauptfenster ist un-

terteilt in Symbolubersicht, Kontenubersicht, Tradeubersicht und einer Ubersicht aller laufend-

en automatischen Handelssysteme.

3siehe [Rei09] Seite 52ff


5.2.2.1 Symbolubersicht

Die Symbolubersicht soll dem Benutzer eine Marktubersicht geben und zeigt alle handelbaren

Wahrungspaare, mit aktuellen Bid- und Ask-Preisen. Symbole konnen der Liste hinzugefugt

und aus ihr entfernt werden.

5.2.2.2 Kontenubersicht

Die Kontenubersicht stellt PAMM-Konten und darin enthaltene Einzelkonten in einer

Baumubersicht dar. Hier konnen PAMM- und Einzelkonten angelegt und geloscht werden.

Außerdem konnen PAMM-Trades ausgelost werden, allerdings nur wenn alle darin enthalte-

nen Einzelkonten online sind. Einzelkonten werden mit einem roten Symbol, wenn sie offline

sind, oder mit einem grunen Symbol, wenn sie online sind, dargestellt.

5.2.2.3 Tradeubersicht

In der Tradeubersicht werden nach PAMM-Konten getrennt offene und bereits geschlossene

PAMM-Trades angezeigt. Sie wird durch einen Doppelklick auf ein PAMM-Konto in der Kon-

tenubersicht geoffnet. Bei offenen Trades konnen nachtraglich Stop- und Limit-Preis gesetzt

bzw. geandert werden. Weiterhin konnen hier Trades geschlossen werden.

5.2.2.4 Automatische Handelssysteme

Hinweise für den Benutzer

Abbildung 5.3: FxTrader Handelssysteme - Eingabe von Parametern

Diese Ubersicht zeigt alle offenen Handelssysteme an, sie konnen hier gestartet und gestoppt

werden. Um ein Handelssystem zu starten, wird ein Wizard (siehe Abbildung 5.3) geoffnet.

Auf der ersten Seite wird das Handelssystem ausgewahlt und allgemein gultige Parameter, also

Wahrungspaar, Zeitebene und Konto, eingegeben. Die nachste Seite wird anhand der vom Han-

delssystem vorgegebenen Parameter erstellt. Es werden automatisch, fur Java-Basisdatentypen

(außer Boolean), Eingabefelder und fur Parameter mit vorgegebenen Auswahlmoglichkeiten


(inklusive Boolean) Dropdown-Listen erstellt. Der Wizard uberpruft die Eingaben auf Validi-

tat, fuhrt die Konvertierung durch und gibt dem Benutzer verschiedene Hilfestellungen in Form

von Popup-Meldungen und Hinweisen im oberen Bereich.

Sind alle Einstellungen valide, dann kann der Wizard abgeschlossen und die Daten an den

Server gesendet werden. Der Server initialisiert und startet dann das Handelssystem.

5.3 Server

Der Server basiert auf OSGi, siehe Komponentendiagramm C.10, Seite 67. Die Server-

Komponenten werden jeweilig in Form von Bundles ausgeliefert, dabei sind Schnittstellen und

Implementierung getrennt. Die Schnittstellen der Server-Komponenten finden sich in Klassendi-

agrammen auf den Seiten 69 und 70, letztere enthalt zusatzlich die Klassen der Handelssysteme

und Indikatoren. In diesem Kapitel wird auf die Implementierung eingegangen.

Anmerkung: Der im Diagramm C.10 gezeigte JMS-Broker wird in Form eines Bundles aus-

geliefert. Hier wird nur ein Objekt vom Typ”org.apache.activemq.broker.BrokerService“ ini-

tialisiert und der Dienst gestartet, auf eine weitere Beschreibung wird deshalb verzichtet.

5.3.1 Broker-APIs

Die APIs der Broker Dukascopy und FXCM wurden implementiert. Sie werden jeweils in einem

OSGi-Bundle ausgeliefert, das aus Bundle-Activator, API-Controller, der Broker-API und einer

Klasse fur ein Einzelkonto dieses Brokers besteht.

Der Bundle-Activator erstellt beim Start des Bundles ServiceTracker fur LogService, Event-

admin und ITickReceiver (siehe Listing 5.2, Zeilen 2-4). API-Controller und Konten greifen uber

entsprechende Methoden auf diese Services zu, um zu loggen und um Events und Tickdaten

zu versenden. Weiterhin initialisiert er den API-Controller und registriert ihn als Dienst unter

dem Interface APIService (siehe Listing 5.2, Zeilen 5-10).

1 ServiceTracker tickListenerTracker = new ServiceTracker

2 (context ,ITickReceiver.class.getName(), null);

3 tickListenerTracker.open ();

4 DukascopyAPIService dukascopyApi = new DukascopyAPIService ();

5 Dictionary <String , String > properties = new ...

6 properties.put(APIService.BROKER_API , DukascopyAPIService.SERVICENAME );

7 bundleContext.registerService(APIService.class.getName(), dukascopyApi , properties );

Listing 5.2: Ausschnitt aus Bundle-Activator einer Broker-API

Beim Registrieren wird eine Service-Property ubergeben, die den Namen des Broker enthalt,

dadurch lassen sich die Broker-Dienste nach Namen filtern. Der API-Controller fungiert als Fas-

sade, erstellt Einzelkonten und steuert den Zugriff darauf. Er vermittelt durch Transformation

der Daten, zwischen dem eigenen System und dem Broker-System. So versteht z.B. Dukascopy

unter einem Lot nicht 100.000$ sondern 1.000.000$ und bildet ein Wahrungspaar uber die eigene

Klasse Instrument ab, was hier entsprechend umgewandelt wird.


Jedes Einzelkonto wird Broker-spezifisch abgebildet, stellt unabhangig von anderen Konten

eine Verbindung zum Broker her und bleibt aus Performancegrunden immer verbunden. Sie leit-

en die Auftrage des API-Controller an den Broker weiter und publizieren uber Events wie, wann

und ob diese Auftrage abgewickelt wurden. Außerdem publizieren Sie sofort das Andern von

Konto- und Tradestatus und das aktuelle Kontoguthaben. Das Kontoguthaben wird allerdings

in einem Intervall von 10 Sekunden publiziert. Erst mit dem Publizieren des Kontoguthabens

wird dieses Konto als online betrachtet, um die korrekte Verteilung von PAMM-Trades nach

Kontogrosse zu gewahrleisten. Jedes Einzelkonto verarbeitet Auftrage uber einen eigenen”Sin-

gleThreadExecutor“4, dadurch wird der API-Controller nicht blockiert.

Jedes Einzelkonto kann weiterhin als Publisher von Tick-Daten fungieren, was im

Komponenten-Diagramm (Seite 67) als Live-Datafeed-Publisher dargestellt wird. Der Publisher

wird durch den PAMM-Controller gewahlt und veroffentlicht Tickdaten, an alle Dienste, die

sich unter dem Interface ITicklistener angemeldet haben, nach dem Whiteboard-Pattern. Geht

das Einzelkonto offline, dann findet eine Neuwahl des Publisher durch den PAMM-Controller

statt. Da alle Einzelkonten, egal welcher Broker, als Publisher fungieren konnen, wird die Aus-

fallsicherheit dieses Dienstes erhoht.

5.3.2 PAMM-Controller

Der PAMM-Controller implementiert die Interfaces EventHandler, IPAMMAccountController

und IPAMMTradeController und registriert sich als Dienst unter diesen Interfaces. Beim Starten

ladt er Trade und Kontodaten vom DAO-Service. Er ist der Mediator zwischen Client-Auftragen

und Broker-API-Controller. Wird z.B. ein PAMM-Trade ausgelost, dann splittet er diesen in

Einzeltrades auf und verteilt sie an die entsprechenden Broker-API-Controller. Er verwaltet die

PAMM-Konten, Einzelkonten, PAMM-Trades und Einzeltrades. Er pflegt die jeweilig moglichen

Zustande, also OrderStatus, AccountStatus, Tradestatus, indem er Events auswertet, genauer

AccountEvents und OrderEvents (siehe Klassendiagramm, Seite 66).

Der PAMM-Controller erstellt einen ServiceTracker um das Registrieren und Deregistrieren

von Broker-API-Controllern zu uberwachen. Geht ein solcher Controller online, dann initialisert

er diesen mit Konto- und Trade-Daten. Geht ein Controller offline, dann setzt er bei allen

dazugehorigen Einzelkonten den Status auf offline.

In dem Aktivitatsdiagramm (Abbildung C.11, Seite 68) wird exemplarisch das Verarbeiten

eines neuen PAMM-Trades5 dargestellt. Hier werden die einzelnen Vorgange bei der Verar-

beitung und das Auslosen von Events gezeigt, aus Platzgrunden musste auf das Darstellen der

Bearbeitung von Events verzichtet werden.

4siehe [Oraa]

5Unter der Vorbedingung, dass der Trade die in Tabelle 2.1 auf Seite 9 dargestellten Bedingungen erfullt


5.3.3 Account-, Trade-DAO-Service

Wird ein neuer Trade oder ein neues Konto erstellt, so wird das dazugehorige Java-Objekt uber

ein entsprechendes Event verteilt. Der DAO-Service registriert sich als Eventhandler und nimmt

selbstandig das Speichern dieser Objekte vor, weiterhin verarbeitet er Anderungen von Trade-

und Kontozustanden und speichert sie ab.

Die Verbindung zum SQL-Server wird uber einen Connectionpool6 hergestellt. Dieser halt

immer eine einstellbare Anzahl von Verbindungen offen und offnet bei Bedarf weitere Verbin-

dungen bzw. schließt diese wieder bei Nichtbenutzung. Dadurch muss nicht fur jeden SQL-Befehl

eine Verbindung aufgebaut werden, was relative lange dauern kann und die Performance be-

eintrachtigen wurde. SQL-Befehle werden in Rahmen von Transaktionen, um Integritat und

Konsistenz der Daten sicherzustellen abgesetzt. Dazu werden Prepared Statements benutzt,

um die Performance zu erhohen.

5.3.4 History-Provider

1 FileChannel output = new RandomAccessFile(getFilename(bar), "rw"). getChannel ();

2 long start = output.size()- BAR_SIZE_IN_BYTES;

3 FileLock lock = output.lock(start ,BAR_SIZE_IN_BYTES , false);

4 ByteBuffer mapByteBuffer = output.map(FileChannel.MapMode.READ_WRITE , start , BAR_SIZE_IN_BYTES );

5 mapByteBuffer.putLong(bar.getOpenDate (). getTime ());

6 ...

7 mapByteBuffer.flip ();

8 output.position(output.size()- BAR_SIZE_IN_BYTES );

9 output.write(mapByteBuffer );

10 output.close ();

Listing 5.3: Updaten eines Bars mit der NIO-API

Der History-Provider ist ein Dienst zum Bereitstellen von historischen Preisdaten, fur die in

den Anforderungen genannten Wahrungspaare und Zeitebenen. Er implementiert die Interfaces

IBarProvider und ITickReceiver.

Der History-Provider baut die History-Daten anhand der Tickdaten auf, wie im vorherigen

Kapitel beschrieben. Der letzte Bar befindet sich immer im Arbeitsspeicher und wird durch

die Tickdaten aktualisiert, dabei wird alle 10 Sekunden ein Backup durchgefuhrt. Wird der

aktuelle Bar von anderen Komponenten benotigt, so wird eine Kopie dieses Bar als Antwort

ubermittelt, wahrend History-Daten aus der Datei geladen werden.

Das Listing 5.3 zeigt exemplarisch das Updaten des letzten Bars, der sich immer am Ende

der Datei befindet. Im Unterschied zur IO-API, erfolgt der Zugriff auf Dateien uber Channels.

Ein Bar belegt 48 Bytes, also werden die letzten 48 Bytes zum exklusiven Schreiben/Lesen

geblockt. Der Bar wird dann in Form von Bytes in einen Buffer geschrieben. Zum Schluss

wird die Position des Buffers auf 0 zuruckgesetzt und der Buffer in die Datei geschrieben.

6siehe [Comb] und [Coma]


Durch das Schließen des Channels wird die Datei wieder freigegeben. Durch das Locking von

Dateiabschnitten ist es moglich, gleichzeitig in die Datei zu schreiben und daraus zu lesen, ohne

dass sich diese Prozesse behindern.

5.3.5 Indikatoren

Indikatoren (siehe Seite 70) erweitern die abstrakte Klasse Indicator und werden zusammen in

einem Bundle ausgeliefert. Um neue Indikatoren zu installieren, muss dieses Bundle geupdatet

werden. Indikatoren konnen nur uber statische Methoden der Klasse Indicators bezogen werden.

Die Klasse Indicator implementiert das Interface ITickReceiver und ruft bei jedem neuen

Tick die abstrakte Methode”calculateIndicator“ auf. Hier findet dann die Berechnung des

aktuellen Indikatorwertes statt. Wird ein Indikator gestartet, so bezieht er History-Daten vom

IBarProvider und beginnt mit der Berechnung der Indikatorenwerte. Fur die Berechnung werden

die benotigten Bardaten im Arbeitsspeicher gehalten und mit Hilfe der Tickdaten selbstandig

gepflegt, was auch in der Klasse Indicator geregelt ist.

5.3.6 Handelssysteme

Handelssysteme konnen eine Vielzahl von Einstellungs-Parametern haben. Fur die Parameter

und das Handelssystem wurden Java-Annotationen definiert. Die Methoden zum Setzen dieser

Parameter und die Klasse des Handelssystems mussen durch Java-Annotationen gekennzeichnet

werden. In der Annotation werden die zur Beschreibung des Parameters benotigten Werte und

etwaige Standardwerte festgelegt (siehe Listing 5.4). In der Annotation der Klasse wird der

Name und die Beschreibung des Handelssystem festgelegt.

1 @Retention( RetentionPolicy.RUNTIME ) @Target( value=METHOD )

2 public @interface ITradingSystemInputParam {

3 String InputParametername ();

4 String InputDescription () default "";

5 String [] AllowedStringValues () default {""};

6 int MinValue () default Integer.MIN_VALUE;

7 int MaxValue () default Integer.MAX_VALUE; }

Listing 5.4: Annotation fur eine Methode

Handelssysteme (siehe Seite 70) konnen in unterschiedlichen Bundles ausgeliefert werden, die

ein oder mehrere Handelssysteme und eine Factory enthalten. Handelssysteme implementieren

das Interface ITradingsystem und werden durch die Factory erzeugt, die das Interface ITrad-

ingSystemFactory implementiert und sich als Service registriert.

Die Factory analysiert beim Starten des Bundles die darin enthaltenen Java-Klassen und

generiert daraus die TradingSystemDescription. Zum Analysieren wird die Java-Reflection-Api

benutzt. Listing 5.5 zeigt ausschnittsweise wie alle Methoden der Klasse untersucht werden

und daraus die Systembeschreibung generiert wird. Diese Losung hat den Vorteil, dass jed-


erzeit neue Handelssysteme zu einem Bundle hinzugefugt werden konnen, ohne dass weitere

Konfigurationen notwendig sind.

1 Class <?> clazz = bundle.loadClass(fullClassName ); ...

2 Method [] methods = clazz.getMethods ();

3 for(Method method : methods)

4 {

5 if(method.isAnnotationPresent(ITradingSystemInputParam.class))

6 {

7 ITradingSystemInputParam methodAnnotation = method.getAnnotation

8 (ITradingSystemInputParam.class );

9 TradingSystemParameterDescription param = new TradingSystemParameterDescription

10 (method.getName(), inputType , methodAnnotation.InputParametername (),

11 methodAnnotation.InputDescription ());

12 ...

Listing 5.5: Annotation fur eine Methode

Der TradingSystemController implementiert das Interface ITradingSystemController und

uberwacht sich an-/abmeldende ITradingSystemFactories, um die Beschreibung zu laden und

systemweit zu publizieren. Mit Hilfe dieser Beschreibung kann dann auf Clientseite der Wizard

generiert werden. Der TradingSystemController initialisiert, startet und stoppt die Handelssys-

teme. Beim Starten des Handelssystems ubergibt er den ITradingSystemContext, uber den das

Handelssystem auf PAMM-Konto und History-Daten zugreift.

5.3.6.1 Installieren von Handelssystemen

Bundles konnen uber die OSGi-Konsole installiert werden. Diese Bundles konnen auf der Fest-

platte des Rechners oder z.B. auf einem Webserver liegen. Das Listing 5.6 zeigt das Installieren

und Starten eines Handelssystems, dessen JAR-Datei sich auf der lokalen Festplatte befindet.

1 osgi > install file:c:\ Pfad_zur_Datei\de.tradingSystem.jar

2 Bundle id is 38

3 osgi > start 38

4 Starting de.tradingSystem

Listing 5.6: Handelssysteme installieren

5.3.6.2 Beispiel fur ein Handelssystem

Zum Abschluss zeigt das Listing 5.7 einen Ausschnitt aus einem Handelssystem. Bei jedem Tick

pruft das System, ob sich schneller und langsamer Moving Average gekreuzt haben und erofnet

gegebenenfalls eine neue Position.


1 MovingAverage slowAVG = Indicators.MovingAverage(Timeframe.D1 , Symbol.EURUSD ,

2 200, "SMA", 2);

3 MovingAverage fastAVG = Indicators.MovingAverage(Timeframe.D1 , Symbol.EURUSD ,

4 50, "SMA", 2);

5 public void onUpdate(Tick tick)

6 {

7 List <PAMMTrade > tradeList = context.getOpenTrades(Symbol.EURUSD );

8 if(tradeList !=null && tradeList.size ()==0)

9 {

10 if(fastAVG.getValue (1)< slowAVG.getValue (1) &&

11 fastAVG.getValue (2)> slowAVG.getValue (2))

12 {

13 Bar actualBar = context.getBar(Symbol.EURUSD , Timeframe.D1);

14 double closePrice = actualBar.getClose ();

15

16 context.openTrade(magicNumber , TradeType.SELL , Symbol.EURUSD ,

17 1, closePrice -0.01 , closePrice +0.01 , closePrice );

18 } ...

Listing 5.7: Beispiel fur ein Handelssystem

Kapitel 6

Software-Test

In Rahmen von Tests sollte uberpruft werden, ob die Anwendung die in der Anforderungs-

analyse ermittelten funktionalen Anforderungen erfullt. Dazu wurden Tests der grafischen Be-

nutzeroberflache (GUI) und Funktionstests automatisiert durchgefuhrt. In GUI-Tests wurden

die wesentlichen Funktionen des Benutzerinfaces und die korrekte Ausfuhrung auf Clientseite

betrachtet. Im Rahmen der Funktionstests, wurden die Schnittstellen der Serverkomponenten

untersucht und wie die einzelnen Komponenten auf die Ausfuhrung reagieren. Außerdem wur-

den Skalierbarkeits-Tests durchgefuhrt um Hardwareanforderungen abzuschatzen.

In diesem Kapitel, wird der Entwurf der zu automatisierenden Tests, Ausfuhrung und Ergeb-

nisse der Tests beschrieben. Die Testfalle entsprechen den Anwendungsfallen, die in der An-

forderungsanalyse ermittelt wurden.

6.1 Testumgebung

Die Tests wurden auf einem Rechner mit einem Intel Core i7-860 Prozessor und 8GB RAM

unter Windows 7 x64 ausgefuhrt. Client-, Server-Anwendung, JMS-Broker und MySQL-Server

liefen wahrend der Tests auf diesem Rechner. Als JMS-Broker wurden ActiveMQ in der Version

5.4.2 und MySQL in der Version 5.1 verwendet. Die Tests wurden unter Eclipse 3.6 als JUnit-

Plugin-Test bzw. als SWTBot-Test ausgefuhrt.

6.2 GUI-Test

Zum Testen des GUI wurden der WindowTester Pro [Goob] von Google und SWTBot (siehe

[Eclb], [Rei09] Seite 217ff) von Eclipse evaluiert. Beide sind kostenlos einsetzbar und erlauben

das externe Testen von SWT-Anwendungen, d.h. sie agieren wie ein Benutzer und fuhren Aktio-

nen durch Anklicken von UI-Objekten aus. Sie identifizieren die einzelnen UI-Elemente anhand

von IDs und Labels, also nicht anhand ihrer Position. Dadurch bleiben Testfalle auch lauffahig,

wenn die Benutzeroberflache um weitere UI-Elemente erweitert wird. Sie unterscheiden sich

KAPITEL 6. SOFTWARE-TEST 46

dadurch, dass beim WindowTester der erste Testlauf manuell ausgefuhrt und dabei aufgezeich-

net wird. Beim SWT-Bot muss der Tester einen JUnit-Test programmieren.

Zum Testen eignete sich schliesslich nur der SWTBot, da die zu testende Anwendung auch

JFace-Dialoge benutzt, die vom WindowTester nicht unterstutzt werden.

6.2.1 Testobjekte

Im Rahmen von GUI-Tests, wird das gesamte System getestet. Testobjekte sind zum einen

das GUI des Clients, aber auch das Zusammenspiel zwischen Client- und Serverkomponenten.

Ein Anwendungsfall muss uber das GUI auslosbar sein und einen entsprechenden Request an

den Server senden. Dieser muss die Aufgabe bearbeiten und Fehler- bzw. Erfolgsmeldungen

zurucksenden, die vom Client verarbeitet und auf der Benutzeroberflache dargestellt werden.

Ein Test gilt als bestanden, wenn als Ergebnis des Funktionsaufrufs vom Server ein

entsprechendes Event empfangen, vom Controller umgesesetzt und in der GUI angezeigt wurde.

Ein Test gilt, nach einem Timeout von 5 Sekunden, als nicht bestanden, wenn ein Element vom

SWTBot nicht gefunden wurde bzw. der Server nicht wie erwartet geantwortet hat.

6.2.2 Durchfuhrung

Um die Tests vorzubereiten musste der Login-Dialog deaktiviert werden, da er vor der Applica-

tion startet und damit auch vor SWTBot. Fur die Durchfuhrung der Tests wurde ein Projekt fur

ein SWTBot Test-Plugin erstellt. Bei der Erstellung der Testfalle musste dann berucksichtigt

werden, dass Ergebnisse erst nach einer gewissen Zeit vorliegen, da alle Methodenaufrufe zum

Erstellen/Loschen von Konten, Trades etc. asynchron sind.

1 public CreateAccountTest(String accountName)

2 { this.accountName = accountName; }

3 @BeforeClass

4 public static void setup()

5 { this.bot = new SWTWorkbenchBot (); }

6 @Parameterized.Parameters

7 public static List <Object[]> data()

8 { return Arrays.asList(new Object [][] {{"test1"}, {"test2"}}); }

9 @Test

10 public void canCreatePAMM () throws Exception {

11 bot.menu("Konten").menu("PAMM erstellen").click ();

12 bot.shell("Erstelle PAMM");

13 SWTBotText textField1 = bot.textWithLabel("Name:");

14 textField1.setText(accountName );

15 bot.button("OK"). click ();

16 }

Listing 6.1: SWTBot-Test - Testfall: Erstellen eines PAMM-Kontos

Das Listing 6.1 zeigt ausschnittsweise den Testfall: PAMM-Konto erstellen. Vor jedem Test-

lauf werden eventuell benotigte Objekte wie z.B. der SWTBot oder Testobjekte initialisiert.


Der eigentliche Testlauf (siehe Zeilen 12-19) geht dann wie ein Benutzer vor, indem er das

Menu anklickt und in das sich offnende Dialogfenster entsprechende Daten eingibt.

6.3 Funktionstests

Die Serverkomponenten wurden im Rahmen von Funktionstests als JUnit-Tests durchgefuhrt.

Hier wurde die korrekte Ausfuhrung von Funktionsaufrufen in Form von Blackbox-Tests

uberpruft. Das heisst, dass die Schnittstellen-Methoden der Komponenten aufgerufen und deren

Ruckgabewerte beziehungsweise das Auslosen von Events gepruft wurde. Ausserdem wurde das

korrekte Abspeichern uber”pruft. So mussen z.B. nach dem Erstellen eines PAMM-Kontos ein

Event ausgelost und die Kontodaten in der Datenbank gespeichert werden.

6.4 Ergebniss von GUI- und Funktionstests

Im Rahmen der Tests stellte sich heraus, dass die Vorbedingungen zum Loschen von Einzel-

und PAMM-Konten noch nicht gepruft werden. Als schwerwiegender stellte sich heraus, dass

der Handel von mehreren FXCM-Konten auf einem Rechner, zumindest mit der derzeitigen

Implementierung, nicht mehr moglich ist. So lasst sich seit dem Update der API vom 1.4.2011

nur noch das erste FXCM-Konto handeln. Werden weitere FXCM-Konten hinzugefugt, so stellen

diese zwar eine Verbindung zum Broker her, ein Ausfuhren von Trades ist jedoch nicht moglich

und wird mit einer Fehlermeldung vom Broker quittiert. Aus Zeitgrunden konnte nicht mehr

ermittelt werden, inwieweit sich dieses Problem beheben lasst.

6.5 Skalierbarkeits-Test

Im Rahmen von Skalierbarkeitstests wurde uberpruft, wie sich der Ressourcenverbrauch des

Server-Systems mit steigender Anzahl von Konten verandert. Dazu wurden der Server ohne

Einzelkonten und mit 1, 2 und 5 Einzelkonten gestartet. Nach einer Warmlaufphase von einer

Minute, wurden jeweils der Maximal- und Minimal-Wert fur Arbeitsspeicher und Threads in

einem Zeitraum von 5 Minuten ermittelt. Auf strichprobenartiges Messen wurde verzichtet, da

der Garbage Collector die Messungen verfalscht hatte.

Die bei den Tests ermittelten Werte skalieren linear, da jedes Konto unabhagig von an-

deren Konten eine Verbindung zum Broker herstellt und damit auch gleich viele Threads und

Arbeitsspeicher benotigt. Auffallig ist der dreimal so hohe Verbrauch von Arbeitsspeicher bei

Dukascopy-Konten, im Vergleich mit FXCM-Konten. So muss fur 5 Dukascopy-Konten Ar-

beitsspeicher von ca. 150 MB und bei FXCM-Konten in Hohe von ca. 50 MB kalkuliert werden.

Außerdem benotigen 5 Dukascopy-Konten mit 140 Threads ca. 100 Threads mehr als FXCM-

Konten. Der Unterschied lasst sich damit erklaren, dass die Dukascopy-API verschiedene Funk-

tionialitaten zum automatisierten Handel mitbringt, wahrend die FXCM-API ausschliesslich


Handelsfunktionalitaten beinhaltet. Hier zeigte sich, dass diese APIs nur fur den Handel von

Einzelkonten optimiert sind.

In weiteren Tests musste die Ausfuhrungszeit untersucht werden und wie es sich auswirkt,

wenn pro Broker nur eine Verbindung hergestellt wird bzw. wenn mehrere Konten des selben

Brokers zu Gruppen zusammengefasst werden und diese Gruppen sich jeweils eine Verbindung

teilen. Diese Verbindung musste dann allerdings bei jeder Transaktion auf- und wieder abgebaut

werden, da pro Broker-Verbindung nur ein Konto gehandelt werden kann.

Kapitel 7

Fazit

Abschließend werden die Ergebnisse der vorliegenden Arbeit vorgestellt. Des Weiteren gibt es

einen Ausblick auf mogliche Erweiterungen und zusatzliche Untersuchungen.

7.1 Ergebnisse

Ziel der Arbeit war es, eine Umgebung zum automatisiertem Handel von PAMM-Konten zu

schaffen. Dieses PAMM-Konto sollte Einzelkonten von unterschiedlichen Brokern beinhalten

konnen.

Dazu wurde eine Komponentenbasierte Client-Server-Anwendung entwickelt und die Java-

APIs der Broker FXCM und Dukascopy eingebunden. OSGi und Eclipse RCP bilden die Grund-

lage der ”´Event-Driven-Systemarchitektur“, die sich sehr gut bewahrt hat. Die einzelnen Kom-

ponenten wurden in unterschiedliche OSGi-Bundles aufgeteilt, die uber Schnittstellen und den

Event-Service lose gekoppelt und damit leicht erweiterbar bzw. austauschbar sind.

Das Ziel einer leicht erweiterbaren Plattform wurde also erreicht, aufgrund der neu aufge-

tretenen Probleme bei FXCM wurde das Ziel mehrere Konten unterschiedlicher Broker gle-

ichzeitig zu handeln jedoch nur eingeschrankt erreicht. Aus Zeitgrunden konnten weiterhin die

Kann-Kriterien nicht mehr erfullt werden.

7.2 Ruckblick

Die im Rahmen der Entwurfsphase getroffenen Entscheidungen wurden fur ein System getrof-

fen, das aus einem Anwendungsserver und gegebenenfalls einem Datenbankserver besteht. Sie

wurden aus der Absicht getroffen, die Daten so nah wie moglich bei der Anwendung (und damit

die Latenz gering) zu halten und eine hohe Performance zu erreichen.

Bei steigenden Anforderungen ist es moglich, dass diese Losungen nicht so skalieren wie

es gewunscht oder erforderlich ist. Weiterhin wird man um die Ausfallsicherheit zu erhohen

zentralisierte und clusterfahige Losungen bevorzugen. In diesen Fallen sollten die erwahnten

KAPITEL 7. FAZIT 50

alternativen Losungsansatze in Betracht gezogen werden. Insbesondere scheint hier die Losung

fur die Ermittlung und Pflege der History-Daten problematisch, da sie einen Single Point of

Failure darstellt.

7.3 Ausblick

Um die im Rahmen dieser Arbeit entwicklelte Anwendung marktreif zu machen, mussten die

Probleme beseitigt und Ausfallsicherheit sowie Sicherheit der Daten erhoht werden. Desweiteren

sollte das FIX-Protokoll in Betracht gezogen werden, da hier die Anbindungen an die Broker,

durch eine eigene Implementierung, besser auf die individuellen Anforderungen zugeschnitten

werden konnen.

Weiterhin wunschenswert wahre das Anzeigen von Charts und Indikatoren, z.B. mit Hilfe

des Business Intelligence and Reporting Tools von Eclipse (BIRT Project, [Ecla]). Ausserdem

sollte eine Moglichkeit geschaffen werden, um Handelssysteme und Indikatoren direkt uber die

Anwendung zu erstellen, oder diese aus anderen Brokerprogrammen zu konvertieren.

Literaturverzeichnis

[Abt10] Abts, Dietmar: Masterkurs Client/Server - Programmierung mit Java.

Vieweg+Teubner, 2010

[Apaa] Apache Software Foundation: Apache - ActiveMQ. http://activemq.

apache.org/, Abruf: 21.12.2010

[Apab] Apache Software Foundation: Apache - Hadoop. http://hadoop.apache.

org, Abruf: 22.12.2010

[Apac] Apache Software Foundation: Apache - MINA Project. http://mina.

apache.org/

[Coma] Commons, Apache: Database Connection Pool API. http://commons.apache.

org/dbcp/apidocs/org/apache/commons/dbcp/package-summary.html

[Comb] Commons, Apache: Java Class GenericObjectPool. http://commons.apache.org/

pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html

[Ebe] Ebert, Ralf: RCP Buch - JFace Data Binding. http://www.ralfebert.de/

rcpbuch/jface_data_binding/, Abruf: 27.03.2011

[Ecla] Eclipse Foundation: BIRT Project. http://www.eclipse.org/birt/phoenix/

intro/

[Eclb] Eclipse Foundation: SWTBot. http://www.eclipse.org/swtbot/

[eis] eishay: Protobuf with option optimize for SPEED. http://www.eishay.com/

2008/11/protobuf-with-option-optimize-for-speed.html

[eSia] eSignal: KnowledgeBase: Technical Analysis Dictionary - MACD. http://kb.

esignal.com, Abruf: 13.03.2011

[eSib] eSignal: KnowledgeBase: Technical Analysis Dictionary - Moving Average. http:

//kb.esignal.com, Abruf: 13.03.2011

[FP] FIX Protocol, Ltd: FIX Protocoll - Industry-Driven Messaging Standard. http:

//www.fixprotocol.org/, Abruf: 28.03.2011

http://activemq.apache.org/

http://activemq.apache.org/

http://hadoop.apache.org

http://hadoop.apache.org

http://mina.apache.org/

http://mina.apache.org/

http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/package-summary.html

http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/package-summary.html

http://commons.apache.org/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html

http://commons.apache.org/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html

http://www.ralfebert.de/rcpbuch/jface_data_binding/

http://www.ralfebert.de/rcpbuch/jface_data_binding/

http://www.eclipse.org/birt/phoenix/intro/

http://www.eclipse.org/birt/phoenix/intro/

http://www.eclipse.org/swtbot/

http://www.eishay.com/2008/11/protobuf-with-option-optimize-for-speed.html

http://www.eishay.com/2008/11/protobuf-with-option-optimize-for-speed.html

http://kb.esignal.com




http://www.fixprotocol.org/

http://www.fixprotocol.org/

LITERATURVERZEICHNIS 52

[Gooa] Google: Google - Protocol Buffers. http://code.google.com/p/protobuf/

[Goob] Google: WindowTester Pro. http://code.google.com/intl/de-DE/

javadevtools/wintester/html/index.html

[IBM] IBM: WebSphere Real Time . http://www-01.ibm.com/software/webservers/

realtime/

[JBo] JBoss Community: JBoss - Netty Project. http://www.jboss.org/netty.html

[MLA10] McAffer, J. ; Lemieux, J.-M. ; Aniszczyk, C.: Eclipse Rich Client Platform,

Second Edition. Addison-Wesley, 2010

[Mon] Monetary and Economic Department, Triennial Central Bank Survey: For-

eign exchange and derivatives market activity in April 2010. http://www.bis.

org/publ/rpfx10.pdf?noframes=1, Abruf: 03.01.2011

[Mur06] Murphy, John J.: Technische Analyse der Finanzmarkte. FinanzBuch Verlag,

Munchen, 2006

[MySa] MySQL: Referenzhandbuch : Kapitel 11.4.3. Die Spaltentypen BLOB und TEXT.

http://dev.mysql.com/doc/refman/5.1/de/blob.html

[MySb] MySQL: Referenzhandbuch : Kapitel 14.2. InnoDB-Tabellen. http://dev.mysql.

com/doc/refman/5.1/de/innodb.html

[Och04] Ochynski, Dr. W.: Strategien an den Devisenmarkten: Eine Anleitung fur die

Praxis unter Berucksichtigung der Euro-Besonderheiten. Betriebswirtschaftlicher

Verlag Dr. Th. Gabler/GWV Fachverlage GMBH, Wiesbaden, 2004

[Oraa] Oracle: Java Class Executors. http://download.oracle.com/javase/1.5.0/

docs/api/java/util/concurrent/Executors.html

[Orab] Oracle: JRockit. http://download.oracle.com/docs/cd/E13150_01/jrockit_

jvm/jrockit/docs30/index.html

[Orac] Oracle: Sun Java Real-Time System. http://java.sun.com/javase/

technologies/realtime/index.jsp

[OSGa] OSGi Alliance: OSGi Release 4.2 Core Specification. http://www.osgi.org/

Download/File?url=/download/r4v42/r4.core.pdf, Abruf: 28.12.2010

[OSGb] OSGi Alliance: OSGi Release 4.2 Service Compendium. http://www.osgi.org/

Download/File?url=/download/r4v42/r4.cmpn.pdf, Abruf: 28.12.2010

[R F] R Foundation: The R Project for Statistical Computing. http://www.

r-project.org, Abruf: 06.04.2011

http://code.google.com/p/protobuf/

http://code.google.com/intl/de-DE/javadevtools/wintester/html/index.html

http://code.google.com/intl/de-DE/javadevtools/wintester/html/index.html

http://www-01.ibm.com/software/webservers/realtime/

http://www-01.ibm.com/software/webservers/realtime/

http://www.jboss.org/netty.html

http://www.bis.org/publ/rpfx10.pdf?noframes=1

http://www.bis.org/publ/rpfx10.pdf?noframes=1

http://dev.mysql.com/doc/refman/5.1/de/blob.html

http://dev.mysql.com/doc/refman/5.1/de/innodb.html

http://dev.mysql.com/doc/refman/5.1/de/innodb.html

http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html

http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html

http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/docs30/index.html

http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/docs30/index.html

http://java.sun.com/javase/technologies/realtime/index.jsp

http://java.sun.com/javase/technologies/realtime/index.jsp

http://www.osgi.org/Download/File?url=/download/r4v42/r4.core.pdf

http://www.osgi.org/Download/File?url=/download/r4v42/r4.core.pdf

http://www.osgi.org/Download/File?url=/download/r4v42/r4.cmpn.pdf

http://www.osgi.org/Download/File?url=/download/r4v42/r4.cmpn.pdf

http://www.r-project.org

http://www.r-project.org

LITERATURVERZEICHNIS 53

[Rap] Rapid-i: Rapid Miner. http://www.rapid-i.com, Abruf: 06.04.2011

[Rei09] Reichert, S.: Eclipse RCP im Unternehmenseinsatz. dpunkt.verlag, Heidelberg,

2009

[Whi10] White, Tom: Hadoop - The Definitive Guide. O’Reilly, 2010

[WHKL08] Wutherich, G. ; Hartmann, N. ; Kolb, B. ; Lubken, M.: Die OSGi Service

Platform. dpunkt.verlag, Heidelberg, 2008

[Wika] Wikipedia: Candlestick pattern. http://en.wikipedia.org/wiki/Candlestick_

pattern, Abruf: 13.03.2011

[Wikb] Wikipedia: Chart pattern. http://en.wikipedia.org/wiki/Chart_pattern,

Abruf: 13.03.2011

[wikc] wikipedia: OSGi Bundle Life-Cycle. http://en.wikipedia.org/wiki/OSGi

http://www.rapid-i.com

http://en.wikipedia.org/wiki/Candlestick_pattern

http://en.wikipedia.org/wiki/Candlestick_pattern

http://en.wikipedia.org/wiki/Chart_pattern

http://en.wikipedia.org/wiki/OSGi

Anhang A

Glossar

Ask: Eroffnungskurs fur eine Long-Position und Schlusskurs fur eine Short-Position.

Bar: Ein Bar ist eine Darstellungsform von High-, Low-, Open- und Close-Preis eines be-

stimmten Zeitraums in einem Chart. Im Kontext der Datenspeicherung wird Bar synonym zum

Begriff des Candlesticks benutzt.

Bid: Eroffnungskurs fur eine Short-Position und Schlusskurs fur eine Long-Position.

Broker: Broker unterhalten Geschaftsbeziehungen zu Großbanken, oder sind selber eine

Großbank (z.B. Deutsche Bank, einer der großten Forex-Broker), und treten als Vermittler

zwischen Kunden und Interbankenmarkt auf.

Candlestick: Eine Darstellungsform von Preisen in einem Chart, siehe Bar.

Forex: Forex, steht fur Foreign Exchange, also den Devisenhandel.

Indikator: Ein Indikator ist ein Werkzeug der Chartanalyse zur statistischen Analyse von

Borsendaten.

Interbankenmarkt: Der Interbankenmarkt ist der Markt auf dem Banken unter anderem

Devisen handeln.

Majors: Unter Majors werden die meistgehandelten Wahrungspaare verstanden, also

EUR/USD, GBP/USD, AUD/USD und NZD/USD.

Long-Position: Ist eine Kauforder, mit der auf steigende Kurse gesetzt wird.

PAMM: PAMM ist die Abkurzung von Percent Allocation Management Module und ist ein

Kozept fur ein Sammelkonto.

ANHANG A. GLOSSAR 56

Pip: Entspricht meist der vierten Nachkommastelle des Wechselkurses und ist die Maßeinheit

fur Kursbewegungen.

Short-Position: Ist eine Verkaufsauforder, mit der auf fallende Kurse gesetzt wird.

Spread: Der Spread ist die Differenz zwischen Bid und Ask und entspricht der Gebuhr die

Broker fur die Ausfuhrung eines Trades verlangen.

Tick: Ein Tick gibt immer den Bid- und Ask-Preis einer bestimmten Wahrung zu einer be-

stimmten Zeit an.

Trade: Steht fur eine Long- oder Short-Position.

Anhang B

JFace Data Binding

JFace Data Binding1 bietet eine weitere Moglichkeit um Datenmodell und UI-Elemente

miteinander zu verknupfen. Im Gegensatz zum Content Provider kann hier auf den Einsatz

von eigenen Listener-Objekten verzichtet werden, da das Framework die Synchronisierung au-

tomatisch ubernehmen kann. Dazu mussen fur Datenmodell-Objekt und UI-Element sogenannte

Observables erstellt werden, dass sind Objekte, die bei Veranderungen ein Ereignis auslosen.

Unterstutzt werden Datenmodell-Objekte, bei denen es sich um Beans, Objekte die den

PropertyChangeSupport gemaß der Java Bean Spezifikation implementieren, oder um POJOs

(plain old java objects) handelt. Entsprechende Observables werden dann mit Hilfe der Fac-

tories: BeansObservables oder PojoObservables erzeugt. Das bedeutet auch fur POJOs, dass

getter- und setter-Methoden, fur die zu uberwachenden Eigenschaften des Objekts, immer dem

Schema:

{get|set}+<Eigenschaftsname(beginnend mit Großbuchstaben)>

entsprechen mussen, z.B. getFirstName(), fur die Eigenschaft: firstName.

Listing B.1: Beispiel fur ein Binding zwischen Text-Element und DatenModell-Objekt

1 Person person = new Person ...

2 Text firstNameText = new Text ...

3 DataBindingContext bindingContext = new DataBindingContext ();

4 IObservableValue widgetValue = SWTObservables.

5 observeText(firstNameText , SWT.Modify );

6 IObservableValue modelValue = BeansObservables.

7 observeValue(person , "firstName");

8 bindingContext.bindValue(widgetValue , modelValue );

Uber ein Binding, das vom DatabindingContext verwaltet wird, werden zwei Observables

miteinander verbunden (siehe Listing B.1). Fur das Binding konnen verschiedene Update-

1vgl. [Ebe]

ANHANG B. JFACE DATA BINDING 58

Strategien, Konverter2 und Validierer, z.B. um nur Werte großer null zuzulassen, festgelegt

werden.

Das ganze Potential des JFace Data Bindings lasst sich im Zusammenspiel mit dem Eclipse

Modelling Framework (EMF) ausnutzen, da hiermit passende Modellklassen und Factories

erzeugt werden konnen.

2Fur einfache Konvertierungen, z.B. von String-Werten zu Integer-Werten, verwendet JFace Data Bindingautomatisch einen passenden Konverter.

Anhang C

Abbildungen

/Benutzer /AccountView /TreeViewer /ContentProvider

new

setContentProvider()

setInput(PAMMAccountList)

getChildren(PAMMAccountList)

Klickt auf ein '+' in der TreeView

getChildren(Einzelkonten)

Abbildung C.1: Sequenzdiagramm - Content Provider

ANHANG C. ABBILDUNGEN 60

Ben

utze

r

PA

MM

-Kon

to e

rste

llen

PA

MM

-Kon

to lö

sche

n

Bed

ingu

ng:

kein

e of

fene

n T

rade

s vo

rhan

den

Ein

zelk

onto

ers

telle

nzu

PA

MM

-Kon

to h

inzu

füge

n<

<in

clud

e>>

Ein

zelk

onto

lösc

hen

aus

PA

MM

-Kon

to e

ntfe

rnen

<<

incl

ude>

>

PA

MM

-Kon

to a

usw

ähle

n

<<

incl

ude>

>

Bro

kera

pi a

usw

ähle

n

<<

incl

ude>

>

Ab

bil

du

ng

C.2

:U

seca

seD

iagra

mm

-K

onto

verw

alt

ung


Ben

utze

r/H

ande

ls-

syst

em

Neu

en T

rade

ers

telle

n

PA

MM

-Kon

to a

usw

ähle

n

<<

incl

ude>

>

Tra

de s

chlie

ssen

Prü

fe P

AM

M-K

onto

<<

incl

ude>

>

Offe

ne T

rade

s an

zeig

en

Ges

chlo

ssen

e T

rade

s an

zeig

en

<<

incl

ude>

>

<<

incl

ude>

>

Tra

de a

usw

ähle

nS

top

setz

en

Lim

it se

tzen

<<

incl

ude>

>

<<

incl

ude>

>

<<

incl

ude>

><

<in

clud

e>>

Ab

bil

du

ng

C.3

:U

seca

seD

iagra

mm

-T

rad

ever

walt

un

g


Hand

elssy

stem

star

ten

Hand

elssy

stem

stop

pen

Zugr

iff au

f Ind

ikato

ren

Zugr

iff au

f hist

orisc

he C

hartd

aten

PAM

M-K

onto

aus

wähle

n

<<inc

lude>

>

Hand

elssy

stem

aus

wähle

n

<<inc

lude>

>

Hand

elssy

stem

<<inc

lude>

>

<<inc

lude>

>

<<inc

lude>

>

Zugr

iff au

f live

Cha

rtdat

en

<<inc

lude>

>

Zugr

iff au

f PAM

M-K

onto

<<inc

lude>

>

Hand

elssy

stem

eins

telle

n (E

igens

chaf

ten)

<<inc

lude>

>

System

Benutzer

<<inc

lude>

>

<<inc

lude>

>

Indi

kato

r ers

telle

n

Ab

bil

du

ng

C.4

:U

seca

seD

iagra

mm

-H

an

del

ssyst

eme


Datenhaltungsschicht

Logikschicht

Präsentationsschicht

externe Systeme

Abbildung C.5: Schichten-Architektur

Anwendungsserver

Broker

Externe Clients

Interner Client

Datenhaltungsserver

Abbildung C.6: Verteilungsdiagramm


Acc

ount

stat

usac

coun

tID

acco

untT

ype

nam

e

PA

MM

Acc

ount

ist e

in

Sin

gleA

ccou

ntha

t1.

.m0.

.n

user

nam

e

pass

wor

d

acco

untN

umbe

r

acco

untH

olde

r

bala

nce

equi

ty

brok

erA

PI

Trad

e

mag

icN

umbe

r

trade

Type

sym

bol

take

Pro

fitst

opLo

ss

requ

este

dVol

ume

fille

dVol

ume

stat

us

erro

rMes

sage

ist e

in

PA

MM

Trad

eS

ingl

eTra

de

wei

ghte

dOpe

nPric

e

wei

ghte

dClo

seP

rice

hat

open

Tim

e

clos

eTim

e

open

Pric

e

clos

ePric

eha

t1.

.m0.

.n

1..m

0..n

sing

leA

ccou

ntID

pam

mA

ccou

ntID

stop

Loss

Ord

er

orde

rTyp

e

acco

untID

trade

ID

orde

rID

take

Pro

fit

orde

rSta

tus

erro

rMes

sage

Ab

bil

du

ng

C.7

:E

RM

-Dia

gra

mm

:D

ate

nty

pen

(Tei

l1)


Tick

bidask

symbol

date

volume

Bar

symbol

openDate

lastUpdate

open high

low

closetimeframe

TradingSystem

id payLoad

Abbildung C.8: ERM-Diagramm: Datentypen (Teil 2)

ANHANG C. ABBILDUNGEN 66<<enumeration>>

Symbol

+EURUSD

+GBPUSD

+NZDUSD

+AUDUSD

-baseCurrency: String

-quoteCurrency: String

-pipValueInDollar: double

-pipValue: double

-pipScale: int

+valueOf(value:int): Symbol

+fromString(symbolString:String): Symbol

+fromStringWithDelimeter(symbolString:String): Symbol

+inList(symbolString:boolean): boolean

<<enumeration>>

OrderStatus

+CREATED

+SEND_TO_SERVER

+RECEIVED

+SEND_TO_BROKER

+FINISHED

+REJECTED

+valueOf(value:int): OrderStatus

<<enumeration>>

AccountType

+PAMM_ACCOUNT

+SINGLE_ACCOUNT_LIVE

+SINGLE_ACCOUNT_DEMO

+valueOf(value:int): AccountType

<<enumeration>>

OrderType

+SET_SL

+SET_TP

+SET_SL_TP

+CLOSE_TRADE


<<enumeration>>

TradeType

+BUY

+SELL

+BUYLIMIT

+BUYSTOP

+SELLLIMIT

+SELLSTOP


<<enumeration>>

AccountStatus

+ONLINE

+OFFLINE

+RECONNECTING

+AUTHENTICATION_FAILED

+ERROR

+DELETED

+RELOGGING

+PARTIALLY_ONLINE

+NOT_ACK


<<enumeration>>

Timeframe

+TICK

+M1

+M5

+M15

+M30

+H1

+H4

+D1

+W1

+MN


<<enumeration>>

TradeStatus

+CREATED

+RECEIVED

+SEND_TO_SERVER

+SEND_TO_BROKER

+ACCEPTED

+PARTIALLY_FILLED

+FILLED

+PARTIALLY_CLOSED

+CLOSED

+CANCELED

+REJECTED


<<enumeration>>

TradingSystemEvent

+STARTED

+STOPPED


<<enumeration>>

AccountEvent

+CREATED

+ONLINE

+OFFLINE

+RECONNECTING

+OPEN_TRADE_LIST

+CHANGED

+DELETED

+AUTHENTICATION_FAILED

+ERROR

+ALREADY_EXIST

+ACCOUNT_UPDATE

+LOGIN_ERROR


<<enumeration>>

OrderEvent

+ORDER_RECEIVED

+ORDER_SEND_TO_BROKER

+ORDER_FINISHED

+ODER_REJECTED

+TRADE_CREATED

+TRADE_RECEIVED

+PENDING_ORDER_ACCEPTED

+PENDING_ORDER_CANCELLED

+TRADE_SEND_TO_BROKER

+TRADE_PARTIALLY_FILLED

+TRADE_FILLED

+TRADE_CHANGED

+TRADE_PARTIALLY_CLOSED

+TRADE_CLOSED

+TRADE_REJECTED

+TRADE_CANCELED

+ERROR

+TRADE_ALREADY_EXIST


Order

-orderID: String

-accountID: String

-tradeID: String

-takeProfit: Double

-stopLoss: Double

-orderStatus: OrderStatus

-orderType: OrderType

-errorMessage: String

Bar

-symbol: Symbol

-openDate: Date

-lastUpdate: Date

-open: Double

-high: Double

-low: Double

-close: Double

-volume: Double

-timeframe: Timeframe

Tick

-symbol: Symbol

-date: Date

-bid: Double

-ask: Double

-volume: Double

<<abstract>>

Account

-accountID: String

-name: String

-balance: Double

-equity: Double

-status: AccountStatus

-accountType: AccountType

PAMMAccount

SingleAccount

-userName: String

-password: String

-accountHolder: String

-accountNumber

-brokerAPI: String

1

*

<<abstract>>

Trade

-status: TradeStatus

-tradeType: TradeType

-symbol: Symbol

-takeProfit: Double

-stopLoss: Double

-requestedVolume: Double

-magicNumber: int

-errorMessage: String

SingleTrade

-singleAccountID: String

-openTime: Date

-closeTime: Date

-openPrice: Double

-closePrice: Date

PAMMTrade

-PAMMAccountID: String

-weightedOpenPrice: Double

-weightedClosePrice: Double

1

*

1

*

Ab

bil

du

ng

C.9

:K

lass

end

iagra

mm

-D

ate

nty

pen


Server

Clients

Account-, Trade-DAO-Service

Indikatoren Live-Datafeed-Publisher

Broker - API

IAccountController ITradeController

benutzt Service: stellt Service zur Verfügung:

ITickListener

PAMM-Controller

IPAMMAccountController, IPAMMTradeController

History-Provider

IBarProvider

Event-Admin-Service

Handelssysteme

ITradingSystemFactory

Client-Task-Dispatcher

BrokerDatenbank-Server

Handelssystem-ControllerITradingSystemController

MySQL

Event-To-JMS Tick-To-JMS

Event-Admin-ServiceJMS-To-Event

JMS-Broker (ActiveMQ)

JDBC TCP/IP

Controller

GUI

JMS-TO-TICK

IAccountListener

ITickreceiver

ITickreceiver

ITickreceiver

ITickreceiver

IAccountDAO

Abbildung C.10: Komponentendiagramm


PAMM-Controller Event-Service

PAMM-Konto vorhanden?

TRADE_REJECTEDauslösen

enthält Einzelkonten?

Einzelkontenonline?

ja

nein

PAMM_TRADE_ERRORauslösen

nein

Berechne Gesamtvermögen

nein

Fehler

Einzeltradevolumenberechnen

Einzeltrades erstellen

SINGLE_TRADE_CREATEDauslösen

API-Controller

Transformationder Daten

Weiterleiten des Tradesan Einzelkonten

Senden des Tradeszum Broker

ok

Einzelkonten

ja

ja

TRADE_RECEIVEDauslösen

FehlerFehler

SINGLE_TRADE_ERRORauslösen

SEND_TO_BROKERauslösen

ok

Abbildung C.11: Aktivitatsdiagramm fur einen PAMM-Trade


<<interface>>

IAccountController

+addAccount(account:SingleAccount): void+getAccountList(): List<String>+changeAccount(account:SingleAccount): void+removeAccount(singleAccountID:String): void

<<interface>>

IPAMMAccountController

+addAccount(account:SingleAccount): void+getAccountList(): List<SingleAccount>+changeAccount(account:SingleAccount): void+removeAccount(singleAccountID:String,pammAccountID:String): void+addPAMMAccount(PAMMAccount:pammAccount): void+getPAMMAccountList(): List<PAMMAccount>+getPAMMAccount(pammAccountID:String): PAMMAccount+changePAMMAccount(pamm:PAMMAccount): void+removePAMMAccount(pammAccountID:String): void

<<interface>>

IPAMMTradeController

+getOpenTrades(pammAccountID:String): List<PAMMTrade>+getTradeHistory(pammAccountID:String): List<PAMMTrade>+openTrade(pammTrade:PAMMTrade): void+processOrder(order:Order ): void

<<interface>>

ITradeController

+getOpenTrades(singleAccount:SingleAccount): List<SingleTrade>+getClosedTrades(singleAccount:SingleAccount): List<SingleTrade>+openTrade(singleTrade:SingleTrade): void+submitOrder(order:Order): void

<<interface>>

IBarProvider

+getBars(symbol:Symbol,timeframe:Timeframe,count:int): List<Bar>+getBar(symbol:Symbol,timeframe:Timeframe,shift:int): Bar+getBar(symbol:Symbol,timeframe:Timeframe): Bar

<<interface>>

ITickReceiver

+SYMBOL: String+TICK: String

+onTick(tick:Tick): void

<<interface>>

IAccountDAO

+saveSingleAccount(singleAccount:SingleAccount): void+savePAMMAccount(pammAccount:PAMMAccount): void+loadPAMMAccount(pammAccountID:String): PAMMAccount+loadPAMMAccounts(): List<PAMMAccount>

<<interface>>

ITradeDAO

+savePAMMTrade(pammTrade:PAMMTrade): void+loadPAMMTradeByTradeID(pammTradeID:String): PAMMTrade+loadPAMMTradeByAccountID(pammAccountID:String): List<PAMMTrade>+loadPAMMTrades(): List<PAMMTrade>+saveSingleTrade(singleTrade:SingleTrade): void+loadSingleTrades(): List<SingleTrade>+loadSingleTrades(pammTradeID:String): List<SingleTrade>+saveOrder(order:Order): void+loadOrder(orderID:String): Order+loadOrders(): List<Order>

<<interface>>

APIServiceenthält die Keys

für die Hashmapsder DTOs

+PAMM_ACCOUNT_ID: String+SINGLE_ACCOUNT_ID: String+TRADE_ID: String+TRADE: String+ORDER_ID: String+ORDER: String+TICKET: String+ORDER_EVENT: String+MESSAGE: String+CLOSE_PRICE: String+OPEN_PRICE: String+OPEN_TIME: String+PROFIT_LOSS: String+FILLED_LOTS: String+ACCOUNT_EVENT: String+OPEN_TRADE_LIST: String+EVENT_DATE: String+EQUITY: String+BALANCE: String+STOP_LOSS: String+TAKE_PROFIT: String+ACCOUNT: String+TRADING_SYSTEM_EVENT: String+SYSTEM_ID: String+TRADING_SYSTEM_INPUT: String

Abbildung C.12: Klassendiagramm Server-Interfaces


<<interface>>

ITradingsystem

+initialize(symbol:Symbol[],timeframe:Timeframe): void+getMagicNumber(): int[]+onUpdate(tick:Tick): void+onStart(context :ITradingSystemContext ): void+onStop(): void<<interface>>

ITradingSystemContext

+getPammAccountName(): String+getBalance(): double+getEquity(): double+getClosedTrades(symbol:Symbol): List<PAMMTrade>+getOpenTrades(symbol:Symbol): List<PAMMTrade>+getTrade(tradeID:String): PAMMTrade+getTrade(symbol:Symbol,magicNumber:int): PAMMTrade+registerTradeListener(listener:OrderListener): void+unregisterTradeListener(): void+openTrade(magic:int,tradeType:TradeType,symbol:Symbol,volume:double,takeProfit:double,stopLoss:double,requestedOpenPrice:double): void+processOrder(order:Order): void+getBar(symbol:Symbol,timeframe:Timeframe): Bar+getBar(symbol:Symbol,timeframe:Timeframe,shift:int): Bar+log(level:int,message:String): void

<<interface>>

ITradingSystemController

+startSystem(dto:TradingSystemInputDTO): void+stopSystem(systemID:String): void+getTradingSystemDescriptions(): List<TradingSystemDescription>+getRunningSystems(): List<TradingSystemInputDTO>

<<interface>>

ITradingSystemFactory

+getTradingSystemDescriptions(): List<TradingSystemDescription>+getInstance(dto:TradingSystemInputDTO): ITradingsystem

<<interface>>

OrderListener

+onOrderEvent(event:OrderEvent,orderID:String,pammTradeID:String): void

<<enumeration>>

InputType

+BOOL+DOUBLE+INTEGER+STRING

TradingSystemParameterDescription

-methodName: String-inputType: InputType-allowedStringValues: String[]-inputParametername: String-inputDescription: String-minValue: Integer-maxValue: Integer

TradingSystemDescription

-className: String-systemName: String-description: String-parameterList: List<TradingSystemParameterDescription>

<<imlements ITickReceiver, ITradingSystemContext, EventHandler>>

TradingSystemContextImpl

-system: ITradingsystem-orderListener: OrderListener-symbolArray: Symbol[]-pammAccountID: String

+handleEvent(event:Event): void+onTick(tick:Tick): void

<<abstract, implements ITickReceiver>>

Indicator

-timeframe: Timeframe-symbol: Symbol-barList: List<Bar>-history: IntegerAnzahl von Indikatorwerten

-shift: Integer0 = aktueller Bar, 1 = letzter Bar

-started: boolean

#Indicator(timeframe:Timeframe,symbol:Symbol,shift:int,context:BundleContext): Indicator#start(): void+<<abstract>> getName(): String+<<abstract>> getDescription(): String#<<abstract>> calculateIndicator(): void+onTick(tick:Tick): void

MovingAverage

-period: Integer-method: Integer-maxPeriod: Integer-minPeriod: Integer

+getValue(shift:Integer): Double

Indicators

+MovingAverage(timeframe:Timeframe,symbol:Symbol,period:Integer,method:String,shift:Integer): MovingAverage const

Abbildung C.13: Klassendiagramm - Indikatoren und Handelssysteme

Anhang D

Tabellen

Tabelle D.1: Broker Ubersicht

Broker FIX-Support SDK - un-

terstutzte

Sprachen

Zugriff auf

Preisdaten

Webseite

Deutsche

Bank

ja, aber Konto

mit mind. 25.000$

Guthaben notig

Plattform

wurde von

FXCM

lizensiert

siehe FXCM www.dbfx.com

Dukascopy ja, aber Konto mit

mind. 100.000$

Guthaben notig

Version 4.4

Java in SDK integri-

ert, Daten auf 10

Sekunden-Basis

reichen bis 2003

zuruck

www.dukascopy

.com

FXCM ja, aber Konto

mit mind. 50.000$

Guthaben erforder-

lich

Version 4.4

Order2Go:

VB, C++,

Delphi,

JAVA Trad-

ing API

uber Order2Go und

extra SDK, das nur

fur kommerzielle

Anwendungen

verfugbar ist.

www.fxcm.com

GAIN Capi-

tal

nein SOAP-

Interface

TCP/IP Socket-

Interface, keine

genaueren Infos

verfugbar

www.forex.com

- Fortsetzung nachste Seite -

ANHANG D. TABELLEN 72

Broker FIX-Support SDK - un-

terstutzte

Sprachen

Zugriff auf

Preisdaten

Webseite

Interactive

Brokers

ja, 500$ Lizen-

zgebuhr zzgl.

100$ monatlich

Version 4.4

C++, Java stark begrenzter

Zeitraum: z.B.

Minutenbars nur

fur die letzten 2

Tage

www.interactive

brokers.com

MB Trading ja, nach FIX

Gateway Zertfi-

fierungstest und

Lizenzgebuhr von

250$ zzgl.

50$ monatlich

Version 4.4

MBT SDK:

VB, C

Quote API bzw.

uber MBT SDK

Tagesbasis - bis zu

10 Jahre.

Minutenbasis - bis

zu einem Jahr.

www.mbtrading

.com

OEC nein API: .Net

2.0

COM API

C++, Delphi

nur auf Tagesbasis

verfugbar

www.openecry

.com

ANHANG D. TABELLEN 73

Tab

elle

D.2

:S

oft

ware

Ub

ersi

cht

Hers

tell

er

Nam

eW

eb

seit

eP

rogra

mm

iers

pra

che

verf

ugb

are

His

tory

Inte

ract

ive

Dat

a

eSig

nal

ww

w.e

sign

al.c

omeS

ign

al

Form

ula

Scr

ipt,

ein

eE

r-

wei

teru

ng

von

Jav

aS

crip

t

Tic

kd

ate

nb

iszu

40

Tage.

Intr

ad

ay-D

ate

n

bis

2007,

au

fT

ages

basi

sb

is1983

Met

aQu

otes

Sof

twar

e

Met

atra

der

4w

ww

.mql4

.com

mql4

,ei

ne

funkti

on

ale

Sp

rach

em

itC

-

ah

nli

cher

Syst

ax

vom

Bro

ker

ab

han

gig

Met

aQu

otes

Sof

twar

e

Met

atra

der

5w

ww

.mql5

.com

mql5

,ei

ne

ob

jekto

rien

tier

teS

pra

che

vom

Bro

ker

ab

han

gig

Mu

ltiC

har

ts,

LL

C

Mu

ltiC

har

tsw

ww

.mu

ltic

har

ts

.com

Easy

Lan

gu

age

unte

rstu

tzt

ver

sch

ied

ene

Date

nfe

eds

Tra

deS

tati

on

Sec

uri

ties

Tra

de

Sta

tion

ww

w.t

rad

esta

tion

.com

Easy

Lan

gu

age,

ein

efu

nkti

on

ale

Sp

rach

e,d

iean

die

natu

rlic

he

Sp

rach

e

an

gel

ehnt

ist

Intr

ad

ay-D

ate

nau

fM

inu

tenb

asi

s,d

ieb

is

2002

od

erb

is2007

zuru

ckre

ichen

Anhang E

Installationsanleitung

In diesem Kapitel werden die einzelnen Installationsschritte beschrieben. Die dazu benotigten

Dateien, sowie Sourcecode und diese Arbeit als pdf-Datei finden sich auf der beiliegenden

CD. Zur Durchfuhrung der folgenden Schritte muss der Programme-Ordner in ein beliebiges,

beschreibares Verzeichnis kopiert werden. Der darin befindliche Client-Ordner kann als einziges

auf einen anderen Rechner kopiert werden.

1. Datenbank einrichten: Die Einstellungen fur den Datenbank-Server sind in der Datei

”/Programme/sql.properties“ geregelt. Zur Zeit ist hier ein Datenbank Server der HTW-Berlin

eingetragen. Sollte der nicht erreichbar sein, dann muss mit Hilfe der Datei”/database.sql“ eine

Datenbank angelegt und die Properties-Datei entsprechend angepasst werden.

2. History-Daten herunterladen: Als nachstes mussen die aktuellen History-Daten

heruntergeladen werden. Dazu befindet sich im Ordner Programme die Datei”historyLoad-

er.properties“. In dieser Text-Datei befinden sich die Zugangsdaten fur ein Demokonto des

Brokers Dukascopy. Sollten die Zugangsdaten nicht mehr gultig sein, dann muss ein neues Kon-

to eingerichtet und eingetragen werden (siehe http://www.dukascopy.com/swiss/english/

forex/demo_fx_account/). Jetz kann das Programm eclipse.exe, das sich im Ordner”/pro-

gramme/historyloader/historyLoader“ befindet aufgerufen werden.

Diese Programm ladt die letzten 2000 Bars der Majors und speichert sie im Ordner”/pro-

gramme/history“ ab.

3. Abschluss: Damit ist die Einrichtung soweit abgeschlossen. Jetzt muss als erstes der Server

gestartet werden, die dazu benotigte Datei heißt”pammtrader server.exe“ und befindet sich

im Ordner”/programme/server/pammtrader“. Ist der Server gestartet, dann kann die Client-

Anwendung”/programme/client/fxsolution/fxsolution.exe“ gestartet werden.

FXCM-Konten lassen sich auf der Webseite: http://www.fxcm.com/

demo-account-country.jsp anlegen, es funktionieren allerdings nur Konten die mit

”´EUD“ beginnen.

http://www.dukascopy.com/swiss/english/forex/demo_fx_account/

http://www.dukascopy.com/swiss/english/forex/demo_fx_account/

http://www.fxcm.com/demo-account-country.jsp

http://www.fxcm.com/demo-account-country.jsp

Anhang F

Eigenstandigkeitserklarung

Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit

Entwicklung eines Frameworks zum automatisiertenHandel eines Multi-Broker-PAMM-Accounts

selbststandig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst

habe. Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderen Prufungsbehorde

vorgelegt.

Berlin, den 21.4.2011

Documents

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