See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/252768952

A Survey Paper on Software Architecture Visualization

Article · January 2008

CITATIONS READS
25 2,244

2 authors:

Yaser Ghanam Sheelagh Carpendale

The University of Calgary The University of Calgary
29 PUBLICATIONS   242 CITATIONS    371 PUBLICATIONS   8,250 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Constructive visualization View project

Vuzik: Exploring a Medium for Painting Music View project

All content following this page was uploaded by Yaser Ghanam on 19 May 2014.

The user has requested enhancement of the downloaded file.

 A Survey Paper on Software Architecture Visualization
Yaser Ghanam and Sheelagh Carpendale
Department of Computer Science
University of Calgary, Canada T2N 1N4
{yghanam, sheelagh}@ucalgary.ca

components, extend its functionality, debug it and write

ABSTRACT
tests for it.
Understanding the software architecture is a vital step
towards building and maintaining software systems. But 1.2. Scope
software architecture is an intangible conceptual entity. SV is a broad field that is concerned with visualizing
Therefore, it is hard to comprehend a software aspects of software engineering as a practice and software
architecture without a visual mapping that reduces the systems as evolving products. Some of these aspects
burden on the human brain. Visualizing software include design models and patterns, software architecture,
architecture has been one of the most important topics in development processes, code history, database schemes,
software visualization. Not only are architects interested network interactions, web services, parallel processing,
in this visualization but also developers, testers, project process execution and many others [3]. This paper
managers and even customers. This paper is a survey on focuses on a single aspect of SV which is software
recent and key literature on software architecture architecture. Software architecture refers to the structure
visualization. It touches on efforts that defined what of a software system including composing entities, the
characteristics an effective visualization should have. It metrics of these entities, and the relationships among
compares various efforts in this discipline according to different entities [4]. Visualizing software architecture
taxonomies such as dimensionality, multiplicity of views encompasses not only the software modules and their
and use of metaphors. The paper also discusses trends and internal structures and interrelations, but also the
patterns in recent research and addresses research evolution of these modules over time [5]. Considering the
questions that are still open for further investigation. numerous tools and approaches proposed to directly or
indirectly help build an understanding of the system
Author Keywords architecture (including software exploration tools),
Software architecture visualization. research in this area has been extensive especially in the
last few years.
ACM Classification Keywords
Software, visualization, HCI. 1.3. Structure
Section 2 of this paper is a listing of the problems and
1. INTRODUCTION questions researchers in the field of software architecture
1.1. Software Visualization visualization have been attempting to address and solve.
Then, Section 3 touches on the criteria of effective
Simply put, Software Visualization (SV) is the use of software visualizations. Section 4 follows to discuss the
visual representations to enhance the understanding and tools and techniques developed to design and build
comprehension of the different aspects of a software effective architecture visualizations. Section 5 talks about
system. Price et al. [1] gives a more precise definition of the main trends in the techniques and tools used to
software visualization as the combination of utilizing produce architecture visualizations followed by a
graphic design and animation combined with technologies discussion on open research questions in this discipline.
in human-computer interaction to reach the ultimate goal
of enhancing both the understanding of software systems 2. QUESTIONS & PROBLEMS
as well as the effective use of these systems. The need to
visualize software systems evolved from the fact that such In this section, we touch on the main problems and
systems are not as tangible and visible as physical objects questions recent research has been trying to tackle.
in the real world [2]. This need becomes particularly Research in the area of software architecture visualization
evident when the software system grows to entail a huge is centered on finding a meaningful and effective mapping
number of complexly related modules and procedures. scheme between the software architecture elements and
This growth results in a boost in the time and effort visual metaphors [6]. Recent research has been trying to
needed to understand the system, maintain its answer different questions such as: “why is the
visualization needed?”, “who will use [it]?”, and “how to Customers are also considered an important audience for
represent it?” [7]. Others like [8] questioned the architecture visualization [12]. They might ask or need to
effectiveness and expressiveness of the visuals to use. In have a general overview about the design of the system,
general the various questions asked in this discipline can but they need not look at low level details that are
be grouped into three broad categories: irrelevant to their concerns. Figure 1 illustrates the
previously mentioned groups along with their interests in
• Who are the different groups of audience for the various levels of detail in the software architecture
architecture visualization [9]? based on [9], [10] and [12].
• What questions do they wish to answer through
this visualization [10]?
• How can visual metaphors and interaction
techniques be used to answer their questions
[11]?

As will be discussed later in this paper, these three

