Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

Practical Challenges in Object-OrientedDependence Analysis

Neil Walkinshaw

Department of Computer ScienceUniversity of Leicester

Slicing COW, January, 2011

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

INTRODUCTION

ContextI OO paradigm is the de-facto choice for software

developmentI Subject to several factors that hamper dependence analysis

Aim of the talkI To show problems that arise with static analysis of OO

codeI From the perspective of my thesis work

I Develop a source code reading toolI Purpose: To navigate the source code related to a given

system-level feature

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

TO BEAR IN MIND...

I Thesis work carried out 2002-2005I Some opinions could be out of date

I Have tried to link relevant slides to discussion onfunctional slicing

I Relevant slides marked

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

THE CHALLENGE OF OO FEATURE IDENTIFICATION

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

THE CHALLENGE OF OO FEATURE IDENTIFICATION

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

THE CHALLENGE OF OO FEATURE IDENTIFICATION

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

THE CHALLENGE OF OO FEATURE IDENTIFICATION

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

THESIS IDEA

Use static code analysis, with limited input fromdeveloper

I Combine slicing, call graph analysis and developer inputI Should identify relevant methods and method callsI Integrate into a code-reading interface

OutcomeI Possible to produce an accurate result

I ... but only with large amount of help from the developer

I Problem massively exacerbated as scale increased

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

THESIS IDEA

Use static code analysis, with limited input fromdeveloper

I Combine slicing, call graph analysis and developer inputI Should identify relevant methods and method callsI Integrate into a code-reading interface

OutcomeI Possible to produce an accurate result

I ... but only with large amount of help from the developer

I Problem massively exacerbated as scale increased

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

OO STATIC ANALYSIS CHALLENGES

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Polymorphism and Dynamic Binding

I Type of an object is defined by the interface it providesI Implementations for methods declared in hierarchyI Methods bound to their implementations at runtime

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Polymorphism and Dynamic Binding

I Type of an object is defined by the interface it providesI Implementations for methods declared in hierarchyI Methods bound to their implementations at runtime

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Polymorphism and Dynamic Binding

I Type of an object is defined by the interface it providesI Implementations for methods declared in hierarchyI Methods bound to their implementations at runtime

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Polymorphism and Dynamic Binding

I Type of an object is defined by the interface it providesI Implementations for methods declared in hierarchyI Methods bound to their implementations at runtime

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Polymorphism and Dynamic Binding

I Type of an object is defined by the interface it providesI Implementations for methods declared in hierarchyI Methods bound to their implementations at runtime

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Data dependence computation relies on inter-proceduralanalysis

I A def or a use of a variable candepend on the called method

I Does call to an objectmethod mutate or access it?

I If passed as an argument, isit accessed or mutated?

I Demands inter-proceduralanalysis

I Erroneous pointers canresult in def-use errors

I Static analysis forced toinclude library methods

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Object associations

I Objects do not occur in isolated hierarchiesI Objects can contain other objects belonging to different

hierarchies

I The possible types of the associated objects (and theirobjects) have to be accounted for

I Dependence analysis needs to account for every possiblecombination of types

I Parameter trees

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Figure

Circle Rectangle

Square

FigureConnector

Figure: fromFigure: to

BezierConnector

Point[]: points

calculateDistance

calculateDistance

printDistance(FigureConnector fc){ double distance = fc.calculateDistance() System.out.println(distance);}

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

PROBLEMS POSED BY OO MECHANISMS

Figure

Circle Rectangle

Square

FigureConnector

BezierConnector

Figure

Circle Rectangle

Square

Figure

Circle Rectangle

Square

Figure

Circle Rectangle

Square

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

DELOCALISED DESIGN

Dependencies are heavily delocalised

I Classes of objects represent units that are conceptuallyaligned with problem domain

I Dependencies tend to span the systemI Some evidence that OO dependencies obey principles of

small-world networksI ”Software systems as complex networks...”, C. Myers, 2003

I ”Distribute system intelligence horizontally as uniformly as possible, that is,the top level classes in a design should share the work uniformly.” [Riel, OOdesign heuristics, Addison Wesley 2002]

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

DELOCALISED DESIGN

Dependencies are heavily delocalised

I Classes of objects represent units that are conceptuallyaligned with problem domain

I Dependencies tend to span the systemI Some evidence that OO dependencies obey principles of

small-world networksI ”Software systems as complex networks...”, C. Myers, 2003

I ”Distribute system intelligence horizontally as uniformly as possible, that is,the top level classes in a design should share the work uniformly.” [Riel, OOdesign heuristics, Addison Wesley 2002]

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

DELOCALISED DESIGN

Dependencies are heavily delocalised

I Classes of objects represent units that are conceptuallyaligned with problem domain

I Dependencies tend to span the systemI Some evidence that OO dependencies obey principles of

small-world networksI ”Software systems as complex networks...”, C. Myers, 2003

