UML Guide v2.1

UML Package Element
A package is a way to organize and group UML elements, thereby allowing the software designer a way to manage complexity at a meta-level. A typical package could contain all the classes and components used in a graphical product to do the drawing, while another package could be used to group GUI artifacts, and for all utility type class or libraries a package could contain them.

The UML package element is drawn like a folder with a tab on the top left or top right corner.

Diagram 1 - Package Element

Just like classes and objects, packages can have various relationships with each others. Package dependency can be shown by having one package import another package, by doing this a package gain access to elements in the imported package. Also as shown below, a package may contain one or more sub-package, with a package subclassing another package.

Diagram 2 - Package Diagram Showing "has-a", "uses", "is-a" Relationships

It should be clarified that a package that imports another package is using the "uses" relationship. A package that contains one or more other sub-packages is using the "has-a" relationship, while a package that inherits from another package is using the "is-a" relationship similar to classes.

How to Package
A package diagram provides a big-picture of the software sub-models and how they are interconnected and grouped. A package will usually need to provide an "exploded" view with some or all of it's constituents elements being accounted for.

Diagram 3 - Packageing

When considering what needs to belong together in a package, here are some points to keep in mind.

1. Classes from the same hierarchy, that don't already belong to another package. A derived class P may subclass from class Q belonging to another package, but all derived classes of class P must be grouped in the same package as class P.
2. Classes that provide similar functionality such as utility classes, GUI classes, or Storage classes.
3. Classes that are tightly coupled, using composition or aggregation.
4. Classes or packages that help form a subsystem, such as a network infrastructure.
5. Classes must provide a cohesion, you should be able to use a single simple name to label the package. Otherwise you have unrelated classes and need to rethink things over.

Namespaces
Package represent a namespace that all UML elements of the package belong to. Namespace provide scoping such that different UML elements like two classes can co-exist in the same architecture having the same name but belonging to different packages. When these classes are referenced, they need to be accessed by their proper fully-qualified name that includes the namespace followed by the name of the class that is separated by a scope "::" (two colon signs) UML notation.

Diagram 4 - Packaging Namespace

In the real world, it is highly likely that different class designers will pick very common names to give to their classes. To prevent names from clashing and causing ambiguity when taking about a particular class, namespaces were introduced to the development community. Without namespaces, if a developer wanted to use the class Event from package SuperUtil and class Logger from package STD, there would be no way to do this because class string and class Queue would cause build time ambiguity.

Previous

Next

Copyright © 2007 Rajinder Yadav, All rights reserved

UML logo are trademarks or registered trademarks of the Object Management Group, Inc. in the United States and other countries