使えるUML　第1回

パターンウィーバー(PatternWeaver) ver2.1
	さらに使いやすく! 名前空間（ネームスペース）の管理機能を搭載 各種環境設定（デフォルト設定）が可能に モデルのビュー（視点）管理機能を搭載 最新Eclipseにも対応 Eclipse3.1.1へ対応 組込み系ユーザにも対応 状態遷移表の機能を搭載 C++ソースコード生成プラグイン ●商品に関するお問い合わせ 株式会社テクノロジックアート e-mail : pw@tech-arts.co.jp http://pw.tech-arts.co.jp/

◇過去と未来を分ける
「続はじめるUML」でも紹介しましたが、ユーザーがシステムを利用する際の業務の流れを表現する方法のひとつとして、アクティビティ図によるビジネスプロセスのモデリングがあります。ビジネスプロセスをモデリングする際には、これから開発しようとするシステムを導入する前の業務の流れである（現状つまり過去を表す）As-Isプロセスと、導入後のイメージである（未来を表す）To-Beプロセスの２つを分けて作成することがコツであることは、以前にも説明したとおりです。
納期による制約などの理由から、現状であるAs-Isプロセスを整理せずにTo-Beプロセスのみを作成した場合、これから開発するシステムの機能の重要度が不明確なために不要な機能を追加してしまったり、肝心な機能を忘れてしまうことでシステム全体の価値が下がったりしてしまうこともあります。システムを導入するということは、SF映画に出てくる夢のような機能を考え出すことではなく、人間が普段行っていることをより効率的に自動化することであることを忘れないでください。
As-IsとTo-Beを分けて考えた方が良いのは、ビジネスプロセスをモデリングするときだけではありません。ユーザービリティを向上させるためにユースケースのイベントフローを改善するときや、仕様変更のためにクラス設計を変更するときにも同じことが言えます。

◇外部と内部を分ける
UMLには、対象とするシステムが、外部に提供する機能を表すためのユースケース図が用意されています。プロジェクトで採用する方法論によっても異なりますが、一般的にユースケース図では対象とするシステムの内部構造までを考慮するべきではありません。システムを利用するユーザーの視点では、システムに何が備わっているかが重要であり、それがどのように作られるかには、さほど興味がない場合がほとんどです。

1. システムの内部的な機能を表すユースケースを抽出しないようにしましょう（外部システムや外部コンポーネントといった人間以外のアクターと関連する場合を除く）。UMLが表現するオブジェクト指向システムでは、機能分割して階層化された内部処理が順番に実行されるのではなく、システム内部のオブジェクトが他のオブジェクトからのイベントによって処理を行います。
2. システムの内部処理が共通しているという理由だけでユースケースをまとめてしまうと、表面化しない機能要求が隠れて存在してしまうことになり、ビジネスプロセス上で別々の意味の機能であることを表す単位や、共通化（または再利用）しやすい単位がなくなってしまいます。

   
   図1 外部と内部が分かれていないユースケース図

   
   図2 改善したユースケース図
   図2の内部構造は図3のようなコンポーネント図などで記述します。

   
   図3 改善したユースケースに対応するコンポーネント図

◇まとめ
もうひとつ大きな「物事を分けてとらえる」に、「仕様と実現方法を分ける」がありますが、これについてはまたの機会とさせていただきます。他にも「物事を分けてとらえる」ことで、より効率的に解決方法が見つかる問題がありますので、難解な問題に直面したときには、気をつけてみてください。