Domain Partitioning  «Prev  Next»
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.

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.

Manage Pricing Plan
  1. In order to create the PricingPlan you have to first create PriceTiers and discounts from which to choose
  2. 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.
  3. 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

Use Case Partitioning
Use Case Partitioning

Partitioning

Partitioning is used to organize conceptual areas within the same layer. In the case of the InfrastructureLibrary, fine-grained partitioning is used to provide the flexibility required by current and future metamodeling standards. In the case of the UML metamodel, the partitioning is coarser-grained in order to increase the cohesion within packages and loosening the coupling across packages.

Model Management package

Model Management refers to the means to model the organization of modeling artifacts. Artifacts may be organized along very general lines such as project phases, application incremental builds, subject matter, and utility versus business models, using packages. Packages may also be specialized to represent more refined views. For example, artifacts may be organized to represent the partitioning of a system into subsystems at any number of levels. Finally, the artifacts may represent a physical system such as a billing or receiving system. Views of the physical system are called models.


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.

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