Concern Spaces

It is helpful to introduce terminology for discussing the "concern structure" of systems: what concerns are present, how they relate, and how they can be used for modularization. Since separation of concerns is important throughout the software lifecycle, we use general terms rather than terms specific to programming languages and code. Software consists of artifacts, which comprise descriptive material in suitable formalisms. A unit is a syntactic construct in some such formalism. A unit might be, for example, a declaration, a statement, a state chart, a class, an interface, a requirements specification, or any other coherent entity that can be described in a given formalism. We distinguish primitive units, which are treated as atomic, from compound units, or modules, which group units together. Thus, for example, a method, instance variable, or performance requirement might be treated as a primitive unit, whereas a class, package, or collaboration diagram might be treated as a module.

"Concern" is a concept of which most software engineers have an intuitive grasp, but no precise definition. This is largely because there is such a variety of concerns of interest. For generality, we define a concern simply as a predicate on units that indicates whether or not a given unit pertains to that concern.

A concern space encompasses all the software in some domain of discourse, such as a set of software systems, product families, or component libraries. It contains the set of units making up this software, and the set of all concerns currently considered of importance in this domain. Its job is to organize the units so as to separate (identify and segregate) the concerns, and to provide means for software engineers to use the concerns as the basis for modularization during development and evolution tasks.

The detailed structure of a concern space, and the flexibility with which its concerns can be used for modularization, will depend upon the mechanism(s) in use for achieving separation and integration of concerns. For example, standard object-oriented programming languages support a one-dimensional space: all concerns are "class" concerns, which interact in the standard ways provided by the language. See the page on hyperspaces, which describes the model we are developing for handling concerns of arbitrary, different kinds.

Beyond the fact that they include units and concerns, concern spaces can thus differ significantly in terms of structure, detail and capability. Concern spaces constitute a useful conceptual framework within which to explore, analyze and compare different approaches to separation of concerns, and especially to multi-dimensional separation of concerns.

If you are interested in reading about concern spaces in more detail, check the list of currently available papers.

Still have questions? Click here to send us mail.

Return to hyperspace home page