MSPLS Spring '95 Workshop
Abstract

Object Interactions as First Class Objects: From Design to Implementation

Collaborations between objects make up the dynamic behavior of OO software. These collaborations among objects require careful design and implementation. Treating the interactions as added responsibilities, that are integrated in the participating objects, results in tight coupling between objects. Tight coupling increases complexity and reduces reusability. Object interactions need to be first class objects from design to implementation. Our research provides a unified approach to model and implement these interactions as first class objects. During analysis and design, they are modeled using DynaSpecs. During implementation, they are coded with a new language construct called Compositions. Both constructs provide a consistent support for object interactions within each phase of the OO lifecycle.

Current OO methodologies model the static structure and dynamic behavioral aspects of OO systems. Static models use entity relationship diagrams to describe attributes in objects and their structural relationships. The dynamic model aim to describe the complex interactions between objects at run time. Interactions among collaborating objects are typically identified in the analysis phase through scenarios (use cases) that expose the functionality of the system. Most methods use object interaction diagrams to model interactions during the design phase. These diagrams capture the objects involved in the interaction and the corresponding flow of message passing. The interactions among objects encompass the assumptions that each makes about other. To understand objects interactions we need to know not just the associated message flow and the participating objects, but also what the state changes and interaction behavior of each the participating objects.

In current methodologies all this information is distributed over the entire spectrum of models: object models, operational models, interaction graphs and state machines. Furthermore, in the design of object classes, the behavior of interactions is scattered across the collaborating classes. This distribution of information and behavior across models increases the redundancy of information, complexity of the classes, and the coupling among classes. This result in difficulties to establishing invariants and properties of the system, difficulty in ensuring proper access to methods, and difficulty in ensuring consistent update of participating objects to reflect dynamic changes. Our model, DynaSpec supports the specification of objects and interactions as first class objects. DynaSpecs model the object interactions using state transitions. The state transitions represent events of message calls that mirror the dynamic behavior of object interactions. The formal semantics of the model is based on the idea of a history which captures the sequence of operations within interactions along with state changes undergone by the participating objects.

Current OO programming language allow programmers to implement object interactions as first class objects by using classes with variable references to participating objects. However, this implementation have the following disadvantages:

• the variable reference allow access to all public methods of the participating object, even methods that are not relevant to the relationship,
• there are no clear separation between participants in the class encapsulation, the participants are accessed through variables,
• in a statically typed language like C++, the participating objects must belong to the variable class type. A suitable participant from a different class type cannot be a participant safely.

• define of participants and their responsibilities,
• provide an explicit dynamic lifetime of an object interaction,
• restrict visibility to only methods of participants relevant to the interaction,
• facilitate reuse of interactions by allowing parameterized interactions, and inheriting Compositions,
• provide the necessary context to clearly separate responsibilities of participants, an encapsulation of the entire interaction, encapsulation of each participant and limited access to participating objects, and
• allow the selection of suitable participating objects based on the methods they implement, not the class hierarchy they belong to.