MORPHOSIS: A Case Study on Lightweight Architecture Sustainability Analysis
Download as PPTX, PDF•1 like•2,531 views
The document presents a case study on the sustainability analysis of lightweight architecture conducted by ABB, focusing on software architecture erosion in large-scale industrial control systems. It describes multi-perspective software architecture analysis methods and results from evolution scenario analysis, highlighting the importance of architecture enforcement and metrics tracking. Lessons learned emphasize cost-benefit considerations, automation benefits, and the need for further quantification and longitudinal studies related to architecture metrics and maintenance costs.
MORPHOSIS: A Case Study on Lightweight Architecture Sustainability Analysis
- 1. Heiko Koziolek, Dominik Domis, Thomas Goldschmidt, Philipp Vorst, Roland Weiss ABB Corporate Research, Ladenburg, Germany MORPHOSIS A Case Study on Lightweight Architecture Sustainability Analysis © ABB August 24, 2012 | Slide 1
- 2. Large-scale Industrial Control Systems Challenge: Software Architecture Erosion Circles = components, Colors = subsystems, Size = lines of code, Arrows = dependencies © ABB August 24, 2012 | Slide 2
- 3. MORPHOSIS Multi-perspective SW Architecture Analysis Method © ABB August 24, 2012 | Slide 3
- 4. Evolution Scenario Analysis Method P. Clements, R. 1. Literature search: 2. Top Down Kazman, and M. Klein, Selected method: Evaluating software sustainability Elicitation: architectures: (enhanced) ALMA methods and case evaluation of software 8 interviews with studies. Addison-Wesley, architectures domain experts Reading, MA, 2002. H. Koziolek Sustainability evaluation of software architectures: A 7 evolution 3. Bottom Up List of 31 generic systematic review. Proc. QoSA'11, p. 3-12, scenarios most Elicitation: evolution ACM, June 2011. relevant for SUS 3-month job rotation, scenarios document analysis P. Bengtsson, N. Lassing, J. Bosch, and H. van Vliet, Architecture-level modifiability analysis (ALMA) Journal of Systems and Software, vol. 69, no. 1- 4. Artifact analysis: 7 refined, priorized 2, pp. 129–147, 2004 Models, code, docs; evolution scenarios additional interviews © ABB August 24, 2012 | Slide 4
- 5. Evolution Scenario Analysis Results Status: 1 mid 2011 0.9 Scenario 1 mid 2012 0.8 2013 Scenario 2 2016 0.7 Scenario 3 Occurrence Probability Project 0.6 Scenario 4 started In research 0.5 0.4 0.3 Scenario 5 0.2 Unlikely Scenario 6 in 2013 0.1 Discarded Scenario 7 0 In research 2011 2012 2013 2014 2015 2016 2017 Year when the evolution scenario becomes relevant © ABB August 24, 2012 | Slide 5
- 6. Architectural Enforcement Derived Module Dependency Rules from UML Tool Goal: Automatic checking of allowed dependencies Derived dependency rules from UML layer diagrams Created name mapping from modules in UML to code Constructed CQL rule for each module class Module Structure: Operations Client «layer» Presentation Layer «group» «group» Workplace Presentation Element «allowed to use» «allowed to use» «layer» Operations Client Libraries and APIs «group» Operation Client Serv ices «allow to use» Enterprise Architect UML model «layer» NDepend CQL rule Runtime System Access (Code Query Language) «allowed to use» «module» RuntimeSystemAccessDefinitions © ABB August 24, 2012 «module» | Slide 6 RuntimeSystemAccessCore e»
- 7. Architecture-level Metric Tracking © ABB August 24, 2012 | Slide 7
- 8. S. Sarkar, G. M. Rama, and A. C. Kak, Architecture-level Metric Tracking “API-based and information-theoretic metrics for measuring the quality of software modularization,” Example: Module Interaction Stability IEEE Trans. Softw. Eng., vol. 33, pp. 14–32, January 2007. Instability of a Modules m Layer 4 1 1 module depends on Layer 3 0.5 0.66 Layer 2 0.5 0.6 0.5 Modules that depend on m Layer 1 0 0 0 Set of stable dependencies to Characterizes software according lower layers to the principle of Maximization of Stand-Alone Extensibility Promotes the use of stable modules in lower layers For all modules © ABB August 24, 2012 | Slide 8
- 9. MORPHOSIS Lessons learned Perceived good cost / benefit ratio Low analysis overhead, high automation However: benefits are not quantified yet Quantifying the costs for evolution scenarios is hard Impact prediction difficult if code not available Externalizing and prioritizing evolution scenarios provides focus to plan mitigation measures Architecture enforcement raises developer awareness Higher regard for the architecture description High developer interest in metrics Desire to improve quality, less concerned about being judged © ABB August 24, 2012 | Slide 1
- 10. MORPHOSIS Conclusions Evolution Scenario Analysis Provided detailed description template Architecture Enforcement Integrated rules from UML model into build process Architecture-level Metrics Tracking Automated tracking of novel architecture metrics Future Work Re-evaluate / add evolution scenarios Conduct a longitudinal study correlating metrics to actual maintenance costs © ABB August 24, 2012 | Slide 1
Editor's Notes
- #3: At ABB we are developing large-scale industrial control systems, which for example manage power plants or oil refineries. Such system have long life times with up to more than 20 years, in which they are extended and improved. If we look inside such systems, we see that they have complex architectures with many interpendent component and subsystems. To keep them sustainable, in the sense of efficient maintainable, we have to avoid architecture erosion and prepare the system for inevitable changesFor a particular system, whose architecture had been already been specified, we were tasked with analysing and improving sustainability.
- #4: We decided to analyse and improve different artifacts in the development processHere you see an idealized and on purpose simplified development process with requirements, architecture, and code.Our method MORPHOSIS thus concerned three different activities:Evolution scenario analysis for the requirements and architectureArchitecture enforcement or compliance checking via automatically checked code rulesArchitecture-level metrics tracking for controlling the evolution of the product during maintenanceI will briefly explain what we did in the three activities.
- #5: First, we conducted a scenario-based analysis approach with a specific focus on evolution scenarios.An evolution scenario is an expected changed to the system‘s architecture, e.g., the adding or replacement of a component.The idea is to prepare the system for such evolution scenarios and thus reduce the development costs when they actually appearWe searched the literature for appropriate methods and were inspired by the ALMA methods, architecture-level modifiability analysis.Then we elicit scenarios first in a top-down fashion by interviewing 8 domain experts, which generated a list of 31 rather generic evolution scenariosAfterwards we elicited scenarios bottom-up by interviewing the architects and developers of the system under analysisWe identified 7 major evolution scenarios, which we then analyzed in detailWe came up with an elaborate template for the specification of such scenarios which is detailed in the paper.
- #8: Finally, we setup metrics for checking architecture properties in the code.These were derived from literature and not included in the Ndepend tool out of the boxOur metrics were systematically derived and concerned modifiability, reusability, modularity and testabilityThe blue bubbles indicate those metrics, I can not explain each of them in detail.One example is the module interaction stability index, which is defined as follows.
- #9: We compute the instability of each module in the system based on its fanout and faninYou see the instability for each module in the example on the right hand sideThe idea is to avoid instable modules in lower layerThus „these“ dependencies between layer 3 and layer 2 are not desirable since the module depends on more instable modulesFrom the instabilities the set of stable dependencies in lower layers can be computedThis serves as input for the module interaction stability index for each module.The average over all modules is then the MISI for the whole system, which is between 0 and 1 with 1 being best.