Topics

References To top of page

The references section presents external documents which provide background information important to an understanding of the architecture of the system. If there are a larger number of references, structure the section in subsections:

  1. external documents
  2. internal documents
  3. government documents
  4. non-government documents
  5. etc.

Architectural Goals and Constraints To top of page

The architecture will be formed by considering:

  • functional requirements, captured in the Use-Case Model, and
  • non-functional requirements, captured in the Supplementary Specifications

However, these are not the only influences that will shape the architecture: there will be constraints imposed by the environment in which the software must operate; by the need to reuse existing assets; by the imposition of various standards; by the need for compatibility with existing systems, and so on.  There may also be a preexisting set of architectural principles and policies which will guide the development, and which need to be elaborated and reified for the project.  This section of the Software Architecture document is the place to describe these goals and constraints, and any architectural decisions flowing from them which do not find a ready home (as requirements) elsewhere. 

When this document is created, an important input is a specification of the implementation environment. Examples of things that should be specified are target platform (hardware, operating system), window system, development tools (language, GUI builder), database management system, and component libraries.  It is also valuable to specify which user interface technologies are allowed and which are not.  Many systems choose to not use certain presentation technologies (JavaScript, Applets, Frames, XML, etc.) so that more client systems are capable of using the application, or to make the application easier to develop.  The decisions are captured here in the Software Architecture Document, while the details for how to use and apply the chosen technologies is documented in the artifact: Project Specific Guidelines.

The enforcement of these decisions is achieved by framing a set of architecture evaluation criteria which will be used as part of the iteration assessment.

Evaluation criteria are also derived from Change Cases which document likely future changes to:

  • the system's capabilities and properties
  • the way the system is used
  • the system's operating and support environments

Change Cases clarify those properties of the system described by subjective phrases such as, "easy to extend", "easy to port", "easy to maintain", "robust in the face of change", and "quick to develop". Change Cases focus on what is important and likely rather than just what is possible.

Change Cases try to predict changes: such predictions rarely turn out to be exactly true.

The properties of a system are determined by users, sponsors, suppliers, developers, and other stakeholders. Changes can arise from many sources, for example:

  • Business drivers: new and modified business processes and goals
  • Technology drivers: adaptation of the system to new platforms, integration with new components
  • Changes in the profiles of the average user
  • Changes in the integration needs with other systems
  • Scope changes arising from the migration of functionality from external systems

The Use-Case View To top of page

The Use-Case View presents a subset of the Artifact: Use-Case Model, presenting the architecturally significant use-cases of the system. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture.

If the model is larger, it will typically be organized in packages; for ease of understanding the use-case view should similarly organized by package, if they are packaged. For each significant use case, include a subsection with the following information:

  1. The name of the use case.
  2. A brief description of the use case.
  3. Significant descriptions of the Flow of Events of the use case. This can be the whole Flow of Events description, or subsections of it that describe significant flows or scenarios of the use case.
  4. Significant descriptions of relationships involving the use case, such as include- and extend-relationships, or communicates-associations.
  5. An enumeration of the significant use-case diagrams related to the use case.
  6. Significant descriptions of Special Requirements of the use case. This can be the whole Special Requirements description, or subsections of it that describe significant requirements.
  7. Significant Pictures of the User Interface, clarifying the use case.
  8. The realizations of these use cases should be found in the logical view.

The Logical View To top of page

The Logical View is a subset of the Artifact: Design Model which presents architecturally significant design elements. It describes the most important classes, their organization in packages and subsystems, and the organization of these packages and subsystems into layers. It also describes the most important use-case realizations, for example, the dynamic aspects of the architecture.

