M cCa - people.cs.aau.dkpeople.cs.aau.dk/~ivan/SOE2005F/SOEmm10.pdf · Bad smells in code! Feature envy! A method seems more interested in another class than the one itÕs defined

McCa!"s Triangle of Quality

Maintainability

Flexibility

Testability

Portability

Reusability

Interoperability

Correctness

Reliability

Efficiency

Integrity

Usability

PRODUCT TRANSITIONPRODUCT REVISION

PRODUCT OPERATION

Internal and external attributes

Reliability

Number of procedureparameters

Cyclomatic complexity

Program size in linesof code

Number of errormessages

Length of user manual

Maintainability

Usability

Portability

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5

Measures, Metrics and Indicators

! A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process

! The IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”

! An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself


Measurement Process

! Formulation. The derivation of software measures and metrics

appropriate for the representation of the software that is being

considered.

! Collection. The mechanism used to accumulate data required to derive

the formulated metrics.

! Analysis. The computation of metrics and the application of

mathematical tools.

! Interpretation. The evaluation of metrics results in an effort to gain

insight into the quality of the representation.

! Feedback. Recommendations derived from the interpretation of product

metrics transmitted to the software team.


Goal-Oriented Software Measurement! The Goa!Question/Metric Paradigm

! (1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed

! (2) define a set of questions that must be answered in order to achieve the goal, and

! (3) identify well-formulated metrics that help to answer these questions.

! Goal definition template

! Analyze {the name of activity or attribute to be measured}

! for the purpose of {the overall objective of the analysis}

! with respect to {the aspect of the activity or attribute that is considered}

! from the viewpoint of {the people who have an interest in the measurement}

! in the context of {the environment in which the measurement takes place}.


Metrics Attributes! simple and computable. It should be relatively easy to learn how to derive the

metric, and its computation should not demand inordinate effort or time

! empirically and intuitively persuasive. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration

! consistent and objective. The metric should always yield results that are unambiguous.

! consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of units.

! programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself.

! an effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product


Collection and Analysis Principles

! Whenever possible, data collection and analysis should be automated;

! Valid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristics

! Interpretative guidelines and recommendations should be established for each metric


Analysis Metrics

! Function-based metrics: use the function point as a normalizing factor or as a measure of the “size” of the specification

! Specification metrics: used as an indication of quality by measuring number of requirements by type


Function-Based Metrics

! The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system.

! Function points are derived using an empirical relationship based on countable (direct) measures of software’s information domain and assessments of software complexity

! Information domain values are defined in the following manner:

! number of external inputs (EIs)

! number of external outputs (EOs)

! number of external inquiries (EQs)

! number of internal logical files (ILFs)

! Number of external interface files (EIFs)


Function Points

Information

Domain Value Count simple average complex

Weighting factor

External Inputs (EIs)

External Outputs (EOs)

External Inquiries (EQs)

Internal Logical Files (ILFs)

External Interface Files (EIFs)

3 4 6

4 5 7

3 4 6

7 10 15

5 7 10

=

=

=

=

=

Count total

3

3

3

3

3

14

What it Refactoring?

Refactoring is a disciplined process of changing a software system in such a way that it does not alter the external behavior of the code while at the same time improves its internal structure.

15

Refactoring

Martin Fowler (and Kent Beck, John Brant, William Opdyke, Don Roberts), Refactoring- Improving the Design of Existing Code, Addison Wesley, 1999.

Refactoring (noun):

• a change made to the internal structure of software to make it easier to understand and

• cheaper to modify without changing its observable behavior.

Refactor (verb):

• to restructure software by applying a series of refactorings.

16

Why should refactoring be done? Argument 1

Refactoring Improves the Design of Software. - Without refactoring, the design of the program will decay. As people change code - changes to realize short-term goals or changes made without a full comprehension of the design of the code - the code loses its structure.

17

When should refactoring be done? Argument 2

Refactoring makes software easier to understand. - There are users of your code. The computer, the writer, and the updater. The most important is the updater. Who cares if the compiler takes a few more cycles to compile your code. If it takes someone 3 weeks to update your code that is a problem.

18

Who should be doing refactoring? Argument 3

Refactoring helps you find bugs. - Part of refactoring code is understanding the code and putting that understanding back into the code. In that process a clarification takes place. In that clarification bugs will be found.

19

Who should be doing refactoring? Argument 4

Refactoring Helps you Program Faster. - Without a good design, you can progress quickly for a while, but soon poor design start to slow you down. You spend time finding and fixing bugs and understanding the system instead of adding new function. New features need more coding as you patch over patches..

20

Bad smells.

! Knowing how to refactor something does not tell you when to refactor and how much to refactor.

! Kent Beck and Martin Fowler coined a phrase ‘Bad Smells’ to describe the hint of when to refactor.

! This phrase was meant to reflect the ability and experience gained over time by a programmer that is needed to

recognize bad coding structure.

21

Bad Smell Examples

! Duplicate Code

! Long Methods

! Large Classes

! Long Parameter Lists

! Feature Envy

! Data Clumps

! Primitive Obsession

22

Bad smells in code

! Duplicated code! “The #1 bad smell”

! Same expression in two methods in the same class?

! Make it a private ancillary routine and parameterize it - gather duplicated code

! (Extract method)

! Same code in two related classes?! Push commonalities into closest mutual ancestor

and parameterize

! Use template method DP for variation in subtasks - gather similar parts, leaving holes

! (Form template method)

23

Bad smells in code

Duplicated code

• Same code in two unrelated classes?• Ought they be related?

• Introduce abstract parent (Extract class, Pull up method)

• Does the code really belongs to just one class?• Make the other class into a client (Extract method)

24

Bad smells in code

! Long method! Often a sign of:

! Trying to do too many things! Poorly thought out abstractions and boundaries

! Best to think carefully about the major tasks and how they inter-relate.

! Break up into smaller private methods within the class

! (Extract method)

! Delegate subtasks to subobjects that “know best” (i.e., template method DP)

! (Extract class/method, Replace data value with object)

25

Bad smells in code

Long method - Fowler’s heuristic:

• When you see a comment, make a method.

• Often, a comment indicates:• The next major step

• Something non-obvious whose details detract from the clarity of the routine as a whole.

• In either case, this is a good spot to “break it up”.

26

Bad smells in code

! Feature envy! A method seems more interested in another

class than the one it’s defined in! e.g., a method A::m() calls lots of get/set methods

of class B

! Solution:! Move m() (or part of it) into B!

(Move method/field, extract method)

! Exceptions:! Visitor/iterator/strategy DP where the whole point

is to decouple the data from the algorithm! Feature envy is more of an issue when both A and B

have interesting data

27

Why not refactor?

Conventional wisdom would discouragemodifying a design

• You might break something in the code

• You have to update the documentation

• Both expensive

But, there are longer term concerns: sticking with an inappropriate design

• Makes the code harder to change

• Makes the code harder to understand and maintain

• Very expensive in the long run

28

Refactoring Philosophy

Make all changes small and methodical

• Follow design patterns

Retest the system after each change

• By rerunning all of your unit tests

• If something breaks, it’s easy to see what caused the failure

29

Principles of Refactoring

In general, each refactoring aims to

• decompose large objects into smaller ones

• distribute responsibility

Like design patterns

• Adds composition and delegation

• In some sense, refactorings are ways of applying design patterns to existing code

30

Obstacles to Refactoring

Complexity

Changing design is hard, understanding code is hard

Possibility to introduce errors

Mitigated by testing

Clean first Then add new functionality

Cultural Issues

Producing negative lines of code, what an idea!

We pay you to add new features, not to improve the code!

If it ain t broke, don’t fix it

We do not have a problem, this is our software!

31

RefactorIT - www.refactorit.com

! Rename Renames a method, field, type,

package or prefix. Updates all references.

! Move Class Moves a class or interface into

another package.

! Encapsulate Field Replaces direct field usage

with corresponding accessor methods.

! Extract Method Analyzes the selected piece of

code and extracts it into a separate method.

! Extract Superclass/Interface Extracts

selected methods and fields into new superclass

or interface.

Documents

M cCa - people.cs.aau.dkpeople.cs.aau.dk/~ivan/SOE2005F/SOEmm10.pdf · Bad smells in code! Feature envy! A method seems more interested in another class than the one itÕs defined