如何使用 UML 工具开发 EA 交易：可视化建模再写码
一、为什么 EA 开发需要 UML（不是画着玩）
EA 一旦变复杂，指标、信号、订单管理、风控模块互相纠缠，纯靠脑图和注释很容易漏掉分支。UML 的价值不在'画图好看'，而在于用一套标准图形把需求、对象、流程、生命周期先固定下来，再动手写 MQL5——等价于先画蓝图再盖楼。
二、用例图：先把'交易者要什么'说清
用例图（Use Case）只回答一个问题：谁，用这个 EA 做什么。参与者通常是'交易者''信号订阅者''风控模块'，用例是'开仓''平仓''启停交易''接收警报'。先把用例列全，需求的边界就清楚了，后面不会写着写着多出一堆没约定的功能。
三、类图：把指标/信号/订单管理拆成对象
类图（Class）把 EA 拆成可复用的对象：一个指标封装成 CIndicator 派生类，信号逻辑是一个 CSignal，订单管理是一个 CTrade 包装，风控是一个 CRisk。每个类只暴露必要的方法和属性。这样写出来的 MQL5 代码模块边界清晰，后续维护和点位改动都不用通篇改。
- 指标类：封装 iMA/iMACD 等句柄与取值，对外只给'当前信号'。
- 信号类：组合多个指标，输出 Buy/Sell/None。
- 交易类：包装 CTrade，统一下单、加仓、平仓入口。
- 风控类：管仓位、止损、日内亏损上限。
四、活动图：把交易流程画成可读步骤
活动图（Activity）适合画'条件分支多'的流程：检测信号→判断是否有持仓→无持仓则按风控算手数→下单→设止损→等待平仓条件。把每个判定菱形画出来，逻辑漏洞（比如忘了清掉挂单）一眼就能发现。
五、状态机：管住 EA 的生命周期
EA 不是一直'在交易'，它有明确状态：初始化→空闲→等待信号→开仓中→持仓→平仓→出错恢复。状态机（State Machine）图把这些状态和转移条件画清楚，能避免'信号来了却在下单一半卡死'这类竞态。MQL5 里可用枚举 + switch 直接落地。
六、序列图：看清模块间的消息流
序列图（Sequence）按时间轴展示'谁先发消息给谁'：OnTick 触发→指标类返回数值→信号类判断→交易类下单→风控类记录。复杂 EA 用序列图最容易暴露'某个模块被重复调用'或'回调顺序错了'的问题。
七、把 UML 落到 MQL5 的实用建议
不必五张图全画。小 EA 用用例 + 活动图就够了；中大型才补类图、状态机、序列图。图画在纸上或 draw.io 都行，重点是'先设计后写'。落地时每个类对应一个 .mqh 文件，状态用 enum，转移写在 OnTick/OnTradeTransaction 里。
八、速查：五张图各自什么时候画
- 用例图：接需求、定边界时画，回答“谁用 EA 做什么”，防止后期冒出没约定的功能。
- 类图：拆模块、定接口时画，回答“分成哪几个对象、各自暴露什么方法”。
- 活动图：画交易与下单流程，回答“步骤和分支怎么走、有没有漏掉清挂单”。
- 状态机：管 EA 生命周期，回答“现在处于什么状态、什么条件触发转移”。
- 序列图：排查模块调用顺序错时画，回答“消息谁先发给谁、有没有重复调用”。
九、常见误用
别把 UML 当交付物堆砌——图多不代表设计好。反模式有：用例写得像实现细节、类图把所有东西塞进一个上帝类、状态机画了十几个状态却分不清转移条件。图少而准，胜过图多而乱。
十、小结
UML 不能替你写 MQL5，但能逼你在写代码前把需求、对象、流程、生命周期想透。先用例定边界，再类图拆模块，活动图与状态机管流程，序列图查调用——这套顺序落到 MQL5 就是'每类一个文件、状态用枚举'的干净工程。