Handels System Uml

MetaTrader 5 - Integration So entwickeln Sie einen Expertenratgeber mit Hilfe von UML Tools Wissenschaftler untersuchen, was bereits Ingenieure schaffen, was noch nie war. Einführung In meinem Artikel Simulink: ein Leitfaden für die Entwickler von Expertenberatern Ich schlug vor, ein Expert Advisor mit dynamischen Systemen zu modellieren. Dieser Ansatz stellt jedoch nur einen Aspekt des Designers von Handelssystemen dar - das dynamische Verhalten des Systems. Professionals haben spezifische Werkzeuge, die die Methodik eines Trading-System-Entwickler zu erweitern. In diesem Artikel werden wir diskutieren, wie ein Expert Advisor mit dem universellen Werkzeug - grafische Sprache UML zu entwickeln. Im Allgemeinen, als grafische Sprache, wird UML für die visuelle Modellierung von objektorientierten Software-Systemen verwendet. Aber, wie ich es sehe, können wir seine Werkzeuge benutzen, um ein Handelssystem zu entwickeln. Darüber hinaus gehört MQL5 zur Familie der objektorientierten Sprachen, was uns die Arbeit erleichtert. Für die Modellierung wählte ich frei für nicht-kommerzielle Software Software Ideas Modeler. 1. UML Grundlagen Wie UML helfen kann, einen Expert Advisor zu schaffen Zunächst können die Grafiken - das Problem der Multi-Aspekt-Modellierung mit Hilfe der grafischen Bilder, die in der Sprache verfügbar sind, gelöst werden. Zweitens die Lesbarkeit. Selbst ein Expert Advisor ist groß und komplex, die Universalität von UML erlaubt es, sein Modell anhand von Diagrammen darzustellen. Wie die Entwickler von UML sagen, liegt das spezifische Merkmal der menschlichen Wahrnehmung darin, dass ein Text mit Bildern leichter wahrgenommen wird als ein bloßer Text. Wir diskutieren kurz die Grundlagen der UML. Wenn Sie sich für das Thema interessieren, können Sie die UML-Werkzeuge aus den zahlreichen Publikationen lernen, die frei im Internet verfügbar sind. Die UML-Struktur kann in einem Diagramm dargestellt werden (Bild 1). Feige. 1. Die UML-Struktur Die Bausteine ​​umfassen: Entitäten (die Elemente des Modells), Beziehungen (die die Dinge binden) und Diagramme (die UML-Modelle repräsentieren). UML-Diagramme ermöglichen die Visualisierung der Darstellung des entworfenen Systems aus verschiedenen Blickwinkeln. Gemeinsame Mechanismen sind: Spezifikationen (Beschreibung der Semantik), Verzierungen (Kennzeichnung der wichtigen Merkmale des Modells), gemeinsame Abteilungen (Abstraktion und ihre Instanzen, Schnittstellen und Implementierung), Erweiterungsmechanismen (Begrenzungen, Stereotypen und markierte Werte). Architektur ist für die hochrangige Präsentation des Systems in seiner Umgebung verantwortlich. Die UML-Architektur lässt sich am besten mit der 41-Architekturansicht beschreiben (Abb. 2): Logische Ansicht Prozesssicht Entwicklungssicht Physische Sicht Szenarien Abb. 2. 41 Architekturansicht Es ist zu beachten, dass die UML eine eigene Hierarchie kanonischer Diagramme aufweist (Bild 3). Die Sprachversion 2.2 verwendet 14 Arten von UML-Diagrammen. Feige. 3. Kanonische UML-Diagramme Weiter schlage ich vor, einige spezielle Fälle der Verwendung von UML-Diagrammen zu betrachten. So können wir von einer Abstraktion zu einer bestimmten Variante der Verwendung eines der Diagramme für EA-Entwicklung zu bewegen. Das Prinzip der Multi-Aspekte-Konstruktion von Handelssystemen, das durch die Hierarchie von UML-Diagrammen bereitgestellt wird, trägt wiederum zur systematischen und umfassenden Lösung der TS-Erstellungsaufgabe bei. 2. UML-Diagramme 2.1 Anwendungsfalldiagramme Wie das Sprichwort sagt, ist ein guter Anfang die halbe Miete. Normalerweise, wenn auch nicht notwendigerweise, beginnt die analytische Arbeit mit Anwendungsfalldiagrammen. Es beschreibt das System aus der Sicht der Benutzer. Bei der Erstellung können wir: die Varianten der TS-Nutzung spezifizieren die Grenzen der TS bestimmen TS-Akteure definieren die Beziehung zwischen den Akteuren und TS-Versionen. Anwendungsfall ist eine Liste von Schritten, die typischerweise Interaktionen zwischen einer Rolle (die in UML als Akteur bekannt ist) und einem System definiert, um ein Ziel zu erreichen. Ein Akteur spezifiziert eine Rolle, die von einem Benutzer oder einem anderen System gespielt wird, das mit dem Subjekt interagiert. Schauspieler können Rollen spielen, die von menschlichen Benutzern, externen Hardware oder anderen Themen gespielt werden. Beziehung ist eine semantische Verbindung zwischen einzelnen Elementen eines Modells. Sie können feststellen, dass diese Art von Diagramm ist ziemlich allgemein, und spiegelt die konzeptionelle Natur des TS, anstatt ihre Umsetzung. Aber das ist der Punkt - von allgemeiner zu spezifischer, von abstrakter zu konkreter. Wer sagte, dass wir nicht Künstler sind Wir zeichnen ein Bild, beginnend mit allgemeinen Ideen und Skizzen. Zuerst zeichnen wir Striche in eine Leinwand. Dann fügen Sie Farben. Zeichnen Sie Details. So können wir versuchen, ein Anwendungsfalldiagramm für ein Handelssystem zu schaffen. Als Input-Akteure, Ive gewählt die folgenden Rollen: Entwickler, System-Analyst, Risk-Manager und Administrator. Es ist zu beachten, dass diese Rollen von einer oder mehreren Personen gespielt werden können. Welche Handlungen tut unser Trading-System und welche Maßnahmen in Bezug auf sie getroffen werden, so kann der Entwickler erstellen und implementieren eine TS. Zusätzlich kann er an der Optimierung des TS teilnehmen. Der Systemanalytiker optimiert den TS. Der Risikomanager ist für das Risikomanagement zuständig. Der Administrator überwacht die Gesamtarbeit der TS. Ausgangsseitig sehen wir, dass der Benutzer durch die Funktionsweise des TS einen Gewinn erzielt. Diese Rolle ist eine Summe von Rollen wie der Händler und Investor. Und der Manager sowie der Administrator überwacht die Arbeit der TS. Das Diagramm enthält den Block Trading System. Sie drückt die TS-Grenze aus und trennt sie von der Außenwelt. Nun ein paar Worte über die Beziehung zwischen den Akteuren und den Anwendungsfällen sowie zwischen den Akteuren und anderen Akteuren und den Anwendungsfällen und anderen Anwendungsfällen. Die meisten Beziehungen werden durch Assoziationen dargestellt, die durch eine durchgezogene Linie markiert sind. Dies bedeutet, dass ein bestimmter Akteur einen Anwendungsfall initiiert. So initiiert der Risikomanager den Prozess des Risikomanagements usw. Die Akteure, die die Anwendungsfälle initiieren, sind prinzipiell, und diejenigen, die die Ergebnisse der begangenen Handlungen nutzen, sind zweitrangig. Zum Beispiel ist ein sekundärer Akteur der Manager auf der Ausgangsseite. Vereinigung kann darauf hindeuten, dass der Akteur den entsprechenden Anwendungsfall initiiert. Generalisierung simuliert die entsprechende Allgemeingültigkeit von Rollen. Extension ist eine Art Abhängigkeitsbeziehung zwischen dem Basiskonsum und seinem Spezialfall. Include definiert die Beziehung des Base Use Case zu einem anderen Use Case, dessen Funktionsverhalten nicht immer vom Base Case, sondern nur unter zusätzlichen Bedingungen verwendet wird. Beachten Sie jedoch, dass eine sekundäre Rolle in Bezug auf den Anwendungsfall nicht bedeutet, dass diese Rolle von untergeordneter Bedeutung ist. Darüber hinaus sehen wir in dem Diagramm, dass die Rolle des TS-Benutzers aus den Rollen von Trader und Investor durch die Verallgemeinerungsrelationen besteht und als Linie mit der unbemalten dreieckigen Pfeilspitze dargestellt ist. Feige. 4. Use-Case-Diagramm der TS Use Cases Offene Position und Close-Position, die wiederum durch eine Generalisierung mit dem Trading verbunden sind. Der letztere Fall ist die Basis für die beiden anderen. Sie enthält also den Anwendungsfall Risiko verwalten. Und sein Verhalten ist komplementär zum abhängigen Fall Profit. Da der TS-Gewinn unter der Bedingung gebildet wird, dass der Verkaufspreis eines Vermögenswertes größer als der Kaufpreis ist, habe ich die Verlängerungsbeziehung für diese Fälle verwendet. Das Diagramm zeigt auch den Erweiterungspunkt, d. h. eine spezifische Bedingung, unter der das Case To Profit verwendet wird. Abhängigkeiten werden durch die gestrichelte Linie mit einem Pfeil mit den entsprechenden Stereotypen ein - und ausgeblendet dargestellt. Für jeden Anwendungsfall müssen Sie ein Szenario erstellen, dh eine Sequenz von Schritten beschreiben, die zu dem beabsichtigten Ziel führt. Der Anwendungsfall kann in mehreren Formen beschrieben werden. Die allgemein akzeptierten Formen umfassen die folgenden: Textbeschreibungen, Pseudocode, Aktivitätsdiagramm, Interaktionsdiagramm. Es ist anzumerken, dass ein Händler an einem TS in seinem strengen Sinn interessiert ist, anstatt an dem, was in 1 gezeigt ist. 4. Daher schlage ich vor, auf den Use Case Trading mit der Erweiterung zu profitieren. Mit dem Klassendiagramm beschreiben wir die TS-Struktur. Wir werden ein Modell einer statischen Struktur des Handelssystems in Form von Klassen der objektorientierten Programmierung vorstellen. Somit spiegeln wir die Programmierlogik des TS wieder. In UML ist ein Klassendiagramm eine Art statischer Strukturdiagramme. Es beschreibt die Struktur des Systems, indem es seine Klassen, seine Attribute und Operatoren, sowie die Beziehung der Klassen. Was sind die Vorteile dieser Art von Diagramm Wer mit den objektorientierten Programmiersprachen ein wenig vertraut ist, bemerkt sofort den vertrauten Begriff der Klasse. Die Klasse agiert im UML-Klassendiagramm als Grundbaustein. Beispielsweise wird beim Erstellen eines C-Codes der UML-Klassenblock automatisch in Form einer Klassenvorlage erstellt. Sie müssen nur die Implementierung jeder Methode und Eigenschaft beenden. Jetzt können wir versuchen, etwas als Beispiel zu entwerfen. Aber zuerst möchte ich Sie auf den Artikel Prototyp eines Handelsroboters aufmerksam machen. In der der Autor die Vorteile der Verwendung einer geraden Logik beschreibt. Meiner Meinung nach, sehr effektiv und produktiv ist das Prinzip der Verschachtelung - Makros-Funktionen-Handels-Module. Zum Beispiel benötigen wir einen Expertenratgeber, der die Möglichkeit von Handelsklassen der Standardbibliothek nutzt. Erstellen Sie im Klassendokument ein Klassenmodell im Klassendiagramm. Ich nannte es CTradeExpert. Wir fügen einige Attribute (in MQL5 sind sie Datenelemente der Klasse) für die neue Klasse hinzu. Sie sind: MagicNo, etrade, eaccount, edeal, esymbol, epnt. Wir fügen auch eine Konstruktormethode der Klasse CTradeExpert ein. Grafisch wird die Operation wie in Fig. Fig. 5. UML-Modell der Klasse CTradeExpert Das Zeichen - vor einem Attribut gibt an, dass das Attribut das Zugriffsrecht im Modus private, - protected, - public hat. Somit ist für das Attribut MagicNo der Zugriffsspezifizierer als privat gesetzt. Für epnt - als Öffentlichkeit. Und für andere - als geschützt. Ein Doppelpunkt, der dem Attributnamen folgt, gibt einen Datentyp für Attribute und Datentypen für Methoden an. Zum Beispiel ist das Attribut MagicNo vom Typ int, etrade - CTrade usw. Wir fügen jetzt keine Methoden und Attribute hinzu, sondern zeigen einfach, wie unsere Klasse CTradeExpert mit den Klassen der Standardbibliothek verbunden ist. Fügen Sie dem Diagramm 6 Blöcke von Klassen hinzu, und rufen Sie sie wie folgt auf: CTrade, CAccountInfo, CDealInfo, CSymbolInfo, CObject. Jetzt verbinden wir das Modell der CTradeExpert-Klasse mit 4 Blöcken von Handelsklassen durch Abhängigkeitsbeziehungen zum Gebrauchstereotyp (die strichpunktierte Linie mit einem Pfeil). Die Abhängigkeit ist eine semantische Beziehung zwischen zwei Entitäten, in der eine Veränderung der unabhängigen von ihnen die Semantik der anderen abhängigen beeinflussen kann. Stereotyp in UML ist eine Beschreibung des Objektverhaltens. Dann verknüpfen wir diese Blöcke mit dem Block CObject durch die Verallgemeinerungsrelation unter Verwendung einer Linie mit einer unbemalten dreieckigen Pfeilspitze. Fügen Sie den Standardbibliothekenklassen Kommentare hinzu. Nun sieht unser UML-Diagramm wie in Abbildung 6 dargestellt aus. 6. UML-Klassendiagramm Wir müssen den Code nur noch mit der Funktion Generieren der Registerkarte Generieren in der Seitenleiste erzeugen (Bild 7). Feige. 7. Generierter Code Am geeignetsten ist die Sprache. Wir verwenden C den Code der Expert Advisor-Klasse generieren, und dann werden wir es leicht in MQL5 zu übersetzen. Für dieses Diagramm ist der generierte Code wie folgt: Eine wirklich vertraute Syntax, ist es nicht Wir müssen nur den Körper der Klasse passen. Dazu erstellen wir in MetaEditor eine Datei für die neue Klasse TradeExpert. mqh. Kopieren Sie den zuvor generierten Code. Zur Lesbarkeit löschen wir den wiederholten Zugriffsspezifizierer, der für die Mitglieder der CTradeExpert-Klasse geschützt ist. Löschen Sie die Zeilen, die mit der Deklaration der Standardbibliothekenklassen verbunden sind. Danach fügen Sie die Datei mit der Anweisung Include für jede verwendete Klasse der Standardbibliothek hinzu, da diese Klassen bereits vom Entwickler definiert sind. Und fügen Sie unsere Kommentare. Als Ergebnis erhalten wir den Code wie folgt: Jetzt können wir noch weitere Handelsfunktionsmodule zu unserer Experten-Advisor-Klasse hinzufügen. Diese können sein: CheckSignal, OpenPosition, CheckPosition, ClosePosition etc. Ich hoffe, dass Sie das Prinzip der Bedingung Bedienen bereits kennen. In diesem Fall würde unsere Testklasse CTradeExpert Ihnen nicht schwer fallen. Ich konzentrierte mich speziell auf einige bereits vertraute Beispiel eines Expert Advisor, um es Ihnen zu erleichtern, die Mechanismen der UML zu verstehen. So, jetzt das Modell der Klasse sieht aus wie in Abb. Fig. 8. UML-Modell der Klasse CTradeExpert Für das aktualisierte Modell der Klasse können wir auch einen Code mit der bereits beschriebenen Methode erzeugen. 2.3 Aktivitätsdiagramm Mit Hilfe dieser Art von UML-Diagrammen können wir das Verhalten des Systems anhand der Modelle des Datenflusses und des Kontrollflusses untersuchen. Aktivitätsdiagramme sind grafische Darstellungen von Arbeitsabläufen von schrittweisen Aktivitäten und Aktionen. Das Aktivitätsdiagramm unterscheidet sich vom Flußdiagramm, das nur die Schritte des Algorithmus beschreibt. Die Aktivitätsdiagramm-Notation ist breiter. Beispielsweise ist es möglich, den Zustand der Objekte darin festzulegen. Aktivitätsdiagramme werden von Entwicklern für die Beschreibung von: Geschäftsregeln Einzelbenutzungsfälle komplexe Reihen von Mehrfachnutzungsfällen Prozesse mit Lösungen und alternativen Strömen parallele Operationen Programmabläufe und logische Steuerelementstrukturen Angenommen, die erstellte Expertenklasse CTradeExpert wird in der Datei der Fachberater TestTradeExpert. mq5. Wie wir uns erinnern, bietet die Standardvorlage beim Erstellen einer EA im MetaEditor 5 drei standardmäßige Ereignishandlerfunktionen: OnInit. OnDeinit und OnTick. Lasst uns auf ihnen wohnen. Lets versuchen, ein Diagramm mit unserer EA-Betrieb Buchhaltung für die Datei TestTradeExpert. mq5 anzuzeigen. Hier ist anzumerken, dass der Expert Advisor, oder besser gesagt seine Struktur, eher primitiv ist. Wir trainieren nur noch. Eine einfache EA-Struktur ist für diesen Zweck ok. Gestalten Sie ein Diagramm für eine Verwendung unseres Expertenberaters, dessen Algorithmus in der Datei TestTradeExpert. mq5 dargestellt wird. Also, alles beginnt mit dem Anfangsknoten (Abb. 9). Von diesem Knoten wechselt ein Steuerelement zu dem Knoten, der die Aktion aufruft, eine Expert Advisor-Instanz an. Mit dieser Aktion wird der Fluss des Objekts (blauer Pfeil) initiiert, der den Status des Objektknotens (myTEcreated) ändert und den Ablauf an einen Knoten weiterleitet, der den Experten-Advisor initialisiert. Eine Steuerströmung wird in Form einer Aktivitätsflanke dargestellt, die die beiden Knoten der Aktivität miteinander verbindet und über die nur Kontrollknoten geführt werden. Ein Objektfluss wird als Aktivitätskante dargestellt, an die nur Objekt - oder Daten-Token übergeben werden. Ein Aktivitätsknoten ist eine abstrakte Klasse für einzelne Punkte im Fluss von Aktivitäten, die durch Kanten verbunden sind. Ein Entscheidungsknoten ist ein Steuerknoten, der zwischen ausgehenden Flüssen auswählt. Ein Objektknoten stellt in der Aktivität verwendete Objekte dar. Eine Aktivitätskante ist eine abstrakte Klasse für gerichtete Verbindungen zwischen zwei Aktivitätsknoten. Der Anfangsknoten zeigt an, wo die Aktivität beginnt. Der letzte Knoten einer Aktivität vervollständigt alle Aktivitätsflüsse. Dies wiederum ändert den Zustand des Objektes myTE (myTEinitialized) und leitet das Kontroll-Token an den Entscheidungsknoten weiter. Wenn der Expert Advisor erfolgreich initialisiert wird, geht der Control Flow zum Knoten Process the trade event NewTick. Wenn die Initialisierung fehlschlägt, wird das Kontroll-Token zuerst den Verallgemeinerungsknoten eingeben und dann der Aktionsknoten Deinitialize Expert Advisor. Tokens sind abstrakte Konstruktionen, die zur Bequemlichkeit bei der Beschreibung des dynamischen Prozesses der Ausführung eines statistisch definierten Aktivitätsgraphen eingeführt werden. Das Token darf keine zusätzlichen Informationen enthalten (ein leeres Token). In diesem Fall wird es als Kontrollfluss-Token bezeichnet, oder es kann einen Verweis auf ein Objekt oder eine Datenstruktur enthalten und wird in diesem Fall als Datenfluss-Token bezeichnet. Betrachten wir den ersten Kontrollfluss, der vom Entscheidungsknoten kommt. Es ist auf einen Bereich mit einer unterbrochenen Aktion gerichtet, wie durch ein Rechteck mit abgerundeten Ecken, die durch die rote gestrichelte Linie gezeichnet sind, und dem Stereotyp des Unterbrechbaren angedeutet ist. Wenn sich der Kontrollfluss in diesem Bereich befindet, kann er unerwartet stoppen. Wenn Sie den Aktionsknoten (orangefarbenes Kennzeichen) aktivieren, das das Ereignis Unload Expert Advisor empfängt, unterbricht es alle Flüsse. Das Steuerelement bewegt sich zur Unterbrechungskante (orange Zickzackpfeil) und dann zum Verbindungsknoten. Danach wird die EA deinitialisiert. Anschließend geht das Steuerelement zum Knoten globale Variablen löschen, dann wird der Fluss im letzten Aktivitätsknoten abgeschlossen. Der Aktionsknoten Deinitalize Expert Advisor ändert auch den Zustand des Objekts myTE (myTEdeinitsialized) durch einen Objektfluss. Der Knoten Delete globale Variablen wiederum entfernt das Objekt myTE (myTEdeleted). Feige. 9. Aktivitätsdiagramm für TestTradeExpert. mq5 Angenommen, der Kontrollfluss ist stabil: Der EA wird nicht entladen. Vom Knoten Process das Trade-Ereignis NewTick fließt der Flow in einen anderen Block - Expansionsbereich, dessen Stereotype als iterativ definiert ist (grünes Rechteck mit gepunkteten Linien). Ich nenne diesen Bereich Handelsblock, um die grundlegenden Eigenschaften zu reflektieren und die Wahrnehmung des Diagramms zu verbessern. Ein charakteristisches Merkmal des Bausteins ist die zyklische Ausführung von Operationen für eingehende Objekte. Wir brauchen nur 2 Zyklen - handhaben Sie die langen und kurzen Richtungen. Am Eingang des Blocks und dem Ausgang des Blocks befinden sich Erweiterungsknoten, die Handelsrichtungsobjekte (lang oder kurz) umfassen. Ein Erweiterungsknoten ist eine Sammlung von Objekten, die in den Erweiterungsbereich ein - oder ausgehen, der einmal für jedes Objekt ausgeführt wird. Der Aktionsknoten, der ein Signal sendet (Signal senden), repräsentiert die Signalübertragung. Der Aktionsknoten, der ein Ereignis akzeptiert (Ereignisaktion akzeptieren), wartet auf den Empfang eines Ereignisses des entsprechenden Typs. Somit wird jede Richtung von solchen Knoten wie folgt gehandhabt: Überprüfungssignal (Signalsendeknoten), Empfangssignal (Signalempfangsknoten), Offenstellung (Signalsendeknoten), Kontrollposition (Signalsendeknoten), Schließposition (Signalsendeknoten) . Es sei angemerkt, dass das Richtungsobjekt (dir) im Objektfluss zwischen Aktionsknoten, wie durch violette Pfeile angedeutet, passiert werden kann. Die Operationen in einem Block werden fortgesetzt, solange der Expert Adviser entladen ist. 2.4 Das Sequenzdiagramm Wir verwenden das Sequenzdiagramm zur Beschreibung der Objektinteraktionssequenz. Ein sehr wichtiger Aspekt dieser Art von Diagramm ist die Zeit. Das Diagramm hat also zwei Skalen in einer impliziten Form. Die horizontale ist für die Abfolge von Objektwechselwirkungen verantwortlich. Die vertikale ist eine Zeitachse. Der Beginn des Zeitintervalls ist der obere Teil des Diagramms. Die Oberseite des Diagramms enthält Diagrammobjekte, die interagieren. Ein Objekt hat seine eigene Rettungsleine als vertikale gepunktete Linie. Die Objekte tauschen Nachrichten aus. Sie sind durch Pfeile dargestellt. Wenn ein Objekt aktiv ist, erhält es den Steuerungsfokus. Grafisch wird dieser Fokus als schmales Rechteck auf der Rettungsleine ausgedrückt. Ein Objekt ist ein Rechteck, das einen unterstrichenen Objektnamen und einen Klassennamen (optional) enthält, die durch einen Doppelpunkt getrennt sind. Eine Objekt-Lebenslinie ist eine Zeile, die die Existenz eines Objekts für eine gewisse Zeitdauer zeigt, je länger die Zeile ist, je länger das Objekt existiert. Der Steuerfokus wird als ein schmales Rechteck gezeichnet, dessen obere Seite den Beginn des Empfangs des Steuerfokus durch das Objekt (Aktivitätsstart) und dessen Nachteil - das Ende des Steuerfokus (Ende der Aktivität) bezeichnet. In UML wird jede Interaktion durch einen Satz von Meldungen beschrieben. Die die daran teilnehmenden Gegenstände austauschen. Lets haben einige Übung. Das Terminal ist ein Schauspieler. Es initiiert den Betrieb des Expertenberaters. Weitere mit dem Ereignis-Stereotyp markierte Objekte sind die Ereignisse des Client-Terminals: Init. Deinit. NewTick. Natürlich, wenn Sie möchten, können Sie das Spektrum der Veranstaltungen erweitern. Beim Starten eines Expertenberaters wird das myTE-Objekt auf globaler Ebene erstellt. Es ist eine Instanz der CTradeExpert-Klasse. Das Klassenobjekt ist etwas niedriger als andere Objekte im Diagramm, was anzeigt, dass es nach der Konstruktorfunktion erstellt wird. Ein Erstellungsbefehl ist mit einer strichpunktierten Linie a mit offenem Pfeil und einer Meldung 1.1 CTradeExpert () markiert. Die strichpunktierte Linie mit einem Pfeil kennzeichnet den Erstellungstyp des Standardkonstruktors CTradeExpert (). Nach dem Erstellen einer Instanz von CTradeExpert wird Schritt 1.2 aktiviert - der Steuerungsfokus wird an das Terminal zurückgegeben. Zur Lesbarkeit zeige ich synchrone Nachrichten im Format von., Wie 1.1 und asynchron - an. Anschließend behandelt das Terminal das Init-Ereignis mit der Funktion OnInit () in Schritt 2.1, der Fokus wird in Schritt 2.2 zurückgegeben. Ruftypnachrichten werden am Ende als Linien mit einem gemalten Dreieckspfeil dargestellt. Wenn das Init-Ereignis einen Wert ungleich Null an das Terminal zurückgibt, bedeutet dies, dass die Initialisierung fehlgeschlagen ist: Schritt 3.1 wird verwendet, der zur Erzeugung und Handhabung des Deinit-Ereignisses führt. In Schritt 3.2 wird der Steuerungsfokus an das Terminal zurückgegeben. Dann wird das CTradeExpert-Klassenobjekt gelöscht (Schritt 4.1). By the way, beim Erstellen eines Klassendiagramms, habe ich nicht die Destruktorfunktion CTradeExpert in der Klasse enthalten. Dies kann später erfolgen. Dies ist einer der Vorteile der Diagramm-Konstruktion - der Prozess der Konstruktion von mehreren Diagrammen ist iterativ. Was zuerst für ein Diagramm getan wurde, kann dann für ein anderes getan werden, und später können Sie das erste ändern. Es ist zu beachten, dass der MQL5-Code einer Standard-EA-Vorlage keinen Block enthält, der die fehlgeschlagene Initialisierung verarbeitet. Ive spezifiziert, um die Logik der Sequenz zu speichern. Das UML-Sequenzdiagramm verwendet den Opt-Block mit einer Guard-Bedingung OnInit () 0, die der MQL5-Konstruktion äquivalent ist, wenn (OnInit () 0). In Schritt 4.2 wird die Steuerung an das Terminal übertragen. Nun ist das Terminal bereit, das Ereignis NewTick zu behandeln. Die Verarbeitung dieses Ereignisses erfolgt in der Blockschleife, dh eine Endlosschleife. Das heißt, die EA wird dieses Ereignis behandeln, bis wir es deaktivieren. Das Terminal verarbeitet das NewTick-Ereignis über die OnTick-Funktion (Schritt 5). In Schritt 6 wird der Steuerungsfokus auf den Expertenratgeber myTE übertragen. Mit 4 reflexiven Meldungen implementiert er folgende Funktionen: CheckSignal, OpenPosition, CheckPosition, ClosePosition. Die Reflexivität ist darauf zurückzuführen, dass das Expert Advisor-Objekt Nachrichten an sich selbst sendet. Außerdem sind diese Funktionen der CTradeExpert-Klasse in dem Schleifenblock (2) eingeschlossen. Zwei bedeutet, daß die Schleife aus zwei Durchgängen besteht. Warum zwei Weil es zwei Handlungsrichtungen behandelt - lange und kurze (von Schritt 7 zu 10). Im 11. Schritt wird der Fokus auf das Terminal übertragen. Die Schritte 12 und 13 sind für die Deinstallation und das Löschen des Expert Advisor-Objekts verantwortlich. Feige. 10. SD-Diagramm für TestTradeExpert. mq5 So haben wir die primären Design-Fähigkeiten. Mit Hilfe von Diagrammen wird die erstellte, die Arbeit des Entwicklers optimiert. Wir können nun einen Code für die Datei TestTradeExpert. mq5 schreiben. Natürlich können Sie auf Diagramme verzichten. Aber wenn Sie eine komplexe Expert Advisor haben, reduziert die Verwendung von Diagrammen die Wahrscheinlichkeit von Fehlern und ermöglicht es Ihnen, effizient verwalten die Entwicklung Ihrer TS. Mit der Expert Advisor-Vorlage erstellen wir nun TestTradeExpert. mq5. Wir erstellen eine Instanz der CTradeExpert myTE-Klasse auf globaler Ebene. Jetzt können Sie füllen Sie den Körper der OnTick () - Funktion. Wir schreiben die Funktionen der Klasse wie folgt: So etwas wird die Behandlung des NewTick-Ereignisses sein. Natürlich müssen wir noch jede der Funktionen festlegen, die von den Klassendatenmitgliedern verwendet werden, unter anderem. Aber lassen Sie diesen Job für die Zukunft. Nun ist es unser Ziel, die Logik von UML-Diagrammen in den MQL5-Code zu übertragen. 3. Entwicklung und Präsentation eines Expertenberaters anhand der UML-Diagramme Als Beispiel können wir Diagramme für einen komplexen Expertenratgeber erstellen. Lets definieren ihre Funktionen im Rahmen einer bestimmten Strategie in der MQL 5 implementiert. Im Allgemeinen wird unsere Expert Advisor Handelstätigkeiten durchführen, insbesondere wird es Handelssignale erzeugen, offene Positionen und Money-Management beibehalten. Es ist eher eine Vorlage Handel Strategie. Für Schulungszwecke werden wir jedoch versuchen, mit diesem zu arbeiten. Zuerst erstellen wir ein Anwendungsfalldiagramm für unsere EA. Nur bis zu einem gewissen Grad wird es anders sein als das, was früher diskutiert wurde. Ich beachtete das interne Umfeld des TS und ignorierte die Außenwelt (Abb. 11), da wir im Code nur die Handelsaufgaben umsetzen werden. Feige. 11. Use-Case-Diagramm des TS Jetzt wollen wir die Struktur des Expert Advisor definieren. Nehmen wir an, dass wir die Standardbibliotheksentwicklungen nutzen werden, weil es mit den erklärten Zielen des TS übereinstimmt. Vor kurzem wurde sie wesentlich erweitert. Und vor allem geht es um die Klassen von Handelsstrategien. Unser Ziel ist es also, ein Klassendiagramm zu erstellen. Es wird nicht einfach sein, so dass Sie Geduld brauchen. Hier möchte ich beachten, dass wir die Standardbibliothek aus wenigen Gründen betrachten. Zunächst versuchen wir, einen Handelsroboter zu schaffen. Und zweitens, was auch wichtig ist, haben wir einige Praxis mit UML-Diagrammen zu arbeiten. Drittens, vielleicht ist die Bibliothek selbst sehr wertvoll. So können wir viele nützliche Dinge aus dem Bibliothekt lernen und gleichzeitig versuchen, seine nicht ganz einfache Struktur zu verstehen. Die Umwandlung eines Codes in die Struktur eines UML-Diagramms wird als Reverse Engineering bezeichnet. Tatsächlich tun wir das manuell. Es gibt professionelle Software, die Ihnen erlaubt, dies automatisch (IBM Rational Rose, Visual Paradigm für UML, etc.). Aber für praktische Zwecke, denke ich, müssen wir manuell arbeiten. Erstellen Sie ein Modell der Basisklasse, um die Handelsstrategien CExpert zu implementieren, indem Sie den Klassenblock verwenden. Lets sehen, was andere Klassen und Konstruktionen im Körper der C Expert-Klasse verwendet werden. Zunächst ist anzumerken, dass die Klasse C Expert von der Basisklasse CExpertBase abgeleitet ist. Die wiederum von der Basisklasse CObject abgeleitet ist. In dem Diagramm erstellen wir Blöcke für diese Klassen und definieren die Beziehung zwischen den Klassen mit einer Linie mit einer unlackierten dreieckigen Pfeilspitze (Generalisierung). Fügen Sie dem Modell der Klasse CExpert einen Kommentar hinzu (ein gelbes Rechteck mit einer gebogenen Ecke). Die Zwischenklassenstruktur sieht nun so aus - Abb. 12. Rufen Sie das Diagramm Expert auf. Feige. 12. Das Experten-Diagramm, die ursprüngliche Ansicht Lets sehen den Code in der Expert. mqh-Datei. Die Klasse CExpert. Unter anderem mit Enumerationen ENUMTRADEEVENTS und ENUMTIMEFRAMES. Einer der 8 vordefinierten Strukturen MqlDateTime. Die Klasse verwendet auch andere Klasseninstanzen, wie: CExpertTrade, CExpertSignal. CExpertMoney. CExpertTrailing. Anzeiger. CPositiontInfo. COrderInfo. Nun müssen wir einige Änderungen am Diagramm vornehmen. Zuerst legen wir fest, dass die Klassen CExpertSignal. CExpertMoney. CExpertTrailing werden von einer Basisklasse CExpertBase abgeleitet. Und Klassen CPositiontInfo. COrderInfo werden von CObject abgeleitet (Ive setzt die Stereotype Metaklasse dafür). Lets markieren die Abhängigkeitsbeziehungen mit der Verwendung Stereotyp zwischen dem Block der Klasse CExpert und andere Klassen, nicht über die MqlDateTime Struktur und Enumerationen zu vergessen. Wir verändern den Farbstil der Blöcke und erhalten folgende Struktur: Abb. Fig. 13. Das Experten-Diagramm, die Anfangsansicht Diese Struktur spiegelt jedoch nicht das Gesamtbild wider, da es eine Anzahl von Klassen gibt, die indirekt von den bereits erwähnten Klassen verwendet werden. Welche Art von Klassen sind sie zuerst, wird die CExpertTrade-Klasse von CTrade abgeleitet. Letzteres ist eine Unterklasse von CObject. Die CExpertTrade-Klasse verwendet die ENUMORDERTYPETIME-Enumeration, die Klassen CSymbolInfo und CAccountInfo sind ebenfalls Kinder von CObject. Die CTrade-Klasse verwendet auch Instanzen der CSymbolInfo-Klassen. Nehmen Sie Änderungen am Diagramm vor. Nun hat unser Diagramm die folgende Form: Abb. Fig. 14. Das Experten-Diagramm, die Anfangsansicht Das Diagramm ist wiederum nicht vollständig. Wenn Sie beispielsweise in der Standardbibliotheksdatei Trade. mqh nachsehen. Werden Sie sehen, dass CTrade mehrere verschiedene Strukturen, Aufzählungen und die CSymbolInfo-Klasse verwendet. Wenn sie alle auf einem Diagramm angezeigt werden, wird es zu viel geladen. Und das wird es schwer zu verstehen. Um diese Schwierigkeit zu bewältigen, verwendete ich ein Paket für das Diagramm. Es kapselt verwandte Klassen, Aufzählungen, andere Pakete, etc. Ich verband das Paket mit den Diagrammelementen über die Schnittstelle. Zum Beispiel kann das Diagramm für das Paket CTrade wie folgt dargestellt werden - Abb. Fig. 15. Das Klassendiagramm für das CTrade-Paket Das Diagramm des CTrade-Pakets zeigt Abhängigkeitsbeziehungen der CTrade-Klasse mit Aufzählungen und Strukturen. Beziehungen zu der CObject-Basisklasse und der verwendeten CSymbolInfo-Klasse werden über eine Schnittstelle implementiert. In der Nähe der Schnittstellen gibt es eine Ikone der Relation mit dem Klassendiagramm, das das CTrade-Paket als ein einzelnes Element enthält. Wenn Sie auf eine der Schnittstellen klicken, gelangen Sie automatisch in das ursprüngliche Diagramm (Abb. 16). Abb. 16. Das Expertendiagramm mit Schnittstellen Die Schnittstellenbeziehungen sind orange. Das Symbol des Klassendiagramms neben dem CTrade-Paket gibt die Möglichkeit an, zu diesem Diagramm zu gelangen. Somit können wir mit Hilfe der Kapselung die Lesbarkeit des Klassendiagramms deutlich verbessern. Also, gehen wir weiter. Die CObject-Klasse verwendet Zeiger auf Instanzen derselben Klasse in ihrem Körper. Daher können wir die Abhängigkeitsbeziehung für den CObject-Block mit der Stereotype-Verwendung relativ zu sich selbst setzen. Schauen wir uns den Block des CExpertBase-Klassenmodells an. Basierend auf den ersten Zeilen der Header-Datei ExpertBase. mqh können wir sagen, dass diese Klasse mehrere Instanzen verschiedener Klassen und Aufzählungen verwendet. Daher ist es für das Klassenmodell und seine Beziehungen sinnvoll, das Paket CE xpertBase zu erstellen. So definieren wir zuerst das CExpertBase-Klassenmodell im Paketdiagramm. Über die Schnittstelle zeigen wir die Beziehung zur Basisklasse CObject. Und die Beziehung der Verwendung mit den Klassen CSymbolInfo und CAccountInfo. Mit Hilfe von Klassenblöcken und Abhängigkeitsbeziehungen legen wir fest, dass die Klasse CExpertBase die folgenden Klassen verwendet: CiOpen. CiHigh. CiLow CiSpread. CiTime. CiTickVolume. CiRealVolume. Die ersten vier Klassen sind von CPriceSeries abgeleitet. Und die letzten vier von CSeries. Darüber hinaus hat die CSeries-Klasse ein Kind CPriceSeries und ist wiederum ein Kind von CArrayObj. Die Vererbungsbeziehungen wurden vorher verwendet, wie wir uns erinnern. Bezeichnen Sie sie als Verallgemeinerungsbeziehung im Diagramm. Vergessen Sie nicht, dass die Klasse CExpertBase in ihrem Körper solche Aufzählungen wie: ENUMTYPETREND verwendet. ENUMUSEDIENSTE. ENUMINITPHASE. ENUMTIMEFRAMES. Die letzte Aufzählung wird auch von den Kindern der Klasse CPriceSeries und Klasse CSeries verwendet. Um die Beziehungen nicht zu verlieren und das Diagramm klar zu machen, können Sie den Stil für jedes der Elemente des Diagramms anpassen. Als Ergebnis erhalten wir das folgende Diagramm (Fig. 17). Feige. 17. Das Klassendiagramm für das CExpertBase-Paket Es ist noch nicht vollständig, und wir müssen noch mehr daran arbeiten. Es stellt sich heraus, dass die vier Klassen, die die CPriceSeries-Klasse erben, auch die CDoubleBuffer-Klasse verwenden. Darüber hinaus verwendet jede der vier Klassen ihre Pufferklasse, die von CDoubleBuffer abgeleitet ist. So verwendet COpen COpenBuffer etc. CDoubleBuffer hat eine Basisklasse (CArrayDouble) und verwendet ENUMTIMEFRAMES. CArrayDouble erbt CArray. uses pointers to the instances of its same class and the ENUMDATATYPE enumeration. The COpenBuffer class and other buffer classes of price series (CHighBuffer. CLowBuffer. CCloseBuffer ) use the ENUMTIMEFRAMES enumeration. The four classes that inherit the CSeries class only use their own buffer classes (CSpreadBuffer. CTimeBuffer. CTickVolumeBuffer. CRealVolumeBuffer ). The first of the class buffers CSpreadBuffer inherits CArrayInt. others CArrayLong . The last two classes use the pointers to the instances of their own class, the ENUMDATATYPE enumeration and are derived from CArray. which, in turn, is a child of class CObject. The CPriceSeries class and its children use the CDoubleBuffer class and the ENUMTIMEFRAMES enumeration. CSeries uses enumerations ENUMSERIESINFOINTEGER. ENUMTIMEFRAMES. It inherits CArrayObj. The latter one inherits CArray. uses ENUMPOINTERTYPE. pointers at the instances of its own class and the CObject class. As a result, we obtain the diagram shown in Figure 18. Fig. 18. Extended class diagram for the CExpertBase package And the original diagram Expert for classes and packages CExpert. CExpertBase . CSymbolInfo. CAccountInfo and CObject with interfaces looks as follows (Fig.19). Feige. 19. The Expert diagram with interfaces Ive also added the ENUMORDERTYPE enumeration used by CExpertTrade. For readability, Ive marked the group of relationships with different colors. We continue our work. I hope that you understand the logic. The model of a class on the diagram may have many relationships with other classes and other entities. So I just replace some set with a package in the base diagram. So, lets study CSymbolInfo. If you look at the code of SymbolInfo. mqh. you will see that the base class CSymbolInfo uses some MQL5 enumerations and structures. Its good to use a package for it and its relationships (Fig. 20). Feige. 20. Diagram of the CSymbolInfo package Some free space in the diagram can be used for comments. Also, Ive marked the interface of relation with the parent class CObject. The original Expert diagram of packages and classes will be slightly modified. I will give its updated version later on, when all the classes and packages are reflected in the diagram. So, lets move on. Lets look at the MQL 5 code in AccountInfo. mqh. As it turns out, CAccountInfo also uses some enumerations. We reflect them on the diagram of the package that will create for this class and its relationships with other entities (Fig. 21). Feige. 21. CAccountlInfo package diagram Now lets deal with the CExpert class. For this class, we also create a package CExpert . which will appear as shown in Fig. 22. We continue to improve the readability of our main diagram. The CExpert class is connected with several other classes, as indicated by the orange interface lines with an arrow. Feige. 22. CExpert package diagram Lets explore other remaining classes. We will creaet more packages for them. CExpertSignal derives from CExpertBase. This relationship has already been shown on the original diagram Expert . In addition, the CExpertSignal class uses CArrayObj. COrderInfo. CIndicators and instances of its own class (Fig .23). In particular, the interface of relationship with the CArrayOb j class will bring us to the CExpertBase package diagram, which shows the relationship of the CArrayObj class with other entities. Feige. 23. CExpertSignal package diagram I am not showing all the diagrams now - they are all available in the attached file Expert. simp. Now lets take a look at our updated diagram of packages and classes Expert (Fig. 24). As you can see, almost all the key classes in the diagram have been encapsulated into packages to make the diagram easier to understand. I have changed the color of the generalization line into brown, to distinguish it from the line of the dependency relationship. Feige. 24. The diagram of packages and classes Expert So, we have reflected all that can be taken from the code available in the standard library for creating diagrams. We only need to add some more blocks, which specify the trading operations of the Expert Advisor. The very first block is the block of CmyExpert that inherits trading skills from the CExpert class. This is the block, for which we have so long been engaged in reverse engineering. He will implement a specific trading strategy. We also need to specify the virtual functions of the base classes of the EA. for this purpose, we create a block of classes CmyExpertSignal, CmyExpertMoney. CmyExpertTrailing and indicate that they are derived from the appropriate (Fig. 25). Feige. 25. Expanded diagram of packages and classes Expert What functions and data should each of the classes include is up to the developer. Here, Im trying to show the more general scheme, not a specific implementation of a derived class. Thus, for each of the derived classes we can create a separate diagram with a detailed list of included methods and properties, as has been done, for example, in Fig. 8. Now lets see how we can use the sequence diagram in our work. Let me remind you that it shows how our EA operates with respect to the timeline. So, we write details of the EA work in chronological order (Fig. 26). Feige. 26. The Sequence diagram of the Expert Advisor The terminal serves as an actor. At the global level it creates the myTrader object - an instance of CmyExpert (Step 1.1). Green denotes predefined events of the client terminal (Init. Deinit. NewTick. Trade .) The sequence diagram logic has been described earlier. Here I would like to point out some specific points. When the body of the Expert Advisor grows, and there is more and more code, it becomes more difficult to display it in a diagram. To solve this problem, use the block approach. A set of some common functions is visualizes in the form of a block. As a rule, it is another sequence diagram. It is said to be an interaction use. Thus, in this case, I created a sequence diagram called OnInit in order to reflect the logic of handling of the terminal event Init in a separate diagram. Syntactically it is defined as a border with the keyword ref ( reference) and is used when the control token passes from OnInit (step 2.1) to the lifeline of the Init object. In addition, Ive set an interface move to this sequence diagram for OnInit. That is, if you click 2 times on the border, you can actually open a detailed sequence diagram of OnInit (Fig. 27). Feige. 27. The sequence diagram of OnInit Moves to other sequence diagrams is very convenient for repetitions of some actions. For example, the OnInit diagram contains actions connected with EA deinitialization, the processing of which is done in myTrader Deinit (Fig. 28). Feige. 28. The sequence diagram of myTraderDeinit In general, at this stage of EA design I have four sequence diagrams. Naturally, during a more serious development you may need additional diagrams. For example, I havent handled other events of the client terminal (NewTick. Trade ). Conclusions In this article, I suggested to take into account the multidimensional nature of the Expert Advisor development process using the graphical language UML, which is used for visual modeling of object-oriented software systems. The main advantage of this approach is the visualization of the designer. As with any complex phenomenon, UML has its own disadvantages that the developer should be aware of (redundancy, imprecise semantics, etc.). I hope that the described methodology of EA development is interesting for you. I would be grateful for any comments and constructive criticism. Location of files:Use Case Diagrams Use Case Diagrams In addition to introducing use cases as primary elements in software development, Jacobson (1994) also introduced a diagram for visualizing use cases. The use case diagram is also now part of the UML. Many people find this kind of diagram useful. However, I must stress that you dont need to draw a diagram to use use cases. One of the most effective projects I know that used use cases involved keeping each one on an index card and sorting the cards into piles to show what needed building in each iteration. Figure 3-2 shows some of the use cases for a financial trading system. Figure 3-2. Use Case Diagram An actor is a role that a user plays with respect to the system. There are four actors in Figure 3-2: Trading Manager, Trader, Salesperson, and Accounting System. (Yes, I know it would be better to use the word role, but apparently, there was a mistranslation from the Swedish.) There will probably be many traders in the given organization, but as far as the system is concerned, they all play the same role. A user may also play more than one role. For instance, one senior trader may play the Trading Manager role and also be a regular trader a Trader may also be a Salesperson. When dealing with actors, it is important to think about roles rather than people or job titles. Actors carry out use cases. A single actor may perform many use cases conversely, a use case may have several actors performing it. In practice, I find that actors are most useful when trying to come up with the use cases. Faced with a big system, it can often be difficult to come up with a list of use cases. It is easier in those situations to arrive at the list of actors first, and then try to work out the use cases for each actor. Actors dont need to be human, even though actors are represented as stick figures within a use case diagram. An actor can also be an external system that needs some information from the current system. In Figure 3-2, we can see the need to update the accounts for the Accounting System. There are several variations on what people show as actors. Some people show every external system or human actor on the use case diagram others prefer to show the initiator of the use case. I prefer to show the actor that gets value from the use case, which some people refer to as the primary actor. However, I dont take this too far. Im happy to see the accounting system get value, without trying to figure out the human actor that gets value from the accounting systemthat would entail modeling the accounting system itself. That said, you should always question use cases with system actors, find out what the real user goals are, and consider alternative ways of meeting those goals. When Im working with actors and use cases, I dont worry too much about what the exact relationships are among them. Most of the time, what Im really after is the use cases the actors are just a way to get there. As long as I get all the use cases, Im not worried about the details of the actors. There are some situations in which it can be worth tracking the actors later. The system may need configuring for various kinds of users. In this case, each kind of user is an actor, and the use cases show you what each actor needs to do. Tracking who wants use cases can help you negotiate priorities among various actors. Some use cases dont have clear links to specific actors. Consider a utility company. Clearly, one of its use cases is Send Out Bill. Its not so easy to identify an associated actor, however. No particular user role requests a bill. The bill is sent to the customer, but the customer wouldnt object if it didnt happen. The best guess at an actor here is the Billing Department, in that it gets value from the use case. But Billing is not usually involved in playing out the use case. Be aware that some use cases will not pop out as a result of the process of thinking about the use cases for each actor. If that happens, dont worry too much. The important thing is understanding the use cases and the user goals they satisfy. A good source for identifying use cases is external events. Think about all the events from the outside world to which you want to react. A given event may cause a system reaction that does not involve users, or it may cause a reaction primarily from the users. Identifying the events that you need to react to will help you identify the use cases. Use Case Relationships In addition to the links among actors and use cases, you can show several kinds of relationships between use cases. The include relationship occurs when you have a chunk of behavior that is similar across more than one use case and you dont want to keep copying the description of that behavior. For instance, both Analyze Risk and Price Deal require you to value the deal. Describing deal valuation involves a fair chunk of writing, and I hate copy-and-paste. So I spun off a separate Value Deal use case for this situation and referred to it from the original use cases. You use use case generalization when you have one use case that is similar to another use case but does a bit more. In effect, this gives us another way of capturing alternative scenarios. In our example, the basic use case is Capture Deal. This is the case in which all goes smoothly. Things can upset the smooth capture of a deal, however. One is when a limit is exceededfor instance, the maximum amount the trading organization has established for a particular customer. Here we dont perform the usual behavior associated with the given use case we carry out an alternative. We could put this variation within the Capture Deal use case as an alternative, as with the Buy a Product use case I described earlier. However, we may feel that this alternative is sufficiently different to deserve a separate use case. We put the alternative path in a specialized use case that refers to the base use case. The specialized use case can override any part of the base use case, although it should still be about satisfying the same essential user goal. A third relationship, which I havent shown on Figure 3-2, is called extend . Essentially, this is similar to generalization but with more rules to it. With this construct, the extending use case may add behavior to the base use case, but this time the base use case must declare certain extension points, and the extending use case may add additional behavior only at those extension points. (See Figure 3-3.) Figure 3-3. Extend Relationship A use case may have many extension points, and an extending use case may extend one or more of these extension points. You indicate which ones on the line between the use cases on the diagram. Both generalization and extend allow you to split up a use case. During elaboration, I often split any use case thats getting too complicated. I split during the construction stage of the project if I find that I cant build the whole use case in one iteration. When I split, I like to do the normal case first and the variations later. Apply the following rules. Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition. Use generalization when you are describing a variation on normal behavior and you wish to describe it casually. Use extend when you are describing a variation on normal behavior and you wish to use the more controlled form, declaring your extension points in your base use case.