Package diagram

Notation

Definition

Package diagram shows the arrangement and organization of model elements in middle to large scale project. Package diagram can show both structure and dependencies between sub-systems or modules.

Access

Definition

An element import is defined as a directed relationship between an importing namespace and a packageable element. The name of the packageable element or its alias is to be added to the namespace of the importing namespace. It is also possible to control whether the imported element can be further imported.

An element import is shown using a dashed arrow with an open arrowhead from the importing namespace to the imported element. The keyword <<import>> is shown near the dashed arrow if the visibility is public; otherwise, the keyword <<access>> is shown to indicate private visibility.

Properties

Name

The name of access relationship.

Supplier

The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific.

Client

The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation.

Visibility

Specifies the visibility of the imported PackageableElement within the importing Package. The default visibility is the same as that of the imported element. If the imported element does not have a visibility, it is possible to add visibility to the element import. Default value is public.

Documentation

Description of access relationship.

Constraint

Definition

A condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.

Properties

Name

The name of constraint. It is optional and is commonly omitted.

Expression

The condition that must be true when evaluated in order for the constraint to be satisfied.

Documentation

Description of constraint.

Dependency

Definition

A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).

Properties

Name

The name of dependency.

Supplier

The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific.

Client

The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation.

Visibility

Determines where the dependency appears within different namespaces within the overall model, and its accessibility.

Documentation

Description of dependency.

Generalization

Definition

A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of the more general classifier.

Properties

Name

The name of generalization.

General

References the general classifier in the Generalization relationship.

Specific

References the specializing classifier in the Generalization relationship.

Visibility

Determines where the generalization relationship appears within different namespaces within the overall model, and its accessibility.

Documentation

Description of generalization relationship.

Substitutable

Indicates whether the specific classifier can be used wherever the general classifier can be used. If true, the execution traces of the specific classifier will be a superset of the execution traces of the general classifier.

Import

Definition

A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace.

Properties

Name

The name of import relationship.

Supplier

The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific.

Client

The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation.

Visibility

Specifies the visibility of the imported PackageableElements within the importing Namespace, i.e., whether imported elements will in turn be visible to other packages that use that importingPackage as an importedPackage. If the PackageImport is public, the imported elements will be visible outside the package, while if it is private they will not.

Documentation

Description of import relationship.

Merge

Definition

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.

Properties

Name

The name of merge relationship.

Supplier

The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific.

Client

The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation.

Visibility

Determines where the merge relationship appears within different namespaces within the overall model, and its accessibility.

Documentation

Description of merge relationship.

Note

Definition

A note (comment) gives the ability to attach various remarks to elements. A comment carries no semantic force, but may contain information that is useful to a modeler.

Properties

Name

The name of note.

Documentation

Specifies a string that is the comment.

Package

Definition

A package is used to group elements, and provides a namespace for the grouped elements. A package is a namespace for its members, and may contain other packages.

Properties

Name

The name of package.

Parent

The element that contains the package.

Visibility

Determines where the merge relationship appears within different namespaces within the overall model, and its accessibility.

Documentation

Description of package.

Abstract

If true, the package does not provide a complete declaration and can typically not be instantiated. An abstract package is intended to be used by other packages.

Leaf

Indicates whether it is possible to further specialize a package. If the value is true, then it is not possible to further specialize the package.

Root

Indicates whether the package has no ancestors. (true for no ancestors)

Children

The children of package.

Related Links

Realization

Definition

Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

Properties

Name

The name of realization relationship.

Supplier

The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific.

Client

The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation.

Visibility

Determines where the realization relationship appears within different namespaces within the overall model, and its accessibility.

Mapping

A composition of an Expression that states the abstraction relationship between the supplier and the client. In some cases, such as Derivation, it is usually formal and unidirectional. In other cases, such as Trace, it is usually informal and bidirectional. The mapping expression is optional and may be omitted if the precise relationship between the elements is not specified.

Documentation

Description of realization relationship.

Subsystem

Definition

A subsystem represents the boundary of the physical subsystem.

Properties

Name

The name of subsystem.

Parent

The element that contains the subsystem.

Documentation

Description of subsystem.

Abstract

If true, the subsystem does not provide a complete declaration and can typically not be instantiated. An abstract subsystem is intended to be used by other subsystems.

Leaf

Indicates whether it is possible to further specialize a subsystem. If the value is true, then it is not possible to further specialize the subsystem.

Root

Indicates whether the subsystem has no ancestors. (true for no ancestors)

Operations

An operation is a behavioral feature of a subsystem that specifies the name, type, parameters, and constraints for invoking an associated behavior. Operations here refers to the operations owned by the subsystem.