Controlling the Complexity of Software Designs

1. Karl Lieberherr College of Computer and Information Science Northeastern University DEMETER DHMHTRA Controlling the Complexity of Software Designs

2. For your personal life: Always talk to strangers. But in your software: Talk only to your friends who contribute to your concerns.

3. Thesis • The Law of Demeter for Concerns (LoDC) helps you to better apply, explain and understand Aspect-Oriented Software Development (AOSD): • LoDC: Talk only to your friends who contribute to your concerns. • AOSD: Modularizing crosscutting concerns. • Concern: Any issue the developer needs to deal with: a use case, a caching policy, …

4. Benefits of LoDC, if followed properly • Helping designers/programmers with improvements to two key properties of software • More information hiding (LoD) • Not only: Separation of clients from implementation changes • But also: Separation of clients from many interface changes • Less information overload (AOSD, LoDC) • “Talk only to your friends” is strengthened to a more restricted set of friends. • You prepare yourself to talk to others by offering them a complex request interface. You permit intrusive behavior to some complex requests. Health care providers.

5. Supporting Claims • Current AOSD tools (AspectJ, Demeter, etc.) provide support for following the LoDC. • The LoDC leads to structure-shyness and concern-shyness which leads to better AOSD.

6. Outline • AOSD • The LoD and LoDC • AOSD Tools support LoDC • LoDC leads to better AOSD • Conclusions

7. Outline as a picture Structure-shyness, more hiding leads to improves LoD AOSD, less overload implies support LoDC AOSD Tools leads to

8. Meta thesis • The LoDC is a simple tool to explain something new and unfamiliar (AOSD) that is important to you.

9. What is AOSD? • Modularize concerns whose ad hoc implementation would be scattered across many classes or methods. • Slogan: Modularize Crosscutting Concerns.

10. AOSD and LoDC as Software Development Approaches • AOSD is an approach to software development that supports modularizing concern implementations that cut across other concern implementations. • LoDC is an approach to software development that supports incremental development, concern by concern.

