非同期メッセージに関するノート

Quick Sequence Diagram Editorは自由にシーケンス図を書くツールではなく、手早く正確に作図するために意図的に以下の２つの制約をつけています:

1. メッセージはアクター、もしくはメッセージを受け取ってアクティブになっているオブジェクトからしか送信できません。
2. メッセージが送信されるときには、送信元オブジェクト(送信者)が開始していたアクティビティは、送信前に完了している必要があります。通常はこの部分はツール側で面倒を見ます。これに関してはメリットがあり、ツール側で、正しい場所とタイミングに、返信用のメッセージを自動で挿入するために、すべてにおいて逐一指定する必要はありません。

これらの制約は、非同期なメッセージに対して行うことはできないように見ます。非同期メッセージは、送信した直後に返事が返ってくるが、送信側がアクティブな間も、受信側がアクティブでい続けて、直前に呼ばれた側が再び非アクティブになる前に、他のメッセージを送信できるかのように描画されます。

しかし、このようなメッセージはQuick Sequence Diagram Editorでは、マルチスレッドの描画をサポートしているため、うまくモデル化することができます。内部的にはマルチスレッドを使用して実装されていることが多く、そのような機能を使って描画するのは詳細に入ってしまうために反対する人もいるかもしれません。しかし、Quick Sequence Diagram Editorにとっては、マルチスレッドが、非同期メッセージを描画する唯一の方法で、なおかつ十分な方法です。結局のところ、単なるモデリングツールなので、マルチスレッドの詳細の深くまで探求する必要はありません。

サンプルとして、サーバが、数多くのクエリーをデータベースに投げるようなバックグランドジョブを実行して、結果を後から返すというケースのシーケンスを以下に示します:

user:Actor
server:Server[a]
job:BackgroundJob[a]
db:Database[a]

user:server[s].start

# ここでは、新しいスレッドを生成することによって、暗示的に非同期メッセージを
# 実現しています。'j'というニーモニックのおかげで、ジョブオブジェクトは
# 新しいスレッド上で安全に識別することができます。そのため、スレッド番号を
# 厳格に取り扱う必要はありません。

[c asynchronous message]
  server:>job[j].start
[/c]

job:db.do 1'000'000 queries
server[s]:server.do something useful
job[j]:job.analyze queries
job[j]:job.compute result
server[s]:server.wait for result
job[j]:server.send back result
job[j]:stop
server[s]:user.send result to user

オブジェクトがシングルスレッドとして使用されるか、ニーモニックがあると、スレッド番号は無視することができます。もしもスレッドに色付けする機能がオフになっていると、自由な位置に矢印を置けるWYSIWYGのツールを使って使って作成したものと、非常に似たシーケンス図が結果としてできあがります。