Proceedings of the Sixth European Conference on Software Maintenance and Reengineering (CSMR 2002), IEEE Computer Society

Press, 11-13 March 2002 in Budapest, Hungary.

Combining Static and Dynamic Views

for Architecture Reconstruction

Claudio Riva and Jordi Vidal Rodriguez

Nokia Research Center
Software Architecture Group
P.O. Box 407, FIN-00045 NOKIA GROUP
Tel.: +358 50 483 7403, Fax.: +358 7180 36308
{claudio.riva | jordi.vidal-rodriguez}@nokia.com

Abstract of a software architecture. The logical view is primarily

concerned with the functional requirements of the system.
Static analysis aims at recovering the structure of a It should describe how the system is partitioned and what
software system, while dynamic analysis focuses on its are the relationships among its parts. The process view is
run time behaviour. We propose a technique for focused on the dynamic aspects of the architecture
combining the analysis of static and dynamic description and should describe the run-time behaviours
architectural information to support the task of of the system. Soni, Nord and Hofmesiter [2] also
architecture reconstruction. The approach emphasises the propose four different architectural views that are used to
correct choice of architecturally significant concepts for describe software architectures: conceptual architecture,
the reconstruction process and relies on abstraction module interconnection architecture, execution
techniques for their manipulation. The technique allows architecture and code architecture. The separation
the software architect to create a set of architectural between static (conceptual, module and code architecture)
views valuable for the architecture description of the and dynamic aspects (execution) is evident in this
system. approach too. In our approach, we follow the definition of
To support our technique, we outline an environment that software architecture given in [13] and we consider the
relies on hierarchical typed directed graphs to show the above-mentioned models as a practical way for describing
system’s structure and message sequence charts for its the software architecture of a system.
behaviour. The main features of the environment are: In both the approaches, multiple views obtained from
visualisation of static and dynamic views, synchronisation different perspectives are necessary for describing and
of abstractions performed on the views, scripting support understanding software architectures. During the forward
and management of the use cases. The approach and the engineering phase, the views are created by the minds of
environment are demonstrated with an example. the architects who are establishing the fundaments of the
Keywords software system implementation. These views are then
Software Architecture, Reverse Engineering, MSC, analysed and reviewed to validate the system architecture.
Dynamic Analysis, Architecture Reconstruction. Once the development has started (an incremental and
iterative process), the architectural views have to been
1 INTRODUCTION maintained and synchronised with the actual
A well-accepted way to think of a software architecture is implementation. Either for monitoring the development
the “4+1 View” model proposed by P. Kruchten [9]. The process or for validating the implementation, the
model suggests organising the architecture descriptions in architects need updated information about the system
five different categories, called views: logical view, architecture. This poses the need for applying reverse
process view, physical view and development view. The engineering techniques aimed at extracting the
fifth view, called scenarios or use cases, is used to architectural information from the actual implementation
illustrate and validate the four views. The “4+1 model” of the system.
separates the description of the static and dynamic aspects
In our previous work [17], we have developed a set of The major shortcomings of the current approaches are
tools aimed at supporting specific reverse engineering (1) architectural level is not the primary focus because
techniques that we call reverse architecting or most of the tools focus on source-level program
architecture reconstruction. These techniques and tools understanding, (2) lack of automation in the extraction
are mainly focused with the extraction of architectural and analysis process, (3) lack of complete graphical
information from the system implementation. A crucial visualisation of software models and (4) the tools are
problem that we are addressing is to combine the often coupled with a specific programming language and
structural and dynamic information extracted from a can be hardly used to handle generic architectural
software system. This paper describes our technique to concepts like applications, servers and subsystems.
solve this problem and the environment to support it.
3 ARCHITECTURE RECONSTRUCTION
2 RELATED WORK The description of a software architecture should
The dynamic analysis aims at describing the run time communicate the essential decisions that have been taken
behaviour of a software system. Its contribution should be in the design of a software system [13]. Architecture
considered during the reconstruction of a software reconstruction (or reverse architecting) concerns with the
architecture. Most of the methods and tools are intended task of recovering the past design decisions that have
to analyse only the static or the dynamic aspects of a been taken during the development of a system. They
system but not both at the same time. For example, SCED comprise either decisions that have been lost (because not
[7] or SCENE [8] are reverse engineering tools that focus documented or developers have left) or are unknown (for
on the dynamic analysis tasks. examples, assumptions not initially take into account).
The reconstruction is performed by examining the
Some attempts have been done to merge the dynamic
available artefacts (documentation, source code, experts)
information into static views. Systä [19] exploited Rigi
and by inferring new architectural information that is not
[16] and SCED [7] to combine static and dynamic
immediately evident. Our approach can be summarised in
analysis. Her work was focused on Java source code level
the following four-step iterative process [17]:
and program comprehension. She used the concept of
horizontal and vertical abstractions to reduce the 1. Definition of architectural concepts
complexity and raise the abstraction level of the subject
The goal is to recover and clarify the architecturally
software. She also showed how the static information can
significant concepts that build the system. These concepts
guide the dynamic analysis and how to slice the static
represent the way developers think of a system and they
view using the dynamic data.
should become the terminology of the reconstruction
ISVis [5] is a tool for analysing C applications, which process. They concern the building blocks of the system
offers vertical abstractions and restricted horizontal and the communication infrastructure that enables the
abstractions. It only provides a MSC representation, and components to communicate at runtime. In a distributed
the horizontal abstractions are limited without support for software system the architectural concepts may be
static model visualisation. applications, servers, software busses while in an
operating system they may be tasks, processes, queues,
Several tools use a kind of vertical abstraction to cope
shared memories, etc.
with message complexity. SCENE [8] uses limited size
subscenarios and hyperlinks to source to aid program 2. Data gathering
understanding. SCED [7] uses algorithmic constructs to
This phase gathers the relevant information for describing
express repetition like loops and subscenarios.
the software architecture of the system. We build a model
In the filed of tools for static and dynamic reverse of the system whose entities are instances of the concepts
engineering there is an attempt based on Dali [6] to identified in the phase 1. A correct choice of the concepts
support the static and dynamic analysis for object oriented will ensure that the model is filled with entities at the
software. Program explorer [21], supports source code, right level of abstraction. Source code is usually the most
class hierarchy, invocation and object graphs. They are dependable for static analysis and simulation for dynamic
synchronised but the tool lacks of abstraction capabilities analysis. However, documentation, software diagrams
and is C++ domain dependent. Richner et al. [15] present (for example, stored in CASE tools), experts can
a method to create views that combine static and dynamic contribute to the creation of the model.
information for object-oriented software. It is based on a
The static information is extracted by analysing the
logic programming language (Prolog) to query the data
source code and searching for architectural significant
and on digraphs for the visualisation. R. Holt has also
elements. This can be achieved with ad hoc analysers
presented a method for manipulating software
(like presented in out previous work [17]) or with existing
architecture data using the relational algebra of Tarski [3].
source code analysers (like SourceNavigator [14] and

2
Columbus [12]). to represent the system’s structure [17], and message
sequence charts (MSC) [4] for describing its behaviour.
The dynamic information is obtained by instrumenting
The representations are based on generic elements and
the source code and executing different scenarios in a
they allow us to describe software architectures for
simulator. We instrument the source code with ThirdEye
different domains. In the MSC we use concepts like
[10] and select the scenarios among the features of the
participant and message, which can be matched for
system. This choice aims at enabling the architects to
instance with subsystems at high level or function calls at
understand how the features are implemented in a system.
source code level.
3. Abstraction
To cope with the complexity of the message sequence
The model of the previous phase is usually at a very low charts, we need two mechanisms of abstractions:
level of abstraction. The goal of this phase is to enrich the horizontal and vertical abstractions. Horizontal
model with domain dependent abstractions that will lead abstractions allow us to group the participants of a MSC
to a high level view of the system. Known abstractions in order to reduce their number. As the participants are
can be easily added to the model. Unknown abstractions architectural entities in the static view, the horizontal
have to be identified by the architects, categorised, named grouping in the MSC has to be linked to the hierarchical
and then stored in the model. Such reasoning is conducted grouping in the static view. Vertical abstractions consist
manually by the architects and then fixed in a set of with grouping a set of contiguous messages into one high-
abstraction rules. The abstraction process has also to level message. This allows us to reduce the amount of
produce the architectural views that will be presented in messages and to order them according to the scenarios
the last phase (for example, according to the 4+1 model and sub-scenarios.
[9]). The abstraction process is supported by a Prolog
We follow an iterative process for refining the
system. This allows us to formally specify the abstraction
architectural model with the aid of the system knowledge.
rules and the transformations that we need to apply to the
The initial raw model is a plain representation of the
model. The abstractions rules can be reused for later
system without any hierarchical structure in the static
versions of the same system.
view and many message repetitions in the dynamic view.
4. Presentation To simplify the model, the user needs to switch between
different views (static and dynamic) and maintain them
The architects need to present the reconstructed synchronised. The synchronisation helps the user in
architecture in different formats. We allow the architects
identifying interesting relations in the structure (static
to select a particular architectural view (logical, process,
view) and behaviour (dynamic view) of the system. As
physical, development) and a particular format: graphs proposed by T. Systä [19], we group the participants of
(using Rigi) for the static views and a simplified version
the dynamic views using the static information and we
of message sequence charts [4] for the dynamic views. use the dynamic view to slice the static view to reduce its
We have also exploited UML visualisations with the tool complexity.
Venice [20].
The use cases are also a mechanism for compressing the
4 REQUIREMENTS FOR THE APPROACH dynamic view. We can break the trace into a set of
As we pointed out in Section 2, most of the approaches
hierarchical use cases, which provide a logical partition of
collect language dependent data either by parsing the
the software behaviour by functionality. A use case is the
source code or by tracing functions calls at run time. Such ordered set of messages used to accomplish a software
a low-level reverse engineering leads to a low-level system or user level goal. A scenario is a contiguous
comprehension of the subject software even after
sequence of messages that performs a concrete function
applying abstractions.
but needs the context of a use case. A scenario can appear
Our goal is to generate architecturally significant views of several times in the use case or others and contributes to
the system based on static and dynamic information. We build up and achieve the goal of the use cases. For
want to allow the architects to start from a high-level instance, a user can ‘load a file’ (use case) in a tool, and
view of the structure and behaviour of the subject the program executes many ‘read record’ calls (scenario),
software, and then to descend the levels of abstraction to which uses some lower level calls.
focus on the details of the implementation or smaller parts
We can summarise the requirements in the following
of the system.
points:
The high level view should not contain language - Architecture and programming language independent
programming artefacts as it is mainly intended to inform approach.
the architect about the important relationships of the
system’s high level components. We use directed graphs - Generation of high-level views of the structure and

