What is a Control Token?

[Bill Egge]

Can someone tell me what a control token is and maybe an example of a control flow having more than 1 control token?  :-?

[Paul Lotz]

Can someone tell me what a control token is and maybe an example of a control flow having more than 1 control token?  :-?

Hmm...  Well, in an activity diagram that shows control flow (vs. object flow) at the UML model level flow occurs by means of control tokens.  I guess you can look at it as if a node can only execute once it possesses the appropriate control token(s).  The tokens flow between the different nodes on the diagram.

There will be multiple control tokens in a flow that has fork and join nodes.

Paul

[Bill Egge]

I am not seeing "what" a control token is.  For instance if I make an activity diagram of making coffee - Add Hot Water > Add Instant Coffee > Add Sugar > Mix with Spoon.  What are the Control Tokens?

[Paul Lotz]

From the UML 2.1 superstructure specification: "The semantics of activities is based on token flow. By flow, we mean that the execution of one node affects, and is
affected by, the execution of other nodes, and such dependencies are represented by edges in the activity diagram. A token
contains an object, datum, or locus of control, and is present in the activity diagram at a particular node. Each token is
distinct from any other, even if it contains the same value as another. A node may begin execution when specified
conditions on its input tokens are satisfied; the conditions depend on the kind of node. When a node begins execution,
tokens are accepted from some or all of its input edges and a token is placed on the node. When a node completes
execution, a token is removed from the node and tokens are offered to some or all of its output edges. See later in this sub
clause for more about how tokens are managed."

You might also see:
http://www.jot.fm/issues/issue_2003_11/column1/
http://hegdeprashanth.wordpress.com/2007/06/23/uml-activity-diagrams-101/
http://www.disi.unige.it/person/ReggioG/ISII04WWW/ActivityDiagrams.ppt#326,4,Some definitions

I think of it a control token (technically, there are multiple tokens that are created and destroyed) as something one node passes to another  (like a "hot potato" in the game).  Whichever node has the control token is active.  I can think of it as a kind of an abstract "thing"but maybe think of it as a control "object."  This makes sense to me in an analogous sense because I do dataflow programming.

In any case, you don't really need to understand control tokens per se to understand activity diagrams at the design level.  You do have to understand how control flows in the diagram from node to node.

The details of how tokens work are available in the UML 2.1.2 superstructure specification....

Paul

[Bill Egge]

Thank you, can I ask where you got the link to the UML specs?  I went to the OMG website but was unable to find it.

[Paul Lotz]

http://www.omg.org/technology/documents/spec_summary.htm

[jeshaw2]

I am not seeing "what" a control token is.  For instance if I make an activity diagram of making coffee - Add Hot Water > Add Instant Coffee > Add Sugar > Mix with Spoon.  What are the Control Tokens?

Your activities are add Hot Water, add Instant Coffee, add Sugar, and Mix with spoon.  

The object that flows from activity to activity is the unreferenced composite object cup-o-coffee that is being constructed (instantiated).  The control flow is the ordering of the activities.

Activity diagrams are based on Petri Net logic, not on flow chart logic.  Petri Nets use Control Tokens for managing the firing order of activities.  Start your Petri Net learnings HERE.

Jim

[Bill Egge]

It appears to be a nueron (http://en.wikipedia.org/wiki/Neuron).  Electric current to nuerons are the Control Tokens.

In my opinion, this (A Petri Net) is a design pattern and a single design pattern should not be used to model ALL activities and therefore UML should not use Petri Nets for Activity Diagrams.  :-/

[jeshaw2]

 :-?With all due respect, I disagree.  

• Your neurons are more analogous to the control flow path than to the token that may move along it.  Tokens are more like the conch shell in the book Lord of the Flies  At their evening meetings, the conch is passed from person to person; only the one holding the conch has permission to speak.  IBM's Token Ring networking is based on this concept also.
• Petri Nets are no more like a design pattern than is a flowchart.  
• In order to fire, an activity must have received a token on all of the control flows into it.
• The OMG/UML 2.x Specification documents specifically states that Activity Diagrams are based upon the Petri Net concepts.

[Bill Egge]

But the concept of a control token only applies to certain designs, in my cupofcoffee example there are no tokens.  It is possible to build cupofcoffee with Control Tokens but not nessesary, the use is a design decision but the idea of a control token is not inherent in an activity.  For this reason, a PetriNet is mearly a design pattern.

[KP]

But the concept of a control token only applies to certain designs, in my cupofcoffee example there are no tokens.  It is possible to build cupofcoffee with Control Tokens but not nessesary, the use is a design decision but the idea of a control token is not inherent in an activity.

Control tokens are imaginary. They exist only in the mind of the person reading your activity diagram, as an aid to understanding. You can choose not to consider them when creating your design, but because UML activity diagrams follow the control token model, you risk not knowing how your own design will be understood by other people.

For this reason, a PetriNet is mearly a design pattern.

I would call it a mathematical notation. A design pattern is something else entirely.

[sargasso]

Control tokens are imaginary.

YEEEEAARRRGH!


They are the basis upon which most of the activity model "theory" depends.  If what's-his-name was still around ....


Rule 1:  a node can ... and only one  ... oh whats the use

[«Midnight»]

Me too bruce.

I thought about stepping in, but I just don't have the energy anymore.

[KP]

Control tokens are imaginary.

YEEEEAARRRGH!

From the point of view of the person trying to understand an activity diagram, they are not visible, they are not part of the model, they are not part of the UML notation, you have to visualize them. Tell me four words that sum that up better than the four I used.

[jeshaw2]

I think of Control Tokens as abstractions that may, depending on the technology platform at hand, be implemented in a variety of ways.