Task: Operation Analysis

Elaborate black-box text into subsystem white-box steps

In this step, you take the Use-Case Model and elaborate the black-box flow-of-events text (which is a property of each use case) into sequences of white-box steps (which speak in terms of subsystem actions and interactions, using the subsystems and outlined collaborations from System Architectural Analysis). If this task is performed for a subsystem for which the operations have been already specified, then the starting point are the operations and you can proceed directly to the Initial White-Box Step Expansion.

For example, if you had used a tabular description as in the table, Example Black-Box Flow-of-Events:

*System Use-Case <name>*
Step	Actor Action	Black-Box Step Description	Black-Box Budgeted Requirements	System Operation
1	(actor action identifier): description of what the actor does, for example, "AA1: this use case begins when the Clerk pushes the New Sale button"	(black-box step identifier): description of the system's response (without revealing the internal structure of the system), for example, "BBS1: the system brings up new sales clerk and customer's screens and enables the scanner"	(black-box step requirements identifier): description of how well the system must perform this step; for example, in terms of response time or rate, for example, "SUP36.2: total response time is 0.5 seconds"	(system operation identifier): name of the system operation which is invoked for this step, for example, "<<operation>> Begin New Sale" (from Context Diagram, defined in Task: Define System Context)
2
3

Example Black-Box Flow-of-Events

If the task is performed for a subsystem for which only the operations have been defined

Next, a System Operation (black-box step) is expanded into one or more white-box steps, each of which is performed by a named subsystem. The Designer is guided by the work done by the Architect (during Architectural Analysis) in the selection of subsystems and interactions which are used to describe the white-box steps. Note that the analysis now proceeds driven by System Operation; that is, treat the next realization step as the realization of each System Operation (rather than the more abstract notion of system use case black-box step).

Initial white-box step expansion

The white-box steps for each System Operation (gray background in the table below) are captured (initially) in the Analysis Model, associated with the corresponding System Operation as its realization. The white-box steps are not stored with the System Use-Case (they are shown that way here simply as an illustration), but can be traced from the System Use Case through the System Operation.

*System Use-Case <name>*
System Operation	Step	Actor Action	Black-Box Step Description	Black-Box Step Budgeted Requirements	Subsystem White-Box Step Description	White-Box Step Budgeted Requirements	Locality	Process	Worker
(system operation identifier): name of the system operation which is invoked for this step, for example, "<<system operation>> Begin New Sale" (from Context Diagram)	1	(actor action identifier): description of what the actor does, e.g., "AA1: this use case begins when the Clerk pushes the New Sale button"	(black-box step identifier): description of the system's response (without revealing the internal structure of the system), e.g., "BBS1: the system brings up new sales clerk and customer's screens and enables the scanner"	(black-box step requirements identifier): description of how well the system must perform this step; for example, in terms of response time or rate, e.g. "SUP36.2: total response time is 0.5 seconds"	(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, e.g., "WBS1: the Point-of-Sale Interface clears the transaction, brings up new sales screens, and requests that Order Processing start a sales list"
					(white-box step identifier):...

	2
	3

Example White-Box Flow-of-Events

Augment white-box steps with locality, process and worker decisions

The description is then further augmented with locality decisions, process decisions, and worker decisions. The locality decision places, with some latitude (given the level of abstraction of locality) where the subsystem white-box step are performed. The process decision is necessary only when it is decided that (for this step at least), the subsystem is "passive," that is, its operations are invoked by processes external to the subsystem. An "active" subsystem is able to respond autonomously, using processes internal to the subsystem. The system designer is again guided by the work of the system architect (in producing the Locality Model and Process Model). In worker decisions, appropriate when you make allocations to human resources, you start to identify the organizational entities and then system worker resources needed for a System Operation.

If the analysis shows that a white-box step requires more than one locality (or process), then decompose it into smaller steps, so that each can be associated with a single locality (and process, where appropriate). This decomposition might have important architectural ramifications (it might need the subsystem to be refactored) and needs to be canvassed with the team or person playing the System Architect role.

