|
 |
|
|
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 | |
| DefinitionPackage 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. |
| | |
|
|
| | | 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. | | Children | The 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
|
|
|
|
|
 |
|
