CoreBanking Renovation Framework...., これが真のMDDのなのか!いきなりビジネスエンティティのライフサイクル分析から始まる!僕がやりたかったのはこれか!さらばExcel方眼紙!
2010-03-27 20:48:56COBOLはクラウド時代でも生き延びるとは恐ろしい・・・エンタープライズ向けがでてきたらまあサポートするところもでてくるよね。でも、それってIaaSどまりであんまりうれしくないよーな。
2010-03-27 21:33:54正直、固定長フラットデータ電文というCOBOL脳の人と話すのは激しく疲れるんだけど、まあ、お客様もそれベースで話すのでユビキタス言語なんだと思ってそっちに歩みよろうともがいてます。
2010-03-27 21:36:02ふむ、エンティティーまたぎのロジックはルール・エンジンにぶち投げるのか。変に責務をどちらに寄せるとか、OOではない新たな概念を持ち込み出すとかじゃなくてこれはこれでありかも。でも、これなんてDOA?多分、ルールの部分が実際のビジネスユーザーに認識できる単位というところが違う。
2010-03-28 00:20:30@oota_ken 僕はDOAぽく考える人です。エンティティが何かによって変わると思います。例えば、「受注」を考えてみます。ある流派では、受注はトランザクションの結果を格納するものとみなし、受注処理に関わるロジックは別に切り出します。ある流派は、受注そのものを処理とみます。
2010-03-28 00:28:14というか、ビジネス・エンティティのライフサイクルからビジネス・プロセスを見る。ビジネス・エンティティごとにビジネス・プロセスのライフサイクル分析をして、ビジネス・プロセスでマージする。
2010-03-28 00:29:15これは、プロセス先行でデータがおざなりになりがちなSOAの開発プロセスを補完する良い方法だと思う。ていうか、OO的にはこっちの方が自然だ。
2010-03-28 00:29:57普通預金口座に入金するのようなトランザクションの場合、単に口座の残高を帰るだけでなく、「入金」自体もイベントエンティティとして「こと」を記録するために永続化対象になります。
2010-03-28 00:33:51今のお客様だとこの「イベント」というのがトランザクション・ログという形でいろいろなものがぐちゃぐちゃに入ってしまっている点でこのモデルを使って、もっと概念を切り分けたいなあと思っています。
2010-03-28 00:35:11@oota_ken はい、僕らテストエンジニアは、エンティティ単独の状態遷移を考えるだけでなく、その各エンティティの状態の組の状態遷移も考えます。でも、複雑すぎてわけがわからなくなることもあります。
2010-03-28 00:35:22@mkoszk はい、エンティティの複合状態分析についても今のプロジェクトでご提案したのですが、「それフラグ分析なので細かくなってからやります」いや、そういうのじゃなくて、ビジネス・エンティティレベルなのですが・・・
2010-03-28 00:38:21@oota_ken そうです。入金エンティティには、口座番号も入り込んでいるわけですが、それを外部キーとしてみるか、述語のパラメータとみるかなど、流派によって見方が違うのです。
2010-03-28 00:39:04ビジネス・プロセス上に出てくるビジネス・エンティティを分析するというのはOOな人や海外のSOAプロジェクトでは普通らしいのですが、どうも日本の金融のお客様ではそもそもそういう発想がないのかな?状態遷移モデルは組み込マーには普通でもエンタープライズ系では異端?
2010-03-28 00:39:59@oota_ken 要件定義というか、業務分析レベルで分析しておかないと、手遅れになりますよ。この分析を外部設計まで引き延ばしてしまうと、フラグ操作の嵐になってテストは爆発します。(^_^;)
2010-03-28 00:41:15@mkoszk そこら辺はモデリングした結果のエンティティの違いですよね。今のモデルだと正規化されまくっているから、口座エンティティに属する入金エンティティにとっては外部キー(サロゲートキーだと外部キーですらないですが)ですね。お客様のモデルだと入金ログ自体には入ってしまいます。
2010-03-28 00:41:59伝票の記録としか思っていないのでは。紙文化です。@oota_ken 日本の金融のお客様ではそもそもそういう発想がないのかな
2010-03-28 00:42:34@mkoszk ・・・それはお客様に何度も申し上げたのですがOTL 僕もテストエンジニアと二束のわらじなのでその観点からも申し上げました。
2010-03-28 00:43:16@oota_ken 僕は通信制御のお仕事をやっていたおかげ+ジャクソンのJSDを知っていたおかげで、状態遷移モデルでみることが多いです。でも、そうでない人が多いですね。まぁ、そのおかげでテストエンジニアとして、つまり、分析者の視点とは異なった指摘ができています。
2010-03-28 00:45:45