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

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

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

---

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

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

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

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

---

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

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

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

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

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

---

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

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

---

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

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

---

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

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

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