Visualizing Software Architectures in Virtual Reality with an Island Metaphor

We propose the tool IslandViz for exploring modular software systems in virtual reality. We use an island metaphor, which represents every module as a distinct island. The resulting island system is displayed in the confines of a virtual table, where users can explore the software visualization on multiple levels of granularity by performing navigational tasks. Our approach allows users to get a first overview about the complexity of an OSGi-based software system by interactively exploring its modules as well as the dependencies between them.

Software architecture has become an important area of research and practice since the late 1980s (Shaw and Clements 2006). The term “software architecture” started gaining acceptance by the software engineering community in early 1990s but the foundations of this field were laid by the seminal work of Edsger Dijkstra, David Parnas, and others between 1960s and 1980s (Clements 2000). The increasing size and complexity of software systems and demand for high quality are some of the most important factors that have driven the increased interest in this sub-discipline of software engineering. It has generally been realized that a high-level design description can play an important role in successfully understanding and managing large and complex software systems (Clements et al. 2002; Lung and Kalaichelvan 2000). The high-level design decisions regarding the software architecture of a system are not only the hardest and most expensive to change but also play a fundamental role in setting the boundaries for the required quality attributes such as maintainability, reliability, usability, performance, and flexibility of a system (Bass et al. 2003; Clement and Northorp 1996). As a result of increasing realization of the important role of software architecture in large-scale software development and evolution projects, the software architecture community has developed several methods, techniques, and tools to support the software Empir Software Eng (2011) 16:539–543 DOI 10.1007/s10664-011-9168-6

The software architecture is typically defined as the fundamental organization of the system embodied in its components, their relationships to one another and to the system's environment. It also encompases principles governing the system's design and evolution. In order to manage the architecture of a large software system the architect needs a holistic model that supports continuous integration and verification for all system artifacts. In earlier papers we proposed a unified graph-based approach to the problem of managing knowledge about the architecture of a software system. In this paper we demonstrate that this approach facilitates convenient and efficient project measurement. First, we show how existing software metrics can be translated into our model in a way that is independent of the programming language. Second, we introduce new metrics that cross the programming language boundaries and are easily implementable using our approach. We conclude by demonstrating how the new model can be implemented using existing tools. In particular, graph databases are a convenient implementation of an architectural repository. Graph query languages and graph algorithms are an effective way to define metrics and specialized graph views.

Large and complex software systems cannot be created in one piece. They need to be separated into manageable units, i.e., modules, which can be developed independently from each other. Precise definition and documentation of the modules and other software artifacts is essential for a successful software project. The module documentation is part of the overall software architecture documentation. However, nowadays most of the utilized tools for documenting software architectures (e.g., word processors) are not fully sufficient for this task. This thesis provides a concept for an extensible tool, which is specialized for documenting software architectures and modules. The concept supports management and visualization of explicitly definable relations, e.g., dependencies among modules or references to external implementation artifacts. Moreover, this thesis suggests a template for module documentation based on its concept. Finally, a proof of concept prototype is implemented and evaluated with promising results.

Metric-based Evaluation of Implemented Software Architectures

A software architecture is typically drawn as a nested set of box and arrow diagrams. The boxes represent components of the software system and the edges represent interactions These diagrams correspond to typed graphs, in which there are a number of types or colors of edges, and in which there is a distinguished contain relation that represents the system hierarchy (the nesting of boxes). During reverse engineering, one often transforms such diagrams in various ways to make them easier to understand. These transformations include edge aggregation, box abstraction (closing a box to hide its contents), and box separation (separating a box from its surrounding system). Such transformations are essential in helping make software architecture diagrams useful in practice. Paper shows how structural manipulations such as these can be specified and automatically carried out in a notation based on Tarski's relational algebra. The operators in this algebra include relational composition, union, subtraction, etc. These operators are supported in a language called Grok. Grok scripts have been used in manipulating the graphs for large scale software systems, such as Linux, to help in program visualization and understanding.

Reverse engineering aims at obtaining high-level representations of software systems from existing low-level artifacts, such as binaries, source code, execution traces or historical information. Reverse engineering methods and technologies play an important role in many software engineering tasks and quite often are the only way to get an understanding of large and complex software systems. Given for example the task to understand certain aspects of the test code in large software systems, such as Eclipse. How would you figure out the answers to the following questions:

