4

私はたいてい 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、またはその両方にする必要があるかどうかです。

4

5 に答える 5

14

UML では、多数の関係タイプが定義されています。

リレーションシップには、さまざまな表記法があります。

  • アソシエーション関係には、実線の基本表記があります
  • 依存関係には破線矢印のベース表記があります
  • 汎化関係には、三角形の矢印が付いた実線パスの基本表記があります
  • 実現関係には、三角形の矢印が付いた破線の矢印の基本表記があります (依存関係と一般化の混合)。

絵画的に

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

              |

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

あれは:

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

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

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

于 2009-01-02T18:54:09.483 に答える
1

この種のものについてあなたがどれほど気難しいかは、そもそもUMLを何に使用しているかに大きく依存します。

ある種の気まぐれなUMLからコードへのトランスレーターがある場合は、慎重に扱う必要があります(ただし、ボックスや行よりもコードの方が快適なようです。なぜそのようなツールを使用するのでしょうか?)

単にUMLを使用して他の人と通信している場合は、多少うるさくする余裕があります。

CraigLarmanの「ApplyingUMLandPatterns」は、ホワイトボードにスケッチされたかのように見える図を含めることで、この点を強調しています。この種の図では、UML標準で点線で示されている実線で問題ありません。だから、鏃などで。

IAnimal行がからに移動する必要があることは私には明らかですFood

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

この紹介記事から:

「一方向の関連付けでは、2つのクラスが関連付けられていますが、関係が存在することを知っているのは1つのクラスだけです。」

于 2009-01-02T11:57:51.740 に答える
0

クラス ダイアグラムを想定すると、IAnimal と Food の間には "use" 関連付けがあり、Cat と IAnimal、Dog と IAnimal の間には "is a" 関連付けが必要です。

    IAnimal ----> Food
     ^   ^
    //   \\
   //     \\
 Cat      Dog
于 2009-01-02T11:52:56.010 に答える
0

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

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

次に、これら 2 つの型の間の接続を示す関連付けを作成する必要があります。

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

2) いいえ、それらのメソッドを作成したり、依存関係を作成したりしないでください。インターフェイス IAnimal のみにすべての表記を残す

于 2009-01-02T12:41:48.657 に答える
0

IAnimal は代謝されるので、HAVE-A Food を持つと主張しますが、本当に HAS-A を示したい場合は、集計 (白抜きのひし形) または合成記号 (ひし形で塗りつぶされた) である必要があると思います。カスケード削除の特性。

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

次に、UML を技術図面と見なす人もいます。そこでは、設計の最後の詳細をすべてキャプチャする必要があります。

しっかりと元陣営にいます。元エンジニアとしての個人的な経験から言えば、UML には、ソフトウェア設計を完全にキャプチャするための実際のエンジニアリング図面のような力はありません。

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

于 2009-01-02T13:50:15.413 に答える