3.

1 The Sub-Flow
Sometimes it is useful to split out a part of either the basic flow, or another flow, so that it can be re-used within the use case. This flow is created in a separate paragraph of the use case document and 'called' just as a sub-function would be called if we were writing code. The sub flow paragraph is given the title: "Sub-Flow: XXX", where XXX the name of the sub-flow starting with an active verb.

In the calling flow the sub-flow is invoked by referring to its name. In the example the words of the title of the sub-flow are capitalised to indicate the call. Other forms include: 'The sub-flow XXX runs here' or 'Do sub-flow XXX' which may be starting to look too much like code for non-technical users. The sub-flow always runs and returns to the point from which it was invoked, unless an exception during the sub-flow prevents it from returning. The use case then continues from that point. The sub-flow can also be used to provide alternative paths following a case statement or other selection statement if this is deemed more appropriate than using one or more alternate flows

3.2 Including Common Sub-Flows

Sometimes there is a flow that is common between two use cases. If this is so, then there is a need to strip out the common flow from the use case where it was first discovered, and put it in a separate place that is accessible from both use cases. In order to do this we create a new 'use case' which is in fact nothing more than a 'sub-flow' and make it accessible from both use cases which use it. All that is happening here is that the sub-flow is being moved to a new, common, document and attached to a new use case symbol on the use case diagram. On the diagram a new use case symbol is created that represents the common sub-flow. This symbol does not represent a new use case, but simply a part of two use cases that has been separated out in order to be documented only once. On the diagram we use an 'include' relationship that is a dependency between use cases with the stereotype (labeled) 'include'. This means that the including use case depends on the included use case, and that the nature of the dependency is that one 'includes' the other. In other words, each of the two original use cases now requires the third in order to be complete.

The included use case description should be written in such a way that everything in it is entirely common to both the including use cases. If we need to include a switch which depends on the use case from which it was called, then we are including things that are not common. The 'child' use case must be independent of both parents. The reference to the included use case is written in the parent in exactly the way that a sub-flow would normally be referenced. The only difference is that the subflow is now in a separate document. This mechanism is commonly abused by decomposing a use case into steps and showing each step as a separate 'use case' on the use case diagram. This kind of functional decomposition bloats the use case model and tends to ignore the '25 to 75 use cases' rule of thumb.

3.3 The Alternate Flow

An alternate flow should be designed so that it 'knows how to insert itself' in the flow that it extends. In other words, the reference to where it is inserted, and the condition under which it is inserted, should be defined in the alternate flow itself. If the other approach is taken: to insert many conditions in the basic flow which call sub-flows that handle the extensions, then the basic flow becomes overloaded with conditions, and the basic flow is obscured. If alternate flows are written following the recommended approach, then they will always contain the following four elements: 1) The place in which the flow inserts itself. In the example this has been written as 'If at 2. in Enter Order'. If each sentence in the use case has a unique line number, then even the reference to the name of the flow in which the alternate flow is inserted may be omitted and the line reference used by itself.

2) The condition under which it inserts itself. In the example: 'the item number is found to be invalid'. 3) What happens in the alternate flow. This is written in exactly the same way that it would be written in any other flow: as numbered sentences which define largely interactions across the system boundary. 4) What happens at the end of the flow. There are 4 options: The use case terminates; the use case returns to where it was called and continues; the use case returns to prior to where it was called; the use case jumps forward. In each of the last 3, if all sentences are uniquely numbered, then all that is required is to state the line to which it returns. The alternate flow is normally just another paragraph in the use case document.

3.4 Making the Alternate Flow an Extension

If the alternate flow is large, that is, more than a page, or if it is optional functionality for the system, then it might be appropriate to split out the flow and put it in a separate use case document. The document is then attached to a new use case symbol on the diagram with an 'extend' relationship from the extending use case symbol to the use case that it extends. Notice that the relationship is a UML dependency with the 'extend' stereotype, going from the extending use case symbol to that which it extends.

If this relationship is seen as a conditional call from the extended use case to the extension, then the call goes against the direction of the arrow, which might be confusing. Remember that the dotted arrow defines a dependency, and that the text in the extension knows about, and therefore depends on, the text in the extended flow. Not the other way round. The text in the extended use case knows nothing of, and is independent of the extension. Note that only 'Enter Order' is a use case. 'Handle Invalid Product Number' is only an alternate flow. Don't overuse this syntax. If you make every alternate flow an extension, then there will be 5 to 10 times the number of use case symbols on the diagram and lots of very small use case documents.

3.5 Activity Diagrams

An activity diagram can be used to supplement the use case text in order to show complex iteration and selection and to get an overview of the flow of the use case. Do not, however, allow the activity diagram to replace the use case text. Activities, in oval boxes, are named starting with an active verb

The arrow indicates the order in which the activities occur. It is the thread of activity A condition, in square brackets, may be used to hold up the thread until the condition becomes true. If there are multiple exits from an activity, as from 'Find Customer Record, then all exit threads should have non-overlapping conditions. This indicates a switch inside the activity The above also applies to a decision, a diamond shape, which can be used to indicate a switch between activities The activity diagram must contain a 'start state' and may contain an 'end state'

3.6 Prototype Screens

A prototype screen is a useful second view of the use case. It is another hook for users to hang their ideas on when trying to explain what they want

It provides a structural aspect to the procedural aspect of the use case text. It provides a place to attach detailed data format and constraint information that doesn't belong in the use case text. The prototype screen should be consistent with the use case text It doesn't have to be created in the target technology. This one was done using basic shapes in word The amount of detail in the design of the screen at this point should be relative to its importance to the users. In other words it should contain only that which is a user requirement not detailed design decisions that are unimportant to the users

3.7 The Use Case Document Template

Each use case symbol in the model should have its own use case document. In some case tools these can be physically attached to the symbol and accessed from the tool
Use Case Name: Primary Actor: Stakeholders and Interests: ID: Use Case Type: Importance Level:

Brief Description: Trigger: Type: Relationships: Association: Include: Extend: Generalization: Normal Flow of Events: 1. SubFlows: S-1: 1. S-2: 1.

Alternate/Exceptional Flows: A1. 1. DISPLAY TO USER " INVALID ITEM NUMBER , RE-ENTER ITEM NUMBER" 2 . RETURN TO ENTER ORDER 2

3.8 Chapter Summary Sub-flows are useful for re-using a common flow or as outcomes of a case statement If the sub-flow is common between two use cases, or very large, then it may be spilt out into a separate use case document and shown as a seperate use case symbol on the diagram with and 'include' relationship showing its use. An alternate flow is a conditional flow that knows how to insert itself in the original flow. If the alternate flow is very large, or optional functionality, then it may be moved to a seperate use case document and shown on the diagram as a seperate use case symbol with an 'extend' relationship to the use case it extends. An activity diagram can be created to show the overall flow of the use case but should not replace the use case text. A prototype screen is a useful second user-facing view of a use case and should be consistent with the use case text. A use case document template is useful to ensure consistency of use case text standards across a project.