1. Thesis Proposal Defense 12/13/06 Marc Eaddy

2. 12/13/2006Thesis Proposal2 Motivation Modularity is unnecessarily limited by the presence of crosscutting concerns

3. 12/13/2006Thesis Proposal3 My thesis in a nutshell Improve understanding of crosscutting concerns and how they impact modularity, and suggest ways to reduce the impact Modularity is essential for understandable, maintainable, and evolvable software Crosscutting concerns hinder modularity, but no one knows how much “Crosscutting concern” concept is ill-defined Impact on modularity insufficiently understood and quantified My solution: New formal model and metrics Existing approaches for modularizing crosscutting concerns actually hinder modularity My solution: New language that improves modularity

4. 12/13/2006Thesis Proposal4 Outline Importance of modular design Crosscutting concerns Concern model Crosscutting metrics Case study Advanced separation of concerns Wicca# Timeline Conclusion

5. 12/13/2006Thesis Proposal5 Modular design Division of a large program into smaller logically self- contained subprograms (modules) Arguably the most important design property of a program Simplifies the program Enables separation of concerns (Dijkstra) Enables modular reasoning Example: Information hiding (Parnas) Enables independent development and testing Example: Interfaces Improves reusability and substitutability Example: Abstract data types (Liskov) Reduces impact of changes

6. 12/13/2006Thesis Proposal6 Software concerns Any consideration about the implementation of a program Features, requirements, policies, design rules, etc. Some concerns easy to modularize (e.g., using OO) “Person” “Shape” “Socket” Some concerns difficult to modularize using a particular decomposition technique Tyranny of the dominant decomposition “Expression problem” “Error handling” “Collision detection”

7. 12/13/2006Thesis Proposal7 Goblin: Game AI Game AI is “localized”

8. 12/13/2006Thesis Proposal8 Goblin: Collision detection Collision detection is “scattered” (“crosscutting”)

9. 12/13/2006Thesis Proposal9 A crosscutting concern Scatters its implementation across many modules Reduces program’s overall modularity Makes program harder to understand, develop in parallel, maintain, and evolve

10. 12/13/2006Thesis Proposal10 Problem: Crosscutting ill-defined A concern can be anything A concern can crosscut anything Common AOP terms ill-defined “scattered”, “tangled”, “crosscutting” Easy to concoct arguments to favor proposed solution Hard to evaluate solutions

11. 12/13/2006Thesis Proposal11 Solution: Formal concern model Concern model: (S, T, R) S: Source domain (e.g., concern domain) T: Target domain (e.g., component specifications) R: Relation on SxT (e.g., “implemented by” relation) … …

12. 12/13/2006Thesis Proposal12 Formal terminology Concern implemented by multiple components Scattered Two concern implementations overlap Tangled (“very appealing” – Gail Murphy) Crosscutting ≡ Scattered

13. 12/13/2006Thesis Proposal13 Model contributions Formalizes terminology and concepts Crosscutting, concern, scattered, tangled S, T, and R should be well-defined Generally applicable Supports all concern and component types Existing formalisms expressible using my model Many CS areas reduced to finding S, T, or R Applicable to non-CS domains Solid math. foundation for measuring crosscutting

14. Related work (model) Robillard and Murphy, Concern Graphs No formal definitions for AOP terminology No metrics Coppit et al., Software Plans No formal definitions for AOP terminology Not suitable for defining metrics 12/13/2006Thesis Proposal14

15. 12/13/2006Thesis Proposal15 Problem: Crosscutting impact insufficiently quantified Concerns are informal (subjective) and incomplete Conclusions are questionable Metrics are crude Spread metric (Lai and Murphy, Revelle et al.), diffusion metrics (Garcia et al.) Measure presence of a concern, not degree Cannot distinguish between a concern split 50- 50 and 99-1 Cannot distinguish the impact of refactorings

16. 16 Solution: Crosscutting metrics Adapted and extended closeness metrics to measure crosscutting Concentration – Amount of a concern’s implementation that is contained in a specific component W. E. Wong, S. G. Swapna, and R. H. Joseph, "Quantifying the closeness between program components and features," Journal of Systems and Software, 2000.

17. 17 Solution: Crosscutting metrics Adapted and extended closeness metrics to measure crosscutting Concentration – Amount of a concern’s implementation that is contained in a specific component W. E. Wong, S. G. Swapna, and R. H. Joseph, "Quantifying the closeness between program components and features," Journal of Systems and Software, 2000. # of component’s statements related to the concern Total # of statements related to the concern

