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
|