山田正樹 (masaki@metabolics.co.jp)
November, 2000
このコースでは、ソフトウェア作成の過程を「オブジェクトを用いたモデリング」の連続としてとらえ、オブジェクト指向の考え方に基づいたモデリングを積み重ねることによって、ソフトウェアを作っていきます。
オブジェクト・モデリングとは、現実の世界に近い、曖昧で大雑把な少数のオブジェクト群から、実行系に近い、厳密で詳細な多数のオブジェクト群へと、一貫した考え方(オブジェクト指向)と表記法(UMLなど)を用いて、できるだけシームレスに変換していく過程であるといえるでしょう。ただし、「モデリング」といっても必ずしもUMLで絵を描くことだけではなく、索引カードやプロトタイプやJavaソースコードなども含めて考えることにしたいと思います。
ソフトウェアを作る場合、例えば以下のようなモデルたちを考えることができます。
ここでは、現実の世界の現状(as-isドメイン・モデル)を、期待するような世界(to-beドメイン・モデル)に変えるために、ソフトウェア・システム(システム・モデル)を作ります。システム・モデルはさらにその詳細度によって
のように複数のモデルから成立していると考えることができます。ソフトウェア・システムの作り方を指定するモデルがプロセス・モデルです。
どのような種類のモデルを何段階考えるのがよいかは、プロジェクトやシステムの種類によって異なることでしょう。個人で簡単なプログラムを作るのならば1段階のモデルで十分かもしれません。ハードウェアも含んだ大規模なシステムを多人数・長期間かけて作るのならばさらに何段階かのモデルが必要になるかもしれません。上にあげたモデルは多くの通常のシステム作成にはちょうどよい程度のものだと思います。
このコースでは具体的なソフトウェア・プロセス(ソフトウェア作成の方法論)として、"Unified Process Light"とでもいうべきものを使うことにしましょう。
Unified Processとは、Rational SoftwareのI. Jacobson, G. Booch, J. Rumbaughらによって開発されてきたオブジェクト指向ソフトウェア・プロセスの一つです。Unified Processは以下のような特徴をもっています。
「ユースケース駆動」とは、プロセスのすべてのワークフローがユースケースを起点とする一連の流れになっていることをいいます。ユースケースとはUMLでいうユースケースと同じもので、システムの機能要件を表します。設計、実装、テスト、ユーザ文書作成などすべてがユースケースを元にすすめられます。
「アーキテクチャ中心」とは、プロセスのすべてのワークフローにおいて常にアーキテクチャを意識しながら作業を行うことをいいます。アーキテクチャとはシステムの静的/動的な骨格を定めるもので、マクロなアーキテクチャからマイクロなアーキテクチャまでさまざまなレベルがあり得ます。アーキテクチャを考慮しないプロセスからは統一性のない、バラバラなシステムがうまれがちです。
ユースケースとアーキテクチャはプロセスを支える二つの柱です。ユーザからの要求(ユースケース)とそれを具体化したもの(アーキテクチャ)は相互に進化します。
「反復的でインクリメンタル」とは、全体の作業を小さな繰り返しに分解し、プロセスの進展を常に実際に動作している成果物で検証することです。繰り返しごとに機能を追加したり、品質や性能を向上させたり、リスクに対処します。これによってリスクや変化に強く、目に見えやすいプロジェクトを運営することができます。
この結果、Unified Processは柔軟でリスクに対処しやすい優れたプロセスを提供します。また、Unified ProcessはもともとRational Softwareの私有的な方法論でしたが、最近はUified Processの開発者たち自身による著作が刊行されたり、OMG(オブジェクト・テクノロジ関連の大きな業界団体)にSPE(Software Process Engineering)というかたちで一部が提出されるなど、幾分はオープンな方向に向かっています。
ただし、Unified Processにはその他にもいくつかの問題点があります。ひとつはどちらかというと中〜大規模のソフトウェア･プロジェクトに適していること、もうひとつは(特にRational Softwareの提供するような)CASEツールの利用を前提としている場面がいくらか見受けられることです。したがって、Unified Processは比較的形式的なプロセスであるということもできます。
このコースでは、Unified Processを簡略化し、小規模なプロジェクトに適した比較的形式的でないプロセスとして利用します。このプロセスをここでは"Unified Process Light"、略してUPLと呼ぶことにしましょう。
本来のUnified Processについてはラショナル統一プロセス入門 、UMLによる統一ソフトウェア開発プロセス―オブジェクト指向開発方法論を参照してください。最近注目を集めている軽量プロセス(小規模プロジェクトに適した、変化に強く管理コストの低いプロセス)については、http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/newMethodology_j.htmlを参照してください。
UPLではあるソフトウェアの一生をひとつの「ライフサイクル」と呼びます。ひとつのライフサイクルは、外部に向けての複数のリリースによってそれぞれの「サイクル」に区切られます。ひとつのサイクルは、あるソフトウェアのバージョンを企画してから外部にリリースするまでの期間ということになります。
ひとつのサイクルは、さらに四つの「フェーズ(段階、局面)」から成ります。
各フェーズには、さまざまな活動(activity)やその集合であるワークフローが含まれます。各フェーズはさらに複数の「イテレーション」から構成されます。イテレーションとは「反復」のことで、それぞれがある目的をもって動作するソフトウェアを作る小さなプロセス(マイクロ・プロセス)です。
一回のイテレーションの期間はプロジェクトの規模や性質により1週間〜数ヶ月程度、ひとつのサイクル中でのイテレーションの回数は同様に数回から十数回程度です。
このようにひとつのプロセス(マクロ･プロセス)を複数の小さなイテレーション(マイクロ・プロセス)に分解することによって、柔軟性が高くリスクに対処しやすいプロセスを実現しているのです。その代わり、反復を混乱なく行うためにはソフトウェアの構成管理をきちんと行うことが必要になります。
ここからはフェーズを追って、オブジェクト･モデリングの詳細を練習してみましょう。