クラスの動作があるメソッドから別のメソッドにどのように流れるかを示すときに使用するのに最適なUMLダイアグラムタイプは何ですか?
私は既存のコードを図解しようとしています。私が見ている動作には、主にプライベートメソッドの呼び出しが含まれ、クラス外の静的オブジェクトへの呼び出しがいくつかあります。問題のクラスは、前述のごくわずかな静的呼び出しを除いて他のクラスと相互作用しないため、この場合、シーケンス図で最も詳細な情報が得られるとは思いません。
この状況に最適なものは何ですか?
クラスの動作があるメソッドから別のメソッドにどのように流れるかを示すときに使用するのに最適なUMLダイアグラムタイプは何ですか?
私は既存のコードを図解しようとしています。私が見ている動作には、主にプライベートメソッドの呼び出しが含まれ、クラス外の静的オブジェクトへの呼び出しがいくつかあります。問題のクラスは、前述のごくわずかな静的呼び出しを除いて他のクラスと相互作用しないため、この場合、シーケンス図で最も詳細な情報が得られるとは思いません。
この状況に最適なものは何ですか?
UMLスーパーストラクチャー(http://www.omg.org/spec/UML)によると、UMLには、緊急動作と実行動作の2種類の動作が存在します。
実行動作はオブジェクト(そのホスト)によって実行され、このオブジェクトの動作の説明です。実行動作は、そのオブジェクトの動作機能の呼び出しまたはその作成によって直接引き起こされます。いずれの場合も、関連するオブジェクトによるアクションの実行の結果です。ビヘイビアは、そのホストオブジェクトの構造的特徴にアクセスできます。ビヘイビアーをホストする可能性のあるオブジェクトは、BehavioredClassifierメタクラスの具象サブタイプによって指定されます。創発的な動作は、1つ以上の参加者オブジェクトの相互作用から生じます。参加しているオブジェクトがより大きな複合オブジェクトの一部である場合、新しい動作は、コンテナオブジェクトの動作も間接的に記述していると見なすことができます。それにもかかわらず、緊急の動作は、参加者オブジェクトの実行動作から生じる可能性があります。
アクティビティまたはインタラクションを使用して動作をモデル化できます(実際には、ステートマシンやユースケースを使用することもできます)。アクティビティはモデルの実行動作により適応し、インタラクションは緊急の動作をモデル化します。
これで、クラスに多くの部分があり、モデル化する動作がその部分の「複雑な」相互作用で構成されている場合、おそらく相互作用図(シーケンス)が正しい選択である可能性があります。それ以外の場合、モデル化する必要のある動作が一連のアトミックアクションで構成されている場合は、アクティビティの方が適している可能性があります。UMLには、専用アクション(ReadSelfAction)を使用して取得できるオブジェクト参照を入力ピンとして受け取るメソッド(CallOperationAction)の呼び出しを表す特定のアクションがあることを考慮してください。オブジェクト属性を読み取るアクション(ReadStructuralFeatureAction)もあります。また、実行可能なUMLモデルの基礎(FUML)http://www.omg.org/spec/FUMLも確認してください。
これまでの答えはすべて正しいですが、ステートマシンを使用してクラスの動作を定義するオプションを追加したいと思います。ステートマシンを使用すると、クラスの現在の状態と、メソッドが呼び出されたりイベントが受信されたりしたときにクラスの状態がどのように変化するかを示すことができます。ほとんどの場合、1つのクラスをモデル化していると述べているので、現在の状態と、これらのメソッド呼び出しがクラスの状態にどのように影響するかに応じて、何ができるか(どのメソッド呼び出しを呼び出すことができるか)を示すことが最も重要だと思います。ステートマシンについて私が本当に気に入っているのは、セマンティクスが比較的明確に定義されており、複合状態と直交状態を使用してさまざまなレベルで情報を表示する方法があることです。
大まかに2つの選択肢があります(@Silliの回答による):シーケンス図またはアクティビティ図。私はおそらく最初の選択肢としてシーケンス診断を提案したでしょうが、あなたはそれが適切でないと思うと言います。理由を詳しく教えていただけますか?
おそらくそれは条件付きロジックですか?もしそうなら、アクティビティ図がより良い選択かもしれません。シーケンス図よりも制御フローを表示するためのより直感的な構文があります。静的オブジェクトを別々のスイムレーンに表示することもできます。これにより、外部オブジェクトへの呼び出しを明確に区別できます。自分に関係がある場合は、並列動作を説明することもできます。それが役立つなら、ここにいくつかの良い例があります。
hth。
コラボレーション図(UML 1.x)の名前をコミュニケーション図(UML 2.x)に変更することをお勧めします。これはシーケンス図よりも優れている可能性があります。これは、ケースの方が読みやすいためです。
通信図は、シーケンスされたメッセージの観点からオブジェクトまたはパーツ間の相互作用をモデル化します。通信図は、システムの静的構造と動的動作の両方を説明するクラス、シーケンス、およびユースケース図から取得した情報の組み合わせを表します。