Srdjan Stevanetic

Empirical evaluation of the understandability of architectural component diagrams

The architecture of a software system plays a crucial role during evolution and maintenance, as it provides the means to cope with the inherent system complexity by abstracting from implementation and design details. Architectural component models represent high level designs and are frequently used as a central view of architectural descriptions of software systems. Hence, understandability of those models is crucial as they play a key role in supporting the architectural understanding of a software system. In this paper we present the results from a study we carried out to examine to which extent the software architecture could be conveyed through architectural component diagrams. The statistical evaluation of the results shows that metrics such as the number of components, number of connectors, number of elements, and number of symbols used in the diagrams can significantly decrease architectural understandability when they are above and below a certain, roughly predicted threshold. Also, our results indicate that architectural understandability is linearly correlated with the perceived precision and general understandability of the diagrams.

Exploring the Relationships between the Understandability of Architectural Components and Graph-Based Component Level Metrics

Architectural component models are frequently used as a central view of architectural descriptions of software systems and therefore play a crucial role in the whole development process and in achieving the desired software qualities. The components in those models represent important high level structural units that are often used to group either lower-level sub-components or classes in object-oriented design views. In this paper we present a study that examines the relationships between the effort required to understand a component, measured through the time that participants spent on studying a component, and a number of information theory based and the corresponding counting based metrics on graphs at the component level. The results show a statistically significant correlation between all of the metrics and the effort required to understand a component. In a multivariate regression analysis we obtained some reasonably well-fitting models that can be used to estimate the effort required to understand a component.

Tool Support for the Architectural Design Decisions in Software Ecosystems

Software architecture entails the making of architectural decisions based on a set of both functional and quality requirements, as well as trade-offs between them, which have to be considered to achieve design goals. Access to accumulated and documented architectural knowledge facilitates this process. In this paper, we present a set of tools that support creative decision making in the different stages an architecture specification goes through. These tools are structured around a central repository, where acquired knowledge is stored for reuse. The approach is motivated by the challenges arising from the particular needs of the software ecosystem environment, where the software design process is characterized by the participation of multiple and diverse stakeholders and the existence of multiple software applications built on a common platform. Our aim is to provide tool support for making quality-driven design decisions in a flexible and reusable manner, facilitating the systems evolvability, as well as enhancing its understandability to the stakeholders involved.

Cost-Effective Traceability Links for Architecture-Level Software Understanding: A Controlled Experiment

An important architectural challenge is to recover traceability links between the software architecture and artifacts produced in the other activities of the development process, such as requirements, detailed design, architectural knowledge, and implementation. This is challenging because, on the one hand, it is desirable to recover traceability links of a high quality and at the right quantity for aiding the software architect or developer, but, on the other hand, the costs and efforts spent for recovering should be as low as possible. The literature suggests manual, semi-automatic, and automatic recovery methods, each of which exhibits different impacts on costs as well as quantity and quality of the recovered links. To date, however, none of the published empirical studies have comparatively examined the automation alternatives of traceability link recovery. This paper reports on a controlled experiment that was conducted to investigate how well typical results produced by the three automation alternatives support human software developers in architecture-level understanding of the software system. The results provide statistical evidence that a focus on automated information retrieval (IR) based traceability recovery methods significantly reduces the quantity and quality of the elements retrieved by the software developers, whereas no significant differences between manual and semi-automatic traceability link recovery were found.

How do software ecosystems evolve? a quantitative assessment of the r ecosystem.

In this work we advance the understanding of software eco-systems research by examining the structure and evolution of the R statistical computing open-source ecosystem. Our research attempts to shed light on the following intriguing question: what makes software ecosystems successful? The approach we follow is to perform a quantitative analysis of the R ecosystem. R is a well-established and popular ecosystem, whose community and marketplace are steadily growing. We assess and quantify the ecosystem throughout its history, and derive metrics on its core software components, the marketplace as well as its community. We use our insights to make observations that are applicable to ecosystems in general, validate existing theories from the literature, and propose a predictive model for the evolution of software packages. Our results show that the success of the ecosystem relies on a strong commitment by a small core of users who support a large and growing community.

Empirical Study on the Effect of a Software Architecture Representation's Abstraction Level on the Architecture-Level Software Understanding

Architectural component models represent high level designs and are frequently used as a central view of architectural descriptions of software systems. In this paper we present a study that examines the effect of the level of abstraction of the software architecture representation on the architecture-level understand ability of a software system. Three architectural representations of the same software system that differ in the level of abstraction (and hence in the number of components used in the architecture) are studied. Our results show that an architecture at the abstraction level that is sufficient to adequately maps the systems relevant functionalities to the corresponding architectural components (i.e., each component in the architecture corresponds to one systems relevant functionality) significantly improves the architecture-level understanding of the software system, as compared to two other architectures that have a low and a high number of elements and hence tangles or scatters the systems relevant functionalities into several architectural components.

