UML 툴을 사용하여 Expert Advisor 개발하기

과학자는 이미 있는 것을 탐구하고, 기술자는 존재하지 않았던 것을 만들어낸다.

알버트 아인슈타인

들어가며

예전에 제가 작성한 문서 시뮬링크(Simulink): Expert Advisor 개발자들을 위한 가이드에서 Expert Advisor를 동적 시스템에서 모델링하시도록 추천드린 바 있습니다. 그러나 이 방식의 접근 방법은 매매 시스템 디자인의 오직 한가지 측면에 불과한 시스템의 능동 행태만을 나타내고 있습니다. 전문가들은 매매 시스템 개발자의 방법론을 확장시킬 수단을 가지고 있습니다. 본 문서에서 우리는 범용성이 뛰어난 도구인 그래픽 언어 UML를 통하여 Expert Advisor를 개발하는 방법에 대해 알아볼 것입니다.

일반적으로 그래픽 언어인 UML은 객체 지향 소프트웨어 시스템의 시각 모델링에 쓰입니다. 그러나 제가 보기에는 이걸 통해서 매매 시스템을 개발할 수 있습니다. 덤으로 MQL5 역시 객체지향 언어에 속하기 때문에 원하는 바를 달성하기도 어렵지 않습니다.

모델링 용으로 저는 비상용 소프트웨어인 소프트웨어 아이디어 모델러(Software Ideas Modeler)를 선택했습니다.

1. UML 기초

Expert Advisor 개발에 UML은 어떤 점에서 도움이 될까요? 첫째로 그래픽을 편하게 처리하게 해줍니다. 다중 측면 모델링의 문제인 그래픽은 UML로 제공되는 그래픽 이미지를 사용하여 해결할 수 있습니다. 둘째로 가독성을 증진시켜줍니다. 방대하고 복잡한 구조의 Expert Advisor일지라도 UML의 범용성이 접합되면 쉽게 다이어그램으로 모델을 나타낼 수 있습니다.

UML 개발자들이 흔히 말하듯이, 인간은 글 보다는 이미지로 더 쉽게 이해한다고 합니다.

이제 UML의 기본을 살펴봅시다. 만약 UML에 관심이 있으시다면 인터넷 상에 무수하게 있는 무료 소스로 부터 UML에 대해 배울 수 있습니다.

UML 구조는 다이어그램으로 표현할 수 있습니다 (1번 그림).

1번 그림. UML 구조

다음이 기본 블럭에 속합니다. 개체(entities) (모델의 요소), 관계(relationship) (물체들을 한데 묶는 것) 그리고 다이어그램(diagrams) (UML 모델을 나타내는 것).

UML 다이어그램을 사용하면 설계된 시스템의 표현을 서로 다른 관점에서 시각화할 수 있습니다.

기본 메커니즘에는 다음이 속합니다. 명시(specifications, 의미의 설명), 강조(adornment, 모델 내에서 가장 중요한 특징을 표현하는 것), 공통 집합(common divisions, 추상화와 그 인스턴스 인터페이스 및 구현), 확장 메카니즘(extensibility mechanisms, 제약, 스테레오타입 및 태그값).

아키텍쳐는 주어진 환경 내에서 시스템을 고등하게 나타내는 역할을 맡고 있습니다. UML 아키텍쳐는 "4+1 아키텍쳐 뷰"(2번 그림)에서 아주 잘 나타나 있습니다.

• 논리적 뷰
• 프로세스 뷰
• 개발 뷰
• 물리적 뷰
• 시나리오

2번 그림. 4+1 아키텍쳐 뷰

또한 UML에는 표준 다이어그램의 자체 계층 구조가 있습니다(3번 그림). UML 2.2 버전에는 14 타입의 UML 다이어그램이 있습니다.

3번 그림. 고전 UML 다이어그램

