netail.net

_ [Java] Primitive Collections for Java (PCJ) ▲

int や long を格納できるコンテナクラス群 PCJ のページを 1.0 beta 以来久しぶりに見に行ってみたら，最近はあまり更新されていないみたいだった．

int リストの各要素に対する処理は IntIterator などの Iterator を拡張したクラスを使うので，Iterable（for文の新しい形式）をはサポートしてくれていない．サポートしてても int から Integer への boxing → unboxing という激しいオーバーヘッドが出そう．

あんまり更新されてない分，違うバージョンを使ってしまって不整合を起こすとかいうこともないので，嬉しいといえば嬉しい．

_ [hyCalendar] カレンダーのタブの保存 ▲

１ヶ月単位で作っているタブの表示は保存できないのか（４ヶ月先とかの予定を記入した後は，アプリ再起動しても表示しっぱなしにできないか）という質問が届いてたので，できませんと返事を出した．

何か対応はしたほうが便利になってよさそうな気はするが，前の月のタブは自動で閉じてほしかったりするので，ちゃんとしたルールの決定が難しそう．

_ 支店番号の変更 ▲

銀行の支店番号が変わって新しいカードが到着．豊中郵便局まで自転車で取りに行ってきた．片道約20分．

_ [論文] コードの使い方の例を見つける ▲

Reid Holmes and Gail C. Murphy: Using Structural Context to Recommend Source Code Examples.

Proceedings of International Conference on Software Engineering 2005, pp.117-125, May 2005.

フレームワークなどを使うときには開発者が適切な順番でクラスのインスタンス化や準備用メソッドの呼び出しを行う必要があるが，それを調べるのはけっこう大変なので，自動でコード片を探してこようというもの．

基本的には，開発者が書きかけのコード片から，使っているクラスやメソッド名を取ってきて，リポジトリ内にあるメソッドが使っているクラスやメソッドとマッチを行うというもの．"Structural Context"という響きにちょっと期待したのだけど，特別なものではなかった．

呼び出す相手のクラスやメソッドは分かっていても，そのインスタンスをどこからもらってくるといいのか分からないときなどに使える．

Eclipse を実験相手にして，与えたタスクは一通り実現されたらしいが，適切な例が見つからないものもあった．ただ，それがマッチさせる基準の問題なのか，そもそも例がなかったのかは不明とのこと．

動機の部分（フレームワークを，ドキュメントなどをもとに正しく使うのはけっこう大変というあたり）は別のところで使いそう．

_ [論文] 動的なロールのバインディング ▲

Tetsuo Tamai, Naoyasu Ubayashi, Ryoichi Ichiyama: An Adaptive Object Model with Dynamic Role Binding.

Proceedings of International Conference on Software Engineering 2005, pp.166-175, May 2005.

複数のオブジェクトが相互作用するための "Context" というオブジェクトを作って，Context の中に定義された各 Role に対してインスタンスを割り付けると，Role に定義されているメソッドが使えるようになるというもの．

メソッド名のバインディングや，Role を担当するインタフェースへの require などの要素もあるので，一般的なアスペクトの逆で「オブジェクトから明示的にバインドされて使われるアスペクト」として，しっかり作られたモデルという印象．

コンテキストのインスタンス数がコントロール可能で，インスタンスごとにバインディングの設定が可能で，クラス側ではなくコンテキスト側の再利用が容易となっている（AspectJ や Caesar のように抽象アスペクトと具象アスペクトを区別しなくてよい）．ちょっとコーディング上の工夫をすれば，Association Aspect でやりたいと思った Role の１対Ｎ関係などの管理なんかもできるかも？

_ [hyCalendar]六曜表示モジュール ▲

六曜計算ライブラリの再配布の許諾がいただけたので，セットでの配布開始．

_ [AspectJ] AspectJのよいところ？ ▲

普通，プログラムとして，「やりたいこと」を書くけれど，AspectJ の declare warning/error みたいに「やってはいけないこと」も一緒に書けるので，特定の concern に限定した（他の開発者には触れてほしくない）メソッドの呼び出しを禁止するとかいった使い方ができて，実はけっこう嬉しい気がするこの頃．

単に設計が悪い可能性も否定できないし，AspectJ の declare error よりは Hyper/J 系を使えという話かもしれないけど．

カスタマイズ可能なコーディングルールチェッカでいいじゃん，とか言われそうだけれど，アプリケーション依存なことがいっぱい含まれているので，ツールの一部というよりはプログラムの一部であるべきという気はする．

