MORPHOSIS: A Case Study on Lightweight Architecture Sustainability Analysis


Published on

Managing the cost-effective evolution of industrial
software systems is a challenging task because of their complexity
and long lifetimes. Limited pro-active evolution planning
and software architecture erosion often lead to huge maintenance
costs in such systems. However, formerly researched
approaches for evolution scenario analysis and architecture
enforcement are only reluctantly applied by practitioners due
to their perceived overhead and high costs. We have applied
several recent sustainability evaluation and improvement approaches
in a case study to the software architecture of a large
industrial software system currently under development at
ABB. We combined our selection of approaches in a lightweight
method called MORPHOSIS, for which this paper presents
experiences and lessons learned. We found that reasonable
sustainability evaluation and improvement is possible already
with limited efforts.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • MORPHOSIS: A Case Study on Lightweight Architecture Sustainability Analysis

    1. 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© ABBAugust 24, 2012 | Slide 1
    2. 2. Large-scale Industrial Control SystemsChallenge: Software Architecture Erosion Circles = components, Colors = subsystems, Size = lines of code, Arrows = dependencies© ABB August 24, 2012 | Slide 2
    3. 3. MORPHOSISMulti-perspective SW Architecture Analysis Method© ABB August 24, 2012 | Slide 3
    4. 4. Evolution Scenario AnalysisMethod 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. QoSA11, 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. 5. Evolution Scenario AnalysisResultsStatus: 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. 6. Architectural EnforcementDerived 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 moduleclass 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. 7. Architecture-level Metric Tracking© ABB August 24, 2012 | Slide 7
    8. 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. 9. MORPHOSISLessons 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. 10. MORPHOSISConclusions  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