流通XML-EDIと、それをJavaで開発する流通業システムに流用する可能性

　前のブログの最後に書いた流通XML-EDIについて、
　・まず、なにそれ？ってことと
　・個人的に思う、いいことと悪いこと
　・Javaで開発する流通業システムに、応用できるかどうか
について、ちょっとまとめようと思います。

---

まず、流通XML-EDIは、流通システム開発センターが、
卸、小売業向けにEDIを行うために開発したXML
「JEDICOS(Japan EDI for Commerce Systems )XML-EDI」
の俗称という定義が、ふつうのようです(ここの説明は、そうなっている）
なお、そのXML-EDIについては、こちら

ただし、ふつう、これより有名なのは、流通XML-EDIサブセットで、こっちは「システム！」です（実際に動くプログラムがあって、ちょっと面倒な（代表者の許可までいる）手続きを経ると、タダでもらえる）。

---

　このいいところは、流通XML-EDIの概説書というのがあって、（それは、昔は申し込めば、煩雑な手続きなしでタダでもらえた。ウィリアムのいたずらは展示会でもらった。いまでも、くれるのかな？）その中に、
　・流通業の標準的な業務とその流れ（つまりビジネスモデル）が記載されていること
　・それら業務間でデータを交換する上でのXMLが、記載されていること
　　　（タグが分かりやすく書いてある）
　なので、これをたたき台として、業務を検討できることがいいところ。

　しかし、だめだめなのは、
　・それをシステムとして作っちゃ、利用できないジャン！
　　流用しようとしたとき、手を入れないといけないし、そもそも、そのソフトを手に入れるのに（ただだけど）、代表者の了解までいるなんて。。。

　・その概説書の手順がある意味わかりにくく、クラス分けされているでもなし。。。
　ということで、ちょっと、そのまま使えるものではないのよ。

---

　でも、せっかくXMLもできてるわけだし、クラスもメソッドも、概説書をみると、大体わかるし。
　
　概説書の内容なら、たぶん、書いても差し障りないだろうし（タダで、別にサブセットみたいになにか書かなきゃいけないわけでなく、自由に配っているんだから）、Javaのクラスにまとめておけば、extensionして使えるよね。
　まあ、Java知らない人でも、クラスとメソッドみれば、基本的に、それ、たたき台に考えられるし。
　ちなみに、それって、MVCモデルのM(モデル）の部分に相当するわけなんだけど。。
（だから、フレームワークなんかとは直接関係無く、そのクラスから継承させて、改造することもできるし）
　そうすれば、Javaで開発する流通業システムに流用する可能性も出てくるよね。

　うーん、クリック数多かったら、書いてみようかな。。。

---

　統一伝票なんかも、クラスにしておいて,setterとgetter作っておいてくれて、FOPで出力できるように、XSLT書いておいてくれればいいのに。。。そうすれば、cocoonでだせるじゃん。

　流通システム開発センターに、Javaのプログラマを送り込む必要があります。

デザインパターンもいろんな本が出てるけど、何から読んだらいいか、わかりにくいよね

　昨日のブログで、本の話をしたので、今日も本の話。
　デザインパターンの本って、いろいろ出てるんだけど、本によっては？？？となってしまったりする。
　ちなみに、デザインパターンの意味は、こちら

　そこの説明も、
・プログラム設計時に起こる典型的な問題とそれに対する解決策を整理し、再利用できるようにまとめたもの。
という話と、
・1995年に出版された書籍「デザインパターン」の中で23のパターンが解説されたのをきっかけに

　という２つの話がかいてありますが、この一般的なデザインパターンについて書いてある本と、後者の１９９５年に出たデザインパターンの本、つまり、GoF本についての説明の本と分かれます。

■■　GOF本について書いた本
　まずは、
オブジェクト指向における再利用のためのデザインパターン
ほかには、Javaで説明した本として、
Java言語で学ぶデザインパターン入門など。
　こっちのほうの本かどうかの見分けは、「２３個の」なんとかかんとかとか書いてあったり、Iteratorの説明とかがあったら、まずこっち。

■■　一般的なデザインパターンについて書いた本
Java言語で学ぶデザインパターン入門 マルチスレッド編など。

---

　で、GoF本については、はじめの「オブジェクト指向における再利用のためのデザインパターン」から読むと、抽象的なんでわかりにくい。かりにJavaがわかんなかったとしても（わかるんならなおさら）「Java言語で学ぶデザインパターン入門」からみて、２３個のパターンは、どのように使われるのかを確認し、その後、Javaがわかるのであれば、ソースコードをみたほうが早い。

　そしてどういうときに使う、なんについてさしているのかがわかってから、「オブジェクト指向における再利用のためのデザインパターン」を読んだほうがわかりやすいと思う。

---

　あと、もうひとつわかりにくくしている話として、このデザインパターン以外にも、「典型的な問題とそれに対する解決策を整理し、再利用できるようにまとめたもの」はあるわけで、それとの関係や、現場で使うときは、どういう感じで使うのかについて、書いてないので、わかりにくいと思う。

　私は、こう理解しています。

　このデザインパターンの説明には、「プログラム設計時に起こる」ということが問題。
　つまり、システム設計するときは、システムの形態から、こういうシステムになるという、システム設計時におこる「典型的な問題とそれに対する解決策」がある。これは、フレームワークにまとめるのがふつう。

　また、このブログで触れたけれど、システム開発時には、形式的な側面と、業務的な側面がある。
　したがって、業務的な側面での「典型的な問題とそれに対する解決策」というのもある。
　たとえば、BtoC（ネットでの販売など）における集金方法っていうと、銀行振込、口座引落、カード、代引き、現金書留（前払い）などときまっていて、それぞれの手順は、業種に関係なく、お決まりのパターンになっている。
　これも、システム全体の話（小売業の業務手順など）と、ある部分（上記の集金方法など）の話がある。

　だから、表にまとめると、こんなふうになる。

典型的な問題とそれに対する解決策を整理したもの

	形式的	業務的
全体	フレームワーク	業種別の共通手順
一部分	デザインパターン	お決まり業務手順（集金方法など）

---

　そして、フレームワークは、クライアントサーバーならサーブレットまたはStrutsのように、決まった形を継承するパターンで再利用する(ActionとActionFormを継承することで利用する）。これらのフレームワークを利用すると、ある程度やることは決まっている（つまり、解決策＝ソリューションの手順はある程度決まってしまう）

　一方、GoF本に出てくるデザインパターンは、クライアントサーバーのシステム全体を捕らえるというのでなく、プログラム中のあるパターンに対して、ノウハウを適用するものだから、ユーティリティ的な扱いになる。
　たとえば、utilクラスの中にカプセル化して、プログラムの必要な場面で使ったりするとか（事実、iteratorなどは、java.utilの中に入っている）。


　そうすると、デザインパターンで重要なのは、どういった場面で、どういうときに、何をつかったらいいのかという考え方を示さなきゃいけないはずなんだけど、そういう本がなかなかないのよね。
（GoF本の２３個のパターンは、どういうものかの紹介で終わっている）
COBOLの場合の、このようなパターンに関しては、比較的簡単にわかりやすいけど（ちなみにパターンは、リスティング、エディティング、マージ、ソート、マッチング、チェッキングなどがあり、その処理結果に応じて、どれをどう使うかはわかる。

　一方、フレームワークは、そういうのがあるかというと、
　　クライアントーサーバーで行う場合、
　　　　　サーバー側で画面をつくる　　　　　　サーブレット,JSPまたはStruts
　　　　　クライアント側で画面をつくる　　　　JavaScript、VBScript、アプレット
　　など、考え方はある。。。けど、これもまとまってない。

　そのうちまとめるかも。。

---

　でも、いいたいことは、そっちじゃなくって、業務側のほう。
　業務全体についての、ノウハウをまとめたものについて、小売業、卸売業の場合の流通XML-EDIというのがあるんだけど、それについて、今後、触れて生きたいと思います。