編集可能
2010年3月29日

すごく・・・紙文化です

まとめました。
8
Kenichiro Ota @oota_ken

CoreBanking Renovation Framework...., これが真のMDDのなのか!いきなりビジネスエンティティのライフサイクル分析から始まる!僕がやりたかったのはこれか!さらばExcel方眼紙!

2010-03-27 20:48:56
Kenichiro Ota @oota_ken

COBOLはクラウド時代でも生き延びるとは恐ろしい・・・エンタープライズ向けがでてきたらまあサポートするところもでてくるよね。でも、それってIaaSどまりであんまりうれしくないよーな。

2010-03-27 21:33:54
Kenichiro Ota @oota_ken

正直、固定長フラットデータ電文というCOBOL脳の人と話すのは激しく疲れるんだけど、まあ、お客様もそれベースで話すのでユビキタス言語なんだと思ってそっちに歩みよろうともがいてます。

2010-03-27 21:36:02
Kenichiro Ota @oota_ken

だめだ!COBOLのこと考えるとつらくなってくるw 理想のモデリング世界に逃避しよう・・・

2010-03-27 21:41:25
Kenichiro Ota @oota_ken

ふむ、エンティティーまたぎのロジックはルール・エンジンにぶち投げるのか。変に責務をどちらに寄せるとか、OOではない新たな概念を持ち込み出すとかじゃなくてこれはこれでありかも。でも、これなんてDOA?多分、ルールの部分が実際のビジネスユーザーに認識できる単位というところが違う。

2010-03-28 00:20:30
Kenichiro Ota @oota_ken

ビジネス・プロセスと同じにそのビジネス・プロセスで使用するビジネス・エンティティのライフサイクル分析をする。

2010-03-28 00:27:53
鈴木三紀夫 @mkoszk

@oota_ken 僕はDOAぽく考える人です。エンティティが何かによって変わると思います。例えば、「受注」を考えてみます。ある流派では、受注はトランザクションの結果を格納するものとみなし、受注処理に関わるロジックは別に切り出します。ある流派は、受注そのものを処理とみます。

2010-03-28 00:28:14
鈴木三紀夫 @mkoszk

@oota_ken ELH。エンティティ・ライフ・ヒストリと教わりました。

2010-03-28 00:29:01
Kenichiro Ota @oota_ken

というか、ビジネス・エンティティのライフサイクルからビジネス・プロセスを見る。ビジネス・エンティティごとにビジネス・プロセスのライフサイクル分析をして、ビジネス・プロセスでマージする。

2010-03-28 00:29:15
Kenichiro Ota @oota_ken

これは、プロセス先行でデータがおざなりになりがちなSOAの開発プロセスを補完する良い方法だと思う。ていうか、OO的にはこっちの方が自然だ。

2010-03-28 00:29:57
Kenichiro Ota @oota_ken

今の参照モデルだとイベント(トランザクションと考えてよい)自体もエンティティとしています。

2010-03-28 00:32:34
鈴木三紀夫 @mkoszk

@oota_ken 金融系のシステムでは、ELHを中心に考えることが多いですね。

2010-03-28 00:32:38
Kenichiro Ota @oota_ken

普通預金口座に入金するのようなトランザクションの場合、単に口座の残高を帰るだけでなく、「入金」自体もイベントエンティティとして「こと」を記録するために永続化対象になります。

2010-03-28 00:33:51
Kenichiro Ota @oota_ken

今のお客様だとこの「イベント」というのがトランザクション・ログという形でいろいろなものがぐちゃぐちゃに入ってしまっている点でこのモデルを使って、もっと概念を切り分けたいなあと思っています。

2010-03-28 00:35:11
鈴木三紀夫 @mkoszk

@oota_ken はい、僕らテストエンジニアは、エンティティ単独の状態遷移を考えるだけでなく、その各エンティティの状態の組の状態遷移も考えます。でも、複雑すぎてわけがわからなくなることもあります。

2010-03-28 00:35:22
Kenichiro Ota @oota_ken

@mkoszk はい、エンティティの複合状態分析についても今のプロジェクトでご提案したのですが、「それフラグ分析なので細かくなってからやります」いや、そういうのじゃなくて、ビジネス・エンティティレベルなのですが・・・

2010-03-28 00:38:21
鈴木三紀夫 @mkoszk

@oota_ken そうです。入金エンティティには、口座番号も入り込んでいるわけですが、それを外部キーとしてみるか、述語のパラメータとみるかなど、流派によって見方が違うのです。

2010-03-28 00:39:04
Kenichiro Ota @oota_ken

ビジネス・プロセス上に出てくるビジネス・エンティティを分析するというのはOOな人や海外のSOAプロジェクトでは普通らしいのですが、どうも日本の金融のお客様ではそもそもそういう発想がないのかな?状態遷移モデルは組み込マーには普通でもエンタープライズ系では異端?

2010-03-28 00:39:59
鈴木三紀夫 @mkoszk

@oota_ken 要件定義というか、業務分析レベルで分析しておかないと、手遅れになりますよ。この分析を外部設計まで引き延ばしてしまうと、フラグ操作の嵐になってテストは爆発します。(^_^;)

2010-03-28 00:41:15
Kenichiro Ota @oota_ken

@mkoszk そこら辺はモデリングした結果のエンティティの違いですよね。今のモデルだと正規化されまくっているから、口座エンティティに属する入金エンティティにとっては外部キー(サロゲートキーだと外部キーですらないですが)ですね。お客様のモデルだと入金ログ自体には入ってしまいます。

2010-03-28 00:41:59
Masayoshi Hagiwara @masayh

伝票の記録としか思っていないのでは。紙文化です@oota_ken 日本の金融のお客様ではそもそもそういう発想がないのかな

2010-03-28 00:42:34
Kenichiro Ota @oota_ken

@mkoszk ・・・それはお客様に何度も申し上げたのですがOTL 僕もテストエンジニアと二束のわらじなのでその観点からも申し上げました。

2010-03-28 00:43:16
Kenichiro Ota @oota_ken

@masayh すごく・・・紙文化ですw

2010-03-28 00:43:43
鈴木三紀夫 @mkoszk

@oota_ken 僕は通信制御のお仕事をやっていたおかげ+ジャクソンのJSDを知っていたおかげで、状態遷移モデルでみることが多いです。でも、そうでない人が多いですね。まぁ、そのおかげでテストエンジニアとして、つまり、分析者の視点とは異なった指摘ができています。

2010-03-28 00:45:45
残りを読む(42)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?