連載
» 2015年11月02日 07時00分 公開

プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (2/8)

[五味弘,MONOist]

UMLを開発現場で使いこなすコツ

(1)階層記述をするコツ

 各組織や各プロジェクトまたは各個人で、UML図を何らかの創意工夫で階層記述しています。一方、モデルは分かりやすさが一番大事です。その階層記述が万人に分かるようになっていれば、それはUMLを使いこなしていると言っていいでしょう。

 一番多く見かける階層記述で、一番分かりやすいと思う階層の記述方法は、サブグラフに分けるものでしょう。これはグラフの疎結合なところでサブグラフに分割するものです。その考え方を図1に示します。

図1. UML図のサブグラフ分割 図1. UML図のサブグラフ分割

 ここで重要なのは図1のA→Bの概略図で、これを提供して管理することです。A1-A2とB1-B2-B3の2枚の詳細図だけでなく、概要図も入れた3枚にすることが必要です。

 図2にあるような巻物のようなモデルの記述方法は良くないでしょう。フォントを小さくして無理やり1枚にするのはもっての外です。逆に階層記述が3階層以上になるのも良くないでしょう。確かに超大規模になれば3階層以上にならざるを得ないかも知れませんが、1階層目を複雑にしても2階層に納めるようにしてください。きっと3階層を許すと4階層のモデル図も出てきて、悩むことになるでしょう。

図2. 巻物風UML図(アンチパターン) 図2. 巻物風UML図(アンチパターン)

(2)ユースケースで要求を描くコツ

 ユースケース図ではなるべく多くの情報が得られるようにするのがコツです。シナリオ記述やアクティビティ図などの手助けを借りずに、なるべくワンストップで要求とその関係が分かるようにします。シナリオ記述は自然言語で書きますので万能ですが曖昧さと不完全さが残ります。アクティビティ図は要求を描くためには機能がありすぎて、アクティビティ図で描くと、正しいけれど、ついつい余計な情報まで描きがちになります。

 ユースケースを描くコツは目的を絞ることです。例えば、開発者とユーザーとの間の要求の理解に目的を絞れば、これほど便利なモデル図はありません。目的を絞れと書くと疑問に思うかも知れません。「一体、何枚のユースケース図を描かなくてはいけないのだ?」という疑問です。残念ながら、この疑問に対するエレガントな答えはありません。「必要なだけ描きなさい」としか答えられません。教科書的な優等生の答えでなく、もっと開発現場向きに正直に言えば、目的を要求の理解だけに絞ってユースケース図を1枚だけ描くのがいいでしょう。それ以外の目的では別のものがいいでしょう。

 もう1つのコツは簡単です。無理にUMLのユースケース図だけで描くのではなく、SysMLの要求図を使うことです。名前で示される通り、要求は要求図の方が描きやすくなっています。

(3)トレーサビリティを取るコツ

 UMLで問題になるものとしてトレーサビリティの問題があります。ユースケース図で描いたユースケースがクラス図ではどこに行ったのか、このクラスの操作はユースケース図でどこに記述されていたのか、捜索願いを出さなくていいのかという問題です。これは同一のUMLツールを使うことで多少は解決できます。しかしこの場合でも各図で粒度を揃え、表記を揃え、仕様変更には一緒に対応する必要があり、大きなコストが必要になります。

 トレーサビリティの簡単で実効性のある解決方法は、やはりExcelで管理することでしょう。プレーンなテキストでもいいですが、要するにUMLツール任せではまだ面倒だということです。今、このように書いていますが、これから先にもっと便利で知的なトレース機能を持ったツールが出てくるかもしれません。

(4)差分表記のコツ

 差分をモデル図で赤色などで描くというテクニックもありますが、これは2世代の差分ぐらいしか見分けがつきません。2世代までなら使えるテクニックですが、きっといつか破綻するでしょう。それにカラープリンタも必要になります。

 階層記述をすることにより、共通部または派生部を階層化するというテクニックがあります。これは派生部が共通部と比較的きれいに疎結合になっているときは有効な方法です。上流のビジネスモデリングや要求モデリングでは差分が疎結合になっていることが多いので有効ですが、実際の下流の設計モデリングや実装モデリング、データモデリングでは、差分が入り組んでいることが多く、うまく階層記述ができない場合が多いです。

 しかし入り組んだ差分は良くないパターンなので、なるべく差分を局所に「繰り込む」ことを考える必要があるでしょう。このように書くのは簡単ですが、差分を局所的にするというのはリファクタリングでも難しい部類に入りますので、ここではこれ以上触れずに、別の機会に紹介させて頂きたいと思います。

(5)その他のコツ

 UMLの各図では目的を絞って描く、コード生成には使わない、一覧表示などの管理は別にするなどがあります。

 ここではUMLの悪口とその対応の面倒くささを紹介した形になりましたが、これは逆に開発現場でUMLが定着し、使っている人が多いからこそです。この記事を読んで別のものを使おうとせずに(苦労はするかもしれませんが)UMLを使ってみてください。

関連キーワード

モデルベース開発 | モデリング | UML | SysML


Copyright © ITmedia, Inc. All Rights Reserved.