310 likes | 323 Views
Learn about Interface Models, Automata, and the concept of Parameterized Interface Automata as introduced by Luca De Alfaro and Thomas A. Henzinger in 2001, emphasizing top-down design and compatibility checking for component-based systems.
E N D
Parameterized Interface Automata Shahram Esmaeilsabzali January 31, 2005
Outline • Interface Models • Interface Automata • Parameterized Interface Automata
Interface Models • Introduced by Luca De Alfaro and Thomas A. Henzinger in 2001 • Interface models: • Specify how systems can be used instead of speciyifying what systems do • Rely on helpful environments (optimistic) • Support top-down design
An Example Interface • How vs. What • Optimistic vs. Pessimistic
Main Idea • Interface models are meant to be: • Concise • Intuitive for top-down design • Useful for checking compatibility of component-based systems
Interface Models (More Formally) • Well-formedness Criteria: • Support composition and refinement • Support top-down design • (f || g) and f’refinesf, then (f’ ||g)refines(f || g)
Refinement • Interface models rely on helpful Env • A more refined interface should have more relaxed assumptions about the Env: • Lessinput assumptions-> Refined Interface should accept Env Inputs • More output guarantees-> Env should be able to accept refined Interface outputs
Example • Assume x,y be inputs and z the output of an interface
Composition • Interface composition is a partial, commutative, associative, binary operation that combines the two interfaces’: • Behaviours of the two interfaces • Environmental assumptions of the two interfaces
Top-down Design • Such Composition and Refinement relations imply top-down design Stronger Output Guarantee Weaker Input assumptions Refinement
Top-Down Design: Compositional Refinement abstract Refined
Outline • Interface Models • Interface Automata • Parameterized Interface Automata
Interface Automata (IA) • Interface automata are suitable for modeling component-based systems name in_cnd ISBN in_us in_cnd? cnd$_price! ISBN? Author! name? in_us? us$_price! us$_price cnd$_price Author
Example ISBN name in_cnd in_us cnd$_price credit_no us$_price in_cnd? cnd$_price! ISBN? ref_no! cnd$_price? credit_no? Author! name? err_no! in_us? us$_price! ref_no err_no us$_price cnd$_price Author
IA Composition ISBN name in_cnd in_us credit_no us$_price cnd$_price in_cnd? cnd$_price! ISBN? ref_no! cnd$_price? credit_no? Author! name? err_no! in_us? us$_price! err_no ref_no us$_price cnd$_price Author name in_cnd credit_no in_us ISBN Author! credit_no? ISBN? err_no! cnd$_price; in_cnd? Author! name? ref_no! credit_no? err_no! Author! ref_no! Author ref_no err_no
IA Composition- Cont’d name in_cnd credit_no in_us ISBN ISBN? in_cnd? Author! name? cnd$_price; ISBN? in_cnd? Author! name? credit_no? credit_no? ISBN? in_cnd? Author! name? err_no! ref_no! err_no! ref_no! ISBN? in_cnd? Author! name? Author ref_no err_no
Illegal States e! b! b? c? d? a? 0’ 3’ 1’ 2’ 0 3 1 2 e! d? (0,0’) (0,3’) (0,1’) (0,2’) a? a? a? a? e! d? (1,3’) (1,0’) (1,1’) (1,2’) b; e! d? (2,2’) (2,0’) (2,3’) (2,1’) c? c? c? c? e! d? (3,0’) (3,3’) (3,1’) (3,2’)
IA Cont’d (helpful environment) a c e! d? (0,0’) (0,1’) (0,2’) a? a? a? e! d? (1,0’) (1,1’) (1,2’) b; (2,3’) c? (3,3’) d e d e d! a! c! e? Environment a c
IA Refinement credit_no us$_price cnd$_price ref_no! cnd$_price? credit_no? Pay err_no! ref_no err_no GenPay refines Pay cnd$_price account_no credit_no us$_price cnd$_price? credit_no? ref_no! GenPay us$_price? ref_no
Outline • Interface Models • Interface Automata • Parameterized Interface Automata
IA is not expressive enough • Actions in IA are atomic elements • Methods/messages/functions are all complex elements consisting of atomic elements • To provide such complex elements we propose a new model
Parameterized Interface Automata (PIA) credit_no us$_price cnd$_price ref_no! pay_in_cnd cnd$_price? credit_no? err_no! ref_no err_no
PIA Cont’d • Each complex action either consists entirely of input/internal or output/internal actions • Each complex action maintains the sequentiality of its consisting simple elements during compositions • An IA is a PIA without complex actions
PIA Cont’d • A PIA can be assumed to be specification of a class and its methods, with all possible orders of execution for such methods • Or, specification of a composite Web service with all scenarios for its operations • PIA can then be used as a tool for top-down design of such systems
PIA Composition ISBN name in_cnd in_us credit_no us$_price cnd$_price in_cnd? cnd$_price! pay_in_cnd ISBN? ref_no! Author! name? cnd$_price? credit_no? err_no! us$_price! in_us? ref_no err_no us$_price cnd$_price Author name in_cnd credit_no in_us ISBN Author! err_no! ISBN? pay_in_cnd in_cnd? ref_no! err_no! cnd$_price; credit_no? Author! name? ref_no! Author ref_no err_no
PIA Composition- Cont’d name in_cnd credit_no in_us ISBN ISBN? in_cnd? Author! name? pay_in_cnd cnd$_price; ISBN? in_cnd? name? credit_no? credit_no? ISBN? in_cnd? Author! name? err_no! ref_no! err_no! ref_no! ISBN? in_cnd? Author! name? Author ref_no err_no
PIA vs. IA name in_cnd credit_no in_us ISBN Author! err_no! ISBN? pay_in_cnd in_cnd? ref_no! err_no! cnd$_price; credit_no? Author! name? ref_no! Author ref_no err_no name in_cnd credit_no in_us ISBN Author! credit_no? ISBN? err_no! cnd$_price; in_cnd? Author! name? ref_no! credit_no? err_no! Author! ref_no! Author ref_no err_no
PIA Refinement credit_no us$_price cnd$_price ref_no! pay_in_cnd Pay Credit_no? cnd$_price? err_no! ref_no err_no credit_no us$_price province cnd$_price account_no pay_in_cnd ref_no! cnd$_price? province? credit_no? GenPay cnd$_price? account_no? err_no! pay_in_cnd_acc ref_no err_no
PIA Is Restrictive ISBN name in_cnd in_us credit_no us$_price cnd$_price in_cnd? cnd$_price! pay_in_cnd ISBN? ref_no! Author! cnd$_price? credit_no? name? err_no! in_us? us$_price! err_no ref_no us$_price cnd$_price Author name in_cnd credit_no in_us ISBN ISBN? Author! err_no! credit_no? in_cnd? cnd$_price; name? ref_no! name? err_no! Author! credit_no? ISBN? ref_no! Author ref_no err_no
Concluding Remarks • PIA is an intuitive model for checking compatibility of component-based (and probably OO) systems • I would like to study and understand how we can decompose interface models into some interesting constituent elements
References • Luca de Alfaro and Thomas A. Henzinger. Interface Automata. In Volker Gruhn, editor, Proceedings of the Joint 8th European Software Engeneering Conference and 9th ACM SIG-SOFT Symposium on the Foundation of Software Engeneering (ESEC/FSE-01), volume 26, 5 of SOFTWARE ENGINEERING NOTES, pages 109-120, New York, September 10-14 2001. ACM Press. • Luca de Alfaro and Thomas A. Henzinger. Interface Theories for Component-Based Design. In Proceedings of the First International Workshop on Embedded Software, volume 2211, pages 148-165. Lecture Notes in Computer Science 2211, Springer-Verlag, 2001. • Shahram Esmaeilsabzali. An Interface Approach to Discovery and Composition ofWeb Services. Master of mathematics, School of Computer Science, University of Waterloo, 200 University Ave. W., Waterloo, Ontario, Canada, N2L 3G1, 06 2004.