Transcript The APPC Pattern Benefiting from advances in component software technology using standard languages

The APPC Pattern
Benefiting from advances in
component software technology using
standard languages
5/23/2016
UBS
1
Design patterns and
programming language features
• They are conceptually equivalent.
• Useful to explain language features using
design pattern terminology.
• Danger of design patterns: workarounds
needed to implement them can be tedious.
Patterns are only used if benefit outweighs
the cost.
5/23/2016
UBS
2
Motivation
• New component software ideas have a big
acceptance threshold if they require nonstandard language extensions.
• Use many of the good ideas with standard
languages and suitable libraries/frameworks
without language extension.
• Describe ideas using pattern terminology
for easy reuse by designers/programmers.
5/23/2016
UBS
3
5/23/2016
UBS
4
Strategies: Three solutions
• Interpreter: Describe as String-objects
– requires concrete syntax
– less verbose, more robust, easier to read
– requires a parser (generated by JavaCC)
• Constructor: Build Strategy-objects
– more verbose, less robust, harder to read
– easy composition using Java
• Hybrid: Interpreter and Constructor
5/23/2016
UBS
5
Strategies: Example: Interpreter
“{ A -> C”+
“ C -> D}”
“{ A -> C C -> D }”
“from A via C to D”
5/23/2016
UBS
6
Strategies: Example: Constructor
S = new Strategy(new
EdgeList());
S.append (new Edge
(“A”,
new String(“C”)));
S.append (new Edge
(new String(“C”), ...
5/23/2016
UBS
7
Hybrid solution
• In addition to constructors:Separate strategy
file where strategies are named and defined.
• class TRAV{static X long_get
(Object o,Strategy s)…};
TRAV.long_get(o, s1);
• Strategy file:
s1 = from A via B to C;
5/23/2016
UBS
8
Hybrid solution
• Combines advantages of both
• But requires two interfaces: a concrete
syntax interface and an abstract syntax
interface
• Allows to summarize all strategies in one
file
5/23/2016
UBS
9
Preferred Solution initially:
Constructor
• Use constructors to build Strategy-objects
– Strategies are not very big
– Composition is important
• S1 = new Strategy(…);
• S2 = new Strategy(…);
• S3 = new Intersection(S1,S2);
– More flexible: S4 = f(S1,S2,S3);
• f a Java function
5/23/2016
UBS
10
Traversal Support for Java: class
Traversal
• static Object long_get(Object
o, Strategy s);
• static Iteration
long_collect(Object o,
Strategy s);
• static Object traverse(Object
o, Strategy s, Visitor v[]);
5/23/2016
UBS
11
Traversal Support for Java
• static X long_get(Object o,
Strategy s);
– starting at object o, traverse down following s
and return target object of s
– s must have a single target and s must specify
unique path
5/23/2016
UBS
12
Traversal Support for Java
• static Iteration
long_collect(Object o,
Strategy s);
– starting at object o traverse following s and
return the collection of target objects of s.
5/23/2016
UBS
13
Traversal Support for Java
• static Object traverse(Object
o, Strategy s, Visitor v[]);
– starting at object o traverse down following s
and execute the visitors in v. Return the object
returned by first visitor.
5/23/2016
UBS
14
Traversal Support: visitors
class SampleVisitor extends Visitor{
// local variables
public SampleVisitor(); // initialize
public void before(Visited host);
public void after (Visited host);
public void before_z(X source, Y dest);
public void after_z (X source, Y dest);
Object get_return_val();
public void start();
public void finish();
}
5/23/2016
UBS
15
Traversal Support: visitors
abstract class Visitor {
// GENERATED CODE EXAMPLE
public Visitor() {super();}
public void start() { }
public void finish() { }
public void before(Visited host);
public void after (Visited host);
public void before_p(Q source, H dest);
public void after_p (Q source, H dest);
…
}
5/23/2016
UBS
16
Class Graph Extraction from
Java Source
• Needed for
– strategy interpretation
– Visitor generation
• Supported by many tools
5/23/2016
UBS
17
APPC ingredient
• ICG objects
• CCG objects
5/23/2016
UBS
18
APPC:Intent
• Filter out noise from implementations:
Describe popular behavior in terms of an
idealized class structure (ideal class graph =
view), using traversal strategy graphs and
visitors as appropriate.
• Map idealized class structure to concrete
class structure using traversal strategy
graphs as appropriate.
5/23/2016
UBS
19
Tension:delete
• Define behavior separately from classes
– Can use it multiple times
– Also makes sense for single impl. class
• Define behavior for ideal class graph
– Is generalization of first
• What is relationship between personalities
and APPCs?
5/23/2016
UBS
20
APPC:Motivation
• Have an encapsulated unit for behavioral
abstraction for new behavior covering
multiple classes.
• Concrete class structures are overworked
and to favor reusability each behavior
should be expressed in terms of an idealized
class structure that is mapped flexibly into a
concrete class structure.
5/23/2016
UBS
21
Motivation
• ICG/CCG approach not only favors
reusability, but it also makes programs
simpler.
• Program towards an abstract structure.
Program towards spec Kiczales/Lamping
• Distinguish between "IS-A" and "PLAYSTHE-ROLE-OF" relationships.
5/23/2016
UBS
22
Motivation
• Make visitor pattern more flexible (David).
• Reuse with different class structures or
multiple times in same class structure.
5/23/2016
UBS
23
• Views and ccg
5/23/2016
UBS
24
APPC:Applicability
• Use to implement "popular" behaviors.
• Whenever you have a class hierarchy (IS-A)
and a behavior assignment to classes
(PLAYS-THE-ROLE-OF) so that the IS-A
structure cross-cuts the behavior
assignment.
5/23/2016
UBS
25
APPC:Applicability
• Whenever the implementation of a behavior
uses classes that are not central to the
behavior.
5/23/2016
UBS
26
APPC:Structure
•
•
•
•
Strategy graph, expansion
ideal class graph, expansion
class graph
An APPC has local data and functions and
a constructor and an upstream and
downstream interface.
5/23/2016
UBS
27
APPC:Structure
• An APPC provides an implementation for a
set of functions (the upstream interface) that
modify classes that implement the
downstream interface of the APPC.
5/23/2016
UBS
28
APPC:Implementation
• Code runs in CCG objects.
– Demeter/Java uses this approach
• Code runs in ICG objects.
– Class graph views use this approach
– Simulate APPC by a Java Package
– How to manage correspondence between ICG
and CCG objects?
5/23/2016
UBS
29
APPC:Implementation
• Mapping from ICG to CCG is best specified
with Traversal Support for Java.
5/23/2016
UBS
30
• While traversing, disallow loading new
classes!
• When object graph is given, classes are
loaded.
• intercept class loader.
5/23/2016
UBS
31
Is there a Law of APPCs?
• ICG: two roles:
– define what is expected from CCG
– define what is added to CCG
5/23/2016
UBS
32
Is there a Law of APPCs?
• The downstream interface must be a set of
pure abstract functions.
• Clients of the APPC must not use the the
downstream interface.
5/23/2016
UBS
33
Is there a Law of APPCs?
• The implementation of the popular
functions must be protected against changes
by the client classes.
5/23/2016
UBS
34
Is there a Law of APPCs?
• The implementation of popular functions is
allowed to use the DI/UI/private methods
and methods of classes returned by the
DI/UI/private methods and nothing more
(Generalization of Law of Demeter).
• Less restrictive but it is ok to have
violations of standard LoD.
5/23/2016
UBS
35
Law of components
• Negotiating phase
• building time negotiation
• plug-and-play
5/23/2016
UBS
36
Simulating APPCs
• Assigning to class structure: use delegation
as with personalities (egos)?
5/23/2016
UBS
37
Interesting system
• Graph G1: edges may be labeled with
strategies for graph G2.
• Graph G2: edges may be labeled with
strategies for graph G3.
• Etc.
• Hierarchical
5/23/2016
UBS
38
A
b
B
5/23/2016
c
d
C
D
UBS
39
A’
A
b
c
C’
B’
B
5/23/2016
C
UBS
d
D’
D
40
Interface Class Graph
• Serves as “short-cut” in concrete class
graph.
5/23/2016
UBS
41
Demeter/Java
• Interface class graphs are simulated by
derived edges. Graphs are embedded.
5/23/2016
UBS
42
APPCs in Java
• APPC is represented by Java package
• one class is distinguished as main class:
Facade
• unfortunately no inheritance between
packages: cannot refine APPCs
5/23/2016
UBS
43
Implementation space
• Delegation: code activated from concrete
class structure. Delegates to APPC code.
• Insertion: code activated from and running
in concrete class structure.
5/23/2016
UBS
44
Using an APPC with Delegation:
Pricing in A.
• Class A implements PricingI
• PricingI is an interface obtained from main
class of Pricing package: _Pricing
• In class A:
– data member: Pricing_Ego _pricing = new
Pricing_Ego();
– function member: int price(…) {return
_pricing.price(this, …); }
5/23/2016
UBS
45
Using an APPC
• Pricing_Ego is obtained from Pricing
package. Implements upstream methods of
main class of package: _Pricing.
• public int price(_Pricing host, …) // this has
been replaced by host
5/23/2016
UBS
46
• Other classes than distinguished class also
get new code
5/23/2016
UBS
47
Citibank Quote: Law of Demeter
• The Law of Demeter forms one of the
cornerstones of the design approach of the
Global Finance Application Architecture
(quote from: Global Finance Application
Architecture: Business Elements Analysis,
Oct. 1991, Citibank confidential document)
5/23/2016
UBS
48
Generalized Law of Demeter
Law of Demeter Principle
• Each unit should only use a limited set of
other units: only units “closely” related to
the current unit.
• “Each unit should only talk to its friends.”
“Don’t talk to strangers.”
• Motivation: Control information overload.
We can only keep a limited set of items in
short-term memory of our minds.
5/23/2016
UBS
49
Examples
• Unit = method
– closely related =
• methods of class of this and other argument
classes
• methods of immediate part classes (classes that are
return types of methods of class of this)
5/23/2016
UBS
50
Examples
• Unit = function
– closely related =
• functions of parameter types
• functions of return types of functions of any of the
parameter types
5/23/2016
UBS
51
The Law of Demeter (cont.)
Violation of the Law
class A {public: void m(); P p(); B b; };
class B {public: C c; };
class C {public: void foo(); };
class P {public: Q q(); };
class Q {public: void bar(); };
void A::m() {
this.b.c.foo(); this.p().q().bar();}
5/23/2016
UBS
52
Violations: Dataflow Diagram
m
B
A
foo()
2:c
1:b
C
bar()
3:p()
4:q()
P
5/23/2016
Q
UBS
53
Elimination of Violation
m
foo2
B
2:foo2()
4:bar2()
A
foo()
c
1:b
C
bar2
bar()
3:p()
q()
P
5/23/2016
Q
UBS
54
Does AP help?
5/23/2016
UBS
55
Motivation
• AP has the AI flavor that it automatically
transforms programs when the context
(class graph) changes.
• Some people see this power as a danger.
• We point out that when a proper software
engineering process is followed there is no
danger.
5/23/2016
UBS
56
Motivation
• Some people feel that AP tools cannot give
the same static error messages as OO tools.
We show that this is not the case.
5/23/2016
UBS
57
What does AP save during
evolution? Terminology.
• T(G): traversal methods for G.
• TG(G,S): traversal graph for G and S.
• Compatible(G,S): Is G compatible with S? For all
edges (x,y) in S there is a path in G from x to y.
5/23/2016
UBS
58
What does AP save during
evolution? Terminology.
• Diff(TG1, TG2), Diff(T(G1), T(G2)): list
differences for each node.
• Errors(G2,T(G1)): compiler error messages
• Errors(G2, G1): if G1 has an edge (A,B) then G2
has such an edge, otherwise report error.
5/23/2016
UBS
59
For AP library
• Errors(G2, G1): if G1 has an edge (A,B)
then G2 has such an edge, otherwise report
error.
• Intent: Lists all the places where the old
traversal (G1) brakes if used in new class
graph (G2).
• Information for test specification: check
whether redirections are correct.
5/23/2016
UBS
60
For AP library
• Errors(G2, G1): if G1 has an edge (A,B)
then G2 has such an edge, otherwise report
error.
• Note: The Errors(G2,G1) function is similar
to checking whether G1 is an “instance” of
G2.
5/23/2016
UBS
61
Written by user
Inspected by user, generated by compiler
What does AP save during
evolution?
• Both: Class graphs G1 and G2. Traversal methods
T(G1) and T(G2) to be tested.
– AP: Strategy graphs S1, S2. Traversal graphs
TG(G1,S1) producing T(G1) and TG(G2,S2)
producing T(G2). Compatible(G1,S1),
Compatible(G2,S2). Errors(G2, Graph(TG(G1,S1))).
Diff(TG(G1,S1), TG (G2,S2)).
– OO: T(G1) and T(G2). Compatible(G2,T(G2)). Errors
(G2,T(G1)). Diff(T(G1), T(G2)).
5/23/2016
UBS
62
Written by user
Inspected by user, generated by compiler
Comparing AP versus OO during
evolution: effort
• AP
• OO
– #S1,TS  S2
– $Compatible(G2,S2)
– §Errors(G2,
Graph(TG(G1,S1)))
– ‡Diff (TG(G1,S1),
TG(G2,S2))
–
–
–
–
#T(G1),TS  T(G2)
$Compatible(G2,T(G2))
§Errors(G2,T(G1))
‡Diff (T(G1), T(G2))
Common: G1  G2, test(T(G1)), test(T(G2)), trav. change spec. TS
Comparable effort: testing § ‡ AP less effort on average: # $
5/23/2016
UBS
63
Written by user
Inspected by user, generated by compiler
Comparing AP versus OO during
evolution: static checking
• AP
• OO
– #S1,TS  S2
– $Compatible(G2,S2)
– §Errors(G2,
Graph(TG(G1,S1)))
– ‡Diff (TG(G1,S1),
TG(G2,S2))
–
–
–
–
#T(G1),TS  T(G2)
$Compatible(G2,T(G2))
§Errors(G2,T(G1))
‡Diff (T(G1), T(G2))
Common: G1  G2, test(T(G1)), test(T(G2)), trav. change spec. TS
Comparable information: $ § ‡
5/23/2016
UBS
64
S1
G1
A
C
A
B
Example
S2
C
G2
A
B
A
B
C
K
C
K
C
X
T(G1)
A
B
C
T(G2)
AP
Errors A
B
A
B
OO
Errors A
C
B
K
Diff
A
5/23/2016
B
C
K
C
UBS
Diff
A
C
B
65
Example
S1 = from A to C
G1:A,B;B,C
T(G1):A B C
Compatible: yes
Errors: no B,C
Diff: B,C>B,K. new K,C
5/23/2016
S2 = from A via B to C
G2:A,B|A,X|B,K|K,C|X,C
T(G2): A B K C
Compatible: yes
Errors: no B,C
Diff:B,C>B,K. new K,C
UBS
66
Comparison: AP versus OO
during evolution
• Static analysis information
– AP gives similar static information as OO
• Evolution effort
– AP never worse than OO
– in many cases AP less effort
• Danger of wrong traversals: testing needed.
– OO: possibility of errors not detected statically.
– AP: possibility of strategy being wrong. If strategy
correct, traversal guaranteed to be correct.
5/23/2016
UBS
67
Comparison: AP versus OO
during evolution
• If class graph changes, it is necessary to re-test
generated program.
• Whether program is hand-coded or generated, it
needs to be tested.
5/23/2016
UBS
68
Abusing AP
• No retesting after class graph change. Reusing
a piece of software (e.g., a strategy) in a new
context (a new class graph) requires retesting.
Antidecomposition adequacy rule
(Weyuker)
– There exists a program P and a component Q of P
such that T is adequate for P, T' is the set of vectors of
values that variables can assume on entrance to Q for
some t of T and T' is not adequate for Q.
5/23/2016
UBS
69
Abusing AP
• Ignoring Errors() and Diff() output
because the regenerated program
compiles. Uncritical acceptance of the
analogical transformation done by the
AP compiler.
5/23/2016
UBS
70
Doug
• APPC pattern
• Demeter/Java pattern
• AP library: Mitch
– new nodes
– deleted nodes
– changed nodes
• Collaboration
5/23/2016
UBS
71
Cd from Java
• Run-time constr. of cd from class files: later
– not all classes loaded
– info. Not available due to package security
5/23/2016
UBS
72
Key ideas
• Separate behavior from structure: assign
behavior to structure separately. Like
methods and classes. Need to provide
context.
5/23/2016
UBS
73
Upstream Interface
Personality
Downstream Interface
5/23/2016
UBS
74