UMLを使用したJava EEアーキテクチャ／デザイン
今日の大部分のアプリケーションは反復的な手法で開発されます。要件が次第に明確になっていくにつれて、システムは徐々に大きくなっていきます。そのようなシステムの中核はイテレーションによって進化していく高レベルのデザインとアーキテクチャです。開発チームと保守チームのためにデザインとアーキテクチャをテキスト形式とビジュアルな形式の両方でドキュメント化する必要があります。ビジュアル表現はとても効果的であり、開発者たちが実行時の相互作用とコンパイル時の依存関係を理解するための助けになります。
UMLは複雑なエンタープライズシステムのアーキテクチャと詳細デザインのモデリングと視覚化に用いられるグラフィカルな言語で、OMG（Object Management Group）によって開発された仕様を基礎にしています。ここではObject Management Group－UMLから入手できるUML 2.0の表記法（最新バージョン）を使用します。ただし、UMLはアーキテクチャとデザインだけでなく、ソフトウェア開発のすべてのフェーズで使用できます。UMLにはクラスとオブジェクトおよび種々の関係と相互作用を表現する豊富な表記群が用意されています。今日のUMLモデリングツール（IBM Rational XDE、Visual Paradigm、Sparx Systems Enterprise Architectなど）では、システムデザイン時にデザインパターンとベストプラクティスを適用できます。これらのツールでは、デザインモデルを使ってアプリケーションソースコードのかなりの部分を生成することもできます。
UML図は何種類もあります。しかし、ここではJava EEデザインパターンを分析するために、主としてクラス図とシーケンス図ならびに「ステレオタイプ」と呼ばれる単純な拡張メカニズムを使用します。UMLに不慣れな方やUMLについて詳しく知りたい方は『UML Distilled Third Edition』（Martin Fowler著、Addison Wesley刊、2005年）などの書籍がお勧めです。
クラス図
クラス図はシステム内の一群のクラスとインターフェースの間の静的な関係を表現するためのものです。ここで取り上げる関係は汎化と集約と継承です。図8は保険金請求の詳細を表現するためのクラスのUML表記法を示しています。この図は3つ区画から成る長方形で表現されています。最初の区画はクラスの名前です。2番目の区画はクラス内の属性を表し、最後の区画はこれらの属性に関して定義された操作を表します。属性名とメソッド名の前に付いている+記号と-記号に注意してください。これの記号は可視性を表すものです。+記号はパブリックな可視性を表し、-記号はプライベートな可視性、すなわち当該の属性がこのクラスの外部からアクセスできないことを表します。またオプションで属性、メソッド戻り値、およびパラメータのデータ型を表せることにも注意してください。
インターフェースは実装が履行しなければならない契約を定めます。言い換えると、インターフェースを実装するクラスが一群の保証付き動作を提供するということです。インターフェースはクラスと同じ長方形で表現されますが、ある相違点があります。一番上の区画がステレオタイプ＜＜interface＞＞で拡張されたクラス名を表すのです。ステレオタイプは既存の表記法を拡張するためのメカニズムです。UMLツールによってはメソッドの明示的な記載のない円でインターフェースを表現するものもあります。図9に2種類の形式を示します。
関係
以下ではソフトウェアシステム内のクラス間に存在する重要な関係について説明します。
汎化
「汎化」関係は2つ以上のクラス間の継承を示すものです。これは親子関係です。子は親の動作と属性の一部または全部を継承します。子が親の動作と属性の一部をオーバーライドすることもできます。図10に汎化関係を示します。
関連
「関連」は2つのクラスの間の一般的な関係を示すものです。実際のクラスでは、この関係は一方のクラスが他方のクラスのインスタンスを保持しているものとして示されます。保険証書には常に1つ以上の当事者が存在し、その最たるものがこの証書を所有する保険契約者です。保険契約者の証書記載を助ける代理人が存在することもあります。関連では関係を詳しく記述するために役割とカーディナリティ（基数）と制約を示すことがよくあります（図11を参照）。
集約
「集約」は関連の一種であり、ある要素が他の小さな構成要素から成るというものです。この関係はダイヤ形の白い矢じりで表現されます。この場合、親オブジェクトが削除されても子オブジェクトは存続できます。図12は保険代理人と彼が勤務している保険会社の営業所との間の集約関係を示しています。営業所は代理人が保険証書への署名や顧客の保険料の預託といった業務を遂行する場所です。そのため、たとえその営業所が閉鎖されても、代理人は別の営業所に出勤できます。同様に、代理人はある営業所への登録を抹消して、同じ保険会社の別の営業所に移ることもできます。
コンポジション
「コンポジション」は、より強い形の集約です。この場合、親が削除されると子も存在しなくなります。この関係はダイヤ形の黒い矢じりで表現されます。図13は、保険証書または保険金請求の当事者とその当事者の住所との間のコンポジション関係を示しています。その当事者がシステムから削除されれば、そのアドレスも削除されます。
シーケンス図
「シーケンス図」は、ある期間にわたるシステム内のオブジェクト間のメッセージ交換を表現することでシステムの動的な面をモデル化するのに使われます。シーケンス図は特定のユースケースを満たすためにオブジェクト間で行われるやりとりのシーケンスを示すのに使われます。クラス図がアプリケーションの全体的なドメインモデルを表現するのに対し、シーケンス図では特定のプロセスのやりとりの詳細を示すことができます。
オブジェクトとメッセージ
シーケンス図において、オブジェクトは長方形で囲まれた下線付きの名前で表現されます。メッセージは一方のオブジェクトを起点として他方のオブジェクトを終点とする矢印で表現されます。オブジェクトは自分自身に対してメソッドを呼び出すことができます。これは再帰メッセージであり、起点も終点も同じオブジェクトにある矢印で表現されます（図14を参照）。
ライフライン
それぞれのオブジェクトには「ライフライン」があり、これはオブジェクトの長方形から下に引かれた破線で表現されます（図14を参照）。これはシーケンス図全体の時間軸を示すものであり、ライフラインに沿った下方への距離が経過時間を表します。
戻り値
シーケンス図におけるメッセージはオプションで「戻り値」を持つことができます（図15を参照）。例えば、createNewPolicyメッセージはPolicyDetailオブジェクトを返します。
まとめ
分散多層アプリケーションを開発するのは大変な仕事です。Java EEプラットフォームはコンテナベースのアーキテクチャを定義することで、この仕事を単純化してくれるように見えます。Java EEプラットフォームはアプリケーションコードの実行環境と提供すべき低レベルのシステムサービスの仕様を定義します。そのため、アプリケーション開発者はビジネスロジックを記述することに専念できます。Java EEアプリケーションアーキテクチャはコアプラットフォームアーキテクチャと確立されたMVC原則をベースにしています。例えば、アプリケーションのプレゼンテーションレイヤはWeb層に置かれ、ビジネスレイヤとデータアクセスレイヤは一般にアプリケーションサーバ層に置かれます。
それに対し、Java EEデザインは拡張されたオブジェクトデザインです。Java EEデザインパターンカタログは、オブジェクトならびにレイヤと層の内部／間でのオブジェクト対話を構成する際のガイドラインとベストプラクティスを提供します。このデザインパターンカタログには、優れたJava EEアプリケーションを供給してきたデザイナと開発者の長年の経験がドキュメント化されています。Java EEのデザインとアーキテクチャはUML表記法を使ってドキュメント化できます。これらはグラフィカルな表記法であり、ドメインオブジェクトの静的な構造と動的な相互作用を視覚的に把握するのに役立ちます。
