WR blog

（佐藤正美氏新刊出版記念）新T字形ER手法「TM」で始めるシステム分析セミナー　　～短納期・高品質・低投資時代への対応～

あるみたいです。 TM/T字形ER手法に興味がある方は是非。

October 27th, 2005 | Tags: T字形ER手法 | Category: TMmethod | Leave a comment

PofEAA 読書会で話題になったので。

シンタックス的に利用する機構（＝多態性）が同じこの2つのパターン。 思うところをつれづれと書いてみたりする。

コマンドパターン

マクロでみた意味的には、そのインスタンスにコマンド実行（処理実行）に必要なデータと、ロジックを詰め込むようなイメージ。

必要なデータとロジックがインスタンスにパッキングされているがゆえに、1番目の処理Aと2番目の処理Bと3番目の処理Aを実行したい場合は、処理Aに対応したインスタンス＋処理Bに対応したインスタンス+処理Aに対応したインスタンスをキューなどに並べておき、順次実行すればよいこととなる。 コマンド実行のトリガを与えるクライアントが、コマンドのインスタンス以外に気を使わなくて良い点がポイント。コマンドクラスが、そのコマンド実行に必要なデータ、ロジックをカプセル化して保持しているから。 さらに、コマンド実行を取り消す（アンドゥ）ために必要なデータと、ロジックも詰め込むようにすることで、アンドゥ処理が可能となる。

OOPの意味的な観点でいうと、コマンドパターンは「インスタンス」に意味がある。

具体的には、同じMoveCommand(dx, dy)でも、new MoveCommand(5,10)と new MoveCommand(-10,20)は、処理内容が異なる。

多態性は、クライアントが異なるコマンド種別を統一的に実行できるために活用される。

Command cmd = queue.getCommand(); cmd.execute()

ストラテジパターン

マクロで見た意味的には、ロジックをプラガブルにしたようなイメージ。インスタンスレベルで保持するデータにはあまり重きを置かれていない。

クラスとか、インスタンスとかが本質的な意味でポイントにはならず、プラガブルな構成要素的な観点を持つものであればよい。

OOPの意味的な観点でいうと、ストラテジパターンは「インスタンス」にあまり意味がない。

プラガブルな機構を実現できれば、ストラテジが提供するメソッドはクラスメソッドでもかまわない。（暴論気味・・・）

多態性は、クライアントの統一的な利用というよりは、プラグ差し替えを実現するための機構として利用される。本質は利用形態の一元化ではなく、差し替え可能性にある。

最近のコマンドパターン

StrutsのActionFormをコマンドパターンとか言う人もいて、 ちょっと違和感を感じていたりもするけど、まぁいいかも。という気もする。

HTTPリクエストの内容を、1つのインスタンスにパックしており、かつ、ビジネスレイヤの呼び出しというロジックも（一応）実装しているから。上記に話とも一応対応している。

が、キューに格納されるでもなく、アンドゥ機構を提供するでもない点がちょっと引っかかるかな。コマンドパターンのご利益を活用しているわけではないということ。

executeメソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。 インスタンスにデータとロジックがパッキングされていることがポイント。 と思いますよー。と、気弱にまとめてみた。

September 19th, 2005 | Category: ObjectModeling, Programming | Leave a comment

PofEAA’s Wiki - PofEAA読書会第6回

行ってきた＆少しお時間をいただけたので、発表しました。

サーガ

.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”

箇条書きにて。

時間15分もらえた。

OHPは5ページ進んだ 残り30(!)ページ

サーガの定義について鋭いツッコミ

いやー書籍における定義は、自分も怪しいとおもっていのたのだよねーと。（→OHP該当ページの一番下の行を見られたし） 補償トランザクションの補償は電話（＝運用対処）

補償トランザクションの実現イメージ

純粋OLTP系処理なら黒伝＋赤伝なるイメージとなる。トランザクションデータ（=取引系データ)に、通常の取引系データ（黒伝）と、打ち消し用取引系データ（赤伝）なる2種類を用意しておき、アプリ側では、赤伝が存在する場合は、黒伝がないものとして扱うようにする。など。 ただ、ただ、大量データを扱うバッチの場合は実現方法にもう一工夫必要となりそうな気がする。 また、正方向のトランザクションと、補償トランザクションの時間差も重要。Webサービスとの絡みで論じられるロングトランザクションは、純粋なトランザクションの観点では同様であるけれども、オンラインバッチの補償トランザクションとは、時間がカナリ異なる。 これらの意味で、当日の議論は若干ずれていた気がする。その場では、理解した気になっていたのですが。すまぬ。＞皆様

バッチでキャッシュは怖い

よねー。やっぱり。

いろいろ

yyamanoさんのPCの壁紙がカッコイイ。（覗き見したった。） 議論の参加者が増えていい感じ。

整理も必要かもと、ちょっとおもったが、ドメインモデルのあたりの話は複雑すぎて、参戦できず・・・。実装センスが弱いな。＞俺

感謝

あれだけの大人数なのに、一体感をもって進められたのは、絶妙な座席配置に資する部分も大きいかと。ありがとうございます。＞オージス軍団の方々。

→ GLADさんとkukutaniさんの工夫みたい。すばらしいです。ありがとうございます。

September 11th, 2005 | Tags: PofEAA | Category: Event, Modeling, ObjectModeling | Comments (6)

渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル

公開されたようです。

