Artifact: Use-Case
Package
|
A use-case package is a collection of use cases, actors, relationships, diagrams, and other packages; it is used to structure the use-case model by dividing it into smaller parts. |
|---|---|
| Other Relationships: |
Part Of Use-Case Model
|
| Role: | Requirements Specifier |
| Optionality/Occurrence: | <<use-case package>> can be excluded. |
| Templates and Reports: |
|
| Examples: | |
| UML Representation: | Package in the use-case model, either its top-level package, or stereotyped as <<use-case package>> |
| More Information: |
| Input to Activities: | Output from Activities: |
Purpose 
The following people use the use-case packages:
- System analysts use use-case packages to structure the use-case model.
- Those who capture the requirements on the next version of the system use the use-case packages to understand the structure of the use-case model.
- Requirements specifiers use use-case packages as a reference for other parts of the system than they are working in.
- Testers use use-case packages as input to planning test activities.
Properties
Property Name |
Brief Description |
UML Representation |
|---|---|---|
| Name | The name of the package. | The attribute "Name" on model element. |
| Brief Description | A brief description of the role and purpose of the package. | Tagged value, of type "short text". |
| Use Cases | The use cases directly contained in the package. | Owned via the aggregation "owns". |
| Actors | The actors directly contained in the package. | - " - |
| Relationships | The relationships directly contained in the package. | - " - |
| Diagrams | The diagrams directly contained in the package. | - " - |
| Use-Case Packages | The packages directly contained in the package. | - " - |
Timing
Use-case package partitioning is done as soon as the use-case model is too large to maintain as a flat structure. This can be the case early in inception, or later on in the elaboration or construction phases.
Responsibility
A requirements specifier is responsible for the integrity of the package, which ensures that:
- The package fulfills its requirements.
- The package is as independent as possible of other packages.
- The existence of the direct contents of the package (including its use cases, actors, relationships, diagrams, and packages) is justified and kept consistent.
It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases. For more information, refer to Guidelines: Use Case.
Tailoring
+ Provide a hierarchical model structure with separate functional units. This is easier to understand than a flat model structure (without packages) if the use-case model and the system is relatively large.
+ Offer a good opportunity to distribute work and responsibilities among several developers according to their area of competence. This is particularly important when you are building a large system. Use-case packages also offer a secure basis if you need to ensure confidentiality among your developers so that only a few know about the complete functionality of the system.
+ Because use-case packages should be units of high cohesion, changing one package will not affect other packages.
- Maintaining use-case packages means more work for the use-case modeling team.
- Using use-case packages means that there is yet another notational concept for the developers to learn.
If you use this technique you have to decide how many levels of packages to use. A rule of thumb is that each use-case package should contain approximately 3 to 10 smaller units (use cases, actors, or other packages). The table below gives some suggestions as to how many packages you should use given the number of use cases and actors. The quantities overlap because it is impossible to give exact guidelines.
- 0-15: No use-case packages needed.
- 10-50: Use one level of use-case packages.
- > 25: Use two levels of use-case packages.
