software remodeling - intertech · 2004-04-23 · ©togethersoft™ corporation 2002 improving the...

Improving the ways people work together™©TogetherSoft™ Corporation 2002

Software RemodelingImproving Design and Implementation Quality

Audits, Metrics and Refactoring using Together® ControlCenter™


Introduction

Code Reviews– Define and Discuss– The Good, Bad and Ugly

Audits – Define and Discuss– Case Studies

Metrics– Define and Discuss– Case Studies

Refactoring– Define and Discuss– Driven by Audits & Metrics

Open Discussion


Code ReviewsSoftware Inspection

Definition:– ‘…a formal evaluation technique in

which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems…’

-ANSI/IEEE Std. 729-1983,IEEE Standard Glossary of Software Engineering Terminology


Code ReviewsSoftware Inspection

Objectives of Software Inspection:– ‘to detect and identify software elements

defects. This is a rigorous, formal peer examination that does the following:

1) Verifies that the software element(s) satisfy its specifications.

2) Verifies that the software elements(s) conform to applicable standards.

3) Identifies deviation from standards and specifications.4) Collects software engineering data (for example,

defect and effort data).5) Does not examine alternatives or stylistic Issues.’

-ANSI/IEEE Std. 1028-1988, IEEE Standard for Software Reviews and Audits


Code ReviewsHistorical View of Software Inspection

Began with Michael Fagan (1970s at IBM)- Applied industrial hardware statistical quality methods to

software- Created ‘Inspection’ technique (Big “I”), typically referred

to as ‘Fagan’s Inspection’Finds defects in all software artifactsAttempts to predict remaining level of defects based on statistical analysis of inspection reports

Also tries to improve the process

See “Software Inspection” by Gilb and Graham


Code ReviewsContemporary Practices

Agile processes focus more on source code:Agile Manifesto…

- Value working software over comprehensive documentation.

Extreme Programming (XP)- Continuous code reviews with pair programming- Produces 85% of the code that should be of

substantially higher quality [Carmichael, Haywood]

Feature-Driven Development (FDD)- Relies heavily on inspections to ensure high quality of

designs and code- Inspection steps built-in- Participants limited to those concerned


Code ReviewsThe Good

Improve software qualityValidate business logicEnforce standardsHelp junior developers grow

“Inspections are the most cost effective intervention you can make in most organizations.” - G. Gack“The average defect detection rate is only 24% for unit testing, 35% for functional testing and 45% for integration testing. In contrast, the average effectiveness of design and code inspections is 55 and 60% respectively.” - C.L. Jones


Code ReviewsThe Bad

Time consuming, especially if “overengineering”occursUsually plagued with human inefficiencies and inaccuraciesDoesn’t scale well with larger code baseOne of the first things tossed when project slips

“One client found that each downstream software error cost on average 5 hours. Others have found [from 9-82!] hours to fix downstream. This is compared to the cost of only one hour to find and fix using inspections.” - T.Gilb and D. Graham


Code ReviewsThe Ugly

Lack of reviews may jeopardize future project success

Business logic is often overlooked

Perceived as a waste of time

Often degrade into chaos

General fear of criticism

Hero mentality: “Nobody needs to tell me how to code!”Common excuse: “We should be doing them, but we just don’t have time.”


Code ReviewsA Breakdown

Audit-Style Violations– Does the code meet company standards?– What language-specific issues are there? etc…

Design / Metric-Related Violations– Is there high cohesion and low coupling?– What is the level of complexity?– Is there a lack of encapsulation? etc…

Business Logic Review– Are the requirements met?– Are the unit tests adequate? etc…

Performance Review– Requires profiling data– Will involve aspects of both audits & metrics


Code ReviewsBenefits of Automation

“Software tools are very effective at finding certain types of defects… [They] are much faster and more accurate…” (Gilb, p.12)

Deep and precise parsing of source

Saves time and budget

Separation of concerns:- Computers excel at low-level inspection and counting

- People do not- People excel at business logic and design inspection

- Computers do not


Code ReviewsAutomation Case Studies

Task– Review by hand a small example set of code

• 5 classes, 139 lines of code, 4 Mentors in 15 minutesResults

