ObjectWorks＋によるアプリケーション開発

定義シートからソースコードを自動生成する

STUDIOの定義シートが完成したら、定義シートで設計したアプリケーション・ソースコードの自動生成を行います。自動生成は、STUDIOに付属するAntスクリプトで、Eclipseなどの統合開発環境やコマンド・プロンプトなどから実行できます。各定義シートから自動生成されるファイルの内訳や関係は、図2-1のようになります。

ここで、それぞれ自動生成されるファイルについて解説します。

pages.xml

画面遷移定義シートの情報は、すべてこのXMLファイルに出力されます。これは、JBoss Seam（以下、Seam）がJava EE 5標準のMVCフレームワーク「JSF」をラップして画面遷移を制御するためのファイルです。pages.xmlは生成後は一切編集せず、アプリケーション内の所定の位置に配置することで動作します。

DTOソースコード

データ定義シートに記述したデータ項目をフィールドに持ち、setter/getterメソッドのみを持ったシンプルなJavaソースコードが生成されます。データのバリデーション属性定義部の記述に対応して、バリデーション用のアノテーションがフィールドに付与され、Javaクラス自体がメタ情報としてバリデーション属性を持っています。

アクション層ソースコード

アクション層では、ベース・アクション・クラスとアクション・クラスの2種類が生成されます。ベース・アクション・クラスには、アクション定義シートに定義したサービスの呼び出しが実装されています。このソースコードには、一切手を入れないことが標準化ルールとして推奨されています。

アクション・クラスは、ベース・アクション・クラスを継承し、何も記述されていない空クラスです。ビジネス・ロジックに依存しない何らかの共通処理を実装したい場合はこちらに任意のコーディングを施すことができます。実際に、画面（XHTML）からはこのアクション・クラスが呼び出されて、親クラスで定義されている通りにサービス呼び出しが実行されます。

サービス層／ロジック層ソースコード

サービス層とロジック層では、「サービス定義シート」に記述したサービス／ロジックが、インターフェースと実装クラスの2つ1組のソースコードとして出力されます。

インターフェースのソースコードには、EJBのビジネス・インターフェースであることを示すアノテーション（@Localなど）が付与されています。

また、実装クラスのソースコードには、EJBの実装クラスであることを示すアノテーション（@Statelessなど）と、Seamの管理するSeamコンポーネントであることを示す@Nameアノテーションが付与されています。@Nameアノテーションで指定するSeamコンポーネントIDには、定義シートに記述したサービス／ロジックIDが利用されます。

このように、STUDIOの定義シートから生成されるビジネス・ロジックのクラスは、自動的にSeam（とその裏側にあるEJB3）上で管理されるシンプルなJavaクラスとなっています。

自動生成したソースコードと定義シートの整合性を保つ

設計シートからアプリケーションのソースコードを自動生成する設計／開発方式では、設計シートとソースコードの2カ所にアプリケーションの定義情報が併存することになります。こうした場合、一般にはこれらの整合性をいかに維持するかが課題となります。

STUDIOでは、アプリケーションの定義情報を常に定義シート側で一元管理することを標準化ルールとしています。これは、マルチベンダーで分担して複数のサブシステムを開発する場合や、定義シートによる設計から先のコーディングをオフショアで実施する場合などにも、アーキテクチャーの標準化などの統制を利かせ、開発をコントロールできるようにするためです。

STUDIOの定義シートで記述している内容に変更がある場合は、手元でJavaソースコードやXMLファイルを変更せず、必ず定義シートを修正してファイルを再度自動生成することを推奨しています。

画面遷移定義やデータ定義については、生成されたファイルに手を加える必要がないため、一元化された定義シート上で変更を管理することに違和感はないはずです。ただ、アクション定義やサービス定義から生成されるJavaクラスのソースコード類は、（ほとんどの場合ロジック・クラスのみですが）生成後にコーディングをすることで自動生成時の内容から変更が加わっています。この部分についてはどのように定義情報を管理しているのでしょうか。

実は、前ページの説明からも分かる通り、STUDIOの定義シートではビジネス・ロジックの本体については管理をしていません。Javaクラスのインターフェース（コンポーネントのインターフェース名と、入出力に用いるDTO）や、クラス間の呼び出し関係だけを定義しています。

これは、インターフェースや呼び出し関係といった設計情報は、必ずスプレッド・シート形式の定義シートで管理をするようにすることで、複数人での開発時に場当たり的な変更による混乱を避け、アーキテクチャーの統制をとりやすくできるためです。一方、ビジネス・ロジック本体の詳細な仕様については、個々のアプリケーション実装クラスの中で管理したほうが、生産性も阻害されず適しているからです。

このように、STUDIOではJavaクラスのインターフェース、呼び出し関係の仕様は、定義シート上で管理することでメンテナンス性を高く保つ標準化ルールを定めています。しかし、ソースコードを生成してその上にコーディングをする以上、個々のアプリケーション開発者によって標準化ルール外の実装が施される可能性は残されています。

そこでSTUDIOでは、定義シートで定めるJavaクラスのインターフェース呼び出し関係と、Javaアプリケーションのソースコード（の現状）とを比較し、相違点の有無をチェックするツール（図2-2）を用いることで、設計の整合性を保っています。

次ページでは、自動生成したソースコードを使った実際のコーディング作業、さらに単体テストについて解説します。