«前月 最新 翌月» 追記

netail.net

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

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


2003-10-01 古い日記からの変換データ [長年日記]

_ 論文

GPCE2003 その2.

Mariano Cilia, Michael Haupt, Mira Mezini, Alejandro Buchmann:The Convergence of AOP and Active Databases:Towards Reactive Middleware

active database における Event-Condition-Action (特定のイベントに対して条件をテストし,対応するアクションを取るようなデータベース)は AOP に類似しているメカニズムである.しかし,双方で使っている Terminology はまったく異なっている.

対象プログラムを書き換える(invasiveness)度合いについて,active database は non-invasive,AOP は invasive (AspectJ), non-invasive (初期のPROSE, JPDA), Aspect-aware runtime environment (AspectS),などと分類している.

この作者たちは,Active Database と AOP の間のミドルウェアとして Aspect-Oriented Run-Time Architecture というのを作りたいらしい.それ自体はともかく,色々な AOP と Active Database がまとめられているので参考文献として良いかも.active database 知らない人も多いだろうから,個人的には貢献度は高いと思う.

_ 論文

GPCE 2003 の論文読み.といっても,Proceedings が LNCS で PDF が取れなかったので筆者が PDF を配ってた二本だけ読む.

Jeff Gray, Ted Bapty, Sandeep Neema, Douglas C. Schmidt, Aniruddha Gokhale, Balachandran Natarajan:"An Approach for Supporting Aspect-Oriented Domain Modeling"2nd International Conference on Generative Programming and Component Engineering (GPCE2003),

モデル+制約言語から,制約付きモデルを導出する.Join Point としてモデル内のノード,Pointcut Designator として宣言的記述(モデル内の位置を指定する),アドバイスとして「concern に関わっているよー」という strategy あるいは heuristic の情報が埋め込まれる.コードジェネレータと組み合わせて(C++限定だが)Strategy に対応したコードを生成する.

モデル自体は general で,domain-specific な weaver を使うというアイディアらしい.weaver 作る手間が高そうだ.

_ 論文

Pascal Costanza:Dynamically Scoped Functions as the Essence of AOPについての議論が続いてる.

AspectJ の pointcut の考え方では,cflow を使って「呼び出しの上のほう」と「下のほう」のそれぞれ独立に定義されたイベント間を接続できるが,dynamically scoped な考え方では「"real" cflow ではなく "predicted" cflow を対象にしている」という主張が出ている.

……まだ議論は続きそう.Kiczales が Non-Invasiveness (Obliviousness) は重要だ,というのを繰り返してるところを見ると,そこが AspectJ の設計時のキーだったらしい.


2003-10-02 古い日記からの変換データ [長年日記]

_ AspectJ

AspectJ 1.2 に向けてどうしよう,という話が進んでいる様子.スケーラビリティ,パフォーマンス問題,再利用可能なアスペクトを書くための方法,なんかが重視されてるみたい.

「ほしい機能リスト」には,"静的に実行可能なアドバイス" とかも入ってた.どうなることやら.

_ Ys6

「Ys6~ナピシュテムの匣」クリア.以前に比べると,意外と簡単だった.ストーリーは王道というかパターンというか,だけどアクション性が上がってたのが嬉しい.

# マスクオブアイズのかわりの品物でしか見つからないアイテムがあるのはどうかと思ったけど.アイテム欄が全部埋まらなかった(2個くらい空いてた)のも少し気になる.

_ お食事

サークルを引退した人と飲みに行く.和ダイニング ひいきや.http://r.gnavi.co.jp/k025913/menu1.htm

創作料理がわりと美味しいし,お酒の種類も多くてけっこう面白かった.3人で10000円で,食べ物も酒もわりと満足.たくさん食べる人だともう少しかかるかな?というところ.


2003-10-03 古い日記からの変換データ [長年日記]

_

NEXTSTEP プログラミングをサークルのOBな人に譲渡.お金をもらう代わりに貸し一つ.

_ 論文

