Architectural Viewpoints

Looking at an architecture description is like looking at a condensed version of the entire set of development artifacts. Organized by viewpoint and view, the architecture description probably has accompanying models and possibly architectural prototypes as well. Many software descriptions have numerous references to vendors' specification sheets. Another important part of an architectural description is the mappings from one viewpoint to another. These mappings are the traceability links that associate an artifact in one view with one in another.

Requirements Viewpoint

The requirements viewpoint in an architecture description provides the support and the reasoning for the decisions made elsewhere. It is the viewpoint that in Kruchten's paper ties all the others together. The requirements viewpoint, concerned with the context of the system, is a representation of the significant architectural requirements (SARs), which influence the structure, arrangement, and constraints for all the other parts of the developing system. Although the views may seem like duplication of all the other documents under development, it should be pointed out that these artifacts represent the architecturally significant requirements, the ones that have driven the decisions made elsewhere in the software architecture.

The requirements viewpoint is organized into the following views:

• Domain view, or view of the business model. The domain view expresses the business context of the system. The domain view is expressed with business use cases, realizations, and objects, and it includes a glossary and may refer to other external documents, such as industry standards or regulations.
• Functional requirements view, which describes the "observable" of the system, typically from the perspective of an actor of the system. These requirements are usually expressed with use case models and specifications but can be expressed in any terms.
• Nonfunctional requirements view, or all those architecturally significant system requirements that are not expressed in the clear terms of functionality. Although they may be observable, these types of requirements, such as performance, robustness, and security, tend to be spread across the system. It is important to capture these requirements with discrete elements to enable traceability. When a decision is made in another part of the architecture because of a nonfunctional SAR, a traceability link can be made to it, thus providing important information to the team implementing that decision in the real system. The SAR explicitly states the justification for the decision. Should that decision ever be questioned late in the process, it can be traced to its rationale.

Design Viewpoint

The design viewpoint contains what most of us would recognize as an architecture document. The design viewpoint describes the system's major subsystems and processes, outlining significant third-party components and middleware to be used. Including this sinformation about middleware vendors' specifications and documentation is important because the fact that components and frameworks are used implies that the application is subject to the design decisions and constraints that the vendor made to produce the components.

The reality of software development is that software teams don't write every line of code in the application. Today's software relies heavily on third-party components and frameworks, and this is generally a good thing. Because these third-party components are pieces of software themselves, their creation was subject to numerous design decisions. Unless the system that uses these components is willing to accept the design decisions of the component's maker, the component should not be used. Fortunately, most middleware and reusable components are made with a high standard of quality and are based on decisions geared toward the typical users of the components. Still, it is wise to understand exactly what you are usingits motivations, rationale, and purposebefore using it in your system.

Most content of the design viewpoint is expressed in a UML model. UML provides the rigid semantics to accurately express the type of content that concerns the design viewpoint. This viewpoint has two major views.

The logical view is the expression of the objects that make up the system. This view includes the structural relationships of logical objects that make up the system and their collaborations. This view is almost always in a UML model. The complexity of today's systems demands a visualization tool like UML for understanding them.

The process view focuses on the activities of the CPU (central processing unit). This view shows which processes and threads of control are active. Most important, the process view shows which activities are executing concurrently during the execution of the system.

Realization Viewpoint

The realization viewpoint expresses how the elements of the logical and process views are implemented in the system. This viewpoint, along with the design viewpoint, comprise the classic architecture specification. This viewpoint includes the UML deployment view, which encompasses the nodes of the system and their topology, and addresses the distribution aspects of the system, including not only the nodes of the system but also all communication mechanisms: CORBA, RMI, DCOM, SOAP, and XML. In discussions of these mechanisms, it is often a good idea to identify their performance limits and expectations.

It also helps to justify specific decisions in this viewpoint with rationale backed by elements in the requirements viewpoint. For example, because SOAP is more flexible and accommodating than the proprietary DCOM, the choice of less efficient SOAP over DCOM to communicate with the shipping department's system would be justified by the expectation that the shipping system will be replaced by an unknown system during the life expectancy of this system and by the low overall volume of traffic expected between the two systems.

