第2回
Java開発を加速するRelaxerプロセスの真髄

浅海智晴
2003/7/15

4.Relaxerプロセス

　第1回「Relaxerで実現するJava開発の新プロセス」はRelaxerおよびRelaxerプロセスが想定するアプリケーション・アーキテクチャについて確認した。今回は、Relaxerプロセスそのものについて解説する。Relaxerプロセスとは、XMLスキーマコンパイラ／コンポーネントコンパイラであるRelaxerの活用を前提としたオブジェクト指向開発プロセスである。

今回の内容

4 Relaxerプロセス

4.1 モデル体系

4.2 工程モデル

4.3 Relaxerプロセスの流れ

4.4 ドメイン分析

4.5 要求分析

4.6 システム分析

4.6.1 ロバストネス分析

4.6.2 コンポーネント分析

4.7 設計

4.7.1 Relaxer設計

4.7.2 コンポーネント設計

4.8 実装

4.9 テスト

4.10 Relaxerプロセスのポイント

5 まとめ

◇4.1 モデル体系

　本連載では図1をオブジェクト指向開発におけるモデル体系のリファレンスモデルとして使用する。このリファレンスモデルでは以下のモデルが登場する。

図1 モデル体系

• ドメイン分析モデル
  
• 要求分析モデル
  
• システム分析モデル
  
• 設計モデル
  
• 実装モデル
  
• テストモデル

　RelaxerはXMLを中心とした実装技術であり、モデル体系の中では設計モデルおよび実装モデルに大きな影響を与えることになる。そして設計モデルおよび実装モデルに対する変更が、上流のシステム分析モデル、テストモデルにも影響してくるわけである。

　図2は、このリファレンスモデルに対して、Relaxerが与える影響を示したものである。この図から分かるとおり、Relaxerの利用は設計モデルに大きな影響を与える。さらに、設計モデルの変更から派生して、システム分析モデル、実装モデル、テストモデル（のホワイトボックス・テスト）にも影響が及ぶことになる。

図2 オブジェクト指向モデルとRelaxer

◇4.2 工程モデル

　イテレーションでは、図2に示したモデル体系に沿った工程モデルを利用する。図3に示すように以下のワークフローで構成される。

• ドメイン分析
  
• 要求分析
  
• システム分析
  
• 設計
  
• 実装
  
• テスト

　Relaxerプロセスでは、図3に示すようにこのイテレーションの反復により漸進的に開発を進めていくことを想定している。

図3 工程モデル

　ただし、Relaxerプロセスでは、イテレーションの反復を管理する上位の工程モデルについては特に定めない。この上位の工程モデルには、Unified Processのフェイズを想定しているが、それ以外のモデルを採用しても構わないとする。

◇4.3 Relaxerプロセスの流れ

　図4がRelaxerプロセスの大まかな流れである。

図4 Relaxerプロセスの流れ（クリックすると拡大）

　一般的なオブジェクト指向開発プロセスとの相違点は以下の3点である。

• バリューオブジェクトの導入（システム分析）
  
• コンポーネントモデルの作成（システム分析）
  
• Relaxerモデルの作成（設計）

　以上の点を考慮に入れながら、ドメイン分析からテストまでの流れを大まかに見ていこう。

◇4.4 ドメイン分析

　ドメイン分析は、システムが解決する対象となる問題領域をオブジェクト・モデルとしてモデル化する作業である。Relaxerプロセスのドメイン分析は、一般的なオブジェクト指向開発プロセスに沿ったものになる。ドメイン分析モデルは以下のモデルから構成される。

• コンテキスト・モデル（コラボレーション図）
  
• エンティティ・モデル（クラス図）
  
• ビジネス・フロー（アクティビティ図）
  
• ビジネス・ルール

