netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2002-10-27 古い日記からの変換データ ▲
_ 文字列の縦書き ▲
Windows で文字列の縦書き出力ができないか，と聞かれて色々調べてみると，Windows API のCreateFontIndirectを使ってフォントを作成すればよいらしい．
Delphi で昔一度作ったことを思い出したのだが，ソースコードはアルバイト先にコミットしたのでもう手元にない．で，Visual Basic で再実装するがうまく動かない．どうも，配列や文字列，オブジェクト参照の扱いが曖昧なので API が呼び出しにくくて全然扱い方が判らない．昔の自分はよくこんな言語使えてたなぁと思う．
2003-10-27 古い日記からの変換データ ▲
_ 論文 ▲
Elissa Newmann and William L. Scherlis:Toward Query-based Constraints
Concern を探すのにsemantic なクエリーを使えるFEAT というツールの話をしている．FEAT そのものの話は ICSE にも出ていた．
この論文での制約というのは「このクラスのサブクラスはこれらのただ二つだけ」とか「このメソッドを呼びたいなら lock をしておけ」とかいう感じの制約のこと．
concern をモデルから取り出して，それらをクエリーによって定義して，concern 間の結合度や合成の制約をクエリーの与える制約によって調べたりできる……のかなぁ．これ自体は Position Paper だったので，素直に FEAT の論文を読んだほうがよさそう．
_ 論文 ▲
Sergei Kojarski, Karl Lieberherr, David H. Lorenz, Robert Hirschfeld:Aspectual ReflectionAOSD 2003 SPLAT Workshop
アスペクトのアプローチとリフレクションを分類した論文．Core Reflection Mechanism と Aspectual Reflection Mechanism を区分けしている．
Core Reflection == メソッド名などの構造的要素Aspectual Reflection == Join Points のような時系列的な要素
主なグループ分けとしては
Smalltak = CRM で実装されたリフレクションインタフェース RI^RAspectS = CRM で実装されたアスペクトインタフェース RI^AAspectJ = ARM で実装されたアスペクトインタフェース AI^ARaspect = ARM で実装されたリフレクションインタフェース I^R
と対応付けている（厳密には AspectJ ではリフレクションが使えたりするので RI^R な側面も持っていることも述べられている）．
_ 論文 ▲
Jeff Gray, Ted Bapty, Sandeep Neema, James Tuck:Handling Crosscutting Constraints inDomain-Specific Modeling
SPLAT2003あたりに出ていた論文．GPCE に出ていたのと同じで，モデルの制約記述をモデルと独立に書いておいてWeaver を使って結合する．基本は XML ベースで結合処理を行う様子．Meta-Weaver Framework からDomain-Specific な Weaver のインスタンスを生成するとか言っている．
_ 論文 ▲
Gary T. Leavens and Yoonsik CheonDesign by Contract with JML
論文というよりは JML の紹介原稿というべきか．
JML の良い点:invariants にも可視性がある． "public" 宣言しない限り，同一パッケージのクラスからしかその invariants は見えない．
representation invariants はクラスの外からは見えない．type invariants は見える．
ensures, signals で通常の終了，例外的終了を分けて書ける．
forall, sum, max, min といった述語が使える．
継承した場合は Liskov の置換原則を保持する．
モデル・フィールドを宣言することができ，実変数を対応付けることができる．同様に，モデルメソッド・モデルクラスを宣言することもできる．
_ ▲ JML の注意点:副作用を持たないメソッドについては不変条件の記述に使うことができるが，メソッドが副作用を持つかどうかを"pure" と自前で宣言しなくてはならない．（書けるだけマシなのだが）
_ 論文 ▲
aosd-discuss で，読んでみてくれーと流れていた論文．
Claudio Sant'Anna, Alessandro Garcia, Christina Chavez,Carlos Lucena, Arndt von Staa:On the Reuse and Maintenance of Aspect-Oriented Software:An Assessment Framework
アスペクト指向ソフトウェア用のメトリクスを提案している論文．
Separation of Concerns Metrics としてどのくらいのコンポーネントがひとつの concern に参加しているか，とかを数え上げている．また，結合度，凝集度，サイズを使っている．オブジェクト指向で書かれたソフトウェアでも同じものは測れるので，それを比較する形になっている．
品質モデルは Basili の GQM パラダイムがベース．実験では，OOとAOで同じシステムを設計して，メトリクス値を測る．システムにいくつかの変更を加えて，それに必要だった変更がどの程度か（いくつ Entity が変更されたか，など）というのをメトリクス値が示している性質と一貫した答えになっているかどうか，評価している様子．
_ 論文 ▲
Robert E. Filman, Daniel P. Friedman:Aspect-Oriented Programming is Quantification and Obliviousnessの続き．
実装上の問題として，スコープをどうするとか，本当に Obliviousness は達成できるのかとか，関連しあったアスペクト間の扱いをどうするのかとか，一貫性の問題は，とかが列挙されている．
アスペクト指向言語とは何なのか，ということも整理されている．・ルールベースのシステムとしてとらえる． しかし，対象プログラムがすべてルールベースだと AOP の議論はできない．・イベントベースの Publish/Subscribe モデルとしてとらえる． コンポーネント間がイベントで動作するモデルなら， Black-Box AOP として考えられる． プログラマが手動でイベントを生成しなければならないのなら， それは oblivious ではないので AOP ではない．・Intentional Programming / Meta-programming としてとらえる． それ自体を AOP というよりは，AOP の実現手段．・Generative Programming としてとらえる． これも AOP の実現手段． まとめ：・AOP の持つ，oblivious quantification というのは OOP とは独立の概念．・一箇所にしか登場しないものはアスペクトにしないほうがよい・より良い AOP システムは，より oblivious である．
_ 論文 ▲
Robert E. Filman, Daniel P. Friedman:Aspect-Oriented Programming is Quantification and ObliviousnessOOPSLA 2000 の論文らしい．
OOP までの概念では，特定のルール，たとえば「オブジェクトを移動させたらディスプレイをアップデートすること」といったルールをで実装するには，「クラスを継承したプログラマは super.foo をメソッドの終わりで呼ぶこと」といったプログラマが協調するためのルールを作る必要があった．
このようなルールが必要ないようにするのが "oblivious" で関連した文を選び出すことが "quantification" ということになる．
AOP でやりたいことは，In programs P, whenever condition C arises, perform action A.という条件ドリブンなプログラミングである．
Static Quantification はプログラムの構造上の情報で条件を定めるもの．特定のコンポーネントへのアクセスや特定のサブルーチン呼び出しをラップしたりする．アスペクトがどこまでベースプログラムの情報を使うかでBlack-Box AOP と Clear-Box AOP と分類している．Clear box はベースプログラムの中身を見るのでソースコード情報が必要だが，デバッグなどには適するし，しかし実装するのは難しい．Black-Box はインタフェースなどを基準に操作するので実装などは簡単だが使える範囲は限られてくる．
また，Dynamic Quantification としては，コールスタックのサイズであるとか，例外の発生や特定の実行パターンがある．
2004-10-27 古い日記からの変換データ ▲
_ [work]エイリアス解析の価値の謎 ▲
エイリアス識別付きのフィールド間データ依存関係の解析を実装しようとしてこける．エイリアス情報が変わるとデータフローが変わってデータフローが変わるとエイリアスの流れも変わるんでは…．という疑問があるし，あまり効果的な解析方法がない．
Flow Sensitive にエイリアスを解析しようとするとメソッド呼び出し順序などが必要になってくるのだが，外部へのメソッド呼び出し時に何が起きるかは（多態性の都合で）決定できないので，外部からメソッド呼び出しを受ける可能性を考えると非現実的．
結局手抜きな実装としては，自分のメソッド内で作ったオブジェクトに対してだけ，外部から参照可能なフィールドに代入されるかメソッドの引数で外へ出て行くまでエイリアスを識別しておくということになるのだろうか．ここでも「外部から参照可能な」が曲者で，Java の private フィールドって自分自身の他のインスタンス（this.class.new したもの）からは参照できてしまう．
こうなると，ローカル変数に代入されているものだけが対象となるわけで，エイリアス解析で解決できる問題がすごく狭いような気がしてきた．
this と，それ以外（thisあるいは他のインスタンスを指す参照）はいちおう区別しておいたほうが良さそうに思えるが，それ以外の場面ではあまり真面目にエイリアス解析しないほうが幸せっぽい気がしてきた．
2007-10-27 ▲
_ [Java][読書] byte は符号ありだった ▲
本屋でたまたま見かけたので，「Java Puzzlers」というピアソン・エデュケーションから出てる本を買ってみました．プログラミングでがんばるのではなく，言語仕様を読み返しながら厳密に動作を検証する（言語仕様の落とし穴やきわどい事例を利用した）パズルです．
まだパズルの章を１つ読んだだけのところですが，Java における byte 型の値域も根拠なく 0〜255 だと思っていたところ，実は -128〜127 だったと，パズルで初めて気づきました．（C言語で BYTE というマクロを unsigned char として定義しているのを見ているせいかもしれません）
Java 相手のプログラム解析とかを作ってて，Java の仕様を知ってるつもりだった身としては，かなり面白いです．ちびちびと読んで遊ぶことにします．
2008-10-27 ▲
_ [論文] WCRE2008 参加メモ ▲
だいぶ時間経ちましたが，先日，アントワープにて開催されたWCREでの議論内容をいくらか書いておきます．
投稿は全部で70件（カナダが最多の22件，日本は5件）で，フルペーパーでの採択は20件．割合でいうと29％．最も厳しい年の１つだったようです．20分発表を３件やってから30分まとめて議論というスタイルの発表でした．４日間シングルトラック（２日目午後のワークショップのみ並列）で，わりと小規模なイベントでした．
コードクローンや関心事はそれなりに注目されているのか，それぞれ１セッションずつありました．ただ，いずれも定義がはっきりしないために手法の評価・比較が難しい，というあたりで議論が進まない感がありました（特に解決策は出ず）．
全体としては，可視化系のツール・論文が目立っていた気がします．ただ，手法の使いやすさを評価するには他人が使わないとダメなのではないか，時間軸をアニメーションで出すのは面白いけど見たあとに結局何も覚えてない，結局何に使うの？とか，厳しめな意見も多数出ていました．また，まず何が知りたいかを色々考えたいときに可視化は有効だ（詳細は表で見ればよい），と言ってる人もいました．
そのほか，変更予測などの研究におけるコスト対効果のトレードオフに関する質問なんかも出ていました．「変更作業を３０分早くするために１０時間計算機を使ってよいか」みたいな話に対して，CVS のサーバが普段は何もしてないのでそれを使って計算する，といった答えが出されていました．このあたり，運用面まで考えた手法の設計が必要になりそうです．
2009年は，ICSEとICSMが北米開催なので，WCREはボストン開催の予定を１年先に延ばして，来年もヨーロッパ開催にするとのことです．
