如何用合规UML建模async/await模式的异步调用返回？

许多现代编程语言都支持异步调用机制，并提供了在真正需要结果时再等待的实现方式，比如C#、Swift中的async/await，或是C++里的promise/future。以下是一段示例代码实现：

class X { 
  private Y y; 
  public async void doSomething() {
    var someTask = y.doSomeAsyncOp();// 异步调用
    doSomethingImmediately();        // 可能与异步操作并行执行
    var result = await someTask;     // 获取或等待异步调用的结果
  }
  ...
}

这段代码的核心设计意图是"发起异步调用后先执行其他逻辑，在需要结果时再等待异步操作完成"，对应的原始序列图试图表达这一逻辑，但根据UML 2.5.1规范，回复消息仅适用于同步调用，异步调用不应带有回复消息（参考规范17.4.3章节：若消息类型为reply，则该消息代表同步调用操作的返回，消息参数对应操作的out、inout和返回型自有参数），规范第13章对同步与异步行为的定义也印证了这一点。

那么，该如何用符合UML规范的方式对这类设计进行建模？下面是几种可选方案的分析：

• 反向异步消息：如果代码中存在显式回调操作时，这种方案可行，但如果没有明确的回调函数（如示例代码仅通过await隐式等待），消息签名的定义会成为难题——无法对应代码中没有显式暴露的回调接口。
• 用第二个同步调用建模await：优势是能直观体现await时的同步等待特性，但同样面临消息签名的定义问题：这个同步调用的命名、参数设计该如何准确对应代码中获取异步任务结果的逻辑？
• 引入中间Task生命线：这属于过细的实现级建模，画出的UML图会比代码本身更难理解，而且无法清晰传递核心的设计意图，显然不是合适的方案。

内容的提问来源于stack exchange，提问作者Christophe