UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース：The Rational Edge（2/2 ページ）

» 2007年05月22日 12時00分 公開
[Arthur V. English（Unisys Corporation シニア学習開発コンサルタント），＠IT]
前のページへ 1|2 　　　　　　

ビジネスユースケースモデルとシステムユースケースモデルの類似点は？

　ビジネスユースケースモデルは、いろいろな意味でシステムユースケースモデルと非常に似通っている。両モデルともにユースケース仕様がある。ビジネスユースケース仕様とシステムユースケース仕様のRUPテンプレートを調べると、フォーマットがかなり似通っていることが分かる。いずれにも、「Preconditions（前提条件）」「Postconditions（事後条件）」「Extension Points（拡張ポイント）」、そして「Special Requirements（特殊要件）」がある。ビジネスユースケース仕様には、基本の「Flow of Events（イベントフロー）」や「Alternative Flows（代替フロー）」ではなく、基本ワークフローと代替ワークフローがある。

　ビジネスとシステムの両ユースケース仕様のフォーマットは酷似しているが、設計の狙いが異なっている。ビジネスユースケースを設計する狙いは業務活動だ。つまり、組織外のビジネスアクターがビジネス組織の事業目標を達成することだ。RUPによるビジネスユースケースの定義は以下のようになる。

　「『ビジネスユースケース』は外部の付加価値の視点からビジネスプロセスを記述する。『ビジネスユースケース』は、ビジネスアクターに価値を提供するために組織の領域を超え、パートナーやサプライヤーまでも含まれることのあるビジネスプロセスである」

　簡潔ではあるが、この定義は以下のような重要なポイントをいくつか明らかにしている。

  • ビジネスユースケースはソフトウェアシステムプロセスではなくビジネスプロセスを示す
  • ビジネスユースケースは利害関係者に価値を提供する。利害関係者とは、アクターもしくは業務従事者を指す
  • ビジネスユースケースは組織の枠組みを超えることができる。中にはこのポイントをあまりに文字通りに取り過ぎてしまうアーキテクトもいる。多くのビジネスユースケースは実際に組織の枠組みを超えるが、1つの組織にだけ重点を置くビジネスユースケースもある。いくつかの例は後述する

　Podeswaの著書である「UML for the IT Business Analyst:」の中のビジネスユースケースの定義も考察しよう。

　「ビジネスユースケース：ビジネスの中の具体的なワークフローを示すビジネスプロセスであり、事業目標を達成する業務と利害関係者のやりとりであって、手作業と自動化されたプロセスの両方が考えられ、長時間にわたって展開される場合もある」

　この定義は、事業目標を達成することで価値を提供するという考え方を説明している。手作業と自動化されたプロセスの両方が関係する具体的なワークフローとしてビジネスプロセスを定義することにより、RUPの定義を拡大している。この定義は、ワークフローが長時間にわたる可能性があることも指摘している。これらはすべて極めて重要なポイントだ。

　では、システムユースケースの方はどうか？ システムユースケースを設計する狙いは、コンピュータシステムを設計することだ。システムアクターがコンピュータシステムによって目標を達成することがその狙いだ。システムユースケースは、アクターとコンピュータ技術とのやりとりを示すものであって、ビジネスプロセスとのやりとりを示すものではない。

　　　　　　　　　　　Very High Summary

　　　　　　　　　　　Summary

　　　　　　　　　　　User Goal

　　　　　　　　　　　Subfunction

　　　　　　　　　　　Too Low

Alistair Cockburnによるビジネスとシステムの両ユースケースの分類


　CockburnがWriting Effective Use Casesで主眼にしているのはシステムユースケースだが、同氏はビジネスユースケースにもかなり注目している。Cockburnは、さまざまなテンプレートタイプを使い、ビジネスとシステムの両ユースケースを差別化する代わりに目標レベルを使っている。では、これらのアイコンや目標レベルは何を意味しているのだろうか？

　これらのアイコン自体は、ユースケースの「海面」（ユーザーの目線）を基点とした海抜を基本にしてシンプルなシステムを表している。システムユースケースのスイートスポットは、「海面」アイコンが示す「ユーザーの目標」だ。複雑なシステムユースケースは、「補助機能」の目標を持ち、「サカナ」アイコンで示される複数のユースケースに分解することも場合によっては必要だ。しかし、「海面」システムユースケースを「貝」のアイコンで示される「低過ぎる」システムユースケースに分解することは絶対に避けるべきだ。

　お分かりかもしれないが、「概要」ユースケース（「たこ」のアイコン）はビジネスユースケースになる。また、「雲」で示される「高度な概要」の目標ユースケースもビジネスユースケースになり得る。

　組織の最高レベルの事業目標から、これらの事業目標を満たすソフトウェアソリューションのインプリメント要件の詳細までの範囲にわたってユースケースを検討するのがCockburnのアプローチだ。このアプローチでは、システムユースケースはビジネスユースケースを分解したもの、としてとらえている。ユースケースを分解するこのアプローチは、ビジネスモデルからシステムユースケースモデルを導き出すのに役立つ。詳細は後述する。

　では、ビジネスユースケースモデルとシステムユースケースモデルの図にはほかにどのような類似点があるだろうか？

  • いずれにもアクターが存在する。ビジネスユースケース図では、アクターを <>とする
  • いずれにもユースケースが存在する。ビジネスユースケースモデルでは、ユースケースを<>とする
  • いずれにもアクターとユースケースの間にコミュニケーションの関連がある
  • システムユースケースに加え、ビジネスユースケースにも包含、拡張、一般化といった関連がある

　ユースケース図におけるコミュニケーションの関連は、ユースケースのモデリングを学習する人にとって混乱することの多い部分だ。筆者はここで矢印を用いるべきだろうか？矢印の向きはどうすればよいだろう？ コミュニケーションの関連は、UML 1.4の仕様から実線で示されてきた。この線には矢印を付けることもできる。線と矢印は、アクターとシステムの双方向の会話を表す。矢印があれば、その関連の後ろにある「もの」だけがコミュニケーションを開始できる。矢印がないのは、いずれもコミュニケーションを開始できないことを意味する（どちらからでもコミュニケーションを開始できるという意味ではない）。

　UML 2.0仕様はこれをもっとシンプルにする。UML 2.0はこの機能に、アクターとユースケース、もしくはビジネスアクターとビジネスユースケースの間で操作可能な関連を持たせない。筆者は、この矢印が個人的には好きだが、UMLのモデリングツールにIBM Rational Software Architect（RSA）を使う場合は、アクターとユースケースの間に矢印を描けない。これはRSAの問題ではない。コミュニケーションの関連が操作可能になっていないのはUML 2.0に原因がある。

　ビジネスユースケースモデルとシステムユースケースモデルの類似点を解説したので、後編では相違点を見ていこう。

本記事は「The Rational Edge」に掲載された「Business modeling with UML: Understanding the similarities and differences between business use cases and system use cases」をアットマーク・アイティが翻訳したものです。

著者プロフィール

Arthur V. English

Unisys Corporation　

シニア学習開発コンサルタント


「The Rational Edge」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