MORPHOSISA Case Study on Lightweight Architecture Sustainability Analysis

Heiko Koziolek, Dominik Domis, Thomas Goldschmidt, Philipp Vorst, Roland WeissABB Corporate Research, Ladenburg, Germany

© ABBAugust 24, 2012 | Slide 1

Large-scale Industrial Control SystemsChallenge: Software Architecture Erosion

© ABB August 24, 2012 | Slide 2

Circles = components, Colors = subsystems, Size = lines of code, Arrows = dependencies

MORPHOSISMulti-perspective SW Architecture Analysis Method

© ABB August 24, 2012 | Slide 3

Evolution Scenario AnalysisMethod

H. KoziolekSustainability evaluation of software architectures: A systematic review. Proc. QoSA'11, p. 3-12, ACM, June 2011.

P. Bengtsson, N. Lassing, J. Bosch, and H. van Vliet,Architecture-level modifiability analysis (ALMA)Journal of Systems and Software, vol. 69, no. 1-2, pp. 129–147, 2004

P. Clements, R. Kazman, and M. Klein, Evaluating software architectures: methods and case studies. Addison-Wesley, Reading, MA, 2002.

1. Literature search:sustainability

evaluation of software architectures

2. Top Down Elicitation:

8 interviews with domain experts

3. Bottom Up Elicitation:

3-month job rotation, document analysis

Selected method: (enhanced) ALMA

List of 31 generic evolution scenarios

4. Artifact analysis:Models, code, docs; additional interviews

7 refined, priorized evolution scenarios

7 evolution scenarios most

relevant for SUS

© ABB August 24, 2012 | Slide 4

Evolution Scenario AnalysisResults

2011 2012 2013 2014 2015 2016 20170

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Scenario 3

Scenario 4

Scenario 5

Scenario 6

Scenario 7

Scenario 1

Scenario 2

Year when the evolution scenario becomes relevant

Oc

cu

rre

nc

e P

rob

ab

ility

Status:

mid 2011

2013

In research

2016

Unlikely in 2013

Discarded

Project started

In research

mid 2012

© ABB August 24, 2012 | Slide 5

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»Runtime System Access

«layer»Operations Client Libraries and APIs

«layer»Portability Layer

«layer»Presentation Layer

«layer»Hardware Platform

«layer».NET Framework Core

«layer».NET Framework WCF

«layer».NET Framework WPF

«layer»Windows Operating System

«layer»BCL

«group»Operation Client Serv ices

«group»Presentation Element

«group»Workplace

«module»RuntimeSystemAccessDefinitions

«module»RuntimeSystemAccessCore

«module»RuntimeObjectModel «

allo

we

d to

use

»

«allow to use»

«allowed to use»

«allowed to use»

«a

llow

ed

to u

se

»

«a

llow

ed

to u

se

»«allow to use»

«allowed to use»

«allow to use»

«a

llow

ed

to u

se

»

«allowed to use»

«allowed to use»

Enterprise Architect UML model NDepend CQL rule(Code Query Language)

© ABB August 24, 2012 | Slide 6

Architecture-level Metric Tracking

© ABB August 24, 2012 | Slide 7

Architecture-level Metric TrackingExample: Module Interaction Stability

Characterizes software according to the principle of Maximization of Stand-Alone Extensibility

Promotes the use of stable modules in lower layers

Layer 4

Layer 3

Layer 2

Layer 1

Modules m depends on

Instability of a module

1 1

0.660.5

0 0 0

0.5 0.6 0.5 Modules that depend on m

Set of stable dependencies to lower layers

For all modules

S. Sarkar, G. M. Rama, and A. C. Kak, “API-based and information-theoretic metrics for measuring the quality of software modularization,” IEEE Trans. Softw. Eng., vol. 33, pp. 14–32, January 2007.

© ABB August 24, 2012 | Slide 8

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

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