”ブログ界は「不快」で「危険」なコンテンツだらけ”なんだってさ（＾＾；）

ここのスラッシュドットニュース
ブログ界は「不快」で「危険」なコンテンツだらけ
http://slashdot.jp/security/07/04/25/0954234.shtml
によると（以下斜体は上記サイトより引用）


Ars Technicaの記事より。ウェブセキュリティ企業のScanSafeが最近発表したリポートによると、企業顧客からの70億以上ものウェブリクエストを分析した結果、80パーセント近くのブログには「不快な」コンテンツが含まれていることが分かった。ここで言う不快(offensive)とは、下品な言葉遣いからわいせつ画像まで千差万別のようだ。また、同リポートによると、ブログの約6%は何らかの種類のマルウェアで汚染されていて危険だと言う。


だそうな・・・

ほー、

ブログが危険っていうのは、あるのかも。。？？

でも不快のほうは、不快の定義によっては、
どーなんでしょー

もし、ブログで著作権違反をしているものも、企業から見たら不快っていうことで、定義したら。。もっと不快が上がる？？

横断的関心事の切り出しと自動生成

なんとなーくシリーズ化してしまった、要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているの話。
　で、書く、書くと書きながら、書いていなかった、


アスペクト指向における横断的関心事の切り出しの問題


について。。

　世間話の与太話なので、まじめに反論とかしないでね（＾＾；）
　ギャグの一種として聞いてください
（ただ、途中から出てくる自動生成の話は、そこまで進んでいて実際に使っているけど、今回は書かないです）

---

■featureと関心事と、階層について

　ここで書いたように、

業務
　｜
アクティビティ層（＝アクティビティ等）
　｜　ライブラリと入出力
基本操作群
　｜
ＯＳ／言語提供モジュール

って考えられます。
で、業務から、アクティビティに落とすのが、要求分析になります。

横断的関心事: Crosscutting Concern
http://netail.net/aosdwiki/index.php?%B2%A3%C3%C7%C5%AA%B4%D8%BF%B4%BB%F6

で書いてある話でいうと、featureは、要求仕様層でいう、アクティビティになると思います。

　したがって、関心事というと、入出力それぞれも、関心事になるし、ライブラリ化する機能も関心事になったりすると言うことになると思います。
　つまり、「ライブラリと入出力」、「基本操作群」のそれぞれが、関心事たりえるということになり、上の図にあるように、それらは階層化されています。

---

■横断的関心事とライブラリと雛形について

　横断的関心事とは（以下斜体は上記横断的関心事より引用


相互に関連しあっていて，何か機能変更などがあった場合に同時に変更されるものは，できるだけ１つのモジュールにまとめておきたい」という要求がありますが，何らかの理由でモジュールとしてまとめられない関心事のことを横断的関心事と呼んでいます．従来，ソフトウェアの機能に基づいてモジュール分割を行うことが多いため，性能向上のためのコードや，ログ取得などの付加的な処理は横断的関心事になりやすいといわれています（ソフトウェアファクトリーでは，機能特性に対して運用特性という表現も使われています）．


とあります。
たしかに、コーディング最中に、そーいう部分はちょくちょくある。
あるんですけど。。。

横断的関心事の話って、たいていその後、アスペクト指向と結びつき。。
で、たいてい、こんな例（ログの例が、なぜか多い）がでてる。。


ここでは、あなたが大規模なソフトウェア・システムを保守する立場にあると仮定しよう。このシステムは、所属する組織の給与計算と人事の機能を管理する。ここで、従業員データに対する変更をすべてログに記録するように経営者側から要求されたとしたらどうするか。これには、減給、昇給、残業手当など、給与計算に関する変更が含まれる。また、従業員の肩書きや個人データなど、従業員のあらゆる情報に関するあらゆる変更が含まれる。この要求を満たすには、どうしたらよいだろうか。


でも、こうかかれると。。。