I ”Distribute system intelligence horizontally as uniformly as possible, that is,the top level classes in a design should share the work uniformly.” [Riel, OOdesign heuristics, Addison Wesley 2002]

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SCALE

Good OO design fosters fragmentation

I Large classes and long methods are “code smells”I Small classes and methods facilitate reuse and program

understandingI Remedy: Break the system up into smaller classes, with

smaller methods

Results in a problem of scaleI Dependence graph size for procedural programs is more

or less linearI This is certainly not the case for object-oriented programs:

I More classes and methods with their respective parametervertices

I Many polymorphic calls (with parameter edges)

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SCALE

Good OO design fosters fragmentation

I Large classes and long methods are “code smells”I Small classes and methods facilitate reuse and program

understandingI Remedy: Break the system up into smaller classes, with

smaller methods

Results in a problem of scaleI Dependence graph size for procedural programs is more

or less linearI This is certainly not the case for object-oriented programs:

I More classes and methods with their respective parametervertices

I Many polymorphic calls (with parameter edges)

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SCALEAppendix C: Entire JSysDG for Example CodeThis page is best viewed in colour (A colour image can be downloaded from:http://www.cs.strath.ac.uk/~nw/documents.html).

CE1

F15_outF15_in S42

E41

S36

E35

S34S33

E32

S31S30

E29

S28

C27C26

E25

S18(b)

S18(a)

CE17

F13_out

F8_in F9_in

F10_in F11_in F11_out

A10_in A11_in A11_out A12_in

F12_in F12_out

A12_out

IE43

S49S48

E47

F4_in F5_in F4_out F5_outC52S51

E50

F5_inF4_in F6_in F7_in F4_out F5_out

A8_in A9_in A9_out

C24S23F5_inF4_in F6_in F7_in F4_out F5_out

A8_in A9_in A9_out

A3_outA2_out

F1_in E2

S3

C5 C6 C7

S4

A2_in A3_in A6_in A7_in

C11

A13_out

S10(a)C8C9

F16_in

E56

F17_in

S57 S58

F17_out

E22

S21S20

E19

F4_in F5_in F4_out F5_out

S38 F9_out

F14_outF14_in S40

E39

F8_in

E53

F9_in

S54 S55

F9_out

AdvancedCalc

a b

AdvancedCalcSimpleCalc

a b a b

e

E44 E45

CE46

F8_in F9_in

e

ba

e

AdvancedCalc

a b a b e

AdvancedCalcSimpleCalc

a b a b

e

ba

E15

A14_out

a b

e

SimpleCalc

S12

S12(a)

e

SimpleCalc.multiply

6 20

AdvancedCalc.multiply

6 20

a b

S16

C16(a)

AdvancedCalc.multiply

S10

C14(a)

E13

S14

C14(b)

A15_in A15_outA14_in A14_out

S37

Vertices marked by the first phase of the slice are shown in blue (darker shade) and those marked by the second phase areshown in pink (lighter shade). A backwards-slice is demonstrated, taken from vertex S25 (return divided).

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SUMMARY

I Conspiracy of three problems:1. Accurate prediction of runtime dependencies from code is

impossible2. Dependencies tend to cut across the system3. Granular decomposition causes scalability problems

I Each ill-computed dependency will significantly amplifyproblems 2 and 3

I The better designed a system is, the worse these problemsbecome

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SUMMARY

“The problem with object-oriented languages is they’ve gotall this implicit environment that they carry around withthem. You wanted a banana but what you got was a gorillaholding the banana and the entire jungle.”

– Joe Armstrong

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

CONCLUSIONS

I Accuracy of dependence analysis intricately tied toaccuracy of underlying analyses

I Results tend to be grossly inaccurateI Cannot be ignored when interpreting OO dependence

analysis resultsI Slices can easily become misleadingI Implications for comprehension tasksI Implications for slice-based metrics?

I Demands new OO dependence analysis techniquesI Or at least new ways to interpret their results

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SEVERAL OF POTENTIAL SOLUTIONS

I Associate confidence measure with each dependence?I Incorporate dynamic analysis - trace / profiling

informationI Can use test-set executions

I Incorporate infrastructures of code-based model-checkingplatforms

I Exploit symbolic reasoning capacities of model-checkingplatforms such as JPF, Bandera etc.

I These enable the incorporation of invariants, behaviouralmodels etc. into the analysis

I Use their ability to provide abstract models of irrelevantclasses

Introduction Work on OO Feature Identification Problems of OO Software Analysis Conclusions

SEVERAL OF POTENTIAL SOLUTIONS

I Associate confidence measure with each dependence?I Incorporate dynamic analysis - trace / profiling

informationI Can use test-set executions

I Incorporate infrastructures of code-based model-checkingplatforms

I Exploit symbolic reasoning capacities of model-checkingplatforms such as JPF, Bandera etc.

I These enable the incorporation of invariants, behaviouralmodels etc. into the analysis

I Use their ability to provide abstract models of irrelevantclasses