Shyness in Programming

1
Shyness in Programming

• Karl Lieberherr
• Demeter Research Group
• Northeastern University
• Boston

2
XAspects

• Go to slide 49

3
Coupling Aspect-Oriented and Adaptive
ProgrammingShyness in Programming

• PhD Visitation Weekend 2003

4
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").

5
MIT Technology Review2001

• Aspect-oriented programming is called adaptive
  programming at Northeastern University.

6
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.

7
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?

8
Scattering and Tangling Static

• aspecti is scattered across many classes (i
  1,2,3)
• class X tangles aspects 1, 2 and 3

class A consisting of three aspects
aspect1
aspect2
aspect3
class diagram
Class X
classes for aspect1
classes for aspect3
classes for aspect2
Adding to classes
9
Scattering and Tangling Dynamic

• Each aspect (colors) is scattered across many
  classes (shapes)
• Class tangles all three aspects

program execution involving three aspects
(colors r b g)
this(s)
f(..)
target(t)
program call tree (classes executing method
calls)
Enhancing calls
t.f(..)
classes
At those calls the aspect enhances the behavior
10
AP-Concern-shy

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks, say b1B1
  and b2B2, that are woven together b1b2. b1
  relies only on partial information about b2 which
  makes b1 more robust and reusable. Goal b1
  should be loosely coupled to b2.

11
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.
12
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)
• AP-Strategy three level model using strategies
• AP-Call aspects shy of call graph using
  strategies
• 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)

50 pages of theory
Best of both worlds
13
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
• AP-ClassGraph-shy
• AP-WildCard
• AP-Strategy

X-shy subX-shy Mechanism-to-achieve-shyness
14
AP-Structure-shy

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks including
  b1and b2Graph, 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.

15
AP-WildCard

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks including
  b1 and b2Graph, that are woven together. b1 uses
  wildcard techniques which makes b1 more robust
  and reusable. Goal b1 should be loosely coupled
  to b2.

16
AP-Strategy
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

• Program with multiple building blocks including
  b1Strategy and b2Graph, 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.

17
A General Strategy-based Adaptive Mechanism
From TOPLAS 2003 paper (Lieberherr, Patt-Shamir,
Orleans)

• 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
  meta-information 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
  the edges.

18
Top graph subgraph of transitive closure of
middle layer
B
A
C
Middle graph Abstraction barrier
B
A
C
Bottom tree select subtrees
B
c1C c2C c3C
A
19
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.

20
AP-Call

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks including
  b1CrossCut and b2CallGraph, 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

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks including
  b1PointCut and b2CallGraph, that are woven
  together. b1 reveals only partial information
  about b2 which makes b1 more robust and reusable.
  Advice on b2 at b1.

22
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 )

23
AP-COOL

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks including
  b1Coordinator and b2CallGraph, 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.
24
AP-Demeter

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program with multiple building blocks including
  b1Strategy and b2ClassGraph, 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.

25
AP-DJ

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program in terms of ClassGraph-, Strategy- and
  Visitor-objects.
• Example
• in Java cg.traverse(o, s, v)

The easiest tool to learn good structure-shy progr
amming
26
AP-DAJ

• AP-Concern-shy
• AP-Structure-shy
• AP-WildCard
• AP-Strategy
• AP-Call
• AP-Demeter

