Architecture is about everything, yet it is not everything. It is about the architecturally significant things in everything that stakeholders and developers must understand in order to comprehend the whole system. The architecture description is an important artifact because it describes the architecture as manifested in the architecture baseline—a skinny system that will become the final system. Recall that the architecture baseline is an early version of the system. Since a system is described by a set of models, the architecture baseline is also described by an early version of these models. The architecture description has views of these models—we call them architectural views—which it collates and presents in an understandable way to both stakeholders and developers. Through the architecture description, you can evaluate whether the goals and constraints of the system are met and whether there is effective separation of concerns. The architecture description serves as the roadmap by which the rest of the system is developed.
The architecture encompasses the important decisions that make the project successful—decisions about the structure of the system, about how functionality, performance, reliability, and other requirements are met, and so on. The architecture is manifested in an early version of the system, which we call the skinny system or the architecture baseline. It demonstrates that the decisions you have made are valid in the sense that they have correctly and feasibly addressed stakeholder concerns.
Since the system is described by a set of models, the skinny system (architecture baseline) is also described by a version of these models (see Figure 18-1).
The skinny system also has an accompanying architecture description. The architecture description is, at the end of elaboration phase, an extract (i.e., a set of views) of the models in the architecture baseline. The architecture description thus manifests what the architecture is—major decisions made about the system.
You may need to rewrite the views and remove the non-architecturally significant elements to make them more readable. The views include the architecturally significant elements. Thus, the architecture description includes descriptions of architecturally significant use cases, architecturally significant analysis elements, architecturally significant design elements, and so on. Many model elements that are part of the architecture baseline also show up in the architecture description. However, not all of them do, because to get an operational system, you may need to develop some model elements that are not architecturally interesting but are needed just to produce executable code. When it comes to the use-case model, you may need to specify much more than the architecturally significant use cases because you need to know about more use cases to be able to pinpoint the use cases that are indeed architecturally significant. The same goes for the analysis model, but to a lesser extent. When it comes to the design model, at the time that you establish the architecture baseline, the version of the contents within the design model is largely architecturally significant.
Actually, the architecture description is developed concurrently, often even ahead of the activities that result in the version of the models that are parts of the architecture baseline. The architecture description is the standard for the development team to build the rest of the system. Since the architecture should be stable, the standard (i.e., the architecture description) should be stable after the elaboration phase.
The architecture description must be updated throughout the system’s lifetime to reflect the changes and additions that are architecturally relevant. The architecture description itself may need to be modified, but it need not grow in size. It is just updated to stay relevant.
Recall that the architecture description is just a proper extract of the models of the system (i.e., it does not add anything new). Given that we don’t try to make a more readable rewrite of these extracts, the architecture description looks very much like ordinary models of the system. This appearance means that the architectural view of the use-case model looks like an ordinary use-case model. The only difference is that this architectural view contains only architecturally significant use cases and more specifically only the scenarios that are architecturally significant, whereas the final use-case model contains all the use cases. The same goes for the architecture view of the design model. It looks like a design model, but it realizes only the use cases that are architecturally interesting.
The truth is this: Even though architecture is extremely important, it is not that special when it comes to content and modeling. In a book like this, it is practically impossible to show how to develop both the architecture and the models. We can only give you a feeling for how it proceeds.
In the following sections, we describe the architectural views of the use-case model, the analysis model, and the design model. Since the implementation model is a straightforward mapping, there is usually no need to describe its view.
Our intent is to provide an extract of the important pieces in the respective models; we do not describe the contents in detail, since they are explained in preceding chapters. Our discussion in this chapter focuses how you choose architecturally significant elements.
The architectural view of the use-case model presents the most important actors and use cases (or scenarios of these use cases). Many architecturally significant use cases come from risks of different kinds. Risks can be associated with functional requirements, nonfunctional requirements, or platform specifics. Thus, architecturally significant use cases encompass both application and infrastructure use cases.
Groups of use cases in a system follow similar behavioral patterns. You naturally choose one representative use case per group to be part of the architecturally significant use cases, because once you solve that particular use case, you can solve the other use cases in the group. After all, they use the same design principles. This is also why, in the preceding chapters, we explored use cases that belong to different categories—application use cases, application extension use cases, infrastructure use cases, and so forth.
The architecturally significant use cases for the Hotel Management System are depicted in Figure 18-2. It shows both application and infrastructure use cases, albeit only the important ones. Note that the architectural view of the use-case model is not just a diagram. The use-case diagram itself does not say much. You need to describe the critical scenarios or at least a brief description of the use cases to help the reader understand what the architecturally significant use cases are about.
The Reserve Room use case is the most important use case, as the fundamental goal of the system is to provide online reservations to customers. Whereas the room reservations by customers are conducted over the Internet, customer check in is performed by counter staff at the hotel itself, and it involves an entirely different set of user interfaces (a thick client as opposed to a Web-based client). The Check In Customer use case is chosen as a representative of functionality provided to hotel staff. Together, the realizations of these three use cases exercise a large portion of the application and domain layers in the design model.
In this case, Handle Authorization is deemed critical, since stakeholders are concerned with security. <Handle Distribution> is also critical, since stakeholders are concerned with scalability of the system.
The <Perform Transaction> use case is not considered architecturally significant in this case. Nevertheless it is still depicted in Figure 18-2. This is because Handle Authorization and <Handle Distribution> are extension use cases and it is necessary to show the use case which they extend. In this case, it is the <Perform Transaction> use case.
To simplify our discussion, we choose only one use case, Reserve Room, to drive the architectural views of the analysis model and design model. In an actual project, you will probably need to describe all the identified architecturally significant use cases.
The architectural view of the analysis model presents the architecturally most important classifiers of the analysis model. Recall that the analysis model comprises an analysis element structure (a containment hierarchy of layers, packages, and analysis classes: i.e., boundary, control, and entity) and a use-case analysis structure (comprising use-case slices, aspects, class extensions). The architectural view of the analysis model also presents how the most important use cases are realized in terms of these elements (i.e., use-case realizations). It is natural to find architecturally significant classifiers present in these realizations. You extract several diagrams to describe these architecturally significant elements and realizations.
Figure 18-3 identifies the architecturally significant analysis elements from among others in the analysis element structure. The shaded packages indicate these important elements.
The choice of architecturally significant analysis elements is motivated by the same criteria that motivates the choice of architecturally significant use cases. Reservation is central to the Hotel Management System, and so are security and distribution. In addition, the rich-client interface used at the staff counters is critical and must be responsive.
You do not need to describe every subsystem or package in detail, but only the architecturally significant ones, and you often find them participating in the realization of architecturally significant use cases.
You depict the realization of architecturally significant use cases in a diagram. Figure 18-4 depicts the realization of an architecturally significant use case—the Reserve Room use case—as an example.
You can depict the Reserve Room use-case realization with authorization added, or you can depict the realization of Handle Authorization in a separate diagram.
The analysis model also contains a use-case structure. The use-case structure attempts to keep the specifics of use cases separate in the analysis model. Figure 18-5 depicts some of the slices, and highlights (shaded) those that are of architectural significance. As you might expect, the choice of the architecturally significant use-case slices follows naturally the architecturally significant use cases. That is why the Reserve Room and Check In Customer use-case slices are shaded.
In the architecture description, you depict the contents of architecturally significant use-case slices. Figure 18-6 shows the contents of the Reserve Room use-case slice as an example.
The architectural view of the design model presents the most architecturally significant elements in the design model. Recall that the design model comprises a deployment structure, a process structure, a design element structure, and a use-case design structure. The architectural view of the design model is an extract of these structures. Frequently, you find that a sizeable portion of the deployment and process structures are architecturally significant.
The purpose of the design model is to deal with platform specifics. These platform specifics are driven not by functionality, but by the deployment environment and the technologies available in that environment. So, you present the extract of the deployment structure first. You then zoom down to an extract of the process structure and show how they map to the chosen elements in the deployment structure. Thereafter, you zoom down to an extract of the design element structure and the use-case design structure.
Figure 18-7 depicts the architectural view of the deployment structure. It comprises the deployment elements (i.e., nodes) that participate in the realization of the Reserve Room and Check In Customer use cases. Both of these, as you recall, are architecturally significant use cases. Figure 18-7 is also annotated with the architect’s choice of communication mechanisms, implementation languages, and technologies. The shaded elements are architecturally significant.
Figure 18-8 depicts the architectural view of the process structure. It refines Figure 18-7 to show how these processes map to the deployment elements. The Web container and EJB container are both architecturally significant process elements in this case. So is the thick client, because a very responsive user interface is needed.
The architectural view of the design element structure comprises several diagrams depicting the architecturally significant design elements individually and their relationship with elements in other structures.
Minimal Design. You can have diagrams to describe design elements before the incorporation of platform specifics (see Figure 18-9).
Platform Specifics. You can have diagrams to describe design elements after the incorporation of platform specifics (see Figure 18-10).
Process Mapping. You can have diagrams to describe how design elements map to the process structure (see Figure 18-11).
The design realization of the Reserve Room use case demonstrates how you describe architecturally significant design elements.
Figure 18-9 depicts the components realizing the Reserve Room use case. It illustrates how the components interact with one another and what primary classes are needed to realize the architecturally significant use case.
Figure 18-10 depicts the components realizing the Reserve Room use case, but unlike Figure 18-9, it shows the platform-specific parts. This is useful in understanding which classes are needed to adapt the minimal design classes, or POJOs, onto the runtime platform.
Figure 18-11 shows the design elements participating in the Reserve Room use-case realization. These design elements are mapped to the process structure, specifically to the Web container and the EJB container within the application server. This diagram clarifies where the design classes execute and is useful for determining which artifacts (binaries, etc.) run on which node. These artifacts are subsequently deployed onto the respective containing nodes.
The architectural view of the use-case design structure comprises a number of diagrams depicting the architecturally significant use-case design slices. Since distribution is a critical part of the Hotel Management System, and the Reserve Room use case is an important use case, the Reserve Room distribution use-case slice is architecturally significant. This is depicted in Figure 18-12.
The architecture description is the most important artifact. It is used to clearly communicate the architecture to stakeholders and project members. It contains detailed descriptions of the architecturally important views of the models that represent the system. Thus, in the architecture description, you find architectural views of the use-case model, the analysis model, the design model, and so on. To show how the various views relate to each other, it is useful to describe them from the perspective of the realization of some critical use case. In this way, you can systematically guide the reader from a very high-level description in the use case and analysis model to the smallest details in the design model. From this understanding, the reader can better evaluate all kinds of structures in the system—element structure, use-case structure, and so on—and, if necessary, improve these structures.
It is important to note that what we have discussed in this chapter is but one way to describe the architecture. You must choose diagrams according to the needs of your project. Drafting the architecture description takes some effort. However, this investment is well worth the effort, as it ensures that you can gracefully grow the system during the rest of the project lifetime, and even more importantly, throughout the system’s lifetime.