Identifying Use Case Packages

A use case diagram represents some behavioral aspect of a system, subsystem, or a class. It consists of a set of conceptually and semantically related use cases. The aggregate of all the use cases in all the use case diagrams represents the system functionality; this is also called the static use case view of a system. However, each individual use case with its associated set of sequences of actions constitutes the dynamic view of the system. The focus should be on creating use cases that factor common behavior, and then grouping use cases that are relevant to each other, both conceptually and semantically, in producing a desired system behavior. Such groupings form independent, self-contained functional units that could be packaged as subsystems during the analysis phase. Use cases in each package must have strong cohesion to each other and exhibit loose coupling with other packages.

Decomposing the system into packages has the advantage of modularizing the system, making it simpler to understand, manage, and document. The atomicity at the level of subsystems enables concurrent analysis, design, and development effort of different subsystems. The package hierarchy defined in the requirements phase can be used to model the structural view of the system during the analysis phase, and each package could potentially result in a subsystem. However, during the analysis phase you will also discover several supporting objects interacting with multiple packages. For example, the authentication module, the error reporting module, and the service locator module could be common to several packages; therefore, in the analysis phase, the package structure will need to be modified for housing such components. During the analysis phase, you may find the need to break down a package into subordinate packages; make sure the nesting is not more than a couple of levels, otherwise the packages get harder to manage.

Once the key abstractions are identified in the system context, we are able to distinguish functionally related use cases and move these into packages. Let's briefly define these groupings and then assess whether each grouping cohesively expresses an independent functional unit. Figure 1-4 depicts the system's use case packages with dependency relationships between several packages. This relationship is shown using a dashed line with an arrowhead pointing in the direction of the package that the other depends on. The dependency implies that a package is dependent on another package for some services or has structural knowledge about the elements in the other package.

Figure 1-4: Decomposing the system into packages

GreaterCause Use Case Packages

GreaterCause use cases are distributed among packages shown in Figure 1-4. Refer to the use case diagrams corresponding to each package under the later section "GreaterCause Use Case Summary" for package description and for the use cases allocated to each package. The use case diagrams associated with each package in the section "GreaterCause Use Case Summary" depicts package interactions or dependencies using actors as stand-ins for related packages.

Once the decomposition has been accomplished, the use case diagrams can show package interactions or dependencies using actors as stand-ins for package-related functions. This notation supports the definition of a system context where every subsystem boundary scopes the behavior from the point of view of all the actors interacting with the subsystem.