 Introduction  Terms  Design – Modeling  Requirements  Languages  Maintenance  Comparison to Object Oriented  Applications 2

 Software Development History › Started out with emphasis on the machine code (basic machines) › Problems discovered in 70s and 80s led to emphasis on quality, productivity › 1980s and 1990s saw the rise of UML 3

 Object Oriented Development › Benchmark of most projects today › Started in 1960s, rose to prominence in late 80s and 90s › Supported by many languages, most common C++ and Java › Easy to be modeled by UML language › Has several problems 4

“AOP can be understood as the desire to make quantified statements about the behavior of programs, and to have these quantifications hold over programs written by oblivious programmers.” – Filman and Friedman 5

 Aspect Oriented Software Development › Developed due to problems with OO › First theory proposed in 1995 › Implementation in early 2000s, Netherlands, Texas › Entire new vocabulary › Key structural differences › Still relatively new, gaining acceptance in a few areas 6

 Concerns › Key new concept › Similar but more refined than objects  Aspects › Implementation of concern › Usually contains only code for a specific feature 7

 Crosscutting Concerns › Code called in several places throughout a program › Feature that is hard to modularize in OO  Areas of Crosscutting Concerns:  Synchronization  Real-time constraints  Error detection and correction  Product features  Memory management  Information security  Caching  Logging  Monitoring  Code mobility  Internationalization and localization  Domain-specific optimizations 8

 Join Points › Where aspects are called in the execution of a program › Placement dependent on language  Advice › Tells system what to do at a an aspect › Oblivious of base code › after() : set() { Display.update(); } 9

 Pointcut designator › Collection of join points › Can be used for features called often at specific places (security)  Weaving › Inserting the aspects into the base code › Can happen at three stages of software 10

 Unified Modeling Language (UML) › Due to acceptance, often used › Implementations capture aspect methods, join points › Separates base code from features 11

12

 UML (Cont’d)  Aspects can also be grouped by function › Synchronization › Distribution › Coordination › Replication 13

14

 Architectural Description Language › Still in development › Able to show connections between base code and aspects › Also shows separation of base code and functional code › Good for upper level requirements 15

 Sequence diagrams › Can demonstrate when aspects are called › Can help developers determine where to put join points 16

 Best in beginning of software development  Good at separating features and base code  Good for determining join points  Helps with concern determination 17

.NET Framework languages (C# / VB.NET)  C / C++  Cobol  Cocoa  ColdFusion  Common Lisp  Delphi  Delphi Prism  e (IEEE 1647)  Haskell  Java › AspectJ  JavaScript  Emacs Lisp  Lua  make  ML  Perl  PHP  Prolog  Python  Ruby  Squeak Smalltalk  UML 2.0  XML 18

 Languages have to be adapted › Some languages are supplementary › Some have built in aspect support › Determine join points › Determine weaving time › Some languages are Object Oriented language compatible, some not 19

 Most Common  Architecture of Java allows easy transition  Reclassifies Java’s critical section features 20

public void doGet(JspImplicitObjects theObjects) throws ServletException { logger.entry("doGet(...)"); JspTestController controller = new JspTestController(); controller.handleRequest(theObjects); logger.exit("doGet"); } public aspect AutoLog{ pointcut publicMethods() : execution(public * org.apache.cactus..*(..)); pointcut logObjectCalls() : execution(* Logger.*(..)); pointcut loggableCalls() : publicMethods() && ! logObjectCalls(); before() : loggableCalls(){ Logger.entry(thisJoinPoint.getSignature().toString()); } after() : loggableCalls(){ Logger.exit(thisJoinPoint.getSignature().toString()); } 21

 New features can be added without disturbing original code  Java programs can easily use aspects  Separation of concerns make maintenance easier  Helps prevent tangling of code  Easier to debug, all code in one place 22

 Still has some problems › Could cause problems in large projects, join points getting changed › Small changes, function call placement can cause problems › Different structure can cause problems for programmers 23

 Aspect Oriented Development is a derivative of Object Oriented Development  Object Orientation focuses on Modularity  Aspect Orientation focuses on Concerns  Object Orientation tangles code, Aspect Orientation separates  Singletons not supported in AOP 24

 Findings : › Easier to find where to put new code › Easier to implement new code › Similar compile times › Harder to make changes › Lack of understanding hurts › Processes not clear to fix problems 25

 Open Source Uses › Can allow mixing of proprietary and open source programming › Easy to add new features to base code › Can determine what features are actually needed 26

 Can implement several different features  Allows many different products from one set of base code  Can roll out product sooner, worry about features later 27

28

 Can turn existing software into AOP  Easier to test, especially features  Several different areas of features can be separated from main program  Makes software more portable 29

 SAP  Siemens Health  Sun Microsystems  IBM  Motorola  Glassbox (Diagnostic Tool) 30

 New emerging technology  Not complete solution to Object Oriented Software Development, but improves in a few areas  Has some exciting features  Currently in use, more widespread as it is refined 31

 [1] Filman, R. & Friedman, D. (2005). Aspect-Oriented Programming Is Quantification and Obliviousness. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp.1-7). Boston: Addison-Wesley.  [2] Clemente, P., Hernandez, J., Herrero, J., Murillo, J., Sanchez, F. (2005). Aspect-Orientation in the Software Lifecycle: Fact and Fiction. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp ). Boston: Addison-Wesley.  [3] Pinto, M., Fuentes, L., Troya, J. (2003) A Dynamic Component and Aspect-Oriented Platform. The Computer Journal, 48, pp  [4] Spring Maintenance. (n.d.). Retrieved November 1, 2009 from Maintenance website. maintenance/  [5] Blair, G., Blair, L., Rashid, A., Moreira, A., Araujo, J., Chitchyan, R. (2005). Engineering Aspect-Oriented Systems. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp ). Boston: Addison-Wesley. 32

 [6] AspectJ. (n.d.). Retrieved October 31, 2009 from Eclipse website,  [7] Colyer, A. (2005). AspectJ. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp ). Boston: Addison-Wesley.  [8] Apel, S., Leich, T., Saake, G. (2008). Aspectual Feature Models. IEEE Transactions of Software Engineering, 34, p  [9] Walker, R., Baniassad, E., Murphy, G. (2005). An Initial Assessment of Aspect-Oriented Programming. In Fillman, Elrad, Clark, Aksit (Eds.), Aspect-Oriented Software Development (pp ). Boston: Addison-Wesley.  [10] Harrison, W., Ossher, H., Sutton, S., Tarr, P. (2005). Supporting aspect-oriented software development with the Concern Manipulation Environment. IBM Systems Journal, 44, (pp ).  [11] Aspect-Oriented Software Development(n.d.). Retrieved November 4, 2009 from Wikipedia website, 33

 Questions 34