| Lesson 5 | Use cases and domain partitioning |
| Objective | Explain partitioning based on use cases. |
Use Cases and Domain Partitioning
Use cases
Use cases define the functionality of the problem domain by establishing the goals that the system must help the users achieve. In a finished application, use cases translate into menu options, transactions, and other discrete units of work. When the use cases are refined,
you may find some that define pieces of a larger task. In this case, you may find that multiple use cases might need to be combined to provide the complete unit of work.
Dividing the functionality of the system based on use cases is probably the most subjective part of the partitioning process. When you move on to the classes and interaction diagrams the partitions will become more clearly visible and may be tested for effectiveness.
Dividing the functionality of the system based on use cases is probably the most subjective part of the partitioning process. When you move on to the classes and interaction diagrams the partitions will become more clearly visible and may be tested for effectiveness.
Units of work
In some cases, one use case defines one unit of work that can stand entirely on its own. Other times, a group of use cases may define a unit of work.
- In order to create the PricingPlan you have to first create PriceTiers and discounts from which to choose
- Likewise, discounts are only created because they are used as part of a PricingPlan. Keep them together with the PricingPlan functions so they can be managed as a unit.
- The only reason to create a PriceTier is to use it in the same subsystem where the users can use them together in a PricingPlan
Use Case Partitioning
Questions to consider
Keep the following questions in mind when partitioning: Would this use case stand on its own?
Would it be reasonable for a user to complete this task and walk away, or switch to something else? If so, then try isolating the use case in its own partition. Would the users typically use a group of functions together? If so, then try putting the use cases together in the same partition. Does the result of one function influence the choices in another function?
Is there a reconciliation, balancing, or assembly type of relationship between the functions?
Beware of just copying the way users currently do their work. Ask probing questions about why the tasks may or may not be performed as a unit. Quite often, people simply do things the way they learned them, whether or not there is substantial benefit or any fundamental dependency between the tasks.
Would it be reasonable for a user to complete this task and walk away, or switch to something else? If so, then try isolating the use case in its own partition. Would the users typically use a group of functions together? If so, then try putting the use cases together in the same partition. Does the result of one function influence the choices in another function?
Is there a reconciliation, balancing, or assembly type of relationship between the functions?
Beware of just copying the way users currently do their work. Ask probing questions about why the tasks may or may not be performed as a unit. Quite often, people simply do things the way they learned them, whether or not there is substantial benefit or any fundamental dependency between the tasks.
Use Cases Domain Partitioning - Exercise
Click the Exercise link below to work on the course project. In this exercise, you will partition the domain based on use cases.
Use Cases Domain Partitioning - Exercise
Use Cases Domain Partitioning - Exercise