トピック

概論 To top of page

このガイドラインは、『ガイドライン: 設計サブシステム』を補完する J2EE アプリケーション開発に固有のガイダンスです。以下の J2EE 固有のガイドラインを読む前に、『ガイドライン: 設計サブシステム』を読むことをお勧めします。以下のガイドラインは、個々の EJB より大きな粒度の設計サブシステムに適用されます。EJB のガイドラインについては、『ガイドライン: Enterprise Java Bean』を参照してください。

アプリケーション・クライアントが特別な設計サブシステムと見なされることにも注意してください。『ガイドライン: アプリケーション・クライアント』を参照してください。

設計サブシステムの発展To top of page

サブシステムが最初に識別された初期の段階では、サブシステムはテクノロジー中立です。つまり、インターフェース、テキストの説明、予期される操作の振る舞いを記述する状態マシンによって特定される可能性があります。しかし、そのようなテクノロジー中立なサブシステムは、一般的に、テクノロジー固有の表現に発展します。

以下に、テクノロジー中立な設計サブシステムがテクノロジー固有のサブシステムに発展する場合の例を示します。

サブシステム仕様 (サブシステムのブラック・ボックス・ビュー)

初期のサブシステム仕様は、抽象 UML インターフェースを組み込んでモデリングできます。

図 1 で示される Customer サブシステムの予備設計を考えてください。 

本文の説明に関連する図

図 1: 予備設計 - Customer サブシステム

ICustomerMgt は、「getCustomerDetails」や「setCustomerDetails」などの操作を持つようにさらに詳しく定義されています。

設計が詳細になるに従って (『作業: サブシステム設計)、これらの抽象インターフェースは言語とテクノロジーに固有の要素に置き換えられます。(例えば、複数の言語やテクノロジーで同じ設計を実装する必要がある場合は、サブシステムの抽象的なモデルを維持できます。これらのオプションについては、『概念: 設計のコードへのマッピング』を参照してください。) 対応する設計ユース・ケースの実現は、インターフェースの変更に一致するように更新されます。

この例では、図 2 は Customer サブシステムのブラック・ボックスまたは仕様ビューです。 以下の設計は、Customer サブシステムがエンティティー EJB である必要があることを示しています。予備設計サブシステムは、EJB インターフェースに以下のように変換されます。 

  • ICustomerMgt =>
    • CustomerHome ?EJBEntityHomeInterface?
  • ICustomer =>
    • Customer ?EJBRemoteInterface?

本文の説明に関連する図

図 2: Customer 設計サブシステムのブラック・ボックス・ビュー 

設計サブシステムが公開したインターフェースは、標準の Java インターフェース、EJB インターフェース (Java インターフェースなど)、EJB インターフェース (リモートとホーム)、1 つ以上の EJB の存在を完全に隠蔽する 1 つ以上の委譲またはアクセス・クラスを含む可能性があります。 Java インターフェースなどのこれらすべてのインターフェースは、UML インターフェースではなく UML クラスとしてモデリングされます (『ガイドライン: J2EE アプリケーションのインターフェース)』を参照してください。例えば、セッション Bean は、密接に関連する複数のエンティティー Bean のセットにアクセスするための Facade として多く使用されます。この場合は、セッション Bean のインターフェースのみがサブシステムからエクスポートされます。

メッセージ駆動型 Bean は、送信先 (またはエンドポイント) からメッセージを非同期的に使用します。したがって、送信先も、メッセージ駆動型 Bean を含む設計サブシステムに対して「インターフェース」としての役割を果たすことができます。

ローカル・インターフェースは、同一の設計サブシステム内で密接に結合したほかの EJB によって使用されるため、サブシステムが公開する参照可能なインターフェース内よりもサブシステムの実現内に多く出現します。

J2EE アプリケーション内のインターフェースについて詳しくは、『ガイドライン: J2EE アプリケーションのインターフェース』を参照してください。EJB のモデリングについて詳しくは、『ガイドライン: Enterprise JavaBeans』を参照してください。

サブシステムの実現 (サブシステムのホワイト・ボックス・ビュー)

設計サブシステムは、クライアントが要求するもののみを公開する必要があります。 したがって、EJB を実装するクラスは、サブシステムに対してプライベートであり、論理的にサブシステム実現の一部です。サブシステム実現は、次のようになります。

  • 1 つ以上の参照可能な委譲またはアクセス・クラスで隠蔽された、コラボレートする EJB とクラスのセット
  • コラボレートするほかのクラスがない単一の EJB

前に示した Customer サブシステムの例でいうと、サブシステムの実現には次の要素が含まれます。

  • CustomerEntityEJB (コンポーネント) ?EJBEntityBean?
  • CustomerBean ?EJBImplementation?
  • 追加のヘルパー・クラス

図 3 は、設計サブシステムのホワイト・ボックス・ビュー (つまり、サブシステムの内部) を示しています。『ガイドライン: Enterprise JavaBeans』で説明されるように EJB クラスがモデリングされることに注意してください。サブシステムのこの内部ビューは、サブシステムの実現として参照されます。このビューでは、クライアントから参照可能でない決定を見ることができます。例えば、このサブシステムの実現では、データ・アクセス・オブジェクト (DAO) クラスは、JDBC API を使用して永続データにアクセスします。(別の設計では、コンテナー管理の永続性が使用されている可能性があります。) DAO クラスについて詳しくは、『ガイドライン: Enterprise JavaBeans』を参照してください。

本文の説明に関連する図

図 3: Customer 設計サブシステムのホワイト・ボックス・ビュー



Rational Unified Process   2003.06.15