Upload
lauren-sparks
View
215
Download
0
Embed Size (px)
DESCRIPTION
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
Citation preview
Thesis Proposal Defense12/13/06
Marc Eaddy
12/13/2006 Thesis Proposal 2
Motivation
12/13/2006 Thesis Proposal 3
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
12/13/2006 Thesis Proposal 4
OutlineImportance of modular designCrosscutting concernsConcern modelCrosscutting metricsCase studyAdvanced separation of concernsWicca#TimelineConclusion
12/13/2006 Thesis Proposal 5
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
12/13/2006 Thesis Proposal 6
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”
12/13/2006 Thesis Proposal 7
Goblin: Game AI
Game AI is “localized”
12/13/2006 Thesis Proposal 8
Goblin: Collision detection
Collision detection is “scattered” (“crosscutting”)
12/13/2006 Thesis Proposal 9
A crosscutting concernScatters its implementation across many modules
Reduces program’s overall modularityMakes program harder to understand, develop in parallel, maintain, and evolve
12/13/2006 Thesis Proposal 10
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
12/13/2006 Thesis Proposal 11
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 ,,:
… …
12/13/2006 Thesis Proposal 12
Formal terminology
12/13/2006 Thesis Proposal 13
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
12/13/2006 Thesis Proposal 14
12/13/2006 Thesis Proposal 15
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
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
# of component’s statements related to the concern
Total # of statements related to the concern
18
Solution: Crosscutting metricsAdapted and extended closeness metrics to measure
crosscuttingConcentration – 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.
s
tsst A
Ac
c
CONC
c
c
c
t
tsst V
A DEDI
# of component’s statements related to the concern
Total # of statements related to the concern
19
Solution: Crosscutting metricsAdapted and extended closeness metrics to measure
crosscuttingConcentration – 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.
s
tsst A
Ac
c
CONC
c
c
c
t
tsst V
A DEDI
# of component’s statements related to the concern
Total # of statements related to the concern
Total # of component’s statements
20
Solution: Crosscutting metricsAdapted and extended closeness metrics to measure
crosscuttingConcentration – 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 insightUnwieldy 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.
s
tsst A
Ac
c
CONC
c
c
c
t
tsst V
A DEDI
# of component’s statements related to the concern
Total # of statements related to the concern
Total # of component’s statements
12/13/2006 Thesis Proposal 21
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
12/13/2006 Thesis Proposal 22
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
12/13/2006 Thesis Proposal 23
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
12/13/2006 Thesis Proposal 24
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)
12/13/2006 Thesis Proposal 25
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
12/13/2006 Thesis Proposal 26
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#
12/13/2006 Thesis Proposal 27
Subject: GoblinPlatform for building 3D applications and games14,500 source lines of C#Designed and partially implemented by me
12/13/2006 Thesis Proposal 28
Case study phasesConcern tagging using statement annotations; statistics gathering
Implement AspectJ-like featuresin Phx.Morph v1.2
Design and implement Wicca#
12/13/2006 Thesis Proposal 29
Advanced separation of concernsAspect-, feature-, subject- oriented
programmingMulti-dimensional separation of concernsOpen classesMetaprogrammingetc.
12/13/2006 Thesis Proposal 30
Problem: ASOC hurts modularity
12/13/2006 Thesis Proposal 31
Solution:Goal
Actually “modularize” crosscutting concerns (i.e., without sacrificing other modularity properties)
Extends C# to supportSide classesStatement annotations
12/13/2006 Thesis Proposal 32
Side classesPowerful and disciplined class extension
12/13/2006 Thesis Proposal 33
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
12/13/2006 Thesis Proposal 34
Timeline
12/13/2006 Thesis Proposal 35
Conclusion
12/13/2006 Thesis Proposal 36
1
1CONC
1 DOS
2
C
CC
C
tst
sc
c
Conclusion
12/13/2006 Thesis Proposal 37
1
1CONC
1 DOS
2
C
CC
C
tst
sc
c
Conclusion
12/13/2006 Thesis Proposal 38
1
1CONC
1 DOS
2
C
CC
C
tst
sc
c
Thank you!
12/13/2006 Thesis Proposal 39
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/2006 Thesis Proposal 40
• 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; }...
12/13/2006 Thesis Proposal 41
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/2006 Thesis Proposal 42
Side class: Caching eval
Cache expression evaluationclass : AddExpr : Observer {
...override public int eval() {
if (!isCacheValid) {cache = base.eval();isCacheValid = true;
}return cache;
}...
12/13/2006 Thesis Proposal 43
Cache expression evaluationclass : AddExpr : Observer {
...override public int eval() {
if (!isCacheValid) {cache = base.eval();isCacheValid = true;
}return cache;
}...
12/13/2006 Thesis Proposal 44
Property change notificationclass : AddExpr : Observer {
...override Expression [$which = left | right] {
set { base.$which = value; $which.observer = this; if (observer != null)
observer.update();}
}}
12/13/2006 Thesis Proposal 45
Property change notificationclass : AddExpr : Observer {
...override Expression [$which = left | right] {
set { base.$which = value; $which.observer = this; if (observer != null)
observer.update();}
}}
12/13/2006 Thesis Proposal 46
12/13/2006 Thesis Proposal 47
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
12/13/2006 Thesis Proposal 48
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