거래 시스템 uml

사례 다이어그램 사용.
사례 다이어그램 사용.
Jacobson (1994)은 유스 케이스를 소프트웨어 개발의 주요 요소로 소개 할뿐만 아니라 유스 케이스를 시각화하기위한 다이어그램도 소개했다. 유스 케이스 다이어그램도 이제 UML의 일부입니다.
많은 사람들이 이러한 종류의 다이어그램을 유용하게 사용합니다. 그러나 유스 케이스를 사용하기 위해 다이어그램을 그릴 필요가 없다는 점을 강조해야합니다. 유스 케이스를 사용한 가장 효과적인 프로젝트 중 하나는 각 인스턴스를 인덱스 카드에 보관하고 카드를 더미로 정렬하여 각 반복에서 필요한 빌드를 표시하는 것이 었습니다.
그림 3-2는 금융 거래 시스템의 몇 가지 사용 사례를 보여줍니다.
그림 3-2. 유스 케이스 다이어그램.
액터는 사용자가 시스템과 관련하여 수행하는 역할입니다. 그림 3-2에는 Trading Manager, Trader, Salesperson 및 Accounting System의 네 가지 액터가 있습니다. (예, "역할"이라는 단어를 사용하는 것이 더 나을 것임을 알고 있지만 분명히 스웨덴 사람에게서 오역이있었습니다.)
해당 조직에는 많은 상인이있을 것입니다. 그러나 시스템과 관련하여 그들은 모두 동일한 역할을합니다. 사용자는 둘 이상의 역할을 수행 할 수도 있습니다. 예를 들어 한 상급 상인은 상장 관리자 역할을 할 수 있으며 또한 정규 상인 일 수도 있습니다. 상인도 영업 사원이 될 수 있습니다. 배우와 대화 할 때 사람이나 직책보다는 역할에 대해 생각하는 것이 중요합니다.
액터는 유스 케이스를 수행합니다. 한 명의 배우가 많은 유스 케이스를 수행 할 수 있습니다. 반대로 유스 케이스에는이를 수행하는 몇 명의 액터가있을 수 있습니다.
실제로 유스 케이스가 생기면 액터가 가장 유용하다는 것을 알게되었습니다. 큰 시스템에 직면하면 유스 케이스 목록을 찾는 것이 어려울 수 있습니다. 이러한 상황에서 먼저 배우 목록에 도달하는 것이 더 쉽습니다. 그리고 나서 각 배우에 대한 사용 사례를 찾아내는 것이 좋습니다.
액터는 유스 케이스 다이어그램 내에서 스틱 형상으로 표현되지만, 인간 일 필요는 없습니다. 액터는 현재 시스템의 일부 정보가 필요한 외부 시스템 일 수도 있습니다. 그림 3-2에서 회계 시스템에 대한 계정을 업데이트해야 할 필요성을 알 수 있습니다.
사람들이 배우로 보여주는 것에는 몇 가지 변형이 있습니다. 어떤 사람들은 유스 케이스 다이어그램에 모든 외부 시스템이나 인간 행위자를 보여줍니다. 다른 사람들은 유스 케이스의 개시자를 보여주는 것을 선호한다. 나는 유스 케이스로부터 가치를 얻는 배우를 보여주기를 선호하는데, 어떤 사람들은 이것을 주인공으로 지칭한다.
그러나 나는 이것을 너무 멀리 생각하지 않는다. 저는 회계 시스템 자체를 모델링해야하는 회계 시스템에서 가치를 얻는 인간 배우를 파악하지 않고 회계 시스템이 가치를 얻는 것을 보아서 기쁩니다. 즉, 시스템 사용자와 항상 유스 케이스에 의문을 제기하고 실제 사용자의 목표를 파악하고 이러한 목표를 달성하기위한 대안을 고려해야합니다.
배우와 유스 케이스를 사용할 때 정확한 관계가 무엇인지 걱정하지 않아도됩니다. 대부분의 경우, 필자가 실제로 사용한 것은 유스 케이스이다. 배우들은 거기에 도달하는 단지 방법 일뿐입니다. 모든 유스 케이스를 얻는 한, 배우의 세부 정보는 걱정하지 않습니다.
나중에 배우를 추적 할만한 가치가있는 상황이 있습니다.
시스템에서 다양한 종류의 사용자를 구성해야 할 수 있습니다. 이 경우, 각 종류의 사용자는 액터이고 유스 케이스는 각 액터가해야 할 일을 보여줍니다.
유스 케이스를 원하는 사람을 추적하면 다양한 액터 간의 우선 순위를 협상하는 데 도움이됩니다.
일부 유스 케이스에는 특정 액터에 대한 명확한 링크가 없습니다. 유틸리티 회사를 생각해보십시오. 분명히, 그것의 유스 케이스 중 하나는 Send Out Bill이다. 그러나 관련 배우를 식별하는 것은 쉽지 않습니다. 특정 사용자 역할이 청구서를 요청하지 않습니다. 이 청구서는 고객에게 보내지 만 고객이 발생하지 않으면 반대하지 않습니다. 배우의 가장 좋은 추측은 유스 케이스로부터 가치를 얻는다는 점에서 Billing Department입니다. 그러나 대금 청구는 대개 유스 케이스의 재생에 포함되지 않습니다.
일부 유스 케이스는 각 액터의 유스 케이스에 대한 생각의 과정에서 튀어 나올 수 없다는 것을 알아 두십시오. 그렇게되면 걱정하지 마십시오. 중요한 것은 유스 케이스와 사용자가 만족하는 목표를 이해하는 것입니다.
유스 케이스를 식별하기위한 좋은 소스는 외부 이벤트입니다. 외부 세계에서 당신이 반응하기를 원하는 모든 사건을 생각해보십시오. 주어진 이벤트는 사용자와 관련이없는 시스템 반응을 유발하거나 사용자가 주로 반응을 일으킬 수 있습니다. 대응해야하는 이벤트를 식별하면 사용 사례를 식별하는 데 도움이됩니다.
사례 관계 사용.
액터와 유스 케이스 사이의 링크 외에도 유스 케이스간에 여러 종류의 관계를 표시 할 수 있습니다.
포함 관계는 둘 이상의 유스 케이스에서 유사한 동작 묶음이 있고 해당 동작의 설명을 계속 복사하지 않으려는 경우에 발생합니다. 예를 들어, 위험 분석 및 가격 거래는 거래를 평가할 것을 요구합니다. 거래 평가를 기술하는 것은 상당한 양의 글쓰기를 포함하며 복사 및 붙여 넣기가 싫다. 따라서이 상황에 대해 별도의 Value Deal 사용 사례를 작성하여 원래의 사용 사례에서 인용했습니다.
다른 유스 케이스와 비슷하지만 좀 더 많은 유스 케이스가있는 경우 유스 케이스 일반화를 사용합니다. 결과적으로 이것은 다른 시나리오를 포착하는 또 다른 방법을 제공합니다.
이 예에서 기본 사용 예제는 Capture Deal입니다. 모든 것이 원활하게 진행되는 경우입니다. 그러나 상황에 따라 거래를 원활하게 포기할 수 있습니다. 하나는 제한이 초과 된 경우입니다. 예를 들어 특정 고객에 대해 거래 조직이 설정 한 최대 금액입니다. 여기서는 주어진 사용 사례와 관련된 일반적인 동작을 수행하지 않습니다. 우리는 대안을 수행합니다.
앞에서 설명한 Buy a Product 유스 케이스와 마찬가지로, 대안으로 Capture Variance 유스 케이스 내에이 대안을 넣을 수 있습니다. 그러나이 대안은 별도의 유스 케이스를 갖추기에 충분하다고 생각할 수 있습니다. 기본 유스 케이스를 참조하는 특수한 유스 케이스에 대체 경로를 넣습니다. 특수화 된 사용 사례는 기본 사용 사례의 모든 부분을 재정의 할 수 있지만 여전히 필수적인 사용자 목표를 충족해야합니다.
그림 3-2에 나와 있지 않은 세 번째 관계를 확장이라고합니다. 본질적으로 이것은 일반화와 비슷하지만 더 많은 규칙이 있습니다.
이 구성을 사용하면 확장 유즈 케이스가 기본 유스 케이스에 동작을 추가 할 수 있지만 이번에는 기본 유스 케이스가 특정 "확장 포인트"를 선언해야하며 확장 유스 케이스는 해당 확장 포인트에서만 추가 동작을 추가 할 수 있습니다. (그림 3-3 참조).
그림 3-3. 관계 확장.
유스 케이스는 많은 확장 포인트를 가질 수 있으며 확장 사용 케이스는 이러한 확장 포인트 중 하나 이상을 확장 할 수 있습니다. 다이어그램의 유스 케이스 사이에 줄에있는 것을 나타냅니다.
일반화와 확장 모두 유스 케이스를 분리 할 수 ​​있습니다. 정교화 과정에서 너무 복잡한 경우가 종종있었습니다. 내가 한 번의 반복에서 전체 유스 케이스를 구축 할 수 없다는 것을 발견하면 프로젝트의 건설 단계에서 나눠 봤다. 내가 쪼개 질 때, 나는 정상적인 경우를 먼저하고 나중에 변이를하고 싶다.
다음 규칙을 적용하십시오.
두 개 이상의 개별 사용 사례에서 반복 할 때 포함을 사용하면 반복을 피하고자합니다.
일반 행동의 변형을 설명하고 자연스럽게 설명하고 싶을 때 일반화를 사용하십시오.
일반 동작의 변형을 설명하고 기본 사용 사례에서 확장 점을 선언하면서보다 제어 된 양식을 사용하려는 경우 extend를 사용합니다.

