Task: Operation Design
This task refines the results of Operation Analysis into detailed Operation Realizations.
Purpose
  • To refine the preliminary subsystem interactions into Operation Realizations in the Design Model.
  • To refine and specify the Subsystem Operations.
Relationships
RolesMain: Additional: Assisting:
InputsMandatory: Optional:
  • None
External:
  • None
Outputs
Steps
Create Operation Realizations

In Task: Operation Analysis, the Designer created subsystem interactions (without much detail) in the Analysis Model. Recall that you had organized the granularity of these interactions so that they were grouped by System Operation, that is, you captured the interactions that realize each System Operation. Now, working with the expanded (white-box) system use-case descriptions, the detail of messages, entities exchanged, sequencing, control flow, and associated data is added and the resulting Operation Realizations are captured in the Design Model, again organized by System Operation. As this detail is added, the Designer evaluates the quality of the emergent collaborations, looking for opportunities to refactor the design. Annotate the Operation Realizations with descriptions of what the subsystem does when processing a message (drawn from the white-box step description and refined if necessary). These descriptions help with the next step, to develop specifications for each Subsystem Operation.

Aggregate similar subsystem white-box steps and specify Subsystem Operations

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.

Footnote What have you achieved

For each subsystem, you have:

  • defined its operations
  • defined the interfaces you expect the subsystem to support
  • described how the subsystem collaborates with other subsystems to realize the system use cases
  • defined the subsystem's context: its actors, interfaces and I/O entities

You are thus well positioned to be able to hand-off this set of work products for independent development, if you so choose, or to re-invoke RUP's tasks in the Requirements discipline, to perform further decomposition in a recursive fashion.

Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information