swarm.objectbase.sgml.reference.html

set for Swarm2.1是圣菲研究院的开发人员对Swarm的特性及其使用描述的最为完备的指南性文档。从这里可以获得最细致的平台说明。

></H2
><P
> It is completely reasonable to assume that explicit
        control can be had over all the activities in a simulation.
        However, at present, this control is limited because the
        context in which an activity runs determines how it behaves.
        To understand how an <I
CLASS="EMPHASIS"
>ActivityControl</I
> is
        to be used, we will have to explore the behavior of activities
        in context.  (For a more complete explanation of the behavior
        of activities, see the <I
CLASS="EMPHASIS"
><A
HREF="swarm.activity.sgml.reference.html"
>activity
        library</A
></I
> documentation.)
      </P
><P
>There are two ways to get an activity started, one can
        activate the activity in <TT
CLASS="LITERAL"
>nil</TT
> or in some
        other activity.  So called "top-level" activities are
        activated in <TT
CLASS="LITERAL"
>nil</TT
> and are intended to be
        independent of the sophisticated scheduling activity that
        dictates the execution of actions in any other context in the
        simulation.  I.e. the only activities that should be activated
        in <TT
CLASS="LITERAL"
>nil</TT
> are those sets of events that are
        expected to preserve the same behavior no matter what goes on
        in any other part of the simulation.
      </P
><P
>The other type of activity, those activated in some other
        activity, is intended to be an integral part of its owner
        activity.  However, this doesn't mean that it
        <I
CLASS="EMPHASIS"
>must</I
> depend on the outcome of actions
        happening in the owner activity.  In fact, an
        <I
CLASS="EMPHASIS"
>ActionPlan</I
> can be designated as
        containing actions that are capable of being processed in
        parallel, via code like the following:


<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>[anActionPlan setDefaultOrder: Concurrent];</PRE
></TD
></TR
></TABLE
>

        But these activities are <I
CLASS="EMPHASIS"
>still</I
> intended to be
        meshed with their owner activities.  In other words, they are
        part and parcel of the same model or simulation.</P
><P
>Now, the operational effect of activating an activity in
        <TT
CLASS="LITERAL"
>nil</TT
> is that it will not be meshed with the
        rest of the Swarm activity structure.  This gives the user (or
        process) complete control over the execution of that activity.
        A <TT
CLASS="LITERAL"
>run</TT
> on that activity will run either to
        completion or until a stop flag is set by a sequence of events
        purely internal to that activity.  Or, one can stop it from
        the outside with a message from something like an
        <I
CLASS="EMPHASIS"
>ActivityControl</I
>.
      </P
><P
>What all this means is that, while one can attach an
        <I
CLASS="EMPHASIS"
>ActivityControl</I
> to <I
CLASS="EMPHASIS"
>any</I
>
        activity, only the "top-level" activities (those having been
        activated in <TT
CLASS="LITERAL"
>nil</TT
>) are going to respond well
        to it.  Any sub-activity will respond half-heartedly, if at
        all.  For example, in the <I
CLASS="EMPHASIS"
>Mousetrap</I
> demo
        distributed with Swarm, an
        <I
CLASS="EMPHASIS"
>ActivityControl</I
> has been placed on both
        the <I
CLASS="EMPHASIS"
>ObserverSwarm</I
> and the
        <I
CLASS="EMPHASIS"
>ModelSwarm</I
> activities.  Now, if one sends
        a <TT
CLASS="LITERAL"
>run</TT
> message to the
        <I
CLASS="EMPHASIS"
>ActivityControl</I
> that is attached to the
        <TT
CLASS="LITERAL"
>observerSwarm</TT
>'s activity, the entire model
        continues to run to completion, unless the user sends a
        <TT
CLASS="LITERAL"
>stop</TT
> message.  However, if the sim is
        stopped at some point, a <TT
CLASS="LITERAL"
>run</TT
> message to the
        <TT
CLASS="LITERAL"
>modelSwarm</TT
>'s activity will have no effect
        at all.  (<I
CLASS="EMPHASIS"
>Note:</I
> If you do this via the
        activity controllers, you see the
        <TT
CLASS="LITERAL"
>currentTime</TT
> variable get updated; but, the
        actual <TT
CLASS="LITERAL"
>run</TT
> message to the activity, itself,
        has no effect.)
      </P