The new trend is to move from the traditional software development approach, which focuses on building software systems from scratch, to component based software development approach, which revolutionizes how software systems are built. The focus of this new approach is on development of new systems, by selecting and assembling a set of off the shelf components within an appropriate software architecture. On one hand, the use of off the shelf components has led to a great potential for: (1) significantly reducing cost and time to market of large scale and complex software systems; (2) improving system maintainability and flexibility by allowing new components to replace old ones; and (3) enhancing system quality by allowing components to be developed by those who are specialized in the application area and systems to be built by software engineers who are specialized in component based software development. On the other hand, the use of commercial off the shelf software-delivered as black box components-has raised a few major technical and non technical issues. The paper explores those issues, and discusses several directions for future research that would help to expand the use of component based software development approach.

This paper provides an introduction to the field of software engineering requires facility in architectural software design. The goal is to demonstrate the current state of the discipline and examine the ways in which architectural design can impact soft-ware design. Software architecture is used to describe a high level design methodology of large software systems. It provides the overall structure of a system in an abstract and structured fashion. A smart architectural demonstration holds the key to the effectiveness of a software architecture description and usage. This paper focuses on criterion to select appropriate architecture style for software system. It also gives overview of definition, goals and requirements of software architecture with various architecture styles, their benefits and applications. The authors have also described the requirements and goals of robotic software architecture. The proposal for layered robotic software architecture for a distributed system is also presented.

Certain software defects require corrective changes repeatedly in a few components of the system. One type of such defects spans multiple components of the system, and we call such defects pervasive multiple-component defects (PMCDs). In this paper, we describe an empirical study of six releases of a large legacy software system (of approx. size 20 million physical lines of code) to analyze PMCDs with respect to: (1) the complexity of fixing such defects and (2) the persistence of defect-prone components across phases and releases. The overall hypothesis in this study is that PMCDs inflict a greater negative impact than do other defects on defect-correction efficacy. Our findings show that the average number of changes required for fixing PMCDs is 20-30 times as much as the average for all defects. Also, over 80% of PMCD-contained defect-prone components still remain defect-prone in successive phases or releases. These findings support the overall hypothesis strongly. We compare our results, where possible, to those of other researchers and discuss the implications on maintenance processes and tools.

Chapter 1 - Relating System Quality and Software Architecture: Foundations and Approaches

Large and complex software systems require expressive notations for representing their software architecture. In this context architecture description languages (ADLs) can be used for describing architectures of components-based software systems. Typical ADLs provide explicit support for specifying components, connectors, and configuration as well as for building hierarchical systems configurations. All of them allow structural dependencies among components to be specified to define static configurations. This may be sufficient for an initial system composition, but does not provide enough information for reasoning about the different kind of connections among elements. Physical and logical connections are defined in this paper. Four kinds of hierarchies are also presented. Each one is used to provide special-purpose view about the architecture.

For a software-intensive system, software quality measures how well the software is designed and how well the software conforms to that design, whereas architecture of a software system is typically defined as the fundamental organization of the system embodied in its components, their relationships to each other and the environment, and the principles governing the system's design and evolution. Obviously, as long as there were no software systems, governing their architecture was no problem at all; when there were only small systems, governing their architecture became a mild problem; and now we have gigantic software systems, and governing their architecture has become an equally gigantic problem (to paraphrase Edsger Dijkstra). In this paper we propose a unified approach to the problem of governing (or managing) the knowledge about architecture of software systems and demonstrate by example its impact on a certain software project. First we postulate that only the holistic approach that supports continuous integration and verification for all system architectural artifacts is one worth taking. Next we demonstrate by example how a concrete large software project being developed in an agile approach is being perceived using the model in question

The foundation for any software system is its architecture. Software architecture is a view of the system that includes the system’s major components, the behaviour of those components as visible to the rest of the system, and the ways in which the components interact and coordinate to achieve the overall system’s goal. Every efficient software system arises as a result of sound architectural basement. This requires the use of good architecture engineering practices and methods. This paper recognizes software architecture practice as a discipline pervading all phases of software development and also presents an enhanced model for software engineering process which provides an avenue for speedy, efficient and timely delivery of software products to their intended users. The integration of software architecture into the phases of software development process in a generic software life cycle is also contained in this research report. This is to enable software engineers and system analysts to use effective software architecture practices and to employ appropriate methodology during the software engineering process.

A large software system contains millions of lines of source code, and the development often involves many developers over a long period. How to understand and analyze its complex code dependencies is challenging but meaningful to developers for program comprehension. In this paper, we propose a novel visual analytics system to explore code dependencies between files for visually understanding software architecture and interactively analyzing bad dependencies. The dependencies between files are abstracted as a directed graph (i.e., the dependency graph) at different levels via the file hierarchy to show the modularization design of source code. Node embeddings of the dependency graph are learned to identify the files with specific dependencies and analyze the similarity between bad dependencies. Finally, we evaluate the usability of our system by two case studies in different JavaScript libraries as well as a user study on software architecture understanding and bad dependency analysis.