いやー、入出力のところは、すべて、自動生成してるから、従業員データアクセスの雛形を書き換えて、もう一度従業員データを自動生成すると。。全部ロギングできる。。。けどお（＾＾；）

終了。。。

って、思ってしまいませんか。。？

---

■いやー、あとから結合点を抜き出すのって、たいへんじゃない？

　つまり、横断的関心事になるようなところは、たいてい雛形がつくれて、雛形があるところは、自動生成している（現実的に、コーディングするような人月数は、もらえないので）から。。。自動生成の雛形を修正するだけでOK、

　一方、当初からまったく予定しないような横断的関心事は、自分１人でコーディングするなら差は出ないけど、そうでない場合、人によってかき方が違うので、結合点が必ずしも見つかるとは限らない。。気がするんですけど。。

---

■具体例で。。

　具体的に、さっきの例だと（以下斜体は上記のこんな例より引用）

　AspectJでは、結合点をポイントカット（pointcut）としてグループ化することによって、結合点を定義する（AspectJの構文は豊富であり、ここではそのすべてについては説明しない）。まず初めに、2つのポイントカットを定義する。1つはEmployeeクラス内の結合点をグループ化するためのものであり、もう1つはIEmployeeFinanceコンポーネント内の結合点をグループ化するためのものである。これらを定義するコードは次のようになる。

pointcut employeeUpdates(Employee e):
call(public void Employee.update*Info()) && target(e);

pointcut employeeFinanceUpdates(Employee e) :
call(public void update*Info(Employee)) && args(e);

　employeeUpdatesという名前の最初のポイントカットは、updateという文字列で始まり、Infoという文字列で終わる、引数を持たないEmployeeオブジェクトのメソッドを呼び出しているすべての結合点を表している。また、このポイントカットは、target指定子によって、Employeeクラスで定義されたメソッドを明確に指定している。2番目のポイントカットである


ってあるけど、自由に書かせると、「updateという文字列で始まり、Infoという文字列で終わる」ように、更新をみんな書いてくれるかというと。。びみょーだし（こー言う決まりを守らない変なやついるんだよ、俺か　＾＾；）

　逆に、コーディング規約で、「こう書きましょう！：っていう風に決まっているなら、雛形を書いて、自動生成をかけてしまう（この辺の話については、別の機会で、自動生成についてまとめて書くので、そこで触れます）。

　なので、雛形プログラムを書き換え、たとえば、従業員アクセスだけは、書き換えた雛形を使い、それ以外は元の雛形をつかうとすると。。。

　簡単にできてしまう。。

---

■雛形とライブラリ。。。

　雛形で、入出力自動生成の場合、

　　パフォーマンスが出ないときにSQL全部を書き換えたり、
　　SQLインジェクション対策みたいなのをする
　　エラーログを全部にいったん入れてみたい

　なんていう対応が、まさに横断的関心事っぽくって、こーいうのの場合、べつにアスペクト指向のツールを使わなくても、いつもの自動生成の雛形を書き換えるだけでできてしまう。

　ライブラリや基本操作を使ってる場合も、ライブラリや基本操作の関数、メソッドを書き換えれば、横断的関心事っぽいことに対応できるけど、もともと、そーいうライブラリの話を除いたものが、横断的関心事？？

　逆に、自動生成でなくて、横断的関心事のところを切り出そうとしても、けっこうみんな、いいかげんにかいちゃうからなあ。。切り出せるかなあ？？（だいたいは間違いなく切り出せる。すべてを切り出せるか？たとえば、上記の例だと、本当に、「updateという文字列で始まり、Infoという文字列で終わる」以外の関数が、従業員データをアクセスしていないか？

---

　なーんておもったりもします。。

　与太話です。まじめに反論とかしないでね（＾＾；）
　（って、コメントもトラックバックも受け付けてないのでできないけど　＾＾；）

　次回のこのシリーズは、デザインパターンの話。