25

プロジェクトのドキュメント用に JSF アプリケーションのクラス図を描く必要があります。そのため、管理対象の Bean として多くのクラスがあり、多くの属性があるため、多くのゲッターとセッターがあります。

クラス ダイアグラムを描画するときに、ゲッターとセッターも図に含める必要がありますか?

4

5 に答える 5

20

それらを含めるのは適切ではありません。アクセサーメソッドを示す1行を追加するだけです

于 2011-03-09T06:24:46.450 に答える
7

ゲッターとセッターを含めるのは悪い考えです。クラスの属性/プロパティセクションに既に表示されている情報を複製するために、「不動産」を浪費しています。

他の回答は、UML図がJavaゲッターとセッターの「異常な」可視性、またはゲッターとセッターの「特別な」動作を文書化する必要があることを示唆しています。

場合によっては正当化できると思います。しかし、私は次のように反論します。

  • UML ダイアグラムはすべてを示す必要はありません。大事なことだけ。実際、優れた UML ダイアグラムの兆候の 1 つは、重要でないものでごちゃごちゃしていないことです。したがって、これらの詳細は、本当に重要な場合にのみ含める必要があります。

  • 抽象化境界の詳細は、通常、設計の関心事ではありません。Java プログラマーは、必要に応じて抽象化/カプセル化を実装する方法の基本を知っている必要があります。さらに、プログラマーは、「多孔性の」抽象化境界が必要な状況について、より優れた洞察を得る可能性が高くなります。たとえば、パフォーマンス上の理由からです。(UML はそのようなことを表現するようには設計されていません。)

  • 通常、フィールドとメソッドの正確な動作は、UML 設計ドキュメントでは考慮されません。(デザイナーが OCL でメソッドの事前条件、事後条件、および不変条件を指定する長さまで行く場合を除きます!) ただし、UML ダイアグラムで、フィールドが決して にならないこと、またはフィールドを取得するとカウンターがインクリメントされることを示す必要がnullある場合は、フィールドのコメント (または OCL 制約) としてそれを記述できるはずです。

最後に、UML 図はソフトウェアの唯一の技術文書であってはなりません。javadocs は、メソッドとフィールドのアクセス修飾子/可視性を自動的に文書化します。同様に、プログラマーが文書化が必要な「特別な」動作を伴う getter および setter を実装している場合は、これを javadoc コメントで説明する必要があります。

于 2011-03-09T06:45:14.437 に答える
3

null チェックなどの特別な処理を行うまで、ゲッターとセッターをダイアグラムに含めないでください。しかし、それは悪い設計の兆候であるため、一般的な答えは「いいえ、すべきではありません」です。

于 2011-03-09T06:49:26.060 に答える
0

UML はかなり非公式な表記法です。最初に、プロジェクトまたは組織で使用するルールを設定するのが最善です。たとえば、通常は getter と setter を非表示にしますが、すべての詳細を表示することが重要な場合もあります。ルールは次のようになります。

プロパティがプライベート変数と、同じ可視性を持つ getter と setter のペアで実装されている場合は、この可視性を持つプロパティを作成するだけです。

プロパティがプライベート変数で実装されているが、パブリック ゲッターと保護されたセッターなど、ゲッターとセッターが異なる可視性を持っている場合は、モデルでゲッターとセッターを表示することをお勧めします。

そして息子...

于 2017-01-12T11:23:15.363 に答える