ユースケースのケースって何？：ソフトウェア工学には頭脳が足りない：SSブログ

	ブログをはじめるログイン

「実践UML 第３版」と責務駆動設計｜このシリーズを始めた動機と意義ブログトップ

ユースケースのケースって何？　[頭脳役の不足] [編集]

さて「ソフトウェア工学には頭脳が足りない」シリーズの３回目。
今回こそ、ユースケースについてである。実を言うと私がUML関連の中で一番使うのがこのユースケースだ。そういう意味ではユースケース駆動開発信者と言えるが、実のところ、あまりユースケース図は描かない。少なくとも自分の推敲用に図を描きたいと思う事は滅多にない。とは言え、図の方が分かりやすい時もあるので、使わないというのも勿体ない話だ。なので最近になってユースケース図の改善に取り組み始めた。今回はその話をしよう。

そもそもユースケースって何？
ユースケースとは直訳すれば「使用事例」だが、事例と言うと語弊がある。「使われ方」と言えば良いのだろうか？正直、上手い日本語が見つからない。「事例」というと実際にあった事を連想するが、ユースケースは実際にはまだ起ってことを扱う。ソフトの「ある使われ方」を中心にして、ソフトウェアを作るために必要な情報を集約するのがユースケースだ。

ユースケースはふつうユースケース図とユースケース記述から成っている。
ユースケース図は簡単に言えば「誰が何をするのか」のみを示す。
ユースケース記述は「誰が何時どうやって何をするのか、問題が起きたとにはどうするのか、準備すべき事は？成果物は？関連する規則は？」と、関連するあらゆる事を記載する。

分類	要素名	説明
サマリー	種類	ビジネス or システム等
	ユースケース名
	要約
図要素	アクター	ユーザもしくは他システム
	システム	自システムの境界
	ユースケース	機能やサービス
フロー	基本フロー	使い方の代表例
	代替	その他の使い方
	例外	正常に処理されないケース
	拡張	プラスアルファ
詳細	トリガ	始まるきっかけ（必要ならガード条件も書く）
	仮定	装置外･システム外で成立しているべき条件
	事前条件	始まる前にシステム内で成立しているべき条件
	事後条件	次のステップのために成立させること
	関連するビジネスルール	業界･ユーザ特有の規則･慣習
シグネチャー	日付
	記録者
	バージョン

今回はそのうちの「ユースケース図」のほうを主に取り上げる。

ユースケース「図」の欠点
まずは、初回の反省から。
初回では現行のユースケース図について以下の様に述べている。

「…ユースケース図ではやはり頭脳に相当するのはアクターだけであり、判断を行う要素がシステムの外部にしか記述できない。つまり頭脳が足りない。」

自分で言うのもナンだが難しい。というか「頭脳が足りない」というお題目に引っ張られたせいか論点が少しズレている。
先程述べた通り、ユースケース図は「誰が何をするのか」のみを示す。上記の難解な文章はシステム内に頭脳を記述していない事を問題視しているが、それ以前に「なぜ？」という“理由やキッカケ”が表現されていない事を問題視すべきだろう。つまりユースケース図では人が脳みそを使って考えた事や判断した事が図のどこにも表現できていない。

ピンと来ない人も多いだろうが、これには大きな問題が含まれている。人は間違いを犯すが、結果だけを見ていては、それが間違っているのかどうか判断できない。つまり検証ができない。だからユースケース図からは正しく動くシステムを作る事が思いの外、難しい。

ユースケース・ドリブン（駆動）に似た手法に「マニュアル・ドリブン」と言う技法があるが、これは取扱説明書（マニュアル）を最初に作ってから、それに基づいて設計を進めるやり方である。プロダクトが無いうちに取扱説明書を作成するのは苦行だし、システム化が難しい要件を取込む可能性もあって、マニュアル・ドリブンは万人向けではない。が、使いやすい良いユーザーマニュアルは「状況別」に使用方法が書かれている。こうしたマニュアルを元に開発できれば確かに問題は起きにくいだろう。

