画面遷移図を書く際にステートマシン図を利用しています。

そこで、単一画面から複数の自己遷移がある場合に問題が発生しました。

[状態]の[オブジェクト]から画面を作成し、
[分析]の[フロー]から遷移線を作成しています。

ここで自己遷移の場合は、必ず次の形になってしまいます。
　　―――――
　　　　　　　　　|
　　←――――

２つの画面間[オブジェクト]で複数の遷移線[フロー]を書く場合は、
「頂点の設定と解除」オプションを使用することにより上手く書けるのですが、
単一画面での複数の自己遷移では、遷移線が重なってしまい上手く書けません。

画面遷移図を上手く書く方法があれば教えてください。

画面遷移図をステートマシン図を利用してかかれているとのことですが、僕の場合は、自己遷移がある場合のことを書かれていますが、自己遷移が複数ある場合とは、どのような場合でしょうか？

ちょっと疑問に思ったのでメッセージをあげました。
また、自己遷移を画面遷移では僕の場合は書かない（書く必要が無いと思っている）のですが、どのような目的で書かれているかをご教えてください。逆に、自己遷移をステートマシン図で書かないという選択もあるのではないのでしょうか。

僕は、自己遷移は、明確に自己遷移（状態を抜けて、また状態に入る）させたい時にのみ書くようにしています。

返信ありがとうございます。とても参考になります。

自己遷移を書かなければいけないと思った経緯と、また複数の自己遷移が出現してしまった経緯を記述します。

先に結論を言えば「お客様の要求を実現できる方法を実装者に伝えるためです。」

その例を一つ書いてみます。

まず背景として、お客様は複数の画面間の遷移を好まない方で、
どうしても一つの画面から複数の機能を実現したいという要望がありました。


「お気に入りUMLツール登録画面」における自己遷移例

①登録画面で自分のお気に入りのUMLツール名をテキストボックスに入力します。
②ただし、フルネームが分からない場合は「Enterp」のように入力して「検索ボタン」を押して、該当するUMLツール名を検索します。
③検索結果が１件の場合は「自己遷移」して、テキストボックスに「Enterprise Architect」のように補完した結果を戻します。
　また検索結果が複数件の場合は「一覧画面」に遷移して、該当結果から１つ選択します。

このように、検索結果が１件の場合は自己遷移するということを明示したいため、ガード条件をつけて
「検索実行{検索結果が１件の場合}」というように画面遷移図に自己遷移線を記述しています。

④テキストフィールドが未入力の場合や入力未許可の文字を入力して「検索ボタン」を押した場合。
⑤ＤＢへの検索まで行かず、入力チェック処理でエラーとなります。(ActionFormのvalidate errorのイメージ）
⑥「自己遷移」してエラーメッセージを表示します。

こんな感じで、自己遷移を書きたくなりました。
また、別々の条件で自己遷移することを区別したいために、複数の自己遷移も書きたくなりました。

きっとノートを上手く使うという方法もあると思いますが、
自己遷移先を複数書きたくなった経緯は上記のとおりです。

よこやりで申し訳ありません

自分としての見解を述べさせて頂きます
参考になるかは分かりませんが

まず、指摘にもあるとおり
③に関しては、「検索結果が複数ある」場合に限り
状態遷移するという考え方で、特に２パターン用意する必要は
ないかなあと思っています

その他についても遷移する条件のみ考慮すれば
実装者も「他の場合は遷移しないのね」と思うのでは？

また⑥のエラーメッセージの場合、エラーメッセージを出力する状態
に遷移すると考えれば、自己遷移ではないような記述の仕方もできるのではないでしょうか？

実際の方法論的な面では他の方からコメントがついていますので
自己遷移の線についてコメントさせていただきます。

現在、ご指摘のように左側面のみにしか
自己遷移の矢印はつけることができません。

これは長らくEnterprise Architectの制限となっておりますが
この位置の改善を希望されるお客様も多く、
技術的な解決策を検討しておりました。

Enterprise Architect4.0では要求/提供インターフェースの
要素が追加されましたが、これは要素の周りの好きな位置に
配置することができるようになりました。これと同様の方法で
改善することができるのではないかと考えており、もし
うまくいけば、今の制限を解除できるかもしれません。

すぐに対応できるかどうかはわかりませんが、ご要望として
いただいておりますので、将来的にはより柔軟な図が
書けるようになると考えております。

>よこやりで申し訳ありません
㌧でもございません。ご意見ありがとうございます。

なんか自己遷移線は書く必要がないように思えてきました。

いやいや、でもやっぱり不安です。
お客様からの要求が変わったらどうなるのでしょうか？

③で検索結果が複数件ヒットした場合は、一覧画面に遷移するのではなく、
エラーメッセージを表示することになった場合を考えてみます。

・検索条件の入力ミス→自己遷移でエラーメッセージ
・検索結果が１件の場合→自己遷移で結果をテキストフィールドに格納
・検索結果が複数件の場合→自己遷移でエラーメッセージ

となり、自己遷移線を書かないとなると、
「検索実行」というイベントが表現できなくなると思います。

やはり「遷移する」ということは、何らかのイベントが必ず発生するので、
イベントを明示的にするという意味でも、遷移線は必須だと思っています。
それが、結果的に自己遷移となったのか、他画面への遷移となったかの問題だと思いませんか？

ふむ・・
なんだかややこしい問題ですね

tkouno殿のレスポンスにあったように
ツール側での対応ができれば、それにこしたことはありませんよね

ダイアグラムの位置付けの話にもなるかとは思いますが
画面遷移にスポットをあてた場合には
画面を遷移する条件とその次に表示される画面の指定だけで
いいかなあとも思います

ただ・・画面遷移と、各イベント発生時に実行する処理まで
考えてしまうと次元数が多くなるので私ですと
おおまかなイベントごとに状態遷移図を分けたりすることを考えてしまいます
signal殿のやりたいことが全てわからず
勝手なことを申しているかもしれませんが

問題は、画面の遷移で考えると重複するけど
本来の状態遷移で考えると
「同じ画面が表示されていてもシステムの状態が違う」
・・にあるような気もしています

あくまで私の見解ですので
ご参考程度に受け取ってくださいね

ここら辺をサブ状態を使用してかけないかなと考えていますけど、どうですか？。なんかできそうな気もするんですが・・

ではでは。

画面の遷移とシステムの状態の遷移が混ざっているように
見えますが…

どうしても1つの状態図に書きたいならば，画面遷移を
概観として，システムの状態をサブ状態として表現すると
良いのでは？