開発プロセスとUMLの拡張性 ［後編］：UML BASIC LECTURE（2/3 ページ）

[羽生田栄一（豆蔵 取締役会長）, 岡村敦彦（豆蔵），＠IT]

再び、SPEM

　さて、このSPEMはなぜ必要なのでしょうか。世間にはいろいろな開発手法や作業手順、開発プロセスがあります。しかしそれぞれのプロセスにおける用語は必ずしも同じではありません。例えば、一般的に使われる「フェイズ」という言葉さえも、それぞれのプロセスにより意味するところが異なります。ウォーターフォール型のプロセスでは「フェイズ」という用語は「要件定義」や「分析」といった作業工程であるのに対し、以前のRUPではそれに当たる「要求」「分析・設計」にはコアワークフローという用語を使用していて、「フェイズ」には別の概念を割り当てていました。さらにIBMのGSメソッドでは「ドメイン」というように、各プロセスで自由に用語を使用しているのが現状です。しかし、プロセスを改善したり、新しく定義しようとする場合には、それらの用語に一貫性を持たせる必要があります。そこで、OMGではプロセスに関する概念を統一しようとしたわけです。

　結果として、この「フェイズ」の件ではDisciplineという用語を採用し、開発段階における共通のテーマに基づく作業の集まり、という定義をしています。このディシプリンという単語は日本ではあまりなじみのない言葉なので、IBM Rationalではそこに「作業分野」という訳語を当てています。

　そうはいっても、もちろんこれまでの歴史的遺産や文化、慣習を無視することはできるはずもなく、一歩間違えればUnified Methodと同じ轍（てつ）を踏むことにもなりかねません。従って、従来のプロセスの用語を変更してすべてSPEMに統一しなければいけない、というわけではなく、それらのプロセスで使用している用語とSPEMで定義されている用語とのマッピングを取ることができれば、基本的にはSPEM準拠とすることが可能です。例えばあるプロセスにおける「カテゴリ」という概念はSPEMのDisciplineと同様の意味である、という対応が定義されていれば問題ありません。

　これは、私たち開発者にとっては大変ありがたい話です。基本的なプロセスを構成する要素は大きな違いがないにもかかわらず、それを表す用語が異なっていては混乱を増すばかりです。

　例えば、成果物とそれを作成する開発者、そしてそれをどのように開発するのか、という関係や概念は、どのプロセスでも表現したい内容です。SPEMではそのべースとなる概念モデルは以下のように記述されています。

図3 SPEM概念モデル　OMG仕様書より

　ここでは、Roleは開発者の役割であり、開発者は複数の成果物（WorkProduct）に責任を持ち、その成果物にはそれを担当する1人の開発者が決まっていることを示しています。また、それらの成果物は作業（Activity）により作成され、もしくは使用されるものであることがここから分かります。

　この概念モデルをベースに、プロセスを表現するときのさまざまな用語や概念とそれらの関係を記述したモデル、つまりプロセス記述のためのメタモデルが定義されています。

図4 SPEMモデル 抜粋

　例えば、この部分を見てみると、ActivityとStepはそのままRUPで使用されている用語と同一なので、RUPをご存じの方は理解しやすいと思います。つまりActivity（作業）は、その作業内容を示す複数のステップからできている、ということになります。そしてそのActivityはWorkdefinitionのサブクラスなので、parentworkやsubworkを複数持つことが可能、ということが表現されています。

　これにより、RUPにおける作業（Activity）である「アーキテクチャ分析」が「アーキテクチャ候補の定義」と「アーキテクチャ統合の実施」という2つのワークフロー詳細（WorkDefinition）で出現するケースとして記述できることが分かるはずです。

　プロセスを定義する場合のよくある悩みに、すべての作業を階層的にきれいに分離できずに、あるところで実施した作業が別の局面でも同様の作業として必要になる場合があるかと思います。そのようなときでも、このモデルは上位作業と下位作業の両方の多重度をゼロ以上とすることで、複数の作業を持つことが表現可能です。これらのプロセスを構成する概念はステレオタイプとして利用できるため、アイコンも使用することができます。

　ここでは、人の形をしたアイコンの役割（Role）、丸三角四角の成果物（WorkProduct）、ホームベースの横になった作業定義（WorkDefinition）のアイコンを使用して、XPの基本的なモデルを例にしてみましょう。

図5 SPEMアイコン XPをSPEMで表現した例 （SPARX SYSTEMのEnterprise Architectを参考に作成：＠IT編集部）

　こうしたアイコンを利用することで、より理解しやすいプロセスのモデルを記述することができるので、今後はのプロセス定義においてSPEMは必須となってくるでしょう。OMGでは、2000年5月にinitial submission、その後名称の変更（SPEMも当初はUPM＝Unified Process Modelと呼ばれていた）も含めて改定が行われ、2002年にver.1.0が承認されました。SPEMの現状は、UML 2.0のリリースに向けてSPEM 2というUML 2対応バージョンが策定されています。