Java EE上のSI向けフレームワーク

開発ツール [1] アーキテクチャーの標準化

次に、ObjectWorks＋の「設計／開発を標準化するための仕組み」について解説します。

前ページで解説したCOREは、アプリケーションを開発するための基盤としては、JSF（MVC）、EJB3（DI×AOP）、JPA（O/Rマッピング）といったJava EE 5標準フレームワーク群にSeamを組み合わせた標準スタックを採用しており、それ単体では、この上でどうアプリケーションの構造を設計するかは規定していません。開発者は、こうしたフレームワーク群の上でCOREの拡張機能群を活用し、自由にアプリケーションを設計することができます。

しかし、アプリケーションのクラス構造などを全く規定しないと、設計／開発にかかわる自由度が極端に大きくなってしまい、大規模なSIでは開発のコントロールが効かなくなってしまう懸念があります。

そこで、設計／開発の標準化ツールであるSTUDIOでは、Java EE 5とSeam上でCOREの機能を使って作成するアプリケーションに、アーキテクチャー上の標準化を導入する役目を果たしています。

具体的には、STUDIOの提供するアプリケーション設計情報の「定義シート」を作成することで、そこから、ある特定のアーキテクチャーに則ったアプリケーション・ソースコードを自動生成し、そのアーキテクチャーに従って必要な業務処理のコーディングを行うことをルール化しています（図3-1）。

図3-1の下半分の、実行環境におけるアプリケーションのクラス構造を見ると、Java EEパターンとして一般的な、レイヤー構造を持っていることが分かると思います。アクション・クラス－サービス・クラス間でPL（プレゼンテーション・ロジック）とBL（ビジネス・ロジック）を分離し、レイヤー間のデータの受け渡しにはDTOを用います。BL側では、データの永続化にDAO（Data Access Object）層を設けています。

Seamでは元々、画面から直接エンティティへデータを渡し、DTOを必要としない設計パターンが意識されていますが、STUDIOが標準的に提供している定義シートが生成するアプリケーションは、図のようにDTOを使ってデータをBL層へ渡し、手続き的に業務処理のみをコーディングするような枠組みを与えています。

これは、マルチベンダーやオフショアを活用する大規模なSIでは、アプリケーション開発者の設計スキルが統一されないために、手続き指向的に業務処理のみをコーディングするという分かりやすい開発方法が好まれる場合が依然として多く、そうした案件で設計／開発を標準化する仕組みとしての設計支援ツールが求められるケースが多いためです。

開発ツール [2] 定義シートによる設計・開発

STUDIOは、4種類の定義シートを提供しています。定義シートはいずれもMicrosoft Excelのスプレッド・シート形式で編集します。

（1）画面遷移定義シート
（2）データ定義シート
（3）アクション定義シート
（4）サービス定義シート

（1）画面遷移定義シートは、Webアプリケーションの画面間の遷移と、その際に起動するアクションの情報を記述するシートです。ここで記述した情報は、JSFの画面遷移制御をラップしている、Seamのpages.xmlというXMLファイルとして自動生成され、そのまま手を加えずに利用できます。

（2）データ定義シートは、DTOクラスのJavaソースコードを自動生成します。シートには、データ項目を一覧列挙するとともに、各データ項目がどのようなバリデーション属性（半角、全角、日付、数値範囲など）を持つかを定義する欄があり、ここを記述することで、自動生成したDTOに、前ページでも解説した「アプリケーション共通部品」のバリデータのためのアノテーションが付与されます。

（3）アクション定義シートは、画面遷移定義で定義したアクションが、BL層のどのサービスを呼び出すかを定義します。このシートからは、サービス・クラスを呼び出すアクション・クラスのソースコードが自動生成されます。

（4）サービス定義シートは、アクション・クラスから呼び出されるサービス・クラスと、そのサービスが呼び出すロジック・クラスを定義します。このシートからは、各ロジック・クラスと、それらを順々に呼び出すサービス・クラスのソースコードが生成されます（ロジック層を設けず、サービス層に直接ビジネス・ロジックを記述することも可能です）。

（1）～（4）の定義シートから自動生成されたソースコードはほとんどすべて、そのままアプリケーション・アーカイブファイルに詰めて稼働させることができます。編集すべきファイルは、基本的には業務処理の本体を実装すべきロジック・クラスのみとなります。

このようにSTUDIOでは、定義シートからのソースコード自動生成によって設計／開発の標準化と簡単化を実現すると同時に、アプリケーションの設計情報を、管理しやすいスプレッド・シートに集約することで、個々のアプリケーション開発者による設計パターン違反を抑止する役目を持っています。

また、STUDIO定義シートのその他の役目として、「設計／開発単位を導入すること」が挙げられます。

STUDIOではこうした定義シート類を、システム全体で1枚ではなく、Seamのコンテキストである「Conversation（対話）」ごとに1枚ずつ作成することをルール化しています。第2回で解説したとおり、Conversationは、画面遷移を伴う一連の処理など、複数のリクエストをまたいで維持されるスコープを表しますが、ObjectWorks＋ではこれを、ある一連の「業務」の単位と解釈して設計する標準化ルールを導入しています。

ObjectWorks＋による開発の際は、画面遷移定義の設計などに移るまえに、システムのサイト構成を、「業務単位」を意識した複数のConversationに分割し、そのConversationごとにSTUDIOの定義シートを作成することとしています（図3-2）。

こうすることで、業務単位ごとに設計／開発を分離させることができ、不具合があった場合や仕様変更時などの影響範囲をConversation内に集約することができるなど、メンテナンス性を保ちやすくなります。

今回は、NRIのSIフレームワークObjectWorks＋の概要をお伝えしました。最終回の次回は、ObjectWorks＋による開発の手順をもう少し詳しく解説します。