Sponsored by the U.S. Department of Defense © 2004 by Carnegie Mellon University Version 1.0 IWPC page 1 Pittsburgh, PA Architectural Views through Collapsing Strategies Liam O’Brien Christoph Stoermer Chris Verhoef

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 2 Motivation - 1 Initial Position 1.Software Architectures are often hard to understand 2.Architecture documentation may not reflect the current state of the implemented system 3.Stakeholders may not be able to find a particular architectural view in the documentation 4.Often the architecture experts are not available for interview 5.There is often a need to use the documentation and possibly the underlying components

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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]

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 5 Collapsing – Example - 1 Schema SourceDestination writefunctionvariable readfunctionvariable Rigi Tuples SourceDestination write fct1var1 readfct2 var1 readfct3var1 fct2fct3fct1 var1

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 6 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. fct1fct2fct3 var1 fct-pc

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 7 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 fct1 fct-wc fct2fct3 var1

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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. var1fct2var1fct3 fct2-fcfct3-fc var1fct1 fct1-fc Note: no relation between containers

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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 var1fct2var1fct3 fct2-fcfct3-fc var1fct1 fct1-fc Note: relations between containers

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 10 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. var1fct2var1fct3 fct2-fcfct3-fc var1fct1

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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.

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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.

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 13 Characteristics of Multi-collapses We identified three characteristics of multi-collapses: 1.Multiple occurrence of entities 2.Disappearance of relations between containers 3.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

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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.

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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.

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 16 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. Model Sub-model Shared Utilities

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 17 Case Study – STA - 3 Based on information needs and interviews with the developers/maintainers we identified the following architectural viewtypes to be generated:

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 18 Case Study – STA Schema model file function variable directory includes callsaccesses usedBy setssetBy contains constainsDir constainsFile consistOf message

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 19 Case Study – STA - 4 – Model view

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 20 Case Study – STA - 5 – Module subgraph

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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

© 2004 by Carnegie Mellon University Version 1.0 IWPC page 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.