アスペクト指向の愉快な利用方法とか

アスペクト指向のこの前のつづき

---

■ポイントカットの応用（この前の続き）
・within　～　call－－
　～から呼び出される－－

・フィールドにアクセスされたときに、ポイントカット
　　get
　　set

■アスペクト指向の愉快な利用方法：

・モックとして使う
　aroundアドバイスは、そのまま帰ってくるので、ダミーモジュールに使うところを、
　aroundアドバイスに変えてしまえば、本体に対して修正などしないで、
　aroundアドバイスを作るだけで、テストができる。

・静的な解析declare errorで、ポイントカットを使って、コンパイルエラーを出す

■さらにすごいこと：存在しないメソッドを後から追加できる
　　インタータイプ宣言：修正せずにメソッド、コンストラクタ、フィールドを追加できる
　　declare句による宣言：修正せずに継承関係を変更できる
　　　　→ただし、変更した結果、実装すべきメソッドがない等の矛盾が生じてはいけない
　　　　→実行順番を指定したい場合は、優先順位の指定をする
　　　　　　→declear precedence
　　特権アスペクト：privileged：privateでも勝手に見えてしまう。

■アノテーションとしても書ける
　また、アノテーションをポイントカットにできる。


■アスペクトの問題点
・テストはどうなるの？
・アスペクト指向の設計方法は？
　　　→表記、手順は？

■他の言語のアスペクト指向
・aspectC http://research.msrg.utoronto.ca/ACC
・aspectC++ http://www.aspectc.org/

SEMATについての感想

　昨日、SEA　Forumに行ってきて、SEMATについて平鍋氏のお話を聞いてきたことは、
　昨日のブログに書いた。
　今日は、その感想。

　正直なところ、SEMATは、何をどこまで作って、どれが、日本の私たちに、どれくらい影響があるのか、よくわからなかった。実は、ここが一番知りたいところなのだが・・・

