Synopsis:
Components
provided interface
adds function and data members
modifies function members with before, after, around methods
required interface
includes participant graph
Connectors
connect provided and required interfaces
Why are aspectual components important? They focus on software reuse and make both initial software development and maintenance easier. Connectors use regular expressing-like notations to express the embedding of a component into a more elaborate structure. Specifically traversal strategies are used to map from high-level to low-level without committing to the details of the lower level. Connectors of aspectual components use clever implementation techniques that would be hard to implement directly in Java by a programmer.
Are aspectual components a new architecture description language? Yes, but the architecture description language is integrated with the programming language. The architecture description language also serves as programming language following the motto: the program should mirror the design.
Bibtex entry:
@TECHREPORT{aspectual:LLM,
AUTHOR = "Karl Lieberherr and David Lorenz and Mira Mezini",
TITLE = "{Programming with Aspectual Components}",
INSTITUTION = "College of Computer Science, Northeastern University",
YEAR = 1999,
MONTH = "March",
NUMBER = "{NU-CCS-99-01}",
ADDRESS = "Boston, MA"
}
Abstract:
Aspect-oriented programming (AOP) controls tangling of concerns by
isolating aspects that cross-cut each other into building blocks.
Component-based programming (CBP) supports software development by
isolating reusable building blocks that can be assembled and connected
in many different ways. We show how AOP and CBP can be integrated by
introducing a new component construct for programming class
collaborations, called \emph{aspectual component}. Aspectual
components extend adaptive plug-and-play components (AP\&P) with a
modification interface that turns them into an effective tool for AOP.
A key ingredient of aspectual components is that they are written in
terms of a generic data model, called a participant graph, which is
later mapped into a data model. We introduce a new property of this map,
called \emph{instance-refinement}, to ensure the proper deployment
of components. We show how aspectual components can be implemented in
Java, and demonstrate that aspectual components improve the AspectJ
language for AOP from Xerox PARC.
Papers in PDF and Postscript (aspectual.ps is the first version)
Viewgraphs on Aspectual Components in PowerPoint
Predecessor paper: OOPSLA '98 paper on Adaptive-Plug-and-Play Components
Aspect-Oriented Programming (AOP)
The following is relevant but did not fit into the paper:
Connectors, in the context of {\AC}s, have the flavor of
mapping high-level structures to low-level structures.
Our goal is to express the mapping in a flexible way that is robust under
changes to the low-level structure. We consider the mapping as a
function $HighLevel$ that takes as actual
parameters LowLevel-objects. What is the type of $HighLevel$?
It is not LowLevel, but
a set of constraints that define the domain of function $HighLevel$.
This way we achieve that $HighLevel$ does not refer to all the information
in LowLevel-objects, but $HighLevel(l)$ for a LowLevel-object $l$
might contain all the
details of $l$.
Mapping small graphs to larger graphs without committing
to the details of the larger graphs is a problem
that can be solved
very effectively using {\AP} \cite{lieber-palsberg-xiao94,strategies-tr:LP97}.
Further discussion of {\AP} is beyond the scope of this paper but
{\AP} is useful for implementing connectors between aspectual components.
How can the mapping function High-level be defined
in a flexible way? It is written in terms of generic operations
that extract information from the Low-level arguments.
Consider a mapping ShortestPath from graphs to graphs.
The domain of the mapping is any graph that has a node A and a node B
and exactly one shortest path between A and B.
When we give a graph H as an actual parameter, then [A,B]
will be mapped into a potentially long path from A to B in H
that reveals many details of H. The mapping specification, however,
does not talk about the details of the arguments.
The mapping specification is robust and applicable to an entire
family of graphs. An alternative would be to specify:
A -> B is mapped to A -> X -> Y -> Z -> B, but such a specification
is a highly specific and needs to be updated when the
argument graph changes.
A danger of the shortest path specification might be that
it may be wrong when the argument changes. For example, we might want
a path that is not the shortest path. In this case we would use
something like ShortestPath![A,Q] \cdot ShortestPath![Q,B] to force
the path we want. Such a specification is still pretty generic,
although it reveals a little more detail about the argument graphs.
ShortestPath![A,B] is an example of a traversal strategy.
They are an ideal tool for specifying mappings of one graph
to another graph in a flexible way. They are a powerful tool
to be used in connectors.
The theory of Adaptive Programming, developed in [PXL,PPL,LP,book]
discusses the the pros and cons of traversal strategies.
The use of traversal strategies in connectors distinguishes
our work on connectors from all other works in software architecture
that use connectors.
Aspect-oriented programs consist of complementary,
collaborating building blocks, each one addressing a
different application/system level concern.
Two building blocks A1 and A2 are complementary collaborating
building blocks if an element a1 of A1 is
formulated in terms of partial information about elements of A2 and A1
adds information to A2 not provided by another aspect.
The partial information about A2 is called join points
and provides the range of the weaving in A2.
The domain of the weaving is in A1 and consists of
weaves that refer to the join points. The weaves describe enhancements to A2.
The join points may be spread through A2.
After the weaving, enhancements from a1 effectively cross-cuts A2.
The mapping between two collaborating views may be specified by a
connector that says how information in A1 adds
information to A2. The separation of building blocks and
connectors supports better reuse of building blocks as well as connectors.
Often multiple (not just two) collaborating building blocks are connected
by a connector. Each building block has a well defined interface that
consists of information that the building block requires
and information that it provides. The connectors
link the provided and required interfaces.
An aspect-oriented system can be viewed as a graph.
The nodes are building blocks and the edges represent connectors.
The above description of AOP is general and not confined to
OO or any other paradigm. In the application of AOP to OO used in this paper
the required interface of a building block
A2 contains a graph ICG that defines structural entities
and relationships relevant to A2. The provided
interface of a component connected to A2 also contains a
graph CCG and this graph may be substantially bigger than ICG. The connector
maps the potentially smaller ICG to the larger CCG. What is important is
that ICG and CCG are in a refinement-instance relationship defined below.
AP is special case of AOP where building blocks or connectors
use traversal strategies (graphs defining traversals through other graphs).
The application of AOP described in this paper is a form of
parameterized programming where formal and actual parameters are linked
by connectors and where the formal parameters define
constraints on graphs that must be satisfied by the
graphs serving as actual parameters. This
is different than template programming in C++.