連載

Javaオブジェクトモデリング

第1回　連載を読む前に知っておくべきこと

　

4.開発プロセス

　大規模なソフトウェア開発では、当然そのモデルは複雑なものになってきます。複雑なモデルを効率良く作成するためには、どのようなモデルを作成するのかだけではなく、どのような手順でモデルを作成するのかといったノウハウがとても重要です。このノウハウを定型化した技術が開発プロセスです。

　UMLは単なる言語なので、これだけではどういったモデルを作成すべきかが見えません。UMLに加えて開発プロセスの技術を用いることで、どのようなモデルを作成しなければならないのかが明確になってきます。

　オブジェクト指向技術の開発プロセスにはいろいろな提案がありますが、ここではUnified Process（以下UP）をベースにし、リファレンスモデルとして使用します。

UPの1つであるRUP（Rational Unified Process）については、「いまなぜ開発プロセスに注目するのか（後編）」を参照ください。

■■4.1 イテレーションとフェイズ■■

　UPの特徴の1つは、「イテレーション（iteration）」と「フェイズ（phase）」の2段階を組み合わせた、反復的で漸進的（iterative／incremental）な工程管理手法です。

　イテレーションは反復的開発における反復の単位で、2〜6週間という範囲内でのミニプロジェクトとして作業が行われます。イテレーションを構成するコアワークフローとして、以下の5つが定義されています。

• 要求（requirement）
  システムに対する要求定義を作成
  
  
• 分析（analysis）
  システムの基本構成を分析
  
  
• 設計（design）
  動作環境に依存したシステムの構成を設計
  
  
• 実装（implementation）
  プログラミングなどによる実装
  
  
• テスト（test）
  成果物に対するテスト
  

　以上のワークフローをワンセットとしたものがイテレーションで、イテレーション完了時には実行可能な成果物が作成されていることになります。

　またUPでは、イテレーションを束ねた工程管理単位としてフェイズ（phase）を用意しています。フェイズには以下の4種類があります。

方向づけ(inception)	開発の可否を判断するためのフェイズ
推敲（elaboration）	アーキテクチャを定めるためのフェイズ
作成（construction）	システムが提供する機能を作成するためのフェイズ
移行（transition）	システムをリリースするためのフェイズ

　イテレーションとフェイズの関係は、図2にあるとおりです。複数のイテレーションを束ねて個々のフェイズが構成されます。そして方向づけ、推敲、作成、移行の4つのフェイズによって、製品開発における工程管理の大きな枠組みが構成されています。

図2　UPのフェイズとコアワークフロー

　この工程は、具体的には図3のような開発ライフサイクルで実行されることになります。

図3　開発のライフサイクル

　つまり、同じ要求ワークフローであっても、方向づけフェイズにおける要求ワークフローと推敲フェイズにおける要求ワークフローでは作業内容が微妙に異なります。ただしこの違いは、イテレーションの上流工程では大きいものの、Javaプログラミングを中心とした下流工程ではあまり大きな違いは出ないと考えられます。

■■4.2 本連載の工程モデルについて■■

　UPをそのままリファレンスモデルにしてもよいのですが、今回は、

• フェイズは扱わない
• コアワークフローをカスタマイズ

という形の開発プロセスをリファレンスモデルとして用いることにします。

　フェイズとイテレーションを組み合わせた工程管理を取り扱わないのは、UMLとJavaの関係においてフェイズという工程管理手法の影響はあまりないと考えられるためです。もちろん、本連載で解説する内容をフェイズと組み合わせて利用することも可能ですし、ほかの方法論で提案されている方法と組み合わせることも可能です。

　また、本連載でリファレンスモデルとして用いるコアワークフローは、「ドメイン分析」「要求」「システム分析」「設計」「実装」「テスト」の6つとします。本連載で用いるコアワークフローとUPのコアワークフローの比較は、図4のとおりです。

図4　コアワークフロー比較図

　「要求」「設計」「実装」「テスト」のワークフローはUPと同様です。UPとの相違は、「要求」の前段階に「ドメイン分析」を導入している点と、「分析」を「システム分析」に改名している点です。

　UPでは、「ドメイン分析」に相当する作業は「要求」の中で補助的に行われるか、「ビジネスモデリング」と呼ばれるワークフローとしてコアワークフローの外側で行われることになっています。つまり、UPのコアワークフローの体系では、実作業中でのドメイン分析の価値が分かりづらいのです。このため本連載のコアワークフローでは、「ドメイン分析」を独立したワークフローとして「要求」の前段階に持ってきています。

　またUPでは、「ドメイン分析」を独立したワークフローとして扱っていないこともあり、「要求」と「設計」の間に存在するワークフローを「分析」と呼んでいます。しかし、伝統的なオブジェクト指向の用語法では、「分析」という用語がドメイン分析を指すことが多いので、本連載では混乱を避けるために「システム分析」と呼ぶことにします。

3/5

Javaオブジェクトモデリング　第1回
	連載のはじめに
	UML（図の分類）
	開発プロセス
	オブジェクト指向開発におけるモデル体系
	Java開発におけるオブジェクトモデリングの意義

Javaオブジェクトモデリング INDEX

IT Architect 連載記事一覧