　つまり、SEAMATは、(以下斜体は、昨日も引用した、平鍋さんのブログ「SEMAT.org にて「ソフトウェア工学再建」運動が開始」から引用）


確かな理論と、証明された原則(principles)とベストプラクティス(best practices)の上にソフトウェア工学を再構築(refound)したい、そのプロセスを支援したい。


っていうと、根本原理からどんどん発展させて、現在のソフトウエア工学を、体系化して見せてくれるような気がしてしまう。

　根本原理から、現在のソフトウエア工学を体系化すると、
・チャーチ＝チューリングのテーゼから、まず、原始帰納的関数を出してきて、
・それから、スパゲティプログラム（N）は、Whileプログラムに書き換えられるよ！
・プロセスやデータを複合していき、オブジェクトという概念を出してきて、
・ソフトウエアの正しさを説明して（部分完全性と停止性）：ここじゃないかも？
・それから、コンポーネントを説明して、パターンに行き
・フレームワークにきて
・開発方法論になって
・マネージメントになる？？
てなかんじなのかしら・・・

だけど、なんかそういうことをするんじゃなくって、議論の土台となる、「共通のものさし」を作るみたいだ。そういう風に聞こえた。

　体系化なら、実務上、それを仕事に当てはめていけるから便利なんだけど、ものさしを作られても、直接日本には、インパクトないかも？たとえば、日本においては、ISO27001より、ISMSのほうが、なじみ深いように、世界的にものさしを作っても、まずJIS化しないと・・・

---

　ただ、その後の議論では・・・
　うーん、日本の学会や、偉い人たちの間では、ちょっと、いや、とっても、体系化は難しいかな？という気がした。

　たとえば、「どうして、OCLなんだ！VDMのほうがずっといい」みたいな意見が出たけど、
　そもそも、OCLとVDMは、形式仕様だけど、適用範囲がちがう。

　OCLを使うときは、クラスを再利用したり、関連をチェックしたいような場合に、
　定義するもので、だから、不変条件と、陰仕様しかかけない。
　　メソッドの内部の記述は出来ない。
　　だから、OCLの場合は、テストデータのイメージとして、これで合っているかどうか
　とかの確認が主になる。

　一方VDMは、自分の考えたやり方で合っているかどうかを確かめたいときに使う。
　陽仕様で書けるので、自分の処理方法をそのまま書ける。
　一方VDM++であっても、インターフェースとか、（あれ、パッケージもなかった？）
　クラス関係の表現力は弱い。弱くっても、単に考えを確認する程度なので、ま、これでいい

　実際、VDMで検証するより、直接、Javaで書いてしまったほうがいい
　という考えもある。これが、アジャイルになる。
　VDMで検証しても、Javaに直すときにバグが入る可能性があるから、
　それなら、直接コードを書き
　　　事前条件は、エラーチェックで
　　　自分の考えはメソッド内に
　　　事後条件は、JUnitのアサーションで
　　　不変条件は、JUnitで処理前と処理後にアサーションで
　確認するというものだ（さらに、JMLで形式仕様を書いてもいいけど）

　ただ、上記のアジャイルは、開発言語が決まっている場合に有効ではあるが、言語が複数あったり、決まっていない場合は、Javaでやっていいの？ということになるから、すぐに確かめられるVDMがいいかもしれない。


　現場的には、このように、形式仕様を持ち出すとしても

　　OCL　VDM　アジャイル＋JML

　と、ちょっと考えただけでもあるし、さらに、話題になっていた、自動車などで、厳密に定義をするんなら、上記のものではだめで、（停止性を保障したいときがある。この場合、バリアント条件がかけないといけない）、EventBやBを使うことになる。

　問題は、現場的には、
　　　・このうち、どれを使えばいいの？
　　　・どーやって適用するの？

というのが、体系的に判りたいわけで、望んでいるのは、まさにこれなわけだ。
だけど、そーいう、どの場合にどう、という話にならずに、どっちがいい論争になり、まさに、ファッション化してましたねえ・・・

---

　あ、そーいう意味では、ステートチャート（ステートマシン）図の話も、気がめいるものだった。。。

　イベントドリブンの場合ステートチャート図を描くのが当たり前であり、フィリピンの人はすぐに思いつくのに、日本のエンジニアは、まったく通じず、総当たりテストしているという発言だ。

　それに対し、平鍋さんが、「いや、必ずしもそうじゃないし、状態爆発しちゃうことがあるでしょ」と正しいツッコミをいれても、まだ無視して、その話を・・・

　うーん・・・これが、日本の上層部の実態なのねえ・・

　まず、イベントドリブンの場合、ステートチャートを書くのは一般的かもしれないが、ステートチャートは、

　　・並行動作が見えにくい→ここで、場合が抜ける可能性がある
　　・ステートチャート図を描いたとしても、網羅性は保障されない

　そこで、前者において、とくに、メッセージが介在しているときなどは、シーケンス図で全体を捕らえる。で、イベントドリブンでも、シーケンス図で理解できてしまう場合もある。このようなときは、わざわざ、ステートチャート図をおこさない。
　→シーケンス図からステートチャート(ステートマシン）図を読み替えられるので

　また、後者で記述したように、ステートマシン図を書いたとしても、線１本抜けてても、ちょっと気づきにくいときがある。なので、ステートチャートで書いても、網羅してるかどうかまではわからない。これが、状態遷移「表」なら、まだマトリックスにするのでありなんだけど、状態爆発の可能性がある。っていうか、ステートをまともにあつかったら、爆発する。
　そこで、SPINやSMVといった、モデル検査にもっていくことになる。

　ただ、あんまりにも大きいものは、細かな部分を隠してしまって、フレームワーク化してしまう。
　フレームワーク化されると、１イベント分しかかかないので、次のイベント処理しかかけない。
　そうなると、ステートチャートを描いても（１イベント分なので）意味がなくなってしまう。
　フレームワークにおいて、イベントが隠れているかどうかを見るには、CSP（プロセス代数）とか使って、詳細化関係を確認すればいいけど、その場合、ステートチャート図より、構造図のほうが、CSP化しやすい。

　ってことで、日本の場合、

・フレームワークのアーキをしている人は少なく、フレームワークから呼び出される
　一部イベント部分を書いている人は、１イベントのステートマシン図を書いても意味
　ないから、書かない→ステートマシンを書かなくても、仕事になる

・どっちかというと、シーケンス図を描いたら、もう、大づかみにコーディングに
　入ってしまう。

ので、必ずしも、ステートマシン図が必要なのではなく、どのような開発の場合は必須で、どのようなときは、イベントドリブンでも、ステートマシン図を必ずしも必要としていないかの体系わけができないといけない。
　で、現場的には、その体系図のほうが、ほしい。

　なんだけど、永遠と、日本だめだめ説なのだ（フィリピンの人は、たぶん、開発経験が少ないので、教条的に、イベントドリブンと来たら、ステートマシンと答えたのだろう）。

　そもそも、総当りで全てテストしている会社としか、お付き合いがないようだと、あんまりいい会社とは付き合ってないんじゃないかなあ？今、直行表くらい、知ってるだろ・・・仕分けされそうな情報処理試験でも出てくるくらいだから・・・

---

　ってことで、仮に体系化されても、日本の上層に受け入れられにくいかもねえ・・

　むしろ、日本でだれかが体系化して、たとえば、astah*で作ったUMLから、その場に合ったシュミレーションや、検証ができるようになったほうが、インパクトでかい気がする。

　ま、そのうち、この体系は書くだろうから、意外と、SEMATより、このブログのほうが影響力強くなるかも？？（なわきゃーないか・・・）

事業仕分けで情報処理技術者試験はどうなる？

ここのスラッシュドットの記事
事業仕分けで情報処理技術者試験はどうなる？
http://slashdot.jp/it/10/11/29/086243.shtml

民営化が有力なようですが、民営化したら、たぶん、受けないな・・・
民間資格だったら、CCNAとかオラクルマスターのほうが、いいわけでしょ。

価格をあげたら、お金持ちしか受験できなくなる。
たとえば、民間資格のように、１回の試験に３万円したら、
会社受験でない場合以外、受けなくなる・・・

そーすると、技術者を図る標準がなくなる。

受益者は業界というより、転職する場合の転職者だから、雇用にも差し支えてくるわけで
（ほかの民間資格は、とても高い上、維持費もかかるので、貧乏人は受けられない）

それに、実務経験がなくても試験慣れしているから受かるのが、問題なら、

　　無線技士・通信士関連の国家試験なんか、めちゃくちゃ問題になるよな
　　（過去問が、結構そのまま出るため、過去問対策すると、受かる）
　　司法試験とかも、問題じゃないですかね・・・（受験生は、実務してないはず）

このまま行くと、国立大学の入試とかも、「手書きは古い」ってことで、センター試験で統一
（大学院の博士課程入試も、コンピューター試験　＾＾；）
センター試験も、民営化できるので、河合塾とか代ゼミが実施するんでしょうかね・・・


・・・ところで、事業仕分けって、めちゃくちゃ無駄だと思うんだけど、
　事業仕分けは、仕分けしないの？

　あ、選挙のときに、仕分け人をことごとく、落とせばいい、それで、仕分けしてるってこと？