1 / 50

Object Oriented Analysis and Design

Object Oriented Analysis and Design. Aspect-Oriented Software Developmen t (AOSD). Introduction. Evolution of Programming Languages Assembly/Machine Languages Formula Translation Procedural Programming Structured Programming Functional Programming Logic Programming

sal
Download Presentation

Object Oriented Analysis and Design

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. Object Oriented Analysis and Design Aspect-Oriented Software Development (AOSD)

  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. 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. 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. 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. 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. 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. 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. 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. Benefits of Separation of Concerns • Supports high cohesion among components • Supports low coupling among components • Increases modularity

  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. 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. Display * Figure FigureElement Point Line 2 getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) Example - Figure Editor - Design • Components are • Cohesive • Loosely Coupled • Have well-defined interfaces (abstraction, encapsulation) Nice Modular Design!

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

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

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

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

  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. 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. 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. 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. 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. What to Do...?

  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. 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. 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. 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. History of AOP languages Scripts (Francez 81) OO languages MOP(1985) Reflection(Smith 81) AI (semanticnetworks 79) Sinainterface predicates(1988) Law of Demeter(1988) CLOS-MOP Adaptiveprogramming(1992) Composition Filters(1992) Crosscuttingaspects (1996) AspectJ(1997) Composition Filterswith superimposition(2001) AspectJ(2000) http://trese.cs.utwente.nl

  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. Example – Without AOP 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 { privateint _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”); } } class Tracer { static void traceEntry(String str) { System.out.println(str); } static void traceExit(String str) { System.out.println(str); } } Tangling Code Scattered Concern

  31. Example – With AOP 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 { privateint _x = 0, _y = 0; int getX() { return _x; } int getY() { return _y; } void setX(int x) { _x = x; } void setY(int y) { _y = y; } } aspectTracing { pointcut traced(): call(* Line.* || call(* Point.*); before(): traced() { println(“Entering:” + thisjopinpoint); voidprintln(String str) {<write to appropriate stream>} } } Aspect is defined in a separate module Crosscutting is localized No scattering; No tangling Improved modularity

  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. Display * Figure FigureElement Point Line 2 getX() getY() getP1 setP1 setX(int) setY(int) setP1(Point) setP2(Point) 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. Tracer pointcut traced(): call(* Line.*) || call(* Point.*);

  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. 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. 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. Advice JP JP Advice Advice JP 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 }

  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 AspectX classX x classY AspectY AspectY

  39. pointcut advice Example - AspectJ 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 { privateint _x = 0, _y = 0; int getX() { return _x; } int getY() { return _y; } void setX(int x) { _x = x; } void setY(int y) { _y = y; } } aspectTracing { pointcut traced(): call(* Line.* || call(* Point.*); before(): traced() { println(“Entering:” + thisjopinpoint); after(): traced() { println(“Exit:” + thisjopinpoint); voidprintln(String str) {<write to appropriate stream>} } } aspect

  40. Code Weaving • Before compile-time (pre-processor) • During compile-time • After compile-time • At load time • At run-time

  41. Example - AspectJ aspect MoveTracking { privatestatic boolean _flag = false; publicstatic 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. 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. 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. 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. 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. 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 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. 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. 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. 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.

More Related