The APPC Pattern

1
The APPC Pattern

• Benefiting from advances in component software
  technology using standard languages

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

3
Motivation

• New component software ideas have a big
  acceptance threshold if they require non-standard
  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.

4
Design Goals Plug and Play
2. black-box composition
5
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

6
Strategies Example Interpreter

• A -gt C
• C -gt D
• A -gt C C -gt D
• from A via C to D

7
Strategies Example Constructor

• S new Strategy(new EdgeList())
• S.append (new Edge
• (A,
• new String(C)))
• S.append (new Edge
• (new String(C), ...

8
Hybrid solution

• In addition to constructorsSeparate strategy
  file where strategies are named and defined.
• class TRAVstatic X long_get (Object
  o,Strategy s)
• TRAV.long_get(o, s1)
• Strategy file
• s1 from A via B to C

9
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

10
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

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

12
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

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

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

15
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()
16
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)
17
Class Graph Extraction from Java Source

• Needed for
• strategy interpretation
• Visitor generation
• Supported by many tools

18
APPC ingredient

• ICG objects
• CCG objects

19
APPCIntent

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

20
Tensiondelete

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

21
APPCMotivation

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

22
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 "PLAYS-THE-ROLE-OF"
  relationships.

23
Motivation

• Make visitor pattern more flexible (David).
• Reuse with different class structures or multiple
  times in same class structure.

24

• Views and ccg

25
APPCApplicability

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

26
APPCApplicability

• Whenever the implementation of a behavior uses
  classes that are not central to the behavior.

27
APPCStructure

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

28
APPCStructure

• An APPC provides an implementation for a set of
  functions (the upstream interface) that modify
  classes that implement the downstream interface
  of the APPC.

29
APPCImplementation

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

30
APPCImplementation

• Mapping from ICG to CCG is best specified with
  Traversal Support for Java.

31

• While traversing, disallow loading new classes!
• When object graph is given, classes are loaded.
• intercept class loader.

32
Is there a Law of APPCs?

• ICG two roles
• define what is expected from CCG
• define what is added to CCG

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

34
Is there a Law of APPCs?

• The implementation of the popular functions must
  be protected against changes by the client
  classes.

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

36
Law of components

• Negotiating phase
• building time negotiation
• plug-and-play

37
Simulating APPCs

• Assigning to class structure use delegation as
  with personalities (egos)?

38
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

39
A
b
c
d
C
D
B
40
A
A
b
c
d
C
B
D
C
D
B
41
Interface Class Graph

• Serves as short-cut in concrete class graph.

42
Demeter/Java

• Interface class graphs are simulated by derived
  edges. Graphs are embedded.

43
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

44
Implementation space

• Delegation code activated from concrete class
  structure. Delegates to APPC code.
• Insertion code activated from and running in
  concrete class structure.

45
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, )

46
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

47

• Other classes than distinguished class also get
  new code

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

49
Generalized Law of DemeterLaw 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.
  Dont talk to strangers.
• Motivation Control information overload. We can
  only keep a limited set of items in short-term
  memory of our minds.

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

51
Examples

• Unit function
• closely related
• functions of parameter types
• functions of return types of functions of any of
  the parameter types

52
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 Am()
• this.b.c.foo() this.p().q().bar()

53
Violations Dataflow Diagram
m
foo()
2c
1b
B
C
A
bar()
3p()
4q()
P
Q
54
Elimination of Violation
m
foo2
foo()
c
1b
B
C
A
2foo2()
4bar2()
bar2
bar()
3p()
q()
P
Q
55
Does AP help?
56
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.

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

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

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

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

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

62
What does AP save during evolution?
Written by user
Inspected by user, generated by compiler

• 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)).

63
Comparing AP versus OO during evolution effort
Written by user
Inspected by user, generated by compiler

• AP
• S1,TS ? S2
• Compatible(G2,S2)
• Errors(G2, Graph(TG(G1,S1)))
• Diff (TG(G1,S1), TG(G2,S2))

• OO
• 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
64
Comparing AP versus OO during evolution static
checking
Written by user
Inspected by user, generated by compiler

• AP
• S1,TS ? S2
• Compatible(G2,S2)
• Errors(G2, Graph(TG(G1,S1)))
• Diff (TG(G1,S1), TG(G2,S2))

• OO
• 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
65
Example
S1
A
C
S2
A
B
C
A
B
C
K
A
B
C
G1
G2
X
K
A
B
C
A
B
C
T(G2)
T(G1)
AP
OO
A
B
C
Errors
A
B
C
Errors
K
K
C
C
A
B
A
B
Diff
Diff
66
Example

• S1 from A to C
• G1A,BB,C
• T(G1)A B C
• Compatible yes
• Errors no B,C
• Diff B,CgtB,K. new K,C

• S2 from A via B to C
• G2A,BA,XB,KK,CX,C
• T(G2) A B K C
• Compatible yes
• Errors no B,C
• DiffB,CgtB,K. new K,C

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

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

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

70
Abusing AP

• Ignoring Errors() and Diff() output because the
  regenerated program compiles. Uncritical
  acceptance of the analogical transformation done
  by the AP compiler.

71
Doug

• APPC pattern
• Demeter/Java pattern
• AP library Mitch
• new nodes
• deleted nodes
• changed nodes
• Collaboration

72
Cd from Java

• Run-time constr. of cd from class files later
• not all classes loaded
• info. Not available due to package security

73
Key ideas

• Separate behavior from structure assign behavior
  to structure separately. Like methods and
  classes. Need to provide context.

74
Upstream Interface
Personality
Downstream Interface