Although we all often use the term “architecture,” and we certainly use it in the book, there is no commonly accepted agreement on what architecture is and how it is described. As a result, if we ask to see the architecture of a system, we are usually given a set of diagrams and possibly documents that describe some, usually structural, aspects of that system. The purpose of this appendix is to explain what we mean when we say “architecture” and how we recommend describing it.
To define architecture, it is easier to start from its role, rather than to look at it as a set of artifacts. The following definition was derived from Mary Shaw and David Garlan (Shaw and Garlan 1996) and then refined by Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman from Rational.
“Software architecture encompasses the set of significant decisions about the organization of a software system including:
Selection of the structural elements and their interfaces by which the system is composed
Behavior as specified in collaborations among those elements
Composition of these structural and behavioral elements into larger subsystems
Architectural style that guides this organization
Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints and tradeoffs and aesthetic concerns.”
This definition emphasizes the fact that architecture involves a set of key design decisions, rules and patterns (a set of constraints) that define a framework in which the design and implementation of the system take place. Architectural decisions are the most fundamental decisions, and changing them late in the development of a system may have significant ripple effects on the system itself and on the project that is delivering the system.
It is impossible to describe any system from only a single perspective. The more complicated a system, the more aspects we need to consider and describe. Software systems are no exception, and describing them is particularly difficult because of software's invisibility.
To describe software systems, we use models. Each model captures a particular aspect of the system or is a projection of the system from what we call a viewpoint. A viewpoint describes:
One or more system model(s) and view(s) (projections) of those models
The stakeholders interested in the view(s)
The stakeholders' concerns that should be addressed through the view(s)
According to our definition, an architecture description is a subset of the system description, in that it addresses the critical design decisions made by the architect. Hence, an architecture is also represented through a set of views defined by viewpoints. As described in IEEE-1471-2000 (IEEE 2000) an architect can define his or her own viewpoints and views to communicate the architecture of the system. However, we recommend the following set of commonly used views:
The Requirements View, describing both functional and non-functional significant architectural requirements (commonly referred to as SARs)
The Logical View, which describes key design mechanisms, architecturally important design elements, their interdependencies and the organization of these elements into subsystems and layers
The Implementation View, which describes the key implementation elements such as code artifacts, executables, and modules
The Process View, which describes processes and threads, and the allocation of the logical and/or the implementation elements to these processes and threads
The Deployment View, which contains a description of various system nodes such as computers or routers, and the allocation of the logical, implementation, or process elements to these nodes
This set of views is known as the “4 + 1 architecture view model” and was first proposed by Philippe Kruchten (Kruchten 1995)[1]. It is easy to see that the views are consistent with the process artifacts discussed throughout this book. In other words, we can think of an architecture view as containing selected elements (those most relevant to the architecture) from the described process artifacts. The correspondence between the views and the major artifacts of the J2EE Developer Roadmap is shown in the Table A.1.
Table A.1. Correspondence Between Architecture Views and J2EE Developer Roadmap Artifacts
| View | J2EE Developer Roadmap Artifacts |
|---|---|
| Requirements View | Use-Case Model Supplementary Specification |
| Logical View | Design Model User-Experience Model Data Model Design Guidelines |
| Implementation View | Implementation Model |
| Process View | Design Model[2] |
| Deployment View | Deployment Model Implementation Model[3] (deployment support) |
[2] The Design Model is the main source of information for both Logical and Process Views. Its elements are sometimes also used in the Deployment View to show allocation of design elements to nodes. [3] The Implementation Model shows the allocation of implementation elements to system nodes. | |
The Software Architecture Document, commonly referred to as the SAD, is an artifact that is used in a number of activities discussed in the book. It is the primary artifact where the architecture of a system is described, and it contains references to all other architecturally significant artifacts. In other words, if someone wants to understand the architecture of a system, then the SAD is the place from which to start.
The SAD should show how the key architectural concerns are addressed, and so it is best organized along the architectural views discussed above. The following is a brief description of a commonly used SAD structure, with a short description of the content of its sections.
Introduction. This section describes the scope of the architecture and lists references to all supporting documents and artifacts. Artifacts that are usually referenced are the Glossary, the Supplementary Specification, the system models, and any standards and stakeholder documents that pertain to the system.
Architecture Representation. This section describes how the architecture is represented. We recommend the 4 + 1 view model as the base of the representation. However, the architect may want to add additional views or notations, and these should be described in this section.
The rest of this SAD structure description assumes that the 4 + 1 view model is followed.
Requirements View. This section is usually broken up into two subsections. The first subsection discusses the architecturally significant Use Cases.
The architecturally significant Use Cases are those that are developed in iterations of the Elaboration phase to:
Exercise and test the main system elements and their collaborations
Investigate identified areas of risk to assist with the definition of risk elimination and mitigation strategies.
The second subsection discusses system-wide architectural goals and constraints that are not associated with any Use Case in particular. It refers to the Supplementary Specification and describes the system-wide requirements and objectives that have significant impact on the architecture. This subsection should also describe requirements for system properties such as performance, size, scalability, security, and privacy. It may also capture special constraints such as use of off-the-shelf products, integration with legacy software, a reuse strategy, required development tools, and team structure and schedule.
Logical View. This section describes the architecturally significant parts of the Design Model, and the User-Experience Model, and may also reference the Design Guidelines. It should start with a discussion of the significant design mechanisms and patterns that shape the system structure. It should then discuss system decomposition into layers and Design Subsystems, as well as any other architecturally significant design elements (such as Framework Components and Design Classes). The key abstractions of the system are also considered architecturally significant and should be described in this section. The descriptions of the architecturally significant design elements should reference specific parts of the Design Model, where the element's responsibilities and relationships are specified.
In cases of a complicated or unusual user experience, the description of the architecturally significant design elements should also reference parts of the User-Experience Model and explain dependencies between those design elements and user-experience elements (Screens and input forms) and the Screen flows, as documented in the Use-Case Storyboards.
This section should illustrate how the architecturally significant design elements work together. This is best done by showing a few selected Use-Case Realizations of the architecturally significant Use Cases and by explaining how the design elements contribute to their functionality.
Process View. This section is particularly important in systems that manage operating system processes and threads. The J2EE technologies support computing resource management. Hence, in the case of J2EE-based systems the Process View is usually only used to describe any desired application concurrency (application concurrency is discussed in more detail in Chapter 8, Design). In such cases, the Process View can describe:
The servlets used to create and manage multiple threads of control
Any Java applications that the system integrates with that manage their own threads of control, and the design elements with which those Java applications communicate
The use of JMS or message-driven EJBs to manage the application concurrency
Implementation View. This section is a view of the Implementation Model, with the emphasis on the structure of the model (the Java packages and virtual directories). This view is important because the structure of the Implementation Model has a major impact on, for example, concurrent development and testing.
Deployment View. This section is a view of the Deployment Model and the Implementation Model. It shows one or more network (hardware) configurations on which the system is deployed and runs. It also shows the allocation of containers to nodes and the allocation of J2EE modules (Implementation Model elements) to the containers.
It is also possible and sometimes informative to show how design elements (such as Design Subsystems and Framework Components) are allocated to nodes.
System Properties. The SAD should conclude with a discussion of how the software architecture contributes to achieving the architectural goals and constraints described in the Requirements section. The System Properties section is where this discussion should take place.
This section usually includes a discussion of key system properties such as performance and portability.