_ [論文] Modular Reasoning な話 ▲

G. Kiczales, M. Mezini: Aspect-Oriented Programming and Modular Reasoning.

Proceedings of International Conference on Software Engineering 2005, pp.49-58, May, 2005.

コードが modular であるとは，一箇所にまとめて書かれていて，他のシステムとどのようにインタラクションを起こすかのインタフェースがあって，インタフェースの整合性がチェックできて，他のモジュールと接続することができるとき．また，Modular Reasoning とは，そのモジュールに関する決定が，他のモジュールを見なくてもできるようにすること．

過去の研究では，クラス側をBlack-Boxとみなせるようにアスペクトの影響力を抑えたり，アスペクトについての言及をクラス側で行うというのが多いが，こちらは AspectJ などのフルセットをきちんと扱いたいというもの．

アスペクトのインタフェースをどう規定するとうれしいか，というのがメインの話題で，アスペクトのインタフェースの中には，アドバイスやポイントカットの宣言と，それがどこで動くのかというクラスのメソッドのリストなども含めている．ただし，executionポイントカットならメソッド名だけでいいが，callやget, setについては join point shadow を含んだメソッドをリストするという程度で，良いアイディアは今のところないらしい．

PointクラスとLineクラスの座標移動時のDisplayUpdatingに関するアスペクトの例を用いて，Non-AOPとAOPについてのReasoningの作業の違いを簡単に説明している．DisplayのUpdateが，オブジェクトが移動した後にただ１度だけ起きることを理解して，それを守った形でコードを変更するには，そのルールについてのドキュメントにたどり着くという作業と，DisplayUpdateを起こすタイミングを知る必要がある．Non-AOPとAOPで，ドキュメントを調べる作業までは同じだが，DisplayUpdatingの振る舞いを調べるのは，Non-AOPの実装では全体を読んでいく必要があり，AOP実装だと簡単に知ることができると述べている．

_ [論文]仮定の記述をアーキテクチャの図に含める ▲

P. Lago, H. van Vliet: Explicit Assumptions Enrich Architectural Models.

Proceedings of International Conferenc on Software Engineering 2005, pp.206-214, May 2005.

ほとんど図だけの拾い読み．

変化するものを管理するのと同様に，変化しないもの，システムに対する様々な仮定（技術的・管理上など）もきちんと扱いましょうというものらしい．アーキテクチャの図（Feature Model とかクラスより抽象度の高い図）で，仮定を表現した assumption という要素を配置して，どのfeatureに影響を与えているか F-Impacts 辺を作って示す．また，featureを実装する役割の要素（featureからリンクされている要素の一部）からは，assumption に対して Realize 辺を引くといった感じ．

最終的には，作ったアーキテクチャから，実際のモジュールへの対応を追いかけていくと，assumption が変化したときへの応対などが楽になりそうではある．traceability が確立されてないといけないから，MDAとか好きな人にはよいのかも．

_ [hyCalendar] 1.1.1 リリース ▲

調べてる間にさらにバグを見つけたので，それも直してリリース．六曜表示に必要なライブラリは，再配布に関する要件が書いてなかったので，作者の方に連絡を取ることにした．それまでは，作者の方のページへのリンクで対処．

_ [hyCalendar] towards 1.1.1 ▲

ポップアップウィンドウのサイズが毎回異なる問題を修正したついでに，期間予定のウィンドウ上での表示とポップアップ時で順序が違うことがある問題を修正した．

ついでに，六曜（友引とか仏滅とか）を表示する機構のプロトタイプを作ってみた．六曜の計算自体は，実装が正しいかどうか検証することが困難なので，外部ライブラリに頼りっきりにして，責任を切り離しておく．

_ [授業] ゼミ ▲

３人発表で，みんなUSBメモリを持ってきてた（１人はMP3プレーヤだったけど）．メディアとしては，フロッピーよりも一般的になってきた感がある．

来週は学科の各研究室の研究内容紹介らしいので研究室には来なくていいよーという告知を出して，あとはあんまり指摘することもなくあっさり終了．

今回登場した謎の訳語は，利害関係者の意味でのstakeholder → 弁護士．辞書の１つに，係争物保管人という意味の後ろに「（普通, 弁護士）」と書かれていた．そこから出てきたのかもしれないが．不思議．

_ ほうじ茶 ▲