3
 behaviour.
R IG I
- Interactive manipulation and synchronisation of static M enu
and dynamic views. M SC
- Abstraction widely used to cope with system
complexity (message and participant compression,
hierarchical grouping)
- Management of scenarios (and use cases).
- Support for an iterative process of data analysis C om m ands
R IG Ifile M SC file
form at form at
5 THE APPROACH
Our technique aims at creating architectural views based Prolog
on static and dynamic information. We are seeking two
key improvements for the analysis of dynamic Static Analysis
Traces
information: (1) an effective method for managing D ata

vertical and horizontal abstractions and, (2) the

integration of the static and dynamic tools in the same RE Figure 1 Integration scheme of the MSC tool in Rigi.
environment. A major constraint is on the independence Figure 2 shows the different types of abstractions
of the RE environment from the subject system. We aim supported on the dynamic view. Diagram a) shows the
at decoupling the system domain dependent information initial MSC, diagram b) shows an horizontal abstraction
from the generic concepts of the RE environment in order over participants A and B, diagram c) shows a vertical
to easily customise the environment according to any abstraction over messages M1 to M4, and diagram d)
subject system. Data gathering phase is system shows the effect of both types of abstraction, resulting in
dependent. a simplified and high-level MSC.
We use the Rigi environment for the static visualisation O rig in al M S C H o rizo n tal ab stractio n
of the system structure [17] with hierarchical typed A B C AB C
graphs. Graphs can be customised according to the
subject system with the Rigi’s concept of domain. Rigi is M1
M2 M2

