These two type of relationships are used in use case models .The UML( Unified Modelling Language) describes the relationship between usecases , <<include>> and <<exclude>> relationship. Before seeing the relationship between these three terms lets see about the use case modelling. Use Cases describes a logical task that may be performed by the system. The Use Case description describes the interaction between the system and the outside world. UML is used to create specification for the system based on the use cases.Use Case corresponds to a logical unit of work, so that as a rule of thumb it is typically,
performed by one person, in one place, at one time,
leaves the business data in a consistent state and
generates some business value.
The Use Case steps are usually arranged into a Basic Flow and Alternative Flows.The Basic Flow has other names, such as the Main Success Scenario or Happy Day scenario. It describes the steps that are required for a straightforward (but not always the simplest) execution of the Use Case. It sets aside the panoply of possibilities within the Use Case so that we can see the essence of the thing.
The Alternative Flows are also known by other names, such as exceptions or extensions. Each one describes some variation from the steps in the Basic Flow. Alternative Flows can also be overlaid on top of other Alternative Flows. Within a single execution of the Use Case – a single Scenario – any number of Alternative Flows may be invoked
Lets take an example of use case and relate it to the <<Include>> and <<extend>> relationship :
Eg : Use Case: “Take Customer Order”
Basic Flow:
1. Actor enters Customer details
2. Actor enters code for product required
3. System displays Product details
4. Actor enters quantity required
5. Actor enters Payment details
6. System saves Customer Order
Alternative Flows:
[multiple products]
After step 4, when the Actor enters the quantity required,
Repeat steps 2 to 4 for additional Products
Resume at step 5, to enter Payment details
This diagram defines the use case with the basic flow.
Now here comes the concept of <<include>> relationship, The «include» relationship allows us to include the steps from one Use Case into another.
This is valuable when the included steps occur as a recognisable sequence in many
different contexts.
In the above example , we need to capture the Customer’s details. After further analysis, we may find that there are other Use Cases where we also need to record the Customer’s details.Furthermore, we will find that there are a number of ways of doing this, for example, we may need to capture them as a new customer or recall them as an existing customer. So long as the steps required to capture the Customer’s details are not trivial, it becomes more economic to extract them into a separate flow, which we may call “Identify Customer”. See the picture below :
Now , the seperate use caseUse Case: “Identify Customer” will be as
Basic Flow:
1. Actor enters search criteria, surname and postcode
2. System displays matching Customers
3. Actor selects Customer
4. System displays Customer details
5. Actor confirms Customer
Alternative Flows:
[new customer]
After step 2, when the System does not display the required Customer, Actor creates new
Customer,
1. Actor selects to add new Customer
2. Actor enters Customer details
Resume at step 5, to confirm Customer
We now modify the base Use Case “Take Customer Order” to refer to the included Use Case “Identify Customer”. The very first use case will look like
Use Case: “Take Customer Order”
Basic Flow:
1. Actor records Customer details, include (Identify Customer)
2. Actor enters code for Product required
3. System displays Product details
4. Actor enters quantity required
5. Actor enters Payment details
6. System saves Customer Order
Alternative Flows:
[multiple products]
After step 4, when the Actor enters the quantity required,
Repeat steps 2 to 4 for additional Products
Resume at step 5, to enter Payment details
So when we execute the Use Case “Take Customer Order” step 1 tells us to execute all the steps of “Identify Customer”, including the possibility of all its Alternative Flows. The name of the included Use Case should be highlighted by placing it in parentheses or quotation marks.
Now lets discuss <<extend>> relationship
The «extend» relationship allows us to modify the behaviour of the base Use Case. Suppose we want to sell products that are made to order and require a degree of customer specification. For these products we will need to record the customer’s additional requirements, such as size and colour. In this case we are adding something extra to the flow of the base Use Case.We could do this as an Alternative Flow, thus: the steps will be like :
Use Case: “Take Customer Order”
Basic Flow:
1. Actor records Customer details include (Identify Customer)
2. Actor enters code for product required
3. System displays product details
4. Actor enters quantity required
5. Actor enters payment details
6. System saves Customer Order
Alternative Flows:
[multiple products]
After step 4, when the Actor enters the quantity required,
Repeat steps 2 to 4 for additional products
Resume at step 5, to enter payment details
[customer specified product]
At step 3, when the System displays the Product details, if the product requires customer
specified features,
1. Actor enters customer specified requirements, such as size and colour
Resume at step 4, to enter quantity required, until step 6 where the Customer Order is saved.
At this step the additional customer-specific product details must also be saved
The «extend» relationship says that we execute the base Use Case but when we get to a
specified point in the flow, if the right conditions are met, we perform some different steps.
Clearly this is very similar to an Alternative Flow.
When to use «include» and when to use «extend»
1. Do the additional steps constitute a single contiguous set of steps?
Yes, you are adding steps at one place in the flow – use «include».
No, you need to modify the base Use Case in more than one place – use «extend».
2. Do the additional steps make sense on their own?
Yes – use «include».
No – use «extend».
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Include is used when you see common behaviour in two use cases. So you abstract out the common behaviour into a separate "abstract" use case.
Extend is optional from user point of view, it may or may not occur.
performed by one person, in one place, at one time,
leaves the business data in a consistent state and
generates some business value.
The Use Case steps are usually arranged into a Basic Flow and Alternative Flows.The Basic Flow has other names, such as the Main Success Scenario or Happy Day scenario. It describes the steps that are required for a straightforward (but not always the simplest) execution of the Use Case. It sets aside the panoply of possibilities within the Use Case so that we can see the essence of the thing.
The Alternative Flows are also known by other names, such as exceptions or extensions. Each one describes some variation from the steps in the Basic Flow. Alternative Flows can also be overlaid on top of other Alternative Flows. Within a single execution of the Use Case – a single Scenario – any number of Alternative Flows may be invoked
Lets take an example of use case and relate it to the <<Include>> and <<extend>> relationship :
Eg : Use Case: “Take Customer Order”
Basic Flow:
1. Actor enters Customer details
2. Actor enters code for product required
3. System displays Product details
4. Actor enters quantity required
5. Actor enters Payment details
6. System saves Customer Order
Alternative Flows:
[multiple products]
After step 4, when the Actor enters the quantity required,
Repeat steps 2 to 4 for additional Products
Resume at step 5, to enter Payment details
Now here comes the concept of <<include>> relationship, The «include» relationship allows us to include the steps from one Use Case into another.
This is valuable when the included steps occur as a recognisable sequence in many
different contexts.
In the above example , we need to capture the Customer’s details. After further analysis, we may find that there are other Use Cases where we also need to record the Customer’s details.Furthermore, we will find that there are a number of ways of doing this, for example, we may need to capture them as a new customer or recall them as an existing customer. So long as the steps required to capture the Customer’s details are not trivial, it becomes more economic to extract them into a separate flow, which we may call “Identify Customer”. See the picture below :
This picture denotes shared common steps for the use case
Basic Flow:
1. Actor enters search criteria, surname and postcode
2. System displays matching Customers
3. Actor selects Customer
4. System displays Customer details
5. Actor confirms Customer
Alternative Flows:
[new customer]
After step 2, when the System does not display the required Customer, Actor creates new
Customer,
1. Actor selects to add new Customer
2. Actor enters Customer details
Resume at step 5, to confirm Customer
We now modify the base Use Case “Take Customer Order” to refer to the included Use Case “Identify Customer”. The very first use case will look like
Use Case: “Take Customer Order”
Basic Flow:
1. Actor records Customer details, include (Identify Customer)
2. Actor enters code for Product required
3. System displays Product details
4. Actor enters quantity required
5. Actor enters Payment details
6. System saves Customer Order
Alternative Flows:
[multiple products]
After step 4, when the Actor enters the quantity required,
Repeat steps 2 to 4 for additional Products
Resume at step 5, to enter Payment details
So when we execute the Use Case “Take Customer Order” step 1 tells us to execute all the steps of “Identify Customer”, including the possibility of all its Alternative Flows. The name of the included Use Case should be highlighted by placing it in parentheses or quotation marks.
Now lets discuss <<extend>> relationship
The «extend» relationship allows us to modify the behaviour of the base Use Case. Suppose we want to sell products that are made to order and require a degree of customer specification. For these products we will need to record the customer’s additional requirements, such as size and colour. In this case we are adding something extra to the flow of the base Use Case.We could do this as an Alternative Flow, thus: the steps will be like :
Use Case: “Take Customer Order”
Basic Flow:
1. Actor records Customer details include (Identify Customer)
2. Actor enters code for product required
3. System displays product details
4. Actor enters quantity required
5. Actor enters payment details
6. System saves Customer Order
Alternative Flows:
[multiple products]
After step 4, when the Actor enters the quantity required,
Repeat steps 2 to 4 for additional products
Resume at step 5, to enter payment details
[customer specified product]
At step 3, when the System displays the Product details, if the product requires customer
specified features,
1. Actor enters customer specified requirements, such as size and colour
Resume at step 4, to enter quantity required, until step 6 where the Customer Order is saved.
At this step the additional customer-specific product details must also be saved
When to use «include» and when to use «extend»
1. Do the additional steps constitute a single contiguous set of steps?
Yes, you are adding steps at one place in the flow – use «include».
No, you need to modify the base Use Case in more than one place – use «extend».
2. Do the additional steps make sense on their own?
Yes – use «include».
No – use «extend».
3. Do the additional steps occur in more than one base Use Case?
Yes – use «include».
No – use «extend».
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Include is used when you see common behaviour in two use cases. So you abstract out the common behaviour into a separate "abstract" use case.
Extend is optional from user point of view, it may or may not occur.
No comments:
Post a Comment