UTI UML教育研究所
トップページ> 読み物> コラム> 使えるUML 第1回
はじめるUML(全12回)
  はじめてみよう!
  モデル要素の整理整頓
  システム全体の構造(1)
  システム全体の構造(2)
  システム全体の構造(3)
  システム化対象の業務(1)
  システム化対象の業務(2)
  システムの動き(1)
  システムの動き(2)
  状態の移り変わり
  OCUPにチャレンジ!
  UML2.0総括(最終回)
続はじめるUML(全10回)
  使ってみよう!
  UMLによる業務分析
  営業職のOCUP受験体験記
  UMLによる要求分析
  インターメディエイト受験体験記
  UMLによるシステム分析
  アドバンスト受験体験記
  UMLによるシステム設計
  情報システム管理者が利用するUML
  続はじめるUML総括
使えるUML(全10回)
  使いこなしてみよう!
  物事を分けてとらえる
  コンポーネント図のいくつかの表現方法
  枠組みを使用してとらえる
  内容とその表現方法をわける
  パターンの表現
  続・パターンの表現
  モデルのモデル
  あいまいさを排除する
  「どのように(How)」から「何を(What)」へ
  大人のオブジェクト指向(最終回)
資格取得までのステップ
FAQ
教育コンテンツ
キャンペーン
ブックプラス
パートナープログラム
認定ユーザープログラム
メールマガジン登録
お問合わせ
使えるUML 第1回

パターンウィーバー(PatternWeaver) ver2.1
さらに使いやすく!
  • 名前空間(ネームスペース)の管理機能を搭載
  • 各種環境設定(デフォルト設定)が可能に
  • モデルのビュー(視点)管理機能を搭載
  • 最新Eclipseにも対応
  • Eclipse3.1.1へ対応
  • 組込み系ユーザにも対応
  • 状態遷移表の機能を搭載
  • C++ソースコード生成プラグイン

●商品に関するお問い合わせ
株式会社テクノロジックアート
e-mail : pw@tech-arts.co.jp
http://pw.tech-arts.co.jp/

2007.2.1 掲載
UMLを使いこなそう!
2007年になり、早くも一か月が過ぎようとしています。昨年の連載記事「続はじめるUML」はいかがでしたでしょうか?少しでも多くの方がUMLをはじめるきっかけとしていただけたら幸いです。今年は「使えるUML」と題しまして、UMLを最大限に活用するためのコツやツボなどをコラムとしてお送りしていきたいと思います。全10回の連載の中で、エンタープライズシステムや組み込みシステムなど、いくつかの分野から旬な話題を取り入れていく予定です。
第一回目の今回のテーマはUML全般に関わる「物事を分けてとらえる」ということです。物事を分けてとらえることは、UMLを利用する・しないに関わらず、問題を解決する際には有効な手段です。いくつかの問題が複雑に絡み合っている状態では、解決策を見出すのは容易ではありません。問題をひとつずつ抽出し、それぞれについて検討することによって、より早く、より適切に解決方法を見つけることができるようになります。UMLに用意されている13のダイアグラムは、いくつかの視点から「物事を分けてとらえる」ためにあると考えることができます。

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

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

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

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

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

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

また、ビジネスプロセスや画面設計・帳票設計といった外部仕様が不明確なユースケースに対する詳細(特に表現の体裁)や内部構造に、あまり時間をかけるべきではありません(実現可能性の調査や、ユーザーの要求を明確化するプロセスである場合を除きます)。オブジェクト指向システムといえども、外部仕様の変化は内部設計に大きな変化をもたらします。変化しやすい段階で、貴重な時間を費やすことは効率的とは言えず、ユーザーのためにもなりません。

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


■筆者紹介
照井 康真/Koma Terui
株式会社テクノロジックアート テクニカルデプト モデリンググループ リーダー