Architectural Views through Collapsing Strategies

1. Architectural Views through Collapsing Strategies Liam O’Brien Christoph Stoermer Chris Verhoef

2. Motivation - 1 Initial Position • Software Architectures are often hard to understand • Architecture documentation may not reflect the current state of the implemented system • Stakeholders may not be able to find a particular architectural view in the documentation • Often the architecture experts are not available for interview • There is often a need to use the documentation and possibly the underlying components

3. Architecture Reconstruction • Architecture Reconstruction is the process by which architectural views of an implemented system are obtained from existing artifacts. • In order to generate views of the architecture during the reconstruction process it is necessary to build abstractions of the system and one of the mechanism used for this is collapsing

4. Collapsing • Collapsing is a mechanism to aggregate detailed source information into higher levels of abstraction. • For example, many systems use naming conventions to express what in fact are architectural aspects. A good collapsing strategy is to combine source elements, such as functions, that satisfy a particular naming convention to recover the intended architectural aspects • Collapsing is achieved by: • clustering of related parts [Lakhotia 97], • lattice partitioning [van Deursen and Riva 02], • aggregation into containment-hierarchies [Finnegan, et al. 97]

5. fct1 fct2 fct3 var1 Collapsing – Example - 1 • Schema • Source Destination • write function variable • read function variable • Rigi Tuples • SourceDestination • write fct1 var1 • read fct2 var1 • read fct3 var1

6. var1 fct1 fct2 fct3 fct-pc Collapsing – Example - 2 • Pattern-Collapsed – collapse entities of particular type such as function • A motivation for this particular case could be the aggregation of all functions that share coherent functionality, for example all functions of a user interface component.

7. fct1 var1 fct-wc fct2 fct3 Collapsing – Example - 3 • Write-Collapsed – collapse on a relation type such as write • A motivation for this particular case could be the segmentation of variables and functions to form a cohesive block in a reengineering environment

8. Collapsing – Example - 4 • Function-Collapsed – collapse all descendants of an entity type such as function • We name collapsing of entities and relations multi-collapsing when there is no unique assignment to a container possible. • The term multi-collapses refers to those entities. fct1 var1 Note: no relation between containers fct1-fc fct2 var1 fct3 var1 fct2-fc fct3-fc

9. Collapsing – Example - 5 • Function-Collapsed – collapse all descendants of an entity type such as function • Add a relation between an entity and each instance of the multi-collapsed item • Explosion of relations with large amounts of data - cluttered graphs fct1 var1 Note: relations between containers fct1-fc fct2 var1 fct3 var1 fct2-fc fct3-fc

10. fct1 var1 fct2 var1 fct3 var1 fct2-fc fct3-fc Collapsing – Example - 6 • Read-Collapsed – collapse on a relation type in this case read • Relation between fct1 and var1 in each container cannot be resolved – it is unclear to which container the relation should go • We could have introduced two relations from fct1 to both containers but this does not scale well for large amounts of data and reduces the understanding of the resulting graph.

11. Multi-collapses - 1 • Collapsing strives to assign entities uniquely in top-down hierarchies, such as a module hierarchy consisting of a system, sub-systems, layers, modules, etc. • In order to generate architectural views using collapsing there is a need to deal with entities that may be assigned to more than one higher-level abstraction. • Into the views that we generate we have introduced multi-collapses, entities such as functions and variables, that are not uniquely assignable to a particular architectural element, such as a layer. • Multi-collapses have advantages, for example, the visualization of a system from a data perspective, where all elements that access or define a variable are collapsed into the corresponding data container. In this case, a function that accesses several variables will be collapsed into several data containers.

12. Multi-collapses - 2 • Multi-collapses are either • the result of applying incorrect collapsing strategies or • an excellent starting point for software analysis to gain better understanding of the existing software. Based on this assertion we implemented collapsing and visualization support for multi-collapses. The principles of multi-collapses are widely applicable and can be implemented in many reconstruction tool environments.

13. Characteristics of Multi-collapses • We identified three characteristics of multi-collapses: • Multiple occurrence of entities • Disappearance of relations between containers • Uncertainties with respect to ownership and responsibilities • Situations where multi-collapses may be useful: • Generating views from a data perspective – multi-collapsing functions into data containers • Generating call-graph views – collapsing files or data into a function container

14. Collapsing and Multi-collapses • The collapsing strategy illuminates an aspect of the system, such as write-relations or read-relations. It is therefore essential to develop a concept about views and their interpretation for a particular system before performing collapsing operations. • The development of the schema is intertwined with the development of a collapsing strategy to achieve the goals of the reconstruction.

15. Case Study – STA - 1 • We consciously detected multi-collapses as a useful mechanism was during a case study for the Satellite Tracking Agency (STA). • The STA supports efforts to develop, acquire, and deploy satellite-tracking systems. In this case, the STA wanted to better understand the architecture of one of its legacy systems, the Satellite Tracking System (STS), to be able to port the system to a new environment. • The STS consists of about 500KLOC, which is a mixture of C, C++, and Fortran that currently runs in a Silicon Graphics environment.

16. Model Sub-model Sub-model Sub-model SharedUtilities Case Study – STA - 2 • The STS is a classified system and access to the system and any information about it is tightly controlled. • As a result the reconstruction of the real system was performed by the developers/maintainers of the STA.

17. Case Study – STA - 3 • Based on information needs and interviews with the developers/maintainers we identified the following architectural viewtypes to be generated:

18. model directory 1 1 constainsDir consistOf constainsFile includes file 1 1 contains sets setBy 1 calls accesses function variable usedBy message Case Study – STA - 3 - Schema

19. Case Study – STA - 4 – Model view

20. Case Study – STA - 5 – Module subgraph

21. Conclusions • Depending on the collapsing strategy chosen during the abstraction process to generate architecture views there may be a need for multi-collapses. • Multi-collapses can be very useful in understanding a system or particular aspects of the system as they allow the information relevant to a container to be included within the container rather than having that information outside of the scope of the container. • Multi-collapses also • reduce the clutter within architectural views • assist the understanding of the system by allowing better hierarchical views of the system to be generated

22. Future Work • We would like to: • Carry out other case studies to further investigate collapsing strategies that involve multi-collapses and their impact on generating and analyzing architectural views • Investigate how the presence of multi-collapses affects the complexity of a container and the difficulty in understanding a container • Are there metrics, such as the number of multi-collapses within a container, that would give a guide to the complexity of a container? • Investigate how the presence and number of multi-collapses relate to quality attributes, for example how the presence of multi-collapses affect the modifiability of a container or the system overall.