questions can be thought of as determinants of what is to
be visualized and how.
2.1. Who?
By answering the “who” question, we determine the
different groups of audience for architecture visualization
and their various interests.
Figure 1 - Various levels of interest of SV audience
Defining the audience of the architecture visualization
2.3. How?
plays a pivotal role in determining what to visualize and
how to visualize it. McNair et al. [9] defines three To satisfy the needs of the different stakeholders, the
different groups that are interested in the software visualization needs to be capable of answering their
architecture of a given system. These three groups are various questions about the software architecture.
developers, managers and researchers. Panas et al. [10] Numerous approaches, techniques and tools have been
consider architects to be one additional group, and they proposed by researchers in an attempt to produce an
differentiate between developers and maintainers. effective visualization that can achieve this goal. But what
an effective visualization is can be an ambiguous issue
2.2. What?
that inevitably might create a gap between the proposed
Having defined the audience for architecture solutions and the needed ones. This issue of determining
visualization, it is equally important to understand the the effectiveness of the visualization has driven a new
needs of this audience. These needs can be understood by stream of research dedicated to answering the question:
studying the roles different groups of audience play and “What makes architecture visualization effective?” The
the influences they have on the software architecture. following section will discuss some of the efforts to
establish reliable and valid criteria that determine the
The questions these groups address differ according to
effectiveness of a proposed solution.
their various interests and level of involvement in the
software project. Therefore, the interests of these groups 3. CRITERIA FOR AN EFFECTIVE VISUALIZATION
are to be considered when visualizing software
architecture. For example, it is important for architects to Research in software architecture visualization attempts to
realize the different characteristics of the architecture they answer the spacious variety of questions asked by the
design such as complexity, coupling, cohesion and other different stakeholders through a number of techniques and
attributes. Developers (and maintainers) are usually approaches. However, what determines how effective a
interested in understanding how the architecture is laid specific visualization technique is has never been a trivial
out, and what the most recent status of the software question. Storey et al. [13] conducted a comprehensive
system is. Developers deem this understanding important analysis of cognitive models of program comprehension.
because it enables them to maintain the system and The aim of her work was to find a set of criteria against
continue the development process. Managers; on the other which the effectiveness of software exploration tools can
hand, want, on a high level, to be able to monitor the be measured. In this highly referenced paper [13], she
progress of the project and determine the completion of presented a hierarchy of cognitive issues which should be
development goals. On another level are researchers. considered when developing a software exploration tool
They are interested in studying characteristics and trends as partially shown in Figure 2.
of software architectures and their evolution in general.
 [20] also suggested that low visual complexity is a
desirable property in any visualization. They also added
other criteria to measure against when evaluating the
effectiveness of a specific visualization such as simple
navigation, good use of visual metaphors and good use of
interaction.

4. SOLUTIONS: TOOLS & TECHNIQUES

Efforts in the field of architecture visualization can be
categorized in more than one way. The following is a
comparative review of existing solutions based on three
taxonomies: multiplicity of view, dimensionality and
metaphor. In the following survey, these characteristics
will overlap resulting in some papers being mentioned
Figure 2 - A part of the hierarchy of cognitive issues defined
by Storey et al. [13] more than once under different sections.