18. 18 Solution: Crosscutting metrics Adapted and extended closeness metrics to measure crosscutting Concentration – Amount of a concern’s implementation that is contained in a specific component Dedication* – Amount of a component’s implementation that is related to a specific concern (* extended to handle tangled concerns) W. E. Wong, S. G. Swapna, and R. H. Joseph, "Quantifying the closeness between program components and features," Journal of Systems and Software, 2000. # of component’s statements related to the concern Total # of statements related to the concern

19. 19 Solution: Crosscutting metrics Adapted and extended closeness metrics to measure crosscutting Concentration – Amount of a concern’s implementation that is contained in a specific component Dedication* – Amount of a component’s implementation that is related to a specific concern (* extended to handle tangled concerns) W. E. Wong, S. G. Swapna, and R. H. Joseph, "Quantifying the closeness between program components and features," Journal of Systems and Software, 2000. # of component’s statements related to the concern Total # of statements related to the concern Total # of component’s statements

20. 20 Solution: Crosscutting metrics Adapted and extended closeness metrics to measure crosscutting Concentration – Amount of a concern’s implementation that is contained in a specific component Dedication* – Amount of a component’s implementation that is related to a specific concern (* extended to handle tangled concerns) Closeness metrics provide data points, not insight Unwieldy for measuring the impact of a refactoring W. E. Wong, S. G. Swapna, and R. H. Joseph, "Quantifying the closeness between program components and features," Journal of Systems and Software, 2000. # of component’s statements related to the concern Total # of statements related to the concern Total # of component’s statements

21. 12/13/2006Thesis Proposal21 My metrics: DOS Degree of scattering – Measures the distribution of a concern’s implementation across multiple components

22. 12/13/2006Thesis Proposal22 My metrics: DOS Degree of scattering – Measures the distribution of a concern’s implementation across multiple components Average DOS – Overall modularity of concerns Summarizes amount of crosscutting present More insightful than traditional metrics “class A is highly coupled” vs. “feature A is hard to change”

23. 12/13/2006Thesis Proposal23 My metrics: DOF Degree of focus – Degree to which a component’s implementation relates to multiple concerns Average DOF – Overall separation of concerns

24. 12/13/2006Thesis Proposal24 Goodness of metrics Counterbalance each other Correlate with intuition Obviously good C/C++ refactorings Promising preliminary results Crosscutting is very sensitive to S, T, and R Metrics useful for program comprehension Not all crosscutting needs to be “fixed” Nonfunctional reqs not always crosscutting “Localized” not always equal to “modularized” (“This is really great.” – Nachi Nagappan)

25. 12/13/2006Thesis Proposal25 Metrics caveats Manual concern identification impractical Only tell part of the modularity story More evidence needed before I can generalize More case studies Multiple “concern identifiers” (e.g., grad students) Comparison to previous case studies and results