– Average audit violations detected: 21 time: 0.25 hr

Comparison– The same set of code analyzed by a machine:

• Audit violations detected: 150 time: 2 sec– Humans @ 84/hr versus Machine @ 270,000/hr

An Actual Project– 187,600 violations in 100 minutes on a project with 1233

classes and 199,146 lines of code (117,250/hr)– 32,443 violations using the default set


AuditsEnforcing Rules for Source Code Conformance

What are Audits?– Checks for conformance to standard or user-defined

style, maintenance, and robustness guidelines.Motivation

– Improved readability– Improved standards-conformance– Increased performance– Reveal subtle errors that may result in bugs

Categories– Coding Style– Errors– Documentation– Superfluous Content– Performance


AuditsKnowing What to Look for…

Reading– Books (e.g. Effective Java™ by Joshua Bloch)– Language Specification– Virtual Machine Specification– Magazine articles (some at least…)– Performance books

Mentors– Senior developers in your organization– Resident “Language Lawyers”– Outside consultants

Experience– Takes time to develop breadth and depth

Tools…


AuditsJava™ Audits in Together® ControlCenter™

5Naming StyleFrom variable naming conventions to method grouping

14EJB SpecificPrevent violating EJB Programming Restrictions

4DocumentationFrom bad tags to collection-based associations

10Declaration StyleFrom order of modifiers to array declaration location

10Critical ErrorsFrom hiding names to command query separation

20Coding StyleFrom switch statement usage to ?: operator

Qty


AuditsJava™ Audits in Together® ControlCenter™ (cont’d)

105Total Java™ Audits:

Additionally, you can write your own custom Audits!

13UI Builder SpecificFrom conflicting mnemonics to multi-word menu titles

9Superfluous ContentFrom == operator to unnecessary cast expressions

15Possible ErrorsFrom synchronized modifier to empty catch blocks

5PerformanceFrom StringBuffer usage to complex loop expressions


AuditsA Sampling

Unused Private Class MembersUPCM

‘synchronized’ ModifierSM

Call super.finalize() from finalize()CSF

Comparing Floating Point TypesCFPT

Empty Catch BlocksECB

Multiple String ConcatenationsMSC

Append to String Within a LoopASWL


AuditsASWL – Append to String Within a Loop

Category: Performance

Effective Java™: Item 33 – Beware the performance of string concatenation

Wrong:

public String method() {

String var = "var";

for (int i=0; i<10; i++) {

var += (" " + i);

}

return var;

}

Right:

