1 / 29

Quality analysis of industrial systems. LaQuSo experience Serguei Roubtsov

Quality analysis of industrial systems. LaQuSo experience Serguei Roubtsov. LaQuSo: Laboratory for Quality Software. 9 employees + master students and students-assistants (HG 5.91) industrial projects research projects own research in software quality assessment and tooling.

grover
Download Presentation

Quality analysis of industrial systems. LaQuSo experience Serguei Roubtsov

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quality analysis of industrial systems.LaQuSo experienceSerguei Roubtsov

  2. LaQuSo: Laboratory for Quality Software • 9 employees + master students and students-assistants (HG 5.91) • industrial projects • research projects • own research in software quality assessment and tooling / LaQuSo / Mathematics & Computer Science

  3. Analysis approach Focus on maintainability: • Static code analysis, architecture assessment, code reviews, tooling • Based on quantifiable measures: software metrics • Provides an answer to an analysis question; for this purpose metrics: • should reflect quality criteria, thresholds • Visualisation / LaQuSo / Mathematics & Computer Science

  4. What code is hard to maintain? • Hard to understand • not documented • cluttered or inconsistently used/developed • too large • Difficult to modify • duplicated • intertwined • non-extendable • non-portable • Difficult to test / analyse • too complex / LaQuSo / Mathematics & Computer Science

  5. What to analyze? • Architecture: • dependencies (layering) • dependency cycles • code external duplication • dead code • system documentation • Code base: • code size and complexity • duplication metrics • potential bugs • documentation • adherence to standards / LaQuSo / Mathematics & Computer Science

  6. Our Tooling SQuAVisiT Software Quality Analysis and Visualisation Toolset Name, Class Count, Abstract Class Count, Ca, Ce, A, I, D, V: bsh,0,0,1,0,0,0,1,1 com.caucho.burlap.client,0,0,1,0,0,0,1,1 com.caucho.burlap.io,0,0,1,0,0,0,1,1 com.caucho.burlap.server,0,0,1,0,0,0,1,1 com.caucho.hessian.client,0,0,1,0,0,0,1,1 com.caucho.hessian.io,0,0,1,0,0,0,1,1 com.caucho.hessian.server,0,0,1,0,0,0,1,1 com.ibatis.common.util,0,0,1,0,0,0,1,1 oracle.toplink.essentials.sessions,0,0,1,0,0,0,1,1 oracle.toplink.exceptions,0,0,2,0,0,0,1,1 oracle.toplink.expressions,0,0,1,0,0,0,1,1 oracle.toplink.internal.databaseaccess,0,0,1,0,0,0,1,1 oracle.toplink.jndi,0,0,1,0,0,0,1,1 oracle.toplink.logging,0,0,1,0,0,0,1,1 oracle.toplink.publicinterface,0,0,2,0,0,0,1,1 oracle.toplink.queryframework,0,0,1,0,0,0,1,1 oracle.toplink.sessionbroker,0,0,1,0,0,0,1,1 oracle.toplink.sessions,0,0,2,0,0,0,1,1 oracle.toplink.threetier,0,0,1,0,0,0,1,1 oracle.toplink.tools.sessionconfiguration,0,0,1,0,0,0,1,1 oracle.toplink.tools.sessionmanagement,0,0,1,0,0,0,1,1 org.aopalliance.aop,0,0,9,0,0,0,1,1 org.aopalliance.intercept,0,0,24,0,0,0,1,1 org.apache.axis.encoding.ser,0,0,1,0,0,0,1,1 org.apache.catalina.loader,0,0,1,0,0,0,1,1 org.aspectj.weaver,0,0,2,0,0,0,1,1 org.aspectj.weaver.ast,0,0,1,0,0,0,1,1 org.aspectj.weaver.bcel,0,0,1,0,0,0,1,1 org.aspectj.weaver.internal.tools,0,0,1,0,0,0,1,1 org.aspectj.weaver.loadtime,0,0,1,0,0,0,1,1 org.quartz.spi,0,0,1,0,0,0,1,1 org.quartz.utils,0,0,1,0,0,0,1,1 org.quartz.xml,0,0,1,0,0,0,1,1 org.springframework.aop,24,20,17,6,0,83,0,26,0,09,1 org.springframework.aop.aspectj,39,7,3,24,0,18,0,89,0,07,1 org.springframework.aop.aspectj.annotation,27,3,0,19,0,11,1,0,11,1 org.springframework.aop.aspectj.autoproxy,3,0,1,8,0,0,89,0,11,1 org.springframework.aop.config,17,3,1,15,0,18,0,94,0,11,1 org.springframework.aop.framework,37,9,22,18,0,24,0,45,0,31,1 org.springframework.jdbc.core,53,20,6,20,0,38,0,77,0,15,1 org.springframework.jdbc.core.metadata,22,2,1,10,0,09,0,91,0,1 org.springframework.jdbc.core.namedparam,10,4,3,12,0,4,0,8,0,2,1 org.springframework.jdbc.core.simple,17,6,0,12,0,35,1,0,35,1 org.springframework.jdbc.core.support,8,5,2,14,0,62,0,88,0,5,1 org.springframework.jdbc.datasource,27,7,13,14,0,26,0,52,0,22,1 org.springframework.jdbc.datasource.lookup,8,2,2,13,0,25,0,87,0,12,1 org.springframework.jdbc.object,14,8,0,12,0,57,1,0,57,1 org.springframework.jdbc.support,15,5,12,16,0,33,0,57,0,1,1 org.springframework.jdbc.support.incrementer,15,4,0,8,0,27,1,0,27,1 org.springframework.jdbc.support.lob,18,5,5,12,0,28,0,71,0,02,1 org.springframework.jdbc.support.nativejdbc,10,2,2,7,0,2,0,78,0,02,1 org.springframework.jdbc.support.rowset,4,2,2,6,0,5,0,75,0,25,1 org.springframework.jdbc.support.xml,7,6,0,7,0,86,1,0,86,1 org.springframework.web.servlet.view.xslt,4,2,0,17,0,5,1,0,5,1 org.springframework.web.struts,16,5,0,22,0,31,1,0,31,1 org.springframework.web.util,24,6,26,15,0,25,0,37,0,38,1 org.w3c.dom,0,0,12,0,0,0,1,1 org.xml.sax,0,0,3,0,0,0,1,1 (2) AV Repository (1) (3) (4) / LaQuSo / Mathematics & Computer Science

  7. SQuAVisiT • Flexible • Plug-in architecture • Languages • C, Cobol, Java, JavaScript, PL/SQL, Delphi, C# • Analysis tools (third party and our own) • dependency extractors, duplication detectors, error detectors, metrics calculators, parsers, code style checkers • Visualization tools • MetricsView, GraphViz, ExTraVis , MatrixZoom, SolidSX, visualization modules of third-party tools / LaQuSo / Mathematics & Computer Science

  8. Real life industrial systems They are often: • Heterogeneous (C/Assembler, Cobol/PL SQL, Java/Object mapping to SQL…) • Incomplete (some code is in libraries and third-party components) • Not compilable and executable within analysis environment ( ‘weird’ OS, proprietary development environment, …) / LaQuSo / Mathematics & Computer Science

  9. Expert system Industrial case: Insurance company’s expert system • What kind of system do we have? • Heterogeneous: JavaScript, PL/SQL, C++, Java, Cobol • Medium size: 300 KLOC • 15 years old • Scarce documentation • Oracle DB • Problem reported • Maintenance (dis)continuation decision / LaQuSo / Mathematics & Computer Science

  10. Dependencies Model: Matrix View Data layer • (Almost) layered: good design • BUT data layer is accessed from several layers • Layers affected by calls from top layer are visible (red squares) / LaQuSo / Mathematics & Computer Science

  11. Dependencies Model: Extravis • Green ‘bubbles’: controversial coding approach • Parameters as names f(1,3) -> f_1_3 • Absence of dedicated data access layer is confirmed / LaQuSo / Mathematics & Computer Science

  12. Code duplication • Code is polluted with duplication: restructuring would improve maintainability but may change the architecture CCFinder/Gemini (Toshihiro Kamiya) / LaQuSo / Mathematics & Computer Science

  13. Summary • Layered architecture • System is well-structured but • JavaScript + two-tier architecture could cause serious maintenance problems in the future • Code polluted by duplication • Low impact if no major changes are expected • Analysis advice: • Short term • Refactor and maintain for limited amount of time (3-5 years) • Develop overview documentation • Long term • Migrate to three-tier architecture / LaQuSo / Mathematics & Computer Science

  14. Industrial case: Embedded System • What kind of code do we have? • Component system with compile-time binding via make files • C with embedded Assembler • Complete • Medium size: 150 KLOC • Developer’s assumption • Layered architecture • Problems reported • Extensive change. Is architectural purity still preserved? / LaQuSo / Mathematics & Computer Science

  15. Dependencies Structure • system is poorly layered • unexpected cyclic dependencies exist between components / LaQuSo / Mathematics & Computer Science

  16. Summary • Layered architecture • System is poorly-structured (indications of decay) but • Code is of good quality, well documented • The system is NOT large or complex • Analysis advice: • Reengineer affected parts according to the presumed layered architecture / LaQuSo / Mathematics & Computer Science

  17. Industrial case: Pension fund • What kind of system do we have? • Homogeneous: Cobol • Large: 1.7 MLOC • 17 years old • Oracle DB • Problem reported • Need to migrate due to discontinuation of support / LaQuSo / Mathematics & Computer Science

  18. Dead code? • “Empty spaces” in the visualization • 1216 modules not called by other modules • Dead code? • Other (sub)systems? • 651 are dead • Confirmed by the developers / LaQuSo / Mathematics & Computer Science

  19. Results of Analysis: effort Halstead metrics Time to understand (T) is proportional to Halstead Effort: T = E / 18 /3600 Time to understand, hours / LaQuSo / Mathematics & Computer Science

  20. Summary • Architecture • System structure is preserved but intertwined in some places • Dead code is widely spread • Code is polluted by duplication but • Percentage of weak (large, complex) parts is low • Analysis advice: • Short term: • Refactor weak parts, eliminate dead code and maintain for limited amount of time • Long term: • Redevelop on a modern platform / LaQuSo / Mathematics & Computer Science

  21. Expert system Industrial case: Insurance company’s front-end • What kind of system do we have? • Technical data • Homogeneous: Java • Large: 750 KLOC • Oracle DB • J2EE application (Spring Framework, Hibernate) • Recently developed by a third party • No documentation • Problem reported • Purchase decision / LaQuSo / Mathematics & Computer Science

  22. Code not available? What can we do? Customer SQuAVisiT • Install locally. • Perform measurements. • Tune results • Analyse, interpret. report / LaQuSo / Mathematics & Computer Science

  23. Understandability: Documentation • Comments percentage (LOCs counter tool) • Average: 43% • Ranging from 0% to 1500%. Why? • large repeated header blocks of comments • commented out code • Javadoc (CheckStyle tool) • 85260 violations • Missing or malformed declarations • Documentation generation is impossible, or • Documentation quality is compromised • Documentation quality should be reassessed! / LaQuSo / Mathematics & Computer Science

  24. Dn – Distance from the main sequence Abstractness = #AbstrClasses/#Classes 1 zone of uselessness main sequence Instability = #Out/(#Out+#In) zone of pain 0 1 Dn = | Abstractness + Instability – 1 | [R.Martin 1994] /LaQuSo SET / W&I

  25. Average Dn 1.00 Benchmarksopen source our System 0.186 0.00 /LaQuSo SET / W&I

  26. What about distributions? % of packages beyond threshold an average open source system our System Dn threshold value /LaQuSo SET / W&I

  27. What have we seen? • Architecture is good • Documentation should be reassessed / LaQuSo / Mathematics & Computer Science

  28. Conclusions • Approach comprising analysis and visualization • Supported by SQuAVisiT, a flexible tool allowing • To address different maintainability aspects • To combine different analysis and visualization techniques • Confirmed by analysis of several middle-size to large systems (150 KLOC – 1.7 MLOC) / LaQuSo / Mathematics & Computer Science

  29. Future Work (Your?) • Flexible SQuAVisiT data structure: How to store data (dependencies, metrics) about historically and hierarchically different software artifacts? • (Fully-featured) parsers/fact extractors for C++, C#, Delphi,… • Improved dependency analysis: Analysis of dynamic bindings, injected dependencies, dependencies via global and static variables,… • More metrics to retrieve: e.g. Dn-based analysis for different languages, analysis/benchmarking of distributions of different metrics / LaQuSo / Mathematics & Computer Science

More Related