Package Diagram

Package diagrams are customized to illustrate different aspects of systems.
- E.g. a package diagram can model the structure of systems and subsystems.
  - An Accounting System package, for instance, might contain packages for the Accounts Receivable subsystem, the Accounts Payable subsystem, the General Ledger subsystem, and so on.
A Package diagram can also represent the organization of the various types of models used to describe a system.
- A Package diagram used in this way might contain a set of packages that describes a billing system including the Use Case model, the Analysis model (Class diagrams), and the Deployment model.
- In a similar manner, an Analysis model package could contain packages that represent just the analysis-level models for a set of subsystems.
- A package is represented in a Package or Class diagram as a folder icon.

The specific type of relationship is called a dependency.
- A dependency simply states that one element needs help from another element.
- The help may be in the form of functionality or data provided by the other element.
- Between packages, dependency states that something inside of one package needs help from something inside the other package.
In the following figure, the dashed arrow models the packages for the theater system.
- Notice the dependency between the two packages at the top of the diagram, VenueManagement and Scheduling.
- This dependency states that something inside the Scheduling package needs help from something inside the VenueManagement package.

Package diagrams identify the data and functional dependencies between parts of a system.
- They also identify the partitioning of a system into subsystems.
- They separate utilities from system-specific components and isolate layers of an architecture.
In a modeling tool, the Package diagram is typically accessed within the Class diagram.

Bold filled arrow identifies derivation.
- Classes/interfaces in "base" package are extended/implemented in "derived" package, etc.
- Derived classes need not be in the same package as base class.
Light arrow represents a dependency, typically stereotyped («import», «access», etc.).

Package name is part of the class name.
- E.g., given the class fred in the flintstone package, the fully-qualified class name is flintstone.fred.
This diagram is generally needed when entire static-model won't fit on one sheet.
Packages can nest, so the outermost packages called domains if they contain only sub packages (no classes).
In the previous example, the tools package is an outer package; the com.holub package is a domain.
Nested packages can also be shown using a tree structure and static-model nested-class symbol.

Class Diagram