August 31st, 2005 | Category: Accounting, RelationalModeling | Leave a comment

▼　早稲田大学エクステンションセンター 秋講座 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　早稲田大学エクステンションセンター（社会人向けの公開講座）の講師を、秋もやることになりました。 　秋の講座は、９月30から12月９日まで、毎週金曜日の19:00から20:30までの10回の連続講座です（10月21日、休校）。

費用が非常に安価なので、個人的にT字形ERに興味があるが、会社からお金を出してもらうのはちょっと・・・という方にオススメできます。

毎回の講座後の飲み会も楽しい。

August 28th, 2005 | Tags: T字形ER手法 | Category: TMmethod | Leave a comment

社員マスタという不思議なエンティティ（第２回）

面白いです。

August 17th, 2005 | Category: RelationalModeling | Comments (2)

XMLとスキーマ PPL Summer School 2004

via 読書記録ChangeLog

なんだか楽しそうなことが書いてありそうなんだけど、よくわからない・・・orz.

とりあえず気になるところを引用しておく。

スキーマと意味？

スキーマは、文書の意味を規定しない > XML文書全体の集合の部分集合を規定しているだけ > DTDに適合する文書を扱うスタイルシート、ソフトウェア、人間の総体が意味を規定する

スキーマは、世界中にあまたあるXML文書を、

スキーマに合致したXML文書 スキーマに合致しないXML文書

の2つに分類するだけ。

別の見解

スキーマは，integerすら持たないXML文書を、型情報を備えたオブジェクトへと昇華させる > 効率は負ける > 誤ったレイヤリングである

「誤ったレイヤリング」の「こころ」はなんだろう？？？？

スキーマの理論

よくわからない・・・が、楽しそう。キーワードだけ並べておく。

正規木文法 木オートマトン 正規文法 文脈自由（列）文法 Chomsky Hierarchy 局所文法(local grammar)

課題1: スキーマの汎用化と特殊化

広い範囲の人が合意するスキーマは複雑すぎて作れない >

日本の電子政府で必要な範囲の人名スキーマ

狭い範囲の人が合意するスキーマは広範囲の情報交換には使えない

UN/CEFACTやOASISで制定された人名（国際化）されたもの）とどう折り合いをつければいいのか？

双方向変換？

「広い範囲の人が合意するスキーマは複雑すぎて作れない」 うーむ・・・。

「XML処理手法と理論」XML [...]

August 6th, 2005 | Category: XML | Leave a comment

koichikさんのコメント : Csus4.net - Just example. ≫ Blog Archive ≫ PoEAA 4th により書名を教えてたいただき、早速購入したのですが・・・・・

む、むずいっす・・・・。 付録AのOSAの形式的定義の構成を抜粋します・・・。

A.1 ORMから第一階述語と規則への写像

A.1.1 述語 A.1.2 規則

A.2 第一階言語から数学的モデルへの写像 A.3 OSAメタモデル

A.3.1 図A.4における最初の制約の変換 A.3.2 図A.4における二つ目の制約の変換 A.3.3 図A.4における三つ目の制約の変換 A.3.4 図A.4における四つ目の制約の変換

なかなか手ごわそうです・・・オブジェクト指向システム開発―分析・設計・プログラミングへの実践的アプローチ

July 13th, 2005 | Category: Book, ObjectModeling, Think | Comments (2)

会計システムのアーキテクチャ論 - 設計者の発言

制度会計ベースのアーキテクチャについて

まず、現在の主流である「制度会計に管理会計が寄生しているスタイル」というのは、「管理会計上の諸問題を仕訳に組み込んでしまう」というものだ。とりあえずすべての取引を１個ずつ仕訳して決算書を作ると同時に、仕訳データを集計して管理会計上の諸問題を管理しようとする。

管理会計ベースのアーキテクチャについて

いっぽうの「管理会計に制度会計が寄生しているスタイル」では、仕訳テーブルは単純な形をとる。このスタイルにおいて仕訳は、公告用の決算書を出力するためだけのネタなので、必要最小限度の項目さえ載っていればいいからだ。日々の活動はそれぞれの業務データ管理サブシステムによって管理されている。個々の取引毎に仕訳する必要はなく、月次でも、場合によっては四半期毎のサマリーデータからでも仕訳すればいいので、仕訳データ量もずっと少ない。期中の進捗については、仕訳データ経由ではなくそれぞれのサブシステムが保持する数字を直接集計して監視すればよい。システムは基本的に「管理会計システム」で、決算書出力機能が「オマケ」としてついているようなイメージだ。

簿記の枠組み、すなわち、汎用の枠組みに大して、業界・業種・企業に特化したデータ を盛り込むようなアプローチには限界がある。 そして、業界・業種・企業に特化したデータをベースに汎用のデータを生成するアプローチのほうが良いと理解した。

六の日記はここにはないぞ - 仕訳をいつ作るかなあと云う話

確かに仕訳中心で全てを従属させると大統一理論てな塩梅でとても愉快なんだけど、やっぱり計上→訂正→消込とかのフローに沿った部分は債務は債務、債権は債権で別管理にしておいて、仕訳は仕訳でその時々のスナップショットみたいな考えでパカパカ生成するのみにして、「どれに対する消込かって？債権側に聞けや」みたく人任せにする形が、良かったなァ、って設計した人と後から反省した。

の話にも通じるのかなっと。

July 3rd, 2005 | Category: Accounting, Modeling | Leave a comment