1. Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Aspect-Oriented Software Development (AOSD)

2. Object Oriented Analysis and Design 2 Introduction  Evolution of Programming Languages  Assembly/Machine Languages  Formula Translation  Procedural Programming  Structured Programming  Functional Programming  Logic Programming  Programming with abstract data types  Evolution of Software Design  Monolithic ---> Modular

3. Object Oriented Analysis and Design 3 Design Principles  Modularity  Abstraction  Focus only on relevant properties  Decomposition  Divide software into separately named and addressable modules  Encapsulation  Group related things together.  Information Hiding  Hide implementation details from the outside  Separation of Concerns  Ensure that each module only deals with one concern  Low Coupling aim for low coupling among the modules  High Cohesion aim for high cohesion within one module

4. Object Oriented Analysis and Design 4 What is a Concern?  Are properties or areas of interest  Can be functional or nonfunctional (quality, systemic)  At different abstraction levels:  Problem domain concerns vs. solution domain concerns  Requirements vs. design  Design vs. implementation

5. Object Oriented Analysis and Design 5 Separation of Concerns  The ability to identify, encapsulate and manipulate concerns  A key principle of SW engineering  Concerns are primary criteria for decomposing SW

6. Object Oriented Analysis and Design 6 Separation of Concerns (Cont.) “clean” separation can help:  Reduce complexity, improve comprehensibility  Simplify evolution of SW  Local, easy changes  Smaller impact of change  Facilitate reuse  developers aren’t burdened by extraneous parts  Simplify component integration

7. Object Oriented Analysis and Design 7 Dijkstra: Separate Program in Layers...  E. W. Dijkstra (1968-2002):  ‘’...Correct arrangement of the structure of software systems before simple programming...‘’  Layered Structure  Programs are grouped into layers  Programs in one layer can only communicate with programs in adjoining layers  Conceptual integrity  Each layer has its own goal  With easier development and maintenance

8. Object Oriented Analysis and Design 8 Parnas - Design Principles for Decomposition  Information hiding modules (1972)  Identify design decisions that are likely to change  Isolate these in separate modules (separation of concerns)  Different design decisions might require different decompositions.  D. Parnas, "On the Criteria to Be Used in Decomposing Systems into Modules.“, Comm. ACM 15, 12 (December 1972), 1053-1058. 1972.

9. Object Oriented Analysis and Design 9 Separation of Concerns applied  Separate software development into phases each dealing with specific activities (e.g. requirements, analysis, design, implementation)  Separation of different artifacts: class, subsystems, attributes.  Separation of different design views (static, dynamic, implementation,...)  Separation of different roles ...

10. Object Oriented Analysis and Design 10 Benefits of Separation of Concerns  Supports high cohesion among components  Supports low coupling among components  Increases modularity

11. Object Oriented Analysis and Design 11 Advantages of Separation of Concerns  Understandability  Maintainability  Extensibility  Reusability  Adaptability  Separation of Concerns directly supports quality factors.  Lack of separation of concerns directly negatively impact quality factors.

12. Object Oriented Analysis and Design 12 Example - Figure Editor  A figure consists of several figure elements. A figure element is either a point or a line. Figures are drawn on Display. A point includes X and Y coordinates. A line is defined as two points.

13. Object Oriented Analysis and Design 13 Example - Figure Editor - Design Components are - Cohesive - Loosely Coupled - Have well-defined interfaces (abstraction, encapsulation) Nice Modular Design! Display Figure FigureElement * PointLine getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) 2

14. Object Oriented Analysis and Design 14 Display Figure FigureElement * PointLine getX() getY() getP1 setP1 DisplayTracking setX(int) setY(int) setP1(Point) setP2(Point) 2 Crosscutting Concern - Example Notify ScreenManager if a figure element moves

