Object Teams

In any software development that involves a certain level of complexity, is based on re-usable components and evolves over a significant period of time, there are typically some tensions between different people and sub-projects contributing to the overall code base. E.g., framework developers have to balance the flexibility of their framework with the safety provided by strong and strictly enforced encapsulation. Framework users (developers of components using the framework) will normally desire more (or just other) options for adapting the framework's behavior than what the framework already provides. Also, different developers may simply focus on different concerns that in the final code crosscut each other due to intricate dependencies. Put simply, these tensions tend to result from the necessity to create systems from a single coherent object oriented design. In order to overcome much of these tensions the Object Teams (OT) programming model has been developed, which is centrally based on the concepts of roles and teams. Roles have first been introduced for role modeling, where different perspectives are expressed by different models which then relate to a shared set of base abstractions (classes). Roles in Object Teams bring this power of multi-perspective modeling to the level of programming. Each role model is mapped to the implementation as a team class, whose contained roles implement those facets of objects that are relevant to the given perspective. In this approach explicit bindings between a role and its base entity provide powerful means for integrating a system from components. Here integration clearly means more than just creating a system as the sum of its components, but those bindings define significant parts of the communication in the resulting system. The benefits of developing in the Object Teams approach are twofold:

1. The code structure within each component can be much simpler and easier to understand because original concerns can faithfully be encapsulated as teams and roles, allowing for separate evolution of concerns over time. Any crosscutting interaction can concisely be defined using the mentioned bindings.
2. Re-use of existing components is greatly improved, because bindings between different components can create client-defined adaptations of a re-usable component in a concise and disciplined way. With Object Teams many of the compromises that are necessary with traditional approaches become obsolete.[1]

The Object Teams approach has been materialized at two levels.

• The programming language OT/J adds the concepts of Object Teams to the Java™ programming language. Development in OT/J is supported by a comprehensive IDE, the OTDT (Object Teams Development Tooling) [2], which builds on and extends the Eclipse Java development tools. Development of the OTDT has started in 2003 (based on Eclipse 2.1.1) to large parts under the umbrella of the publically funded project TOPPrax. After the 1.0 release in March 2007 new release have been published roughly every 6 weeks.
• The component runtime OT/Equinox [3] extends Equinox as to support so-called aspect bindings accross bundle boundaries. Thus, Equinox bundles (plug-ins) can be implemented in OT/J and explicit bindings connect an Object Teams bundle to other bundles in much more powerful ways than the traditional approach. OT/Equinox is being developed since 2006 and has been used for the implementation of the OTDT itself ever since.