symar - a systematic method for software architecture recovery

A Systematic Method for Software Architecture Recovery

A Systematic Methodfor

Software Architecture Recovery

Fritz SolmsSESAr Research Group

Dept of Computer Science, University of Pretoria

April 30, 2015


Introduction

ContextOngoing system maintenance

⇒ architectural drift & erosion

↑ complexity, maintenance costs & arch failure& ↓ understanding ⇒ accelerates process

only definitive info on architecture

Source artifacts (e.g. code)

⇒ Architecture Recovery

information extraction, abstraction & description−→ architectural description


Introduction

Motivation

Automated Software Architecture Recovery methods

do not currenly expose architectural abstractions sufficientlyonly partially useful

Manual Software Architecture Recovery Methods

Very labour intensiveDo not scale well


Introduction

Research Question

Can we devise a manual (tool assisted) method which

can be used to recover software architecture of large industrialsystemsexposes the required architecural abstractions

Are the outputs useful?


Introduction

What is Software Achitecture?

Many different definitions of software architecture

Choose one whichis consistent with

architecture analysis aproachesreference architectures

allows for

well defined boundary btw application and architecture designcontinuous addition of application functionality within definedsoftware architecture.

Definition

Software Architecture is the specification of the software infrastructureaddressing non-functional requirements within which applicationfunctionality addressing primary functional requirements can be deployedand executeda.

aNon-functional reuirements may give rise to sedondary functional requirements


Related work

Architecture Recovery Output

ISO/IEC/IEEE 42010:2011

consensus around requirements for an architectural descriptiondoes not prescribe content

Pinzger & Gall 2002, van Heesch et al 2012quality & efficiency of architecture decision recovery

improved by recovering architectural abstractions

ADLs → very low adoption rate

few can capture abstractions explicitlysome: patterns/stylestactics: only aspect-oriented ADLs (e.g. AO-ADL)

QRs modeled as cross-cutting concernsaddressed through tactics modeled as aspects

No explicit support for concepts & constraints for applicationcomponents.


SyMAR

SyMAR

guides software architects

through (efficient) manual recovery of software architecturerelies on request tracing as primary tool

to discover architecturally significant components.

OutputISO/ISEC/IEEE 42010 compliant architectural description

containing the architectural abstractions


SyMAR

Overview of SyMAR

<<structured>>

abstraction and description

identify architectural responsibilities for level of granularity and abstract assign to

abstract architectural components

abstract infrastructure to architectural style/pattern for component

map architectural components onto framework components

abstract code addressing quality requirements into tactics

abstract application components into concepts and constraints for

application components

project out request trace views for level of granularity

ACCV

RTVs

FMV

RAV

SV

TV

<<structured>>

preparation

documentation analysis

interviews<<structured>>

extraction

request tracing

select component

[there are lower level architecturally significant components]

[there no more lower level architecturally significant components]


An Industrial Case Study

Case Study

End 2012 → requested to

reverse engineer SA of large corporate banking system> 3× 106 lines of own code

Original architecture

based on SOA framework for banking systems bought from vendor.processes:

standard vendor provided processes customized and extendedown processes added

All within architecture provided by vendor product

Vendor architecture failed to realize quality requirements.bought source to incorporate some architetcural elements

within new home-grown Java-EE architecture

Further 10 years of development within new architecture



Preparation

Preparation

Obtain access to resources

peopledocumentation

may be largely incorrect/out of date

source

Scope briefing

Case study:

1 hour overview and history presentation by lead architectSome outdated, very high-level documentationFull source codeAccess to project architects for questions



Extraction

Extraction

Extract info from source code

Relies primarily on request tracesgenerated for

different access channelsrepresentative use cases

Request traces selected for architectural coveragedifferent infrastructural concerns

integration/access channelsdifferent quality requirementsdifferent responsibility domain

Partially automated using tracing or profiling tools.



Extraction

Extraction: Case study



Abstraction

Abstraction

Used to identify abstractions

Abstractions expose architectural decisions made

e.g. layering, resource pooling, clustering, . . .

Starts with manual inspection of request traces, abstracting1 request traces to level of granularity,2 system elements into abstractions with assigned architectural

responsibilities,3 infrastructural constraints into architectural patterns,4 processes addressing quality requirements into architectural tactics,

and5 application components into concepts and constraints within which

they are designed and implemented.

Abstractions captured in SyMAR views.



Abstraction

Abstracting Requests into Architectural Responsibilitiesand Components

Analyze service requests for responsibilities they address

Responsibilities grouped into responsibility domains

Highest level responsibility domains

= responsibility domains for current LOGassigned to abstract architectural componentscaptured in Responsibility Allocation View



