1. An Empirical Study of the Demeter System
Pengcheng Wu and Mitchell Wand
Northeastern University
2018/11/29
PhD seminar

2. Motivation
Collect evidence to support the claim: Demeter system improves the –ilities of software systems.
In this talk, we focus on a specific –ility: Comprehensibility.
2018/11/29
PhD seminar

3. System overview
Problem addressed: manual implementation of a traversal on a complex object structure is tedious and error-prone. E.g., AST traversal.
Solution: have a high-level description of traversals, then generate the code!
2018/11/29
PhD seminar

4. System overview (cont.)
Demeter’s high-level traversal language: strategy
Subgraph of transitive closure of class graph
Graph language: may be cyclic
E.g., from class A via class B to class E
A bunch of traversal generating algorithms.
E.g., FIRST algorithm [Lieberherr and Wand 2002]
2018/11/29
PhD seminar

5. from A via B to E FIRST Algorithm class A { void t1() { if(b!=null)}
void t1prime() {
access(e);
class B {
void t1() {
d.t1(); }
class D {
a.t1prime();
FIRST
Algorithm
2018/11/29
PhD seminar

6. High-level description is much easier to understand! from A via B to E
class A {
void t1() {
if(b!=null)
b.t1(); }
void t1prime() {
access(e);
class B {
void t1() {
d.t1(); }
class D {
a.t1prime();
2018/11/29
PhD seminar

7. Q: Do you have any more convincing statistics?
A: YES! The largest software system using Demeter’s traversal strategies: the DemeterJ Compiler. It has 413 classes, 80 traversals on ASTs
2018/11/29
PhD seminar

8. How complex are those traversals?
2018/11/29
PhD seminar

9. How complex are those traversals? (cont.)
2018/11/29
PhD seminar

10. Traversal strategies improve comprehensibility
How to measure the improvement?
Abstractness of a traversal strategy
= Length(MethodCallPaths)/Length(Strategy)
The larger the ratio is, the more abstract the strategy is, then the more details are left out and the better comprehensibility we achieve.
2018/11/29
PhD seminar

11. The abstractness metric
2018/11/29
PhD seminar

12. Conclusion
Traversals on complex object structures tend to be complex too.
High level description of traversals helps improve the comprehensibility of the traversal concerns in software system.
The improvements are nontrivial.
2018/11/29
PhD seminar

13. Tradeoff in AOP Specific, explicit, closed
Controls spuriousness
Leads to
Brittleness
Predictability
Rigidity
Generic, implicit, open-ended
Controls brittleness
Leads to
Spuriousness
comprehensability
Evolvability
2018/11/29
PhD seminar

14. Tradeoff in AOP Specific, explicit, closed
Controls spuriousness
Leads to
Brittleness
Predictability
Rigidity
Complex request to base
Hospital, go left,right,up
Base can refuse
Generic, implicit, open-ended
Controls brittleness
Leads to
Spuriousness
comprehensability
Evolvability
Complex request to base
Place where they heal people
2018/11/29
PhD seminar

15. Questions and Discussions ...
2018/11/29
PhD seminar

16. Edinburgh, Scottish symbols Mik:
Effects of control flow advice
Query languages
3 layer structure, editing at second layer
2018/11/29
PhD seminar

17. NSF design proposal CME and Demeter
Use selector language to define editing
Selector language needs unification, pattern matching
Enhancement: SelectorExpression(p1, … ) {body}
2018/11/29
PhD seminar

18. Mario Visitor makes assumptions on class graph
Analyze traversal graph: another graph intersection
2018/11/29
PhD seminar

19. Pengcheng Traversal graph: pcd and call graph
call f()) from main() to call f()
cflow(call f()) = from main() via call f() to *
Cflow(p) = from main() via pathset to *
Pathset starts at Main
Join(Pathset(p), target(…) to *
2018/11/29
PhD seminar

20. !call f() = !pathset(from main to f())
Same source, same target: all other paths
!(from A to B) : from A to !B: forward from A, backward from all other nodes
!(from A via B to C) = from A via !B to C or from A via B to !C or from A via !B to !C
!([A,B].[B,C]) =[A,!B].[!B,C] or [A,B][B,!C]
!(D1.D2) =!D1.D2’ || D1.!D2
2018/11/29
PhD seminar

21. Thoughts on highlighting
Cdn (cd normalized)
Cdh (cd highlighted)
First find an Eclipse independent solution, then specialize for Eclipse.
Cleaner thinking
More reusable
2018/11/29
PhD seminar

22. Turn the two cds into one new cd: integrated cd
*h* A = <b> B *h* <c> C <d> D *h* <e> E.
*h* C : G | *h* H | *h* I | J.
*h* E ~ { *h* S }.
A = <b> B <c> C <d> D <e> E.
C : G | H | I | J.
E ~ { S }.
2018/11/29
PhD seminar

23. Four questions to second cd
A ?
->A,b,* ?
=>A,B
~>R,S
2018/11/29
PhD seminar

24. Three questions to second cd
A ?
aplib.cd.ClassGraph.definesClass
->A,b,* ?
aplib.cd.ClassGraph.getOutgoingEdges(v)
aplib.EdgeI.getSource()
aplib.EdgeI.isConstructionEdge()
=>A,B
aplib.EdgeI.isAlternationEdge()
2018/11/29
PhD seminar

25. Can we avoid constructing integrated cd explicitly? YES.
Traverse cdn and ask questions about cdh.
Need to do the work of the Printvisitor but in two colors.
Use e.g. aplib.cd.ClassDef.
isAlternationClass()
isConstructionClass()
isRepetitionClass()
2018/11/29
PhD seminar

26. Now become Eclipse specific
Use StyledText
Need to create pair coordinates to do the highlighting
2018/11/29
PhD seminar

27. Aspects of Security
Karl Lieberherr
2018/11/29
PhD seminar

28. The bottleneck
"The kernel of the problem is that the existing description mechanisms - programming languages - are inadequate when it comes to conveying relevant information to people about the software systems. The established programming paradigms fail in providing appropriate support for non-hierarchical concerns, additional or custom-made behavior, and non-trivial domain specific structures and processes."
2018/11/29
PhD seminar

29. Credits
The following viewgraphs about security are from Bart De Win’s PhD thesis in Belgium.
Engineering Application-level Security through Aspect-Oriented Software Development
Catholic University of Leuven, March 2004
2018/11/29
PhD seminar

30. Secure Software Insecurity is a fact in today's IT systems
Many attacks are possible because of security vulnerabilities in the software
Doubles every year
The SANS Top 20 Internet Security Vulnerabilities
The vast majority of worms and other successful cyber attacks are made possible by vulnerabilities in a small number of common operating system services.
SANS = SysAdmin, Audit, Network, Security
2018/11/29
PhD seminar

31. Where can vulnerabilities be introduced?
Architectural design
Software development
System integration
System configuration
Software maintenance
2018/11/29
PhD seminar

32. Why is it hard Pervasiveness of security
Secure coding for all: implementing application functionality (at first sight not security related) can introduce severe security problems. PL can help. How to make sure that code cannot be abused to achieve undesirable results.
Security related, crosscutting concerns: security cuts across many classes
2018/11/29
PhD seminar

33. Security crosscuts
Java SecurityManager: needs to be called at right places: in Java JDK places (invoking check methods) in 869 classes.
Security information may not be localized
communication encryption: key selection, connection information, security state, actual data to protect.
2018/11/29
PhD seminar

34. Unanticipated risks
Unanticipated threats always show up during the lifetime of a system
Threat analysis was incomplete
Environment changes
Business functionality changes
Building very secure system is expensive
2018/11/29
PhD seminar

35. Recent Trends Disappearing security perimeter. Increasing complexity.
Share business processes B2B, B2C
Security requirements that were formerly enforced at the security perimeter must be more and more migrated into the internals (i.e. closer to the business logic)
Increasing complexity.
More functionality, more security
Security requirements get more complex, evolving security models
2018/11/29
PhD seminar

36. Separation of concerns for security
Established modularization techniques such as functional decomposition and object-orientation do not adequately support separation of security.
They are capable of encapsulating security logic, but the relation between security and business functionality is necessarily an intrinsic part of the business logic.
2018/11/29
PhD seminar

37. Introduction to security
Security regards the protection of valuable information against different kinds of threats, such as stealing, modifying, destroying etc.
The value of information is always (directly or indirectly) related to its economic or political value, which may change over time. Hence, security involves a continuous trade-off between cost and security strength, based on the use of risk analysis techniques and dictated by a security policy.
2018/11/29
PhD seminar

38. Security Requirements
There is no standard list but ISO :
authentication: corroboration of the identity of an entity (or the source of information);
access control: restricting access to resources to privileged entities;
data confidentiality: keeping information secret from all but those who are authorized to see it;
data integrity: ensuring information has not been altered by unauthorized or unknown means;
non-repudiation: preventing the denial of previous commitments or actions.
2018/11/29
PhD seminar

39. Security Primitives
The enforcement of these security requirements is based on several security primitives such as
encryption (symmetric key or public key)
hash-functions and
MAC (Message Authentication Code)
digital signatures and so forth.
In addition need: secure programming
2018/11/29
PhD seminar

40. Structure of application
Business logic
Application server
Language run-time
Middleware
Operating system
Network
Physical level
2018/11/29
PhD seminar

41. Level of enforcement
Enforcement of a security requirement can be achieved on different levels (and in different forms). For instance, confidentiality for distributed information exchange could be implemented using
IPSEC [65] on the network layer or
secure connections on the middleware layer or
encryption mechanism in the business layer.
In general, the rule is that the lower the mechanism is implemented, the faster it can be executed, but the less fine-grained and flexible it can be used.
2018/11/29
PhD seminar

42. Application layer Interesting for deployment of security mechanisms
can target very fine-grained parts of the application; more flexible security policies
the implementation of custom security mechanisms at lower levels is hard
advanced security policies necessitate mechanisms that rely on information that is available (or even only known) at the application level.
2018/11/29
PhD seminar

43. Focus on enforcing security at application level
Writing aspects like …
2018/11/29
PhD seminar

44. aspect Identification perthis(this ( Client ) ) {
public Subject subject = null ;}
aspect Authentication percflow(serviceRequest ( ) ) {
private Subject subject ;
pointcut serviceRequest ( ) : call( ServerInterface . service ( . . ) ) ;
pointcut authenticationCall ( Object caller ) :
this ( caller )
&& serviceRequest ( )
&& if ( Identifification . hasAspect ( caller ) ) ;
2018/11/29
PhD seminar

45. before ( Object caller ) : authenticationCall ( caller ) {
Identification id = Identification . aspectOf ( caller ) ;
if ( id . subject == null ) { <login>};
subject = id . subject ; }
public Subject getSubject ( ) {
return subject ; } }
2018/11/29
PhD seminar

46. The LoDC: The Law of Demeter for Concerns
Talk only to your friends that contribute to your current concerns (or that share your current concerns).
Standard interpretation:
you: a method
friends: preferred supplier objects
Talk: send message
2018/11/29
PhD seminar

47. Violating the Law of Demeter
class PaperBoy
customer.wallet.money;
customer.apartment.kitchen.
kitchenCabinet.money;
customer.apartment.bedroom.
mattress.money;
widen the interface of the Customer class:
int customer.getPayment(..)
2018/11/29
PhD seminar

48. LoDC restricts LoD
There may be multiple concerns (e.g. non-security concerns) in play and each communication should be restricted to those preferred supplier objects that contribute to the current concerns.
2018/11/29
PhD seminar

49. How to deal with new concerns
We cannot avoid talking to friends that don't contribute to our current concerns but we want to impose this communication using a separate module.
This imposition has the advantage that the code for the current concerns stays unpolluted and does not get cluttered with calls related to foreign concerns.
2018/11/29
PhD seminar

50. LoD and Contracting
like contracting with a crosscutting interaction pattern
delegate the security concern to a contracting provider called S.
2018/11/29
PhD seminar

51. Contracting analogy continued
define a well-defined interface to S consisting of a set of extension points giving selected information and property access.
Reorganize?
2018/11/29
PhD seminar

52. Benefits of contracting (similar to LoDC)
More agile; switch?
Amortize over several clients
Better service
2018/11/29
PhD seminar

53. Logging example base application
implements a set of current concerns and
now we want to log some of the method calls in the base application.
2018/11/29
PhD seminar

54. Logging continued
The logging concern is distinct from the application's concerns; indeed it is an intrusive concern that wants to watch what the base application does. The logging concern wants to send messages to a logfile with information from the base application.
2018/11/29
PhD seminar

55. Logging continued
Instead of adding the logging calls in the base application code, violating the LoDC (the “that contribute to your current concerns” part), we need to enhance the base application from the “outside”.
2018/11/29
PhD seminar

56. Logging continued
We need to find a convenient way to specify the places in the program execution where those additional calls to the logfile object should happen.
The logging concern is an example of a concern that cuts across the base program.
2018/11/29
PhD seminar

57. Logging continued
By following the LoDC, we build an interesting abstraction in the spirit of the guideline on creating abstractions:
Form an abstraction instead of copying and modifying a piece of a program.
2018/11/29
PhD seminar

58. Logging continued Here we don't want to duplicate the log calls.
What is interesting is that the aspectual abstraction cuts across several methods and classes.
2018/11/29
PhD seminar

59. Logging Example abstract public aspect RemoteExceptionLogging {
abstract pointcut logPoint();
after() throwing (RemoteException e): logPoint() {
log.println(“Remote call failed in: ” thisJoinPoint.toString() “(” + e + “).”); }
public aspect MyRMILogging extends RemoteExceptionLogging {
pointcut logPoint():
call(* RegistryServer.*.*(..)) ||
call(private * RMIMessageBrokerImpl.*.*(..));
2018/11/29
PhD seminar

60. Replace argument trickle by wormhole
Often, there is a need to pass a part of the current
context to invoked methods, which in turn pass it along,
so that a called method down the call chain eventually
may use the context to perform its task. The result is
API pollution due to a crosscutting concern and
increased cognitive burden for the developer of the
classes in the middle of the chain. This also causes
significant problems for reusing components. With AO
refactoring, you can avoid passing the parameters to
methods in the call chain.
2018/11/29
PhD seminar

61. Aspects may be structure-shy
aspect CapabilityChecking {
pointcut invocations(Caller c):
this(c) && call(void Service.doService(String));
pointcut workPoints(Worker w):
target(w) && call(void Worker.doTask(Task));
pointcut perCallerWork(Caller c, Worker w):
cflow(invocations(c)) && workPoints(w);
before (Caller c, Worker w): perCallerWork(c, w) {
w.checkCapabilities(c); }
2018/11/29
PhD seminar

62. LoDC The LoDC has a subtle influence on how we structure our software.
If a new concern has to be added from the outside through a set of extension points, we will be careful to make it easy to express the coordinates of the extension points.
Similar to a contracting buyer
2018/11/29
PhD seminar

63. Partition based on concerns
In many situations we might be able to
partition the objects based on concerns.
In that case, the LoDC disallows calling
methods of objects that
are not friends and that
don't contribute to the current concerns.
2018/11/29
PhD seminar

64. Extension languages
What do we gain from factoring out the logging calls? We gain the advantage that we can easily plug-in and plug-out the logging aspect.
But we don't gain much, if we have to enumerate one by one the places where the calls should happen.
It could be that writing down the “coordinates” of the calls is more cumbersome than writing the calls themselves. -> pattern
2018/11/29
PhD seminar

65. Pattern
For example, we might want to log all method calls of the form C.withdraw(..)}. (.. means any number of arguments.)
In this case, factoring out the logging concern is a big win. We are guaranteed to capture all those method calls while the manual solution might miss some.
2018/11/29
PhD seminar

66. Following LoD and LoDC
The LoD is about organizing software within a set of concerns and the LoDC promotes the separation of a new concern if it is considered to be separable.
2018/11/29
PhD seminar

67. Adaptation Dilemma We continue with the logging example.
The specification: find_Cwithdraw = “find all calls of the form C.withdraw(..)” is adaptive in that it can be used with many different base programs. But adaptation has its price: when the base program changes, we need to retest the specification to prove that the right elements are still being selected.
2018/11/29
PhD seminar

68. Adaptation Dilemma
When a parameterized program abstraction P(Q)is given with a broad definition of the domain of the allowed actual parameters, we need to retest and possibly change the abstraction P when we modify the actual parameter, i.e., we move from P(Q1) to P(Q2).
2018/11/29
PhD seminar

69. Live with some uncertainty
In the context of the adaptation dilemma, the abstraction P will change its meaning based on the actual parameter.
2018/11/29
PhD seminar

70. Embraced by practitioners
The high-level program abstractions used in AOP (called AOP abstractions) are different than “traditional” abstractions because of the analogous adaptation they cause. AOP practitioners using tools such as AspectJ, AspectWerkz, JBoss-AOP, JAC, DemeterJ etc. are happy to work with AOP abstractions by using good tool support.
2018/11/29
PhD seminar

71. Why do practitioners like those abstractions?
The AOP abstractions produce a lot of code that would be
tedious and error-prone to write by hand and
the code would be scattered over many methods and not pluggable.
Instead of labeling AOP abstractions as wrong or breaking modularity, it is much better to find good ways of working with them.
2018/11/29
PhD seminar

72. Conclusions Security becomes more and more important
Disappearing security perimeter: B2B etc.
Secure coding for all
Implementing numerous security concerns
AOSD techniques provide useful ideas to better deal with security (and other concerns)
2018/11/29
PhD seminar