Neil B. Harrison

How do architecture patterns and tactics interact? A model and annotation

Software architecture designers inevitably work with both architecture patterns and tactics. Architecture patterns describe the high-level structure and behavior of software systems as the solution to multiple system requirements, whereas tactics are design decisions that improve individual quality attribute concerns. Tactics that are implemented in existing architectures can have significant impact on the architecture patterns in the system. Similarly, tactics that are selected during initial architecture design significantly impact the architecture of the system to be designed: which patterns to use, and how they must be changed to accommodate the tactics. However, little is understood about how patterns and tactics interact. In this paper, we develop a model for the interaction of patterns and tactics that enables software architects to annotate architecture diagrams with information about the tactics used and their impact on the overall structure. This model is based on our in-depth analysis of the types of interactions involved, and we show several examples of how the model can be used to annotate different kinds of architecture diagrams. We illustrate the model and annotation by showing examples taken from real systems, and describe how the annotation was used in architecture reviews. Tactics and patterns are known architectural concepts; this work provides more specific and in-depth understanding of how they interact. Its other key contribution is that it explores the larger problem of understanding the relation between strategic decisions and how they need to be tailored in light of more tactical decisions.

Analysis of Architecture Pattern Usage in Legacy System Architecture Documentation

Architecture patterns are an important tool in architectural design. However, while many architecture patterns have been identified, there is little in-depth understanding of their actual use in software architectures. For instance, there is no overview of how many patterns are used per system or which patterns are the most common or most important for particular domains. In addition, little is known of how architecture patterns ay interact with each other. We studied architecture documentation of 47 systems to learn about their architecture patterns. Most systems had two or more architecture patterns, and certain patterns were prominent in different application domains. We identified several patterns that are commonly used together, and are beginning to learn how such combinations may impact system quality attributes. This information can be used to help designers select architecture patterns, can help people learn both architectures and patterns, and can be useful in architectural reviews.

Pattern-Driven Architectural Partitioning: Balancing Functional and Non-functional Requirements

One of the vexing challenges of software architecture is the problem of satisfying the functional specifications of the system to be created while at the same time meeting its non-functional needs. In this work we focus on the early stages of the software architecture process, when initial high-level system partitioning is being performed. Specifically, we study the problem of system partitioning with respect to both functional requirements and quality attributes. Architecture patterns are particularly well-suited to simultaneously addressing functional requirements and quality attributes. They support architects in considering both, understanding the impact of decisions on other attributes, and making tradeoffs among them. Existing architectural design methods accommodate pattern use, but do not exploit it in detail. We propose a pattern-based approach that leverages the benefits of patterns, and fits well with existing methods.

Pattern-Based Architecture Reviews

Software architecture reviews are effective in identifying potential problems in architectures, however, are expensive, time-consuming, and generally rely on extensive architecture documentation. An architecture review that accommodates projects with very short development cycles, minimal documentation, or frequently changing requirements could be useful if it identifies important architectural issues. We developed a useful, inexpensive architecture review method that uses the architecture patterns in a system to identify important issues in the achievement of quality attributes.

Incorporating fault tolerance tactics in software architecture patterns

One important way that an architecture impacts fault tolerance is by making it easy or hard to implement measures that improve fault tolerance. Many such measures are described as fault tolerance tactics. We studied how various fault tolerance tactics can be implemented in the best-known architecture patterns. This shows that certain patterns are better suited to implementing fault tolerance tactics than others, and that certain alternate tactics are better matches than others for a given pattern. System architects can use this data to help select architecture patterns and tactics for reliable systems.

On the impact of fault tolerance tactics on architecture patterns

One important way that an architecture impacts fault tolerance is by making it easy or hard to implement tactics that improve fault tolerance. Information about how the implementation of fault tolerance tactics affects the architecture patterns of a system should be useful to architects during architectural design in selecting optimal fault tolerance tactics and architecture patterns. In order to understand more about how useful this information can be, we performed an informal study of teams designing fault tolerance tactics in an architecture. One group used information about the interaction of tactics and architecture patterns; the other did not. We observed that the group with the information produced better quality architectures, and were able to better estimate the difficulty of implementing the tactics. We recommend that information about the interaction of tactics and architecture patterns be made available to architects, particularly those with less familiarity about fault tolerance tactics.

Decision-Centric Architecture Reviews

Recent developments in wearable sensor technologies allow for collecting various information about the person in different conditions. This data is often of limited use without proper interpretation provided by human experts. We propose a practical platform that collects long-term data from multiple body and ambient sensors along with human-provided tagging in practical and mobile conditions. We address the platform requirements of security, privacy, and trustworthiness. Our approach will be tested in a case study focused on stress monitoring at work.

Implementing reliability: the interaction of requirements, tactics and architecture patterns

An important way that the reliability of a software system is enhanced is through the implementation of specific run-time measures called runtime tactics. Because reliability is a system-wide property, tactic implementations affect the software structure and behavior at the system, or architectural level. For a given architecture, different tactics may be a better or worse fit for the architecture, depending on the requirements and how the architecture patterns used must change to accommodate the tactic: different tactics may be a better or worse fit for the architecture. We found three important factors that influence the implementation of reliability tactics. One is the nature of the tactic, which indicates whether the tactic influences all components of the architecture or just a subset of them. The second is the interaction between architecture patterns and tactics: specific tactics and patterns are inherently compatible or incompatible. The third is the reliability requirements which influence which tactics to use and where they should be implemented. Together, these factors affect how, where, and the difficulty of implementing reliability tactics. This information can be used by architects and developers to help make decisions about which patterns and tactics to use, and can also assist these users in learning what modifications and additions to the patterns are needed.

The supportive effect of patterns in architecture decision recovery - A controlled experiment

The documentation of software architectural design decisions is important to help people understand the system and the rationale behind architectural solutions. In practice, the documentation of such decisions is regularly done after the fact, or skipped completely. To support software maintenance and evolution, the decisions have to be recovered and described. This is often hindered by the fact that the original architects are not available any more, or they do not completely remember the reasons for making the decisions. Additionally, the whole process is very expensive. In this paper, we hypothesize that architecture decision recovery can be more efficient by focusing on recovering decisions related to applying architecture patterns. To test this hypothesis, we designed a controlled experiment that was conducted to analyze the impact of architecture patterns on the quality and quantity of architecture decisions recovered after the fact. We are able to provide statistical evidence that a focus on patterns significantly increases the quality of decisions, while no conclusive evidence concerning the quantity of decisions was found.

DCAR - Decision-Centric Architecture Reviews

Recent developments in wearable sensor technologies allow for collecting various information about the person in different conditions. This data is often of limited use without proper interpretation provided by human experts. We propose a practical platform that collects long-term data from multiple body and ambient sensors along with human-provided tagging in practical and mobile conditions. We address the platform requirements of security, privacy, and trustworthiness. Our approach will be tested in a case study focused on stress monitoring at work.