AMP/Acore Model Design

As part of the move to Eclipse we've been planning to transition the "metaabm" meta-model to "acore". Acore will have significant changes based on everyone's experience using MetaABM over the last couple of years. This page is for community discussion about those changes. Please see this doc for more on where MetaABM -> Acore currently is.

Participating

The AMP project is actively soliciting feedback on those changes. Even better than feedback would be active participation in the design process. Things will be moving pretty rapidly so now is the time to get involved! Design discussions will take place at the following places.

Design Feedback and Ideas

This page is an active design document.

All you have to do to edit this page is get an Eclipse bugzilla account here: https://bugs.eclipse.org/bugs/createaccount.cgi

Please feel free to add your own thoughts, and to revise or add categories, etc... And, just saying "this part didn't work really well", or "I'm not sure what you were thinking with.." is really valuable too. Think of this as brainstorming now, so you can throw ideas at the wall and we'll see what sticks.

Just a few guidelines. Please follow general wiki talk etiquette, i.e. don't erase other's comments until it is a good time to condense. We will be churning and refining the doc overtime things so things will get distilled and we can archive discussions. Please end any comments with the following sequence so that your name and the time show up on the wiki: ~~----

General Discussion and Help

That should go to newsgroup:

Implementation and technical issues

If it is really nitty-gritty: https://dev.eclipse.org/mailman/listinfo/amp-dev

Actual Requirements

As we refine things, we'll add them to the bugzilla. If there is a change or improvement that you really want to make sure gets into the Acore release, then you should file a bug report to the AMP AMF component for it. Really, feel free, it's always nice to get reports that come from outside of the actual project! Please also add it as a dependency to https://bugs.eclipse.org/bugs/show_bug.cgi?id=291254

Schedule

I'm really pushing to get this out by the end of the year. I think it's important to get on to the release train and go to 1.0 status so I don't want to delay things more than necessary. Thoughts?--Milesparker.gmail.com 00:31, 4 November 2009 (UTC)

Design

General

There are a lot of dependencies, some of which (such as in gen code) aren't really obvious, so we should balance changes against that. We also need to be sure that there is a clear mapping from MetaABM to Acore constructs. There are a number of design features that are in place largely as a result of original Repast Simphony integration that we should pull out.

The overall design requirements are below. Let's try to capture anything in current model that doesn't meet them.

1. Ability to construct any (cannonical, imagined..?) ABM model with an Acore model and no other artifacts.
2. Extendible
3. Modifications to one part of model have low coupling to other components. (For example, we want to be able to change the type of a space without having to change everything that refers to that space.
4. Transparant
5. ...

Naming conventions

Thinking about changing everything from current S for structure, A for Actions, F for Functions design so that everything starts with an "A" to match with Ecore design.

Structure

The most radical changes are actually to the basic composition structure. I think that there are some flaws in the Simphony Context model that I discussed in NAACSOS talk. I'm going to try to get that online. I'm proposing a model that provides an ensmeble structure that allows much more control over "scale", "scope" and "space".

Some specific proposed changes:

"SContext" -> ~"AEnsemble" "SProjection" -> "ASpace"

"ASpace" and "AAgent" both inherit from "AScape" (not "Ascape" :))

AAttribute would have a new "derived" flag that would specify the value as mutable but not modifiable through behavior.

Space

Graphs / Networks

Should these be called graphs, networks, or relations?

Construction

We had space construction types defined as attributes of graphs. These should really be moved out of there and into a build graph action specialization.

Behavior

New Features

Add a "derived" rule, which allows one to create attributes that are completely derived from rules. IFF an attribute is derived can it be modified in a ADervived root action, and it cannot be changed anywhere else. This would clean up a lot of code and make it much more modular and it would also allow users to easily create statistics and other measures.

Changes to Select, Query and Logic

Currently the ASelect, AQuery and ALogic is complex and the semantics are somewhat poorly defined. In practice it has been difficult for users to understand and difficult to generate code for. On the other hand, there are subtle and important things that the design allows you to do that we'd like to keep. Here are some random thoughts..

For example, consider the following:

             S1
          /       \
        Q1      Q2
         \        /
            &
           Q3

In the above case, we do a select against space and agent in S1 using Q1 and Q2 as terms. Then we check if the results of that selection meet Q3. A potentially confusing thing is that for the fowllowing case:

             S1
          /       \      \
        Q1      Q2    Q3
         \        /        /
            &            /
             \         /
                   | (AAll)
                  Q4

The select is ((Q1 & Q2) | Q3) and then Q4 is applied to the result of that selection. Basically, AAll and AAny serve as search terminals. This get's even more confusing when we add in ANone (Negation). We perhaps need to make this clearer. Here are some potential approaches:

1. We could bundle up AQuery with a list of query expressions. This would get rid of the trees of queries that currently proliferate. But I think we'd still want to keep ASelect and AQuery separate.
2. Get rid of AAny, which is effectively a logical OR and not really necessary, as multiple paths to a given node are implicitly ORs. One could get any logical statement using (implicitly) Disjunctive Normal Form. AAny is not strictly speaking necessary (I think!) because it allows a set of potential boolean conditions to be clearly gathered up in one place, but i creates a lot of confusion esp. when we get to negation. This would mean that all queries were exactly two node layers deep, but I think we'd need to add the facility to negate any of the queries. Is the potential value to end-user of being able to use any kind of logical construction outwighed by the simplicty of simply allowing some set of AND queries connected with (implicit) ORs?
3. Have an explicit "end query" node. Currently the semantics of when a query ends might not be clear, because it is possible to have a query filtering the results immediately following a select construct.

I'm thinking the best idea is to morph AAll into an AEnd node which indicates a set of conditions and just getting rid of AAny, but I'm not sure. It might be really nice and clean to just bundle them up into a set of Selects and Queries with multiple and entries. We need to make sure that any solution allows full and simple equivalence to the General Purpose Language else construct. I think we can do that with Negation but we need to be sure that will work. These are critical issues, so we really need feedback.

Support for Systems Dynamics

There has been a lot of discussion about this. I wonder if we're ready to implement some specific proposals, for example explicit support for some concepts.

State Machine

Do we want more explicit support for state machines? Or is this really more of an editor issue? IOTW, are there things that we can't do easily now?