UMLクラス図では、境界クラス、制御クラス、およびエンティティクラスとは何ですか？

Question 1

現在、選択のIDEとしてNetBeansを使用しており、UMLモデリング用のプラグインがあります。クラス図では、存在として知られているモデル要素はBoundary Class、Control Class、およびEntity Class。しかし、それらの適切な定義を見つけることはできませんが、UMLクラス図でこのサイトを見つけました。

Question 2

多くの場合、OOADおよびビジネスモデリングとともに/その一部として使用されます。Neilによる定義は正しいですが、基本的にMVCと同じですが、ビジネスのために抽象化されています。「良い要約」はよくできているので、ここではコピーしません。これは私の仕事ではなく、より詳細ですが、ニールの箇条書きに沿ったものです。

良い要約-概念：エンティティ-制御-境界パターン

OOAD

Question 3

堅牢性図は、ユースケースの後、クラス図の前に作成されます。これらは、ユースケースステップの役割を特定するのに役立ちます。これらを使用して、構築しているシステムの使用要件を表すのに十分な堅牢性をユースケースで確保できます。

それらは以下を含みます：

俳優
ユースケース
エンティティ
境界
コントロール

一方、モデル・ビュー・コントローラ・パターンは、ユーザインターフェースのために使用される、エンティティ制御境界パターン（ECB）は、システムのために使用されます。ECBの次の側面は、それが役立つ場合は、MVCの抽象バージョンに例えることができます。

UML表記

エンティティ （モデル）
システムデータを表すオブジェクト。多くの場合、ドメインモデルからのものです。

境界 （ビュー/サービスコラボレーター）
システムアクター（ユーザーや外部サービスなど）とインターフェイスするオブジェクト。ウィンドウ、画面、メニューは、ユーザーとやり取りする境界の例です。

コントロール （コントローラー）
境界とエンティティの間を仲介するオブジェクト。これらは、境界要素とエンティティ要素の間の接着剤として機能し、さまざまな要素とそれらの相互作用を管理するために必要なロジックを実装します。デザイン内にオブジェクト以外のものとしてコントローラーを実装することを決定する可能性があることを理解することが重要です。多くのコントローラーは、たとえばエンティティまたは境界クラスのメソッドとして実装できるほど単純です。

彼らのコミュニケーションには4つのルールが適用されます。

アクターは境界オブジェクトとのみ話すことができます。
境界オブジェクトは、コントローラーとアクターとのみ通信できます。
エンティティオブジェクトは、コントローラーとのみ通信できます。
コントローラーは、境界オブジェクトやエンティティオブジェクト、および他のコントローラーと通信できますが、アクターとは通信できません。

許可された通信：

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X

Question 4

これらは、分析で使用されるクラスステレオタイプです。

境界クラスは、システムの境界にあるクラスです-あなたまたは他のシステムが相互作用するクラス
エンティティクラスクラスは、「個人」や「銀行口座」などの一般的なビジネスエンティティです。
制御クラスは、いくつかのビジネスロジックまたはその他を実装します

Question 5

境界制御エンティティパターンには2つのバージョンがあります。
-127で説明されている古い構造（データモデル要素としてのエンティティ、関数としての制御、アプリケーションインターフェイスとしての境界）
-新しいオブジェクトパターンオブジェクトパターン

として：
-境界は "のインターフェイスです"他の世界」
-任意の内部ロジックでの制御（DDDパターンのサービスなど）
-エンティティは、オブジェクトの永続性サービス（DDDパターンのリポジトリなど）です。
すべてのクラスには操作があります（ファウラー貧血ドメインモデルのアンチパターンを参照）
。これらはすべて、MVCパターンのモデルコンポーネントです。ルール：
-境界のみが「他の世界」にサービスを提供します
-境界はControllにのみ
呼び出すことができます-Controlは誰にでも呼び出すことができます
-エンティティは誰にも呼び出すことはできず（！）、呼び出されるだけです。

jz

Question 6

実際、ロバストネス図（または分析図と呼ばれることもあります）は、特殊なクラス図にすぎません。それらはUMLの一部であり、最初からあります（Jacobsonの本、Unified Software Development Process-「ThreeAmigos」シリーズの本の一部を参照）。前述の本には、183〜185ページのこれら3つのクラスの適切な定義があります。