満足せる豚。眠たげなポチ。

• 複雑なUIの一例で、コンボボックスの選択をいじると別のコンボボックスの選択内容が変わるとか、別の入力の入力可否が変わるとかを一画面でやっているものなんかがあると思う。これって結局内在するルールやフロー制御をプレゼンテーション層で扱ってしまっているだけなんだよね。そこを画面を割って buri や ebi 使うとすれば、UI レベルで本当に複雑さが必要なアプリってたしかにそうそう無い。（自分の担当業務アプリを考えたりして。）
• 一方で、「一画面で入力させたい」という要求は良くも悪くも強くあって、たとえば消費者向けの Web のページで契約成立まで20ページとかあったらそりゃ嫌がられるよなとかは理解できる。じゃ、Ajax のような非同期な作りにすれば入力単位としては１ページに見えるけど実装上は適切な単位に区切ってしまうとかできそう。どうせ一回に入力すべきなのは一箇所だけなのだし。「ページ遷移うざい」というだけの問題なら解決できそう。
• まさにこれを地道に徹底したわけだ。と妙に納得。

  手作業で開発すると500人月はかかる。それとは対照的に、同じシステムの仕様を決定するだけなら 5, 6 週程度で済むだろう。そして、その仕様がそのまま動作するシステムとなるのなら、開発期間を劇的に短縮するのに成功することとなる。〜 What Not How P7.(適当訳)

とか。

追記： What Not How に関してはこの辺とか。

What Not How: The Business Rules Approach to Application Development

posted with amazlet on 07.07.24

C. J. Date
Addison-Wesley Pub (Sd) (2000/04/12)
売り上げランキング: 94569

amazlet.com で詳細を見る