public String method() {

StringBuffer var = new StringBuffer("var“);

for (int i = 0; i < 10; i++) {

var.append(" " + i);

}

return var.toString();

}


AuditsMSC – Multiple String Concatenations

Category: Performance

Effective Java™: Item 33 – Beware the performance of string concatenation

Wrong:

private String getHtmlOut() {

String htmlOut;

htmlOut = "<html>";

...

htmlOut += "<body>";

...

htmlOut += “Record not found";

...

htmlOut += "</body></html>";

return htmlOut;

}

Right:

private String getHtmlOut() {

StringBuffer htmlOut=new StringBuffer(100);

htmlOut.append("<html>");

...

htmlOut.append("<body>");

...

htmlOut.append(“Record not found");

...

htmlOut.append("</body></html>");

return htmlOut.toString();

}


AuditsECB – Empty Catch Blocks

Category: Possible Errors

Effective Java™: Item 47 – Don’t ignore exceptions

Wrong:private void method() {

try {

// something...

} catch (Exception e) {

}

}

Right:private void method() {

try {

// something...

} catch (AnticipatedException ae) {

// recover gracefully

} catch (LowerLevelException lle) {

// exception chaining

throw new HigherLevelException(lle);

} catch (PropertyVetoException pve) {

// ignore with comment for why

} catch (Exception e) {

// not much better than empty

e.printStackTrace();

}

}


AuditsCFPT – Comparing Floating Point Types

Category: Possible ErrorsEffective Java™: Item 7 – Obey the general contract when overriding equals

Item 31 – Avoid float and double if exact answers required

Wrong:

void loop() {

double total = 0.00;

double dollar = 1.00;

for (int i=0; i<10; i++) {

total += 0.10;

}

if (total == dollar) {}

}

boolean equals (Object obj) {

if (this.d != obj.d) {

return false;

}

Right:

void loop () {

BigDecimal total = new BigDecimal(“0.00”);

final BigDecimal DIME = new BigDecimal(“0.10”);

for (int i=0; i<10; i++) {

total = total.add(DIME);

}

if (total.compareTo(new BigDecimal(“1.00”)) == 0) {}

}

boolean equals (Object obj) {

if (Double.doubleToLongBits(this.getDbl()) !=Double.doubleToLongBits(obj.getDbl()) {

return false;

}

}


AuditsCSF – Call super.finalize() from finalize()


Effective Java™: Item 6 – Avoid finalizers

Wrong:

void finalize() {

// cleanup

}

Right:

void finalize () throws Throwable {

try {

// cleanup

} finally {

super.finalize();

}

}


AuditsSM – ‘synchronized’Modifier


Effective Java™: Item 49 – Avoid excessive synchronization (Implied)

Wrong:

public synchronized void method() {

// do something...

}

Right:

public void method() {

// do something...

synchronized(this) {

// do something

}

// do something else...

}


AuditsUPCM – Unused Private Class Members

ULVFP – Unused Local Variables and Formal Parameters

Category: Superfluous Content

Effective Java™: Item 29 – Minimize the scope of local variables (Implied)

Wrong:

class WrittenLongAgo {

private int unused = 0;

private int used = 0;

public void doSomething (int x) {

int factor = 2;

int unused = 0;

for(int i=0; i<10; i++) {

used += i;

}

used *= factor;

}

}

Right:

class WrittenLongAgo {

private int used = 0;

public void doSomething () {

for(int i=0; i<10; i++) {

used += i;

}

int factor = 2;

used *= factor;

// OR… used <<=1;

}

}


AuditsAn Example

There are 150+Audit violationsIn these 5 files.

Let’s take a lookat this project inTogether®ControlCenter™…


AuditsCase Studies

2752Total from Default Audit Set2576…

24OWS (Overloading Within a Subclass)23MVDSN (Multiple Visible Declarations with Same Name)40HN (Hiding Names)1HISM (Hiding Inherited Static Methods)9HIA (Hiding Inherited Attributes)

40ASWL (Appending to String Within a Loop)28ASMO (Accessing Static Members through Objects)11AFLV (Assignment to ‘for’ Loop Variables)

Apache Ant version 1.4851Total from Default Audit Set

5258Sun Code Conventions for Java™ Audit Set

# ViolationsPetStore1.3 from Sun’s J2EE Blueprints Program


AuditsAdditional Audits Inspired by Effective Java™

18

17

15

15129

4Item

Override hashCode() When Overriding equals()

Constants Interface Pattern should be avoided – use a typesafe enum or non-instantiatable class instead

Private Serializer Methods – readResolve() and writeReplace() methods in inheritable Serializable classes must be declared protected

Invoking Overridable Methods with a constructor, clone() or readObject() must not be done.

Avoid Public Final Static Arrays – as they are mutableAlways Override toString()

Avoid String Constructor (e.g. String silly = newString (“silly”);)

Description

36OHWOE

89CIP

82PSM

80IOM61APSFA42AOT

13ASCPageAudit


AuditsAdditional Audits Inspired by Effective Java™(cont’d)

12725Use Interface Type For Parameters (e.g. use Maprather than HashMap)

UITFP

535049

48

442726

Item

Avoid Thread Groups – flawed, obsolete conceptNever Invoke wait Outside a LoopSynchronized Invocation of Overridable Method

Unsynchronized Increment Operator on Static Variable – ++ operator is not atomic and must be synchronized when used in public methods on static variables

Improper Throws Declaration – never declare methods throws Exception or throws Throwable

Return Zero-Length Arrays and not nullSame Number Of Parameters Overload

Description

211ATG201NIWOL196SIOM

190UIOSV

181ITD134RZLA130SNOPO

PageAudit


AuditsSummary

Checks for conformance to standard or user-defined style, maintenance, and robustness guidelines

Evolve with language and best-practice revisions

Highly automatable- Allows for more time in code reviews to be spend on

business logic and design issues

Not well suited to human detection at scale

After the break… Metrics


MetricsQuantifying Source Code Characteristics

What are Software Metrics?– Measurements that allow for the analysis of software code

and design are formulated as metrics• Technically, a metric is a function with two arguments, while a

measure “is a numerical value for an attribute assessed for magnitude against an agreed scale” (Henderson-Sellers, 42).

– Merriam-Webster’s Collegiate Dictionary (10th Edition): “ a mathematical function that associates with each pair of elements of a set a

real nonnegative number with the general properties of distance such that the number is zero only if the two elements are identical, the number is the same regardless of the order in which the two elements are taken, and the number associated with one pair of elements plus that associated with one member of the pair and a third element is equal to or greater than the number associated with the other member of the pair and the third element ”


MetricsQuantifying Source Code Characteristics (continued)

Motivation– Improve the process of developing software– Identify potential defects through quantitative measures– Further understanding of software design complexity

Categories– Basic Counts– Cohesion– Coupling– Complexity– Encapsulation– Halstead’s– Inheritance– Polymorphism


MetricsInternal vs. External

Internal– Objective measures to assess internal characteristics– Typical Characteristics:

External– Stochastically based measures that in principle can assess

external characteristics– Typical Characteristics:

Does a link exist between Internal and External? [2] p40

Modular CohesionInter-module CouplingControl Flow ComplexitySize

QualityMaintainabilityTestabilityModifiabilityUnderstandabilityComplexity


MetricsA Disclaimer

“Beware! The domain of metrics is deep and muddy waters.” – Brian Henderson-Sellers

Metrics and their results are somewhat subjective

The Reflection API, class instantiation with Class.forName(“MyClass”).newInstance(), etc. present an obstacle for static analysis and reverse engineering tools

“… metrics will always be useful hints, but never firm certainties. A human mind will always be necessary to take the final decision…” – Radu Marinescu


MetricsKnowing What to Look for…

Reading– Software Metrics books– OO Design books– GoF’s Design Patterns

Mentors– Senior developers in your organization– Outside consultants

Experience– Takes time to develop breadth and depth– Firm grasp of object-oriented techniques

Tools…


Metrics Java™ Metrics in Together® ControlCenter™

4InheritanceFrom depth of hierarchy to attribute inheritance factor

9HalsteadFrom Halstead’s book Elements of Software Science

2EncapsulationAttribute and method hiding factor

7CouplingFrom fanout to Demeter’s law violations

6ComplexityFrom cyclomatic complexity to response for class

3CohesionThree flavors of lack of cohesion of methods

7BasicFrom lines of code to number of import statements

Qty


Metrics Java™ Metrics in Together® ControlCenter™

55Total Java™ Metrics:

1User InterfaceNumber of controls in a form

6RatioFrom comment ratio to percentage of scoped members

3PolymorphismAdded/overridden methods and polymorphism factor

3MaximumNumber of levels, parameters and size of operation

4Inheritance-Based CouplingTotal Reuse metrics for ancestors and descendants

Metrics can be collected on Audit violationsMetric results can be compared to previous metric resultsAdditionally, you can write your own custom Metrics!


MetricsA Sampling

Lack Of Cohesion Of MethodsLOCOM

Weighted Methods Per ClassWMPC

Cyclomatic ComplexityCC

Response For ClassRFC

Coupling Between ObjectsCBO

Number of Child ClassesNOCC

Depth Of Inheritance HierarchyDOIH


MetricsDepth Of Inheritance Hierarchy

The maximum length from the node to the root of the tree, measured by the number of ancestor classes.

- In general, as DOIH increases:Complexity increases

Behavior prediction difficulty increases

Fragility increases

Reuse potential increases


MetricsDepth Of Inheritance Hierarchy – An Example

DOIH = 1

DOIH = 2

DOIH = 3

DOIH = 4

DOIH = 5


MetricsNumber Of Child Classes

The number of subclasses of a class.

- In general, as NOCC increases:Likelihood of improper abstraction increases

Potential for subclassing misuse increases

Testing difficulty increases

Reuse potential increases

NOCC counts implemented interfaces


MetricsNumber Of Child Classes – An Example

NOCC = 7

NOCC = 6

NOCC = 0


MetricsCoupling Between Objects

The number of other classes to which a class is coupled.- In general, as CBO increases:

Modular design decreasesPotential reuse decreasesMaintenance difficulty increasesTesting difficulty increases

CBO does not take inheritance into accountPrimitive types and those in java.lang.* are ignored


MetricsCoupling Between Objects – An Example

import java.util.List;

import java.util.Map;

import java.io.File;

public class CBO extends Base implements Metric {

private int number;

private List list;

private String string;

public void one(List l, Map m) {

list = l;

}

private List two() throws AppException {

File file;

//...

return new List();

}

}

Couplings0010

10

11

0

Total: 4

Ignore

Ignore

Count

Ignore

Ignore,Count

Ignore

Ignore,Count

Count

Ignore


MetricsResponse For Class

The number of methods, internal and external, available to a class.– Let RS be the Response Set of the class– Let Mi = set of all methods in class– Let Ri = {Rij} = set of methods called by Mi

– Then,

– Alternatively,

Where NLM = number of local methods =And, NRM = number of remote methods =

}{ ijjalli RMRSRFC U==

NRMNLMRFC +=iM

∑n iR


MetricsResponse For Class – An Example

AAA NRMNLMRFC +=

6}6,5,4,3,2,1{ == ffffffNLM A

6}2.,1.,3.{

}1.{}3.,2.,1.{

==fCfCfB

fBfCfBfB

NRM A

U

U

1266 =+=ARFC


MetricsResponse For Class (continued)

- In general, as RFC increases:Testing difficulty increases

Debugging difficulty increases

Complexity of the class increases

RFC takes inherited methods into account, but does not count those overridden

RFC only goes one method call deep for remote methods


MetricsCyclomatic Complexity

Counts the number of possible paths through an algorithm by counting the number of distinct regions on a flowgraph, meaning the number of if, for and while statements in the operation's body.

– Let e be the number of edges, n be the number of nodes, and p be the number of components

– Then,

pneGVCC 2)( +−==


MetricsCyclomatic Complexity – An Example

public class CC {

public void one(){

if(true) {

while(false) {

two();

}

} else {

for(int i=0;i<10;i++) {

two();

}

}

}

public void two(){

}

}

pneGVCC 2)( +−==

4)1(2810)( =+−== GVCC

1)1(221)( =+−== GVCC

CC Total for Class: 5


MetricsCyclomatic Complexity (continued)

- In general, as CC increases:Testing difficulty increasesDebugging difficulty increasesOverall complexity of the class increases

CC does not count into called methodsMcCabe’s CC metric was not originally developed for the object-oriented paradigmThe value of CC for a method can be used as the basis for the minimum number of tests needed by the method


MetricsWeighted Methods Per Class

Provides the sum of the static complexities of all methods in a class.– Let n be the number of methods– Let c be a measure of a method’s complexity– Then,

Note that complexity is normally a measure of Cyclomatic Complexity (CC), but may also be taken as unity for each method.

∑=

=n

iic

1WMPC


MetricsWeighted Methods Per Class – An Example

public class WMPC {

public void one(){

if(true) {

two();

} else {

}

if(true && !false){

}

}

public void two(){

if(true){}

}

public void three(int i){}

}

cc3

2

16

mc1

1

24

6123WMPC11

=++==∑=

n

iicc

4211WMPC21

=++==∑=

n

iimc


MetricsWeighted Methods Per Class (continued)

- In general, as WMPC increases:Time and effort for development increases

Impact on children classes increases

Testing difficulty increases

Reuse of the class may decrease

WMPC does not include inherited methods.

WMPC includes getter, setter and private methods.

In TCC, WMPC1 sums the CC for each method, while WMPC2 sums the number of methods and parameters.


MetricsLack Of Cohesion Of Methods

Measures the dissimilarity of methods in a class by attributes.– Consider a set of methods {Mi} (i = 1, . . . , m)– Accessing a set of attributes {Aj} (j = 1, . . . , a)– Let α(Mi) = number of attributes accessed by each method Mi

– Let µ(Aj) = number of methods which access each datum– Then,

m

mAaLOCOM

a

ij

−

−

=∑

=

1

)(11

µ


MetricsLack Of Cohesion Of Methods – An Example

public class LOCOM {

int i1;

int i2;

int i3;

public void one(){

if(true) {

i1 = 0;

}

i2 = 0;

}

public void two(){

…

i3 = 0;

…

}

}

i1

i2

i3

a) {i1, i2} b) {i3}

LOCOM1 = 1LOCOM2 = 50LOCOM3 = 100No cohesion

[2] p144

a)

b)

