UML: Modeling Software Architecture with Packages

If a system is big, it should be partitioned in smaller sub-systems, each with its own class diagram. In UML notation, the partitions/sub-systems are called packages. A package is a grouping of model elements, and as such, it is a UML construct used also in other UML diagrams. Packages themselves may be nested within other packages that basically the UML version of a directory, a place to put things. Package diagrams are typically applied for the following cases:

• Provide a way to group related UML elements and to scope their names
• Provide a way to visualize dependencies between parts of your system
• Vulnerable to changes (in other packages)
• Provide support for analysis
• Determine compilation order

Package Diagram at a Glance

Package diagram is used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements.

The diagram below is a business model in which the classes are grouped into packages:

• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly force changes in the first.

Package Diagram Namespace

Packages contain different elements (packages too). A UML package establishes a namespace for specifying the context of a UML. A package defines what is known as an encapsulated namespace. When an element in one space needs to refer to an element in a different namespace, it has to specify both the name of the element it wants and the qualified name or pathname of the element (compare to file system analogy). You provide the fully scoped name, for example,

packageName::className

In Java, a fully-scoped name corresponds to specify the Java package. It is possible to specify visibility for owned and imported elements, such as, public or private as well.

• Qualified name of the class Librarian in the figure below is

Library::Users::Librarian

Alternative Representation of Package

System and SubSystem

A system is represented as a package with the stereotype of <<system>> as shown in Figure below. The system represents all the model elements that pertain to the particular project. You can also break a system into <<business systems>> and <<application systems>> when building more detailed models to make them smaller and more workable. In the UML, packages are represented as folders.

A subsystem is a grouping of model elements that are part of the overall system. Subsystems, like systems, are stereotyped packages with the stereotype of <<subsystem>> as shown in the Figure below.

Stereotype in UML

Stereotypes are a high-level classification of an object that gives you some indication of the kind of object it is. Classes can be grouped under stereotypes, whose name is written between matched guillemots (<< >>), over the class name.

A stereotype enables you to extend the UML to fit your modeling needs more specifically. A stereotype is a UML modeling element that extends the existing elements. Stereotyping a UML element causes it to act as something else that has specific properties. A stereotype is represented as <<stereotype>> on the element being stereotyped.

Packages for Software Structure

Because a system or subsystem is a stereotyped package, it has all the properties and rules of a package. This means those model elements that are contained by the system and subsystem are owned by that package and can only be part of them and no other.

The subsystem gives the project team an easy way to partition the system. Since a system contains multiple subsystems, everything contained within the subsystems is owned by the system that they roll up into. A diagram can display the logical architecture of a system.

Element Visibility in Package

Package elements with public visibility are accessible outside the package, while elements with private visibility are available only to other elements inside the package. In UML, public, protected and private visibilities correspond to a class being public, protected or private to a Java package. If the public keyword is absent, then the class is private to the package.

Visibility	Java Syntax	UML Syntax
public	public	+
protected	protected	#
package		~
private	private	–

• A public element is visible to all elements that can access the contents of the namespace that owns it. Public visibility is represented by ‘+’ literal.
• A protected element is visible to elements that have a generalization relationship to the namespace that owns it. Protected visibility is represented by ‘#’ literal.
• A package element is owned by a namespace that is not a package and is visible to elements that are in the same package as its owning namespace. Package visibility is represented by ‘~’ literal.
• A private element is only visible inside the namespace that owns it. Private visibility is represented by ‘-‘ literal.

Note That:

• The package is the UML mechanism for grouping items (including other packages).
• Each package has its own namespace within which all names must be unique.
• Every model element is owned by one package.
• The packages form a hierarchy.
• The set of UML building blocks consists of things, relationships, and diagrams.

Package Diagram – Dependency Notation

They are different types of dependency relationship represented by using stereotypes, perhaps we can define some new stereotype to serve for your specific purpose.

 

Package dependency	Semantics
	An element in the client package uses a public element in the supplier package in some way – the client depends on the supplier. If a package dependency is shown without a stereotype, then <<use>> should be assumed.
	Public elements of the supplier namespace are added as public elements to the client namespace. Elements in the client can access all public elements in the supplier using unqualified names.
	Public elements of the supplier namespace are added as private elements to the client namespace. Elements in the client can access all public elements in the supplier using unqualified names.
	<<trace>> usually represents a historical development of one element into another more developed version – it is usually a relationship between models rather than elements (an extra-model relationship),
	Public elements of the supplier package are merged with elements of the client package. This dependency is only used in metamodeling – you should not encounter it in ordinary OO analysis and design.