Software Architecture

Software-intensive systems are often independently developed, operated, managed, and evolved. Progressively, communication networks enabled these independent systems to interact, yielding a new kind of complex system, i.e. a system that is itself composed of systems, the so-called System-of-Systems (SoS). By its very nature, SoS is evolutionarily developed and exhibits emergent behavior.

Actually, software architecture research has mainly focused on single systems, mostly large or very large distributed systems whose software architecture is described as design-time configurations of components linked together through connectors. However, it is well known that the restricted characteristics of single (even very large distributed) systems lead to architectural solutions (in terms of theories, languages, tools, and methods) that do not scale up to the case of systems-of-systems.

Indeed, novel architectural solutions are needed to handle the complexity of software-intensive systems-of-systems in particular regarding the software architecture challenges implied by evolutionary development and emergent behavior.

This paper presents the challenges facing software architecture research to address software-intensive systems-of-systems. It analyzes the discriminating characteristics of system-of-systems when compared with single systems from the software architecture perspective and focuses on recent advances in software architecture research to formally describe the architecture of software-intensive systems-of-systems.

Software design is a complicated process, and novice designers have seldom been taught how to reason with a design. They use a naturalistic approach to work their way through software design. In order to impart the use of design techniques, a card game was developed to help design reasoning. This game was tested on groups of students and resulted in noticeable differences between the control and test groups. Those who used the cards produced better design arguments: the groups with the card game on average perform 75 % more reasoning than the control groups. The results show that the design strategy used by the groups is a clear indicator for how many and what kind of design problems are designed, while the cards influence how the designers solve these problems.

We use real options theory to evaluate the options of diversity in design by looking at the trade-offs between the cost and long-term value of different architectural strategies under uncertainty, given a set of scenarios of interest. As part of our approach, we extend one of the widely used architecture trade-offs analysis methods (Cost-Benefit Analysis Method) to incorporate diversification. We also use a case study to demonstrate how decision makers and architects can reason about sustainability using a diversified cost-value approach.

Building successful and meaningful interoperation with external software APIs requires satisfying their conceptual interoperability constraints. These constraints, which we call the COINs, include structure, dynamic, and quality specifications that if missed they lead to costly implications of unexpected mismatches and running-late projects. However, for software architects and analysts, manual analysis of unstructured text in API documents to identify conceptual interoperability constraints is a tedious and time-consuming task that requires knowledge about constraint types. In this paper, we present our empirically-based research in addressing the aforementioned issues by utilizing machine learning techniques. We started with a multiple-case study through which we contributed a ground truth dataset. Then, we built a model for this dataset and tested its robustness through experiments using different machine learning text-classification algorithms. The results show that our model enables achieving \(70.4\,\%\) precision and \(70.2\,\%\) recall in identifying seven classes of constraints (i.e., Syntax, Semantic, Structure, Dynamic, Context, Quality, and Not-COIN). This achievement increases to \(81.9\,\%\) precision and \(82.0\,\%\) recall when identifying two classes (i.e., COIN, Not-COIN). Finally, we implemented a tool prototype to demonstrate the value of our findings for architects in a practical context.

Despite the abundance of research on methodologies for the documentation of design decisions and the evidence linking documentation to the improvement in the systems evolution, their practical adoption seems to be sparse. To understand this issue, we have conducted an overview of state-of-the-art on documentation of design decisions. We pursue an identification of characteristics of the different techniques proposed in the literature, such as the final goal of the documentation, the quantity of information attached to each decision documentation, the rigour of the proposed technique or its level of automation. To unveil these, we propose six classification dimensions, relevant for the industrial application, and use them to structure and analyse the review results. This work contributes with a taxonomy of the area, a structured overview covering 96 publications and a summary of open questions, which can be addressed by future research to facilitate practical adoption.

It is widely agreed that architecture documentation, independent of its form, is necessary to prescribe architectural concepts for development and to conserve architectural information over time. However, very often architecture documentation is perceived as inadequate, too long, too abstract, too detailed, or simply outdated. While developers have tasks to develop certain features or parts of a system, they are confronted with architecture documents that globally describe the architecture and use concepts like separation of concerns. Then, the developers have the hard task to find all information of the separated concerns and to synthesize the excerpt relevant for their concrete task. Ideally, they would get an architecture document, which is exactly tailored to their need of architectural information for their task at hand. Such documentation can however not be created by architects in reasonable time. In this paper, we propose an approach of modeling architecture and automatically synthesizing a tailored architecture documentation for each developer and each development task. Therefore architectural concepts are selected from the model based on the task and an interleaving of concepts is done. This makes for example all interfaces explicit, which a component has to implement in order to comply with security, availability, etc. concepts. The required modeling and automation is realized in the tool Enterprise Architect. We got already very positive feedback for this idea from practitioners and expect a significant improvement of implementation quality and architecture compliance.

