学校の登録システムにクラス図を作成する必要がある大学のプロジェクトを行っています。そこには、Studentクラス、registrationUI境界クラス、およびregistrationControllerコントローラー クラスが含まれています。
systemController請求書の計算などの他のタスクを実行するために呼び出される別のコントローラークラスを作成しました...
systemControllerクラスと一緒にクラスに参加できるかどうか尋ねていregistrationUIます。
ECB アーキテクチャ パターン
ECB アーキテクチャ パターンがユース ケースモデルに由来することを理解すると便利です。
RegistrationControlerユース ケース「学生の登録」)。コントローラーは、ユース ケースに関係するすべてのエンティティにリンクされます ( 、Registration、など、いくつかの場合がStudentありますCourse) 。RegistrationUI、登録マネージャーまたはセルフ サービス システムの場合は学生にユーザー インターフェイスを提供します)。そのため、複数の境界をコントローラーにリンクできます (たとえば、サードパーティ システムなどの二次的なアクターが関与している場合)。 Student)。したがって、エンティティは他のいくつかの関連エンティティにリンクできます (たとえば、のRegistrationレコード) 。StudentCourse整合性チェック
この記事またはその記事の最後に、エンティティ、コントロール、および境界の間の可能な関係を示す短いマトリックスが表示されます。
この論理によれば、エンティティは [境界に直接接続されるべきではありません。したがって、とAccessの関係はお勧めできません ( ECB は MVC ではありません)。 StudentRegistrationUI
1 つの境界と 2 つのコントローラー ?
ユース ケースを境界とコントローラーに分解する Jacobson の OOSE ロジックに従う場合、またはユース ケース駆動型モデリング アプローチで基本的な段階的な堅牢性分析を適用する場合は、コントローラー (ユース ケース) を特定し、それぞれの境界を作成します。アクターとユースケースの間のリンク。したがって、一見すると、境界は最大 1 つのコントローラーにリンクできると考えることができます。
ただし、「含まれる」ユースケースまたは「拡張される」ユースケースもあります。これらは、少なくともグラフィックで明示的にではなく、アクターに直接接続されていません。これは、複数のコントローラーに関連する 1 つの境界を十分に持つことができることを意味します。このチュートリアルでは、1 つの境界と複数の ATM トランザクションを含む非常に優れた ATM の例を示します。上記の DDJ 記事のリンクにも、同様の例があります。
PS: 個人的には、 で何を達成したいのかよくわかりませんsystemController。その役割と名前について考えてみることをお勧めします。その内容を見ると、の一部であることが想像できましたRegistrationController。また、他のコントローラーを起動するディスパッチャーであると想像することもできます。