Model, Notation, and Tools for Verification of Protocol-Based Components Assembly Pascal Rapicault 1,2 , Jean-Paul Rigault 1 , and Luc Bourlier 1 1 Rainbow and Sports Projects, I3S Laboratory, University of Nice Sophia Antipolis and CNRS (UMR 6070), F-06902 Sophia Antipolis Cedex, France 2 Object Technology International, Inc. (OTI), firstname.lastname@essi.fr Abstract. Assembly of blackbox components is made difficult by the lack of precise information on the way components interact. What is needed is a behavioral model of the component, at the input and output interface levels. This paper introduces the notion of behavioral points of view and an associated graphical notation, SyncClass, to represent such a model. The underlying semantics of SyncClass makes it possible to au- tomatically verify component assembly, either for individual components or for a whole system. 1 Introduction We are currently working on the definition and the implementation of a CASE environment, named Co2 1 , which provides notations and tools to specify, de- velop, and use components. This communication focuses on the notations and tools devoted to the user of components, that is the person who assembles existing components to build an application. More specifically it addresses the problem of verifying components assembly, either for individual components or for a whole system. The ideal way of assembling components should rely on the sole knowledge of the component interfaces (blackbox reus e [19]). However the reality is different, and the developers often require knowledge about component internals (glassbox reuse [19]). Indeed the user is generally provided with a static description of the interface (a simple list of operations) whereas information about the valid sequences of operation calls would be needed. The latter information is what we call the component protocol of use. The situation is even worse when components are organized into a component framework [19]. In order to respect a given component protocol, the user cannot just consider his/her own calls to the component but also the calls originating from other components and targeted to the component under study. Thus the user has to guess the part of the protocol to which he/she must comply. 1 Co2 stands for Components and Composition J. Bishop (Ed.): CD 2002, LNCS 2370, pp. 257–268, 2002. c  Springer-Verlag Berlin Heidelberg 2002