Introduction

Use-case flowdown is the technique for deriving functional requirements for the analysis (and then design) elements. The results of the activity are:

• survey of subsystem operations
• survey of hosted subsystem operations for localities
• survey of executed subsystem operations for processes
• use-case survey for subsystems (optional)

The technique uses the standard RUP activity of choosing an architecturally significant set of use cases. For each chosen use case, the flow of events is developed. This is the description of the interactions between the system actors and the system. The system responses are black box; the descriptions make no reference to the architectural elements. Next, a black-box step (which will be performed by a system operation) is expanded into one or more white-box steps, each of which is performed by a named subsystem. The white-box steps are also associated with the localities which host them, and the processes that execute them. Each white-box step that spans localities or processes (that is, requires more than one to complete) is split until it can be completed at a single locality, by a single process. A white-box step can be replicated at several localities, but these are independent instances. These white-box steps are candidates to become subsystem operations, which are the equivalent of system operations at this lower level of logical decomposition.

The compositions of unique sequences of subsystem operations for an individual subsystem, participating in the realization of system operations, yields the subsystem use cases (optional step).

Subsystem-Locality mapping

At the outset of use-case flowdown, you are dealing with a system which typically spans (and might even encapsulate) several localities; the depth to which decomposition into subsystems (and sub-subsystems) is performed, is a matter for architectural judgment, and depends on the domain and the complexity of the system, among other things. However, for the purposes of performance analysis it is important that you understand the computational load to be imposed at a locality, and this is done in terms of the subsystem operations hosted there. Therefore, consider the following prescription for decomposition: the decomposition must yield a set of subsystem operations that cleanly partitions between localities; that is, a subsystem operation does not span localities, and if a subsystem operation (of, say subsystem A) requires, for its performance, the use of resources at a different locality, then those resources must themselves be made available through a subsystem operation, which might be provided by subsystem A itself at that locality, or another subsystem.

This condition will obviously hold if a subsystem does not span localities, but a subsystem can span localities if its operations can be partitioned as described—otherwise, the subsystem must be decomposed further. The discussion here concerns single instances of a subsystem spanning localities; a subsystem can always be replicated at several localities, but these are separate instances.