コンテキスト・モデル：開発ターゲットのシステムの全体像を特定するために作成するモデルである。コンテキスト・モデルはコラボレーション図で記述される エンティティ・モデル：システムがターゲットとするコンテキスト・モデルで特定されたコンテキストの構造を、オブジェクトを用いてモデル化したものである。エンティティ・モデルはクラス図で記述される ビジネス・フロー：システムが遂行するビジネス・プロセスをオブジェクト・フローとして記述したものである。ビジネス・フローはアクティビティ図として記述される ビジネス・ルール：制約を記述したものである。ビジネス・ルールの記述は、自然文でもよいし、可能であればOCL（Object Constraint Language）を用いてもよい

◇4.5 要求分析

　要求分析は、顧客の要求仕様をユースケースを中心としてモデル化する作業である。ドメイン分析と同様にRelaxerプロセスの要求分析は、一般的なオブジェクト指向開発プロセスに沿ったものになる。要求分析モデルは以下のモデルから構成される。

• ユースケース記述
  
• ユースケース図
  
• 開発計画表

　要求分析モデルの核となるのが、ユースケースである。ユースケースは、ユースケース記述およびユースケース図として記述される。また、要求分析モデルで得られた情報を反映する形で、クラス図とビジネス・ルールは更新される。

◇4.6 システム分析

　システム分析は、要求分析によってモデル化された顧客の要求を、ソフトウェアで実現するための基本構造を分析する作業である。この作業では、一般的なオブジェクト指向開発プロセスの作業をRelaxer向けにチューニングしている。Relaxerプロセスのシステム分析は、以下の2つの作業から構成される。

• ロバストネス分析
  
• コンポーネント分析

●4.6.1 ロバストネス分析

　Relaxerプロセスでは、システム分析の最初の段階でロバストネス分析を行う。このロバストネス分析では図5に示す分析オブジェクトを使用する。

図5 分析オブジェクト

• アクター
  
• バウンダリオブジェクト
  
• コントロールオブジェクト
  
• エンティティオブジェクト
  
• バリューオブジェクト

　この中で、アクター、バウンダリオブジェクト、コントロールオブジェクト、エンティティオブジェクトは一般的なオブジェクト指向開発においてすでに利用されている分析オブジェクトである。つまり、バリューオブジェクトがRelaxerプロセスで新規に導入された分析オブジェクトとなるわけである。ロバストネス分析では、静的モデルをクラス図、動的モデルをシーケンス図（またはコラボレーション図）で記述する。以上の分析オブジェクトを使用したクラス図の例が図6である。この図から分かる通り、Relaxerプロセスにおけるロバストネス分析では、バウンダリオブジェクト、コントロールオブジェクト、エンティティオブジェクトの間を流通するデータをバリューオブジェクトとしてモデル化する。

図6 分析オブジェクトの使用例

●4.6.2 コンポーネント分析

　ロバストネス分析の次の作業はコンポーネント分析である。ロバストネス分析の結果から分析コンポーネントモデルを作成する。コンポーネント分析では、静的モデルをクラス図、動的モデルをシーケンス図およびステートチャート図で記述する。

◇4.7 設計

　設計は、システム分析によってモデル化された分析コンポーネントからJavaでの実装をターゲットに設計コンポーネント仕様とその実装を設計する作業である。一般的なオブジェクト指向開発プロセスの作業をRelaxer向けにチューニングしている。Relaxerプロセスの設計は、以下の2つの作業から構成される。

• Relaxer設計
  
• コンポーネント設計

●4.7.1 Relaxer設計

　設計作業においてRelaxerモデルを作成する点が、Relaxerプロセスの特徴である。コンポーネント分析の結果、分析コンポーネントと、分析コンポーネントが使用するデータモデルが作成される。これらのモデルをRelaxer CDL（RCDL）定義およびRELAXスキーマに変換するのが、Relaxer設計の目的である。
　
　もちろんRCDL定義およびRELAXスキーマを作成するのは、Relaxerを用いてJavaプログラムを自動生成するためだ。RCDL定義からは、JavaBeansやEnterprise Beansなど、コンポーネント基盤上で動作させるためのコンポーネント・スケルトンが生成される。また、RELAXスキーマからは、Relaxerオブジェクトと呼ばれるXML文書と相互変換可能なJavaオブジェクトが生成される。

