detecting and maintaining architecture consistency · architecture reconstruction • armin –...
TRANSCRIPT
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