要求仕様を受け取って
これから取り組むアプリケーションは、たくさんの諺が保存されたデータベースを、キーワードを使って検索する、というものである。
顧客から提示された画面レイアウトと、基本的な操作手順は、次のようなものであったとしよう。
基本的な操作手順
- キーワードを入力して検索ボタンを押すと、データベースに入っている諺の中から、一致するものを表示する。
- 1ページに収まらない場合は、複数のページに分けて表示する。左右の矢印ボタンで、ページの移動ができること。
- もう1つのキーワードを入力して絞り込みボタンを押すと、検索した諺のうち、もう1つのキーワードに一致するものだけに、表示を絞り込む。
- 表示された諺を修正、削除することができる。
要求仕様にある基本的な操作手順を見ると、単純なアプリケーションに思えるかもしれない。だが、開発者の立場で言えば、細かい点でいろいろな疑問が湧くはずだ。
例えば、絞り込みを立て続けに行った時は、どのような結果が表示されるべきなのだろうか。また、諺を書き直してから、修正ボタンを押さずに次のページに移った時は、修正した内容はどうなるのだろうか。
機能仕様の策定では、このような細かい点について、きちんと挙動を定めておく必要がある。
機能仕様で大苦戦
はじめは、概念モデルを使わずに、機能仕様の策定に取り組んでみよう。
ボタンを押すと何が起こるか
諺を検索するアプリケーションでは、ボタンを押した時に、アプリケーションがどのような動作をするかを定めることになる。
まずは、それぞれのボタンについて、概要を書き出してみよう。これはすぐにできるはずだ。例えば、次のようにまとめられるだろう。
- 検索
-
キーワード欄に入力された文字列を含む諺がデータベースから取り出され、そのうちの最初の3個が画面に表示される。
- 絞り込み
-
検索ボタンを押した時にデータベースから取り出された諺の中から更に、キーワード欄に入力された文字列を含むものだけが選び出され、そのうちの最初の3個が画面に表示される。
- 左矢印
-
表示されている諺の、前の3個が画面に表示される。
- 右矢印
-
表示されている諺の、次の3個が画面に表示される。
- 修正
-
画面に表示された諺について、ユーザが画面で書き換えた通りに、データベースが書き換えられる。
- 削除
-
画面に表示された諺について、データベースから削除され、画面からも消去される。
これで、基本的な機能仕様は策定できた。だが、アプリケーションの設計、実装に着手するには、これではまだまだ不充分である。
細かい点を考えだしたらきりがない
ユーザは必ずしも、決められた通りに操作をするとは限らない。どのような操作をしても、データが壊れたり、意味不明な挙動をしてユーザを混乱させることがないように、細かい点についても、きちんと詰めておかなくてはいけない。
例えば、修正と削除に限っても、次のようにたくさんの状況が思い浮かぶ。
- 諺を書き直してから削除ボタンを押した時は?
- 諺を書き直してから次のページに移り、また前のページに戻った時は?
- 諺を書き直してから次のページに移り、修正ボタンを押した時は?
- 諺を書き直してから修正ボタンを押さずに、絞り込みを行った時は?
- ことわざ欄を空欄にしてから削除ボタンを押した時は?
- ことわざ欄を空欄にしてから修正ボタンを押した時は?
これらの操作をした時、アプリケーションはどのような挙動をするべきだろうか。1つ1つ考えてみると、次のようになるだろう。
- 諺を書き直してから削除ボタンを押した時は?
-
諺は削除されない。
(書き直した後の諺がデータベースに存在すれば、それが削除される、という案も考えられる。)
- 諺を書き直してから次のページに移り、また前のページに戻った時は?
-
書き直す前の状態に戻っている。
(書き直した通りに表示される、という案も考えられる。)
- 諺を書き直してから次のページに移り、修正ボタンを押した時は?
-
何も修正されない。
(書き直した通りに修正される、という案も考えられる。)
- 諺を書き直してから修正ボタンを押さずに、絞り込みを行った時は?
-
書き直す前の状態に戻っている。
(書き直した通りに表示される、という案も考えられる。)
- ことわざ欄を空欄にしてから削除ボタンを押した時は?
-
諺は削除されない。
(空欄にする前に表示されていた諺が削除される、という案も考えられる。)
- ことわざ欄を空欄にしてから修正ボタンを押した時は?
-
諺は修正も削除もされない。
(空欄にする前に表示されていた諺が削除される、という案も考えられる。)
しかし、ありとあらゆる状況についてすべて洗い出し、挙動を定めていくのは、大変な作業となる。もっと細かい点や複合的な操作まで考えだすと、いくら考えてもきりがないことになってしまう。
洗い出してはみたけれど…
洗い出しが終わったら、表や箇条書きで文書にまとめて、ようやく機能仕様書が完成する。だが、そこで苦労が終わる訳ではない。
あらゆる状況を想定したつもりでも、重大な見落としをしているかもしれない。また、一通り定めたアプリケーションの挙動の中に、互いに矛盾するものが含まれているかもしれない。こうした懸念は、レビューなどで検証しなくてはならない。
また、開発者が定めたアプリケーションの挙動が、ユーザが望むものかどうかを、顧客とも検証しなくてはならない。たいてい、顧客からはいくつかの改善要望が出される。この時、顧客の要望が他の挙動と矛盾しないかどうか、また、要望通りに修正した時に、一緒にどこを修正しなくてはいけないか、改めて再検討しなくてはならない。
機能仕様書には、膨大な細かい点についてのアプリケーションの挙動が羅列されている。それを検証したり、修正したりするのは、極めて困難となる。
このように、操作性の複雑なアプリケーションの機能仕様は、策定するのに膨大な労力と時間がかかってしまう。また、せっかく作成した機能仕様書も難解なものとなり、顧客からの要望に柔軟に対応するのが難しい。その結果、機能仕様の策定で、予定の工数をオーバーしてしまうことも少なくない。
概念モデルを作って考える
今度は、同じ諺を検索するアプリケーションについて、概念モデルを作って、機能仕様を考えてみよう。
基本的な操作手順を、ユースケース(シナリオ)として洗い出す
まずは、要求仕様を元にして、ユーザがアプリケーションを使う際の基本的な操作手順を、ユースケース(シナリオ)として洗い出す。
ユースケース(シナリオ)を考える時は、あくまでユーザの視点に立つことが大切である。ユーザにアプリケーションの使い方を教えたり、操作マニュアルを書く時の気持ちで考えると良い。
諺を検索するアプリケーションでは、次のようにまとめられるだろう。
- 検索
-
- 画面を開く。
- キーワード欄にキーワードを入力する。
- 検索ボタンを押す。
- データベースから、キーワードを含む諺が取り出される。例えば、諺1〜諺7という、7個の諺が取り出される。
- 諺1〜諺3が画面に表示される。
- 右矢印ボタンを押す。
- 諺4〜諺6が画面に表示される。
- 右矢印ボタンを押す。
- 諺7が画面に表示される。
- 絞り込み
-
- 画面を開く。
- キーワード欄にキーワードを入力する。
- 検索ボタンを押す。
- データベースから、キーワードを含む諺が取り出される。例えば、諺1〜諺7という、7個の諺が取り出される。
- 諺1〜諺3が画面に表示される。
- キーワード欄に、絞り込みのためのキーワードを入力し直す。
- 絞り込みボタンを押す。
- 諺1〜諺7のうち、絞り込みのためのキーワードを含む諺だけが選び出される。例えば、諺3と諺6だけが選び出される。
- 諺3と諺6が画面に表示される。
- 修正
-
- 画面を開く。
- キーワード欄にキーワードを入力する。
- 検索ボタンを押す。
- データベースから、キーワードを含む諺が取り出される。例えば、諺1〜諺7という、7個の諺が取り出される。
- 諺1〜諺3が画面に表示される。
- 右矢印ボタンを押す。
- 諺4〜諺6が画面に表示される。
- 修正したい諺について、ことわざ欄を書き換える。例えば、諺5を書き換える。
- 修正ボタンを押す。
- データベースに入っている諺5が、書き換えた通りに変更される。
- 修正が成功したことがメッセージで表示される。
- 削除
-
- 画面を開く。
- キーワード欄にキーワードを入力する。
- 検索ボタンを押す。
- データベースから、キーワードを含む諺が取り出される。例えば、諺1〜諺7という、7個の諺が取り出される。
- 諺1〜諺3が画面に表示される。
- 右矢印ボタンを押す。
- 諺4〜諺6が画面に表示される。
- 削除したい諺だけを残し、削除しない諺のことわざ欄を空欄にする。例えば、諺5だけを残して、諺4と諺6は空欄にする。
- 削除ボタンを押す。
- データベースに入っている諺5が、削除される。
- 削除が成功したことがメッセージで表示される。
- 画面のことわざ欄はすべて空欄になる。
ユースケース(シナリオ)は、アプリケーションの使い方を書き下したものだ。使いやすいアプリケーションになるかどうかは、ユースケース(シナリオ)から判断できる。そこで、ユースケース(シナリオ)をまとめた時点で、顧客とのレビューを行い、ユーザインターフェースについて確認すると良い。
なお、ここに挙げたユースケース(シナリオ)は、アプリケーションが完成した時の、ブラック・ボックス・テストの試験項目となる。
ユーザの頭にある概念をモデル化する
ユーザがアプリケーションを使う時、頭の中では、アプリケーションの動きや仕組みについて、何らかの概念的なイメージを思い浮かべている。
例えば、メモ帳で文章を書いているユーザは、終了する前に、必ずファイルに保存する。これは、ユーザの頭の中に、次のような概念があるためだ。
この概念を見ると、書いた文章をファイルとして残すには、書き込むだけでなく、保存しないといけないことが分かる。だからこそユーザは、ファイルに保存する、という操作を行うのである。
ユースケース(シナリオ)を洗い出した後は、アプリケーションをユーザが使った時に頭に思い浮かぶであろう概念を考えて、モデル化する。この概念モデルは、ユースケース(シナリオ)に書かれている操作手順を、自然と表すようなモデルでなければならない。
諺を検索するアプリケーションの概念モデルは、次のようになるだろう。
アプリケーションの動きは、次のように説明される。
モデルからアプリケーションの挙動を導く
概念モデルが出来上がると、さまざまな操作を行った時にアプリケーションがどのように振る舞うか、モデルから明確に導き出すことができる。
そこで、ユースケース(シナリオ)に書かれている基本的な操作手順の他に、ユーザが行いそうないろいろな例外的、複合的な操作を思い浮かべ、それぞれについて、アプリケーションの挙動をモデルから導いてみる。
例えば、冒頭で挙げた疑問点については、さきほどの概念モデルから、次のような結論が導かれる。
- 絞り込みを立て続けに行った時は、どのような結果が表示されるべきなのだろうか。
-
絞り込みを続けて行っても、どんどん数が減っていく訳ではない。
例えば、「水」というキーワードで検索すると、「立て板に水」「寝耳に水」「焼け石に水」の3つが表示される。次に「石」というキーワードで絞り込みを行うと、「焼け石に水」だけが表示される。続けて「板」というキーワードで絞り込みを行うと、今度は「立て板に水」だけが表示される。
- 諺を書き直してから、修正ボタンを押さずに次のページに移った時は、修正した内容はどうなるのだろうか。
-
書き直したことは、ページを移った時に忘れられてしまう。
次のページに移った後で、また前のページに戻ると、書き直す前の諺が表示される。
ここで、思いつく限りのいろいろな操作に対して、アプリケーションの挙動を洗い出して、概念モデルの検証を行う。ユーザにとって望ましくない挙動が導かれた時は、概念モデルに修正を加える。
なお、ここで洗い出した項目は、アプリケーションが完成した時の、ブラック・ボックス・テストの試験項目となる。
モデルに合わせて、ユーザインターフェースを見直す
もし、概念モデルがあまりにも複雑になったり、トリッキーなものになったら、使いづらいアプリケーションを作ろうとしている可能性がある。その時は、ユーザインターフェースを見直して、画面レイアウトやユースケース(シナリオ)を書き直した方が良いこともある。
諺を検索するアプリケーションの概念モデルは、実は、削除のユースケース(シナリオ)を正しく表せていない。概念モデルに従えば、削除が成功した後で、画面には最初の3個の諺が表示されることになる。
ユースケース(シナリオ)の段階では、削除を行った時は、画面のことわざ欄はすべて空欄になる、と考えていた。だが、この動作を表すためには、概念モデルは複雑になりすぎるようだ。
ここでは、削除のユースケース(シナリオ)を、次のように書き直す方が良いだろう。
- 削除
-
- 画面を開く。
- キーワード欄にキーワードを入力する。
- 検索ボタンを押す。
- データベースから、キーワードを含む諺が取り出される。例えば、諺1〜諺7という、7個の諺が取り出される。
- 諺1〜諺3が画面に表示される。
- 右矢印ボタンを押す。
- 諺4〜諺6が画面に表示される。
- 削除したい諺だけを残し、削除しない諺のことわざ欄を空欄にする。例えば、諺5だけを残して、諺4と諺6は空欄にする。
- 削除ボタンを押す。
- データベースに入っている諺5が、削除される。
- 削除が成功したことがメッセージで表示される。
- 諺1〜諺3が画面に表示される。
概念モデルが完成したら、機能仕様の策定も完了である。機能仕様書には、ユースケース(シナリオ)と概念モデルを書いておく。必要なら、例外的な操作を行った時のアプリケーションの挙動についても、概念モデルから導かれる結果を文章で書いておくと良い。
設計に進んでからは
ここまでに作ったモデルは、アプリケーションの仕組みをイメージした時の、概念的なものである。
ソフトウェアの設計では、クラスの関係やデータの流れなど、さまざまなモデルを作成する。だが、設計で作成するモデルは、ソフトウェアの構造を表す実装モデルである。機能仕様を表す概念モデルとは、きちんと区別しなければならない。
概念モデルを作った場合でも、設計に進んでからは改めて、実装モデルを作成する。実装モデルは、必ずしも概念モデルを詳細にしたものとは限らない。
例えば、諺を検索するアプリケーションでは、絞り込みボタンを押した時は、その前に検索ボタンを押した時にデータベースから取り出しておいた諺の中から、一致するものを選び出す、という概念モデルを作った。
しかし、データベースのアクセス速度が問題にならない時は、絞り込みボタンを押した時にも、データベースの検索を行うような設計をするかもしれない。その場合は、検索のキーワードと、絞り込みのキーワードを、AND条件で並べることになる。この方法であれば、諺とキーワードとの一致判定を、データベースにアクセスする箇所だけに実装すれば良い、という利点も生まれる。
また、諺を検索するアプリケーションを、WWWアプリケーションとして実装するのであれば、全体の構成はプレゼンテーション層、ビジネス・ロジック層、データ・アクセス層という、3つの階層に分かれることになる。その場合の実装モデルは、概念モデルとは大きくかけ離れたものとなるだろう。