Self-adaptive software-intensive cyber-physical systems (sasiCPS) encounter a high level of run-time uncertainty. State-of-the-art architecture-based self-adaptation approaches assume designing against a fixed set of situations that warrant self-adaptation; as a result, failures may appear when sasiCPS operate in environment conditions they are not specifically designed for. In response, we propose to increase the homeostasis of sasiCPS, i.e., the capacity to maintain an operational state despite run-time uncertainty, by introducing run-time changes to the architecture-based self-adaptation strategies according to environment stimuli. In addition to articulating the main idea of architectural homeostasis, we describe three mechanisms that reify the idea: (i) collaborative sensing, (ii) faulty component isolation from adaptation, and (iii) enhancing mode switching. Moreover, our experimental evaluation of the three mechanisms confirms that allowing a complex system to change its self-adaptation strategies helps the system recover from runtime errors and abnormalities and keep it in an operational state.

Most Software Architecture Description Languages (ADLs) lack explicit support for executing an architecture description. In the execution view, the runtime behavior of an architecture is simulated to validate its logic regarding satisfaction of behavioral requirements. In this paper, we present the executable viewpoint of SysADL, a SysML Profile for modeling the architecture of software-intensive systems, which brings together the expressive power of ADLs for architecture description with a standard modeling language widely accepted by the industry, i.e. SysML. SysADL encompasses three integrated viewpoints: structural, behavioral, and executable. This paper focuses on the executable viewpoint that enables the description of the execution model of a software architecture. In this viewpoint, SysADL provides an extended action language subsuming the ALF action language based on fUML, adapted for SysML. In this paper, we use a Central Conditioner System as a case study to illustrate SysADL execution views.

Separation through hardware/software virtualization on operating system (OS) layer reduces complexity in automotive software. Automotive software is categorized into domains (e.g. comfort, safety related features, driver assistance) and each domain is handled by a separate OS, which contains domain-specific applications. A common user interface (UI) for all applications from all domains is created through an UI-Compositor, which composites and manages the different input/output modalities.

While interactions with a single OS with multiple applications and input/output modalities are well known, we find that a composition of applications from different OSs or a composition of multiple OSs into a single UI is challenging. In this paper we investigate architectural patterns for an UI-Compositor for Multi-OS environments and suggest a new architecture that supports the concept of separation.

Several approaches have been proposed to study and provide information about the evolution of a software system, but very few proposals analyze and interpret this information at the architectural level. In this paper, we propose an approach that supports the understanding of software evolution at the architectural level. Our approach relies on the idea that an architectural tactic can be mapped to a number of operational representations, each of which is a transformation described using a set of elementary actions on source code entities (e.g., adding a package, moving a class from a package to another, etc.). These operational representations make it possible to: (1) detect architectural tactics’ application (or cancellation) by analyzing different versions of the source code of analyzed systems, and (2) understand the architectural evolution of these systems. To evaluate the proposed approach, we carried out a case study on the JFreeChart open source software. We focused on the modifiability tactics and we analyzed a number of available releases of JFreeChart. The results of our analysis revealed inconsistencies in the evolution of the system and some erratic applications and cancellations of modifiability tactics.

Software systems need to be continuously maintained and evolved in order to cope with ever-changing requirements and environments. Introducing these changes without stopping the system is a critical requirement for many software systems. This is especially so when the stop may result in serious damage or monetary losses, hence a mechanism for system change at runtime is needed. With the increase in size and complexity of software systems, software architecture has become the cornerstone in the lifecycle of a software system and constitutes the model that drives the engineering process. Therefore, the evolution of software architecture has been a key issue of software evolution research. Architects have few techniques to help them plan and perform the dynamic evolution of software architecture for real-time systems. Thus, our approach endeavors to capture the essential concepts for modeling dynamic evolution of software architectures, in order to equip the architects with a framework to model this process.

