Structural manipulations of software architecture using Tarski relational algebra

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:

Metric-based Evaluation of Implemented Software Architectures

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

Software architecture is abstract and intangible. Tools for visualizing software architecture can help to comprehend the implemented architecture but they need an effective and feasible visual metaphor, which maps all relevant aspects of a software architecture and fits all types of software. We focus on the visualization of module-based software—such as OSGi, which underlies many large software systems—in virtual reality, since this offers a much higher comprehension potential compared to classical 3D visualizations. Particularly, we present an approach for visualizing OSGi-based software architectures in virtual reality based on an island metaphor. The software modules are visualized as islands on a water surface. The 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 intuitive navigational tasks. Our approach allows users to get a first overview about the complexity of the software system by interactively exploring its modules as well as the dependencies between them.

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.

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.

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

Reverse engineering of large legacy software systems generally cannot meet its objectives because it cannot be cost-effective. There are two main reasons for this. First, it is very costly to understand legacy code sufficiently well to permit changes to be made safely, because reverse engineering of legacy code is intractable in the usual computational complexity sense. Second, even if legacy code could be cost-effectively reverse engineered, the ultimate objective - re-engineering code to create a system that will not need to be reverse engineered again in the future - is presently unattainable. Not just crusty old systems, but even ones engineered today, from scratch, cannot escape the clutches of intractability until software engineers learn to design systems that support modular reasoning about their behavior. We hope these observations serve as a wake-up call to those who dream of developing high-quality software systems by transforming them from defective raw materials.

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.

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

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.

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.

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.

Software architecture (SA) is the blueprint of the software system and considered as one of the most important artifacts in component based development. The design and analysis of SA can be very complex. Under the inspiration of Model-Driven Development, the design of SA has been no more constrained in one stage. It is a trend to construct multiple SA models in multiple stages during the software life cycle. Thus, the traceability between these SA models becomes a new challenge. The information between these SA models in deferent stages is usually not recorded well and easy to be lost lately, which makes the maintenance and evolution difficult and error-prone. In this paper, we present an approach to recording the information between SA models via a traceability model for reducing the loss of design decisions and helping developers understand the software system well.