web-dev-qa-db-ja.com

単一のクラス、または既存のクラスの属性/操作として検討しますか?

UP方法論でクラスを認識するためのさまざまな方法があります。

  1. 名詞/動詞分析
  2. cRC分析の使用
  3. rUPステレオタイプの使用
  4. 他の情報源

UML 2 and the Unified Process_ Practical Object-Oriented Analysis and Design (2nd Edition)-Addison-Wesley Professional (2005)の本で詳細に説明されている上記のメソッドを読みました。

定義:何かを単一のクラスまたは既存のクラスの属性と見なすことには、あいまいさがいくつかあります。

goods transportation system以下の明らかなクラスを使用します。

  1. driver
  2. システム管理者
  3. 注文
  4. お客様
  5. 等.

このシステムでは、顧客は自分の注文を運ぶドライバーの現在地を確認する必要があります。

問題は、経度や緯度などの場所をドライバーの属性(および操​​作としての機能)と見なしたり、ドライバークラスと関係のある単一のクラスと見なしたりできないことです。

質問:解決策を見つけてこの種のあいまいさを明確にする方法はありますか?

2
Mostafa Ghadimi

あなたが説明したこのRUPプロセスは [〜#〜] bduf [〜#〜] アプローチに従います。これは、「経度/緯度は2つの属性のみである必要がある」などの詳細な設計決定を行うにはあまり適していません。 、またはそれ自体がクラスになる必要があります。」.

このような設計決定を行うことができるプロセスは次のとおりです。

  • ドライバークラスの2つの属性から始める

  • 次に、implementコード内の動作の一部(たとえば、テストの使用、おそらくテスト駆動開発による)

  • 実装中に、経度/緯度のペアのみを操作する賢明な操作があることを発見した場合(それらをコピーする、異なる座標系に変換するなど、システムが必要とするものなど)、それらを別のクラスにリファクタリングします。

システムがそのような操作を必要としない場合は、属性をそのままにしておきます。

初期の「分析フェーズ」で見つかったクラスは、作業を始めるのに適しているかもしれませんが、システムに実際に必要なクラスは、「分析-少し-少し-少し実装-少しテスト-少し-リファクタリング」プロセスで見つかることがよくあります」.

したがって、賢明な設計を実現したい場合は、自分自身で賛成し、ウォーターフォールアプローチをより反復的な開発プロセスに置き換えてください。必要なフィードバックループがなければ、設計を適切に決定することはできません。

4
Doc Brown

セマンティクスは同じです。

それは図解の選択です。物事の見方や見たい方法を伝えることができます。

  • 「プロパティ」(属性のUML用語)を定義できます。 x: MyType
  • 代わりに、クラスMyTypeとの関連付けを使用して、関連付けの最後にxを表示することができます。できれば、ドット表記を使用して 所有権を表示 にしてください。
  • 多重度は、A側が1である限り、どちらの場合でも使用できます。これが当てはまらなくなったらすぐに、プロパティではなく関連付けを検討する必要があります。

上記のウェブリンクに示されているように:

クラスが所有する関連端も属性であるため、属性表記はクラスが所有する関連端に使用できます。この表記を線矢印表記と組み合わせて使用​​して、属性が関連端でもあることを完全に明確にすることができます。

表現を選択するには?

次のプラクティスがガイドとなります(ただし、これは個人的なプラクティスであり、公式の推奨ではありません)。

  • クラスのオブジェクトに独自のアイデンティティがある場合。同じオブジェクトが複数の場所から参照される場合は、常にクラスとの関連付けを使用してください。
  • クラスが複雑な動作を伴う複雑なオブジェクトである場合は、関連付けも使用します。
  • オブジェクトが単純な「値オブジェクト」である場合、つまり、一意のオブジェクトを気にせず、それらがプロパティの値の組み合わせによって完全に定義されている場合は、popertiesとして表示することをお勧めします。

別の(互換性のある)プラクティスは、ステレオタイプを使用することです «datatype» 他の図の属性に使用するクラスで、意図をより明確に伝えるため。

2
Christophe