Latest News
2 Jan 2010: Treaty for Eclipse 2.1.1 released. Treaty is now dynamic, i.e. a contract registry is maintained when new bundles are installed/uninstalled. Treaty contains a new contract vizualisation framework (see snapshot below), and some example contracts for standard Eclipse extension points (some of which fail !). Contracts can now have triggers and actions (=they are based on ECA rules). This means that component lifecycle events can trigger contract verification. To try it, install the respective Eclipse plugins from the following update site: http://treaty.googlecode.com/svn/tags/release2.1.1/treaty-eclipse-updatesite/site.xml.
30 November 2009: We have submitted a proposal to talk about Treaty at EclipseCon.
26 March 2009: We have finished an experiment where we formalised existing contracts documented in Eclipse extension points, and then verified Eclipse against these contracts. There are some surprising results.
Introduction
Treaty is a contract framework for arbitrary component models. It supports the precise specification of relationships between collaborating components and verification with respect to these contracts. To explain this, consider a simple clock application in Eclipse (this application can be installed from the following update site: http://treaty.googlecode.com/svn/tags/release2.0.0/treaty-eclipse-updatesite/site.xml). The clock view provided by the plugin displays date and time, but the actual date formatting services are provided by additional plugin components. The relationship between these components is described by precise contracts that reference types defined in an ontology. The following contract types are used in the example:
- Java classes must implement Java interfaces (level 1 contracts) - used to provide date formatter classes implementing a given interface.
- XML instances must instantiate a given XMLSchema - used to provide date format strings, contracts are therefore "polymorphic" (like in Eclipse).
- Java classes have to pass JUnit functional tests (level 2 contracts) - used to make sure that data formatter implementation classes render at least date, month and the last two digits of the year.
- Java classes have to pass JUnit performance tests (level 4 contracts) - used to make sure dates can be rendered in <10ms - JUnit is used as well here. These are "quality of service" contracts.
- complex contracts: a plugin can either provide the class or the XML format definition, but not both (exclusive disjunction).
The prototype uses a verification service to check the system for integrity as defined by these contracts. This is useful in complex dynamic systems that change often as new services (components) are discovered and integrated. Treaty is not invasive: contracts are just text files added to the plugin meta data (example). Treaty is open: the contract vocabulary consisting of types and relationships has an open modular design. In particular, the underlying component model itself can be used to make contributions to the contract vocabulary.
Relevant publications
- Jens Dietrich, Graham Jenson: Components, Contracts and Vocabularies - Making Dynamic Component Assemblies more Predictable. In Journal of Object Technology, vol. 8, no. 7, November - December 2009, pp. 131-148 http://www.jot.fm/issues/issue_2009_11/article4/ . This is an extended version of the WCOP workshop paper.
- Jens Dietrich, Graham Jenson: Treaty - A Modular Component Contract Language. Proceedings WCOP'2008.
- Jens Dietrich, John Hosking, Jonathan Giles: A Formal Contract Language for Plugin-based Software Engineering. Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems (ICECCS 2007), pp. 175-184, 2007. DOI.
- Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, Damien Watkins, "Making Components Contract Aware," Computer ,vol. 32, no. 7, pp. 38-45, July, 1999. DOI - contract levels are defined here.
Miscellaneous
Treaty for Eclipse contains a custom JUnit that allows constructor dependency injection. See also the discussion on the JUnit mailing list about unit testing and dependency injection.
Todos
- Add triggers and actions to the contract language.
- Apply this to other component models: document components, pure OSGi, ..
