ObjectWorks＋によるアプリケーション開発
アプリケーションのコーディング
定義シートからアプリケーションのソースコードを自動生成したら、業務要件に従ってコーディングを行います。開発者が直接コーディングを行う主な開発対象物としては、以下のものがあります。
- ロジック・クラス（Java）
- 画面（XHTML、JSP）
ロジック・クラスは、前ページで解説したようにEJB兼Seamコンポーネントとして自動生成され、業務処理本体を実装するメソッドの「ガワ」だけが記述されているスケルトン・ソースコードの状態となっています。あとは、そこにメソッドの引数で与えられた入力DTOからデータを取得し、ビジネス・ロジックの処理を実施し、出力DTOに詰めてreturnする処理を記述するのみです。
データ・アクセス処理は必要に応じてDAO（Data Access Object）クラスとして独立させ、Java EE標準O/Rマッピング・ツールのJPAの実装（Hibernateなど）を用いてコーディングします。この部分には、ObjectWorks＋特有の制約などはあまりなく、標準的なツールの仕様に従って開発ができます。
ここでは、画面開発に関して、ObjectWorks＋で特長的な点を解説します。
Seamでは、JSF上のテンプレート・エンジンである「Facelets」を内部で採用しており、動的な画面ファイルをJSPでなくXHTMLで開発することができます（このFaceletsも、Java EE 6に含まれるJSF2.0に取り込まれて標準規格となりました）。Faceletsを使った画面開発には下記のような特長があります。
- 理解しやすいXHTMLで画面を開発可能
- テンプレート機能により画面の部品化／再利用が容易
シンプルなXHTMLとして画面開発ができるので、オープンソース（無償）で入手できる統合開発環境プラグイン（図3-1）でも、プレビューを見ながら画面部品（タグ）のドラッグ・アンド・ドロップによる開発を行うことが可能です。
ObjectWorks＋による画面開発の例としては、前回解説したObjectWorks＋/CORE「アプリケーション共通機能」のうち、値入力時のバリデーション実装方法を解説します。
前回解説した通り、ObjectWorks＋では自動生成されたDTOにバリデーション属性のアノテーションが付与され、データ項目ごとにバリデーション属性の情報が一元管理できるようになっています。
このバリデーションを画面で実行するには、XHTMLファイルのソースコード中で、バリデーションを実施したいデータ入力フィールドなどのHTML部品タグの範囲を、ObjectWorks＋の「バリデーション起動用タグ」で囲むだけです。
--------------------------------------------------------------------------------
…
<input type=”text” jsfc=”h:inputText” name=”date” value=”#{xxxDto.date}” />
…
※xxxDtoの持つ”date”というデータ項目に対して、アノテーションで設定されているバリデーションが実行される。
--------------------------------------------------------------------------------
これで、カスタム・タグに囲まれた範囲では、DTOに付与されたアノテーションに従ってバリデーションが実施されるようになります。また、このカスタム・タグはクライアント・サイドのJavaScriptによるバリデーション部品とも連携しており、タグの属性値を変更するだけでクライアント・サイド／サーバー・サイドのバリデーションの有無を制御することができます。
支援ツールを用いた単体テスト
最後に、開発したソースコードの単体テスト工程について解説します。
ObjectWorks＋では、開発した画面（XHTML）、サービス／ロジック／DAO（Javaクラス）を単体テストする際に利用できる、「単体テスト支援ツール」を提供しています。これは、「BL（ビジネス・ロジック）単体テスト支援機能」と「PL（プレゼンテーション・ロジック）単体テスト支援機能」の、大きく2つに分かれます。
BL単体テスト支援機能
サービスとロジックなど、複数のクラスを結合した状態で単体テスト観点のテストを行うためには、オブジェクトを開発者（テスト開発者）が組み立てる必要があります。また、データベース・アクセスを行うプログラムのテストの場合、データベースの初期化などの手間がかかります。
BL単体テスト支援機能では、上記を解決するため、Excelから読み込んだテスト・データからのDTOなどの作成や、モックの差し込みの制御、Excelから読み込んだデータベースのテーブル情報による初期化などの機能を提供しています（図3-2）。
PL単体テスト支援機能
画面ファイル（XHTML）ごとに、周辺のDTOなどと組み合わせて単体テスト観点のテストを行う際に利用します。まだBL層のクラス（サービス・クラスなど）が作成されていない段階でも、BL層の呼び出し処理を横取りして疑似的な結果を返すモック・インターセプタによって、画面ファイル単体の動作確認を可能にします。
モック・インターセプタは、あらかじめ用意しておいたExcelシートから、シナリオに応じた返却データをDTOにして画面へ返す機能を提供しています（図3-3）。
単体テストの実施範囲や粒度は、プロジェクトによってまちまちです。始めからPLやBLのファイルを結合したテストを行うケースもあれば、まずはBLを単体テストして、順次結合しながらテストを繰り返していくケースなどもあります。いずれにせよ、上記のようなツール類によってテスト・コードの作成やデータ投入といった作業を簡単化し、テストの生産性を高めることができます。
これからのSIフレームワークに求められること
本連載では、企業情報システム開発を支えているJava技術の標準化の動向から、その上でシステム・インテグレーション（SI）を行うために必要な機能や標準化を備えた「SIフレームワーク」を紹介してきました。
第1回でも解説したとおり、Javaの世界では技術の選択肢が多様であり、自社の汎用的な開発標準、というものを定めるのが困難でしたが、近年のJava EE拡張の動きによって「使える標準規格」が整ってきています。
これからのSIフレームワークでは、こうしたオープンで標準化された安定的な技術をベースとしているかどうか、ということもポイントの1つとなってきます。ベースに標準的な技術基盤を利用しつつ、拡張機能やアーキテクチャー標準化などの仕組みをいかに標準仕様にのっとった形で提供されているかが、そのSIフレームワークで開発したアプリケーションの安定性や保守性に大きく影響してきます。
今後、フレームワークの進化を追っていく際には、こうした標準化の観点からも技術動向を見極めていきましょう。
