Latest News

Public presentations on Object Teams in reverse chronological order.


Introduction ot Object Teams (May, 2010)
Stephan Herrmann
Object Teams: The Next Dimension of Modularity
GeeCON 2010, PoznaƄ, Poland.
Slides: Download PDF

Object Teams is a new approach towards modular architectures, which recently moved from the research labs to Object Teams takes on where object-orientation leaves the developer with difficult trade-offs. This regards typical tensions between modularity, re-use, encapsulation, extensibility, maintenance and evolution. Architectures that are bloated by the use of complex design patterns are another sign of insufficient capabilities of the object-oriented toolbox.

With Object Teams, architects are no longer forced to choose between a textbook version of OOP, where bloated business objects carry all their state and behavior, or a pragmatic use of OOP, where monolithic use cases are the central focus and entities degrade to mere data records. Neither approach provides for good modularity regarding objects AND use cases.

In order to mediate between both views Object Teams introduces "roles" as a new kind of classes and objects. A role represents that slice of an object that contributes to a given use case. A role is bound to a base object which defines the intrinsic properties of an entity. Roles can be added to/removed from a base object as the object enters or leaves the context of a use case. This context is furthermore modeled as a "team". A team contains all roles contributing to the given use case. By means of declarative method bindings between a role and its base, adding a new use case to an application becomes a purely additive task. This significantly raises the evolvability of an application without compromising its crisp modular architecture.

Persistence for Object Teams with JPA and EclipseLink (Nov/Dec, 2009)
Stephan Herrmann
Adapting EclipseLink for Object Teams, of course using Object Teams
Eclipse Demo Camp  Berlin (Nov 23)
Slides: Download PDF
Abstract: The JVM is a popular platform not only for Java but for a variety of languages. All these languages promise in some kind the access to the wealth of Java libraries. The JPA, however, is a special case as it is intimately connected to Java.

As an example of current JVM languages, OT/J extends the Java programming language with the concepts of Object Teams, which brings two new flavors of classes: teams and roles. With teams and roles all use-cases of an application can be cleanly separated, regardless their inherent interdependencies or even overlap. However, in order to apply OT/J in a business setting, interoperability with existing libraries, and specifically persistence frameworks, has to be shown or established.

The JPA implementation EclipseLink has been successfully adapted for persisting instances of team and role classes. This presentation will discuss special challenges towards referential integrity including lazy loading. Also some difficulties caused by differences between source code and the generated byte code will be touched.

Like the Object Teams Development Tooling itself, the adaptation of EclipseLink has been achieved in non-invasive ways using OT/J for its own implementation.

Comprehensive Overview of Object Teams (July 9, 2009)
Stephan Herrmann
Object Teams: Programming with Contextual Roles
Summer School at ECOOP 2009, Genova, Italy.
Slides: Download PDF
Abstract: From the early days of object orientation it is well-known that inheritance between classes and delegation between objects provide similar capabilities. While each approach has its specific strengths and limitations, only few programming languages support a combination of both. The concept of roles provides an excellent intuition for objects that are instances of a class and also delegate to a base or parent object.

Early attempts of integrating the role concept into an object oriented language add accidental complexity to programs because one important property of roles had been neglected: roles depend on context. More recent languages thus reify the context in which roles live as "teams" (ObjectTeams/Java (OT/J)) or "institutions" (powerJava) etc. Of these languages OT/J is an excellent representative due to the maturity of the language and its tools.

Steimann has identified 15 criteria from what various authors had considered relevant for the role concept. OT/J supports all 15 criteria.

OT/J has been thoroughly integrated with Java, accounting for all relevant features of Java up-to version 6, as documented in the comprehensive language definition.

Furthermore, team inheritance treats roles as virtual classes and fully implements the concept of family polymorphism, with additional options towards more strictness (in terms of object confinement) and towards more flexibility (in terms of migration between teams). For typesafe substitution of roles and bases, OT/J introduces translation polymorphism, realized by the implicit translations "lifting" and "lowering". With smart lifting a powerful mechanism is provided for mapping an inheritance hierarchy of base classes to a similar, but potentially different, hierarchy of role classes. Finally, several mechanisms for activating and deactivating a team support the notion that roles can be interpreted as a specific form of disciplined aspects, where aspect bindings utilize and extend the power of Java generics to overcome typing issues that have been identified in AspectJ.