an open environment that can be easily extended using M3

M4 M3
the Tcl/Tk language. We have extended Rigi to support M5 M7

the visualisation of dynamic data. Figure 1 shows the M6

M 10
M7
integration scheme. The MSC visualisation tool is able to M8
M 11

exchange data with Rigi, reacting when static abstractions M9

M 10
are performed and vice versa. The synchronisation of M 11
M 12
both views is essential because the user need to work on
the multiple views at the same time. The data from the
static and dynamic analysis are represented with Prolog H o rizo n tal an d V eritcal
ab stractio n s
V ertical ab stractio n
facts. A set of Prolog propositions is used to process the
A B C AB C
data and generated the required format for Rigi and the
MSC visualisation tool. M 1-M 4
M 1-M 4
M5
The main features of the environment are: (1) the ability M6 M7
to perform horizontal and vertical abstraction on the M7

dynamic view, (2) the integration with a static analysis M8

M 9-M 12

tool and, (3) the support for the management of M 9-M 12

hierarchical use cases, (4) a scripting facility based on

Tcl/Tk for customisation and batch processing.
Figure 2. Horizontal and Vertical abstractions in
MSC.
In the MSC file format, we have implemented a support
for the management of use cases. We need this feature to
cope with the complexity and size of traces. The use cases
provide a logical hierarchy for partitioning the long traces
that we extract. Use cases can be used to describe HMSC