（おまけ　ユースケース「図」のいやなとこ UMLのユースケース図の何が嫌って、図内の楕円に付けられた「ユースケース」という名前だ。ユースケース図でユースケースと呼ばれている楕円はどう見ても「機能」か「サービス」である。「使用者とサービス」の組合せを「使用事例／使用法」と呼ぶのは百歩譲って許せても、「機能やサービス」をなぜ「ユースケース」と呼ぶのか理解し難い。これは私の想像だが、たぶん、問題領域のユースケースでは楕円に「行為」を書くので、「行為」と「サービス」の両方の意味を含む言葉を探して「ユースケース」に落ち着いたのだろう。でも、これが自然な英語なのだろうか？とてもそうとは思えない。まぁ、私も「頭脳と方法の混同」と言う不思議な日本語で読者を混乱させているから、言葉の問題について他人のことはああこう言える立場ではないが。（苦笑））

ぶっちゃけ話
でも、ホントはそんなお堅い話ではなくて、個人的に気になっているのはユースケース図には「ケース」が書かれていないことだ。（ご想像通り、これはダジャレ・レベルの話である。）やっぱりユース「ケース」というなら「どういうケース（状況）で、誰が、どう使うのか」の3点ぐらいは図で表現してほしい。「誰に対するサービスなのか」を明らかにするだけなら「サービス図」と呼ぶべきだと思うのだが、いかがだろうか？

ちなみに図ではない「ユースケース」では「トリガ」等を記述することがデファクト・スタンダードになっており、これらが「状況」を補完している。だからユースケース記述まで合わせれば現状でも体裁は整っている。だからこそユースケースの推進者の多くはユースケース図よりユースケース記述を重視しているし、図の事はアイキャッチぐらいに考えている。
話を「図の改善」に戻そう。

イベントを入れよう

前回で「ユースケース図にも「イベント」を入れてほしい」と（括弧書きで）書いたが、先ほどの「トリガ」とこの「イベント」は"ほぼイコール"だ。でも少しだけ違う。人工知能の一種で、UMLの図にもなっているステートマシンでもイベントを扱うのでそちらを使って説明しよう。

ステートマシンでは「トリガ」と「ガード条件」がそろうと、イベントが発生し、状態が遷移する。言換えると、判断は「トリガ」から始まり「ガード条件」で絞り込まれ「イベント」で結実する。つまりトリガは「状況の一部」に過ぎない。それに対してイベントは前回述べた様に「判断」のシンボルだから、その判断の元となった状況も内包している。だから、「イベント」はユースケースとステートマシンをつなげるのに最適な要素だ。

ユースケースはステートマシンの「遷移」に相当する。だから、ユースケース図にイベントを追加するとステートマシン図と対にしてフローを追掛け易くなる。ただしフローも図に書かれていないので結局はユースケース記述が必要になる。（苦笑）
まあ、イベント入ユースケース図のメリットはこれだけには留まらないので、気を取り直して今度はそれを見ていこう。

PDCの対要素「BSP」
さて、今回もまたPDCが出てくる。PDCプロセスではそれらを遂行するために「頭脳、スキル、フィジカル」を使用すると前回書いた。今回はこちらも頭文字を取って「BSP」と呼ぶことにしよう。イベント入ユースケース図の３要素「イベント、サービス、アクター」はBSPに相当する。イベントは「判断のシンボル」なので背後の頭脳を指し示しているし、スキルが表に出る時にサービスに変わることは前回書いた。アクターがフィジカルなのは感覚的に分かるだろう。正確にはフィジカルに相当するのはアクターではないが、それについては後程述べる。

私はこのBSPに対応していると言う性質こそが「イベント入ユースケース図」の良さだと思っている。
さて、本番はここからだ。今まで以上に抽象的な話になるが、ガンバって付いてきてほしい。
イベント入ユースケース図がBSPに相当するなら、これを使ってPDCプロセスを回すことができることになる。イベントを介してステートマシン（＝人工知能）と繋げられることは書いた。つまりB＝頭脳を使ってPlanningができる。また、サービス（＝関数群）を使って処理の実行ができる。チェックはアクターとやり取りするデータを使って行う。

このようにイベント入ユースケース図はPDCプロセスに対応している。PDCは業務プロセスなどでビジネスパーソンも馴染み深いものだから、イベント入ユースケース図はビジネスパーソンでもちょっとの訓練で思考の道具として使える様になるだろう。例えば「判断要素が足りているか」、「判断と実行内容に齟齬が無いか」「業務プロセスの最後に誰が何をチェックすれば良いのか」と言ったことを考える材料になる。それも個別に考えるのではなく、ユースケース毎に集約的に考えることができる。これこそがユースケース図にイベントを入れることのメリットだ。

