TRESE Aspects and advanced separation of concerns homepage

The Separation of concerns principle

One of the most important principles in software engineering is the separation of concerns principle [3]. This principle states that a given problem involves different kinds of concerns, which should be identified and separated to cope with complexity and to achieve the required engineering quality factors such as adaptability, maintainability, extendibility and reusability.

The principle can be applied in various ways. For example, separation of phases in the engineering process can be seen as a separation of engineering activities in time and goal. Defining sub-systems, objects and components may be seen as realizations of separation of concern principle in software. We can give many more examples and correspondingly, it is no exaggeration to state that the separation of concerns principle is an ubiquitous software engineering principle.

Concerns

Despite a common agreement on the necessity of the application of the separation of concerns principle, there is not a well-established understanding of the notion of concern. For example, in object-oriented methods the separated concerns are modeled as objects and classes, which are generally derived from the entities in the requirement specification and use cases. In structural methods, concerns are represented as procedures. In aspect-oriented programming, the term concern is extended with the so-called non-functional properties such as synchronization, memory management and persistency. In a sense one can consider this as a generalization of the notion of concern in the context of programming languages. Although we consider this as a natural development, it increases the necessity of renewed understanding of what concerns are because concerns are not anymore restricted to objects and functions. Moreover, the task of separating the right concerns is complicated because one has now to deal with larger set and variety of concerns.

Concerns from the problem-solving perspective

In this section we will discuss the notion of concern. For this we consider software development as a problem-solving process in which a software solution is searched for the given requirements. Typically, this can be expressed as follows:

R-> S

whereby R represents the requirements, S the solution and the arrow -> represents the transformation process. For example, for the design of a distributed system the requirements R may be the preservation of consistency under the presence of failures. The solution S may be represented by a failure recovery protocol.

It is generally assumed that the requirements R include the specification of the relevant problems. In practice, however, finding the right problems and expressing these in the right way is not a trivial task. To simplify this, it is worthwhile to provide an intermediary phase in which the relevant problems are abstracted using the initial requirement specifications:

R-> P -> S

Hereby, P represents the actual problem for which a software solution is sought. In the example of failure recovery, P may represent the problem of designing a transparent failure recovery algorithm.

Let us now consider the solution model S in more detail. Basically, we can define S as a set of abstractions and relations that fulfills a specific role.

S = (SA, SR)

Hereby SA represents the set of abstractions (sa₁, sa₂, sa₃, .. ,sa_n) and R represents the set of relations among these abstractions (sr₁, sr₂, sr₃, .. ,sr_m). In theory, for a given problem P, numerous solutions may be possible. The quality of individual solutions is proportional to the degree in which they meet the following properties:

Relevance property

The solution S is required to meet the goal and constraints of the problem P. That is to say, S should be relevant, and as such is valid for the context as defined by P.

Canonical form property

The solution S should include necessary and sufficient abstractions to provide a relevant solution. Further, it should not include irrelevant and/or redundant abstractions. In other words, S should be generic and succinct, that is, canonical.

The relevance property ensures that the right solution is searched for the right problem. The canonical form property inherently reduces unnecessary complexity.

Given this model of software development we define a concern as follows:

Concern
A canonical solution abstraction that is relevant for a given problem.

Note that this definition implies that the concerns are not absolute but relative with respect to the considered problem. What may be a concern for one problem may not be a concern at all for another problem.

Since a concern is defined as a generic abstraction this means that it represents a set of possible instances of that concern. This implies that we can derive different alternatives from the given solution model. To explicitly reason about the set of alternatives of a solution model we present the following set of definitions [5][6]:

dimensions.gif (4125 bytes)

Figure 1. A visualization of a three-dimensional design space for a solution abstraction SA = (sa₁, sa₂, sa₃)

Design Space
A multi-dimensional design space representing the set of alternative solutions for a given problem.

Dimensions
Orthogonal representations of concerns spanning a design space of a solution abstraction. A dimension includes a set of alternative elements.

Coordinate
An element of a dimension representing an alternative instantiation of the concern.

Alternative
A composition of a selection of instances of concerns in a solution model. Alternatives are represented as points in the design space. A point is a set of coordinate elements of the individual dimensions.

Figure 1 provides, for example, a visualization of a three-dimensional design space that represents the solution abstraction SA = (sa₁, sa₂, sa₃).

Expressing concerns

To implement the design space we have to express the concerns in a given language. To provide certain quality factors, such as adaptability and reusability, the following is required for the adopted language:

	Represent concerns as first-class entities
	Provide compositional operators