4
and the scenarios bMSC [4]. During the data-gathering One key issue of the architects is to manage the
phase, we organise the use cases in a tree hierarchy organisation of the components so that they can
(nested use cases are possible) as shown in Figure 3. The collaborate to implement the system’s features. Each
hierarchy is defined during the data gathering phase, message exchange between two components creates a
inserting bookmarks in the trace. The use cases hierarchy dependency that has to be taken into account by the
can be used to slice the dynamic views and provides architect. In a system with hundreds of components the
context information of the current scenario being dependency graph becomes rather complicated. For this
analysed. The abstractions applied on one scenario are task, the architects can find very useful to have a logical
also reflected overamong the other scenarios in the view that shows the organisation of the components in
hierarchy. packages and their dependences and an execution view
that shows how the components interact. To generate
F
A E those views, we have to analyse the exchange of
B C messages statically and dynamically. This is the focus of
D
the next phases.
A Extraction of Static Information
B The extraction of the static information is carried out with
C a source code analyser that detects all the communication
Trace flow

D instances in the source code. The approach is similar to

the one described in our previous work [17].
E
The output of the extraction is presented as a set of Prolog
facts. Each fact defines a relationship between two
F elements of the model. In our case, we have created (1)
the ‘register’ relationship between a component’s
directory and its name on the software bus and (2) the
‘message’ relationship among the sender, receiver and
Figure 3. Three views of the Use Case hierarchy. content of a message. Below there is a sample of the
6 AN EXAMPLE information extracted by the code analyser.
We demonstrate the approach with an example that is the register(‘/gui/voice’,’VO IC E_C TR L’).
simplification of a real case. The description follows the m essage('VO IC E_C TR L','PR O TO C O L','sel_prot').
fours steps of the process described in Section 3. m essage('VO IC E_C TR L','PR O TO C O L','connect').
Architectural Concepts register(‘/gui/data’,’D ATA_C TR L’).
We start examining the architectural documentation in m essage('D ATA_C TR L','PR O TO C O L','sel_prot').
order to identify the architecturally significant concepts register(‘/resource/protocol’,’PR O TO C O L’).
that build the system. The system is component based. m essage('PR O TO C O L','R AD IO ','setup').
Components represent computational units or system register(‘/gui/m akeC all’,’M AKE_C ALL’).
resource controllers and expose well-defined interfaces. m essage('M AKE_C ALL','D ISPLAY','w rite').
The communication among the components is achieved For instance, the first line means that the directory
with the exchange of asynchronous messages. The ‘/gui/voice’ contains the implementation of the
operating system takes care of the delivery of the component ‘VOICE_CTRL’. The second line means that
messages using a software bus. There are three primitives the component ‘VOICE_CTRL’ sends a message to the
for registering on the bus, sending and receiving component ‘PROTOCL’ and the message is ‘sel_prot’.
messages:
Abstraction
register(ID) – primitive to register a component on the The extracted source code model is at a very low level of
bus. abstraction. The abstraction process can be divided in two
send(dest, msg) – primitive for sending a message to dest. steps: composition rules and view selection.

