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:
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 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.
Library::Users::Librarian
Alternative Representation of Package
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.
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.
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.
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 | – |
Note That:
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. |