NEWS AT SEI
This article was originally published in News at SEI on: August 1, 2007
Architects use architectural patterns and tactics to improve software architectural decisions and simplify the design process. In this column, we explore the relationships of tactics and architectural patterns, focusing on the quality attribute of modifiability.
Patterns are solutions that resolve multiple forces, whereas tactics focus on specific quality attributes. To more effectively apply both tactics and patterns, architects need to understand how architectural tactics and patterns relate and how to use them effectively.
The attribute-driven design (ADD) method [Wojcik 2006] provides guidance on when to apply patterns and tactics while designing the architecture but leaves the ordering to the discretion of the designer. Architects are advised to choose a pattern if they can find one and then adjust the pattern based on tactics. They are advised to use tactics when they need help coming up with a pattern, when an existing pattern isn’t quite right and they need to tailor it, or when they want to validate the choice of a pattern. To help with this activity, Table 1 shows the relationship of some well known architectural patterns [Buschmann 2007] to their corresponding tactics that address modifiability.
Table 1: Architectural Patterns and Corresponding Tactics for Modifiability
Modifiability tactics are based on analytic models [Bachmann 2007]. They can be thought of as the transformations that are available to affect the behavior of a design with respect to modifiability. They provide the architect with a view of the analytic model in terms of a limited number of parameters based on coupling and cohesion, and on cost models. Figure 1 shows tactics that support modifiability and are organized based on these models to increase cohesion by localizing changes and reduce coupling by preventing ripple effects. Furthermore, the coupling and cohesion-based tactics enable the deferred binding time tactics.
Figure 1: Tactics to support modifiability [Bass 2003]
Consider an example where a change request is made that specifies that the modification is made with no side effects in three hours. To understand the implications of the proposed change, the architect would interpret the architecture of the system to create a model for reasoning about modifiability. One such interpretation is shown in Figure 2.
Figure 2: Using the architecture to reason about modifiability
The architecture is defined in terms of modules and their associated responsibilities. Costs are associated with the responsibilities and the dependencies between them represent the probability that a change to one responsibility will propagate to another. The corresponding modifiability model shows the associated costs and probabilities of propagations for the modules, based on the responsibilities that are assigned to them.
Consider the case when the proposed change affects module A. The modifiability model shows that the cost of changing module A is 2 hours. Furthermore, there is a 0.7 probability that the change to module A will propagate and require a change to module B and a 0.2 probability that the change to module A will propagate and require a change to module C. The model predicts that the change will take:
2.0 + (0.7 * 4.0) + (0.2 * 5.0) = 5.8 hours
This predicted response is compared with the three hour desired response and found to be lacking. The architect has the option of making changes at the tactic level or the pattern level:
- apply tactics – the model indicates that there is a problematic dependency chain between modules A and B which contributes 2.8 hours to the predicted time for modifying the system. The architect can minimize the ripple by applying tactics for preventing ripple effects such as the use an intermediary tactic to decouple responsibilities in the architecture and the restrict communication paths tactic to prevent modules from bypassing the intermediary.
- apply a pattern – the layered pattern can be used to break the dependency between modules A and B. To validate the choice of the pattern, it can be understood in terms of the use an intermediary and other tactics shown in Table 1 and reasoned about in terms of the associated modifiability model.
Patterns have widespread use in the design process. By relating patterns to tactics, practitioners gain a basis for making principled design decisions. The designer can use tactics to understand patterns and how they support quality attributes such as modifiability, or to adjust patterns in order to improve their properties.
Modifiability is one important quality, but it is not the only one. We anticipate providing similar analysis for other important quality attributes.
Bachmann, F.; Bass, L.; and Nord, R. Modifiability Tactics, (CMU/SEI-2007-TR-002). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2007.
Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd ed. Boston, MA: Addison-Wesley, 2003.
Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; & Stal, M. Pattern-Oriented Software Architecture: A System of Patterns. Chichester, NY: Wiley, 1996 (ISBN: 978-0-471-95869-7).
Wojcik, R.; Bachmann, F.; Bass, L.; Clements, P.; Merson, P.; Nord, R.; Wood, B. Attribute-Driven Design (ADD), Version 2.0, (CMU/SEI-2006-TR-023). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2006.
About the Authors
Robert L. Nord is a senior member of the technical staff in the Product Line Systems Program at the SEI where he works to develop and communicate effective methods and practices for software architecture. Prior to joining the SEI, he was a member of the software architecture program at Siemens, where he balanced research in software architecture with work in designing and evaluating large-scale systems. He earned a PhD in computer science from Carnegie Mellon University. Nord lectures internationally on architecture-centric approaches. He is co-author of Applied Software Architecture (2000) and Documenting Software Architectures: Views and Beyond (2002).
Len Bass is a senior member of the technical staff at the Software Engineering Institute who participates in the High Dependability Computing Program. He has written two award-winning books on software architecture as well as several other books and numerous papers in a wide variety of areas of computer science and software engineering. He is currently working on techniques for the methodical design of software architectures and to understand how to support usability through software architecture. He has been involved in the development of numerous production or research software systems ranging from operating systems to database management systems to automotive systems.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.