Preface
Software architecture is the earliest design artifact that realizes the requirements of the software system. It is the manifestation of the earliest design decisions, which comprise the architectural structure (i.e., components and interfaces), the architectural topology (i.e., the architectural style), the architectural infrastructure (e.g., the middleware), the relationship among them, and their relation to other software artifacts (e.g., detailed design and implementation) and the environment. As an earliest design artifact, a software architecture realizes the qualities of the software system such as security, reliability, availability, scalability, and real-time performance. The architecture can also guide the evolution of these qualities over time, as stand-alone product or across a family of products. Those properties, whether structural or behavioral, can have global impact on the software system. Poor realization and architecting for qualities may “regress” the software system, threating its trustworthiness and slowing down its evolution. Quality is the degree to which a software product lives up to the modifiability, durability, interoperability, portability, security, predictability, scalability, and other attributes. These qualities translate stakeholders’ expectations when procuring, using, maintaining, and evolving, or even “transacting” a software system. The realization of these qualities in the architecture and the software product has significant impact on users’ satisfaction, value creation, sustainability, and durability of the software. They also determine the extent to which it can meet its business and strategic objectives. Realizing qualities in the architecture and engineering for qualities in a software product are therefore interlinked, intertwined, and interleaved activities cross-cutting technical, structural, behavioral, environmental, and business concerns.
As the field of software architecture enters its third decade of formal study, it finds itself moving from its traditional and foundational focus on the nature of an architecture in terms of its structure and behavior to the more general notion of software architecture as the set of design decisions made to ensure the software requirements will be met. Consistent with this view is the trend toward focusing software architecture documentation on meeting stakeholder needs and communicating how the software solution addresses their concerns and the business objectives. Often, a software system is not isolated, but a part of a larger system. When making decisions, not only is the quality of the software architecture itself important, but a consideration of the overall quality of the system is warranted. For example, quality attributes such as performance and reliability can only be realized through a combination of software, hardware, and the operating environment (and, if relevant to the system, people).
Quality concerns describe system-level attributes such as reliability, testability, usability, modifiability, performance, security, maintainability, and portability. In conjunction with functional requirements, these quality concerns drive and constrain a system’s architectural design and often introduce significant trade-offs that must be considered and balanced.
The goal of this book is to expand the quality aspects of software architecture, focusing broadly on quality-related characteristics and how these relate to the design of software architectures. In addition to architectural qualities (conceptual integrity, correctness, and completeness), we are including three additional directions that distinguish our book from “classical” (however excellent) publications on quality of software architectures:
1. We are including Business Qualities (e.g., product lifetime, time to market, roll-out schedule, integration, cost, and benefit) as well as enterprise aspects such as Business Goals, Return on Investment, Economics, and Value Creation, to ensure a comprehensive consideration of quality, thereby supporting the concept of “total quality management.”
2. We are also including System Quality Attributes (those properties of a system that do not directly relate to the functionality of that system, e.g., modifiability, usability, security, availability, testability, performance) and Nonfunctional Requirements (specific, measurable properties of a system that relate to a quality attribute) in relation to software architecture. Their consideration ensures that the resulting software product addresses these quality attributes, which are strongly influenced by the architecture of the software.
3. From the perspective of technology platforms, we are including recent interest in “disruptive” technologies and approaches. In particular, we are including cloud, mobile, and ultra-large-scale/Internet-scale architecture as an application focus of this book.
In particular, this book addresses the key elements of System Quality and identifies current challenges in relating System Quality and Software Architecture:
Software quality, by definition, is the degree to which software possesses a desired combination of attributes [IEEE 19921]. To improve system quality, we pay attention to system quality attributes, such as usability, maintainability, flexibility, reliability, reusability, agility, interoperability, performance, scalability, security, testability, and supportability.
– Defining Quality Requirements
An oft-cited reason for failed software projects is incomplete and/or unclear requirements. This is especially true of nonfunctional requirements and quality requirements in particular. Our focus is on techniques for defining quality requirements. taxonomies of quality attributes. stakeholder interaction when gathering quality requirements. and approaches for prioritizing requirements.
The following issues have been identified in addressing system qualities:
system patterns that improve quality: This encompasses tactics for meeting specific quality requirements; system anti-patterns that degrade quality; the tradeoffs necessary when addressing quality requirements (the classic case being a tradeoff between system performance and system flexibility); and different project lifecycles and how they contribute to ensuring that quality attributes are met. Waterfall, iterative, agile, and disciplined agile are examples of project lifecycles.
Based on assumptions listed above of how to implement system quality, we are defining the metrics relating to system quality and how these are monitored and tracked throughout the software-development life cycle. The purpose of using metrics is to reduce subjectivity during monitoring activities and provide quantitative data for analysis. We are focusing on approaches for assessing different quality attributes and metrics relevant to an assessment of quality attributes. The IEEE Software Quality Metrics Methodology [IEEE 1992] is a framework for defining and monitoring system-quality metrics and analysis of measurements gathered through the implementation of metrics.
Over the past decade many different opinions and viewpoints have been expressed on the terms “quality of software architecture,” “software quality,” and “system quality.” However, no clear consensus has yet emerged. Fundamental questions remain open to debate: how to align software specifications with quality and business goals; what impact the organization developing the software, architectural design decisions, and development processes has on software quality; what interdependencies software quality attributes have among each other; what the exact relationships are between quality of software architecture, software quality, and system quality; what extrinsic relations such as the increase of one property (e.g., performance) diminishing another property (e.g., maintainability) are; what intrinsic interdependencies are, because many quality attributes depend per definition on other quality attributes (e.g., reliability depends on the system's timing behavior in real-time systems); what additional factors (besides architectural design) are that influence software quality attributes; what impact organizational issues (e.g., team structuring and individual software development processes) have as well as implications of the software development process (e.g., quality assurance measures like reviews and the deployment of agile methods) for software quality; how to balance different quality attributes of a system so that they are best aligned to delivering business value for the organization; how to foster the exchange between several areas of research which have been historically divided into different communities (e.g., performance engineering, software reliability, software metrics); and how to assure the alignment of quality and business IT during the entire software development process.
This book provides a collection of perspectives marking one of the first detailed discussions on the theme of relating system quality, software quality, and software architecture. Through these viewpoints we gain significant insight into the challenges of relating system quality and software architecture from experienced software architects, distinguished academics, and leading industry commentators.
We have organized this book into three major sections, with an introductory editorial chapter providing an introduction to the topic of relating system quality and software architecture.
• Part 1: Human-centric Evaluation for System Qualities and Software Architecture explores several of the most basic issues surrounding the task of quality software delivery and the role of stakeholder’s goals.
• Part 2: Analysis, Monitoring, and Control of Software Architecture for System Qualities considers how core architectural ideas impact other areas of quality software delivery such as knowledge management and continuous system delivery.
• Part 3: Domain-specific Software Architecture and Software Qualities offers deeper insight into how quality software architecture issues affect specific solution domains.
As we summarize below, each of the chapters of this book will provide you with interesting and important insights into a key aspect of relating system quality and software architecture. However, more importantly, the comprehensive nature of this book provides us with the opportunity to take stock of how the emergence of quality software delivery practices change our understanding of the critical task of architecting enterprise-scale software systems.
Part 1: Human-centric Evaluation for System Qualities and Software Architecture
Software architecture not only embodies important design decisions about software systems, but also plays a critical role in facilitating communication among stakeholders. While the impact of these design decisions on system quality has been subject of much investigation, it is important to study the role of human stakeholders in evaluating and interpreting architectural design decisions. Over the past few years, specific emphasis on capturing design decisions for different stakeholders has driven much of the research in this area. This part includes three chapters that reflect on the role of stakeholders in capturing and evaluating system quality as it relates to software architecture. The key objectives of these chapters include:
• Studying how different quality-related design decisions are perceived by different stakeholders.
• Focusing on stakeholder perspectives when ensuring the consistency among different views and optimizing functional and quality requirements.
Chapter 2 reports on a study that assesses the perception of software engineers about Attribute Driven Development (ADD) method. Specifically, the authors have focused on the stakeholders’ perception related to the usefulness, ease of use, and willingness to use the ADD method. Chapter 3 motivates the need to harmonize different stakeholders’ views on software quality and present a conceptualized reference framework for the harmonization. Chapter 4 presents a methodology to obtain an optimal set of requirements that contain no conflicts and satisfy stakeholders’ goals and quality requirements.
The Attribute Driven Design (ADD) method provides steps for designing software architecture for satisfying quality attributes. This method has not been explored in terms of users’ perception on its usefulness and ease of use. The goal is to study the perceptions that software engineers with no or little experience industrially in designing software architecture using the ADD. In Chapter 2, Nour Ali and Carlos Solis describe an empirical study that they conducted on master students to measure their perceptions of the ADD after using it. Authors of this chapter performed two experiments: one with students enrolled in the Software Architecture module in 2010 and the second with the students of the same module in 2011. The main findings are that the subjects perceive the ADD method as useful and that there is a relationship between its usefulness and willingness of use. However, the subjects’ opinion was that they did not agree that the ADD method is easy to use. They also discuss several problems that the subjects faced when using ADD.
Chapter 3 by Vladimir A. Shekhovtsov, Heinrich C. Mayr, and Christian Kop summarizes the related state-of-the-art and presents a conceptualization of the process of harmonizing the views on quality possessed by the different sides of the software process. These concepts are based on applying the empirical techniques to the qualitative data obtained from relevant IT companies and are grounded in the set of basic concepts provided by the Unified Foundational Ontology. In particular, the chapter deals with and conceptualizes the following dimensions: the software quality itself and the related aspects as well as their interrelations, in particular, the notion of quality assessment and the concepts utilized in the quality assessment activities; the knowledge about the various stakeholders and the differences in their perception of quality; the knowledge about the activities of the harmonization process and the capabilities of the process participants needed for performing these activities. The proposed conceptualizations could be used as a reference framework for the particular applications in the domain of harmonizing the views on quality; the conceptual models utilized by these tools could be based on these concepts to achieve higher degree of reuse and semantic interoperability.
High-quality software has to consider various quality issues and different stakeholders’ goals. Such diverse requirements may be conflicting, and the conflicts may not be visible at first sight. Moreover, the sheer number of stakeholders and requirements for a software system make it difficult to select a set of requirements sufficient to meet the initial goals. In Chapter 4, Azadeh Alebrahim, Christine Choppy, Stephan Faßbender, and Maritta Heisel propose a method for obtaining an optimal set of requirements that contains no conflicts and satisfies the stakeholders’ goals and quality requirements to the largest possible extent. At first, they capture the stakeholders’ goals and then analyze functional and quality requirements using an extension of the problem frame approach. Afterward, they determine candidates for requirements interaction and derive alternatives in a systematic way. Then they assign values to the different requirements using the Analytic Network Process. Finally, they obtain an optimal set of requirements not containing any conflicting requirements. The authors illustrate their method with the real-life example of smart metering.
Part 2: Analysis, Monitoring, and Control of Software Architecture for System Qualities
As the earliest design artifact, a software architecture realizes the qualities of the software system such as security, reliability, availability, scalability, and real-time performance and manages their evolution over time. Those properties have a global impact on the software system, where any change in users’ requirements or operating environment may “regress” these qualities, threatening system trustworthiness and slowing down its evolution.
Current research and practice pursue software architectures as the appropriate level of abstraction for evaluating, reasoning about, and managing change and evolution of qualities and their trade-offs in complex software systems. An architecture-based approach for analyzing, reasoning about, and monitoring a system’s qualities is believed to offer the potential benefits of generality (i.e., the underlying concepts and principles are applicable to a wide range of application domains), appropriate level of abstraction to tackle the complexity (i.e., software architecture can provide the appropriate level of abstraction in describing dynamic changes as opposed to algorithmic level), potential for scalability (i.e., facilitating the use in large-scale complex applications), and providing opportunities to facilitate automated analyses benefiting from Architecture Description Languages analyses (ADLs).
Research into analysis, monitoring, and control of software architectures for qualities and their trade-offs has taken two forms: (A) static analysis, where a number of analysis techniques and ADLs have been proposed for modeling and analysis of architectures both within a particular domain and as general-purpose architecture modeling languages. Modeling has primarily been intended to analyze qualities concerned with large, distributed, and concurrent systems. Analysis of architectural qualities upstream, at the architectural level, can substantially lessen the costs of any errors and promote proactivity when designing for dependability. The usefulness of these techniques and ADLs has been directly related to the kind of analyses they tend to support. The ultimate goal is to establish confidence in systems qualities through various means. Examples include analysis of connectors for deadlocks; schedulability analysis for criticality and priority; relative correctness of architectures with respect to a refinement map; use of critics to establish adherence to style rules and design guidelines; enforcement of constraints implicit in types, nonfunctional attributes, component and connector interfaces, and semantic models, etc. Static analysis verifies that all possible executions of the architecture description conform to the specification. Such analyses help the developers to understand the changes that need to be made to satisfy the analyzed properties and to appraise the architecture for meeting its qualities. They span approaches such as reachability analysis, symbolic model checking, flow equations, and data-flow analysis. Dynamic analysis and monitoring for quality, where work has focused on the principles and foundations for enriching the architecture with primitives that can monitor, analyze, plan, and execute decisions that react to feedback loops, emerging from the system and its environment. The ultimate objective has been treating qualities as a moving target and maintaining them through runtime monitors and control. The influx of work on self-* including self-awareness, self-configuration, self-optimization, self-healing, self-protecting, and self-adaptive architectures in specific has advanced our understanding to means of achieving qualities at runtime. Rainbow project of SEI and the Autonomic Manager of IBM are classic examples.
The chapters in this part provide new perspectives and a set of practices and principles for analysis, monitoring, and control of software architecture for qualities.
Chapter 5 by Hong Zhu, Quian Zhang, and Yanlong Zhang proposes a model-based approach called HASARD for the analysis of software quality based on architectural designs. The name HASARD stands for Hazard Analysis of Software Architectural Designs. It adapts the HAZOP hazard identification technique and applies it to software architectural designs to systematically discover the potential quality issues. The identified hazards are then transformed into a graphic quality model to represent how quality attributes and quality carrying properties relate to each other in the particular system. A number of algorithms are developed to analyze the critical design decisions with respect to certain quality concerns, the impacts of a design decision to various quality attributes, the factors that influence a quality attributes, and the trade-off points between a number of contradiction quality properties. The chapter also presents a tool called SQUARE that supports the whole HASARD quality modeling and analysis process and implements the quality analysis algorithms. Finally, the chapter reports a case study with a real e-commerce software system to demonstrate the applicability of the method to real systems.
Software architecture provides the foundation upon which the most important qualities of a software product can be achieved. Thus, it is crucial to evaluate software architecture in the early stages of the software design to avoid expensive rework during later stages. Unfortunately, architecture evaluation methods rarely support the iterative and incremental nature of agile software development methods. A software architecture can be considered as a set of design decisions that are made incrementally as the architect gradually analyzes the problem and solution spaces. To enable the evaluation of the architecture during this process, an evaluation method should support incremental assessment of the design decisions, rather than the architecture as a whole. Furthermore, during development, some of the decisions may become invalid or deprecated; thus, decisions should be revisited and re-evaluated at certain periods. In Chapter 6, Veli-Pekka Eloranta, Uwe van Heesch, Kai Koskimies, Paris Avgeriou, and Neil Harrison present the Decision-Centric Architecture Review method (DCAR). DCAR uses architecture decisions as first-class entities to carry out lightweight, incremental, and iterative architecture evaluations. Additionally, this chapter describes how DCAR can be integrated in the Scrum framework.
The process of divergence between intended software architecture and its actual implementation, often called architecture erosion or architectural drifts, can have negative effects on the overall quality of the system. It is hence very important to check regularly whether the realization of a system conforms to its intended architecture. Checking architectural conformance and consistency is a difficult task because many types of artifacts can be affected by constraints that software architecture defines. Moreover, the broad range of sources for such constraints, which we call architectural rules, makes it difficult to provide flexible tool support. In Chapter 7, Sebastian Herold and Andreas Rausch describe an approach to flexible architecture conformance checking based on a formalization of architectural rules as logical formulas. The artifacts manifesting the intended software architecture and the realization of a software system are represented as knowledge base of logical knowledge representation and reasoning system that is utilized to check the validity of the required architectural rules. The approach is implemented prototypically and has been successfully applied in several case studies.
In Chapter 8, Miroslaw Staron, Wilhelm Meding, Jörgen Hansson, Christoffer Höglund, Kents Niesel, and Vilhelm Bergmann address the challenges of continuously monitoring of internal and external quality of products under development in modern large-scale software development. The challenges are related to the fact that modern software development utilizes the concepts of distributed, self-organized teams and decentralized responsibility for the product. The chapter introduces the concepts relevant for continuous measurement, elements of successful measurement systems, examples of how to visualize the measures, and a case study of three companies that successfully realized these concepts—Ericsson, Volvo Car Corporation, and Saab Electronic Defense Systems. The case study is concluded by a set of guidelines for other companies willing to follow Ericsson, Volvo Car Corporation, and Saab Electronic Defense Systems—for example, how to assess information quality and how to identify implicit architectural dependencies.
Part 3: Domain-specific Software Architecture and Software Qualities
In commercial development projects, software architects face various challenges regarding technology and cost constraints. Stringent quality expectations of customers need to be balanced with cost/benefit aspects. The difficulty in dealing with such aspects is mainly caused by strategic requirements such as reliability, usability, safety, or real-time behavior, which tend to introduce many sensitivity and trade-off points. Hence, strategic quality attributes have a huge impact on sustainability and maintainability of a system. In addition, software and system engineers mostly address cost reduction through tactical qualities like reusability and modifiability. Getting modifiability and reusability right is hard, but achieving the combination of technical and business goals is even harder.
This particularly holds for industrial and enterprise domains where software development comprises only one constituent among other disciplines such as mechatronics or electronics. Consider, for example, medical imaging devices, automation, automotive applications, or railway control systems. When architects design such large-scale systems, application integration and system integration increase complexity and costs significantly. Desired capabilities such as connecting mobile and embedded devices in enterprise systems cause additional quality challenges.
Part 3 contains five chapters looking at addressing strategic and tactical qualities in different domains. The chapters in this section present perspectives how to ensure developmental qualities such as configurability and systematic reuse in product lines, as well as how to deal with operational quality in mobile systems and medical systems. The last chapter extracts experiences from real-world projects that reveal how software architects have addressed quality requirements and software architecture in practice.
Customers of products that include or are determined by software nowadays expect the product to be individually configurable. At the same time, high quality and short delivery times are expected. As a consequence, the producer of the software must be able to develop systems that can be easily configured according to the customers’ needs in such a way that each individually configured system satisfies all quality requirements. Especially in the case of high numbers of possible configurations, it is obvious that it is not feasible to construct all system configurations and check the properties of each of them. Rather, there must be means to assure quality generically, which means once and for all configurations at the same time. Chapter 9 by Martin Große-Rhode, Robert Hilbrich, Stefan Mann, and Stephan Weißleder considers software product line engineering as the base technology for how to construct configurable systems and adds generic quality assurance means to this process. The mechanism can be understood as a general pattern describing how to carry over quality assurance techniques to configurable systems. This is done for two concrete techniques in the chapter: model-based testing as technique for the assurance of functional quality and model-based deployment as a technique for the assurance of real-time properties like responsiveness, availability, and reliability. The techniques are demonstrated on the example of a configurable flight management system as used in modern airplanes.
The increased size and complexity of software systems has led to the notion of multiple software product lines (MPL) in which products are composed from sub-products in separate software product lines. Thus it is important to identify the proper architectural decomposition of the MPL with respect to the stakeholders’ concerns before large organizational resources are committed to the development. Designing MPL architectures is challenging due to the higher level of abstraction and the integration of different product lines. Different architecture analysis approaches have been introduced, but none of these focuses on the evaluation of multiple product line architectures. In Chapter 10, Bedir Tekinerdogan, Özgü Özköse Erdogan, and Onur Aktug propose the architecture analysis approach for multiple product line engineering, Archample, which has been particularly defined for the analysis of multiple product line architectures. Archample also introduces architectural viewpoints for modeling and documenting multiple product lines and likewise supporting the analysis of the decomposition of a multiple product line architecture. The approach has been designed and validated within a real industrial context of Aselsan REHİS Group (Aselsan REHİS), a leading high technology company in defense systems development in Turkey.
In Chapter 11, Matthias Galster and Antoine Widmer think that medical planning and simulation systems integrate resource-consuming computations (e.g., simulations of human tissue) and advanced interaction techniques (e.g., haptic devices and stereoscopic displays). Developing such systems is challenging and usually a specialized, time-consuming, and expensive activity. Achieving high quality for these systems is essential because such systems are often critical to human health and life. Throughout their experience with developing research and commercial medical planning and simulation systems over several years, they found that these systems impose specific constraints on “quality.” Therefore, they elaborate on how quality attributes of medical planning and simulation systems are exhibited in the architecture and the architecting process for those systems and how we may achieve those quality attributes. In particular, their chapter (a) explores challenges related to quality attributes in the development of medical planning and simulation systems, (b) proposes a set of quality attributes that should be addressed in the software architecture of such systems, and (c) discusses some potential strategies on how to handle these quality attributes at the architecture stage.
Chapter 12 by Rafael Capilla, Laura Carvajal, and Hui Lin highlights the role of usability requirements in software architecture, and in particular how important usability concerns are addressed in the architecture of mobile software applications. Because mobile software demands stringent quality requirements, many times quality concerns are not properly addressed in the design, and usability is only described at the code level. Therefore, software designers cannot estimate properly the impact in the design of the usability mechanisms introduced in the system. Consequently, this chapter describes first which usability mechanisms are key for mobile software, and second, it guides software designers to determine the generic and concrete architectural responsibilities of such usability mechanisms including which classes describe the functionality pertaining to each mechanism. As a result, the software architect can use the concrete responsibilities of any usability mechanism such as the ones shown in this chapter to adapt and integrate them in any particular architecture of a mobile application, identifying which classes are necessary to support the functionality of the usability mechanism used and estimating the design effort to introduce or modify one or several usability mechanisms before implementation.
Chapter 13 by Maya Daneva, Andrea Herrmann, and Luigi Buglione describes the involvement of software architects in the process of engineering quality requirements in large contract-based system delivery projects. It also seeks to understand how architects viewed their work in relation to other project stakeholders involved in quality requirements engineering. The chapter presents findings from an exploratory study based on interviews with 21 software architects from European project organizations. Special attention is paid to the roles that these architects played in quality requirements’ activities; their interactions with other project roles; the ways in which the architects coped with elicitation, documentation, prioritization, quantification, negotiation, and validation of quality requirements; and the role of the contract in orchestrating the quality requirements engineering activities and in encouraging the architects to do what they did. Some interesting findings that emerged from the research in contract-based project contexts include (1) the notion of the contract as a vehicle for reinforcing the cost-consciousness of software architects when reasoning about quality requirements, (2) the notion of the project business cases as the key driver for making quality requirements trade-offs, and (3) the notion of quality requirements validation as a socially constructed process and not merely a technical tool-based one.