Method Driven Model: A Unified Model for an Object Composition Language

Chitra Babu and D Janakiram

Distributed Object Systems Lab, Dept. of Computer Science & Engg.,

Indian Institute of Technology Madras,

Chennai - 600 036, India.

Email: chitra@cs.iitm.ernet.in, djram@lotus.iitm.ernet.in

URL: http://lotus.iitm.ac.in

Abstract

Object-Oriented (OO) paradigm facilitates identification of pertinent domain objects as nouns. Often the domain verbs are

modeled as member functions associated with these objects. However, object interactions are also characterized by domain

verbs. The current OO programming languages lack suitable abstractions for modeling interactions among objects. To

overcome this limitation, we propose a unified model known as Method Driven Model (MDM) that employs a novel approach

for capturing object interactions using aspects. Each object in the proposed model is viewed as consisting of several aspects

from the identity and encapsulation perspective. Instead of viewing objects as being rigidly defined at compile-time, the

aspect run-time system weaves the aspects appropriately with the objects. The key features of MDM are that it enables State

Based Filtering(SBF) and eliminates Object Schizophrenia Problem (OSP).

Keywords: Object Identity, Aspect, Object Schizophrenia Problem

1 Introduction

Object-oriented modeling helps to conquer complex problems by providing a natural way of identifying pertinent domain

objects. OO analysis methods [1] suggest looking for nouns in the domain and map them to objects. Often the domain verbs

are modeled as member functions associated with these objects. However, identification of objects and member functions

constitutes only a small percentage of the effort involved in developing the entire application. Building large scale appli-

cations involves capturing meaningful object interactions through message passing. A well defined grammar imposing the

interaction rules pertaining to the proper composition of identified nouns and verbs is very much essential. While current OO

programming languages provide suitable abstractions for capturing domain nouns and functional verbs, they lack necessary

constructs that encapsulate object interactions.

Another major issue arises with current OO programming languages because of their lack of expressiveness in providing

distinction between object Behavioral eXtension(BeX) and Specialization(BeS). These are two different facets of modeling

object behaviors. Behavioral extension can be seen as an identity preserving phenomenon, whereas specialization produces

an object with a new identity. While class-based OO programming languages elegantly capture specialization, they lack the

ability to model dynamic behavioral evolution of a single object. This is due to the fact that the behaviour of an object gets

frozen at the time of its instantiation. Although prototype-based languages capture behavioral extension by a combination of

dynamic inheritance and delegation mechanism[2], they risk compromising encapsulation, and the safety normally provided

by static typing. A clear separation in modeling object behavioral extension from specialization requires building new

programming language constructs. These constructs need to address the issues of modeling object identity and type safety

with respect to abstraction and encapsulation.

The tight coupling between abstraction and encapsulation in traditional class-based OO programming languages is the ma-

jor obstacle that prevents them from suitably modeling evolving object behaviour. Systematic type-safe way of breaking the

encapsulation of objects is essential to address this issue. Glue object model[3] advocates loose coupling between abstraction

and encapsulation, thus enabling object behavioral evolution. However, relaxing the encapsulation causes the behaviour of

ACM SIGPLAN 61 Vol. 39(8), Aug 2004

a single logical entity to spread across multiple physical objects, which leads to a condition known as Object Schizophrenia

(OS)[4]. OS manifests itself through symptoms such as broken delegation, broken security and doppelgangers in the presence

of a message sending semantics such as delegation. This is mainly due to the asymmetric receiver-oriented OO messaging

semantics. OS itself is unavoidable in modeling evolving object behavior in general. Role modeling is one prominent area

where this holds true. If the possibility of occurrence of any of the associated symptoms of OS can be eliminated, the model

becomes free from OSP.

Further, while composing objects, it is just not enough to check signature compatibility of methods alone. More impor-

tantly, the semantic matching based on contractual assertions need to be ensured, so that software applications can be built

with reliability and robustness. If objects can intrinsically select the methods to be executed, based on their internal state, the

