4

クラス図に関する講義では、エレベーター システムでの関係を説明する次のスライドが表示されました。

エレベーターシステム

講義では、黒い頭の矢印を「複合集約」関係と呼びました。これは、子が親から独立して存在できないことを意味します。

このエレベーター システムの例では、Motor オブジェクトは Elevator オブジェクトの外側では無関係です。

私が理解していないのは、複合集計がコード自体にどのように表示されるかです。Elevator に「myMotor」プロパティがあることを期待していますが、ありません。

この関係を描くことで、プログラマーにそれを実装する必要があることを伝えますが、実装の詳細はプログラマーが選択する必要があるためでしょうか?

明示的に記述された親オブジェクトのプロパティ (エレベーターの isActive ブール プロパティなど) とは対照的に?

4

3 に答える 3

1

UML は、非常に概念的な設計ツールとして、またはより具体的なプログラミング設計ツールとして、いくつかの方法で使用できます。

そのため、複合集計を表す場合、いくつかの方法で表すことができます。

  • クラスのすべてのメンバーを表示したい場合があります。メンバーが多すぎると悪い。
    + --------------------------+
    | | エレベーター クラス |
    + --------------------------+
    | | [+] ブール値: isActive |
    | | [+] ブール値: isInOrder |
    | | [+] フロア: 場所 |
    | | [+] MotorClass: モーター |
    | | [+] DoorClass: ドア |
    + --------------------------+
    | | [+] startOperation() |
    | | [+] stopOperation() |
    | | [+] gooUp() |
    | | [+] gooDown() |
    | | [+] openDoor() |
    | | [+] closeDoor() |
    + --------------------------+
  • クラスのすべてのメンバーを非表示にしたい場合があります。メンバーではなく、クラスに集中したい場合に適しています。注: これは、あなたが今探しているケースかもしれません。
    +--------------------------+1 1+------------------- -------+
    | | ElevatorClass |------<*>| RescueButton クラス |
    +---------------------+ +--------------------- ------+
  • クラスの一部のメンバーを表示し、別のメンバーを非表示にしたい場合があります。
    +--------------------------+ 1 1 +------------------- -------+
    | | ElevatorClass |------<*>| モーター ボタン クラス |
    +---------------------+ +--------------------- ------+
    | | [+] ブール値: isActive |
    | | [+] ブール値: isInOrder |
    | | [+] フロア: 場所 |
    | | [+] MotorClass: モーター |
    | | [+] DoorClass: ドア |
    + --------------------------+

物事を少し複雑にするために、モーターは他の要素と同様に、必ずしもエレベータ クラスの参照メンバーによって参照される必要はありません。

例 (c スタイル):

class ElevatorClass {
public:
  List<ComponentClass*> Components;

  ...

  void AddComponent(ComponentClass* ThisComponent);
} // class ElevatorClass

...

MyElevator.AddComponent(MyMotor);

前のコード例では、メンバーは直接参照されていません。

個人的には、これは非常に明確であることに同意します。

class ElevatorClass {
public:
  MotorClass* Motor;
  MotorClass* Motor;
} // class ElevatorClass

乾杯。

于 2013-10-31T18:39:39.467 に答える
0

あなたの仮定は正しいです-UML関係は実装の詳細を指定していません。コンポジションの場合、要件は、Motorオブジェクトの有効期間が含まれているオブジェクトの有効期間に制限されていることElevatorです。これは、いくつかの方法で実現できます (使用する言語にも依存します)。内のプロパティにすることができElevator、この場合、含まれている とともに自動的に破棄されElevatorます。一方、それは、包含Elevatorオブジェクトの存続期間中に手動でインスタンス化および解放される外部オブジェクトである可能性があります。実装は、特定のケースと、単純さ、柔軟性、モジュール性などの追加の設計上の考慮事項に依存します。

ダイアグラムに追加できる詳細は多数あります。図の作成者は、何を含め、何を省略するかを検討する必要があります。たとえば、プライベート プロパティは通常、実装の詳細に関連しており、クラス ダイアグラムにとって重要ではないため、言及されません。明示的に言及されたプロパティは、それを含むオブジェクトとプロパティの間の合成関係を意味します。このような概念は、通常、boolean、int などのプリミティブ プロパティに使用されます。より複雑なプロパティの場合、オブジェクト間の関係 ( と の間ElevatorなどMotor) を表すために、通常、明示的な UML 関係が使用されます。

于 2013-10-31T19:13:51.743 に答える
0

複合集約 (構成とも呼ばれます) の場合、通常、これは親子関係を示します。あなたの例では、コード内の Elevator オブジェクトには、1 つの Motor オブジェクトのみへの参照が含まれます。これは、それをよりよく説明する可能性のあるブログ投稿へのリンクです。構成セクションを探します。

http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

この表現は、おそらく StopRequest を除いて、描かれているすべてのオブジェクトにとって意味があると思います。個人的には、これを Elevator オブジェクトのコンポジションとは考えていませんでしたが、UML は正確な科学ではないことを思い出してください。

于 2013-10-31T17:11:48.510 に答える