TOC
単語
相互作用 | そうごさよう | 互相作用 | |
契約 | けいやく | 合同,协议 | |
(開発)しようとする | 正要(开发)的 | ||
駆動する | くどう | 驱动 | |
現場 | げんば | ||
境界 | きょうかい | 边界 | |
手段 | しゅだん | 手段,手法 | |
アクター | actor | 使用者,参与者 | |
人形 | ひとがた | 拟人的图标 | |
接続線 | せつぞくせん | 连接线 | |
車両見積作成 | 记录车辆问价 | ||
営業マン | 营业员 | ||
結ぶ | むすぶ | 连接 | |
うまく(表現)できない | 不能很好地(表现) | ||
包含 | ほうがん | 包含,包括 | |
拡張 | かくちょう | 扩张,扩充 | |
拡張子 | かくちょうし | 后缀 | |
イベント・フロー | event flow | 事件流 | |
シナリオ | scenario | 情景 | |
インスタンス | instance | 实例 | |
流れ | ながれ | 流程 | |
基本フロー | きほん | 基本流程 | |
代替フロー | だいたい | 替代流程 | |
例外フロー | れいがい | 例外流程 | |
表す | あらわす | 表现,表达,表示 |
ポイント
-
了解しました・わかりました・承知しました・かしこまりました
-
十分ではありません。
会話
会話の背景
- ユーザーの要求を明確に記述するために、ユースケースを書く。
- ユースケースはシステムと外部との相互作用を表現するもので、システムの機能仕様であり、あるいは、ユーザーと開発者間の契約とも言える。なぜなら、これらは、われわれが開発しようとするシステムが、どのようになるかをユーザーに説明するもので、ユーザーとのコミュニケーションの大事な手段ともなる。また、ユースケースはシステム開発プロセスを駆動する中心的なドキュメントでもある。
登場人物
- 鈴木:開発チームリーダー
佐藤、田中:開発チームメンバー
会話内容
-
鈴木:
- おはようございます。
- これまでに、われわれはユーザーの要求をよく聞き、現場の資料も集めました。これからは、もっと厳密にユーザーの要求を記述しなければなりません。そのために、これからユースケースを書いて、要求を整理しましょう。
-
佐藤:
- ユースケースについて聞いたことがありますが、実際に書いたことがありませんので、簡単に、紹介してもらえますか?
-
鈴木:
- そうですね。ユースケースは、われわれがこれから開発しようとするシステムの機能をユーザーに説明するの手段です。ユースケースでは、さらにシステムの境界を定義します。つまり、誰がこのシステムを使い、このシステムがどこまでの機能を持つのかということを定義します。
-
佐藤:
- 分かりました。でも、どんなドキュメントを書くでしょうか?
-
鈴木:
- ユースケースのドキュメントは2つの種類があります。まずはユースケース図です。2番目は ユースケース記述です。
-
佐藤:
- ユースケース図の記号と要点は、何でしょうか?
-
鈴木:
- 各々のユースケースは1つの機能または動作を記述するので、基本的には誰が何をするかを記述します。
- そのため、ユースケース図ではユースケース名(楕円)、アクター(人形)、関係(接続線)を含んでいます。
-
佐藤:
- 例で説明してもらえるでしょうか?
-
鈴木:
- はい。たとえば、車両見積作成という機能では、ユースケース名は”車両見積を作成する”で、アクターは営業マンと外部のデータベースで、アクターとユースケース名の間は、接続線で結びます。
-
田中:
- すみませんが、営業マンがアクターになることは分かりますが、なぜこのデータベースもアクターになるでしょうか?
-
鈴木:
- そうですね。ユースケースは実現しようとするシステムの立場から記述するので、このシステム以外で、システムと相互作用をする特定の機能を持つもの、または特定の操作を行う別のもの、例えば外部のシステムやデータベースなどを操作するものならば、全てはアクターと呼ばれます。
-
田中:
- そうですか、分かりました。
- それと、もしシステムの機能が複雑で、一つのユースケースでうまく表現できない場合はどうすればいいでしょうか?
-
鈴木:
- そんなことはよくあります。そこで、ユースケースの間には、包含、拡張の関係があるので、これらの関係を使えば、一つの大きなユースケースをいくつかに分離し、いろいろなユースケース間の関係を表現できると思います。
-
田中:
- なるほど。それでは、ユースケース記述の方法を教えていただけますか?
-
鈴木:
- はい、ユースケース記述を紹介しましょう。
- ユースケース記述はユースケース図より正確に定義する手段として、ある機能のイベントフローを記述します。
- もちろん、このイベントフローはシナリオ図で書くこともできますが、シナリオ図はイベントフローの1つインスタンスだと思えばいいと思います。
- ユースケース記述はユースケース図より詳しく機能の流れを記述できます。実際には、ユースケース図よりユースケース記述の方がもっと重要だと思います。
- ユースケース図は、他人に説明をするなら、また、システム全体を理解するには有効ですが、ユースケース図だけでは、機能の仕様を表すには、十分ではありません。
-
田中:
- それは助かります。ユースケース記述を行う時の要点は何でしょうか?
-
鈴木:
- ユースケース記述に関しては、UML標準の中では統一されていませんが、大抵以下の部分を含んでいると思います。
- ユースケース名、概要、基本フロー、代替フロー、例外フロー、事前条件、事後条件、等です。
-
佐藤:
- 概念は大体わかりましたが、ユースケース図でもユースケース記述でもサンプルをいただけるでしょうか?
-
鈴木:
- それは後で、例をあげましょう。
-
佐藤:
- 最後ですが、ユースケースに関してどんな参考文献がありますか?
-
鈴木:
- そうですね。たとえば、アリスターコーバーンさんが書いた「ユースケース実践ガイドーー効果的なユースケースの書き方」という本は参考にできると思います。訳本は翔泳社が出版しました。
- それ以外にもいろいろありますが、サンプルと一緒にリストしておきましょう。
-
佐藤:
- どうもありがとうございました。
-
鈴木:
- それでは、皆さんには今回の車両販売管理システムのユースケースを書いてもらいます。頑張ってください。
- 今日のミーティングはここまでです。
「真诚赞赏,手留余香」
真诚赞赏,手留余香
使用微信扫描二维码完成支付
