Package diagram

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.
Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram

Package diagram

Notation

 Access Constraint
 Dependency Generalization
 Import Merge
 Note Package
 Realization Subsystem

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

NameThe name of access relationship.
SupplierThe 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.
ClientThe 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.
VisibilitySpecifies 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.
DocumentationDescription 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

NameThe name of constraint. It is optional and is commonly omitted.
ExpressionThe condition that must be true when evaluated in order for the constraint to be satisfied.
DocumentationDescription 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

NameThe name of dependency.
SupplierThe 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.
ClientThe 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.
VisibilityDetermines where the dependency appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription 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

NameThe name of generalization.
GeneralReferences the general classifier in the Generalization relationship.
SpecificReferences the specializing classifier in the Generalization relationship.
VisibilityDetermines where the generalization relationship appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of generalization relationship.
SubstitutableIndicates 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

NameThe name of import relationship.
SupplierThe 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.
ClientThe 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.
VisibilitySpecifies 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.
DocumentationDescription 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

NameThe name of merge relationship.
SupplierThe 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.
ClientThe 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.
VisibilityDetermines where the merge relationship appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription 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

NameThe name of note.
DocumentationSpecifies 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

NameThe name of package.
ParentThe element that contains the package.
VisibilityDetermines where the merge relationship appears within different namespaces within the overall model, and its accessibility.
DocumentationDescription of package.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a package. If the value is true, then it is not possible to further specialize the package.
RootIndicates whether the package has no ancestors. (true for no ancestors)
ChildrenThe children of package.

Related Links

[Tutorial] UML Package Diagram Tutorial
 

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

NameThe name of realization relationship.
SupplierThe 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.
ClientThe 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.
VisibilityDetermines where the realization relationship appears within different namespaces within the overall model, and its accessibility.
MappingA 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.
DocumentationDescription of realization relationship.
 

Subsystem

Definition

A subsystem represents the boundary of the physical subsystem.

Properties

NameThe name of subsystem.
ParentThe element that contains the subsystem.
DocumentationDescription of subsystem.
AbstractIf 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.
LeafIndicates whether it is possible to further specialize a subsystem. If the value is true, then it is not possible to further specialize the subsystem.
RootIndicates whether the subsystem has no ancestors. (true for no ancestors)
OperationsAn 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.
ChildrenThe children of subsystem.
 
Definition of notations is quoted from Object Management Group Unified Modeling Language (OMG UML) Superstructure Version 2.2 and former versions (for notations that do not exist anymore in latest specification).
 
Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram
Gallery Home
Visual Modeling
UML Modeling
Use Case Modeling
Requirements Capturing
Data Modeling
Business Process Modeling
Object Relational Mapping
Documentation Generation
Code Engineering
Interoperability
User Interface
Cross-Platform
Visual Studio Integration
Eclipse Integration
NetBeans Integration