アプリケーションの画面遷移

面白いところに気付きましたね。
これは方式の違いというかスコープの違いです。
着目点も正しくて、片方がWeb系であると言う判断もあっています。
ただし他方がOA系と言うわけではありません。非Web系の場合は機械の制御卓でも同じです。

要するに、画面と処理が一体化した設計ができるのか、全く分離した世界なのかということです。

従来の開発は１のタイプがほとんどのはずです。
これは画面と処理が表裏一体の考え方です。
顧客入力画面＝顧客を入力しDBに登録する処理、です。
そうすると、画面の名前と処理の名まえを同じにして管理することができます。
顧客登録の画面と処理、顧客修正の画面と処理、顧客削除の画面と処理、という視点で扱えます。

２のタイプはそうではありません。
画面は画面、処理は処理なんです。
データをDBに登録する処理、が存在しているのです。
それがたまたま顧客データであるか、商品データであるかは問わず、登録処理があるのです。
そして、データ別に画面があるのです。

画面とコントロールがあるという言い方をします。
この場合、当然、画面の名前とコントロールの名前は同じものを使えません。

順次いいますと、メニュー画面というのが存在していて、登録、を押すと、登録画面を作ってくれというコントロールに制御が渡ります。
そのコントロールは登録画面をつくります。項目の入力欄を設定し、登録実行というボタンを用意した画面を作り、いま作った画面に表示を切り替えます。
切り替えられた画面は、キャンセルボタンで今入力されたものを全部クリアする程度のことは画面内で行います。
登録実行、を押されたときは、今入力された全データを、登録実行せよというコントロールに渡し、制御を移します。
そのコントロールは、DBと会話してデータを登録し、終了したら「登録完了しました」という画面をつくって表示を切り替えるか、あるいはメニューを再表示するかをします。

そうすると、最後のメニューか完了画面かというのを入れないとすれば画面はふたつあります。
コントロールは２つあります。

別々のものですから、名前は４つあるはずです。

こういう作り方は何がいいかというと、実行しているコンピュータ（サーバーですね）が全部を握っている必要がないことです。
画面の表示とユーザーとの会話は、完全に端末機だけがやっています。
そしてコントロールだけをサーバ―が実行しているのです。

画面と処理が一体化していると、仮に処理中に電源でも落ちたらすべてのデータがパーになり、場合によってはDBも壊れます。
こういうピンポンゲームというかビリヤードゲームのようにやっていると仮に端末機がダウンしても、途中までは確保されます。
サーバ―側に万が一のことがあったとしても端末機は状況をキープできます。
ふたたび復活したとき、さきほど中断したところから作業を続けることができるのです。
（こういうことのために、サーバ―と端末の間にセッションを持ちますし、端末側にはクッキーというものを持てる仕組みになっています。）

もうひとつ言いますと、コントロールのほうは、動きにパタンがありますので、いちいち１からくみ上げる必要がなくなります。
データをもらってDBに登録するということであれば、個々に違うのはそのデータのフォーマットと数ぐらいのものです。
個々のデータの名前だとか意味なんて考える必要はありません。名前は画面のほうが知っていればいいだけです。
だったら、そこだけ書き換え可能な構造でプログラムを作っておけば、DBに従ってデータを割り付けるところだけ組めばいいでしょう。
ひな形のプログラムを修正するなんていうことをするとミスで壊すかもしれないから、スーパークラスにしてしまって継承するだけにすれば、危険もなくなります。
これがフレームワークという考えかたです。

で、メリットデメリットと言うことで言いますと、
１のほうは、品質判断が楽です。テストケースが明示的に羅列できる。
２のほうは見過ごしやすい。
１のほうは、仕様変更に対し作業が膨大になります。いちいち全部直す必要がありますから。
２はそれほどでもありません。うまくフレームワーク化していたら1か所の修正ですべてが片付くことがあります。
１は、熟練の技術者を必要とします。
２は、かならずしもそうではありません。
１は、自分の内部だけでデータを処理していますから、他と切り離して単独に動作可能のことが多いですからセキュリティ上かなり安全です。
２は、どうしても別々のものが会話をして連携動作をしているため、セキュリティの観点からは危険です。
１、は何か修正が入った時、そのリプレースとかアップデートをいちいちしっかり行う必要があります。
２、は処理は1か所にありますから、そこだけ修正しておけば、いちいちユーザーごとに対応する必要はありません。

どちらをほめるわけでもありません。1でしか実現できないものもあれば２を前提としなければだめなものもあります。

ただ、ひとこといえば、設計方法という意味では２をきっちり記述できる書式のドキュメント様式はまだ完成していないということはあります。
UMLがかなりできるようにはなっていますけど、どうしても、誰が見ても明白という形の書類を作るのは至難の業です。

お礼

2016/04/04 11:06

丁寧なご回答、ありがとうございました。

質問者

一般的なアプリケーションの定義ですが、プログラムの作り易さで
考えるのではなく、エンドユーザーが何を望んでいるかを考える事
が先決です。
ところが、SEになりたての人は、PG側に立って考えがちになります。
（仕方の無い事ですが）

従って、OA系＝ケース１やWeb系＝ケース２は成り立ちません。
エンドユーザーの使い勝手により、ケース１もケース２もその他の
ケースも有り得ます。

ケース１は省略します。
大量のレコードからあいまい検索等で絞った後、エンドユーザーが
選択して訂正／削除する場合は、ケース２がよいと思われます。

エンドユーザーは、何で１画面で登録／訂正／削除が出来ないの？
使い難いねと普通に言ってきたりします。
それに対して、そのように設計した理由が説明できて、先方を納得
させることができればよいだけです。

アプリはZEROから開発するものを除いて、今は部品化されている
と思いますので、プログラムは部品の組み合わせ作業だと思います。

ご参考になりましたら幸いです。

お礼

2016/04/04 11:07

ご回答ありがとうございます。
まさに仰る通りで、「何で１画面で登録／訂正／削除が出来ないの？」と言われるエンドユーザーに、どのように説明すれば理解していただけるか悩んでいます。

質問者