（目的）あるメソッドに変更が加わった場合に、そのメソッドを呼び出している所を追跡したいと考えています。

（質問への背景）コードで追うことも可能なのですが、コードで追うためには、ポリモフィズムのあるコードでは、追うことが簡単にはできません。
　そのため、EAのシーケンス図上から追跡できないかと考えました。
　APIのSample(C#)を用いて、出来ないかを調べていたのですが、シーケンス図の実行仕様に当たる所がどこか分からず、行き詰ってしまいました。
　実行仕様に当たる所がなければ、ConnectorとLifeLineとの接続のレベルのようなものがあるのかとも思いましたが、見つけられませんでした。

(質問内容）
　シーケンス図のメッセージによる実行仕様から、どのメッセージが次へ続いているのか、をAPIで見つける方法を教えてください。
　（目的は、最初の内容ですので、他の方法でも良いので、）

よろしくお願い致します。

最初に1点確認ですが、今回調べようとされているシーケンス図は、
Enterprise Architectのシーケンス図自動生成機能を利用して
生成したものでしょうか？
それとも、ご自身で書かれたものでしょうか？

なお、シーケンス図の実行仕様につきましては、データとしては
保持しておりません。
その前後のメッセージの内容により、適した実行仕様を表示しております。


調べたい内容ですが、あるメッセージが変更になった場合、
そのメッセージを利用している(呼んでいる)メソッドを
調べたいということで認識は合っておりますでしょうか？

この場合は、変更のあったメソッドのSequenceNoよりも小さい値を持ち(上部にあり)、
かつConnectorの接続先が該当のメソッドを保有するオブジェクト
という条件で探すことになると思います。


いただいた(質問内容)から、調べたいことの認識が異なる可能性も
ありますので、その場合は、ご指摘いただけますと助かります。

すばやいご回答、ありがとうございます。

>最初に1点確認ですが、今回調べようとされているシーケンス図は、
>Enterprise Architectのシーケンス図自動生成機能を利用して
>生成したものでしょうか？
>それとも、ご自身で書かれたものでしょうか？
これは、自身で書いたものです。

>調べたい内容ですが、あるメッセージが変更になった場合、
>そのメッセージを利用している(呼んでいる)メソッドを
>調べたいということで認識は合っておりますでしょうか？
はい。その通りです。

>この場合は、変更のあったメソッドのSequenceNoよりも小さい値を持ち(上部にあり)、
>かつConnectorの接続先が該当のメソッドを保有するオブジェクト
>という条件で探すことになると思います。
もう一息、お付き合い頂いて教えていただきたいのですが、メッセージグループが異なるメッセージを拾って来ないようにするには、どのように調べたら宜しいでしょうか？

よろしくお願い致します。

該当メッセージのSequenceNoの直前から、より小さい値のメッセージに
向かって順番に参照し、新しいメッセージグループが開始されている
メッセージがあれば、そこまでが同一グループであるという認識は
可能だと思います。

メッセージグループとは、メッセージを選択し「実行仕様」→
「新規メッセージグループの開始」の設定を指しています。
この設定が有効な場合は、ConnectorのStateFlagsの文字列内にある
Initiateの値が1になっています。(Initiate=1;)

この間に、該当のメッセージを保持するオブジェクトに対して、
別のオブジェクトからのメッセージがあれば、それが該当の
メッセージを呼んでいるメッセージということが言えるのでは
ないかと考えております。

ただし、どのようなシーケンス図を書かれているかにもよりますので、
さらにいくつかの条件をチェックする必要があるかもしれません。

ご検討のほど、よろしくお願いいたします。

何かご不明点などありましたら、ご連絡ください。

どうもありがとうございます。

通常のシーケンスについては、上記で教えて頂いた方法で対応できると思います 。

下記のようなケースの場合には、条件を追加しないとならないと思いますが、何を追加して判断したら良いのでしょうか？
（imageの貼り付けがうまく出来なかったため、文字ですみません）

シーケンスは、上から、
msg元 , msg名 , msg先
O -> 出現メッセージ１() -> クラス１ .. <1>
クラス１ -> メッセージ１to２() -> クラス２ .. <2>
クラス２ -> メッセージ２to１() -> クラス１ .. <3>
クラス１ -> メッセージ１to２の２() -> クラス２ .. <4>

<1>により開始された実行仕様が、<2>と<4>をcallしています。
<2>により開始された実行仕様が、<3>をcallしています。
仮に<4>が変更された時に、
単純に下から上に追うと、<4>の上に<3>があり、<3>は、SeqNoが小さく、Connectorの接続先が該当のメソッドを保有するので、該当してしまいますが、実際には、探したいのは、<1>となります。

この他に困りそうな所は、
別のタスクから来たメッセージが混ざっている場合です。
でも、これは、上述の<3>のケースの解決方法の範疇なのかも知れないと思いました。念のため、挙げさせてください。

以上、お手数をお掛けします。よろしくお願い致します。

まず、<3>は戻りメッセージではないということでよろしいでしょうか？

この場合ですと、メッセージの向きで判定する必要があると思われます。
変更のあったメッセージと同じと向き(この場合は、左から右)で、
他のオブジェクトからのメッセージという条件になると思います。
メッセージの位置は、StartPointX、EndPointXなどで取得できますので、
この情報を元に向きを判断できます。

ただし、メッセージによっては、右方向にあるオブジェクトからの
メッセージ呼び出し(右から左)によって、左から右へのメッセージ
を発行する場合もある可能性がありますので、すべてのパターンにおいて、
方向のみで正しく判断できるとは限りません。

また、<4>のメッセージの実行仕様が上がっている場合は、<1>ではなく、
<3>からの呼び出しになると思いますが、この場合は、Connectorの
StateFlags内の文字列であるActivationが1になりますので、この情報で判断できます。


さまざまなパターンを考えますと、何かこのデータを参照すれば
間違いないというものは現状ありませんので、周辺のメッセージの
情報を取得し、その都度、解析を行う必要があると思います。

そのほか情報の取得方法などでご不明点がありましたら、ご連絡ください。

>まず、<3>は戻りメッセージではないと
>いうことでよろしいでしょうか？
はい。<3>は、戻りメッセージではなく、イベント通知です。但し、同期呼び出しで、通常のメッセージと同じ振る舞いになります。

軽くコードを組んで確認してみました。
向きの判断を加えれば、あとは、出来そうな感じになってきました。向きと、Connectorの位置情報から、大分工夫できそうです。

これ以上の複雑な場合は、シーケンス図側を少しメンテすることで、判断しづらいケースを取り除いたりする方が、コスト面や安全性からみて、良いとも感じました。

また、困ったケースになってしまったら、質問をさせてください。

とても助かりました。どうもありがとうございました。

メッセージの向きが、今回の判定に利用できそうでよかったです。

別のケースで、情報の取得方法などが不明な場合は、ご連絡ください。

今後ともよろしくお願いします。