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