Component & connector architecture description languages (C&C ADLs) provide hierarchical decomposition of system functionality into components and their interaction. Most ADLs fix interaction configurations at design time while some express dynamic reconfiguration of components to adapt to runtime changes. Implementing dynamic reconfiguration in a static C&C ADL by encoding it into component behavior creates implicit dependencies between components and forfeits the abstraction of behavior paramount to C&C models. We developed a mechanism for retrofitting dynamic reconfiguration into the static C&C ADL MontiArcAutomaton. This mechanism lifts reconfiguration to an architecture concern and allows to preserve encapsulation and abstraction of C&C ADLs. Our approach enables efficient retrofitting by a smooth integration of reconfiguration semantics and encapsulation. The new dynamic C&C ADL is fully backwards compatible and well-formedness of configurations can be statically checked at design time. Our work provides dynamic reconfiguration for the C&C ADL MontiArcAutomaton.

The critical nature of many complex software-intensive systems calls for formal, rigorous architecture descriptions as means of supporting automated verification and enforcement of architectural properties and constraints. Model checking has been one of the most used techniques to automatically verify software architectures with respect to the satisfaction of architectural properties. However, such a technique leads to an exhaustive exploration of all possible states of the system, a problem that becomes more severe when verifying dynamic software systems due to their typical non-deterministic runtime behavior and unpredictable operation conditions. To tackle these issues, we propose using statistical model checking (SMC) to support the verification of dynamic software architectures while aiming at reducing computational resources and time required for this task. In this paper, we introduce a novel notation to formally express architectural properties as well as an SMC-based toolchain for verifying dynamic software architectures described in \(\pi \)-ADL, a formal architecture description language. We use a flood monitoring system to show how to express relevant properties to be verified. We also report the results of some computational experiments performed to assess the efficiency of our approach.

During the development of a software system, architects deal with a large number of stakeholders, each with differing concerns. This inevitably leads to inconsistency: goals, concerns, design decisions, and models are interrelated and overlapping. Existing approaches to support inconsistency management are limited in their applicability and usefulness in day to day practice due to the presence of incomplete, informal and heterogeneous models in software architecture. This paper presents a novel process in the form of a lightweight generic method, the Concern-Driven Inconsistency Management (CDIM) method, that is designed to address limitations of different related approaches. It aims to aid architects with management of intangible inconsistency in software architecture.

Socio-technical systems are increasingly becoming software-intensive. The challenge now is to design the architecture of such software-intensive systems for guaranteeing not only its correctness, but also the correctness of its implementation. In social-technical systems, the architecture (including software and physical elements) is described in terms of Piping and Instrumentation Diagrams (P&ID). The design of these P&ID is still considered an art for which no rigorous design support exists. In order to detect and eliminate architectural design flaws, this paper proposes a formal-based automated approach for the verification of the essential architecture “total correctness” properties, i.e. compatibility, completeness, consistency, and correctness. This approach is based on the definition of an architectural style for P&ID design in Alloy. We use MDE to automatically generate Alloy models from a P&ID and check their compatibility with the style and its completeness, consistency, and correctness properties. Our approach is presented through an industrial case study: the system of storage and production of freshwater for a ship.

Context: Even though Scrum (the most popular agile software development approach) does not consider architecting an explicit activity, research and professional literature provide insights into how to approach architecting in agile development projects. However, challenges faced by architects in Scrum when performing tasks relevant to the architects’ role are still unexplored. Objective: We aim at identifying challenges that architects face in Scrum and how they tackle them. Method: We conducted a case study involving interviews with architects from six Dutch companies. Results: Challenges faced by architects are mostly related to the autonomy of development teams and expected competences of Product Owners. Conclusions: The results presented in this paper help architects understand potential pitfalls that might occur in Scrum and what they can do to mitigate or to avoid them.

Architecture decision making is considered one of the most challenging cognitive tasks in software development. The objective of this study is to explore the state of the practice of architecture decision making in software teams, including the role of the architect and the associated challenges. An exploratory case study was conducted in a large software company in Europe and fifteen software architects were interviewed as the primary method of data collection. The results reveal that the majority of software teams make architecture decisions collaboratively. Especially, the consultative decision-making style is preferred as it helps to make decisions efficiently while taking the opinions of the team members into consideration. It is observed that most of the software architects maintain a close relationship with the software teams. Several organisational, process and human related challenges and their impact on architecture decision-making are also identified.

