Multi-Dimensional Separation of Concerns: An Overview

Separation of concerns is at the core of software engineering in general, and of object-oriented software development in particular. Done well, it can provide a host of crucial benefits: additive, rather than invasive, change; improved comprehension and reduction of complexity; adaptability, customizability, and reuse, particularly of off-the-shelf components; simplified component integration; and the ultimate goal of "faster, safer, cheaper, better" software.

To benefit fully from separation of concerns, one must have the right modularization at the right time: the concerns that are separated must match the concerns one needs to deal with. Unfortunately, different development activities often involve concerns of dramatically different kinds. For example, changing a data representation in an object-oriented system might involve a single class, or a few closely-related classes, and might be done additively using subclassing or suitable design patterns. Here the hallmark of object orientation--modularization by class (or object)--is a major asset. On the other hand, adding a new feature to a system typically involves invasive changes to many classes: the feature code is scattered across multiple classes, and tangled with other code within those classes. This reduces comprehensibilty and increases impact of change and the likelihood of error. In short, one needs different modularizations for different purposes: sometimes by class, sometimes by feature, sometimes by aspect (e.g., distribution or persistence), role, variant or other criterion.

We use the term multi-dimensional separation of concerns to denote separation of concerns involving:

• Multiple, arbitrary kinds (dimensions) of concerns.
• Separation according to these concerns simultaneously; i.e., a developer is not forced to choose a small number (usually one) of "dominant" dimensions of concern according to which to decompose a system at the expense of others. This separation must be more than just identification of concerns and of the code that pertains to each. It must include segregation (encapsulation) that is sufficient to limit significantly the impact of change. This does not mean that every change within a concern can affect only that concern; this is never possible. It means that, just as modules in a dominant decomposition localize the impact of many kinds of change and limit the impact (propagation) of others, so must this be true of any of the concerns. More precise definition of this requirement is an interesting topic for discussion and for further research.
• Overlapping or interacting concerns. It is appealing to think of many concerns as being independent or "orthogonal," but this is rarely the case in practice. It is essential to be able to support interacting concerns, while still achieving useful separation.

Recent approaches such as adaptive programming, aspect-oriented programming, composition filters, role-modeling and subject-oriented programming have enhanced object-oriented programming by providing separation of concerns along additional dimensions, beyond "class." Multi-dimensional separation of concerns is more general, and its goals are more ambitious, than these approaches; considerable research is still required before any existing approach fully achieves the goals listed above.

Hyperspaces are our approach to achieving multi-dimensional separation of concerns.

If you are interested in reading about the domain of multi-dimensional separation of concerns in more detail, check the list of currently available papers.

Still have questions? Click here to send us mail.

Return to hyperspace home page