tmpa-2017: stemming architectural decay in software systems

53
Stemming Architectural Decay in Software Systems Nenad Medvidović Computer Science Department Viterbi School of Engineering University of Southern California Los Angeles, CA, USA [email protected] http://csse.usc.edu/~neno/

Upload: iosif-itkin

Post on 11-Apr-2017

143 views

Category:

Technology


2 download

TRANSCRIPT

Page 1: TMPA-2017:  Stemming Architectural Decay in Software Systems

Stemming Architectural Decayin Software Systems

Nenad MedvidovićComputer Science DepartmentViterbi School of Engineering

University of Southern CaliforniaLos Angeles, CA, USA

[email protected]://csse.usc.edu/~neno/

Page 2: TMPA-2017:  Stemming Architectural Decay in Software Systems

Part I

SoftwareArchitecturesRealandImagined

Page 3: TMPA-2017:  Stemming Architectural Decay in Software Systems

ABitofTerminology• Asoftwaresystem’sarchitectureisthesetofprincipaldesigndecisions aboutthesystem– Softwarearchitectureistheblueprintforasoftwaresystem’sconstructionandevolution

• Designdecisionsencompasseveryfacetofthesystemunderdevelopment– Structure– Behavior– Interaction– Non-functionalproperties– Deployment– …

Page 4: TMPA-2017:  Stemming Architectural Decay in Software Systems
Page 5: TMPA-2017:  Stemming Architectural Decay in Software Systems

TemporalAspectofArchitecture• Designdecisionsare madeandunmadeoverasystem’slifetime– Attimet asystemhasonlyonearchitecture

• Prescriptivearchitecture(PA) capturesdesigndecisionsmadepriortosystemconstruction– as-designed

• Descriptivearchitecture(DA) describeshowthesystemhasbeenbuilt– as-implemented

Page 6: TMPA-2017:  Stemming Architectural Decay in Software Systems

iRODS – DescriptiveArchitecture

HowManySystemsStartoffiRODS – PrescriptiveArchitecture …andEndup

Page 7: TMPA-2017:  Stemming Architectural Decay in Software Systems

WhatHappened?• Softwaredecay

– Drift– introductionofdesigndecisionsintoasystemthatarenotencompassedorimpliedbyitsarchitecturaldesign

– Erosion– introductionofdesigndecisionsintoasystemthatviolateitsarchitecturaldesign

• Decayingsystemsbeginto“smell”«Moreonthislater…

Page 8: TMPA-2017:  Stemming Architectural Decay in Software Systems

DecayinRealSystems?

Linux– PrescriptiveArchitecture

Linux– DescriptiveArchitecture

Page 9: TMPA-2017:  Stemming Architectural Decay in Software Systems

Top-LevelArchitecture– AnotherView

Page 10: TMPA-2017:  Stemming Architectural Decay in Software Systems

AnotherExampleHadoopDistributedFileSystem– PrescriptiveArchitecture

HDFS– DescriptiveArchitecture

Page 11: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – HDFS+MapReduce

Page 12: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – CompleteArchitecture

Page 13: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – CompleteArchitecture,AnotherView

Page 14: TMPA-2017:  Stemming Architectural Decay in Software Systems

OneMoreExampleBashPrescriptiveArchitecture

BashDescriptiveArchitecture

Page 15: TMPA-2017:  Stemming Architectural Decay in Software Systems

Part II

Decay

Page 16: TMPA-2017:  Stemming Architectural Decay in Software Systems

CanWe“Smell”Decay?• Yes,bothinthedesignandcode• Softwaresmell

• Commonlymadedesignorimplementationdecision• Negativelyimpactsyoursystem’slifecycleproperties• Itisnotabug– itdoesn’tbreakyoursystem

• Ourgoalistodiscoverarchitecturaldesignsmellsautomatically

• Inspiredby• Refactoring:ImprovingtheDesignofExistingCode

byMartinFowler

Page 17: TMPA-2017:  Stemming Architectural Decay in Software Systems

ACatalogueofArchitecturalSmells• BrickConcernOverload• BrickUseOverload• BrickDependencyCycle• UnusedInterface• AmbiguousInterface• DuplicateComponentFunctionality• ScatteredFunctionality• ComponentEnvy• ConnectorEnvy• ConnectorChain• ExtraneousAdjacentConnector• …

Page 18: TMPA-2017:  Stemming Architectural Decay in Software Systems

ExamplesofSmellsfromRealSystems

ThisdocumentcontainsnotechnicaldatasubjecttotheEARortheITAR.

Page 19: TMPA-2017:  Stemming Architectural Decay in Software Systems

LinuxArchitecture

Page 20: TMPA-2017:  Stemming Architectural Decay in Software Systems

Linux– MemoryManagerSubsystem

Page 21: TMPA-2017:  Stemming Architectural Decay in Software Systems

BashArchitecture

Page 22: TMPA-2017:  Stemming Architectural Decay in Software Systems