또한 UML 다이어그램의 사용에 대한 몇 가지 특수한 사례를 고려해 보시기 바랍니다. 따라서, 우리는 추상화에서 EA 개발 목적으로 다이어그램을 사용하는 특정 변형으로 이동할 수 있습니다. 보시다시피 UML 다이어그램의 계층구조가 제공하는 매매 시스템의 다면설계 원칙이 TS창출 과제의 체계적이고 포괄적인 해결책에 기여하고 있습니다.

2. UML 다이어그램

2.1 사용 케이스(Use Case) 다이어그램

옛 말에 시작이 반이라고 했습니다. 물론 항상 그런건 아니지만 많은 분석 업무가 유즈 케이스 다이어그램으로부터 시작됩니다. 이 다이어그램은 사용자의 관점에서 시스템을 설명합니다.

생성중에 우리가 할 수 있는 것엔,

• TS 사용의 다른 가능성을 명시
• TS의 한계를 명시
• TS 사용자 판단
• TS 버전과 사용자 간의 관계를 정립

유즈 케이스란 목표를 달성하기 위해 한 역할 (UML에선 "행위자"라고 알려진)과 시스템 간의 상호작용을 명시함으로서 단계의 정리한 세부 목표의 목록입니다.

행위자 "란 사용자나 어떤 시스템이 대상과 접촉할 때의 역할을 나타냅니다. 행위자는 인간 사용자들, 외부 하드웨어, 혹은 다른 대상이 수행하는 역할을 나타낼 수 있습니다.

관계는 모델의 개별 요소들 간의 의미있는 연결을 의미합니다.

이 타입의 다이어그램은 꽤나 일반적이고 TS의 컨셉트적 본질을 나타내지, 그걸 구현하는 법에 대한 것은 아니라는 것을 깨달으실 수 있으실겁니다. 그러나 그게 바로 의도된 바 입니다. 범용적인 것 부터 구체적인 것으로, 추상적인 것에서 보다 확실한 것으로. 대체 누가 우리가 예술가가 되어선 안된다고 했습니까? 우리도 아이디어와 스케치를 시작으로 그림을 그립니다. 먼저 캔버스에 획을 긋습니다. 그 후 색을 추가합니다. 디테일을 그리고...

그러니까 매매 시스템 용으로 유즈 케이스 다이어그램을 만들어봅시다.

입력 행위자로 다음 역할을 선택했습니다. 개발자, 시스템 분석가, 위험 관리자 및 관리자. 이러한 역할은 한 명이나 여러 사람이 수행할 수 있습니다. 매매 시스템은 어떤 조치를 취하며 이와 관련하여 어떤 조치를 취합니까?

따라서 개발자 또한 TS를 개발하고 구현할 수 있습니다. 또한 그 개발자는 TS의 최적화에도 합류할 수 있습니다. 시스템 분석가는 TS를 최적화합니다. 위험 관리자는 위험 관리의 책임을 맡습니다. 관리자는 TS의 전반적인 작업을 감시합니다. 출력 측면에서는 사용자가 TS의 기능을 통해 수익을 창출하는 것을 볼 수 있습니다. 이 역할은 트레이더와 투자자가 합쳐진 역할과도 같습니다. 그리고 매니저와 관리자는 TS 작업을 총괄합니다.

이 다이어그램은 "매매 시스템"이라는 블럭을 포함합니다. TS 경계를 표현하고 외부 세계와 구분합니다.

이제 행위자와 다른 행위자 간의 관계, 그리고 사용 사례 및 기타 사용 사례에 대해 몇 마디 하겠습니다. 대부분의 관계는 실선으로 표시된 연결로 표시됩니다. 이 말은 특정 행위자가 유즈 케이스를 발동시킨다는 의미입니다. 따라서 위험 관리자는 위험 관리 프로세스를 시작하는 등, 유즈 케이스를 개시하는 행위자는 주체가 되며, 커밋된 조치의 결과를 사용하는 행위자는 부차적입니다. 예를 들어 부차적 행위자는 출력 측의 매니저입니다. 

