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

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
IssuesArchitectures
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