UMLを使ったビジネスモデリング(前編):なるほど! ビジネスユースケース:The Rational Edge(2/2 ページ)
The Rational Edgeより:IBM Rational Software Architectをはじめとする各種モデリングツールではユースケースのモデリングにどのUML図を使うのかなど、ビジネスユースケースとシステムユースケースの相違点と類似点について学ぶ。
ビジネスユースケースモデルとシステムユースケースモデルの類似点は?
ビジネスユースケースモデルは、いろいろな意味でシステムユースケースモデルと非常に似通っている。両モデルともにユースケース仕様がある。ビジネスユースケース仕様とシステムユースケース仕様のRUPテンプレートを調べると、フォーマットがかなり似通っていることが分かる。いずれにも、「Preconditions(前提条件)」「Postconditions(事後条件)」「Extension Points(拡張ポイント)」、そして「Special Requirements(特殊要件)」がある。ビジネスユースケース仕様には、基本の「Flow of Events(イベントフロー)」や「Alternative Flows(代替フロー)」ではなく、基本ワークフローと代替ワークフローがある。
ビジネスとシステムの両ユースケース仕様のフォーマットは酷似しているが、設計の狙いが異なっている。ビジネスユースケースを設計する狙いは業務活動だ。つまり、組織外のビジネスアクターがビジネス組織の事業目標を達成することだ。RUPによるビジネスユースケースの定義は以下のようになる。
「『ビジネスユースケース』は外部の付加価値の視点からビジネスプロセスを記述する。『ビジネスユースケース』は、ビジネスアクターに価値を提供するために組織の領域を超え、パートナーやサプライヤーまでも含まれることのあるビジネスプロセスである」
簡潔ではあるが、この定義は以下のような重要なポイントをいくつか明らかにしている。
- ビジネスユースケースはソフトウェアシステムプロセスではなくビジネスプロセスを示す
- ビジネスユースケースは利害関係者に価値を提供する。利害関係者とは、アクターもしくは業務従事者を指す
- ビジネスユースケースは組織の枠組みを超えることができる。中にはこのポイントをあまりに文字通りに取り過ぎてしまうアーキテクトもいる。多くのビジネスユースケースは実際に組織の枠組みを超えるが、1つの組織にだけ重点を置くビジネスユースケースもある。いくつかの例は後述する
Podeswaの著書である「UML for the IT Business Analyst:」の中のビジネスユースケースの定義も考察しよう。
「ビジネスユースケース:ビジネスの中の具体的なワークフローを示すビジネスプロセスであり、事業目標を達成する業務と利害関係者のやりとりであって、手作業と自動化されたプロセスの両方が考えられ、長時間にわたって展開される場合もある」
この定義は、事業目標を達成することで価値を提供するという考え方を説明している。手作業と自動化されたプロセスの両方が関係する具体的なワークフローとしてビジネスプロセスを定義することにより、RUPの定義を拡大している。この定義は、ワークフローが長時間にわたる可能性があることも指摘している。これらはすべて極めて重要なポイントだ。
では、システムユースケースの方はどうか? システムユースケースを設計する狙いは、コンピュータシステムを設計することだ。システムアクターがコンピュータシステムによって目標を達成することがその狙いだ。システムユースケースは、アクターとコンピュータ技術とのやりとりを示すものであって、ビジネスプロセスとのやりとりを示すものではない。
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に原因がある。
ビジネスユースケースモデルとシステムユースケースモデルの類似点を解説したので、後編では相違点を見ていこう。
著者プロフィール
Arthur V. English
Unisys Corporation
シニア学習開発コンサルタント
- トランザクション管理の複雑性を克服する(パート1)
- アジャイルとシステムテストの新たな関係(後編)
- アジャイルとシステムテストの新たな関係(前編)
- アジャイル開発の広範な普及を目指して
- 見積もりの精度 Accuracy of Estimation
- 複雑性を理解する(後編):ソフトウェアの複雑性を手なずける
- 複雑性を理解する(前編):ソフトウェアが複雑なのは仕方がない?
- 鈍重な開発チームは鈍重なシステムを作る?/パート3:役割とポリシー(後編)
- 人事評価と開発者のモチベーション/パート3:役割とポリシー(中編)
- 自己管理型チームの利点と弱点/パート3:役割とポリシー(前編)
- プロセスはチャンスが訪れるたびに改善する/パート2:プロセスと基準(後編)
- 開発プロセス導入のアンチパターン/パート2:プロセスと基準(中編)
- 反復開発の「ここはぜひカバーしたいポイント」/パート2:プロセスと基準(前編)
- 開発プロジェクト「統治」のピンポイント解説/パート1:原則と組織(後編)
- 開発プロジェクトを「統治」するベストプラクティス/パート1:原則と組織(前編)
- 初歩の「Perl」「Python」「Ruby」
- ビルドが全滅する原因/プロジェクトの状態を評価する:パート2(後編)
- 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する:パート2(前編)
- UMLを使ったビジネスモデリング(後編):そうだったのか! システムユースケース
- UMLを使ったビジネスモデリング(前編):なるほど! ビジネスユースケース
- 「この開発プロジェクトは中止!」の基準/プロジェクトの状態を評価する:パート1(後編)
- プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する:パート1(前編)
- 専門家に聞くモデル駆動開発のメカニズム
- 「設計」や「構築」よりも重宝されるスキル
- キミのコードが汚い理由
- 汎用グラフィカルモデリング言語「SysML」 パート2:グラフィカルなモデル言語で製品構造を記述
- 汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリング
- ウォーターフォールから反復型への移行手順
- ソフトウェアアーキテクティングのメリット
- ソフトウェアアーキテクティングのプロセス
- ソフトウェアアーキテクトの役割
- ソフトウェアアーキテクチャって何なの?(後編)
- ソフトウェアアーキテクチャって何なの?(前編)
- ITプロジェクトを見える化する
- ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由(後編)
- 隣のテストチームが優秀ないくつかの理由(前編)
Copyright © ITmedia, Inc. All Rights Reserved.