*System Use-Case <name>*
System Operation	Step	Actor Action	Black-Box Step Description	Black-Box Step Budgeted Requirements	Subsystem White-Box Step Description	White-Box Step Budgeted Requirements	Locality	Process	Worker
(system operation identifier): name of the system operation which is invoked for this step, for example, "<<system operation>> Begin New Sale" (from Context Diagram)	1	(actor action identifier): description of what the actor does, for example, "AA1: this use case begins when the Clerk pushes the New Sale button"	(black-box step identifier): description of the response (without revealing the internal structure of the system), for example, "BBS1: the system brings up new sales clerk and customer's screens and enables the scanner"	(black-box step requirements identifier): description of how well the system must perform this step; for example, in terms of response time or rate, for example, "SUP36.2: total response time is 0.5 seconds"	(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, for example, "WBS1: the Point-of-Sale Interface clears the transaction, brings up new sales screens, and requests that Order Processing start a sales list"		Locality identifier	Process identifier	Organization or System Worker identifier
					(white-box step identifier):...

	2
	3

Example Augmented White-Box Flow-of-Events

Allocate white-box budgeted requirements

Next, apportion black-box step budgeted requirements to white-box steps. This allocation helps determine the performance requirements for both the subsystem and the associated locality. In the case of a passive subsystem, it is an input into latency analysis of the invoking process (which might have other responsibilities).

*System Use-Case <name>*
System Operation	Step	Actor Action	Black-Box Step Description	Black-Box Step Budgeted Requirements	Subsystem White-Box Step Description	White-Box Step Budgeted Requirements	Locality	Process	Worker
(system operation identifier): name of the system operation which is invoked for this step, for example, "<<system operation>> Begin New Sale" (from Context Diagram)	1	(actor action identifier): description of what the actor does, for example, "AA1: this use case begins when the Clerk pushes the New Sale button"	(black-box step identifier): description of the system's response (without revealing the internal structure of the system), for example, "BBS1: the system brings up new sales clerk and customer's screens and enables the scanner"	(black-box step requirements identifier): description of how well the system must perform this step; for example, in terms of response time or rate, for example, "SUP36.2: total response time is 0.5 seconds"	(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, for example, "WBS1: the Point-of-Sale Interface clears the transaction, brings up new sales screens, and requests that Order Processing start a sales list"	(white-box step requirements identifier): description of how well the subsystem must perform this step; for example, in terms of response time or rate, for example, "SUP36.2.1: elapsed time 0.16 second"	Locality identifier (in locality model)	Process identifier (in process model)	Organization or System Worker identifier
					(white-box step identifier):...	(white-box step requirements identifier):...	Locality identifier	Process identifier	Organization or System Worker identifier

	2
	3

Example Allocated White-Box Flow-of-Events Budgeted Requirements

Sort white-box steps by subsystem

In this step, you collect together all white-box steps for each subsystem (that is, the white-box steps that belong to that subsystem). This is done in preparation for the identification of Subsystem Operations (which are to the subsystem what System Operations are to the system), by examination of the subsystem white-box step descriptions. As with the identification of system operations, there might not be a unique subsystem operation for each white-box step. Also note that the white-box steps are grouped by system operation. For example, this might be done in tabular form as well, grouped by subsystem:

Example Subsystem Use-Case Survey

*Subsystem <name>*
System Operation	Locality	Process	Worker	Subsystem White-Box Step Description	Subsystem Operation
<name>	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

Example Operation Use-Case Survey

In the case of a "systems of systems", where a use-case model is maintained for each system/subsystem, this grouping is a strong guide to the identification of subsystem use cases: you can initially identify a subsystem use case for each system operation in which the subsystem participates. You might then note that the sequences of white-box steps are the same for some of these use cases; therefore, they can be aggregated, and thus a single subsystem use case can be made to fulfill the needs of several system operations.

Refine outlined collaborations for each system operation

Based on the white-box steps, subsystem interactions are created in sequence or collaboration diagrams (in the Analysis Model). This refines the work done previously by the System Architect. At this stage, the collaborations might still be abstract, perhaps only links are identified, or messages at an abstract level. This work, nevertheless, gives an insight into the coupling and cohesion of the subsystems. This refines the white-box step expansion performed previously (see Initial White-Box Step Expansion).

Evaluate the analysis

The System Designer needs to call for an informal review at the conclusion of this task, and thus ensure that all emergent issues are recorded and scheduled for resolution.