WR blog

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)

超オススメできる。

あとで書くかも。いや、（ビジネス的な視点に興味がある人なら）買いなさい。とりあえず。

June 19th, 2005 | Category: Book, Business, Think | Comments (2)

職場のやりとりの中で、オブジェクト指向を知らない上司にオブジェクト指向を説明する羽目になった。

たとえ話で説明したのだけど、なかなかうまくいったように思う。上司にも「わかりやすい！」と感謝してもらえ、かつマイmixi限定でやりとりを公開したら結構好評で、わたくしカナリゴキゲン（←アホ）なので、ここにもやり取りを残しておくことにする。うほ。

やりとり

上司「なんで継承構造が複雑だと問題なの？」

自分「（継承を駆使した(※)）オブジェクト指向設計のメリットは2つです。1つは、実作業者をある種のカタにはめられること。もう1つは、機能を共有できることです。」 （※: テンプレートメソッド的なイメージを持っていただければ。）

自分「たとえると、ビジネスフォームみたいなものです。たとえば、契約書とかで、本文には「甲が乙に・・・の義務を負う」みたいなヤツありますよね？ 甲の部分を変えれば別の契約書になりますし、逆に言えば、ソコしか変えることが出来ないので、いわゆるカタにはめる格好になります。そして肝心の契約本文は共有できるので、契約を起こすたびに文面を考える必要はありません。継承を多用したオブジェクト指向設計っていうのは、こんな感じなんです。」

上司「ふーん、いいじゃない。」

自分「ですけど、問題点もあるんです。」

上司「何？」

自分「たいていの開発の場合、契約書テンプレートを作る人と、テンプレートを埋める人は別の人なんです。そして、継続してメンテナンスしないといけない。しかも、契約書の場合と異なり、両者は常に整合性をもっていないとイケないんです。 たとえば、法律の改正があって、契約書を修正しないといけないとしましょう。契約書の場合だと、テンプレートを修正して終わりですけど、ソフトウェア開発の場合だと、そうはいきません。現実の契約書テンプレートとは異なり、契約書テンプレートを修正すると、この契約書テンプレートを元にして作った契約書も全部修正されちゃうことになるんです。去年作った契約書も全部です。」

上司「あー」

自分「しかも、この(イケてない)協力会社がつくったソースの構造は複雑で、契約書にたとえると、契約書の本文に、「～の詳細については、・・・を参照」みたに契約書の構成が複雑で全貌を容易につかめないような感じなわけです。 これを将来的にメンテナンスしていくのは大変ですよ。」

上司「なるほどねー」

てな具合。

June 19th, 2005 | Category: ObjectModeling, Think | Leave a comment

Doblog - Joe’s Labo -

人事制度を作る時、従業員に対して“将来のビジョン”が描けるかどうかが非常に重要 な鍵となる。十年後自分がどうなっているか、あるいは自分の希望する業務に携われる かどうか。平たく言えば「その会社で夢がかなうか」ということだ。

一見古臭そうだけど、実は大きなパワーをもつ日本企業の施策については、この本が詳しい。しかも面白い。オススメできる。

June 3rd, 2005 | Category: Book, Business, Think | Leave a comment