The semantics of UML2 Activity Charts is very loosely based on the token flow semantics of the well-known Petri Nets. Tokens – drawn on this site by green circles – tell where current locus of control reside. There can be many tokens active in one activity in parallel, meaning that behavior is concurrently executing.

According to the current UML2 specification [UML04], there are different steps when executing an action:

	Enabled If an execution of an action is enabled, it means that the action has been called and is currently running. Note, that we only show CallBehaviorActions here for illustration; other kinds of actions (AcceptEventAction, SendSignalAction, …) which have other symbols behave the same way!
	Terminated After an action has finished executing, it is terminated.
	CreateExecution For an action that is about to start (“Action B” in the figure on the left), is in a state called create execution. The next state for this action will be the before mentioned enabled step.

Tokens never rest at Control Nodes (like Decision, Merge, Fork, Join), except Intial Nodes. Transitions only occur between Actions (CallBehaviorAction, AcceptEventAction, SendSignalAction, …) and are always atomic.

If tokens appear to be on wrong positions during simulation you have to adjust the token positions on the shapes manually. All actions and edges have position markers for tokens:

Activity edges for example have markers for “upper” and “lower” token positions. After adjusting, you have to re-import your diagrams to reflect the new configuration.

Timers (more precisely: UML2 AcceptEventActions with a TimeTrigger) are used to suspend token flow for a specific amount of time. The following figure shows some examples of Timers:

Differences are made between relative and absolute times. The first four examples show relative time specifications: when a token reaches the timer, it waits for the time to elapse, e.g. 1 minute and 59 seconds (“1m 59s”-caption). The example on the right (“2:25:44 PM”) depicts an absolute time: when a token arrives, it waits for the clock showing “2:25:44 PM” and then continues flowing. The following table shows the abbreviations that can be used for timers in ActiveCharts .

Activities describe behavior for UML classes. Therefore, each activity has to be associated with its corresponding class – named “context class” – which is achieved using a special UML tag [UML04], which is a well-known extension mechanism of the UML. The folloing figure shows such a link. Below the name of the class, the tag “{behavior=<name of activity>}” is found. Furthermore, the “Siren”-class is marked “active” in Visio 2003 by using its popup menu. This further indicates that this is a behavioral class.

The class generator notices those specifications and generates special code to import the activity diagrams from the XML representation automatically. Additionally, a “StartBehavior()” method is generated for each active class, which a developer can call in his project to initiate the behavior associated with that class. This is normally not necessary since a behavior is started automatically upon creating an instance of a class. An optional UML tag called “{autostart=false}” can be used in the class to disable automatic starting of the behavior (see the following figure). In that case, an additional call of the “StartBehavior()”-method must be made to initiate the activity.