The following topics for the group break-out sessions are being proposed (if you have not done so, please send your top-three preference to us):
Overview: In any non-trivial system, one can identify multiple relevant kinds of concerns. Some are domain- or application-specific, while others are moregeneral. Some common kinds of concerns in object-oriented systems are classes, features, persistence, concurrency, and business rules. This group will examine a number of issues in concern selection and use.
Some issues that may be addressed by this group include:
- What concerns arise?
- When do they arise; how are they identified?
- What are they useful for? What are they NOT useful for? (E.g., class concerns are useful
for localizing the effects of changes in representation, but they're particularly bad for
localizing changes to function)
- To what does each kind of concern apply?
- What properties do they have and how can they be specified?
- Can they be changed? If so, when? What is the impact of such a change?
- How do they interact?
- What kinds of scenarios highlight the need for each kind of concern?
Possible outputs of this group: A catalog of common concerns and their characteristics; requirements on ASOC solution approaches; scenarios and challenge problems that focus on concern identification and usage.
Overview: While some kinds of concerns are orthogonal and independent (i.e., they do not interact or otherwise affect one another), the majority of concerns do interact in some way. Various kinds of concern interrelationships are possible; for example, constraints, semantic interactions, extension and adaptation, mutual exclusion, etc. This group will explore some of the kinds of interrelationships concerns may have, their properties, and their usage.
Some issues that may be addressed by this group include:
- What kinds of interrelationships exist?
- When do they arise? In what context?
- How should they be specified?
- When should they be specified?
- Can they be changed? If so, when? What is the impact of such a change?
- When are they used? By whom?
- What kinds of scenarios highlight the need for eack kind of interrelationship?
Possible outputs of this group: A catalog of common interactions and their properties; requirements on ASOC solution approaches; scenarios and challenge problems that focus on concern interaction and interrelationships.
Overview: Although the complete set of issues and requirements on approaches to ASOC is not yet known, there are a number of requirements on, and features of, ASOC approaches and mechanisms that are now considered "standard." Given these standard features, plus some that are not yet standard, there exists a design space of features and properties of ASOC mechanisms and approaches. Each point in the design space is characterized by both positive and negative effects. This focus group will explore a set of design decisions, alternatives, and tradeoffs that face ASOC technology providers.
Possible outputs of this group: A set of design decisions and issues and tradeoffs to consider in making these decisions; interactions among design decisions (i.e., how making one choice may affect other choices); requirements on ASOC solution approaches; scenarios and challenge problems that highlight issues in making different design decisions
Overview: Effective software engineering using ASOC requires the identification of different kinds of concern throughout the software lifecycle, and it requires the ability to carry concerns across software artifacts, such as requirements specifications, designs, architectures, product lines, etc. Thus, it must be possible, for example, for concerns identified during design and architecture to be carried through to code and beyond. This group will explore issues in providing explicit support for ASOC during software specification, architecture, design, analysis and design phases.
Possible outputs of this group: A set of scenarios and challenge problems that highlight requirements on ASOC support across the lifecycle; a set of issues and tradeoffs to be addressed in providing such support; requirements on solutions.
Overview: One of the major concerns often expressed about ASOC mechanisms is that they are power tools without safeguards: they allow one to decompose and compose software in flexible ways, but seldom inspire confidence that the result will work correctly, or even that it will preserve important properties of the separate modules. There is groundbreaking work to be done in the areas of formalization, specification and analysis, and in building checking tools based on these, to improve this situation. There might be synergy here with refactoring, and important lessons to be learnt from the refactoring community, because they have long been concerned with "semantics-preserving" transformations.
Possible outputs of this group: A set of scenarios and challenge problems that highlight "unexpected" errors resulting from concern composition; a set of research issues to be addressed; a list of techniques from related research communities that might provide suitable starting points; requirements on solutions.