netail.net

_ TRPG つづき ▲

プレイ前の説明に手間取って，予想よりもプレイに割ける時間がなくなった．３時間程度と予想してたところを２時間で終わらせようとしたから，ちょっと不自然な（一部のプレイヤーが活躍できない）まま終了．時間オーバーよりはマシだけど，まだまだ未熟かな．

_ TRPG ▲

神戸方面の後輩の家に出張してトーキョーN◎VAのルーラーをやることになってたので，早起き．片道１時間程度らしいので，京都での国際会議に行ったときよりは楽だろう．

シナリオの大枠はできているが，細かいところは移動中に詰めることにする．昨日まで研究室での中間報告の資料とか，N◎VA用のルールレジュメみたいなものを作ってたせいでちょっと寝不足気味かもしれない．

中間報告の資料を手直しする時間が，帰ってきてから取れるかな？

_ CATV ▲

排熱が微妙に悪いことが分かったので，ケーブルモデムを風通しの良い位置に再配置．

液晶ディスプレイの箱をたたんだりしたので，だいぶ空間を確保できた．

_ 読書 ▲

エリヤフ・ゴールドラット，「チェンジ・ザ・ルール」を読了．システム・インテグレータがテクノロジーを売るのかバリューを売るのか，とかいう話．TOCとかも絡んで，システムを導入してもシステム導入前のルールが，システムの活用を阻害するとかいう厳しいお話．

_ OACISシンポジウム ▲

今回は情報セキュリティについてのシンポジウム．奈良先の山口先生の講演を初めて聞いたけど，PowerPointも使えない（PCがこけた）状況下でもよどみなく喋っていて，内容的にも政府レベルの取り組みまで含めた話で，とても面白かった．

そのほか，カーネギーメロン大学日本校で情報セキュリティのコースが神戸ハーバーランドセンタービルにできる（できた？）という話とか，なんか色々と組織的活動をしているらしい．

_ CfP: Asian Workshop on AOSD ▲

AO-Asia の人々中心での First Asian Workshop on Aspect-Oriented Software Development の Call for Paper が aosd-announce に流れていた．

PC としては Oege de Moor とか Tzilla Elrad とか Gail Murphy とか，別に関係なくメンバーが集まっている様子．

_ [読書] Heuristics 本ようやく読了 ▲

Arthur J. Riel: Object-Oriented Design Heuristics. Addison Wesley, April 1996.

９章までがヒューリスティクスの紹介だったのに対して，10章はデザインパターンとヒューリスティクスの違いについて検討されている．この本の発表の時期的には，パターンランゲージは既に知られているけど GoF のデザインパターンカタログなんかはまだ，というぐらい？

ヒューリスティクスとデザインパターンの関連性は明らかにあり，筆者の「ヒューリスティクス」というのは「悪い設計パターン」から「良い設計パターン」へ至る変換のパターンであるといえる．

デザインパターンは，それをいつ適用すべきかというのが分かりづらいことがある．それに対して，ヒューリスティクスは「悪い設計パターン」というのがどういうものかを短く表現していて，しかもCASEツールによって自動的に検出できるものが多い．

ただし，変換パターンとして適用できる変換というのは複数あって，たとえば柔軟性とかクラス数の最小化とか，どの属性に着目するかで適用する変換が変わってくる．ものによっては，性能面など，実装都合上のトレードオフなんかも影響する，と述べている．

10章ではいくつか今までのヒューリスティクスを変換パターンとして書き直して紹介していて，１つのパターンの出力が他のパターンの入力になりうる推移性と，specialize/generalize のような反射性（２つ適用すると元に戻る）を持つパターンが挙げられている．

今後の研究の方向性として，次のようなことが挙げられていた: (1) 変換パターンをどう分類するのが良いのか．推移性などでその関連性を整理できるか． (2) 機能拡張などでの設計変更は，変換パターンによってとらえることが可能か？もしそうなら，それらのパターンの入力とは何なのか？ (3) 変換パターンを多数持っていたとして，それによって設計の最適化を自動化することは可能か？つまり，悪いデザインから良いデザインへユーザを導くようなツールは作れるか？そんなツールを作るには，設計の良さを，柔軟性，移植性，効率性，ソフトウェアやハードウェアの制約，クラス数の最小化といった側面から判断できる必要がある．

最後の11章は銀行のATMと銀行のトランザクションを取り扱った設計の例．途中でどんな選択肢があり，どのヒューリスティクスに基づいて設計を選んでいくかというのが解説されている．あとは付録で，ヒューリスティクスのリストと，なぜか「C++で起きるメモリリーク」の例とかが付いていた．

読むのにけっこう時間はかかったものの，読んだ価値はあったといえそう．10章の内容は，悪い設計パターン＝「コードの不吉なにおい」と読み替えると，「リファクタリング」の話に近いことだと言ってよいかもしれない（リファクタリングはコード可読性レベルの話もあるので一緒くたにするとまずい？）．今後の研究の方向性については，けっこうどこかの学会で聞いたかな？というような話もあったりするし，かなり示唆に富んでいるように思う．

余談: ヒューリスティクスによる改善の効果は，リファクタリングの効果が評価しにくいというのと同じように，評価しにくい．この本で出ているヒューリスティクスは，局所的な依存関係の変換だけを提示しているので，クラス数の増減や実行効率の変化を除いては，システムのほかの部分に波及することがない（カプセル化がうまくされているなら）．だからこそ step-by-step な改善に適用できるんだけど，「その改善ってどのくらい効果があるの？」と聞かれると弱かったりする．

_ [ツール] CX-Checker 試してみました ▲

授業で学生がＣ言語のコードを「読みやすく」書きなおす作業をするということだったので，CX-Checkerを試してみました．

一括インストーラでインストールしたら，Cygwin の /bin ディレクトリへの PATH を環境変数に設定してから，Eclipse を起動します．CDT でプロジェクトを作成した後，設定マニュアルに従って，プロジェクトに Cygwin の /usr/include と /usr/lib へのパスを設定しておきます．検査したいコーディングルールを記述した XML ファイルを好きなだけ登録してから，プロジェクトを右クリックして 「Checker」メニューから 「SDB の作成」を行い，続いてソースコードのチェックを実行するだけとなります．設定の半分は CDT の設定に関する部分であり，CX-Checker 自身が要求しているのは Cygwin/bin への PATH 設定とルール集合だけです．設定項目はかなり少なく収まっている気がします．

Cygwin の /bin ディレクトリへの PATH を設定しておかないと java.io.IOException: Cannot run program "cygpath" (プロジェクトのパス名) ... (以降文字化け) というエラーメッセージが出ます．いわゆる「コマンドが見つからない」状態であることがエラーメッセージには明示されていなかったので，解決にはちょっとだけ考え込んでしまいました．また，Cygwin を普通に setup.exe からインストールしていたのですが，make が標準ではインストールされないということに気付かなかったので，こちらも少し引っかかりました．

CX-Checker のツールそのものに関しては，チェックするルール集合が標準では空になっており，「チェックしたいルールだけを追加して使う」という形式になっているので，「学習しながら試す」のに向いている気がしました．変数名の長さぐらいの簡単な検査であれば，MISRA-C 用に書かれた既存 XML ファイル群をそのまま使えますし，「どんな検査がしたいか」考えてカスタマイズすることが可能です．今回は，学部生が授業で書いたプログラムに対して，いくつかの検査ルールを適用するという使い方だったので，既定で大量のルールを用意しているようなコーディングチェッカに比べて，利用しやすかったという印象です．