読者です 読者をやめる 読者になる 読者になる

ユースケースの推敲

UC図をOO開発経験の浅い者が作成した場合とても読み辛いものとなる。UC図は様々な目線の者が読む文書である。そのためその様々な目線に耐えうる記述でなければならない。すべての関係者にわかるような記述が必要ということだ。だが、経験の浅い者はその記述が概してできない。彼らにとって特に厄介なのはシナリオの作成である。

ユースケースシナリオは「文」の羅列であるがこの「文」は基本「SVO」「SVOO」「SVOC」で表現される。そしてそのS、つまり主語は「アクター」と「システム」しかない。またOはSがアクターの場合は画面のウィジェットつまりテキストボックスやチェックボタン等の入力項目やボタンやリンク等のイベント項目となり、Cはその内容、そしてVはその項目に対する振る舞いとなる。例えば

1.アクターは入会画面のテキストボックスにメールアドレスを入力する

という具合だ。

だがこの文章には問題がある。冗長であると云うことだ。ゆえに見やすさを兼ねて抽象化する必要がある。それが多くの人にわかりやすい記述となるからだ。1であればこういう表現となる。

2.入会希望者はメールアドレスを登録する

1が開発者の視点で記述された文章であるのに対し2はユーザ視点の文章となる。どちらが正解ということはない。どちらも正解だ。だが最終的には1の形式となる。2はモデラーがクライアントとラフなレベルの要求確認をする際に重要だがそれが済めば重要ではなくなる。開発者は2を読めないからだ。だが1は読める。だから最終的には1が成果物となる。

重要なのは最初から1ができるわけではないということだ。原型は2でありそれが1になる。その変換がモデラーのタスクとなる。

1のようなユースケースシナリオの最終形は標準的な書き方がある。この例は「ユースケースからテストケースへの追跡可能性」にも示されている。一部抜粋しよう(誤植修正)。

このオンライン書店 (Online Bookstore) プロジェクトでは、ユースケースの基本フローは注文で、次のようになります。
B1 ユーザーがブラウザーに Web サイトのアドレスを入力します。
 システムがログイン・ページを表示します。
B2 ユーザーは電子メール・アドレスとパスワードを入力します。
 システムは正しいログインを確認し、メイン・ページを表示して、検索文字列の入力を要求します。
B3 ユーザーは検索文字列 (書名の一部) を入力します。
 システムは検索条件と一致するすべての本のリストを表示します。

B4 ユーザーは本を選択します。
 システムは本の詳細な情報を表示します。
B5 ユーザーはその本をショッピング・カートに追加します。
 ショッピング・カートの内容がユーザーに表示されます。
B6 ユーザーは「チェックアウト」オプションを選択します。
 システムは配送先住所の確認を要求します。
B7 ユーザーは配送先住所を確認します。
 システムは配送オプションを表示します。
B8 ユーザーは配送オプションを選択します。
 システムはどのクレジットカードを使用するかをたずねます。
B9 ユーザーはシステムに登録されているクレジットカードを確認します。
 システムは注文の最終的な確認を要求します。
B10 ユーザーは注文を確定します。
 システムは確認番号を表示します。

・・・

 「アクター」ではなく「ユーザー」だがこれは作成者の癖のようなもので大した差はない。注目すべきはB1からB10までの文が上で述べたように非常に単純な文型であることだ。いずれもが「SがVします」「SがOをVします」「SがOをCにVします」または「SがO1をO2にVします」と。B2のようにこれとは違うと思われる文章はあってもそれはただ複数の文章が直列でつながれているだけで分解すれば結局はこの形式に収まる。

だが、実際にこの形になっても推敲作業は終わらない。

例えばこのシナリオB1をみてみよう。ここに登場する「ブラウザ」は具体的にどういう画面かわからない。そこで「ああ、ここで登場する画面の名前を考えないといけないな」と気づく。そしてその画面には、Web サイトのアドレスを入力するテキストボックスと入力が確定したことをシステムに告げるOKボタンが必要と理解する。そうしてUIは分析される。つまりこのUI定義が完了しない限り当該シナリオは修正される可能性があるのだ。

あるいはB9はどうか。「ユーザーはシステムに登録されているクレジットカードを確認します。」とあるが、これはもちろん現物の確認ではなく、クレジットカード情報が画面に表示されておりその確認という意味だ。そして確認すると云う文言からそこに確認ボタンもあると推理できる。アクターは何らかの作業をしたら必ず何らかのアクションを起こす。つまり確認をすると云う表現でそこに確認ボタンが存在するとわかる。その上で、カード情報がどのような構成になっているかを定義しないとこのユースケースシナリオは確認を負えることができない。

こうした他のモデリングを並行しながらユースケースを検証をしていく過程で、ベンダーとクライアントは業務に関する様々なことを学習していく。不整合、記述不備、曖昧記述は直されユースケースは徐々に推敲されていく。その間に新たなアイデアも浮かぶ。ならばそれも取り込めばよい。それが最適化につながる。

この作業は上流で繰り返される。これをユースケース推敲と呼ぶ。 

推敲作業はユースケースシナリオが完成してから2回行われる。その際に1回目の推敲がおわるまで、設計作業は開始すべきではなく、2回目の推敲が終わるまでは実装を始めるべきではない。