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 '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 sub-flow 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.
	A use case model with many included use cases generally indicates that the include mechanism has been used without a proper understanding of the content of the included flow.