To 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:

R→ S

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 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:

1.        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.

2.        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. 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:

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