UML BASIC LECTURE（10） page1 page2 page3
開発プロセスとUMLの拡張性 ［後編］



豆蔵 取締役会長 羽生田栄一
豆蔵 岡村敦彦
2005/3/23

---

■ 開発プロセスの傾向

　 私たち開発者はプロセスの信仰者ではありません。いずれかのプロセスを採用したからといって、それ以外の手法を認めないような排他的態度は取るべきではないでしょう。とはいえ、プロセスや開発手法の話になるときに、そうした宗教論争的な傾向に偏りがちなのは大変残念なことです。重要なのは組織やプロジェクトの開発目的に応じた柔軟なプロセスにしていくこと、つまり開発のアジャイルさだけではなく、プロセス自身に対するアジャイルさも必要であり、それが本当の意味での「アジャイルプロセス」であると考えます。

　例えばCMMはよくアジャイル系から標的とされますが、最近ではSEI（カーネギーメロン大学のSoftware Engineering Institute）においてもアジャイルの考え方を取り入れた研究が増えてきているので、これからはお互いが歩み寄ることで適切な方向に向かっていくことを期待したいです。

■ 開発プロセスとUMLの関係

　では、そうした開発プロセスとUMLはどのような関係にあるのでしょうか。UMLももともとは統一方法論（Unified Method）として開発された経緯から、オブジェクト指向の開発手法と思われている時期もありました。

■ UMLから見た開発プロセス

　UMLは開発プロセスにニュートラルな存在のため、どのような開発プロセスでもUMLを使用することができます。ある程度想定された使い方があるとはいえ、それを強制するものではありません。例えば、UMLにはユースケース図がありユースケースベースの開発手法を想定していますが、だからといってユースケースを使わなければいけないということではなく、そのプロジェクトで「要求」に関する適切な技法がすでにほかにあるのであれば、それを使うのがいいでしょう。

■ 開発プロセスから見たUML

　一方、プロセスから見たUMLには2通りの考え方があります。まず1つ目が、プロセスの中で使用する成果物を記述するための一手段であるということ。これは UMLの使い方としては最も一般的な利用方法といえます。分析モデルや設計モデルをUMLで記述する、というケースです。ただしプロセスからすれば、開発段階での成果物には、UML以外の形式もいろいろあるわけです。

　もう1つは開発プロセス自体をUMLで記述する、という考え方。前者は、RUPをはじめとするUMLベースの開発プロセスの話であり、すでに至る所で取り上げられているので、今回は後者に注目してみたいと思います。

■ SPEM（Software Process Engineering Metamodel）

　SPEMとはSoftware Process Engineering Metamodelの略で、開発プロセスのメタモデルをUMLで仕様化したものです。SPEMにはそのモデルとUMLのプロファイルが含まれます。SPEMの話の前に、プロファイルの復習をしておきましょう。

■ UMLの拡張方法

　UMLは標準的な表記法が決められている厳密な言語ですが、利用するユーザーへの拡張に対しても無頓着ではありません。UMLに限らず一般的に「標準」はあくまでも「標準」であって、それだけではカバーできない部分も当然あります。標準がその世界に受け入れられるかどうかは、それ自体が持つ厳密さとその拡張性に対する柔軟さによる双方のバランスが取れていることが大きいでしょう（オブジェクト指向でいうところの開閉原則？）。

　UMLは以下の3つの方法で拡張することができます。

• 制約
  
• タグ付値
  
• ステレオタイプ

　制約に関してはOCLで触れたので、今回はステレオタイプです。

　「ステレオタイプ」とは、辞書的な意味では「固定観念」「紋切り型」というようにあまりよい場面で使われることがない気もしますが、ここでは「形式化する」という意味でとらえてください。つまりある何らかのドメインを表現したいときに、そのドメイン特有の表現形式に当てはめたいことがあります。そのようなある対象ドメイン向けのステレオタイプなどのほかのセットがプロファイルです。

　例えば、UML 2.0に標準として添付されているプロファイルの1つである「UML Profile for J2EE」。これは通常のモデル要素に加え、EJB用のステレオタイプにより新たな意味付けをすることでJ2EEによる開発をモデル化するための拡張です。

　例えば、EntityBean、SessionBean、HomeInterface、RemoteInterfaceなどの概念はUML Profile for J2EEのステレオタイプでは以下のように表します。

• <<EJBEntityBean>>
  
• <<EJBSessionBean>>
  
• <<EJBHome>>
  
• <<EJBRemote>>

　こうしたプロファイルはUMLのユーザーが自由に設定できるため、UMLのsyntaxを利用しながら、自分の表現したい領域を独自の表現で記述することが可能になります。

■ UML 2.0とステレオタイプ

　UML 1.x までは、ステレオタイプを新しく定義するときのモデル要素は特に用意されておらず、依存関係で記述していました。つまり、依存線のステレオタイプにstereotypeと指定することでステレオタイプであることを表現していたので、ある意味で分かりにくかったといえるでしょう（文章で書くとさらに分かりにくいですね……）。UML 2からは閉じた矢印の“extension”により、どのステレオタイプが何を拡張しているのかをもう少し分かりやすく表現できるようになりました。

旧：UML 1.x依存関係で表現

新：UML 2.0新しい表記法extensionの矢印

図2 stereotypeの定義方法

　ステレオタイプはクラスに限らず、いろいろなモデル要素を拡張することができるので、何の拡張なのかを上記の使用に定義する必要があります。通常は、クラスや関係に対するステレオタイプが多いですね。

　OMGのページでは以下のようなプロファイルを確認できます。

* UML Profile for CORBA * UML Profile for CORBA Component Model （CCM） * UML Profile for Enterprise Application Integration （EAI） * UML Profile for Enterprise Distributed Object Computing （EDOC） * UML Profile for QoS and Fault Tolerance * UML Profile for Schedulability, Performance, and Time * UML Testing Profile

　今回のSPEMもそうしたプロファイルの1つとして表現されています。プロファイルの復習が終わったところで、SPEMの話に戻りましょう。

1/3

INDEX
UML BASIC LECTURE（10） 開発プロセスとUMLの拡張性 ［後編］
	Page1 開発プロセスの傾向
	Page2 再び、SPEM
	Page3 アスペクト指向ユースケース

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）