Packages provide a generic tool for grouping information and model elements. The contents of a package are entirely user-defined, so packages make a convenient tool for defining partitions. A package may be named and stereotyped, for example:
If you need some review of packages or package notation, please visit the Resources page and look at the pdf file UML Fundamentals_packages.
When you use a package to represent a subsystem, use the <<stereotype>> notation, for example, <<subsystem>>. This notation ensures that your model will be interpreted correctly.
Like packages, stereotypes are pretty much up to you to define, but the UML standard does provide some standardized stereotypes.
Packages and subsystem specifications
Packages may represent subsystems. In fact, "subsystem" is a UML keyword used with packages to specify "a grouping of elements of which some constitute a specification of the behavior offered by the other contained elements."
The goal in domain partitioning is to place all of the model elements that define the behavior and the resources for the system into cohesive packages. Each package represents a subsystem, a subset of the complete functionality of the finished system.
Relationships between packages are expressed as dependencies.
A dependency is described with a dashed arrow and a stereotype or UML keyword.
A dependency arrow indicates that the source package requires assistance from the target package, such as access to objects created or maintained by the target package, or functionality owned by the target package. In the booking system,
for example, you cannot sell tickets for shows until the seats in the show have been defined and priced.
sales Subsystem Dependencies
Consequently, the Sales subsystem would depend on the Venue Management, which places the seats within the auditorium. The Sales subsystem would also depend on Show Management, which defines the shows; and Pricing, which assigns the prices to seats in each show.