COBOLからJAVAへの変換試案 No３ システム設計編

　今回の話は、あんまり、多くの人に関係ありません。
　というのは、ふつう、分析の際、論理的な業務で作ったクラスと、
　実装したjavaのクラスの対応関係が取れなかったとしても、
　そのことで、文句を言うユーザー、発注者は、ほとんどいないと思うんです。
　ある１事業体（会社と、あえて書かないところがみそ！）を除いて。。。

　ということで、今回は、（独創的な、創造的な、まだだれも踏み込んでないような(^^)v）ＣＯＢＯＬからＪａｖａ変換のプログラムを考えちゃって、その事業体からお金（売上と書かないところがみそ！）をもらっちゃったんだけど、検収する人が、うるさくて、「これ一致してないじゃん」！などといわれたときに、逃げる、逃げ口上を考えてみましたあ！

---

COBOLの１プログラムって、たとえば、「受注表作成」のような、業務手続１個分が、１本のプログラムになるケースが多いです。この業務手続は、メソッドにあたるのが普通です。

　そこで、これをそのまま、１クラスにしてしまうと、１メソッド１クラスとなるため、分析のとき作ったクラス図に合いません。

　「メソッドがなぜクラスになるの？」

　あの事業体から出向いてきた、検査官がつっこみそうなところです。
　（出向いて・・・「でむいて」と読んでね。「しゅっこう」とよむと、「あの事業体に！でしょ」っていう話になり、意味が変わる）

---

　実は、その現象、ほかでも起こります。

　それは、サーブレットを利用したとき（strutsも当然、含む）。
　たとえば、そういうのだと、画面のボタンを押されたら、サーバー側のあるクラスのdoPost,doGet（strutsだとexecute)にはいります。
　ここで、画面のボタンって、たいてい、「保存」とか、「終了」とかのメソッドです。
　その一方、画面の１まとまりがクラスになっていたりします。

　つまり、クラスにある、「保存」とかいうメソッドが、なぜ、サーバーにいくとクラスになるのか。。。おなじ現象です。

　「メソッドがなぜクラスになるの？」

　あの事業体から出向いてきた、検査官がつっこみそうなところです。

---

　で、この説明ですが、無理やりの説明をします。

　受注とか、発注っていうのは、クラスになっていると思います。
　でも、これらのクラスも、「商品」というクラスのメソッドにもできると思います。
　そこで、
　　「商品」というクラスのメソッドである「受注」がクラスとして独立できるなら
　　「受注」というクラスのメソッドである「受注表作成」がクラスとして独立
　することは可能だ！と主張します。
　言い切っちゃえば、こっちのモンです（なのかなあ？？）

---

　で、次に、クラスには、２つの側面があると主張してしまいます。
　それは、業務の意味的な側面（たとえば、受注とか発注とか）と、
　形式的な側面（クライアントの画面としてある、サーブレットとしてあるなど）がある
と主張してしまいましょう。
　継承には、この場合、意味的な側面を書く場合と、形式的な側面を書く場合、両方を継承させる場合(extendsとimplimentsを書く場合）があると主張します。

　サーブレットやstrutsのActionクラスの継承（ extends Action)は、この形式的な側面が記載されているとします。
　そうすると、COBOLでも、パターンを使っている場合、extends そのパターンクラスとなると思うけど、これは、形式的な側面が記載されているものだと言い切れます。

---

　ということで、この事業体から、仕事を受けても、言い逃れできそうです(^^;)
　（ほんとーかよ！）

　さあ、だれか、国のお金をつかって、COBOLからJava変換をやりましょう！
　そうすれば、２００７年問題、解消。。。するのかなあ？？
　
　といって、自分ではやらないウィリアムのいたずらなのでした

　（これにてCOBOLからJavaへの変換試案　完）

むしろインターネットが進むほど、テレビの良さが分かる（ホリエモンの言ってるのの逆？）

　昨日のブログで、３つの方法を挙げて、１つのクラス（あるいはプログラム）で、複数画面があるときの書き方を説明しましたが、この方法、実は、（放送局のように）サーバーからのデータをたれ流す場合にも同じことが言えます。

つまり、インターネットのWebを利用して、サーバーが情報を送りたいときに、クライアントにおくるには、以下の３つの手法が考えられます（以下の（１）、（２）、（３）は、昨日のブログの（１）、（２）、（３）に対応しています）

（１）それでも、webの技術を使いたいあなたへ
　　　→これが、push技術にあたります。

（２）そういう動きをするプログラムをつくってしまう

（３）サーバーのプログラム（データ）をクライアントに持ってくる
　　　→実際に、サーバーのデータをすべてクライアントに置くのは非現実的なので
　　　　現在は、必要なデータを、ダウンロードして、その後、再生します。
　　　　今の主流ですよね。

---

　（１）は、しかし、クライアントから定期的に情報を取得するのが主流なので、リアルタイムな情報取得ができません。たとえば、津波情報など、一刻をあらそうような情報は、すぐに表示したいけど、１０分毎にサーバーに見に行くとか言う設定では、最大１０分も待ってしまうわけで、下手したら、津波、来ちゃいます。

　っていうことは、やっぱり、（２）のように、サーバーからの情報をリアルタイムで流すプログラムを開発しなければいけません。そういうプログラム、有線放送や、ケーブルテレビ局が、視聴者をふやすには、有効かもしれません（作る価値有り？？）

---

　でも、そんな面倒なことをしなくても、いま、放送局は、まさに、この方式です。

　放送局というサーバーから、みなさんのご家庭のテレビというクライアントに、ずーっと情報をながしてます。テレビは情報を選択しなくていいので、「ながら族」などというものを生み出しました。そういう便利なシステムです。

　っていうことは、今のwebでできないことをテレビがやってるわけで、インターネットが発達しても、（上記（２）のようなプログラムだ出来ない限り）放送は、方式が違うのですたれない、むしろ、インターネットの面倒さ（自分で選択したりしなくちゃならない）を補完するものとして、インターネットが、発達すればするほど、放送の重要性がわかるかも！

　これって、ホリエモンの言っていることの逆？それとも、放送とインターネットで言ってることは一緒？？