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.
|