Architecture Patterns

I will not go through all of the architectural patterns or the tactics; there are simply too may of them, it will simply be a boring enumeration, and it does not help you understand them. It is, however, good to have an overview of the architectural styles, since these will be your starting point when creating (or approaching an existing) new system. Just as with design patterns, it is good to know their names, roughly how they organise your system, and what problem(s) they address, since this means that you will share a vocabulary with other software developers.

Table 1: Architectural Patterns in Buschmann et al.

Pattern	Brief Summary
Layered	Decompose system into groups of subtasks that are on different levels of abstraction (such as closer to the user interface or closer to the metal)
Pipes and Filters	Process a data stream in a series of different steps
Blackboard	Several “workers” collaborating over a shared data set
Broker	Decouple distributed components
Model-View-Controller	Separate data and rules for data consistency from presentation and user input
Presentation-Abstraction-Control	Separate viewing and manipulating data into independent but cooperating agents
Microkernel	Support a minimal core where it is easy to plug in new components
Reflection	Separate the software into a self-aware “knows how to configure and run jobs” part and a “knows how to do the job” part

The architecture tactics are organised in a different way. The classic design patterns and architecture patterns are described with a generic problem, an example, a solution, and a discussion of the solution. Tactics start from the notion of quality attribute scenarios, which is a way to define the parameters of a quality requirement. Consider the example in Figure 1. In this scenario a user starts a transaction when the system is running as normal. The user expects the transaction to be processed within two seconds on average.

The next step is to find a tactic that can control the response such that the response measure is achieved. In the example in Figure 1, how may we ensure that transactions are processed within an average of two seconds? This is a performance issue, so we look in Bass et al. under Chapter 8, “Performance” and find the tactics listed in Table 2. We then choose the tactic(s) that best suit our particular problem.

Table 2: Performance Tactics from Bass et al.

Overall Strategy	Specific Tactics
Control Resource Demand	Manage Sampling Rate
	Limit Event Response
	Prioritise Events
	Reduce Overhead
	Bound Execution Times
	Increase Resource Efficiency
Manage Resources	Increase Resources
	Introduce Concurrency
	Maintain Multiple Copies of Computations
	Maintain Multiple Copies of Data
	Bound Queue Sizes
	Schedule Resources

Notice that tactics do not tell you exactly which components are needed, or what responsibilities they should have. Instead they merely discuss the solution, and things to consider when using this particular solution. It is then up to you to define which components you will need to implement the tactic, and where in your overall architecture (e.g. which layers) they fit. Not only does this give you a freedom as software designer, it enabled Bass and his colleagues to discuss and categorise architecture solutions for quality requirements that were traditionally “ignored” because they could not be expressed as a set of interacting components.

One part of architecture patterns which I have not mentioned yet is that just as there are basic design principles for object oriented designs, there are also good practices for architectures. C. Larman, Applying UML and Patterns, 3rd Edition summarises a set of these with respect to package design. These principles should be applied even when working within a particular architecture pattern or when designing in a particular architecture tactic.

• C. Larman, Applying UML and Patterns, 3rd Edition, Chapters:
  35. Package Design

• F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stahl. Pattern-Oriented Software Architecture - A System of Patterns. John Wiley & Sons, Chichester UK, 1996.
• L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, Third Edition. Addison-Wesley Publishing Co., Reading MA, 2012.
• A. Brown, G. Wilson, The Architecture of Open Source Applications, available online at: http://www.aosabook.org/en/index.html .
• The chapter on architectural tactics (Chapter 5) from the Second Edition of Bass, Clements, and Kazman

Go through the user stories for this sprint and make sure you have a clear understanding of how to solve each of them.

Revisit and update your risks and contingencies section.

Add and/or revise the following items to your glossary:

• Architecture Pattern (also the individual architecture patterns mentioned above)
• Architecture Tactic (also the individual tactics for different quality attributes)
• Quality Attribute Scenario

Make sure you understand what each item is, the notation for them, and how to use them either in isolation or together with the other concepts.

Study the architecture of a couple of open-source systems in the AOSA-book (http://www.aosabook.org/en/index.html). Identify the main challenges they have with respect to:

• Modifiability
• Performance
• Testability

You are free to study any of the systems, but you should be warned that not all of these texts actually describe the architecture of the applications or, if they do, in a way that enables evaluation with respect to quality attributes or tactics. I have previously used the following chapters for similar purposes in software architecture courses:

• Nginx
• Audacity
• Graphite

Once you have identified the main challenges for the system, explore the different architecture tactics that might address the challenges (Unless you have access to the third edition of Bass et al., you may use The chapter on architectural tactics (Chapter 5) from the Second Edition of Bass, Clements, and Kazman).

How did they decide to address the challenge? Which architecture tactics best correspond to their solution? Exactly how is this tactic instantiated into a workable system architecture?

The intention of this self-study task is that by going in one direction (from an already solved solution to a generic tactic) you also get experience in seeing how the other direction (going from the tactic to a workable solution) may be done.

This sprint, and the previous, describes a “top-down” approach to creating an architecture. By this I mean that you start with the problem and then you create an overall architecture, and then (theoretically) you continue by doing detailed design (e.g. with the help of RUP/UML) inside each component or module. How would this fit into a workflow that is primarily based on RUP/UML, which can be described as a more “bottom-up” approach?

Are there any other questions that you want answered? Add them, along with a brief strategy for how to find an answer.