Recovering a software architecture from source is challenging. Automated methods generally provide architectural descriptions which are not very useful. Manual architecture recovery methods are very labour intensive. SyMAR is a method for manual software architecture recovery which aims to efficiently extract a software architecture description from vertical slices through the software system.

1. A Systematic Method for Software Architecture Recovery
A Systematic Method
for
Software Architecture Recovery
Fritz Solms
SESAr Research Group
Dept of Computer Science, University of Pretoria
April 30, 2015

2. A Systematic Method for Software Architecture Recovery
Introduction
Context
Ongoing 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

3. A Systematic Method for Software Architecture Recovery
Introduction
Motivation
Automated Software Architecture Recovery methods
do not currenly expose architectural abstractions sufficiently
only partially useful
Manual Software Architecture Recovery Methods
Very labour intensive
Do not scale well

4. A Systematic Method for Software Architecture Recovery
Introduction
Research Question
Can we devise a manual (tool assisted) method which
can be used to recover software architecture of large industrial
systems
exposes the required architecural abstractions
Are the outputs useful?

5. A Systematic Method for Software Architecture Recovery
Introduction
What is Software Achitecture?
Many different definitions of software architecture
Choose one which
is consistent with
architecture analysis aproaches
reference architectures
allows for
well defined boundary btw application and architecture design
continuous addition of application functionality within defined
software architecture.
Definition
Software Architecture is the specification of the software infrastructure
addressing non-functional requirements within which application
functionality addressing primary functional requirements can be deployed
and executeda
.
aNon-functional reuirements may give rise to sedondary functional requirements

6. A Systematic Method for Software Architecture Recovery
Related work
Architecture Recovery Output
ISO/IEC/IEEE 42010:2011
consensus around requirements for an architectural description
does not prescribe content
Pinzger & Gall 2002, van Heesch et al 2012
quality & efficiency of architecture decision recovery
improved by recovering architectural abstractions
ADLs → very low adoption rate
few can capture abstractions explicitly
some: patterns/styles
tactics: only aspect-oriented ADLs (e.g. AO-ADL)
QRs modeled as cross-cutting concerns
addressed through tactics modeled as aspects
No explicit support for concepts & constraints for application
components.

7. A Systematic Method for Software Architecture Recovery
SyMAR
SyMAR
guides software architects
through (efficient) manual recovery of software architecture
relies on request tracing as primary tool
to discover architecturally significant components.
Output
ISO/ISEC/IEEE 42010 compliant architectural description
containing the architectural abstractions

8. A Systematic Method for Software Architecture Recovery
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]

9. A Systematic Method for Software Architecture Recovery
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 extended
own 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

10. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Preparation
Preparation
Obtain access to resources
people
documentation
may be largely incorrect/out of date
source
Scope briefing
Case study:
1 hour overview and history presentation by lead architect
Some outdated, very high-level documentation
Full source code
Access to project architects for questions

11. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Extraction
Extraction
Extract info from source code
Relies primarily on request traces
generated for
different access channels
representative use cases
Request traces selected for architectural coverage
different infrastructural concerns
integration/access channels
different quality requirements
different responsibility domain
Partially automated using tracing or profiling tools.

12. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Extraction
Extraction: Case study

13. A Systematic Method for Software Architecture Recovery
An Industrial 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, abstracting
1 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,
and
5 application components into concepts and constraints within which
they are designed and implemented.
Abstractions captured in SyMAR views.

14. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Abstracting Requests into Architectural Responsibilities
and Components
Analyze service requests for responsibilities they address
Responsibilities grouped into responsibility domains
Highest level responsibility domains
= responsibility domains for current LOG
assigned to abstract architectural components
captured in Responsibility Allocation View

15. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Abstracting To Architectural Responsibilities: Case
study
<<Responsibilty>>
Persist Domain Objects
<<Responsibilty>>
Encode Business Logic
<<Responsibilty>>
Map Domain Objects
to Database
<<Responsibilty>>
Demarshall Request
PersistenceContextApplicationAdapterClient Application
<<Responsibilty>>
Human adapter
<<Responsibilty>>
Route Request
ServiceBean DatabaseRouter

16. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Request Trace Abstraction
Full request traces generally very deep
include requests made to very low level components
abstract by including only requests made to components identified in
previous step.
prune msgs exchanged within responsibility domains
Room for automation

17. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Abstracting Request Traces: Case study
Remove all msgs exchanged within responsibility domains
i.e. 2, 3, 5, 6, 7, 8, 9, 16

18. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Abstracting Infrastructure into Architectural Patterns
Analyze pruned request traces for msg exchanged patterns
to identify patterns used to constrain infrastructure between
architectural components for LOG.
Examples
Layered architectural pattern
synchronous requests fed down through layers
corresponding 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?

19. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Abstracting to Patterns: Case study
Based 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.

20. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
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 are
concretely addressed
Tactics commonly applied at
access and integration channels
interception points
point cuts for aspects
Also study frameworks for patterns they implement.

21. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Abstracting to Architectural Tactics: Case study
Client Layer Access Layer Routing
Layer
Services
Layer
Domain
Layer
Persistence
Layer
<<Tactic>>
Load
Balancing
<<Tactic>>
Encryption
<<Tactic>>
Encryption
<<Tactic>>
Runtime
Lookup
<<Tactic>>
Reference
Caching
<<Tactic>>
Object
Caching
<<Tactic>>
Connection
Pooling
<<Tactic>>
Object-Relational
Mapping
<<Tactic>>
Role-Based
Authorization
<<Tactic>>
Data Access
Authorization
<<Tactic>>
Binary-
Protocol
Mapping

22. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Concepts and Constraints for Application Components
Often specified by Software Architecture
e.g. SOA
composable, stateless, discoverable services within pipes and filters
infrastructure
Java-EE
enterprise beans as published application components (not directly
accessible)
entities as persisted, transferable domain objects
AUTOSAR
ECUs decoupled through Virtual Function Bus
More abstractly, application functionality in
pure functions
stateless services
stateful objects
Decoupling through contracts in either case.

23. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Concepts and Constraints for Application Components
Java-EE architecture evolved from SOA
Process spec → stateless session beans
object paradigm (stateful SBs) not used
Domain objects as JPA entities.

24. A Systematic Method for Software Architecture Recovery
An Industrial Case Study
Abstraction
Lower Levels of Granularity
Process repeated ∀ architectural components of current LOG
For case study:
3 levels sufficient
3’rd LOG components provided by frameworks
Not components developed for this instance architecture

25. A Systematic Method for Software Architecture Recovery
Results
Results
Method applied to case study & 2 other industrial architecture
recovery projects
Case study results
Had to traverse ≈ 5% of source code
2-3 LOGS sufficient for all components.
Method enabled single analyst to obtain architectural description
In all 3 projects
relatively clean separation btw architectural & application
components
Client found resultant architectural description useful.
Several architectural improvement initiatives faclitated through
architectural description.
Limitations:
source code must be available
not suitable for systems for which infrastructural code is extensively
intertwined within application code

26. A Systematic Method for Software Architecture Recovery
Conclusions
Conclusions
Method usable
for systems with relatively good separation of architectural &
application components.
Output: ISO/IEC/IEEE 42010 compliant architectural description
explicit 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