ユースケース図にアクター、システム領域、ユースケース、関連線として表現されるものについて、ご理解いただけたと思います。
今回は、ユースケース記述についてのお話です。
ユースケース図は、
- どんなアクターがいるのか
- どんなユースケースがあるのか
- どのアクターがどのユースケースを利用するのか
- ユースケース同士は、どんな関係を持っているのか
でも、わかりやすい反面、シンプルすぎて、これだけでは細かい情報が欠けています。
図に書けない細かい情報を補足するものが、ユースケース記述です。
コンテンツ
ユースケース記述とは
でも、UML(2.0)では、実際の書き方は規定されていません。
自由に書いてください。おしまい。
…と言ってしまってはミもフタもありませんので、現在一般的だろうと思われる書き方をお話ししてみたいと思います。
一般的には、ユースケース記述には以下のようなことを書きます。
- ユースケース名
- この記述が、ユースケース図のどのユースケースと対応するか。
- アクター
- このユースケースを利用するアクター。
ユースケース図のアクター名と対応します。 - 概要
- このユースケースの概要の説明。
- 前提条件
- このユースケースを開始する前に満たすべき条件。
- イベントフロー
- このユースケースが実行される中で起こっていく出来事の流れ。
ソフトウェア開発では、抽象的な処理の流れと言うこともできます。
基本フローと、例外的な状況のための代替フローを記述します。 - 事後条件
- このユースケースが終了した後で満たされるべき条件。
ユースケース名
今回の場合、「料理を作る」ですね。
これが、このユースケース記述のタイトルになります。
一つのユースケース記述が、ユースケース図にある一つのユースケースに対応するということが、おわかりいただけるでしょうか。
アクター
今回の場合、「生徒」になります。
もし、利用しているアクターが複数ある場合は、それらを全て列挙します。
ユースケース図のユースケースの一つと、それに対応するユースケース記述は、同じことを、違う書き方で表現しているということができます。
概要
そして、ここからがユースケースを補足する、新しい情報の始まりです。
概要では、このユースケースが何をするものなのかの、簡単な説明をします。
ぱっと見てわかる程度の、簡潔な内容にしましょう。
一般的には、2～3行程度の量におさめるのが適度と言われています。
それって、1行何文字で？とか、細かいツッコミはなしで。
ぱっと見てわかる程度というところがミソです。
今回は、「お手本を見せながら、みんなで料理を作る。」というかんじにしておきましょうか。
前提条件
料理教室で、料理を作り始めるための条件って何でしょう？
「先生と生徒が揃っていること。」ですかね。
教室開始時刻がきていることを、条件に含めるかどうかは、微妙です。
メンバーが揃ってさえいれば、ちょっと早くてもはじめちゃうのか、それともあくまで定刻を守るのか。
今回、これを条件に含めなかったということは、ちょっと早くてもはじめちゃうかもしれないということを示しています。
このように、一見条件になりそうでも実はならなかったり、あるいはその逆だったりということはよくあります。
そのあたり、少し慎重に考えてください。
イベントフロー
ここでは、この料理教室で料理を作る際の、進め方ということになります。
料理教室によって、それぞれ進め方は違うと思いますが、ここでは、こんなふうに進めると考えてみましょう。
- 先生は(和気あいあいと、あるいはさりげなく)出席をとる。
- 先生はレシピ1)を配布する。
- 先生は食材2)の山を出す。
- 生徒は(レシピを確認しながら)食材の山から食材をとる。
- 先生と生徒は下ごしらえをする。
- 先生は料理のお手本を示す。
- 生徒は料理をする。
1) ユースケース「レシピを提供する」によって提供されるレシピ。これが「料理を作る」の基本フローです。
2) ユースケース「食材を提供する」によって提供される食材。
2つの注記については、前回のユースケース図を参照してみてください。
「料理を作る」ユースケースは、「レシピを提供する」と「食材を提供する」の2つを包含していますね。
この注記は、図上で示された2つのユースケースが、このイベントフロー上のどこにあたるのかを示したものです。
基本フローのすべての文章は、「誰は」から始まってますね。
日本語というのは、主語を省略しやすい言語です。
そのことが、日本語に、表現を簡潔にしたり、幅を広げたりといった、力をもたらしています。
反面、論理的な表現をする際には、正確さを欠き、誤解を招きやすくする原因になっているのです。
ですから、ここでは意図的に、主語をはっきり書くことになっています。
ところで、何事にも例外的な状況っていうのはあるものです。
たとえば、基本フローの1. で出席をとった結果、来ていない生徒さんがいた場合どうするのでしょう？
1. で来ていない生徒さんがいた場合の代替フロー
- 先生は来ていない生徒さんが欠席の連絡リストに含まれていないか確認する。
- 含まれていない場合、先生は電話で欠席の意志を確認する。
事後条件
今回の場合なら、「全員が(できは別として)料理が出来上がっている。」ですね。
「料理法を理解した」とか「レシピを憶えた」とかいうことは、終了条件に含めません。
料理そのものよりも、料理をしながらのおしゃべりの方に、より関心がある生徒さんだっているんですから。
前提条件と同じで、条件に入りそうで入らないことがありますので、こちらもちょっと慎重に考えてください。
まとめ
全部まとめてみましょう。
ユースケース名:
料理を作るアクター:
生徒概要:
お手本を見せながら、みんなで料理を作る。前提条件:
先生と生徒が揃っていること。イベントフロー:
基本フロー:事後条件:
- 先生は(和気あいあいと、あるいはさりげなく)出席をとる。
- 先生はレシピ1)を配布する。
- 先生は食材2)の山を出す。
- 生徒は(レシピを確認しながら)食材の山から食材をとる。
- 先生と生徒は下ごしらえをする。
- 先生は料理のお手本を示す。
- 生徒は料理をする。
1) ユースケース「レシピを提供する」によって提供されるレシピ。1. で来ていない生徒さんがいた場合の代替フロー:
2) ユースケース「食材を提供する」によって提供される食材。
- 先生は来ていない生徒さんが欠席の連絡リストに含まれていないか確認する。
- 含まれていない場合、先生は電話で欠席の意志を確認する。
全員が(できは別として)料理が出来上がっている。
ユースケース図のユースケースそれぞれには、背後にこんな説明を持っているんです。
ユースケース図を書くとき、一つ楕円を書くたびに、こんなにたくさんの説明を書かなくちゃならなくなるんじゃ、ちょっとうんざりですね。
そこで、最後に言っておきたいことは、「なにがなんでも、ユースケース図とユースケース記述の両方を書かなければならない!」…わけではないということです。
たとえば単純なコマンドを一つ作る場合など、アクター一つにユースケース一つしか、図に現れないかもしれません。
そんな図を描いても、あまり意味はないですよね。
また、図で読み取れる以上の情報がほとんど無いようなユースケース記述を書くことも、時間のムダですね。
公式な仕様書、設計書として形式を整える必要がある場合は別として、図か記述かのどちらかで事足りることもあるでしょう。
あなたは、開発チームのメンバーや、あるいは将来の自分とコミュニケーションをとる必要があり、そのためにUMLを書くわけです。
円滑にコミュニケーションをとるために、必要十分な量だけを書きましょう。
オススメ
UML学習のとっかかりに最適な本が、初めて学ぶUMLです。オブジェクト指向の基本に軽く触れた上で、UMLの一つ一つの図の基本的な書き方が、わかりやすく説明されています。
基本的な書き方がわかってきたから、もう少し実践的なことを学びたいという方は、UMLの本カテゴリを覗いてみてください。
また、優れた人が書いたUMLは、優れた設計例であるとともに、UMLの実践的な使用例でもあります。
オブジェクト指向の本にあるような本も、参考になさるといいと思います。
0 件のコメント:
コメントを投稿