Amongst the different cognitive models mentioned in this 4.1. Multiplicity of view
paper are two fundamental models. The first model is the With regards to the multiplicity of view, two schools of
bottom-up comprehension model, where software thoughts can be identified. On the one hand, the first
understanding is constructed from mentally grouping school asserts that any visualization should support
smaller elements into higher level abstractions. The top- multiple views of the architecture at different levels of
down comprehension model; however, states that detail in order to satisfy the audience’s different interests
software understanding is constructed through a high [18, 21, 22]. That is, for the visualization to be deemed
level comprehension of the domain of the software useful, it has to provide a means of looking at the
followed by a mapping of this domain into smaller different aspects of a software architecture through
building components. Some research suggests that people different views, and possibly via multiple windows. For
are actually capable of using either model according to instance, if one view provides an insight into the internal
certain cues. Whereas an integrated model suggests that structure of software entities composing the architecture,
people can simultaneously activate both models at any another view should, on a higher level, focus on the
given time to gain an understanding of the software at relationships and communication between these entities.
different levels of abstraction. The implications of the
work in [13] and other efforts in the same field by Storey The other school of thought; on the other hand, believes
such as [14] and [15], have been influential on recent and that a carefully designed single view of the visualization
current research [6, 10, 16, 17, 18]. When designing a might be more effective and meaningful in conveying the
software visualization tool, Storey states that it is essential multiple aspects of the architecture than the multiple view
to determine whether the tool better support a top-down approach [10, 14]. For example, the tool can provide
approach, a bottom-up approach or a hybrid of both. different levels of detail in a single view (e.g. internal
structures of entities along with the relationships between
Li et al. [19] had another interesting view on what defines them) and leave it up to the viewers to draw their own
an effective visualization based on the challenge of mental maps at the level of interest to them.
complexity in software architectures. According to [19],
in addition to the data complexity represented in the huge 4.1.1. Multiple-view visualization
number of nodes and edges, there is a visual complexity Lanza et al. [23, 24] introduced a software visualization
associated with the limitations of the human brain tool called CodeCrawler (CC). Through a 2D
capabilities and short-term memory capacity. Therefore, visualization of reverse-engineered object oriented
Li et al. proposed the use of a clustered graph model to software systems, CC offers the advantage of having
reduce the data complexity, and, consequently, the visual multiple views of the same architecture. The multiplicity
complexity. In this model, three requirements are to be of views aims to uncover the different aspects of the
satisfied in order to deem the view of the architecture architectural design and emphasize specific metrics in the
effective: an adequate information supply (a non- software system. In general, CC represents the
distorting level of abstraction), mental map requirements architecture in a polymeric view in which entities
(the context of previous views should be preserved), and a (classes, methods … etc) are represented as nodes and
constant visual complexity. Also, the algorithm for laying relationships as edges connecting these nodes. The node’s
out the visual elements should ensure a non-overlapping size, position and color are used to represent the metrics
distribution of nodes, the ability to produce compact of interest in the software system. There are four different
output and a way to preserve the mental map. Young et al. views that CC has to offer: 1) coarse-grained view by
which the system complexity is emphasized, 2) fine-
grained view which hierarchically represents the class
blueprint in the architecture, 3) coupling view which, as
the name suggests, underscores coupling amongst
modules in the architecture, and 4) evolutionary view
which helps track changes of the architecture over time.
Figure 3 shows the four different views. Lanza et al.
explain, in great detail, the algorithm followed to layout
the class blueprint visualization in a separate paper [25].

Figure 4 - A unified view of software architecture by Panas

et al. [10]
In the figure above, the green landscapes represent
directories (high level groups); whereas the blue plates
indicate source files. And methods are represented by
buildings.
A – Coarse-grained B – Fine-grained
4.2. Dimensionality
Visualizations in general can be classified according to
the dimensionality of the graphical elements as 2D
visualizations and 3D visualizations. Virtual
Environments (VE) are also used as a means of conveying
information about software architectures especially large-
C – Coupling D - Evolutionary scale ones. VEs can mainly be categorized under 3D
visualizations. This paper; however, discusses VEs as a
Figure 3 - Four different views for the software architecture separate group of visualizations due to the considerable
by Lanza et al. [23, 24]
number of focused research efforts on this specific
4.1.2. Single-view visualization technique.
SHriMP [14, 15] was one of the early attempts to 4.2.1 2D visualization
visualize multiple aspects of the architecture through a
By differentiating between 2D and 3D representations, we
single view. Storey et al. [14] suggested the use of a
refer to the dimensionality of the graphical visuals and not
unified single view visualization that presents information
the dimensionality of the data itself. That is, a carefully
at different levels of the software system, especially the
designed 2D representation of an architecture should be
architectural level. However, according to Panas et al.
capable of representing more than two dimensions in the
[10], SHriMP did not consider stakeholder
dataset. For example, if we look back at Figure 3, we can
communication. Therefore, [10] proposed an enhanced
notice that CodeCrawler [23, 24] chose to use a two
single-view model that addresses three main issues. For
dimensional representation of the software architecture.
one, it enhances communication between the different
That is, there is no third dimension in the graphical
stakeholders by allowing them to reach a common
visuals such as depth. Nevertheless, CC used the
understanding of the architecture. Secondly, it reduces the
attributes of the 2D visuals to reflect more dimensions.
“significant cognitive burden” resulting from trying to
The node size, color and position are all used to visualize
comprehend multiple views. And thirdly, it rapidly
more characteristics of the software entities. Figure 5
summarizes systems especially large-scale ones. The
shows the metrics in the 2D visual that were utilized to
proposed model uses common (rather than varying)
map the entity’s attributes.
interests amongst stakeholders to come up with a
collective comprehension of the architecture. Figure 4
shows an example of this visualization.
 Marcus et al. [16] suggested the utilization of the third