UML 도구를 사용하여 전문가 고문을 개발하는 방법.
과학자들은 이미있는 것을 조사한다. 엔지니어는 지금까지 없었던 것을 만듭니다.
소개.
필자는 Simulink : Expert Advisors 개발자를위한 가이드에서 동적 시스템을 사용하여 Expert Advisor를 모델링 할 것을 제안했습니다. 그러나이 접근법은 거래 시스템 설계자의 한 가지 측면, 즉 시스템의 동적 동작을 나타냅니다. 전문가에게는 거래 시스템 개발자의 방법론을 확장하는 특정 도구가 있습니다. 이 기사에서는 범용 도구 인 그래픽 언어 UML을 사용하여 Expert Advisor를 개발하는 방법에 대해 설명합니다.
일반적으로 그래픽 언어이므로 UML은 객체 지향 소프트웨어 시스템의 시각적 모델링에 사용됩니다. 그러나, 내가 본대로, 우리는 도구를 사용하여 거래 시스템을 개발할 수 있습니다. 게다가 MQL5는 객체 지향 언어 계열에 속하므로 작업이 훨씬 쉬워졌습니다.
모델링 목적으로 비상업적 인 소프트웨어 인 Software Ideas Modeler를 무료로 선택했습니다.
Expert Advisor를 만드는 데 UML이 어떻게 도움이 될까요? 첫째, 그래픽 - 다중 측면 모델링의 문제점은 언어에서 사용할 수있는 그래픽 이미지를 사용하여 해결할 수 있습니다. 둘째, 가독성. Expert Advisor가 크고 복잡하더라도 UML의 보편성 덕분에 다이어그램을 사용하여 모델을 표현할 수 있습니다.
UML의 개발자가 말했듯이, 인간 인식의 구체적인 특징은 이미지가있는 텍스트가 맨손 텍스트보다 더 쉽게 인식된다는 사실에 있습니다.
UML의 기본 사항에 대해 간략하게 살펴 보겠습니다. 주제에 관심이 있다면 웹에서 자유롭게 사용할 수있는 수많은 발행물에서 UML 도구를 배울 수 있습니다.
UML 구조는 다이어그램 (그림 1)에 표시 될 수 있습니다.
그림 1. UML 구조.
빌딩 블록은 엔티티 (모델의 요소), 관계 (사물을 묶는) 및 다이어그램 (UML 모델을 나타냄)을 포함합니다.
UML 다이어그램은 서로 다른 관점에서 설계된 시스템의 표현을 시각화합니다.
일반적인 메커니즘은 사양 (의미의 설명), 장식 (모델의 중요한 특성을 표시), 공통 구분 (추상화 및 인스턴스, 인터페이스 및 구현), 확장 성 메커니즘 (제약 조건, 고정 관념 및 태그 값)을 포함합니다.
아키텍처는 환경에서 시스템의 고수준 표현을 담당합니다. UML 아키텍처는 "4 + 1 아키텍처보기"(그림 2)로 가장 잘 설명 될 수 있습니다.
그림 2. 4 + 1 아키텍처보기.
또한 UML에는 정식 다이어그램 (그림 3)의 계층 구조가 있습니다. 언어 버전 2.2는 14 가지 유형의 UML 다이어그램을 사용합니다.
그림 3. 표준 UML 다이어그램.
또한 UML 다이어그램을 사용하는 몇 가지 특수한 경우를 고려할 것을 제안합니다. 따라서 우리는 EA 개발 목적을 위해 다이어그램을 사용하여 추상화에서 특정 변형으로 이동할 수 있습니다. UML 다이어그램의 계층 구조에 의해 제공되는 거래 시스템의 다중 측면 설계 원칙은 다시 TS 생성 작업의 체계적이고 포괄적 인 솔루션에 기여합니다.
2.1 유스 케이스 다이어그램.
속담처럼, 좋은 출발은 전투의 절반입니다. 일반적으로, 필연적 인 것은 아니지만, 분석 작업은 유스 케이스 다이어그램으로 시작됩니다. 사용자 관점에서 시스템을 설명합니다.
그것을 만들 때, 우리는 할 수 있습니다 :
TS의 변형을 명세한다. TS의 경계를 명세한다. TS 행위자가 행위자와 TS 버전 간의 관계를 정의하는지 결정한다.
유스 케이스는 일반적으로 목표를 달성하기 위해 역할 (UML에서 "행위자"로 알려짐)과 시스템 간의 상호 작용을 정의하는 단계 목록입니다.
배우 "는 주체와 상호 작용하는 사용자 또는 다른 시스템이 수행하는 역할을 지정하며, 액터는 사용자, 외부 하드웨어 또는 기타 주제가 수행하는 역할을 나타낼 수 있습니다.
관계는 모델의 개별 요소 간의 의미 론적 연결입니다.
이 유형의 다이어그램은 매우 일반적이며 구현보다는 TS의 개념적 특성을 반영합니다. 그러나 그것은 추상적 인 것에서부터 구체적인 것에 이르기까지 일반에서 특수까지 이동하는 요점입니다. 누가 우리가 예술가가 아니라고 했습니까? 우리는 일반적인 생각과 스케치로 시작하여 그림을 그린다. 먼저 우리는 선을 캔버스에 그립니다. 그런 다음 색상을 추가하십시오. 세부 사항 그리기.
그럼, 거래 시스템을위한 유스 케이스 다이어그램을 만들자.
입력 액터로서 저는 개발자, 시스템 분석가, 위험 관리자 및 관리자 역할을 선택했습니다. 이러한 역할은 하나 이상의 사람이 수행 할 수 있습니다. 우리 거래 시스템은 어떤 행동을 취하고 그것에 관련된 어떤 조치가 취해 집니까?
따라서 개발자는 TS를 생성하고 구현할 수 있습니다. 또한 TS 최적화에 참여할 수 있습니다. 시스템 분석가는 TS를 최적화합니다. 위험 관리자는 위험 관리를 담당합니다. 관리자는 TS의 전체 작업을 모니터링합니다. 출력면에서 사용자는 TS의 기능으로 인해 이익을 얻는 것으로 나타납니다. 이 역할은 Trader와 Investor와 같은 역할의 합계입니다. 그리고 관리자와 관리자는 TS의 작업을 감독합니다.
다이어그램에는 "Trading System"블록이 있습니다. 그것은 TS 경계를 표현하고 외부와 분리시킨다.
이제 액터와 유스 케이스의 관계, 액터와 다른 액터와의 관계, 유스 케이스와 기타 유스 케이스에 대해 설명합니다. 대부분의 관계는 실선으로 표시된 연관에 의해 표현됩니다. 즉, 특정 액터가 유스 케이스를 시작합니다. 따라서 위험 관리자는 위험 관리 프로세스 등을 시작합니다. 유스 케이스를 시작하는 행위자는 원칙이고, 실행 된 행위 결과를 사용하는 행위자는 부수적입니다. 예를 들어 보조 액터는 출력 측의 관리자입니다.
연결은 액터가 적절한 유스 케이스를 시작한다는 것을 나타낼 수 있습니다.
일반화는 적절한 일반성을 시뮬레이션합니다.
확장은 기본 유스 케이스와 특별한 경우 사이의 종속 관계의 일종입니다.
Include는 기본 유스 케이스와 다른 유스 케이스의 관계를 정의합니다. 이 유스 케이스의 기능적 동작은 기본 케이스에서 항상 사용되는 것은 아니지만 추가 조건에서만 사용됩니다.
그러나 유스 케이스와 관련하여 보조 역할은이 역할이 중요하지 않다는 것을 의미하지는 않습니다. 또한 다이어그램에서 TS 사용자의 역할은 일반화 관계를 통해 상인과 투자자의 역할로 구성되며, "도색되지 않은"삼각형의 화살촉이있는 선으로 표시됩니다.
그림 4. TS의 유스 케이스 다이어그램.
사용 사례 "열린 위치"와 "닫는 위치"는 차례로 "거래"와 관련된 일반화와 관련됩니다. 후자의 경우는 다른 두 경우에 기본입니다. 따라서, 여기에는 유스 케이스 "위험 관리"가 포함됩니다. 그리고 그것의 행동은 종속적 인 경우 "이익"을 보완합니다.
TS 이익은 자산의 매도 가격이 매수 가격보다 큰 조건으로 형성되므로이 경우 확장 관계를 사용했습니다. 또한 다이어그램에는 확장 포인트, 즉 특정 조건이 표시되며 여기에서 "이익을 위해"가 사용됩니다. 종속 관계는 점선으로 화살표와 함께 해당 고정 관념 "include"와 "extend"로 표시됩니다.
각 유스 케이스에 대해 시나리오를 작성해야합니다. 시나리오는 의도 된 대상으로 이어지는 일련의 단계를 설명하는 것입니다. 유스 케이스는 여러 가지 형태로 설명 될 수 있습니다. 일반적으로 허용되는 양식은 텍스트 설명, 의사 코드, 활동 다이어그램, 상호 작용 다이어그램을 포함합니다.
상인은 그림 4와 같이 엄격한 의미에서 TS에 관심이 있다는 점에 유의해야합니다. 따라서 "To profit"이라는 확장 사례가있는 "Trading"유즈 케이스에 초점을 두는 것이 좋습니다.
2.2 클래스 다이어그램.
클래스 다이어그램을 사용하여 TS 구조를 설명 할 것입니다. 즉, 우리는 객체 지향 프로그래밍의 클래스 측면에서 트레이딩 시스템의 정적 구조 모델을 제시 할 것이다. 따라서 우리는 TS의 프로그래밍 논리를 반영 할 것입니다.
UML에서 클래스 다이어그램은 정적 구조 다이어그램 유형입니다. 클래스의 특성, 연산자 및 클래스의 관계를 보여줌으로써 시스템의 구조를 설명합니다.
이 다이어그램 유형의 장점은 무엇입니까? 객체 지향 프로그래밍 언어에 익숙한 사람들은 익숙한 "클래스"개념에 즉시 주목할 것입니다. 이 클래스는 UML 클래스 다이어그램에서 기본 빌딩 블록으로 사용됩니다. 예를 들어, C ++ 코드를 생성 할 때 UML 클래스 블록은 자동으로 클래스 템플릿의 형태로 생성됩니다. 각 메소드와 속성의 구현 만 완료하면됩니다.
이제 예제로 무언가를 디자인 해 봅시다. 하지만 먼저 저자가 직접 논리를 사용하는 이점을 설명하는 "무역 로봇의 프로토 타입"이라는 기사에 관심을 기울이고 싶습니다. 제 생각에 매우 효과적이고 생산적 인 기능은 중첩의 원칙입니다 - "매크로 기능 - 무역 모듈".
예를 들어 표준 라이브러리 클래스를 거래 할 수있는 전문가 조언자가 필요합니다.
클래스 블록을 사용하여 클래스 다이어그램에 클래스 모델을 만듭니다. 나는 그것을 CTradeExpert라고 불렀다. 우리는 새로운 클래스에 대한 몇 가지 속성 (클래스의 데이터 멤버 인 MQL5에서)을 추가합니다. 그들은 : Magic_No, e_trade, e_account, e_deal, e_symbol, e_pnt입니다. 또한 CTradeExpert 클래스의 생성자 메서드를 삽입합니다. 그래픽 적으로, 동작은도 5에 도시 된 바와 같다.
그림 5. CTradeExpert 클래스의 UML 모델.
속성 앞의 문자 "-"는 속성이«개인»,«#»-«보호»,«+»-«공개»모드에서 액세스 권한을 가지고 있음을 나타냅니다. 따라서 Magic_No 속성의 경우 액세스 지정자는 e_pnt - 공개 키 및 기타 키 - 에 대해 개인용으로 설정됩니다. 속성 이름 다음에 오는 콜론은 속성에 대한 데이터 유형과 메소드에 대해 리턴 된 데이터 유형을 나타냅니다. 예를 들어, Magic_No 속성은 int 유형, e_trade - CTrade 유형 등입니다.
우리는 지금 어떤 메소드와 속성도 추가하지 않고 있으며, 단순히 CTradeExpert 클래스가 표준 라이브러리의 클래스와 어떻게 연결되어 있는지 보여줍니다. 이렇게하려면 다이어그램에 6 블록의 클래스를 추가하고 다음과 같이 호출합니다 : CTrade, CAccountInfo, CDealInfo, CSymbolInfo, CObject. 이제 우리는 CTradeExpert 클래스 모델을 "사용"스테레오 타입 (화살표가있는 파선)과의 의존 관계를 통해 4 개의 무역 클래스 블록과 연결합니다.
의존성이란 두 엔터티 간의 의미 론적 관계로, 독립된 하나의 변경이 다른 종속 된 엔터티의 의미에 영향을 미칠 수 있습니다.
UML의 스테레오 타입은 객체의 동작에 대한 설명입니다.
그 다음, 우리는이 블록들을 "도색되지 않은"삼각형 화살촉이있는 라인을 사용하여 일반화 관계에 의해 블록 CObject와 연결합니다. 표준 라이브러리 클래스에 주석을 추가하십시오. 자, UML 다이어그램은 그림 6과 같습니다.
그림 6. UML 클래스 다이어그램
우리는 이제 사이드 바에있는 "Generate"탭의 "Generate"기능을 사용하여 코드를 생성하면됩니다 (그림 7).
그림 7. 생성 된 코드.
가장 적합한 언어는 С ++입니다. C ++을 사용하여 Expert Advisor 클래스의 코드를 생성 한 다음 MQL5로 쉽게 변환 할 것입니다.
이 다이어그램에서 생성 된 코드는 다음과 같습니다.
정말 친숙한 구문 이죠? 우리는 단지 수업의 몸에 꼭 맞아야합니다. MetaEditor에서이 목적을 위해 우리는 새로운 클래스 TradeExpert. mqh를위한 파일을 생성합니다. 이전에 생성 된 코드를 여기에 복사하십시오. 가독성을 위해 CTradeExpert 클래스의 멤버에 대해 보호 된 반복 액세스 지정자를 삭제합니다.
표준 라이브러리 클래스의 선언과 연결된 행을 삭제하십시오. 그런 다음 표준 라이브러리의 각 사용 된 클래스에 대해 명령어 # Include를 포함한 파일을 추가하십시오. 이러한 클래스는 개발자가 이미 정의했기 때문입니다. 그리고 우리의 의견을 추가하십시오. 결과적으로 다음과 같은 코드가 생성됩니다.
이제 Expert Advisor 클래스에 더 많은 거래 기능 모듈을 추가해 보겠습니다.
CheckSignal, OpenPosition, CheckPosition, ClosePosition 등이 있습니다. "조건 제공"원칙을 이미 알고 있기를 바랍니다. 이 경우 우리의 테스트 클래스 인 CTradeExpert는 당신에게 어려움이 없을 것입니다. 필자는 UML의 메커니즘을 더 쉽게 이해할 수 있도록 익숙한 Expert Advisor 예제에 중점을 두었습니다.
그래서, 이제 클래스의 모델은 그림 8과 같습니다.
그림 8. CTradeExpert 클래스의 UML 모델.
클래스의 업데이트 된 모델의 경우 이미 설명한 메서드를 사용하여 코드를 생성 할 수도 있습니다.
2.3 활동 다이어그램.
이러한 유형의 UML 다이어그램을 사용하여 데이터 흐름 및 제어 흐름 모델을 사용하여 시스템의 동작을 연구 할 수 있습니다. 활동 다이어그램은 단계별 활동 및 조치의 워크 플로를 그래픽으로 표현한 것입니다.
활동 다이어그램은 알고리즘의 단계 만 설명하는 순서도와 다릅니다. 활동 다이어그램 표기법이 더 넓습니다. 예를 들어, 객체의 상태를 지정할 수 있습니다.
활동 다이어그램은 개발자가 다음을 설명하는 데 사용됩니다.
비즈니스 규칙 단일 사용 사례 솔루션 및 대안 스트림 병렬 운영 프로그램 흐름 및 논리 제어 구조를 사용하는 여러 유스 케이스 프로세스의 복잡한 시리즈.
생성 된 전문가 클래스 CTradeExpert가 Expert Advisor Test_TradeExpert. mq5 파일에 사용된다고 가정합니다. 우리가 기억 하듯이, MetaEditor 5에서 EA를 생성 할 때 기본 템플릿은 OnInit, OnDeinit 및 OnTick의 세 가지 기본 이벤트 처리기 기능을 제공합니다. 그들과 함께 지내자.
Test_TradeExpert. mq5 파일에 대한 EA 작업 회계를 사용하여 다이어그램을 표시해 봅시다. 여기서 전문가 어드바이저 또는 오히려 그 구조는 다소 원시적이라는 점에 유의해야합니다. 우리는 지금 훈련 중이다. 간단한 EA 구조가이 목적에 적합합니다.
Expert Advisor 사용을위한 다이어그램을 디자인 해 봅시다. 알고리즘은 Test_TradeExpert. mq5 파일에 표시됩니다.
그래서, 그것은 모두 초기 노드에서부터 시작됩니다 (그림 9). 이 노드에서 컨트롤 토큰이 "전문가 자문 인스턴스 생성"작업을 호출하는 노드로 이동합니다. 이 작업은 객체 노드 (myTE = created)의 상태를 변경하고 "Expert Advisor 초기화"를 호출하는 노드로의 흐름을 제어하는 ​​객체 흐름 (파란색 화살표)을 시작합니다.
제어 흐름은 액티비티의 두 노드를 연결하고 제어 토큰 만 전달되는 활동 에지 형태로 표시됩니다.
오브젝트 플로우는 오브젝트 또는 데이터 토큰 만 전달되는 활동 에지로 표시됩니다.
활동 노드는 모서리로 연결된 활동 흐름의 개별 지점에 대한 추상 클래스입니다.
결정 노드는 나가는 플로우들 사이에서 선택하는 제어 노드입니다.
오브젝트 노드는 활동에 사용 된 오브젝트를 나타냄니다.
액티비티 에지는 두 액티비티 노드 간의 직접 연결에 대한 추상 클래스입니다.
초기 노드는 활동이 시작되는 위치를 표시합니다.
활동의 마지막 노드는 모든 활동 흐름을 완료합니다.
차례대로 개체 myTE (myTE = 초기화 됨)의 상태가 변경되고 컨트롤 토큰이 결정 노드로 전달됩니다. Expert Advisor가 성공적으로 초기화되면 제어 흐름은 "Trade 이벤트 NewTick 처리"노드로 이동하고 초기화가 실패하면 제어 토큰은 먼저 일반화 노드로 들어가고 "Deinitialize Expert Advisor"작업 노드로 들어갑니다.
토큰은 통계적으로 정의 된 활동 그래프의 동적 실행 프로세스를 설명하는 편의를 위해 도입 된 추상 구성입니다. 토큰은 추가 정보 (빈 토큰)를 포함 할 수 없습니다. 이 경우이를 제어 흐름 토큰이라고 부르거나 개체 또는 데이터 구조에 대한 참조를 포함 할 수 있으며이 경우이를 데이터 흐름 토큰이라고합니다.
결정 노드에서 오는 첫 번째 제어 흐름을 살펴 보겠습니다. 빨간 점선으로 그려진 모서리가 둥근 직사각형과 "인터럽트 가능"의 스테레오 타입으로 표시되는 것처럼 중단 된 동작이있는 영역으로 보내집니다. 제어 흐름이이 영역에있을 때 예기치 않게 중지 될 수 있습니다. "Unload Expert Advisor"이벤트를 수신하는 작업 노드 (주황색 플래그)를 활성화하면 모든 플로우가 중단됩니다. 제어 토큰이 인터럽트 가장자리 (오렌지색 지그재그 화살표)로 이동 한 다음 연결 노드로 이동합니다. 그 후 EA는 초기화가 해제됩니다. 그런 다음 제어 토큰이 노드 "전역 변수 삭제"로 이동하면 마지막 활동 노드에서 흐름이 완료됩니다.
조치 노드 "Deinitalize Expert Advisor"는 또한 오브젝트 흐름에 의해 myTE (myTE = 초기화되지 않음) 상태를 변경합니다. 노드 "전역 변수 삭제"는 개체 myTE (myTE = deleted)를 제거합니다.
그림 9. Test_TradeExpert. mq5의 활동 다이어그램.
제어 흐름이 안정적이라고 가정합니다. EA는 언로드되지 않습니다. 노드 "거래 이벤트 NewTick 처리"에서 흐름은 또 다른 블록으로 이동합니다 - 확장 영역, 고정 관념은 "반복"(점선이있는 녹색 사각형)으로 정의됩니다.
나는이 영역을 "Trading block"이라고 부르며, 다이어그램의 기본 특성을 반영하고 다이어그램의 인식을 향상시킵니다. 블록의 특징은 들어오는 객체에 대한 작업의 주기적 실행입니다. 길고 짧은 방향을 다루는 2 사이클 만 있으면됩니다. 블록의 입구와 블록의 출력에는 무역 방향 객체 (길거나 짧은)가 포함 된 확장 노드가 있습니다.
확장 노드는 확장 영역에 들어가거나 나오는 확장 객체의 집합입니다. 각 객체에 대해 한 번 실행됩니다.
신호를 보내는 동작 노드 (신호 동작 보내기)는 신호 전송을 나타냅니다.
이벤트를 수락 (이벤트 동작 수락)하고 적절한 유형의 이벤트 수신을 기다리는 동작 노드입니다.
따라서, 각 방향은 "확인 신호"(신호 송신 노드), "수신 신호"(신호 수신 노드), "열린 위치"(신호 송신 노드), "위치 확인"(신호 송신 노드) , "Close position"(신호 송신 노드). 방향 객체 (dir)는 보라색 화살표로 표시된대로 작업 노드 사이의 객체 흐름에서 전달 될 수 있습니다. 전문가 어드바이저가 언로드되는 한 블록의 작업은 계속됩니다.
2.4 시퀀스 다이어그램.
시퀀스 다이어그램을 사용하여 객체 상호 작용 순서를 설명합니다. 이 유형의 다이어그램에서 매우 중요한 부분은 시간입니다.
따라서 다이어그램에는 암시적인 형식의 두 가지 비율이 있습니다. 수평선은 객체 상호 작용의 순서를 담당합니다. 수직축은 시간축입니다. 시간 간격의 시작은 다이어그램의 위쪽 부분입니다.
다이어그램의 맨 위에는 상호 작용하는 다이어그램 객체가 있습니다. 객체는 자체 라이프 라인을 세로 점선으로 사용합니다. 객체는 메시지를 교환합니다. 그들은 화살표로 표시됩니다. 오브젝트가 활성화되면 컨트롤 포커스를받습니다. 그래픽 적으로이 초점은 라이프 라인의 좁은 직사각형으로 표현됩니다.
객체는 밑줄이 그어진 객체 이름과 콜론으로 구분 된 클래스 이름 (선택 사항)이 포함 된 사각형입니다.
객체 생명선은 일정 기간 동안 객체의 존재를 나타내는 라인입니다. 라인이 길수록 오브젝트가 길어집니다.
컨트롤 포커스는 좁은 사각형으로 그려지는데, 위쪽은 오브젝트 (컨트롤 시작)에 의한 컨트롤 포커스 수신 시작을 나타내며, 아래쪽 - 컨트롤 포커스 끝 (동작 끝)을 나타냅니다.
UML에서 각 상호 작용은 메시지 세트로 설명되며, 여기에 참여하는 객체가 교환됩니다.
연습을 해봅시다.
터미널은 배우입니다. Expert Advisor의 작동을 시작합니다. "이벤트"스테레오 타입으로 표시된 다른 객체는 클라이언트 터미널의 이벤트입니다 : Init, Deinit, NewTick. 물론 원하는 경우 이벤트 범위를 확장 할 수 있습니다. Expert Advisor를 시작할 때 myTE 객체는 전역 수준에서 만들어집니다. 이것은 CTradeExpert 클래스의 인스턴스입니다. 클래스 개체는 다이어그램의 다른 개체보다 약간 낮습니다. 이 개체는 생성자 함수 다음에 만들어 짐을 나타냅니다.
생성 명령은 열린 화살표와 1.1 CTradeExpert () 메시지와 함께 점선으로 표시되어 있습니다. 화살표가있는 점선은 CTradeExpert ()의 "생성"유형을 나타냅니다. CTradeExpert의 인스턴스를 생성 한 후 1.2 단계가 활성화됩니다. 컨트롤 포커스가 터미널로 반환됩니다. 읽기 쉽도록 동기 메시지를 #. # 형식 (예 : 1.1 및 비동기 - #)으로 나타냅니다. 그런 다음 터미널은 2.1 단계에서 OnInit () 함수를 사용하여 Init 이벤트를 처리하고 포커스는 2.2 단계에서 반환됩니다. "통화"유형 메시지는 끝에 "칠한"삼각형 화살표가있는 선으로 표시됩니다.
Init 이벤트가 0이 아닌 값을 터미널에 반환하면 초기화가 실패했음을 의미합니다. Deinit 이벤트 생성 및 처리로 이어지는 3.1 단계가 사용됩니다. 3.2 단계에서 제어 포커스가 터미널로 반환됩니다. 그런 다음 CTradeExpert 클래스 개체가 삭제됩니다 (4.1 단계). 그런데 클래스 다이어그램을 만들 때 클래스에 소멸자 함수 CTradeExpert를 포함하지 않았습니다. 이 작업은 나중에 수행 할 수 있습니다. 이것은 다이어그램 작성의 장점 중 하나입니다. 여러 다이어그램의 작성 과정이 반복됩니다. 하나의 다이어그램에 대해 처음 수행 된 작업은 다른 작업에 대해 수행 할 수 있으며 나중에 나중에 수행 할 수 있습니다.
표준 EA 템플릿의 MQL5 코드에는 실패한 초기화를 처리하는 블록이 포함되어 있지 않습니다. 시퀀스 논리를 저장하도록 지정했습니다. UML 시퀀스 다이어그램은 (OnInit ()! = 0) <> 인 경우 MQL5 구성과 동일한 보호 조건 OnInit ()! = 0을 가진 opt 블록을 사용합니다.
단계 4.2에서 제어가 터미널로 전송됩니다.
이제 터미널은 NewTick 이벤트를 처리 할 준비가되었습니다.
이 이벤트의 처리는 블록 루프에 있으며 무한 루프를 의미합니다. 즉 EA는 사용 중지 할 때까지이 이벤트를 처리합니다. 터미널은 OnTick 함수를 사용하여 NewTick 이벤트를 처리합니다 (5 단계). 6 단계에서, 컨트롤 포커스는 Expert Advisor myTE로 전송됩니다. 4 개의 리플 렉 시브 메시지를 사용하여 CheckSignal, OpenPosition, CheckPosition, ClosePosition과 같은 기능을 구현합니다. 반영 성은 Expert Advisor 객체가 메시지를 자신에게 보내는 사실 때문입니다.
또한 CTradeExpert 클래스의 이러한 함수는 loop (2) 블록에 포함되어 있습니다. 두 개는 루프가 두 개의 통과로 구성됨을 의미합니다. 왜 둘? 그것은 무역의 두 방향을 처리하기 때문에 - 길고 짧다 (7 단계에서 10 단계까지). 11 번째 단계에서는 포커스가 터미널로 전달됩니다.
12 단계와 13 단계는 각각 Expert Advisor 객체의 초기화 및 삭제를 담당합니다.
그림 10. Test_TradeExpert. mq5의 SD 다이어그램
따라서 우리는 기본 설계 기술을 가지고 있습니다. 생성 된 다이어그램의 도움으로 개발자의 작업이 최적화됩니다. 이제 Test_TradeExpert. mq5 파일에 대한 코드를 작성할 수 있습니다. 물론 다이어그램없이 할 수 있습니다. 그러나 복잡한 전문가를 보유하고있는 경우 다이어그램을 사용하면 오류 발생 가능성이 줄어들고 TS 개발을 효율적으로 관리 할 수 ​​있습니다.
Expert Advisor 템플릿을 사용하여 Test_TradeExpert. mq5를 작성합니다.
우리는 CTradeExpert myTE 클래스의 인스턴스를 글로벌 수준에서 만듭니다.
이제 OnTick () 함수의 본문을 채우자.
다음과 같이 클래스의 함수를 작성합니다.
이런 식으로 NewTick 이벤트를 처리 할 수 ​​있습니다. 물론 클래스 데이터 멤버가 사용할 함수를 각각 지정해야합니다. 그러나 미래를 위해이 일을 떠나자. 이제 우리의 목표는 UML 다이어그램의 로직을 MQL5 코드로 전송하는 것입니다.
3. UML 다이어그램에 기반한 전문가 고문의 개발 및 발표.
예를 들어, 복잡한 Expert Advisor에 대한 다이어그램을 작성해 봅시다. MQL 5에서 구현 된 주어진 전략의 맥락에서 그 기능을 정의합시다. 일반적으로 전문가 조언자는 무역 업무를 수행합니다. 특히 거래 신호를 생성하고 미결 상태를 유지하며 자금 관리를 유지합니다. 그것은 오히려 템플릿 거래 전략입니다. 그러나 훈련 목적으로 우리는이 문제를 해결하려고 노력할 것입니다.
먼저 EA의 유스 케이스 다이어그램을 만듭니다. 어느 정도까지는 이전에 논의 된 것과 다를 것입니다. 외부 작업 (그림 11)을 무시하고 TS의 내부 환경에주의를 기울였습니다. 코드에서는 거래 작업 만 구현합니다.
그림 11. TS의 유스 케이스 다이어그램.
이제 Expert Advisor의 구조를 정의하겠습니다. TS의 명시된 목적과 일치하기 때문에 우리는 표준 라이브러리 개발을 사용할 것이라고 가정한다. 최근에, 그것은 실질적으로 확장되었습니다. 그리고 무엇보다도 그것은 거래 전략의 클래스와 관련이 있습니다. 그래서, 우리의 목표는 클래스 다이어그램을 만드는 것입니다. 그것은 단순하지 않으므로 인내가 필요합니다.
여기에서는 몇 가지 이유로 표준 라이브러리를 고려해야한다. 첫째, 우리는 기초 위에서 거래 로봇을 만들려고 노력합니다. 두 번째로 중요한 것은 UML 다이어그램을 사용하여 연습하는 것입니다. 셋째, 도서관 자체가 매우 가치있을 것입니다. 그래서 우리는 도서관에서 많은 유용한 것들을 배울 수 있으며, 동시에 아주 단순하지 않은 구조를 이해하려고 노력합니다.
UML 다이어그램의 구조에서 코드를 변환하는 것을 리버스 엔지니어링이라고합니다. 사실, 우리는 이것을 수동으로하고 있습니다. 이 작업을 자동으로 수행 할 수있는 전문 소프트웨어가 있습니다 (IBM Rational Rose, UML 용 시각적 패러다임 등). 그러나 실용적인 목적을 위해서는 "수동으로"일해야한다고 생각합니다.
"클래스"블록을 사용하여 거래 전략 CExpert를 구현하기위한 기본 클래스의 모델을 만들어 보겠습니다. C Expert 클래스의 본문에서 다른 클래스와 구조가 사용되는 것을 확인해보십시오. 첫째, C Expert 클래스는 CExpertBase라는 기본 클래스에서 파생된다는 것을 알아야합니다. CExpertBase는 기본 클래스 CObject에서 파생됩니다.
다이어그램에서 이러한 클래스에 대한 블록을 만들고 "칠해지지 않은"삼각형 화살촉이있는 라인 (일반화)을 사용하여 클래스 간의 관계를 정의합니다. CExpert 클래스의 모델 (구부러진 모서리가있는 노란색 직사각형)에 주석을 추가하십시오. 이제 중간 클래스 구조가 다음과 같이 보입니다 (그림 12).
그림 12. 초기 다이어그램의 전문가 다이어그램
Expert. mqh 파일에 코드를 보자. CExpert 클래스는 특히 미리 정의 된 8 개의 구조체 인 MqlDateTime 중 하나 인 ENUM_TRADE_EVENTS 및 ENUM_TIMEFRAMES 열거 형을 포함합니다. 클래스는 또한 CExpertTrade, CExpertSignal, CExpertMoney, CExpertTrailing, CIndicators, CPositiontInfo, COrderInfo와 같은 다른 클래스 인스턴스를 사용합니다.
CExpert 클래스 블록과 다른 클래스 사이의 "사용"스테레오 타입과의 종속 관계를 표시하고 MqlDateTime 구조체와 열거 형을 잊어 버리자. 블록의 색상 스타일을 변경하고 다음 구조를 얻습니다 (그림 13).
그림 13. 전문가 다이어그램, 초기보기.
그러나 이미 언급 된 클래스에서 간접적으로 사용되는 클래스가 많기 때문에이 구조는 전체 그림을 반영하지 않습니다. 어떤 종류의 수업입니까? 첫째, CExpertTrade 클래스는 CTrade에서 파생됩니다. 후자는 CObject의 하위 클래스입니다.
CExpertTrade 클래스는 ENUM_ORDER_TYPE_TIME 열거 형을 사용하고 CSymbolInfo 및 CAccountInfo 클래스는 CObject의 자식입니다. 또한 CTrade 클래스는 CSymbolInfo 클래스의 인스턴스를 사용합니다. 다이어그램을 변경해 보겠습니다. 이제 우리 다이어그램은 다음과 같은 형식을 갖습니다 - 그림 14.
그림 14. 전문가 다이어그램, 초기보기.
다시, 다이어그램은 완전하지 않습니다. 예를 들어 표준 라이브러리 파일 Trade. mqh를 보면 CTrade가 여러 가지 구조, 열거 형 및 CSymbolInfo 클래스를 사용한다는 것을 알 수 있습니다. 그것들이 모두 하나의 다이어그램에 표시되면 너무 많이로드됩니다. 그리고 이것은 이해하기 어렵게 만들 것입니다.
이 어려움에 대처하기 위해 다이어그램에 패키지를 사용했습니다. 관련 클래스, 열거 형, 다른 패키지 등을 캡슐화합니다. 패키지를 인터페이스를 통해 다이어그램 요소와 연결했습니다. 예를 들어, 패키지 CTrade에 대한 다이어그램은 다음과 같이 나타낼 수 있습니다 - 그림 15.
그림 15. CTrade 패키지의 클래스 다이어그램
CTrade 패키지 다이어그램은 CTrade 클래스와 열거 형 및 구조의 종속 관계를 보여줍니다.
CObject 기본 클래스 및 사용 된 CSymbolInfo 클래스와의 관계는 인터페이스를 통해 구현됩니다.
인터페이스 근처에는 CTrade 패키지를 단일 요소로 포함하는 클래스 다이어그램과의 관계 아이콘이 있습니다. 인터페이스 중 하나를 클릭하면 자동으로 원래 다이어그램이 표시됩니다 (그림 16).
무화과. 16. 인터페이스가있는 전문가 다이어그램.
인터페이스 관계는 주황색입니다. CTrade 패키지 옆의 클래스 다이어그램 아이콘은이 다이어그램으로 이동할 가능성을 나타냅니다. 따라서 캡슐화를 사용하여 클래스 다이어그램의 가독성을 크게 향상시킬 수 있습니다.
그럼, 계속 나아가 자. CObject 클래스는 본문에서 동일한 클래스의 인스턴스에 대한 포인터를 사용합니다. 따라서 우리는 스테레오 타입 "use"를 가진 CObject 블록에 대한 의존 관계를 자체에 대해 설정할 수 있습니다.
CExpertBase 클래스 모델의 블록을 살펴 보겠습니다. ExpertBase. mqh 헤더 파일의 첫 번째 줄을 기반으로이 클래스는 다양한 클래스와 열거 형의 여러 인스턴스를 사용한다고 말할 수 있습니다. 따라서 클래스 모델과 그 관계에 대해 CE xpertBase 패키지를 만드는 것이 합리적입니다.
먼저 패키지 다이어그램에서 CExpertBase 클래스 모델을 정의합니다. 인터페이스를 통해 기본 클래스 CObject와의 관계 및 CSymbolInfo 및 CAccountInfo 클래스와의 사용 관계를 보여줍니다. 그런 다음 클래스 블록과 의존 관계를 사용하여 CExpertBase 클래스가 CiOpen, CiHigh, CiLow, CiSpread, CiTime, CiTickVolume, CiRealVolume 클래스를 사용하도록 지정합니다.
첫 번째 네 클래스는 CPriceSeries에서 파생되며, 네 번째 클래스는 CSeries에서 파생됩니다. 또한 CSeries 클래스에는 자식 CPriceSeries가 있고 CArrayObj의 자식입니다. 우리가 기억 하듯이 상속 관계는 이전에 사용되어 왔습니다. 이들을 다이어그램의 일반화 관계로 나타냅니다.
CExpertBase 클래스가 ENUM_TYPE_TREND, ENUM_USED_SERIES, ENUM_INIT_PHASE, ENUM_TIMEFRAMES와 같은 열거 형을 본문에서 사용한다는 것을 잊지 마십시오. 마지막 열거 형은 CPriceSeries 클래스 및 CSeries 클래스의 자식에서도 사용됩니다. 관계를 잃지 않고 다이어그램을 명확하게 만들려면 다이어그램의 각 요소에 대한 스타일을 조정하십시오. 결과적으로 다음 다이어그램을 얻습니다 (그림 17).
무화과.. 17. CExpertBase 패키지의 클래스 다이어그램.
그것은 아직 완전하지 않으며, 우리는 그것에 대해 좀 더 연구해야 할 것입니다. CPriceSeries 클래스를 상속받은 네 개의 클래스도 CDoubleBuffer 클래스를 사용합니다. 또한 네 클래스 각각은 CDoubleBuffer에서 파생 된 버퍼 클래스를 사용합니다. 따라서 COpen은 COpenBuffer 등을 사용합니다. CDoubleBuffer는 기본 클래스 (CArrayDouble)를 가지며 ENUM_TIMEFRAMES를 사용합니다.
CArrayDouble은 CArray를 상속하고 동일한 클래스 및 ENUM_DATATYPE 열거 형의 인스턴스에 대한 포인터를 사용합니다. The COpenBuffer class and other buffer classes of price series (CHighBuffer, CLowBuffer, CCloseBuffer) use the ENUM_TIMEFRAMES 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 ENUM_DATATYPE 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 ENUM_TIMEFRAMES enumeration.
CSeries uses enumerations ENUM_SERIES_INFO_INTEGER , ENUM_TIMEFRAMES . It inherits CArrayObj. The latter one inherits CArray, uses ENUM_POINTER_TYPE , 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).
Fig. 19. The Expert diagram with interfaces.
I've also added the ENUM_ORDER_TYPE enumeration used by CExpertTrade . For readability, I've 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, let's 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 . It's good to use a package for it and its relationships (Fig. 20).
Fig. 20. Diagram of the CSymbolInfo package.
Some free space in the diagram can be used for comments. Also, I've 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, let's move on. Let's 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).
Fig. 21. CAccountlInfo package diagram.
Now let's 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.
Fig. 22. CExpert package diagram.
Let's 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.
Fig. 23. CExpertSignal package diagram.
I am not showing all the diagrams now - they are all available in the attached file Expert. simp . Now let's 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.
Fig. 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).
Fig. 25. Expanded diagram of packages and classes Expert.
What functions and data should each of the classes include is up to the developer. Here, I'm 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 let's 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).
Fig. 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, I've 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).
Fig. 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).
Fig. 28. The sequence diagram of myTrader_Deinit.
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 haven't handled other events of the client terminal (NewTick, Trade).
결론.
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:
MetaQuotes Software Corp. 에서 러시아어로 번역