15. Object Oriented Analysis and Design 15 class Point { void setX(int x) { DisplayTracker.updatePoint(this); this.x = x; } class DisplayTracker { static void updatePoint(Point p) { this.display(p);.... } static void updateLine(Line l) { this.display(l);.... } Display Figure FigureElement * PointLine getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) 2 DisplayTracker class Line { void setP1(Point p1 { DisplayTracker.updateLine(this); this.p1 = p1; } Example: Display Tracking Crosscutting Concern

16. Object Oriented Analysis and Design 16 Example - Tracing - Design Display Figure FigureElement * PointLine getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) 2 Tracer traceEntry traceExit Tracing Trace the execution of all operations...

17. Object Oriented Analysis and Design 17 class Point { void setX(int x) { _x = x; } class Tracer { static void traceEntry(String str) { System.out.println(str); } static void traceExit(String str) { System.out.println(str); } } Display Figure FigureElement * PointLine getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) 2 Tracer Tracer.traceEntry(“Entry Point.set”); Tracer.traceExit(“Exit Point.set”); class Line { void setP1(Point p1 { _p1 = p1; } Tracer.traceEntry(“Entry Line.set”); Tracer.traceExit(“Exit Line.set”); Tangling Code Example - Tracing Scattered Concern

18. Object Oriented Analysis and Design 18 Crosscutting Concerns  Concerns that naturally tend to be scattered over multiple components  Which connot be localized into single units (components, objects, procedures, functions)...  If not appropriately coped with:  Scattered over multiple components  Tangled code per component

19. Object Oriented Analysis and Design 19 Crosscutting, Scattering and Tangling  Crosscutting  Concern that inherently relates to multiple components  Results in scattered concern and tangled code  Scattering  Single concern affects multiple modules  Tangling  Multiple concerns are interleaved in a single module

20. Object Oriented Analysis and Design 20 The Cost of Crosscutting Concerns  Reduced understandability  Redundant code in many places  Non-explicit structure  Decreased adaptability  Have to find all the code involved  Have to be sure to change it consistently  Have to be sure not to break it by accident  New concerns cannot be easily added  Decreased reusability  Component code is tangled with specific tangling code  Decreased maintainability  ‘Ripple effect’

21. Object Oriented Analysis and Design 21 Example of Crosscutting Concerns  Synchronization  Real-time constraints  Error-checking  Object interaction constraints  Memory management  Persistency  Security  Caching  Logging  Monitoring  Testing  Domain specific optimization ...

22. Object Oriented Analysis and Design 22 Many crosscutting concerns may appear in one system  Example: Distributed System Design  Component interaction  Synchronization  Remote invocation  Load balancing  Replication  Failure handling  Quality of service  Distributed transactions

23. Object Oriented Analysis and Design 23 What to Do...?

24. Object Oriented Analysis and Design 24 Historical Context  Crosscutting concerns are new type of concerns that have not been (appropriately) detected/handled before.  No explicit management until recently at programming level  No explicit consideration in design methods  No explicit consideration in process  No explicit consideration in case tools

25. Object Oriented Analysis and Design 25 Aspect-Oriented Software Development  Provides better separation of concerns by explicitly considering crosscutting concerns (as well)  Does this by providing explicit abstractions for representing crosscutting concerns, i.e. aspects  And composing these into programs, i.e. aspect weaving or aspect composing.  As such AOSD improves modularity  And supports quality factors such as  Maintainability  Adaptability  Reusability  Understandability ...

26. Object Oriented Analysis and Design 26 Impact of AOSD on Society...  MIT Technology Review lists AOP as one of the top 10 emerging technologies that will change the world  –(MIT Technology Review, January 2001)

27. Object Oriented Analysis and Design 27 Basic AOSD Technologies  Composition Filters (since 1991)  University of Twente, The Netherlands  AspectJ (since 1997)  XEROX PARC, US  DemeterJ/DJ (1993)  Northeastern University, US  Multi-dimensional separation of Concerns/HyperJ (1999)

28. Object Oriented Analysis and Design 28 OO languages MOP (1985) CLOS-MOP Crosscutting aspects (1996) AspectJ (1997) Scripts (Francez 81) Reflection (Smith 81) Sina interface predicates (1988) Composition Filters (1992) AI (semantic networks 79) Composition Filters with superimposition (2001) Law of Demeter (1988) Adaptive programming (1992) AspectJ (2000) http://trese.cs.utwente.nl History of AOP languages

29. Object Oriented Analysis and Design 29 AspectJ  A general purpose AO programming language  just as Java is a general-purpose OO language  unlike examples in ECOOP ’ 97 paper domain specific languages for each aspect  an integrated extension to Java  accepts all java programs as input  outputs.class files compatible with any JVM  integrated with tools

30. Object Oriented Analysis and Design 30 class Line { private Point _p1, _p2; Point getP1() { return _p1; } Point getP2() { return _p2; } void setP1(Point p1) { Tracer.traceEntry(“entry setP1”); _p1 = p1; Tracer.traceExit(“exit setP1”); } void setP2(Point p2) { Tracer.traceEntry(“entry setP2”); _p2 = p2; Tracer.traceExit(“exit setP2”); } class Point { private int _x = 0, _y = 0; int getX() { return _x; } int getY() { return _y; } void setX(int x) { Tracer.traceEntry(“entry setX”); _x = x; Tracer.traceExit(“exit setX”) } void setY(int y) { Tracer.traceEntry(“exit setY”); _y = y; Tracer.traceExit(“exit setY”); } Example – Without AOP Tangling Code Scattered Concern class Tracer { static void traceEntry(String str) { System.out.println(str); } static void traceExit(String str) { System.out.println(str); } }

31. Object Oriented Analysis and Design 31 class Line { private Point _p1, _p2; Point getP1() { return _p1; } Point getP2() { return _p2; } void setP1(Point p1) { _p1 = p1; } void setP2(Point p2) { _p2 = p2; } class Point { private int _x = 0, _y = 0; int getX() { return _x; } int getY() { return _y; } void setX(int x) { _x = x; } void setY(int y) { _y = y; } Example – With AOP aspect Tracing { pointcut traced(): call(* Line.* || call(* Point.*); before(): traced() { println(“Entering:” + thisjopinpoint); void println(String str) { } } Aspect is defined in a separate module Crosscutting is localized No scattering; No tangling Improved modularity

32. Object Oriented Analysis and Design 32 Aspect Language Elements  join point (JP) model  certain principled points in program execution such as method calls, field accesses, and object construction  means of identifying JPs  picking out join points of interest (predicate)  pointcuts: set of join points  means of specifying behavior at JPs  what happens  advice declarations

33. Object Oriented Analysis and Design 33 Modularizing Crosscutting  Joinpoints: any well-defined point of execution in a program such as method calls, field accesses, and object construction  Pointcut: predicate on joinpoints selecting a collection of joinpoints. Display Figure FigureElement * PointLine getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) 2 Tracer pointcut traced(): call(* Line.*) || call(* Point.*);

34. Object Oriented Analysis and Design 34 Joinpoints  method call join points  when a method is called  method reception join points  when an object receives a message  method execution join points  when the body of code for an actual method executes  field get joint point  when a field is accessed  field set joint point  when a field is set  exception handler execution join point  when an exception handler executes  object creation join point  when an instance of a class is created

35. Object Oriented Analysis and Design 35 Some primitive pointcuts  call(Signature)  picks out method or constructor call based on Signature  execution(Signature)  picks out a method or constructor execution join point based on Signature  get(Signature)  picks out a field get join point based on Signature  set(Signature)  picks out a field set join point based on Signature  handles(TypePattern)  picks out an exception handler of any of the Throwable types of TypePattern  instanceOf(ClassName)  picks out join points of currently executing objects of class ClassName  within(ClassName)  picks out join points that are in code contained in ClassName  withinCode(Signature)  picks out join points within the member defined by methor or constructor (Signature)  cflow(pointcut)  picks out all the join points in the control flow of the join points picked out by the pointcut

36. Object Oriented Analysis and Design 36 Advice  Piece of code that attaches to a pointcut and thus injects behavior at all joinpoints selected by that pointcut.  example: before (args): pointcut { Body } where before represents a before advice type (see next slide).  Can take parameters with pointcuts

37. Object Oriented Analysis and Design 37 Advice Types Advice code executes  before, code is injected before the joinpoint before (args): pointcut { Body }  after, code is injected after the joinpoint after (args): pointcut { Body }  around, code is injected around (in place of) code from joinpoint ReturnType around (args): pointcut { Body } JP Advice JP Advice JP

38. Object Oriented Analysis and Design 38 Aspect  A modular unit of cross-cutting behavior.  Like a class, can have methods, fields, initializers.  can be abstract, inherit from classes and abstract aspects and implement interfaces.  encapsulates pointcuts and advices  can introduce new methods / fields to a class AspectX AspectY classX AspectY AspectX classY x

39. Object Oriented Analysis and Design 39 class Line { private Point _p1, _p2; Point getP1() { return _p1; } Point getP2() { return _p2; } void setP1(Point p1) { _p1 = p1; } void setP2(Point p2) { _p2 = p2; } class Point { private int _x = 0, _y = 0; int getX() { return _x; } int getY() { return _y; } void setX(int x) { _x = x; } void setY(int y) { _y = y; } Example - AspectJ aspect Tracing { pointcut traced(): call(* Line.* || call(* Point.*); before(): traced() { println(“Entering:” + thisjopinpoint); after(): traced() { println(“Exit:” + thisjopinpoint); void println(String str) { } } pointcut advice aspect

40. Object Oriented Analysis and Design 40 Code Weaving  Before compile-time (pre-processor)  During compile-time  After compile-time  At load time  At run-time

41. Object Oriented Analysis and Design 41 Example - AspectJ aspect MoveTracking { private static boolean _flag = false; public static boolean testAndClear() { boolean result = _flag; _flag = false; return result; } pointcut moves(): receptions(void Line.setP1(Point)) || receptions(void Line.setP2(Point)); static after(): moves() { _flag = true; }

42. Object Oriented Analysis and Design 42 DemeterJ / DJ  Law Of Demeter  Each unit should only have limited knowledge about other units: only about units “closely” related to the current unit.  “Each unit should only talk to its friends.”  “Don’t talk to strangers.”  Goal: Reduce behavioral dependencies between classes.  Loose coupling

43. Object Oriented Analysis and Design 43 Applying LoD  A method must be able to traverse links to obtain its neighbors and must be able to call operations on them.  But it should not traverse a second link from the neighbor to a third class.  Methods should communicate only with preferred suppliers:  immediate parts on this  objects passed as arguments to method  objects which are directly created in method  objects in global variables  No other calls allowed  ---> Scattering

44. Object Oriented Analysis and Design 44 Solution is Adaptive Programming  Encapsulate operation into one place thereby avoiding scattering  Specify traversal over (graph) structure in a succinct way thereby reducing tangling.  Navigation strategy

45. Object Oriented Analysis and Design 45 Adaptive Programming: Demeter  Adaptive Programming: references to other objects are replaced by traversal strategies for the class graph  Methods become less brittle with regard to changes in the class structure

46. Object Oriented Analysis and Design 46 Adaptive Programming: Demeter (cont.)  Instance of AOP [Lieberherr92]  Aspects are traversal strategies  Separate the program text and the class structure  Program is independent of class graph  Accomplish tasks by traversals  Specification for what parts of received object should be traversed  Code fragments for what to execute when specific object types are encountered

47. Object Oriented Analysis and Design 47 Object Traversals  The heart of Adaptive Programming is object traversals  Traversal code is tedious to write  Traversal code should not obstruct the view of the “ real ” program logic

48. Object Oriented Analysis and Design 48 Use of Visitors import edu.neu.ccs.demeter.dj.*; // define strategy String strategy= “ from BusRoute through BusStop to Person ” class BusRoute { // define class graph static Classgraph cg = new ClassGraph(); int printCountWaitingPersons(){ // traversal/visitor weaving //define visitor Visitor v = new Visitor() public void before(Person host){ r++; … } public void start() { r = 0;} … } cg.traverse(this, strategy, v);...}

49. Object Oriented Analysis and Design 49 Advantages of DJ  Use of reflection  No need for source code (no code weaving)  Can work on class files  Purely Java (no new structure)

50. Object Oriented Analysis and Design 50 Conclusion  Crosscutting concerns are typically scattered over several modules and result in tangled code.  This reduces the modularity and as such the quality of the software system.  AOSD provides explicit abstractions mechanisms to represent these so-called aspects and compose these into programs  This increases the modularity of systems.