[技術講座]
みなさんは UML に興味はありますか？
それでは、ソフトウェアプロセスには？
UML のメタモデルには？
本稿では、UML Profile の一つ、Software Process Engineering Metamodel (以下、SPEM )を紹介します。
SPEM はソフトウェアプロセスを定義するための OMG ( Object Management Group ) 承認の UML Profile です。UML Profile とは UML を拡張した特定用途向けのモデリング言語です。
本稿は 3 章構成になっています。興味のあるところだけつまみ食いして頂けるとよいでしょう。
1 章 「SPEM の用語」では、SPEM に登場するソフトウェアプロセスの用語を説明します。SPEM に興味がなくてもソフトウェアに興味がある方にもお薦めします。
2 章 「SPEM の使い方」では SPEM の記述法を説明します。SPEM を実際に使ってみたい方にお薦めします。
3 章 「SPEM のメタモデル」では SPEM がどのように定義されているか説明します。SPEM を使い倒したい方、UML Profile とはどのようなものか知りたい方にお薦めします。
SPEM を理解する上ではソフトウェアプロセスの用語を理解しておく必要があります。この章ではソフトウェアプロセスの用語を説明します。もちろん、SPEM を使わない方も、ソフトウェアプロセスの用語を知っておくことに損はないと思います。
以降の説明で、ソフトウェアプロセスの用語に対応する例を RUP（ラショナル統一プロセス）から提示します。RUP そのものの説明自体はここでは行いませんので、必要であれば『ラショナル統一プロセス入門』などの書籍を参考にしてください。
JIS で定義されている規格の一つ、ソフトウェアライフサイクルプロセス（ JISX0160 ）ではプロセスをこのように定義しています。
「互いに関連をもった"アクティビティ"の集合で、入力を出力に変換するもの。」
ちなみに、この定義に書かれているアクティビティとは以降で説明する作業分野と同じ意味ととらえてよいでしょう。
RUP はプロセスです。それもソフトウェア開発に特化したプロセスです。
プロセスにしたがってソフトウェアが進化していく過程で、どのような段階があるか定義するものがライフサイクルです。そして、この段階のことをフェーズといいます。言い換えると、ライフサイクルはソフトウェアの状態を定義しているともいえます。
RUP のライフサイクルは 4 つのフェーズによって定義されています。方向付け、推敲、作成、移行という 4 つのフェーズです。
反復とは小規模のマイルストーンをもった作業の集合です。
反復は RUP の核となる仕組みです。
プロセスのライフサイクルやフェーズ、反復、そして作業には必ず前提条件とゴールが存在します。前提条件が整わない限り、ライフサイクルやフェーズは開始できないでしょうし、ゴールが達成できなければ作業は終了にならないか、失敗したことになります。ゴールのことをソフトウェア開発では一般的にマイルストーンと呼んでいます。
作業分野とは、プロセスで定義している作業や成果物を共通の"テーマ"に沿って分類したものです。 RUP には「ビジネスモデリング」、「要求」、「分析/設計」、「実装」、「テスト」、「導入」、「構成および変更管理」、「プロジェクト管理」、「環境」という 9 つの作業分野があります。
作業とは、人が実行する仕事の最小単位を表します。実際のプロジェクトではこの単位で人やチームに作業を割り当てます。ステップは作業の手順を示すものです。作業定義とは作業の流れを定義するものです。 RUP には「ユースケース設計」という作業があります。この作業の手順を示すために、「ユースケースの実現の作成」、「設計オブジェクト間の相互作用の記述」などというステップがあります。
成果物とは、プロセスを実施していく過程で作成し、使用するものです。成果物には、文書、モデル、プログラムなど様々なものがあります。 RUP には「プロジェクト管理計画書」という文書や、「ユースケース」や「設計クラス」などのモデル、「実装要素」などのプログラム、「プロジェクトリポジトリ」や「要求属性」といったリポジトリがあります。
役割とは、作業を実施する人の「立場」です。 RUP で定義されている「プロジェクト管理者」は「ソフトウェアアーキテクト」は役割の一例です。
では、SPEM ではどのようにプロセスを記述するのでしょうか。SPEM は UML Profile であるため、SPEM の記述も UML を用いて行います。SPEM で頻繁に使う UML の図はパッケージ図、アクティビティ図、クラス図です。
パッケージ図はモデルの要素を特定の単位で分類したい時に使う図です。そのため、SPEM においても、プロセスの要素を分類するときにパッケージ図を使います。
まずは、プロセスの記述の仕方です。プロセスは次のようなアイコンで表現します。
図 1 プロセス
プロセスは UML のパッケージのように記述します。プロセスで定義される全ての要素はこのパッケージの中に記述されることになります。
図 2 プロセスの書き方
このプロセスのパッケージの中には作業分野を定義するアイコンを記述しています。作業分野もプロセスと同じようにパッケージを使って定義することができます。当然、このパッケージの中には作業分野に含むプロセスの要素を記述することができます。
図 3 作業分野の書き方
この作業分野のパッケージの中には左から役割を定義するアイコン、作業を定義するアイコン、文書を定義するアイコン、モデルを定義するアイコン、文書やモデル以外の成果物を定義するためのアイコンを記述しています。
アクティビティ図は作業とものや情報の流れを定義するために使う図です。SPEM はその名のとおり、プロセスを定義するための UML 拡張であるため、当然のようにアクティビティ図を利用する機会が多くなります。
プロセス中の作業の流れ（ワークフロー）を定義するために、これらのアイコンを使ったアクティビティ図を記述することができます。
図 4 アクティビティ図を使ったワークフロー
アクティビティ図を用いる場合には、役割をスイムレーンとして記述し、作業をアクション状態として記述し、モデルや文書を含む成果物はオブジェクトフローとして記述します。SPEM を使った記述の中でも最も頻繁に使う機会がある記述はこれです。
SPEM の用語で説明したように作業の流れを定義したものを作業定義と言います。この作業定義を使って作業の流れをより、高い視点から定義することができます。
直前のワークフローの例は設計のワークフローについて扱っていました。もう一段高い視点から、分析・設計のワークフローを定義すると以下のようになります。
図 5 作業定義を使ったワークフロー
また、SPEM の用語の説明でプロセスにはライフサイクルがあると言いました。SPEM ではプロセスにおけるライフサイクルとそれを定義するフェーズについてもアクティビティ図を用いて記述します。例えば、RUP のような方向付けフェーズ、推敲フェーズ、作成フェーズ、移行フェーズの 4 つのフェーズがあるライフサイクルは次のように記述します。
図 6 アクティビティ図を使ったライフサイクルの定義
SPEM ではクラス図も使います。ただし、パッケージ図やアクティビティ図に比べると使用する頻度はあまりないかもしれません。
クラス図の一つの例に、成果物の構造や成果物に責任を持つ役割の定義があります。
図 7 成果物の定義
また、クラス図はその他の使い方として、役割が実行する作業を定義するためにも使えます。
図 8 役割の定義
これまで説明してきた SPEM の記述法は UML Profile として定義されています。UML Profile は UML のメタモデルに特定用途用のメタモデルを追加定義しています。そのため、UML Profile を正確に理解するためには、そのメタモデルを理解しなければなりません。ちなみに、最新の SPEM は UML 1.4 のメタモデルをもとに拡張をしています。
以降から SPEM のメタモデルを説明します。メタモデル中のグレーのクラスは UML 1.4 が定義しているメタモデル、クリーム色のクラスは SPEM が定義しているメタモデルです。
図 9 プロセスコンポーネント
プロセス（ Process ）と作業分野（ Discipline ）はプロセスコンポーネント（ ProcessCmponent ）を継承しています。このプロセスコンポーネントとは UML のパッケージ（ Package ）を拡張したメタモデルです。
図 10 作業定義の継承関係
作業定義（ WorkDefinition ）は UML の操作（ Operation ）とアクション状態（ ActionState ）とユースケース（ UseCase ）を拡張したメタモデルです。ライフサイクル（ Lifecycle ）、フェーズ（ Phase ）、反復（ Iteration ）、作業（ Activity ）はこの作業定義を継承しています。
図 11 作業定義の詳細
作業定義は必要に応じて、前提条件（ Precondition ）とゴール（ Goal ）が設定することができます。そのため、メタモデルでは作業定義から前提条件とゴールに対して関連が定義され、これらの多重度は 0..* となっています。前提条件とゴールは UML の制約（ Constraiont ）を拡張したメタモデルです。
また、作業定義は親子関係を持つことが可能です。作業定義は SPEM 用語でライフサイクルの内容をフェーズで定義すると説明したような関係です。作業定義は 0..* の親作業定義を持ち、同様に 0..* の子作業定義を持ちます。
図 12 作業パラメーター
作業定義の入力/出力のデータを定義するためのメタモデルとして作業パラメーター（ ActivityParameter ）があります。作業パラメーターは引数（Parameter ）の拡張です。
作業パラメーターには hasWorkPerArtifact という boolean の属性があります。この属性は作業の入力となる成果物ごとに、1 回の作業が実施されるか定義します。「ユースケースの詳細を定義する」という作業は入力の成果物に「ユースケース」がある場合、この作業パラメーターの hasWorkPerArtifact の値は true であるといえます。
図 13 ライフサイクル
ライフサイクルはプロセス全体の振る舞いを定義します。メタモデルではプロセスとライフサイクルの間に関連が定義されており、ライフサイクルからプロセスへの多重度は 0..* と、プロセスからライフサイクルへの多重度は 0..1 と定義されています。つまり、プロセスにはライフサイクルが定義されているものと、全く定義されていないものがあり、1 つのライフサイクルに対して複数のプロセスがあると言えます。
図 14 作業
作業はステップ（ Step ）に対して多重度 0..* の複合関連を持っています。ステップはアクション状態を拡張したメタモデルです。
図 15 役割
役割（ ProcessRole ）はプロセスパフォーマー（ ProcessPerfomer ）を継承したメタモデルです。プロセスパフォーマーは分類子（ Classifier ）を拡張したメタモデルです。プロセスパフォーマーは関係がある作業定義に対して多重度 0..* の関連を持っています。対して、役割は実際に担当する作業に対して多重度 0..* の関連を持っています。
プロセスパフォーマーとは役割の抽象的な概念で、例えば、プロセスパフォーマーを「開発者」とした場合、役割は「ソフトウェアアーキテクト」や「設計者」というような抽象度の違いがあります。大抵のプロセス定義の場合には、「アーキテクチャ分析」のような具体的な作業に対しては「ソフトウェアアーキテクト」のような具体的な役割を関係付け、「設計」のような抽象度の高い作業定義に対しては「開発者」のような抽象度の高いプロセスパフォーマーを関連付けます。
図 16 成果物
成果物（ WorkProduct ）は分類子を拡張したメタモデルです。成果物には isDelivarable という boolean の属性があります。この属性には成果物が納品物となるかを定義します。成果物種類（ WorkProductKind ）に対して関連を持ちます。成果物種類はモデル要素（ ModelElement ）を拡張したメタモデルです。成果物種類はその名のとおり、「文書」や「モデル」など成果物の種類を定義します。対して、成果物は「ユースケース」や「設計モデル」など具体的な成果物を定義します。
成果物と役割の間には関連があります。この関連はどの役割がどの成果物に責任を持っているのかを定義します。
図 17 依存関係
SPEM では 6 つの依存関係が定義されています。
カテゴリー（ Categories ）は使用（ Usage ）を拡張したメタモデルです。プロセスの複数のパッケージにモデル要素を分類するために用います。プロセスや作業分野はパッケージの拡張であるために、カテゴリーを使わなければモデル要素を 1 つのパッケージにしか分類できません。カテゴリーを使うことで、「レビュー」のような抽象的な作業を複数の作業分野に分類できます。
インパクト（ Impacts ）も使用を拡張したメタモデルです。ある成果物が変更されると他の成果物も変更されるといった関係を定義するために用います。例えば「ユースケース」に変更があった場合、「設計モデル」も「ソースプログラム」にも変更が発生することをインパクトを用いて表現します。
参照（ ReferTo ）も使用を拡張したメタモデルです。プロセスのモデル要素が別のモデル要素を参照していることを定義します。
順序（ Precedes ）も使用を拡張したメタモデルです。作業間の時間的な前後関係を定義するために用います。順序は順序種類（ PrecedenceKind ）型の属性を持ちます。この順序種類は値として、開始−開始（ pk_start_start ）、終了−開始（ pk_finish_start ）、終了−終了（ pk_finish_finish ）を持つことができます。開始−開始は 2 つの作業が同時に始まることを、終了−開始はある作業が終了してから次の作業を開始することを、終了−終了は 2 つの作業が同時に終了することを定義します。
インポート（ Import ）は許可（ Permission ）を拡張したメタモデルです。インポートはあるパッケージを別のパッケージに加えていることを定義します。加えられたパッケージのすべてのモデル要素の可視性が public になるということを除けば、UML で定義しているインポートと同じ意味です。
トレース（ Trace ）は抽象化（ Abstraction ）を拡張したメタモデルです。作業定義間の追跡可能性について定義するために用います。通常は要求とモデルの変更をトレースするために用います。UML のトレースと同じ意味です。
図 18 ガイダンス
ガイダンス（ Guidance ）はモデル要素を拡張したメタモデルです。プロセスの特定のモデル要素（フェーズ、作業、成果物などなど）について、より詳細な情報を提供するためのもので、そのためモデル要素に対して多重度 1..* の関連を定義しています。ガイダンスにはガイダンス種類（ GuidanceKind ）に関連を持ちます。ガイダンス種類には、作業ガイドライン、コーディング規約、チェックリスト、ドキュメントテンプレートなど様々な種類があります。
図 19 外部記述
外部記述（ ExternalDescription ）はプレゼンテーション要素（ PresentationElement ）を拡張したメタモデルです。プロセスのモデル要素についての説明を記述するためものです。モデル要素の名前（ name ）、モデル要素の説明である内容（ content ）、外部記述を含むメディアとファイル形式（ medium ）、内容と名前に使った言語（ language ）という属性を持ちます。
いかがだったでしょうか。SPEM とは何か、どのように使えばよいのか分かって頂けたでしょうか。
今後、ソフトウェアプロセスへの需要が今まで以上に高くなることは容易に想像できます。結果として、ソフトウェアプロセスを定義する共通言語 SPEM を利用する機会も多くなるのではないでしょうか。
最後に SPEM とは関係ありませんが、今回紹介した SPEM 以外にも多くの UML Profile があります。その中には掘り出し物のような UML Profile が世に出ています。これからも機会があれば、そのような掘り出し物の UML Profile 達を紹介するかもしれません。
[1] OMG ( Object Management Group )
[2] SPEM ( Software Process Engineering Metamodel )
[3] 『ラショナル統一プロセス入門』 Philippe・Kruchten／著, 藤井拓／監訳, ピアソン・エデュケーション
[4] 『共通フレーム 98 - SLCP-JCF98 - ( 1998 年版)』 SLCP-JCF98 委員会／編, 通産資料調査会
| © 2004 OGIS-RI Co., Ltd. |
|