研究室で余っていたほうじ茶450g（ちょっと賞味期限が近い）をもらった．OUCCの人でほしい人にあげようかと思うけれど，450gは普通のお茶缶に入らないのでどうしたものやら．

_ [論文] デザインパターンを使っても欠陥が入りにくくなったりはしないみたい ▲

Vokac, M.: Defect frequency and design patterns: an empirical study of industrial code.

IEEE Transactions on Software Engineering, Vol.30, No.12, pp.904-917, Dec. 2004.

ざくっと目を通しただけだが，デザインパターンは良い設計の再利用で，良い設計ならバグが入り込みにくいはず，本当にバグが少ないかどうか調べてみよう，という調査を行った論文．

対象システムは１つなので，さすがにあまり強い結果でもなく，デザインパターンによっても傾向が違って，実はあまり影響なさそう？ということが分かった，くらいか．

_ [Java][ツール] Eclipse Visual Editor で GUI デザイン ▲

JavaのGUIが作りたくなったのでつついてみる．インストールはHelp → Software Updates → Find and Install で，Eclipse公式サイトからVE，EMF，GEFをダウンロードするだけと非常に簡単．

パーツをパレットから選んで配置していくだけなので簡単っぽいのだが，privateとはいえ，コンポーネントを作成する getter メソッドがいっぱい生成されるのが気にかかる．実装が簡単にできるからこうなってるのかな？

プロパティセット系のメソッドをコンポーネント生成コード部分に書き込むと，直接画面に反映されて，けっこう面白い．

_ pukiwikiのプラグイン設定変更 ▲

XSS脆弱性とかのニュースを見つけたので，アスペクト指向の情報公開用に使っているpukiwikiのプラグインの設定を変更．

_ [論文] リファクタリング効果のCOCOMO IIでの予測 ▲

Robert Leitch, Eleni Stroulia: Assessing the Maintainability Benefits of Design Restructureing Using Dependency Analsyis.

Proceedings of METRICS 2003.

輪講で紹介された論文．

リファクタリングのコストが回収できるかどうかは，実施前後での保守コストの差がどれだけあるかで決まる．保守コスト＝回帰テストのコスト＝コードを変更したときに影響を受ける平均コード量＝各手続きからの影響波及解析を行ったときの行数の平均として見積もっている．

リファクタリングでどのようにコードが変更されるかは与えないといけないので，自動リファクタリングツールとの組み合わせが必要そうで，複雑なリファクタリングに適用することは難しそう．保守コストが回帰テストのコード量に比例するかどうかといった妥当性や，見積もった結果の妥当性については評価を行っていない．ただ，リファクタリングを行った場合か行わなかった場合のどちらかでしか実際には計測できないので，このあたり苦しいところではある．

_ [論文] Fragile Base Class Problem ▲

Leonid Mikhajlov and Emil Sekerinski: A Study of The Fragile Base Class Problems.

Proceedings of ECOOP 98.

親クラスと子クラスがあって，親クラスを変更したら子クラスに影響が及んでしまう問題(Fragile Base Class Problem)について述べた論文．

たとえば，Bag.addAll が Bag.add を内部的に使っていることを想定して，addメソッドで要素数をカウントする CountableBag を作ると，Bag.addAllが addメソッドを使わなくなったとき，CountableBagは正しく機能しなくなる．このような問題を色々分析して，問題を避けるために (1) ベースクラスの変更や，サブクラスは，メソッド依存関係に循環を導入しないこと，(2) 親クラス側を変更するとき，メソッドは，自身のほかのメソッドの振る舞いに余計な仮定を置かないこと．(3) 継承クラス側のメソッドは，親クラスの中で自分自身を呼び出しているとき，それを継承クラス側で受け取ろうとしないこと．(4) 継承クラスから，親クラスの内部状態を触らないこと，を挙げている．

で，上記のような問題がなく，親クラスと子クラスが安全に拡張できるような性質かどうかの判定を行う Flexibility Theorem というのを作っている．

_ [論文] Sublclassing Contract ▲

Clyde D. Ruby: Safely Creating Correct Subclasses without Seeing Superclass Code.

Proceedings of OOPSLA 2000.

OOPSLA2000の２ページのポジションペーパー．サブクラスからスーパークラスへの呼び出しを行っても安全かどうか，オーバーライドしなければならないメソッドがないか，といった情報をクラスの contract の一部に含めようという提案．