|
|
One of the oldest and most difficult questions in software design is how do we break down a large system into smaller systems? This is because as systems get larger and larger, it becomes difficult to understand and maintain them. Package analysis is UML's method of breaking down large systems.
A package is a container of modeling elements, a general-purpose mechanism or higher-level unit for organizing elements into groups.
A package diagram can be used in every step of the UML. It may be a container of use cases, of classes, of components etc. In the case of use cases, every package should correspond to a chapter or a main paragraph of the program’s manual. A package diagram is shown in Figure 7 .
Figure 7 A Package diagram
The relationship that connects two packages is called a dependency. A dependency relationship from package A to package B means that A depends on B playing the role of a client/supplier relationship (A:client, B:supplier). A dependency exists between two packages if changes to the definition of one package may cause changes to the other. A dependency between two packages exists if a dependency exists between any use cases (or classes for package diagrams containing classes) in the packages. E.g. because a use case in BorrowRequest package depends on a use case in SearchRequest package, the two packages are connected with a dependency relationship (see Figure 7). Good system architecture tries to minimise dependencies among packages.
In the case of package diagrams containing classes, this means that a class inside the client package is dependent on a public method of a public class in the supplier package. Hence, a package's interface contains only the public methods of it public classes. A good system design technique is to reduce the interface of a package by exporting only a small subset of the operations associated with the package's public classes. We can do this by giving all classes package visibility, so that they can be viewed only by other classes in the same package, and by adding extra public classes in the same package, for the public behaviour of the package. These extra classes are called facades [Gamma et. al., 1995] and delegate public operations to their syer companions in the package.
Packages can include other packages, called sub-packages.
Generalisation
relationships can also be used with packages [Fowler, 2000a]. This means that
the specific package must conform to the interface of the general package. The
general package may be marked as {abstract} to show that it merely defines an
interface that is implemented by one or more specific packages. Generalisation
implies a dependency relationship from the subtype to the supertype.
You
can mark a package as «global»,
which means that all packages in the system have a dependency to this package
(e.g. a Utilities package). When you show a package’s contents, you put the
name of the package in the tab of the package icon and the package contents
inside the main box. These contents can be a list of classes, another package
diagram, or a class diagram.
