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

図2. 巻物風UML図（アンチパターン）

（2）ユースケースで要求を描くコツ

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

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

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

（3）トレーサビリティを取るコツ

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

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

（4）差分表記のコツ

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

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

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