Artifact: System Deployment Model
This is the Deployment Model at the system level. It has three levels of refinement: Locality, Descriptor, Implementation. When the SE activities are invoked, it substitutes for the Deployment Model because implementation technologies are chosen in its evolution, making conceptual modeling, and so forth, of the Deployment Model unnecessary.
Domain:  Systems Engineering
Work Product Kinds:  Model
Purpose

The purpose of the System Deployment Model is to capture the decomposition of the system into elements which host the processing. This is done at several levels of abstraction, namely Locality (the most abstract), Descriptor, and Implementation (the least abstract) - these levels are more or less equivalent to the Conceptual, Specification and Physical levels described for the Work Product: Deployment Model (which is used when the application of the RUP is limited to software development). 

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 on). A locality expresses 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. It is conceivable for very complex, very large systems, that the initial Locality Model might have localities that decompose to finer-grained localities (just as a subsystem can contain subsystems). At the Descriptor level, the types of processing resources at a locality are specified - these are nodes, which might include computing devices (servers, workstations, and so on), people, or other electro-mechanical devices. Finally, at the Implementation level, the actual hardware selection is made, numbers of role instances (in the case of human resources) determined, with a defined set of configurations, capacity, power and other environmental requirements, cost, and performance. See Guidelines: System Deployment Model for more information.

The System Deployment Model is also used to record the subsystem operations that are hosted at each locality - this determines the computing requirements to be supported at the locality. Based on the behavior to be supported at the localities, collaborations of localities can be constructed (and represented in interaction diagrams). These help characterize the connections between the localities.

Each locality in the System Deployment Model has an attached description of derived supplementary requirements (derived from system supplementary specifications) which specify quality (reliability, maintainability, safety, and so forth), physical and environmental requirements, and development constraints (cost, technical risk, and so forth). From these requirements, the actual characteristics (of each locality) are determined; 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 are characterized with: 

  • Quality tags, such as reliability, availability, performance, capacity, and so on
  • Management tags, such as cost and technical risk

Connections are characterized with:

  • Link parameters, such as data rate, supported protocols, physical flow rate
  • Management tags, such as cost and technical risk
Relationships
Illustrations
Tailoring
Representation OptionsUML Representation:

Model, stereotyped as "system deployment model."

The System Deployment Model is mandatory in the systems engineering context. If the system is not complex (in its distribution) or the system architect is constrained to use existing physical infrastructure, for example, the creation of multiple levels of abstraction in the model might not be warranted.