recv(src, msg) – primitive for retrieving a message from Composition Rules

the component’s queue. This step concerns with adding the part-of relationships to
When the components are initialised, they register the model. It is a crucial activity of the abstraction
themselves on the bus with a unique identifier that is process because it creates a hierarchical structure in the
statically assigned at compile time. The same identifier is model that simplifies its navigation. The composition
used in the sending and receiving primitives. rules specify how the source code elements are grouped

5
to form subsystems or more abstracted entities. that is done in the real case.
Below there is an example in Prolog where we define four Visualisation.
new components. The components are associated to the The logical view can be visualised with Rigi as a
directory that contains its implementation. hierarchical graph. We can also export the graph from
Rigi to the Venice. Venice allows us to show the logical
contain(‘C all’,X):-register(‘/gui/voice’,X).
view in the UML notation. We use the notation proposed
contain(‘C all’,X):-register(‘/gui/data’,X).
contain(‘M essaging’,X):-register(‘/gui/inst_m sg’,X).
in [18]. Figure 4 shows the logical view of the example.
contain(‘M essaging’,X):-register(‘/gui/em ail’,X). The packages have been created according to the
contain(‘N etw ork’,X):-register(‘/resource/protocol’,X). hierarchy relationship. The edges show the high level
The previous components are then grouped in subsystems dependencies that exist among the packages. The user can
according to their functionality. select the level of detail for the visualisation of the edges
[20].
contain(‘Services’,’C all’).
contain(‘Services’,’C all’).
contain(‘G U I’,’Services’).
contain(‘G U I’,’Application’).
contain(‘R esources’,’D isplay’).
contain(‘R esources’,’N etw ork’).

View selection
To define a view, we need (1) to select its representation
format and (2) to define the set of relationships that have
to be projected in it. We use graph-based representations
for the static information and message sequence charts for
the dynamic information

To create the static view we need to compute the high

level dependencies among the components. We represent
the logical view with the typed oriented hierarchical
graphs of Rigi. This is achieved by (1) defining a
grouping relationships that describes the hierarchy, (2) Figure 4. The component view visualised with Venice.
defining the set of relationships of the graph, (3) Extract dynamic information.
compuing the transitive closure and (4) create the graph. The extraction of dynamic information is conducted by
Below there is the Prolog code that defines the grouping (1) instrumenting the source code, (2) executing a set of
relationship and the relation relationship for our simple usage scenarios and (3) collecting the traces. The
example. architectural concepts of the first phase drive us in the
choice of the correct instrumentation of the system. In the
grouping(X,Y):-contain(X,Y). example, we can trace all the calls to the ‘send’ primitive
relation(X,Y):-m essage(X,Y). that are architecturally significant for our system.
We can calculate the reflexive transitive closure with an
We use the ThirdEye [10] environment for instrumenting
auxiliary function trans defined below:
the code. In the example, we execute two scenarios in the
trans(R ,X,Y):-P=..[R ,X,Y],call(P). system simulator. Each scenario is represented by a
trans(R ,X,Y):-P=..[R ,X,Link],call(P),trans(R ,Link,Y). sequence of commands. The traces are then converted to
trans(_,X,X). Prolog facts. And example is given below.
We can then create the graph by defining a hierarchy
relationship that is basically identical to the grouping trace(’sc_start’,’M akeC all’,’’,’’,1).
trace(’m sg’,’M AKE_C ALL’,’D ISPLAY’,’sel_num ’,2).
relationship. The edges of the graph are obtained by the
trace(’m sg’,’M AKE_C ALL’,’VO IC E_C TR L’,’setup’,3).
transitive closure. Below there is the Prolog code. trace(’m sg’,’VO IC E_C TR L’,’PR O TO CO L’,’sel_prot’,4).
hierachy(X,Y):-grouping(X,Y). ...
edge(X,Y):-tran(grouping,X,Item 1),tran(grouping,Y,Item 2), trace(’m sg’,’VO IC E_C TR L’,’M AKE_C ALL’,’callact’,14).
relation(Item 1,Item 2). trace(’sc_end’,’M akeC all’,’’,’’,15).
trace(’sc_start’,’SendM ail’,’’,’’,16).
In this simple example, we have not taken in trace(’m sg’,’SEN D _M AIL’,’EM AIL’,’setup’,17).
consideration the management of the types of the nodes ...
trace(’m sg’,’PR O TO C O L’,’D ATA_C TR L’,’ack’,29).

