Packages are Unified Modeling Language (UML) constructs that enable you to organize model elements, such as use cases and classes, into groups. Packages, when applied effectively, are used to simplify your software diagrams. In the UML, packages are depicted as file folders, as you see in Figure 2, and may be used on any UML diagram. However, packages are most commonly applied to use case diagrams and class diagrams because these models have a tendency to grow and hence have a greater need to be partitioned.
An example: Simplifying a use case diagram
Figure 1 depicts a complex use case diagram (use case diagrams are described in "Modeling essential use cases"), and Figure 2 shows how you would partition it using packages. By introducing packages, the use case diagram becomes simpler and easier to understand. Each package, in turn, would be documented by another use case diagram, such as the one presented in Figure 3.
Figure 1. A partial use case model for a university system
Figure 2. A use case model organized with packages
Figure 3. The "Manage seminar registration" package
Rules of thumb for applying packages
- Apply packages when diagrams become cluttered
I typically use packages only when my diagrams become unwieldy, which generally implies they cannot be printed on a single page. Packages can be used to organize a large diagram into several smaller ones. A good heuristic is that a diagram should have 7 +/- 2 bubbles on it, where each bubble is a use case or class.
- Packages should be cohesive
Anything you put into the package should make sense when considered with the rest of the contents of the package. A package is likely cohesive if you can give it a short, descriptive name. If you can't, you may have put several unrelated things into the package.
- For use case diagrams, start with related use cases
To identify packages on use case diagrams, I like to start with use cases that are related to one another via extend and include associations. My heuristic is that included and extended use cases belong in the same package as the base/parent use case. This rule works well because these use cases typically were introduced by "pulling out" their logic from the base/parent use case to start with. I then analyze the use cases with which my main actors are involved. What you will find is that each actor will interact with your system to fulfill a few main goals; for example, students interact with your system to enroll in the university, manage their schedules, and manage their financial obligations with the university.
- For class diagrams, start with related classes
I take a similar approach for UML class diagrams. First, classes in the same inheritance hierarchy typically belong in the same package. Second, classes related to one another via aggregation or composition often belong in the same package. Third, classes that collaborate with each other a lot -- information reflected by your sequence diagrams and collaboration diagrams -- often belong in the same package. Fourth, the desire to make your packages cohesive will often drive your other decisions to put a class into a package.
- The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2000.
- The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.