トップ «前の日記(2006-06-25) 最新次の日記(2006-06-27)» 編集

日々の破片

2006-06-26

_ LL Ring

買った。

_ まとめ

良くわからなくなったのでまとめてみた。わかる粒度が名前を知ってるだけ、概念を理解している、実際に利用したまでばらけているので、嘘八百のような気もする（というか、嘘は確実にある）。

こういうときにマインドマップってのを使うんだろうか？

EA（全体統合）
　BA　……　プロセス
　DA　……　データ
　AA　……　制約
　TA　……　実装
　
DOA（AS IS重視）—フラット—物理モデル—ボトムアップ
まずモノ（エンティティとリレーション）
　検証手段：エンティティの整合性
　思考法：join

抽象的　　T字型派……純粋抽象派（ここに含めるべきではないのでは）
　↑　　　伝統派……業務分析
　↓　　　TH派……帳票上のエンティティ
具象的　　はぶ派……UI（Webのページ、帳票など）上のエンティティ＋業務フロー

（頂いたコメントを元に修正：7/1）
伝統派……業務分析
TH派……帳票上のエンティティ
T字型派……UI上のエンティティ+自然キー
 （マスター重視↑　／　イベント重視↓　−という印象を受けたけどどちらも必要なのは共通のはず）
はぶ派（T字型改）……UI上のエンティティ+システムキー+業務フロー
 
OOA（TO BE重視）—レイヤリング—概念モデル—トップダウン
まずプロセス（ユースケース）
　検証手段：ユースケース
　思考法：継承
いろいろ
　いろいろある（BCEとか）
TFP分割
　データモデル＋ビジネスフィーチャ＋SOA
述語駆動
　DOAと一線を画す。良くわからない
アーティファクト複合化（注目）
　矛盾を許容。最終段階で工学的に解消（良くわからないが、これは開発プロセス含めて実装手段のような）
　
その他の現時点での周縁技術
メタモデル（独立）
アスペクト指向
状態遷移機械（FSM）
DSL

で、さらにAで終わり、Dまで含む、I（implementation）まで進める（はぶ派）まで分かれる（ということは、Aの対象粒度も千差万別ということだ）。が、ここでは、Iは含まない（AAとDAのボーダーラインまで）と考えるのが吉だろう。

なお、おれの主となる立ち位置はTAとAAのボーダーラインなので、特にOOAの百家争鳴ぶりは半分（理解できる点もあるので半分）不思議に見える。

本日のツッコミ(全11件) [ツッコミを入れる]

_ WR (2006-06-27 00:09)

用語の用法が違うかもしれませんが、T字形は純粋抽象派というよりは、理想主義が近いかもです。 理由は、 * ナチュラルキー重視: 実ビジネスで用いられるIDを鍵に業務分析を行い、そのIDを主キーとする。 　* 実ビジネスに対して、IDの整備を求める 　* ITに対して、実ビジネスにおけるナチュラルキーの変更への対応を求める * 正規化重視: 対照表に代表される交差エンティティを多用する 　* （正規化不十分な）既存データの移行時にデータ構造の変換を求める 　* （大部分の）SQL不慣れなプログラマにJOINを多用したデータアクセスを求める というように、現実にいろいろ難題を突きつけるからです。

_ arton (2006-06-27 01:17)

ツッコミありがとうございます。上で使っている用語は摘み食いだから元々正確じゃないです。 わからない点：交差エンティティの多用とJOIN重要というのは、DOAそのものとは違うの？そこだけ取り出すとはぶさんのと違わない（もちろん、IDが違うというのはわかるし、おそらく分析手順も違うと思うけど）ように見えます。（すると、上の絵を現実主義←→理想主義と書き直した場合、その2点は同じになってしまうけど、それはらせんということになるのかな？）

_ WR (2006-06-27 02:07)

>DOAそのもの 実はT字形とはぶ流以外知らないのですけど、自分の理解では、DOA＝要求分析（or機能定義）時点でデータモデル（あえてリレーショナルモデルとは書かず・・・）にある程度の重きを置いてアプローチするやり方と理解しています。 データ中心に要求・機能を捉える態度とでも申せましょうか。 ですので、出来上がるデータモデルが、 * リレーショナルモデルか？ * どの程度正規化されているか？ * 実装（リレーショナル物理モデル）に落としやすいか？ などはとりあえず留保するというイメージです。 ということで言うと、T字形はDOAで、かつ、そのデータモデルは比較的物理モデルに落としやすいモデルあるという特徴を持つと思います。 はぶ流（とその関連技法）は、T字形の弱点を補完すべく、 * アイデンティファイアの導入 * イベント間の交差エンティティの導入 --- * （IT適用範囲の拡大に伴い複雑化したUIを踏まえて）UI重視の態度 * ワークフロー実装のためのS2Buri などの拡張・補強を行ったものと大くくりで理解しています。 > らせん ここらへんはちょっと議論したいところですけど、自分も仕込みが必要そうですね・・・:-)