dimension to better represent highly dimensional data in
large-scale software systems. This 3D visualization, as
shown in Figure 7, does not use graph-based
representation because, according to [16], graph-based
representations suffer from scalability, layout and
mapping problems.

Figure 5 - The metrics used in the 2D visual to map the

entity's attributes by Lanza et al. [23, 24]
Furthermore, Storey et al. [14, 15] suggested the use of
the SHriMP (Simple Hierarchical Multi-Perspective) tool
as a customizable and interactive 2D environment for
navigating and browsing hierarchical software structures.
The tool, originally described in [26], uses filtering,
abstraction and graph layout algorithms to reveal complex
structures in the software system. The hierarchical
structure is represented via a nested graph in a
Figure 7 - A non-graph-based representation by Marcus et
containment layout as shown in Figure 6. al. [16]
But rather it uses bar-based color and pixel maps to show
relationships between elements of a software system. The
reason behind introducing the third dimension is that 2D
pixel bars limit the number of attributes that can be
visualized. Occlusion was a problem in this visualization
until transparency and elevation control was introduced as
shown in Figure 8.

Figure 6 –SHriMP showing the extend & implement

relationships between classes in a software architecture by
Storey et al. [14, 15]
The tool provides fisheye zooming, semantic zooming as
well as geometric zooming to serve different purposes of
navigation. Also, the capability to hide some levels of the
architecture is provided in order to make the visualization Figure 8 - Transparency as a solution for occlusion by
suitable for different levels of details. Although this work Marcus et al. [16]
was a relatively simplistic design, it has been repeatedly
It is worthwhile to mention that there was a previous
referenced in literature and was the basis for later efforts
effort to use brightness to represent the third dimension,
in architecture visualization [11, 16, 27, 28].
but it did not enjoy success because it was confusing and
4.2.2 3D visualization poorly perceived by the users [36].
The main reason behind proposing the use of 3D DiffArchViz is another tool developed by Sawant et al.
visualizations, as will be detailed in this section, is the [18] specifically for visualizing the software architecture
realization that using only two dimensions to represent of network-based large-scale systems. According to [18],
highly dimensional data can be too overwhelming for the the use of 3D glyphs to represent the architecture was to
viewer to comprehend. In an early attempt to justify the offer more surface area to place information on. This tool
use of the third dimension, [29] mentions that visualizing uses a multidimensional scaling technique to represent the
a 1000 node cone tree without visual clutter can in no way pattern of proximities among the set of software
be achieved in a 2D plane, but is possible using a 3D components extracted from raw code. The visualization
plane. uses hue, luminance, size, orientation, transparency and
height as visual representations for the different attributes
of software components (represented as glyphs). Figure 9
shows a screenshot of this visualization. The drawback of
this tool is that it categorizes raw code into software
components in a static manner, hence mandating the user
to stick to this categorization throughout the visualization
process.

Figure 10 - EvoSpaces virtual city by Alam et al. [11]

