Design Package		 A design package is a collection of classes, relationships, use-case realizations, diagrams, and other packages. It is used to structure the design model by dividing it into smaller parts.
UML representation: Package in the design model.
Worker: Designer
Reports: Design-Model Survey, Design Package/Subsystem
More information: Guidelines: Design Package

Purpose To top of page

The following people use the design packages:

  • Architects to structure the design model.
  • Those who design the next version of the system to understand the structure of the design model.
  • Designers of other parts of the system to understand how their functionality can be used.
  • Testers for the package to plan testing activities.

Design Packages are used to group related Design Model elements together for organizational purposes, and often for configuration management.  Unlike the Artifact: Design Subsystem, a Design Package does not offer a formal interface, though it may expose some of its contents (marked as 'public') which offer behavior.  Design Packages should be used primarily as an model organizational tool, to group related things together; if behavioral semantics are needed, use Design Subsystems.

A Design Package and its contents are the responsibility of a single Worker: Designer.   Elements within the package may be dependent on the elements contained by other packages; this gives rise to dependencies between packages.  Package dependencies can be used as a tool to analyze the resiliency of the design model: a model with cross-dependent packages is less resilient to change.

Properties To top of page

Property Name

Brief Description

UML Representation
Name The name of the package. The attribute "Name" on model element.
Brief Description A brief description of the role and purpose, or the "theme" of the package. Tagged value, of type "short text".
Classes The classes directly contained in the package. Owned via the aggregation "owns"
Relationships The relationships directly contained in the package. - " -
Use-Case Realizations The use-case realizations directly contained in the package. - " -
Diagrams The diagrams directly contained in the package. - " -
Design Packages The packages directly contained in the package. - " -
Import Dependencies The import dependencies from the package to other packages. Owned by an enclosing package, via the aggregation "owns".

Timing To top of page

Packaging should be done at the beginning of the elaboration phase, during the Activity: Architectural Analysis and the Activity: Architectural Design. Packaging may be adjusted at any time during the project, to re-balance responsibilities or reorganize the Artifact: Design Model. 

Responsibility To top of page

A designer is responsible for the integrity of the package, ensuring that:

  • The package fulfills the requirements made on it.
  • The package is as independent as possible of other packages.
  • The import dependencies originating from the package are described so that the effect of future changes can be estimated.
  • The existence of the direct contents of the package, including its classes, relationships, use-case realizations, diagrams, and packages, is justified and kept consistent.
  • The visibilities of the direct contents of the package, primarily regarding classes and packages, are correct. A visibility can be "public," "private," and so on.

It is recommended that the designer responsible for a design package is also responsible for its contained classes; for more information refer to Artifact: Design Class.

Note that the designer is not responsible for the contained use-case realizations and their related diagrams; instead, these are under the corresponding use-case designer's responsibilities.

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)