_ arton (2006-06-27 03:09)

>データ中心に要求・機能を捉える態度とでも申せましょうか。 まあ、それはDOAという言葉が先に来ている以上そうですね。 ちょっと思考実験に入るけど、データを格納するその先のデータベースの実装がOODBだった場合は、それでもDOAなのだろうか？

_ まこたん (2006-06-27 08:30)

ほぼ書き終わったのにカーソルキーで戻そうとしたら画面戻しちゃったよ・・・(T.T) 羽生さんの元々の方法はT字形をベースにした方法でT字形の問題点を解消してます。T字形自体が画面や帳票を元に作業してあとからまとめるっていうやり方なので基本線としては今でもそれほど変わってないです。 はぶさんの最近の方法(ABD)はワークフローエンジンとかルールエンジンの存在を設計の各段階に取り込んでる最中に本人の頭の中であれやこれやが一緒になってDB設計が本来の姿に戻ったって感じですね(笑) 手順としては業務設計〜画面設計〜DB設計っていう所はそれでもほとんど変わってないと思います。変わったのはそこで使うツールとライブラリが前提になったことかな〜

_ はぶあきひろ (2006-06-27 09:04)

ですよ＞データを格納するその先のデータベースの実装がOODBだった場合は、それでもDOAなのだろうか？ 但し、DOAの要点はデータ構造とアルゴリズムの分離なので、OODBMSにインプリしても面白くない（ｗ で、DB設計の都度払いはRDBMSでも可能。但し、スキーマ進化の問題がある。でもこれはOODBMSでも未解決。10年前の処理を再度やって欲しいといわれたときに、バックアップデータを戻すだけじゃなくて、アルゴリズムもロールバックできないといけないという話。

_ はぶあきひろ (2006-06-27 09:08)

DOAにもToBe派とAsIs派がいます。というかDOAもToBe派が殆ど。 ではOOAとの違いは何かというと、カプセル化を許容するかどうかの違い。逆に言えばそこしか違わないんじゃないかという気がする。 なんだけど、カプセル化を許容する＝オールドスタイルのOO（当時）なので、正規化に反することになる。DOA側のOOAに対する指摘は「クラス設計の指針をどうやって担保するのか」ということ。

_ はぶあきひろ (2006-06-27 09:13)

POA対DOAっていう図式があるのも忘れてはならない。プロセス主体の構造化技法。構造化技法には2つあって、プロセス主体のものとデータ主体のものがある。後者はデータ中心の構造化技法と言われるので、尚更ややこしい（ｗ で、前者が形を変えてOOA（の初期）になったようにも感じられますが、ここにも断絶がある。 今の若い人たちはUMLがなかった時代のOOとかを知らないので、この辺の確執は実感できないのかも知れない（ｗ　私はシュラメラですけど、DOA臭いということで忌避されてたもんな〜＞シュラメラ

_ arton (2006-06-27 10:06)

どうもありがとうございます。>まこたん（名前にたんが付いてる人にはさんは付けない）、はぶさん。 ここまでのまとめ：T字型に対する本文の認識は間違い（後で直す）。むしろはぶさんの源流として置いたほうが良い。OOはカプセル化を許容（というか推進）→正規化に反する→クラスの設計方法によって制約する→何が担保か、というのがDOAからのOOA批判となる（このあたりとよくわからないアーティファクト複合化は結びつくのかな）、POAを忘れるな。UMLドリブンの設計→属性を埋めることとコンポジションによって正規化まで持ち込める（ボキャブラリーの出現箇所で制約できますね）。 このあたりについては整理できたように思えます。 #都度払いはアジャイル（非アジャイルなRUPでも同じと思うけど）にイテレーションで精度を上げていく話だと思うので10年データを持ち出すのはちょっと違うと思います。

_ はぶあきひろ (2006-06-27 10:30)

シュレイアー＆メラー法です。これとか。 http://www.amazon.co.jp/exec/obidos/ASIN/4894710366/

_ arton (2006-06-27 10:42)

おお、どうもありがとうございます。 #そうか（全然関係ないところにとぶけど）、ルーツ本というのはおもしろいな。