2007年07月18日

ユースケース: 問題の分析

 オブジェクト指向で問題解決をする際、最初にすべきことは、問題そのものの分析です。

 ソフトウェアの開発も、問題解決の一手段ですね。
そして、ソフトウェア開発において「問題そのもの」とは、ビジネスプロセスのことです。

 問題を分析する際に役立つのが、ユースケースです。
ユースケースには、図と記述が含まれます。
今回は、図の方―ユースケース図についてお話しします。

コンテンツ

  1. サンプル
  2. アクター
  3. システム境界
  4. ユースケース
  5. 関連線
  6. 結果
  7. オススメ

サンプル

 まず最初に、サンプルとなる基本的なユースケース図をお見せします。
こんなかんじです。
ユースケース図 サンプル
 簡単な図ですね。
では、この図の書き方を、一つずつお話ししていきましょう。

アクター

 サンプルの図にアクター1、アクター2と書いてあるものは、この問題領域に登場する役割です。
英語のアクター(actor)は、俳優という意味で使われるのを、よく聞きますね。
何かの役割を演じる人です。
他に、「関係者」「行為者」という意味もあります。

 図に書くとき、アクターは簡単な人形のマークで表現されます。(この人形マークを、俗にスティックマンと言います)
ですので、ついついアクターに具体的な登場人物を書いてしまいがちです。
でも、これはあくまで役割であって、人ではないということを覚えておいて下さい。

 例として、あなたが料理教室を開くと仮定して、このことを詳しく見てみましょう。
この料理教室というものを、ユースケースで分析してみます。

 料理教室に登場する役割として、「生徒」というアクターが登場することは、すぐに想像できますね。
ここで注意しなければならないのは、もし山田さん、田中さん、鈴木さんという3人の生徒さんがいたとしても、この方達はユースケースには登場しないということです。
「山田さん」「田中さん」「鈴木さん」の3つではなく、あくまで「生徒」というアクターが1つだけ登場します。

 なぜなら、アクターはインスタンスではなく、クラスだからです。
山田さん、田中さん、鈴木さんは、「生徒」クラスのインスタンスですね。
だから、3人それぞれの名前ではなく、「生徒」という役割名を書くのです。

 「役割であって、人ではない」と言ったのは、こういう意味です。

 今回、この料理教室の問題を使ってお話を続けていきます。
もしお手すきであれば、最初のサンプルを参考に、実際に紙に図を書きながら読み進めてみて下さい。

システム境界

 サンプルの図にシステム境界と書いてあるものは、解決策に含まれるものと、そうでないものの境界線です。
ソフトウェア開発では、これはシステム(アプリケーション)と外界との境界線になります。

 あなたが料理教室を開くのは、問題を解決するためですね。
まぁ「ただ単にやってみたいから」とか言っちゃうとミもフタもないんですが。

 でももし、本当にあなたがやりたいだけで、料理教室がなんの問題も解決しないとなると、せっかく料理教室を開いても、生徒さんは集まりません。
生徒さんは、料理教室になにかの問題を解決してもらおうと思って集まってくるのです。
問題っていうのは、なにも頭を抱える悩み事みたいな、マイナスのことばかりではありませんよ。
例えば
  • 単身赴任しても自炊できるようになりたい
  • 家庭料理のレパートリーを増やしたい
  • 食べるのが好きだから、いろいろ作って食べたい
  • 料理が好きだから、いろんな料理を知りたい
  • 料理はどうでもいいけど、たくさんの人とお友達になりたい
てなかんじで、積極的でプラスなことも、問題と捉えることができます。
解決したいことは、全て問題です。

 こう考えると、料理教室に来る生徒さん達は、みんなそれぞれ、解決したい問題を持っているわけです。
あなたの料理教室は、こういういろんな問題に対する解決策です。

 「料理教室」という名前で、四角い大きめの枠を書きます。
「生徒」アクターは、料理教室という解決策の外に書きます。
アクターを外に書くのは、生徒さんが教室の外に締め出されてるとか、そういう意味じゃありませんよ。
アクター(生徒さん)は、解決策に含まれているのではなくて、解決策を利用する立場です。
枠の中には、解決策自体に含まれるものを書くんです。
だから、アクターは外です。

 はい、ではあなた自身は何なんでしょう?