A complex system may require a number of sections to describe the Logical View:

  1. Overview

    This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers. If the system has several levels of packages, you should first describe those that are significant at the top level. Include any diagrams showing significant top-level packages, as well as their interdependencies and layering. Next present any significant packages within these, and so on all the way down to the significant packages at the bottom of the hierarchy.

  2. Architecturally Significant Design Packages

    For each significant package, include a subsection with the following information

    1. Its name.
    2. A brief description.
    3. A diagram with all significant classes and packages contained within the package. For a better understanding this diagram may show some classes from other packages if necessary.
    4. For each significant class in the package, include its name, brief description, and, optionally a description of some of its major responsibilities, operations and attributes. Also describe its important relationships if necessary to understand the included diagrams.
  3. Use-Case Realizations

    This section illustrates how the software works by giving a few selected use-case (or scenario) realizations, and explains how the various design model elements contribute to their functionality. The realizations given here are chosen because they represent some significant, central functionality of the final system; or for their architectural coverage - they exercise many architectural elements - or stress or illustrate a specific, delicate point of the architecture. The corresponding use cases and scenarios of these realizations should be found in the use-case view.

    For each significant use-case realization, include a subsection with the following information

    1. The name of the realized use case.
    2. A brief description of the realized use case.
    3. Significant descriptions of the Flow of Events - Design of the use-case realization. This can be the whole Flow of Events - Design description, or subsections of it that describe the realization of significant flows or scenarios of the use case.
    4. An enumeration of the significant interaction or class diagrams related to the use-case realization.
    5. Significant descriptions of Derived Requirements of the use-case realization. This can be the whole Derived Requirements description, or subsections of it that describe significant requirements.

Architecturally Significant Design Elements

To assist in deciding what is architecturally significant, some examples of qualifying elements and their characteristics are presented:

  • A model element that encapsulates a major abstraction of the problem domain, such as:
    • A flight plan in an air-traffic control system.
    • An employee in a payroll system.
    • A subscriber in a telephone system.

    Sub-types of these should not necessarily be included, e.g. Distinguishing an ICAO Standard Flight Plan from a US Domestic Flight Plan is not important; they are all flight plans and share a substantial amount of attributes and operations.

    Distinguishing a subscriber with a data line, or with a voice line, does not matter as long as the call handling proceeds in roughly the same way.

  • A model element that is used by many other model elements.
  • A model element that encapsulates a major mechanism (service) of the system
  • Design Mechanisms
    • Persistency mechanism (repository, database, memory management).
    • Communication mechanism (RPC, broadcast, broker service).
    • Error handling or recovery mechanism.
    • Display mechanism, and other common interfaces (windowing, data capture, signal conditioning, and so on).
    • Parameterization mechanisms.

In general, any mechanism likely to be used in many different packages (as opposed to completely internal to a package), and for which it is wise to have one single common implementation throughout the system, or at least a single interface that hides several alternative implementations.

  • A model element that participates in a major interface in the system with, for example:
    • An operating system.
    • An off-the-shelf product (windowing system, RDBMS, geographic information system).
    • A class that implements or supports an architectural pattern (such as patterns for de-coupling model elements, including the model-view-controller pattern, or the broker pattern).
  • A model element that is of localized visibility, but may have some huge impact on the overall performance of the system, for example:
    • A polling mechanism to scan sensors at a very high rate.
    • A tracing mechanism for troubleshooting.
    • A check-pointing mechanism for high-availability system (check-point and restart).
    • A start-up sequence.
    • An online update of code.
    • A class that encapsulates a novel and technically risky algorithm, or some algorithm that is safety-critical or security-critical, for example: computation of irradiation level; airplane collision-avoidance criteria for congested airspace; Password encryption.

The criteria as to what is architecturally significant will evolve in the early iterations of the project, as you discover technical difficulties and begin to better understand the system. As a rule however, you should label at most 10% of the model elements as "architecturally significant." Otherwise you risk diluting the concept of architecture, and "everything is architecture."

When you define and include the architecturally significant model elements in the logical view, you should also take the following aspects into consideration

  • Identify potential for commonality and reuse. Which classes could be subclasses of a common class, or instances of the same parameterized class?
  • Identify potential for parameterization. What part of the design can be made more reusable or flexible by using static and run-time parameters (such as table-driven behavior, or resource data loaded at start-up time)?
  • Identify potential for using off-the-shelf products.

The Process View To top of page

The process view describes the process structure of the system. Since the process structure has great architectural impact, all processes should be presented. Within processes, only architecturally significant lightweight threads need be presented. The process view describes the tasks (processes and threads) involved in the system's execution, their interactions and configurations, as well as the allocation of objects and classes to tasks.

