Detecting and Maintaining ArchitectureConsistency

Dr Liam O’Brien, Geoscience Australia

Personal Background25 years experience in the IT area mainly as:

• Researcher (21 years)• Reverse engineering, Reengineering, Software Architecture,

Architecture Reconstruction, SOA, Cloud Computing

• Solution Architect (past 4 years)• CSIRO – Chief Software Architect for eResearch – SOA, Cloud

Computing, Scientific Workflow, Data Management Tools andWorkflows

• Geoscience Australia – SOA, Data services, Data Processing• CO2 Infrastructure Assessment (CIAP)• Sentinel – Bushfire Hotspots• National Offshore Petroleum Information Management System (NOPIMS)• National Flood Risk Information Platform (NFRIP)

SAEroCon April 2014

Overview• Why is Architecture Important?

• Architecture Consistency and Clarity

• Architecture Inconsistencies

• Detecting Architecture Inconsistency

• Ensuring Architecture Consistency

• Architecture Reconstruction

• Examples of Architecture Reconstruction

• Reflexion Modelling

• Conclusion

SAEroCon April 2014

Why is Architecture Important?

SAEroCon April 2014

Represents earliest design decisions

• hardest to change later• most critical to get right• communication vehicle among

stakeholders

First design artifact addressing• performance• reliability

• modifiability• security

Key to systematic reuse

The right architecture paves the way for system success.The wrong architecture usually spells some form of disaster.

The right architecture paves the way for system success.The wrong architecture usually spells some form of disaster.

• transferable, reusable abstraction

SAEroCon April 2014

From: http://www.codingthearchitecture.com/pages/book/structure-and-guidelines-consistency-and-clarity.html

Consistency and Clarity

Architecture Conceptual Integrity“The goal of “conceptual integrity” or unity of design: Thebest programs and software systems exhibit a sense ofconsistency and elegance, as if they are shaped by asingle creative mind, even when they are in fact the productof many. The fiendish problem is less how to create thatsense in the first place than in how to preserve it against allthe other pressures that come to bear throughout theprocess of writing software.”

Frederick P Brooks Jr

The Mythical Man-Month: Essays on SoftwareEngineering

SAEroCon April 2014

Architecture Inconsistencies

• Differences between architectural documentation andimplemented code

• Name Inconsistencies – difficult to catch

• Interface Inconsistencies – ill-defined interfaces

• Behavioural inconsistencies - differences

• Interaction Inconsistencies – protocol/sequence

• Refinement Inconsistencies – high-level to low-level –adding or removing something, or violating (inter-layerbridging)

SAEroCon April 2014

Causes of Architecture Inconsistencies

• Differences between architecture views

• Implementation does not follow the architecture

• Uncontrolled evolution of code

• Architecture documentation not kept up to date

SAEroCon April 2014

Example of Architecture Inconsistency from CIAP

SAEroCon April 2014

CIAP GUI

SAEroCon April 2014

Example of Architecture Inconsistency from CIAP

SAEroCon April 2014

Example of Architecture Inconsistency from CIAP

SAEroCon April 2014

Example of Architecture Inconsistency from CIAP

SAEroCon April 2014

Example of Architecture Inconsistency from CIAP

SAEroCon April 2014

Ensuring Architecture ConsistencyFrom Implementation Perspective

• Code Review

From Architecture Perspective

• Architecture Review• Other members of Architecture team• Architecture Committee (technical people from across

Organisation)

Enforcing Architecture Consistency

• Disabling access to Databases

• Logging and Auditing of the system

SAEroCon April 2014

Reviews and Inspections of Code/ArchitectureReviews and inspections of code and architecture involveseveral participants and activities

Participants: Coders, Architects, Project Managers,Reviewers

Activities:• Preparation for inspection of code and architecture material

• Preparation of participants

• Review/Analysis of code and architecture

• Analysis of the review results and recommend actions

• Follow-up and Finalisation

SAEroCon April 2014

Architecture Reviews

SAEroCon April 2014

More thorough architecture reviews – ATAM, etc

Detecting Architecture InconsistenciesDetecting inconsistencies between the implementedsystem and the architecture can be done using:

• Architecture Reconstruction

• Reflexion Modelling

SAEroCon April 2014

Architecture ReconstructionArchitecture Reconstruction is the process ofreconstructing or recovering the architecture of animplemented system.

Also known as Architecture Recovery.

SAEroCon April 2014

Source Code,Documentation

Source Extraction

Architecture ViewComposition

Source Model,

Selected Architecture Views

Architectural Views, Styles,Patterns, Drivers

Extraction

Fusion

Reconstruction

Architecture Reconstruction• ARMIN – Architecture Reconstruction Tool

SAEroCon April 2014

Repository

Navigator

product andmodel

browsing

Aggregator

creation ofaggregation

models

ProjectManager

definition ofproducts and

models

Architects

creation ofarchitecture

views

ARMIN Tool

Interpreter ARL Experts

SourcesSources ExtractedSources

ExtractedSources

extraction

import

DesignTools

DesignTools

AnalysisTools

AnalysisTools

export

Architecture Consistency – Arch Recon Example 1Embedded Automotive Control System

Consistency/Conformance Exercise• Determine if the architecture as documented reflects the as-built

system.

• Layered system with three layers – ApplicationSW, Data andHardwareControl.

• In the documentation the ApplicationSW and HardwareControllayers were only connected through the Data layer and were notdirectly connected.

SAEroCon April 2014

Files KLOC Functions Macros Variables TypesC/c 61 9 376 225 180 5Header 71 2 0 1055 311 56Total 132 11 376 1280 491 61

Example – Highest-level System View – Layers

SAEroCon April 2014

Exploring the Data Layer – 1

SAEroCon April 2014

Data Accesses

Exploring the Data Layer – 2

SAEroCon April 2014

Calls

Example 2Automotive Infotainment System

Consistency of the Architecture

• Determine if the Top Level Architecture as Documentedreflects the as-built system

• Produce views of several layers to determine consistencyand if they conform to expectations

SAEroCon April 2014

Code Size Files ClassesC/C++ 2.58MLOC 6484 1018Java 1.78MLOC 9570 22542Total 4.36MLOC 16054 23560

Another Example System – CMM Layer

SAEroCon April 2014

MM_SERVICES - Dependencies

SAEroCon April 2014

Reflexion Modelling for Architecture ConsistencyChecking

SAEroCon April 2014

Conclusion• Architecture consistency not easy to enforce

• Architecture inconsistencies will occur

• Needs mechanisms to detect inconsistencies

• Don’t want to make detection and enforcement too onerouson implementers or architects

• Similar architecture inconsistencies happen in InfrastructureArchitecture

SAEroCon April 2014

QUESTIONS?Questions or requests for meetings for further information

SAEroCon April 2014

References• Kazman, R., O’Brien, L., and Verhoef, C., Architecture

Reconstruction Guidelines, CMU/SEI-2001-TR-026.

• Van Deursen, et al, Symphony: view driven softwarearchitecture reconstruction, WICSA 2004.

• Stoermer, C, O’Brien, L., Verhoef, C., Moving Towards QualityAttribute Driven Software Architecture Reconstruction, WCRE2003.

• Murphy, G, Notkin, D., Sullivan, K., Software reflexion models:bridging the gap between source and high-level models,SIGSOFT 1995.

• Buckley, J., Mooney, S., Rosik, J., Ali, N., JITTAC: a just-in-time tool for architectural consistency, ICSE 2013.

SAEroCon April 2014