objects become active rather than passive entities.

In pursuit of the above goals, this paper proposes a unified Method Driven Model(MDM) for an object composition

language that uses a novel approach for representing objects from various aspect dimensions such as encapsulation, identity,

and contracts. The model also modularizes object interactions using aspects. The term aspect used in this paper differs from

its regular connotation in the context of the well known paradigm, Aspect Oriented Programming (AOP) [5]. In AOP, aspects

encapsulate orthogonal cross-cutting concerns such as security, logging etc, which span multiple classes. Moreover, such

concerns are derived from the problem domain and are external with respect to all the involved classes. In contrast, MDM

identifies aspects that are internal to classes. The class design in itself is aspect-oriented and the aspects model encapsulation,

identity and contractual obligations required in different contexts.

The rest of the paper is organized as follows. Section 2 provides an overview of the Method Driven Model(MDM) for

the object composition language. A formal way of defining object identity is explained in Section 3. The key benefits of the

model are summarized in Section 4. Section 5 discusses related works and section 6 concludes and suggests future directions.

2 Method Driven Model (MDM)

The paper proposes a generalized unified model for an object composition language, called Method Driven Model (MDM).

The key distinction of the model lies in designing objects as composition of various aspects such as encapsulation, identity and

contracts. Further, the model also views the object interactions as a meaningful grammar defined over the objects. Moreover

the model is built in such a way that the asymmetry towards receivers that characterizes the traditional OO messaging

semantics is eliminated. The methods are modeled as connectors and they dictate how much “encapsulation breaking”

should be done both on the sender and the receiver side.

Generally, a language supports a programming paradigm if it provides facilities that make it relatively easy, safe and

efficient to realize the style associated with that paradigm. If it takes an extraordinary amount of effort to build programs

conforming to the specific paradigm, it implies that the language does not provide inherent support for the technique. Hence,

it can be argued that even though current OO programming languages model object interactions through message passing,

they do not make it viable to dynamically modify the object interactions. This is due to their inadequate expressiveness. An

object composition language built upon MDM will facilitate dynamic composition of objects by providing first class status

to object interactions.

2.1 Overview

The key idea behind Method Driven Model is capturing object interactions elegantly using aspects. In this context, the

“aspect” should not be viewed in the traditional way of modeling a cross-cutting concern. In MDM, different factors related

to a given class are separately captured using aspects. The state of the object at any point in its life-cycle dictates the set of

aspects that should be weaved with the class. The fundamental entity in this model is a partial class, which comprises of:

�Composable-Aspects: The set of aspects that can be weaved with the partial class,

�Aspect-View: Visibility of the private attributes to other aspects,

� Private, Protected and Public attributes,

� Methods describing the fixed behavior,

�TypeMarker(TM): Declaration of methods describing the variable behavior.

ACM SIGPLAN 62 Vol. 39(8), Aug 2004

Aspect1

Weave

instantiate

Legend

Object

Partial Class

TM1

TM2

TM3

Aspect4

Aspect2

Aspect3

TM TypeMarker

Alternative Aspects

Figure 1. Class Design in MDM

Traditionally, the class acts as a template for the structure and behaviour of the objects instantiated from it. In our model,

the partial class also dictates the blueprint for the interactions that are possible for objects created from this template. The

class is called as “partial” because it becomes complete only after the proper TM method definitions are weaved based on the

state of the object.

Various considerations such as encapsulation, communication styles, contractual obligations, identity semantics and others

are captured using the construct aspect. This consists of the following units:

�Unit-Type: This unit specifies the category of the TypeMarker which can be one of “Part-of”, “using”, “in” or “out”,

and communication styles such as “delegation” or “consultation”.

�Unit-Encap: This unit defines the TM methods of the partial class. Inside this unit, replace keyword signifies the

definition of TM methods of category “Part-of” or “Using”. The keywords before and after are used for specifying

additional actions associated with TM methods that fall under “in” category.