Bash– JobControlComponent

Page 23: TMPA-2017:  Stemming Architectural Decay in Software Systems

Bash– CommandsComponent

Page 24: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – CompleteArchitecture

Page 25: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – DependencyCycle

Page 26: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – ComponentUseOverload

Page 27: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop – BrickConcernOverload

ValueAggregator

Page 28: TMPA-2017:  Stemming Architectural Decay in Software Systems

Hadoop –* EnvyInterDataNode Protocol

Page 29: TMPA-2017:  Stemming Architectural Decay in Software Systems

Part III

Recovery(andthenrefactoring)

Page 30: TMPA-2017:  Stemming Architectural Decay in Software Systems

FableofTwoSystems

PrescriptiveArchitecture DescriptiveArchitecture

Page 31: TMPA-2017:  Stemming Architectural Decay in Software Systems

NewsFlash!

PrescriptiveArchitecture DescriptiveArchitecture

Page 32: TMPA-2017:  Stemming Architectural Decay in Software Systems

iRODS – DescriptiveArchitecture

HowManySystemsStartoffiRODS – PrescriptiveArchitecture …andEndup

Page 33: TMPA-2017:  Stemming Architectural Decay in Software Systems

SmellsImpactRealSystemsSmellyfilesaremoreissueprone

Smellyfilestendtobemorechangeprone

Page 34: TMPA-2017:  Stemming Architectural Decay in Software Systems

HowDoWeKnow?• Architecturerecovery

– Theprocessofdetermininga system’sarchitecturefromitsimplementation-levelartifacts

– Sourcecode,executablefiles,Java.classfiles,…• Difficultinpractice

– Sizeofcodebases– Irrelevantdetails– Misleadingdetails– Missinginformation– Hardtoobjectivelyassessexistingtechniques

• Still,automatedsolutionsareavailable

Page 35: TMPA-2017:  Stemming Architectural Decay in Software Systems

WhatAreTheseSolutionsYouSpeakof?• ACDC– AlgorithmforComprehension-DrivenClustering

– Structuralpattern-basedclustering

• ARC– ArchitectureRecoveryUsingConcerns– Concern-basedhierarchicalclusteringbasedonsimilaritymeasure

• Bunch-NAHC& Bunch-SAHC– Hill-climbingalgorithmformaximizingModularizationQuality

• LIMBO– scaLable InforMation BOttleneck– Probabilistichierarchicalclustering

• WCA-UE& WCA-UENM– Weigted CombinedAlgorithm– Dependency-basedhierarchicalclustering

• ZBR– Zone-BasedRecovery– Hierarchicalclusteringbasedontextualinformation

• PKG– ImplementationPackageStructure

Page 36: TMPA-2017:  Stemming Architectural Decay in Software Systems

DoTheyReallyWork?

BashfromACDC

BashfromBunch BashfromZBR

Bash“GroundTruth”

Page 37: TMPA-2017:  Stemming Architectural Decay in Software Systems

AMoreIn-DepthStudy• Eightarchitecturesofsixopen-sourcesystems• Previouslyobtainedground-truthsforeach

ArchStudio 4 IDE Java 280K 54comp.Bash 1.14.4 OSShell C 70K 25Hadoop 0.19.0 DataPrc Java 200K 68Linux-C 2.0.27 OS C 750K 7Linux-D 2.0.27 OS C 750K 120Mozilla-C 1.3 Browser C/C++ 4M 10Mozilla-D 1.3 Browser C/C++ 4M 233OODT 0.2 DataMgt Java 180K 217

Page 38: TMPA-2017:  Stemming Architectural Decay in Software Systems

ProximitytoGroundTruth

Page 39: TMPA-2017:  Stemming Architectural Decay in Software Systems

ClusterComparison

Page 40: TMPA-2017:  Stemming Architectural Decay in Software Systems

Part IV

UnderstandingArchitectureasa“BigData”problem

Page 41: TMPA-2017:  Stemming Architectural Decay in Software Systems

Software ArchitectureARCADEArchitectureRecovery,Change,andDecayEvaluator

SourceCode

IssueRepository

RecoveryTechniques IssueExtractor

IssuesArchitecturesArchitecturalSmellDetector

Architectural-SmellInstances

ChangeMetricsCalculator

DecayMetricsCalculator

ChangeMetrics

DecayMetrics

RelationAnalyzer

CorrelationData

Page 42: TMPA-2017:  Stemming Architectural Decay in Software Systems

EmpiricalStudyofChangeandDecay

1. Inwhatwaysdoarchitectureschange?

2. Whenandhowdoarchitecturesdecay?

3. Whatistherelationshipbetweenarchitecturalsmellsandimplementationissues?

42

Page 43: TMPA-2017:  Stemming Architectural Decay in Software Systems

SeveralSubjectSystems

43

