«前7日分 最新 次7日分» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2006-10-11 [長年日記]

_ [論文] AOASIA2006関連その3:アスペクトの影響の解析

アスペクトを持ってきたらその影響がすぐ調べられる,というような開発支援環境ができたらうれしいなぁ,というようなことを Guenter Kniesel は言っていました.

アスペクトの影響を調べるというのでは,ワークショップのほうでは,アスペクトのウィービング後に成り立っているべき振る舞いを検証する COW (Shinotsuka, S. et al.: An Extensible Contract Verifier for AspectJ)が該当しているかと思います.私はなぜか weaver の実装が正しいことを検証するためのツールだと勘違いしていたのですが…….

うまく発展させれば,「ポイントカットが変なところにもマッチしている」とか,「アスペクト貼り付ける先のメソッドが,元々思っていたような振る舞いをしてなかった」というようなエラーを回避できるんではないかと思います.あんまりちゃんと論文読んでないんで嘘書いてるかもしれませんが.

アスペクトのウィービング前後で特定の性質が保存されていることを検証できるかどうか,というあたりの問題は,ウィービングもプログラム改変操作の一種だと考えれば,たとえばリファクタリング作業の結果プログラムを壊してないか調べるとかいった方面への適用(「動いてるコードは怖くて触れない」問題の軽減とか)もできそうで,実は大事なところなのかもしれない,と思います.道は遠そうなんですけど,まあ,何か思いつくようなら次回の AOSD あたりで誰かを捕まえます :)


2006-10-10 [長年日記]

_ [論文] AOASIA2006関連その2:Fluid AOP

Gregor Kiczales のビデオ接続な Keynote Talk と Terry Hon の発表で,Fluid AOP について説明がありました(Hon, T. et al.: Fluid AOP Join Point Models).

Gregor としては,アスペクトがやっていいことをコード上に明示してアスペクトの能力を制限するのは嬉しくないと思っていたりするようです.どうせほとんどの人は統合開発環境を使うんだから,賢い開発環境のサポート下でプログラムを書く,というのを目指しているようです.

Fluid AOP は,けっこう前にも別のところで論文出てた気がするんですが,プログラミング言語自体は普通のJavaなどを使用し,開発環境が必要に応じて(開発者が「ロギングのコードをいじりたい」というような作業ごとのポイントカットを定義して)該当するコードを発見し,それらのコード片を一括して修正するというアプローチです.

発想としては,「開発者ごとに取り扱うコードのかたまりは違うんだから,開発者が作業ごとに動的にモジュールを構成すればいいよね」といった感じです.過去にあった「ファイル単位にとらわれないソースコードビューを作りましょう」という研究に近いと思います.

今のところ,この手法は,特別なソースコードエディタとして実装されています.クエリに対してコード片集合を抜き出してきて,個々のコード片ごとに違う部分は obj.update***(x, ***) のように塗りつぶしてマージし,見かけ上単一のコード片として提示します.そして,そのコード片を開発者が書き換えると,実際にはポイントカットに該当しているすべてのコードがまとめて編集されます.

このアプローチは,保存結果はただのJavaファイルですし,コンパイラその他の道具も特に変わりません.言語を導入するよりも開発プロセスへの導入の敷居が低く,この環境で書いたコードの実行自体は既存のプラットフォーム上でできるという利点があります.個人的には好みだったりします.

安心して使うには,ちゃんと正しいポイントカットを書いて全部のコードを漏れなく変更しているのかどうかとか,何か他のサポートが必要になってきそうな気はします.しかし,現状,普通のエディタで検索+全置換とかで多数のコード片を編集することを考えると(私が知らないだけかもしれませんが),実用上はそんなに困らないのかもしれません.


2006-10-09 [長年日記]

_ [論文] AOASIA2006関連その1:Obliviousness

ぼちぼちAOASIA関連の話題を整理してます.この記事自体は,正確にはAOASIA前日の別ワークショップで話された内容です.とりあえず研究関連ってことで論文カテゴリに入れておきます.

Obliviousness というのは,「アスペクトを結合するコード(クラスなど)はアスペクトの存在を知らない」といった意味なのですが,これが「クラスのコードは,アスペクトのコードへの参照を含んではいけない」という構文レベルでの話なのか,「アスペクトがなくても動くようなコードを書く」「クラスの開発者はアスペクトの存在を知らなく良い?」とかいう意味的な話なのか,というところが実は曖昧でした.

結局,使ってる人によって意味合いが違っていたようで(おかげでだいぶ議論が混乱していましたが),ベースコード中ではアスペクトの要素を参照しないという構文的な意味が AOP においては必須の性質であろう,意味的な Obliviousness の達成は望ましいが必須ではない,という形で整理されました.