Software architecture provides the high-level design of software systems with the most critical decisions. The source code of a system has to conform to the architectural decisions to guarantee the systems’ success in terms of quality properties. Therefore, architects have to continuously ensure that architecture decisions are implemented correctly to prevent architecture erosion. This is the main goal of Architecture Enforcement. For an effective enforcement, architects have to be aware of the most important enforcement concerns and activities. Unfortunately, current state of the art does not provide a concrete structure on how the process of architecture enforcement is actually applied in industry. Therefore, we conducted an empirical study in order to gain insight in the industrial practice of architecture enforcement. For this, we interviewed 12 experienced software architects from different companies. As a result, we identified the most important concerns that software architects care about during architecture enforcement. Additionally, we investigated which activities architects usually apply in order to enforce those concerns.

In recent years, we have been observing a paradigm shift in design and documentation practices for web and mobile applications. There is a trend towards fewer up-front design specification and more code and configuration-centric documentation. In this paper we present the results of a survey, conducted with professional software engineers who build web and mobile applications. Our focus was on understanding the role of software architecture in these applications, i.e. what is designed up-front and how; which parts of the architecture are reused from previous projects and what is the average lifetime of such applications. Among other things, the results indicate that free-text design specification is favored over the use of modeling languages like UML; architectural knowledge is primarily preserved through verbal communication between team members, and the average lifetime of web and mobile applications is between one and five years.

Software architecture modeling is important for analyzing system quality attributes, particularly security. However, such analyses often assume that the architecture is completely known in advance. In many modern domains, especially those that use plugin-based frameworks, it is not possible to have such a complete model because the software system continuously changes. The Android mobile operating system is one such framework, where users can install and uninstall apps at run time. We need ways to model and analyze such architectures that strike a balance between supporting the dynamism of the underlying platforms and enabling analysis, particularly throughout a system’s lifetime. In this paper, we describe a formal architecture style that captures the modifiable architectures of Android systems, and that supports security analysis as a system evolves. We illustrate the use of the style with two security analyses: a predicate-based approach defined over architectural structure that can detect some common security vulnerabilities, and inter-app permission leakage determined by model checking. We also show how the evolving architecture of an Android device can be obtained by analysis of the apps on a device, and provide some performance evaluation that indicates that the architecture can be amenable for use throughout the system’s lifetime.

In the literature of software engineering, many approaches have been proposed for the recovery of software architectures. These approaches propose to group classes into highly-cohesive and loosely-coupled clusters considered as architectural components. The recovered architecture plays mainly a documentation role, as high-level design views that enhance software understandability. In addition, architecture recovery can be considered as an intermediate step for migration to component-based platforms. This migration allows to fully benefit from all advantages brought by software component concept. For that, the recovered clusters should not be considered as simple packaging and deployment units. They should be treated as real components: true structural and behavior units that are instantiable from component descriptors and connected together to materialize the architecture of the software. In this paper, we propose an approach for revealing component descriptors, component instances and component-based architecture to materialize the recovered architecture of an object-oriented software in component-based languages. We applied our solution onto two well known component-based languages, OSGi and SOFA.

Software architecture reconstruction techniques aim at recovering software architecture documentation regarding a software system. These techniques mainly analyze coupling/dependencies among the software modules to group them and reason about the high-level structure of the system. Hereby, inter-dependencies among the software modules are mainly represented with design structure matrices or regular directed/undirected graphs. In this paper, we introduce a software architecture reconstruction approach that utilizes hypergraphs for representing inter-module dependencies. We focus on PL/SQL programs that are developed as data access tiers of business software. These programs are mainly composed of procedures that are coupled due to commonly accessed database elements. Hypergraphs are more appropriate for capturing this type of coupling, where an element can relate to more than one procedure. We illustrate the application of the approach with an industrial PL/SQL program from the telecommunications domain. We analyze and represent dependencies among the modules of this program in the form of a hypergraph. Then, we perform modularity clustering on this model and propose a packaging structure to the designer accordingly. We observed promising results in comparison with previous work. The accuracy of the results were also approved by domain experts.

We present the open reference architecture of the SeaClouds solution. It aims at enabling a seamless adaptive multi-cloud management of complex applications by supporting the distribution, monitoring and reconfiguration of app modules over heterogeneous cloud providers.