「先生」という役割を演じますね。
つまり、「先生」というアクター?
違います。

 先生というのは、料理教室というものを利用する人―つまり生徒さんに対して、解決策を提供する人ですね。
先生は、解決策に含まれるものです。
だから、システム境界内です。

 ところで、アクターのお話では触れなかったのですが、ここでアクターについての新しい事実があります。
システム境界内には、アクターを書かないということです。
この図は、実は、解決策とそれを利用する人との関係に焦点を置いた図なのです。

 ユースケースの目的は、以下のようなことにあります。
  • 解決策を利用する人には、どんな役割の人がいるのかをはっきりさせる
  • それぞれの役割の人が、解決策をどう利用するのかをはっきりさせる

そういうわけで、解決策を提供する側の人、つまり解決策に含まれている人は、あえて書かないのです。

ユースケース

 サンプルの図にユースケース1、ユースケース2、ユースケース3と書いてある楕円形が、ユースケースです。
これがあるから、この図はユースケース図と呼ばれているわけです。
このことからもわかるとおり、これがこの図の中で一番重要なところです。
次回ご紹介するユースケース記述にも、直接影響するところですので、しっかり覚えておいて下さい。

 ユースケースは、解決策がアクターに対して提供する一つ一つの機能です。
機能と言っちゃうと、ソフトウェア開発者でない方には、なんだか小難しそうに感じるかもしれませんね。
違う言い方をしてみましょう。
解決策が、アクターにしてあげることです。
ちょっと漠然としちゃった気もしますが、この方が簡単に感じますね。

 あなたの料理教室は、生徒アクターになにをしてあげるべきでしょう?
「料理を作る」というのは当然ですね。料理教室なんですから。

 システム境界のところで列挙した、生徒さん達がもつ問題を振り返ってみて下さい。
そこから考えてみると、料理を作ること以外にも、以下のようなことをしてあげるべきでしょう。
  • 食材を提供する
  • レシピを提供する
  • 料理を作る
  • 食べる
  • おしゃべりする
これら全てについて、システム境界内に楕円を書いて、そこにすることを書き込みます。

 いかがですか?
最初にアクターをはっきりさせていたことで、アクターがもつ問題を検討することができました。
そして、そこから解決策に何が求められているのかがわかりましたね。

関連線

 最後に、関連線です。
サンプルの図を見ると、アクターとユースケースの間に線が引いてありますね。
これが関連線です。
どのアクターがどのユースケースを利用するのかということです。
アクターと、それが利用するユースケースの間に線を引きます。

 料理教室の例の場合、アクターは「生徒」だけですね。
ユースケースは、ユースケースのところで挙げました。
じゃあ、生徒から全部のユースケースに線を引けばいいのかな?
いいえ、違います。
生徒さんが直接利用するわけではないユースケースがあります。
  • 食材を提供する
  • レシピを提供する
の2つです。

 生徒さんは、料理を作るつもりで料理教室に来ます。
食材もレシピも、その中に含まれてはいますが、生徒さん自身は、あまりそれを意識してませんよね。

 生徒さんに「あなたは料理教室に何しにいくんですか?」と聞くと、「料理を作りにいきます」と答える人はたくさんいるでしょう。
でも、「食材を貰いにいきます」と答える人はあまりいないんじゃないでしょうか。
つまり、生徒さんが直接利用するのは料理を作ることであって、食材やレシピは、料理を作ることに含まれているわけです。

 そこで、「生徒」アクターと「食材を提供する」「レシピを提供する」以外の全てのユースケースの間に、関連線を引きます。

 じゃあ、「食材を提供する」と「レシピを提供する」は、宙ぶらりんでいいのかな?
もちろん、違います。

 もう一度サンプルを見て下さい。
