質問

私は通常UMLと混同されますが、この状況も変わりません。 IAnimal、Food、Catクラスのインターフェースがあるとします:

interface IAnimal {
    void Feed(Food food);
}

class Cat : IAnimal {
    void Feed(Food food) {
        //code
    }
}

これら3つの要素のUMLクラス図の描画について3つの質問があります:

  • IAnimalとFoodまたはCatとFoodの関連付けを使用する必要があると思います。アソシエーションラインの片側に矢印がある場合、ある場合は、どちら側に、なぜそこにあるのですか?

  • Feedを図のIAnimalメソッドとして記述する場合、Catクラス内にメソッドFeedを記述する必要がありますか、それとも追加のCatメソッドのみを記述しますか?

  • 最も重要なのは、IAnimalとFood、CatとFood、またはその両方の関連付けを行うべきかどうかです。

役に立ちましたか?

解決

UMLは、多数の関係タイプを定義します。

関係にはさまざまな表記法があります:

  • 関連付けリレーションシップには、ソリッドパスの基本表記があります
  • 依存関係には破線矢印の基本表記があります
  • 一般化関係には、三角形の矢印の付いた実線の基本表記法があります
  • 実現関係には、三角形の矢印の付いた破線矢印の基本表記(依存関係と一般化の組み合わせ)があります

図解

+---------------------------+
|       <<interface>>       |
|           IAnimal         |
+---------------------------+                        +--------+
| + Feed(food: Food) : void |- - - - <<use>> - - - ->|  Food  |
+---------------------------+                        +--------+
              ^
             /_\
              |

              |

              |
        +-----------+
        |    Cat    |
        +-----------+

つまり:

  • IAnimal Food の関係は、使用の関係です。 これは、ステレオタイプ&#171; use&#187;の依存関係として示されています
  • IAnimal Cat の関係は、実現関係です。

関連付け関係は、2つ以上の分類子間の接続を示すために使用されます。これは、少なくとも1つのクラスに他のタイプ(またはコレクション)の属性があることを意味します。実際、属性と関連付けの終了には同じ情報が含まれており、交換することができます。

だから、私見、あなたが説明する関係は、関連としてモデル化されるべきではありません。

他のヒント

クラス図を想定すると、「使用」が必要です。 IAnimalとFoodの関連付け、および「is a」猫とIAnimalと犬とIAnimalの関連付け:

    IAnimal ----> Food
     ^   ^
    //   \\
   //     \\
 Cat      Dog

この種のものに対するあなたのうるささは、そもそもUMLの使用目的に大きく依存します。

UMLからコードへの気まぐれなトランスレーターがある場合は、気を配る必要があります(ただし、ボックスや線よりもコードに慣れているように見えますが、なぜこのようなツールを使用するのですか? )

単にUMLを使用して他の人と通信する場合は、多少うるさくなくてもかまいません。

Craig Larmanの「UMLとパターンの適用」ホワイトボードにスケッチされているように見える図を含めることで、この点を強調しています。この種の図では、UML標準が点線であると言う実線は問題ありません。矢印などがあります。

行が IAnimal から Food に移動することは明らかです。

矢じりが明快さを追加するかどうか(人間の読者にとって)は選択の問題ですが、単方向の関係を示します:

からこの紹介部分

  

&quot;単方向の関連付けでは、2   クラスは関連していますが、1つだけです   クラスは関係を知っている   存在します。&quot;

IAnimalは代謝されるのでHAVE-Aフードがあると主張しますが、HAS-Aを本当に表示したい場合は、凝集(オープンダイアモンド)または構成シンボル(ダイアモンドで塗りつぶし)にする必要があります。カスケード削除特性に応じて。

Martin Fowlerによると、UMLには2つの考え方があります。ホワイトボードや奇妙な紙の表記を使用して、アイデアを仲間の開発者に十分に伝える「スケッチャー」がいます。

次に、設計の最後の詳細をすべてキャプチャする必要があるエンジニアリング図面としてUMLを見る人がいます。

私は元キャンプにしっかりといます。元エンジニアとして、UMLにはソフトウェア設計を完全にキャプチャする実際のエンジニアリング図面の力がないことを個人的な経験からお伝えできます。

後者を信じている場合は、UMLを使用して完全なデスクトップまたはWeb UIデザインを行い、ここに投稿してください。

1)インターフェイスIAnimalとタイプFoodの間に関連付けを記述しないでください。関連付けは、タイプをクラス内のプロパティに接続するためにのみ使用されます。 E.G

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

次に、これら2つのタイプ間の接続を示す関連付けを記述する必要があります。

代わりに描画する必要があるのは、インターフェイスIAnimalがFoodタイプに依存することを示す依存関係です。依存関係は上の図の関連付けと同じように描かれ、直線を点線に変更するだけです。

2)いいえ、これらのメソッドを記述せず、依存関係を記述しません。 Interface IAnimalのみにすべての表記を残します

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top