Users can navigate through this virtual city with a road
map that would be available in one of the corners of the
screen. They can zoom inside buildings to see stickmen
who represent methods and functions. Each stickman may
be surrounded by his resources (yellow-colored boxes)
which represent local variables.
Figure 9 - Glyphs as a 3D visualization metaphor by Sawant In addition, Panas et al. [10], as we showed earlier in
et al. [18] Figure 4, also used the city metaphor as a theme for a
virtual environment. This work aimed for a reduction of
4.2.3 VE visualization
the visual complexity of the single-view visualization
The ultimate goal of using Virtual Environments to Panas proposed.
visualize software architecture is to make it possible and
4.3 Metaphor
easy for the viewer to compare metrics of the different
components in the architecture and realize the As discussed earlier in this paper, a primary aspect of
relationships amongst them. Also, amplifying cognition is research in the area of architecture visualization is finding
another advantage of VEs, for they allow for navigation in a meaningful mapping scheme between the software
an open 3D space that has commonalities with physical architecture elements and visual metaphors [6]. Some
environments in our everyday life. researchers suggested the use of abstract metaphors such
as polygons, spheres and other geometrical 2D or 3D
EvoSpaces [11] is a reverse engineering tool that provides
shapes to represent software entities. Another group of
an architectural level visualization of software systems as
researchers thought it would be easier for the human brain
a virtual environment. It takes advantage of the fact that
to understand the structure of and the relationships in a
software systems are often structured hierarchically to
software architecture if a real metaphor was used instead.
suggest the use of a virtual city metaphor. Entities along
That is, it is argued that by looking at familiar objects
with their relationships are represented as residential
(such as buildings) whose physical characteristics map
glyphs (e.g. house, apartment, office, hall … etc);
directly to attributes of the software entities, the viewer
whereas metrics of these entities are represented as
will perceive the visualization as more intuitive and easier
positions and visual scales in the 3D layout (e.g. size,
to comprehend and remember. On the negative side;
color value … etc). The tool provides different interaction
however, the complexity of the real metaphor may
modes with zooming and navigation capabilities. Figure
negatively impact the effectiveness of the visualization as
10 shows an instance of visualizing a software
will be discussed later.
architecture using EvoSpaces.
4.3.1. Abstract metaphor
Balzer et al. suggested the use of 3D spheres [31] or
hemispheres [32] as an abstract metaphor to visualize
entities in software architecture (e.g. packages, classes,
methods and attributes). These entities are related to each
other through inheritance, access and call relationships.
Nested hemispheres are used in a containment layout to
represent the hierarchical structure of a software system
with their size corresponding to how many entities they
contain. Moreover, relationships are visualized using a
“Hierarchical Net” where a point resting above the center
of each hemisphere is used as a connecting hub for the
relationships within this hemisphere. The thickness of a
connecting edge between two nodes is used as an
indicator of the number of relations that link these nodes.
An interesting use of transparency in the suggested
solution makes it possible to view into the system or sub-
system while maintaining the context of neighboring sub- Figure 12 - A house metaphor showing a) a miss-shaped and
systems. The deeper the entity is in the software b) a well-shaped glyph by Boccuzzo [12].
hierarchy, the more opaque it becomes. Figure 11 shows
an example of the hemisphere visualization. The tool also provides normalization and filtering
capabilities to make the visualization more cognitively
intuitive. Figure 13 shows the mapped software metrics in
the house metaphor representation.

Figure 13 - The mapped software metrics in the house

Figure 11 - Hemispheres as an abstract metaphor by Balzer metaphor by Boccuzzo [12].
et al. [32]
Beside the works previously shown in Figure 4 and
A year later, Balzer et al. [33] proposed another solution Figure 10 where the city metaphor was used, Vizz3D
to visualize metrics of a software architecture using [35] is another tool that used the very same metaphor and
Treemaps. It is also a hierarchy-based solution with an later was the basis for other efforts like the one by [10].
abstract metaphor. But the main difference in this effort is Figure 14 shows the abstract representation of a software
the use of the polygon metaphor to visualize entities. architecture along with the city metaphor mapping of that
architecture.
4.3.2. Real metaphor
The main goal that drives some efforts to adopt the use of
real metaphors in architecture visualization is to utilize
the properties of familiar objects (such as houses and
tables) to enhance the users’ understanding of software
components. For instance, Boccuzzo [12] introduced
CocoViz as a software metrics configuring engine to
handle metaphors and allow optimizations to their
graphical representation. Depending on the fact that it is
easy for a viewer to quickly distinguish between a well-
shaped glyph and a miss-shaped one, the distinction
between a good architectural design and a poor one will
be fairly easy and quick. CocoViz uses three different
metaphors to represent entities in a software architecture:
house metaphor, table metaphor and spear metaphor. For
each metaphor, a set of parameters is defined along with a
criterion that determines whether a well-shaped glyph or a
miss-shaped glyph should be used for representing a
given entity as illustrated in Figure 12. Figure 14 - Mapping between abstract & real metaphor in
Vizz3D [35]
At different levels of complexity, the house metaphor Adding an extra dimension for existing 2D visualization
seems to repeatedly be used in architecture visualization solutions has also been a noticeable trend in recent
as a real metaphor. This metaphor is hoped to make the literature. 3D visualizations became more appealing after
software entities and the relationship between them the advantages of 3D visualizations over 2D ones were
cognitively easy to comprehend [12, 34]. A collection of uncovered through practical comparisons [16]. Although
house-related metaphors are utilized to come up with a in 2005, there were still some proposed 2D solutions, we
city metaphor that is more complex in nature and can notice that in 2007, most (if not all) of the proposed
potentially more capable of visualizing the different solutions consider the third dimension. This transition to
perspectives of a given software architecture [10, 11, 34]. 3D spaces can be deemed an enhancement (as opposed to
the previous trend of real metaphors) because of the
5. DISCUSSION accompanying (old and new) evidences of what the added
benefits are.
5.1. Trends
Considering the third taxonomy, there is no obvious trend
In this paper, the main focus of our literature review was
other than the original practice of providing multiple
research efforts in the last few years. It is indeed difficult
views of the architecture to underscore the different
to make conclusions about trends in the discipline of
design aspects. Some people did suggest that single-view
software architecture visualization without also looking at
visualizations are more effective, but their argument was
research efforts in the last two decades. This is because
not backed by any experiments or empirical studies.
the incremental advancements in this field, as you might
have noticed from the previous sections, are not 16 A
significant enough to notice revolutionary changes in a 10 R
short period of time. Actually, some works are too similar
to be able to tell what the significance of the latter work 14 A
is. For example, in 2007, the “habitability” or the “city” 18 A
metaphor has been a repeatedly proposed visualization 12 R
Paper (reference at the end)

