Overview

Position Papers

Links

Organizers

Contact Webmaster

The second workshop on multi-dimensional separation of concerns in software engineering will occur at ICSE 2000 on Tuesday, June 6, 2000.

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, or purpose. Concerns are the primary means of organizing and decomposing software into smaller, more manageable and comprehensible parts. Many kinds of concerns may be relevant to different developers 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, and configurations. The 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; facilitiate reuse, non-invasive adaptation and customization, and evolution; and simplify component integration.

These goals, while laudable and important, have not yet been achieved in practice. This is because the set of relevant concerns varies over time and is context-sensitive--different development activities, stages of the software lifecycle, developers, and roles often involve concerns of dramatically different kinds. One concern may promote some goals and activities, while impeding others; thus, any criterion for decomposition will be appropriate for some contexts, but not for all. Further, multiple kinds of concerns may be relevant simultaneously, and they may overlap and interact, as features and classes do. Thus, different concerns and modularizations are needed for different purposes: sometimes by class, sometimes by feature, sometimes by viewpoint, or aspect, role, variant, or other criterion.

We use the term multi-dimensional separation of concerns to denote separation of concerns involving:

1. Multiple, arbitrary kinds (dimensions) of concerns.
2. Separation according to these concerns simultaneously; i.e., a developer is not forced to choose a small number (usually one) of "dominant" dimensions of concern at the expense of others.
3. Overlapping or interacting concerns. It is appealing to think of many concerns as being independent or "orthogonal," but this is rarely the case in practice. It is essential to be able to support interacting concerns, while still achieving useful separation.

This workshop is intended to bring together researchers in this burgeoning area, and practitioners who have experienced problems that can help to guide the research. Specific areas of interest include:

1. Development scenarios illustrating the need for multi-dimensional separation of concerns.
2. Illustrations of concern overlap or interactions.
3. Flexible, concern-based modularization and remodularization.
4. Multi-dimensional separation of concerns throughout the software lifecycle, especially handling of concerns that span lifecycle phases and software artifacts.
5. Adaptive programming, aspect-oriented programming, composition filters, conceptual modules, role-modeling, subject-oriented programming, views, viewpoints, and other related approaches.
6. Theoretical foundations.
7. Language support.
8. Environment support.

Workshop Organizers:

Contact organizer: Peri Tarr, IBM T.J. Watson Research Center (USA)
Anthony Finkelstein, University College London (UK)
William Harrison, IBM T.J. Watson Research Center (USA)
Bashar Nusibeh, Imperial College (UK)
Harold Ossher, IBM T.J. Watson Research Center (USA)
Dewayne Perry, University of Texas at Austin (USA)