- - PR -
GUIのデザイン
1
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2005-12-22 19:32
皆さんはGUIをデザインするときはどのようにされているでしょうか?
私の経験が浅いことがありましてよくGUIでバグを作ってしまいます。 例えばTreeViewのある一定のアイテムをクリックしたときにチェックボックス を隠してテキストボックスを表示するなど… 他の人にとっては、簡単かもしれないですけどテストの時間も限られているので デザイン工程で何とかケアレスミステイクをなくしたいのですがどなたか よい方法をご存知の方いらっしゃいませんか? |
|
投稿日時: 2005-12-23 11:41
もし「対応するべき動作が、テストすると抜けている」ということでしたら、画面のプロトタイプを紙芝居風に作って、それを印刷したものに手書きで「ここをクリックしたら画面2のように表示を変える」などと書いていくのがいいかな。私はそうやってます。
紙芝居は画面のイメージが掴めれば、手書きでもパワポでもビジオでもHTMLでも…私はホームページ作成ツールなどでHTMLベースのものを作ります。リンクをクリックする動作ぐらいまでなら表現できて便利なので。 手法はともかく、チェックのポイントは次のようなことかな。 1. 画面イメージのプロトタイプを作る ※デザインは無視。パーツを漏れなく入れる。画面番号などをつけて区別する。 2. そのプロトタイプで、仕様の動作を実現できるか検討する ※動的な動作がわかりやすいようにメモを書き込む 3. 検討資料に基づいて画面を作る 4. 作った画面の動作を、検討資料に沿ってテストする |
|
投稿日時: 2005-12-23 12:07
提示されている問題は、ヒューマンインターフェースはいかにあるべきか、ではなくて、GUI のモジュールでバグをいかになくすか、ということでしょうか?
できるだけ、すでに出来合いのものを使う、ということぐらいしか思い付きません。たとえば、テキストボックスと下向き矢印が表示されているボタンを組み合わせるのではなく、(出来合いの)コンボボックスを使う、ということです。 もし、コンボボックスが存在していなかったら自分で作ることになるのですが、この場合も、アプリケーションの仕様とは切り離して、コンボボックスを汎用的な部品として作るべきでしょう。 それでも残るような、アプリケーションと密に連携することを余儀なくされる画面は、それがアプリケーションの核なのですから、結局は地道な設計とテスト・デバッグするしかないでしょう。ただ、こういう仕様は、アプリケーションを使う際にも習熟が要りますので、やはり、画面を見ただけで自ずと操作が分かるような画面設計にしたほうが良いです。そのためにも、コンポーネントは汎用的なものを使う・作るほうが良いでしょう。 顧客が思い付きで「こういう画面構成がいいんだけど〜」と言ったのを、間に受けてそれをそっくりそのまま実装すると、ハマると思います。どこまで要求をのんでどこで切り捨てるかが、腕の見せ所でしょう。 |
|
投稿日時: 2005-12-23 16:46
私の場合は肝心の処理を担うロジック部分と、それをかぶせる部分の GUI を分離してロジック部分を手厚くテストします。
ロジック部分にバグがなければそれを被せただけのGUI部分はあまりデバッグに工数がかかりません。Swing の API の使い方についていつも行き当たりばったりなのでむしろ JavaDoc を見ながら右往左往している時間の方が多いです。また、GUI部分は一度作ってしまえば修正を加えるうちにリグレッションが発生、ということも少ない(気がする)のでテストの自動化もあまりしていないのが現状です。 とはいっても、趣味のプログラミングの範囲の話なので仕事でそれなりの規模のコーディングをするのであればやはりテストの自動化が必要でしょうね。 https://swingunit.dev.java.net/ http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/trans/ts/&toc=comp/trans/ts/2005/10/extoc.xml&DOI=10.1109/TSE.2005.117 |
1