Interface Decomposition for Service Compositions

Interface Decomposition for
Service Compositions
Domenico Bianculli*1
Dimitra Giannakopoulou*2
Corina S. Păsăreanu*2
University of Lugano
*2 NASA Ames / CMU Silicon Valley
*1
背景
• Assume-guaranteeスタイルcompositional verification
– 特に、自動 interface (i.e., assumption) 生成
• Builds on the previous work by the authors[14]
– “Assumption Generation for Software Component Verification” ,
Giannakopoulou, Păsăreanu, Barringer, ASE2002
• Actually, much prior/related work in this area
– See refences in the paper and [14]
Contribution (1/2)
• [14]では正確なinterfaceの自動生成手法が提案された
– プログラムM インターフェースI
– E || M safe , environment E satisfies I
• I.e., I is the most permissive interface of M
– M, E, Iは有限LTS(i.e., FSM)で表現されているので、理論上は可能
である
• 本論文では[14]の手法で生成されたIを複数に分割する
– I
I1 || I2 || … || In
– 環境が複数のserviceで構成されている時に役立つ
• I.e., E = E1 || E2 || … || En
Contribution (2/2)
• [14]と違い完全性はないが、健全である
– E1, …, En satisfies I1, …, In then E1 || … || En || M safe
• つまらないI1,…,Inを生成しないようheuristicな手法が提案さ
れている
• I1, …, In too strong (e.g., false) trivially satisfy the above
– 大まかなアイデア: Infer Ii strong enough s.t. even Ei alone is
able to guarantee M’s safety, but assuming only the “actions”
of Ei can directly move M to an error state
• 実験評価は生成されたI1,…,Inの適正を目で見て判断
まとめと感想
• 環境 E=E1 || E2 … || En 上で動く M に対し,
– E || Mの safety を保障する健全な interface をMから,
– Ei ごとに Ii を heuristic に生成する
• 環境を複数のcomponentに分割するというのは面白い
– 仮定を強めれば完全な生成はできるか、など発展が考え
られる？
Unifying Execution of Imperative
and Declarative Code
Aleksandar Milicevic
Derek Rayside
Kuat Yessenov
Daniel Jackson
MIT
背景
• プログラミング言語の大まかな分類
– Imperative (命令系)
• C/C++, Java, Perl, Python, Ruby, Fortran, Pascal, …
• ほとんどのメジャーなプログラミング言語はこれ
– Functional (関数型)
• Haskell, ML (mostly), Scheme (mostly), Lisp (mostly), …
– Logic / Constraint (論理型 / 制約型)
• Prolog
Declarative
Contribution (1/2)
• Imperativeとdeclarativeを混ぜた言語を提案
– Javaがベース
• Javaのimperative codeが使える
– Declarative codeはFOLの制約で宣言する
• SyntaxはAlloy[Jackson 2006]風
static class Cell {int val = 0; }
@Invariant(“all v: int|v!=0 => lone this.cells.elems.val.v”)
…
public class Sudoku {
…
@Ensures(“all c:Cell | c.val >0 && c.val<=this.n”)
public void solve() { Squander.exe(this); }
}
Contribution (2/2)
• Imperative code can access objects of declarative
code and vice versa
– 残念ながら、論文にはよい例がない
• 例がすべてconstraint solvingだけで解決するものになっており、
融合するmeritが伝わりにくい
• 論理制約解消には既存のconstraint solverを用いる
– Kodkod [Torlak 2008]
• BackendにSAT solverを使用している
まとめと感想
• 論理型言語+Javaの融合言語の提案
– 論理記述の自由度が高い
• Imperativeとdeclarativeの融合は最近の流行らしい
– 特にSQLなどdatabase query言語との組み合わせ
• LINQ (Microsoft)など
– 本論文のようなlogic言語との融合も面白い
• が、誰でも思いつくことなので、当然、過去研究がある
– See references in papers ([Hoare 1987]~)
• 近年のSAT solverなどdecision proverの躍進で現実味を帯び
てきたという感じか？
Always-Available Static and
Dynamic Feedback
Michael Bayne
Richard Cook
Michael D. Ernst
University of Washington
背景
• Two worlds of typing
– Static: Java, C#, ML, Haskell, …
• Detect type errors at compile time
• Issues: 型検査器は神ではない
– Dynamic: Perl, Python, Ruby, Lisp, …
• Detect type errors at run time
• Issues: 型エラー検出が遅れる
• Many “hybrid” approaches have been proposed
– Soft typing, Gradual typing, Hybrid typing, Contracts, etc.
– See references in the paper
本論文
• Java Dynamically typed Java
• 大まかなアイデア：
class Foo {
}
class Foo {
int bar;
Object bar;
int compute (int baz) { … }
Object compute (Object baz) { … }
}
– 動的にメソッド呼び出し時のチェックなどを行う
– メソッドoverloadingなど静的型依存な部分は少しtricky
まとめと感想
• 動的型Javaの提案？
– 既存研究と比較して、根本的に新しいという印象はない
• Javaのかなりのsubsetに対応した実装がある
– この点が高く評価された？

Download Report