Zicomi Systems Logo
contact us  |  your privacy
Company
Services
Products
Support
Resources
  OMG Standards
OMG Logo
  Have You Heard?
UML Diagrams
Zicomi Systems publishes some UML example diagrams online from the world famous UML dictionary.
more...
Version 2.5 Released
Zicomi Systems is delighted to announce that version 2.5 of Zicomi Mentor is released. With support for UML 2.0 and all thirteen UML diagrams
more...
Zicomi Systems' Director
speaks about the UML at Objects by Design - an informative interview
more...
Partner Programme
Zicom Systems is delighted to announce a new world wide partner programme, become a partner today.
more...
OMG Member
Zicom Systems is made a member of the OMG!
UML Element Description
Interaction Occurrence
Interaction Occurrence    
An interaction occurrence stands in the place of an interaction or portion of an interaction. An interaction occurrence is a diagrammatic device for reusing or copying the contents of an interaction to another diagram.
Diagram
Diagram    
A diagram is a graphical device for representing a part of a UML model. A model is typically comprised of a number of diverse elements that are vertices connected by edges in a graph representing the semantic and structural elements of the model. A UML diagram will typically display a subset of the model and will commonly consist of a number of elements that have structural or behavioral significance when viewed together. A diagram has a frame that acts as a boundary to separate its contents-area from other diagrams and a heading which contains a string that lists the kind of diagram, its name and parameters of the namespace.
Control Flow
Control Flow    
A control flow is a directed connection (flow) between two activity nodes. As soon as the activity node at the source (tail) end of the flow is finished it presents tokens to the control flow at the target (arrowhead) end of the flow. A control flow can only carry control tokens; it cannot carry object (data) tokens. There are rules that determine whether tokens can flow along the control flow and these are determined by the type of activity nodes at the source and target of the flow. In the case of complete activities a control flow may define a weight, which specifies the minimum number of tokens that must flow along the control flow as a group.
Initial Node
Initial Node    
An initial node is a type of control node which initiates flow in an invoked activity. It has no incoming flows and one or more outgoing flows. The outgoing flows may be guarded with conditions that determine if they will accept tokens. When an activity is invoked tokens are offered to all outgoing flows. There may be zero or more initial nodes in any activity. While other control nodes cannot detain tokens an initial node can retain a token if the guard on an outgoing flow prevents a token from being accepted when the activity starts.
Activity Final Node
Activity Final Node    
An activity final node is a type of final node that stops an activity. When a token arrives at an activity final node all flows in the enclosing activity are stopped and the activity is terminated. The token arriving at the activity final node is itself destroyed. Any tokens that are offered on the incoming edges of the activity are accepted and object nodes declared as outputs are offered to the output edges of the enclosing activity.
Flow Final Node
Flow Final Node    
A flow final is a type of final node that consumes the incoming token. When a token arrives at a flow final the token is consumed. No other part of the enclosing activity is affected. Since there are no outgoing flows from a flow final node the effect is simply to remove tokens from the activity.
Decision Node
Decision Node    
A decision node is a control node that has one incoming flow and two or more outgoing flows. When a token arrives at a decision node it is offered to all the outgoing flows, one (and only one) of which accepts the token. Tokens cannot be detained at the node, nor are they copied; they are passed onto an outgoing flow. The guards (conditions) on the outgoing flows determine which flow will accept the token. The incoming flow and all outgoing flows must be either all control flows or all object flows.
Merge Node
Merge Node    
A merge node is a type of control node that has two or more incoming flows and a single outgoing flow. It is used to re-unite alternate flows that originate from one or more decision nodes. The merge node accepts a token on any one (and only one) of the incoming flows and passes it to the single outgoing flow. Tokens cannot be detained at the node, nor are they copied; they are passed onto a single outgoing flow.
Fork Node
Fork Node    
A fork node is a control node that has a single incoming flow and two or more outgoing flows. Incoming tokens are offered to all outgoing flows (edges). The outgoing flows can be guarded which gives them a mechanism to accept or reject a token. If the token is accepted by an outgoing edge it is duplicated so as to create a copied token for each outgoing flow that has accepted the token. The incoming flow and all outgoing flows must be either all control flows or all object flows. Tokens cannot be detained at the node; the token copying is effectively instantaneous.
Fork Node
Fork Node    
A fork node can be orientated horizontally or vertically. Both orientations have exactly the same semantics the difference is simply that when flows are parallel to the x-axis a vertically orientated fork node is required, whereas when flows are parallel to the y-axis a horizontally orientated fork is required.
Join Node
Join Node    
A join node is a type of control node that synchronizes a number of incoming flows into a single outgoing flow. Each (and every) incoming control flow must present a control token to the join node before the node can offer a single token to the outgoing flow. If some of the incoming flows are object flows, which carry object (data) tokens, these tokens are all offered to the outgoing flow. A join specification (for complete activities) may be used, which further governs the way that the join will evaluate the arrival of tokens.
Join Node
Join Node    
A join node can be orientated horizontally or vertically. Both orientations have exactly the same semantics; the difference is simply that when flows are parallel to the x-axis a vertically orientated join node is required, whereas when flows are parallel to the y-axis a horizontally orientated join node is required.
Activity Partition
Activity Partition    
An activity partition is a type of activity group that specifies that a number of elements in an activity have something in common. Partitions may be oriented horizontally or vertically, and except in the case that a partition is a dimension can contain other partitions down to any level of nesting. Partitions have no effect on the execution of an activity or the nodes and edges contained within it.
Swimlanes
Swimlanes    
Swimlanes divide or partition activity diagrams into a number of "lanes", which typically organize the diagram into a number of regions of responsibility. Each lane may have a name, which signifies the responsibility or governance of the elements that lie within it.
Comment (Note)
Comment (Note)    
A comment can contain textual information or graphical symbols that add additional information to a diagram or model. The information can take many forms from very formal, in the case of constraints, to conversational, in the case of working notes. Comments can be placed anywhere in a model or diagram, and simply by their proximity and alignment; they can be applicable to one or more elements. They may also be attached either to one or more elements by a comment attaching line.
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.
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.
Exception Edge
Exception Edge    
An exception edge is a type of activity edge drawn as a lighting bolt. It connects the executable node that is being protected by an exception handler to an exception input node on the border of the exception handler.
Exception Handler
Exception Handler    
An exception handler is an element that allows an action (protected node) to be protected by specifying an alternate action to execute when a certain condition or event occurs in the execution of the protected node. The alternate action called the handler has an input pin, which specifies the type of the exception. The handler will only be invoked if the type of the exception is the same or a child of the type specified by the handler.
Continuation
Continuation    
A continuation is an interaction fragment that is used with alternative and weak sequencing combined fragments. It is a device that expresses the continuation of the different branches of the enclosing combined fragment.
Unified Modeling Language and UML are either registered

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

United States and/or other countries.