><P
>So, the rule of thumb, for the present, is to attach
        <I
CLASS="EMPHASIS"
>ActivityControl</I
> objects only to
        "top-level" activities, like the
        <I
CLASS="EMPHASIS"
>ObserverSwarm</I
>.
      </P
></DIV
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="SWARM.OBJECTBASE.SGML.SECT1.SUBCLASS"
>5. Subclassing Reference</A
></H1
><P
>The main classes defined here that are intended to be
      subclassed by users are Swarm and SwarmObject. The probing
      functionality provided here is mainly for use within the
      <I
CLASS="EMPHASIS"
>Swarm</I
> kernel. However, this probe machinery
      should be used when designing any interface between
      <I
CLASS="EMPHASIS"
>Swarm</I
> and any other agent or
      device. </P
><DIV
CLASS="FORMALPARA"
><P
><B
>SwarmObject. </B
><I
CLASS="EMPHASIS"
>SwarmObject</I
> is the base class for all
      interactive agents in <I
CLASS="EMPHASIS"
>Swarm</I
>.  It defines
      the standard behavior for Swarmstyle agents, which includes
      hooks for creation, probing, zoned memory allocation, and
      destruction.</P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Swarm. </B
>The <I
CLASS="EMPHASIS"
>Swarm</I
> class encapsulates all of
      the abstract execution machinery in the
      <I
CLASS="EMPHASIS"
>activity</I
> library, as well as the notion of
      a group of related objects. Metaphorically, a "Swarm" is a
      combination of a collection of objects and a schedule of
      activity over those objects. Hence, the
      <I
CLASS="EMPHASIS"
>Swarm</I
> class provides the behavior necessary
      for creating such an object and starting up the schedule.</P
></DIV
><P
>Further details on subclassing are also described in the
      <A
HREF="swarm.objectbase.sgml.reference.html#SWARM.OBJECTBASE.SGML.SECT1.USAGE"
>Usage
      Guide</A
></P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="SWARM.OBJECTBASE.SGML.SECT1.DESIGN"
>6. Interface Design Notes</A
></H1
><P
>Unfortunately, this interface has not undergone a rigorous
      design review.  As such it is subject to change in the future.
      However, there are rumours that this library will be integrated
      into the <I
CLASS="EMPHASIS"
><A
HREF="swarm.defobj.sgml.reference.html"
>defobj
      library</A
></I
> anyway.  So, even though little
      thought was given to the design of this interface (and it is not
      likely to be worthwhile designing a robust interface at this
      time), it was implemented in order to provide a first step
      towards bringing all the various libraries in line with the
      standard set by <I
CLASS="EMPHASIS"
>defobj</I
>.</P
><P
>Along these lines, a few notes are relevant.
    
      <P
></P
><OL
TYPE="1"
><LI
><P
><I
CLASS="EMPHASIS"
>Probe</I
>s may become an inherent
          part of any object.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>ActivityControl</I
>s will become a
            part of a larger set of tools used for debugging Swarm
            models. </P
></LI
></OL
>
    </P
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="SWARM.OBJECTBASE.SGML.SECT1.IMPL"
>7. Implementation Notes</A
></H1
><P
></P
><OL
TYPE="1"
><LI
><P
>Right now, <I
CLASS="EMPHASIS"
>Probe</I
>'s rely on a
          special method, <TT
CLASS="LITERAL"
>getInstanceName</TT
>, that has
          to be implemented in any probe-able object in order to get
          anything other than the class name of that object into the
          object designation widget.  However, a more general
          capability has been added to <I
CLASS="EMPHASIS"
>defobj</I
> to
          give a meaningful name to any object.
          <I
CLASS="EMPHASIS"
>Probe</I
>s will be changed to take
          advantage of this new capability.
        </P
></LI
><LI
><P
>In the <I
CLASS="EMPHASIS"
>ActivityControl</I
> the
          frequency of the message <TT
CLASS="LITERAL"
>updateStateVar</TT
>
          is very high.  It is sent at least once every cycle and
          <I
CLASS="EMPHASIS"
>every</I
> time a message is sent to the
          <I
CLASS="EMPHASIS"
>ActivityControl</I
>.  This is
          unsatisfactory.  Some of these messages can be pruned out of
          the object.</P
></LI
><LI
><P
>The <TT
CLASS="LITERAL"
>probeMap</TT
> designed for use with an
          <I
