The Designer produced the initial Subsystem Operation Survey placeholder during the Operation Analysis task. The survey
table also shows (with a gray background) the traceability back to the system use case black-box steps, indicating (in
the table) that system use case black-box steps <id 1> and <id 2> are both performed by invocations of
<system operation name 1>.
|
Subsystem <name>
|
|
System Operation
|
System Use Case Black-Box Step Identifier
|
Locality
|
Process
|
Worker
|
Subsystem White-Box Step Description
|
Subsystem Operation
|
|
<system operation name1>
|
<id 1>
|
Locality identifier
|
Process identifier
|
Organization or System Worker identifier
|
(white-box step identifier): description of an action performed by a
subsystem (performing part of the black-box step) in the form of input, processing,
output
|
(subsystem
operation identifier): name of the subsystem operation which is invoked for this step, for example,
"«subsystem operation» Start a Sales List" (for subsystem Order Processing)
|
|
...
|
...
|
|
(white-box step identifier):...
|
|
|
...
|
...
|
|
...
|
|
|
<id 2>
|
...
|
...
|
|
...
|
|
|
<system operation name2>
|
<id 3>
|
...
|
...
|
|
...
|
|
|
<id 4>
|
...
|
...
|
|
...
|
|
|
...
|
...
|
...
|
...
|
|
...
|
|
Example Subsystem Operation Survey.
Next, working from the white-box steps and the Operation Realizations, the Subsystem Operations are identified and
their behavior specified. As with the identification of system operations, there might not be a unique subsystem
operation for each white-box step; that is, as you examine the set of white-box steps and their associated exchange of
messages, input-output entities, and so forth., you might find that it is possible to define a smaller set of Subsystem
Operations to fulfill their needs.
Note that the survey table can also be resorted by locality or by process, thus showing the association of a set of
Subsystem Operations with each locality or with each process. The locality sort gives an indication of the computing
load at a locality (and so is useful for reasoning about the capacity of the physical components that support the
locality). In this form, the survey sorted by locality becomes a property of the Deployment Model.
When a Subsystem Operation is hosted at multiple localities, this indicates that at least part of the subsystem is
replicated. There is no implication that these replicated portions necessarily share data or are kept in
synchronization. These are design choices which depend on the application and reason for replication; for example, the
processing required might be identical, but occur for a different business segment. In the extreme, all of a
subsystem's operations can be hosted at multiple localities, meaning that, effectively, the subsystem itself is
replicated. The need to identify replicated instances uniquely also depends on the reasons for replication.
The process sort allows the Designer to reason about concurrency issues: if you were to view a Subsystem Operation as a
discrete piece of functionality available to actors, then, as a first approximation, operations associated with the
same process cannot be performed in parallel. This might lead the Designer to reconsider the process allocation, or
consider process replication, or to examine the perceived latency problem at a lower level of detail, for example,
through examination of time-slicing options, and process sharing when an operation blocks (to do input-output, for
example). These techniques can give acceptable responsiveness, whereas a delaying of the start of an operation
(strictly serializing operations) might be intolerable. In this form, the survey sorted by process becomes a property
of the Design Model.
|
