Carlo Montangero (joint work with Laura Semini)
Dipartimento di Informatica - University of Pisa
Corso Italia, 40 - Pisa, Italy
FAX: ++39 050 887 226
cmontangero@di.unipi.it
http://www.di.unipi.it/~monta/
Abstract
Component-Oriented Programming (COP) aims at producing software components for a component market and for late composition. Composers are third parties, possibly the end user, who are not able or willing to change components. This requires standards to allow independently created components to interoperate, and specifications that put the composer into the position to decide what can be composed under which conditions. On these grounds, WCOP'96 led to the following definition: ``A component is a unit of composition with contractually specified interfaces and explicit context dependencies only. Components can be deployed independently and are subject to composition by third parties.''
Like in many other situations in software design, also in COP it is useful to divide and conquer, and that both the component developer and the component integrator can gain from this attitude. The concerns to be separated are functionality and coordination. Indeed, coordination defines the ways components interact to reach the common goals when they are composed in a larger system, and can be largely independent from the specific functionalities of a given application. The separation is useful both at the high (specification) level and at the middle (interoperability) level. At the specification level, where the component integrator operates, separating functionality and coordination helps in understanding how to compose the components at hand. Indeed, there are well established coordination patterns, that can be studied per se, and lessen the needed cognitive load when attacking a new composition. On the other side, i.e. when developing components, coordination defines the structure that the middleware must implement to allow the component to interoperate correctly. Separating coordination from functionality, we allow the independent implementation of specific coordination templates on the middleware of interest. For instance, coordination may lead to the definition of skeletons in some middleware, like CORBA, to be completed by the code implementing the functionalities implementing the component functionalities. More in general, we can say that coordination defines the implementation of the interoperability level of a framework.
Formal methods can play a major role in COP. Precisely because the actors are programmatically independent, they need to have reliable ways to share precise knowledge of the artifacts they use or produce, independently of the particular technology (programming languages, middleware, ...) they are using. Formal methods offer exactly this kind of independence and precision, since they provide abstract models to share when operating with components. For instance, they provide ways to understand the potentialities and limitations of a coordination pattern, without the need to consider the specific middleware in use. Also, they can provide ways to make precise the specifications of the components and of their contextual dependencies, and to prove in advance global properties of a given composition, i.e. that the composition will meet the specifications it addresses.
An ideal world would see a unique universal middleware for interoperability in COP. In the real world the situation is muddier, but a number of standards (CORBA, COM, DCOM) are emerging, and it is natural to consider them as targets of component development.
We are using a combination of formal methods and standard middelware to approach COP with the coordination based attitude described above. We expect that the presentation may trigger interesting discussions within the themes of the workshop, like Software Specification, Software Architectures, Frameworks and Patterns, Component specification and aggregation and Automated support.
Last Updated: May 15, 2000 by Elisabetta Ferrando