UML – Package Diagram

So the story continues, Ever Whining Rational Rose Corporation were not happy with just drawing classes. They wanted to wrap them in packages. So Three Amigos concocted what we now call Package Diagram.

So what is a package diagram?

A Package is a container which contains groups of related elements. These elements can be any of the UML constructs like classes, components , use cases, etcetera.

A Package Diagram is an UML structural Diagrams that helps us in showing and modelling the dependencies between various packages in a system.

Although packages can be used to group anything but they are mostly used to group classes and components and sometimes use cases. From UML 2 superstructure Package  definition goes as follows.

A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned members of a package. By virtue of being a namespace, a package can import either individual members of other packages, or all the members of other packages. In addition a package can be merged with other packages.

Within a system a package name is unique, but for elements the rules change a bit. Elements of same types within a package should have unique names but two elements of different type can have same name in the same package.

A typical element in a package is owned by that package. The package can import elements of other packages by importing the package.

Graphically a package is depicted like a folder with package name written in center of the package.

Visibility of package elements

An element of package can be marked as public, private and protected.

  • public (+) – public elements can be accessed by any elements inside or outside the package.
  • private (-)- Only the elements within the same package can access a private element.
  • protected (#)- Protected elements can be used by elements within the same package or any package that extends the parent package.

A package can contain other packages and the nested packages can be marked as public private or protected. Elements of  a package can be represented using text, rectangular content notation or composition style notation. For example consider a package called CourseManager. CourseManager has public elements like Course, Tutor, Students and a private element called StudentCourseLink. Then the package can be represented graphically in following three ways.

Textual Representation

Rectangular Content Notation

Composition Style Notation

Package Dependencies – As we already know that is a software system we have multiple components which interact with each other to provide services to client. Same concept holds for packages. A real live systems will be composed of many packages and they will interact with each other. In other words the packages have dependencies on each other. The UML defines two kinds of dependencies on the packages.

  1. Access – Signifies that a package uses or accesses public element of another package. It is depicted by drawing a dotted arrow stereotyped with <<access>>. The direction of arrow is from the package that uses another package to package which is used.
  2. Import – Signifies that a package has imported the public elements of another package into its own namespace. The imported package namespace remains intact.
Both the access and import sounds almost similar. The difference is that in case of access. the source package access selected public elements of the target package however in case of import, all the public elements of target package is imported. Both the dependencies are depicted by an open ended broken arrow pointing towards target 
The diagram below will explain how to show dependency between packages. 

Package Stereotypes – There are many predefined UML stereotypes, of these 5 are applicable to package diagrams. They are facade, framework, stub, subsystem and system. Let us see what they mean.

  1. facade – As the name suggests a Facade package is a public representation of another larger package. Facade package does not contain any element of its own rather it contains references to elements of other larger packages. To make it clear you can visualize facade design pattern where working of a larger complex component/s is hidden from the client by use of a public facade interface.
  2. Framework – When creating a framework we use a lot of application level patterns to implement a various subsystems within the framework. Classes and interfaces used to implement the subsystems can be packaged in a Framework package.
  3. Stub – Stub Package is usually used to package interfaces and abstract classes that defines a web service.
  4. Subsystem – A system is composed of many subsystems and each subsystem in turn will contain many component. A subsystem package contains classes and interfaces that are used to fully implement a subsystem.
  5. System – A system package contains all the classes, interfaces, components and subsystems that creates the system

Package Tagged Values – Packages support tag values. You can tag a package with information such as version, author name, description, major version etc

Package Merge – Apart from import there is one more important dependency between packages, i.e., Package Merge. Package merge indicates a relationship between two packages where all the public contents of target package is to be combined with those of source package. Merge is done if multiple packages have elements of same name which also represent a similar concept.  Merge is very similar to generalization (inheritance) in sense that all the matching elements are combined to give a base definition to the matching element then the base definition is extended incrementally in different merged packages giving the merged element a specific purpose in each of the packages. The independent elements of merged packages retain their original characteristic.

Here are some exerpts from UML 2 superstructure document

A package merge is a directed relationship between two packages that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both.

This mechanism should be used when elements defined in different packages have the same name and are intended to represent the same concept. Most often it is used to provide different definitions of a given concept for different purposes, starting from a common base definition. A given base concept is extended in increments, with each increment defined in a separate merged package. By selecting which increments to merge, it is possible to obtain a custom definition of a concept for a specific end. Package merge is particularly useful in meta-modeling and is extensively used in the definition of the UML metamodel.

Conceptually, a package merge can be viewed as an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge. In terms of model semantics, there is no difference between a model with explicit package merges, and a model in which all the merges have been performed.

Package merge is shown as dotted line with open arrowhead pointing from receiving package to target package. In addition keyword <<merge>> is put near the the dotted line.

Small Example – Consider a video processing engine. It has a VideoQueue which is turn contains video objects to be processed. There is a Videopocessing thread picks the video  from queue and uses a VideoProcessor to process the video. The VideoProcessor is an interface implemented by various kinds of video processor. A have tried to create a simple package diagram to capture the the elements in this design.

Package Diagram for a Video processing engine. 

I mostly use package diagram to capture the high level entities of a system and then finally use it as starting point to model my database. Some times I also use it to capture the solution architecture of my application. I will share the solution architecture diagram I created for one of my projects. Would love to see the comments of reader and check if makes sense to rest of folks or only to me.

Note – some of the info about the system has been removed due to non disclosure agreement.

Package Diagram depicting high level solution Architecture (Beautiful ain’t it. :)).

Phew! that was quite something. Writing a blog post is very difficult and I am sure I have missed many things. But I know that my fans (err I meant dear readers 🙂 ) will find few missing points or mistake and they will notify me about it. But for now I feel bit tired and want to go out for a coffee.

I my next post on UML I will be producing an awesomely beautiful essay on Component Diagram. I will surely remember to out a link out here for easy navigation. Till then bye bye and take care  🙂 .




Print Friendly, PDF & Email

About Niraj Singh

I am CEO and CoFounder of a startup "Aranin Software Private Limited, Bangalore. I completed my graduation in 2002 as an Aerospace Engineer from IIT Kharagpur. I love working on new ideas and projects and recently released my first open source project JaiomServer "". I have 9 years of experience in IT industries most of which I have spent in developing community applications for various clients using java. Some of the sites in which I have actively involved with are,,,, etc.
This entry was posted in Package Diagram and tagged , . Bookmark the permalink.

One Response to UML – Package Diagram

  1. fan says:

    The next time I read a weblog, I hope that it doesn’t disappoint me as much as this one. I mean, I know it was my option to learn, however I actually thought you’d have something interesting to say. All I hear is a bunch of whining about one thing that you can repair should you weren’t too busy on the lookout for attention.

Comments are closed.