Software Architecture Erosion and Modernization
Upcoming SlideShare
Loading in...5
×
 

Software Architecture Erosion and Modernization

on

  • 2,245 views

Software Architecture Erosion, Modernization and what you can do about it

Software Architecture Erosion, Modernization and what you can do about it

Statistics

Views

Total Views
2,245
Views on SlideShare
2,143
Embed Views
102

Actions

Likes
0
Downloads
48
Comments
0

4 Embeds 102

http://www.eclipsecon.org 89
http://eclipsecon.org 9
https://www.eclipsecon.org 3
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Architecture Erosion and Modernization Software Architecture Erosion and Modernization Presentation Transcript

  • Stop the SoftwareArchitecture ErosionBernhard Merkle Frederic MadiotR&D Software Products ManagerSICK AG, Germany OBEO, France Contact us on linkedin.com or xing.com Page: 1
  • Agenda – Software Architecture – Detect Architectural Erosion – Eclipse + Open Source Projects – Model-Driven Reverse-Engineering Page: 2
  • Architecture, Erosion Page: 6
  • Software-Architecture: DefinitionsIEEE 1471-2000: The fundamental organization of a system, embodied in its components, their relationship to each other and the environment, and the principles governing its design and evolution. Page: 7
  • Architectural Erosion“Sometimes the developers manage tomaintain this purity of design through theinitial development and into the first release.More often something goes wrong.The software starts to rot like apiece of bad meat”.Uncle Bob: “Agile Software Development” Page: 9
  • Architectural ErosionWhy should we care ? – In (lots of) Projects, Architecture decay happens – We are not alone, as we‘ve some good representatives… ;-)There is/was a plan Page: 10
  • X-raying Software… Page: 11
  • Findbugs: the first years 0.7.2 0.8.6 (03/2004) (10/2004) Page: 12
  • Findbugs: first erosion 0.8.7 (05/2005) Page: 13
  • Tangle increase… 0.8.8 1.0.0 (05/2005) (06/2006) Page: 14
  • Tangle increase… 1.3.0 Page: 15 (07/2007)
  • ONE BIG Tangle… 1.3.8 (03/2009) Page: 16
  • Page: 17
  • Modeling Subsystems: Page: 20
  • Fixing Architectural Violations Page: 21
  • Fixing Architectural Violations Page: 22
  • Fixing Architectural Violations Page: 23
  • Fixing Architectural Violations Page: 24
  • Fixing Architectural Violations Page: 25
  • Fixing Architectural Violations Page: 26
  • Fixing Architectural Violations Page: 27
  • Tools for Architecture-Analysis – SotoArc SonarJ – Bauhaus Lattix – Structure101 Klocwork, Coverity – http://code.google.com/p/architecturerules/ – ODASA, CodeCrawler, Codecity, SeeSoft, XRadar, XDepend, SonarSource, Kalistick, Sqoring, … – Eclipse-Based: MoDisco (+Modernization of Applications)http://se-radio.net/episode-115-architecture-analysis Page: 28
  • Basic Approaches (Dependencies) – makedepend, jdepend – Eclipse (Java Build Path) – OSGI (Dependencies) Page: 29
  • Basic ApproachesPDE Dependency Visualization Page: 30
  • Missing in basic approaches:Architecture Analysis (Deviation)Drill-Down + AggregationDisplaying resultsMonitoring changes, trendsRating of Architecture Requirements for Architectural Analysis Tools Page: 31
  • Architecture Analysis (deviation) Requirements Architecture- Should- Design Architecture Comparison “Diff-” Actions Architecture Extraction Is- •Violations •Conformance Architecture Existing Code Page: 32
  • Displaying results: Page: 33
  • Architecture: critical for OS-projectsHow to augment How to replacethe development key people ?and support load ? Open-Source Project Marketplace How to maintain How to develop confidence with users? a market ? Page: 34
  • Openess limits Erosion Developers expose their reputation Names are associated to the architecture Community can provide feedback Warnings, Recommendations, ... Page: 35
  • Risks of Erosion in FOSS Contributors from several organizations Different cultures, processes, tools, … Lower pressure from management Indirect Business Hazardous funding Difficulties to calculate costs and benefits Page: 36
  • Eclipse: Architectural Analysis Page: 37
  • Eclipse: 10 Years Legacy System Eclipse Helios = 33M lines of code Page: 38
  • Eclipse Architecture Page: 39
  • Eclipse Architecture Page: 40
  • Eclipse Architecture Page: 41
  • E3.4: Plattf:Ant JDT:* Page: 42
  • E3.4: Plattf:Ant JDT:UI Page: 43
  • Plattform: CVS Workb (internal) Page: 44
  • Team-UI UI-workbench (internal)https://bugs.eclipse.org/bugs/show_bug.cgi?id=90582 Page: 45
  • Antipatterns Page: 46
  • Dependent BaseClass – Type: • Design Problem – Problem: • one of more Methods shall implement different behavior, depending on the type, passed in – Context: • make “extensible” systems, frameworks – Forces: • Programming languages offer, instanceof/typeid funcs. – Antipattern: • Methods of the baseclass, depend on derived classes, e.g. accessing their members, doing switch/case depending on type information Page: 47
  • AntiPatterns / Bad Smells:Metrics/1000 Classes Eclipse JDKDependent Baseclass: 1 16Multiple Interface Inher. 4 18Abstractable Methods 80 60Abstractable Attributes 45 170Unused Classes 50 150Unused Methods 950 2500Unused Attributes 30 20 Page: 48
  • CodeCode Clones Clones Page: 49
  • Code Clones – identical Files • E2.0 JDT,CDT – jdtdebuginternaluidialogfieldsListDialogField.java – cdtdebuginternaluidialogfieldsListDialogField.java • E3.4 CDT: identical packages – cdtdebuginternaluidialogfields, cdtdebugmiinternaluidialogfields – variation of former identical Files • E3.4 JDT,CDT – jdtdebuginternaluidialogfieldsListDialogField.java – cdtdebuginternaluidialogfieldsListDialogField.java Page: 50
  • Rating Eclipse ArchitectureMinor Erosions, Code Duplication – large codebase, – OSGI helps a lot – API Police, – Guidelines – upcoming PDE tools – Processes and Tools Page: 51
  • Architecture Council Recommend.•Architectural Recommendations •Community Practices • Be asynchronous • Engage your user community • Think API • Long-running operations should be cancelable •Software Development Practices • Separate policy and mechanism • Unit Test, Unit Test, Unit Test • Keep simple things simple • Continuous Integration • Create Unittests early • Integrate in small steps • Minimize plug-in dependencies • Be aware of the deployment context • Package coherence • Putting only related things together http://wiki.eclipse.org/Architecture_Council/Top_Ten_Project_Development_Practices http://wiki.eclipse.org/Architecture_Council/Top_Ten_Recommendations Page: 52
  • Yearly Simultaneous Releases Rules Projects should leverage only published APIs of dependencies Version number ends with « qualifier » Source code must use ICU4J classes The project must contain an « about.html » file Packages name should start with the plug-in ID Plug-in must not contain JARs files Plug-in should contain only one « message.properties » and « Message.java » files Etc… http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php Page: 53
  • New Eclipse projects … driving to new architectures Components that are more reusable + customizable Service-oriented programming model GUI represented by a model and configurable with CSS Enabling Javascript app to be executed by Eclipse runtime Framework to build SWT app declarativeley Ajax-enabled web applications by using a subset of RCP APIs Eclipse development model Plug-ins & Eclipse workbench extension points Widget toolkit using SWT API Browser-based tools to develop for the web, in the web Client: loosely coupled components written in JavaScript Server: services exposed via REST-oriented HTTP APIs Page: 54
  • Manage architectural transition? ? Architecture A Architecture B Page: 55
  • Evolution to e4 Backward Compatibility Layer • Eclipse 3.x plug-ins run on e4 Challenges • Not clean APIs usage? Refactoring • Using e4 development model? Migration • Single sourcing? Forward Compat. Layer (Session: Singlesourcing for Eclipse 4.x and Eclipse 3.x) Page: 56
  • Evolution to RAPSingle sourcing with RAP is not automatic • API differences • Missing extension points • Application startup and Activator scope • API Differences • Field validation Refactoring • SWT ressources • Singletons and Scopes • Jobs and background threads • Internationalization and localization (http://eclipsesource.com/fileadmin/doc/2009_product/single_sourcing_guide.pdf) Page: 57
  • How to modernizeexisting Eclipse plug-ins? Page: 58
  • Architectural Modernization Process Transformation Reference Tooling Tests Modernization Transformation Strategy & Integration Non-Regression Audit Tests Legacy Modernized Software Software System System Page: 59
  • Anatomy of an Eclipse 3.x Plug-in folders files .project .classpath ! ity MANIFEST.MF e ne gEclipse Plug-in build.properties te ro He plugin.xml plugin.properties Source code Page: 60
  • Model-DrivenReverse-Engineeringof Eclipse plug-ins Page: 61
  • MoDisco use Models to represent and manipulate artifacts of existing systems Discover ExistingUnderstand Transform Software System Software artifacts : - source code New Models Viewpoints - configuration files Software System - tests - database -… http://www.eclipse.org/MoDisco/ Page: 62
  • MoDisco Architecture Supported Technologies Java JSP XML EclipsePlugin Metamodel Metamodel Metamodel Discoverer Discoverer Discoverer Metamodel Generator Generator Generator Discoverer Transfo. to KDM Discovery Model Customization OMG/ADM Manager Browser & Extensibility Standards Plug and orchestrate Navigation Definition of Pivot transformations through specific Metamodels complex models Viewpoints (SMM & KDM) Infrastructure Eclipse Modeling projects Page: 63
  • Using EMF to describe a Plug-in folders Project’s structure (KDMSource) files .project (XML) .project .classpath (XML) .classpath it y! manifest e MANIFEST.MF en plugin build.properties og (eclipseplugin) om (XML)Eclipse Plug-in build.properties (KDMCore) Hextensions plugin.xml plugin.properties plugin.properties (KDMCore) Java source code Source code (Java) Page: 64
  • Using EMF to describe a Plug-in Page: 65
  • What can you do withthe EMF modelof a plug-in ? Page: 66
  • Leverage Eclipse Modeling components Inspect Inspect (MoDisco Browser, EEF) (MoDisco Browser, EEF) Query Query (EMF Query) (EMF Query) Vizualize Vizualize (GMF, Graphiti) (GMF, Graphiti) EMF Model of an Eclipse plug-in Compare Compare (EMF Compare) (EMF Compare) Transform Transform (ATL, QVTo) (ATL, QVTo) Generate code Generate code (Acceleo, Xpand, Jet) (Acceleo, Xpand, Jet) Page: 67
  • Architectural Modernization Process Transformation Transformation Reference Reference Tooling Tooling Tests Tests Modernization Modernization Transformation Transformation Strategy Strategy & Integration & Integration Non-Regression Non-Regression Audit Tests Tests • Quality Analysis • Volumetry • Cartography Legacy Legacy Modernized Modernized Software Software Software Software System System System System Page: 68
  • Validation Page: 69
  • Architecture Visualization GMF diagram created with ObeoDesigner • purple: EMF Model • green: UI Page: 70
  • Architectural Modernization Process Transformation Reference Reference Tooling Tests Tests Modernization Modernization Transformation Transformation Strategy Strategy & Integration & Integration Non-Regression Non-Regression Audit Audit • Parsing Tests Tests • Transformation rules • Re-generation Legacy Legacy Modernized Modernized Software Software Software Software System System System System Page: 71
  • Refactoring & Migration Model Model Existing of the existing Transformed of the migrated Plug-in Plug-in Plug-in Plug-in Transformation Rules What to change + How to change • Renaming • Changing code structure (inheritance, attributes, methods, etc) • Replacing method calls • Changing instructions order • Etc Page: 72
  • Architectural Modernization Process Transformation Transformation Reference Tooling Tooling Tests Modernization Modernization Transformation Transformation Strategy Strategy & Integration & Integration • Tests coverage analysis Non-Regression Non-Regression Audit Audit Tests Tests Legacy Legacy Modernized Modernized Software Software Software Software System System System System Page: 73
  • Test coverage analysis Page: 74
  • Architectural Modernization Process Transformation Transformation Reference Reference Tooling Tooling Tests Tests Modernization Modernization Transformation Strategy Strategy & Integration Non-Regression Non-Regression Audit Audit Tests Tests • Automatic transformation • Manual transformation • Build Legacy Legacy Modernized Modernized Software Software Software Software System System System System Page: 75
  • Build IDM++ Research Project (ANR) -> Sept 2011 Plug-ins to build Model of plugins to build Team information (CVS, SVN, etc) constraints solver B3 Model (build configuration) Model of Update sites update sites content (p2) Build Strategies Page: 76
  • SummaryStop the Software Architecture Erosion ?Analysis is Required – Evaluate the architectural situation – Take the right decisions at the right timeModernization is Required – Correct erosion consequences – Go with architectural Evolutions=> Continuous Analysis + Modernization Page: 77
  • Thank you ! Page: 78