INGI2252Measures &
MaintenanceAn excerpt of some final presentations
by Prof. Kim Mens
partly based on a presentation by R. Capron & R. Wallez, Dec. 2012
Concept of the Course« Software Measures and Maintenance »
• Two interleaved parts• Software development and maintenance
• Software measures and metrics
• Main objective• How to develop « better » and more « maintainable » software systems?
• and object-oriented software in particular
• How to assess the quality of a software system?
• and its maintainability in particular
• Side objective• Learn yet a new programming language (Smalltalk)
Techniques and tools« Software Measures and Maintenance »
• “Pure” object-oriented programming
• Integrated development environments
• Best programming practices & design heuristics
• Framework development
• Refactoring & bad smells
• Unit testing
• Software metrics and measures
• And a whole bunch of software analysis tools
Course assignment« Software Measures and Maintenance »
• No traditional exam
• Instead, analyze quality (maintainability) of an existing software systemwith techniques and tools seen in the course
• Part 1 : Manual code assessment
• Based on good practices, conventions, heuristics, design principles and patterns
• Part 2 : Automated analysis
• Using software metrics, visualisation and code querying tools like MOOSE, Mondrian, SOUL, ...
• Present overall results of the analysis to a « client »
Global view of the analyzed systemUsing the « System Complexity » visualization
NOP : Number of PackagesNOC : Number of ClassesNOM : Number of MethodsLOC : Lines of CodeCYCLO : McCabe’s Cyclomatic complexity number
ANDC : Average Number of Derived ClassesAHH : Average Hierarchy HeightCALLS : Number of Distinct Method InvocationsFANOUT : Number of Called Classes
Summary of the system’s measures
Using the « Overview Pyramid »
Critical evaluation ofthresholds used
Compare predefined thresholds
(good, bad, average) used by
the tool with :
• The system being analyzed
• Some “good” reference
systems
Collection hierarchy
Pharo Kernel
Evolution of a metricin terms of the chosen threshold
Detailed analysis of FANOUT metric
per class of the analyzed system
Number of Comments
Number of Public Methods
9
Illustration of the lack of comments
Absence of accessors and mutators
Using the « Class Blueprint »
After adding accessors and mutators
Using the « Class Blueprint »
Number of statements vs. lines of code
Using a Mondrian « Scatter Plot »
Detection of code duplicationUsing the « Side-by-side Code Duplication »
tool
Discovering dependenciesbetween packages
Using the« Dependency Structure Matrix »