Trading system uml

코드 1-20 / 60 페이지 : 1 2 3 다음으로 & gt; & gt; 페이지.
Nevron Diagram for (Windows Forms 및 ASP)은 완벽하게 관리되고 확장 가능하며 강력한 다이어그램 작성 프레임 워크로, WinForms 및 WebForms에서 풍부한 기능의 다이어그램 작성 솔루션을 만들 수 있습니다.
프로그램은 760mmHg 및 76mmHg에서 에탄올 - 물 이원 시스템에 대한 엔탈피 대 조성 도표를 계산합니다. 또한 타이 라인과 공액 라인을 그립니다.
프로그램은 큐빅지도와 현실적인 인구 역학 모델에 대한 분기 다이어그램을 계산합니다. 세 번째주기가 나타날 때 매개 변수 r의 값이 표시됩니다. 예상대로, r 값이 높을수록 우리는 혼란을 겪는다.
XML 스키마 및 UML 용 UML 프로파일을 포함하여 UML로 XML 애플리케이션을 모델링하기위한 개발 툴. 플러그인은 Eclipse Modeling Tools (MDT)를 기반으로합니다. 이클립스 업데이트 사이트 URL xmlmodeling. sourceforge / updates에서 설치할 수 있습니다.
이 도구는 런타임시 Java 프로그램의 UML 시퀀스 다이어그램을 리버스 엔지니어링 할 수 있도록 도와줍니다. 이것은 여러 Java 프로그램 (다중 스레드가 있음)과 Application Server에 전개 된 J2EE 응용 프로그램에서 잘 작동합니다.
'기술 거래 시스템은 거래 신호를 생성하는 데 사용할 수있는 일련의 거래 규칙으로 구성됩니다. 일반적으로 간단한 거래 시스템에는 거래 신호의 타이밍을 결정하는 하나 또는 두 개의 매개 변수가 있습니다. 각 규칙은 거래에 포함됩니다.
이것은 당신이 필요로하는 유일한 링크 거래 시스템입니다. 그들이 당신을 보내는 것처럼 당신의 가입에게 동일한 양의 방문자를 보내는 것을 디자인된다.
이 프로젝트는 LETS 회원의 사용을 위해 웹에서 액세스 할 수있는 로컬 교환 및 트레이딩 시스템 관리 도구입니다. 온라인 디렉토리, 회계 및 지불 시스템 및 온라인 뉴스 레터로 구성됩니다.
Nevron 다이어그램은 완벽하게 관리되고 확장 가능하며 강력한 다이어그램 작성 프레임 워크로, WinForms 및 ASP 프로젝트에서 대화식 및 기능이 풍부한 다이어그램 및지도 솔루션을 만들 수 있습니다. 제품은 고체를 기본으로합니다.
mcdp는 리눅스 운영체제를위한 작고 (아마도 가장 작은) CD 플레이어입니다.
- 그것은 다이어트 라이브러리에 대해 컴파일 될 수 있습니다 (
- 일하는 놀이 방법 : reapeat cd.
열 전달 적용을위한 Heisler 다이어그램.
Webmail-Client for DBMail-Servers, PHP 5.3으로 작성된 mysql 데이터베이스의 dbmail 시스템 용 브라우저 기반 클라이언트. POP3 또는 IMAP을 사용하지 않았습니다.
opentick-ruby (실시간 견적) 및 ib-ruby (주문)를 사용한 자동화 된 거래 (로봇)를위한 도메인 특정 언어
거래자는 거래 알고리즘을이 분산 된 프레임 워크에 연결하여 자체 거래 시스템을 개발할 수 있습니다. 지원 : 클라이언트 계정, 포트폴리오 추상화, (a) 틱 데이터 하위 및 (b) 클라이언트 포트 당 여러 브로커 API에 대한 개방형 I / F를 지원합니다.
디렉토리에 대한 간단한 파일 시스템 작업을위한 래퍼. 예를 들어 디렉토리의 내용을 열거하면 매번 openDir / readDir / closeDir 전체 공연을하는 대신 오류를 처리하는 read_file 함수를 사용합니다.
lpr이있는 모든 * nix 시스템을위한 매우 간단한 프린터 모듈.
.. 고정 금리 타이머로 운영되고 데이터의 검색, 저장 및 분석을 처리하는 원시적 인 양식 자동화 된 거래 시스템을 구축하십시오. 각 반복에서 포트폴리오를 재조정하는 '전략'가이드가 기본 출력을 a.
Simulink 용 블록은 알려지지 않은 시스템 다이내믹스를 자극하는 짹짹 소스를 제공합니다. 이 블록은 시스템 식별을 위해 특별히 개발되었지만 강력하고 안정적인 기능을 원하는 사람에게는 관심을 가져야합니다.
시뮬레이션 시스템을위한 + 시뮬 링크 모델.
IRC PHPbot은 데이터베이스 시스템에 MySQL을 사용하여 PHP로 코딩 된 IRC 봇입니다.
모든 파일 및 무료 다운로드는 해당 소유자의 저작권입니다. 우리는 스크립트, 코드, 구성 요소 다운로드의 해킹되고, 금이 가며, 불법적 인 해적판을 제공하지 않습니다. 모든 파일은 게시자 웹 사이트, 파일 서버 또는 다운로드 미러에서 다운로드됩니다. 항상 웹에서 다운로드 한 바이러스 검사 파일은 특별히 zip, rar, exe, trial, 정식 버전 등 Rapidshare, depositfiles, megaupload 등에서 다운로드 링크를 다운로드하지 않습니다.

UML 유스 케이스 다이어그램 - 티켓 처리 시스템.
UML 유스 케이스 다이어그램 - 티켓 처리 시스템.
(1) 고객 서비스 기술자가 문제에 대해 고객으로부터 전화 통화 또는 기타 통신을 수신합니다. 일부 응용 프로그램은 기본 제공 메시징 시스템과 예외 처리 블록에서 자동 오류보고 기능을 제공합니다.
(2) 기술자는 문제가 실제로인지 아닌지를 확인합니다. 기술자는 문제에 대한 충분한 정보를 고객으로부터 확보 할 수도 있습니다. 이 정보는 일반적으로 고객의 환경, 문제 발생시기 및 방법, 기타 모든 관련 상황을 포함합니다.
(3) 기술자는 시스템에서 고객이 제공 한 모든 관련 데이터를 입력하여 문제를 만듭니다.
(4) 그 문제에 대한 연구가 끝나면 기술자가 새로운 데이터로 시스템을 업데이트합니다. 문제를 해결하려는 시도는 문제 시스템에 기록되어야합니다. 티켓 상태가 열린 상태에서 대기 상태로 변경 될 가능성이 큽니다.
(5) 문제가 완전히 해결 된 후에는 문제 추적 시스템에서 해결 된 것으로 표시됩니다.
문제가 완전히 해결되지 않으면 기술자가 고객으로부터 새로운 정보를 받으면 티켓이 다시 열립니다. 이러한 워크 플로우에 대한 모범 사례를 구현하고 IT 직원의 효율성을 높이는 Run Book Automation 프로세스가 매우 보편화되고 있습니다. "[Issue tracking system. Wikipedia]
UML 유스 케이스 다이어그램 예제 "티켓 처리 시스템"은 ConceptDraw Solution Park의 소프트웨어 개발 영역에서 Rapid UML 솔루션으로 확장 된 ConceptDraw PRO 다이어그램 작성 및 벡터 드로잉 소프트웨어를 사용하여 작성되었습니다. 더 많은 것을 읽으십시오.
UML 유스 케이스 다이어그램 - 거래 시스템 사용 시나리오.
알고리즘 트레이딩의 특별한 클래스는 "고주파 거래"(high frequency trading, HFT)로, 종종 시장 변동성이 높은시기에 가장 수익성이 있습니다. 지난 몇 년 동안 Algorate와 같은 회사는 HFT 전략을 사용하여 시장이 가파른 하락세를 보인 기간에도 높은 수익을 기록했습니다. "[알고리즘 거래. Wikipedia]
UML 유스 케이스 다이어그램 예제 "거래 시스템 사용 시나리오"는 ConceptDraw Solution Park의 소프트웨어 개발 영역에서 Rapid UML 솔루션으로 확장 된 ConceptDraw PRO 다이어그램 작성 및 벡터 드로잉 소프트웨어를 사용하여 작성되었습니다. 더 많은 것을 읽으십시오.
Jacobson 사용 사례 다이어그램.
UML 유스 케이스 다이어그램 예제. 서비스 UML 다이어그램. ATM 시스템.
은행 ATM 유스 케이스 다이어그램.
"예를 들어, 자동 출납기를 설계하는 경우, 시스템 기능의 특정 측면에 대한 유스 케이스는 모든 가능한 상황에서 자동 출납기가 수행하는 것을 설명 할 수 있습니다. 이러한 각각의 변화는 시나리오 및 유스 케이스는 시나리오 모음으로 간주 될 수 있습니다. 시나리오는 다음으로 시작하는 질문으로 생각할 수 있습니다 : 시스템이 수행하는 작업 ” 예를 들어, 고객이 막 공정한 경우 자동 응답기는 어떻게합니까? 마지막 24 시간 안에 수표를 예금하고, there†™ s는 원하는 철수를 제공하는 것을 맑게하는 수표없이 계정에서 충분하지 않다? †s.
유스 케이스 다이어그램은 의도적으로 단순하여 시스템 구현 세부 사항을 조기에 파악할 수 없도록합니다.
각 스틱 사람은 전형적으로 사람 또는 다른 종류의 자유 계약자 인 “actor, †represents를 나타냅니다. (“ATM의 경우와 마찬가지로 다른 컴퓨터 시스템 일 수도 있습니다.) 상자는 시스템의 경계를 나타냅니다. 타원은 유스 케이스를 나타내며 시스템에서 수행 할 수있는 중요한 작업에 대한 설명입니다. 액터와 유스 케이스 사이의 선은 상호 작용을 나타냅니다.
그것은 시스템에 실제로 구현되는 방법은 사용자에게 이와 같이 보이지 않는 한 중요하지 않습니다. "
이 ATM (automated teller machine) UML 유스 케이스 다이어그램 예제는 ConceptDraw Solution Park의 소프트웨어 개발 영역에서 ATM UML 다이어그램 솔루션으로 확장 된 ConceptDraw PRO 다이어그램 작성 및 벡터 드로잉 소프트웨어를 사용하여 작성되었습니다. 더 많은 것을 읽으십시오.