Zicomi Systems Logo
contact us  |  your privacy
Company
Services
Products
Support
Resources
  OMG Standards
OMG Logo
UML Element Description
Abstraction
Abstraction    
An abstraction is a type of dependency and therefore a directed relationship between one or more clients (tail end) and one or more suppliers (arrowhead end). The elements represent the same concept but may be an expression of the concept at different stages of evolution, be views that hide or reveal detail, or be a representation from a different viewpoint. An abstraction can be used as an element in its own right, although it has a number of stereotypes that make its application more precise.
Call Dependency
Call Dependency    
A call dependency connects an operation in one class, the source to an operation in another class, the target. The relationship may be made less precise by attaching either the source or target or both ends to the classes that contain the operations.
Comment (Note) Attaching Line
Comment (Note) Attaching Line    
A comment attaching line is a dashed line that is used to attach a comment (note) to a model element in a diagram. The comment (note) attaching line is not a UML relationship and has no semantics beyond signifying that the contents of a comment apply to the model element it is attached to. A comment may be attached to any number of model elements or may exist in isolation and by placement in proximity to one or more model elements signify that it applies to those elements.
Create Dependency
Create Dependency    
A create dependency is a usage dependency that signifies that one or more of the operations on the client (tail end) create instances of the supplier classifier (arrowhead end).
Dependency
Dependency    
A dependency is a type of relationship that signifies that one element, or group of elements, acting as the client depends on another element or group of elements that act as a supplier. It is a weak relationship that denotes that if the supplier is changed the client may be affected. It is a unidirectional relationship.
Deployment
Deployment    
A deployment is a type of dependency. It is a directed relationship between one or more deployed artifacts and a deployment target. The deployment target is the location where the artifact is deployed and can be a device, execution environment or a property. The deployment can be used to describe the relationship at a type or instance level. A component deployment is a specialized form of deployment that can have one or more deployment specifications that govern the way the artifact is deployed.
Derive Dependency
Derive Dependency    
A derive dependency is an abstraction dependency that indicates that the client (tail end) can always be calculated from the supplier (arrowhead). This implies that the client is strictly redundant, and may be modeled for performance reasons or ease of use.
Element Import
Element Import    
An element import is a directed relationship between a packageable element (arrowhead end) and an importing namespace (tail end). The element that is pointed to is added to the namespace, allowing the element to be used in the namespace without any qualification. A name can be added to the element import relationship, which is used as an alias (alternative name) for the element in the importing namespace. The visibility of the element in the importing namespace is by default public.
Element Import (Access)
Element Import (Access)    
An element import with the keyword access is a directed relationship between a packageable element (arrowhead end) and an importing namespace (tail end). The element that is pointed to is made accessible to the namespace, allowing the element to be used in the namespace without any qualification. It is different from an element import with keyword import because it does not import the element into the namespace but rather just allows it to be accessed. A name can be added to the element import relationship, which is used as an alias (alternative name) for the element in the importing namespace. The visibility of the element in the importing namespace is by default public.
Extend
Extend    
Extend is a relationship that may exist between two use cases, the base use case and the extension use case. It is said to be conditional in the sense that a set of extension points defines conditions under which the insertion will occur. The extension points are defined in a separate section of the use case.
General Ordering
General Ordering    
A general ordering is a named element that relates two event occurrences (message ends) specifying that the event occurrence at the tail end must occur before the event occurrence at the arrowhead end of the message.
Include
Include    
Include is a relationship that may exist between two use cases, a base use case and an addition use case. It means a base use case may insert behavior from an addition use case. The relationship is said to be unconditional in the sense that if the insertion occurs; all the behavior of the addition use case is unconditionally inserted.
Instantiate Dependency
Instantiate Dependency    
An instantiate dependency is a usage dependency that exists between classifiers and indicates that the client classifier (tail end) creates instances of the supplier (arrowhead end).
Interruptible Activity Region
Interruptible Activity Region    
An interruptible activity region is a type of activity group which provides a mechanism for destroying all tokens and terminating all behaviors in the section of the activity enclosed within the boundary of the region. An interruptible activity region can contain any number of nodes and flows. When a token is accepted by a special kind of edge called an interrupting flow (edge), which is designated by a lightning bolt, it leaves the region and all other tokens are destroyed and behaviors within the region are terminated.
Iterative Expansion Region
Iterative Expansion Region    
When the value of iterative is specified for the mode of an expansion region, execution within the region must occur in sequence. An expansion region is a type of activity group that contains one or more actions. These actions are executed multiple times depending on the number of elements in the input collection that arrive at one or more expansion nodes positioned on the edge of the region. The results of the actions may be placed in one or more expansion nodes acting as outputs.
Lifeline
Lifeline    
A lifeline represents the lifetime or existence of the participant located at the head of the dashed line. Regardless of whether a participant has an execution occurrence, if it has a lifeline then it has been created. Where the lifeline "disappears" beneath the execution occurrence it is assumed to continue to exist. If the participant is created or destroyed during the period of time represented by the diagram the lifeline will start or stop at the designated points.
Lifeline (Class Instance)
Lifeline (Class Instance)    
A lifeline represents the lifetime or existence of the participant located at the head of the dashed line. Regardless of whether a participant has an execution occurrence, if it has a lifeline then it has been created. Where the lifeline "disappears" beneath the execution occurrence it is assumed to continue to exist. If the participant is created or destroyed during the period of time represented by the diagram the lifeline will start or stop at the designated points.
Manifestation
Manifestation    
A manifestation is an abstraction dependency that describes the physical embodiment of a packageable model element in an artifact. An artifact can have any number of manifestations each of which is a dependency on a single model element.
Package Import
Package Import    
A package import is a directed relationship between a package (arrowhead end) and an importing namespace (tail end). The members of the referenced package can be used in the importing namespace without any qualification of the element name. A name can be added to the package import relationship, which is used as an alias (alternative name) for the elements in the importing namespace. The visibility of the elements in the importing namespace is by default public.
Package Import (Access)
Package Import (Access)    
A package import with the keyword access is a directed relationship between a package (arrowhead end) and an importing namespace (tail end). The members of the referenced package can be used in the importing namespace without any qualification of the element name. It is different from a package import with keyword import because it does not import the members of the other package into the namespace, but rather just allows them to be referenced. The visibility of the elements in the importing namespace is by default public.
Package Merge
Package Merge    
A package merge is a directed relationship between two packages that is used when elements of one package (tail end) represent the same concept as those in another package (arrowhead end). It is a convenient way of representing a set of generalizations and redefinitions between two packages. It is termed a merge because the relationship means that elements with the same name and of the same type from one or more packages will be merged into a single element in the merging package (tail end). This is achieved by the use of generalizations and redefinitions.
Parallel Expansion Region
Parallel Expansion Region    
When the value of parallel is specified for the mode of an expansion region, execution of the region can occur concurrently. An expansion region is a type of activity group that contains one or more actions. These actions are executed multiple times depending on the number of elements in the input collection that arrive at one or more expansion nodes positioned on the edge of the region. The results of the actions may be placed in one or more expansion nodes acting as outputs.
Permission
Permission    
A permission is a type of dependency and therefore a directed relationship between one or more clients (tail end) and one or more suppliers (arrowhead end). The relationship signifies that the elements at the tail end (client) require access to the elements at the arrowhead end (supplier) and that this access is granted (permitted). There are no standard stereotypes of a permission defined in the UML.
Realization
Realization    
A realize signifies that a relationship exists between a set of elements that form a specification (the client) and another set of elements that form the implementation (the supplier).
Refine Dependency
Refine Dependency    
A refine dependency is an abstraction dependency that implies that the client (tail end) is a refinement or more evolved element. This refinement may signify different version of the same element or extensions.
Region
Region    
A region is a part of a state machine or composite state. It contains (encloses) vertices and transitions. It can have one (and only one) initial pseudostate and any number of final states. A composite state with one region is called a non-orthogonal (simple) composite state and one with two or more regions is called an orthogonal state.
Reply Message
Reply Message    
A reply message denotes a return from a procedure call. This is an explicit representation of the return, which if it is not present, is implied in the synchronous message.
Reply Message (State)
Reply Message (State)    
A reply message (state) is a visual synonym of a reply message. It adds no additional semantics; it is simply an example of the reply message adapted for use on a timing diagram. This usage of the reply message has the same form as a reply message used on other interaction diagrams: a dashed line with an open arrowhead directed from one execution occurrence to another (possibly reflexive). It is listed separately because the message ends give it a different appearance from other examples. The reply represents an explicit representation of a return from a synchronous message. There is a single form of presentation in the three different types of interaction diagrams and the two different presentations of the timing diagram.
Reply Message (Value)
Reply Message (Value)    
A reply message (value) is a visual synonym of a reply message. It adds no additional semantics; it is simply an example of the reply message adapted for use on a timing diagram. This usage of the reply message has the same form as a reply message used on other interaction diagrams: a dashed line with an open arrowhead directed from one execution occurrence to another (possibly reflexive). It is listed separately because the message ends give it a different appearance from other examples. The reply represents an explicit representation of a return from a synchronous message. There is a single form of presentation in the three different types of interaction diagrams and the two different presentations of the timing diagram.
Send Dependency
Send Dependency    
A send dependency is a type of usage dependency that exists between an operation in a classifier and a signal. It signifies that the operation (tail end) can send the signal. (arrowhead end).
Stream Expansion Region
Stream Expansion Region    
When the value of stream is specified for the mode of an expansion region, the region executes a single time. An expansion region is a type of activity group that contains one or more actions. These actions are executed multiple times depending on the number of elements in the input collection that arrive at one or more expansion nodes positioned on the edge of the region. The results of the actions may be placed in one or more expansion nodes acting as outputs.
Trace Dependency
Trace Dependency    
A trace dependency is an abstraction dependency between a supplier and a client that indicates that one or more elements in one model represent an analogous concept in another model. Its meaning depends on the relationship between the models.
Usage
Usage    
A usage is a type of dependency and therefore a directed relationship between one or more clients (tail end) and one or more suppliers (arrowhead end). The elements at the tail end (clients) require the elements at the arrowhead end (supplier) in some way. This requirement may be that the elements need the other elements to be able to perform their function in a running system. It may also be an implementation dependency where only one set of elements exists in the running system and the other set were needed as part of the implementation. A usage can be used as an element in its own right, although it has a number of stereotypes that make its application more precise.
Unified Modeling Language and UML are either registered

trademarks or trademarks of Object Management Group, Inc. in the

United States and/or other countries.