Wie man mit einem UML-Werkzeug einen Expert Advisor entwickelt

Forscher untersuchen das bereits Vorhandene, Techniker schaffen das noch nie Dagewesene.

Albert Einstein

Einleitung

In meinem Artikel Simulink: a Guide for the Developers of Expert Advisors (Simulink: Ein Leitfaden für die Entwickler von Expert Advisors) habe ich vorgeschlagen, einen Expert Advisor mit dynamischen Systemen zu modellieren. Diese Vorgehensweise stellt jedoch nur einen Aspekt des Designs von Handelssystemem dar - das dynamische Verhalten des Systems. Experten haben bestimmte Werkzeuge, die die Methodologie eines Handelssystem-Entwicklers erweitern. In diesem Artikel werden wir uns mit der Entwicklung eines Expert Advisors anhand eines universellen Werkzeuges befassen - der Modellierungssprache UML.

UML wird als Modellierungssprache generell für die bildliche Modellierung von objektorientierten Softwaresystemen verwendet. Meiner Meinung nach kann man diese Werkzeuge aber auch bei der Entwicklung eines Handelssystems verwenden. Außerdem gehört MQL5 zur Familie der objektorientierten Sprachen, was unsere Aufgabe erleichtert.

Zum Modellieren habe ich mich für die nicht-kommerzielle, kostenlose Software Software Ideas Modeler entschieden.

1. Grundlage der UML

Wie UML bei der Entwicklung eines Expert Advisors helfen kann? Erstes Problem, die Bilder: Probleme, die man mit vielschichtigem Modellieren hat, können mit der Verwendung von Grafiken, die in der Sprache vorhanden sind, gelöst werden. Zweites Problem, die Lesbarkeit. Auch wenn ein Expert Advisor groß und komplex ist, kann er dank der universellen Einsetzbarkeit von UML sein Modell mit Diagrammen darstellen.

Schon die Entwickler von UML sagten, dass eine herausragende Eigenschaft menschlicher Wahrnehmung darin besteht, dass ein Text mit Bildern besser verarbeitet werden kann als bloßer Text.

Kurze Diskussion der UML-Grundlagen Bei Interesse können Sie den Umgang mit UML-Werkzeugen von den vielen Veröffentlichungen lernen, die kostenlos im Internet erhältlich sind.

Die UML-Struktur kann in einem Diagramm dargestellt werden (Abb. 1).

Abb. 1. Die UML-Struktur

Bauteile sind unter anderem: Objekte (die Elemente des Systems), Beziehungen (binden die Objekte) und Diagramme (stellen UML-Modelle dar).

UML-Diagramme ermöglichen eine Visualisierung der Darstellung von Systemen aus verschiedenen Gesichtspunkten.

Gemeinsame Mechanismen, zum Beispiel: Präzisierungen (Beschreibung der Semantik), Ausschmückungen (Kennzeichnung der wichtigen Merkmale des Modells), gemeinsame Einteilungen (Abstrahierung, Schnittstellen und Implementierung) und erweiterbare Architektur (Einschränkungen, Stereotypen und markierte Werte).

Die Architektur ist verantwortlich für die hochwertige Darstellung des Systems in seiner Umgebung. Die UML-Architektur wird am besten mit dem "4+1 architecture view" (Abb. 2) beschrieben:

• Logical view
• Process view
• Development view
• Physical view
• Scenarios

Abb. 2. 4+1 Architecture view

Beachten Sie auch, dass UML seine eigene Hierarchie kanonischer Diagramme hat (Abb. 3). Version 2.2 der Sprache verwendet 14 Arten von UML-Diagrammen.

Abb. 3. Kanonische UML-Diagramme

Außerdem gibt es auch einige erwähnenswerte Fälle von besonderer Verwendung der UML-Diagramme. So können wir also von einer Abstrahierung zu einer bestimmten Variante der Verwendung der Diagramme für die Entwicklung von Expert Advisors gehen. Die Grundlage eines vielschichtigen Designs von Handelssystemen, die durch die Hierarchie der UML-Diagramme ermöglicht wird, trägt zur systematischen und umfassenden Lösung vom Erstellungsablauf bei.

2. UML-Diagramme

2.1 Anwendungsfalldiagramme

Frisch gewagt ist halb gewonnen. Normalerweise, aber nicht unbedingt zwingend, beginnt die analytische Arbeit mit Anwendungsfalldiagrammen. Sie beschreiben das System aus der User-Perspektive.

Bei der Erstellung kann man:

• die Arten der Handelssysteme spezifizieren
• die Abgrenzungen des Handelssystems spezifizieren
• die Akteure (actors) des Handelssystems bestimmen
• die Beziehung zwischen Akteuren und Handelssystemversionen bestimmen

