behavior composition in component systems

DISTRIBUTED SYSTEMS RESEARCH GROUPhttp://nenya.ms.mff.cuni.cz

CHARLES UNIVERSITY PRAGUEFaculty of Mathematics and Physics

Behavior Composition in Component Systems

Jiří Adámek

Jiří AdámekDoctoral thesis defense, September 19, 2006

The context

• The context Automated formal verification of component-

based applications


The context

• What is formal verification? The process of proving or disproving the correctness

of a model with respect to a specified property• Model

Finite automata

• Specification language Behavior Protocols

• Property Predefined, component-specific

Automated formal verification• The process is fully automated and does not require human

assistance• Verification tools• Example of automated formal verification

Model Checking


The context: Software components

• What are software components? Building software from reusable blocks with well-

defined interfaces• These blocks are called software components

Provided and required interfaces Primitive and composed components


The context: Example

• Example: the Token component A part of a complex application providing wireless internet

access on airports This component manages the session of a single user

Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAcco

un

t

ITim

erC

allb

ack

Tim

er

Tim

eo

ut(

)

ITim

erC

allb

ack

ITim

er

ITim

er

Ca

nce

lTim

eo

ut(

)

Se

tTim

eo

ut(Timeout)

IAcco

un

t

InvalidatingToken(TimeLeft)

ILife

ILife

Start()


The context: Example

?ICustomCallback.InvalidatingToken_1 {

!IAccount.AdjustAccountPrepaidTime_1

}*

|

?ICustomCallback.InvalidatingToken_2 {

!IAccount.AdjustAccountPrepaidTime_2

}*

Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAcco

un

t

ITim

erC

allb

ack

Tim

er

Tim

eo

ut(

)

ITim

erC

allb

ack

ITim

er

ITim

er

Ca

nce

lTim

eo

ut(

)

Se

tTim

eo

ut(Timeout)

IAcco

un

t


ILife

ILife

Start()


?Invalidating Token_1^

!Invalidating Token_1$

!AdjustAccountPrepaidTime_1^

?AdjustAccountPrepaidTime_1$

?Invalidating Token_2^

!AdjustAccountPrepaidTime_2^

?AdjustAccountPrepaidTime_2$

!Invalidating Token_2$


Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAcco

un

t

ITim

erC

allb

ack

Tim

er

Tim

eo

ut(

)

ITim

erC

allb

ack

ITim

er

ITim

er

Ca

nce

lTim

eo

ut(

)

Se

tTim

eo

ut(Timeout)

IAcco

un

t


ILife

ILife

Start()

What is behavior composition?

A (partial) behavior model is associated with each primitive component


Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAcco

un

t

ITim

erC

allb

ack

Tim

er

Tim

eo

ut(

)

ITim

erC

allb

ack

ITim

er

ITim

er

Ca

nce

lTim

eo

ut(

)

Se

tTim

eo

ut(Timeout)

IAcco

un

t


ILife

ILife

Start()


?


Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAcco

un

t

ITim

erC

allb

ack

Tim

er

Tim

eo

ut(

)

ITim

erC

allb

ack

ITim

er

ITim

er

Ca

nce

lTim

eo

ut(

)

Se

tTim

eo

ut(Timeout)

IAcco

un

t


ILife

ILife

Start()

?


Behavior Composition


Why is behavior composition important?

• Case 1 Behavior model is not manually specified for a

composite component We want to verify the behavior of composite

components

• Case 2 Behavior model is manually specified for a

composite component We want to compare the manually written behavior

model of a composite component with the automatically constructed one

• In order check that the design is consistent Vertical compliance checking


My contribution

• Analysis of behavior composition in current component models

• Identification of drawbacks

• Proposal of improvements Detection of composition errors Support for reentrant component behavior

specification The improvements were designed for SOFA

and behavior protocols


Detection of composition errors

• A typical approach to behavior composition Model of correct behavior is constructed

• A proposed improvement The resulting model describes both correct behavior

and composition errors



• Example of a composition error ValidityChecker tries to call two methods on ICustomCallback in parallel

CustomToken is not able to accept parallel calls

Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAccount

ITim

erC

allb

ack

Tim

er

Tim

eout

()

ITim

erC

allb

ack

ITim

er

ITim

erCan

celT

imeo

ut()

Set

Tim

eout

(Timeout

)

IAccount


ILife

ILife

Start()



• Four types of composition errors identified

Bad activity

No activity

Divergence

Unbound requirement error


Standalone detectionContext-dependent detection


Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAccoun

t

ITim

erC

