オブジェクト指向とDOA,構造化分析は、結局、業務プロセスによるエンティティの利用法に収束する！

　修正可能なシステムの裏づけを考えてきて、さっき、オブジェクト指向の(エンティティ）クラス抽出の手法として、ER図の正規化を利用しましたけど、結局、

・コンピューターは人がやる業務(プロセス）を代わりにやっている
・業務は、会社のリソースと、過去にやった業務をもとに、実行していく

という性格がある以上、

　　・業務プロセスと、
　　・リソース＋過去にやったイベント（業務）＝エンティティ

にわかれて、業務プロセスが、エンティティを操作して、必要な結果(出力）を得る、そのために必要な入力はどこからか得るという構図は、絶対的にかわらないわけです。

---

　そうなってくると、問題は、

・業務プロセスとエンティティをどうやって明確化していくか？
・それを、どうコンピューター上に表現するか？

　ということに、帰結してくるわけです。

　そこで、MVCというフレームワークにおいては、

・Viewの部分で、業務プロセスに必要なデータを入力し、
　業務プロセスを実行するイベントを、クリックなどで表現し、
　コントローラーに起動をかける

・コントローラーによって、業務プロセスに対応するイベント
　を受け取り、
　　　・コントローラーが、エンティティを処理して、
　　　　　結果をView(画面、帳票）にかえしてもいいし、
　　　・コントローラーが、さらにWebサービス
　　　　　（サービスは業務プロセスに当たる）を呼び出す、
　　　　　つまり、業務プロセス処理を委譲してもいい

・でも、最終的には、業務プロセス処理は、
　リソースや過去のプロセスの処理結果である、エンティティを利用する。
　この部分がモデルに相当する。

って言うことになると思うし、この場合、

プロセスを出してくる手法が、
　オブジェクト指向の場合、アクティビティ図からユースケース図
　構造化分析の場合、DFDとなり、

エンティティは、
　DOAのER図・・を導く、正規化手法ということになる。

---

オブジェクト指向の場合、エンティティでとめるのでなく、クラスにしないといけない。
クラスはもちろん、
・１業務プロセスを１クラスとして
　　　メソッドは、executeとか、doとかrunとか
・１エンティティを１クラスとし、
　　　メソッドは、CRUDとか、PutGet
というまとめかたもできる。

ただし、エンティティ内に、業務プロセスをメソッドとして入れることも出来る
（受注クラスに受注票出力とか、受注キャンセルとか入れることも出来る）
この場合、業務プロセスを、どこのクラスに入れるかの基準は、
　　Aさんが、なになにを、なんとかする
という形になっている業務プロセスは、Aさん＝＞コンピューターに業務委譲
することになるので、
　コンピューターが、エンティティ「なになに」をプロセス「なんとか」する
という形になる。

　したがって、この場合、目的語にあたる「なになに」のエンティティに、
プロセス「なんとか」を入れることになる。

　一方、
　　ランプが点灯する
　のような、主語、述語しかない場合は、主語のクラスに述語のプロセスを
入れることがふつう。

---

結論をまとめると、
オブジェクト指向とDOA,構造化分析は、結局、
　・業務プロセスによる
　・エンティティの利用法
に収束する。

　クライアントサーバ、MVCやSOA、Webサービスなど、さまざまな実装法の話が出ては消えているが、これは、プロセスは何段にでもできるので、
　・プロセスをどこにおくのか、
　・何段に設定するのか、
　・エンティティはどこにおくのか
という話に収束する。

---

ということは、修正可能なシステムということは、
修正箇所を、

・業務プロセスとエンティティに明確に分けられ、
・不用意に他のエンティティやプロセスへの影響を与えない

ようにすれば、よさそうだ。

この、「他のエンティティやプロセスへの影響を与えない」という、独立性の問題と、参照制約などの一貫性の問題がある。これらはDBでは確立しているが、それをオブジェクト指向で実現できないと、オブジェクト指向で修正可能なシステムを実現することは難しくなってしまう。

　幸いにも、実は簡単にこれは実現できる（エンティティオブジェクトの一貫性と、業務プロセスからの独立性をオブジェクト指向の基本的な性質を利用して記述できる）が、あまりにも長い話になったので、またいつか、書くことにします。

生物情報学（６）－ミトコンドリアからみたヒトの系統樹

　ひさびさに、生物情報学です。
　今回は、前に、サイエンスZEROでやっていた、ミトコンドリアからみたヒトの起源、その起源を図にあらわす系統樹を作ってみましょう！！というお話。

　ただ、ちょっとわかっていないところもあるので、授業の資料に書いてあることを、てきとーに解釈してしまっているところもあります。まちがってたらごめん

※このシリーズをはじめてみる人へ：授業＝これは、放送大学の面接授業、「生物情報学実習」でやった内容をまとめて、さらにそこで使ったソフトのページをリンクしたり、（今回のMEGAのように）もっと詳しく載っているページをメモしたりするシリーズです。

---

■まずは、下準備
（１）まず、ここで書いた、bioeditというソフトで、DNAのAGCTの配列を書いた、いくつかのミトコンドリアのデータを読み込みます。

　授業では、Nature 408 708-(2000)のMitochondrial genome variation and the origin of modern humansのデータを使ったようです（良く分かってない　＾＾；）

（２）このいくつかのミトコンドリアの配列を、自動的にアラインメントします。
　　　mafftというソフトを使う
　　　って書いてあるんだけど・・・
　　　そこのダウンロード、Windowsだとcygwinを要求してるけど、つかわなかったぞ？
　　　起動したバッチファイルを見ると、
　　　　disttbfast2、tbfast2、dndpre、dvtditrというものを実行している。
　　　コンパイルしなおしたのかな？、ま、いいか・・

（３）この出力結果をbioeditで再度確認すると、きれいになっている。

---

■次に系統樹を書く

（４）ここから、系統樹を書くには、MEGAというソフトを使うのですが、それは、以下のページ

分子系統樹の作成
http://evolgen.biol.metro-u.ac.jp/MEGA/tree-protocol.htm

にあるみたいなので、省略します。

　さらに、このあとで、授業では、塩基の変異が大きいDNA領域などを調べたのですが、perlのプログラムを使ってファイルに出していて、フリーソフトを使ったのもではないので、省略します。

---

■で、評価・・

　ということで、この生物情報学のシリーズはおしまいです。
　最後に、ここ風に、面接授業の生物情報学と、データベース実習の評価をひとつ・・
　（ちなみに、どっちも単位取れました）

●生物情報学実習
担当講師：二河 成男
評者 ウィリアムのいたずらさん
東京文京　科目履修生（ただし、「生物情報学実習」は、千葉で行われます）

単位取得難易度　１
学問的レベル　５（ただし、やってることがわかってない人にとっては、２）
授業の面白さ　５（ただし、やってることがわかってない人にとっては、３）

評者のコメント
　単位取得は楽勝。授業に出ていればOK。
　プリントがあるので、そのとおりに操作していても、それなりに楽しい。
　ただ、そのやっていることがわかったら、「すんげえ（＠＿＠！）」と思う授業。
　DNAの解析から、遺伝子、タンパク質の構造までの、一連のコンピューター処理の流れを、すべて、フリーソフトでやってのけてしまうというすごさがある。大学の生物の授業って、他大学では、ここまでやるんだろうか・・

　分かる人には、そーとう楽しいと思うし、分からない人にも、それなりに楽しい授業です！！
　（分かる人には、超お勧めです）

●データベース実習
担当講師：日下部貢一
評者 ウィリアムのいたずらさん
東京文京　科目履修生（文京の授業です）

単位取得難易度　５
学問的レベル　３（ただし、やってることがわかってない人にとっては、５）
授業の面白さ　５（ただし、やってることがわかってない人にとっては、１）

評者のコメント
　単位取得は授業出席とテスト。
　Windows操作ができればOKみたいなことが書いてあるが、その程度では、きついと思う
　（「生物情報学実習」はその程度でOK)
　Accessを使って、１日目は正規化理論の第一正規形から第三正規形までを行い、
　２日目（１週間後）は、実習となる。
　正規化理論の説明は非常に丁寧で分かりやすい。
　しかし、１週間後に、「はいじゃあ、それでDB組んでくださいね、終わったらテストですよ！」
　っていうのに、Windows操作がやっと出来る人が、ついていけるのかどうか・・（＾＾；）

　正規化理論を勉強したい人には、良い授業だが、
　何にも知らない人には、もっと楽に取れる授業が、いいかもよ・・

よりオブジェクト指向らしくするために、DOAを応用する？

　前に、修正可能なシステムを作ることが大事で、オブジェクト指向においては、修正可能にしやすくなるために、カプセル化を行うという話を書きました。

　しかし、このカプセル化、逆に言うと、関連している事項までみえにくくしてしまいます。
　そうすると、修正しにくくなってしまいます（修正すべきところが、カプセル化によって隠れてしまい、修正し忘れてしまいます）

　したがって、１事実１箇所に書き込んで、不要な関連（従属性）をなくし、できるだけ局所化するようにしなければいけません。

　１事実１箇所にするってことは・・・DOAで、ER図を作ったり、さらにテーブル設計に使う、正規化を行うことになります。第二正規形、第三正規形を行うことによって、エンティティの不要な従属条件は排除されます。
　このエンティティがクラスなら、いいっていうことになりますが。。

---

　ここで、MVCモデルを考えてみます。
　View（＝画面）から、ボタンを押すなどのイベントを起こし、サーブレットなどのコントロール(C)を呼び出した場合、このイベントは、なんらかの仕事をさせようとしています。つまり、プロセスや、ユースケースに関連していることになります。あるプロセスを実行したいから、イベントをあげているわけです。

　そして、プロセスは、DBにあるテーブルの値（＝エンティティの属性値）を使って、処理を行い、結果を返したり、出力します。このDBのテーブル値の入出力を行う部分と、それに関係する処理を行う部分がモデルといえそうです。

---

って考えると、

　　　プロセス　　→　　　エンティティ

という部分がありそうです。

これを、

　　　プロセス　　→　　　エンティティ
---------------------------------------
コントロール　　　→　　　モデル
サーブレット　　　→　　　モデルのクラス
セッションBean　　→　　　エンティティBean

のように実装しても、かまわないですし、
プロセス部分を

　　　プロセス　　　　→　　　　　　エンティティ
-------------------------------------------------
クライアント→サービス提供サーブレット　→　モデル

のように、多段にしてもかまいません。

とにかく、プロセス提供部分と、エンティティ部分に分かれます。

---

　このとき、プロセス部分の一例である、サーブレットがクラスということから想像つくように、プロセス提供部分はクラスにすることは出来ます。
　さらに、クラスにしないこともできます。
（例：全プロセスが、１つのサーブレットに行き、
　　　そのサーブレットが各プロセスに対応するエンティティクラスのメソッドを呼ぶことも
　　　技術的には出来る）

---

　一方、エンティティ部分に相当するクラスは、ER図のエンティティ、
RDBのテーブルに相当してくるわけで（同じではないにしろ、似ている）

そうなってくると、ER図を作成したときの正規化理論が使えるというか、正規化してできたエンティティにクラスを関連づけないと、おかしな話になってきそうです。

　ということで、オブジェクト指向の局所化を実現し、修正を少なくするには、エンティティ部分のクラスに関しては、１事実１箇所にすべきで、それには、正規化理論を使うのが素直ということになりそうです。

「食の安全」を守るには、やっぱリアルタイムBI（ビジネスインテリジェンス）だよね！

　さっき、NHKスペシャルで、
「食の安全」をどう守るのか
～冷凍ギョーザ事件の波紋～
http://www.nhk.or.jp/special/onair/080330.html
っていうのをやってた。

あの毒餃子の件だけど、はじめに毒餃子をたべて大変なことになっちゃう前に、
異臭がするとか、３件のケースが報告されていたそうな。。
しかし、それを見落としてしまったっていう問題。。

これなどは、報告があったら、その報告をデータベースにしておいて、商品発注画面で、
その商品をバイヤーさんが発注しようとしたら、そーいう”やばい報告”があるのを知らせればいいっていうことになるだろう。

---

また、別の話で、アメリカのバーガーキングでは、
冷凍庫の温度が上がった時間をチェックしていて、普段（補充などで）あけることのない時間に
温度が上がっていたら、「おかしい！！だれか侵入したな（－＿－）」ってことで、すぐに
調べるということだった。

　これに対して、「日本は、温度をしらべても、そーいう監視をしていないから」と解説していたけど、こーいう自動的に監視していて、おかしいことがあったらアラートを上げるというのは、まさにリアルタイムBI（ビジネスインテリジェンス）の世界の話だ。

---

　上の報告の話も、もちろん、自動的に監視してアラートをあげる（そのアラートを発注画面にだす）ということなので、BIの話といえるだろう。

　とはいえ、BI自体の話は、古くさい話なので、BIのマッシュアップ（さっきの例でいえば、商品発注画面は、Web化されてあって、それに、報告データベースからやばい情報を抽出するWebサービスを作成し、クライアント側で表示するよう、GreaseMonkeyを使ってマッシュアップするっていう感じ）とか、さらに、オープンソースBIの話と絡めるとか、なんかひとひねりは必要だと思うけど、

食の安全にからめて、リアルタイムBI＋マッシュアップとか、SOAとかの新しい話っていうシステム提案は、アリだと思うね！

日本Linux協会初代理事長の生越昌己氏は。。。

今、こんなところで、連載をしてるのね
生越昌己のオープンソースGTD
http://itpro.nikkeibp.co.jp/watcher/ogochan/index.html

富士通の社長交代で、現在の黒川社長の評価記事が出ているね！

ここのプレスリリース
役員人事について
http://pr.fujitsu.com/jp/news/2008/03/27-1.html
を紹介するまでもなく、次期株主総会とその後の取締役会の承認を経て、富士通のトップ人事が変わり、現在の黒川社長が相談役に退くようだ。

で、それに関して、黒川社長の評価記事がでている。

富士通のトップ交代、黒川社長の最大の功績とは？
http://itpro.nikkeibp.co.jp/article/Watcher/20080327/297343/
たしかに、東証をのりきったっていうことが、いちばん大きいんでしょうね。
（以下斜体は上記ITPROからの引用）

当時までは「お客様は神様、システム・トラブルはすべてベンダーの責任」という風潮が確かにあった。要件定義はユーザーの仕事、システムのバグはゼロにはできない、ベンダーは契約以上の義務を負えない、といった当たり前の認識ですら世間では希薄だった。

　だから、あの局面で最大手SIerのトップである黒川社長が、契約や要件定義にないことについてまで“責任”を取って辞任なんかしていたら、ITサービス業界全体がミゼラブルの状況に追いやられていただろう。そんなわけだから、あの猛烈なバッシングの中で、黒川社長が「契約内容を超えた負担には応じられない」と言い切り筋を通したことを、私は評価している。


というのは、確かにあると思う。
でも

　実際これがきっかけで、ユーザーとベンダーの関係、契約や要件定義の問題、システム・トラブルへの対処法などで、少しは冷静な議論ができるようになったと思う。


いや、それはまだ・・・（＾＾；）


でも、どっちかというと、ウィリアムのいたずら的には、一番の功績は

社長就任当時の、

SIでの火だるまプロジェクト

を、一応どーにか、しゅうそく（収束？終息？）させたことだと思う。


発生しない体制作りに一応成功し、業績を回復させた。

と、言いきれるかどうかは、まだ分んないと思うけど

高橋名人、１６連射ならず！

ここのニュース
＜高橋名人＞スターソルジャーで“16連射”ならず　山本梓も尊敬　Wiiウェア版記念イベント
http://headlines.yahoo.co.jp/hl?a=20080329-00000000-maiall-game
によると、高橋名人、１６連射ならず、
11.9連射だそうな・・・

「Firefox 3」と言うより、mozillaがマイクロソフトにとって脅威となる理由

ここの記事
「Firefox 3」がマイクロソフトにとって脅威となる理由
http://japan.cnet.com/special/media/story/0,2000056936,20370332,00.htm
では、FireFoxが、IEにとって脅威となる話についているけど、

いや、そんなレベルの話じゃなくって、
今後のmozillaがマイクロソフトにとって脅威となってくると思う。

今後、SOAが進み、クラウドコンピューティングになってくると、Greasemonkeyのような、クライアント側で、サービスをまとめる手段や、mozillaがやっている、 personasやprismのようなWebとOSの融合、Web－OS化が必要になってくると思う。このほか、mozillaでは、クラウドコンピューティングに向けて、Weaveとかもやっているわけで（一連の話については、Mozilla LabのChris Beard氏のお話のところで書いた）・・・

こうなってくると、IEとかFireFoxといったブラウザレベルのお話ではなく、次のクラウドコンピューティングによるWebとOSの融合（Web-OS化）の部分で、mozillaのほうが先に行っているように見えるわけで、この点のほうが、マイクロソフトにとって、脅威だと思う。

　なお、ウィリアムのいたずらが、まえに、Web３．０は中継局みたいなことを書いたけど、WebOSは、中継局が手元にあるような感じと捉えると、WebOSの世界は、Web３．０なんじゃないかな。。という気がしている。。

「中国、初の国際旅客機」のニュース、ナムコのゲームと全く同じ所を飛んだのでなければ、著作権は？

ところで、もし、

テクノバーンの以下の記事
中国、初の国際旅客機「ARJ-21」の1号機が完成
http://www.technobahn.com/cgi-bin/news/read2?f=200712222045&photo=zoom

の中国の国際旅客機が、

バンダイナムコのエースコンバット04のダウンロードの壁紙
http://www.acecombat04.com/down/down_7_b.html

と、まったくおんなじ空を寸分たがわず飛んだのではなく、

合成写真だったとしたら、

（中国の人へ：いや、仮定ですよ、仮定！！）

ニュースを配信したテクノバーンは、著作権侵害になるんだろうか？
たぶん、テクノバーンは中国から提供された写真を貼っただけだよね・・

「iモード普及の立役者、夏野剛氏がドコモを退職」って、まじ（＠＿＠）！。。。

ここのニュース
iモード普及の立役者、夏野剛氏がドコモを退職するとの報道
http://headlines.yahoo.co.jp/hl?a=20080328-00000061-zdn_m-mobi
によると(以下斜体は上記サイトより引用）


　日本経済新聞は3月28日、「NTTドコモの夏野剛氏が4月末でドコモを退職する」と報じた。ドコモの広報部では「人事のことなので何もコメントはできない」としている。


もし、やめないなら、「やめないよ！」って言うだろうし・・・
あやしーよねー・・・

ちなみに、夏野氏とは

夏野氏は、現在ドコモの執行役員 マルチメディアサービス部長を務めており、iモード普及の立役者とされる人物。

修正可能なシステム構築実現の論理的根拠（EAの失敗から出てきたロハス化）

ここの記事
崖っぷち！電子政府～迷走する4500億円プロジェクトの行方・第3回：
問われるGPMOの調整機能 (2/2)
http://www.itmedia.co.jp/enterprise/articles/0608/15/news002_2.html

を大雑把に言うと、電子政府の設計概念として使われたEAが失敗し（と上記記事では言い切ってないものの、ほぼ、そういう論調だ）、ロハス化（LOHAS化）という概念が生まれてきた。

　このLOHAS化は、環境なんかででてくるLOHAS化というよりは、そこでいわれる、

　持続可能

　って、いうことから来ているみたい。
　「持続可能」＝＞継続性に基づく、ゆとりあるオルタナティヴ（代替計画）を模索する
　(上記斜体は、上記記事より引用）
　ってことのように見える・・・

　・・が、持続可能なシステムって、なんだ？

---

　っていうことになると、修正可能なシステムって言うことになると思う。
　システムを維持していくには、世の中が変わっているから、その変化に対応する修正が必要になってくる。
　だから、修正可能なシステムをつくらないと、持続しない。

　そもそも、そのシステムは修正していくものという視点がEAに抜けているから（ToBeがちょくちょく変わるという視点がない）EAを実現しても修正可能なシステムになるとは限らない。

　というか、ToBeが、どんどん変わってしまったら、なにを作ったらいいかわかんないので、開発できない。そもそも、最適解が存在しないので、ToBeが存在しなくなってしまう。ということで、そのToBeを基にするEAという考えは、修正可能なシステムには合わない＝＞世の中の変化が激しい現在にはあわない。

---

　でも、修正する、仕様変更がばんばん起こるから、システムが崩壊するんだよね。

　そもそも、修正してもシステムが崩壊しない論理とか、そーいうことを世の中で、やっている人たちがあるのか？って問題になる。

　もし、これが「ない」とすると、システム修正が中心のコンピューター業界というのは、絶望的な業界になってしまう（システムは崩壊するもので、崩壊にむかって進んでいることになる。さらに、アジャイルのように、どんどん修正してしまうと、急ピッチでシステム崩壊に向かわせることになるので）・・・

---

　残念ながらというか、幸運にもというか、世の中、「もともとあるシステムを修正して、あらたなシステムと融合する」ということをしている人たちは存在する。

　法システムにおいて、既存の法システムに対して、あらたな項目、規則を修正して融合させるという、溶かし込みという作業がある。まあ、法律が崩壊していないので、修正によって一概に崩壊するとは言えないと、経験的に考えてもいいかもしれない。

・・・が、それだけの根拠ではおぼつかない。

修正可能なシステムというのは、作れるのだろうか？その論理的な根拠は？

---

　エンティティを修正しても、それを利用するプログラムには、影響を与えないので、修正が可能になるというのは、独立性といわれる、データベースの基本概念だったりするわけです。

　で、この独立性を実現するためには、
・概念的に分析して（概念スキーマ）保存したもの（物理スキーマ）と、
　プログラムで利用するもの（外部スキーマ、View)を分ける

・１事実は１箇所にしかかかれない。

　そして、この１事実１箇所にするのが正規化理論で、１箇所にしかかかれないのに、いろんなプログラムで利用可能で、自分に関係ないがあっても、影響を受けなくさせるのが、Viewという概念のはずです。

　ということは、このような手法が、オブジェクト指向でもすでに実現しているか、今後利用可能になれば、修正可能なシステムが理論上作れそうです。

---

　ということで、いいかげんながくなったので、ここできります。
　オブジェクト指向による、修正可能システムの話はまた今度

　

グーグルケータイOS、androidのお勉強（９）－メソッドその３

　シリーズ「グーグルケータイOS、androidのお勉強」。
　今、画面をやっています。
　画面では、レイアウトのXMLと、Javaのクラスが必要でした。

　Javaのクラスでは、
　　onCreate()　　　　　　　：アプリ生成時
　　onCreateOptionsMenu()　　：メニューオプション作成
　　onOptionsItemSelected()　：メニュー項目が選択された

　を書き換えないといけなく、前回はonCreateOptionsMenuやったので、今回はonOptionsItemSelectedです。

---

■onOptionsItemSelectedでやるべきこと

　メニューで選択されたとき、ここにきます。
　選択されたItemが引数としてやってくるので、選択箇所をgetId()メソッドなどを使って取得し、（IDの番号は、メニューをaddするときにセットしている）、それに伴うテキトーな(適切な）処理を行います。

　そして、親のonOptionsItemSelectedを呼び出します。

---

■で、実際

ということで、実際のソースコードを見てみると、サンプルと、チュートリアルのドキュメントで書いていることが違います。

まずは、サンプル。こんなかんじ

    public boolean onOptionsItemSelected(Item item) {
    	switch (item.getId()) {
    	case INSERT_ID:
    		createNote();
    		fillData();
    		break;
    	}
    	
        return super.onOptionsItemSelected(item);
    }

一方、チュートリアルは、こんなかんじ

public boolean onOptionsItemSelected(Item item) {
        switch (item.getId()) {
        case INSERT_ID:
            createNote();
            return true;
        }
       
        return super.onOptionsItemSelected(item);
    }

違いは、
１．createNote()のあと、fillDataを呼ぶか呼ばないか
２．そのあとsuper.onOptionsItemSelectedを呼ぶか呼ばないか、
３．返り値は、必ずsuper.onOptionsItemSelectedか？

１に関しては、createNote()の中で、fillDataを呼んでいるので、
　createNoteのあとにfillDataを呼ばなくてOK
　→チュートリアルの勝ち

２に関しては、チュートリアルでは、createNoteを実行した場合、
呼ばれないけど、うーん・・・たぶん、チュートリアルのほうが
正解そう・・・

３に関しては、サンプルの場合、super.onOptionsItemSelectedが、
falseを返してしまったら、ここで処理しているのにfalseが
帰ってしまうから、よくないだろう・・
　→チュートリアルのほうが、正解っぽい？？

---

■createNote

　で、結局、createNoteというのが呼ばれるのですが、
それは、チュートリアルでは、こんなかんじ

private void createNote() {
        String noteName = "Note " + mNoteNumber++;
        mDbHelper.createNote(noteName, "");
        fillData();
    }

データを追加すると。。

で、そこにある、fillDataは、すでに７話で紹介しています。

---

ということで、ひとまず、お話が終わりました。
これ以降、チュートリアルは続いているのですが、
ここで、一区切りついたので、このシリーズは、
ここまでっていうことにします。

オブジェクト指向は、ある技術を知らないと、デスマーチになるように出来ている？論理的に考えると？？

　オブジェクト指向の言語が、他の言語とわかれる決定的な違いは、カプセル化によるデータの隠蔽と、継承にあル戸思います。

　では、そもそも、オブジェクトは、なぜカプセル化できるのか？と考えると、そりゃーあなた、オブジェクトというのは、１つしか存在しない(一意に存在する）、その属性は、そのオブジェクトに閉じている（局所的に存在する）から・・

　・・・と、仮に答えてしまうと（多分、これが正解でしょう）、ここで問題が起こります。

　もし、クラス内に、まったく関係のない、他のクラスに依存する属性を持たせて、それをインスタンスにしてしまったら、どうなるでしょう・・・オブジェクトは、実在の世界からかけ離れたものができてしまいます。

---

　たとえば、極端な話ですが、顧客クラスに、特売購入フラグというのを作りましょう。
　これは、特売を買う人を、いち早く調べたいからという理由で導入したとします。

　本来なら、これは受注した(受注明細の）商品に付けるべき属性ですので、受注明細につくようなものです。
　（商品という普遍的なものでなく、受注した商品という受注明細の商品関連の属性となる）

　そして、受注明細で、特売レコードをあつめ、そこの明細に対応する受注をした顧客をあつめて、
　顧客データを取り出すべきものです。

　でも、めんどっちいから、顧客クラスに、特売購入フラグというのをいれましょう。

　DBにも、いれちゃいましょう。。。

　とします。

---

　一見、この修正は手っ取り早くて、うまくいきます。

　でも、もし、特売の受注がキャンセルになったら、

　　　特売購入フラグをOFFにしないといけません。

　　　さらに、キャンセルされていても、
　　　　他に特売を買っていたらONにしないといけません。
　
　　　そしてさらに、この場合、特売購入フラグがPublicになっていればいいけど、
　　　privateになっていたら、受注時キャンセルのときに、
　　　　　特売購入フラグが操作できないかもしれません。

　じゃあ、全部publicにすれば・・・っていったら、カプセル化になりません。

---

　つまり、オブジェクト指向で書くのであれば、カプセル化にして、情報を隠蔽するさい、隠蔽しても問題ないように、適切なクラスに属性をいれないといけません。

　そして、その「適切なクラス」とは、

そのクラスを実際の実存する（あるいは想像物の）
　オブジェクト（これをモデル化してクラスを作ったはず）に
　インスタンス化した際、

そのオブジェクトが、対象となる属性を持っていること
　（あるいは持っても差し障りない、持つべきもの）

ということになります。

　そうしないと、へんなクラスに属性を入れてしまうと、隠蔽化されているので、データ操作ができなかったり、値をセットし忘れたりしてしまいます。

---

　ということは、

（１）ビジネスの実態にあった、クラスを切り出す方法と
（２）そのクラスに対して、適切な属性をふる
　　　→局所化して、隠蔽できるように、属性をふりわける

という技術がないといけません。もし、この技術がなく、てきとうにセンスでえいや！とクラスに属性追加してしまうと、そのときはよくても、データが隠蔽されているので、あとで値を直せなかったり（直すために大幅修正になったり）、気づかなかったり（気づきにくくなっているので）する可能性が大きくなります。

　・・そーすると、デスマーチですよね。

blancoみたいな、Excelの設計書からの自動生成は、一度XMLに落としてくれたほうがいいよね！

　まえに、ここで、
　見える化したツールから、形式化（プログラミング言語）なんかを
　自動生成させるには、

　　　　見える化→XML→形式化の自動生成

と、一回XMLを仲介したほうがいいとかきました。
（そのほうが、いろんな形式で自動生成したい場合、よい）

---

　Excelの設計書もふくめて、設計書っていうのは、プログラミング内容の見える化、ないしは、プログラムにいたるまでの思考過程の見える化だと思うわけであります。

　ってことは、Excelなどの設計書から、プログラムなどを自動生成する場合も、いったんXMLを経由したほうがいいような気がするんですよ。

---

　たとえば、blancoなどの場合、Excelの設計書から、いろんなプログラミング言語を生成してくれるけど、あたらしい言語が出てきた場合や言語仕様が変わった場合、それに対応するには、VBAからいじらないといけなくなってしまうと思うんですよ。いまのような、Excelからソース自動生成だと。。。

　それよりも、Excelの仕様書から、XMLに落としてくれれば、
XMLから、ある言語を自動生成するプログラムは、VBAで書く必要はなく、（XMLが扱えれば）好きな言語でかけるので、
　自動生成プログラムを作れる人は増えるし、
　自動生成の稼動環境も増えると思う
（VBAに限定してしまうと、Windows環境になってしまうが、Excel仕様書からXMLに落として、そのXMLから自動生成するなら、自動生成部分は、LinuxでもOKになる。また、仕様書もExcelで書かなくても、OpenOfficeでも、おなじXMLで書き出せればOKとなる）。

---

　ってことで、自動生成は、いったん設計書（＝ある意味、見える化ツール）からXMLに落とし、そのXMLを各種プログラミング言語の自動生成（形式化の自動生成）に変換したほうが、いいような気がします。

クラスとエンティティが関連する論理的根拠。。

　Javaなどのプログラムのクラスと、RDBのテーブル、ER図のエンティティは、１対１対応とまではいかないものの（もし、１対１対応なら、O/Rマッピングツールなどはいらないはずだ）、もし、やろうとすれば１対１対応できるし、そうでないにしても、おおまかな関連は、たいていある（いくつかのテーブルをまとめて１クラスのような）。

　この根拠は、どこにあるのか・・という話。

　クラスをインスタンス化したのがオブジェクトであり、オブジェクトはモノとして存在している＝１つ１つが識別できる。
　一方、テーブル（エンティティとほぼおなじようなもん）をインスタンス化したものがレコードであり、これは、主キーにより、１つ１つが識別される＝一意に決まる。

　ってことは、レコードもオブジェクトも、
　　　　　エンティティをインスタンス化したものと考えられるわけで、
　ってことは、そのもととなるエンティティに対応する
　　　　　クラスとテーブルに、だいたい関係があってもおかしくない。

---

　ということになるけど、ってことは、テーブルに対応するのは、J2EEなんかだと、（エンティティが対応するクラスである）エンティティBeanっていうことになりそうなわけで、これに対して、セッションBeanは、ある業務プロセスにおいて、各種のエンティティを呼び出し、それらのトランザクションを管理するってことで、エンティティBeanとちがい、業務プロセスに対応するほうが近い。

　そして、もっと簡単に使うRESTの場合や、サーブレットの場合は、業務プロセス（＝ユースケース）に対応する部分が、コントローラーになったりするわけで（業務プロセス実行時→画面でボタンをおしたり、イベントを発生させるのが普通→サーバーを呼び出すのが普通→サーブレットを呼び出す：はじめと最後を切り出すと、業務プロセスは、サーブレットに対応しがちになり、そのサーブレットは、モデルを呼び出すコントローラーになる）。。。

　このコントローラーであるサーブレットに、セッションBeanの役割を持たす（トランザクション管理をさせる）か、
　エンティティBeanに相当するモデルのクラスの中にあるメソッド（＝これが、業務プロセスに対応）にトランザクション管理をさせるかは・・

・・・自由だー

ということになるんだろう。