Creating Architectural Understanding

Let's return to the definitions of software architecture provided earlier. An important criterion for the development team is that they have some way to identify, describe, communicate, and modify their understanding of the architecture, without resorting to the source code. One or more models must exist in order for the team to actually operate at the "big picture" level. There are a variety of models for doing this, and I've had good success with several of them. Recently, I adopted the Rational "4+1" model, which captures several of the most useful models in one convenient approach (see the references for other models you may wish to consider).

Based primarily on resolving the needs of key participants in the software process, the Rational 4+1 model recommends four primary views of the architecture, as shown in Figure 1-1. Philippe Kruchten, the creator of 4+1, defines these views as follows :

  • Logical view. The logical view provides the static snapshot of the relationships that exist among objects or entities in the development of the system. This view may actually have two or more representations, one of the conceptual model and the other of the realization of the model in a database schema.

  • Process view. The process view describes the design's concurrency and synchronization aspects.

  • Physical view. The physical view describes the mapping of the software onto the hardware, including distribution of processing components created to achieve such goals as high availability, reliability, fault tolerance, and performance.

  • Development view. The development view describes the software's static organization in its development environment.

Figure 1-1. Rational 4+1 model


Software designers can organize their architectural decisions around the four views. To make the system easier to understand, each view can be described in the context of few key use cases (all of the use cases constitute the "+1" architectural view.

In truth, this approach should be referred to as " n +1", because nothing in it restricts the architect to just four views. Indeed, all of the major disciplines for representing software architectures explicitly recognize the need for multiple views for correct architecture modeling. As near as I can tell, no one dogmatically requires that you use exactly three or five views. Instead, they encourage you to understand the communication properties of a given view and then use this view as needed.

This shouldn't be surprising, as the concept of multiple models of complex systems is quite common. I have both built and remodeled homes and in the process have learned to carefully read the many models of the home produced by the architectfrom the site plan to the electrical plan to the lighting plan to the elevations and to the plumbing plan. The specialized and skilled workers creating a home need all of these models, and to the extent possible I want to make certain that they will result in a home I will like.

The value of plans, like the various viewpoints of architecture promoted by Rational and others, is that they provide artifacts of relatively enduring value to the team. More generally , the parts of the architecture whose capture is worthy of your time, energy, and money deal with the relatively stable aspects of the problem, the problem domain, the business model (see Chapter 4), and the idiosyncratic aspects of the technical solution that exist between all of these things.

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: