Karl Lieberherr,
Northeastern University David H. Lorenz,
Northeastern University Mira Mezini,
Northeastern University
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.
Technical Report NU-CCS-99-01,
College of Computer Science, Northeastern University, March 1999.
@TechReport{Lieberherr:1999:PAC,
Title = "Programming with Aspectual Components",
Author = "Karl Lieberherr and David~H. Lorenz and Mira Mezini",
Number = "{NU-CCS-99-01}",
Institution = "College of Computer Science, Northeastern University",
Address = "Boston, MA 02115",
Month = mar,
Year = 1999,
URL = "\url{http://www.ccs.neu.edu/home/lorenz/papers/reports/NU-CCS-99-01.html}",
}
Lieberherr, K., Lorenz, D. and Mezini, M. Programming with Aspectual Components. Technical Report, NU-CCS-99-01, March 1999. Available at: http://www'ccs'neu'edu/research/demeter/bibli/aspectualcomps. html.
....it
is argued, that Object Teams also provide strong concepts for
encapsulation, which help for modular reasoning about aspect oriented
programs developed in this model. 1 Object Teams in a nutshell The Object Teams programming model [7, 14] has its roots in the concept of Aspectual Components [11].
It has gone through several iterations [12, 5, 6, 17] before its current
incarnation as ObjectTeams Java, an implementation based on a
combination of a modified Java compiler and a runtime system performing
load time byte code adaptation using JMangler [10] Object Teams combine
the expressive ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report, Northeastern University, April 1999.
....it
is argued, that Object Teams also provide strong concepts for
encapsulation, which help for modular reasoning about aspect oriented
programs developed in this model. 1 Object Teams in a nutshell The Object Teams programming model [7, 14] has its roots in the concept of Aspectual Components [11].
It has gone through several iterations [12, 5, 6, 17] before its current
incarnation as ObjectTeams Java, an implementation based on a
combination of a modi ed Java compiler and a runtime system performing
load time byte code adaptation using JMangler [10] Object Teams combine
the expressive ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report, Northeastern University, April 1999.
....Jiazzi s support for AOP is similar to Hyper J [20] where atoms are like hyperslices and compounds are like hypermodules. Linking
in Jiazzi and composition in Hyper J serve the same purpose by giving
the programmer explicit control over aspect inclusion and
configuration. Aspectual components [15]
are also adept at modularizing object crosscutting concerns and, like
Jiazzi, emphasize modularity to enable separate reasoning about concern
implementations. Others have explored the relationship between units
and aspects [6] the features described in this paper focus concerns
that cross cut ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. 1999.
....MVC in a more radical way than traditional object oriented techniques do. 3. INTRODUCTION
TO OBJECT TEAMS Object Teams is a recent programming model, which
combines two concepts for improving modularity: aspects and
collaborations. The direct predecessors of Object Teams are Aspectual Components [9] and LAC [5] From this background, Object Teams is a general AOSD approach aiming at a broad range of modularity issues.
Before demonstrating the applicability of Object Teams for the MVC
architecture, let us brie y show, how the concepts of collaborations
and aspects are re ned to teams, roles ....
....typos cannot be detected by the compiler. Di erent approaches for building interactive applications have been mentioned in the introduction. A good discussion on this behalf can, e.g. be found in [12] 8. STATUS, SUMMARY AND FUTURE Object Teams [6, 11] have their roots in Aspectual Components [9]. Two prototypical implementations exists. LAC [5] was the rst practical demonstration, that the concepts proposed in [9] can in fact be implemented and operate as expected. After further re nements of concepts and terminology, Object Teams have been implemented on the basis of Ruby [13] This ....
[Article contains additional citation context not shown here]
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. In Technical Report, Northeastern University, April 1999.
....to implementing that feature. Figure 1 contrasts these two approaches. As
with aspects [27] feature oriented designs often divide the
implementation of each actor into several fragments that crosscut the
modular structure of the design. Modules in such designs are sometimes called collaborations [31],
hyperslices [35] refinements [5] or units [16] We will use the term
features, but our work should apply to other similar notions of cross
cutting. Feature modules have well defined interfaces that permit
their composition to build larger designs; they tend, at least in
principle, to obey ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report NU-CCS99 -01, College of Computer Science, Northeastern University, Mar. 1999.
....do
f base( g invoke in context 7 else 8 base( invoke unmodified 10
entryHook book; 12 static void setActive (Passenger BonusPassenger p,
Team c) 13 f p.myContext = c; g Fig 7. A static entry trigger mechanism. A predecessor of the current model, Aspectual Components [13], made a strict separation between the definition of a collaboration and a connector which binds it to the application.
Technically, this distinction is not needed, and in fact we have
observed situations, where partial Team definitions with partial
bindings are helpful. Thus we allow mixing the ....
....been discussed in the introduction and throughout the paper. Let us now focus on a comparison within the field of languages for aspect oriented software development.
Object Teams build upon and further develop ideas from the works on
Pluggable Composite Adapters (PCAs) 15] Aspectual Components [13],
and the language prototype LAC [8] which in turn have their common
roots in the work on Adaptive Plug Play Components [14] In the
following, we will clearly state the commonalities and differences of
Object Teams with these predecessor models as well as with other models
for aspect oriented ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. In Technical Report, Northeastern University, Apr. 1999.
....g
invoke in context 7 else 8 base.entryHook( invoke unmodified 10
entryHook book; 12 static void setActive (Passenger as BonusPassenger
p, Team c) 13 f p.myContext = c; g Fig. 8. A static entry trigger mechanism. A predecessor of the current model, Aspectual Components [11], made a strict distinction between the definition of a collaboration and a connector that binds it to the application.
Technically, this distinction is not needed, and in fact we have
observed situations in which partial Team definitions with partial
bindings are helpful. Thus, we allow the ....
....data flows enter leave a team. Teams are implicitly activated whenever a control flow enters a Team.
3 Related work Object Teams aim at implementing collaboration based
designs [16, 2, 19, 17] They have their roots in Adaptive Plug Play
Components [12] PCA [13] and Aspectual Components [11].
They have been influenced by Hyper J [18] with respect to the separation
of concern definition and concern composition as well as its
capabilities for on demand restructuring. Influence from AspectJ [9] concerns the technique of weaving into existing code. Virtual classes from gbeta and ....
[Article contains additional citation context not shown here]
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. In Technical Report, Northeastern University, Apr. 1999.
....depends on a seamless embedding into the software life cycle. When
striving for an appropriate design notation for AOSD it is important to
carefully balance the abstraction required by design with the precision
required for implementing a given design. We choose the Aspectual Collaborations model [7, 5]
as a basis, which allows separate development of modules comprising sets
of collaborating classes and a posteriori integration of such modules. We present UFA (UML for Aspects) as an extension of the UML, which maps these modules to packages in UML. We furthermore focus on multiple levels of ....
....towards which the re nement process is optimized. If
seamlessness can be shown for one language, but transition to other
languages remains dicult, it is still to be shown whether this is a de
ciency of the AOD notation or the AOPL. We chose for this work the model of Aspectual Collaborations [7, 5]. This model combines several composition techniques from existing AOPLs. It
has been implemented in a language prototype called LAC [5] A Java based
compiler is under development. 2.1 From Decomposition to Composition
Separation of concerns and decomposition have been guiding principles
in ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. In Technical Report, Northeastern University, April 1999.
....on a seamless embedding into the software life cycle. When
striving for an appropriate design notation for AOSD it is important to
carefully balance the abstraction required by design with the precision
required for implementing a given design. We choose the Aspectual Collaborations model [7, 5]
as a basis, which allows separate development of modules comprising sets
of collaborating classes and a posteriori integration of such modules. We present UFA (UML for Aspects) as an extension of the UML, which maps these modules to packages in UML. We furthermore focus on multiple levels of ....
....towards which the refinement process is optimized. If
seamlessness can be shown for one language, but transition to other
languages remains di#cult, it is still to be shown whether this is a
deficiency of the AOD notation or the AOPL. We chose for this work the model of Aspectual Collaborations [7, 5]. This model combines several composition techniques from existing AOPLs. It
has been implemented in a language prototype called LAC [5] A Java based
compiler is under development. 2.1 From Decomposition to Composition
Separation of concerns and decomposition have been guiding principles
in ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. In Technical Report, Northeastern University, April 1999.
....different possibilities to modularize crosscutting concerns in our component based context. The first solution consists of using a new component model that allows a component to describe adaptations in other components. Prof Lieberherr and others present a concrete proposal for such a component [4]. They call these components aspectual components. They
propose to have a new type of interface that allows components to
describe adaptations independent of the concrete components that will
be adapted. At composition time, special compositions connect the adaptations with the concrete ....
Lieberherr, K., Lorenz, D. and Mezini, M. Programming with Aspectual Components.
Technical Report, NU-CCS-99-01, March 1999. Available at:
http://www.ccs.neu.edu/research/demeter/biblio/aspectual-comps.html.
....different possibilities to modularise crosscutting concerns in our component based context. The first solution consists of using a new component model that allows a component to describe adaptations in other components. Prof Lieberherr and others present a concrete proposal for such a component [3]. They call these components aspectual components. They
propose to have a new type of interface that allows components to
describe adaptations independent of the concrete components that will
be adapted. At composition time, special compositions connect the adaptations with the concrete ....
Lieberherr, K., Lorenz, D. and Mezini, M. Programming with Aspectual Components. Technical Report, NU-CCS-99-01, March 1999. Available at: http://www.ccs.neu.edu/research/demeter/biblio/aspectualcomps. html.
....designs
realign the module boundaries so that all of the code pertaining to a
single operation lies in the same module; the modules therefore cross
cut actors. Researchers have proposed feature oriented modules under many names (refinements [6] units [15] aspects [23] collaborations [27],
hyper slices [28] and others) some have spoken of feature oriented
designs (or feature engineering) in more general terms [32] Ongoing
research on feature oriented modules shows that they simplify key
software engineering problems such as configurability, maintainability,
and evolution [3, ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report NU-CCS-99-01, College of Computer Science, Northeastern University, Mar. 1999.
....in the account objects. Doing
the computation with small objects as given in the collaborations, seems
to result in the desired efficiency provided the synchronization of the
many small business objects can be solved efficiently. Collaborations can also be of a rewriting nature as described in [LLM99]
Those collaborations can easily express aspects in a similar way as
they are expressed in aspect oriented programming with AspectJ [Tea99]
We propose to implement those rewriting collaborations and compare the
resulting system with AspectJ from Xerox PARC. This work will include a compiler for ....
Karl Lieberherr, David Lorenz, and Mira Mezini. Programming with Aspectual Components. Technical Report NU-CCS-99-01, College of Computer Science, Northeastern University, Boston, MA, March 1999.
.... of
methods for a given message from di erent subjects supported in SOP are
components in the AOP sense since they can be well localized in a
generalized procedure (routine) But this seem to be a more general
issue, since it applies to AspectJ too, named aspectual paradox by
Liebrherr et al. LLM99] an
aspect described in AspectJ, the Xerox PARC s AOP language, which has a
construct for specifying aspects, is by de nition no longer an aspect,
as it has just been captured in a (new kind of) generalized routine . It is worth mentioning, as Czarnecki [Cza98] observed, that SOP is close to ....
Karl Lieberherr, David Lorenz, and Mira Mezini. Programming with Aspectual Components.
Technical Report NU-CCS-99-01, College of Computer Science,
Northeastern University, Boston, MA, March 1999. Available at [Dem].
....to determine how to optimize the analyzer. It would be difficult to prove (or even rigorously argue) that the generation algorithm was correct.
Another avenue to explore for acheiving efficiency without sacrificing
transparency is to use aspect oriented programming [12] or aspectual
components [13] to weave the evaluation of rules into custom algorithms that manipulate data structures containing the premise steps. These approaches facilitate transparency but lack a formal basis in which to prove correctness. Our formalization of inference graphs allows a proof that this abstraction is ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report NU-CCS-99-01, College of Computer Science, Northeastern University, Boston, MA, March 1999.
....of an aspect to an application (the aspect is said to be woven) is one of them.
Several approaches exist: AspectJ [KHH 01] which is a general language
for AOP, the composition lter object model [BA01] where aspects are de
ned as lters applied upon application objects, aspectual components [LLM99]
that de ne patterns of interaction with roles and connectors to map
these roles to application objects, subject oriented programming [HO93]
OKH 95] which decomposes an application into subjects and provides
composition rules to recompose them, domain speci c languages to de ne
crosscutting ....
....only crosscuts the application, but may also crosscut others aspects. Indeed, aspects may not be orthogonal to each others. We call this issue the inter aspects composition aspect. Some solutions exist, e.g. precedence rules in AspectJ [KHH 01] or composed connectors in aspectual components [LLM99] see section 6 for a discussion of these features) but as far as we know, this 1 is still an open issue for the AOP community. Most of the time aspect programmers still have to invent some ad hoc means to handle it. This problem deeply a ects the potential power of AOP by making aspects less ....
[Article contains additional citation context not shown here]
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report NU-CCS-99-01, Northeastern University's College of Computer Science, April 1999.
....realized on object level using reflection there is no static type checking available. So
the developer has to be sure, that the interface of the adapted object
really fulfills the signatures specified in the concrete adapter. This presented approach can be used for composing aspectual components [6], which represent aspects whose interfaces have to be adapted to let them interact with their environment. In the future we will examine, how such components can be realized in existing general purpose aspect languages. ....
Lieberherr, K., Lorenz, D., Mezini, M.: Programming with Aspectual Components , Technical Report, NU-CCS-99-01, Northeastern University, Boston, 1999
....aspects disappear from the resultant object graph after weaving is completed. The only noticeable change in the object graph is the addition of the constraint aspects. The Adaptive Programming community has recently addressed issues concerning the separation of aspects from their join points [Lieberherr et al. 99]
In their approach, called aspectual components, a definition that is
separate from the aspect description is used to describe the assembly
of join points. We would like to explore further this idea with our
own language so that our constraint aspects are more generic and can be
reused in ....
Karl Lieberherr, David Lorenz and Mira Mezini, "Programming with Aspectual Components," NU-CCS-99-01, College of Computer Science, Northeastern University, March 1999.
....prerequisite for reusable and extensible software. On
contrary, Caesar o#ers an alternative to open classes that is even more
powerful and does not violate independent extensibility. Adaptive Plug and Play Components (APPCs) 10] and their aspect oriented variant of Aspectual Components [8]
are related to our work in that both approaches support the definition
of multi abstraction components aspects and have a vague definition of
required and provided interfaces. However, the latter feature was not well integrated with the type system. Recognizing this deficiency, the successor ....
....improvement over all three models, as far as support for multi abstraction aspects is concerned. Due
to the lack of a CI notion, connectors and adapters in APPC, Aspectual
Components, and PCA models are bound to a fixed implementation of an
aspect and cannot be reused. In addition, 10] and [8] rely on a dedicated mapping sublanguage that is less powerful than our object oriented wrappers with wrapper recycling.
Finally, the lack of the notion of virtual types is another drawback of
these approaches as compared to the work presented here. Delegation layers [13] are an approach to ....
K. Lieberherr, D. Lorenz, and M. Mezini. Programming with aspectual components. Technical Report NU-CCS-99-01, March 1999.
....of broken modularity, partly, they utilize incompatible concepts for similar problems. The great merger has not happened.
While the two leading language implementations, AspectJ and Hyper J are
elaborated up to a point, where moving towards each other seems to be
impossible, a proposal dated 1999 [6] had not been implemented to date, which has the capability to combine some ideas from di erent groups of researchers. The model is called Aspectual Components. This
paper presents a light weight implementation of Aspectual Components, by
which the design of this model is re ned and open design ....
....of this model is re ned and open design decisions are cast into this discussion. We implemented LAC as a small extension to the interpreted language Lua [4] Thus, LAC stands for Lua Aspectual Components. In section 2, we will present the conceptual elements of Aspectual Components according to [6], supplemented by some considerations that arose while implementing LAC.
Section 3 presents the internal design of LAC, introducing concepts like
facet compound objects and run time Submission for ASoC Workshop at
ICSE 2001. weaving as a special style of meta programming. This might lay the ....
[Article contains additional citation context not shown here]
Karl Lieberherr, David Lorenz, and Mira Mezini. Programming with aspectual components. In Technical Report, Northeastern University, April 1999.
Lieberherr, K., Lorenz, D. and Mezini, M. Programming with Aspectual Components. Technical Report, NU-CCS-99-01, March 1999. Available at: http://www'ccs'neu'edu/research/demeter/bibli/aspectualcomps. html.
Karl Lieberherr and David Lorenz and Mira Mezini, Programming with Aspectual Components, College of Computer Science, Northeastern University {NU-CCS-99-01}, March 1999.
NU-CCS-99-01.ps.gz (164k)
