2007-07-18

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

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

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

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

コンテンツ

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

サンプル

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

アクター

サンプルの図にアクター1、アクター2と書いてあるものは、この問題領域に登場する役割です。
英語のアクター (actor) は、俳優という意味で使われるのを、よく聞きますね。
俳優というのは、何かの役割を演じる人です。
actor には、他に「関係者」「行為者」という意味もあります。
図に書くとき、アクターは簡単な人形のマークで表現されます。(この人形マークを、俗にスティックマンと言います)
ですので、ついついアクターに具体的な登場人物を書いてしまいがちです。
でも、これはあくまで役割であって、人ではないということを覚えておいて下さい。
例として、あなたが料理教室を開くと仮定して、このことを詳しく見てみましょう。
この料理教室というものを、ユースケースで分析してみます。
料理教室に登場する役割として、「生徒」というアクターが登場することは、すぐに想像できますね。

ここで注意しなければならないのは、もし山田さん、田中さん、鈴木さんという3人の生徒さんがいたとしても、この方達はユースケースには登場しないということです。
「山田さん」「田中さん」「鈴木さん」の3つではなく、あくまで「生徒」というアクターが1つだけ登場します。
なぜなら、アクターはインスタンスではなく、クラスだからです。
山田さん、田中さん、鈴木さんは、「生徒」クラスのインスタンスと言えますね。
だから、3人それぞれの名前ではなく、「生徒」という役割名を書くのです。
「役割であって、人ではない」と言ったのは、こういう意味です。
今回、この料理教室の問題を使ってお話を続けていきます。
もしお手すきであれば、最初のサンプルを参考に、実際に紙に図を書きながら読み進めてみて下さい。

システム境界

サンプルの図にシステム境界と書いてあるものは、解決策に含まれるものと、そうでないものの境界線です。
ソフトウェア開発では、これはシステム(アプリケーション)と外界との境界線になります。
あなたが料理教室を開くのは、問題を解決するためですね。
まぁ「ただ単にやってみたいから」とか言っちゃうとミもフタもないんですが。
でももし、本当にあなたがやりたいだけで、料理教室がなんの問題も解決しないとすると、せっかく料理教室を開いても、生徒さんは集まりません。
生徒さんは、料理教室になにかの問題を解決してもらおうと思って集まってくるのです。
問題っていうのは、なにも頭を抱える悩み事みたいな、マイナスのことばかりではありません。
例えば
  • 単身赴任しても自炊できるようになりたい
  • 家庭料理のレパートリーを増やしたい
  • 食べるのが好きだから、いろいろ作って食べたい
  • 料理が好きだから、いろんな料理を知りたい
  • 料理はどうでもいいけど、たくさんの人とお友達になりたい
てなかんじで、積極的でプラスなことも、問題と捉えることができます。
解決したいことは、全て問題です。
こう考えれば、料理教室に来る生徒さん達は、みんなそれぞれ解決したい問題を持っているといえます。
あなたの料理教室は、こういういろんな問題に対する解決策です。
そこで、「料理教室」という名前で、四角い大きめの枠を書きます。
「生徒」アクターは、料理教室という解決策の外に書きます。
アクターを外に書くのは、生徒さんが教室の外に締め出されてるとか、そういう意味ではありません。
アクター(生徒さん)は、解決策に含まれているのではなくて、解決策を利用する立場です。
枠の中には、解決策に含まれるものを書きます。
だから、アクターは外です。

はい、ではあなた自身は何なんでしょう?
「先生」という役割を演じますね。
つまり、「先生」というアクター?
違います。
先生というのは、料理教室というものを利用する人―つまり生徒さんに対して、解決策を提供する人ですね。
先生は、解決策に含まれるものです。
だから、システム境界内です。
以上のことで、おわかりかと思いますが、システム境界内には、アクターを書きません
ユースケース図は、システムとアクター、つまり解決策と利用者との関係に焦点を置いた図なのです。
ユースケースの目的は、以下のようなことにあります。
  • 解決策を利用する人には、どんな役割の人がいるのかをはっきりさせる
  • それぞれの役割の人が、解決策をどう利用するのかをはっきりさせる

ユースケース

サンプルの図にユースケース1、ユースケース2、ユースケース3と書いてある楕円形が、ユースケースです。
これがあるから、この図はユースケース図と呼ばれています。
このことからもわかるとおり、この楕円形がこの図の中で一番重要なところです。
ユースケースは、解決策がアクターに対して提供する一つ一つの機能です。

さて、話を料理教室に戻してみましょう。
あなたの料理教室は、生徒アクターになにをしてあげるべきでしょう?
「料理を作る」というのは当然ですね。料理教室なんですから。
他には?
システム境界のところで列挙した、生徒さん達がもつ問題を振り返ってみて下さい。
そこから考えてみると、料理を作ること以外にも、以下のようなことをしてあげるべきでしょう。
  • 食材を提供する
  • レシピを提供する
  • 料理を作る
  • 食べる
  • おしゃべりする
これら全てについて、システム境界内に楕円を書いて、そこにすることを書き込みます。
いかがですか?
最初にアクターをはっきりさせていたことで、アクターがもつ問題を検討することができました。
そして、そこから解決策に何が求められているのかがわかりましたね。

関連線

