オブジェクト指向と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図を作成したときの正規化理論が使えるというか、正規化してできたエンティティにクラスを関連づけないと、おかしな話になってきそうです。

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