Separation of concerns [6] is at the core of object-oriented software engineering. In its most general form, it refers to the ability to identify, encapsulate, and manipulate those parts of software that are relevant to a particular concept, goal, purpose, or issue. In object-oriented software development (as well as all others), concerns are the primary means of organizing and decomposing software into smaller, more manageable and comprehensible parts. Appropriate separation of concerns has been hypothesized to reduce software complexity and improve comprehensibility; promote traceability within and across artifacts and throughout the software lifecycle; facilitate reuse, non-invasive adaptation and customization, and evolution, thus reducing software cost; and simplify component integration.
The potential has not yet been achieved, however, despite attention to this issue for nearly three decades. Separation of concerns is still inadequate, and software is still plagued by the attendant problems. A key reason is that the modularization features provided by software languages typically suffer from a limitation we call the tyranny of the dominant decomposition: they allow separation of only certain kinds of concerns (e.g., data in object-oriented approaches). Other important kinds of concerns cut across the dominant modules, and cannot be encapsulated effectively. Instead, the software pertaining to such a concern is scattered across many modules, and tangled with the software pertaining to other concerns.
Over the last few years, a number of researchers have recognized this limitation, illustrated it in a number of domains and scenarios, and developed advanced modularization mechanisms to help overcome it. Key work includes adaptive programming [17], aspect-oriented programming [14], composition filters [7], feature-based requirements engineering [16], multi-dimensional separation of concerns and hyperspaces [21], role-modeling [8], viewpoints [11], and subject-oriented programming [9]. The list is growing, and with it the new area of "advanced separation of concerns."
The time is right for this area of research: the problems are becoming more pressing and more widely recognized, and computer science has evolved enough that we have a realistic hope of solving them. The area is young, and many open research issues and practical challenges remain. This workshop is intended to bring together researchers interested in pushing the frontier in this important area, and practitioners who have experienced problems related to inadequate separation of concerns that can help to guide the research.
Many kinds of concerns may be relevant to different developers in different roles and/or with different views of the software, to achieving different goals, or at different stages of the software lifecycle. For example, the prevalent module in object-oriented software engineering is the class (or object), which encapsulates data concerns. Functional or feature concerns (e.g., printing, persistence, and display capabilities) and aspects (e.g., concurrency control and distribution) are also common, as are roles, variants, configurations, and business rules.
One kind of concern may promote some goals and activities, while impeding others. For example, classes help to localize changes in data representation, so changing a data representation in an object-oriented system might involve a single class, or a few closely-related classes, and might be done additively using subclassing or suitable design patterns. Here the hallmark of object-orientation-modularization by class (or object)-is a major asset. On the other hand, adding a new aspect or feature to a system typically involves invasive changes to many classes: the new code is scattered across multiple classes, and tangled with other code within those classes. This reduces comprehensibility and increases impact of change and the likelihood of error.
Since every criterion for decomposition has corresponding benefits and disadvantages, any criterion for decomposition will be appropriate for some contexts, goals, and purposes, but not for all. Further, multiple kinds of concerns may be relevant simultaneously, and they may overlap and interact, as features and classes do. Many concerns span lifecycle phases and artifacts. Finally, the set of concerns and modularizations needed will tend to evolve throughout the lifecycle, as new requirements, technologies, developers, methodologies, and practices emerge.
Of course, decomposition is not enough; it must also be possible to compose or weave the separate modules together to form full artifacts and systems. As decomposition becomes more sophisticated, correspondingly sophisticated composition mechanisms are needed.
The need to support this evolving plethora of interacting concerns across the software lifecycle poses serious challenges to advanced separation of concerns mechanisms. None comes close to doing the whole job, yet, and work pertaining to any subarea is within the scope of this workshop.
This is a partial list of relevant workshops and selected papers on advanced separation of concerns, listed chronologically.