ユースケースとユースケースの間にも、線がありますね。
これは、あるユースケースがあるユースケースに含まれる場合、またはあるユースケースを拡張する場合に引く関連線です。
「食材を提供する」と「レシピを提供する」は、「料理を作る」という行為に含まれてます。
こういう場合、「料理を作る」から「食材を提供する」と「レシピを提供する」に向かって矢印を引きます。

 拡張するというのはどういうことかというと、あるユースケースに拡張できるポイント―拡張ポイントがあって、別のユースケースを、そのポイントに当てはめることができるということです。
わかりやすく例を挙げると、こんなかんじでしょうか。

 学校の「1日分の授業を行う」というユースケースに対して、「各授業時間」というのが拡張ポイントです。
「国語の授業を行う」「数学の授業を行う」など、それぞれの授業を行うユースケースを、この拡張ポイントに当てはめることができます。
実際に当てはめを行うことで、時間割というのが決定されるわけです。
こういう場合、各授業が1日分の授業を拡張しますので、各授業から1日分の授業へ矢印を引きます。
含まれている場合と拡張する場合では、矢印の向きが逆になります。

 ところで、含まれる場合も拡張する場合も、同じように矢印を引きますね。
これだと、一見どれがどっちだかわかりにくいですね。
そこで、含まれる矢印の横には<< include >>と書きます。
includeとは、英語で含むという意味ですね。
で、拡張する場合には、矢印の横に<< extend >>と書きます。
extendとは、英語で拡張するという意味ですね。

 この、「<<」と「>>」で囲んで付けたメモを、ステレオタイプと言います。
これについてはおいおい説明しますが、他の図でも頻繁に出てくる書き方ですので、そういうものがあるんだということは覚えておいて下さい。

結果

 いかがですか?
料理教室のユースケース図は、できあがりましたか?
あなたが(紙の上にか、または頭の中に)描いたユースケース図を、下の図と比べてみて下さい。

 細かい配置や大きさなどは、気にしないで下さい。
そんなことはどうだっていいんです。
大切なのは、どう分析したのかということと、それがはっきりと伝えられるかどうかです。
料理教室のユースケース図

オススメ

 UMLをはじめて学ぶ方には、はじめて学ぶUMLがオススメです。

 私も、最初のとっかかりにはこの本を使いました。
私が読んだのは第1版だったんですが、第2版になって最新のUML仕様(バージョン2.0)にも対応したようですので、安心です。

 説明が丁寧で、わかりやすいです。
また、各章の終わりに練習問題がありますので、一歩一歩確実に理解していきたい人は、それを活用するといいでしょう。

 はじめて学ぶ人向けの本なので、これだけではソフトウェア開発の実務には、ちょっとつながりにくいところがあるかもしれません。
より実践的な知識が欲しい方は、これを読んだ後、もっと上級者向けで実践的な本も読むといいのではないでしょうか。
posted by craftsman at 15:09 | 東京 🌁 | Comment(4) | TrackBack(0) | UML
この記事へのコメント
「はじめて学ぶUML」持ってます!第1版ですが。

私のブログに、たまに登場する”エセUML”もこの本を参考にしているんです。f(^_^)
Posted by サンドラ at 2007年07月18日 20:57
 おー。
そうですか、持ってらっしゃいますか。

 「わかりやすい」というのは、最初は特に、重要なファクターですよね。
そういう意味で、「はじめて学ぶ〜」はいい本ですよね。

 その次には、どんな本を読んでらっしゃるのでしょうか?

UMLも、知れば知るほど、自分の思い描いたモデルを自在に表現できるようになって、楽しいですよね。
Posted by craftsman at 2007年07月19日 00:32
UMLに関する本は、「はじめて学ぶUML」しか持っていません。f(^_^;

これまでの、業務でUMLを利用した事がありませんでしたので、実はこれの魅力に気付いたのは、ここ最近です。

(^_^)/
Posted by サンドラ at 2007年07月19日 20:11
 サンドラさんの職場でも、はやくUMLが飛び交うようになるといいですね。

 必要なのは、的確に意思疎通ができることで、そのためのツールは何でもいいわけなんですが、でも、何か一つに統一されなければなりませんよね。

で、今なら、やはりUMLに統一するのが一番ですよね。
Posted by craftsman at 2007年07月19日 22:31
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。