ユースケースの推敲
UC図をOO開発経験の浅い者が作成した場合とても読み辛いものとなる。UC図は様々な目線の者が読む文書である。そのためその様々な目線に耐えうる記述でなければならない。すべての関係者にわかるような記述が必要ということだ。だが、経験の浅い者はその記述が概してできない。彼らにとって特に厄介なのはシナリオの作成である。
ユースケースシナリオは「文」の羅列であるがこの「文」は基本「SVO」「SVOO」「SVOC」で表現されるのが望ましい。S、つまり主語は「アクター」と「システム」しかない。OはSがアクターの場合は画面のウィジェットつまりテキストボックスやチェックボタン等の入力項目やボタンやリンク等のイベント項目となり、システムの場合はドメインとなる事が多い。そしてVはその項目に対する振る舞いとなる。例えば
●アクターは、メールアドレスを、入力する【SVO】
という具合だ。文章は冗長である。ゆえに見やすさを兼ねて抽象化する必要がある。それが多くの人にわかりやすい記述となるからだ。上の例であればこういう表現となる。
●入会希望者はシステムにメールアドレスを登録する
これはユーザ視点の文である。だが最終的にはSVO形式となる。２はモデラーがクライアントとラフなレベルの要求確認をする際に重要だがそれが済めば重要ではなくなる。開発者は２を読めないからだ。だが１は読める。だから最終的には１が成果物となる。
重要なのは最初から１ができるわけではないということだ。原型は２でありそれが１になる。その変換がモデラーのタスクとなる。
１のようなユースケースシナリオの最終形は標準的な書き方がある。この例は「ユースケースからテストケースへの追跡可能性」にも示されている。一部抜粋しよう（誤植修正）。
このオンライン書店 (Online Bookstore) プロジェクトでは、ユースケースの基本フローは注文で、次のようになります。
B1 ユーザーがブラウザーに Web サイトのアドレスを入力します。
システムがログイン・ページを表示します。
B2 ユーザーは電子メール・アドレスとパスワードを入力します。
システムは正しいログインを確認し、メイン・ページを表示して、検索文字列の入力を要求します。
B3 ユーザーは検索文字列 (書名の一部) を入力します。
システムは検索条件と一致するすべての本のリストを表示します。B4 ユーザーは本を選択します。
システムは本の詳細な情報を表示します。
B5 ユーザーはその本をショッピング・カートに追加します。
ショッピング・カートの内容がユーザーに表示されます。
B6 ユーザーは「チェックアウト」オプションを選択します。
システムは配送先住所の確認を要求します。
B7 ユーザーは配送先住所を確認します。
システムは配送オプションを表示します。
B8 ユーザーは配送オプションを選択します。
システムはどのクレジットカードを使用するかをたずねます。
B9 ユーザーはシステムに登録されているクレジットカードを確認します。
システムは注文の最終的な確認を要求します。
B10 ユーザーは注文を確定します。
システムは確認番号を表示します。・・・
注目すべきはB1からB10までの文が単純であることだ。殆どが「SはOをVします」「SがO1をO2にVします」となっている。B2も文が直列でつながれているだけだしB5も能動態に直せばSVOで表現される。ここでより明確にSVOであることを示そう。
B1
【ユーザー】が【ブラウザー】に【 Web サイトのアドレス】を【入力】します。
【システム】が【ログイン・ページ】を【表示】します。
B2
【ユーザー】は【電子メール・アドレスとパスワード】を【入力】します。
【システム】は【正しいログイン】を【確認】します
【システム】は【メイン・ページ】を【表示】します
【システム】は【検索文字列の入力】を【要求】します。
B3
【ユーザー】は【検索文字列 (書名の一部) 】を【入力】します。
【システム】は【検索条件と一致するすべての本のリスト】を【表示】します。
B4
【ユーザー】は【本】を【選択】します。
【システム】は【本の詳細な情報】を【表示】します。
B5【ユーザー】は【その本】を【ショッピング・カート】に【追加】します。
【システム】は【ショッピング・カートの内容】を【表示】します。
B6【ユーザー】は【「チェックアウト」オプション】を【選択】します。
【システム】は【配送先住所の確認】を【要求】します。
B7【ユーザー】は【配送先住所】を【確認】します。
【システム】は【配送オプション】を【表示】します。
B8【ユーザー】は【配送オプション】を【選択】します。
【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
B9【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。
【システム】は【注文の最終的な確認】を【要求】します。
B10【ユーザー】は【注文】を【確定】します。
【システム】は【確認番号】を【表示】します。
このようにすべて叙述的な文に修正すればかなり明確な意味となる。ただそうならない文もある。修正済のB8を見てみよう。
●【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。●【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
これを見て皆さんは違和感を覚えるだろうか。１文目は素直に読めばこれは、画面に「登録されているクレジットカード」が表示されており、それをユーザが目視で確認するという意味だ。では2文目はどうか。システムが尋ねるとはどういう意味か。そもそもなぜアクションをユーザが起こしてもいないのにシステムに処理が移動したのだろうか。
実はこの２文目の主体はシステムではない。ユーザだ。処理がユーザからシステムに移動していない。ユースケース記述としてはトリッキーだ。私なら次のように書く。
●【アクター】は【クレジットカードを使用するか】を【たずね】ます。
これはアクションではない。ユーザ側からシステム側に処理が移動する条件はユーザがボタン押下などのアクションを起こさなけらばならない。ところが目視はアクションではない。ではこの次の行にあるのだろうか。ところが次の文はこうなっている。
●【システム】は【注文の最終的な確認】を【要求】します。
システムに処理が移動している。これはいったいどういう事か。
「確認する」の意味は通常３つである。
①「目視する」
②「目視確認し▲▲ボタンを押下する」
③「確認ボタンを押下する」
では上の例はどれに相当するのか。
●【ユーザー】は【システムに登録されているクレジットカード】を【確認】します。
●【システム】は【どのクレジットカードを使用するか】を【たずね】ます。
●ユーザーはシステムに登録されているクレジットカードを確認します。（【ユーザー】は【登録されているクレジットカード】を【確認】する）
これは登録されたクレジットカード情報が画面に表示されていることを確認するという意味だ。だがこの「確認」は「目視」ではなく「確認ボタンを押下する」と云う意味である。これは次行のアクティビティからわかる。
システムは注文の最終的な確認を要求します。
察し、そこから確認ボタンの存在を推理できる。その上で、カード情報がどのような構成になっているかをドメインモデル図、概念モデル図を参考にしながら別紙にでも書き留めておかないとこのユースケースレビューを終わらせることはできない。
こうした他のモデリングを並行しながらユースケースを検証をしていく過程で、ベンダーとクライアントは様々なことを学習していく。不整合、記述不備、曖昧記述は直されユースケースは徐々に推敲されていく。その間に新たなアイデアも浮かぶ。ならばそれも取り込めばよい。そのレビューが最適化につながる。これを推敲と呼ぶ。
推敲作業はユースケースシナリオが完成してから２回行われる。その際に１回目の推敲がおわるまで、設計作業は開始すべきではなく、２回目の推敲が終わるまでは実装を始めるべきではない。
＜修正中＞
