ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

流通XML-EDIのJAVA化計画:その2:昨日のクラスとXML-EDIのメッセージと統一伝票の関係

2005-04-14 15:10:27 | 業務のモデル化
流通XML-EDIについて、昨日、クラスを定義したので(今日修正しました。理由は、この記事の本文中にあります)。今日は、以下のテーマについて

(今日のお題)

・肝心の流通XML-EDIには、どんな種類があるか
・XMLで定義しているのはなにか?
・そのクラスとどのようにかかわってくるのか?
・同じような小売と卸の決め事に統一伝票があるが、それはどうかかわるのか?


について説明します。




肝心の流通XML-EDIには、どんな種類があるか


 6つのメッセージ交換をXMLで定義しています。
 その定義しているものは、以下のとおりです。
(概説書P14の図をそのまままとめています)
メッセージ交換名小売からみると卸からみると
(1)商品マスタ商品情報(基本)の入力商品情報(基本)の出力
(2)発注発注の出力受注の入力
(3)入荷予定入荷予定の出力出荷予定の入力
(4)受領出荷確定の出力出荷確定の入力
(5)支払案内支払い案内の出力支払い案内の入力
(6)請求請求の入力請求の出力






XMLで定義しているのはなにか?


小売と卸のメッセージ交換部分について、定義しています。
つまり、情報のやりとりなわけで、これは、昔(というか、今でもリアルの世界では)伝票に書いてある部分のことです。

 昨日定義したのは、小売と卸の業務であり、業務は伝票の行き来(入出力)でおこなわれるので、当然、昨日定義したクラスの入出力にもなるわけです。
 その関係は、こちら(上の表と対比してね)。

メッセージ交換名小売からみると卸からみると
(1)商品マスタ商談の入力商談の出力
(2)発注発注の出力受注の入力
(3)入荷予定入荷予定の出力出荷予定の入力
(4)受領検品の出力*納品の入力
(5)支払案内支払の出力支払確認の入力
(6)請求請求書受理の入力請求書発行の出力


*納品の入力=納品が確定したことの入力の意味。納品書とは違う
5番と6番は、手順と入れ替わっています。

で、はじめ、昨日のブログのように書いていたら、入荷と出荷で、2つのメッセージが行き来することになり、他は1つなので、対照的にへん。なんか見落としてるかも?ということで、クラスを
(小売側)入荷については:入荷予定と検品に
(卸側)出荷については:出荷予定と納品に
わけました。その結果について、昨日のブログを修正してあります。




統一伝票は、どうかかわるのか


 統一伝票も、小売卸間でのメッセージのやりとりです。
ということは、上記のXML同様、統一伝票でも、伝票一枚一枚は、上記の6つのメッセージに対応、ないしは継承(XML-EDIが一般的、統一伝票が、細かくなってる)でないと変です。

 そうなっているのかについては、今後調べます。

 統一伝票の例として、e-お菓子ネット 統一伝票マニュアル 第四版を参考にしたいと思ってます。( ここにある。ただしPDF

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

本家はSkipeAPIのまとめ、ここは要求仕様書の書き方のまとめ(項目例)

2005-04-14 08:51:33 | コピーされるほど儲かるシステム!
 今日は、本家のほうに、いつもは、こっちで書くような話題である、Skype APIの現状と、それを使ったサイトの話題について(ここ)、書きまくってしまったので、こっちの話題は、時間がかからずにかける、「コピーされるほど儲かるシステム」開発日記の、要件仕様の話。

 いつも引用する「要件プロセス完全修得法」
スザンヌ・ロバートソン+ ジェームズ・ロバートソン/著 苅部英司/訳
http://www.sangensha.co.jp/allbooks/index/111.htm
では、要件仕様のテンプレートして、ボレーレ仕様テンプレートというのをあげている(P154から156)それによると、要件仕様書に書くパートは4つ。1.制約、2.機能要件、3.非機能要件、4.プロジェクト課題だそうな。

それらについて、細かく書くと、以下のとおり(以下上記の本の154から155を引用しています)。

■■ 1.システム制約
・システムの目的
・依頼主、顧客、その他の決定権者
・システムのユーザー
・要件制約
・命名法と定義
・関連事実
・仮定

■■ 2.機能要件
・システムの範囲
・機能およびデータ要件

■■ 3.非機能要件
・ルックアンドフィール要件
・使用性要件
・パフォーマンス要件
・運用・操作要件
・保守性および可搬性要件
・セキュリティ要件
・文化的および政治的要件
・法的要件

■■ 4.プロジェクト課題
・未解決課題
・既製品による解決策
・新たな問題
・必要作業
・カットオーバー
・リスク
・コスト
・ユーザー向け資料の作成
・要件予備軍

(引用おわり)-----------------

うーん、こう見ると、基本的にはいいとおもうし、結果としてこんなことを書くんだろうけど。。。
まとめたほうがよさそうなところとかもあるし。。。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする