Transcript Shyness in Programming Karl Lieberherr Demeter Research Group Northeastern University Boston XAspects • Go to slide 49

Shyness in Programming
Karl Lieberherr
Demeter Research Group
Northeastern University
Boston
1
XAspects
• Go to slide 49
2
Coupling Aspect-Oriented and
Adaptive Programming:
Shyness in Programming
PhD Visitation Weekend 2003
3
Our Intuition behind AOP
• Our Aspect-Oriented Programming (AOP)
intuition has been: "adaptiveness". It comes
in two flavors: adaptiveness
– to the class graph ("painting the class graph in
broad strokes with code") and
– to the call graph of the traversal ("picking
points in the graph where additional code gets
called").
4
MIT Technology Review
2001
• Aspect-oriented programming is called
“adaptive programming” at Northeastern
University.
5
Definitions
y is x-shy if:
(1) y relies only on minimal information of x
(2) y can adapt to small changes in x
(3) y is loosely coupled with x
(4) y can work with x1, x2, ... which are close
or similar to x.
What is a concern? A concern is something
that the programmer cares about.
6
Examples of concerns the
programmer has to deal with
• Production concerns
– How do I compute the price allowing for
multiple pricing schemes?
• Non-Production concerns
– What do I have to print to understand why this
program does not work?
– Are all objects of class A created in class
Afactory?
7
Scattering and Tangling: Static
• aspecti is scattered across many classes (i = 1,2,3)
• class X tangles aspects 1, 2 and 3
class
diagram
aspect1 aspect2 aspect3
class A consisting
of three aspects
Class X
classes for
aspect1
classes for
aspect2
classes for
aspect3
Adding to classes
8
Scattering and Tangling: Dynamic
•Each aspect (colors) is scattered across many classes (shapes)
program execution
•Class tangles all three aspects
involving three
this(s)
aspects (colors r b g)
f(..)
t.f(..);
target(t)
Enhancing calls
program call tree
(classes
executing
method calls)
classes
At those calls the aspect enhances the behavior
9
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-Concern-shy
• Program with multiple building blocks, say
b1:B1 and b2:B2, that are woven together:
b1*b2. b1 relies only on partial information
about b2 which makes b1 more robust and
reusable. Goal: b1 should be loosely
coupled to b2.
10
Law of Demeter (LoD)
for Concerns
• A concern implementation should not rely on
too much information about other concern
implementations.
• (Classic LoD: A method should not rely on too
much information about other classes/objects.)
Ian Holland PhD 1992:
Vice President of Architecture and Systems Engineering
at Kronos Incorporated in Chelmsford, MA. 2200 empls.
11
Adaptive Programming.
• AP-Concern-shy: concerns shy of other concerns
– AP-Structure-shy: concerns shy of graph structure
• AP-WildCard: aspects shy through wildcards
– AspectJ: *, .., this, target, args, call, execution, … (call graph)
50 pages • AP-Strategy: three level model using strategies
– AP-Call: aspects shy of call graph using strategies
of theory
Best of
both worlds
» AspectJ: cflow
– AP-Demeter: behavior shy of class graph using strategies; advice
on traversal
» AP-DJ: ClassGraph, Strategy, Visitor (in Java)
» AP-DAJ: Strategy enhances ClassGraph; Visitor enhances
traversal defined by Strategy (in AspectJ)
» AP-DemeterJ (new programming language)
12
Adaptive Programming.
• AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
Alternative
organization:
• AP-Concern-shy
– AP-Graph-shy
• AP-CallGraph-shy
X-shy
• AP-ClassGraph-shy
subX-shy
– AP-WildCard
Mechanism-to-achieve-shyness
– AP-Strategy
13
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-Structure-shy
• Program with multiple building blocks
including b1and b2:Graph, that are woven
together. b1 relies only on partial
information about b2 which makes b1 more
robust and reusable. Goal: b1 should be
loosely coupled to b2. b1 enhances b2 at
nodes and edges.
14
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-WildCard
• Program with multiple building blocks
including b1 and b2:Graph, that are woven
together. b1 uses wildcard techniques which
makes b1 more robust and reusable. Goal:
b1 should be loosely coupled to b2.
15
•
One contributor: Ignacio Silva-Lepe PhD 1994
Currently at IBM Watson Research Lab
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-Strategy
• Program with multiple building blocks
including b1:Strategy and b2:Graph, that
are woven together. b1 reveals only partial
information about b2 which makes b1 more
robust and reusable. b1 is written against an
abstraction of b2 so that the application to
b2 is well defined. Goal: b1 should be
loosely coupled to b2.
16
From TOPLAS 2003 paper (Lieberherr, Patt-Shamir, Orleans)
A General Strategy-based
Adaptive Mechanism
• Three layers of graphs: Bottom, Middle, Top
– Bottom layer: trees to select subtrees guided by
top layer. Each bottom layer tree has a graph from
the
– Middle layer associated with it that contains metainformation about the bottom layer tree. Acts as an
abstraction barrier between the top and bottom
layers. Used to reduce search space.
– Top layer graph is basically a subgraph of the
transitive closure of the middle layer graph,
decorated with additional information attached to
17
the edges.
Top graph: subgraph of transitive closure of middle layer
A
B
C
Middle graph: Abstraction barrier
A
B
C
Bottom tree: select subtrees
B
A
c1:C
c2:C
c3:C
18
Strategy-based adaptiveness
• The call graph application (AspectJ):
– Top: computational pattern,
– Middle: static call graph,
– Bottom: call tree.
• The standard application (Demeter):
– Top: strategy graph,
– Middle: class graph,
– Bottom: object trees.
19
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-Call
• Program with multiple building blocks
including b1:CrossCut and b2:CallGraph,
that are woven together. b1 reveals only
partial information about b2 which makes
b1 more robust and reusable. Advice on b2
at b1.
20
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-AspectJ
• Program with multiple building blocks
including b1:PointCut and b2:CallGraph,
that are woven together. b1 reveals only
partial information about b2 which makes
b1 more robust and reusable. Advice on b2
at b1.
21
AP-AspectJ
• Many AspectJ programs are adaptive (designed for a
family of Java programs)
– Context: Java program or its execution tree (lexical joinpoints
or dynamic join points)
• Features enabling adaptiveness:
– *, .. (wildcards)
– cflow, + (graph transitivity)
– this(s), target(s), args(a), call (…), …
(inheritance as wild card)
• pc(Object s, Object t):
this(s) && target(t) && call(… f …)
22
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-COOL
• Program with multiple building blocks
including b1:Coordinator and b2:CallGraph,
that are woven together. b1 reveals only
partial information about b2 which makes
b1 more robust and reusable. Advice on b2
at b1.
Crista Lopes, PhD 1997
Assistant Professor at UC Irvine, first PhD thesis on AOP.
23
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-Demeter
• Program with multiple building blocks
including b1:Strategy and b2:ClassGraph,
that are woven together. b1 reveals only
partial information about b2 which makes
b1 more robust and reusable. Advice on
traversal defined by b1 and b2.
24
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-DJ
• Program in terms of ClassGraph-, Strategyand Visitor-objects.
• Example:
– in Java: cg.traverse(o, s, v);
The easiest tool to learn good structure-shy
programming
25
•
AP-Concern-shy
– AP-Structure-shy
• AP-WildCard
• AP-Strategy
– AP-Call
– AP-Demeter
AP-DAJ
• Program in terms of Strategy-objects that
introduce traversal methods into ClassGraphobjects (adaptiveness to class graph).
• Enhance the execution of the traversal methods
with Visitor-objects that may modify the run-time
traversal (adaptiveness to the traversal execution).
• Example: In AspectJ: declare traversal f(): s V;
o.f();
26
crosscutting
base
Adaptive to
family of
bases
Isolated join points
Connected join points
27
Demeter crosscutting I
Class graph or
Object graph
From Company to Salary
Adaptive to
family of
class graphs
From BusRoute via BusStop to Person
Connected join points
28
Demeter crosscutting II
Static call graph or
Dynamic call graph
From Company to Salary
Adaptive to
family of
traversal call
graphs
…_salary(Employee, Object)
Isolated join points
Connected join points
29
AspectJ crosscutting I
Company.cache(){}
Isolated join points
Class graph or
Object graph
Vector BusRoute.busses;
30
AspectJ crosscutting II
Static call graph or
Dynamic call graph
Adaptive to
family of
call graphs
cflow
target(Employee)
Isolated join points
Connected join points
31
Demeter crosscutting
Graph
From BusRoute via Bus to Person
Adaptive to
family of
graphs
…_salary(Employee, Object)
Isolated join points
Connected join points
32
How are AP and AOP coupled?
• AOP: module-shy programming
– Modularize programs that cut across modules
(with minimal reliance on information in
modules).
– Programming is module-shy if the modular
structure of the program does not prevent
concerns that cut across other concerns to be
modularized.
• AP: concern-shy programming
Can we view concern implementations as modules?
33
Many open questions
•
•
•
•
Doug Orleans: Simple model of AOP: Fred
Johan Ovlinger: Modules and Aspects
Pengcheng Wu: Statically Executable Advice
Theo Skotiniotis: Contracts for Aspects
34
The End
35
Crosscutting in Demeter
generated
Java program
Demeter program
structure-shy
functionality
structure
replicated!
synchronization
36
range of AOP languages
means of … join points
JPM
join points
identifying
specifying semantics at
AspectJ
dynamic JPM
points in execution
call, get, set…
signatures
w/ wildcards &
other properties of
JPs
advice
class members
signatures
add members
when traversal reaches
object or edge
visitor method bodies
class members
visitor method
signatures
traversal spec. s
class graph g
class members
class names
class members
class graph
add members
class graph with
tokens=grammar (result =
parsing and printing
implementation)
static JPM
DemeterJ, DAJ
dynamic JPM
static JPM 1
static JPM 2
static JPM 3
s + g (result = traversal
implementation)
37
Adaptiveness
• The next 7 viewgraphs show how two
traversals (parts of an adaptive program)
adapt to two different class graphs.
38
Class graph:
Find undefined things
System
Ident
definedThings
*
usedThings *
S
T
def
*
Definition
body
D
Thing
*
Body
B
definedThings= from System bypassing Body to Thing
usedThings = from System through Body to Thing
39
M1: Equation System
EquationSystem
equations
Equation_List
Ident
*
Variable
lhs
Equation
Numerical
rhs
Expression
Expression_List
Simple
args
*
op
Compound
Add
40
definedThings = from EquationSystem
bypassing Expression to Variable
M1: Equation System
EquationSystem
equations
Equation_List
Ident
*
Equation
lhs
Variable
Numerical
rhs
Expression
*
Simple
args
Expression_List
op
Compound
S
T
Add
D
41
B
usedThings = from EquationSystem
through Expression to Variable
M1: Equation System
EquationSystem
equations
Equation_List
Ident
*
Equation
lhs
Variable
Numerical
rhs
Expression
*
Simple
args
Expression_List
op
Compound
S
T
Add
D
42
B
CS1: Grammar
0..*
Entry
EParse
entries
Grammar
BParse
Production
Body
rhs
parts
0..*
Concrete
Part
lhs
NonTerm
Abstract
43
definedThings = from Grammar bypassing Body to NonTerm
CS1: Grammar
0..*
Entry
EParse
entries
Grammar
BParse
Production
Body
rhs
parts
0..*
Part
lhs
NonTerm
S
Concrete
Abstract
T
D
B44
usedThings = from Grammar through Body to NonTerm
CS1:Grammar
0..*
Entry
EParse
entries
Grammar
BParse
Production
Body
rhs
parts
0..*
Part
lhs
NonTerm
S
Concrete
Abstract
T
D
B45
46
AP-structure-shy:
notion of crosscutting
• B2 = program and its execution trees or an abstraction
thereof: UML class diagram and its object diagrams.
• A program b1*b2 is aspect-oriented if it is crosscutting.
• Examples: Adaptive, aspect-oriented programs: Policies
(Concurrency, Distribution, Authentication, Logging),
Adaptive Method, Law of Demeter Checker in AspectJ
47
Scattering
• B2 is a graph. Count number of nodes and edges
that are enhanced. Scat(b1*b2) = number of nodes
and edges in b2 enhanced by b1. The higher the
number, the more the crosscutting.
• A program b1*B2 is crosscutting if there is an
infinite sequence R1, R2, … of B2 so that
Scat(b1*R1), Scat(b1*R2), … is strictly
increasing.
48
XAspects: An Extensible
System for DomainSpecific
Aspect Languages
Macneil Shonle
Ankit Shah
Karl Lieberherr
49
Goal of AOSD
• Decompose problem into
– Representation languages that support structure-shy
representations of objects (Object representation
concern for input/output/intermediate objects)
• Benefit: define objects in a structure-shy way. Need structureshy language design (not XML).
– domain-specific aspect languages that support concernshy representations of concerns. Aspect languages are
IO-languages-shy.
50
Why Domain-Specific
Aspect Languages?
• Concerns whose implementation in the chosen PL is
either scattered or the concern implementation
duplicates information of other concerns.
• Example: Use case U1 concern implemented by
adaptive method:
– Is scattered (follow Law of Demeter): traversal methods
are spread over many modules
– Duplicates (Law of Demeter is violated): traversal is
modularized in one method BUT duplication of class
graph
51
DSL
• Domain Specific Languages (DSL) are
programming languages which sacrifice
generality for closeness to a particular
problem area. By reducing the conceptual
distance between the problem space and the
language used to express the problem,
programming becomes simpler, easier, and
more reliable. The amount of code which must
be written is reduced -- increasing productivity
and decreasing maintenance costs.
52
Shyness can be defined in many different ways:
An implementation of a concern C_1 is C_2-shy if:
•The C_1 implementation relies only on minimal information of C_2
implementations.
•The C_1 implementation can adapt to small changes in C_2
implementations.
•The C_1 implementation is loosely coupled with C_2
implementations.
•The C_1 implementation can work with a family C'_2, C''_2, C'''_2,
… of C_2 implementations that are “similar”.
53
D*J = DemeterJ/DJ/DAJ
Shy: a useful term
• AP = concern-shy programming
– D*J: class-graph-shy programming
• AOP = module-shy programming
– AspectJ is call-graph-shy programming
– AspectJ is class-graph-shy programming
– AspectJ-DAJ is better class-graph-shy programming
• Obliviousness: program is aspect-shy
54
Related Work
•
•
•
•
D
AspectJ
DemeterJ
DAJ
55
Related Work: SDP
NSF Workshop
• Jim Hugunin: The Next Steps For
Aspect-Oriented Programming
Languages (in Java)
• Don Batory: ExCIS: An Integration of
Domain-Specific Languages and
Feature-Oriented Programming
56
Related Work: Jim Hugunin
• While aspect libraries can provide some
domain specific support in a general
purpose AOP language such as AspectJ, it is
likely that some domains will be important
enough to warrant the creation of domainspecific AOP languages. Some engineering
approaches to encourage that sort of work
are discussed in the next section.
57
Jim Hugunin
• The next obvious step for this extensibility is to provide
clearly documented and stable public APIs for adding
things like custom pointcut designators or new static
program transformations through extensions of the declare
language space. This would make it easy for other Javabased AOP languages such as DemeterJ [10] to be
implemented as a compatible extension to AspectJ.
Further into the future, work is needed to determine the
right way to enable programmers to extend these languages
without operating on the compiler.
58
Work to be done (Batory)
• Debuggers. Domain-specific languages are not
new languages, but rather extensions of current,
standard languages. So, standard development
environments and debuggers can be used with
DSLs. However, if the programmer works in the
context of the base language (C++, Java, etc.)
rather than the extended language, much of the
simplicity obtained by using the DSL is lost.
Therefore, DSL specific debuggers are required.
59
Work to be done (Batory)
• Visual Programming Tool-kit. The ExCIS tool-kit
supports the construction of domain-specific languages.
This simplifies the problem of producing a DSL, but does
not assist in providing an interface between the user and
the DSL. An equivalent tool-kit for the construction of
visual programming environments linked to a domainspecific language is needed. Such a tool-kit would allow
the DSL designer to easily specify a visual programming
interfacethat would generate the required DSL code. Some
degree of round-trip engineering would be supported.
60
Work to be done (Batory)
• Visual Programming Tool-kit. The ExCIS toolkit supports the construction of domain-specific
languages. This simplifies the problem of
producing a DSL, but does not assist in providing
an interface between the user and the DSL. An
equivalent tool-kit for the construction of visual
programming environments linked to a domainspecific language is needed. Such a tool-kit would
allow the DSL designer to easily specify a visual
programming interface that would generate the
required DSL code.
61
Work to be done (Batory)
• Program Composition Validation. The
mechanisms used for the construction of programs
using feature-based components lend themselves
to automated validation for correct composition.
Preliminary work shows that relatively simple
mechanisms can be employed to validate a
proposed composition of features [2]. More
sophisticated algorithms from model checking
may extend our capability to compose correct
systems [9].
62
Work to be done (Batory)
Program Composition Optimization. Any given
program feature can usually be implemented in a
variety of ways. The best implementation for an
application will depend upon non-functional
requirements such as performance constraints or
resource usage. A feature component library contains
not only components, but also a characterization of the
component. By specifying both functional and nonfunctional requirements, the system assembler can
optimize the selection of components to satisfy both
types of requirements [3].
63
Need for Domain-Specific AL
We conjecture that this gap between domainspecific aspect languages and general
purpose aspect languages will always exist
because any general solution cannot cover
all possible ways an aspect can crosscut a
system. By their nature concerns are related
to the problem domain, and there is an innite
variety of forms that problem domains can
take.
64
Aspect Libraries
AspectJ has some support for particular
domains via abstract aspect libraries: The
pointcut sets described by an abstract
aspect can be defined later by a concrete
aspect. Only a limited set of problems has
thus far created useful aspect libraries.
65
Problem with multiple DSLs
A tool for each concern that translates to
AspectJ.
The fragmentation of tools causes problems
when each concern relies on the solutions
provided by the other tools.
While a parser can be orthogonal to the rest of
the program, a traversal through the program
cannot be orthogonal.
66
Plug-in Architecture
The fragmentation problem can be solved by forcing
each domain-specific solution to conform to
particular framework and by defining a common
language with which the domain-specific tools can
communicate. The XAspects tool provides a plug-in
framework that integrates domain-specific
languages such that the tools become extensions
of the AspectJ language. Rules on what a plug-in
can do are introduced in order to enhance the
integration.
67
Example
01 aspect(ClassDictionary) CompactDisc {
02 CD = "cd" <album> String "by" Artist ","
03 "(" <upc> UPCNumber ")" ".";
04 Artist : SingleArtist | MultipleArtist;
05 SingleArist = Name;
06 MultipleArist = Name "," CommaList(Name);
07 Name = String;
08 UPCNumber = String;
09 CommaList(S) ~ S { "," S };
68
10 }
2.2 Compilation Phases
The XAspects compiler and each plug-in tool
communicate with each other four times:
1. The XAspects compiler identies in the source code all
program text that belongs to the plug-in and
providesthat text to the plug-in.
2. The plug-in generates source les that dene the
external (i.e. program visible) components introduced
by the language that the plug-in implements.
3. The XAspects compiler provides the plug-in the
complete binary of the program.
4. The plug-in generates behavioral changes to the
generated program in the form of AspectJ source
69
code.
2.2.1 Source Code
Identication
The input files to the XAspects compiler are
Java and AspectJ source files that are
allowed to include one minor syntactic
extension: When the aspect keyword is
followed by parentheses the parentheses
must contain a valid type name for a class
that can be found on the current class
path.
70
2.2.2 Generation of External
Interfaces
• The XAspects compiler then queries
each plug-in to provide a set of source
files that describe the program visible
interfaces generated by the plug-ins.
For example, the ClassDictionary plugin at this point will provide the list of
classes, methods and fields that were
described by the grammar.
71
External Interfaces
The external interfaces are described
through AspectJ source code. Therefore
the external interfaces can express new
classes or modications to existing
classes via inter-type declarations.
72
External Interfaces
The AspectJ source code generated needs to meet
the following restrictions:
• All new classes generated must be generated for
the same package in which the aspect body was
defined.
• All new classes generated must have a name that
appeared as an identifier token in the aspect body.
This restriction allows the user of the plug-in to
have full control over the names generated.
73
External Interfaces
• All new public fields or new public methods
introduced to existing classes (via inter-type
declarations) must have a name that appeared
as an identifier token in the aspect body.
The fields or methods introduced to new classes
do not have to be named by identifiers present
in the aspect body because any further
changes to that class will be done by external
inter-type declarations or plug-ins. Any name
clashes that arise can be handled in those
changes.
74
2.2.3 Crosscutting Analysis
After the external interfaces are generated by the
plug-ins, the rest of the AspectJ and Java source
is compiled with those interfaces. At this point the
structure of the program is complete and plug-ins
cannot add new fields to any of the classes.
Because the structure of the program is fixed the
complete bytecodes for the program can be
provided to each plug-in. Because each plug-in is
ultimately generating Java bytecodes, the changes
made by all plug-ins are in the same language.
75
Crosscutting Analysis
During this phase, domain-specific aspect
languages can perform structural
analysis on the program. For example,
the Traversal plug-in can generate
concrete paths based on the traversal
rules specified.
76
2.2.4 Generation of Semantics
Finally, each plug-in can provide semantic changes by using
AspectJ's dynamic join-point model. The implementation of
stub functions can be specified by using AspectJ's around
advice. New private methods can also be introduced at this
point by using inter-type declarations. Note that a private
inter-type declaration does introduce a private method to the
class, rather it introduces a method to the class that is only
visible by the generating aspect. For example, the Traversal
plug-in can generate private methods to each of the classes
it needs to traverse: these private methods cannot be called
by other parts of the program.
77
Advantages of XAspects
The XAspects system is unique because it
separates conceptually two different
provisions of a domain-specific language:
• the langauge's external interface and
• its semantics.
The separation of these two concepts allows
for the plug-ins to passively cooperate with
each other.
78
Advantages of XAspects
The XAspects infrastructure essentially reduces
the problem for a domain-specific language to
the problem of reading in Java code and
producing changes and additions to that
code. Dependency issues among domainspecific languages are reduced: each plug-in
only has to worry about the properties of Java
classes, and not the properties of constructs
of other domain-specific languages that
created those classes.
79
Advantages of XAspects
It could be argued that it is not feasible to introduce many
little domain-specific languages that the programmers
have to work with. However, the inherent complexity of a
project may require that the programmers address the
issues of composition of aspect languages on a
conceptual level. A conscious language design that
addresses the aspect composition issues systematically
can simplify the programmer's job: Without such an
approach, the programmers will have to do this at the
lower level of a general purpose aspect language, which
results in more code that actually needs to be written,
some of which will be redundant with the structure of the
program and could have been automatically generated.
80
Future work
•
•
•
•
Add Multi-Java as a plug-in.
HyperJ like features.
Composition filters.
Sandbox for experimenting with multiple
AOP approaches.
81
End
82
Mitch Suggestion
• Spectrum
– Oblivious
• Nothing at all
– Information-Hiding
• Well defined interface
– Shyness
• Goes inside; information restriction
• Program, structure, class graph, call graph, concern,
aspect
83
Goal of AOSD
• Decompose into domain-specific languages
DL1, … and aspect-specific languages AS1,
…
– Dli have minimal overlap
– As1 is shy of Dli and other Asi (elements of
AS1 are shy of elements of DL1 and elements
of
84