allb

ack

Tim

er

Tim

eou

t()

ITim

erC

allb

ack

ITim

er

ITim

erCan

celT

imeo

ut(

)

Set

Tim

eou

t(Timeout

)

IAccoun

t


ILife

ILife

Start()



• Algorithms for detection of all the identified types of composition errors were designed Both standalone and context-dependent detection

• The models: specified via behavior protocols describe behavior of SOFA components

• The main advantage Identification of composition errors in an early stage

of the development cycle It does not influence the time and memory

complexity of behavior composition


Support for reentrant component specification

• Reentrant component The methods provided by the component

may by called in parallel There is no upper bound on the number of

parallel calls



• How to model behavior of a reentrant component? Absolute view (component design time)

• We have no information on the other components of the application

The behavior has to be specified with an infinite state model

It is very difficult to handle infinite models by the tools

Relative view (application design time)• We have the information about other components

The behavior can be often specified with a finite state model

The model is application-specific



• A compromise solution At the component design time, the behavior

is specified via a behavior template At the application design time, the behavior

template is automatically transformed into concrete behavior model

The behavior template is general

The concrete behavior model is often finite and can be handled by the tools



• Languages for behavior templates and concrete behavior models were proposed They are both based on behavior protocols

• An algorithm for automatic transformation of behavior templates into concrete behavior models was designed


Related work

• Parameterized synchronized networks of labeled transition systems E. Madelaine et. al.

• Tracta J. Kramer et. al

• Parameterized contracts R. H. Reussner, H. W. Schmidt, et. al

• Component-interaction automata I. Cerna et. al

• Wright R. Allen, D. Garlan

• Interface Automata L. De Alfaro, T. Henzinger

• I/O Automata N. A. Lynch, M. R. Tuttle


Publications (1)

• Detection of composition errors Adamek, J., Plasil, F.: Component Composition Errors and Update

Atomicity: Static Analysis, Journal of Software Maintenance and Evolution: Research and Practice 17(5), Sep 2005

Kofron, J., Adamek, J., Bures, T., Jezek, P., Mencl, V., Parizek, P., Plasil, F.: Checking Fractal Component Behavior Using Behavior Protocols, presented at the 5th Fractal Workshop (part of ECOOP'06), July 3rd, 2006, Nantes, France, Jul 2006

Adamek, J., Plasil, F.: Partial Bindings of Components - any Harm?, Presented at the SACT 2004 Workshop, Busan, Korea (held in conjunction with the APSEC 2004 conference), and published in the Proceedings of APSEC 2004, IEEE Computer Society, Nov 2004

Adamek, J., Plasil, F.: Erroneous Architecture is a Relative Concept, in Proceedings of Software Engineering and Applications (SEA) conference, Cambridge, MA, USA, published by ACTA Press, Nov 2004

Adamek, J.: Static Analysis of Component Systems Using Behavior Protocols, in OOPSLA 2003 Companion, Anaheim, CA, USA, published by ACM, Oct 2003

Adamek, J., Plasil, F.: Behavior Protocols Capturing Errors and Updates, in Proceedings of the Second International Workshop on Unanticipated Software Evolution (USE 2003), ETAPS, published by University of Warsaw, Poland, Apr 2003


Publications (2)

• Reentrant component specification Adamek, J.: Addressing Unbounded Parallelism in Verification of Software

Components, in proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD 2006), Las Vegas, Nevada, USA, published by IEEE Computer Society, Jun 2006


Citations (1)

• Adamek, J., Plasil, F.: Behavior Protocols Capturing Errors and Updates, in Proceedings of the Second International Workshop on Unanticipated Software Evolution (USE 2003), ETAPS, published by University of Warsaw, Poland, pp. 17-25, Apr 2003 J. Buckley, T. Mens, M. Zenger, A. Rashid, G. Kniesel: Towards a

taxonomy of software change, Journal of Software Maintenance and Evolution: Research and Practice 17(5), pp. 309 - 332, Sep 2005