BSPを入れ子化する
さて、実を言うと先ほどのイベント入ユースケース図とPDCの説明にはいくつかの穴がある。例えばユーザ（＝アクター）はどうやって意志をシステムに伝えるのだろうか？またチェックすべき実行結果はどこにあるのだろうか？これらはユーザ・インタフェースの問題で、ロバストネス分析を使ってこれらを表現することもできるが、ここでは「イベント入ユースケース図」をロール（役割）別に固めて入れ子化する方法を用いて表現してみよう。

でもその前にまず「イベント入ユースケース図」を使うをやめよう。元々私が「イベント入ユースケース図」を考えた理由はBSPに対応付けるためだったのだから、ここからは「イベント入ユースケース図」の代りにBSPそのものを表現した「ユースケースBSP図（仮称。他の候補は“BSP要素図”）」を使うことにする。B要素には頭脳（≒人工知能）とイベント（＝判断結果）が入る。S要素はサービスや行為や「スキル」とする。F要素はアクターではなく、アクターとやり取りするデータとする。そしてBSP３つを内包する「ロール（役割）」をアクターとする。BSPは元々人の構成要素のメタファだし、アクターも人のメタファだからこの定義は矛盾しない。コンピュータシステムもBSPで表せるからアクターとして扱える。それからBSPは入れ子にできる。例えばB要素をBSPに細分化したりすることができる。

BSPは前回述べた様にPDCに対応する。PDCが入れ子になればBSPも入れ子になる。一連のPDCサイクルに対応するBSPは１つのロールとして括ることができる。また、BSPには仕掛けと結果の両方が含まれる。言換えればBSPを使ってPDCを行うが、PDCの結果もBSPとなる。例えばBrain要素には頭脳と判断結果の両方が含まれるし、Skillsにはスキルと行為が含まれる。Physicalには入力フォームも出力データも含まれる。本来両者は別ものだが後行程から見ると「結果」だけが見える。だから両者を同一視する。これは「関数」と「関数の戻り値」を式の中で同一視するのと同じ事だ。

さあ、準備はできた。新しい道具、ユースケースBSP図（仮称）を使ってユーザ・インタフェースを「見える化」しよう。以下の図がユーザ・インタフェースの「ユースケースBSP図（仮称）」だ。（そろそろ仮称は取ろうか。）見た目が洗練されていないのは考察中の図法なのでご容赦いただきたい。

まず、ユーザは相変わらずアクターだ。ただし大きなBSPの"P要素"も兼ねている。これはユーザの意図がB要素として表に出て、かつ、システムがサービスとして振舞っているからだ。大きいBSPをロールとしてみる必要はない。システムの中はBSPに分かれていて、PにはGUI、Bにはイベント、Sには関数等が割り当てられる。システムの外から見るとPは常にインタフェースだ。システムのロールがサービスの時はPは大抵GUIになるが別にCUIとか他のインタフェースでも構わない。一方、システム内から見るとPは操作対象であり、データだ。つまりP要素は外から見るとGUIでうちから見るとデータという２面性を持っている。

GUIとデータが「MVCモデル」や「PBD層モデル」では全く別物なのはご存知の通りである。このため、MVCモデル等とBSPの相性はあまり良くない。でも忘れないでほしいのは「MとV」、「PとD」の内容は必ず同期しなければならない事だ。これがズレたシステムは使い物にならない。そういう意味ではMVCモデル等とBSPは補間し合う関係にあると言える。

それでもやっぱりユースケース
さて、ユースケース図の拡張のはずが「ユースケースBSP図」という新しい図になってしまった。いや、正直に言おう。最初からユースケースBSP図に持っていくつもりだった。「頭脳が足りない」というシリーズ名からはイササか外れるかもしれないが（笑）、元々やりたいことはPDCプロセスとBSPを使って、新しい時代にふさわしい設計パラダイムを考える事にある。イベントなどは旧時代の設計パラダイムからはみ出した技術要素であって、それらをオブジェクト指向をベースにしたUMLに付け足す事は初めから本意ではない。「頭脳とスキルの混同」もオブジェクト指向で顕著に起きている現象であって、いわばオブジェクト指向を否定するための道具だ。もちろん、PDCやBSPでも表現できない事が沢山あるから、「頭脳とスキルの混同」を問題にする事は天にツバする行為だろう。つまりユースケースBSP図もいずれ否定される運命にある。でもだからって、それが足踏みする理由にはならない。少なくとも私には目の前の道具が物足りなく思う。だから改善するし、そのことを伝えるためにキツい表現も使う。

