The following is the first in a continuing series of reports on important aspects of Metascape LLC and related technologies. A formatted PDF version is available at: http://metascapeabm.com/images/news/tr1-metaabminpictures.pdf
Introduction
This report provides a diagrammatic overview of the metaABM system. metaABM is designed to be a general representation or “meta-model” for Agent-Based Models. Models can be fully defined within the metaABM lingua franca and model implementations can then be generated from those models with no further coding or configuration. The metaABM system as whole currently provides a hierarchical visual editor and reference implementations targeting the Ascape and Repast Simphony platforms. metaABM is built upon the Eclipse Modeling Framework using the OpenArchitectureWare toolset. The metaABM system is fully integrated with the Eclipse IDE platform, but metaABM models themselves need have no dependencies on any particular technology beyond XML/XSD.
We do not imagine that the meta-model covers every possible model instance, or that we have not overlooked important issues. But if nothing else we hope that this model serves as a useful “straw-agent” that the community can use to refine and explore key representational issues.
A note to non coders: In this report, we describe the metaABM system using UML style diagrams. Diagrams can cause instance eye-droop, but when depicting complex software interactions, pictures are worth more than a thousand words -- they are almost indispensable. Regardless of your level of familiarity with this approach, time spent understanding the following diagrams will help considerably in understanding the overall vision of the metaABM representation.
A note to coders: On the other hand, when viewing these diagrams, it is important to toss out your conception of a typical UML Object Diagram. These diagrams do not represent objects, they represent meta-objects. So when we talk about an instance of SAgent, we are not talking about some particular agent, say a Sugarscape agent on some landscape. Instead an instance of SAgent represents an agent description for an entire type of agent. In that sense an SAgent is analogous to -- for example -- a SugarAgent Java class description, but more abstracted, implementation and language neutral, and focussed on the Agent-Based Modeling paradigm.
Our first diagram depicts the core of the metaABM system. Core interactions are in Red. Every metaABM model has at its root an SContext.*1 SContexts instances represent types of agents that are capable of containing other SAgents (including other contexts, naturally). At runtime, instances of SContext instances (got that?) contain agent instances each corresponding to one of the contained SAgent instances.
This sounds more complicated than it is, so perhaps an example will help explain the flavor, after which we will simply discuss important aspects of the metaABM model which may not be apparant from the general model. Suppose we create a new SContext, and give it a label of “Sugarscape Model”.*2 Within that SContext, we create an SAgent and give it a label of “SugarAgent” and another SAgent with the label “SugarCell”. (For those unfamiliar with UML notation, we know that SContexts are sub-types of SAgent because there is an open arrow from SContext to SAgent, and we know that SAgents can have a label because they are sub-types of SImplementated, which are sub-types of IID -- almost every object in metaABM has identifiers -- and IID has an attribute of “label”.) At runtime (when we are actually executing the model, and ignoring setting up projections and initializers), we will have one Sugarscape model which contains a number of SugarAgents along with a set of SugarCells arranged in a grid structure. We can add an SAttribute to our “SugarAgent” SAgent, and give it a label of say “Wealth”, with a type of “Real”. (We know that SAgents can have SAttributes because they are a sub-type of SActables, which are a sub-type of SAttributed. SAttrributed has a line leading to SAttribute and that line has a a solid diamond at one end and a “0..*” label at the other, telling us that each SAgent can include any number of attributes. *3
SContexts may have SProjections, which represent some kind of spatial or structural interaction space for the agents; either a grid, a continuous (euclidian) space, or a network or GIS space of some kind. (GIS is currently only supported as a notional construct and has no target platform implementation.) In addition to SAttributes, agents are SActables can have any number of behaviors, called “Acts”, described in the next diagram. *4 SStyles provide a mechanism for defining generic visualization behavior for Agents and so are also SActables. For example, an SAgent might have an Act that says effectively “draw a red circle shaded red for the wealth of the agent”.
- 1. See Howe, et. al.CONTAINING AGENTS: CONTEXTS, PROJECTIONS, AND AGENTS http://www.agent2006.anl.gov/2006procpdf/Howe_Agent_2006.pdf
- 2. See the classic Epstein and Axtell Sugarscape model, http://www.brookings.edu/press/Books/1996/artifsoc.aspx
- 3. Hopefully, if you are not familiar with UML you have a better sense of how useful it can be for depicting such relationships. There are a number of good resources on the web; googling “UML” should provide a good starting point.
- 4. Here Acts are instances of IAct, which is an interface to avoid a circular reference between the base and act packages.
Acts are a key aspect of the metaABM representational scheme, as they allow the definition of arbitrary but high level behavior for agents. They are also conceptually more challenging as unlike the metaABM structure they have no direct analogies to past agent representation approaches. But a few basic ideas should clarify matters.
- All of the above meta-objects except AInput, ALiteral, and the enumerators (lists of options) are Acts. Blue Acts are concrete (you can create and use them directly). Red indicates a key meta-object collaboration.
- An Act is anything that might happen during the execution of an Agent-Based Model.
- Acts are targets and sources of one another, but an Act can never have itself as a source. (That is, Acts are acyclic, but branches can re-converge. When we refer to an Act source or target, we typically mean to include all ancestors or descendants, not just the immediately connected Act.)
- Acts reference an ASelect, referred to as the “selected” relation. An ASelect represents the model aspects that the Act is working within; that is, the spatial, temporal and type (agent) “world” that is currently being selected.
- ATransforms also specify a “destination” ASelect. This represents aspects that the selected agent(s) will transform to. For example, an AMove may use an ARule to select all SugarAgents (type) in the SugarGrid (space) every period (time) and move them to a destination of a neighboring SugarCell (type) in the SugarGrid (space, with time implicit).
- All Acts have as their root-most source Act an ARoot. These are added first to any agent behavior and act as triggers for all target behavior. For example, an AWatch will “fire” any time the watched attribute is modified. (As the diagrams do not refer to elements outside of the current package, we cannot see here that AAccessor includes a reference to some SAttribute, but it does. To see these kinds of relationships you will want to refer to the metaabm.ecore file itself.)
- ASinks are Acts which use some FFunction (see next section) to interpret state in the form of AInputs. Inputs can come from selected agent attributes, other Acts, or literal values.
- AControls determine wether target acts are executed and against what agents. They are in some sense query terms.
- ACommands trigger some model state change (ASet) or spatial transformation (ATransform).
A forthcoming Technical Report will discuss the ideas behind the metaABM Act approach in greater detail, but in brief, the system can be thought of as a very high-level quasi-declarative query and transformation language. As we define metaABM itself through another meta-model (a meta-meta-model!) we leave typical language features such as syntax undefined. Here we are only interested in the core of what can and cannot be done with the language and leave specific implementation “flavors” up to implementations.
The Function representation is relatively simple. As indicated above, Functions are used by ASinks to interpret some model state. Functions are broken into two broad types; FOperators, which are simple calculations sharing the same type, and FGenericFunctions that can represent any general function that takes some well-defined input(s) and returns some well-defined output(s). (Conceptually, functions can return multi-values, but that is not currently implemented in the reference targets because of limitations of the target language Java. Future reference implementations should address this issue.) FLogicals return some binary result and that is used by AQueries to decide wether target Acts apply to a particular selection. Input types should be defined as generally as possible.
|
