Overview

Position Papers

Schedule

Links

Organizers

Contact Webmaster

Separation of concerns is at the core of 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, task, or purpose. Concerns are the primary motivation for organizing and decomposing software into smaller, more manageable and comprehensible parts, each of which addresses one or more concerns.

Many kinds of concerns may be relevant to different software engineers in different roles, to achieving different goals, or at different stages of the software lifecycle. For example, the prevalent concern in object-oriented software engineering is the class, which encapsulates data concerns.  Feature concerns, like printing, persistence, and display capabilities, are also common, as are concerns like aspects, roles, variants, viewpoints, product lines, and configurations.  The artifacts of a software engineering process—such as requirements specifications, designs, architectures, code, test cases, etc.—are also common concerns in software engineering, and a given concern may span multiple artifacts (e.g., a particular feature has a corresponding requirement specification, design and code fragments, test cases that evaluate it, etc.). An 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; and simplify component integration.

Significant advances have been made over the last thirty years, with technologies such as structured programming, object-oriented programming, Booch object-oriented design, etc. As systems become larger and more complex, however, the scale and complexity of the separation of concerns problem continues to grow.  With that in mind, we are working on a new generation of SOC technology, which is aimed at overcoming the resulting problems, including 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 concomitant problems—increased complexity, incomprehensible softwarelow comprehensibility, low reuse, high impact of change and difficult software evolution and integration. One key reason is that the modularization features provided by software languages typically suffer from a limitation we call theA key goal of this new area of advanced separation of concerns is to overcome the tyranny of the dominant decomposition, from which many modern artifact notations suffer—: they they allow separation of only certain kinds of concerns (e.g., data in object-oriented approaches). Other important kinds of concerns overlap, interact with, and cut across the dominant modules, and cannot be encapsulated effectively. Instead, the software pertaining to other concerns is scattered across many modules, and tangled with the software pertaining to other concerns.  Advanced separation of concerns approaches specifically address these key characteristics of large-scale, complex software.

The area of advanced separation of concerns seeks to address the limitations associated with inadequate “traditional” separation of concerns by breaking the tyranny of the dominant decomposition.  Over the last few years, a number of researchers have developed advanced modularization mechanisms that help to overcome a range of problems associated with inadequate separation of concerns.  Key work includes adaptive programming [16] , adaptive plug-and-play components [18] , aspect-oriented programming [15] , composition filters [6] , conceptual modules [8] , feature-based requirements engineering [12] , generative programming [9] [10] [11] , multi-dimensional separation of concerns and hyperspaces [20] , role-modeling [7] , subject-oriented programming [13] , variation-oriented programming [16] , viewpoints [19] , and the list is growing.  Each approach explores a different point in the solution space and addresses different subsets of problems.  In fact, a multitude of possible approaches to advanced separation of concerns exist (many still unexplored), and each has different cost/benefit tradeoffs, but advanced separation of concerns approaches share in common the ability to define and manipulate both “traditional” (orthogonal) concerns and overlapping or crosscutting (non-orthogonal) concerns.

Much of the existing work on advanced separation of concerns has targeted separation of concerns problems in code artifacts.  The need for advanced separation of concerns is quite evident in most areas of software engineering, however, as noted earlier.  Some other key areas in which the need to encapsulate multiple, overlapping and/or crosscutting kinds of concerns appears include requirements specification, design, architecture, product lines, configuration management, middleware, distributed applications, “round-tripping,” and software processes.  Since all software artifacts are related, advanced separation of concerns approaches that address the full software lifecycle (or significant portions of it) must also address the need to identify and use interrelationships among concerns.

The problems that motivate advanced separation of concerns approaches are becoming more pressing and more widely recognized, and computer science has evolved enough that we have a realistic hope of addressing them. The area is young and poses many open research issues and practical challenges. This workshop is intended to bring together researchers interested in pushing the frontier in this important area, researchers in other areas of software engineering who can contribute to attacking some of the key ASOC problems, and practitioners who have experienced problems related to inadequate separation of concerns that can help to guide research and technology development efforts.  The workshop will explore a number of issues in advanced separation of concerns in software engineering.