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
Activity
Activity    
An activity is a classifier that describes a set of nodes and flows that specify a coordinated behavior made up of subordinate behaviors called actions. The nodes can be actions that are the atomic executable units of behavior, control nodes that coordinate flows or object nodes that can store objects or data. The flows (edges) can be control flows that carry control tokens or object flows, which carry object (data) tokens. An activity can participate in generalization relationships with other activities, and can also have sub activities that form a hierarchy. Activities are based on token flow where the execution of one node results in token flows that ultimately affect other nodes.
Action
Action    
An action is an executable activity node. It is the atomic unit of processing or behavior specification in an activity. An action may receive inputs in the form of control flows and object flows (the latter via input pins) and passes the results of its processing or transformations to one or more outgoing control flows or object flows (the latter via output pins) and onto downstream nodes. Execution of the action cannot begin until all its prerequisites are satisfied. Typically this means that all incoming control flows have control tokens and all input pins have object tokens.
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.
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.
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.
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.
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.
Object Flow
Object Flow    
An object flow is one of two types of activity edges, which are directed connection (flows) between activity nodes, the other being a control flow. As soon as the activity node at the source (tail) end of the flow is finished it presents tokens to the object flow at the target (arrowhead) end of the flow. An object flow can only carry object (data) tokens; it cannot carry control tokens. There are rules that specify whether tokens can flow along the object flow and these are determined by the type of activity node at the source and target of the flow. In the case of complete activities an object flow may define a weight, which specifies the minimum number of tokens that must flow along the object flow as a group.
Input Pin
Input Pin    
An input pin is a type of object node, that gives the node the capability of storing (buffering) tokens. Input pins are owned by actions and tokens may accumulate at an input pin waiting to be consumed by the action. Input pins only have incoming flows all of which must be object flows, and they provide values to the actions that consume the tokens.
Output Pin
Output Pin    
An output pin is a type of object node, which gives the node the capability of storing (buffering) tokens. Tokens produced by actions may accumulate at output pins before being passed onto other downstream object nodes via object flows. Output pins have only incoming flows all of which must be object flows. They receive tokens produced by the actions.
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.
Interrupting Edge
Interrupting Edge    
An interrupting edge is a type of activity edge drawn as a lighting bolt. It connects a node inside a region to a node outside the region in the same activity. When a token leaves a region via an interrupting edge all other tokens in the region are consumed and all behaviors in the region are halted.
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.
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.
Central Buffer
Central Buffer    
A central buffer is a type of object node, which gives the node the capability of storing (buffering) tokens. It manages the tokens that arrive at incoming flows (edges) from one or more object nodes and selects which tokens and in what order these tokens will be presented to the downstream object nodes via the outgoing flows (edges).
Data Store
Data Store    
A data store node is a type of central buffer node and can therefore store (buffer) tokens. It adds the additional mechanism to keep a copy of the tokens even when they are passed out of the node via an outgoing object flow. Whenever an incoming token contains an object or piece of data that already exists in the data store the incoming token replaces the existing one.
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.
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.
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.
Expansion Node
Expansion Node    
An expansion node is a type of object node. They are used exclusively with expansion regions. An object flow that arrives at an expansion node contains a collection of objects or data, which are separated by the expansion node before being passed onto elements within the region. A region must have one or more expansion nodes receiving input and may have any number of expansion nodes as output including the case of having no output expansion node.
Generalization
Generalization    
Generalization is a relationship of classification between a more general element (parent) and a more specific element (child). The head of the arrow is attached to the "parent" and the tail is attached to the "child". It is a taxonomic relationship that can exist between a number of types of UML elements including classifiers and associations.
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.
Unified Modeling Language and UML are either registered

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

United States and/or other countries.