ユースケースを教えてもらった

ユーザーストーリー同様、テスト設計コンテストの課題(http://aster.or.jp/business/contest/testbase.html)を使って教えてもらいました。

わかったこと

「ユースケース」と言われるのは、UML(図)の場合とシナリオ(文)の場合がある。

文重要。文には大きく3流派がある。

• RUP(ラショナル統一プロセス)
• Alistair Cockburn
• ICONIX ← きょんさんはこれが書きやすい

アクターにできることをユースケース名にする

ユーザーストーリーのWhyとWhatの間くらいの感じ。

自動販売機の利用者がジュースを買う

パスの書き方いろいろ

実装に依らない言葉で書く

1STEPには以下2つを必ず含める

ユーザーがすること
ユーザーがしたことに対してシステムがどう動くか

ユーザーとシステムをつなぐインターフェース(バウンダリ)はきちんと書く

× ユーザーが硬貨を入れると
○ ユーザーが硬貨投入口に硬貨を入れると

基本パスと代替パスに分けて書く

基本パスと代替パスの名前はいろいろ。
ex)晴れの日パスと雨の日パス

パスが大量になり過ぎたらケースを分割する

要求分析～外部設計、および及びそれにかかわるテストを考えるときに使える

ユーザーストーリーは要求分析までが範囲

ドメインモデリングとユースケースの記述を並行すると良い

ユビキタス言語を作ってからユースケースを書きましょうという派もある。
ユースケースを書いていて必要な言葉がわかることもあるので、並行が良いと思われるとのこと。

難しいと思ったこと

どれくらいのパスを書いたら満足かわからない

ICONIXとRUPは目安があるので勉強するといいとのこと。
きょんさん的には実装できる気がするまで。

書いたものを残しておく

自動販売機利用者がジュースを買う

基本パス

自動販売機利用者がお金を硬貨投入口に硬貨を入れると、自動販売機が買えるジュースのボタンを点ける。
自動販売機利用者が光っているボタンを押すと、該当商品が商品取り出し口から出てくる自動販売機が該当商品を商品取り出し口へ送出する。

代替パス

自動販売機利用者がお金を入れると、自動販売機が使えないお金と判断して返金する。

バウンダリオブジェクトを明確にする。
該当商品はシステムじゃない。

自動販売機利用者が自動販売機でジュースを買って抽選に参加する

基本パス

自動販売機利用者がお金を硬貨投入口に硬貨を入れると、自動販売機が販売できる販売可能な商品のボタンを点ける。
自動販売機利用者が光っているボタンのうち抽選対象になっている商品のボタンを押すと、該当商品が商品取り出し口から出てきて、抽選を行う自動販売機が該当商品を商品取り出し口へ送出して、抽選を行い、はずれ結果を表示する。

代替パス

当たった場合：←あとから追加
当たり結果を表示して、販売可能な商品のボタンを点ける。

当たっても渡せる商品がない場合：
販売可能な商品がない場合、抽選は行わない。

「販売できる」と「販売可能な」の混在を解消。

もっとたくさんありそうな代替パスはない？
→はずれが基本パスで、当たりが代替パスで書きたい
→追加