TMPA-2017: Stemming Architectural Decay in Software Systems

TMPA-2017: Tools and Methods of Program Analysis
3-4 March, 2017, Hotel Holiday Inn Moscow Vinogradovo, Moscow

Stemming Architectural Decay in Software Systems
Nenad Medvidovic (Professor, USA University of Southern California, ACM SIGSOFT Executive Committee Chair)

For video follow the link: https://youtu.be/D7ZVSifyJoA
Would like to know more?
Visit our website:
www.tmpaconf.org
www.exactprosystems.com/events/tmpa

Follow us:
https://www.linkedin.com/company/exactpro-systems-llc?trk=biz-companies-cym
https://twitter.com/exactpro

Transcript

1. Stemming Architectural Decay in Software Systems Nenad Medvidović Computer Science Department Viterbi School of Engineering University of Southern California Los Angeles, CA, USA neno@usc.edu http://csse.usc.edu/~neno/
2. Part I Software Architectures Real and Imagined
3. A Bit of Terminology • A software system’s architecture is the set of principal design decisions about the system – Software architecture is the blueprint for a software system’s construction and evolution • Design decisions encompass every facet of the system under development – Structure – Behavior – Interaction – Non-functional properties – Deployment – …
5. Temporal Aspect of Architecture • Design decisions are made and unmade over a system’s lifetime – At time t a system has only one architecture • Prescriptive architecture (PA) captures design decisions made prior to system construction – as-designed • Descriptive architecture (DA) describes how the system has been built – as-implemented
6. iRODS – Descriptive Architecture How Many Systems Start off iRODS – Prescriptive Architecture …and End up
7. What Happened? • Software decay – Drift – introduction of design decisions into a system that are not encompassed or implied by its architectural design – Erosion – introduction of design decisions into a system that violate its architectural design • Decaying systems begin to “smell” «More on this later…
8. Decay in Real Systems? Linux – Prescriptive Architecture Linux – Descriptive Architecture
9. Top-Level Architecture – Another View
10. Another Example Hadoop Distributed File System – Prescriptive Architecture HDFS – Descriptive Architecture
11. Hadoop – HDFS + MapReduce
12. Hadoop – Complete Architecture
13. Hadoop – Complete Architecture, Another View
14. One More Example Bash Prescriptive Architecture Bash Descriptive Architecture
15. Part II Decay
16. Can We “Smell” Decay? • Yes, both in the design and code • Software smell • Commonly made design or implementation decision • Negatively impacts your system’s lifecycle properties • It is not a bug – it doesn’t break your system • Our goal is to discover architectural design smells automatically • Inspired by • Refactoring: Improving the Design of Existing Code by Martin Fowler
17. A Catalogue of Architectural Smells • Brick Concern Overload • Brick Use Overload • Brick Dependency Cycle • Unused Interface • Ambiguous Interface • Duplicate Component Functionality • Scattered Functionality • Component Envy • Connector Envy • Connector Chain • Extraneous Adjacent Connector • …
18. Examples of Smells from Real Systems This document contains no technical data subject to the EAR or the ITAR.
19. Linux Architecture
20. Linux – Memory Manager Subsystem
21. Bash Architecture
22. Bash – Job Control Component
23. Bash – Commands Component
24. Hadoop – Complete Architecture
25. Hadoop – Dependency Cycle
26. Hadoop – Component Use Overload
27. Hadoop – Brick Concern Overload Value Aggregator
28. Hadoop – *Envy InterDataNode Protocol
29. Part III Recovery (and then refactoring)
30. Fable of Two Systems Prescriptive Architecture Descriptive Architecture
31. News Flash! Prescriptive Architecture Descriptive Architecture
32. iRODS – Descriptive Architecture How Many Systems Start off iRODS – Prescriptive Architecture …and End up
33. Smells Impact Real Systems Smelly files are more issue prone Smelly files tend to be more change prone
34. How Do We Know? • Architecture recovery – The process of determining a system’s architecture from its implementation-level artifacts – Source code, executable files, Java .class files, … • Difficult in practice – Size of code bases – Irrelevant details – Misleading details – Missing information – Hard to objectively assess existing techniques • Still, automated solutions are available
35. What Are These Solutions You Speak of? • ACDC – Algorithm for Comprehension-Driven Clustering – Structural pattern-based clustering • ARC – Architecture Recovery Using Concerns – Concern-based hierarchical clustering based on similarity measure • Bunch-NAHC & Bunch-SAHC – Hill-climbing algorithm for maximizing Modularization Quality • LIMBO – scaLable InforMation BOttleneck – Probabilistic hierarchical clustering • WCA-UE & WCA-UENM – Weigted Combined Algorithm – Dependency-based hierarchical clustering • ZBR – Zone-Based Recovery – Hierarchical clustering based on textual information • PKG – Implementation Package Structure
36. Do They Really Work? Bash from ACDC Bash from Bunch Bash from ZBR Bash “Ground Truth”
37. A More In-Depth Study • Eight architectures of six open-source systems • Previously obtained ground-truths for each ArchStudio 4 IDE Java 280K 54 comp. Bash 1.14.4 OS Shell C 70K 25 Hadoop 0.19.0 Data Prc Java 200K 68 Linux-C 2.0.27 OS C 750K 7 Linux-D 2.0.27 OS C 750K 120 Mozilla-C 1.3 Browser C/C++ 4M 10 Mozilla-D 1.3 Browser C/C++ 4M 233 OODT 0.2 Data Mgt Java 180K 217
38. Proximity to Ground Truth
39. Cluster Comparison
40. Part IV Understanding Architecture as a “Big Data” problem
41. Software Architecture ARCADE Architecture Recovery, Change, and Decay Evaluator Source Code Issue Repository Recovery Techniques Issue Extractor Issues Architectures Architectural Smell Detector Architectural- Smell Instances Change Metrics Calculator Decay Metrics Calculator Change Metrics Decay Metrics Relation Analyzer Correlation Data
42. Empirical Study of Change and Decay 1. In what ways do architectures change? 2. When and how do architectures decay? 3. What is the relationship between architectural smells and implementation issues? 42
43. Several Subject Systems 43 System Application Domain Versions Time MSLOC ActiveMQ Message Broker 20 8/04-12/05 3.4 Cassandra Distributed DBMS 127 9/09-9/13 22.0 Chukwa Data Monitoring 7 5/09-2/14 2.2 Hadoop Data Processing 63 4/06-8/13 30.0 Ivy Dependency Manager 20 12/07-2/14 0.4 JackRabbit Content Repository 97 8/04-2/14 34.0 Jena Semantic Web Framework 7 6/12-9/13 2.7 JSPWiki Wiki Engine 54 10/07-3/14 1.2 Log4j Logging 41 01/01-06/14 2.4 Lucene Search Engine 21 12/10-1/14 5.1 Mina Network Framework 40 11/06-11/12 2.3 PDFBox PDF Library 17 2/08-3/14 2.7 Struts Web Apps 36 3/00-2/14 6.7 Xerces XML Library 22 3/03-11/09 2.3
44. A Few Background Bits • Versioning Scheme – major.minor.patch release • Change metrics – MojoFM – a2a – c2c • Decay metrics – # structural dependencies – Change proneness – Coupling and cohesion – Smell density and coverage 44 1.5.3 1.6.0 1.6.1 2.0.0
45. Recovery Techniques Used • PKG – package structure recovery • ACDC* – algorithm for comprehension-driven clustering • ARC** – architecture recovery using concerns * V. Tzerpos et al., ACDC: an algorithm for comprehension-driven clustering, In Working Conference on Reverse Engineering (WCRE), 2000 ** J. Garcia et al., Enhancing architectural recovery using concerns, In International Conference on Automated Software Engineering (ASE), 2011
46. How Architectures Change Value unit is percentage Lower numbers mean more change 0 10 20 30 40 50 60 70 80 90 100 Ivy Lucene JSPWiki Ivy Lucene JSPWiki Ivy Lucene JSPWiki Ivy Lucene JSPWiki Major MinMajor Minor Patch Average a2a values between versions ACDC ARC PKG Architecture Similarity “Reversed” architecture changes On average, architecture changes range from 15-25% Changes differ between different views Major < MinMajor < Minor < Patch
47. System vs. Component Level • Architecture changes occur within components even when the system’s overall architectural structure remains relatively stable Architectural similarity between minor versions of “Ivy” ARC view: architecture changes more than 80% within components
48. • Dramatic architecture change can occur across minor versions 0 10 20 30 40 50 60 70 80 90 100 Minimum a2a values between minor versions ACDC ARC PKG RQ3 – When Significant Change Occurs Architecture changes > 50% Architecture Similarity
49. At What Point Does Change Become Decay? Apache Chukwa 0.3.0 Apache Chukwa 0.4.0
50. Architectural Decay 50 0 20 40 60 80 100 120 co lo spf dc Versions v1 v123 Cassandra’s architectures recovered using ARC
51. Smells Impact Real Systems Smelly files are more issue prone Smelly files tend to be more change prone Smelly files are continuously involved in many issues
52. On-Going Work • Identify, understand, and catalogue smells • Identify patterns indicating decay • Collect and document ground-truths • Improve architectural recovery – Better code analysis – Dynamic system aspects • Study correlation/causality of architectural change & decay with – implementation issues – code decay – refactoring – self-adaptive behavior
53. Acknowledgments • Supporters – NSF – Bosch RTC – NASA/JPL • Project participants and collaborators - Pooyan Behnamghader, USC - Yuanfang Cai, Drexel U. - Eric Dashofy, Aerospace Corp. - Chris Douglas, Microsoft - Eder Figueroa, USC - Alessandro Garcia, PUC-Rio - Joshua Garcia, UC Irvine - Muzzammil Imam, USC - Igor Ivkovic, U. of Waterloo - Ivo Krka, Google - Duc Le, USC - Daniel Link, USC - Isela Macia, PUC-Rio - Chris Mattmann, NASA/JPL - Daniel Popescu, Google - Arman Shahbazian, USC - Yixue Zhao, USC – Infosys – Northrop Grumman – Huawei