最後に、関連線です。
サンプルの図を見ると、アクターとユースケースの間に線が引いてありますね。
これが関連線です。
どのアクターがどのユースケースを利用するのかということを表しています。
料理教室の例の場合、アクターは「生徒」だけですね。
ユースケースは、ユースケースのところで挙げました。
じゃあ、生徒から全部のユースケースに線を引けばいいのか?
いいえ、違います。
生徒さんが直接利用するわけではないユースケースがあります。
  • 食材を提供する
  • レシピを提供する
の2つです。
生徒さんは、料理を作るつもりで料理教室に来ます。
食材もレシピも、その中に含まれてはいますが、生徒さん自身は、あまりそれを意識してませんよね。
生徒さんに「あなたは料理教室に何しにいくんですか?」と聞くと、たいていの人は「料理を作りにいきます」と答えるでしょう。
でも、「食材を貰いにいきます」とか「レシピを貰いにいきます」と答える人は、あまりいないんじゃないでしょうか。
つまり、生徒さんが直接利用するのは料理を作ることであって、食材やレシピは、料理を作ることに含まれているわけです。
そこで、「生徒」アクターと「食材を提供する」「レシピを提供する」以外の全てのユースケースの間に、関連線を引きます。
では、「食材を提供する」と「レシピを提供する」は、宙ぶらりんでいいのか?
もちろん、違います。
もう一度サンプルを見て下さい。
ユースケースとユースケースの間にも、線がありますね。
これは、あるユースケースがあるユースケースに含まれる場合、またはあるユースケースを拡張する場合に引く関連線です。
「食材を提供する」と「レシピを提供する」は、「料理を作る」という行為に含まれてます。
こういう場合、「料理を作る」から「食材を提供する」と「レシピを提供する」に向かって矢印を引きます。
拡張するというのはどういうことかというと、あるユースケースに拡張できるポイント―拡張ポイントがあって、別のユースケースを、そのポイントに当てはめることができるということです。
わかりやすく例を挙げると、こんなかんじでしょうか。
学校の「1日分の授業を行う」というユースケースに対して、「各授業時間」というのが拡張ポイントです。
「国語の授業を行う」「数学の授業を行う」など、それぞれの授業を行うユースケースを、この拡張ポイントに当てはめることができます。
実際に当てはめを行うことで、時間割というのが決定されるわけです。
こういう場合、各授業が1日分の授業を拡張しますので、各授業から1日分の授業へ矢印を引きます。
含まれている場合と拡張する場合では、矢印の向きが逆になります。
ところで、含まれる場合も拡張する場合も、同じように矢印を引きますね。
これだと、一見どれがどっちだかわかりにくいですね。
そこで、含まれる矢印の横には << include >> と書きます。
include は、英語で含むという意味ですね。
で、拡張する場合には、矢印の横に << extend >> と書きます。
extend は、英語で拡張するという意味ですね。
この、「<<」と「>>」で囲んで付けたメモを、ステレオタイプと言います。
これについてはおいおい説明しますが、他の図でも頻繁に出てくる書き方ですので、そういうものがあるんだということは覚えておいて下さい。

結果

いかがでしょうか?
料理教室のユースケース図は、できあがりましたか?
あなたが(紙の上にか、または頭の中に)描いたユースケース図を、下の図と比べてみて下さい。
細かい配置や大きさなどは、気にしないで下さい。
そんなことはどうだっていいんです。
大切なのは、どう分析したのかということと、それを誰かにはっきりと伝えられるかどうかです。

オススメ

 UMLをはじめて学ぶ方には、はじめて学ぶUMLがオススメです。
私も、最初のとっかかりにはこの本を使いました。
私が読んだのは第1版だったんですが、第2版になって最新のUML仕様(バージョン2.0)にも対応したようですので、安心です。
説明が丁寧で、わかりやすいです。
また、各章の終わりに練習問題がありますので、一歩一歩確実に理解していきたい人は、それを活用するといいでしょう。
はじめて学ぶ人向けの本なので、これだけではソフトウェア開発の実務には、ちょっとつながりにくいところがあるかもしれません。
より実践的な知識が欲しい方は、これを読んだ後、もっと上級者向けで実践的な本も読むといいのではないでしょうか。
Top
2013-03-5
リンクと、説明の端々を改訂しました。

4 件のコメント:

  1. 「はじめて学ぶUML」持ってます!第1版ですが。
    私のブログに、たまに登場する”エセUML”もこの本を参考にしているんです。f(^_^)

    返信削除
  2. おー。
    そうですか、持ってらっしゃいますか。
     「わかりやすい」というのは、最初は特に、重要なファクターですよね。
    そういう意味で、「はじめて学ぶ~」はいい本ですよね。
     その次には、どんな本を読んでらっしゃるのでしょうか?
    UMLも、知れば知るほど、自分の思い描いたモデルを自在に表現できるようになって、楽しいですよね。

    返信削除
  3. UMLに関する本は、「はじめて学ぶUML」しか持っていません。f(^_^;
    これまでの、業務でUMLを利用した事がありませんでしたので、実はこれの魅力に気付いたのは、ここ最近です。
    (^_^)/

    返信削除
  4. サンドラさんの職場でも、はやくUMLが飛び交うようになるといいですね。
     必要なのは、的確に意思疎通ができることで、そのためのツールは何でもいいわけなんですが、でも、何か一つに統一されなければなりませんよね。
    で、今なら、やはりUMLに統一するのが一番ですよね。

    返信削除

Related Posts Plugin for WordPress, Blogger...