| Lesson 3 | Packages |
| Objective | Explain the use of packages to model partitions. |
Packages to Model Partitions
Packages
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:
- Dependency arrow: The Sales partition depends on the Show Pricing partition.
- Dependency arrow: The Sales partition depends on the Show Pricing partition.
- Package name and Stereotype (in label form; stereotypes may also be shown as icons
uml Package Description
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.
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.
Package dependencies
Relationships between packages are expressed as dependencies[1].
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.
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.
- This subsystem will define the seat locations within the auditorium.
- This subsystem tracks which seats are available for sale for each show.
- This subsystem assigns prices to seats within each show.
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.
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.
Domain Partitioning Packages
Click the Exercise link below to practice what you have learned about domain partitioning and packages.
Domain Partitioning Packages
Domain Partitioning Packages
[1]Dependency: A relationship between two model entities in which a change to one (the independent model element) will affect the other (the dependent model element).