6
trace(’m sg’,’D ATA_C TR L’,’EM AIL’,’con_active’,30). and dynamic information to be available and presented in
trace(’sc_end’,’SendM ail’,’’,’’,31). different views. Abstraction plays a key role in reducing
The ‘trace’ relationship contains the type of the trace, the the complexity of the models in different dimensions
sender, the receiver, a label and the time stamp. Two (system structure, organisation of scenarios, participants
special events (‘sc_start’ and ‘sc_end’) delimit the begin and messages in the MSC).
and end of a scenario. We elaborate the traces with We have highlighted that the architectural views have to
Prolog propositions in order to apply the abstraction rules be maintained synchronised in order to present the static
created during the static analysis. We plan to use Prolog and dynamic views at the same level of abstraction.
also to separate the different scenarios and to detect
patterns in the sequence chart. The results can be exported The end-user customisation represents a powerful
to the Message Sequence Chart visualiser. mechanism to tailor the tools for the specific subject
system needs. It is an improvement to cope with the wide
Navigating Static and Dynamic Views variety of programming languages. Moreover, it makes
We present an example of navigation in the architectural easy to introduce new features, to aid the process of
model with both the static and dynamic views. Figure 5 abstracting and understanding, like dynamic metrics
shows a graph-based representation of the logical view of calculation and participants clustering algorithms [1].
Figure 4 in Rigi. The graph shows the two components at
the highest level of abstraction: ‘GUI’ and ‘Resources’. The use case hierarchy allows the user to select the
The process (or execution) view is visualised in the MSC starting point of the analysis, either from a bottom-up or a
Visualiser as shown in Figure 6. The MSC is shown at the top-down approach.
same level of abstraction as the logical view in Rigi. The use case hierarchy allows the user to focus into more
Therefore, only the two high level participants and concrete use cases or scenarios. The hierarchy could be
messages are visualised. The messages that are exchanged used to generate other static-dynamic representations, as
among the nodes contained in the two participants are in [11], or collaboration diagrams, at different levels of
hidden. This reduces the objects to be visualised and architecture abstraction. As well, it is useful for program
simplifies the understanding of the MSC. comprehension, to isolate smaller scenarios, discover
The user can navigate the two views by expanding or errors or analyse concrete behaviour.
collapsing the nodes in the same style like in Rigi. The Our future work will focus on creating a better
system takes care of maintaining the two views management for the scenarios and defining a technique
synchronised. We imagine the user wants to investigate for detecting interaction patterns in the MSC using
the details of the ‘GUI’ component. The user can expand Prolog.
the GUI node for example in the logical view, as shown
in Figure 7. The same effect is propagated to the MSC, as 8 REFERENCES
shown in Figure 8. The messages between the two 1. Cho E. S., Kim C. J., Kim S. D., Rhew S. Y., Static
components (‘Services’ and ‘Application’) of the ‘GUI’ and Dynamic Metrics for Effective Object Clustering,
component are visible. The same result can be achieved Proceedings of the Asia Pacific Software Engineering
by selecting and expanding a node in the MSC. Conference, December 2-4 1998, Taipei, Taiwan.
The user can also apply vertical abstractions in order to 2. Hofmeister C., Nord R.L. and Soni D., Describing
hide a set of messages. In Figure 9, the user selects a set Software Architecture with UML, Proc. of the 1st
of messages. The selection can be either contiguous or Working IFIP Conference on Software Architecture,
not. The user can then group together the messages in one Kluwer Academic Publishers, 1999.
single message that represents them. In case of un- 3. Holt R., Structural Manipulations of Software
contiguous messages, multiple groups are created. The Architecture using Tarski Relational Algebra,
result of the grouping is shown in Figure 10. Figure 11 Proceedings of the Working Conference on Reverse
and Figure 12 show the views at a lower level of Engineering 1998, pp. 210-219, 1998.
abstraction where the two low level elements
(‘MAKE_CALL’ and ‘SEND_MAIL’) are visible. 4. ITU-T. recommendations Z.120. ITU –
Telecommunication Standarization Sector, Geneva,
The user can also follow a bottom-up approach by Switzerland, may 1996. review draft Version.
starting with a raw model and by grouping the nodes
towards higher levels of abstraction. The system takes 5. Jerding D., Rugaber S., Using visualization for
care of keeping the views synchronised. Architectural Localization and Extraction,
Proceedings of the Working Conference on Reverse
7 CONCLUSIONS AND FUTURE WORK Engineering, (WCRE97), pp. 56-65, October 1997,
Understanding a software architecture requires both static Amsterdam, Netherlands..