The first class property means that the expressed concerns can be represented and manipulated individually. The language must provide a set of operators to compose the first-class entities. Let us explain these two requirements in more detail.

The first-class property of the concerns helps to increase the quality factors by localizing and expressing concerns separately. This means that given the set of solution abstractions as defined by SA = (sa₁, sa₂, sa₃, .. ,sa_n), we can define an abstraction model IA in a language such that:

IA = (ia₁, ia₂, ia₃, .. ,ia_n)

where there is a bijective mapping from SA to IA, that is, every abstraction in SA, can be separately represented by an abstraction in IA. Similar kind of mappings may be required for the set of semantic relations as defined by IR.

These requirements together lead to an implementation model I = (IA, IR), that forms an isomorphic model of the solution abstraction. We denote such a case in which the structure of the concerns in the solution model is preserved a structure-preserving transformation.

For every individual technical problem an ideal solution can be generated that requires a specific language in which all the concerns can be easily represented and the structure is optimally preserved. In practice, however, there is a huge set of technical problems that require different solution models with different concerns. Given the restricted time and resources of software projects, however, this is generally not a viable option and usually an existing and often a general-purpose language is used instead.

For a given problem, some languages are better in separating the concerns, and as such better in preserving the structure of the solution model, while other languages are less effective in this matter. In case the language is not expressive enough to either (1) represent the concerns separately and/or (2) provide the appropriate composition operators we say that the transformation from the solution model to the implementation model is anomalous and we denote this situation as a separation of concerns anomaly:

Separation of concerns anomalies

The situation in which a solution model is transformed to an implementation model, whereby the structure of the concerns as defined by the solution model is not preserved. Basically, for a given language and a given problem, the separation of concerns anomaly can occur in two ways:

Non-Separable Concerns

The concerns of the problem cannot be represented as first-class entities in the adopted language. Hereby, the original concerns of the solution model are scattered over many implementation concerns. This scattering is usually called cross-cutting [4].

The cross-cutting concern itself is defined as an aspect.

We may represent this as follows: sa_i -> {ia_j, ia_k, ia_l, … }, where the concern sa_i in the solution domain model is represented over more that one first-class entities {ia_j, ia_k, ia_l, … }.

Lack of suitable composition operators

The composition operators as defined by the language cannot appropriately compose the first-class entities that represent the separated concerns. We term this as a composition anomaly [1] [2].

Assume for example, that sa₃= sa₂ + sa₁ where the concerns sa₁ and sa₂ are composed together and yield the solution abstraction sa₃ using the composition operator + . There will be a composition anomaly if we cannot define a composition operator in the implementation language to realize ia₃= ia₂ + ia₁.

(See for example the E-tutorial "Evolution problems in object-oriented modeling": in powerpoint (1174KB), in zipped (340KB) or pdf format (1048KB))

Current Separation of Concerns Research

The following research activities explicitly address the separation of concerns problems:

	Composition filters;
	Aspect-oriented programming and AspectJ (Gregor Kiczales);
	The Demeter project (Karl Lieberherr);
	Multi-dimensional separation of concerns (Harold Ossher and Peri Tarr).

References

An historical perspective to our research activities can be found here.

Our publications on aspects and advanced separation of concerns can be found here.

M. Aksit and L. Bergmans, Guidelines for Identifying Obstacles when Composing Distributed Systems from Components, to be published in Software Architectures and Component Technology: The State of the Art in Research and Practice, M. Aksit (Ed.), Kluwer Academic Publishers, 2000.
L. Bergmans, B. Tekinerdogan, M. Glandrup & M. Aksit, On Composing Software from Multiple Concerns: Composability and Composition Anomalies. Dept. of Computer Science, Univ. of Twente, The Netherlands, submitted, August 2000.
E.W. Dijkstra, A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.
G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, J. Irwin, Aspect-Oriented Programming. In proceedings of ECOOP '97, Springer-Verlag LNCS 1241. June 1997.
B.Tekinerdogan & M. Aksit, Deriving design aspects from conceptual models. In: Demeyer, S., & Bosch, J. (eds.), Object-Oriented Technology, ECOOP '98 Workshop Reader, LNCS 1543, Springer-Verlag, pp.410-414,1999.
B.Tekinerdogan, Synthesis-Based Software Architecture Design, PhD Thesis, Dept. of Computer Science, University of Twente, The Netherlands, 2000.

This page was last modified by Mehmet Aksit on December 25, 2000.