연계성(Association)은 어떤 행위자가 적절한 유즈 케이스를 개시하도록 할 수 있습니다.

일반성(Generalization)는 각 역할의 일반성을 시뮬레이션합니다.

확장성(Extension)은 기본 유즈 케이스와 특수 케이스 간의 종속도 같은 것입니다.

포괄성(Include)은 한 유즈 케이스와 다른 유즈 케이스 간의 관계를 정의하며, 기본 케이스가 항상 사용하는 것이 아니라 특정 부가 상황 하에서만 사용하는 기능적 행태에 대해 정의합니다.

그러나 유즈 케이스와 관련된 2차 역할이 부차적 중요성을 의미하는 것은 아닙니다. 또한, 다이어그램에서 TS 사용자의 역할은 일반화의 관계를 통해 트레이더와 투자자의 역할로 구성되며, 이는 "색칠되지 않은" 삼각형 화살촉과 선으로 표시됩니다.

4번 그림. TS의 사용 케이스 다이어그램

유즈 케이스 "개방 포지션" 및 "청산 포지션"은 차례로 "매매"와의 일반성에 의해 관련됩니다. 뒤쪽의 "매매"가 나머지 두 케이스의 기본 케이스입니다. 따라서 이에는 "리스크 관리"라는 유즈 케이스가 포함됩니다. 그리고 이 행태는 종속 관계 케이스인 "수익"과 관련되어 있습니다.

TS 수익은 자산의 매도가가 매수가보다 높다는 조건으로 형성되기 때문에, 저는 이러한 경우에 확장 관계를 사용하였습니다. 다이어그램은 또한 "수익 실현"이 사용되는 확장 지점(특정 조건)을 보여줍니다. 종속 관계는 해당하는 고정관념이 "포함" 및 "확장"인 화살표로 점선으로 표시됩니다.

각 사용 사례에 대해 시나리오를 작성해야 합니다. 즉, 의도된 대상으로 이어지는 일련의 단계를 설명하는 것입니다. 유즈 케이스는 여러 형태로 설명될 수 있습니다. 가장 흔하게 사용되는 것에는 글로 된 설명, 가짜 코드(pseudocode), 활동 다이어그램, 관계 다이어그램이 있습니다.

트레이더 TS에 관심을 갖는 것은 4번 그림과 같은 것이 아닌 엄격한 의미에서라는 점에 주목해야 한다. 따라서, 저는 "수익 창출"이라는 확장자를 가진 사용 사례 "트레이딩"에 초점을 맞출 것을 제안합니다.

2.2 클래스 다이어그램

클래스 다이어그램을 이용하여 TS 구조를 설명할 것입니다. 객체 지향 프로그래밍의 클래스 측면에서 매매 시스템의 정적 구조 모델을 제시하겠습니다. 그러므로 우리는 TS의 프로그래밍 논리를 반영시킬 것입니다.

UML에서 클래스 다이어그램이란 수동 구조 다이어그램 중 하나입니다. 클래스, 속성 및 연산자는 물론 클래스의 관계를 보여줌으로써 시스템의 구조를 설명합니다.

이 타입 다이어그램의 장점은 무엇일까요? 객체 지향 프로그래밍 언어에 조금 익숙한 사람들은 "클래스"라는 익숙한 개념을 즉시 알아차릴 것입니다. 이 클래스는 UML 클래스 다이어그램에서 기초 블럭처럼 활용됩니다. 예를 들어 C++ 코드를 생성할 때면 UML 클래스 블럭이 클래스 템플릿 형태로 자연스럽게 생성됩니다. 각 메소드와 속성을 마저 구현할 필요가 있습니다.

연습 삼아 무언가 디자인해보도록합시다. 우선 그걸 하기 전에 "Prototype of a Trading Robot" 문서를 읽어줏셨으면 합니다. 이 문서에서 저자는 직접 논리를 사용하는 것의 장점에 대해 설명하고 있습니다. 제 생각에는 "매크로-함수-매매 모듈" 테스팅 원칙은 상당히 쓸모 있고 생산적입니다.

