Create Operation Realizations
In Task: System Operation Analysis, the System Designer created subsystem interactions
(without much detail) in the System 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 System Design Model, again organized by System Operation. As this detail is added, the
System 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 System Designer produced the initial Subsystem Operation Survey placeholder during the Task: System Operation Analysis. 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, "<> 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 System 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 System 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 System Design Model.
|
Refine the Subsystem Use-Case Model
The System Designer produced the initial Subsystem Use-Case Survey placeholder during the Task: System Operation Analysis. The survey is a property of the Subsystem Use-Case
Model.
Recall that in Task: System Operation Analysis, you grouped the white-box steps by System Operation. The observation was made that this
grouping is a strong guide to the identification of subsystem use cases - initially, you identify a subsystem use case
for each system operation in which the subsystem participates. Then, noting that the sequences of white-box steps are
the same for some of these use cases, they (the use cases) can be aggregated, and thus a single subsystem use case can
be made to fulfill the needs of several system operations. This is done for economy of descriptive effort.
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 1 operation name).
Subsystem (NAME)
|
Subsystem Use-Case Name
|
Description
|
System Operation
|
System Use Case Black-Box Step Identifier
|
Locality
|
Process
|
Worker
|
Subsystem White-Box Step?Description
|
Subsystem Operation
|
(SUBSYSTEM 1 name use-case)
|
Description of subsystem use case, how it is initiated, consequent iterations, and its results
|
(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)
|
...
|
...
|
|
...
|
|
(SUBSYSTEM 2 name use-case)
|
...
|
...
|
...
|
...
|
...
|
|
...
|
|
Example Subsystem Use Case Survey.
Thus the subsystem use cases can be inferred and added to the Survey Description. In this way, the System
Designer has formed, at least partially, the context for the subsystem (analogously to the context elaborated by
the System Analyst for the entire system).
|
Create remainder of Subsystem Use-Case Model
The System Designer can now create or refine the Subsystem Use-Case Model, identifying and describing the use cases,
identifying actors and their associations to the use cases, and characterizing these associations. Diagrams can also be
created.
|
Update Subsystem Supplementary Requirements
As a result of refactoring the locality and the process performance considerations, the non-functional requirements
(including interface requirements) imposed on the subsystems might change, requiring changes to the Subsystem
Supplementary Requirements.
|
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 perform further decomposition in a recursive fashion.
|
|