netail.net

_ コンテキスト制約記述言語CCL ▲

Context-Based Constraint Language，というのがあるらしいというので調べてみた．

あるコンポーネントにコンテキスト値を付加して，そのコンポーネントが働いているときに属しているコンテキストをリストアップしておく．そして，「コンテキスト 'Controller' のときは 'Personal Data = Yes' の属性を持ったオブジェクトに アクセスしては駄目です」といったように制約を記述する．

使い方としては，設計時に UML などに付加しておいてあとでコードに落とす制約言語なので，OCL と似ている．

単なる表明だけでなくて ENCRYPTED WHEN CALLING とかいった呼び出しまわりの属性付加もあるので，主には CORBA やら EJB なんかでの使用になるみたい．

単に表明を記述する言語としてみると，AspectJ・JBoss AOP などでアトリビュートを付加してdeclare error や実行時のエラーチェックを付加する実装方法とうまく対応しそうな印象がある．

SPLAT2004に出したアサーションをアスペクトで書くと，という話とも絡むけれど，CCLでいうコンテキストはかなり大域的な情報で，「利用コンポーネントに応じて違う表明を書く」というのはコンポーネントとその利用者の間だけのローカルな情報なのかなと思ったりする．技術的には極端な差はないように見えるけれど．

_ [論文]ソフトウェア内部のパターン認識 ▲

Martin Pinzger and Harald Gall:Pattern-Supported Architecture Recovery.Technical Report, TUV-1841-2002-16, Technical University of Vienna.

ソフトウェア・アーキテクチャをソースやドキュメントから復元するために，どんな設計上の決定がシステム内に含まれているかを認識しましょう，という話みたい．

ただ，やってることはちょっと賢い（複数行に渡った情報が扱える）grep のように見えなくもない．マッチした結果を「パターンインスタンス」と呼んで，それらの関係図を出力しましょう，といった感じに見える．

_ [論文]データ項目の自動対応付け ▲

Sebastian Bossung, Hermann Stoeckle, John Grundy, Robert Amor, John Hosking:Automated Data Mapping Specification via Schema Heuristics and User Interaction.Proceedings of ASE 2004, pp.208-217.

XMLスキーマがたくさんあって，データを相互変換したいが，毎回手動で変換ルールを作るのは大変だから，XMLスキーマが２個与えられたとき，なるべく自動でデータのマッピングを生成しましょう，という論文．スキーマだけでなく，インスタンス文書のほうも（もしあれば）入力として受け付けるようにしているみたい．

スキーマ間のデータ項目のマッチが基本になるが，マッチの実装方式としては，色々なヒューリスティックを実装したエージェントを環境に放り込む，という形にしている．

使うヒューリスティックとしては

・項目の名前が同一である

・一方の項目の名前が，他方の項目名の部分列になっている

・文字列同士の Levenshtein 距離（一方を他方に変換する操作列の長さ）が小さい

・要素型が等しい

・要素のセット（あるタグの配下全員）で型が等しい

・一方が他方の略称アルファベット列になっている

・インスタンス文書の，要素の値が同じ…など．

ツールをプロトタイプを作ってみたら，スキーマがそれなりに似ていると事前に分かっているものでは，いい感じに使えた，らしい．

ただ，この時点では，データのマッピングは値のコピーにしか対応してないようなので，複数項目の集計とかに反応しようとすると大変そう．（変換を容易に記述できるスクリプトと組み合わせになる？）

あったら便利そう，という印象はあるけれど，こういう類のツールはどう評価するのがいいのか分からない（せいぜい「正しい対応付け」に対する正解率？）という微妙なところ．どのヒューリスティックがよく効くのかは見てみたい気もするが．

_ [論文]デバッグ操作のプログラム化 ▲

Guillaume Marceau, Gregory H. Cooper, Shriram Krishnamurthi, Steven P. Reiss:A Dataflow Language for Scriptable Debugging.Proceedings of ASE 2004, pp.218-227.

デバッグ用の操作をプログラム（スクリプト）から扱えるようにした，という話．デバッグ時に行う操作はわりと定型的だ，というのが前提．

Lispぽい文法の言語を作っていて，Trace命令で（AspectJの args や this などのように）プログラムの状態のいくつかを変数にバインドして，プログラム実行中に制約違反を起こしたらプログラムを止める，といったスクリプトを作っている．

東工大の千葉先生のところでやってたデバッガにAOPな機能を取り込んでみる，という話が近いのかも．

_ [論文]抽象プログラムによる制約違反の発見 ▲

Mana Taghdiri: Inferring Specifications to Detect Errors in Code.Proceedings of 19th International Conference on Automated Software Engineering (ASE'04), pp.144-153,Linz, Austria, September, 2004.

クラスの各メソッドから簡単な仕様を抽出し（たとえば戻り値が null でないとかフィールドが更新されるとか），プログラム中のメソッド呼び出しをその制約式で単純化し（a = list.contains(element) なら [a = "?"] のように）抽象化されたプログラムが制約を本当に満たすか検査する．満たさない場合，制約違反を起こすような抽象実行列を出力する．

あんまりよく分かっていないが，データ構造コンポーネントの一貫性検査などに使ったりするみたい．

_ [論文]ソフトウェア変更時の横断的関心事 ▲

Elisa L.A. Baniassad, Gail C. Murphy, Christa Schwanninger and Michael Kircher:Managing Crosscutting Concerns During Software Evolution Tasks:An Inquisitive Study.Proceedings of AOSD 2002.

ソフトウェアの変更時に，開発者がどう横断的関心事を意識して対処するかを調べようというケーススタディ．

開発者に後からインタビューしたところ，明示的にドキュメントやモジュールがないと，「何をしているのか」という理解が人によって変わってきて，また対処方法も３つくらいのパターンに分かれたらしい．

また，「このコードを変更するとどこに変更が及ぶのか？」というのが開発者の不安の種となっていることが確認されている．

開発者の作業の監視ではなく終わった後のインタビューなのと，参加者８人でタスクも小さいということからValidity として強いわけではないけれど．