�Unit-Identity: The rebinding of self can be specified by the programmer according to the specific problem needs.

�Unit-Contract: This unit specifies:

– the pre-conditions, which must be satisfied for this aspect to be weaved with an object

– the post-conditions that must hold before the aspect gets unweaved

– interdependencies among the TMs specified as an invariant

– the preconditions that need to be checked before a particular method execution

– the post-conditions that a given method must ensure at the end of its execution

�Unit-Style: This unit specifies the styles in which the objects should be composed, such as Pipe and filter, event etc.

Figure 1 illustrates the construction of a class in its entirety through weaving of suitable aspects along with the partial class

at the control points specified by the TypeMarkers. An aspect at the lowest granularity captures the behavioural extension

of a single object. Aspects can be nested within each other. A composite aspect characterizes the interaction between two

objects. A single object can participate simultaneously in more than one interaction.

2.2 Visibility of Variables

The access specifiers public, protected and private are used in their usual connotation, within the partial class. However,

private variables should be accessible to some of the aspects. Within the partial class, the keyword aspect-view is specified

with the keyword all, indicating that all the aspects can access the private attributes of this partial class. Within the aspect,

variables are declared with the name of the partial class following the derives keyword to indicate the applicable scope.

ACM SIGPLAN 63 Vol. 39(8), Aug 2004

Aspect

Object 1 Object 2

Figure 2. Interlocking Aspect

Another alternative strategy is to define the accessor methods “get” and “set” for all the private variables. Within the

aspect, these accessor methods can be declared as TM methods. For the TM methods declared in an aspect, the partial class

or other aspects could provide actual definitions. By parameterizing the behaviour of the aspect, its reusability is enhanced.

However, this option is rather expensive because every access to a private variable incurs a method call overhead. Hence in

this work, the former approach, namely, explicit encapsulation breaking by allowing direct access to the private variables has

been used throughout.

2.3 Aspect Instances

Traditionally, a class defines the blueprint of the objects that are instantiated from it. All these objects have their own

values for the variables defined in the class, but each distinct object has the same methods available to be invoked on it.

Analogously, the form of the aspect instance(aspin) is determined by the aspect. Each aspin has its own values defined for

the variables defined within the aspect.

2.4 Relationship between Aspects

Aspects can be nested within each other. A single aspect can comprise of multiple aspects where each aspect could

represent single or multiple TMs of the same class. Such aspects are not cross-cutting, as they are aspects of a single class.

On the other hand, aspects nested within a single aspect can be associated with different classes. In both of these scenarios,

the contract unit of the containing aspect will capture the dependencies among the contained aspects.

The degree of an aspect is defined as the number of objects whose interactions it captures. If an aspect is binding two

objects, its degree is 2. Figure 2 illustrates an interlocking aspect of degree 2.

Figures 3 and 4 illustrate an example involving aspect interactions.

2.5 Aspect Inheritance

An aspect can inherit from another aspect. Since an aspect encompasses a certain set of object interactions, the derived

aspect should specialize these interactions. If an aspect D is derived from B, the following actions are permitted.

� The TM category and communication style can be redefined. If a TM is of category “Part-of” in the base aspect, it can

be refined to “Using” in the derived aspect. However, the reverse is not allowed. The TM category “part-of” can also

be refined to “in” at the derived aspect level to introduce additional filtering actions at the receiving end.

�The TM method definitions provided in the base aspect can be overridden. Definitions can be given for additional TM

methods.

� The conditions defined in the contract section can be redefined in a consistent way. The preconditions should always

be strengthened and the post-conditions always be weakened.

Since meaningful object interactions constitute a standard design pattern[6], specializing an aspect amounts to refining

a design pattern. For example, the design pattern State refines Strategy[7]. The meaning of this refinement is, the

pattern State deals with a specialization of the problem addressed by the general pattern Strategy. Also, state design

ACM SIGPLAN 64 Vol. 39(8), Aug 2004

