Task Descriptor: System Architectural Analysis
This task focuses on defining a candidate architecture, its structure and the main collaborations realizing the architecturally significant use cases.
Based on Method Task:  System Architectural Analysis
Relationships
Steps
Develop System Architecture Overview

The System Architecture Overview is created early in the lifecycle of a project, possibly as early as the inception phase (in Activity: Synthesize System Architecture). It reflects early decisions and working assumptions on implementing the Vision, as well as decisions concerning the physical, logical and process architecture and non-functional requirements of the system. It is produced by the System Architect, usually in the form of an informal sketch. Conceptually, it illustrates the essential nature of the proposed solution, conveying the governing ideas and including the major building blocks. The level of formality of the System Architectural Overview is project-dependent. For example, in a large, high-ceremony project, it might be necessary to capture the System Architecture Overview in the appropriate sections of the System Architecture Document, so that it can be formally reviewed. In this case the System Architect has to use a formal (UML) illustration of the tentative solution.

Many systems are constrained to be developed and deployed in an existing environment of hardware, software, and people; for these, the Software Architect gathers information about the current environment and captures it in the System Deployment Model.

Survey available assets

Understand the requirements of the environment for which assets are being considered. Understand the system scope and the general functionality required. Search through organizational asset bases, and industry literature to identify assets or similar projects. Consider several types of assets, such as, but not limited to, industry models, frameworks, classes, and experience. Assess whether available assets could contribute to solving the key challenges of the current project, and are compatible with its constraints.

Analyze the extent of fit between asset and customer requirements. Consider whether any of the requirements are negotiable (to enable use of the asset).

Assess whether the asset could be modified or extended to satisfy requirements. Assess the trade-offs in cost, risk, and functionality from adopting the asset.

Decide in principle whether to use one or more assets, and document the rationale for this decision.

Determine the initial logical decomposition into subsystems

In this step, the System Architect has the task of partitioning the system into subsystems (which themselves can be further decomposed if sufficiently large or complex). The subsystems collaborate to deliver the behavior described in the Use-Case Model, and, in particular, collaborate to realize the operations defined in Task: Define the System Context. The System Architect strives to create a set of subsystems that are:

  • Functionally cohesive (have a well-defined and limited set of related capabilities and responsibilities).
  • Minimally coupled one to the other (the communication between subsystems that is required in the realization of system operations is kept to a minimum).

Requirements work and Business Modeling work highlight abstractions that are candidates to become subsystems: the expression of requirements in domain-appropriate language yield terms for entities that might become subsystems. The domain itself, independent of the specific requirements for this system, might also guide the System Architect, because there are concepts in the domain that are naturally (and historically) treated as subsystems. Rarely are a system and its associated domain so completely unprecedented that there is not some guidance from previous implementations. Indeed the domain might be so well explored that the System Architect can say with confidence that certain capabilities are to be implemented in mechanical/electrical subsystems, others in software subsystems, and others as manual (people/procedural) subsystems.

Depending on the domain, and the novelty of the system, analysis patterns, which capture many of the key abstractions required to model the system, might already exist. The Object Management Group is also attempting to define interfaces and protocols for many domains, through the work of its Domain Technology Committee and associated task forces. Inevitably, this work leads to the identification of important abstractions in the domain.

Approached in this way, the System Architect can avoid a purely ad-hoc functional decomposition (and allocation of requirements to subsystems), which often results in a sub-optimal architecture (see Concept: Derived Requirements).

Determine the system-level processes

By default, the System Architect might treat each subsystem as an entity capable of carrying out its responsibilities autonomously and concurrently with other subsystems, communicating asynchronously with other subsystems as needed; that is, the subsystems can be regarded as active, having their own loci of control. From this basic model, other forms of computation and communication can be constructed if required. For example, in a software system, if the System Architect see fit, a subsystem can be designed to be passive, that is, its operations are executed by processes external to the subsystem (including invocations by other subsystems). This might bring some efficiencies in execution (by reducing the process context switching overhead), at the expense of perhaps having to protect the passive subsystem (or have it protect itself) from corruption caused by multiple simultaneous (and uncoordinated) invocations of its operations.

