Section 21.2. WHAT IS A CONCERN?

21.2. WHAT IS A CONCERN?

Although most software developers have a good intuitive sense of what a concern is, good definitions of concern are hard to come by. Aspects are one category of concern: An aspect is a (program) property that cannot be cleanly encapsulated in a "generalized procedure" (such as an object, method, procedure, or API) [21]. A later but comparable definition is that an aspect is a program property that forces crosscutting in the implementation [11]. These definitions identify a critical property of some concerns that makes separation of concerns problematic in conventional programming languages. However, it is too focused on program structure (and code) to qualify as a general definition of concern. Tarr and others [37] define a concern as a predicate over software units. This definition is not limited to code and appropriately spans the lifecycle, but it is still based on software units.

To promote concerns to first-class status in software development, they must be defined independently of any specific type of software artifact and even of software artifacts in general. One dictionary definition of concern is "a matter for consideration" [27]. More specifically to software, an IEEE standard defines the concerns for a system as ". . . those interests which pertain to the system's development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders" [17, p. 4]. We take concern generally to be any matter of interest in a software system. This may not seem like a particularly technical definition, but it is open, simple, and intuitive, encompasses other definitions, and is suitable for many purposes. We give some examples in Section 21.7.

Based on this definition, it follows that concerns are fundamentally conceptual. They are not, in general, artifacts, although artifacts may represent concerns, and artifacts may be of concern (say, as work products in a development task). Concerns are not, in general, requirements, although requirements represent concerns and are of concern at many points in a development process. Similarly, a concern model is not, in general, a domain model, although a domain model may contribute concerns (or define a domain over which concerns are expressed).