( )1

21

211131

1

)(11 =

−

−

++

=−

−

=∑

=

m

mAaLOCOM

a

ijµ


MetricsLack Of Cohesion Of Methods – Another Example

public class LOCOM {

int i1;

int i2;

int i3;

public void one(){

if(true) {

i1 = 0;

}

i2 = 0;

}

public void two(){

…

i3 = 0;

i1 = 0;

i2 = 0;

…

}

}

i1

i2

i3

[2] p144

a) {i1, i2} b) {i1, i2, i3}

LOCOM1 = 0LOCOM2 = 17LOCOM3 = 34High cohesion

a)

b)

( )333.0

21

212231

1

)(11 =

−

−

++

=−

−

=∑

=

m

mAaLOCOM

a

ijµ


MetricsLack Of Cohesion Of Methods (continued)

- In general, as LOCOM increases:Class complexity increasesEncapsulation decreasesReuse potential decreases

In TCC, LOCOM has 3 flavors:LOCOM1 – Based on Chidamber & Kemerer 1994 (flawed)LOCOM2 – Better, zero value not ambiguousLOCOM3 – Henderson-Sellers 1995b

LOCOM3 = 0 with “perfect cohesion”LOCOM3 = 100 with each method accessing different attributes


MetricsInterpretation & Outcome

Visualizations:– Bar Graph– Kiviat Graph– Distribution Graph

Metrics Results Comparison

Metric-Driven Refactoring


MetricsVisualization – Bar Graph Upper Limit

Selected Metric Scope


MetricsVisualization – Kiviat Graph

Scaled Axis for Each Metric

Red Circle RepresentsUpper Limit


MetricsVisualization – Distribution Graph Upper Limit

X Axis isMetricValue

Y Axis is% of ElementsFound at/belowA Given Metric Value

Selected Metric

Scope


MetricsTrend Analysis

Increased

DecreasedComparison


MetricsCase StudiesPetStore 1.3 Ant 1.4.1


MetricsRules of Etiquette

Do:Understand and publish a metrics planProvide feedback to team regarding dataEnforce established standards and criteria

Don’t:Try to measure individualsPublish metric results on “wall of shame”Emphasize one metric to exclusion of othersLose sight of the goal: working software

[2] p210


MetricsSummary

Metrics are not a “silver bullet”

Metrics are improving, albeit slowly…

To benefit from metrics, you must understand:- object-oriented design concepts

- what metrics are measuring

- how to interpret the results

As with audits, automation is a key component

After the break… Refactoring


Refactoring“Improving the Design of Existing Code” [5]

What is Refactoring?– Martin Fowler defines refactoring as:

“…the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

– A frequent result of code reviews

Motivation– To improve design, understandability and code quality– To decrease the cost of maintenance


RefactoringCategories (from Martin Fowler’s book)

Composing Methods- Extract Method, Inline Method, etc.

Moving Features Between Objects- Move Method, Extract Class, etc.

Organizing Data- Encapsulate Field, Replace Subclass with Fields, etc.

Simplifying Conditional Expressions- Decompose Conditional, Remove Control Flag, etc.

Making Method Calls Simpler- Rename Method, Parameterize Method, etc.

Dealing with Generalization- Pull Up Field, Pull Up Method, Extract Interface, etc.

Big Refactorings- Tease Apart Inheritance, Extract Hierarchy, etc.


RefactoringSome Considerations

Metrics may help drive refactoring, but be careful they don’t have too great an impact

Audits & Metrics have best results with code that compiles

Always run JUnit tests before and after refactoring

Run Audits before Metrics

Rerun Audits/Metrics after Refactoring

Metric Violations Bad “smells” Design Patterns


RefactoringSome Considerations (continued)

Configure Metrics sets that are aimed at certain refactorings:– Extract Class

• CBO, NOIS, NOC, LOCOM3, FO, NOAM, LOC, NOA, NOO, NORM, HPLen

– Extract Subclass• NOA, NOM, NOO, RFC, WMPC1, NOAM, WMPC2, DAC,

FO, NOCC– Extract Method

• MSOO, NOCON, RFC, MNOL, CC, NORM, WMPC1, MNOP, WMPC2, CBO

– Extract Interface• NOOM

– Inheritance-Based Refactorings• DOIH, NOCC


RefactoringSome Considerations (continued)

Use Audits to target certain refactorings:– Reverse Conditional, Remove Double Negative

• NOIS (Negation Operator in ‘if’ Statement)– Encapsulate Field

• PPA (Public and Package Attribute)– Renaming

• NC (Naming Conventions – uses regex)

Run Audits before Metrics– UPCM and ULVFP before WMPC2, NOA etc.– ILC before NOIS

Format Code before Metrics, as may impact:- LOC (Lines Of Code) – consider using HPLen- (CR) Comment Ratio & (TCR) True Comment Ratio


RefactoringDemonstrated Example – Tomcat 4.0.3


Code ReviewsRethought

“The detection of design problems for large or very large systems is impossible to be fulfilled manually and must therefore be accomplished by automated methods.” [7]

Automate as much as possible using available tools

Utilize tools with projectors, rather than printouts

Perform “live” metric-driven refactorings during code reviews

Don’t lose focus of the business logic


Code ReviewsRethought (continued)

Don’t wait until a formal code review to run audits and metrics

– Run them frequently, in order to:

minimize the time spent in code reviews

increase the capabilities of your team

– Run with nightly build

– Run after unit tests

Maintain Audit/Metric results for later data analysis


Open Discussion

Your current code/design review process…

How well do automated audits/metrics work with “traditional” methodologies?

How well do automated audits/metrics work with agile methodologies?

Ideas for new audits/metrics?

Can Kiviat shapes be cataloged?

Static source code analysis versus runtime profiling…


References[1] Joshua Bloch, Effective Java™: Program Language Guide.

Addison-Wesley, 2001.[2] Brian Henderson-Sellers, Object-Oriented Metrics: Measures of

Complexity. Prentice Hall, 1995.[3] Shyam R. Chidamber and Chris F. Kemerer, A Metrics Suite for

Object Oriented Design. IEEE Transactions on Software Engineering, Vol. 20 Number 6, pp476-493,1994.

[4] Martin Fowler, Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.

[5] Kent Beck, extreme Programming explained: Embrace Change. Addison-Wesley, 2000.

[6] Joshua Kerievsky, Refactoring to Patterns. Industrial Logic, Inc., version 0.14, 2002. http://industriallogic.com/papers/rtp014.pdf

[7] Radu Marinescu, Using Object-Oriented Metrics for Automatic Design Flaws Detection in Large Scale Systems. “Politehnica”University in Timisoara, ECOOP Workshop 1998: 252-255.


References[8] Shuqin Li-Kokko, Code and Design Metrics for Object-Oriented

Systems. Helsinki University of Technology, 2000.[9] R. Grady, Software Metrics Etiquette. Cutter Information Corp.,

publishers of American Programmer, 6(2), 6-15.[10] C.L. Jones, “A Process-Integrated Approach to Defect

Prevention”. IBM Systems Journal, 24(2):150-167 (1985).[11] T. Gilb and D. Graham, Software Inspection. Reading, MA:

Addison-Wesley Publishing Co., 1993.[12] A. Carmichael and D. Haywood, Better Software Faster. Upper

Saddle River, NJ: Prentice Hall PTR, 2002.[13] Gary Gack, “The Value of Software Inspections: a case study”,

IT Effectiveness, Inc., 2002. http://www.iteffectiveness.com/valusoftinspect.htm

software remodeling - intertech · 2004-04-23 · ©togethersoft™ corporation 2002 improving the...

Documents