私は常に UML シーケンス図を使用しており、UML2 表記法にも精通しています。
しかし、私は自分がやろうとしていることの本質を捉えるためにしかそれらを使用しません. 言い換えれば、ダイアグラムは常に実際のコードの上の抽象化レベルに存在します。それらを使用して自分が何をしようとしているのかを正確に説明しようとするたびに、非常に多くの水平スペースと非常に多くの alt/loop フレームを使用することになり、努力する価値がありません。
理論的には可能かもしれませんが、この詳細レベルで図を実際に使用した人はいますか? もしそうなら、あなたは例を提供できますか？
私は同じ問題を抱えていますが、低レベルになっていることに気付いたら、これを読み直します。
1 つのユース ケース内で複数のオブジェクトの動作を調べたい場合は、シーケンス図を使用する必要があります。シーケンス図は、オブジェクト間のコラボレーションを示すのに適しています。彼らは行動を正確に定義するのが苦手です。
1 つのオブジェクトの動作を多くのユース ケースで確認したい場合は、状態図を使用します。多数のユース ケースまたは多数のスレッドにわたる動作を調べたい場合は、 アクティビティ図を検討してください。
複数の代替相互作用をすばやく探索したい場合は、多くの描画と消去を回避できるCRC カードを使用したほうがよい場合があります。多くの場合、CRC カード セッションを行って設計の代替案を検討し、シーケンス図を使用して、後で参照したい相互作用をキャプチャすると便利です。
[ Martin Fowler のUML Distilled本からの抜粋]
それはすべて相対的です。ダイアグラムを作成するときは、収穫逓減の法則が常に適用されます。オブジェクト間の相互作用を示すのは良いことだと思います (objectA が objectB を初期化し、それに対してメソッド foo を呼び出します)。しかし、関数の内部を示すのは実際的ではありません。その点で、コードと同じ深さでロジックを捉えるシーケンス図は実用的ではありません。複雑なロジックについては、フローチャートを使用することをお勧めします。
考慮すべき問題は 2 つあると思います。
シーケンス図は、単一の具体的なシナリオ (ユース ケースなど) を伝えるために使用される場合に最適です。
それらを使用して複数のシナリオを描写すると、通常はユースケースのすべての可能なパスで何が起こるかを示すために、それらはすぐに複雑になります。
ソース コードは、この点でユース ケースのようなものなので (つまり、特定の説明ではなく一般的な説明)、シーケンス図は適切ではありません。あるメソッドのコール グラフを x レベルに展開し、すべての if & ループ条件を含むすべての情報を 1 つの図に表示することを想像してみてください。
だからこそ、おっしゃる「本質を捉える」ことがとても大切です。
シーケンス図は A4/レター 1 ページに収まるのが理想的ですが、これより大きくなると図が扱いにくくなります。おそらく経験則として、オブジェクトの数を 6 ～ 10 に制限し、呼び出しの数を 10 ～ 25 に制限します。
シーケンス図は、内部処理ではなく、コミュニケーションを強調するためのものです。
発生する通信 (関係者、非同期、同期、即時、遅延、シグナル、呼び出しなど) を指定することに関しては非常に表現力がありますが、内部処理 (実際にはアクションのみ) に関してはそうではありません。
また、変数を使用できますが、完全にはほど遠いです。一番上のオブジェクトは、まあ、オブジェクトです。それらを変数と見なすこともできます (つまり、それらの名前を変数として使用します) が、あまり便利ではありません。
たとえば、ある要素とその前の要素を把握しておく必要がある連結リストのトラバーサルを、シーケンス図で表現してみてください。「current」と「previous」という 2 つの「変数」オブジェクトを使用し、必要なアクションを追加して current=current.next および previous=current にすることもできますが、結果は厄介です。
個人的には、シーケンス図は、異なるオブジェクト間の一般的な相互作用の説明、つまり簡単な「一時的な相互作用のスケッチ」としてのみ使用してきました。もっと深く掘り下げようとすると、すぐにすべてが混乱し始めました...
最良の妥協点は、「単純化された」シーケンス図と、その下にあるロジックの明確で詳細な説明が続くことであることがわかりました。
答えはノーです。ソース コードよりもうまくキャプチャできます。少なくともいくつかの側面では。詳しく説明しましょう。
あなたは、私を含む大多数のプログラマーと同じように、ソース コード行で考えます。しかし、ソフトウェアの最終製品 (システムと呼びましょう) は、それ以上のものです。チームメンバーの心の中にのみ存在します。より良いケースでは、紙またはその他の文書化された形式でも存在します。
システムを記述するための標準的な「ビュー」がたくさんあります。UML クラス図、UML アクティビティ図などと同様に、各図は別の視点からシステムを示します。静的ビュー、動的ビューがありますが、アーキテクチャ/ソフトウェア ドキュメントでは、そこで止まる必要はありません。展開ビュー、パフォーマンス ビュー、使いやすさビュー、会社の価値観ビュー、上司のお気に入りビューなど、独自の言葉で非標準ビューを提示できます。各ビューは、システムの特定のプロパティをキャプチャして文書化します。
ソース コードは 1 つのビューにすぎないことを認識することは非常に重要です。ただし、コンピューター プログラムを生成するために必要なため、最も重要です。ただし、システムのすべての情報が含まれているわけではなく、明示的または暗黙的に含まれているわけでもありません。(たとえば、オフラインのユーザー アクティビティを介してのみ接続される、プログラム モジュール間の共有データ。ソースにトレースはありません)。それはただの静的ビューであり、プロセス、つまり生きている呼吸プログラムの実行時ダイナミクスを理解するのにほとんど役立ちません。
オブザーバー パターンの典型的な例です。特に多用すると、ソースコードからシステムの仕組みをほとんど理解できなくなります。そのため、その場合はシーケンス図を使用します。システムの「動的ロジック」をソース コードよりもはるかによく捉えます。
しかし、ある種のビジネス ロジックを非常に詳細に意味する場合は、プレーン テキスト/ソース コード/疑似コードなどを使用する方が適切です。UML ダイアグラムが標準だからといって、UML ダイアグラムを使用する必要はありません。ユースケース図を描かなくても、ユースケース モデリングを使用できます。自分と目的に最適なビューを常に選択してください。
UML ダイアグラムはガイドラインであり、厳密なルールではありません。
ソースコードのように正確かつ詳細にする必要はありませんが、必要に応じて試してみてください。
システムの詳細や複雑さのために、またはそれを行う時間や詳細がないために、それを実行できる場合もあれば、不可能な場合もあります。
乾杯。
PD 猫用のチーズバーガーまたはマグロフィッシュバーガーはありますか?