A Director governs the execution within a CompositeActor. A composite actor
that contains a director is said to be <i>opaque</i>, and the execution model
within the composite actor is determined by the contained director. This
director is called the <i>local director</i> of a composite actor.
A composite actor is also aware of the director of its container,
which is referred to as its <i>executive director</i>.
A director may also be contained by a CompositeEntity that is not a
CompositeActor, in which case it acts like any other entity within
that composite.
<p>
A top-level composite actor is generally associated with a <i>manager</i>
as well as a local director. The Manager has overall responsibility for
executing the application, and is often associated with a GUI. Top-level
composite actors have no executive director and getExecutiveDirector() will
return null.
<p>
A local director is responsible for invoking the actors contained by the
composite. If there is no local director, then the executive director
is given the responsibility. The getDirector() method of CompositeActor,
therefore, returns the local director, if there is one, and otherwise
returns the executive director. Thus, it returns whichever director
is responsible for executing the contained actors, or null if there is none.
Whatever it returns is called simply the <i>director</i> (vs. local
director or executive director).
<p>
A director implements the action methods (preinitialize(),
initialize(), prefire(), fire(), postfire(), iterate(),
and wrapup()). In this base class, default implementations
are provided that may or may not be useful in specific domains. In general,
these methods will perform domain-dependent actions, and then call the
respective methods in all contained actors.
<p>
The director also provides methods to optimize the iteration portion of an
execution. This is done by setting the workspace to be read-only during
an iteration. In this base class, the default implementation results in
a read/write workspace. Derived classes (e.g. domain specific
directors) should override the _writeAccessRequired() method to report
that write access is not required. If none of the directors in a simulation
require write access, then it is safe to set the workspace to be read-only,
which will result in faster execution.
<p>
Mudit Goel, Edward A. Lee, Lukito Muliadi, Steve Neuendorffer, John Reekie
$Id: Director.java 70402 2014-10-23 00:52:20Z cxh $
Ptolemy II 0.2
Green (eal)
Yellow (neuendor)
The local time of model when this director is initialized.
By default, this is blank, which
indicates that the start time is the current time of the enclosing
director when initialize() is invoked, or 0.0 if there is no
enclosing director. This can be set to a double value to explicitly
specify a start time.
Note that if <i>startTime</i> is given a value
that is different from the start time of the enclosing
director, then local time may be ahead of or behind
environment time during execution.
Also note that some directors do not advance time (including
PN and Rendezvous, for example), in which case, local time remains
at the start time value throughout the execution.
The stop time of the model. By default, this is blank, which
means that no stop time is specified. If a stop time is specified,
it must be a double, and when local time meets or exceeds the
stop time, then <a href="../../ptolemy/actor/Director.html#postfire">postfire()</a> returns false.