Supporting Software Evolution by Integrating DSL-based Architectural Abstraction and Understandability Related Metrics

Software architecture erosion and architectural drift are well known software evolution problems. While there exist a number of approaches to address these problems, so far in these approaches the understandability of the resulting architectural models (e.g., component models) is seldom studied. However, reduced understandability of the architectural models might lead to problems similar to architecture erosion and architectural drift. To address this problem, we propose to extend our existing DSL-based architecture abstraction approach with empirically evaluated understandability metrics. While the DSL-based architecture abstraction approach enables software architects to keep source code and architecture consistent, the understandability metrics extensions enables them, while working with the DSL, to continuously judge the understandability of the architectural component models they create with the DSL. We studied the applicability of our approach in a case study of an existing open source system.

Supporting the evolution of event-driven service-oriented architectures using change patterns

Abstract Context The components of an event-driven service-oriented architecture (EDSOA) are composed in a highly decoupled way, facilitating high flexibility, scalability and concurrency in SOA systems. Evolving an EDSOA is challenging because the absence of explicit dependencies among constituent components makes understanding and analysing the overall system composition difficult. The evolution of EDSOAs typically happens by performing a series of primitive changes—which can be described formally as change primitives. Objective In this article, we present our change pattern based approach for managing the EDSOA evolution as a novel design method supporting EDSOA evolution. The change patterns operate on a higher abstraction level than change primitives. Method To evaluate our approach, we have compared both time and correctness of changes in a controlled experiment comparing the understanding and performing of changes in EDSOAs. The experiment has been conducted with 90 students of the Software Architecture course at the University of Vienna. We compare the efficiency of 3 sets of change operations for modifying a given system architecture to obtain a desired architecture: a minimal set of 3 change patterns, an extended set of 5 change patterns, and a minimal set of 4 change primitives. Results Our results show that change patterns based evolution requires significantly less time to capture a similar level of correctness as the evolution based on change primitives, presuming that a certain level of transformation complexity is required. Furthermore, we did not observe a significant difference in the correctness level nor in the time required to perform the changes using an extended pattern set compared to a minimal set of patterns. Conclusions We clearly show the feasibility of our approach by developing a design method and tool support using a model-driven tool chain consisting of 3 domain-specific languages and empirically evaluating the approach in a controlled experiment.

Towards a pattern language for construction and maintenance of software architecture traceability links

The documentation of software architecture traceability links is the foundation for many important architecture management activities, such as verification and validation, reuse evaluation and impact analysis. In practice, the construction and maintenance of traceability links is mostly manual, which is labor-intensive and error prone. Although the costs of manual traceability in terms of the time, effort and money required can be mitigated by automated construction, the completeness and correctness of traceability links tends to be negatively affected by automation in their creation and maintenance. This paper presents a pattern language for construction and maintenance of software architecture traceability links to requirements and source code. As a foundation for deriving the pattern language, we have performed systematic literature reviews, investigations of traceability links for multiple open-source software systems, and empirical studies. In particular, we studied the nature of the software architecture traceability phenomenon and its driving factors and impacts, as well as the methods that provide the means to control software architecture traceability. The derived pattern language provides support for addressing multiple decision categories for construction and maintenance of software architecture traceability links. To illustrate the patterns, their application is shown in the context of constructing and maintaining traceability links for an open source framework for mobile games.

The Impact of Hierarchies on the Architecture-Level Software Understandability - A Controlled Experiment

Architectural component models represent high level designs and are frequently used as a central view of architectural descriptions of software systems. They play a crucial role in the whole development process and in achieving the desired software qualities. This paper presents an empirical study that examines the impact of hierarchies on the architecture-level software understand ability. In particular we have studied three different architectural representations of a large-size software system, one with a hierarchical representation where architectural components at all abstraction levels in the hierarchy are shown, and two that do not contain hierarchical abstractions but concentrate only on the lowest level or on the highest level components in the hierarchy. We conducted a controlled experiment in which participants of three groups received one of the three architecture documentations plus the source code of the system and had to answer understand ability related questions. Our results show that using the hierarchical architecture leads to: 1) higher quantity of correctly retrieved elements, 2) lower quantity of incorrectly retrieved elements, and 3) higher overall quality of retrieved elements. The obtained results provide empirical evidence that hierarchies play an important role in the context of architectural component models from the viewpoint of the architecture-level software understandability.