예를 들어 표준 라이브러리 내 매매 클래스의 가능성을 활용하는 Expert Advisor가 필요합니다.

클래스 블록을 활용하여 클래스 다이어글매 내 클래스 모델을 생성합니다. 저는 이를 CTradeExpert라고 부릅니다. 새 클래스를 위해 몇가지 속성을 추가합니다 (MQL5에서는 class 데이터 멤버라고 불립니다). 추가된 것은 Magic_No, e_trade, e_account, e_deal, e_symbol, e_pnt 입니다. 또한 CTradeExpert 클래스의 생성자 메소드도 넣습니다. 해당 작업은 5번 그림과 같이 보일 것입니다.

5번 그림. CTradeExpert 클래스의 UML 모델

속성 앞의 "-" 기호는 해당 속성이 «private», «#» - «protected», «+» - «public» 등에 액세스할 권한이 부여되어있다는 의미입니다. 따라서 예를 들어 Magic_No 속성은 private로 되어있고, e_pnt는 public, 그리고 나머지는 protected 인 식입니다. 속성 이름 뒤에 오는 콜론은 속성에 대한 데이터 유형과 메소드에 대해 반환되는 데이터 유형을 나타냅니다. 예를 들어 Magic_No 메소드는 int 타입이며, e_trade는 CTrade 타입인 식입니다.

지금은 어떠한 메소드나 속성을 추가하진 않고, 그냥 CTradeExpert 클래스가 어떤 식으로 표준 라이브러리 클래스와 연결되어있는지만 보여드릴 것입니다.. 이를 위해서는 다이어그램에 클래스 블럭 6개를 추가하고 다음과 같이 명명하십시오. CTrade, CAccountInfo, CDealInfo, CSymbolInfo, CObject. 이제 우리는 CTradeExpert 클래스 모델을 "use" 스테레오타입 (화살표가 달린 /모양 점선) 과의 종속 관계를 통해 4개의 trade 클래스 블록과 연관시킬 것입니다 

종속성(Dependency)는 한 독립된 개체의 변화가 다른 개체의 변화로 이어지는 영향을 미칠 수 있는, 두 개체간의 의미 관계를 지칭합니다.

UML에서 스테레오타입이란 객체 행동의 설명을 일컫습니다.

그런 다음 "도색되지 않은" 삼각형 화살촉이 있는 선을 사용하여 일반화 관계에 따라 이러한 블록을 CObject 블록과 연결합니다. 표준 라이브러리 클래스에 코멘트를 추가합니다. 이제 우리의 UML 다이어그램은 6번 그림에서처럼 보입니다.

6번 그림. UML 클래스 다이어그램

이제 사이드 바의 "생성" 탭을 눌러 "생성" 함수를 통해 코드를 생성하기만 하면 됩니다 (7번 그림).

7번 그림. 생성된 코드

가장 적합한 것은 C++ 언어입니다. C++를 이용하여 Expert Advsior 코드를 생성하고, 그 뒤 MQL5로 쉬이 포팅할 것입니다.

이 다이어그램 용 생성 코드는 다음과 같습니다.

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

꽤 익숙한 신택스 아닙니까? 그냥 클래스 본문에 붙이기만 하면 됩니다. 이를 위해서 MetaEditor에서 새 클래스를 위한 파일 TradeExpert.mqh를 생성합니다. 앞에서 생성된 코드를 복사하십시오. 가독성을 위해 CTradeExpert 클래스 멤버들로 부터 protected를 지워야합니다.

표준 라이브러리 클래스 선언에 관련된 줄들을 지우십시오. 그 후에 우리가 쓰는 표준 라이브러리 클래스 각각에 대해 파일 인클루드 명령# Include을 추가해야합니다. 이는 이미 개발자에 의해 해당 클래스들이 정의되었기 때문입니다. 코멘트를 추가하고요. 그 결과 다음과 같은 코드를 얻습니다.