1 / 72

An Empirical Study of the Demeter System

An Empirical Study of the Demeter System. Pengcheng Wu and Mitchell Wand Northeastern University. 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.

capril
Download Presentation

An Empirical Study of the Demeter System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Empirical Study of the Demeter System Pengcheng Wu and Mitchell Wand Northeastern University 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. PhD seminar

  3. 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! System overview PhD seminar

  4. 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] System overview (cont.) PhD seminar

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

  6. from A via B to E High-level description is much easier to understand! class A { void t1() { if(b!=null) b.t1(); } void t1prime() { access(e); if(b!=null) b.t1(); } } class B { void t1() { d.t1(); } } class D { void t1() { a.t1prime(); } } 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 PhD seminar

  8. How complex are those traversals? PhD seminar

  9. How complex are those traversals? (cont.) 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. PhD seminar

  11. The abstractness metric 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. PhD seminar

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

  14. 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 Tradeoff in AOP PhD seminar

  15. Questions and Discussions ... PhD seminar

  16. Edinburgh, Scottish symbols • Mik: • Effects of control flow advice • Query languages • 3 layer structure, editing at second layer 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} PhD seminar

  18. Mario • Visitor makes assumptions on class graph • Analyze traversal graph: another graph intersection 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 * 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 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 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 }. PhD seminar

  23. Four questions to second cd • A ? • ->A,b,* ? • =>A,B • ~>R,S 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() 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() PhD seminar

  26. Now become Eclipse specific • Use StyledText • Need to create pair coordinates to do the highlighting PhD seminar

  27. Aspects of Security Karl Lieberherr 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." 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 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 PhD seminar

  31. Where can vulnerabilities be introduced? • Architectural design • Software development • System integration • System configuration • Software maintenance 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 PhD seminar

  33. Security crosscuts • Java SecurityManager: needs to be called at right places: in Java JDK 1.3 170 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. 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 PhD seminar

  35. Recent Trends • Disappearing security perimeter. • 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 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. 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. PhD seminar

  38. Security Requirements • There is no standard list but ISO 7498-2: • 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. 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 PhD seminar

  40. Structure of application • Business logic • Application server • Language run-time • Middleware • Operating system • Network • Physical level 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. 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. PhD seminar

  43. Focus on enforcing security at application level • Writing aspects like … PhD seminar

  44. aspectIdentification perthis(this( Client ) ) { publicSubject subject = null ;} aspectAuthentication percflow(serviceRequest ( ) ) { privateSubject subject ; pointcutserviceRequest ( ) : call( ServerInterface . service ( . . ) ) ; pointcutauthenticationCall ( Object caller ) : this( caller ) && serviceRequest ( ) && if ( Identifification . hasAspect ( caller ) ) ; PhD seminar

  45. before( Object caller ) : authenticationCall ( caller ) { Identification id = Identification . aspectOf ( caller ) ; if ( id . subject == null ) { <login>}; subject = id . subject ; } publicSubject getSubject ( ) { return subject ; } } 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 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(..) 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. 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. PhD seminar

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

More Related