CLASS="EMPHASIS"
>ActivityControl</I
> was chosen fairly
          arbitrarily.  Right now, it serves as a default for the
          class.  A user can override it by designing a new one and
          inserting it into the <TT
CLASS="LITERAL"
>probeLibrary</TT
>.
          </P
></LI
><LI
><P
>Errors specific to objects in the
          <I
CLASS="EMPHASIS"
>objectbase</I
> library need to be gathered
          and initialized like those in the
          <I
CLASS="EMPHASIS"
>defobj</I
> library.</P
></LI
></OL
></DIV
></DIV
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
><A
HREF="swarm.objectbase.activitycontrol.protocol.html"
>ActivityControl</A
> &#8212;  A class that provides an object interface to an activity.</DT
><DT
><A
HREF="swarm.objectbase.completeprobemap.protocol.html"
>CompleteProbeMap</A
> &#8212;  A subclass of ProbeMap whose initial state contains the VarProbes and MessageProbes of the requested target class but also those of all its subclasses.</DT
><DT
><A
HREF="swarm.objectbase.completevarmap.protocol.html"
>CompleteVarMap</A
> &#8212;  A subclass of ProbeMap, whose initial state contains no MessageProbes.</DT
><DT
><A
HREF="swarm.objectbase.customprobemap.protocol.html"
>CustomProbeMap</A
> &#8212;  A subclass of ProbeMap, whose initial state is empty unlike the default probeMap initial state which contains all the VarProbes of the requested target class.</DT
><DT
><A
HREF="swarm.objectbase.defaultprobemap.protocol.html"
>DefaultProbeMap</A
> &#8212;  A subclass of ProbeMap, whose initial state contains all the VarProbes  of the requested target class and also those of all its superclasses.</DT
><DT
><A
HREF="swarm.objectbase.emptyprobemap.protocol.html"
>EmptyProbeMap</A
> &#8212;  A CustomProbeMap to be used for building up ProbeMaps from scratch.</DT
><DT
><A
HREF="swarm.objectbase.messageprobe.protocol.html"
>MessageProbe</A
> &#8212;  A class that allows the user to call a given message on any candidate that is an instance of, or inherits from, a given class.</DT
><DT
><A
HREF="swarm.objectbase.probe.protocol.html"
>Probe</A
> &#8212;  An abstract superclass of both VarProbe and MessageProbe.</DT
><DT
><A
HREF="swarm.objectbase.probeconfig.protocol.html"
>ProbeConfig</A
> &#8212;  Protocol for configuration of Probes, ProbeMaps, and the ProbeLibrary.</DT
><DT
><A
HREF="swarm.objectbase.probelibrary.protocol.html"
>ProbeLibrary</A
> &#8212;  A (singleton) Class, whose instance is used as a container for a global mapping between classnames and their 'default' ProbeMaps. These defaults can be changed by the user, thus allowing him/her to customize the default contents of the ProbeDisplays generated when probing objects.</DT
><DT
><A
HREF="swarm.objectbase.probemap.protocol.html"
>ProbeMap</A
> &#8212;  A container class for Probes used to specify the contents of a  ProbeDisplay.</DT
><DT
><A
HREF="swarm.objectbase.swarm.protocol.html"
>Swarm</A
> &#8212;  A temporal container.</DT
><DT
><A
HREF="swarm.objectbase.swarmobject.protocol.html"
>SwarmObject</A
> &#8212;  A superclass of most objects in a Swarm simulation that provides support for probing.</DT
><DT
><A
HREF="swarm.objectbase.varprobe.protocol.html"
>VarProbe</A
> &#8212;  A class that allows the user to inspect a given variable in any candidate that is an instance of, or inherits from, a given class.</DT
><DT
><A
HREF="swarm.objectbase.generic.module.html"
>General</A
> &#8212;  Support for Swarm objects and probing</DT
></DL
></DIV
></DIV
><DIV
CLASS="TITLEPAGE"
><DIV
CLASS="ABSTRACT"
><P
><B
>Documentation and Implementation Status</B
></P
><P
></P
></DIV
><A
HREF="swarm.objectbase.generic.revhistory.html"
>Revision History (objectbase)</A
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="swarm.activity.generic.module.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="set.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="swarm.objectbase.activitycontrol.protocol.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>General</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book930.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>ActivityControl</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>