Process: Iterative Architecture in the UP - UML

The UP is an architecture - centric iterative and evolutionary method. This does not mean a waterfall attempt to fully identify all architectural requirements before development, nor an attempt to fully design the "correct" architecture before program and test. Rather, it means that early iterations focus on programming and testing architecturally significant concerns (such as security) and using, proving, developing and stabilizing the key architectural elements (subsystems, interfaces, frameworks, and so on).

In the UP, the architecture evolves and stabilizes through early development and test with an architecture - focus, not through speculation on paper, or "PowerPoint Architecture." In the UP, the architectural factors - or requirements - are recorded in the Supplementary Specification, and the architectural decisions that resolve them are recorded in the Software Architecture Document (SAD). Because the UP is not the waterfall, the SAD is not fully created before programming, but rather, after programming - once the code has stabilized. Then, the SAD documents the actual system as a learning aid for others.

Architectural analysis starts early, during the inception phase, and is a focus of the elaboration phase; it is a high - priority and very influential activity in software development.

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.


Inception— If it is unclear whether 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 toleragice or performance reasons, the architecture is changed to use multiple local tax calculators.

Recommended Resources

There is a growing body of architecture - related patterns, and general software architecture advice Suggestions:

  • Beyond Software Architecture [Hohman03]. This useful guide, from someone experienced as both architect and product manager, brings a business - oriented emphasis to architecture. Hohman shares his experience with important issues seldom covered, such as the impact of the business model, licensing, and upgrades on the software architecture.
  • Ppatterns of Enterprise Application Architecture.
  • Software Architecture in Practice.
  • Pattern - Oriented Software Architecture, both volumes.
  • Pattern Languages of Program Design, all volumes. Each volume has a section on architecture - related patterns.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics