|
Overview:
Why the Concern Manipulation Environment (CME)?
To be widely adopted,
AOSD requires:
- Extensive lifecycle
tooling. Developers require tool support for all stages and
artifacts of an aspect-oriented lifecycle. These include tools
to support requirements engineering, design, architecture, coding
in a variety of programming languages, analysis, testing, problem
determination, and reengineering.
- Extensive task-directed
tooling.
Some common
tasks requiring tool support include new development, development
of extensions or variants, integration of new features, enforcement
of architectural constraints, and performance analysis.
- Problem-directed
AOSD paradigms.
Different paradigms have different cost/benefit tradeoffs, so
are more or less suited to addressing particular goals. Some commonly
used paradigms include concern composition, aspect attachment,
behavioral filtering, and adaptive routing.
To be useful to a wide
range of developers, AOSD tooling must satisfy several constraints:
- Applicable to a
variety of different types of artifacts. Aspects may be found
at any stage of the software lifecycle, and it must therefore
be possible to create and manipulate them at any stage, and for
any artifact.
- Adaptable to a
variety of artifact notations, languages, and representations.
Developers use many different artifact representations, including
UML/XMI, Java source code, Java binary, and C#. AOSD tools must
support these different representations.
- Adaptable to a
variety of operating environments, platforms, and processes.
Developers may use Sun's JDK alone, Eclipse, other other development
environments in the creation of their artifacts. They may use
configuration management systems, like Stellation, or various
forms of artifact repositories, to store their artifacts. They
may develop their software using Rational's Unified Process, one
of the Agile processes, or a traditional (waterfall) process.
AOSD tooling must work within different environments, platforms,
and processes, and be adaptable to a particular user's preferred
environment.
Implementing AOSD tools
is hard. No higher-level "virtual machine" or abstractions
exist to facilitate the development task--most tool providers and
researchers are forced to implement from scratch, which is a significant
impediment. Moreover, because there is no common set of underlying
abstractions, the tools they build do not integrate with one another
readily, if at all.
The CME is intended to
provide an extensible, reusable, open, and customizable base on
which AOSD tool developers can build and integrate tools. It is
also intended to provide an environment for AOSD developers that
addresses the constraints noted above.
The
CME Architecture
The Concern Manipulation
Environment architecture consists of:
- a collection of end-user
tools, which aid developers in performing full-lifecycle
aspect-oriented software engineering. These tools are customized
for particular tasks (e.g., creating a variant or adding
a feature), lifecycle stages or artifacts (e.g.,
design or code, using UML, Java source, or Java byte codes), AOSD
paradigms (e.g., AspectJ, Hyper/J, DJ, Composition Filters),
and environments (e.g., Eclipse, Stellation).
- a collection of components,
which provide much of the higher-level capabilities required by
the tools. Components are typically independent of task, lifecycle,
paradigm, or environment, and have tailorable, adaptable behaviors.
Examples include analysis capabilities, artifact stores, refactoring
components, and composition capabilities.
- a collection of frameworks,
which provide language- and paradigm-independent access to low-level
concern representation and manipulation capabilities, and which
support pluggability to permit the use of different underlying
engines.
- a collection of engines,
which define language- and paradigm-dependent access to low-level
concern representation and manipulation capabilities.
The following diagram
shows a high-level view of the CME architecture. By clicking on
entities of interest, you can read more about their capabilities.
Items with white backgrounds are already supported (in part or in
whole); items with grey backgrounds are planned but not yet supported.
Descriptions exist for all items.
|
|