Partial class bank {

Composable−Aspects: CB1, CB2;

Aspect−View : all;

String[] customers;

public TM B {

public float calculateInterest(float amt) {

Aspect−View : all;

String name;

String accNo;

String address;

String accType;

public TM A {

public string setAccountType() { };

public string[] getAccInfo() {

SetAccountType();

if (accType = "checking")

// return checking account details

else

// return savings account details

}

}

Composable−Aspects: CB1, CB2;

Partial class customer{

}

}

}

Figure 3. Interacting Objects

Aspect CB1 {

Unit−Type {

Aspect C1, B1;

TM−Asp−Mapping {<C,C1>, <B, B1>};

}

Unit−Contract {

Enable C1 => Enable B1; // invariant

}

Unit−Style {

Operator "|"

// The following code should be executed after the contained

// aspects are weaved

CustomerObj.getAccountInfo();

}

} BankObj.calculateInterest();

// filtering of outbound messages are handled here;

Aspect C1 {

Unit−Type {

TM C "Part−of";

Comm−Style "delegation";}

Unit−Encap {

String getAccountType() {

accType = "Checking";

return accType;

}

}

Unit−Identity {

thisAspect = this;

}}

// aspect B1, CB2, C2, B2 are defined similarly

Figure 4. Aspect Binding of Objects

ACM SIGPLAN 65 Vol. 39(8), Aug 2004

pattern has a similar, but more specialized solution structure compared to the one associated with strategy pattern.

The aspect capturing the object interactions for strategy will not have any precondition or it may just have a trivial

precondition true. In the derived aspect, the precondition would be strengthened by specifying a particular assertion

capturing the object’s present state. This refinement of precondition deals with the specialized pattern State, whose

intent is to vary the behaviour of the object based on its current state.

3 Formalism for Object Identity

3.1 Present Usage of Type

In order to satisfactorily model object behavioural extension, formalization of the notion of Object Identity(OID) is re-

quired. In this section, the concept of type and usage of types in different languages are discussed.

Types, in general, help to enforce correctness of programs by imposing appropriate constraints. The fundamental objective

of a well-defined type-system is to minimize the possibility of run-time errors during program execution. Initially, procedural

languages modeled data alone as type. The most prominent data types are, integer, real, character and boolean. The type of

the data decides the storage layout for that data. By statically associating types with every constant, variable and function,

the type system allows the compiler to catch any inconsistency or type mismatch of expressions in codes.

In the context of object-orientation, some programming languages treat the concept of class and type as identical. Class

serves as a template for defining both structure and behavior. Any object instantiated from a given class conforms to the

structure and behavior dictated by that class. The static type system provides compile-time guarantees that whenever an

execution of a particular program causes an invocation of a certain functionality on these objects, they will be able to handle

the calls properly without throwing exceptions. This greatly improves the run-time efficiency. However, static typing offers

very limited flexibility, because it prematurely restricts the behavior of objects to only one type. Instead of binding the type

to a variable statically, the binding can be postponed until run-time. Such dynamic binding facilitates polymorphism which

greatly enhances the expressive power of OO type systems.

Although, the above perspective of “class-is-type” is easy to define, it has serious limitations. It does not provide separation

between interface and implementation, thus impeding object reuse[8] to a great extent. In order to alleviate this problem,

Java language modeled behavior alone as type. The interface construct of Java captures the abstract behavior alone. Even

though, a class can extend only one other class, it is allowed to implement multiple interfaces[9]. Thus, the interface construct

allowed the modeling of multiple inheritance without the associated pitfalls such as the diamond inheritance problem.

3.2 Modeling Object Identity as a Type

In this section, a novel approach to modeling object identity as a type is discussed. This approach allows the distinction

between the two notions of BeX and BeS to be formally explained.

Traditionally, whenever an object is created, it gets a unique identity by which it can be referred. An instance created

from a single class or a statically defined class composition structure, will map to a single unique identity. On the other hand,

if an object is dynamically composed out of multiple aspects, as in MDM, the composed object’s identity is an “AND” of

identities of the object and all the constituent aspects. It would be desirable if the phenomenon of behavioral extension of an

object retained the underlying object’s identity all the time. To this end, a novel way of modeling OID has been proposed. It

uses two levels of abstraction: one level for defining the type and another for defining the actual identity of the object.

In the first level, OID is captured as a type, (i.e) a set containing the name of the partial class and composition of names for

each possible partial class-aspect combination. At the second level, objects instantiated from this OID-Type will be assigned

object identities each of which will comprise a set of elements. This set is called as OID-Instance set. The elements of this

set are identity of the partial object and tuples corresponding to identities of partial object and appropriate aspect instances.

In this context, the identity of the partial object is the “self” that is defined according to denotational semantics[10] by finding

the fixed point of the generator function corresponding to the partial class.

Modeling OID as a type uniformly captures both BeX and BeS. Whenever BeS occurs, the sets OID-Type and OID-

Instance themselves will change for the specialized object. On the other hand, when the behavior of an object is extended,

the sets OID-Type and OID-Instance will remain the same for the extended object. However, the value of the identity type

will switch among the elements of the set, based on the current class-aspect structure that dictates the extended object’s state

and behavior. Further, the object identity is also governed by the specific tuple of self of object instantiated from the partial

class and self’s of the aspect instances.

ACM SIGPLAN 66 Vol. 39(8), Aug 2004

4 Benefits of MDM

4.1 State Based Filtering

Traditionally, message filtering[11, 12] is done during inter-object message communication in order to separate the mes-

sage control code and message processing code in a transparent way. This facilitates changing the message control code

dynamically without affecting the processing code. The filter relationship is the ability given by one object to another object

to intercept and manipulate the messages sent to it. The message filters are implemented using “in” TM methods. However,

the state of the object is not checked before plugging in a particular filter method. Only simple signature matching is done

and there is no semantic guarantee that the object is in the correct state while a particular filter is being plugged. Performing

appropriate filtering based on the state of the object is increasingly important in distributed systems and mobile systems.

In MDM, the presence of “Unit-Contract” within the aspect ensures that the state of the object dictates whether a method

should be filtered or not, and by which filter. The precondition specified in the “Unit-Contract” indicates the valid state of the

object in which certain filtering actions need to be taken. The key difference between MDM and the existing filter models

is that the object intrinsically decides when additional filtering actions need to be enabled. It is not controlled by an entity

external to the object. This is highly significant in distributed and mobile systems. The object can autonomously enable and

disable the filters to both incoming and outgoing messages based on its contextual environment.

In the present message filters, there is no general abstraction for filtering outgoing messages from an object. In distributed

systems, it is possible to realize filters on both client and server side. Nevertheless, the models lack a generalized mechanism

by which the outbound messages from any object can be intercepted in a transparent manner. In MDM, the “Unit-Style”

section of the contract provides an elegant way of performing filtering actions for messages that are leaving an object. If the

composition style is “Pipe”, the sequence of method dispatches corresponding to that style is specified. This will be an ideal

place where the outgoing messages can be trapped. After a method call on the object on the left side of “Pipe”, if the right

side of “Pipe” matches the “out” TM method signature, then the filtering actions specified in the TM method definition in

“Unit-Encap” are weaved and executed.

4.2 Elimination of Object Schizophrenia Problem

4.2.1 Object Schizophrenia Problem

Whenever the individual objects are composed, object identity needs clear semantics. Otherwise it results in a condition

known as Object Schizophrenia(OS) where the state and/or behaviour of what is intended to appear as single object is actually

broken into several objects where each object has its own identity[13]. This is characterized by either broken or split identity.

When there is OS, the presence of message forwarding semantics such as delegation causes Object Schizophrenia Problem.

This manifests itself through symptoms such as broken delegation, broken assumptions, broken security and doppelgangers.

Broken identity results in incorrect binding of a message to an object that is not supposed to respond, whereas split identity

causes the problem of dangling references which is also known as doppelgangers. In the following subsections, we will

explain how MDM tackles these symptoms.

4.2.2 Doppelgangers

Whenever a composite object holds reference to several “nominally part-of” objects, these inner objects are accessible

independently as well as from the outer composite object’s reference. This scenario is illustrated in Figure 5. If a client

directly disposes an inner object through the independent reference, then the outer reference to that disposed object becomes

a dangling reference. If any attempt is made to access the object through the outer composite reference, it results in a

problematic scenario known as doppelgangers.

In MDM, while a particular aspect is unweaved, the postcondition can specify that all the references to this unweaved

aspect should be NULL. If the postcondition is violated, then appropriate exception handling routines can be invoked where

the dangling references can be properly set back to NULL. The postcondition thus acts as a guard and catches any possible

anomalies.

ACM SIGPLAN 67 Vol. 39(8), Aug 2004

Composite Object

independent

inner reference

Outer reference

Legend:

nominally part−of

object

Figure 5. Doppelgangers

(Role Playing Object)

Clerk DepartmentManager

EmployeeStudentMary

Figure 6. Object Playing Multiple Roles

4.2.3 Broken Delegation

In role modeling scenario, when one intrinsic object plays several roles simultaneously, the roles themselves are organized

in a hierarchy so that the commonalities can be abstracted and reused. Figure 6 illustrates a sample scenario, where a

person Mary plays the roles of student, employee, clerk as well as Department Manager(DM). The roles clerk and DM are

specializations of the employee role. If a client sends a message “getSalary()” to the DM, and DM does not have the method

to respond to that message, the message will automatically be forwarded to employee. If the method is found in employee,

while executing that, it may invoke “getBasic()” which should be bound to the DM instance, not to the local employee

instance. This is what is necessary for ensuring proper delegation semantics. Instead, if the “getBasic()” of employee is

invoked, it causes broken delegation.

In MDM, new keywords thisAspect and thisForwardingAspect have been introduced similar to this which hold the refer-

ence to the current aspect that responds to a message and the reference to an aspect which forwarded the message. Whenever

a message is forwarded, a global flag is set. When an aspect receives a message, it checks this flag and based on the value it

infers whether it is a directly received message from a client or a forwarded message. If it is a forwarded message, the self of

the aspect, thisAspect is rebound to thisForwardingAspect. This self rebinding semantics is specified in the “Unit-Identity”

section of the aspects.

4.2.4 Broken Security

If messages received by one role are indiscreetly forwarded to roles upward in the hierarchy, it might violate the security

associated with that role. The security policy should be such that only if the forwarding role has the necessary privileges to

get certain information from the higher level roles, should the message be answered. Otherwise, a security exception should

be raised. Presently, there is no elegant solution for solving this particular OSP symptom. In MDM model, the condition

under which a given message should be answered is captured as an assertion inside “Unit-Contract”. In the current example,

if it needs to be ensured that the messages received at the employee role instance level should be denied response, in case

they are forwarded from clerk, the corresponding assertion inside “Unit-Contract” of employee aspect is as follows:

ACM SIGPLAN 68 Vol. 39(8), Aug 2004

instance-of(thisForwardingAspect) != C1 OR C2

where C1 and C2 correspond to two different aspects for clerk role.

5 Related Work

5.1 Object Composition

For modeling dynamic behaviour of an object, object composition is a better mechanism compared to class level inher-

itance. Object composition is defined dynamically at runtime by means of objects acquiring references to other objects.

Even though class-based OO languages facilitate object composition through aggregation, they do not provide support for

delegation semantics at a language level. For example, Strategy design pattern[6] attempts to capture dynamic behaviour by

combining inheritance and aggregation. However, this attempt results in explicit forwarding of messages along the aggrega-

tion relationships which can possibly cause broken delegation. Alternatively, there are indirect ways of simulating the effect

of composition by a combination of aggregation and a passed reference to self as an argument to the forwarded messages.

This process is cumbersome and error-prone.

There are few models that have been proposed in literature that address behavioural evolution of objects: glue model[3],

context relations model[14], contracts[15] composition filters model[12] and rondo model[16, 17]. The first two models

focus on separating the invariant and variant behaviour of objects and composing them at runtime. However, they both deal

only with the behavioural extension of a single object. They do not address the issues related to composing individual objects

while coordinating their behavioural extensions too. Contracts include the specifications of the participating objects and their

contractual obligations. Although, they focus towards coordinated behaviour of objects, they do not address issues of object

identity and object schizophrenia that arise while composing objects. The major aim of composition filters model is to specify

filters in the class so that both incoming and outgoing messages can be intercepted and manipulated. Nevertheless, the object

cannot autonomously change the filters at runtime based on its state. Rondo model provides an additional abstraction in

between the class and an object called class-combiner. Instead of an object being rigidly associated with a class, it changes

its behavioural landscape according to the blueprint of the class-combiner which combines classes based on specific rules.

However, there is no generalized abstraction for interactions among objects in this model.

5.2 Aspect Oriented Composition

Aspect orientation[5] is a technique for improving separation of concerns in software by modularizing orthogonal cross-

cutting concerns. Aspect Oriented Languages(AOLs) are designed with this objective in mind. The focus of these languages

is to provide a modular construct for describing global system level concerns such as logging, locking and authentication,

which cut across class boundaries. When current OO languages are used to capture these concerns, the method invocations

pertaining to these concerns are scattered across the classes, resulting in tangled code. Prominent AOLs such as AspectJ[18]

provides constructs for specifying the different control points in various classes and the corresponding code that should be

executed when control flow reaches those points. Another AOL AspectCOOL[19] enables separate compilation of component

and aspect code, where aspects can be applied on already compiled components to improve reusability of components.

Even though this paper uses the term aspect, its functionality is entirely different from its counterpart in AOLs. In AOLs,

the aspect encapsulates a global concern which affects several classes. However, in MDM the aspect modularly encompasses

the object interactions in an elegant way. Using MDM, the designer is forced to focus in the early stages of class design itself,

on the possible interactions between objects instantiated from a given class and the remaining objects in the application.

5.3 Subject Oriented Composition

Subject-Oriented Programming (SOP)[20], and its successor Multi Dimensional Separation Of Concerns (MDSOC) define

various views of a single class. It also provides explicit composition operators for merging these different views. HyperJ[21]

is a language designed based on this paradigm. While AOLs distinguish a primary core dimension from aspects which are

secondary, HyperJ treats all dimensions equally. Instead of using join points, HyperJ defines the relationships between the

dimensions and also describes how they can be merged. In HyperJ, the primary motivation is building a class based on several

dimensions. However, object interactions are not typed in HyperJ. MDM primarily focuses on capturing object interactions

using aspects.

ACM SIGPLAN 69 Vol. 39(8), Aug 2004

6 Conclusions

A unified Method Driven Model for an object composition language is proposed in this paper. The key idea underlying

our model is the design of classes in an aspect-oriented fashion. By modularizing and capturing object interactions using

aspects, a well-defined grammar can be imposed over the domain objects. Instead of viewing objects as being rigidly defined

during compile-time, the aspect run-time system weaves the aspects appropriately with the object. The distinct feature of

the model is that it facilitates State Based Filtering that is highly significant in distributed and mobile systems. The model is

also unique in its ability to break the asymmetry that arises from the current receiver-centric OO messaging semantics. Since

aspects are modeled as connectors abstracting the interactions between sender and receiver objects, the self can be rebound

to the proper object based on the intended communication style.

References

[1] Peter Coad and Edward Yourdon. Object-Oriented Analysis. Prentice Hall, 1990.

[2] H. Lieberman. Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems. In Proceedings

of the First ACM Conference on Object-Oriented Programming Systems, Languages and Applications(OOPSLA), pages

214–223, September 1986.

[3] D. Janaki Ram and O. Ramakrishna. The Glue Model for Reuse by Customization in Object-Oriented Systems. Tech-

nical Report IITM-CSE-DOS-98-02, Indian Institute of Technology, Madras, India, 1998.

[4] C. Sekaraiah and D. Janaki Ram. Object Schizophrenia Problem in Modeling Is-Role-Of Inheritance. In Proceedings

of the Inheritance Workshop conducted in ECOOP 2002, 2002.

[5] G. Kiczales, J. Lamping, A. Mendheker, C.Maeda, C. Lopes, J. M. Loingtier, and J. Irwin. Aspect-Oriented Program-

ming. In Proceedings of ECOOP 1997, pages 220–242, Finland, June 1997.

[6] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Object-Oriented Software Architecture.

Addison-Wesley, 1995.

[7] L. Tahvildari and K. Kontogiannis. On the Role of Design Patterns in Quality-Driven Re-engineering. In Proceedings

of the 6th European Conference on Software Maintenance and Reengineering (CSMR ’02), 2002.

[8] Sheng Yu. Class-is-type is Inadequate for Object Reuse. ACM SIGPLAN Notices, 36(6):50–59, June 2001.

[9] K. Arnold and J. Gosling. The Java programming Language. Addison-Wesley, 2000.

[10] W. Cook and J. Palsberg. A Denotational Semantics of Inheritance and its Correctness. In Proceedings of the Fourth

ACM Conference on Object-Oriented Programming Systems, Languages and Applications(OOPSLA), pages 433–443,

October 1989.

[11] R.K. Joshi and D. Janaki Ram. Message Filters for Object-Oriented Systems. Software-Practice and Experience,

27(6):678–699, 1997.

[12] M. Aksit, K. Wakita, J. Bosch, L. Bergmans, and A. Yonezawa. Abstracting Object Interactions Using Composition

Filters. In R. Guerraoui, O. Nierstrasz, and M. Riveill, editors, Proceedings of the ECOOP Workshop on Object-based

Distributed Programming, pages 152–184. LNCS, Springer-Verlag, 1993.

[13] IBM SOP Web Page. http://research.ibm.com/sop/sopcpats.html.

[14] L.M. Seiter and K.J. Lieberherr. Evolution of Object Behavior Using Context Relations. IEEE Transactions on Software

Engineering, 24(1):79–92, January 1998.

[15] R. Helm, I.M. Holland, and D. Gangopadhyay. Contracts: Specifying Behavioral Composition in Object-Oriented

Systems. In Proceedings of the Fifth ACM Conference on Object-Oriented Programming Systems, Languages and

Applications(OOPSLA), pages 169–180, October 1990.

ACM SIGPLAN 70 Vol. 39(8), Aug 2004

[16] M. Mezini. Supporting Evolving Objects Without Giving Up Classes. In Proceedings of the 18th TOOLS Pacific

Conference, pages 183–197, 1995.

[17] M. Mezini. Variational Object-Oriented Programming Beyond Classes and Inheritance. PhD thesis, University of

Siegen, Germany, 1997.

[18] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W.G. Griswold. An Overview of AspectJ. In Proceedings

of the 15th European Conference on Object-Oriented Programming (ECOOP 2001), pages 327–353, 2001.

[19] E. Avdicauisevic, M. Lenic, M. Mernik, and V. Zumer. AspectCOOL: An Experiment in Design and Implementation

of Aspect-Oriented Language. ACM SIGPLAN Notices, 36(12):84–94, December 2001.

[20] W. Harrison and H. Ossher. Subject Oriented Programming(a Critique of Pure Objects). In Proceedings of the Eighth

ACM Conference on Object-Oriented Programming Systems, Languages and Applications(OOPSLA), pages 411–428,

September 1993.

[21] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton. N Degrees of Separation: Multi-Dimensional Separation of Concerns.

In Proceedings of 21st International Conference on Software Engineering, pages 107–119, May 1999.

ACM SIGPLAN 71 Vol. 39(8), Aug 2004