複雑なアプリケーションの機能仕様は、概念モデルで整理しよう

ボタンを押すと何が起こるか

諺を検索するアプリケーションでは、ボタンを押した時に、アプリケーションがどのような動作をするかを定めることになる。

まずは、それぞれのボタンについて、概要を書き出してみよう。これはすぐにできるはずだ。例えば、次のようにまとめられるだろう。

これで、基本的な機能仕様は策定できた。だが、アプリケーションの設計、実装に着手するには、これではまだまだ不充分である。

細かい点を考えだしたらきりがない

ユーザは必ずしも、決められた通りに操作をするとは限らない。どのような操作をしても、データが壊れたり、意味不明な挙動をしてユーザを混乱させることがないように、細かい点についても、きちんと詰めておかなくてはいけない。

例えば、修正と削除に限っても、次のようにたくさんの状況が思い浮かぶ。

• 諺を書き直してから削除ボタンを押した時は？
• 諺を書き直してから次のページに移り、また前のページに戻った時は？
• 諺を書き直してから次のページに移り、修正ボタンを押した時は？
• 諺を書き直してから修正ボタンを押さずに、絞り込みを行った時は？
• ことわざ欄を空欄にしてから削除ボタンを押した時は？
• ことわざ欄を空欄にしてから修正ボタンを押した時は？

これらの操作をした時、アプリケーションはどのような挙動をするべきだろうか。１つ１つ考えてみると、次のようになるだろう。

しかし、ありとあらゆる状況についてすべて洗い出し、挙動を定めていくのは、大変な作業となる。もっと細かい点や複合的な操作まで考えだすと、いくら考えてもきりがないことになってしまう。

洗い出してはみたけれど…

洗い出しが終わったら、表や箇条書きで文書にまとめて、ようやく機能仕様書が完成する。だが、そこで苦労が終わる訳ではない。

あらゆる状況を想定したつもりでも、重大な見落としをしているかもしれない。また、一通り定めたアプリケーションの挙動の中に、互いに矛盾するものが含まれているかもしれない。こうした懸念は、レビューなどで検証しなくてはならない。

また、開発者が定めたアプリケーションの挙動が、ユーザが望むものかどうかを、顧客とも検証しなくてはならない。たいてい、顧客からはいくつかの改善要望が出される。この時、顧客の要望が他の挙動と矛盾しないかどうか、また、要望通りに修正した時に、一緒にどこを修正しなくてはいけないか、改めて再検討しなくてはならない。

機能仕様書には、膨大な細かい点についてのアプリケーションの挙動が羅列されている。それを検証したり、修正したりするのは、極めて困難となる。

基本的な操作手順を、ユースケース（シナリオ）として洗い出す

まずは、要求仕様を元にして、ユーザがアプリケーションを使う際の基本的な操作手順を、ユースケース（シナリオ）として洗い出す。

ユースケース（シナリオ）を考える時は、あくまでユーザの視点に立つことが大切である。ユーザにアプリケーションの使い方を教えたり、操作マニュアルを書く時の気持ちで考えると良い。

諺を検索するアプリケーションでは、次のようにまとめられるだろう。

ユースケース（シナリオ）は、アプリケーションの使い方を書き下したものだ。使いやすいアプリケーションになるかどうかは、ユースケース（シナリオ）から判断できる。そこで、ユースケース（シナリオ）をまとめた時点で、顧客とのレビューを行い、ユーザインターフェースについて確認すると良い。

なお、ここに挙げたユースケース（シナリオ）は、アプリケーションが完成した時の、ブラック・ボックス・テストの試験項目となる。

ユーザの頭にある概念をモデル化する

ユーザがアプリケーションを使う時、頭の中では、アプリケーションの動きや仕組みについて、何らかの概念的なイメージを思い浮かべている。

例えば、メモ帳で文章を書いているユーザは、終了する前に、必ずファイルに保存する。これは、ユーザの頭の中に、次のような概念があるためだ。

この概念を見ると、書いた文章をファイルとして残すには、書き込むだけでなく、保存しないといけないことが分かる。だからこそユーザは、ファイルに保存する、という操作を行うのである。

ユースケース（シナリオ）を洗い出した後は、アプリケーションをユーザが使った時に頭に思い浮かぶであろう概念を考えて、モデル化する。この概念モデルは、ユースケース（シナリオ）に書かれている操作手順を、自然と表すようなモデルでなければならない。

諺を検索するアプリケーションの概念モデルは、次のようになるだろう。

アプリケーションの動きは、次のように説明される。

モデルからアプリケーションの挙動を導く

概念モデルが出来上がると、さまざまな操作を行った時にアプリケーションがどのように振る舞うか、モデルから明確に導き出すことができる。

そこで、ユースケース（シナリオ）に書かれている基本的な操作手順の他に、ユーザが行いそうないろいろな例外的、複合的な操作を思い浮かべ、それぞれについて、アプリケーションの挙動をモデルから導いてみる。

例えば、冒頭で挙げた疑問点については、さきほどの概念モデルから、次のような結論が導かれる。

ここで、思いつく限りのいろいろな操作に対して、アプリケーションの挙動を洗い出して、概念モデルの検証を行う。ユーザにとって望ましくない挙動が導かれた時は、概念モデルに修正を加える。

なお、ここで洗い出した項目は、アプリケーションが完成した時の、ブラック・ボックス・テストの試験項目となる。

モデルに合わせて、ユーザインターフェースを見直す

もし、概念モデルがあまりにも複雑になったり、トリッキーなものになったら、使いづらいアプリケーションを作ろうとしている可能性がある。その時は、ユーザインターフェースを見直して、画面レイアウトやユースケース（シナリオ）を書き直した方が良いこともある。

諺を検索するアプリケーションの概念モデルは、実は、削除のユースケース（シナリオ）を正しく表せていない。概念モデルに従えば、削除が成功した後で、画面には最初の３個の諺が表示されることになる。

ユースケース（シナリオ）の段階では、削除を行った時は、画面のことわざ欄はすべて空欄になる、と考えていた。だが、この動作を表すためには、概念モデルは複雑になりすぎるようだ。

ここでは、削除のユースケース（シナリオ）を、次のように書き直す方が良いだろう。