Section 18.1.  Architecture Description Comprises Architectural Views

18.1. Architecture Description Comprises Architectural Views The architecture encompasses the important decisions that make the project successfuldecisions 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). Figure 18-1. System models, views, and architecture. [View full size image] 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 ismajor 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.