Architectural Perspectives

 Architectural Perspectives

we explained how we use viewpoints (such as the Context, Functional, Information, and Deployment viewpoints) to guide the process of capturing and representing the architecture as a set of views, with the development of each view being guided by the use of a specific viewpoint. When creating a view, your focus is on the issues, concerns, and solutions pertinent to that view. So, for an Information view, for example, you focus on things such as information structure, ownership, transactional integrity, data quality, and timeliness. Many of the important concerns that are pertinent to one view are much less important when considering the others. Data ownership, for example, is not key to formulating the Concurrency view, nor is the development environment a major concern when considering the Functional view. (Of course, the decisions taken in one view can have a considerable impact on the others, and it is a big part of the architect’s job to make sure that these implications are understood. However, the concerns addressed in different views are largely different.) Although the views, when combined, form a representation of the whole architecture, we can consider them largely independent of one another—a disjoint partition of the whole architectural analysis. In fact, for any significant system, you usually must partition your analysis this way because the entire problem is too much to understand or describe in a single piece.

Quality Properties

 Many architectural decisions address concerns that are common to many or all views. These concerns are normally driven by the need for the system to exhibit a certain quality property rather than to provide a particular function. In our experience, trying to address these aspects of an architecture by using viewpoints doesn’t work well. Let’s look at an example to understand why.

As the example shows, there is an inherent need to consider quality properties such as security in each architectural view. Considering a quality property in isolation just doesn’t make sense, so using a viewpoint to guide the creation of another view for each quality property doesn’t make sense either

Architectural Perspectives

 Going back to our example, although security is clearly important, representing it in our conceptual model of software architecture as another viewpoint doesn’t really work. A comprehensive security viewpoint would have to consider process security, information security, operational security, deployment security, and so on. In other words, it would affect exactly the aspects of the system that we have considered so far using our viewpoints. Rather than defining another viewpoint and creating another view, we need some way to modify and enhance our existing views to ensure that our architecture exhibits the desired quality properties. This should define the activities that we would perform to determine whether the architecture exhibits the required quality properties, some proven architectural tactics that we would apply to improve the architecture if we discover that it doesn’t, and some guidelines we would follow to help us apply these tactics in the right way. We therefore need something in our conceptual model that can be considered “orthogonal” to viewpoints, and we have coined the term architectural perspective (which we shorten to perspective) to refer to it.

Although our use of the term perspective is relatively new compared to the other concepts we discuss in the book, the ideas behind it have a very established pedigree. The issues addressed by perspectives are often referred to as cross-cutting concerns or nonfunctional requirements of the architecture, although we prefer not to use this latter term. 1 With perspectives, we are trying to systematize what a good architect does anyway—understand the quality properties that are required; assess and review the architectural models to ensure that the architecture exhibits the required properties; identify, prototype, test, and select architectural tactics to address cases when the architecture is lacking; and so on.

An example architectural tactic for achieving satisfactory overall system performance might be to define different processing priorities for different parts of the system’s workload, and to manage this by using a priority-based process scheduler. The concept of architectural tactics was created and developed by the software architecture researchers at the Carnegie Mellon Software Engineering Institute (SEI), and although our definition is worded slightly differently from theirs, our approach to tactics is based directly on their work in this area. Don’t confuse tactics with design patterns, which we discuss in Part II. Although tactics and patterns are both valuable sources of design knowledge, a tactic is much more general and less constraining than a classical design pattern because it does not mandate a particular software structure but provides general guidance on how to design a particular aspect of your system. (See the Further Reading section at the end of this chapter for some references on tactics.) A perspective provides a framework to guide and formalize this process. This means that you never work with perspectives in isolation but instead use them with each view of your architecture to analyze and validate its qualities and to drive further architectural decision making. We describe this as applying the perspective to the view.