netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-05-29 古い日記からの変換データ ▲
_ ウィルス ▲
ウィルス作成講座を大学の授業でやるとかいう話に対して色々賛否両論起こっているらしい．http://www.zdnet.co.jp/news/0305/29/ne00_virus.html
ウィルスやその他サーバへの攻撃などの話では，コンピュータ倫理学(Computer Ethics) での「たとえば病院のサーバがダウンして，死者が出た場合， その責任を取れるのか？」という話なんかもあるので実はそうそうウィルスやワームを作られてはたまらないのだが，正しい原理を学んでおかないと誤った情報を信じて行動してしまう可能性もあるので，悩ましいところではある．
そのうち，ネット家電等に感染するウィルスとかが出てくると本当に死者が出る可能性はある……かな？
_ Eclipse ▲
最近気付いたのだが，Eclipse は起動時のカレントディレクトリにworkspace を作るらしい．だから，ショートカットで「作業時のディレクトリ」を固定しておかないと，エクスプローラで最後に開いたディレクトリにworkspace が作られてしまう．親切なんだか不親切なんだか，微妙なところだ．
_ 暗号 ▲
暗号化してファイルを保存するエディタ EDエディタを使ってみる．いちおう，きわめて類似した平文を同じパスワードから２個暗号化して差分を取って，X+Y - (Z+Y) = X-Z が出てくる!なんてことがないことだけ見て，脆弱な暗号システムではないことを確認．
単に，リムーバブルメディアにプライベートなデータを置いておくときの用心程度なら，この程度で十分のはず．実際のところ，暗号を壊されるよりもパケットやキーボードを監視されるほうがよほど怖いので，手間としてもこのあたりが限界だろう．
2004-05-29 古い日記からの変換データ ▲
2006-05-29 ▲
_ [hyCalendar] 今後の改造プラン ▲
メールで質問を受けて気づいたのですが，今まで「隔週予定」はあっても「５日ごとの予定」とかは書けなかったんですね．30日ごとにチャージしなおす必要があるプリペイドSIMを買ってみたところなので，ちょっと対応してみようかと思います．
ただし，現在は単体テストの導入に向けてかなり大規模な改修を加えている真っ最中です．本業の都合も強く影響しているので，次のリリースはまだ少し（かなり？）先になる予定です．
_ [論文] 良いテスト集合の選択基準の提案 ▲
Benoit Baudry and Franck Fleurey, Yves Le Traon: Improving Test Suites for Efficient Fault Localization.
Proceedings of ICSE 2006, pp.82-91, Shanghai, China, May 2006.
各ステートメントに対して「成功／失敗したテストケースの数」をカウント・比較することで「疑わしさ」を計算し，調査すべき対象のステートメントを推薦することができる．しかし，下手にテストを用意すると，ほとんどの文が同じ「疑わしさ」を持ってしまって役に立たないため，疑わしい文とそうでない文をうまく区別できるような良いテスト集合を作ろう，という論文．
論文では，テストケースの最適化の基準の提案と，それを用いることで「バグを発見するまでに調べなければならなかったステートメントの数」がどのくらい小さくなったかを実験している．
この論文では，テストケースの良さの基準を「Dynamic Basic Block（DBB）」と名づけている．DBBは，あるテスト集合に対して，まったく同じテストケースによってカバーされるような文の集合のことを指す．
たとえば，文 p, q, r, s に対してテスト３つのカバレッジが t1 = (p, q, r, s)，t2 = (p, q, r) ，t3 = (r, s) だったとすると，(t1, t2) によってカバーされる (p, q)，(t1, t2, t3) によってカバーされる(r), (t1, t3) によってカバーされる(s) という３つの Dynamic Basic Block が得られる．(p, q) の片方だけを実行するようなテストケースが作れなければ，これらは区分できないので，同じブロックに属し，「疑わしさ」度合いが常に同じ値になる．
Dynamic Basic Block の数が大きい（１つの集合が少数の文しか含まない）テスト集合というのは，テストごとに違う文の集合を実行することになるので，各文ごとのテストの成功・失敗数をカウントする方法による調査が容易なテスト集合であると考えられる．
この論文では，テストケースを遺伝的アルゴリズムで選ぶ・生成する方法によってテスト集合を洗練する実験を行っている．その評価基準として Dynamic Basic Block を使っており，従来手法より，調べるべきステートメント数を減らせるような少数のテストケースを選択することに成功している．
「良いテスト集合」を得るまでは，カバレッジ計算のためにひたすらテスト実行する必要はあるのが個人的には気になるけれど……，そこは人間の仕事ではないからOKという立場でもいいのかもしれない．
2009-05-29 ▲
_ [論文] Island Grammar の作り方とか例とか ▲
ときどき論文の構文解析に関する記述で目にしていた Island Grammar の解説を探してたんですが，１本だけそれらしいのを見つけました： Leon Moonen: Generating Robust Parsers using Island Grammars. WCRE 2001, pp.13-22. [DOI]
Island Grammar の作り方とかが明示的に与えられているわけではなく，興味ある構文要素だけを取りだすように簡略化した文法の総称だったようです．Island Grammar の非形式的な定義としては，元となった文法で受理できる言語よりも広い言語を受理することがあるが，文法が単純化されたもの，となっているようです．興味のある場所を Island，そうでない場所を Water と呼びます．
構文エラーやヘッダファイルの不足，処理系の方言などの問題によって「正しくASTが作れない」状況や，そもそも特定の構文要素にしか興味がない状況において，ソースコードから情報を取り出したい場合に使うものらしいです．
文法の作り方としては，興味のある最小限の言語要素の並び順だけを処理する単純な Lexer ＆ Parser を作成する方法と，通常の文法をもとに興味のない場所をすべて Waterに置き換えていく方法があります．結局，どういう構文要素が，どんな順序で登場すべきか，というのを厳密に書き下す必要があります．
論文では，COBOL の Call Graph を抽出するために CALL 命令だけ取りだすという状況を最初の例に挙げていて，「CALL Id」「MOVE Id TO CALLEE（CALL HANDLER による呼び出し先を動的に決める命令）」は取り出すが「CALL HANDLER」やそれ以外の空白以外の記号などを Water とする，という文法を作ってます．Island Grammar の定義自体には文法をどのクラスで構成するかは制限なしのようですが，この著者はGeneralized LR (GLR) 文法の世界で定義を作っています．GLR 文法を処理できる parser generator には，Elkhound，DMS Software Reengineering Tools や Bison などがあるようです．使ったことありませんが……．
まじめな構文解析をさぼる分，興味のない部分の構文エラーを無視するようになります．ただし，本当は受理しないはずのソースを受理するので，目的に合致した範囲に収まってるかどうかは注意する必要もあるようです．
