thesis proposal defense 12/13/06 marc eaddy. 12/13/2006thesis proposal2 motivation modularity is...

Thesis Proposal Defense12/13/06

Marc Eaddy

12/13/2006 Thesis Proposal 2

Motivation


My thesis in a nutshellImprove 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 metricsExisting approaches for modularizing crosscutting concerns

actually hinder modularityMy solution: New language that improves modularity


OutlineImportance of modular designCrosscutting concernsConcern modelCrosscutting metricsCase studyAdvanced separation of concernsWicca#TimelineConclusion


Modular designDivision of a large program into smaller logically self-

contained subprograms (modules)Arguably the most important design property of a

programSimplifies the program

Enables separation of concerns (Dijkstra)Enables modular reasoningExample: Information hiding (Parnas)

Enables independent development and testingExample: Interfaces

Improves reusability and substitutabilityExample: Abstract data types (Liskov)

Reduces impact of changes


Software concernsAny consideration about the implementation of a programFeatures, 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 techniqueTyranny of the dominant decomposition“Expression problem”“Error handling”“Collision detection”


Goblin: Game AI

Game AI is “localized”


Goblin: Collision detection

Collision detection is “scattered” (“crosscutting”)


A crosscutting concernScatters its implementation across many modules

Reduces program’s overall modularityMakes program harder to understand, develop in parallel, maintain, and evolve


Problem: Crosscutting ill-definedA concern can be anythingA concern can crosscut anythingCommon AOP terms ill-defined

“scattered”, “tangled”, “crosscutting”Easy to concoct arguments to favor proposed

solutionHard to evaluate solutions


Solution: Formal concern modelConcern 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)

TtSsts,R ,,:

… …


Formal terminology


Model contributionsFormalizes terminology and concepts

Crosscutting, concern, scattered, tangledS, T, and R should be well-defined

Generally applicableSupports all concern and component typesExisting formalisms expressible using my modelMany CS areas reduced to finding S, T, or RApplicable to non-CS domains

Solid math. foundation for measuring crosscutting

Related work (model)Robillard and Murphy, Concern Graphs

No formal definitions for AOP terminology

No metricsCoppit et al., Software Plans

No formal definitions for AOP terminology

Not suitable for defining metrics



Problem: Crosscutting impact insufficiently quantifiedConcerns are informal (subjective) and

incompleteConclusions are questionable

Metrics are crudeSpread metric (Lai and Murphy, Revelle et

al.), diffusion metrics (Garcia et al.)Measure presence of a concern, not degreeCannot distinguish between a concern split

50-50 and 99-1Cannot distinguish the impact of refactorings

16

Solution: Crosscutting metricsAdapted and extended closeness metrics to measure

crosscuttingConcentration – 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.

s

tsst A

Ac

c

CONC

17





s

tsst A

Ac

c

CONC

# of component’s statements related to the concern

Total # of statements related to the concern

18




Dedication* – Amount of a component’s implementation that is related to a specific concern (* extended to handle tangled concerns)


s

tsst A

Ac

c

CONC

c

c

c

t

tsst V

A DEDI



19






s

tsst A

Ac

c

CONC

c

c

c

t

tsst V

A DEDI



Total # of component’s statements

20


crosscuttingConcentration – Amount of a concern’s implementation that is

contained in a specific component


Closeness metrics provide data points, not insightUnwieldy for measuring the impact of a refactoring


s

tsst A

Ac

c

CONC

c

c

c

t

tsst V

A DEDI



Total # of component’s statements


My metrics: DOSDegree of scattering – Measures the

distribution of a concern’s implementation across multiple components

1

1CONC

1 DOS

2

C

CC

C

tst

sc

c


My metrics: DOSDegree of scattering – Measures the

distribution of a concern’s implementation across multiple components

Average DOS – Overall modularity of concernsSummarizes amount of crosscutting present

More insightful than traditional metrics“class A is highly coupled” vs. “feature A is

hard to change”

1

1CONC

1 DOS

2

C

CC

C

tst

sc

c


My metrics: DOFDegree of focus – Degree to which a

component’s implementation relates to multiple concerns

Average DOF – Overall separation of concerns

1

1DEDI DOF

2

SS

SS

sst

t

c

c


Goodness of metricsCounterbalance each otherCorrelate with intuition

Obviously good C/C++ refactoringsPromising preliminary results

Crosscutting is very sensitive to S, T, and RMetrics useful for program comprehensionNot all crosscutting needs to be “fixed”Nonfunctional reqs not always crosscutting“Localized” not always equal to “modularized”

(“This is really great.” – Nachi Nagappan)


Metrics caveatsManual concern identification impracticalOnly tell part of the modularity storyMore evidence needed before I can

generalizeMore case studiesMultiple “concern identifiers” (e.g., grad

students)Comparison to previous case studies and

results


Case studyValidate model and metricsObtain insight into crosscutting

Nature of crosscuttingScope of crosscutting problem

Amount of latent modularity potentialLimits of modularity

Inform design of new modularization technique (Wicca#)

Compare modularization techniquesAspectJ, Wicca#


Subject: GoblinPlatform for building 3D applications and games14,500 source lines of C#Designed and partially implemented by me


Case study phasesConcern tagging using statement annotations; statistics gathering

Implement AspectJ-like featuresin Phx.Morph v1.2

Design and implement Wicca#


Advanced separation of concernsAspect-, feature-, subject- oriented

programmingMulti-dimensional separation of concernsOpen classesMetaprogrammingetc.


Problem: ASOC hurts modularity


Solution:Goal

Actually “modularize” crosscutting concerns (i.e., without sacrificing other modularity properties)

Extends C# to supportSide classesStatement annotations


Side classesPowerful and disciplined class extension


Statement annotations

Relating code to concerns (R)Indicating code injection locations (AOP)Specifying

Optimization and parallelization hintsContracts

Fault isolation for injected/generated codeReducing concern scattering

“Statement Annotations for Fine-Grained Advising”, RAM-SE 2006

Allows any program statement to be annotated

//[Concern("Input")]inputMapper.Update(elapsedTime);

Related work (language design)Unification of AO and OO (C#)

Example: EosRemoved asymmetry between aspects and classesHowever, unification is deeper in Wicca#

Advising mechanism: method overloading Introduction mechanism: base class derivation

Language restrictions to enable modular reasoningExamples: Crosscut Program Interfaces, Aspect-

Aware Interfaces, Open ModulesAdvising more explicit, but not well integrated with

OO


Timeline


Conclusion


1

1CONC

1 DOS

2

C

CC

C

tst

sc

c

Thank you!


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(); }}


• Language parsing• Expressions: Literal, Add, etc.• Operations: eval, print, etc.

• Task: Cache expression evaluation

Side class: Caching evalclass : 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; }...


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; }...


Side class: Caching eval

Cache expression evaluationclass : AddExpr : Observer {

...override public int eval() {

if (!isCacheValid) {cache = base.eval();isCacheValid = true;

}return cache;

}...


Property change notificationclass : AddExpr : Observer {

...override Expression [$which = left | right] {

set { base.$which = value; $which.observer = this; if (observer != null)

observer.update();}

}}



My metrics: DOTDegree of tangling – Degree to which a

concern shares its implementation with other concerns

Average DOT – Overall concern coupling

s

ss A

D DOT


My metrics: DOTDegree 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 concerns

ss A

D DOT

thesis proposal defense 12/13/06 marc eaddy. 12/13/2006thesis proposal2 motivation modularity is...

Documents