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

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 122-132 [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 514-523

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

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

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

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

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

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

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

Symphony Stages Reconstruction design Reconstruction execution

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

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

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

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

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 CS@AU Henrik Bærbak Christensen

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

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

MagicDraw (1): Module View

MagicDraw (2): Module View

Module View: Example Manual

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

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

MagicDraw (4): C&C View

DiscoTect: C&C View

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

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

State of the Art (2005 ) Koscke

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

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???

Architectural Annotations

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 http://www.daimi.au.dk/~hbc/ProjectReports/index.html And I guess there is some on the masters produced page as well… CS@AU Henrik Bærbak Christensen