1. Software Architecture in Practice
Architectural Reconstruction
Credits: Original slideset made by Klaus Marius Hansen

2. Literature Main [van Deursen et al., 2004]
van Deursen, A., Hofmeister, C., Koschke, R., Moonen, L., Riva, C.(2004) Symphony: View-Driven Software Architecture Reconstruction. In Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04), pp
[Bass et al., 2013], Chapter 20
Background
[Koschke, 2005a]
Koschke, R. (2005). What architects should know about reverse engineering and reengineering. In Proceedings of the Third Working IEEE/IFIP Conference on Software Architecture (WICSA’05), pp 4-10
[Gorton and Zhu, 2005]
Gorton, I. and Zhu, L. (2005) Tool Support for Just-in-Time Architecture Reconstruction and Evaluation: An Experience Report. In Proceedings of ICSE'05, pp

3. Motivation
Many software engineering activities need correct architectural information, in, e.g.,
Evolution
Application integration
(Architecture) evaluation
Architectural documentation is ideally updated as decisions are taken
Architecture-as-design = architecture-as-implemented

4. Motivation Unfortunately, architectural documentation is often
Outdated in that new decisions are not reflected, e.g., because of time pressure
Wrong in that the information in the documentation was never correct
Or plainly missing !
However, the system-as-implemented embodies the (architectural) design and implicitly design decisions
Architectural reconstruction may help in retrieving these

5. Architecture reconstruction
Architecture reconstruction is the process of obtaining a documented architecture for an existing system
Why is architecture reconstruction difficult?
Implementation and architecture/design are on different abstraction levels
E.g., source code versus CC view
Non-local decisions may never be reflected in code
E.g., a decision on using a layered architectural style

6. Architecture Reconstruction
One consequence is that no comprehensive tool exists for architecture reconstruction – needs to be tailored to problem
The Symphony process is a viable process to structure the work
I have supervised several works that use the Symphony proces to aid in real-world reconstructions

7. Exercise
Do you have comprehensive architecture documentation of all systems in your organization?
Is it a problem?

8. Software Architecture Reconstruction
The process of obtaining a documented architecture for an existing system
Architectural requirements
Architectural views
Architectural decisions …
Essentially a design recovery process
Extract -> abstrac t-> present
Data gathering
Knowledge inference
Information presentation
Hard for software architectures
Potentially a big gap between implementation and architecture

9. Process: “Symphony” We will look at the “Symphony” process Concepts
Created a.o. by Nokia Research
Concepts
Views and viewpoints as in IEEE 1471
Source view
View that can be extracted from artifacts of a system
Not all source views are architectural views
E.g., abstract syntax tree
Target view
View that describes architecture-as-implemented with the information needed for the purpose of the reconstruction
E.g. CC viewpoint to assess performance bottle-neck
Hypothetical view
Hypothetical architecture-as-designed, (inaccurate, maybe postulated)
Interview with architects, existing docs

10. Symphony Stages
Reconstruction design
Reconstruction execution

11. Reconstruction design
Performance issues, maintenance costs, replacements, poor reliability, …
Problem elicitation
“Business case” for reconstruction
What is the problem?
Requires the stakeholders (testers, developers, managers, users,…)
Concept determination
What architectural information is needed to solve the problem?
Which viewpoints are relevant?
Define target and source viewpoints
Define mapping rules, i.e. how does source view translate into target view?
Often heuristics and informal approaches
x.java in directory y
=>
Class X is-in Layer Y;
classname ends-in ‘Strategy’
Class plays Strategy role in Strategy

12. Reconstruction execution
Data gathering
i.e. collect the data: static+dynamic techiques
‘the truth is in the source’
Knowledge inference
Get the target view from the source view
Often iterative and highly manual 
Information interpretation
Decide 
Extract-abstract-present

13. Data gathering Source view in Rigi format
Sources
Running system
Build files
(Unit) tests
Configuration files
Source code
Data(base) …
Techniques
Static
Source-code-based
Manual inspection
Lexical analysis
Syntactic analysis
Fuzzy parsing
Island grammars
Semantic analyses
Dynamic
Trace collection
Profiling
Debugging
Code instrumentation, e.g., using aspects
Special runtime environment
Source view in Rigi format
Result: Repository of source views

14. Inference and Interpretation
Knowledge inference
Going from source to target view…
Techniques
Manual
E.g., Rigi [Storey et al., 1996]
Semi-automatic
E.g, SQL queries for defining grouping rules (Dali)
Automatic ?
Information Interpretation
E.g., visualizing using UML
SHRiMP is from Rigi: A Visualization Environment for Reverse Engineering

15. Henrik Bærbak Christensen
Bass § 20
Somewhat more coarse grained process
Raw View Extraction
Database Construction
Convert raw info into ‘standard form’
View Fusion
‘combines views of info in db’ 
Architecture Analysis
Test hypotheses about the architecture
My perception:
Abstract to the point of irrelevance…
Morale: Symphony process is the one to emphasize
Henrik Bærbak Christensen

16. Reverse Engineering Tool
Some examples
„Traditional“
IDE support for ‘reverse engineering’ a UML diagram based upon the source code
„Untraditional“
Rigi
DiscoTect

17. Rigi Components of the system are nodes, relationships are arcs
Lead to graphs
E.g., call graph
Example
IBM's SQL/DS system

18. MagicDraw (1): Module View

19. MagicDraw (2): Module View

20. Module View: Example Manual

21. Dynamic Views Module viewpoints are really the ‘easy case’.
Static elements ‘are’ in the code
Problems: ‘hidden dependencies’
Program A writes file in format Z that is read by program B
DB schemas, etc. etc.
The dynamic views (run-time / CC view) are even more complex
Require execution and data collection…
… and they only describe one instance of the system

22. JSeq
Jseq instruments java code and makes (textual) sequence diagrams. (And no longer maintained)
backgammon.domain.ConfigurableGame.newGame
backgammon.domain.AbstractGame.newGame
backgammon.domain.ConfigurableGame.getBoard
backgammon.domain.strategies.StandardBoard.reset
backgammon.domain.strategies.StandardBoard.putCheckerOntoBoard (x 8)
backgammon.domain.Color.getSign
backgammon.domain.strategies.AbstractBoard._notify
backgammon.domain.ConfigurableGame$LocalBoardListener.update
backgammon.view.AbstractBackgammonApplication.boardChange

23. MagicDraw (4): C&C View

24. DiscoTect: C&C View

25. Discussion
Obvious difficulties for dynamic view generation are in distributed settings 
How do we trace this central TM16 use case?

26. Henrik Bærbak Christensen
Akhera
A (now defunct) research project, used AspectJ to produce traces for Java programs…
Henrik Bærbak Christensen

27. State of the Art (2005 )
Koscke

28. Discussion Allocation view? What about rationale and decisions  ?
Docker-compose files actually are machine readable documentation of deployment
What about rationale and decisions  ?

29. Can we do better? If we cannot find the architecture in the code…
Because code is much more low level
And code is the primary artifact
Because it is what pays our paycheck
… then why do we not put the architecture back into the code???

30. Architectural Annotations

31. Henrik Bærbak Christensen
Quite a few have tried…
It is a recurring problem
I just got appointed as maintainer of this pile of (---) code and no-one knows how its architecture is…
Check
And I guess there is some on the masters produced page as well…
Henrik Bærbak Christensen