Separation of Concerns: Techniques, Issues and Implications

[anitsh]

Separation of Concerns: Techniques, Issues and Implications

[anitsh]

Related Issue #1049

Define the concept of separation of concerns in detail

Decomposition is a fundamental principle of software engineering. Decomposition involves breaking down the system into smaller and more manageable parts, which at a requirements level generally corresponds to subdividing the overall problem into sub-problems that can be addressed independently. Concerns are abstractions of a given problem (Tekinerdogan & Aksit, 2000). They are a set of coherent issues based around a problem that has to be resolved. Concerns are generic abstractions but are highly relative to the problem. As a result, what might be considered a concern for a given problem might not be relevant at all for another problem. The definition of concern, however, does not provide a clear distinction of the granularity at which concerns should be viewed. The distinction is based more on the practical utility or the view taken about the concern. As a result, depending on the view taken of the definition, a concern can be either a small task like "Print a document" or a complete software artefact like requirements under- standing. A concern can be any element that is relevant in the development of a system.

Concerns as they stand can be separated into basic concerns and special purpose concerns (Hursch & Lopes, 1995; Aldrich, 2000).

Basic concerns within software are usually responsible for providing basic functionality and services to the client. The client of the system can be either the user, another program, or some other component of the system (Aldrich, 2000). The primary objective of basic concerns is to answer the functional needs of the system in a traditional manner and usually do not depend on any other aspect Vol. 15, No. 1-4, 2006 Separation of Concerns: Techniques, Issues and Implications of the system. The design style they support is to break the software down into components that can be called upon to perform some function. These components specify what is really important to the system and work accordingly. Classes and objects exist as a prime example for basic concerns. Classes and objects fit within the majority of existing programming languages and provide the perfect platform for decomposing the system into small parts, in which each part is assigned to perform some function. Both data and methods are defined within the classes, thus encapsulating (or hiding) the details from the outside world. Furthermore, inheritance and overriding mechanisms allow classes to modify and extend certain features without changing their inherent organization. Other examples can be application features and services, sub-routines, procedures, and functions.

Special purpose concerns are generally attributed to serve or manage the basic concerns within the system or fulfilling some special requirements for the system. Special concerns are usually performance related and accordingly play an auxiliary role to the basic concerns. Being crosscutting in nature, special purpose concerns do not affect any single module or domain but rather spread throughout the system functionality. Examples of special purpose concerns within the system can be concurrency or synchronization, persistency, real-time constraints, distribution, location control, or configuration, failure recovery, and replication.

Over the years, concerns have often been viewed in terms of software implementation. With all programming languages supporting decomposition along a single dimension, concerns are decomposed based around that predefined dimension. Dimension can defined as a combination of the decomposition unit and the means to assemble the units to make it a running program. For example, traditional systems based on the object-oriented paradigm often modularize the concerns based on a single dimension like class (Constantinides et al., 2000). This form of decomposition based on a single dimension can be acceptable when the problem can be solved through simple interfaces. With concurrent programming based on component technology, interactions no longer localize within a single modular unit, but rather tend to cut across the whole of system functionality. The reason for the latter being that component interaction in itself is based on a number of properties like synchronization, scheduling, and distribution, which affect the performance of the whole system; defining these along a single dimension is quite a challenging task. This manner of looking at concerns through a single dimension has been referred to as the "the tyranny of dominant decomposition" within the literature (Ossher et al., 1999). This view has made it quite difficult for designers to manipulate these properties under a single dimension and has resulted in many significant problems for the development and deployment of software.

As a direct consequence of the above limitation, it has become important to look at concerns from different dimensions or angles. Recently, several new techniques have emerged for organizing and composing concerns along different dimensions. These techniques are based on the premise that programming all concerns within a single block of code is often the reason for increased complexity and tangling problems. By abstracting and separating the concerns, programming then becomes substantially less complex and code can be effectively reused. Such techniques are assumed to directly support decomposition along different dimensions while remaining orthogonal to the basic concerns. The value of these techniques, however, will clearly depend
on overcoming two major hurdles. Firstly, with SoC techniques still at its early stages, the knowledge of key concerns and how they should be separated is very limited. Secondly, there exists little or no high-level scenarios or design mechanisms whereby concerns can be understood both individually and in relation to other aspects of the system. As a result, concerns are often just
directly implemented without understanding and knowing what effects it may have on the overall system.

[anitsh]

Comparative criteria for SoC techniques

