The state of knowledge in how to specify sequential programs in object-oriented languages such as Java and C# and the state of the art in automated verification tools for such programs have made measurable progress in the last several years. This paper describes several remaining challenges and approaches to their solution.

Component-based software development is gaining recognition as the key technology for the construction of high-quality, evolvable, large software systems in timely and affordable manners. In this new setting, interoperability is one of the essential issues, since it enables the composition of reusable heterogeneous components developed by different people, at different times, and possibly with different uses in mind. Currently most object and component platforms (such as CORBA, DCOM, or EJB) already provide the basic infrastructure for component interoperability at the lower levels, i.e., they sort out most of the "plumbing" issues. However, interoperability goes far beyond that; it also involves behavioral compatibility, protocol compliance, agreements on the business rules, etc. This chapter tries to go through the basic concepts related to component interoperability, with special emphasis in the syntactic, protocol and operational specifications of components. Our main goal is to point out the existing problems, survey the current solutions and how they address those problems, and to draw attention towards some of the still open issues and challenges in this interesting research area.

We propose a method for implementing behavioral interface specifications on the.NET platform. Our interface specifications are expressed as executable model programs. Model programs can be run either as stand-alone simulations or used as contracts to check the conformance of an implementation class to its specification. We focus on the latter, which we call runtime verification. In our framework, model programs are expressed in the new specification language AsmL. We describe how AsmL can be used to describe contracts independently from any implementation language, how AsmL allows properties of component interaction to be specified using mandatory calls, and how AsmL is used to check the behavior of a component written in any of the.NET languages, such as VB, C], orCþþ.

We propose a method for implementing behavioral interface specifications on the .NET platform. Our interface...

Traditional IDLs were defined for describing the services that objects offer, but not those services they require from other objects, nor the relative order in which they expect their methods to be called. In this paper we propose an extension of the CORBA IDL that uses a sugared subset of the polyadic #-calculus for describing object service protocols, aimed at the automated checking of protocol interoperability between CORBA objects in open component-based environments. In addition, some advantages and disadvantages of our proposal are discussed, as well as some of the practical limitations encountered when trying to implement and use this sort of IDL extensions in open systems.

Abstract. To our point of view, adaptability is a key characteristic of components and should be at the heart of any proper component model. However, contrarily to the object crystal-box model of reuse, which assumes full access to the object implementation, this adaptability should be strongly guided in order to keep the necessary decoupling between the component producer and its consumers, another key characteristic of components. It turns out that the current component models and infrastructures fall short of conciling these two characteristics and only provide a superficial form of adaptation. Taking full advantage of the notion of component requires a deeper form of adaptation, which calls for considering program specialization tools and techniques as key elements of the component-based software engineering toolbox. 1

Abstract. The performance of a software component heavily depends on the environment of the component. As a software component only justifies its investment when deployed in several environments, one can not specify the performance of a component as a constant (e.g., as a single value or distribution of values in its interface). Hence, classical component contracts allowing to state the component’s performance as a post-condition, if the environment realises a specific performance stated in the precondition, do not help. This fixed pair of pre- and postcondition do not model that a component can have very different performance figures depending on its context. Instead of that, parametric contracts are needed for specifying the environmental dependency of the component’s provided performance. In this paper we discuss the specification of such dependencies for the performance metric response time. We model the statistical distribution of response time in dependency of the distribution of response times of environmental services. 1

There is some consensus in the aspect-oriented community that a notion of interface between joinpoints and advice may be necessary for improved modularity of aspect-oriented programs, for modular reasoning, and for overcoming pointcut fragility. Different approaches for adding such interfaces, such as aspect-aware interfaces, pointcut interfaces, crosscutting interfaces, explicit joinpoints, quantified typed events, open modules, and joinpoint types decouple aspects and base code, enhancing modularity. However, existing work has not shown how one can write specifications for such interfaces that will actually allow modular reasoning when aspects and base code evolve independently, and that are capable of specifying control effects, such as when advice does not proceed. The main contribution of this work is a specification technique that allows programmers to write modular specification of such interfaces and that allows one to understand such control effects. We show that such specifications allow typical interaction patterns, and interesting control effects to be understood and enforced. We illustrate our techniques via an extension of Ptolemy, but we also show that our ideas can be applied in a straightforward manner to other notions of joinpoint interfaces, e.g. the crosscutting interfaces.

Abstract. Web services are distributed software components, that are decoupled from each other using interfaces with specified functional behaviors. However, such behavioral specifications are insufficient to demonstrate compliance with certain temporal non-functional policies. An example is demonstrating that a patient’s health-related query sent to a health care service is answered only by a doctor (and not by a secretary). Demonstrating compliance with such policies is important for satisfying governmental privacy regulations. It is often necessary to expose the internals of the web service implementation for demonstrating such compliance, which may compromise modularity. In this work, we provide a language design that enables such demonstrations, while hiding majority of the service’s source code. The key idea is to use greybox specifications to allow service providers to selectively hide and expose parts of their implementation. The overall problem of showing compliance is then reduced to two subproblems: whether the desired properties are satisfied by the service’s greybox specification, and whether this greybox specification is satisfied by the service’s implementation. We specify policies using LTL and solve the first problem by model checking. We solve the second problem by refinement techniques. 1

The paper presents the reection facilities of the speci cation language Slam-sl. Slam-sl is an object oriented speci cation language where class methods are speci ed by pre and postconditions. The reection capabilities permit managing these pre and postconditions in speci cations what means that semantic reection is possible. The range of interesting applications is very wide: formal speci cation of interfaces and abstract classes, speci cation of component based software, formalization of design pattern, using Slamsl as a pattern language, etc. The paper discusses the last two advantages in some detail.