Any processes external to the subsystems are represented as stereotyped active classes, and the drivers for their identification are the same as for standard RUP-based software development (see Concept: Concurrency), for example, as proxies and interfaces for external systems or hardware (for example, acting in an analogous way to a boundary class), or as control or sequencing agents (like a control class), in the end, together with the active subsystems, representing internal system activities that need to run (at least logically, and perhaps even physically) concurrently.

Develop Locality Model

Using the System Architecture Overview developed previously, the conceptual level of the Work Product: System Deployment Model is now developed. The System Deployment Model is concerned with determination of elements which host the computational work defined by the subsystems and their interactions. The System Deployment Model evolves through three levels: Locality (the most abstract), Descriptor (where computational nodes are identified, along with their required characteristics), and Implementation (at which actual hardware selections are made).

The primary business drivers of the System Deployment Model are:

  • users (at locations), defined in User Profiles (in the Vision) and use cases and the Use-Case Model
  • business data (in the Business Analysis Model), if a business modeling approach has been employed
  • operation level requirements (in the Supplementary Specifications)
  • constraints (in the Supplementary Specifications)

At this level of analysis, the concern is with the Locality Model (see Guidelines: System Deployment Model). The System Architect partitions the computational resources into groups in support of kinds of processing, without, at this stage, constraining the geographic location. The Locality Model represents the initial, abstract, physical partitioning and distribution of the system, and is concerned with the physical resources of the system (nodes, devices, sensors and their physical connections and interfaces, and the physical characteristics of these, for example weight, heat generation, power consumption, vibration, and so forth.). The individual localities express notionally where processing occurs (the semantics of locality implies a tighter grouping of resources) without defining exact geographic location or how the processing capability is to be realized.

The System Architect prepares the locality diagram(s), consisting of the localities and their connections. Like the localities, the connections are abstract at this level and simply represent pathways for information, mass, energy, or discrete physical items to be exchanged between localities.

For each locality in the System Deployment Model, the System Architect prepares and attaches a description of derived supplementary requirements (derived from system supplementary specifications) which specify quality (reliability, maintainability, safety, and so on), physical and environmental requirements, and development constraints (cost, technical risk, and so forth). From these requirements, the actual characteristics (of each locality) are determined (tentatively in this task, more detail is added in Task: Refine System Deployment Model); obviously, these are chosen to meet the explicit requirements at least, but can exceed the requirements if sound engineering practice dictates this, for example, to cope with unexpected capacity demands.

Localities and connections are tagged (with UML tagged values) with their characteristics:

  • Localities, characterized with 
    • Quality tags, such as reliability, availability, performance, capacity, and so forth
    • Management tags, such as cost and technical risk
  • Connections, characterized with
    • Link parameters, such as data rate, supported protocols, and flow rate
    • Management tags, such as cost and technical risk.

When there are no explicitly imposed requirements and constraints, the System Architect has to make judgments about the implicit needs (confirming these with the stakeholders) and derive these characteristics accordingly.

Each locality hosts some set of subsystem operations, and the System Architect must ensure that the locality and connection characteristics support the putative set of subsystem operations.

Detailed specification of localities and connections is deferred, except where this is important for estimation or viability assessment.

Although this is the most abstract System Deployment Model produced in the project, and is produced quickly and at a high level, it might identify actual hardware and software products if these are known (or required), or if it is important to make these selection decisions at this time.

Outline significant collaborations

Based on the set of architecturally significant use cases (see Task: Prioritize System Use Cases), the System Architect outlines the collaborations of subsystems that realize them, and captures these embryonic System Use-Case Realizations in the System Analysis Model. At this stage, the System Architect need only identify the set of subsystems which realizes the use case; the links and messages between them are added later.

Create/update Subsystem Vision(s)

Based on work in this task, the subsystems that need to be constructed have started to emerge. For each of these, the System Architect produces an initial Subsystem Vision and includes a preliminary description of the desired capabilities, responsibilities, qualities and interface requirements.

Review the results

The System Architect evaluates the results with the stakeholders, validating the choice of subsystems (with respect to the domain and the architecturally significant use cases) and validating the assumptions and rationale behind the choices made in the Locality Model.


Properties
Multiple Occurrences
Event-Driven
Ongoing
Optional
Planned
Repeatable