netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-07-12 古い日記からの変換データ [長年日記] ▲
_ LotR ▲
キャンペーンで色々わかったこと，その３．その他．
- レベルが高いキャラクターなら，武器スキルはほぼ確実に12（最大）まで成長させられて，かつ専門化されている可能性は高い．技能における戦闘力だけなら，どのキャラクターも簡単にナズグルなどと渡り合えるようになる．実際には，Intimidate に耐えられるかどうか， 呪文による攻撃に耐えられるかどうかというのがキーポイントとなるので，低レベルのキャラクターで戦うのが難しくなっている．
- 意外と Willpower が伸びないことも．
- 実は，Edgeのほうが成長が安価なので，Strong-willed や Tireless，Resolute などのほうが得だったりする（種族にも依存するが）．
- 交渉系技能は，GMの方針によってはほとんど使われない．
- Inspire, Intimidate は使いどころが難しい．
- 種族の能力は忘れられやすい．
- Renown は，有名な敵と戦って倒すと，一気に上がる．
_ LotR ▲
色々わかったことその２．戦闘関連．
- 飛び道具は命中しやすい．接近戦闘での使用を許可すると，どんどん当たる．威力は低いが，技能が高いと最大ダメージが連続になる．
- 「ラウンドの最初で行動を宣言」は運用が難しい．また，攻撃の達成値を決める前に防御か回避を宣言するのも難しい．防御はできそうもない攻撃を耐えるという選択肢がないため．
- 各行動順のときに行動を宣言するときは，先に４連続攻撃などをするキャラクターが現れたとき，防御側は「これは追加行動(-5ペナルティ)分で防御」などと宣言できるようにしておくべき．
- Bane-spell など，攻撃に修正が入るものについて，防御に対して修正が入るか不明瞭だが，入るとしておいたほうが安全．
- 多人数戦闘のときは，強いキャラクターなら圧倒的勝利可能．
- ただし，囲まれると追加防御行動の-5ペナルティが出てくるのでかわしきれない場合が多い．基本的に Health の削りあいになる．鎧や盾は重要．
- Sweep(2行動分)は，3体狙えない場合は，２体を別々に攻撃したほうが有効（何かルールを読み落としている？）．
_ LotR ▲
キャンペーン終了．原作設定を応用しつつ色々遊んだ感じ．色々分かったこと，その１，魔法関連．
- 魔法の威力は Bearing で上がる
- 魔法使いは Stamina を高くしたいので Vitality が上がる
- 呪文の＜集中＞の維持するのに必要な Wits 15 は まず成功しない
- 序盤は，Intimidate がやや強力すぎる感あり．Resist Fear がない状態のキャラクターに Evoke Fear すると Willpower が低いので，Disastrous Failure を起こしやすい．
- 魔法の状態（修得からの経過時間，２回の Superior Success）をトラッキングできないとダメ．書き込み用の別シートがほしいところ．
- Warrior's Heart，Tireless などを限界まで取ると，それなりに魔法を使える．
- 魔術師のほうが，戦士より Stamina が高くなる．
- 魔術師は，意外と Wisdom を使うタイミングが少ない．
- 攻撃魔法を使いたい場合は，Ranged Combat が重要．
- 攻撃魔法に対してアーマーが有効かどうか不明．（一般に，有効としたほうが安全そう）
- 支援系魔法は非常に強力．Bane-spell, Victory-spell を事前にかけておくのは重要．
- 「１分間以内の魔法」のカウントが意外と面倒．非戦闘時に，１分の準備時間の呪文をかけるときなど．
- 効果が発動中の呪文の個数のカウントと，両方が必要．これも分かりやすいカウント方法が必要そう．
_ PDA ▲
最近 mp3 プレーヤと化していた Genio e で，メールを読めるようにしてみた．メーラはnPOP．無線LAN 環境さえ整えれば，部室でのメール読みはすごく楽になる……かも？ノートＰＣ持ち歩きたくないときに使ってみることにする．
それにしても，データをSDカードに入れてコピーできるのでアプリケーションのインストールがすごく簡単でいいなぁ．
2003-07-11 古い日記からの変換データ [長年日記] ▲
_ ITCC ▲
輪講に出てきた論文の出典がInternational Conference on Information Technology: Coding and Computing という名前のわりに聞いたことがなかったので調べてみたら，マルチメディアデータの効率的な符号化・計算などが主な interest らしい．
_ Java ▲
Java から C# に乗り換えた10の理由，とかいう記事が載ってた．http://www.atmarkit.co.jp/fdotnet/special/java2cs/java2cs_01.html
スタック上にオブジェクトを構築できること，delegate が存在するあたりは C# のいいところなので素直に同意してみる．
property はメタデータ記述と似ているので置いといて，メタデータ記述は JSR 待ちとなっているので，今のところ C# のほうが上．
スレッドまわりの話は，Java のクラスライブラリがいけてないだけなので，C# との言語的な差というのは微妙．
しかし，「final を速度向上のためにつける，それよりは virtual/override のほうがいい」というのは，final を付けたら速度が上がるという噂に騙されてるので，ちょっと困ったもんだ（多くのJavaプログラマも，記事の筆者も騙されている）．virtual はオーバーライドされて挙動を変えられる可能性を明示することでプログラマに注意を促すという重要な意味があるのに……．
まあ，C# に優れた点があるので乗り換えました，というのは正しい意見なのだが，10の理由とか挙げるほどかなぁ．いくつかの強い理由と弱い理由が混在してる気がする．
2003-07-10 古い日記からの変換データ [長年日記] ▲
_ SCO ▲
Linux でもめてる SCO の意見．大変だなぁ，とは思うのだが，ライセンスの「方法を真似してもダメよ」系は厳しすぎるような気がする．特に，ソースコードが公開されてしまって「コードを読んでしまった」状態のプログラマたちがそれ以外の手法でプログラム書き直すのは難しいのに……．昔みたいに「経験者お断り」なクリーンルーム実装でもしないと無理かしら．http://itpro.nikkeibp.co.jp/free/LIN/NEWS/20030709/1/
_ Eiffel ▲
Assertion, Representation Invariants が気になったので，B. Meyer のオブジェクト指向入門を読み直してみた．
- Assertion は，「クラスが安定した時点」で守られていればよい．安定した時点とは，次のタイミングである．
- インスタンス化された（Create 実行が終了した）直後
- obj.method 形式のリモートコール （外部からの呼び出し）の前後
- メソッドの処理中や，ローカルコール（オブジェクト内部のコール）においてはAssertion は守られなくてもよい．
- クラス不変表明 (Class Invariants) は， すべての事前・事後条件に AND で付加される共通条件である．ただし，「これから追加されるメソッド」に制限を課すという点で，通常の事前・事後条件よりも強い意味を持つ．
- 実現不変表明 (Representation Invariant) は，クラス不変表明のひとつで，「抽象データ型の仕様に対して直接対応するもののない表明」．簡単に言うなら，外部に公開されていないような内部変数に関する表明である．
- 副作用 (Side-Effect) とは，オブジェクトの持つ属性を一つ以上変更する操作のこと．オブジェクトの持つファンクションは，副作用はあってもよいが，抽象状態ではなく具象状態にのみ影響を与えるものでなければならない．
どれも，妥当な意見なので納得．昔読んだときに比べると少しは理解度が上がった気がする．
2003-07-09 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Remi Dounence, Olivier Motelet, Mario Sudholt:"A formal definition of crosscuts"
「プログラムは，ステップごとにイベントを生成する」というモデルを説明した論文．モニタは，イベントのリストをプログラムから受け取って，crosscuts (イベントのリストとして定義される）が発生したかどうかをチェックする．
Crosscutsを定義するための Domain Specific Language を定義していて，実行時には Java としてコンパイルしてしまう．
どうやら，Event-based AOP というタイプらしい．素の Java で記述した Event-based AOP に比べると，DSL にした分，少し抽象的に書けている気はする．あと，cflow の最適化に関して証明が付いてるところもいちおうポイントだろうか．
_ 論文 ▲
Andres Farias and Mario Sudholt:"On Components with explicit protocols satisfying a notion of correctness by construction"
メソッド呼び出しの順序と，それによって起こる状態遷移を Protocol として定義するという話．まあ，ここまでは基本的に他のと同じだが，複数のプロトコルを結合（合成）するための形式的な計算法を提案している．これを使えば，オブジェクト間の Protocol をうまく計算できる可能性はある．もちろん，状態定義などをきちんとできれば，だが……．この手の protocol 定義では，例外処理などが定義されていなかったりするあたりが少し悲しいという気もする．
_ 論文 ▲
Matthew B. Dwyer, John Hatcliff, Robby Joehanes, Shawn Laubach, Corina S. Pasareanu, Robby, Hongjun Zheng,Willem Visser:"Tool-supported Program Abstraction for Finite-state Verification"出典はICSE2001らしい．
マルチスレッドなプログラムに対する検証を行うために，プログラムを抽象化して必要なところだけ取り出してやろうというものらしい．BASL (Bandera Abstract Specification Language) をJava に変換して，具体的なオペレータをその抽象的オペレータに置き換えたりするらしい．あと，PDG を辿っていって，途中の制御変数では最も影響の強い（数多く使われている）ものだけを残して他を取り除いたり，といったプログラムスライシングを応用したようなこともやっている様子．
しかし，適用対象が小さいプログラムなので，あまり有効性については分からない．
抽象的なオブジェクトに落としていく，というのは"ソースコード縮退" 系の研究には微妙に関連しそうではあるが．
_ AspectJ ▲
pointcut のところに，Jim Hugunin が指摘していたafter/around : handler が使用不可能になった話を追加．追加しようとして，ずっと忘れていた．
また，#hoge 形式のページ内リンクがフレーム有効時にうまく動かなかった部分を修正した．
_ C# ▲
Borland C#Builder が出るらしい．Visual C# .NET のぱっと使った限りでの完成度からして，戦うのは難しそうなのだが，Personal の機能限定版は無償配布らしいので地味に食い込んでいくかもしれない．まあ，使いやすさや，Delphi, C++Builderからの移行しやすさ（ツールの操作の共通性）がどの程度かによって，売れるかどうかは決まってきそうだ．
_ タクシー ▲
GPS 使ってタクシーが駆けつけるサービスとかがようやく実現され始めたらしい．以前は，「できたらいいなぁ」という程度だったのだが，不況→打開策として投資という動きで，しばらく進んでいきそうだ．http://biztech.nikkeibp.co.jp/wcs/leaf/CID/onair/biztech/biz/255498
_ AspectJ ▲
Jianjun Zhao, Martin Rinard:"Pipa: A Behavioral Interface Specification Language for AspectJ"
BISL (Behavioral Interface Specification Language) のひとつJML (Java Modeling Language) を AspectJ に拡張するという話っぽい．
JML は，ドキュメントコメントタイプ．@model instance int x_Mdl; とかいってモデル上での変数を宣言したり， @depends, @represents とかを使ってモデルと実体のフィールドを対応付けたりする．で，メソッドごとに ensures とか定義するらしい．
これを AspectJ に拡張しているのだけれど，advice の先頭にこの振る舞い記述を書けるらしい．
しかし，コード中にいっぱい分岐があると，その分振る舞いの仕様も増えていて，コードと仕様記述が重複していて無駄に見える．invariants とか書けるのは，まあ便利だが．
コンパイル時に AspectJ 記述が Java ソースに落ちるのと同様にJML 記述に落とすようなことが書いてあるが，詳細は不明．また，cflow など一部の join point はサポートしていない様子．
どうやら，この手の仕様記述や assertion の設計としては「動的にチェックするかどうか」といった問題があるらしい．いっぱい関連研究を挙げている．あまり読む気は起きないけど．
結局，この手の仕様記述は，書くかと言われると書かないなぁ．特に振る舞いの仕様記述は，コードと内容が重複するのが問題のような気がする．
_ 論文 ▲
論文を斜め読み．Steven P. Reiss and Manos Renieris:"Encoding Program Executions"
実行履歴を使って動的解析するのはいいけど，大量の実行履歴を扱うためには圧縮が必要，ということで色々な圧縮方法を比べている論文．
call/return を ABvCv (v はreturn) と表現する String Encoding,stack trace の中身を tuple で表現するとか，DAG で表現するとかになるらしい．
Grammar Based Encoding は，ICSE2003 の J. Law, G. Rothermel:"Whole Program Path-Based Dynamic Impact Analysis"で使っていたような気がする．
また，Finite State Automata を構成するなんてのも．圧縮率がけっこう違うんだなー．生データで 20G とかあっても，FSA とかに圧縮してしまえば実用範囲内に落ちるらしい．繰り返し回数とかの情報が落ちることを考慮しないといけないだろうけど．
2003-07-08 古い日記からの変換データ [長年日記] ▲
_ AspectJ ▲
さらに意見が出てた．これ，どこまで続くんだろう．- Aspect には， "abstract" なアスペクトが，pointcut に join point と関連付けられていないという形式と，pointcut は定義されているが処理が定義されていない，という二つの形で存在している．これらを言語上で区別するべきではないだろうか．
_ AspectJ ▲
MLでの議論はまだ続いてる様子．- Eclipse AJDT ではマーカーを表示してくれる．タグ付けで「ここでアスペクトが動く」っていうのを書くのはたしかに一見してわかるという利点はあるが，統合開発環境のサポートがないからといって言語が対応するというのは問題なのではないだろうか．
_ AspectJ ▲
AspectJ-users メーリングリストで，AspectJ みたいな言語によるアプローチと，Java を拡張するフレームワークとで，どっちがいいんだろう？とかいう感じの話があった．まとめると，だいたい次の通り．
- アスペクトを複数のファイルに記述するとき，言語的な観点からは，導入する複雑さのほうが本来解決すべき問題の複雑さを超えてしまうかもしれない．
- JBoss グループでは，メタデータとインターセプタによってAOP を実装しているが，「AOP を実現するツールとしてのメタデータとインタセプタ」が，「AOP とはメタデータとインタセプタだ」ということに置き換わる恐れがある．
- デバッグのサポートは重要．アスペクトによって，予期せず到達したコードがある場合，「なぜそのコードにたどり着いたか」を知ることが重要となる．
- pointcut は単純すぎるとアスペクトの記述が難しくなる．たとえば，Control-Flow 記述を省略することでシンプルな言語を作ることはできるが，特殊な実行トレースなどを作るときに苦しむことになる．
- 補足的なアスペクトを追加するときは Java + XML が妥当に見えるが，アプリケーションで重要な（「補足的でない」）アスペクトを記述するときは，できるだけソースコード中に情報を書きたくなる．補足的なアスペクトだけを見ている人には，フレームワークのほうがわかりやすい．
- フレームワークのほうが導入しやすいが，使いにくい．フレームワークの動的な側面は，Java がリフレクションで利便性を得たのと同様に，便利な側面がある．
- XML によるdeployment の記述は，意外と難しい．また，アスペクトの情報が複数のファイルに分散するのも大変．アスペクトを別ファイルに書くくらいなら，xdoclet みたいに@xx という追加タグを埋め込んだほうがマシ．
- シンプルなフレームワークには魅力がある．しかし，ツールによるサポートなしでは厳しそうに見える．
……といったところ．全体では，AspectJ の方法のほうが良いと思ってる人は意外と多そうだ．Users メーリングリストなんだから当然かもしれないが．
2003-07-07 古い日記からの変換データ [長年日記] ▲
_ Java ▲
Ant の Taskdef の追加方法が良く分からないので，そのまま ANT_HOME/lib に突っ込んでおくことにした．ant Tasks も数が増えてくると管理が面倒だが……．user.taskdef とか何かで設定するのかなぁ．
_ Java ▲
SableCC をインストールしてみた．
Token 系が Txxx というクラスになっていて，identifier = {single} id | {multiple} id identifier;というように書くとPIdentifier に共通の実装が定義され，ASingleIdentifier と AMultipleIdentifier で個別のケースにアクセスできるらしい．
で，Analyzer (DepthFirstAdaptor) に自動生成される void caseASingleIdentifier(ASingleIdentifier) をオーバーライドして Visitor パターンと同様に解析クラスを実装して，root.apply(adaptor) で解析する．
思ったよりシンプル．構文解析系のツール(ANTLRとか)を使うのは苦手なのだが，このぐらいが実装が楽でよいかも．
_ 論文 ▲
A.J.M.M. Weijters, W.M.P van der Aalst:"Rediscovering Workflow Models from Event-Based Data"
ペトリネットで Workflow を記述するとして，Workflow Log からペトリネットを逆に抽出してやろうというもの．Dependency/Frequency なんてものを使ってる．
A が出る頻度，A の出た後に B が出る頻度，A の出る前に B が出る頻度，なんてものを見ることで順序，並行関係にあるかを見てやろうというものらしい．シーケンス長 n に対して O(n^2) な様子．
_ 論文 ▲
Mohammad El-Ramly, Eleni Stroulia, Paul Sorenson:"From Run-time Behavior to Usage Scenarios:An Interaction-Pattern Mining Approach"
画面トレース（画面ＩＤの並び）からシステムの動作パターンを検出しようというもの．ユーザ・システム間のインタラクションを取り出すのが目的．
パターン抽出の基本操作はシーケンスの長さ n，数 k に対して長さ２の組み合わせを取り出すので，O(k * n^2) になる．
メソッドの実行トレースから計算しようとするとこの方法だと n = 10000~ なので大変そうだ．
_ 論文 ▲
Sergey Butkevich, Marco Renedo, Gerald Baumgartner, Michal Young:"Compiler and Tool Support for Debugging Object Protocols"出典は FSE-8, San Diego, CA, USA (2000) らしい． interface 定義に，一緒にプロトコルを定義しようというもの．
interface DataInput { protocol { open; read*; close; }}
メソッド呼び出しパターンと，状態変数の定義を組み合わせて記述しよう，とか書いてある．
実際には表現力が謎ではある．例示として上がっているのが Stack なせいかも．やはり，もうちょっとオブジェクト内部の記述にも触れるようにしたいところ．
実行時の検査はやっぱりラッパークラスを使うみたい．ラッパーを使うと， self problem が発生するのが難点だが．
2003-07-06 古い日記からの変換データ [長年日記] ▲
_ LotR ▲
エラッタ，FAQ によって更新されている部分を確認，反映．ルーリングセクション → エラッタ でかなり移動していた．
ひそかに，Warrior's Heart Edge が戦闘中の呪文にも適用できるので，魔術師のスタミナは意外と高く設定されることになりそう．実際，キャンペーンでは Tireless Edge で既にスタミナが10超えてる人がいるし，魔術師がパーティの中で一番スタミナがあるっていうのもどうかと思うけど．
_ 読書 ▲
Ken Arnold, James Gosling, David Holmes:プログラミング言語 Java 第３版，ピアソン・エデュケーションをちょっとだけ読んでみた．
新しい情報があったわけではなくて，StrictMath とか Process とか Locale とか存在自体を忘れてたクラスの存在を思い出したり，ソースコードで Unicode 文字が使えるとか，AccessibleObject （Field, Method などのスーパークラス）を使えばアクセス制御を無視したりできるんだ，とか微妙な情報がいっぱい載ってた．
でも，新しい情報がほとんどないということは，言語レベルではそれなりに Java に習熟してきたということなのだろう．もちろん，ライブラリのリファレンスは手放せないが．
_ 論文 ▲
次のネタ向けにピックアップした論文のうちのひとつを読む．Robert B. Findler, Mario Latendresse, Matthias Felleisen:"Behavioral Contracts and Behavioral Subtyping"出典は Foundations of Software Engineering (FSE 2001)で，Behavioral Subtyping を考慮して assertion をチェックしようという話．あるサブクラスが Bahavioral subtyping かどうか，というのはJava では記述できないので，そのあたりでは困っている様子．assertion の持っている問題を説明しているのでそのあたりで議論するときに refer するかも？