Anwendungsfall ist eine Auflistung an Schritten, die typischerweise Wechselwirkungen zwischen einem Akteur (in UML "actor" genannt") und einem System beschreibt, um ein Ziel zu erreichen.

Ein Akteur "beschreibt eine Rolle, die von einem User oder einem anderen System ausgeführt wird, die oder das mit dem Subjekt interagiert". Akteure stellen Rollen dar, die von menschlichen Usern, externer Hardware oder anderen Subjekten gespielt werden.

Beziehung ist eine semantische Verbindung zwischen einzelnen Elementen eines Modells.

Ihnen wird vielleicht aufgefallen sein, dass diese Art von Diagramm sehr allgemein ist und dass es eher das konzeptuelle Wesen von Handelssystemen beschreibt als ihre Anwendung. Aber um das geht es hier auch - um eine Entwicklung vom Allgemeinem zum Spezifischen, vom Abstrakten zum Konkreten. Wer hat nochmal behauptet, dass wir keine Künstler sind? Wir schaffen ein Gemälde und fangen bei allgemeinen Ideen und Entwürfen an. Zuerst zeichnen wir Striche auf eine Leinwand. Dann fügen wir die Farben hinzu und malen die Details ...

Versuchen wir also, ein Anwendungsfalldiagramm für ein Handelssystem zu erstellen.

Als Akteure habe ich folgende Rollen gewählt: Entwickler, Systemanalyst, Risikomanager und Administrator. Beachten Sie auch, dass diese Rollen von einer oder mehreren Personen gespielt werden können. Welche Aktionen führt unser Handelssystem aus, und welche Aktionen werden in Verbindung damit ausgeführt?

Der Entwickler kann also Handelssysteme erstellen und implementieren. Außerdem kann er auch zur Optimierung des Handelssystems beitragen. Der Systemanalysator optimiert das Handelssystem. Der Risikomanager ist für das Risikomanagement verantwortlich. Der Administrator überwacht das gesamte Handelssystem. Auf der Output-Seite können wir sehen, dass der User als Resultat der Funktionen des Handelssystems einen Gewinn erzielt. Diese Rolle ist die Summe von Rollen wie Trader und Investor. Sowohl Manager als auch Administrator überwachen die Arbeit des Handelssystems.

Das Diagramm beinhaltet das Bauteil "Handelssystem". Es stellt die Grenzen des Handelssystems dar und trennt es von der Außenwelt.

Es folgen nun ein paar Anmerkungen über die Beziehung zwischen den Akteuren und den Anwendungsfällen, genauso wie zwischen den Akteuren und anderen Akteuren und Anwendungsfällen und anderen Anwendungsfällen. Die meisten Beziehungen werden von Assoziationen in einer gut erkennbaren Linie dargestellt. Das heißt, dass ein gewisser Akteur einen Anwendungsfall initiiert. Der Risikomanager initiiert also den Prozess des Risikomanagements, und so weiter. Die Akteure, die die Anwendungsfälle initiieren, sind primär, diejenigen, welche mit den Ergebnissen begangener Aktionen arbeiten, sekundär. Ein sekundärer Akteur ist zum Beispiel der Manager auf der Output-Seite.  

Assoziation gibt an, dass der Akteur den passenden Anwendungsfall initiiert.

Generalisierung simuliert die passende Allgemeinheit der Rollen.

Erweiterung ist eine Abhängigkeitsbeziehung zwischen dem normalen Anwendungsfall und seiner speziellen Ausführung.

Inklusion definiert die Beziehung des normalen Anwendungsfall zu einem anderen Anwendungsfall, dessen funktionales Verhalten nicht immer vom normalen Fall verwendet wird, sondern nur unter zusätzlichen Bedingungen

Beachten Sie aber, dass eine sekundäre Rolle in Bezug auf den Anwendungsfall nicht bedeutet, dass diese Rolle nur sekundäre Bedeutung hat. Außerdem können wir in dem Diagramm erkennen, dass die Rolle des Handelssystem-Users aus der Rolle des Traders und des Investors durch die Beziehung der Generalisierung besteht, dargestellt als Linie mit dem "nicht angemalten" dreieckigen Pfeil.

Abb. 4. Anwendungsfalldiagramm des Handelssystems

Die Anwendungsfälle "Öffne Position" und "Schließe Position" stehen wiederum durch Generalisierung mit "Trading" in Beziehung. Letzteres ist die Grundlage der ersten beiden. Daraus folgt, dass es den Anwendungsfall "Manage risk" beinhaltet. Und sein Verhalten ist komplementär zum abhängigen Fall "Profit".

Da der Profit des Handelssystems auf der Bedingung beruht, dass der Verkaufspreis eines Postens größer ist als sein Kaufpreis, habe ich für diesen Fall die erweiterte Beziehung verwendet . Das Diagramm zeigt auch den Erweiterungspunkt, das heißt, einen bestimmten Zustand, in dem der Fall "profitieren" verwendet wird. Abhängigkeitsbeziehungen werden durch den gestrichelten Pfeil angezeigt, der die korrespondierenden Stereotypen "include" und "extend" anzeigt.

Für jeden Anwendungsfall wird die Erstellung eines Szenarios benötigt, also die Beschreibung von Abläufen, die zum Ziel führen sollen. Der Anwendungsfall kann unterschiedlich beschrieben werden. Die gemeinhin akzeptierte Weise beinhaltet folgendes: Textbeschreibung, Pseudocode, Aktivitätsdiagramm, Interaktionsdiagramm.

Beachten Sie, dass ein Trader eher an einem Handelssystem in seiner engsten Form interessiert ist als an dem in Abb. 4 gezeigten. Daher schlage ich eine Fokussierung auf den Anwendungsfall "Trading" mit der Erweiterung "profitieren" vor.

2.2 Klassendiagramm

Mit dem Klassendiagramm werden wir die Handelssystemstruktur beschreiben. Wir werden das Modell eines Handelssystems mit statischer Struktur vorstellen in Hinsicht auf Klassen der objektorientierten Programmierung. Wir werden also auf die Programmierlogik des Handelssystems eingehen.

Ein Klassendiagramm in UML ist eine Art Diagramm mit statischer Struktur. Es beschreibt die Struktur des Systems, indem es seine Klassen aufzeigt, ihre Eigenschaften und Operatoren genauso wie die Beziehungen zwischen den Klassen.

Was sind die Vorteile eines solchen Diagramms? Diejenigen, die mit objektorientiertem Programmieren vertraut sind, werden das bekannte Konzept der "Klassen" sofort erkennen. Klassen agieren im UML-Klassendiagramm als Grundlage des Bauteilblockes. Wenn man zum Beispiel einen C++-Code generiert, wird automatisch ein UML-Klassenblock in Form einer Klassen-Vorlage erstellt. Man muss nur die Implementierung jeder Methode und Eigenschaft beenden.

Versuchen wir es! Zuerst will ich aber Ihre Aufmerksamkeit auf den Artikel "Prototype of a Trading Robot" (Prototyp eines Handel-Roboters) lenken, in dem die Autoren die Vorteile eines logischen Ansatzes beschreiben. Meiner Meinung nach ist die Verschachtelungsmethode sehr effektiv - "macros-functions-trade modules".

Wir brauchen zum Beispiel einen Expert Advisor, der die Möglichkeiten von Handelsklassen der Standardbibliothek verwendet.

Erstellen Sie ein Klassenmodell anhand des Klassenblockes im Klassendiagramm. Ich habe es CTradeExpert genannt. Wir fügen einige Eigenschaften für die neuen Klassen hinzu (in MQL5 sind sie Datenmitglieder der Klasse). Sie sind: Magic_No, e_trade, e_account, e_deal, e_symbol, e_pnt. Wir fügen auch eine Konstruktionsmethode der Klasse CTradeExpert an. Dieser Vorgang ist in Abb. 5 dargestellt.

Abb. 5. UML-Modell einer CTradeExpert-Klasse

Das Zeichen "-" vor einer Eigenschaft bedeutet dass die Eigenschaft Zugriffsrechte in den Modi «private», «#» - «protected», «+» - «public» hat. Das heißt, für die Eigenschaft "Magic_No" sind die Zugriffdetails als privat eingestellt, für "e_pnt" als öffentlich und für andere als geschützt. Ein Doppelpunkt nach der Eigenschaft bedeutet einen Datentyp für Eigenschaften und einen Datentyp für Methoden. Die Eigenschaft "Magic_No" ist zum Beispiel Typ int, "e_trade" ist C Trade, etc.

Wir fügen keine Methoden oder Eigenschaften hinzu, wir zeigen nur, wie unsere Klasse CTradeExpert mit den Klassen der Standardbibliothek verbunden ist. Um dies zu tun, fügen Sie 6 Klassenblöcke zu dem Diagramm hinzu und nennen Sie sie wie folgt: CTrade, CAccountInfo, CDealInfo, CSymbolInfo, CObject. Nun verbinden wir das Modell der CTradeExpert-Klasse mit 4 Blöcken von Handelsklassen mit Abhängigkeitsbeziehungen mit dem "use"-Stereotyp (gestrichelte Linie).  

Abhängigkeit ist eine semantische Beziehung zwischen zwei Bestandteilen bei der eine Änderung des unabhängigen Bestandteils die Semantik des anderen, abhängigen, beeinflussen kann.

Stereotyp ist in UML eine Beschreibung des Objektverhaltens.

Dann verbinden wir diese Blöcke mit dem Block CObject durch die Generalisierungsbeziehung (Pfeil). Kommentiere die Standardbibliotheksklassen Nun sieht unser UML-Diagramm aus wie in Abb. 6.

Abb. 6. UML-Klassendiagramm

Nun müssen wir nur noch den Code generieren, und zwar mithilfe der Funktion "generieren" auf der Seitenleiste (Abb. 7.).

Abb. 7. Generierter Code

Die beste Sprache für dieses Unterfangen ist C++. Wir werden C++ verwenden, um den Code der Expert-Advisor-Klasse zu generieren, und dann werden wir es einfach in MQL5 übersetzen.

Der generierte Code für dieses Programm ist:

//
class CTradeExpert
{

private:
        int Magic_No;

protected:
        CTrade e_trade;

protected:
        CAccountInfo e_account;

protected:
        CDealInfo e_deal;

protected:
        CSymbolInfo e_symbol;

public:
        double e_pnt;

public:
        void CTradeExpert () 
    {

    }

};


//
class CObject
{
};

//
class CTrade : public CObject
{
};

//
class CDealInfo : public CObject
{
};

//
class CSymbolInfo : public CObject
{
};

//
class CAccountInfo : public CObject
{
};

Eine vertraute Syntax, nicht? Wir müssen nur den Text der Klasse anpassen. Dafür erstellen wir in MetaEditor eine Datei für die neue Klasse TradeExpert.mqh. Kopieren Sie den zuvor generierten Code hinein. Um Lesbarkeit zu garantieren löschen wir die oft wiederholte Angabe geschützt für Mitglieder der CTradeExpert-Klasse.

Löschen Sie die Zeilen, die mit der Erklärung der Standardbibliothek-Klassen verbunden sind. Fügen Sie die Datei mit der Anweisung # Include an jede benutzte Klasse der Standardbibliothek hinzu, denn diese Klassen wurden bereits vom Entwickler definiert. Fügen Sie unsere Kommentare hinzu. Als Ergebnis erhalten wir folgenden Code:

//includes
#include <Trade\Trade.mqh>
#include <Trade\AccountInfo.mqh>
#include <Trade\DealInfo.mqh>
#include <Trade\SymbolInfo.mqh>
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class CTradeExpert
  {
private:
   int               Magic_No;   // Expert Advisor magic

protected:
   CTrade            e_trade;    // An object for executing trade orders
   CAccountInfo      e_account;  // An object for receiving account properties
   CDealInfo         e_deal;     // An object for receiving deal properties
   CSymbolInfo       e_symbol;   // An object for receiving symbol properties

public:
   double            e_pnt;      // Value in points

public:
                     CTradeExpert()
     {
     }
  };
//+------------------------------------------------------------------+

-->

Fügen wir nun noch mehr Handelsfunktionsmodule zu unserer Expert-Advisor-Klasse hinzu.

Zum Beispiel: CheckSignal, OpenPosition, CheckPosition, ClosePosition etc. Ich hoffe, Sie sind bereits vertraut mit dem Prinzip "condition serving". Wenn ja, dann wird unsere Testklasse CTradeExpert kein Problem für Sie sein. Ich habe mich extra auf ein paar vertraute Bespiele von Expert Advisors konzentriert, um es für Sie einfacher zu machen, die Mechanismen von UML zu verstehen.

Nun sieht das Modell der Klasse so aus wie in Abb. 8.

Abb. 8. UML-Modell einer CTradeExpert-Klasse

Für ein Update dieser Klasse können wir noch einen Code mit der erläuterten Methode generieren.

2.3 Aktivitätsdiagramm

Mit dieser Form von UML-Diagramm können wir das Verhalten des Systems anhand von Dataflow- und Controlflow-Modellen beobachten. Aktivitätsdiagramme sind graphische Darstellungen von Workflow und schrittweisen Aktivitäten und Aktionen.

Das Aktivitätsdiagramm unterscheidet sich von der Flowchart, die nur die Schritte der Algorithmen beschreibt. Die Notation des Aktivitätsdiagrammes ist größer. Es ist zum Beispiel möglich, den Zustand der inneren Objekte zu beschreiben.

Aktivitätsdiagramme werden von Entwicklern für folgende Beschreibungen verwendet.

• Geschäftsregeln
• einzelne Anwendungsfälle
• komplexe Reihen an mehrfachen Anwendungsfällen
• Prozesse
• Parallelprozesse
• Programmfluss und logische Kontrollstrukturen

Gehen wir davon aus, dass die erstellte Expertenklasse CTradeExpert in der Datei der Expert Advisor verwendet wird Test_TradeExpert.mq5. Die Standard-Vorlage bei der Erstellung eines Expert Advisors im MetaEditor 5 bietet drei Standardfunktionen zur Situationsanwendung. OnInit, OnDeinit und OnTick. Gehen wir kurz darauf ein.

Versuchen wir, ein Diagramm mit unserer Expert-Advisor-Operation der Datei Test_TradeExpert.mq5 anzuzeigen. Beachten Sie hier, dass die Struktur der Expert Advisor nicht kompliziert ist. Dies ist nur eine Übung. Eine einfache Expert-Advisor-Struktur reicht für Übungszwecke.

Entwerfen wir nun ein Diagramm für die Verwendung unseres Expert Advisors, dessen Algorithmus in der Datei Test_TradeExpert.mq5 gezeigt wird.

Es beginnt mit dem Startknoten (Abb. 9). Von diesem Knoten bewegt sich ein Kontroll-Token zu dem Aktionsknoten "Create an Expert Advisor instance". Diese Aktion initiiert den Objektfluss (blauer Pfeil), der den Status des Objektknotens ändert (myTE=created), sowie den Kontrollfluss zum Knoten "Initialize the Expert Advisor". 

Kontrollfluss (control flow) wird durch eine Aktivitätskante dargestellt, die zwei Aktivitätsknoten verbindet und über die nur Kontroll-Token fließen. 

Objektfluss (object flow) wird als Aktivitätskante dargestellt, in die nur Objekt- oder Daten-Token fließen.

Aktivitätsknoten (activity node) ist eine abstrakte Klasse für individuelle Punkte im Fluss der durch Ecken verbundenen Aktivitäten.

Entscheidungsknoten (decision node) ist ein Kontrollknoten, der aus den herauskommenden Flüssen wählt.

Objektknoten (object node) stellt Objekte dar, die in der Aktivität verwendet werden.

Aktivitätskante (activity edge) ist eine abstrakte Klasse für gerichtete Verbindungen zwischen zwei Aktivitätsknoten.

Der Startknoten zeigt, wo die Aktivität beginnt.

Der Endknoten (final node) einer Aktivität beendet alle Aktivitätsflüsse.

Er selbst ändert dann den Status des Objektes myTE (myTE=initialized) und lässt das Kontroll-Token zum Entscheidungsknoten fließen. Wenn der Expert Advisor erfolgreich gestartet wurde, geht der Kontrollfluss zum Knoten "Process the trade event NewTick". Wenn der Start nicht erfolgreich war, fließt das Kontroll-Token zuerst in den Generalisierungsknoten, und dann in den Aktionsknoten "Deinitialize Expert Advisor".

Token sind abstrakte Konstruktionen, die für die Beschreibung von dynamischen Prozessen eines statistisch festgelegten Aktivitätsgraphen eingeführt wurden. Das Token kann entweder keine zusätzlichen Informationen enthalten (leeres Token) und wird dann Kontrollfluss-Token genannt, oder es enthält Hinweise auf ein Objekt oder eine Datenstruktur und wird dann Datenfluss-Token genannt.

Schauen wir uns den ersten Kontrollfluss an, der vom Entscheidungsknoten kommt. Er zeigt in ein Feld mit einer unterbrochenen Aktion, wie man an dem rot-gestricheltem Rechteck mit runden Ecken und dem Stereotyp "interruptible" (unterbrechbar) erkennen kann. Wenn der Kontrollfluss in dieses Feld kommt, kann er unerwartet anhalten. Wenn man den Aktionsknoten (orange) aktiviert, der das Ereignis "Unload Expert Advisor" empfängt, werden alle Flüsse unterbrochen. Das Kontroll-Token bewegt sich zur unterbrochenen Kante (oranger Zickzackpfeil) und dann zum Verbindungsknoten. Danach wird der Expert Advisor beendet. Dann geht das Kontroll-Token zum Knoten "Delete global variables", dann wird der Fluss im finalen Aktivitätsknoten beendet.

Der Aktionsknoten "Deinitalize Expert Advisor" verändert auch den Status des Objektes myTE (myTE=deinitialized) mit einem Objektfluss. Der Knoten "Delete global variables" löscht das Objekt myTE (myTE=deleted).

Abb. 9. Aktivitätsdiagramm für Test_TradeExpert.mq5

Wenn der Kontrollfluss stabil ist, wird der Expert Advisor nicht entladen. Vom Startknoten "Process the trade event NewTick" bewegt sich der Fluss zu einem anderen Blockerweiterungsfeld, dessen Stereotyp als "iterativ" definiert ist (grünes, gestricheltes Rechteck).

Ich nenne dieses Feld "Handelsblock", um die grundlegenden Eigenschaften wiederzugeben und um die Erfassung des Diagramms zu verbessern. Eine typische Eigenschaft des Blockes ist die zyklische Ausführung von Aktionen für ankommende Objekte. Wir brauchen lediglich 2 Zyklen - long direction und short direction. Über dem Eingang und Ausgang des grün-gestrichelten Blockes sind Erweiterungsknoten, die die Objekte Handelsoptionen "long" oder "short" anzeigen.  

Ein Erweiterungsknoten (expansion node) ist eine Sammlung von Objekten, die in ein Erweiterungsfeld hineingehen oder es verlassen.

Der Aktionsknoten, der ein Signal sendet (send signal action), stellt Signalsender dar.

Der Aktionsknoten, der eine Aktion akzeptiert (accept event action), wartet auf den Empfang einer passenden Aktion.

Jede Option wird somit von Knoten bestimmt wie: "Check signal" (signal sending node), "Receive signal" (signal receiving node), "Open position" (signal sending node), "Check position" (signal sending node), "Close position" (signal sending node). Beachten Sie hier, dass das Optionsobjekt (dir) in den Objektfluss zwischen Aktionsknoten fließen kann, wie man an den violetten Pfeilen sehen kann. Vorgänge in einem Block werden so lange fortgesetzt, bis der Expert Advisor entladen ist.

2.4 Das Sequenzdiagramm

Das Sequenzdiagramm wird verwendet, um die Objekt-Interaktions-Sequenz zu beschreiben. Ein sehr wichtiger Aspekt dieser Art von Diagramm ist Zeit.

Das Diagramm hat zwei implizite Skalen. Die horizontale zeigt die Sequenz von Objektinteraktionen an. Die vertikale ist eine Zeitachse. Der Anfang des Zeitintervalls ist der obere Teil des Diagramms.

Die Spitze des Diagramms beinhaltet Diagrammobjekte, die miteinander interagieren. Ein Objekt hat seine eigene Lebenslinie, die vertikale, gestrichelte Linie. Die Objekte tauschen Nachrichten aus, die mit Pfeilen dargestellt werden. Wenn ein Objekt aktiv ist, erhält es den Kontrollfokus. Dieser Kontrollfokus wird als schmales Rechteck auf der Lebenslinie dargestellt.

Ein Objekt ist ein Rechteck, das einen unterstrichenen Objektnamen und Klassennamen (optional) hat (getrennt durch Doppelpunkt).

Eine Objekt-Lebenslinie ist eine Linie, die die Existenz eines Objekts über eine Zeitperiode zeigt; je länger die Linie ist, desto länger existiert das Objekt.

Der Kontrollfokus wird als schmales Rechteck dargestellt, dessen obere Seite Beginn und Ende des Empfanges des Kontrollfokus von Seiten des Objektes anzeigt

In UML wird jede Interaktion mit einem Set von Nachrichten beschrieben, die die teilhabenden Objekte miteinander austauschen.

Das üben wir jetzt.

Das Terminal ist ein Akteur. Es initiiert den Arbeitsablauf des Expert Advisors. Andere Objekte, die mit dem "event"-Stereotyp markiert wurden, sind die Aktionen des Kundenterminals: Init, Deinit, NewTick. Wenn Sie wollen, können Sie die Auswahl an Ereignissen natürlich vergrößern. Beim Start eines Expert Advisors wird das Objekt "myTE" auf globalem Level erstellt. Es gehört zur CTradeExpert-Klasse. Das Klassenobjekt ist etwas niedriger als andere Objekte in dem Diagramm, was vermuten lässt, dass es im Sinne der Konstruktor-Funktion erstellt wurde.

Ein Erstellungsbefehl ist gekennzeichnet durch eine gestrichelte Linie, einem offenen Pfeil und einer Nachricht 1.1 CTradeExpert(). Die gestrichelte Linie mit einem Pfeil weist auf den "create"-Typ des Standard-Konstrukors CTradeExpert() hin. Nach der Erstellung des CTradeExpert wird Schritt 1.2 aktiviert - der Kontrollfokus wird zum Terminal zurückgebracht. Um Lesbarkeit zu garantieren, füge ich synchrone Nachrichten im Format #.# wie 1.1, und asynchrone im Format -# hinzu. Dann bearbeitet das Terminal das Init-Ereignis anhand der OnInit()-Funktion in Schritt 2.1, der Fokus wird in Schritt 2.2 retourniert. Nachrichten des Typus "Call" werden als Linien mit einem "vollen" Pfeil dargestellt.

Wenn das Init-Ereignis einen Nonzero-Wert zum Terminal bringt, heißt es, dass das Starten nicht erfolgreich war. Hier sollte mit Schritt 3.1 fortgesetzt werden, der zur Generierung des Deinit-Ereignisses führt. In Schritt 3.2 kehrt der Kontroll-Fokus zum Terminal zurück. Dann wird das Klassenobjekt CTradeExpert gelöscht (Schritt 4.1). Übrigens, bei der Erstellung eines Klassendiagramms habe ich die Destruktor-Funktion CTradeExpert nicht berücksichtigt. Das kann auch später gemacht werden. Dies ist einer der Vorteile der Diagrammkonstruktion - der Konstruktionsprozess von einigen Diagrammen wiederholt sich. Was zuerst für ein Diagramm festgesetzt wurde, kann dann auch für ein anderes festgesetzt werden, und später kann man das erste ändern.

Beachten Sie hier, dass der MQL5-Code einer Standard-Expert-Advisor-Vorlage keinen Block für einen misslungenen Start hat. Ich mache darauf aufmerksam, um die Sequenzlogik zu bewahren. Das UML-Sequenzdiagramm verwendet den opt-Block mit dem Wächter condition OnInit()!=0, der gleichwertig zur MQL5-Konstruktion if(OnInit()!= 0) {} ist.

In Schritt 4.2 wird die Kontrolle auf das Terminal übertragen.

Nun ist das Terminal bereit, das Ereignis NewTick durchzuführen.

Die Verarbeitung dieses Ereignisses findet im Block loop statt, was sich auf eine unendliche Schleife bezieht. Das heißt, der Expert Advisor wird dieses Ereignis durchführen, bis wir ihn außer Kraft setzen. Das Terminal führt das Ereignis NewTick mit der OnTick-Funktion aus (Schritt 5). In Schritt 6 wird der Kontrollfokus auf den Expert Advisor myTE übertragen. Mit 4 selbstbezüglichen Nachrichten implementiert er die folgenden Funktionen: CheckSignal, OpenPosition, CheckPosition, ClosePosition. Der Selbstbezug bezieht sich auf die Tatsache, dass das Expert-Advisor-Objekt sich selbst Nachrichten schickt.

Außerdem sind diese Funktionen der CTradeExpert-Klasse vom Schleifenblock (2) umgeben. Zwei heißt, dass die Schleife aus zwei Flüssen besteht. Warum zwei? Weil es zwei Handelsoptionen ausführt- lang (long) und kurz (short); von Schritt 7 zu Schritt 10. Im elften Schritt geht der Fokus wieder zurück zum Terminal.

Schritte 12 und 13 sind verantwortlich für die Deinitialisierung und das Löschen des Expert-Advisor-Objekts.

Abb. 10. Sequenzdiagramm für Test_TradeExpert.mq5

Somit haben wir die erste Entwurf-Lektion hinter uns gebracht. Mithilfe von Diagrammen wird die Arbeit von Entwicklern optimiert. Nun können wir anfangen, einen Code für die Datei Test_TradeExpert.mq5 zu schreiben. Natürlich kann man das auch ohne Diagramme. Aber wenn man einen komplexen Expert Advisor hat, verringert ein gutes Diagramm die Wahrscheinlichkeit von Fehlern und erlaubt es Ihnen, die Entwicklung ihres Handelssystems effizient zu managen.

Mit der Vorlage des Expert Advisors können wir nun Test_TradeExpert.mq5 erstellen.

Wir erstellen ein Beispiel einer CTradeExpert myTE-Klasse auf globaler Ebene.

Erstellen wir nun eine OnTick()-Funktion.

Wir schreiben die Funktion einer Klasse folgendermaßen:

for(long dir=0;dir<2;dir++)

     {

      myTE.CheckSignal(dir);

      myTE.OpenPosition(dir);

      myTE.CheckPosition (dir);

      myTE.ClosePosition(dir);

     }

So ähnlich schaut auch die Ausführung des Ereignisses NewTick. Natürlich müssen wir jede Funktion, die von den Klassendatenmitgliedern verwendet wird, zuerst genau festlegen. Um das kümmern wir uns aber später. Unser jetziges Ziel ist es, die Logik von UML-Diagrammen auf den MQL5-Code zu übertragen.

3. Entwicklung und Darstellung eines Expert Advisors basierend auf UML-Diagrammen

Erstellen wir nun zum Beispiel Diagramme für einen komplexen Expert Advisor. Zuerst müssen wir die Eigenschaften im Kontext einer gegebenen Strategie definieren, die in MQL5. implementiert wird. Im Allgemeinen wird unser Expert Advisor Handelsoperationen vollbringen, im Besonderen wird er Handelssignale generieren, offene Positionen und Geldmanagement beibehalten. Es ist eher eine ideale Handelsstrategie als eine, die im echten Leben vorkommt Aber für Übungszwecke werden wir mit ihr arbeiten.

Zuerst erstellen wir ein Anwendungsfalldiagramm für unseren Expert Advisor. Er wird sich nur in einigen Aspekten vom zuerst erwähnten unterscheiden. Hier wird vor allem auf die interne Struktur des Handelssystems eingegangen, ohne die Außenwelt (Abb. 11), da mit diesem Code nur Handelsaufgaben implementiert werden.

Abb. 11. Anwendungsfalldiagramm des Handelssystems

Definieren wir nun die Struktur des Expert Advisors. Angenommen, wir benutzen die Entwicklungen Standardbibliothek, da sie zu den angegebenen Zielen des Handelssystem passen. Vor kurzem wurde es erheblich vergrößert. Und vor allem sind die Klassen der Handelsstrategien betroffen . Unser Ziel ist es also, ein Klassendiagramm zu erstellen. Es wird nicht einfach sein, Sie brauchen also Geduld.

Die Wahl der Standardbibliothek geschah aus einigen Gründen. Erstens versuchen wir mit ihr als Grundlage einen Handelsroboter zu erstellen. Und zweitens haben wir bereits einiges an Übung in der Arbeit mit UML-Diagrammen. Drittens ist die Bibliothek selbst wahrscheinlich sehr wertvoll. Also können wir viel von der Bibliothek lernen und gleichzeitig versuchen, ihre nicht ganz einfache Struktur zu verstehen.

Die Umwandlung eines Codes in die Struktur eines UML-Diagrammes heißt reverse engineering. Wir tun dies tatsächlich manuell. Es gibt keine professionelle Software, die es uns erlaubt, dies automatisch zu tun (IBM, Rational Rose, Visual Paradigm für UML, etc.). Aber aus praktischen Gründen müssen wir meiner Meinung nach "manuell" arbeiten.

Erstellen wir ein Modell der grundlegenden Klasse CExpert, um Handelsstrategien zu implementieren, mit dem Block "Klasse". Schauen wir, welche anderen Klassen und Konstruktionen im Body der CExpert-Klasse verwendet werden. Als erstes sollten Sie beachten, dass dieCExpert-Klasse von der grundlegenden Klasse CExpertBase abstammt, die wiederum von der Klasse CObject abstammt.

Im Diagramm erstellen wir Blöcke für diese Klassen und definieren die Beziehung zwischen den Klassen mit einer Linie mit einem "leeren", dreieckigen Pfeil (Generalisierung). Fügen Sie ein Kommentar zum Modell der CExpert-Klasse hinzu (ein gelbes Rechteck mit einer umgeknickten Ecke). Die unmittelbare Klassenstruktur schaut nun so aus wie in Abb. 12. Nennen wir das Diagramm Expert.

Abb. 12. Das Expert-Diagramm, erster Anblick

Schauen wir uns den Code in der Expert.mqh-Datei an. Die Klasse CExpert beinhaltet unter anderem Aufzählungen ENUM_TRADE_EVENTS und ENUM_TIMEFRAMES, eine der acht vordefinierten Strukturen MqlDateTime. Die Klasse verwendet auch andere Instanzen, zum Beispiel: CExpertTrade, CExpertSignal, CExpertMoney, CExpertTrailing, CIndicators, CPositiontInfo, COrderInfo.

Nun müssen wir einige Änderungen am Diagramm vornehmen. Zuerst spezifizieren wir die Klassen: CExpertSignal, CExpertMoney, CExpertTrailing stammen von der grundlegenden Klasse CExpertBase ab, und die Klassen CPositiontInfo, COrderInfo stammen von CObject ab (ich habe den Stereotyp "Metaklasse" für diese festgelegt).

Markieren wir nun die Abhängigkeitsbeziehungen mit dem "use" Stereotype zwischen den Blöcken der CExpert-Klasse und anderen Klassen, sowie der MqlDateTime-Struktur und Aufzählungen. Wir ändern die Farben der Blöcke und bekommen folgende Struktur - Abb. 13.

Abb. 13. Das Expert-Diagramm, erster Anblick

Diese Struktur gibt aber nicht das gesamt Bild, denn es gibt einige Klassen die indirekt von den bereits erwähnten Klassen verwendet werden. Welche Art von Klassen sind sie? Die CExpertTrade-Klasse stammt von CTrade ab. Letztere ist eine Unterklasse von CObject.

DieCExpertTrade-Klasse verwendet die ENUM_ORDER_TYPE_TIME-Aufzählung, die Klassen CSymbolInfo und CAccountInfo stammen auch von CObject ab. Die CTrade-Klasse verwendet auch Erscheinungen der CSymbolInfo-Klassen. Ändern wir nun das Diagramm Unser Diagramm hat nun die folgende Form - Abb. 14.

Abb. 14. Das Expert-Diagramm, erster Anblick

Das Diagramm ist wieder nicht komplett. Wenn Sie sich zum Beispiel die Standardbibliothek-Datei Trade.mqh anschauen, werden Sie sehen, dass CTrade einige andere Strukturen, Aufzählungen und die CSymbolInfo-Klasse verwendet. Wenn sie alle auf einem Diagramm angezeigt werden, wird es zu voll. Und das macht es schwer verständlich.

Um mit dieser Schwierigkeit fertig zu werden, habe ich ein Paket für das Diagramm verwendet. Es beinhaltet verwandte Klassen, Aufzählungen, andere Pakete, etc. Ich habe die Pakete mit den Diagrammelementen durch das Interface verbunden. Das Diagramm des Pakets CTrade kann zum Beispiel wie in Abb. 15 dargestellt werden.

Abb. 15. Das Klassendiagramm für das CTrade-Paket.

Das Diagramm des CTrade-Pakets zeigt Abhängigkeitsbeziehungen der CTrade-Klasse mit Aufzählungen und Struktur.

Beziehungen mit der grundlegenden CObject-Klasse und der verwendeten CSymbolInfo -Klasse sind durch ein Interface realisiert worden.

Neben den Interfaces ist ein Icon mit dem Klassendiagramm, das das CTrade-Paket als einzelnes Element enthält. Das Original-Diagramm wird durch Klicken auf jedes beliebige Interface automatisch aufgerufen (Abb. 16).

Abb. 16. Das Expert-Diagramm mit Schnittstellen

Schnittstellen-Beziehungen sind orange. Das Icon des Klassendiagramms neben dem CTrade-Paket zeigt die Möglichkeit an, zu diesem Diagramm zu wechseln. Daher können wir anhand der Einfassung die Lesbarkeit des Klassendiagramms deutlich verbessern.

Fahren wir also fort. Die CObject-Klasse verwendet Zeiger für Objekte der selben Klasse in seinem Body. Daher können wir die Abhängigkeitsbeziehung für den CObject-Block mit dem Stereotyp "use" in Beziehung zu ihm selbst setzen.

Sehen wir uns den Block des CExpertBase-Klassenmodells an. Ausgehend von den ersten Zeilen des Headers ExpertBase.mqh können wir sagen, dass diese Klasse mehrfache Fälle von verschiedenen Klassen und Aufzählungen verwendet. Daher macht es Sinn, für das Klassenmodell und seine Beziehungen das Paket CExpertBase zu erstellen.

Also definieren wir zuerst das CExpertBase-Klassenmodell im Paket-Diagramm. Die Schnittstelle zeigt die Beziehung mit der grundlegenden Klasse CObject und die Beziehung mit den Klassen CSymbolInfo und CAccountInfo. Dann spezifizieren wir durch die Verwendung von Blöcken mit Klassen und Beziehungen, dass die CExpertBase-Klasse die folgenden Klassen verwendet. CiOpen, CiHigh, CiLow, CiSpread, CiTime, CiTickVolume, CiRealVolume.

Die ersten vier Klassen stammen von CPriceSeries und die letzteren von CSeries ab. Außerdem hat die CSeries -Klasse einen Nachfolger CPriceSeries und ist ihrerseits ein Nachfolger von CArrayObj. Diese Vererbungs-Beziehungen wurden bereits benutzt. Nennen Sie sie eine Generalisierungs-Beziehung im Diagramm.

Vergessen Sie nicht, dass die Klasse CExpertBase in ihrem Body Aufzählungen verwendet, zum Beispiel: ENUM_TYPE_TREND, ENUM_USED_SERIES, ENUM_INIT_PHASE, ENUM_TIMEFRAMES. Die letzte Aufzählung wird auch von den Nachfolgern der Klassen CPriceSeries und CSeries verwendet. Um die Beziehung nicht zu verlieren und das Diagramm klar darzustellen, stellen wir den Style jedes Elements des Diagramms ein. Als Ergebnis erhalten wir folgende Darstellung (Abb. 17).

Abb. 17. Das Klassendiagramm für das CExpert-Paket.

Es ist noch nicht vollständig und wir müssen noch ein bisschen mehr daran arbeiten. Es stellt sich heraus, dass die vier Nachfolgeklassen der Klasse CPriceSeries auch die CDoubleBuffer-Klasse verwenden. Zusätzlich verwendet jede der vier Klassen ihre Puffer-Klassen, die von CDoubleBuffer abstammen. COpenverwendet also COpenBuffer etc. CDoubleBufferhat eine grundlegende Klasse (CArrayDouble) und verwendet ENUM_TIMEFRAMES.

CArrayDoublestammt von CArray ab, verwendet Zeiger zu den Objekten derselben Klasse und den ENUM_DATATYPE-Aufzählungen. DieCOpenBuffer-Klasse und andere Puffer-Klassen (CHighBuffer, CLowBuffer, CCloseBuffer) verwenden die ENUM_TIMEFRAMES-Aufzählungen.

Die vier Nachfolgeklassen der CSeries-Klasse verwenden nur ihre eigenen Puffer-Klassen (CSpreadBuffer, CTimeBuffer, CTickVolumeBuffer, CRealVolumeBuffer). Der erste der Klassen-Puffer CSpreadBuffer ist der Nachfolger von CArrayInt,andere von CArrayLong. Die letzten beiden Klassen verwenden die Zeiger zu den Objekten ihrer eigenen Klasse, die ENUM_DATATYPE-Aufzählungen und stammen von CArray ab, die wiederum von der Klasse CObject abstammt.

DieCPriceSeries-Klasse und ihre Nachfolger verwenden die CDoubleBuffer-Klasse und die ENUM_TIMEFRAMES-Aufzählung.

CSeries verwendet die Aufzählungen ENUM_SERIES_INFO_INTEGER, ENUM_TIMEFRAMES. Sie ist die Nachfolgerin von CArrayObj, die wiederum eine Nachfolgerin von CArray ist und ENUM_POINTER_TYPE-Zeiger verwendet für Objekte ihrer eigenen Klasse und der CObject-Klasse. Als Ergebnis erhalten wir das Diagramm in Abb. 18.

Abb. 18. Erweitertes Klassendiagramm für das CExpert-Paket.

Und das Original-Diagramm Expert für Klassen und Pakete CExpert, CExpertBase, CSymbolInfo, CAccountInfo und CObject mit den folgenden Schnittstellen (Abb.19).

Abb. 19. Das Expert-Diagramm mit Schnittstellen

Ich habe auch die ENUM_ORDER_TYPE-Aufzählung CExpertTrade hinzugefügt. Um Lesbarkeit zu garantieren, habe ich die Beziehungsgruppen mit verschiedenen Farben markiert.

Weiter geht's. Ich hoffe, Sie verstehen die Logik. Dieses Modell einer Klasse auf dem Diagramm kann einige Beziehungen mit anderen Klassen und anderen Objekten haben. Also ersetze ich eine Gruppe mit einem Paket des grundlegenden Diagramms.

Schauen wir uns nun CSymbolInfo an. Beim Betrachten des Codes SymbolInfo.mqh fällt auf, dass die grundlegende Klasse CSymbolInfo einige MQL5-Aufzählungen und Strukturen verwendet. Die Verwendung eines Paketes für diese Klasse und ihre Beziehungen ist sinnvoll (Abb. 20).

Abb. 20. Diagramm des CSymbolInfo-Paketes

Freier Platz im Diagramm kann für Kommentare genutzt werden. Außerdem habe ich auch die Schnittstelle der Beziehung mit der Eltern-Klasse CObject markiert. Das originaleExpert-Diagramm mit Paketen und Klassen wird leicht verändert. Ich werde die aktualisierte Version später angeben, wenn alle Klassen und Pakete im Diagramm dargestellt sind.

Fahren wir also fort. Schauen wir uns den MQL5 Code in AccountInfo.mqh an. Es stellt sich heraus, dass CAccountInfo ebenfalls einige Nummerierungen verwendet. Wir stellen sie in dem Diagramm des Paketes dar, das wir für diese Klasse und ihre Beziehungen mit anderen Objekten erstellen (Abb. 21).

Abb. 21. CAccountlInfo Paket Diagramm

Schauen wir uns nun die CExpert Klasse an. Für diese Klasse erstellen wir ebenfalls ein Paket CExpert das wie in Abb. 22 dargestellt wird. Wir verbessern auch weiterhin die Lesbarkeit unseres Hauptdiagrammes. Die CExpert-Klasse ist mit einigen anderen Klassen verbunden, wie die orangen Pfeile zeigen.

Abb. 22. CExpert Paket Diagramm

Schauen wir uns nun die übrigen Klassen an. Wir werden mehrere Pakete für sie erstellen.

CExpertSignal stammt von CExpertBase ab. Diese Beziehung wurde bereits auf dem Original-Diagramm Expert gezeigt. Zusätzlich verwendet die CExpertSignal-Klasse CArrayObj, COrderInfo, CIndicatorsund Objekte ihrer eigenen Klasse (Abb. 23). Speziell die Schnittstelle der Beziehung mit der CArrayObj-Klasse wird uns zum CExpertBase-Paketdiagramm bringen, das die Beziehung der CArrayObj-Klasse mit anderen Objekten zeigt.

Abb. 23. CExpertSignal Paket Diagramm

Ich werde nicht alle Diagramme hier zeigen - sie stehen in der angehängten Datei Expert.simp zur Verfügung. Schauen wir uns nun unsere aktualisierten Paketdiagramme und Klassen Expert an (Abb. 24).

Wie Sie sehen, wurden fast alle Schlüsselklassen in den Diagrammen in Pakete geschnürt, um die Diagramme besser verständlich zu machen. Ich habe die Farbe der Generalisierungslinie braun gemacht, um sie von der Linie der Abhängigkeitsbeziehung zu unterscheiden.

Abb. 24. Das Diagramm der Pakete und Klassen Expert

Nun haben wir alles geübt, was von den Codes zu holen ist, die in der Standardbibliothek zur Verfügung stehen. Wir müssen nun lediglich mehrere Blöcke hinzufügen, die die Handelsoperationen des Expert Advisor spezifizieren.

Der erste Block ist der BlockCmyExpert der Handelsgeschick von der CExpert Klasse erbt. Dies ist der Block, mit dem wir uns im Reverse Engineerung so lange beschäftigt haben. Er wird eine spezielle Handelsstrategie implementieren. Wir müssen auch die virtuellen Funktionen der grundlegenden Klasse des Expert Advisors spezifizieren.

Dafür erstellen wir einen Block aus den Klassen CmyExpertSignal, CmyExpertMoney, CmyExpertTrailing und weisen darauf hin, dass sie von den passenden Klassen abstammen (Abb. 25).

Abb. 25. Erweitertes Diagramm der Pakete und Klassen Expert

Welche Funktionen und Daten jede dieser Klassen beinhalten sollte, ist dem Entwickler überlassen. Ich versuche hier, das generellere Schema zu zeigen, keine bestimmte Implementierung einer nachfolgenden Klasse. Daher können wir für jede nachfolgende Klasse ein separates Diagramm erstellen, mit einer detaillierten Liste von inkludierten Methoden und Eigenschaften, wie es zum Beispiel in Abb. 8 geschehen ist.

Nun schauen wir uns an, wie wir das Sequenzdiagramm in unserer Arbeit verwenden können. Beachten Sie hier, dass dies zeigt, wie unser Expert Advisor in Bezug auf Deadlines arbeitet.

Schreiben wir also Details der Arbeit des Expert Advisors in chronologischer Reihenfolge (Abb. 26).

Abb. 26. Das Sequenzdiagramm des Expert Advisors

Das Terminal ist ein Akteur. Auf globaler Ebene erstellt es das myTrader-Objekt - ein Beispiel eines CmyExpert (Schritt 1.1). Green zeigt vordefinierte Aktionen des client terminal (Init, Deinit, NewTick, Trade.) auf. Die Logik des Sequenzdiagramms wurde bereits erörtert. Hier würde ich gerne einige spezifische Punkte erläutern. Wenn der Body eines Expert Advisors wächst und sich mehr und mehr Code anhäuft, wird es immer schwieriger, ihn in einem Diagramm darzustellen.

Um dieses Problem zu lösen, arbeiten Sie am besten mit der Block-Methode. Ein Satz gewöhnlicher Funktionen wird in Form eines Blockes verbildlicht. Es ist normalerweise ein anderes Sequenzdiagramm und dient angeblich der Interaktion.

In diesem Fall habe ich also ein Sequenzdiagramm mit dem Namen OnInit erstellt, um die Verwendungslogik der Terminal-Aktion Init in einem weiteren Diagramm zu veranschaulichen. Syntaktisch wird es als Grenze mit dem Schlüsselwort ref (reference) definiert; es wird verwendet, wenn das Kontroll-Token von OnInit (Schritt 2.1) zur Lebenslinie des Init-Objekts wandert.

Außerdem habe ich hier einen Schnittstellen-Link zum Sequenzdiagramm für OnInit erstellt. Wenn Sie also zweimal auf die Grenze klicken, können Sie ein detailliertes Sequenzdiagramm für OnInit öffnen (Abb. 27).

Abb. 27. Das Sequenzdiagramm für OnInit.

Links, die zu anderen Diagrammen führen, sind sehr praktisch für Wiederholungen und einige Befehle.

Das OnInit-Diagramm beinhaltet zum Beispiel Befehle, die mit der Expert-Advisor-Deinitialisierung zusammenhängen, deren Verarbeitung mitmyTrader_Deinit durchgeführt wird (Abb. 28).

Abb. 28. Das Sequenzdiagramm von myTrader_Deinit

In dieser Phase der Expert-Advisor-Erstellung habe ich nun vier Sequenzdiagramme. Bei einer echten Entwicklung könnten zusätzliche Diagramme gebraucht werden. Ich habe zum Beispiel andere Aktionen des Client-Terminals vernachlässigt (NewTick, Trade).

Fazit

In diesem Artikel wurde das vielschichtige Wesen des Entwicklungsprozesses von Expert Advisors mit der graphischen Sprache UML behandelt, die für das bildhafte Modellieren objektorientierter Softwaresystemen verwendet wird. Der wesentliche Vorteil dieses Ansatzes ist die Verbildlichung des Erstellungsprozesses.

UML hat wie jede komplexe Sprache ihr eigenen Vor- und Nachteile, über die sich Entwickler im Klaren sein sollten (Redundanz, ungenaue Semantik, etc.).

Ich hoffe, die beschriebene Methodologie der Expert-Advisor-Entwicklung war interessant für Sie. Um Kommentare und konstruktive Kritik bin ich sehr dankbar.

Ablageort der Dateien:

#	Datei	Pfad	Beschreibung
1	TradeExpert.mqh	%MetaTrader%\MQL5\Include	Expert Advisor Protokoll
2	Test_TradeExpert.mq5	%MetaTrader%\MQL5\Files	Expert Advisor
3	Expert.simp	%Documents%\UML projects	Project of UML diagrams
4	SoftwareIdeasModeler.4.103.zip	%Program Files%\SoftwareIdeasModeler	Software Ideas Modeler distribution file

Literatur:

1. Free UML courses. The Internet University of Information Technology
   
2. Jim Arlow, Ila Neutstadt. UML2 and the Unified Process Practical: Object-Oriented Analysis and Design
   
3. Leonenkov A. Object-Oriented Analysis and Design Using UML and IBM Rational Rose.
   
4. Martin Fowler UML Distilled: A Brief Guide to the Standard Object Modeling Language. - 192 стр.
5. Paul Kimmel. UML Demystified. - 272 стр.
   
6. F. A. Novikov, D. Y. Ivanov. Modeling in UML
   
7. Mark Priestly. Practical Object-Oriented Design With Uml, Mcgraw Hill Higher Education; 2nd edition, 2007.