26. 12/13/2006Thesis Proposal26 Case study Validate model and metrics Obtain insight into crosscutting Nature of crosscutting Scope of crosscutting problem Amount of latent modularity potential Limits of modularity Inform design of new modularization technique (Wicca#) Compare modularization techniques AspectJ, Wicca#

27. 12/13/2006Thesis Proposal27 Subject: Goblin Platform for building 3D applications and games 14,500 source lines of C# Designed and partially implemented by me

28. 12/13/2006Thesis Proposal28 Case study phases Concern tagging using statement annotations; statistics gathering Initial 50% complete OO Refactoring AO Refactoring Wicca# Refactoring Implement AspectJ-like features in Phx.Morph v1.2 Design and implement Wicca#

29. 12/13/2006Thesis Proposal29 Advanced separation of concerns Aspect-, feature-, subject- oriented programming Multi-dimensional separation of concerns Open classes Metaprogramming etc.

30. 12/13/2006Thesis Proposal30 Problem: ASOC hurts modularity Violates information hidingGlobalizes variablesAlters control flow arbitrarilyPrevents modular reasoningRequires global system knowledgeHinders extensibility and independent developmentCreates implicit and fragile couplings between modulesIntegrates poorly with existing paradigms (e.g., OO)

31. 12/13/2006Thesis Proposal31 Solution: Goal Actually “modularize” crosscutting concerns (i.e., without sacrificing other modularity properties) Extends C# to support Side classes Statement annotations

32. 12/13/2006Thesis Proposal32 Side classes Powerful and disciplined class extension Powerful Combines and unifies features of subclasses, aspects, open classes, and refinements Virtual fields, constructors, and static members Multiple base classes can be extended simultaneously Extension order is arbitrary or explicit Disciplined Extensions must be explicitly allowed Honors access restrictions (public, private, protected, virtual) Limits quantification

33. 12/13/2006Thesis Proposal33 Statement annotations Relating code to concerns (R) Indicating code injection locations (AOP) Specifying Optimization and parallelization hints Contracts Fault isolation for injected/generated code Reducing concern scattering “Statement Annotations for Fine-Grained Advising”, RAM-SE 2006 Allows any program statement to be annotated //[Concern("Input")] inputMapper.Update(elapsedTime);

34. Related work (language design) Unification of AO and OO (C#) Example: Eos Removed asymmetry between aspects and classes However, unification is deeper in Wicca# Advising mechanism: method overloading Introduction mechanism: base class derivation Language restrictions to enable modular reasoning Examples: Crosscut Program Interfaces, Aspect-Aware Interfaces, Open Modules Advising more explicit, but not well integrated with OO 12/13/2006Thesis Proposal34

35. Timeline Writing Prep Defense Revisions Deposit Fall 2007 Intern Thesis writing Summer 2007 OO refactoring Phx.Morph ver. 1.2 AO refactoring Wicca# ver. 3 Wicca# refactoring Write 2 papers Additional case studies Thesis writing Spring 2007 12/13/2006Thesis Proposal35

36. Conclusion Concern model Crosscutting metrics Measurement methodology New approach for quantifying crosscutting 12/13/2006Thesis Proposal36

37. Conclusion Concern model Crosscutting metrics Measurement methodology New approach for quantifying crosscutting Nature Scope Impact on modularity Improved understanding of crosscutting 12/13/2006Thesis Proposal37

38. Conclusion Concern model Crosscutting metrics Measurement methodology New approach for quantifying crosscutting Nature Scope Impact on modularity Improved understanding of crosscutting Side classes Statement annotations New approach for modularizing crosscutting 12/13/2006Thesis Proposal38

39. Thank you! 12/13/2006Thesis Proposal39

40. Expression problem revisited class AddExpr : Expression { virtual Expression left, right; public virtual AddExpr(Expression left, Expression right) { this.left = left; this.right = right; } public int eval() { return left.eval() + right.eval(); } } 12/13/2006Thesis Proposal40 Language parsing Expressions: Literal, Add, etc. Operations: eval, print, etc. Task: Cache expression evaluation

41. Side class: Caching eval class : AddExpr : Observer { int cache; bool isCacheValid = false; public override AddExpr(Expression left, Expression right) { base(left, right); this.left.observer = this; this.right.observer = this; } void Observer.update() { isCacheValid = false; }... 12/13/2006Thesis Proposal41

42. class : AddExpr : Observer { int cache; bool isCacheValid = false; public override AddExpr(Expression left, Expression right) { base(left, right); this.left.observer = this; this.right.observer = this; } void Observer.update() { isCacheValid = false; }... 12/13/2006Thesis Proposal42 Side class: Caching eval

43. Cache expression evaluation class : AddExpr : Observer {... override public int eval() { if (!isCacheValid) { cache = base.eval(); isCacheValid = true; } return cache; }... 12/13/2006Thesis Proposal43

44. Cache expression evaluation class : AddExpr : Observer {... override public int eval() { if (!isCacheValid) { cache = base.eval(); isCacheValid = true; } return cache; }... 12/13/2006Thesis Proposal44

45. Property change notification class : AddExpr : Observer {... override Expression [$which = left | right] { set { base.$which = value; $which.observer = this; if (observer != null) observer.update(); } 12/13/2006Thesis Proposal45

46. Property change notification class : AddExpr : Observer {... override Expression [$which = left | right] { set { base.$which = value; $which.observer = this; if (observer != null) observer.update(); } 12/13/2006Thesis Proposal46

47. 12/13/2006Thesis Proposal47 My metrics: DOT Degree of tangling – Degree to which a concern shares its implementation with other concerns Average DOT – Overall concern coupling

48. 12/13/2006Thesis Proposal48 My metrics: DOT Degree of tangling – Degree to which a concern shares its implementation with other concerns Average DOT – Overall concern coupling # of nonshared statements related to the concern Total # of statements related to the concern