System ApplicationDomain Versions Time MSLOCActiveMQ MessageBroker 20 8/04-12/05 3.4Cassandra DistributedDBMS 127 9/09-9/13 22.0Chukwa DataMonitoring 7 5/09-2/14 2.2Hadoop DataProcessing 63 4/06-8/13 30.0Ivy DependencyManager 20 12/07-2/14 0.4JackRabbit ContentRepository 97 8/04-2/14 34.0Jena SemanticWebFramework 7 6/12-9/13 2.7JSPWiki WikiEngine 54 10/07-3/14 1.2Log4j Logging 41 01/01-06/14 2.4Lucene SearchEngine 21 12/10-1/14 5.1Mina NetworkFramework 40 11/06-11/12 2.3PDFBox PDFLibrary 17 2/08-3/14 2.7Struts WebApps 36 3/00-2/14 6.7Xerces XMLLibrary 22 3/03-11/09 2.3

Page 44: TMPA-2017:  Stemming Architectural Decay in Software Systems

AFewBackgroundBits• VersioningScheme

– major.minor.patch release• Changemetrics

– MojoFM– a2a– c2c

• Decaymetrics– #structuraldependencies– Changeproneness– Couplingandcohesion– Smelldensityandcoverage

44

1.5.3

1.6.0

1.6.1

2.0.0

Page 45: TMPA-2017:  Stemming Architectural Decay in Software Systems

RecoveryTechniquesUsed

• PKG – package structure recovery

• ACDC* – algorithm forcomprehension-drivenclustering

• ARC** – architecture recovery usingconcerns

*V.Tzerpos etal.,ACDC:analgorithmforcomprehension-drivenclustering,InWorkingConferenceonReverseEngineering(WCRE),2000

**J.Garciaetal.,Enhancingarchitecturalrecoveryusingconcerns,InInternationalConferenceonAutomatedSoftwareEngineering(ASE),2011

Page 46: TMPA-2017:  Stemming Architectural Decay in Software Systems

HowArchitecturesChange

ValueunitispercentageLowernumbersmeanmorechange

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

Averagea2avaluesbetweenversions

ACDC ARC PKG

ArchitectureSimilarity

“Reversed”architecturechanges

Onaverage,architecturechangesrangefrom15-25%

Changesdifferbetweendifferentviews

Major<MinMajor <Minor<Patch

Page 47: TMPA-2017:  Stemming Architectural Decay in Software Systems

System vs.ComponentLevel• Architecture changes occur within components even when the

system’s overall architectural structure remains relatively stable

Architecturalsimilaritybetweenminorversionsof“Ivy”

ARCview: architecturechangesmorethan80%withincomponents

Page 48: TMPA-2017:  Stemming Architectural Decay in Software Systems

• Dramaticarchitecturechangecanoccuracrossminorversions

0

10

20

30

40

50

60

70

80

90

100

Minimuma2avaluesbetweenminorversions

ACDC ARC PKG

RQ3 – WhenSignificantChangeOccurs

Architecturechanges> 50%

ArchitectureSimilarity

Page 49: TMPA-2017:  Stemming Architectural Decay in Software Systems

AtWhatPointDoesChangeBecomeDecay?

ApacheChukwa0.3.0 ApacheChukwa0.4.0

Page 50: TMPA-2017:  Stemming Architectural Decay in Software Systems

ArchitecturalDecay

50

0

20

40

60

80

100

120

colospfdc

Versionsv1 v123

Cassandra’sarchitecturesrecoveredusingARC

Page 51: TMPA-2017:  Stemming Architectural Decay in Software Systems

SmellsImpactRealSystemsSmellyfilesaremoreissueprone

Smellyfilestendtobemorechangeprone

Smellyfilesarecontinuouslyinvolvedinmanyissues

Page 52: TMPA-2017:  Stemming Architectural Decay in Software Systems

On-GoingWork• Identify,understand,andcataloguesmells• Identifypatternsindicatingdecay• Collectanddocumentground-truths• Improvearchitecturalrecovery

– Bettercodeanalysis– Dynamicsystemaspects

• Studycorrelation/causalityofarchitecturalchange&decaywith– implementationissues – codedecay– refactoring – self-adaptivebehavior

Page 53: TMPA-2017:  Stemming Architectural Decay in Software Systems

Acknowledgments• Supporters

– NSF– BoschRTC– NASA/JPL

• Projectparticipantsandcollaborators- Pooyan Behnamghader,USC- Yuanfang Cai,DrexelU.- EricDashofy,AerospaceCorp.- ChrisDouglas,Microsoft- EderFigueroa,USC- AlessandroGarcia,PUC-Rio- JoshuaGarcia,UCIrvine- Muzzammil Imam,USC- IgorIvkovic,U.ofWaterloo

- IvoKrka,Google- Duc Le,USC- DanielLink,USC- Isela Macia,PUC-Rio- ChrisMattmann,NASA/JPL- DanielPopescu,Google- ArmanShahbazian,USC- Yixue Zhao,USC

– Infosys– NorthropGrumman– Huawei