• Program in terms of Strategy-objects that
  introduce traversal methods into
  ClassGraph-objects (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()

27
crosscutting
base
Adaptive to family of bases
Connected join points
Isolated join points
28
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
29
Demeter crosscutting II
Static call graph or Dynamic call graph
From Company to Salary
Adaptive to family of traversal call graphs
_salary(Employee, Object)
Connected join points
Isolated join points
30
AspectJ crosscutting I
Class graph or Object graph
Company.cache()
Vector BusRoute.busses
Isolated join points
31
Static call graph or Dynamic call graph
AspectJ crosscutting II
Adaptive to family of call graphs
cflow
target(Employee)
Connected join points
Isolated join points
32
Demeter crosscutting
Graph
From BusRoute via Bus to Person
Adaptive to family of graphs
_salary(Employee, Object)
Connected join points
Isolated join points
33
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?
34
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

35
The End
36
Crosscutting in Demeter
generated Java program
Demeter program
structure-shy functionality
structure
replicated!
synchronization
37
range of AOP languages
means of join points

JPM
join points
identifying
specifying semantics at
AspectJ dynamic JPM
points in execution call, get, set
signaturesw/ wildcards other properties of JPs
advice
add members
signatures
class members
static JPM

• DemeterJ, DAJ
• dynamic JPM
• static JPM 1
• static JPM 2
• static JPM 3

when traversal reaches object or edge class
members class members class members
visitor method signatures traversal spec. s class
graph g class names class graph
visitor method bodies s g (result traversal
implementation) add members class graph with
tokensgrammar (result parsing and printing
implementation)
38
Adaptiveness

• The next 7 viewgraphs show how two traversals
  (parts of an adaptive program) adapt to two
  different class graphs.

39
Class graph Find undefined things
Ident
definedThings
System

Thing

usedThings

def

S
Definition
T
body
Body
D
B
definedThings from System bypassing Body to
Thing usedThings from System through Body to
Thing
40
M1 Equation System
EquationSystem
equations
Equation_List
Ident

Variable
lhs
Equation
Numerical
rhs
Expression_List
Simple
args
Expression

op
Add
Compound
41
M1 Equation System
definedThings from EquationSystem bypassing
Expression to Variable
EquationSystem
equations
Equation_List
Ident

lhs
Equation
Variable
Numerical
rhs
Simple
args
Expression_List
Expression
S
T

op
Add
Compound
D
B
42
M1 Equation System
usedThings from EquationSystem through
Expression to Variable
EquationSystem
equations
Equation_List
Ident

lhs
Equation
Variable
Numerical
rhs
Simple
args
Expression_List
Expression
S
T

op
Add
Compound
D
B
43
CS1 Grammar
Entry
0..
EParse
entries
Grammar
BParse
Production
rhs
Body
Part
parts
lhs
NonTerm
0..
Concrete
Abstract
44
CS1 Grammar
definedThings from Grammar bypassing Body to
NonTerm
Entry
0..
EParse
entries
Grammar
BParse
Production
rhs
Body
Part
parts
lhs
NonTerm
0..
S
T
Concrete
Abstract
D
B
45
CS1Grammar
usedThings from Grammar through Body to NonTerm
Entry
0..
EParse
entries
Grammar
BParse
Production
Body
rhs
Part
parts
lhs
NonTerm
0..
S
T
Concrete
Abstract
D
B
46
Software Structure with ACs
Software Structure with ACs
Software Structure with ACs
P1
P1
P1
P2
P2
P2
P3
P3
P3
P1
P1
P1
P4
P4
P4
P3
P3
P3
P5
P5
P5
P2
P2
P2
P2
P2
P2
P6
P6
P6
P1
P1
P1
46
46
46
47
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 b1b2 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

48
Scattering

• B2 is a graph. Count number of nodes and edges
  that are enhanced. Scat(b1b2) number of nodes
  and edges in b2 enhanced by b1. The higher the
  number, the more the crosscutting.
• A program b1B2 is crosscutting if there is an
  infinite sequence R1, R2, of B2 so that
  Scat(b1R1), Scat(b1R2), is strictly
  increasing.

49
XAspects An Extensible System for
DomainSpecificAspect Languages

• Macneil Shonle
• Ankit Shah
• Karl Lieberherr

50
Goal of AOSD

• Decompose problem into
• Representation languages that support
  structure-shy representations of objects (Object
  representation concern for input/output/intermedia
  te objects)
• Benefit define objects in a structure-shy way.
  Need structure-shy language design (not XML).
• domain-specific aspect languages that support
  concern-shy representations of concerns. Aspect
  languages are IO-languages-shy.

51
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

52
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.

53
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.

54
Shy a useful term
DJ DemeterJ/DJ/DAJ

• AP concern-shy programming
• DJ 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

55
Related Work

• D
• AspectJ
• DemeterJ
• DAJ

56
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

57
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 domain-specific AOP languages. Some
  engineering approaches to encourage that sort of
  work are discussed in the next section.

58
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 Java-based 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.

59
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.

60
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
  domain-specific 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.

61
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
  domain-specific 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.

62
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.

63
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 non-functional requirements,
  the system assembler can optimize the selection
  of components to satisfy both types of
  requirements 3.

64
Need for Domain-Specific AL

• We conjecture that this gap between
  domain-specific 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.

65
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.

66
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.

67
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.

68
Example

• 01 aspect(ClassDictionary) CompactDisc
• 02 CD "cd" ltalbumgt String "by" Artist ","
• 03 "(" ltupcgt UPCNumber ")" "."
• 04 Artist SingleArtist MultipleArtist
• 05 SingleArist Name
• 06 MultipleArist Name "," CommaList(Name)
• 07 Name String
• 08 UPCNumber String
• 09 CommaList(S) S "," S
• 10

69
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 code.

70
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.

71
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
  plug-in at this point will provide the list of
  classes, methods and fields that were described
  by the grammar.

72
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.

73
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.

74
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.

75
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.

76
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.

77
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.

78
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.

79
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 domain-specific 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.

80
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.

81
Future work

• Add Multi-Java as a plug-in.
• HyperJ like features.
• Composition filters.
• Sandbox for experimenting with multiple AOP
  approaches.

82
End
83
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

84
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