The use and misuse of includes and extends
Any sizeable collection of use cases will have relationships between use cases that can be modeled using the UML includes and extends stereotypes. Used properly these model constructs help make the model more readable and maintainable. Used improperly they can make the model incomprehensible and this happens all too often.
The includes relationship occurs when an included use case modifies the behavior of a base use case. The behavior of the included use case is inserted into the behavior of the base use case at an insertion point. An included use case can be included at multiple points in a base use case and can be included in more than one use case. The included use case is specifically referenced at the insertion point(s) in the base use case(s). On a UML use case diagram the relationship is drawn using a dashed line with an arrow head pointing at the included use case. Includes relationships can be nested so a use case can be both a base use case and an included use case. Conceptually, you can think of the base use case ‘calling’ the included use case. Included use cases are often used to encapsulate behavior that is common to multiple base use cases.
The extends relationship also involves one use case modifying the behavior of another use case but the relationship between the use cases is quite different than with the includes relationship. The base use case has extension points but does not specifically identify the extending use case(s). The extending use case adds to the base use case and essentially becomes part of the base use case. Extending use cases are often used to encapsulate alternative and exception flows. In fact, this is a good conceptual way to think about extending use cases. If you have alternatives within alternatives you may have a good reason to separate out the flows into an extending use case. On the UML use case diagram the relationship is drawn using a dashed line with an arrow head pointing from the extending use case to the base use case.
Adding lots of includes and extends to your use case diagram can make it difficult to read so use them only when they improve readability and maintainability, and use them correctly. If you are modeling behavior that is common across use cases, consider the includes relationship. If you have complex alternatives and exceptions, consider using the extends.
The includes relationship occurs when an included use case modifies the behavior of a base use case. The behavior of the included use case is inserted into the behavior of the base use case at an insertion point. An included use case can be included at multiple points in a base use case and can be included in more than one use case. The included use case is specifically referenced at the insertion point(s) in the base use case(s). On a UML use case diagram the relationship is drawn using a dashed line with an arrow head pointing at the included use case. Includes relationships can be nested so a use case can be both a base use case and an included use case. Conceptually, you can think of the base use case ‘calling’ the included use case. Included use cases are often used to encapsulate behavior that is common to multiple base use cases.
The extends relationship also involves one use case modifying the behavior of another use case but the relationship between the use cases is quite different than with the includes relationship. The base use case has extension points but does not specifically identify the extending use case(s). The extending use case adds to the base use case and essentially becomes part of the base use case. Extending use cases are often used to encapsulate alternative and exception flows. In fact, this is a good conceptual way to think about extending use cases. If you have alternatives within alternatives you may have a good reason to separate out the flows into an extending use case. On the UML use case diagram the relationship is drawn using a dashed line with an arrow head pointing from the extending use case to the base use case.
Adding lots of includes and extends to your use case diagram can make it difficult to read so use them only when they improve readability and maintainability, and use them correctly. If you are modeling behavior that is common across use cases, consider the includes relationship. If you have complex alternatives and exceptions, consider using the extends.
posted by MJMurphy at 11/01/2007 09:11:00 AM
0 Comments:
Post a Comment
<< Home