Realizations of the logical and process elements of the system are associated with the system's nodes in this viewpoint. For example, it should be obvious which nodes in the system are responsible for managing personal account information. If any deployment unitlogical and component packageof the system is concurrently executed on multiple nodes, this section of the architecture must clearly express all the issues and strategies for managing concurrency. It might be as simple as letting the single database node manage concurrent entity instances, or there might be a complex strategy. As an architect, designer, or deployment engineer, if you are interested in concurrency and deployment issues, the realization viewpoint is one place in the architecture document where that information is expressed.

This viewpoint is also a key area for expressing some scalability strategies for the system. Scaling typically involves the addition of processing nodes. Just how the nodes of the system are arranged and how they would be altered to meet the system's scalability requirements is a core focus of this viewpoint.

This viewpoint might also refer to development environment issues, such as shared libraries, namespaces, and compiler and tool configurations. This might even extend to coding or naming conventions. For example, the EJB 1.1 specification requires certain naming conventions for property GET and SET methods. These conventions are required for Enterprise JavaBeans to work properly in standard containers. Similar conventions might be employed on projects developing in-house tools or postcompilers.

The final element of this viewpoint is the class and component implementations or source code. Because this is an architecture document, it obviously doesn't mean that the entirety of the system's source code is included. The system itself hasn't even been constructed yet. Instead, only key source code exemplars are necessary for the architecture document. These might include standardized ways to provide class GET and SET methods, handle variable association multiplicities0..n associationsor acceptable sorting algorithms.

Test Viewpoint

The test viewpoint is considered a companion viewpoint because its artifacts play a special role in the development process. That role is to provide feedback to the development team and stakeholders. In its purest form, the results of the test workflow provide quality and performance measures of the evolving system against the system's requirements. The practical reality is that a well-integrated testing team will evaluate not only any distributable part of the system but also any artifact produced in the process.

In one of my earliest consulting experiences, I had the opportunity to work with a top-notch test engineer. The organization not only managed to find such an excellent individual but also had the foresight to ensure that this person reported directly to executive management, bypassing the project manager. This organization was serious about quality. Because testing was involved very early in the process, many of the requirements artifacts were reviewed with an eye toward their eventual use downstream by the testing team. This eliminated many ambiguities that might have had to be resolved when the testing occurred. The test engineer's influence also extended into other areas of the project's artifacts, such as coding, user interface, and design standards.

When an architect expresses an application's test viewpoint, the expected testing strategies and frameworks are included. This viewpoint essentially outlines the requirements for the creation of the test plan, which is the formal document that describes the purpose and the goals of the testing effort and outlines the team's strategies and scope. In the architecture document, the scope and the general strategies for testing are explained.

Of particular importance to Web and Internet applications is the scope of testing Internet-specific features. Delivering an application on the Internet is more than connecting a server to the Internet. Ensuring that the system meets the needs of the users might involve testing things outside of the scope of the organization's control. For example, some ISPs perform automatic page caching, and many organizations have firewalls that limit certain kinds of network traffic. The testing team needs to have a strategy for addressing and identifying these things outside the influence of the development team.

Viewpoint Mappings

Because only one system is being developed and all the views and viewpoints in the system's architecture describe this one system, the mappings among the views can provide significant architectural information. A mapping is the connection of one element in a view to another element(s) in another view. Some of these mappings are rather common and exist outside the architecture document. For example, use case realizations are a modeling element in the logical analysis model: design viewpoint. They express a use case's dynamic behavior in terms of analysis model objects.

Most of the valid mappings have been described with UML «trace» dependencies in the artifact set diagrams of Chapter 6. Their significance in the architecture document is that they enable conceptual connections among the views. Highlighting important mappings in the architecture document might fill some conceptual gap that would make understanding the system's architecture easier.