話をユースケースBSP図に戻そう。
図は大きく様変わりしたが、それでもセットになるのは「ユースケース記述」で、こちらはあまり変わらない。トリガがイベントになり、必要なら親や子のBSP（＝ユースケース）とロール（親ユースケース内での役割：Plan, Do, Check等）を記述することになるが、その他は変わらない。相変わらず、どのフローを基本に据えてどれを代替にするか悩むだろうし、関連するビジネスルールを探すのに四苦八苦するだろう。それでもB要素やロールの明示、ロールの入れ子化、PDCとの対応はユースケースの役割をより明らかにしてくれる。

責務駆動設計やPDCへの広がり
「ロール」という言葉からピンと来た人もいるだろうが、ユースケースBSP図は前回も話題に上った「責務駆動設計」に呼応している。「責務駆動設計」と言うのはレベッカ・ワースブラック等による著書「オブジェクトデザイン　ロール、責務、コラボレーションによる設計技法」に記された、複雑なシステムをシンプルに分解する設計手法だ。「オブジェクト・・・・」というタイトルなのに徹底した擬人化手法が特徴で、難しいシステムを設計する人たちの間ではかなり名前の通った設計手法である。「責務駆動設計」というとCRCカードのイメージがあるが「ロール、責務、コラボレーション」に留意しながら設計すれば、それは「責務駆動設計」と呼んで良いだろう。ユースケースBSP図では「ロール、責務、コラボレーション」を表現できる。

この様にユースケースBSP図は責務駆動設計のおかげで詳細設計との対応が明確だし、PDCのおかげで要件との関係も明確になる。だから従来のユースケース図に混乱していた技術者でも少しは使いやすいだろう。ま、「責務駆動設計」を勉強しなきゃならないのは仕方がない。「責務駆動設計」は抽象的でプログラマーがいきなり習得するのは骨が折れる事は申し添えておく。でも、それはオブジェクト指向思想だって同じ事だ。

ちなみに「責務駆動設計」はUMLより古くからある設計手法だが、ロールには基本となるステレオタイプがあって、その中には「判断と指示」を行う「制御役（＝頭脳役）」もある。何という先見性だろう。だから私は「責務駆動設計」が好きだ。
ロールの基本ステレオタイプには「情報保持役、構造化役、サービス提供役、調整役、制御役、インタフェース役」の６つがあって、「BSPおよびアクター」とピッタリ符合するモノも、しないモノもあるが、どれがどれに相当するのか自分で考えてみてほしい。ヒントを出すと最初の２ロールはどれにでも当てはまる。

最後にユースケースBSP図に対応したユースケース記述の項目例を挙げておく。

「ユースケースBSP図に対応したユースケース記述の項目例」

分類	要素名	説明
サマリー	種類	ビジネス or システム等
	ユースケース名
	要約
図要素	ロール	アクターもしくはシステム
	ブレイン	イベント、判断結果
	サービス	UMLではユースケース
	リソース（フィジカル）	サービスの操作対象。必要ならGUIも含む。
位置付け	親ユースケース（存在するなら）
	役割	親ユースケース内での役割：Plan, Do, Check等
	子ユースケース（必要なら）
フロー	基本フロー	使い方の代表例
	代替	その他の使い方
	例外	正常に処理されないケース
	拡張	プラスアルファ
詳細	トリガ	始まるきっかけ（必要ならガード条件も書く）
	仮定	装置外･システム外で成立しているべき条件
	事前条件	始まる前にシステム内で成立しているべき条件
	事後条件	次のステップのために成立させること
	関連するビジネスルール	業界･ユーザ特有の規則･慣習
シグネチャー	日付
	記録者
	バージョン

さて、今回はここでオシマイ。

次回は「このシリーズの意義について」ちょっと畏まった話をする。

できるだけ分かりやすく書くつもりだが、何分、かなり先で取扱う様な話も含まれているので、理解するのに苦労するかもしれない。まぁ、読まなくても先で同じ事を詳しく扱うから、次回はお休みでも構わない。

まあ、ともかく次回をお楽しみに。