This is the most common and important relationship
It is common to have some partial behavior that is common across several use cases. For example, the description of paying by credit occurs in several use cases, including Process Sale, Process Rental, Contribute to Lay - away Plan, and so forth. Rather than duplicate this text, it is desirable to separate it into its own subfunction use case, and indicate its inclusion. This is simply refactoring and linking text to avoid duplication.
CJC1: Process Sale
UC12: Handle Credit Payment
This is the include relationship.
A slightly shorter (and thus perhaps preferred) notation to indicate an included use case is simply to underline it or highlight it in some fashion. For example:
UC1: Process Sale
Notice that the Handle Credit Payment subfunction use case was originally in the Extensions section of the Process Sale use case, but was factored out to avoid duplication. Also note that the same Main Success and Extensions structures are used in the subfunction use case as in the regular elementary business process use cases such as Process Sale.
A simple, practical guideline of when to use the include relationship is offered by Fowler [Fowler 03]:
Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition.
Another motivation is simply to decompose an overwhelmingly long use case into subunits to improve comprehension.
Using include with Asynchronous Event Handling
Yet another use of the include relationship is to describe the handling of an asynchronous event, such as when a user is able to, at any time, select or branch to a particular window, function, or Web page, or within a range of steps. In fact, the use case notation to support this asynchronous branching was already explored in the introduction to use cases in Chapter, but at that time the addition of calling out to an included sub - use case was not discussed.
The basic notation is to use the a*, b*, ... style labels in the Extensions section. Recall that these imply an extension or event that can happen at any time. A minor variation is a range label, such as 3 - 9, to be used when the asynchronous event can occur within a relatively large range of the use case steps, but not all.
UC1: Process FooBars
Terminology : Concrete, Abstract, Base, and Addition Use Cases
A concrete use case i# initiated by an actor and performs the entire behavior desired by the actor [RUP]. These are the elementary business process use cases. For example, Process Sale is a concrete use case. By contrast, an abstract use case is never instantiated by itself; it is a subfunction use case that is part of another use case. Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of another story, such as Process Sale,
A use case that includes another use case, or that is extended or specialized by another use case is called a base use case. Process Sale is a base use case with respect to the included Handle Credit Payment subfunction use case. On the other hand, the use case that is an inclusion, extension, or specialization is called an addition use case. Handle Credit Payment is the addition use case in the include relationship to Process Sale.Addition use cases are usually abstract. Base use cases are usually concrete.
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.