連載
Javaオブジェクトモデリング 第1回
| （2）開発プロセス |
大規模なソフトウェア開発では、当然そのモデルは複雑なものになってきます。複雑なモデルを効率良く作成するためには、どのようなモデルを作成するのかだけではなく、どのような手順でモデルを作成するのかといったノウハウがとても重要です。このノウハウを定型化した技術が開発プロセスです。
UMLは単なる言語なので、これだけではどういったモデルを作成すべきかが見えません。UMLに加えて開発プロセスの技術を用いることで、どのようなモデルを作成しなければならないのかが明確になってきます。
オブジェクト指向技術の開発プロセスにはいろいろな提案がありますが、ここではRational Unified Process（以下RUP）をベースにし、リファレンスモデルとして使用します。
| RUPについては、「いまなぜ開発プロセスに注目するのか（後編）」を参照ください。 |
■イテレーションとフェーズ
RUPの特徴の1つは、「イテレーション（iteration）」と「フェーズ（phase）」の2段階を組み合わせた、反復的で漸進的（iterative／incremental）な工程管理手法です。
イテレーションは反復的開発における反復の単位で、2〜6週間という範囲内でのミニプロジェクトとして作業が行われます。イテレーションを構成するコアワークフローとして、以下の5つが定義されています。
- 要求（requirement）
システムに対する要求定義を作成
- 分析（analysis）
システムの基本構成を分析
- 設計（design）
動作環境に依存したシステムの構成を設計
- 実装（implementation）
プログラミングなどによる実装
- テスト（test）
成果物に対するテスト
以上のワークフローをワンセットとしたものがイテレーションで、イテレーション完了時には実行可能な成果物が作成されていることになります。
またRUPでは、イテレーションを束ねた工程管理単位としてフェーズ（phase）を用意しています。フェーズには以下の4種類があります。
| 方向づけ（inception） | 開発の可否を判断するためのフェーズ |
| 推敲（elaboration） | アーキテクチャを定めるためのフェーズ |
| 作成（construction） | システムが提供する機能を作成するためのフェーズ |
| 移行（transition） | システムをリリースするためのフェーズ |
イテレーションとフェーズの関係は、図2にあるとおりです。複数のイテレーションを束ねて個々のフェーズが構成されます。そして方向づけ、推敲、作成、移行の4つのフェーズによって、製品開発における工程管理の大きな枠組みが構成されています。
| 図2入る |
| 図2 RUPのフェーズとコアワークフロー |
この工程は、具体的には図3のような開発ライフサイクルで実行されることになります。
 |
| 図3 開発のライフサイクル |
つまり、同じ要求ワークフローであっても、方向づけフェーズにおける要求ワークフローと推敲フェーズにおける要求ワークフローでは作業内容が微妙に異なります。ただしこの違いは、イテレーションの上流工程では大きいものの、Javaプログラミングを中心とした下流工程ではあまり大きな違いは出ないと考えられます。
■本連載の工程モデルについて
RUPをそのままリファレンスモデルにしてもよいのですが、今回は、
- フェーズは扱わない
- コアワークフローをカスタマイズ
という形の開発プロセスをリファレンスモデルとして用いることにします。
フェーズとイテレーションを組み合わせた工程管理を取り扱わないのは、UMLとJavaの関係においてフェーズという工程管理手法の影響はあまりないと考えられるためです。もちろん、本連載で解説する内容をフェーズと組み合わせて利用することも可能ですし、ほかの方法論で提案されている方法と組み合わせることも可能です。
また、本連載でリファレンスモデルとして用いるコアワークフローは、「ドメイン分析」「要求」「システム分析」「設計」「実装」「テスト」の6つとします。本連載で用いるコアワークフローとRUPのコアワークフローの比較は、図4のとおりです。
 |
| 図4 コアワークフロー比較図 |
「要求」「設計」「実装」「テスト」のワークフローはRUPと同様です。RUPとの相違は、「要求」の前段階に「ドメイン分析」を導入している点と、「分析」を「システム分析」に改名している点です。
RUPでは、「ドメイン分析」に相当する作業は「要求」の中で補助的に行われるか、「ビジネスモデリング」と呼ばれるワークフローとしてコアワークフローの外側で行われることになっています。つまり、RUPのコアワークフローの体系では、実作業中でのドメイン分析の価値が分かりづらいのです。このため本連載のコアワークフローでは、「ドメイン分析」を独立したワークフローとして「要求」の前段階に持ってきています。
またRUPでは、「ドメイン分析」を独立したワークフローとして扱っていないこともあり、「要求」と「設計」の間に存在するワークフローを「分析」と呼んでいます。しかし、伝統的なオブジェクト指向の用語法では、「分析」という用語がドメイン分析を指すことが多いので、本連載では混乱を避けるために「システム分析」と呼ぶことにします。
 |
3/5
|
 |
| Javaオブジェクトモデリング 第1回 | |
| 連載のはじめに | |
| （1）UML | |
 |
（2）開発プロセス |
| （3）オブジェクト指向開発におけるモデル体系 | |
| Java開発におけるオブジェクトモデリングの意義 | |
| INDEX | |
| Javaオブジェクトモデリング | |
|
第1回 UMLとJavaの関係 |
 |
Java Solution全記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
