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

アプリケーション情報の定義シートを作成する（1）

前回は、野村総合研究所（NRI）のSIフレームワーク「ObjectWorks＋（オブジェクトワークス プラス）」の概要を解説しました。最終回の今回は、ObjectWorks＋によるWebアプリケーション開発の流れに沿って、もう少し詳細な特長を解説していきます。

ObjectWorks＋による開発の流れは、「定義シート作成」→「ソースコード自動生成」→「コーディング」→「単体テスト」と4つの作業に大別されます。まずは、アプリケーション開発支援ツールObjectWorks＋/STUDIO（以下、STUDIO）での「定義シート作成」から、開発がスタートします。

この工程では、画面遷移設計やデータ項目の定義など、アプリケーションの基本設計の中でも、「内部設計」に相当する設計を行います。その前段には、前回解説したようにサイト構成図の「Conversation分割」が完了し、STUDIOの定義シートの設計範囲が切り分けられていることが必要です。

STUDIOでは、「画面遷移定義」「データ定義」「アクション定義」「サービス定義」と、Excelをベースとした4つの定義シートを準備します（図1）。

画面遷移定義

まず始めに、「画面遷移定義シート」を作成します。画面遷移定義シートは、大きく分けると「遷移元画面」「遷移時のアクション」「遷移先の画面」の3つの領域があります。アプリケーション内（Conversation内）のすべての画面について、その中で発生するアクションを書き出し、その処理結果に応じて遷移先の画面を定義します。

データ定義

次に、「データ定義シート」を作成します。データ定義シートは、「データ項目と属性の定義部」と「DTO（Data Transfer Object）設計部」の2つの領域に分かれます。まず、シートの左端に、そのアプリケーション内に登場するすべてのデータ項目を列挙します。

データ項目を列挙した後、それぞれについて属性情報を記入していきます。属性情報としては、データ型や日本語名称、デフォルト値などのほかに、バリデーション属性があります。ここで「必須」や「全角」といった欄にチェックを入れておくことで、後ほど自動生成されるDTOにこれらのバリデーションを実装するアノテーションが付与されます。

続いて、シートの右端に、任意のデータ項目をフィールドとして持つDTOを設計します。DTOをどの程度細かく分割して定義するかは、プロジェクトの標準化ルールによります。画面（XHTML）とアクション・クラスとの間でデータのやり取りに用いる「Web層DTO」を、サービス／ロジック・クラスの入出力にもそのまま用いるように単純化するケースもあれば、サービス／ロジックの種類に応じて最低限必要なデータ項目だけを持たせた入力DTO、出力DTOを用意する場合もあります。DTOは、後述する「アクション定義シート」、「サービス定義シート」とも同時並行的に設計していくことになります。

アプリケーション情報の定義シートを作成する（2）

アクション定義

次に、「アクション定義シート」を作成します。アクション定義シートは、「画面遷移定義シート」で記述した、遷移時に呼び出されるアクションを設計します。画面遷移定義シートで記述したアクションのコンポーネントID（＝アクションID）に対して、そのアクションが呼び出すサービスのコンポーネントID（＝サービスID）を記述していきます。

また、アクション・クラスと画面（XHTML）との間でデータをやり取りするためのDTOを指定します。ここには、先ほどの「データ定義シート」で設計したDTOの名前を指定します。

サービス定義

最後に、「サービス定義シート」を作成します。「アクション定義シート」で記述したサービスIDに対して、そのサービスが呼び出すロジック（ビジネス・ロジックの実装部の本体）を記述していきます。

また、サービス・クラスの入出力に用いるDTO、およびロジック・クラスの入出力に用いるDTOも、ここに定義します。この入出力DTOを、サービスやロジックごとに適切に設計することで、サービスやロジックといったBL（ビジネス・ロジック）層のクラスがPL（プレゼンテーション・ロジック）層の画面やアクションと切り離されて管理しやすくなります。

以上で、最初のステップとなる「定義シート作成」の工程は完了です。STUDIOの定義シートは、アプリケーションのクラス構造に、理解しやすい単純なアーキテクチャーを導入して標準化する役割を果たしていますが、役割はそれだけではありません。

アプリケーションの設計情報を、これらのスプレッド・シート上に一元化することで、アプリケーション全体の構造を俯瞰（ふかん）したり、サービスの入出力のようなインターフェースが、個々の開発者によって変更されないよう管理を集約するなどの役割も担っています。