For each network of processes, include a subsection with the following information:

  1. Its name.
  2. The processes involved.
  3. The interactions between processes in the form of communication diagrams, in which the objects are actual processes that encompass their own threads of control. For each process, briefly describe its behavior, lifetime and communication characteristics.

The Deployment View To top of page

This section describes one or more physical network (hardware) configurations on which the software is deployed and run. It also describes the allocation of tasks (from the Process View) to the physical nodes. For each physical network configuration, include a subsection with the following information:

  1. Its name.
  2. A deployment diagram illustrating the configuration, followed by a mapping of processes to each processor.
  3. If there are many possible physical configurations, just describe a typical one and then explain the general mapping rules to follow in defining others. You should also include, in most cases, descriptions of network configurations for performing software tests and simulations.

This view is generated from the Artifact: Deployment Model.

The Implementation View To top of page

This section describes the decomposition of the software into layers and implementation subsystems in the implementation model. It also provides an overview of the allocation of design elements (from the Logical View) to the implementation. It contains two subsections:

  1. Overview

    This subsection names and defines the various layers and their contents, the rules that govern the inclusion to a given layer, and the boundaries between layers. Include a component diagram that shows the relations between layers.

  2. Layers

    For each layer, include a subsection with the following information:

    1. Its name.
    2. A component diagram showing the implementation subsystems and their import dependencies.
    3. If appropriate, an outline of the layer's relationship to elements in the logical or process view.
    4. An enumeration of the implementation subsystems located in the layer. For each implementation subsystem:
      • Give its name, abbreviation or nickname, a brief description, and a rationale for its existence;
      • If appropriate, indicate the implementation subsystem's relationship to elements in the logical or process view. In many cases, an implementation subsystem will implement one or more design subsystems from the logical view.
      • If an implementation subsystem contains architecturally significant implementation subsystems and/or
        directories, consider reflecting this in the subsection hierarchy.
      • If an implementation subsystem doesn't map one-to-one with an implementation directory, then include an explanation of how the implementation subsystem is defined in terms of implementation directories and/or files.

The Data View To top of page

This view describes the architecturally significant persistent elements in the data model. It describes an overview of the data model and its organization in terms of the tables, views, indexes, triggers and stored procedures used to provide persistence to the system. It also describes the mapping of persistent classes (from the Logical View) to the data structure of the database

It typically includes:

  • The mapping from key persistent design classes, especially where the mapping is non-trivial.
  • The architecturally significant parts of the system which have been implemented in the database, in the form of stored procedures and triggers.
  • Important decisions in other views which have data implications, such as choice of transaction strategy, distribution, concurrency, fault tolerance. For example, the choice to use database-based transaction management (relying on the database to commit or abort transactions) requires that the error handling mechanism used in the architecture include a strategy for recovering from a failed transaction by refreshing the state of persistence objects cached in memory in the application.

You should present architecturally significant data model elements, describe their responsibilities, as well as a few very important relationships and behaviors (triggers, stored procedures, etc.).

Size and Performance To top of page

This section describes architecturally-defining volumetric and responsiveness characteristics of the system. The information presented may include:

  • The number of key elements the system will have to handle (such as the number of concurrent flights for an air traffic control system, the number of concurrent phone calls for a telecom switch, the number of concurrent online users for an airline reservation system, etc.).
  • The key performance measures of the system, such as average response time for key events; average, maximum and minimum throughput rates, etc.
  • The footprint (in terms of disk and memory) of the executables - essential if the system is an embedded system which must live within extremely confining constraints.

Most of these qualities are captured as requirements; they are presented here because they shape the architecture in significant ways and warrant special focus. For each requirement, discuss how the architecture supports this requirement.

Quality To top of page

In this section, list the key quality dimensions of the system that shape the architecture. The information presented may include:

  • Operating performance requirements, such as mean-time between failure (MTBF).
  • Quality targets, such as "no unscheduled down-time"
  • Extensibility targets, such as "the software will be upgradeable while the system is running".
  • Portability targets, such as hardware platforms, operating systems, languages.

For each dimension, discuss how the architecture supports this requirement. You can organize the section by the different views (logical, implementation, and so on), or by quality. When particular characteristics are important in the system, for example, safety, security or privacy, the architectural support for these should be carefully delineated in this section.



© Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process   2003.06.13