UML Araçlarını Kullanarak Expert Advisor Nasıl Geliştirilir?

Bilim insanları zaten var olan bir şeyi araştırırlar; Mühendisler ise hiç olmayan bir şeyi yaratırlar.

Albert Einstein

Giriş

Simulink: Expert Advisor'ların Geliştiricileri için Bir Kılavuz adlı makalemde, dinamik sistemler kullanarak bir Expert Advisor modellemeyi önerdim. Ancak, bu yaklaşım, alım satım sistemlerinin tasarımcısının yalnızca bir yönünü temsil eder - sistemin dinamik davranışı. Profesyoneller, bir alım satım sistemi geliştiricisinin metodolojisini genişleten özel araçlara sahiptir. Bu makalede, evrensel bir araç olan UML grafik dili kullanılarak bir Expert Advisor'ın nasıl geliştirileceğini tartışacağız.

Genel olarak, bir grafik dili olan UML, nesne yönelimli yazılım sistemlerinin görsel modellemesi için kullanılır. Ama gördüğüm kadarıyla, araçlarını bir alım satım sistemi geliştirmek için kullanabiliriz. Ayrıca, MQL5 nesne yönelimli diller ailesine aittir ve bu da işimizi kolaylaştırır.

Modelleme amacıyla, ticari olmayan yazılımlar için ücretsiz Software Ideas Modeler'ı seçtim.

1. UML Temelleri

UML, bir Expert Advisor oluşturulmasına nasıl yardımcı olabilir? İlk olarak, grafikler - çok yönlü modelleme sorunu, dilde mevcut olan grafik görüntüleri kullanılarak çözülebilir. İkincisi, okunabilirliktir. Expert Advisor büyük ve karmaşık olsa dahi, UML'nin evrenselliği modelini diyagramlar kullanarak sunmasına olanak tanır.

UML geliştiricilerinin dediği gibi, insan algısının kendine özgü özelliği, resimli bir metnin çıplak bir metinden daha kolay algılanması gerçeğinde yatmaktadır.

UML'nin temellerini kısaca ele alalım. Konuyla ilgileniyorsanız, internet üzerinde ücretsiz olarak bulunan sayısız yayından UML araçlarını öğrenebilirsiniz.

UML yapısı bir diyagramda gösterilebilir (Şek. 1).

Şek. 1. UML yapısı

Yapı taşları şunları içerir: varlıklar (modelin öğeleri), ilişkiler (şeyleri bağlayan) ve diyagramlar (UML modellerini temsil eden).

UML diyagramları, tasarlanan sistemin temsilinin farklı bakış açılarından görselleştirilmesine olanak tanır.

Genel mekanizmalar şunları içerir: Özellikler (anlambilimin açıklaması), süslemeler (modelin önemli özelliklerini işaretleme), ortak bölümler (soyutlama ve örnekleri, arayüzler ve uygulama), genişletilebilirlik mekanizmaları (kısıtlamalar, stereotipler ve etiketli değerler)

Sistemin kendi ortamında üst düzey sunumundan mimari sorumludur. UML mimarisi en iyi "4+1 mimari görünümü" ile tanımlanabilir (Şek. 2):

• Mantıksal görünüm
• Süreç görünümü
• Geliştirme görünümü
• Fiziksel görünüm
• Senaryolar

Şek. 2. 4+1 Mimari görünümü

UML'nin kendi kanonik diyagram hiyerarşisine sahip olduğu da belirtilmelidir (Şek. 3). Dil sürümü 2.2, 14 tür UML diyagramı kullanır.

Şek. 3. Kanonik UML diyagramları

Ayrıca UML diyagramlarının kullanımının bazı özel durumlarını göz önünde bulundurmayı öneriyorum. Böylece, bir soyutlamadan herhangi bir diyagramı EA geliştirme amaçları için kullanmanın belirli bir varyantına geçebiliriz. Bir kez daha, UML diyagramlarının hiyerarşisi tarafından sağlanan alım satım sistemlerinin çok yönlü tasarımı prensibi, TS oluşturma görevinin sistematik ve kapsamlı çözümüne katkıda bulunur.

2. UML diyagramları

2.1 Kullanım Senaryosu diyagramları

Dedikleri gibi, başlamak bitirmenin yarısıdır. Genellikle, zorunlu olmasa da, analitik çalışma kullanım senaryosu diyagramları ile başlar. Sistemi, kullanıcıların bakış açısından tanımlar.

Bunu oluştururken:

• TS kullanımının çeşitlerini belirleyebilir
• TS'nin sınırlarını belirleyebilir
• TS'nin aktörlerini tayin edebilir
• aktörler ve TS sürümleri arasındaki ilişkiyi tanımlayabiliriz.

Kullanım senaryosu, bir hedefe ulaşmak için tipik olarak bir rol (UML'de "aktör" olarak bilinir) ile bir sistem arasındaki etkileşimleri tanımlayan adımların bir listesidir.

Aktör "bir kullanıcı tarafından veya konuyla etkileşime giren başka bir sistem tarafından oynanan rolü belirtir. Aktörler, insan kullanıcılar, harici donanım veya diğer konular tarafından oynanan rolleri temsil edebilir.

İlişki, bir modelin tek tek öğeleri arasındaki anlamsal bağlantıdır.

Bu diyagram türünün oldukça genel olduğunu ve TS'nin uygulanmasından ziyade kavramsal yapısını yansıttığını fark edebilirsiniz. Ama işte mesele de bu - Genelden özele, soyuttan somuta geçmek. Sanatçı olmadığımızı da kim söyledi? Genel fikirler ve eskizlerle başlayarak bir resim çiziyoruz. İlk önce bir tuval üzerine çizgiler çiziyoruz. Ardından renklendiriyoruz. Ayrıntıları çiziyoruz...

O halde, bir alım satım sistemi için bir kullanım senaryosu diyagramı oluşturmaya çalışalım.

Giriş aktörleri olarak aşağıdaki rolleri seçtim: Geliştirici, Sistem analisti, Risk yöneticisi ve Yönetici. Bu rollerin bir veya daha fazla kişi tarafından üstlenilebileceği unutulmamalıdır. Alım satım sistemimiz hangi işlemleri yapıyor ve bununla ilgili olarak hangi işlemler yapılıyor?

Böylece, Geliştirici bir TS oluşturabilir ve uygulayabilir. Ayrıca, TS'nin optimizasyonuna katılabilir. Sistem analisti TS'yi optimize eder. Risk yöneticisi, risk yönetiminden sorumludur. Yönetici, TS'nin genel çalışmasını izler. Çıkış tarafında ise TS'nin işleyişi sonucunda Kullanıcının kazanç elde ettiğini görüyoruz. Bu rol, Yatırımcı ve Sermaye Sahibi gibi rollerin toplamıdır. Risk Yöneticisi ve Yönetici, TS'nin çalışmalarını denetler.

Diyagram "Alım Satım Sistemi" bloğunu içerir. TS sınırını ifade eder ve onu dış dünyadan ayırır.

Şimdi, aktörler ve kullanım senaryoları, ayrıca aktörler ve diğer aktörler ve kullanım senaryoları ve diğer kullanım senaryoları arasındaki ilişki hakkında birkaç şey söyleyeceğim. İlişkilerin çoğu, düz bir çizgiyle işaretlenmiş ilişkilendirmelerle temsil edilir. Bu, belirli bir aktörün bir kullanım senaryosu başlattığı anlamına gelir. Böylece Risk yöneticisi, risk yönetimi vb. süreçleri başlatır. Kullanım senaryolarını başlatan aktörler ana, taahhüt edilen eylemlerin sonuçlarını kullananlar ise ikincildir. Örneğin, çıkış tarafındaki Yönetici ikincil bir aktördür. 

İlişkilendirme, aktörün uygun kullanım senaryosunu başlattığını gösterebilir.

Genelleştirme, rollerin uygun genelliğini simüle eder.

Genişletme, temel kullanım senaryosu ile özel durumu arasındaki bir tür bağımlılık ilişkisidir.

Dahil etme, temel kullanım senaryosunun, işlevsel davranışı her zaman temel senaryo tarafından kullanılmayan, ancak yalnızca ek koşullar altında kullanılan başka bir kullanım senaryosuyla ilişkisini tanımlar.

Ancak, kullanım senaryosuna göre ikincil bir rolün, bu rolün ikincil öneme sahip olduğu anlamına gelmediğini unutmayın. Ayrıca, diyagramda TS Kullanıcısının rolünün, "boyasız" üçgen ok ucu ile bir çizgi olarak gösterilen genelleştirme ilişkileri üzerinden Yatırımcı ve Sermaye Sahibi rollerinden oluştuğunu görüyoruz.

Şek. 4. TS'nin kullanım senaryosu diyagramı

Sırayla "Pozisyon aç" ve "Pozisyon kapat" kullanım senaryoları, "Alım Satım" ile ilgili bir genelleştirme ile ilişkilidir. İkinci senaryo, diğer ikisi için temel olandır. Bu nedenle, "Riski yönet" kullanım senaryosunu içerir. Ve davranışı, bağımlı senaryo olan "Kar" için tamamlayıcıdır.

TS karı, bir varlığın Satış fiyatının Alış fiyatından büyük olması koşuluyla oluştuğu için, bu senaryolar için genişletme ilişkisini kullandım. Diyagram ayrıca genişletme noktasını, yani "Kar amaçlı" durumunun kullanıldığı belirli bir koşulu gösterir. Bağımlılık ilişkileri, "dahil et" ve "genişlet" stereotiplerine karşılık gelen bir ok ile kesik çizgi ile gösterilir.

Her kullanım senaryosu için, planlanan hedefe götüren bir dizi adımı tanımlayan bir senaryo oluşturmanız gerekir. Kullanım senaryosu çeşitli şekillerde tanımlanabilir. Yaygın olarak kabul edilen formlar şunları içerir: Metin açıklamaları, sözde kod, etkinlik diyagramı, etkileşim diyagramı.

Bir yatırımcının, Şekil 4'te gösterilenden ziyade, bir TS ile tam anlamıyla ilgilendiğine dikkat edilmelidir. Bu nedenle, ayrıca "Kar amaçlı" genişletmesiyle "Alım Satım" kullanım senaryosuna odaklanmanızı öneririm.

2.2 Sınıf Diyagramı

sınıf diyagramını kullanarak TS yapısını tanımlayacağız. Yani, nesne yönelimli programlama sınıfları açısından alım satım sisteminin statik yapısının bir modelini sunacağız. Böylece TS'nin programlama mantığını yansıtacağız.

UML'de sınıf diyagramı bir tür statik yapı diyagramıdır. Sınıflarını, özniteliklerini ve işleçlerini ve ayrıca sınıfların ilişkilerini göstererek sistemin yapısını tanımlar.

Bu diyagram türünün avantajları nelerdir? Nesne yönelimli programlama dillerine biraz aşina olanlar, tanıdık "sınıf" kavramını hemen fark edeceklerdir. Sınıf, UML sınıfı diyagramında temel yapı taşı olarak işlev görür. Örneğin, bir C++ kodu oluştururken, UML sınıfı bloğu, bir sınıf şablonu biçiminde otomatik olarak oluşturulur. Yalnızca her yöntemin ve özelliğin uygulamasını tamamlamanız gerekir.

Şimdi örnek olarak bir şey tasarlamaya çalışalım. Ama ilk olarak, yazarın düz bir mantık kullanmanın avantajlarını açıkladığı "Bir Alım Satım Robotu Prototipi" makalesine dikkatinizi çekmek istiyorum. Benim düşünceme göre, çok etkili ve üretken, iç içe geçme prensibidir - "makro-işlevler-alım satım modülleri".

Örneğin, standart kitaplığın alım satım sınıflarının olasılığını kullanan bir Expert Advisor'a ihtiyacımız var.

Sınıf bloğunu kullanarak sınıf diyagramında bir sınıf modeli oluşturun. Ben buna CTradeExpert adını verdim. Yeni sınıf için bazı öznitelikler (MQL5'de sınıfın veri üyeleridir) ekliyoruz. Bunlar şu şekildedir: Magic_No, e_trade, e_account, e_deal, e_symbol, e_pnt. Ayrıca CTradeExpert sınıfının oluşturucu yöntemini de ekliyoruz. Grafiksel olarak, işlem Şek. 5'te gösterildiği gibi olacaktır.

Şek. 5. CTradeExpert sınıfının UML modeli

Bir özniteliğin önündeki "-" karakteri, özniteliğin «özel», «#» - «korumalı», «+» - «genel» modunda erişim hakkına sahip olduğunu gösterir. Bu nedenle, Magic_No özniteliği için erişim belirticisi özel, e_pnt için genel ve diğerleri için korumalı olarak ayarlanır. Öznitelik adını izleyen iki nokta üst üste, öznitelikler için bir veri türünü ve yöntemler için döndürülen veri türünü belirtir. Örneğin, Magic_No özniteliği int, e_trade - CTrade, vb. türündedir.

Şu anda herhangi bir yöntem ve öznitelik eklemiyoruz; yalnızca CTradeExpert sınıfımızın Standart Kitaplık sınıflarıyla nasıl bağlantılı olduğunu gösterin. Bunu yapmak için diyagrama 6 sınıf bloğu ekleyin ve bunları aşağıdaki gibi çağırın: CTrade, CAccountInfo, CDealInfo, CSymbolInfo, CObject. Şimdi CTradeExpert sınıfının modelini, "kullanım" stereotipiyle (oklu kesikli noktalı çizgi) bağımlılık ilişkileri aracılığıyla 4 alım satım sınıfı bloğuyla ilişkilendiriyoruz. 

Bağımlılık, iki varlık arasındaki anlamsal bir ilişkidir; burada bağımsız olandaki bir değişiklik diğer bağımlı olanın anlamını etkileyebilir.

UML'deki Stereotip, nesne davranışının bir açıklamasıdır.

Daha sonra, bu blokları "boyasız" üçgen ok uçlu bir çizgi kullanarak genelleştirme ilişkisiyle CObject bloğuna bağlarız. Standart kitaplık sınıflarına açıklama ekleyin. Şimdi, UML diyagramımız Şekil 6'da gösterildiği gibi görünüyor.

Şek. 6. UML sınıfı diyagramı

Şimdi yalnızca kenar çubuğundaki "Oluştur" sekmesinin "Oluştur" işlevini kullanarak kodu oluşturmamız gerekiyor (Şek. 7).

Şek. 7. Oluşturulan Kod

En uygun olanı С++ dilidir. Expert Advisor sınıfının kodunu oluşturmak için C++'yı kullanacağız ve ardından bunu kolayca MQL5'e çevireceğiz.

Bu diyagram için oluşturulan kod aşağıdaki gibidir:

//
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
{
};

Bu, gerçekten tanıdık bir sözdizimi, değil mi? Yalnızca sınıfın gövdesine uymamız gerekiyor. Bu amaçla MetaEditor'da yeni TradeExpert.mqh sınıfı için bir dosya oluşturuyoruz. Daha önce oluşturulan kodu buna kopyalayın. Okunabilirlik için, CTradeExpert sınıfının üyeleri için korumalı tekrarlanan erişim belirticisini siliyoruz.

Standart kitaplık sınıflarının bildirimi ile bağlantılı satırları silin. Bundan sonra, standart kitaplığın kullanılan her sınıfı için #include talimatını içeren dosyayı ekleyin; zira bu sınıflar zaten geliştirici tarafından tanımlanmıştır. Ve açıklamalarımızı ekleyin. Sonuç olarak aşağıdaki gibi bir kod elde ederiz.

//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()
     {
     }
  };
//+------------------------------------------------------------------+

Şimdi Expert Advisor sınıfımıza biraz daha alım satım işlevi modülü ekleyelim.

Bunlar, şu şekilde olabilir: CheckSignal, OpenPosition, CheckPosition, ClosePosition vb. "Koşullara hizmet etme" prensibini zaten bildiğinizi umuyorum. Bu durumda, test sınıfımız CTradeExpert size zor görünmeyecektir. UML mekanizmalarını anlamanızı kolaylaştırmak için özellikle zaten bilinen bir Expert Advisor örneğine odaklandım.

Şimdi sınıfın modeli Şek. 8'deki gibi görünüyor.

Şek. 8. CTradeExpert sınıfının UML modeli

Sınıfın güncellenmiş modeli için, daha önce açıklanan yöntemi kullanarak bir kod da oluşturabiliriz.

2.3 Etkinlik Diyagramı

Bu tür UML diyagramlarını kullanarak, veri akışı ve kontrol akışı modellerini kullanarak sistemin davranışını inceleyebiliriz. Etkinlik diyagramları, adım adım etkinliklerin ve eylemlerin iş akışlarının grafiksel temsilleridir.

Etkinlik diyagramı, yalnızca algoritmanın adımlarını açıklayan akış grafiğinden farklıdır. Etkinlik diyagramı gösterimi daha geniştir. Örneğin, içindeki nesnelerin durumunu belirtmek mümkündür.

Etkinlik diyagramları, geliştiriciler tarafından aşağıdakileri açıklamak için kullanılır:

• İş kuralları
• Tekli kullanım senaryoları
• Karmaşık çoklu kullanım senaryoları serisi
• Çözümleri ve alternatif akışları içeren süreçler
• Paralel işlemler
• Program akışları ve mantık kontrolü yapıları

Oluşturulan CTradeExpert expert sınıfının Expert Advisor Test_TradeExpert.mq5 dosyasında kullanılacağını varsayalım. Hatırladığımız gibi, MetaEditor 5'te bir EA oluştururken varsayılan şablon, üç varsayılan olay işleyici işlevi sağlar: OnInit, OnDeinit ve OnTick. Onlar üzerinde duralım.

Test_TradeExpert.mq5 dosyasını hesaba katan EA işlemimizle bir diyagram görüntülemeye çalışalım. Burada Expert Advisor'ın daha doğrusu yapısının oldukça ilkel olduğunu belirtmek gerekir. Şu anda yalnızca alıştırma yapıyoruz. Bu amaç için basit bir EA yapısı uygundur.

Algoritması Test_TradeExpert.mq5 dosyasında temsil edilen Expert Advisor'ımızın kullanımı için bir diyagram tasarlayalım.

Böylece her şey başlangıç düğümüyle başlar (Şek. 9). Bu düğümden, bir kontrol belirteci, "Expert Advisor örneği oluştur" eylemini çağıran düğüme hareket eder. Bu eylem, nesne düğümünün durumunu ve kontrol akışını ve "Expert Advisor'u Başlat" işlevini çağıran bir düğüme değiştiren (myTE=created) nesnenin akışını (mavi ok) başlatır. 

Kontrol akışı, iki etkinlik düğümünü birbirine bağlayan ve üzerinden yalnızca kontrol belirteçlerinin iletildiği bir etkinlik ucu şeklinde temsil edilir. 

Nesne akışı, yalnızca nesnenin veya veri belirteçlerinin iletildiği bir etkinlik ucu olarak temsil edilir.

Etkinlik düğümü, uçlarla bağlanan etkinliklerin akışındaki bireysel noktalar için soyut bir sınıftır.

Karar düğümü, giden akışlar arasında seçim yapan kontrol düğümüdür.

Nesne düğümü, etkinlikte kullanılan nesneleri temsil eder.

Etkinlik ucu, iki etkinlik düğümü arasında yönlendirilmiş bağlantılar için soyut bir sınıftır.

Başlangıç düğümü etkinliğin başladığı yeri gösterir.

Bir etkinliğin son düğümü tüm etkinlik akışlarını tamamlar.

Sırayla, myTE nesnesinin (myTE=initialized) durumunu değiştirir ve kontrol belirtecini karar düğümüne iletir. Expert Advisor başarıyla başlatılırsa, kontrol akışı "NewTick alım satım olayını işle" düğümüne gider. Başlatma başarısız olursa, kontrol belirteci önce genelleştirme düğümüne ve ardından "Expert Advisor Başlatmasını Geri Al" eylem düğümüne girer.

Belirteçler, istatistiksel olarak tanımlanmış bir etkinlik grafiğinin dinamik yürütme sürecini tanımlamada kolaylık sağlamak için tanıtılan soyut yapılardır. Belirteç herhangi bir ek bilgi içeremez (boş bir belirteç); bu durumda bu, kontrol akışı belirteci olarak adlandırılır veya bir nesneye veya veri yapısına bir referans içerebilir ve bu durumda da bu, veri akışı belirteci olarak adlandırılır.

Karar düğümünden gelen ilk kontrol akışına bakalım. Kırmızı noktalı çizgi ile çizilmiş köşeleri yuvarlatılmış bir dikdörtgen ve "kesilebilir" stereotipiyle gösterildiği gibi, kesintiye uğramış bir eylemin olduğu bir alana yönlendirilir. Kontrol akışı bu alanda olduğunda beklenmedik bir şekilde durabilir. "Expert Advisor Yüklemesini Kaldır" olayını alan eylem düğümünü (turuncu bayrak) etkinleştirirseniz, bu, tüm akışları kesecektir. Kontrol belirteci, kesme ucuna (turuncu zikzak ok) ve ardından bağlantı düğümüne hareket eder. Bundan sonra EA'nın başlatması geri alınır. Ardından, kontrol belirteci "Genel değişkenleri sil" düğümüne gider, daha sonra akış son etkinlik düğümünde tamamlanır.

"Expert Advisor Başlatmasını Geri Al" eylem düğümü ayrıca bir nesne akışı tarafından myTE (myTE=deinitialized) nesnesinin durumunu da değiştirir. "Genel değişkenleri sil" düğümü, sırayla, myTE nesnesini kaldırır (myTE=deleted).

Şek. 9. Test_TradeExpert.mq5 için etkinlik diyagramı

Kontrol akışının kararlı olduğunu varsayın: EA yüksüz değildir. "NewTick alım satım olayını işle" düğümünden akış, stereotipi "yinelemeli" (noktalı çizgili yeşil dikdörtgen) olarak tanımlanan başka bir bloğa - genişleme alanına hareket eder.

Temel özellikleri yansıtmak ve diyagram algısını geliştirmek için bu alana "Alım satım bloğu" diyorum. Bloğun karakteristik bir özelliği, gelen nesneler için işlemlerin döngüsel olarak yürütülmesidir. Yalnızca 2 döngüye ihtiyacımız var - uzun ve kısa yönleri işleyin. Bloğun girişinde ve bloğun çıkışında alım satım yönü nesnelerini (uzun veya kısa) içeren genişleme düğümleri vardır. 

Genişleme düğümü, her nesne için bir kez çalıştırılan genişleme alanına giren veya çıkan nesneler topluluğudur.

Sinyal gönderen eylem düğümü (sinyal gönderme eylemi) sinyal göndermeyi temsil eder.

Bir olayı kabul eden eylem düğümü (olay kabul etme eylemi), uygun türde bir olayın alınmasını bekler.

Böylece, her yön şu düğümler tarafından işlenir: "Sinyali kontrol et" (sinyal gönderme düğümü), "Sinyal al" (sinyal alma düğümü), "Pozisyon aç" (sinyal gönderme düğümü), "Pozisyon kontrol et" (sinyal gönderme düğümü), "Pozisyon kapat" (sinyal gönderme düğümü). Mor renkte oklarla gösterildiği gibi, yön nesnesinin (dir) eylem düğümleri arasındaki nesne akışında iletilebileceğine dikkat edilmelidir. Bir bloktaki işlemler, Expert Advisor'ın yükü boşaltıldığı sürece devam edecektir.

2.4 Dizi Diyagramı

Nesne etkileşim dizisini tanımlamak için dizi diyagramını kullanırız. Bu diyagram türünün çok önemli bir yönü zamandır.

Bu nedenle, diyagramın örtük biçimde iki ölçeği vardır. Yatay olan, nesne etkileşimlerinin dizisinden sorumludur. Dikey olan bir zaman eksenidir. Zaman aralığının başlangıcı diyagramın üst kısmıdır.

Diyagramın üst kısmı, etkileşime giren diyagram nesnelerini içerir. Bir nesnenin dikey noktalı bir çizgi olarak kendi yaşam çizgisi vardır. Nesneler mesaj alışverişinde bulunur. Bunlar, oklarla temsil edilirler. Bir nesne aktif olduğunda, kontrol odağını alır. Grafiksel olarak bu odak, yaşam çizgisi üzerinde dar bir dikdörtgen olarak ifade edilir.

Nesne, altı çizili bir nesne adı ve iki nokta üst üste işaretiyle ayrılmış sınıf adı (isteğe bağlı) içeren bir dikdörtgendir.

Nesne yaşam çizgisi, bir nesnenin belirli bir süre boyunca varlığını gösteren çizgidir; çizgi ne kadar uzunsa, nesne o kadar uzun süre var olur.

kontrol odağı, dar bir dikdörtgen olarak çizilir, üst tarafı, kontrol odağının nesne tarafından alınmasının başlangıcını (etkinlik başlangıcı) ve dezavantajı - kontrol odağının bitişini (etkinliğin sonu) gösterir.

UML'de her etkileşim, kendisine katılan nesnelerin değiş tokuş ettiği bir dizi mesaj ile tanımlanır.

Biraz pratik yapalım.

Terminal, bir aktördür. Expert Advisor'ın çalışmasını başlatır. "Olay" stereotipiyle işaretlenmiş diğer nesneler, istemci terminalinin olaylarıdır: Init, Deinit, NewTick. Elbette ki, isterseniz olay aralığını genişletebilirsiniz. Bir Expert Advisor'ı başlatırken, myTE nesnesi genel düzeyde oluşturulur. Bu, CTradeExpert sınıfının bir örneğidir. Sınıf nesnesi, diyagramdaki diğer nesnelerden biraz daha düşüktür; bu da oluşturucu işlevinden sonra oluşturulduğunu gösterir.

Oluşturma komutu, açık ok ve 1.1 CTradeExpert() mesajı içeren bir kesik noktalı çizgi ile işaretlenmiştir. Bir ok içeren kesik noktalı çizgi, varsayılan CTradeExpert() oluşturucusunun "oluştur" türünü gösterir. CTradeExpert örneğini oluşturduktan sonra adım 1.2 etkinleştirilir - Kontrol odağı terminale döndürülür. Okunabilirlik için, zaman uyumlu mesajları 1.1 gibi #.# biçiminde ve zaman uyumsuz mesajları - # biçiminde belirtiyorum. Ardından terminal, adım 2.1'de OnInit() işlevini kullanarak Init olayını işler, odak adım 2.2'de döndürülür. "Çağrı" türü mesajlar, sonunda "boyalı" üçgen ok bulunan çizgiler olarak gösterilir.

Init olayı terminale sıfırdan farklı bir değer döndürürse, bu, başlatmanın başarısız olduğu anlamına gelir: Deinit olayının oluşturulmasına ve işlenmesine yol açan Adım 3.1 kullanılır. Adım 3.2'de kontrol odağı terminale döndürülür. Ardından CTradeExpert sınıf nesnesi silinir (adım 4.1). Bu arada sınıf diyagramını oluştururken CTradeExpert yıkıcı işlevini sınıfa dahil etmedim. Bu, daha sonra yapılabilir. Bu, diyagram oluşturmanın avantajlarından biridir - Birkaç diyagramın oluşturulma süreci yinelemelidir. İlk önce bir diyagram için yapılan, daha sonra diğeri için yapılabilir ve daha sonra ilkini değiştirebilirsiniz.

Standart bir EA şablonunun MQL5 kodunun, başarısız başlatmayı işleyen bir blok içermediğine dikkat edilmelidir. Bunu, dizi mantığını kaydetmek için belirttim. UML dizi diyagramı, if(OnInit()!= 0) {} MQL5 yapısına eşdeğer olan OnInit()!=0 koruma koşuluyla opt bloğunu kullanır.

Adım 4.2'de kontrol terminale aktarılır.

Artık terminal NewTick olayını işlemeye hazırdır.

Bu olayın işlenmesi, sonsuz bir döngü anlamına gelen loop bloğundadır. Yani EA, biz onu devre dışı bırakana kadar bu olayı işleyecektir. Terminal, OnTick işlevini kullanarak NewTick olayını işler (adım 5). Adım 6'da, kontrol odağı Expert Advisor myTE'ye aktarılır. 4 yansımalı mesaj kullanarak, aşağıdaki işlevleri uygular: CheckSignal, OpenPosition, CheckPosition, ClosePosition. Yansıma, Expert Advisor nesnesinin kendisine mesaj göndermesinden kaynaklanmaktadır.

Ayrıca, CTradeExpert sınıfının bu işlevleri loop(2) bloğunun içine alınır. İki, döngünün iki geçişten oluştuğu anlamına gelir. Peki neden iki? Çünkü alım satım işleminin iki yönünü işler; uzun ve kısa (adım 7'den 10'a kadar). Adım 11'de odak terminale iletilir.

Adım 12 ve 13, sırasıyla Expert Advisor nesnesinin başlatmasının geri alınması ve silinmesi işlemlerini içerir.

Şek. 10. Test_TradeExpert.mq5 için SD diyagramı

Böylece, birincil tasarım becerilerine sahibiz. Oluşturulan diyagramlar yardımıyla geliştiricinin çalışması optimize edilmiştir. Artık Test_TradeExpert.mq5 dosyası için bir kod yazmaya başlayabiliriz. Tabii ki, diyagramlar olmadan yapabilirsiniz. Ancak karmaşık bir Expert Advisor'ınız olduğunda, diyagramların kullanımı hata olasılığını azaltır ve TS'nizin gelişimini verimli bir şekilde yönetmenize olanak tanır.

Expert Advisor şablonunu kullanarak şimdi Test_TradeExpert.mq5 oluşturuyoruz.

Genel düzeyde CTradeExpert myTE sınıfının bir örneğini oluşturuyoruz.

Şimdi OnTick() işlevinin gövdesini dolduralım.

Sınıfın işlevlerini aşağıdaki gibi yazıyoruz:

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

     {

      myTE.CheckSignal(dir);

      myTE.OpenPosition(dir);

      myTE.CheckPosition (dir);

      myTE.ClosePosition(dir);

     }

Bunun gibi bir şey, NewTick olayının işlenmesi olacaktır. Tabii ki, diğerleri arasında sınıf verisinin üyeleri tarafından kullanılacak işlevlerin her birini belirtmemiz gerekiyor. Ama bu işi sonraya bırakalım. Şimdi amacımız UML diyagramlarının mantığını MQL5 koduna aktarmak.

3. UML Diyagramlarına Dayalı Bir Expert Advisor'ın Geliştirilmesi ve Sunumu

Örnek olarak, karmaşık bir Expert Advisor için diyagramlar oluşturalım. Özelliklerini MQL5'te uygulanan belirli bir strateji bağlamında tanımlayalım. Genel olarak, Expert Advisor'ımız alım satım işlemlerini gerçekleştirecektir; özellikle alım satım sinyalleri üretecek, açık pozisyonları ve para yönetimini sürdürecektir. Bu, daha çok bir şablon alım satım stratejisidir. Ancak eğitim amaçlı olarak bununla çalışmayı deneyeceğiz.

İlk olarak, EA'mız için bir kullanım senaryosu diyagramı oluşturuyoruz. Bu, yalnızca bir dereceye kadar daha önce tartışılandan farklı olacaktır. TS'nin iç ortamına dikkat ettim, dışarıyı görmezden geldim (Şek. 11), kodda olduğu gibi yalnızca alım satım görevlerini uygulayacağız.

Şek. 11. TS'nin kullanım senaryosu diyagramı

Şimdi Expert Advisor'ın yapısını tanımlayalım. TS'nin belirtilen hedefleriyle tutarlı olduğu için standart kitaplık geliştirmelerini kullanacağımızı varsayalım. Son zamanlarda, bu, önemli ölçüde genişletildi. Ve hepsinden önemlisi, bu, alım satım stratejileri sınıflarıyla ilgilidir. Yani amacımız bir sınıf diyagramı oluşturmak. Bu, basit olmayacak; bu nedenle sabırlı olmanız gerekiyor.

Burada standart kitaplığı birkaç nedenden dolayı ele aldığımızı belirtmek isterim. İlk olarak, temelinde bir alım satım robotu oluşturmaya çalışıyoruz. İkincisi, (bu da ayrıca önemli bir konu), UML diyagramlarıyla çalışma deneyimimiz var. Üçüncüsü, belki de kitaplığın kendisi çok değerlidir. Böylece kitaplıktan birçok faydalı şey öğrenebilir ve aynı zamanda onun çok da basit olmayan yapısını anlamaya çalışabiliriz.

Bir UML diyagramının yapısındaki bir kodun dönüştürülmesi tersine mühendislik olarak adlandırılır. Aslında, bunu manuel olarak yapıyoruz. Bunu otomatik olarak yapmanıza olanak tanıyan profesyonel yazılımlar mevcuttur (IBM Rational Rose, UML için Visual Paradigm vb.). Ancak pratik amaçlar için "manuel" çalışmamız gerektiğini düşünüyorum.

"Class" bloğunu kullanarak CExpert alım satım stratejilerini uygulamak için temel sınıfın bir modelini oluşturalım. CExpert sınıfının gövdesinde başka hangi sınıfların ve yapıların kullanıldığını görelim. İlk olarak, CExpert sınıfının sırayla, CObject temel sınıfından türetilen CExpertBase temel sınıfından türetildiği belirtilmelidir.

Diyagramda bu sınıflar için bloklar oluşturuyoruz ve sınıflar arasındaki ilişkiyi "boyasız" üçgen ok uçlu bir çizgi (genelleştirme) kullanarak tanımlıyoruz. CExpert sınıfının modeline bir açıklama ekleyin (bükülü köşeli sarı bir dikdörtgen). Ara sınıf yapısı şimdi şuna benziyor - Şek. 12. Diyagrama Expert diyelim.

Şek. 12. Expert diyagramı, başlangıç görünümü

Expert.mqh dosyasındaki kodu görelim. CEExpert sınıfı, diğerlerinin yanı sıra ENUM_TRADE_EVENTS ve ENUM_TIMEFRAMES numaralandırmalarını içerir8 ve bu önceden tanımlanmış bir MqlDateTime yapısıdır. Sınıf ayrıca aşağıdakiler gibi diğer sınıf örneklerini de kullanır: CExpertTrade, CExpertSignal, CExpertMoney, CExpertTrailing, CIndicators, CPositiontInfo, COrderInfo.

Şimdi diyagramda bazı değişiklikler yapmamız gerekiyor. İlk olarak, CExpertSignal, CExpertMoney, CExpertTrailing sınıflarının bir CExpertBase, temel sınıfından ve CPositiontInfo, COrderInfo sınıflarının CObject'ten türetildiğini belirtiyoruz (Bunun için "metaclass" stereotipini ayarladım).

CExpert sınıfının bloğu ile diğer sınıflar arasındaki "use" stereotipi ile bağımlılık ilişkilerini işaretleyelim, MqlDateTime yapısını ve numaralandırmalarını unutmayın. Blokların renk stilini değiştiriyor ve aşağıdaki yapıyı elde ediyoruz - Şek. 13.

Şek. 13. Expert diyagramı, başlangıç görünümü

Ancak, bu yapı resmin tamamını yansıtmamaktadır; zira daha önce bahsedilen sınıflar tarafından dolaylı olarak kullanılan birtakım sınıflar vardır. Peki onlar ne tür sınıflar? İlk olarak, CExpertTrade sınıfı, CTrade'den türetilir. İkincisi, CObject'in bir alt sınıfıdır.

CExpertTrade sınıfı, ENUM_ORDER_TYPE_TIME numaralandırmasını kullanır, ayrıca CSymbolInfo ve CAccountInfo sınıfları, CObject'in alt öğeleridir. CTrade sınıfı ayrıca CSymbolInfo sınıflarının örneklerini de kullanır. Diyagramda değişiklikler yapalım. Şimdi diyagramımız şu formda - Şek. 14.

Şek. 14. Expert diyagramı, başlangıç görünümü

Yine, diyagram tamamlanmadı. Örneğin, Trade.mqh standart kitaplık dosyasına bakarsanız, CTrade'in birkaç farklı yapı, numaralandırma ve CSymbolInfo sınıfını kullandığını görürsünüz. Hepsi bir diyagramda gösteriliyorsa, çok fazla yüklenecektir. Ve bu, anlaşılmasını zorlaştıracaktır.

Bu zorluğun üstesinden gelmek için diyagram için bir paket kullandım. Bu, ilgili sınıfları, numaralandırmaları, diğer paketleri vb.'ini içermektedir. Arayüz üzerinden diyagram öğeleri ile paketi bağladım. Örneğin, CTrade paketinin diyagramı aşağıdaki gibi gösterilebilir - Şek. 15.

Şek. 15. CTrade paketi için sınıf diyagramı

CTrade paketi diyagramı, CTrade sınıfının numaralandırmalar ve yapı ile bağımlılık ilişkilerini gösterir.

CObject temel sınıfı ve kullanılan CSymbolInfo sınıfı ile ilişkiler bir arayüz aracılığıyla uygulanır.

Arayüzlerin yanında, CTrade paketini tek bir öğe olarak içeren sınıf diyagramıyla bir ilişki simgesi vardır. Arayüzlerden herhangi birine tıklamak otomatik olarak orijinal diyagrama götürür (Şek. 16).

Şek． 16. Arayüzler içeren Expert diyagramı

Arayüz ilişkileri turuncu renktedir. CTrade paketinin yanındaki sınıf diyagramı simgesi, bu diyagrama geçme olasılığını gösterir. Böylece, kapsüllemeyi kullanarak sınıf diyagramının okunabilirliğini önemli ölçüde iyileştirebiliriz.

Öyleyse devam edelim. CObject sınıfı, gövdesindeki aynı sınıfın örneklerine işaretçiler kullanır. Bu nedenle, CObject bloğu için bağımlılık ilişkisini kendisine göre "use" stereotipiyle ayarlayabiliriz.

CExpertBase sınıf modelinin bloğuna bakalım. ExpertBase.mqh üst bilgi dosyasının ilk satırlarına dayanarak, bu sınıfın çeşitli sınıfların ve numaralandırmaların birden çok örneğini kullandığını söyleyebiliriz. Bu nedenle, sınıf modeli ve ilişkileri için CExpertBase paketini oluşturmak mantıklıdır.

Öncelikle paket diyagramında CExpertBase sınıf modelini tanımlıyoruz. Arayüz aracılığıyla, CObject temel sınıfıyla ilişkiyi ve CSymbolInfo ve CAccountInfo sınıflarıyla kullanım ilişkisini gösteririz. Ardından, sınıf bloklarını ve bağımlılık ilişkilerini kullanarak CExpertBase sınıfının aşağıdaki sınıfları kullandığını belirtiriz: CiOpen, CiHigh, CiLow, CiSpread, CiTime, CiTickVolume, CiRealVolume.

İlk dört sınıf CPriceSeries'dan, son dördü ise CSeries'dan türetilmiştir. Ayrıca, CSeries sınıfı bir CPriceSeries alt öğesine sahiptir ve sırayla, CArrayObj öğesinin alt öğesidir. Devralma ilişkileri hatırladığımız gibi daha önce kullanılmıştır. Bunları diyagramda bir genelleştirme ilişkisi olarak gösterin.

CExpertBase sınıfının gövdesinde aşağıdaki gibi numaralandırmaları kullandığını unutmayın: ENUM_TYPE_TREND, ENUM_USED_SERIES, ENUM_INIT_PHASE, ENUM_TIMEFRAMES. Son numaralandırma, CPriceSeries ve CSeries sınıfının alt öğeleri tarafından da kullanılır. İlişkileri kaybetmemek ve diyagramı netleştirmek için, diyagramın her bir öğesi için stili ayarlayalım. Sonuç olarak aşağıdaki diyagramı elde ederiz (Şek. 17).

Şek.． 17. CExpertBase paketi için sınıf diyagramı

Henüz tamamlanmadı ve üzerinde biraz daha çalışmamız gerekecek. CPriceSeries sınıfını devralan dört sınıfın da CDoubleBuffer sınıfını kullandığı ortaya çıktı. Ayrıca, dört sınıfın her biri CDoubleBuffer öğesinden türetilen arabellek sınıfını kullanır. Bu nedenle, COpen COpenBuffer kullanır vb.. CDoubleBuffer (CArrayDouble) temel sınıfına sahiptir ve ENUM_TIMEFRAMES'i kullanır.

CArrayDouble, CArray'i devralır, aynı sınıfın örneklerine işaretçiler ve ENUM_DATATYPE numaralandırmasını kullanır. Fiyat serisinin COpenBuffer sınıfı ve diğer arabellek sınıfları (CHighBuffer, CLowBuffer, CCloseBuffer) ENUM_TIMEFRAMES numaralandırmasını kullanır.

CSeries sınıfını devralan dört sınıf yalnızca kendi arabellek sınıflarını kullanır (CSpreadBuffer, CTimeBuffer, CTickVolumeBuffer, CRealVolumeBuffer). Sınıf arabelleklerinin ilki CSpreadBuffer, CArrayInt, öğesini, diğerleri – CArrayLong öğesini devralır. Son iki sınıf, kendi sınıflarının örneklerine, ENUM_DATATYPE numaralandırmasına yönelik işaretçileri kullanır ve bunlar CArray'den türetilir ardından , CObject sınıfının bir alt öğesi haline gelir.

CPriceSeries sınıfı ve alt öğeleri CDoubleBuffer sınıfını ve ENUM_TIMEFRAMES numaralandırmasını kullanır.

CSeries, numaralandırma ENUM_SERIES_INFO_INTEGER, ENUM_TIMEFRAMES'i kullanır. Bu, CArrayObj'i devralır. İkincisi CARray kaynaklıdır, ENUM_POINTER_TYPE kullanır, kendi sınıfının örneklerine ve CObject sınıfına işaret eder. Sonuç olarak, Şekil 18'de gösterilen diyagramı elde ederiz.

Şek. 18. CExpertBase paketi için genişletilmiş sınıf diyagramı

Orijinal Expert diyagramı, CExpert, CExpertBase, CSymbolInfo, CAccountInfo ve CObject sınıfları ve paketleri için arayüzleriyle aşağıdaki gibi görünür (Şek. 19).

Şek. 19. Arayüzler içeren Expert diyagramı

Ayrıca, CExpertTrade tarafından kullanılan ENUM_ORDER_TYPE numaralandırmasını da ekledim. Okunabilirlik için, ilişki grubunu farklı renklerle işaretledim.

Çalışmamıza devam edelim. Umarım mantığı anlamışsınızdır. Diyagramdaki bir sınıfın modeli, diğer sınıflar ve diğer varlıklarla birçok ilişkiye sahip olabilir. Bu nedenle, bazı kümeleri temel diyagramda bir paketle değiştirdim.

Öyleyse, CSymbolInfo üzerinde çalışalım. SymbolInfo.mqh koduna bakarsanız, CSymbolInfo temel sınıfının bazı MQL5 numaralandırmalarını ve yapılarını kullandığını görürsünüz. Bunun için ve ilişkileri için bir paket kullanmak iyidir (Şek. 20).

Şek. 20. CSymbolInfo paketinin diyagramı

Diyagramdaki bir miktar boş alan, açıklamalar için kullanılabilir. Ayrıca, CObject üst sınıfı ile ilişkinin arayüzünü de işaretledim. Paketlerin ve sınıfların orijinal Expert diyagramı biraz değiştirilecektir. Tüm sınıflar ve paketler diyagrama yansıtıldığında güncellenmiş sürümünü daha sonra vereceğim.

Öyleyse devam edelim. AccountInfo.mqh içindeki MQL5 koduna bakalım. Görünen o ki, CAccountInfo bazı numaralandırmaları da kullanıyor. Bunları bu sınıf için oluşturacağımız paketin diyagramına ve diğer varlıklarla olan ilişkilerine yansıtıyoruz (Şek. 21).

Şek. 21. CAccountlInfo paketi diyagramı

Şimdi CExpert sınıfıyla ilgilenelim. Bu sınıf için, Şek. 22'de gösterildiği gibi görünecek olan bir CExpert paketi de oluşturuyoruz. Ana diyagramımızın okunabilirliğini geliştirmeye devam ediyoruz. CExpert sınıfı, oklu turuncu arayüz çizgileriyle gösterildiği gibi, diğer birkaç sınıfla bağlantılıdır.

Şek. 22. CExpert paketi diyagramı

Kalan diğer sınıfları keşfedelim. Onlar için daha fazla paket oluşturacağız.

CExpertSignal, CExpertBase'den türetilir. Bu ilişki, orijinal Expert diyagramında zaten gösterilmiştir. Ayrıca, CExpertSignal sınıfı, CArrayObj, COrderInfo, CIndicators ve kendi sınıfının örneklerini kullanır (Şek. 23). Özellikle, CArrayObj sınıfı ile olan ilişkinin arayüzü bizi CArrayObj sınıfının diğer varlıklarla ilişkisini gösteren CExpertBase paketi diyagramına götürecektir.

Şek. 23. CExpertSignal paketi diyagramı

Şu anda tüm diyagramları göstermiyorum; bunların tümü ekteki Expert.simp dosyasında mevcuttur. Şimdi güncellenmiş Expert paketlerinin ve sınıflarının diyagramına bir göz atalım (Şek. 24).

Gördüğünüz gibi, diyagramdaki neredeyse tüm anahtar sınıflar, diyagramın daha kolay anlaşılmasını sağlamak için paketler içine kapsüllenmiştir. Bağımlılık ilişkisi çizgisinden ayırt etmek için genelleştirme çizgisinin rengini kahverengiye çevirdim.

Şek. 24. Expert paketlerinin ve sınıflarının diyagramı

Dolayısıyla, diyagram oluşturmak için standart kitaplıkta bulunan koddan alınabilecek her şeyi yansıttık. Yalnızca Expert Advisor'ın alım satım işlemlerini belirten birkaç blok daha eklememiz gerekiyor.

İlk blok CmyExpert bloğudur ve CExpert sınıfından alım satım "becerilerini" devralır. Bu, uzun süredir tersine mühendislikle ilgilendiğimiz bloktur. Belirli bir alım satım stratejisi uygulayacak. Ayrıca EA'nın temel sınıflarının sanal işlevlerini de belirtmemiz gerekiyor.

Bu amaçla, CmyExpertSignal, CmyExpertMoney, CmyExpertTrailing sınıflarının bir bloğunu oluşturuyoruz ve bunların uygun olandan türetildiğini belirtiyoruz (Şek. 25).

Şek. 25. Genişletilmiş Expert paketi ve sınıfı diyagramı

Sınıfların her birinin hangi işlevleri ve verileri içermesi gerektiği geliştiriciye bağlıdır. Burada, türetilmiş bir sınıfın belirli bir uygulamasını değil, daha genel şemayı göstermeye çalışıyorum. Böylece, türetilmiş sınıfların her biri için, örneğin Şek. 8'de yapıldığı gibi, dahil edilen yöntemlerin ve özelliklerin ayrıntılı bir listesini içeren ayrı bir diyagram oluşturabiliriz.

Şimdi dizi diyagramını çalışmamızda nasıl kullanabileceğimize bakalım. EA'mızın zaman çizelgesine göre nasıl çalıştığını gösterdiğini size hatırlatmama izin verin.

Yani, EA'nın çalışmasının ayrıntılarını kronolojik sırayla yazıyoruz (Şek. 26).

Şek. 26. Expert Advisor'ın dizi diyagramı

Terminal, aktör işlevi görür. Genel düzeyde, myTrader nesnesini oluşturur - bir CmyExpert örneği (Adım 1.1). Yeşil, istemci terminalinin (Init, Deinit, NewTick, Trade) önceden tanımlanmış olaylarını gösterir. Dizi diyagramı mantığı daha önce açıklanmıştır. Burada bazı özel noktalara dikkat çekmek istiyorum. Expert Advisor'ın gövdesi büyüdüğünde ve daha fazla kod olduğunda, onu bir diyagramda göstermek daha zor hale gelir.

Bu sorunu çözmek için blok yaklaşımını kullanın. Bazı ortak işlevler kümesi, bir blok şeklinde görselleştirilir. Kural olarak, bu, başka bir dizi diyagramıdır. Bir etkileşim kullanımı olduğu söylenir.

Bu durumda, Init terminal olayının ayrı bir diyagramda işlenme mantığını yansıtmak için OnInit adında bir dizi diyagramı oluşturdum. Sözdizimsel olarak, ref (referans) anahtar sözcüğüyle bir sınır olarak tanımlanır ve kontrol belirteci OnInit'dan (adım 2.1) Init nesnesinin yaşam çizgisine iletildiğinde kullanılır.

Ayrıca, OnInit için bu dizi diyagramına bir arayüz geçişi ayarladım. Yani, kenarlığa 2 kez tıklarsanız, aslında OnInit'in ayrıntılı bir dizi diyagramını açabilirsiniz (Şek. 27).

Şek. 27. OnInit'in dizi diyagramı

Diğer dizi diyagramlarına geçiş bazı eylemlerin yinelenmesi için çok uygundur.

Örneğin, OnInit diyagramı, işlenmesi myTrader_Deinit'te (Şek. 28) gerçekleştirilen EA başlatmasını geri alma ile bağlantılı eylemleri içerir.

Şek. 28. myTrader_Deinit dizi diyagramı

Genel olarak, EA tasarımının bu aşamasında dört dizi diyagramım var. Doğal olarak, daha ciddi bir geliştirme sırasında ek diyagramlara ihtiyacınız olabilir. Örneğin, istemci terminalinin diğer olaylarını ele almadım (NewTick, Trade).

Sonuçlar

Bu makalede, nesne yönelimli yazılım sistemlerinin görsel modellemesi için kullanılan UML grafik dilini kullanarak Expert Advisor geliştirme sürecinin çok boyutlu yapısını göz önünde bulundurmayı önerdim. Bu yaklaşımın temel avantajı, tasarımcının görselleştirilmesidir.

Herhangi bir karmaşık olguda olduğu gibi, UML'nin geliştiricinin bilmesi gereken kendi dezavantajları vardır (artıklık, kesin olmayan anlambilim vb.).

EA geliştirmenin açıklanan metodolojisinin sizin için ilgi çekici olduğunu umuyorum. Herhangi bir yorum ve yapıcı eleştiri için minnettar olurum.

Dosyaların konumu:

#	Dosya	Yol	Açıklama
1	TradeExpert.mqh	%MetaTrader%\MQL5\Include	Expert Advisor sınıfı
2	Test_TradeExpert.mq5	%MetaTrader%\MQL5\Experts	Expert Advisor
3	Expert.simp	%Documents%\UML projects	UML diyagramları projesi
4	SoftwareIdeasModeler.4.103.zip	%Program Files%\SoftwareIdeasModeler	Software Ideas Modeler dağıtım dosyası

Referans:

1. Ücretsiz UML kursları. 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.