Visual
Basic* による画面アプリの開発方法
--- 単純な開発方法、分割専門開発方法、部品化アプリ開発方法
---
＊： ここでは VB の場合を書いていますが、他の GUI 開発支援ツールを用いる場合も同様です。
クラサバ (クライアントサーバ) システムの業務アプリは、次の三つに分けて捉らえるのがよいでしょう。
・ 画面アプリ
・ 帳票アプリ
・ バッチ処理アプリ
この３種類の中で、画面アプリが一番やっかいです。帳票アプリは、例えば Visual Basic に添付されている“クリスタルレポート”などのツールを用いることで比較的に簡単に開発できます。また、バッチ処理アプリは、日次処理や月次処理などに必要ですが、バッチで処理する部分は、昔に比べて格段に少なくなりました。というのは、昔、バッチ処理していたものの多くは、画面アプリの中でオンライン処理することが普通になったためです。
ところが、画面アプリは、昔に比べて開発すべき画面数が多くなり、かつ開発が難しく (表情豊かで、操作に即反応する画面アプリが求められるように) なりました。しかも、Windows 流の GUI だけでなく、インプット操作を素早く行えるように洗練されてきた長い歴史をもつダム端末やオフコンの操作性
(キーボード主体の操作性) も継承することが求められるのですから、一番やっかいです。
ここでは、クラサバシステムの業務アプリの中でも一番やっかいな画面アプリの開発方法を取り上げて、詳しく調べてみることにします。
ところで、画面アプリの形態を見ると、次の三つがあります。
① クライアントアプリのみで機能を実現
② サーバアプリのみで機能を実現
③ クライアントアプリとサーバアプリの協調動作で機能を実現
この三つの中で、①のクライアントアプリのみで機能を実現というのが最もよく採用される形態です。
②のサーバアプリのみで機能を実現という形態では、昔の“ダム端とホスト”の形態と同じですから、操作性を従来以上に改善することが困難です。具体的に言うと、操作員のインプットに即反応する表情豊かな画面アプリにするには、キーボードやマウスからのインプットに、プログラムが即こたえることが必要ですが、これをサーバアプリとして実現することは、クライアントとサーバのトラフィックが増え、サーバの負荷が増えるという問題があり、お勧めできません。こうした問題のために、操作性を改善することが困難なのです。
③のクライアントアプリとサーバアプリの協調動作で機能を実現という形態は、例えば Visual Basic のエンタープライズ版を用いてリモート OLE サーバとして実現することができます。しかし、二つのアプリに協調的に仕事をさせるには、プログラムの作り方が大変に難しくなるものです。こういう形態でないと実現できない業務システムもあるでしょうが、普通はお勧めできない形態です。
ということで、①のクライアントアプリのみで機能を実現という形態が最もよく採用されるわけです。この形態にすれば、クライアント側にある Pentium などの高速のプロセッサ (CPU) を活用することができますから、トータルに見てもバランスのよいシステム形態だといえます。一般に、クラサバシステムでは、クライアント側の
CPU が遊んでいるのが普通ですから、遊んでいる CPU を活用することが理にかなうわけです。将棋の世界でいうところの「遊び駒の活用」です。
だいぶ前置きが長くなりましたが、ここでは“クライアントアプリのみで機能を実現”または“クライアントアプリとサーバアプリの協調動作で機能を実現”という形態のクライアントアプリの開発方法を掘り下げてみます。
さて、例えば１５０画面から構成される画面アプリを１０名の開発者で作成するときに、どのようにすればよいでしょうか？
以下では、次の三つの方法を比較してみることにします。
（深く考えずに単純な方法を採用した場合）
（望ましい開発方法を目指した場合）
（究極の開発方法を目指した場合）
|
|
|
|
|