Summarizing, OT/J is a modern extension of the object oriented paradigm, borrowing from several approved concepts, combining all into a mature language. This language is supported by an industrial strength development environment based on and deeply integrated with the Eclipse JDT.

Object Teams in MDSD (May 25 & June 23, 2009)
Marco Mosconi
Modular EMF/GMF customization with ObjectTeams/Java — case study: UML2 Tools —
Eclipse Demo CampHamburg (May 25) & Leipzig (June 23), Germany.
Slides: Download PDF
  • Are you developing with model-driven frameworks, like EMF or GMF?
  • Do you sometimes ask yourself where all those places in the generated code are that you (or your colleagues) once had customized for feature XYZ?
  • Are you sure that you and your colleagues always remembered to mark custom code with generated NOT, before running the generator next time?
  • Do you also have the dream of never touching a single line of generated code again?
The presented solution to these problems is based on the aspect-oriented mechanisms and role-based modularity of ObjectTeams/Java. Our case study shows how we were able to extract 100% of the invasive code customizations from the Eclipse UML2 Tools project and transform them into a modular, feature-oriented structure. The result is a clean separation of generated and hand-written code.
OT/Equinox (March 25, 2009)
Stephan Herrmann
Plugin reuse and adaptation with Object Teams: Don't settle for a compromise!
Long Talk at EclipseCon 2009, Santa Clara, USA.
Slides: Download PDF
new: Recording: View Demo  —  published at Eclipse Live Eclipse Live
Abstract: When reusing existing plugins for something innovative, you're likely to do things the original plugin author has not anticipated. This typically brings about some kinds of compromise:
  • You adjust your requirements to what the reused plugins provide.
    Thus you settle for a different product than you intended.
  • Or, you refrain from reuse but develop everything from scratch,
    settling for much lower productivity.
  • Or, you apply some brute force method (like copy&paste) to get your job done,
    but then you settle for a brittle design, that is a pain to maintain.
With Object Teams it is possible to eat the cake(apply unanticipated adaptations by disciplined aspect bindings)and still have it(sustain a well modularized, maintainable design).OT/Equinox brings this power to the development of Eclipse plugins (Equinox bundles).

This demo will show several real world examples from the implementation of the OTDT itself. Included are adaptations of a variety of plugins like JDT, Debug, PDE, JUnit, Workbench etc.

Object Teams Development Tooling (March 20, 2008)
Stephan Herrmann
The Object Teams Development Tooling: A high fidelity extension of the JDT
Long Talk at EclipseCon 2008, Santa Clara, USA.
Slides: Download PDF
Abstract: In this talk the Object Teams Development Tooling (OTDT) is presented which extends the full set of the JDT's functionality for programming in ObjectTeams/Java (OT/J).
OT/J, in turn, extends the Java language with support for role-based and aspect-oriented development.

High fidelity extension. When developing the Eclipse-based IDE for the Java-based programming language OT/J it was a high goal to reproduce the high quality of the JDT for the new language. By a high fidelity extension of the JDT for OT/J we mean an environment where
  • all features of the JDT work on OT/J source, too,
  • the look and feel of the JDT is preserved throughout,
  • JDT-features are aware of OT/J semantics and provide additional, OT/J-specific assistance.

The Object Teams Development Tooling. I will give a comprehensive walk through the JDT showing how the original functionality is available in the OTDT and how this functionality is extended to also reflect and support the new concepts and features of OT/J. Examples include syntax highlighting, eager and incremental compilation, code navigation, structure viewers, search, code assist, refactoring and debugging, all of which have been extended to reflect the new elements of OT/J like team and role classes, an enhanced inheritance relation for teams, and method bindings inducing new kinds of control flows etc.
See also the OTDT List of Features.

Enabling Technology. The talk will furthermore present the technology that made possible this high fidelity extension. In contrast to other projects that apply an architecture with loose coupling between a custom compiler and Eclipse, the OTDT employs deep integration to consistently leverage the JDT, without being limited by the set of existing API and extension points, which naturally can never accommodate all potential use cases of all possible extensions.
The obvious problem with such deep integration is the significant effort it costs to adapt the JDT in-place and to maintain such a fork. The OTDT preserves maintainability by applying OT/J for its own implementation. Using OT/Equinox as the technical integration, a number of aspect plug-ins host the adaptations we had to apply to existing plug-ins such as the JDT UI. This allows us to concentrate our adaptations in a single location even without editing the original plug-in. Thus, our approach combines the maintainability of a loosely coupled approach with the feature-richness of a deep integration.