Hidehiko Masuhara and Kazunori Kawauchi:Dataflow Pointcut in Aspect-Oriented Programming,In Proceedings of The First Asian Symposium on Programming Languages and Systems (APLAS'03), November 2003, to appearを読む.dflow pointcut は,どの変数を経由してきたかを示すように変数に "タグ付け" して後でそのタグがあるかどうかをチェックする,という形で書かれていた.「C.foo の戻り値由来の値が D.bar に届いたとき」なんてのが書けるようになる.これは,cflow では表現できない世界なので今まで HashMap とかを使って自前で実装していた部分が不要になって便利そう.ただ,言語仕様としても,実装方法としても,利用方法にも,まだまだ研究の余地は多分にありそう.

ライブラリなど,外部でのデータやり取りを抽象化する declare propagate は便利だなーと思う.解析系の人々の作業も多少は楽になるし.(たとえば,ある関数の戻り値がある関数の引数に 依存していることを明示できる)ライブラリとかを書く人は手間が増えて大変だけど,データフロー解析して propagate の宣言を自動生成とかすれば解決できそう.ステートフルな外部オブジェクトの扱いが難しそうではある.

とりあえず refer する予定リストに追加.


2003-10-04 古い日記からの変換データ [長年日記]

_ IEEE

IEEE Computer Society の値段を調べてたら,$160 (IPSJ会員なら1割引で $144) だった.Digital Library 利用したければさらに $109 と,なかなか微妙.ACM は論文などが portal.acm.org で無料で取れるので取るなら IEEE アカウントのような気もするのだが.とりあえず,学生の間はあまり取る必要もなさそうなので見送ることにする.

_ EUC

文字コード自動判別による文字化けを防ぐには第2バイトが 0xfd, 0xfe の文字をページの先頭近くに置いとけばよい,というので調べてみたら,

往時, 応用理工 (応と理), 享保の改革 (享と改),雀の往来,麦の屑,線の幅,方向,入口,収入,向こう傷,増刷 などといったキーワードがいけるらしい.

元々は "美乳効果" で検索するといい,と教えてもらったのだが,サイトは消えていた.響きが悪いせいか.

_ アクセス解析

なぜか文字化けすると思ってたら,Shift_JIS エンコーディング設定になっていた.META タグを EUC に修正.


2003-10-06 古い日記からの変換データ [長年日記]

_ EJB

コンポーネントの precondition や postcondition のことを考えながら EJB のことを調べていたのだが,EJB では synchronized キーワードやスレッド生成を禁止してコンテナが全部管理するということになっているらしい.同時性制御に関しては,セッション Bean ,エンティティ Bean はデフォルトではリエントラントではない(あるトランザクションコンテキスト内部で マルチスレッドなアクセスをしてくる可能性と 区別できないため).そのため,コンポーネント間のループバックは禁止されている.ループバック禁止がプログラムに与える制約はどの程度だろう?

メッセージ駆動型 Bean は,複数インスタンスを生成することで複数メッセージを同時に並行して処理するらしい.


2003-10-08 古い日記からの変換データ [長年日記]

_ 論文

The Concept of Dynamic AnalysisESEC/FSE 99, Thomas Ball

頻繁に動作している部分とそうでない部分を明示することでプログラムの分解に役立てる Frequency Spectrum Analysis とテストケースごとにどのあたりが実行されるかを見ることでカバレッジ向上を行う Coverage Concept Analysis を提案している論文.

Introduction での静的解析と動的解析の比較を行っていて,静的解析はプログラムが特定の性質を持つかどうかを判定できるが,動的解析は特定の性質の違反を検出することができる.動的解析は「入力に注目した解析」で静的解析は「プログラムに注目した解析」だとしている.また,これらは,完全性,スコープ,正確性の違いだとしている.

完全性において,動的解析はプログラムを十分な回数を実行する必要があり,静的解析ではありえない実行系列などを排除する必要がある.

スコープについて,静的解析はプログラム中の位置による制約を受けやすい.特に遠距離(異なるモジュール,時間的距離)の依存関係を解析するのは非効率的である場合もある.

正確性については,静的解析は解析を終わらせるために情報の抽象化(ある種の情報損失)が必要となる.動的解析では,プログラム実行のうち必要なドメインにのみ注目することでコストを削減することが容易である.

_ 論文

久々にプログラムスライス関係の論文を読む.

Paolo Tonella:Using a Concept Lattice of Decomposition Slices for Program Understanding and Impact Analysis,IEEE Transactions on Software Engineering, Vol.29, No.6, pp.495-509, June (2003)

ある変数に対する計算処理を Decomposition Slice と呼ぶが,Decomposition Slice Graph ではなく Lattice として構造化し複数の変数で共通した計算部分をくくりだす.

影響波及解析自体は,Lattice を使ってチェックされる.ただの Forward Slice と違い,影響を受ける文だけでなく,何の計算に影響を与えるかを示せる点らしい.ちょっと怪しい気もするが.文を「計算」という単位にグループ化できることがLattice の強みらしい.

共有されている部分が Decomposition Slice でない場合(たまたま同一の制御構造などを共有している場合)を,弱い干渉 (Weak Interference) と定義して実験している点が興味深いと言えなくはない.

静的解析で,どこまで正確に解析できるかとか,その解析コストがどの程度か,とかいうあたりの議論がないような気はするが,それにしても,Concept Lattice をちゃんと使っている論文は珍しい.


2003-10-09 古い日記からの変換データ [長年日記]

_ 論文

Stephan Herrmann:Object Teams: Improving Modularityfor Crosscutting CollaborationsNet.Object Days 2002

を読んだ.Object Team というモジュール単位を導入している.Aspectual Collaboration に近い概念(?)で,Team class 側は「こんな参加者がいるよー」と宣言して,個々のクラス側は「私は Subscriber 役をやります,メソッド xxx は私のこのメソッドに delegate してね」と宣言する.依存関係が AOP の場合と逆.

で,クラス側が「この Team を active にしてブロックを実行」というようにコントロールできるみたいではある.登場人物となるオブジェクトが全員揃った状態でオブジェクト間の関係を明示しながらプログラムを書くことになりそうなので,1:n あるいは m:n のオブジェクト対応をどう扱うのか,とかちょっと気になる.

個人的には,アスペクトと併用してTeam オブジェクト記述→ Team に参加するオブジェクト記述→ オブジェクト間のルールをアスペクトで記述なんてやってみたい.

アプローチ自体は嫌いじゃないのだけど,プログラム言語を作ったことで,どのくらい複雑さが低減できるのか,とか抽象度が高い記述が可能なのか,とか色々議論する余地は多そう.

すべての振る舞いを Object Team で書いたらどうなるか,っていうのを見てみたいところ.

_ 論文

以前読んだ論文の読み直し.Behavioral Specification and Analysis of Object-Oriented Designs (1997)Boumediene Belkhouche, Joel WuJournal of Object-Oriented Programming

Object Oriented Design Language (OODL) という形式記述言語とその検証系を説明した論文.オブジェクトがやり取りするメッセージやそれに伴う状態遷移を記述して,オブジェクト間の依存関係の循環や,結合度,client/server 関係といったものを調べる.しかし,ソースコードとの対応関係の確認はできない.


2003-10-10 古い日記からの変換データ [長年日記]

_ AspectJ

例外処理の話を追加.それにしても,アスペクトが投げる例外くらいオブジェクト側は無視してくれればいいのに……と思う.

catch (Throwable) などで後処理を行ってからthrow し直している場合,例外ハンドラに引っかからないとそれはそれで問題になる(後処理に失敗する恐れがある)ので困ったものではあるが.

結局,例外の制御フローがオブジェクト上の制御フローに直接載ってしまう時点でダメなんだろうか.


2003-10-11 古い日記からの変換データ [長年日記]

_ Delphi

久々に Delphi でコーディング.スケジューラ(カレンダー式)でURL をハイパーリンクできるものが見つからなかったのでとりあえず適当に自作してみる.

string → NUL (#0) で終わる文字列へのポインタ,の変換がPChar(str) というキャスト演算であることには未だに慣れない.


2003-10-13 古い日記からの変換データ [長年日記]

_ 読書

ダイアナ・マーセラス「シャーリアの魔女(1) 海より生まれし娘」(上・下),ハヤカワ文庫,を読了.

前田珠子が推薦文書いてたので読んでみた.(といっても前田珠子の作品は "堕神綺譚" くらいしかちゃんと読んでないけど)

魔女として狩られた一族の女性と狩る側の立場の伯爵の関係がメインな,ある意味お約束な展開だけど,悪くない.続編が出たら買って読みたいところ.


2003-10-15 古い日記からの変換データ [長年日記]

_ Neverbird

JBoss を広めようとしている Neverbird の人からもAOP のキーワードでリンクされていたことに気付いた.developerWorks や OO シンポに関する記事と同列.でも「その他」かぁ.

Neverbird の人々,かなり情報収集量が多い.参考にさせてもらいつつ,もうちょっと頑張ろう.http://neverbird.sourceforge.jp/

_ カレンダー

スケジューラというほうが正しいのかなぁ.ある程度,形になってきたのでいちおう公開してみる.hyCalendar 公開ページ

_ Delphi

Delphi から Windows API を叩くための資料を探していて,サイトを発見.ソースコードを積極的に掲載しているので,すぐ使える断片が手に入って嬉しい.http://halbow.cool.ne.jp/top.html

_ 祝日

スケジューラ作るのに祝日をどうやって計算しよう,と思っていたら,ちゃんと祝日情報をまとめて,しかも Excel のアドインにして公開している人がいた.まったくありがたい.http://www.h3.dion.ne.jp/~sakatsu/ktfunc_0701.htm

_ AOP

論文の添削をネイティブの方にお願いしたら,"Advice" って変な使い方してるけど,なぜ? と聞かれた.

日本人にとってもよく分からない使い方だけど,advice は複数形にはならないので感覚的に合わないらしい.


2003-10-17 古い日記からの変換データ [長年日記]

_ 論文

Nevin Heintze, Jon G. Riecke:The SLam Calculus: Programming with Secrecy and Integrity

情報流(Information Flow)解析の論文.Direct Read, Indirect Read というのを区別して,変数ごとの,いわゆるセキュリティクラスをどうやって求めていくかを示している.

今のところ厳密な情報流解析は使わないのだけど,使うことになったらこのあたりを参考にすることになるかもしれない.

_ ドレスコード

ドレスコードの見本(?) http://www.venus-cruise.co.jp/dress.html

"フォーマル" な場所は行く機会なさそうだ.

_ クイズ

ウィルス関連の雑学?クイズ.http://itpro.nikkeibp.co.jp/free/ITPro/ITBASIC/20031015/1/

ウィルスの名前なんて興味がないから苦戦したが,Q.6, 7, 9, 10 だけは何とか正解.40点で低いなー,と思っていたら平均は27点.88人中8位だった.


2003-10-20 古い日記からの変換データ [長年日記]

_ カレンダー

微妙な表示バグをいくつか直した.hyCalendar 0.3.2 になってしまった.

_ Calendar

hyCalendar (仮) 0.3.0 公開してみる.ようやくクリップボードに対応.hyCalendar 公開ページ


2003-10-21 古い日記からの変換データ [長年日記]

_ アクセス

アクセス解析の結果から,至近 1000 件のアクセスのうち約1割の 99件 が *.fit.ac.jp から.趙先生が一人で叩いてるとは思えないので,誰か学生とかで興味持ってる人がいるんだろうか…….

_ AOSD

"Dynamically Scoped Function" を書いたPascal Costanza が aosd-discuss に投稿していて,Join points という名前はないがプログラムを変換するフレームワークはすでにあったから,Join points というのが AOP の貢献というわけではない.

構文木上のある範囲を超えて作用することができる(Lexical Scope ならマクロがあるが, 副作用などの問題もある上に Lexical Scope は超えられない)ところこそが AOP の良いところなのではないだろうか,と言っていた.

プログラム実行中のイベント(Join points)をFirst class に持ってきたところ,も貢献であるような気はするけど,どうなんだろう.

_ Calendar

hyCalendar (仮) 0.3.3 リリース.クリップボード扱いで,一箇所 CopyToClipboard を呼ぶはずが PasteFromClipboard を呼んでいたバグを修正.っちうか大ぼけ.

_ AspectJ

カウンタ設置から約1年で,結局カウンタは5500程度.平均すると15アクセス/日.実際には10アクセス/日くらいだったものがだんだん増えてるのだが.


2003-10-22 古い日記からの変換データ [長年日記]

_ Calendar

hyCalendar 0.3.5 リリース.そろそろ公開してもいいのだが,アイコンがないので微妙.誰か描いてくれないかなー.

_ AOSD2004

論文を投稿した.結果は12月22日に帰ってくるらしい.

_ Java

Sun の Java Tips,今月は新旧(Java2 / 1.1)二つのコレクションの扱いだった.

古いのから新しいのに移行するのはVector が List を実装するので簡単だが,古いほうへ移動する場合,Collections.enumeration を使うとEnumeration を作れるらしい.


2003-10-23 古い日記からの変換データ [長年日記]

_ 食事

阪急梅田駅茶屋町口近くにある「麹」という店に行ってきた.http://r.gnavi.co.jp/k160126/

焼酎が各種.どこかで焼酎がブームという話を聞いたのを思い出した.和食系の,つまみにふさわしいものが多かったのだが酒飲めないメンバーでも,料理がけっこう面白いので満足.

_ Calendar

hyCalendar 0.4.0 リリース.日付のリンク先の内容がポップアップで表示されるようになった.あとは,こまごました変更.README を書くのが意外と大変だった.


2003-10-24 古い日記からの変換データ [長年日記]

_ 論文

Kasper B. Graversen and Kasper {\O}sterbye:Implementation of a Role Language for Object-Specific Dynamic Separation of Concerns,AOSD '03 Workshop ``SPLAT''を読んだ.

"Role" を動的にオブジェクトに貼り付けてメソッド定義などを置き換えるDelegation Layer, JAC 系のアプローチ.Role 間は,継承関係がない場合は完全に独立.貼り付けられた複数の Role は相互に影響を与えない.super や self 同様,貼り付けられた対象を示すintrinsic という参照を使うらしい.

たまたま継承オブジェクトと貼り付けられたロールが同じ名前のメソッドを追加していたら名前の上書きが起こるみたいだけど,そのあたりはあまり本質的ではないので置いておくとして,どのロールとして参照されているかによってオブジェクトの振る舞いが変わることになる.この点はとても面白い.そのかわり,オブジェクトを管理する側は大変そう.

この論文の筆者らは,このChameleon モデルについて他にも論文を書いている様子.

_ 論文

オブジェクト間の制約とかを書いたり解決できたりするのかなーとちょっと期待して Constraint Programming 関係の文献をあさってみたが,結局,Object-Oriented Constraint Programming とか言ってる人が少し関連していることをしているように見えるけれど実は整理される対象がオブジェクトなだけ?で制約を一般的なプログラム上で使うのはしんどそう.

せっかく読んだので論文名だけメモ.Samir Ouis, Narendra Jussien and Patrice Boizumault:k-relevant explanations for constraint programming

_ 論文

R\acute{e}mi Douence and Narendra Jussien:Non-intrusive constraint solver enhancements

単純な Constraint Solver +アスペクトで拡張していこうというショートペーパー.バックトラックなどをアスペクトとして実装することで拡張性なんかを確保できる……のかな?

_ 論文

オブジェクト制約言語に関して色々調べてみる.

中島 震:制約伝播機構を内蔵するオブジェクト指向言語: COOL. 情報処理学会論文誌 Vol.30, No.1, January (1989).

オブジェクトの状態が変化したら命題を評価してその命題に依存した他の命題を評価して,……というようにたとえば回路の入力ピンの値が1箇所変化したら順番にそれを伝播させていく,というような制約記述を Lisp ベースで導入している.矛盾解消機構を持っていて,命題の出力が処理キューに並んでいる命題値と矛盾した場合に勝手にその基となった命題を削除して解消したりするみたい.勝手に制約が置き換えられていくことになるので本当に動くのかなぁ,と不思議.

Hon Wai Chun:A Methodology for Object-Oriented Constraint ProgrammingAPSEC 97, P.116ILOG を使って分析を行い,UML のクラス図などの上で制約を記述し,ILOG 記述に落としていくという話.

C++ プログラム上でどう使っていくか,みたいな話っぽいのだが,オブジェクト間の制約が,必要なオブジェクトが一式揃う前から適用されてしまうような気がするのだけど初期化タイミングなんかではどう扱うんだろう.コンストラクタがすごく頑張るんだろうか…….

_ 論文

OOPSLA 2003 間近ということで ML に流れてきた論文.Jim Hugunin: The Next Steps For Aspect-Oriented Programming Languages(in Java)

今後の研究の方向性について述べた Position Paper.

(1) 適切な分割コンパイル,静的なチェック(declare errorなど)とロード時 weave との扱いなどに関する問題

(2) Pointcut の表現範囲 -- たとえば dataflow の拡張

(3) 特定ドメインに対応したアスペクト,再利用可能なアスペクトライブラリの構築

(4) 拡張可能なコンパイラなど,様々な開発ツールといったところ.

確かに,そのくらいの方向性だという気はする.(1) と (4), (2) と (3) は相互に絡んでいくんだろうか…….

_ Norton

Norton Internet Security 2004 へのアップグレードパッケージは 5300円.ダウンロード版(新規ライセンス)は 5500円.これならダウンロード販売で買ったほうが200円上乗せでパッケージ届くのを待つ手間がないのなら楽だなぁと思ってしまう.

_ Calendar

hyCalendar 0.4.2 リリース.バグ修正.そろそろ history.txt を準備したほうがよさげ.

_ Calendar

hyCalendar 0.4.1 リリース.ただのバグフィクス.

0.4.0 でセルの内容をポップアップ表示するようにしてみたのだが,ポップアップが必要ない場所でもポップアップが出てしまうのを抑える方向で 0.4.2 を準備中.


2003-10-25 古い日記からの変換データ [長年日記]

_ Calendar

hyCalendar 0.4.3 リリース.とりあえず仮(?)のアイコンを作ってもらえたのでVector で公開を試みることにする.# 3人くらいの人に言われた

_ Delphi

今日のはまり.

Canvas.Font への代入は参照のコピーではなくAssign だったことに気づかずに

f = Canvas.Font;Canvas.Font := x;

// do something

Canvas.Font := f;

とかやっていた.f は Canvas.Font の参照なので,Canvas.Font := f; は意味を持たない.とほほー.


2003-10-26 古い日記からの変換データ [長年日記]

_ 論文

Curtis Clifton and Gary T. Leavens:Obliviousness, Modular Reasoning, andthe Behavioral Subtyping Analogy

これも出典はSPLAT2003.アスペクトが勝手にクラスを置き換えてBehavioral Subtyping を破壊することがあり,しかもクラスはこれに気づくことがない.(これはAspectJ の obliviousness であるという特徴)

しかし,実際には,それではプログラマは「1モジュールずつ理解する」ということができないので,このような Behavioral Subtyping を破壊するようなアスペクトについては "Assistants" と呼んで別扱いし,(破壊しないものは "Spectators" と呼ぶ)Assistants については明示的に取り扱いません?という論文.これ,出典は忘れたが前に同じ著者がどこかで出していた論文(or テクニカルレポート)と内容的には同じ.今後は Assistants を接続するような言語を作ったりしようか,とか言っている.

参考文献としてFilman and Friedman, Aspect-oriented programming is quantification and obliviousness (OOPSLA2000) を挙げている.http://ic.arc.nasa.gov/~filman/text/oif/aop-is.pdf

_ 論文

SPLAT2003 Workshop の論文を読む.Therapon Skotiniotis, Karl Lieberherr, David H. Lorenz:Aspect Instances and their Interactions

6ページ弱のショートペーパー.アスペクトを記述するときに,「あるクラスのインスタンスのみ」を指定しようとすると!call((Circle+ && !Circle).*) && call(Circle.*) といった記述になる.また,if(thisJoinPoint.getTarget().getName() == ...)といった式や aspectOf をうまく使おう,というテクニック紹介みたいな論文.

アスペクトのインスタンスを生成したり特定のオブジェクトに install したりするAspectS の設計は良さげだと思える,らしい.Dynamic Aspect なほうが柔軟なアスペクトの管理ができていいなぁ,ということなのかな?

_ hyCalendar

期間予定のフォント設定機能を追加して,0.4.4 リリース.TODO リストの中身も一時期に比べると少なくなってきた.

それにしても,部室は学祭関連のプログラム構築で忙しい中関係ないプログラムを書いてるのも,ある意味申し訳ない気がする.それでも書くんだけど.


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 としては,コールスタックのサイズであるとか,例外の発生や特定の実行パターンがある.

_ クレジット

426USD の謎の請求.IWPSE は EUR で払ったはずだし……?でもどこかで見覚えがある,とひたすら研究室に置いた請求書やらの山を調べていたら,その正体は IWPSE の Reprint Order だった.うーむ.請求団体名の後ろに一言くらい添えられるような空間を用意しておいてほしい…….

_ Ruby

サーバーの Ruby が 1.8 になったとたん,コンパイラの微妙な変化でエラーで落ちるようになってしまっていた.とりあえず式展開中のダブルクォートが怒られるようになったことが原因のようなのでそれだけ直した.


2003-10-28 古い日記からの変換データ [長年日記]

_ Calendar

ひっそりと hyCalendar 0.4.5 リリース.ちょっと描画部分を直しただけ.

_ ReaD

日本科学技術振興機構から調査票が届いた.実は誰がどこの所属とか全部管理されているらしい.http://read.jst.go.jp/

このサイト,技術系英語辞書を強化した機械翻訳とかも付いてる.どのくらい強いのかは知らないが.


2003-10-30 古い日記からの変換データ [長年日記]

_ MERP

Web に公開していた情報をたぐって,Mr. Duckworth という人からメールをもらった.「MERP を日本でも遊んでる人がいるのね.もしよかったら東京近辺で遊ぶような人いないっすか」という感じ.で「とりあえず,そういう知り合いがいそうな人に転送しといたよ」と返事をしたら,「ありがとう.機会があれば色々話をしてみたい」とか返事が返ってきた.うーむ.

_ 学祭

微妙に働いている人を手伝う.1年生でまじめにびしびしと仕切ってくれる人がいるのは頼もしい限りだけど,負荷をもう少し分散しないと効率が悪そげ.

_ バトルテック

久しぶりに遊んだはいいけど,やっぱり細かいところでルールをいくつか間違えていることが判明.

ルールをもうちょっと整理したレジュメ作ろうかなぁ.初級/中級/上級ルールに分解されていて微妙に参照しにくい.徐々に拡張されていく様子はクラスの継承に近い気もするが,順番に学習していく場合はいいけどいきなり上級ルールに取り込まれている「射撃ルール」というアスペクトを把握したい場合は使いにくい??

_ Vector

hyCalendar の登録申請をした.


2003-10-31 古い日記からの変換データ [長年日記]

_ IPADIC

OUCC の学祭で使う文章合成用に名詞・形容詞・副詞などをipadic から抜き出す.正規表現は適当に書いた

[^(]*\([^(]*\([^(]*\([^(]*\([^(]*\(([^ ]+)

とかいうのを使って取り出してみた.一部,それでは抜き出せないようだが,だいたい通ったのでよしとする.

# 本当は働き手のはずの3年生がいないのでけっこう大変そうではあるが.

_ AspectJ

Prof. Laurie Hendren から,AspectJ のベンチマークとしてツールを使ってみたいんだけどだめかな?という連絡が来た.

オックスフォードって ox.ac.uk なんだなーと感心しつつ返事は保留.