UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース：The Rational Edge（3/3 ページ）

[Arthur V. English（Unisys Corporation シニア学習開発コンサルタント），＠IT]

◆ ビジネスユースケースモデルとシステムユースケースモデルの関係は？

図7 ビジネスユースケースからシステムユースケースへの流れ （クリックすると拡大）：「ビジネスユースケースからシステムユースケースへの流れ」は、筆者が教えるIBM Rationalコース、「Mastering Requirements Management with Use Cases（ユースケースを使った要件管理のマスター）」から転用したもの

　図7は、この図の理解に必要な基本原理の大半が標準コースの教材ではカバーされていないために本コースで教えるのが最も難しい話題を詳細に示している。この新たな基本原理を提供することも本稿の目的の1つだ。

　図7は、ビジネスモデルにあるものと、各自のシステムユースケースモデルにあるものを明確にマッピングしている。この特定の例では、システムが業務従事者の作業を自動化できることが示されている。また、重要な業務従事者が自動化の候補になっていることも示されている。

　ビジネスモデルがビジネスユースケースモデルとビジネス分析モデルの両方で構成されていることを覚えておきたい。ビジネス分析モデルはビジネスユースケースモデルを描写したものであり、密接に統合され、トレーサビリティがある。システムユースケースモデルはビジネス分析モデルにさかのぼることができる。そして、ビジネス分析モデルはビジネスユースケースモデルにさかのぼることができる。

　このアプローチを使えば、ビジネス分析モデルから下へと流れたシステムユースケースモデルを構築することができる。これにより、UMLモデル全体で一貫性とトレーサビリティが実現する。

　では、システムアクターとシステムユースケースはどこから来ているのだろうか？ システムアクターは、ビジネス分析モデルのビジネスアクターと業務従事者を基本にして作成されている。業務従事者の自動化候補とやりとりするビジネスアクターは、常にシステムアクターになる。また、業務従事者自動化候補とやりとりはするが自動化候補ではない業務従事者は、システムアクターになる。例えば、ISMビジネス分析モデルの「警察」と「裁判所」はシステムアクターになる。ISM Brokerは「純粋な」自動化候補であり、これがシステムアクターになることはない。

　ここで筆者が使った「純粋な」とはどういう意味だろうか？ それは、開発中のソフトウェアソリューションの代用になることが自動化候補の唯一の目的であることを意味する。図7の「ローン担当者」に注目したい。「ローン担当者」という業務従事者は、システムアクターにもシステムユースケースにも変化する。説明しよう。

　「ローン担当者」は図7で示されるビジネスモデルの役割の1つだ。ここのシステムユースケースモデルでは、「ローン担当者」の役割を担うアクターが必要だ。しかし、新たに開発中のソフトウェアソリューションでは「ローン担当者」の業務のいくつかについて自動化も進めている。ビジネス分析モデルの中のこれらの業務が、システムユースケースモデルの中のシステムユースケースになる。

　このほかの純粋な業務従事者の自動化候補は、システムユースケースモデルのシステムアクターには変化しない。これが、「システムユースケースはどこから来ているのだろうか？」という疑問に対する回答だ。システムユースケースは、ビジネス分析モデルにおいて業務従事者自動化候補の業務をベースにして作成される。図5を見ると、VOPC図からISM Brokerや「情報の問い合わせ」などの各業務がシステムユースケースモデルのシステムユースケースに変換されるのが分かる。

　分析モデルは、ビジネス要素がシステム分析モデルのクラスにマッピングされる様子を示している。これらのクラスは、システムが処理する「データ」を示しているのだ。

---

　システムユースケースのモデリングと比較したRUPビジネスモデリングの概要を説明するのが筆者の目標だった。ここまで、類似点と相違点のほか、ビジネスユースケースモデルとシステムユースケースモデルの間の関係を解説した。これらの比較や関係について質問があれば、[e-mail]まで問い合わせていただきたい。

---

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

---

［参考文献］

1.　「Writing Effective Use Cases」、Cockburn, Alistair 著、2001年Addison-Wesley刊

2.　「UML for the IT Business Analyst」、Podeswa, Howard著、2005年Thomson Course Technology刊

3.　「Business Modeling with UML: Business Patterns and Business Objects」、Eriksson, Hans-Erik、Magnus Penker共著、1999年Wiley刊

4.　「Effective Business Modeling with UML: Describing Business Use Cases and Realizations」、Ng, Pan-Wei著、2002年Rational Edge

5.　「The Unified Modeling Language Reference Manual, Second Edition」、Booch, Grady, Jacobson, Ivar, Rumbaugh,James共著、2005年Addison-Wesley刊

---

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート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プロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）