ガイドライン: J2EE アプリケーションに対する実装モデルの構成

トピック

概論 To top of page

ここでは、『概念: J2EE の概要: Enterprise JavaBeans』と『概念: 設計のコードへのマッピング』で説明するテクノロジー・プラットフォームとしての J2EE に関する一般的な情報を、ユーザーが理解していると仮定しています。 ユーザーがこのガイドラインを UML 1.3 ベースのプラグインのコンテキストで使用している可能性もありますが、このガイドラインでの概念のいくつかは UML 1.4 に属しています。何かわからないことがある場合は、2 つの UML 仕様でそれがどのように説明されているかを確認してください。

実装モデルの構成 To top of page

作業: 実装モデルの構成』は、設計モデルの構造と密接に関連した実装モデルの構造を組み立てる方法を記述しますが、その一方で、開発環境の制約を反映し、並列開発や段階的な統合もサポートしています。

J2EE アプリケーションに対する実装モデル構造は、開発環境と実装環境に依存します。しかし、通常は、J2EE 実装モデル内には次に示す 4 つの潜在的な構造があります。

  • 導入サポート (J2EE モジュールと配置記述子)
  • 仮想ディレクトリー構造 (JSP、HTML ページ)
  • Web サーバー上で導入された要素に対する Java ディレクトリー (サーブレット、JavaBeans)
  • EJB アプリケーション・サーバー上で導入された要素に対する Java ディレクトリー (EJB)

実装サブシステムのモデリング To top of page

成果物: ソフトウェア・アーキテクチャー説明書』の実装ビューは、実装モデルの高レベルの概要を示します。これには実装サブシステムの識別も含まれます。J2EE アプリケーションでは、実装サブシステムは、ファイル・システムの単一のディレクトリーまたはモデルの単一のパッケージにはマップしないことがあります。これは、実装サブシステムは、1 つのモデル (JSP、HTML ページなど) からの Java ではない要素と、別のモデルからの Java 要素を含む可能性があるためです。 これに対処する戦略の 1 つは、各モデルで並行パッケージ構造を持つことです。各モデルで同じ名前のパッケージは、暗黙的に関連付けられます。

実装サブシステムが単一の導入可能な実装ファイル (JAR、WAR、EAR ファイル) を実装するのは一般的なことです。 この場合、導入可能なファイルを識別すると、実装サブシステムが識別されることがあります。

実装ディレクトリーと実装ファイルから構成される物理要素の表現が、各実装サブシステムの内部にあることがあります。クラス、コンポーネント、 パッケージなどから構成される論理要素が存在することもあります。これらの要素は『成果物: 設計モデル』要素に対応しますが、これらはソース・コードの正確なモデル (ラウンド・トリップ・エンジニアリング・モデル) です。設計モデル実装モデルとの間の関係について詳しくは、『概念: 設計のコードへのマッピング』を参照してください。

ラウンド・トリップ・エンジニアリング・モデルは、ソース・コードの正確な表現を提供します。J2EE には、Java モデルの各パッケージが Java パッケージを表現し、各クラスが Java クラスを表現するなどの特徴があります。 しかし、ラウンド・トリップ・エンジニアリング・モデルに次のような追加情報が必要な場合が多くあります。

  • ラウンド・トリップ・エンジニアリングの一部として自動的に生成されない情報を示すダイアグラム
  • より高レベルのモデルの抽象化

設計モデルは、クラス、コンポーネント、パッケージなどを抽象化します。しかし、より高レベルの抽象化や物理的要素 (ファイルやディレクトリー) に対する追加のダイアグラムが必要な場合もあります。 これらについては、以下のセクションで説明します。

実装ディレクトリーのモデリング To top of page

ラウンド・トリップ・エンジニアリングは通常、開発環境で必要なディレクトリーのサブセットのみを処理します。テスト成果物、導入ユニット、文書などを編成するために、ディレクトリーの追加が必要になることがよくあります。 ディレクトリーはファイル・システムの一部として表示できるので、通常、モデリングは必要ありません。

実装ファイルのモデリング To top of page

ラウンド・トリップ・エンジニアリング・ツールがサポートを提供する場合や、あまり明確ではない関係を表示する必要がある場合を除いて、通常、実装ファイルはモデリングされません。

一般に、各 Java インターフェースやクラスに対して 1 つの .java ファイルがあり、各 .java ファイルに対して 1 つのコンパイル済みの .class ファイルが存在します。したがって、これらのファイルのモデリングには、あまり注意を払う必要はありません。

J2EE では、サブシステムは通常 1 つ以上のアーカイブ・ファイル (JAR、WAR 、EAR ファイル) を含みます。

アーカイブ・ファイルは、アーカイブ・ファイルからそれに含まれるファイルへのコンポジション関係として最も正確にモデリングされます。しかし、複数のコンパイルされた .class ファイルを結合して 1 つの JAR ファイルを作成する際には、JAR ファイルが最終的に実装するクラスとインターフェースへの JAR ファイルの依存関係を示したほうが便利なこともあります。

実装サブシステムが 1 つの JAR ファイルのみを生成する場合、特に実装サブシステムのすべての導入可能なファイルが JAR ファイルの一部であると仮定できる場合、一般にモデリングはまったく必要ありません。

アーカイブ・ファイルのオーバーラップ

同一の要素をいくつか含む 2 つのアーカイブ・ファイルを定義できますが、通常はお勧めできません。例えば、2 つの EAR ファイルが同一の EJB JAR をいくつか含んでいても、すべてが同一ではない可能性があります。また、2 つの EJB JAR が同一の EJB を含んでいても、配置記述子が異なることがあります。

実装サブシステムと導入可能なアーカイブ・ファイルの間の密接な対応を維持するには、アーカイブ・ファイルをオーバーラップさせないことが最もよい方法です。 しかし、オーバーラップが必要な場合は、これをオーバーラップの根拠と共にモデリングすると役立つことがあります。



Rational Unified Process   2003.06.15