metaphor with very small incremental enhancements [10,

11 R
11, 35]. For these reasons, the reader is asked to keep in
mind, when reading the analysis in this section, that little 23 A
context has been considered before the year 2001. 32 A
The plot in Figure 15 shows some of the papers in the 33 A
architecture visualization literature (some of which have 31 A
been discussed in detail in Section 4) over a 7 year period.
35 R
The x-axis represents the years whereas the y-axis
indicates the references to these works in our paper. A 36 A
box can be either white (2D), grey (3D) or black (VE). A 37 A A
dotted frame indicates multiple-view whereas a connected
2001

2002

2003

2004

2005

2006

2007
frame indicates single-view. Each box contains either the
letter “A” for abstract metaphor or “R” for real metaphor.
Year
As seen in Figure 15, the most obvious trend in software
Metaphor View Multiplicity Dimensionality
architecture visualization (SAV) is the use of real A → Abstract ____ single-view 2D
metaphors as opposed to abstract ones. By 2005, most of R→ real ------- multi-view YY 3D
the proposed efforts focused on delivering visualizations YY VE

that make use of real-life objects to represent software Figure 15 - Some papers on SAV from 2001 to 2007
entities. This trend has been most probably supported by
the advancement in graphics-related technologies 5.2. Open research questions
(software and hardware) rather than empirical evidence of In Section 2 of this paper, we mentioned that the
the advantages of using a real metaphor in software questions research has been trying to answer can be
visualizations. Literature lacks empirical evaluation of summarized by: Who is the audience? What do they want
what the added benefit is when utilizing a “city” metaphor to know? How can the visualization satisfy their needs?
for example. There have been evaluations that tested And we also mentioned some efforts to identify criteria
utilization of space and other visual attributes, but none for good visualizations.
(from the set covered) touched on the cognitive aspect of
the effectiveness of these real metaphors. It is fairly reasonable to assume that research efforts have
successfully identified the different groups of audience
and their various interests. This conclusion can be drawn
from the fact that recent papers have (in most of the suggested, visualization efforts should be evaluated such
cases) designed and structured their work to target a well- as expressiveness, user interaction, visual complexity and
defined audience. navigation techniques.
Having said that, it is important to mention that these The fourth part of this paper focused on recent software
efforts have failed in evaluating how their work directly architecture visualization tools and techniques. We
influenced the targeted audience. Some people did defined three taxonomies to differentiate between the
evaluate their work against some criteria and heuristics. various efforts. The first taxonomy is dimensionality. We
But as mentioned before, there has not been enough noticed that there is an obvious and justifiable trend to
evaluation that considers human factors in architecture make use of the third dimension as a way to reduce the
visualization. Therefore, it is not guaranteed that the tools visual complexity. In the second taxonomy, multiplicity
and techniques being developed satisfy the audiences’ of views, we noticed no specific trends but different
needs even though they might fully satisfy design opinions about whether a single-view or a multiple-view
principles. is more effective in representing the multiple aspects of
the software architecture. The most obvious trend in
Moreover, it is not sufficient to rely on our guesses or use
literature was related to the third taxonomy which is
the “coolness” factor to decide whether a specific
metaphors. There is an increasing tendency to utilize real
metaphor should be used or not. There is a need to study
metaphors as opposed to abstract ones as a means to
how effective and expressive an abstract or a real
amplify cognition. But with no empirical evidence of the
metaphor is. This is still an open question that requires a
added benefits of these real metaphors, this tendency is
huge amount of effort to answer. Not only do we need to
yet to be scientifically justified.
address the cognitive influence of these metaphors on the
viewer’s comprehension of the architecture, but we also Open research questions in the field of software
need to study the correlation between the complexity of architecture visualization are mainly related to the
the metaphor and the viewer’s ability to form the intended validation of the effectiveness of the tools and approaches
mental map. This issue was also raised by Knodel et al. proposed. There is an evident lack of empirical evidence
[38] who confirmed that there are no empirical evidences which is an important step towards understanding the
of the benefits of some visualization concepts in software value of the research done in this field.
architecture. Therefore, [38] introduced an approach that
This survey paper was limited to recent and key research
explicitly integrated architecture development with the
efforts. A more longitudinal literature survey is needed in
selection, use and empirical validation of visualization
order to come up with more valid and reliable
metaphors. The approach is a composition of defined
generalizations about trends and patterns in software
roles (i.e. stakeholders & visualization experts),
architecture visualization research.
processing steps (i.e. selection of architectural
perspectives), and products (i.e. architectural view). This
ACKNOWLEDGMENTS
approach was validated through several industrial projects
and proved to be successful. We thank Dr. Carpendale for reviewing the credibility of
the resources used in this literature review and making
6. CONCLUSION sure the paper collection sufficiently covers the topic of
interest.
Software visualization is a broad topic that has
increasingly been extended to cover many aspects of
REFERENCES
software engineering and software systems. Two main
conferences lead research in this area: “The ACM 1. Price, B.A., Baecker, R., and Small, I.S. (1998) A
Symposium on Software Visualization (SOFTVIS)” and principled taxonomy of software visualisation. Journal
“The IEEE International Workshop on Visualizing of Visual Languages and Computing. 4(3), pp. 211-
Software for Understanding and Analysis (VISSOFT)”. 266.
Other conferences like SIGGRAPH and INFOVIS are 2. Petre, M., and de Quincey, E. (2006) A gentle
also valuable venues for this discipline. overview of software visualization. The Computer
This paper talked about a specific area in software Society of India Communications (CSIC) & Autumn
visualization concerned with visualizing software 2006 PPIG newsletter.
architecture. To begin with, we defined the field and its 3. ACM Symposium on Software Visualization.
position within the scope of software visualization. Then, Available at http://www.st.uni-
we discussed the three main axes around which all efforts trier.de/~diehl/softvis/org/softvis08, last accessed Feb
in this field orbit, namely: the audience, their needs and 20, 2008.
the tools and techniques to satisfy these needs. After that,
we mentioned the attributes against which, as researchers
4. L. Bass, P. Clements, and R. Kazman. (2003) Software 17. Tilley, S. and Huang, S. (2002) Documenting software
Architecture in Practice. Addison – Wesley Inc. systems with views III: towards a task-oriented
5. D'Ambros, M., and Lanza, M. (2007) BugCrawler: classification of program visualization techniques. The
Visualizing Evolving Software Systems. The 11th 20th Annual international Conference on Computer
European Conference on Software Maintenance and Documentation, 2002, pp. 226-233.
Reengineering, 2007, pp.333-334. 18. Sawant, A., and Bali, N. (2007) DiffArchViz: A Tool
to Visualize Correspondence between Multiple
6. Gračanin, D., Matković, K., and Eltoweissy, M. Representations of Software Architecture. The 4th
(2005) Software visualization. Innovations in Systems IEEE International Workshop on Visualizing Software
and Software Engineering, 1(2), pp. 221-230, Springer for Understanding and Analysis, 2007, pp.121-128.
London. 19. Li, W., Eades, P., and Hong, S. (2005) Navigating
7. Maletic, J., Marcus, A., and Coollard, M. (2002). A software architectures with constant visual complexity.
Task Oriented View of Software Visualization. IEEE IEEE Symposium on Visual Languages and Human-
Workshop of Visualizing Software for Understanding Centric Computing, 2005, pp. 225-232.
and Analysis, 2002, pp. 32-40. 20. Young, P., and Munro, M. (2003) Visualising software
8. Mackinlay, J. (1986) Automating the design of in virtual reality. IEEE First International Workshop
graphical presentation of relational information. ACM on Visualizing Software for Understanding and
Transaction on Graphics, 5(2), pp. 110-141. Analysis, 2003.
9. McNair, A., German, D., Weber-Jahnke, J. (2007) 21. Reiss, S., and Renieris, M. (2003) The BLOOM
Visualizing Software Architecture Evolution Using Software Visualization System. Software Visualization
Change-Sets. The 14th Working Conference on – From Theory to Practice, MIT Press, 2003.
Reverse Engineering, 2007, pp.130-139. 22. Kruchten, P. (1995) The “4+1” view model of
10. Panas, T., Epperly, T., Quinlan, D., Saebjornsen, A., architecture. IEEE Software, 12(6), pp. 42-50.
and Vuduc, R. (2007) Communicating Software 23. Lanza, M., Ducasse, S., Gall, H., and Pinzger, M.
Architecture using a Unified Single-View (2005) CodeCrawler - an information visualization
Visualization. The 12th IEEE International tool for program comprehension. The 27th
Conference on Engineering Complex Computer International Conference on Software Engineering,
Systems, 2007, pp. 217-228. 2005, pp. 672-673.
11. Alam S., and Dugerdil P. (2007) EvoSpaces: 3D 24. Lanza, M. (2003) CodeCrawler - A Lightweight
Visualization of Software Architecture. The 19th Software Visualization Tool. The 2nd International
International Conference on Software Engineering & Workshop on Visualizing Software for Understanding
Knowledge Engineering, 2007. and Analysis, 2003, pp. 51 - 52.
12. Boccuzzo, S., and Gall, H. (2007) CocoViz: Towards 25. Lanza, M., and Ducasse, S. (2001) The Class
Cognitive Software Visualizations. The 4th IEEE Blueprint - A Visualization of the Internal Structure of
International Workshop on Visualizing Software for Classes. Software Visualization Workshop (OOPSLA,
Understanding and Analysis, 2007, pp.72-79. 2001).
13. Storey, M., Fracchia, F., and Muller, H. (1997) 26. Michaud, J., Storey, M., and Muller, H. (2001)
Cognitive design elements to support the construction Integrating information sources for visualizing Java
of a mental model during software visualization. The programs. IEEE International Conference on Software
Fifth International Workshop on Program Maintenance, 2001, pp.250-258.
Comprehension, 1997, pp.17-28. 27. Lintern, R., Michaud, J., Storey, M., and Wu, X.
14. Storey, M., Best, C., and Michand, J. (2001) SHriMP (2003) Plugging-in visualization: experiences
views: an interactive environment for exploring Java integrating a visualization tool with Eclipse. The ACM
programs. The 9th International Workshop on Symposium on Software Visualization, 2003, p. 47.
Program Comprehension, 2001, pp.111-112. 28. Voinea, L., Lukkien, J., and Telea, A. (2007) Visual
15. Storey, M., Best, C., Michaud, J., Rayside, D., Litoiu, assessment of software evolution. Science of
M., and Musen, M. (2002) SHriMP views: an Computer Programming, pp. 222-248.
interactive environment for information visualization 29. Ware, C., Hui, D., and Franck, G. (1993) Visualizing
and navigation. In CHI '02 Extended Abstracts on object oriented software in three dimensions. The IBM
Human Factors in Computing Systems, 2002. Center for Advanced Studies Conference, 1993, pp.
16. Marcus, A., Feng, L., and Maletic, J. (2003) 3D 612-660.
Representations for Software Visualization. The 1st 30. Jones, J., Harrold, M., and Stasko, J. (2001)
ACM Symposium on Software Visualization, 2003, pp. Visualization for Fault Localization. The ICSE
27-36. Workshop on Software Visualization, 2001, pp. 71-75.
31. Balzer, M., Noack, A., Deussen, O., and Lewerentz, C.
(2004) Software landscapes: Visualizing the structure
 of large software systems. The ACM Symposium on
