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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Multiplicity
Multiplicity    
multiplicity is a property of an association end that specifies the number of instances of the classifier connected at the target end (near end) that can be associated with a single instance of the classifier at the source end (far end). It is specified in the form of a string stipulating a possible infinite number governed by a lower and upper bound.
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.
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.
Class
Class    
A class represents some concept, physical or otherwise, in the system being modeled. Classes describe sets of things or concepts that have similar attributes, behavior and relationships. They are a higher order concept to objects, which represent instances of the class.
Package
Package    
A package is a grouping of model elements. Packages group any set of zero or more model elements, including packages themselves, with the condition that no model element exists in more than one package. The package also defines the extent of names.
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.
Artifact (Keyword Presentation)
Artifact (Keyword Presentation)    
An artifact (keyword presentation) is a visual synonym of an artifact. It adds no additional semantics; it is simply an alternative presentation of the element. The standard form of this element is considered to be the artifact displayed with a small icon in the top left hand corner of a classifier rectangle.
Unified Modeling Language and UML are either registered

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

United States and/or other countries.