●4.7.2 コンポーネント設計

　コンポーネント設計は、コンポーネントの実装を設計する作業である。コンポーネントの外部仕様はRCDL定義によって定義され、ここからJavaインターフェイスという形でJavaプログラム化される。コンポーネント設計では、このJavaインターフェイスの実装を設計するわけである。
　
　コンポーネント設計では、静的モデルをクラス図、動的モデルをシーケンス図とステートチャート図で記述する。また、物理モデルとしてコンポーネント図とディプロイメント図を作成する。

◇4.8 実装

　Relaxerプロセスでは、実装に入る前に、以下のJavaプログラムがRelaxerによって自動生成されている。

• RCDL定義からコンポーネント・スケルトン
  
• RELAXスキーマからRelaxerオブジェクト

　実装では、以上のJavaプログラムをベースにして、コンポーネント設計で作成したコンポーネントを実装していく。

　もちろん、コンポーネント設計で適切なCASEツールを使うことができれば、Javaプログラムの静的モデル部分は自動生成できるので、プログラミングが必要となるのはシーケンス図やステートチャート図からJavaメソッドの実装を作成する部分のみとなるだろう。また、マニュアルの作成もこのタイミングで行うことになる。

◇4.9 テスト

　Relaxerプロセスのテストは、一般のオブジェクト指向開発と同様の作業となる。

　テストには、負荷テストや回帰テストなど、従来、さまざまな種類のテストがあり、その多くはオブジェクト指向開発でも引き続き有効である。オブジェクト指向開発という観点からは、以下の2つの切り口のテストが重要である。

• ブラックボックス・テスト
  
• ホワイトボックス・テスト

　ブラックボックス・テストはシステムがユーザーの要求どおりに動作するのかを確認するテストである。いわゆるシステム・テストと考えてもらってよい。いわば、問題領域のモデルに対するテストであり、ユースケースの情報を基にテストセットが作成される。

　ホワイトボックス・テストはシステムを構成する部品が、開発者の意図した仕様どおりに動作するのかを確認するテストである。いわゆるコンポーネント・テストと考えてもらってよい。いわば、解決領域のモデルに対するテストである。特にコンポーネント仕様から作成されることが多いだろう。

◇4.10 Relaxerプロセスのポイント

　Relaxerプロセスの核となるシステム分析から実装への流れは図7となる。

図7 システム分析から実装への流れ

　システム分析では、バウンダリオブジェクト、コントロールオブジェクト、エンティティオブジェクト、バリューオブジェクトの4つの分析オブジェクトが生成される。問題はこれらの分析オブジェクトをどのようにしてJavaプログラムに落とし込んでいくかである。

　Relaxerプロセスにおける基本的な流れは以下の2つである。

• コントロールオブジェクトからRCDL定義を作成する
  
• バリューオブジェクトからRELAXスキーマを作成する

　また、条件が満たされれば、バウンダリオブジェクトからRCDL定義の作成、エンティティオブジェクトからRELAXスキーマの作成を行う。

　RCDL定義を作成することで、コントロールオブジェクトの実装として各種のコンポーネントを、RELAXスキーマを作成することで、データを表現するためのJavaオブジェクトをRelaxerが生成してくれる。

　つまり、分析モデルを可能な限りRCDL定義あるいはRELAXスキーマに変換することが、開発効率を向上させるカギとなるわけだ。

5.まとめ

　2回に渡ってRelaxerプロセスの概要について説明した。次回より、Relaxerプロセスの効果を検証するためのサンプルアプリケーションとして開発した図書館システムの実例を通して、Relaxerプロセスの流れについて説明していく予定である。

IT Architect 連載記事一覧