初めてのＲｕｂｙを読む その４８ ９．６

「初めてのRuby」を読むの続き

今日は

９章　本書を越えて


９．６　Ｒｕｂｙの黒魔術

から

---

■９．６　Ｒｕｂｙの黒魔術
・Ｒｕｂｙには、俗に「黒魔術」と呼ばれる危険な領域が存在する
　→良く理解して使わないと、可読性を下げたり、セキュリティホールになる
　→それだけの代償を払っても魅力的な機能

---

■９．６．１　eval族
・eval族：組み込み関数eval
　　　　　Object＃instace_eval
　　　　　Module#module_eval
　　　　　Class#class_eval

・文字列評価
　eval族を使えば、実行時に文字列をRubyコードとして解析・実行できる
　→外部からコードを入力して実行することすらできる

・コンテキストのすり替え
　eval族を用いれば、コードの評価コンテキストをするかえることもできる
　　→本来ならインスタンスの中でしかアクセスできないはずのインスタンス
　　　変数も、外部からアクセスできる


・言語内ＤＳＬ
　コンテキストのすり替えは、言語内ＤＳＬを構築するには欠かせない存在

---

■９．６．２　method_missing

・呼び出されたレシーバーが存在しないとき
　　→Object＃method_missingが呼ばれる
　　　　→NoMethodError例外が発生する

・method_missingをオーバーライドすると、実際には、存在しないメソッドを
　存在するかの容易振舞わせることができる

---

■９．６．３ set_trace_func

・set_trace_func
　　→ruby処理系にフックを仕掛けられる
・メソッドが呼ばれたり、戻ったり、クラスが定義されたり、インスタンス化
　　→そのたびいコールバックルーチンが呼ばれる

---

■９．６．４　継続
・継続とは、プログラム実行中のある時点において、以降で使われるであろう
　計算、処理のこと

・Continuationオブジェクトとして操作できる

---

障害の原因となる銀の弾丸はないってこと？

　ソフトウエア・メトリクスの分野（特にエンピリカル・ソフトウエア工学）の分野では、
障害の原因となる要因を、過去のプロジェクトから探し出し、それを元に、新規プロジェクト
に適用して、障害予測や各種見積もり予測に役立てようとしている。

　そのために、

PROMISE Software Engineering Repository
http://promise.site.uottawa.ca/SERepository/datasets-page.html

なんかで、プロジェクトデータが公開されているということは、前に書いた。

今日は、そこで興味深いことを見つけたので、書いてみる。

---

そこにある２つの（はじめにある、ＮＡＳＡのプロジェクト）ＣＭ１とＪＭ１について

普通だと、障害原因を探るのに、ステップワイズ法（変数増減法）を使うと思うけど、
ここでは、決定木を使って、確かめられないか、考えてみよう。

ＣＭ１をＷｅｋａの決定木Ｊ４８（Ｃ４．５と同じようなもの）で分析すると

となる。つまり、障害は、lOComment（Halstead's count of lines of comments）と
ev(g)（McCabe "essential complexity"）で説明付いてしまう。

　ほ～、正答率８８％だそうな。。。

---

とおもって、じゃあ、ＪＭ１でやると・・・

なんじゃこりゃ（－＿－；）ちなみに正答率７９．５％
なので、主要３要因、Loc、IOBlank、Total_Opでやると、こうなる

loc（McCabe's line count of code）、total_Op（total operators）
で説明付くらしい・・・
正答率８１．１％なので、ぐちゃぐちゃなのより、よくなった。

---

あれ・・・指標、変わってない？

じゃあ、ＣＭ１のデータを、ＪＭ１の指標Loc,IOBlank,Total_Opとdefeateの値
だけを残して、決定木で分析したら？

なにもでてこないし、
逆にＪＭ１のデータを、ＣＭ１の指標IOComment,ev(g)とdefeateだけを使って
決定木を分析すると、

出てくるけど、正答率は下がる。

---

つまり、決定木を使うと、

ＣＭ１の指標は、lOComment、ev(g)
ＪＭ１の指標は、Loc,Total_Op

が向いていて、他の変数ではあまりせつめいできなさそう。

・・・ということは、プロジェクトによって、障害が起こる要因はちがうってこと・・

障害の原因となる銀の弾丸はないってこと？


だとしたら、ステップワイズ法で変数を決定し、それを「ほかの」プロジェクトに適用することは無理ということになり、もしそのようなことがやりたいのなら、

（１）先に、いろいろなプロジェクトにおいて、
　　何が障害を予見する要因かを探し出し、
　　→Ｊ４８でもいいけど、他にもっと適切な方法があると思う


（２）適用しようとするプロジェクトが（１）のどのプロジェクトと
　　類似しているかを、Ｋ－ＮＮ法などで確認し、

（３）その似ているプロジェクトの障害説明要因を使って、
　　適用したいプロジェクトの予測を行う

っていうように、やり方をがらりと変えないといけなくなると思うんですけど・・・


・・・データマイニングとか、この分野は専門外だから、よくわかんないんですけど、
どう思います？


Ｐ．Ｓ　実はこれ、大学院のレポート＆発表で出したもの。

　そのときのコメントが、「でも、この要因でも、説明しているとはいえないよね。当てはまりはよくない。意外と、プログラマの技術力とかが測れたとして、その指標を入れたら、ガラリと変わるといったようなこともありえるかもね？」という意見がありました。