Lately, I have been thinking about the role of concerns in architecting (software, systems and enterprises). The term was used by Dijkstra in 1974, in an often cited quote:
Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.This led to frequent usage of the phrase, "separation of concerns" in software engineering up to the present. Some of those uses have been lip service; in other cases, folks have tried to take concerns seriously.
In IEEE 1471:2000, concerns were first-class entities. That standard, and its current edition, ISO/IEC/IEEE 42010:2011 provides best practices for architecture description.
[http://www.iso-architecture.org/42010/]
Architecture descriptions use multiple views. In the Standard, each view of an architecture is expected to explicitly identify the concerns it addresses. This helps to determine whether the right notations are being chosen: e.g., if response time is your current concern, being shown a static class diagram probably won't tell you very much! More generally, associating concerns with viewpoints establishes a 'contract' between the architect and the stakeholders for where to look to get the answers to particular kinds of questions about the architecture.
Concerns subsume other familiar notions such as system characteristics, software qualities, 'non-functional requirements' [a term I dislike].
[http://www.slideshare.net/dJdU/concerns]
Concerns are what we care about in software.
— Sutton and Rouvellou (OOPSLA 2001)
Concerns are taken somewhat seriously also in the world of aspect oriented programming and its successors in the areas of Early Aspects. This is nicely surveyed by Stanley M. Sutton Jr. and Isabelle Rouvellou, "Concern Modeling for Aspect-Oriented Software Development," a chapter in Aspect-Oriented Software Development (edited by Robert E. Filman, Tzilla Elrad, Siobhán Clarke, and Mehmet Akşit, Addison-Wesley, 2004).
My hypothesis is: 1) that concerns are a missing dimension when thinking about software; 2) even while taken for granted (without that name) in mature engineering fields; and 3) that treating them as explicit during architecting and engineering has potential to improve what we do. Concerns are useful, not just for selecting suitable representations (as in the ISO standard above), but for defining and carrying out methods and processes, and organizing the bodies of engineering and architecting knowledge among other things.
Concerns are largely ignored in the process and method models that occupy much of current theorizing about software (and systems) engineering. They are not to be found in process models like:
- Software & Systems Process Engineering Metamodel (SPEM)
- ISO 24744, Software Engineering Metamodel for Development Methodologies (SEMDM)
- ISO/IEC TR 24774, Software and systems engineering — Lifecycle management — Guidelines for process description
Recently OMG issued an RFP, Foundation for the Agile Creation and Enactment of Software Engineering Methods, that at least mentions concerns in its requirements:
6.5.2.2.4 Specification of practicesThere is much more to say about this topic. Watch this space for a paper on these ideas. In the meantime: "In search of the Higgs, or What's wrong with SEMAT?" Work-in-progress, comments appreciated!
The Language shall have features for specifying practices in terms of Kernel elements, including:
a. Description of the particular cross-cutting concern addressed by the practice and the goal of the application of the practice. ...
6.5.2.2.5 Composition of practices
The Language shall have features for the composition of practices, to describe existing and new methods, including:
a. Identifying the overall set of concerns addressed by composing the practices. ...
d. Modifying an existing method by replacing a practice within that method by another practice addressing a similar cross-cutting concern.