Abstraction

Abstracting To Architectural Responsibilities: Casestudy

<<Responsibilty>>

Persist Domain Objects

<<Responsibilty>>

Encode Business Logic

<<Responsibilty>>

Map Domain Objectsto Database

<<Responsibilty>>

Demarshall Request

PersistenceContextApplicationAdapterClient Application

<<Responsibilty>>

Human adapter

<<Responsibilty>>

Route Request

ServiceBean DatabaseRouter



Abstraction

Request Trace Abstraction

Full request traces generally very deep

include requests made to very low level componentsabstract by including only requests made to components identified inprevious step.prune msgs exchanged within responsibility domains

Room for automation



Abstraction

Abstracting Request Traces: Case study

Remove all msgs exchanged within responsibility domains

i.e. 2, 3, 5, 6, 7, 8, 9, 16



Abstraction

Abstracting Infrastructure into Architectural Patterns

Analyze pruned request traces for msg exchanged patterns

to identify patterns used to constrain infrastructure betweenarchitectural components for LOG.

ExamplesLayered architectural pattern

synchronous requests fed down through layerscorresponding responses ravel up the layers.

Controller pattern

requests all disseminate from controller

Pipes & Filters

asynchronous requests along a pipeline.

Blackboard pattern

requests made from various components to blackboard.

Future automation based on Pahl’s pattern formalization work?



Abstraction

Abstracting to Patterns: Case studyBased on analysis of msg exchange patterns in pruned request trace

Routing Layer

Module Delegate ProcessService

Persistence Layer

Database

Access/Adapter Layer

<<Message-Driven Bean>>

QueueProcessor

<<Servlet>>

CoreRouter<<Servlet>>

Java-WS

<<webWebServicesClient>>

System Client

Client Layer

Java Swing App Mobile App

Infrastructure Layer

Persistence Context EntityManager O/R Mapper

<<StatelessSessionBean>>

Business Layer

<<Entity>>

<<POJO>>

Concepts for application functionality.



Abstraction

Abstracting to Architectural Tactics

Tactics

e.g. thread or connection pooling, database caching, queueing,interception, . . .

Recovering tactics

exposes architectural decisions on how quality requirements areconcretely addressed

Tactics commonly applied at

access and integration channelsinterception pointspoint cuts for aspects

Also study frameworks for patterns they implement.



Abstraction

Abstracting to Architectural Tactics: Case study

Client Layer Access Layer Routing

Layer

Services

Layer

Domain

Layer

Persistence

Layer

<<Tactic>>

LoadBalancing

<<Tactic>>

Encryption

<<Tactic>>

Encryption<<Tactic>>

RuntimeLookup

<<Tactic>>

ReferenceCaching

<<Tactic>>

ObjectCaching

<<Tactic>>

ConnectionPooling

<<Tactic>>

Object-RelationalMapping

<<Tactic>>

Role-BasedAuthorization

<<Tactic>>

Data AccessAuthorization

<<Tactic>>

Binary-ProtocolMapping



Abstraction

Concepts and Constraints for Application Components

Often specified by Software Architecturee.g. SOA

composable, stateless, discoverable services within pipes and filtersinfrastructure

Java-EE

enterprise beans as published application components (not directlyaccessible)entities as persisted, transferable domain objects

AUTOSAR

ECUs decoupled through Virtual Function Bus

More abstractly, application functionality in

pure functionsstateless servicesstateful objects

Decoupling through contracts in either case.



Abstraction

Concepts and Constraints for Application Components

Java-EE architecture evolved from SOAProcess spec → stateless session beans

object paradigm (stateful SBs) not used

Domain objects as JPA entities.



Abstraction

Lower Levels of Granularity

Process repeated ∀ architectural components of current LOG

For case study:3 levels sufficient

3’rd LOG components provided by frameworksNot components developed for this instance architecture


Results

Results

Method applied to case study & 2 other industrial architecturerecovery projects

Case study resultsHad to traverse ≈ 5% of source code

2-3 LOGS sufficient for all components.

Method enabled single analyst to obtain architectural descriptionIn all 3 projects

relatively clean separation btw architectural & applicationcomponents

Client found resultant architectural description useful.

Several architectural improvement initiatives faclitated througharchitectural description.

Limitations:

source code must be availablenot suitable for systems for which infrastructural code is extensivelyintertwined within application code


Conclusions

Conclusions

Method usable

for systems with relatively good separation of architectural &application components.

Output: ISO/IEC/IEEE 42010 compliant architectural descriptionexplicit description of architectural abstractions

patterns, tactics, concepts & constraints for appl components

Tools can be used to reduce manual labour

used only tracing tools in study