32.7. Architectural Analysis within the UP
Caution: Waterfall Architectural Analysis
Architectural analysis methods and books often implicitly encourage waterfall-style extensive architectural design decisions before implementation. In iterative development and UP, apply these ideas in the context of small steps, feedback, and adaptation, rather than attempting to fully resolve the architecture before programming. Tackle implementation of the riskiest or most difficult solutions in early iterations, and adjust the architectural solutions based on feedback and growing insight.
Architectural Information in the UP Artifacts
The architectural factors (for example, in a factor table) are recorded in the Supplementary Specification.
The architectural decisions are recorded in the SAD. This includes the technical memos and descriptions of the architectural views.
The SAD and Its Architectural Views
In addition to the UML package, class, and interaction diagrams, another key artifact in the UP Design Model is the SAD. It describes the big ideas in the architecture, including the decisions of architectural analysis. Practically, it is a learning aid for developers who need to understand the essential ideas of the system.
When someone joins the team, a project coach can say, “Welcome to the NextGen project! Please go to the project website and read the ten page SAD in order to get an introduction to the major ideas.” During a later release, when new people work on the system, the SAD is a key learning aid.
Therefore, it should be written with this audience and goal in mind: What do I need to say (and draw in the UML) that will quickly help someone understand the major ideas in this system?
The essence of the SAD is a summary of the architectural decisions (such as with technical memos) and the UP architectural views.
Architectural Views in the SAD
Having an architecture is one thing; describing it is something else.
In [Kruchten95], the influential idea of describing an architecture with multiple views was promoted. The essential idea of an architectural view is this:
|
Architectural View A view of the system architecture from a given perspective; focuses primarily on structure, modularity, essential components, and the main control flows. [RUP]. An important aspect of the view missing from this RUP definition is the motivation. That is, an architectural view should explain why the architecture is the way it is. An architectural view is a window onto the system from a particular perspective that emphasizes the key noteworthy information or ideas, and ignores the rest. |
An architectural view is a tool of communication, education, or thought; it is expressed in text and UML diagrams.
In the UP, six views of the architecture are suggested (more are allowed, such as a security view).[3] All are optional, but documenting at least the logical, process, use case, and deployment views is recommended. The six views are:
[3] Early versions of the UP described the “4+1” views as defined in [Kruchten95], which evolved into the six views.
Conceptual organization of the software in terms of the most important layers, subsystems, packages, frameworks, classes, and interfaces. Also summarizes the functionality of the major software elements, such as each subsystem.
Shows outstanding use-case realization scenarios (as interaction diagrams) that illustrate key aspects of the system.
A view onto the UP Design Model, visualized with UML package, class, and interaction diagrams.
Physical deployment of processes and components to processing nodes, and the physical network configuration between nodes.
A view onto the UP Deployment Model, visualized with UML deployment diagrams. Normally, the “view” is simply the entire model rather than a subset, as all of it is noteworthy. See Chapter 38 for the UML deployment diagram notation.
Overview of the persistent data schema, the schema mapping from objects to persistent data (usually in a relational database), the mechanism of mapping from objects to a database, database stored procedures and triggers.
A view onto the UP Data Model, visualized with UML class diagrams used to describe a data model.
Summary of the most architecturally significant use cases and their non-functional requirements. That is, those use cases that, by their implementation, illustrate significant architectural coverage or that exercise many architectural elements. For example, the Process Sale use case, when fully implemented, has these qualities.
A view onto the UP Use-Case Model, expressed in text and visualized with UML use case diagrams.
First, a definition of the Implementation Model: In contrast to the other UP models, which are text and diagrams, this “model” is the actual source code, executables, and so forth. It has two parts: 1) deliverables, and 2) things that create deliverables (such as source code and graphics). The Implementation Model is all of this stuff, including web pages, DLLs, executables, source code, and so forth, and their organization—such as source code in Java packages, and bytecode organized into JAR files.
The implementation view is a summary description of the noteworthy organization of deliverables and the things that create deliverables (such as the source code).
A view onto the UP Implementation Model, expressed in text and visualized with UML package and component diagrams.
For example, the NextGen package and interaction diagrams shown in Chapter 30 on layering and logical architecture show the big ideas of the logical structure of the software architecture. In the SAD, the architect will create a section called Logical View, insert those UML diagrams, and add some written commentary on what each package and layer is for, and the motivation behind the logical design. Likewise with the process and deployment views.
A key idea of the architectural views—which concretely are text and diagrams—is that they do not describe all of the system from some perspective, but only outstanding ideas from that perspective. A view is, if you will, the “one minute elevator” description: What are the most important things you would say in one minute in an elevator to a colleague on this perspective?
Architectural views may be created:
after the system is built, as a summary and learning aid for future developers
at the end of certain iteration milestones (such as the end of elaboration) to serve as a learning aid for the current development team, and new members
speculatively, during early iterations, as an aid in creative design work, recognizing that the original view will change as design and implementation proceeds
Sample Structure of a SAD
Software Architecture DocumentArchitectural Representation (Summary of how the architecture will be described in this document, such as using by technical memos and the architectural views. This is useful for someone unfamiliar with the idea of technical memos or views. Note that not all views are necessary.) Architectural Factors and Decisions (Reference to the Supplementary Specification to view the Factor Table. Also, the set of technical memos the summarize the decisions.) Logical View (UML package diagrams, and class diagrams of major elements. Commentary on the large scale structure and functionality of major components.) Process View (UML class and interaction diagrams illustrating the processes and threads of the system. Group this by threads and processes that interact. Comment on how the interprocess communication works (e.g., by Java RMI). Use-Case View (Brief summary of the most architecturally significant use cases. UML interaction diagrams for some architectural significant use-case realizations, or scenarios, with commentary on the diagrams explaining how they illustrate the major architectural elements.) Deployment View (UML deployment diagrams showing the nodes and allocation of processes and components. Commentary on the networking.) |
Phases
Inception— If it is unclear if it is technically possible to satisfy the architecturally significant requirements, the team may implement an architectural proof-of-concept (POC) to determine feasibility. In the UP, its creation and assessment is called Architectural Synthesis. This is distinct from plain old small POC programming experiments for isolated technical questions. An architectural POC lightly covers many of the architecturally significant requirements to assess their combined feasibility.
Elaboration— A major goal of this phase is to implement the core risky architectural elements, thus most architectural analysis is completed during elaboration. It is normally expected that the majority of factor table, technical memo, and SAD content can be completed by the end of elaboration.
Transition— Although ideally the architecturally significant factors and decisions were resolved long before transition, the SAD will need a review and possible revision at the end of this phase to ensure it accurately describes the final deployed system.
Subsequent evolution cycles— Before the design of new versions, it is common to revisit architectural factors and decisions. For example, the decision in version 1.0 to create a single remote tax calculator service, rather than one duplicated on each POS node, could have been motivated by cost (to avoid multiple licenses). But perhaps in the future the cost of tax calculators is reduced, and thus, for fault tolerance or performance reasons, the architecture is changed to use multiple local tax calculators.