意味的な Obliviousness としては,たとえば性能計測のような完全に後付けのアスペクトは,Obliviousness を達成する必要がありそうです.また,クラスから見た場合,別アプリケーションで再利用したいクラス群というのはアスペクトがあってもなくても動く必要があるでしょうし,アプリケーション固有のクラスは,そのアプリケーション内にいるアスペクトのことを多少意識したコードになっていても問題ない気がします.今のところ,構文的な参照関係以上の明確な指針はありません.


2006-10-08 [長年日記]

_ [お知らせ][hyCalendar] hyCalendar 1.4.1 リリース

リリースしました.変更内容は先週書いたとおりです.

ヘルプのほうは大きなHTMLを多数に分割するなどして,色々直してみましたが,まだ厳しいかもしれません.


2006-10-05 [長年日記]

_ [論文] ASE 2006 の情報少しだけまとめ

NIIでやってたASE2006は,参加者221人(うち本会議参加者は182人),日本人が当然ながら最多で129人,USAから33人,ドイツから13人,フランスから12人.論文投稿数は121,うち22本がフルペーパー,17本がショートペーパー採録でした.フルペーパー採択率は18%.

個人的な印象としては,formal methods を使えるツールにしていこう,と努力してる人が目立った気がします.

便利そうなツールとしては,基調講演で紹介されていた仕様記述&検証環境のCafeObj,Java などオブジェクトの要素をちゃんと扱ってコードのモデルチェックをしようというBogorあたりでしょうか.後者のほうは某先生が「授業で使おうかな」とか仰ってたくらいに良いもののようです(さすがにこの種のツールの良さはまだ自分では判断できないので伝聞形です).

そのほかにも,ツールの使い勝手という側面では,コンパイラに組み込んだらどう?と Volanschi, N.: "A Portable Compiler-Integrated Approach to Permanent Checking" が提案していたり,ツール自体のカスタマイズを容易にするためにZ言語でコード量を小さく抑えてみた,と Ledru, Y. et al.: "Tobias-Z: An executable formal specification of a test generator" が言っていたりしました(Tobias 自体はテストケース生成ツールです).

_ [論文] ASE 2006 でのアスペクト関連な話

ASE の formal methods 系に少し関連しそうな AOP 関連の発表としては,では,Falcarin, P. et al.: "Automated Reasoning on Aspects Interactions", Stoerzer, M. et al.: "Detecting Precedence-Related Advice Interference" の2本のショートペーパーがありました(他にはアスペクトマイニングの発表なんかもありました).

前者はアドバイスが書くデータを読むアドバイスやメソッドが他にいるかどうかを調べて警告を出す,後者はアスペクトの動作順によって文間の依存関係が変わってしまうような場合に警告を出す,というツールの提案です.

どちらの手法も,「あるとちょっと嬉しい」というのは分かっても,本当にどのくらい役立つ事例があるのかはよく分かりません.現時点では世の中にあまり AspectJ プログラムが転がってるわけではないので(Stoerzer は実例は1個だけ知っていると言ってました),その辺は仕方ないかなと思います.

AOASIA の話は独立して長くなりそうなんでまた後日にします.


2006-10-04 [長年日記]

_ [ツール] XTMemo のバグレポートを書いてみた

ここ半年くらい愛用しているXTMemoのバグレポートをごそごそ書いて送ってみました.これで報告は2度目だったりします.

Changelogというただのテキストファイルを3ペインの軽快なGUIで見せる,というのが良いところだと思います.このソフトをインストールしてない別PCでもテキストエディタさえあれば普通に中身を読めるし,不足してる機能があっても他のテキスト操作ツール(grep,sed,ほか)が適用できるという安心感もかなり大きいような気がします.

未来のスケジュールはカレンダーで,詳しい内容はテーマ別に区切ったchangelogに記録していくというのが,今のところお気に入りのデータ管理です.

これからも開発がんばってほしいなあ(大変だろうけど……),と思うツールの1つです.


2006-10-03 [長年日記]

_ tex2textを更新

tex2text.rb スクリプトを,自分の博士論文の原稿が通る程度には直してみました.

多段階の \input{filename} を通るようになったり,エスケープされた "$" をちゃんと識別するようになったり,"section*" のような番号なしのセクションを処理するようになったりしています.

"-s" オプションが有効なときは「行末がピリオドで終わってたら改行する,そうでないなら空白1個で文をつなげる」というように改行を調整するようにしたので,Microsoft Word のスペルチェッカを少しは適用しやすくなったんではないかなーと思います.