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.