7
6. Kazman R., Carrière S. J., View Extraction and View 17. Riva C., Reverse Architecting: an Industrial
Fusion in Architectural Understanding, Proceedings Experience Report, Proceedings of the 7th Working
of the fifth International Conference on Software Conference on Reverse Engineering (WCRE2000),
Reuse (ICSR5), pp.290-299, IEEE Computer Society Brisbane, Australia, 23-25 November, 2000.
Press, Victoria, B.C, Canada, June 1998.
18. Riva C., Xu J. and Maccari A., Architecting and
7. Koskimies K., Männistö T., Systä T., Tuomi J.: Reverse Architecting in UML, Workshop on
Automated support for modeling of OO software. Describing Software Architecture with UML,
IEEE Software, January/February 1998, 87-94. International Conference on Software Engineering
2001 (ICSE), Toronto, May 2001.
8. Koskimies K., Mössenböck H., SCENE: Using
Scenario Diagrams and Active Text for Illustrating 19. Systä T., Static and Dynamic Reverse Engineering
Object-Oriented Programs, Proceedings of the 18th Techniques for Java Software Systems, Ph.D Thesis,
International Conference on Software Engineering, University of Tampere, Dept. of Computer and
(ICSE ’96), IEEE Computer Society Press, pp 366- Information Sciences, Report A-2000-4, 2000.
375, 1996.
20. Venice, http://www.cs.Helsinki.FI/group/venice/
9. Kruchten P.B., The 4+1 View Model of architecture,
21.Danny B. Lange and Yuichi Nakamura. Program
IEEE Software, 12(6):42-50, 1995.
Explorer: A Program Visualiser for C++. In Proc. of
10. Lencevicius R., Ran A., Yairi R., ThirdEye – the USENIX Conference on Object-Oriented
Specification-Based Analysis of Software Execution Technologies, June 1995.
Traces, Proceedings of the 22nd International
Conference on Software Engineering (ICSE 2000),
Limerick, Ireland, 4-11 June, 2000, page 772.
11. Leue,S., Mehrmann L., Rezai M., Synthesizing
software architecture descriptions from Message
Sequence Chart specifications, Proceedings of the
13th IEEE International Conference on Automated
Software Engineering (ASE ’98), 1998, Page(s): 192 -
195
12. R. Ferenc, F. Magyar, Á. Beszédes, Á. Kiss and M.
Tarkiainen. Columbus - Tool for Reverse Engineering
Large Object Oriented Software Systems, Proc. of
SPLST 2001, Szeged, Hungary, pp. 16-27, June 15-
16, 2001. (ed. T. Gyimothy)
13. Ran A., “ARES Conceptual Framework for Software
Architecture” in M. Jazayeri, A. Ran, F. van der
Linden (eds.), Software Architecture for Product
Families Principles and Practice, Addison Wesley,
2000.
14. RedHat Source Navigator,
http://sources.redhat.com/sourcenav/
15. Richner T., Ducasse S., Recovering high-level views
of object-oriented applications from static and
dynamic information, Proceedings of the IEEE
International Conference on Software Maintenance
(ICSM '99), Oxford, 1999, Page(s): 13 -22
16. Rigi: a visual tool for understanding legacy systems,
University of Victoria, http://www.rigi.csc.uvic.ca/

8
Figure 5. The component view in Rigi. Figure 6. The MSC in the MSC visualisarer.

Figure 7. Expand node. Figure 8. Expand node. Figure 9. Selection in MSC. Figure 10. Grouping.

Figure 11. Low level. Figure 12. Low level details in MSC.