11. interface ShapeI extends Remote{ double get_x() throws RemoteException; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; } publicclass Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException{ returnloc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { returnloc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException{ returndim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException{ returndim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); } } publicclass Shape { protecteddouble x_= 0.0, y_= 0.0; protecteddouble width_=0.0, height_=0.0; double get_x() { return x_(); } void set_x(int x) { x_ = x; } double get_y() { return y_(); } void set_y(int y) { y_ = y; } double get_width(){ return width_(); } void set_width(int w) { width_ = w; } double get_height(){ return height_(); } void set_height(int h) { height_ = h; } void adjustLocation() { x_ = longCalculation1(); y_ = longCalculation2(); } void adjustDimensions() { width_ = longCalculation3(); height_ = longCalculation4(); } } Write this coordinator Shape { selfex adjustLocation, adjustDimensions; mutex {adjustLocation, get_x, set_x, get_y, set_y}; mutex {adjustDimensions, get_width, get_height, set_width, set_height}; } Instead of writing this class AdjustableLocation { protecteddouble x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronizeddouble get_x() { return x_; } synchronizedvoid set_x(int x) {x_ = x;} synchronizeddouble get_y() { return y_; } synchronizedvoid set_y(int y) {y_ = y;} synchronizedvoid adjust() { x_ = longCalculation1(); y_ = longCalculation2(); } } class AdjustableDimension { protecteddouble width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronizeddouble get_width() { return width_; } synchronizedvoid set_w(int w) {width_ = w;} synchronizeddouble get_height() { return height_; } synchronizedvoid set_h(int h) {height_ = h;} synchronizedvoid adjust() { width_ = longCalculation3(); height_ = longCalculation4(); } } portal Shape { double get_x() {} ; void set_x(int x) {}; double get_y() {}; void set_y(int y) {}; double get_width() {}; void set_width(int w) {}; double get_height() {}; void set_height(int h) {}; void adjustLocation() {}; void adjustDimensions() {}; } Modularization of crosscutting concerns Crista Lopes 1995 COOL, RIDL

12. Outline • AOSD • What is AOSD? • AOSD as an emerging technology • The LoD and LoDC • AOSD Tools support LoDC • AspectJ supports LoDC • Demeter supports LoDC • LoDC leads to better AOSD • From LoD to structure-shyness and better AOSD • Information hiding and LoDC • Conclusions

13. AOSD as an Emerging Technology • First I want to position AOSD as an important emerging technology. • Statement from IBM at AOSD 2004. • A case study of AspectJ usage from a paper by Colyer and Clement at AOSD 2004. Also used by LoDC explanation. • More on AspectJ successes.

14. Daniel Sabbah (IBM VP for Software): Quotes from Conclusions at AOSD 2004 • AOSD’s time has come. • The Software Industry needs it, and IBM is using it now. • IBM is taking AOSD very seriously. • From a technical and business perspective • AOSD has development impact today across all major IBM brands – • Tivoli, WebSphere, DB2, Lotus, Rational

15. How is AOSD technology currently used? Large-scale AOSD for Middleware Adrian Colyer and Andrew Clement IBM UK, in Proceedings AOSD 2004. From the Abstract: “We also wanted to know whether aspect-oriented techniques could scale to commercial project sizes with tens of thousands of classes, many millions of lines of code, hundreds of developers, and sophisticated build systems.”

16. From: Large Scale AOSD for Middleware They were able to capture the extensive logging policy in an aspect that defined both when and how logging was to be performed. Note: They applied AOSD to many other concerns!

17. When WhatToDo Logging in AspectJ May affect Hundreds of Places 8000 places (IBM report) aspect Logging{ LogFile l; pointcut traced(): call(void *.update()) || call(void *.repaint()); before():traced(){ l.log(“Entering:”+ thisJoinPoint);} }

18. Manual alternative • Mistakes that happened: • Some extra methods may be logged. • Some methods are forgotten to be logged. • Some logging methods may not be properly guarded. • From Colyer/Clement: “The aspect-based solution gave a more accurate and more complete implementation of the tracing policy… All of these mistakes are the natural consequence of asking humans to perform mundane and repetitive work.”

19. More AspectJ Successes • 4 published trade press books with more coming. • Hand-coded alternatives accuracy 70%-80%. • Used in production applications around the world. • Popular in J2EE community. • IBM will soon ship AspectJ code in Websphere.

20. Other Examples of Commercially Used AOP Tools • AspectWerkz • Supported by BEA • Spring AOP framework • JBoss AOP • CME (Concern Manipulation Environment) • Supported by IBM

21. Outline • AOSD • The LoD and LoDC • AOSD supports LoDC • LoDC leads to better AOSD • Conclusions

22. Booch about the Law of Demeter (LoD) Quote: • “The basic effect of applying this Law is the creation of loosely coupledclasses, whose implementation secrets are encapsulated.” • “Such classes are fairly unencumbered, meaning that to understand the meaning of one class, you need not understand the details of many other classes.”

23. Rumbaugh about the Law of Demeter (LoD) Quote: • “Avoid traversing multiple links or methods. A method should have limited knowledge of an object model.”

24. The LoD and LoDC • LoD: Talk only to your friends. • Control information overload • How to organize inside a set of concern implementations. • LoDC: Talk only to your friends who contribute to your concerns. • Better control of information overload and control of scattering. • Separate outside concerns. • LoDC implies LoD.

25. FRIENDS Talk only to your friends Law of Demeter (LoD) you

26. OO interpretation of LoD • Talk only to your friends • Class form: you = method of class, talk = use, friends = preferred supplier classes • Object form: you = method of object, talk = send message, friends = preferred supplier objects

27. Preferred supplier objects of a method • the immediate parts of this(computed or stored) • the method’s argument objects (which includes this) • the objects that are created directly in the method A job interview question

28. Violating the LoD (example by David Bock) • In class PaperBoy: • customer.wallet.money; • customer.apartment.kitchen. kitchenCabinet.money; • customer.apartment.bedroom.mattress.money;

29. Explaining LoDC • Base application deals with set of concerns Cs. • A new concern D needs to be dealt with that requires additional method and/or method calls. • Those methods or method calls do not contribute to Cs. • Therefore, the methods and/or calls required by D need to be factored out into a modular unit called a complex request. LoDC = Talk only to your friends who contribute to your concerns

30. LoDC: Talk only to your friends who contribute to your concerns. • When your concerns change the set of contributing friends changes. • You talk to friends that don’t contribute to your concerns through a complex request. • Such a complex request (e.g., Logging) may modularize many communications that would otherwise be scattered across many classes and methods.

31. contributing friends FRIENDS Law of Demeterfor Concerns (LoDC) you

32. contributing friends Law of Demeterfor Concerns (LoDC) FRIENDS l:LogFile you coordinates Complex request

33. Missing: Subject-Oriented Prog. Hyper/J Composition Filters etc. Outline • AOSD • The LoD and LoDC • AOSD supports LoDC • AspectJ supports LoDC • Demeter supports LoDC • LoDC leads to better AOSD • Conclusions

34. Use Logging example to explain LoDC • Base application deals with a set of concerns Cs different from Logging. • The logging object, although it may be a friend, does not contribute to Cs. • Therefore, the calls to the logging object need to be factored out. LoDC = Talk only to your friends who contribute to your concerns

35. aspect Logging{ LogFile l; pointcut traced(): call(void *.update()} || call(void *.repaint(); before():traced(){ l.log(“Entering:”+ thisJoinPoint);} } // follows LoDC How does AspectJ support the LoDC? Inserting calls l.log() manually would violate LoDC because logging is an intrusive new concern that is not part of the current concerns. When WhatToDo AspectJ

36. Outline • AOSD • The LoD and LoDC • AOSD supports LoDC • AspectJ supports LoDC • Demeter supports LoDC • LoDC leads to better AOSD • Conclusions

37. Demeter Motivation • Coupling between classes is bad! • Demeter reduces the coupling in two stages: • Following the Law of Demeter using standard object-oriented techniques eliminates the obviously bad coupling. • Traversal strategies reduce the coupling further by coupling only with (distant) stable friends.

38. Stable Friends Redefine! Talk only to your stable friends who contribute to your concerns. • A friend is stable if its definition is unlikely to change if the functional requirements don’t change. • A stable friend may not be an ordinary preferred supplier. It may be a distant stable friend.

39. Preferred supplier objects of a method: redefined • the stable parts of this(computed or stored) • Parts reachable by a “short” traversal specification derived from the requirements • the method’s argument objects (which includes this) • the objects that are created directly in the method

40. Requirement: count all persons waiting at any bus stop on a bus route Stable Friends strategy: from BusRoute via BusStop via {-> *,waiting,*} to Person BusRoute BusStopList villages buses VillageList busStops 0..* 0..* BusStop BusList Village waiting 0..* passengers Bus PersonList Person 0..*

41. Requirement: count all persons waiting at any bus stop on a bus route Stable Friends strategy: from BusRoute via BusStop via {-> *,waiting,*} to Person busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..*

42. Requirement: count all persons waiting at any bus stop on a bus route Stable Friends strategy: from BusRoute via BusStop via {-> *,waiting,*} to Person busStops BusRoute BusStopList buses 0..* BusStop BusList waiting drinkingCoffee 0..* passengers Bus PersonList Person 0..*

43. Requirements and Stability of Strategies • Strategies should only refer to the high-level terms in the requirements, without referring to accidental details of the current class graph. • Point – Line duality: A functional requirement works with many class graphs (and a class graph may be used to implement many functional requirements). • Unless requirements change, strategy will be stable with respect to many changes in class graph.

44. Three kinds of requirement changes • Changes to class graph and functional requirements • Changes to class graph only (villages) • Changes to functional requirements only (count people in buses)

45. Requirement: count all passengers riding in some bus on a bus route Stable Friends strategy: from BusRoute via Bus via {-> *,passengers,*} to Person BusRoute BusStopList busStops buses 0..* 0..1 BusStop BusList waiting approaching 0..* Bus PersonList passengers Person 0..*

46. Requirement: count all bus stops where some bus is approaching on a bus route strategy: from BusRoute via Bus via {-> *,approaching,*} to BusStop BusRoute BusStopList busStops buses 0..* 0..1 BusStop BusList waiting approaching 0..* Bus PersonList passengers Person 0..*

47. Following the LoD • Instead of using (in class PaperBoy) • customer.wallet.money; • customer.apartment.kitchen. kitchenCabinet.money; • customer.apartment.bedroom.mattress.money; • Widen the interface of Customer but decrease coupling: int Customer.getPayment(..) using stable friend Money in: from Customer to Money.

48. When (pointcut) set of execution points of any method, … rich set of primitive pointcuts: this, target, call, execution … when to enhance WhatToDo (advice) how to enhance When (visitor signature) set of execution points oftraversal methods specialized set of pointcuts for traversal methods (node, edge) when to enhance WhatToDo (visitor body) how to enhance From AspectJ (1997) back to Demeter (1992) Demeter (e.g., DJ) AspectJ DAJ = Efficient version of DJ as AspectJ extension

49. aspect Logging{ LogFile l; pointcut traced(): call(void *.update()) || call(void *.repaint()); before():traced(){ l.log(“Entering:”+ thisJoinPoint);} } class Source{ HashSet collect(ClassGraph cg) {return (HashSet) cg.traverse(this, “from Source to Target”, new Visitor(){ … ; public void before (Targeth) { … } public voidstart(){…}}); } } When WhatToDo AspectJ Java+DJ

50. How DJ works • Make concepts of Demeter available as Java classes: • ClassGraph (Object structure): method traverse(Object, WhereToGo, WhenAndWhatToDo) • Strategy = String (WhereToGo) • Visitor (WhenAndWhatToDo)