netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-09-02 古い日記からの変換データ [長年日記] ▲
_ IWPSE/FSE ▲
IWPSE2003 １日目が無事終了．発表も無事(?)終了．質疑応答をまとめる．
論文は面白いものが色々．研究室の特定の人に読んでもらったほうがよさそうな論文がいくつかあるので，後でまとめることにする．
JAISTの，おざきさんと話す．ネタが固まると，いきなり論文を英語で書く（書かせられる）らしい．けっこう大変そうだけど……．D1で2回目の発表だ，と言ったら感心された．
カンファレンス・ディナーはフィンランド料理のコース．１品１時間くらいの間隔で，３時間ほど食べてたらしい．会話が主役だからかゆっくりしている．最後のほうは，みんな疲れたせいか口数も少なくなってたけど．
夜になると，さすがに寒い．吐く息が微妙に白かったりする．
2003-09-07 古い日記からの変換データ [長年日記] ▲
2003-09-08 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
JML について調べてる最中に偶然見つけた論文．
Maximilian Storzer, Jens Krinke, Silvia Breu:Trace Analysis for Aspect Application
出典は Workshop on Analysis of Aspect-Oriented Software (AAOS 2003) as part of ECOOP 2003, July, 2003
実行履歴トレースの差分から impact analysis をするらしい．役立つのかどうかは謎．
_ 論文 ▲
FSE 2003 論文整理もこれで終わり．
FSE Session IX: Safety and Security
S. Yong, S. Horwitz:Protecting C Programs from Attacks via Invalid Pointer Dereferences
「ポインタが指してよい領域」を保持したメモリマップを作っておいて，それに対する書き込みをチェックする．また，フロー解析をして，ポインタが予期せぬ領域を指す可能性があるものをunsafe とマークしておいて，unsafe ポインタのアクセスだけを監視すればオーバーヘッドを抑えられる，という話．unsafe な read は調べるべきか調べないべきか，という議論はあるが，完全に実用を考えた構成になっている．
K. Sen, G. Rosu, G. Agha:Runtime Safety Analysis of Multithreaded Programs
Temporal Logic でデータアクセスの順序を検証しようというもの．データの流れを Lattice 化して検証しているようなのだが，空間も時間も O(w・2^m) で m は Temporal Logic の式の数，w は Lattice の幅（イベントの「同期」数に依存）らしくて，コスト的によいと言えるのかどうか謎．個人的には Temporal Logic を誰が書くんだろうというのも気になる．誰かが，「オブジェクト指向言語でなら，もうちょっとインスタンス共有とかうまい方法で状態数が減りそう」とか言っていた．
_ 論文 ▲
FSE 2003 論文整理はさらに続く．
FSE Session VIII: Component-Based Software Engineering
F. Xie, J. Browne:Verified System by Compsoition from Verified Components
コンポーネントの検証の話．After(xxx) Never (yyy) Until (zzz) のような動作特性をボトムアップに検証する．Assumption (ソースコードやマニュアルから自動生成の予定）とProperty (調べたい特性) を比較するんだーという，目的がはっきりしている点は好感が持てた．
S. McCamant, M. Ernst:Predicting Problems Caused by Component Upgrade
アプリケーションはコンポーネントの実装に依存しているかもしれないのでBehavioral Subtyping では不十分．( Pre_app → Pre_comp )∧( Pre_app ∧ Post_cop → Post_app )というのが良い，と言っている．で，実際に検証して，「このバージョン変化でこの部分は動作しなくなる可能性がある」と表示するということになるらしい．ただ，コンポーネントの不変条件とかは自分で書かないといけないらしいので，そのあたり，実用化には厳しい．
H. Rajan, K. Sulivan:Eos: Instance-Level Aspects for Integrated System Design
Mediator としてアスペクトを使いたいので，アスペクトのインスタンスがほしい．型ベースで，すべてのインスタンスに反応するようなのは嫌．また，対応相手がいない場合や１個のインスタンスに複数のアスペクトのインスタンスが貼り付くようなのも考えたい．そこで，インスタンスレベルアスペクトというのを考えた．要は，イベント処理を言語要素にしたくて，単に new Aspect(obj1, obj2) とか叫びましょう，というものなのだが，これ，アスペクトを生成するのは誰か，という問題が出てくるので，かえって複雑度を上げてたりはしないのだろうか？
_ 論文 ▲
FSE 2003 論文整理その５．
FSE Session VII: Software Analysis and Model Checking
Stan Jarzabek:Eliminating Redundancies with a "Composition with Adaptation" Meta-Programming Technique
XVCL を使って，コードをパラメタライズすることで冗長性を減らしましょう，というもの．発表の後で，「継承と Generics と XVCL ではどれがいいんですか？」と聞いてみたのだが，「リファクタリングで複雑なモジュール構造を導入するのは良くない，リファクタリングで大事なのは冗長性を減らすこと」みたいな考えを持っているらしい．メタプログラミング（というより「コード本体のテンプレート化」か）は難しくないのだろうか，とは思わなくもないが，ただの Generics よりはコード本体部分をパラメータ化できる強みがある．コードの冗長性はいいが，理解容易性やメンテナンス性はどうなのか，とか質問もあって，みんな興味は惹かれていた様子．
Yung-pin Cheng:Towards Scalable Compositional Analysis by Refactoring Design Models
リファクタリングの話かと思っていたら，モデル P から，解析しやすく意味は等価な P' を作りましょう，という話だった．こんなの考える人がいるんだなーと感心はしたが，興味がないので飛ばす．
_ 論文 ▲
FSE 2003 その４．正確には論文ではなく Invited Talk だけど．
Ari Jaaksi:Assessing Software Projects - Tools for Business Owners
色々なツールをどう使うか，という話だったのだが，その中ではエラー数グラフの読み方が面白かった．・時刻に対してエラー数が増えないのは，テストが正しくない可能性が高い．・新しいエラーを見つけながら古いエラーは修正されるはずである． エラーが未解決のままなら，開発は進展していない．という感じで考えるらしい．また，Product Family 間でドキュメントやテストを共有することでコストを削減できる，といった発言もあった．
_ 論文 ▲
FSE 2003 その３．
FSE Session V: Validation and Verification
J. Krinke:Context-Sensitive Slicing of Concurrent Programs
スレッドの扱いをきちんと行った論文．普通は「すべての可能性を」依存関係に含めるが，その中から，ありえないパスを除去するためにコンテキスト情報を使う．依存関係を解析するときに「スレッドＡなら１行目か５行目から，スレッドＢなら２行目から」依存関係が来る，という情報を持ってスレッドを追いかけていくことで，「スレッドＡの６行目からの依存関係はありえない」というようにスライスの正確性をできるだけ保持しようとする．
O. Tkachuk, M. Dwyer:Adapting Side Effects Analysis for Modular Program Model Checking
ある検証範囲を設定して，その中での Side Effect を抽出しようというもの．ここでの Side Effect というのは「データの変化」っぽいのだが．将来的には，連動するクラスを勝手に探すとかいうのも考えているらしい．
_ 論文 ▲
FSE 2003 論文その２．
FSE Session IV: Software Process and Workflow
M. Muller, F. Padbera:On the Economic Evaluation of XP Projects
XP が儲かるか？という話．経済モデルとして，Net Present Value Model （だったか？）:現在の１＄ ＞ 翌年の１＄＋Discount Rate という計算を考えて，
XPは「ペアプログラミングなので開発は少し遅れる」，普通の方法は「品質がXPより少し下がるのでその品質保証分作業時間が必要」というSpeed Factor, Defect Factor という二つのパラメータを考えて，パラメータの変化でどのくらい得られる金額が変わるかを計算した論文．ある程度の Speed Factor と Defect Factor があるなら，Market Pressure が大きくなると(Discount Rate が上がると)XP のほうが儲かりやすくなるらしい．
Communication Overhead を考慮していなかったり，どうやって二つのパラメータを推定するんだ，とかモデルにも色々な問題はあるのだが，最初に言ったという意味ではすごくえらいと思う．
_ 論文 ▲
続いて，FSE 2003 の論文整理．
FSE Session I: Requirements Engineering and Design
S. Uchitel, J. Kramer, J. Magee:Behaviour Model Elaboration using Partial Labelled Transition Systems
仮定，制約 から シナリオ（シーケンス図）を書いて，それを読んで Labelled Transition Model を生成して解析しましょう，というもの．
従来は，モデルに書いてあるものは許可，書いてないものは禁止，だったのだが今度は許可と禁止は明示して，そうでないものは Undefined として，状態変数と，シナリオごとの事前条件から，「この状態ではこういう遷移の選択肢があるけど，これは未定義だよ」とユーザにフィードバックをしようというもの．設計フェイズで使うと面白そうなツール．わりと実用的に見えたけど，どうなんだろう．
R. Jeffords, C. Heitmeyer:A Proof Strategy for Efficient Verification of Requirements Specifications Using Composition and Invariants
全然よくは分かっていないのだが，検証コストが高いものを，Σ → Σ1 ＋ Σ2 に分解してから個別に検証をかけよう，という Compositional Approach という言葉だけが印象に残った．最近，スケーラビリティが問題になることが多いせいだろうか．
_ 論文 ▲
IWPSE2003 論文整理その４．
Ahmed E. Hassan, Richard C. Holt:The Chaos of Software Development
ある一定の期間の，ファイル変更回数を「各ファイルが変更される確率」とみなして，Entropy を計算する．変更が特定ファイルにかたまるほど Entropy が下がる．正規化する都合上，ファイル数が増えると Entropy が小さくなるので変更される Active Set のサイズで見よう，とか言っている．ちなみに，期間はリリース回数や時間，変更回数などで見る．Future Work として，複雑度 Metrics との対応や，リファクタリングやアスペクト抽出の手がかりなどを挙げていた．
John Champaign, Andrew Malton, Xinyi Dong:Stability and Volatility in the Linux Kernel
変更されてリリースされた回数÷総リリース回数 で得られる確率から，「変更される確率」を予測しようという話があって，それを Linux Kernel に適用したらあまり合ってなかった，らしい．予測しようというだけえらいいとは思うのだが，もうちょっと考える必要があるのかもしれない．
_ 論文 ▲
IWPSE2003 の論文整理その３．
Reeigineering a PC-based System into the mobile Device Product Line
PC上で動かす City Guide アプリケーション（JDK1.4, J2SE）をMobile デバイス用の J2ME or J2SE（しかもディスプレイやメモリも制限される）上で動作させる．XVCL でメタコンポーネントを作って，目的デバイスに合わせたコードを生成するようにした．
個々のコンポーネントを作るのは，コンポーネントの数または大きさが増加するし，共有コードをうまく扱えないし，冗長で無駄が多いので，メタ情報を使ったほうがよい．実行時アーキテクチャと開発時のアーキテクチャは別物．実行時: Components, Connectors, ...開発時: 変更をどう扱うかunit of change != unit of execution
C. O'Reilly, P. Morrow and D. Bustard:Lightweight Prevention of Architectural Erosion
ソース変更→依存関係の変化，をビューアで見ようとかいうものらしい．ArchAngel というツールを実装しているあたりは偉い．
_ How History Justifies System Architecture (or not) ▲
変更履歴 → 同時に変更された Entity → Couplings Metricsを計算する．ソースコードから，抜き出す情報は，クラス名やメソッド名と，その行番号の対応だけ．その範囲の行が変更されたら，メソッドが変更されたとみなす．
Coupling を dotplot (クローンの場合と違って多段階だが) で表す．A が10回，Bが4回変更されていて，同時に変更されたのが3回なら，A→B は 30％，B→A は75％の結合度となるので，非対称の絵になる．絵の中で，結合度がある区画にまとまっているほどモジュールの強度が良いということになる．また，エディタ上での変更に対して，この結合度を使って変更波及可能性を出したりしてプログラマの支援を行う．
_ 論文 ▲
IWPSE2003 の論文整理その２．
Using Coordination Contracts for Flexible Adaptation to Changing Business RulesM. Wermelinger et al.
Service を computation interface （機能の実装）とconfiguration interface （必要な条件パラメータを返す）という二つのinterface を持つものと考えて，Coordination Contracts を記述する．Coordination Contract は，サービスに対するメソッド呼び出しに対して，Configuration インタフェースを使って条件をテストし，when ... do {} という書き方で Dynamic AOP 的に手続きを実行する．Instance ベースで，システムを止めずに BR を追加できたりするらしい．
Dynamic Behavior and Protocol Models for Incremental Changes among a Set of Collaborative ObjectsNguyen Truong Thang, Takuya Katayama
1 concern = 1 collaboration と考えて，Separation of Concerns を実践する．incremental change を collaboration の追加と考えて，モジュールとして扱う．別々に定義した collaboration を形式的手法で合成するらしい．
Class Refinement for Software EvolutionHiroyuki Ozaki, Katsuhiko Gondow, Takuya Katayama
クラスの継承は「Class Refinement （機能の変更）」と「Augmentation （オーバーライドなしの継承）」に区分できる．CLASSICJAVA (Javaのサブセットらしい）上でA# を拡張した A と B# を拡張した B があるとき，A# と B# の Augmentation の関係があり， A と B に Augmentation であるときにA# + B# が A + B と Augmentation であることを形式的に示すらしい．インスタンス変数が親子クラス間で共有していないこと，といった微妙な制約だけでよいらしい．CLASSICJAVA については Flatt, Krishnamurthi, Fellenisen, "Classes and mixins", POPL 98, を参照．
_ 論文 ▲
IWPSE 論文の整理その１．
Reconstruction of Successful Software Evolution Using Code Clone DetectionF. Van Rysselberghe and S. Demeyer
バージョン間のクローンを解析して，システム内部の変更なしのコピーを識別したりリファクタリングの手がかりを得よう，dotplot による可視化で，メソッドの移動などを識別したりコードクローンの exact マッチからメソッド抽出リファクタリングなどをしようという話．発表の後で本人に聞いてみたら，クローンの図にはパッケージ単位などではなくシステム全体を使うらしく，「100 万行くらいになったら小さいクローンはどうするの？」と聞いたら，「難しい，困ってる」という感じで返ってきた．ちなみにクローン識別には Duploc を使ってるらしい．「違いを見つける」ことで「同じところを見つける」らしい．
Beyond the Refactoring Browser: Advanced Tool Support for Software RefactoringT. Mens, T. Tourwe, and F. Munoz
リファクタリングは，1. リファクタリングをするべきか，2. どこにどのリファクタリングをするのか，3. リファクタリング作業，4. リファクタリングの効果を評価，という４ステップで実行される．ここで，論理型言語で「使われていないパラメータが存在する」などといった「不吉な臭い」述語を記述しておいて，それらがtrue になったらリファクタリングを提案する．小さなリファクタリング（メソッドの移動，名前の変更，etc）の組み合わせでリファクタリングを実行する．また，メトリクスを使ってその効果を計る（あくまでリファクタリング終了後に効果を計るだけの様子で，別に「どのリファクタリングが効果的か」というのを示すわけではない）．また，リファクタリング作業が終わると，述語を再評価して新たなリファクタリング候補を提示する．
2003-09-09 古い日記からの変換データ [長年日記] ▲
_ LotR ▲
どうやら誤植訂正は，お馬さんや Warg の Strength の修正だけらしい．ルールに関しては，長い持続時間の呪文のペナルティが累積していく問題が修正された．
BRGｘ１時間より長い持続時間であるような呪文に関しては，夜明けの時点で，持続中の呪文によるペナルティが消える．また，Sorcery に関しては夜明けのかわりに日没がその条件になる．持続が "集中" の呪文は，この処理の対象とはならず，効果が持続している間，ペナルティとなる．
_ 論文 ▲
Behaviroral Specification メモその３．
SDL とかのはなし．http://www.cs.rutgers.edu/~shklar/www11/final_submissions/paper5.pdf
Component Protocols/Sequencing Constraints Bibliographyhttp://www.cs.washington.edu/homes/taoxie/sequencing.htm
実行時の振舞いからコンポーネントの使い方を見つけるhttp://www.cs.ualberta.ca/~stroulia/Papers/KDD2002.pdf
Integrating Behavior Protocols in Enterprise Java BeansEJBで，メソッドの呼び出し順序などをステートマシンで表現して静的・動的にチェックしましょうという話．http://www.emn.fr/x-info/afarias/docs/farias-geheneuc-sudholt2002integrating.pdf同じ人の別論文． http://www.emn.fr/x-info/afarias/docs/doa2002.pdfこの人，メソッド呼び出し順序だけに「状態」を限定しているのかな？
Bandera: Extracting Finite-state Models from Java Source Code
Rediscovering Workflow Models from Event-Based Data http://cnts.uia.ac.be/benelearn2001/proceedings/bene01-weyters.pdf
S. Butkevich, M. Renedo, G. Baumgartner, and M. Young. Compiler and tool support for debugging object protocols. FSE 2000 http://www.cis.ohio-state.edu/~gb/Brew/Publications/Protocols.pdf
_ 論文 ▲
Behavioral Specification 関連情報その２．
Behavioral Specification Walk-thru
What should the behavior spec include?- How does the component act in every defined situation?- How does it change its functional state?- How does it restrict state changes?- How does it maintain its internal state variables?- If it is a physical object, what is the physics of its performance?- How are its output requirements met?- How are its constraints met (if applicable)- How are potentially dangerous states/commands handled?- How are any potential ambiguities in the command structure handled?- Once this is done ask yourself - does it meet its safety and performance objectives?
どうやら，動作仕様というのは「全部」書くもので，最小限の制約記述ではないらしい？
Functional and Non-Functional Contracts Support for Component-Oriented Programminghttp://www.ccs.neu.edu/home/lorenz/oopsla2001/53_Collet.pdf
Deploying Non-Functional Aspects by Contractcontract 記述でコンポーネントが従う QoS 情報などを指定する．オブジェクトはそのままで，Contract だけを差し替えることが可能？http://www.cs.wustl.edu/~corsaro/papers/RM2003/p1-sztajnberg.pdf
Behavioral Specification and Analysis of Object-Oriented Designs (1997)Boumediene Belkhouche, Joel WuJournal of Object-Oriented Programmingオブジェクトの振る舞いを記述する．振る舞いの記述は，一般に，プロセッサ・回路設計，通信プロトコル合成などで使われている
http://www.objs.com/x3h7/sec24.htm
ステートマシンを使って，コンポーネントの合成結果の一貫性を調べるものは既にあるらしい．でも，ステートを全部記述するのは「実用的ではない」という気がする．
http://www.uni-paderborn.de/cs/ag-engels/Papers/2002/IDPT-Pasadena.pdfConsistent Interaction of Software ComponentsGregor Engels and Jochen M. K¨ uster
_ 論文 ▲
Behavioral Specification 関連の話をメモ一式．なんか適当だ．
Larch/C++ インタフェース記述言語:http://www.cs.iastate.edu/~leavens/larchc++.htmlドキュメントコメント形式で，各メソッドの事前条件と事後条件を記述できる．
通常，事前・事後条件は，各メソッドの開始と終了にだけ言及する．インタフェース記述であり，実装に関する言及は行わない．
http://www.i3s.unice.fr/~map/WEBSPORTS/1999a2002.htmlBehavioral specification of Java component using SyncCharts.コンポーネントの振る舞いの仕様を記述しようというもの．
Isabelle Ryl and Mireille Clerbout and Arnaud Bailly:A Component Oriented Notation for BehavioralSpecification and Validationhttp://www.cs.iastate.edu/~leavens/SAVCBS/2001/papers-2001/ryl-clerbout-bailly.pdf
コンポーネントの仕様をIDLで記述する，特にメソッドごとの振る舞いについても記述されている．
_ JML ▲
Gary T. Leavens, Albet L. Baker, Clyde Ruby:JML: A Notation for Detailed Designを読んだ．各クラスの仕様を /*@ @*/ コメントとして記述しておく．記述言語が Java に特化されており，Eiffel の Pre/Post Condition に加えてnormal behavior と exceptional behavior を分けて書いたり，モデル上でのみ有効な型や変数を定義したり，必要なら実装上の変数にマップできたり，といった色々な機能が使えるらしい．これと Protocol 系の定義を組み合わせたらかなりのレベルまで詳細な仕様記述が書けそう．
2003-09-11 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Dataflow pointcut に関しては増原先生の論文が APLAS'03 に出るらしい．11月らしいのでメモしておく．連絡して論文送ってもらうようお願いしたほうが早い気もするけど :-)
_ 論文 ▲
Mitchell Wand, Gregor Kiczales, Christopher Dotchyn:A Semantics for Advice and Dynamic Join Points in Aspect-Oriented ProgrammingACM Transactions on Programming Languages and Systems
Workshop on Foundations of Aspect-Oriented Languages (FOAL2002) に登場した論文の改良版(?)らしい．
アドバイスをλ抽象で記述したりしているのを見ていると，Dataflow Pointcut なんかもこうやって記述される日が来るのだろうか．でも，control flow はスタックでいいとして，data flow はどうやって表現するのが正解なのだろう．
2003-09-12 古い日記からの変換データ [長年日記] ▲
2003-09-15 古い日記からの変換データ [長年日記] ▲
_ 新マシン ▲
小型ケースなのでファンが貧弱（ちなみに電源はACアダプタ），放熱が大丈夫なのかなーと思ってたら，ケース全体の熱伝導性がかなり良いようで長時間は触っていられない熱さになっている．こう熱いと上に変なものを載せられないので，微妙に置き場所が難しい．
_ 読書 ▲
本を整理していて，そういえばそろそろエリザベス・ヘイドン「ラプソディ」の第３部が出るはずだなぁ，と思っていたら，もう発売されていたらしい．タイトルは「デスティニィ -大空の子-」．時間が取れ次第買いに行くことにする．
2003-09-16 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
AAOS2003 からもうひとつ．
Maximilian Storzer, Jens Krinke, Silvia Breu:Trace Analysis for Aspect Application
以前ざっと見て役に立つのかなーと思って流してたのだが，実はJens Krinke ってコードクローンな研究してる人だったような気がしたり，いくつか気になったのでちゃんと読み直し．
アスペクトの影響を調べるために実行トレースの差分を取ってやろう，というもの．実行トレースを用いる都合上，「たまたまアスペクトが貼り付いていない」場所などは認識できないという問題はあるが，どのメソッドが呼ばれるように/呼ばれないようになった，とか調べることができる．
もちろん，条件はシステムが同じ入力を受け取ること，同じ入力には同じ動作をする（ランダムな振る舞いをしない）こと．
マルチスレッドな場合も，ちゃんとスレッドの区別だけしてれば大丈夫らしい．
システムを改造しても（たとえばアスペクトの抽出をしても）セマンティクスさえ同じなら実行トレースは同じはずだ，と言っているけど，クラス名なんかの変化をどうやって扱う気なんだろう（このあたりは特に記述はない）．
アスペクト指向なプログラムにおけるデータフロー解析の研究はまだ十分ではないので，static analysis を支援するのにこういう実行時解析を使いましょう，とも言っている．たしかに，実現は楽かも．
_ 論文 ▲
Analysis of Aspect-Oriented Software (AAOS2003) より:
A. M. Reina, J. Torres, M. Toro:Aspect-Oriented Web Development vs.Non Aspect-Oriented Web Development
Cocoon2 と AspectJ で同じ Web Application を開発して比較したという論文．
比較されているのはユーザ認証と引数チェックだけだが，結果として，・Cocoon2 は XML で制御されているので，簡単に書けるけど 局所性は完全ではない・AspectJ は局所性はうまく行ってるけど，見易さという意味では Cocoon2 にはかなわないという結果となった．Cocoon2 のほうが Domain-Specific だと考えればわりと妥当な結果である．
理想系は「強力な（高い抽象度記述が可能な）AspectJみたいなアスペクトを使ったフレームワークがあること」なんだろうなぁ．分散した(Scattered)記述を管理するためのツールさえあれば，ある程度はうまくいくのだろうけど，
_ Aspect Browser ▲
Aspect Browser: Aspect Emacs and Nebuloushttp://www.cs.ucsd.edu/users/wgg/Software/AB/を試してみる．
grep （正規表現あり）の結果を色づけマーキングしてソースコードを縮小表示するツール．JDK1.3 でないと動かなかったり，画面描画もちょっと怪しかったりするが．
マッチした部分が重なったときに色を組み合わせて表示できないところが，少し物足りない．が，「こんなに同じ行が登場してるよ」とリスト表示してくれる機能は面白い．Eclipse プラグイン化するらしいので，それに伴ってユーザインタフェースがもう少し洗練されたらちゃんと使えるツールになるかも．
2003-09-17 古い日記からの変換データ [長年日記] ▲
_ AOSD ▲
ようやく AOSD2004 の Call for Contribution が更新された．Full Paper は 10 ページらしい．おかげで，日本語論文ではかなりカットした原稿までフルに載せられそう（載せないといけない，という意味でもあるが）．
_ Java ▲
JScrollPane に載せたテキストコンポーネントにファイルをロードしてもスクロールバーが有効にならない，のはスクロールバーを revalidate すればいける，と教えてもらった．
2003-09-21 古い日記からの変換データ [長年日記] ▲
_ NIS ▲
Network Infomation Service ではなく，Norton Internet Security 2004 のアップグレード案内が届く．今回は5300円．なんか税金みたいに取られていくが，頻繁に（ほぼ毎日）移動するノートPCだといつ感染するか分からないので投資としては妥当な金額か．
デスクトップのほうはルータで守られているので放置の方針．
_ LaTeX ▲
ニ段組ぶち抜きの表や図はfigure* や table* らしい．なぜ "*" なのかはよく分からない．eqnarray* は数式の番号省略だし．Windows API の ...Ex みたいなものだろうか．
2003-09-23 古い日記からの変換データ [長年日記] ▲
_ 読書 ▲
水野良「砂塵の国の魔法戦士」読了．以前からの伏線（魔法戦士リウイシリーズ）が長かったのでもう半分以上状況は忘れてた気もするが，あとがきによれば，次回作では "ファーラムの剣" など，ソードワールド初期からの設定が関わってくるらしいし，アトンのせいで止められていた新王国歴521年以降にようやく踏み込んでいくらしい．かなり期待．
_ TRPG ▲
トーキョーN◎VA the Detonation 購入．世界設定は the Revolution のときに比べて使いやすそうなので少し期待している．ルールの変化をちゃんと把握しないといけないけど．
_ 読書 ▲
秋田禎信「我が聖域に開け扉（下）」読了．９年越し，20巻目にしてようやく完結．
最終的な解決方法はわりと妥当な感じ．でも，真相解明~エンディングまでがちょっと短すぎるような気はする．やっぱり作品の長さに対して発愛の都合とかもあって構成が難しいんだろうか．
_ AspectJ ▲
Macneil Shonle という人の報告によれば，(AspectJ-dev ML)AJDT では，まだ Organize Import が動作しないらしい．単に AspectJ の構文解析ができないせいらしいが．もっとも， import 文の自動生成は，以前，パッケージ名が異なりクラス名が同一であるようなクラス名に対しての処理が甘くてファイル全部壊されたので，あまり使う気が起きない．
あとは，set* のようなワイルドカードが，ソース整形したときにトークン単位で set * のように分離されて構文エラーになるとか．もうちょっと，良い表記法があればいいのだけど．
_ AspectJ ▲
AJDT も AspectJ 1.1.1 に合わせてバージョンアップ．こっちは 1.1.4．（1.1.2 まではRelease Candidate で使ったので番号がずれている）
Mac OS X にも対応したらしい．（今までは Swing にくっついてた実装があったらしい）
2003-09-25 古い日記からの変換データ [長年日記] ▲
_ Java ▲
Java の言語仕様に AOP を取り込むことを考えている，とかいう微妙な記事．熱心なのは JBoss と IBM の人々らしいが，どうするんだろう．取り込まれるのは AOP であってAspectJ ではないので，どういう形式になるかによって実用的かどうかが決まってきそう．http://news.com.com/2100-1007_3-5081831.html
_ 論文 ▲
The Computer Journal Special Issue on AOP and Crosscutting ConcernsVolume 46, Issue 5, September 2003がオンラインからアクセス可能になったよーとaosd-announce でアナウンスされてた．
http://www3.oup.co.uk/computer_journal/current/
リストを見た限りでは，どこかで見たことがあるものばかり．
2003-09-26 古い日記からの変換データ [長年日記] ▲
2003-09-27 古い日記からの変換データ [長年日記] ▲
2003-09-28 古い日記からの変換データ [長年日記] ▲
2003-09-29 古い日記からの変換データ [長年日記] ▲
_ pdftotext ▲
あまり時間をかけても仕方ないし，pdftotext -raw で実用に比較的近いものが出てくるようなので妥協することにした．それでも改行時の "-" 取ったりとか適当な文の切れ目を見つけたりとか，色々やることはあるんだけど．
_ PDF2TEXT ▲
PDF2Text Batch バージョンなんてものがあったから試してみたが，"ff" などの特定の文字並びが一部文字化けする上ニ段組の解決もしてないので，全然役に立たない．http://www.traction-software.co.uk/pdf2textBatch/index.html
_ PDF2ASCII ▲
pdf2ascii ってないんだなーと思っていたら pdftotext だった．PDF から英語論文のコーパスを作ってみたいのだが，ニ段組がそのままの形で出力されてしまうのが難点．
_ 論文 ▲
Frank Hunleth, Ron Cytron, and Christopher Gill:Building Customizable Middleware using Aspect-Oriented Programming
分散アプリケーションのミドルウェアでアスペクト指向を使おうというshort paper．CORBA を使っているので，AspectIDL とかいうのを考えていたらしい．アスペクトがミドルウェアの実装とテストフレームワークを横断している図にちょっと興味を惹かれた．
_ 論文 ▲
AspectJ のイディオムを整理した論文．前の Idioms for Building Software Framworks in AspectJ を包含して，Marker Interface が新しく加わっている．
Stefan Hanenberg, Rainer Unland:AspectJ Idioms for Aspect-Oriented Software Constructionhttp://www.cs.uni-essen.de/dawis/publications/papers/aop/2003_HSU_AspectJIdioms_EuroPLOP_2003.pdf
こっちのほうが refer するには良さそう．Hanenberg, S., Schmidmeier, A.: AspectJ Idioms for Aspect-Oriented Software Construction, Proceedings of 8th European Conference on Pattern Languages of Programs (EuroPLoP), Irsee, Germany, 25th–29th June, 2003
このあたりも，一度サイトに整理してみようかなぁ．
_ 論文 ▲
Stefan Hanenberg, Pascal Costanza:Connecting Aspects in AspectJ: Strategies vs. Patterns
AspectJ の機能を整理している論文．アスペクトをどのようにアプリケーションに接続していくか，という Strategy (パターンではなくて戦略）の話．
アスペクト・アプリケーション間の接続に利用可能な Strategy を，次のように規定している．
Static Crosscutting:
・クラスの先祖を直接追加
・クラスのメンバーを直接追加
・アスペクトの影響を受けたコンテナと 接続するアスペクト（間接的な振る舞いの追加）
Dynamic Crosscutting:
・直接，pointcut で接続・アスペクトが接続されたコンテナに，オブジェクトを接続
・具象アスペクトが抽象 pointcut を再定義して接続
・独立した pointcut 同士を組み合わせて接続
それぞれ，どんなメリットがあるかを記述しているのでデザインパターンに似ているのだが，この人たちはあえて Strategy という言葉を使っているらしい．
Strategy と Idiom, Pattern の区別として，Idiom は特定言語の実装例のこと，Pattern は，使うことで品質が保証されたりといった利益があるものである，という立場を取っている．
_ 論文 ▲
前に読んだ論文の読み直し．
S. Hanenberg, A. Schmidmeier:"Idioms for Building Software Frameworks in AspectJ"AspectJ のイディオム４種類を紹介している論文．
子アスペクトが，動作すべきかどうかを boolean 値で返して，true のときのみアドバイスが動作する pointcut method，というイディオムがあるのだが，pointcut method が副作用を持っていると問題が起こる場合があるので，それを防止する策と一緒に使わないと困るのかなぁ，とふと思った．副作用について議論しようとすると，その過程で refer することになるかな？と思ったのでここに再掲しておくことにする．
_ AspectJ ▲
ふと思い立ってGoogle で "AspectJ" で検索してみたら，日本語サイトだけなら２位，英語も含めても13位．だんだん順位が上がってきた．"アスペクト指向" ではまだまだ developerWorks などにかなわないけど，論文などは10位以内に出るようになってきた．
_ AspectJ ▲
こんなのもあるらしい．aosd-discuss で紹介されていた．The Aspect-Oriented Software Architecture Design Portalhttp://trese.cs.utwente.nl/taosad/
どこかで見た URL だと思っているのだが，Early Aspects の Workshop を去年くらいに開催したところのような気がする．
2003-09-30 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Hanenberg, S., Oberschulte, C., Unland, R.: Refactoring of Aspect-Oriented Software, Net.ObjectDays 2003, Erfurt, Germany, September 22-25, 2003
Aspect-aware Refactorings をしましょう，という論文．
call(class_name.set(*)) でアスペクトを貼り付けても，「メソッドの引き上げ」などのリファクタリングをしてしまうとアスペクトが効果を発揮しなくなってしまう．
メソッドの名前変更 (Rename Method):
C.foo から C.bar に変更した場合，pointcut も変更する必要がある．call(*.foo()) → call(*.foo()) || call(C.bar()); とか，call(*.bar()) → call(*.bar()) && !call(C.bar()); とか．
メソッドの抽出:
C.foo の一部を C.bar に抽出した場合，withincode を等価変換するには，次のように変更する必要がある．withincode(void *.foo(..)) → (withincode(void *.foo(..)) && !call(void C.bar(..))) ||(withincode(void C.bar(..)) && !execution(void C.bar(..)) && cflow(withincode(void C.foo(..))));
メソッドの移動:
C.foo から D.foo に移動した場合，target や this を変更する必要がある．pointcut x(C c): execution(void *.foo()) && this(c) → pointcut new_x(C c): execution(void *.foo()) && this(c);pointcut new_y(D d): execution(void D.foo()) && this(d);
アドバイスの抽出(Extract Advice):
this, target, args, などを使って元のメソッドを厳密に指定する．また，advice 自体は around を使って，メソッドの実装をコピーして，元のメソッドに残した部分だけをproceed に変えて，なるべく元の制御構造を維持するようにすると簡単．
Introduction の抽出(Extract Introduction):
こっちは，普通にメソッド定義をコピーし，頭に型名をつけるだけでよい．
Pointcut の分解 (Separate Pointcut):
pointcut 定義の共通部分だけをくくりだして別の pointcut にする．
で，この人たちは，Aspect-aware なリファクタリングをするためのツールを Eclipse プラグインとして作ったらしい．
主に名前と型情報関係だけで，cflow などは（実際に呼ばれるコンテキストが変わらない限り）影響を受けないので気にしなくてよいらしい．
_ 論文 ▲
Pascal Costanza:Dynamically Scoped Functions as the Essence of AOP
を読んでみた．Lexical Scope （定義位置に依存して変数の binding が決まる）と Dynamic Scope （実行時点に依存して変数の binding が決まる）の違いをCommon Lisp 的記述を使って説明している．
で，アスペクトの役割をdflet という述語を使ってdflet (関数などの再定義) (評価したい関数)という形で書いている．「評価したい関数」というのが変換元のプログラムのことで，「関数などの再定義」 がアドバイスに相当し，「評価したい関数」の中で呼んでいる関数を実行時バインディングで置き換える．
「関数などの再定義」をする dflet をどこに配置するかというのが，Pointcut の役割をしている．
「特定のポイントで関数のバインディングを変える」とみなすか「イベントに連動してまったく処理を行う」と考えるか，という違いのような気がするけれど，関数のバインディングと制限してるほうがちょっと範囲が狭くて，それで十分な範囲をカバーしているのか謎．
_ 論文 ▲
aosd-discuss で，次の記事のことが話題に上がっていた．
Pascal Costanza:Dynamically Scoped Functions as the Essence of AOPACM SIGPLAN Notices,Volume 38 , Issue 8, pp.29-36 (August 2003)http://portal.acm.org/citation.cfm?doid=944579.944587
この記事に対して，Kiczales が，「cflow を dynamically scoped functionとしてとらえるにしても，AOP はそれだけじゃないでしょ，たとえばメソッド呼び出し以外の join points だってあるんだから，云々」と言ってた．ということで，後で読んでみることにする．
