Separation of Concerns
understand the ideas in AOSD we have first to look at the separation
of concerns principle, which can be actually considered one of the
key principles in software engineering. 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 robustness, adaptability,
maintainability, and reusability. The principle can be applied in
various ways and it is no exaggeration to state that the separation of
concerns principle is an ubiquitous software engineering principle.
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
crosscutting 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.
To provide a proper
definition for the notion of concern we argue that we should 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:
Hereby 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
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
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)
represents the set of abstractions (sa1, sa2, sa3,
.. ,san) and R
represents the set of relations among these abstractions (sr1,
sr2, sr3, .. ,srm).
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:
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.
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.
Obviously, for architecture design ensuring these above properties plays
a major role. Architectural components need to be relevant for the given
problem and ought to be canonical so that the right problem is solved in
the right way.
Given the above model
of software development we can now define a concern as follows:
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 for another problem. The generalization of concern
is the notion of concept. A conceptis usually defined as a
(mental) representation of a category of instances and is formed by
abstracting knowledge about instances . Concepts are not just
arbitrary abstractions or groupings of a set of instances but are
defined by a consensus of experts in the corresponding domain. As such
concepts are stable and well-defined abstractions with rich semantics.
In this context, we consider concerns as concepts that provide canonical
abstractions for solving a given problem.