A. Occello and A-M. Dery-Pinna: Safe runtime adaptations of components: a UML metamodel with OCL constraints. In First International Workshop on Foundations of Unanticipated Software Evolution (FUSE'04), Barcelona, Spain, Mar 2004

A. Occello and A-M. Dery-Pinna: Safety of component adaptations: Elements of formalization. Technical Report I3S/RR-2004-04-FR, Laboratoire I3S - Université de Nice-Sophia Antipolis, Bâtiment ESSI - BP145 - F-06903 Sophia Antipolis CEDEX, Jan 2004

B. Zimmerova, L. Brim, I. Cerna, P. Varekova: Component-Interaction Automata as a Verification-Oriented Component-Based System Specification. Proceedings of SAVCBS 2005

C. Carrez: Contrats comportementaux pour composants, PhD. thesis, ENST, Paris, France, Dec 2003


Citations (2)

• Adamek, J.: Static Analysis of Component Systems Using Behavior Protocols, in OOPSLA 2003 Companion, Anaheim, CA, USA, published by ACM, Oct 2003 T. Barros: Formal specification and verification of distributed

component systems, PhD thesis, Université de Nice - INRIA Sophia Antipolis, Nov 2005

• Adamek, J., Plasil, F.: Component Composition Errors and Update Atomicity: Static Analysis, Journal of Software Maintenance and Evolution: Research and Practice 17(5), Sep 2005 T. Barros: Formal specification and verification of distributed

component systems, PhD thesis, Université de Nice - INRIA Sophia Antipolis, Nov 2005


Citations (3)

• Mencl, V., Adamek, J., Buble, A., Hnetynka, P., Visnovsky, S.: Enhancing EJB Component Model, Tech. Report No. 2001/7, Dep. of SW Engineering, Charles University, Prague, Dec 2001 A. Farías, Y-G. Guéhéneuc: On the Coherence of Component

Protocols. In Uwe Assmann, Elke Pulvermueller, Isabelle Borne, Noury Bouraqadi, and Pierre Cointe, editors, Electronic Notes in Theoretical Computer Science, volume 82, April 2003, Elsevier Science

A. Farías, Y-G. Guéhéneuc, M. Südholt: Integrating Behavioral Protocols in Enterprise Java Beans. In Kenneth Baclawski and Haim Kilov, editors, Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer, pp. 80--89, Oct 2002


Projects

• The SOFA project A tool was implemented: BPChecker

• The implementation is work of Jan Kofroň

• The CRE project Supported by France Telecom The BPChecker ported to the Fractal

component model


Demo

• Verification of the Token component: Example 1 CustomToken accepts only sequential calls ValidityChecker calls two methods in parallel Bad activity error

(?ICustomCallback.InvalidatingToken_1 {

!IAccount.AdjustAccountPrepaidTime_1}+?ICustomCallback.InvalidatingToken_2 {

!IAccount.AdjustAccountPrepaidTime_2}

)*

Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAccount

ITim

erC

allb

ack

Tim

er

Tim

eout

()

ITim

erC

allb

ack

ITim

er

ITim

erCan

celT

imeo

ut()

Set

Tim

eout

(Timeout

)

IAccount


ILife

ILife

Start()


Demo

Composition error detected – bad activity(!ICustomCallback.InvalidatingToken_1):

(S0) #ILifetimeController.Start^(S1) #ITimer.SetTimeout_1^(S2) [#ILifetimeController.Start$,

#ITimer.SetTimeout_1$](S3) #ITimerCallback.Timeout^(S4) #ICustomCallback.InvalidatingToken_2^(S5) #IToken.InvalidateAndSave^(S6)

Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAccount

ITim

erC

allb

ack

Tim

er

Tim

eout

()

ITim

erC

allb

ack

ITim

er

ITim

erCan

celT

imeo

ut()

Set

Tim

eout

(Timeout

)

IAccount


ILife

ILife

Start()


Demo

• Verification of the Token component: Example 2 CustomToken accepts parallel calls ValidityChecker calls two methods in parallel No errors

?ICustomCallback.InvalidatingToken_1 {!IAccount.AdjustAccountPrepaidTime_1

}*|?ICustomCallback.InvalidatingToken_2 {

!IAccount.AdjustAccountPrepaidTime_2}*

Token

ValidityChecker

ITokenCallback

ITokenCallback

IToken

IToken

CustomToken

ICustomCallback

ICustomCallback

IAccount

ITim

erC

allb

ack

Tim

er

Tim

eout

()

ITim

erC

allb

ack

ITim

er

ITim

erCan

celT

imeo

ut()

Set

Tim

eout

(Timeout

)

IAccount


ILife

ILife

Start()


Conclusion

• Behavior composition in current component models was analyzed

• Several improvements were proposed and implemented

• Future work Implementation of the behavior template

transformation A case study

• For which kind of application the transformation of a behavior template into a finite concrete behavior model is possible?

behavior composition in component systems

Documents

behavior composition

partial behavior model

airportsthis component

token componenta

invalidating token

composite componentwe

software componentswhat

software componentsprovided