Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
AMP UserGuide/AMF/MetaModel
Contents
The Agent Modeling Framework MetaABM / Acore Meta-Model
Important Note
The MetaABM "metaabm" meta-model will be transitioning to a significantly changed "acore" meta-model as part of the overall AMP project plan. At the moment, metaabm is serving as the AMF meta-model. We'll be providing automated migration tools, so developers can use it without worry about future compatibility. To avoid having to re-edit all of this documentation, we'll be referring to "acore" below, unless we anticipate a change in which case we'll tag that with (metaabm).
Background
The foundation of the Agent Modeling Framework is "acore" (metaabm). It's is designed to be a general representation or “meta-model” for Agent-Based Models. As the name implies, the "acore" model (will be) analogous to the EMF "ecore" meta-model but provides representations that are suited to agent-based and other modeling (in the "modeling and simulation" sense of the word) oriented domains. Models can be fully defined within the acore lingua franca and model implementations can then be generated from those models with no further coding or configuration. The system as whole currently provides a hierarchical visual editor and reference implementations targeting the Escape, Ascape and Repast Simphony platforms. MetaABM is built upon the Eclipse Modeling Framework and a number of other Modeling project technologies, including Xpand. AMF is fully integrated with the Eclipse IDE platform, but acore 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.
Acknowledgements
The AMF meta-model started life as "score" [1], a component of the Repast Simphony environment. It wasn't fully utilized within Simphony[2], and migrated from there to the MetaABM project. The MetaABM project defined a complete editor, code-generation and model execution suite that formed the initial AMP AMF contribution. Argonne National Labs supported the initial development of score and Metascape, LLC continued development of MetaABM and both agreed to contribute the relevant IP to the Eclipse project in 2009. The previous meta-models serveed as a “straw-agents” that have allowed the community to refine and explore key representational issues. Some of the following discussion is drawn from previous Metascape documentation and is released by the author (Miles Parker) under ECL.
- ↑ AGENT-BASED META-MODELS, Parker, et.al. http://www.agent2005.anl.gov/2006procpdf/Parker_Agent_2006.pdf
- ↑ Howe, et. al. CONTAINING AGENTS: CONTEXTS, PROJECTIONS, AND AGENTS http://www.agent2006.anl.gov/2006procpdf/Howe_Agent_2006.pdf
Meta-Model Design
The acore / MetaABM meta-model is made up of three main packages. This is all based on MetaABM, and while names and important details will change for Acore, the core design should be quite similar.
Structure
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”.
Behavior
Functions
