Team LiB   Previous Section   Next Section

8.2 Flow Transitions

Given a collection of action states, how are those action states related to one another? Flow transitions address this issue. As discussed in Chapter 2, a flow transition shows how action states are ordered or sequenced. There are various types of flow transitions, including control-flow and object-flow transitions, which are mentioned in Chapter 2 and discussed here.

8.2.1 Control-Flow Transitions

A control-flow transition indicates the order of action states. That is, once a source action state completes its processing, a target action state starts its processing. For example, the project management system may have the following order of action states for the task of generating a report:

  1. The Project Manager Enters Report Criteria action state occurs first, because the project manager must enter the report criteria before the system can generate a report.

  2. The Project Management System Generates Report action state occurs next, because the project management system must generate the report before the printer can print the report.

  3. The Printer Prints Report action state occurs last, once the report has been generated by the project management system.

In the UML, a control-flow transition is shown as a solid line from a source action state to a target action state. Figure 8-3 shows the order of action states associated with the project management system.

Figure 8-3. Control-flow transitions
figs/Luml_0803.gif

Figure 8-3 also shows a control-flow transition originating from the initial state to indicate the first action state, and a transition to the final state to indicate the last action state.

Control-flow transitions are also known as default transitions or automatic transitions, because they are unlabeled and are immediately triggered after the source action state completes processing.

8.2.2 Object-Flow Transitions

An object-flow transition indicates that an action state inputs or outputs an object. For example, the action states shown in Figure 8-3 may have inputs and outputs as follows:

Project Manager Enters Report Criteria

Outputs a Report Criteria object and may be renamed as the Project Manager Enters Data action state

Project Management System Generates Report

Inputs the Report Criteria object and outputs a Report object and may be renamed as the Project Management System Generates Information action state

Printer Prints Report

Inputs the Report object and may be renamed as the Printer Prints Information action state

In the UML, an object-flow transition is shown as a dashed arrow between an action state and an object. An action state that uses an object as input is shown with the object-flow transition arrow pointing from the object to the action state. An action state that updates or produces an object as output is shown with the object-flow transition arrow pointing from the action state to the object. Figure 8-4 shows the objects used by the action states associated with the project management system.

Notice the new names for the action states in Figure 8-4 as compared to Figure 8-3. In Figure 8-3, the action state names conveyed some idea of the inputs and outputs from each state. Figure 8-4 however, shows these inputs and outputs explicitly, so there's no longer any need to imply them redundantly in the action state names. The advantage is the action state names can now focus purely on the actions, while the object-flow transitions indicate clearly the inputs and outputs to and from the actions.

Figure 8-4. Control-flow and object-flow transitions
figs/Luml_0804.gif

A control-flow transition may be omitted when an object-flow transition indicates the ordering of action states; that is, when an action state produces an output that is input to a subsequent action state, the object-flow transition implies a control-flow transition and an explicit control-flow transition is not necessary. Figure 8-5 updates Figure 8-4 by removing the unnecessary control-flow transitions.

Figure 8-5. Control-flow and object-flow transitions without unnecessary control-flow transitions
figs/Luml_0805.gif
    Team LiB   Previous Section   Next Section