These criteria serve a dual purpose:

1. To describe the main aspects of each technique
2. To form the basis of evaluation and comparison of the techniques analyzed

Criteria selected and their relevance to SoC

Criteria	Understanding of the technique and relevant description
Understanding of the technique and relevant description	Identification of Concern; Understanding of the sub-parts of a concern
Design Knowledge	Encapsulation and Decomposition of Concern; Design Capability
Composition of Concern	Integration of Concerns; Composition Rules
Language Support	Provides knowledge about implementation abilities of the technique; Highlighting the relationship between design and implementation
Overlapping Concern	Establishes the relationship between intersecting concern

Comparing the relevance of any technique to its cause requires a thorough understanding of the technique itself, requiring the technique to identify which dimension(s) of concerns it has to target and to identify how the units are to be populated within the concerns. This identification makes explicit all the concerns of interest along with the detailed understanding of the requirements of the various concerns.

[anitsh]

Design Knowledge

Design knowledge of the system has often been referred to as one of the most important and beneficial activities within the system lifecycle (Booch, 1994; Coleman, 1993; Daniels, 1994).

With design being the mapping ground between requirements and implementation, a clean and unambiguous design model can provide benefits ranging from early assessment of requirements to a clear definition of the coding principles and management of issues like traceability, complexity, and evolution (Rumbaugh et al., 1990).

In addition, two major benefits are noteworthy. A clear expression of the design knowledge provides a better encapsulation of the major concerns. Secondly, as the goal is to develop an entire system, decomposition usually implies recomposition: a model that is decomposed makes the integration of those decomposed parts easy and more understandable, resulting in a system that is operational.

Design knowledge is imperative for any system, more so for large and evolving systems (Tarr et al., 1999).

[anitsh]

Composition of Concerns

Composition of concerns looks at what kind of rules the technique employs to compose different concerns. The SoC principle would be less beneficial without the integration of decomposed parts as noted by Jackson (1990), who asserts the importance by saying "having divided to conquer, wemust reunite to rule".

Integration mechanisms describe how these abstractions can be combined with each other and with other functionality of the system. For example, how a crosscutting concern can be weaved back with the functional aspects of the system or with other crosscutting concerns.

Due to the cross cutting nature shown by the majority of the concerns, the integration process is as relevant and important as identifying the concerns themselves. Whereas the thrust on decomposition has been evident while designing systems (Gruenbacher et al., 2000), addressing the composability or integration mechanism remains an issue with a majority of the techniques.

Many questions are being raised as to how the integration mechanism should be carried out. How should the basic and special concerns be woven together? Should the integration be carried out at the source code or the object code level? What rules and principles should be applied while carrying out such procedures? What design framework should it follow for the integration
process? These and a host of other issues have made composition of concerns an important area of focus, and a number of publications have started to address the composability problems within systems (Mullet et al. 1995; Nierstrasz & Tsichritzis, 1995).

[anitsh]

Language Support

The construction of complex, evolving software systems requires clear and unambiguous language constructs to manage the gap between the high-level design and its low-level implementation. The above three criteria provide the identification, encapsulation, and integration of various concerns at a high level.

A fluent relationship between high-level and low-level repre-sentations provides traceability and alignment between requirements, design, and implementation. This relationship within traditional systems, however, is very rarely enforced.

The essence of the problem with OO design techniques is that they traditionally align well with OO code and not with requirements. This makes the alignment between requirements and code very poor, which leaves room for the designers to diverge from the requirements, thus differentiating the designed system from the actual implemented one (Ossher et al., 1999).

[anitsh]

Overlapping Concern

One of the primary aims of separation of concern is to identify and modularize those parts of a system that can be based around some purpose, goal, or scope.

This goal involves identifying different dimensions of concerns and developing solutions orthogonally to avoid the problems of code tangling and scattering of code. This approach, however, has effects when composing overlapping concerns within the systems. Most concerns within systems just do not exist in isolation; they are interrelated in different ways. For example, a piece of functionality might be associated with two or more concerns.

The presence of overlapping concerns raises many questions within the minds of the designer about how they should be eventually tackled. Should multiple copies of the code be executed if all concerns are composed into a system? Does overlapping indicate a relationship between concerns, such that one concern must be included if another concern is included? Should the code be executed only if all concerns are composed into the system? As a result of these questions and many more, different techniques need to counter and provide a suitable answer to overlapping concerns.

orthogonally: statistically independent