Frequently Asked Questions


This document has two sets of questions. The first set serves as a quick overview of coordination contracts and the tool for those in a hurry. The answers provide links to other documents for further details. The second set assumes basic knowledge of the concepts and methodology of coordination contracts and the tool; it covers some topics that may not be clear from reading the other documents.

The list of questions answered in this document is:

Introductory Questions

  1. What are coordination contracts?
  2. Are there any tools for coordination contracts? 
  3. Have coordination contracts been used in "real" projects?
  4. Where can I learn more about coordination contracts?
  5. How can I stay in touch with new developments?

Advanced Questions

  1. How are coordination contracts related to...
    1. aspects as in AOP?
    2. architectural connectors?
    3. primitives available in other coordination languages?
    4. design patterns?
    5. other notions of contract (e.g. Meyer's)?
  2. Your examples use coordination contracts at the business modelling level; can they be used at other levels (design, implementation)? Which languages can they work with?  
  3. What is the overhead that coordination puts on performance?
  4. Do contracts apply to instances or to classes? Do they define classes?

 

Introductory Questions

  1. What are coordination contracts?
    See Concepts and Methodology.
  2. Are there any tools for coordination contracts?
    The Coordination Development Environment (CDE) is a pair of tools to help develop Java applications using coordination contracts. One of the tools is an editor to write contracts and translate them into Java classes, which can then be compiled with the other classes that form the application. The other tool is an animator, with some reconfiguration capabilities, in which the run-time behaviour of contracts and their participants can be observed using sequence diagrams, thus allowing rapid testing of different scenarios. The Java classes generated for coordination contracts provide public methods that allow the applications to dynamically reconfigure themselves by creating and deleting contracts, and changing the values of their attributes. The CDE is written in Java and can be downloaded for free from www.atxsoftware.com/CDE. The document Guided Tour provides a guided introduction to the CDE. 
  3. Have coordination contracts been used in "real" projects?
    Not yet in a large-scale and not with the assistance of the CDE (just released!). The associated methodology has been used in projects that ATX has been developing for banks, to which the CDE will now be able to provide much needed assistance.
  4. Where can I learn more about coordination contracts?
    This FAQ is part of the CDE documentation which includes an introduction to the concepts and methodology of coordination contracts, and several examples to be tried out with the CDE. There are several papers and a set of tutorial slides on coordination contracts. All of them are available on-line. The document Publications provides an annotated bibliography to help you find the papers most suited to your interests.
  5. How can I stay in touch with new developments?
    There is a mailing list used by ATX Software to announce all its public activities, like the publication or update of documents, presentation of papers, tutorials or demos at conferences, release of software, etc. To subscribe, send a message to cde-list@atxsoftware.com

Advanced Questions

  1. What is the relationship between coordination contracts and...
    1. aspects as in AOP?
      Aspect-Oriented Programming shares some of the goals of coordination contracts: facilitate evolution, separate concerns, diminish conceptual complexity of the system. However, there are some important differences between the two approaches. Firstly, AOP addresses code/design modularity i.e. implementation-time modifications, while contracts are a modelling semantic primitive for dynamically superposing behaviour at run-time. Aspects are weaved into all objects of a given class but contracts are applied to specific objects. This means that it is possible to superpose, at run-time, by activating and deactivating contracts, different behaviour for different objects (e.g. charging of different instances of customers according to different schemes). With aspects this is not the case. Aspects can be plugged in or off, but it seems to be through recompilation and not at run-time, and not for different instances of the same class.  Actually, it is possible to define aspects for specific instances but the decision on which instances needs to be explicitly stated in the code (i.e at implementation time), which is not the case with contracts. Secondly, being a design and not a modelling technique, aspects face the same problem that we have identified for other techniques such as design patterns: Interactions are modelled at a low level and, therefore, aspects are not adequate for supporting an evolution process that takes place at the much higher level of abstraction in which business strategies and rules are defined. Although the solution provides a clean separation of concerns, it does not support the coordination of off-the-shelf components. Aspects and components are mixed at compile time, leaving out the possibility to plug-in other components afterwards. In other words, aspects are also useful, but for achieving code/design modularity and not for supporting modelling and run time modifications.

    2. architectural connectors?
      Software Architecture has put forward the distinction between components, which encapsulate the computational parts of the system, and connectors, which encapsulate the interaction parts of the system. As such, coordination contracts are connectors from an architectural point of view. However, the system construction methodology differs from what is usually prescribed in Software Architecture. Coordination contracts are "invisible" to components, which therefore are designed to interact directly among themselves. Architectural connectors, on the other hand, are mediators, in the sense that components interact directly with them, knowing the services provided by connectors. To put it succinctly, coordination contracts superpose interactions, connectors interpose them; superposition is not intrusive, interposing is.

    3. primitives available in other coordination languages?
      Coordination Contracts bring into conceptual modelling the ability to separate the description of the computational aspects that are responsible for establishing local functionalities of services within a system from the coordination aspects through which components cooperate or are regulated/adapted/monitored in order to make global properties emerge.  As such, coordination contracts are related to the primitives that have been proposed in the area of "Coordination Languages and Models".  An excellent introduction to this area can be found in "What Do You Mean, Coordination?" by F. Arbab, which appeared in the March '98 Issue of the Bulletin of the Dutch Association for Theoretical Computer Science (NVTI) (http://www.cwi.nl/pub/manifold/NVTIpaper.ps.Z)
      Coordination models and languages were born and have evolved around the notion of a shared dataspace, a centrally managed space which contains the pieces of data that processes want to communicate. This is the communication paradigm made available through the first coordination language: Linda and its Tuple Space (N.Carriero and D.Gelernter, "LINDA in context", Communications of the ACM 32:444-458, 1989).  Such models are usually called data-driven.  The coordination model that we have adopted for contracts is the dual one, i.e. is control-driven in the sense that components do not interact by sharing data but on the basis of shared actions or reactions to events.  In this sense, coordination contracts are closer to languages like MANIFOLD (http://www.cwi.nl/pub/manifold.html). Coordination contracts also share with MANIFOLD the fact they provide exogeneous models in the sense that they externalise the coordination features as first-class citizens (components, processes), which is not the case, for instance, of Linda.  There are many differences between coordination contracts and, say, the manager/coordinator processes used in MANIFOLD.  These differences stem, basically, from the fact that contracts were developed as a semantic primitive that should be usable within a conceptual modelling approach, say extending the UML, not withstanding their applicability at the design and implementation levels as well (read FAQ below).

    4. design patterns?  
      The models of cooperation that are used in most applications are, essentially, a set of ad-hoc templates that have been found to be useful in practice.  Indeed, many of the design patterns that can be found in the literature do provide solutions for coordinating components and the micro-architectures that we are using for deploying coordination contracts are based on well-known patterns (see, for instance, (http://www.atxsoftware.com/publications/tool.pdf).
      However, coordination contracts are more than a design solution.  They are a semantic primitive that supports a paradigm wherein we can systematically talk about cooperation and interaction between active entities and construct and evolve systems in a way that reflects the structure of the application domain.  That is to say, coordination contracts aim at  bridging the conceptual gap between the modelling of the cooperation aspects of an application and the lower-level communication model used in its implementation.  They can be seen as a higher-level linguistic counterpart of design solutions that lie in the middleware that is offered by popular software platforms and libraries for component-based development.

    5. other notions of contract (e.g. Meyer's)?
      The term 'contract' is, indeed, somewhat overloaded:
      • There are, of course, contracts in the sense of Meyer [B.Meyer, "Applying Design by Contract", IEEE Computer, Oct.1992, 40-51]; they fulfil a different, but complementary, role to coordination contracts: their purpose is to support the development of object methods in the context of client-supplier relationships between objects.  Therefore, they apply, essentially, to the "in-the-small" construction of systems rather than the "in-the-large" dimension that we have chosen as target and which is concerned with architecture and evolution.  In fact, in what concerns evolution, the use of Meyer's contracts in a non-architectural approach leads to some of the problems that lead to the proposal of coordination contracts: by adopting clientship as the basic discipline for object interconnection, a bias is introduced in the way business rules get coded up, assigning to the supplier side the responsibility for accommodating changes that, from the point of view of the business rules, belong to the client.
      • A notion of contract that applies to behaviours and not to individual operations or methods is the one developed in [R.Helm, I.Holland and D.Gangopadhyay, "Contracts: Specifying Behavioral Compositions in Object-Oriented Systems", in Proc. OOPSLA'90/ECOOP'90, ACM Press 1990, 169-180].  The aim of contracts as developed therein is to model collaboration and behavioural relationships between objects that are jointly required to accomplish some task.  The emphasis, however, is in software construction, not so much in evolution.
      • A notion of contract can also be found in [RJ.Back, L.Petre and I.Paltor, "Analysing UML Use Cases as Contracts", in UML'99 - Be-yond the Standard, R.France and B.Rumpe (eds), LNCS 1723, Springer Verlag 1999, 518-533.] that emerged in the context of the action-systems approach.  Like in our case, it promotes the separation between the specification of what actors can do in a system and how they need to be coordinated so that the computations required of the system are indeed part of the global behaviour. The architectural and evolutionary dimensions are not explored as such.
      • The importance of architectures for run-time software evolution has been recently pointed out  [P.Oreizy, N.Medvidovic and R.Taylor, "Architecture-based Runtime Software Evolution", in Proc. ICSE'98, IEEE Computer Science Press 1998]. The authors highlight the role of architectural connectors in mediating and governing interactions among components, which is essential for facilitating system evolution in the sense that we motivated in the paper.  However, the authors concentrate too much in presenting design and implementation solutions in the form of a tool set for a Java-C2 combination, missing the abstraction power that superposition provides as a general technique for enabling contract (or connector) based evolution, and the setting-up of semantic primitive which, like contracts, can be used in conjunction with general languages for object-oriented development like the UML.
      • Another recent architectural-approach to evolution that is important to mention is the one developed by [H.Evans and P.Dickman, "Zones, Contracts and Absorbing Change: An Approach to Software Evolution", in Proc. OOPSLA'99, ACM Press 1999, 415-434] in which a notion of contract is explicitly developed for managing exchanges between units of evolution.  These units, called zones, encapsulate processes, objects and types at design and run-time so that the contents of one zone can be evolved without affecting the code in another zone.  Contracts make the inter-relationships and communication between zones explicit by providing mechanisms - "change absorbers" - for transforming calls made on a pre-evolution type from outside the zone into a call onto the evolved type.  The emphasis is, therefore, very much on "lower-level" aspects of managing change during run-time evolution which, nevertheless, is a good indication of the importance of architecture-based approaches for all levels of evolution.


  2. Your examples use coordination contracts at the business modelling level; can they be used at other levels (design, implementation)? Which languages can they work with?  
    Contracts are a modelling primitive with precise semantics and an implementation strategy defined in terms of a micro-architecture that can be mapped to typical platforms for component-based development. In that sense, contracts can also be used at the design/implementation level. Moreover, the semantics of contracts is language and platform independent; its current implementation is in Java, but the micro-architecture we have proposed can be implemented in other OO languages.


  3. What is the overhead that coordination puts on performance?
    There may be a negative impact on performance due to the increased number of objects that the use of contracts implies. However, today, evolution is the rule of the game and that is the dimension for which contracts provide solutions. Still, if contracts are to be applied to performance critical systems, an assessment of potential performance bottlenecks may be necessary. If contracts actually have a negative impact, an idea would be to distinguish between evolution critical and performance critical parts of systems, and decide where to use contracts or not.


  4. Do contracts apply to instances or to classes? Do they define classes? 
    A contract has as participants one or more instances of one or more classes. So there may be different contract instances coordinating different class instances. This is important because different superposition of behavior is often required for different instances. For instance, charging different customers according to different schemes. Actually, this is the dynamic aspect of contracts: at run time, the system can be reconfigured activating and deactivating contracts so that new behavior can emerge. instance coordinating all instances of class types. At the implementation level, a contract defines a class that has to be instantiated with its participants. However, this class is not part of the class diagram of the system in the sense that it cannot be used by the other classes as a service provider. Contracts do not provide services at the same level as the other classes in the system. This is the major difference between contracts and the use of mediators. Mediators have to be called explicitly; contracts superpose interaction mechanisms without the partners involved being aware that they are being coordinated and how.










© Copyright 2001 ATX Software SA. All rights reserved.