Software Visualization, 2004, pp. 261-266.
32. Balzer, M., and Deussen, O. (2004) Hierarchy Based
3D Visualization of Large Software Structures. IEEE
Visualization, 2004.
33. Balzer, M., Deussen, O., and Lewerentz, C. (2005)
Voronoi treemaps for the visualization of software
metrics. The ACM Symposium on Software
Visualization, 2005, pp. 165-172.
34. Löwe, W., and Panas, T. (2005) Rapid Construction of
Software Comprehension Tools. International Journal
of Software Engineering & Knowledge Engineering,
15(6), pp. 905-1023.
35. Wettel, R., and Lanza, M. (2007) Program
Comprehension through Software Habitability. The
15th IEEE International Conference on Program
Comprehension, 2007, pp.231-240.
36. Ham, F. (2003) Using Multilevel Call Matrices in
Large Software Projects. IEEE Symposium on
Information Visualization, 2003, p. 29.
37. Lewerentz, C., and Simon, F. (2002) Metrics-based
3D visualization of large object-oriented programs.
The First International Workshop on Visualizing
Software for Understanding and Analysis, 2002, pp.
70-77.
38. Knodel, J., Muthig, D., Naab, M., and Zeckzer, D.
(2006) Towards Empirically Validated Software
Architecture Visualization. IESE-Report 071.06/E.

View publication stats