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.
Difference between revisions of "AMP/Acore Model Design"
(→Structure) |
(→Inheritance and Composition) |
||
| Line 88: | Line 88: | ||
Possibilities: | Possibilities: | ||
| − | { | + | {{SolutionSet}} |
| − | + | ||
| − | + | ||
|- | |- | ||
| Action-Based | | Action-Based | ||
Revision as of 17:28, 4 November 2009
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.
Contents
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: [1] Again, you can get access to the newsgroups by getting a bugzilla account == easy.
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)
User Experiences
This is a place to put any thoughts that don't fit into specific design issues.
Things that didn't work well
- The hierarchical editor really doesn't work well for editing behavior. Should we try to make behavior definition more hierarchical?
Things that did and we should keep
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.
- Ability to construct any (cannonical, imagined..?) ABM model with an Acore model and no other artifacts.
- Extendible
- 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.
- Transparant
- ...
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
General
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.
Probably some cleanup of the IID and SNamed stuff as well as taking a look at SImplementation -- that seems a bit unnecessarily complicated.
Perhaps provide a more privileged way of specifying non-model (library) resources.
Inheritance and Composition
The most radical changes are actually to the basic composition structure. We need to figure out a general way to handle both of these in a way that supports ad hoc model composition but retains much of the elegance and simplicity of past models.
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 that we need a model that provides an ensemble structure that allows much more control over "scale", "scope" and "space". What we want to support here is the seamless meshing, composition and filtering of models from any domain, scale, methodology or granularity. A somewhat tall order! --Milesparker.gmail.com 18:33, 4 November 2009 (UTC)
There isn't any support for inheritance at all currently, as the naive approach of modeling the Java pattern doesn't fit with what we need to do. Hopefully the scoping mechanism will resolve those issues...being a bit vague here..but the idea is that we can move beyond raw inheritance to an ad hoc assembly of agent "facets" both through explicitly defining Agent Facets (like an abstract base class or a strategy pattern) that can be assembled into runtime agents through a scoping mechanism. Question: Is there a difference in kind between such a facet and simply supporting (multi!) inheritance? I think there may be, for example for the following use case:
| Salim wants to build a model of bicycle sharing in Paris. He has designed a behavioral model which covers usage decisions, but needs to model the actual road movement. There is already an extensive model for vehicle travel developed at the Big Think Institute. Salim wants a simple way to incorporate that model that does't involve a lot of moving things around and that will benefit from changes in the BTI model. | |||
|---|---|---|---|
| {{{1}}} | |
|---|---|
| Action-Based | One thing I was thinking of doing is sort of inspired by Apple's Dylan project of the mid-90s. In Dylan, there was no such thing as an actual object per se - or rather, methods did not belong to objects, but were instead inferred from the method body definitions. This gave the code a very dynamic flavor and meant no time wasted on refactoring different pieces. Just change the method signature! But I don't think that quite works in practice as we really want to be have object attributes be a high level part of a model definition.--Milesparker.gmail.com 21:26, 4 November 2009 (UTC) |
| Wild-card namespace inclusion | We don't need to go that far, but we could encourage the definition of very small fragments, say supporting movement or whatever. This could then fit in with scoping. The idea would be that instead of a single inheritance hierarchy you could actually use scoping to assemble agents. So you'd define a bunch of agent fragments, and then refer to them as an agent, where an agent is basically an identifier combined with a string defining the inclusion of all behavior. In the use case above, Salim might define a fragment for his behavior, and then specify a TransporationUser agent that had a behavior inclusion list like "". Do we need exclusion? (See below.) We'd need to manage name collision and so on, so this isn't a trivial thing to implement, but I think the benefits for composability would be really significant.Milesparker.gmail.com 19:12, 4 November 2009 (UTC) |
| List of multi-inheiritance. | Keep it simple, just allow agents to be specified as an inclusion of a bunch of Facets. This would be like a no-op class that inherits from a bunch of base classes. I think this one might be best, especially as we don't have to deal with issues of multiple levels of wild-card inclusion, which could get really messy. But it could prevent a more flexible approach to composition (across scales, say.)--Milesparker.gmail.com 21:26, 4 November 2009 (UTC) |
Scope, Scale, Type/Kind and Space
What we need is a good way to define arbitrary semantic structures with an easily grokked one-line syntax. Here is a use case:
| Tim, a grad student at the University of Pennsyltucky, has built a model of the social dynamics and demographics of penguins in Antarctica. He wants to test a theory that penguins about food sharing based on rational utility optimization and so wants to integrate a notional model of economic actors that Sally made at the Big Think Institute. We'd like to define some string for each of the models that we can use with another inclusion string that will effectively search a common namespace and that will then be able to gather and integrate the two models. | |||
|---|---|---|---|
| {{{1}}} | Java-like | A strict hierarchal java package name space probably doesn't work, as those end up being arbitrary and can't deal with cross-cutting concerns:
edu.pentk.marinebio.antarctica.. org.bti.econ.rational | |
|---|---|---|---|
| Hierachical Wild-Card | Or we could add in wildcards, ala XPath, but that's still hierarchical.
edu/pentk/marine/**/antarctica/social.. org/bti/econ/**/rational | ||
| Tuple Wild-card | So currently I'm thinking about using some kind of tuple space to allow an arbitrary set of dimensions and then encourage the actual detailed specification to be developed by the community at large..these could then be attached to particular agent facets, spaces and scales. A model then is simply some defined region in this arbitrarily complex space.
Tim's Ensemble: institution=edu.pentk, scope="bio,social", scale="community.higher-organisms" Tim's Ensemble: institution=edu.pentk | ||
I'm sure that there is relevant work out there. Please share it along with any ideas for the most flexible approach to this.
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
Because of timeline, we should try to keep scope of new features down, remembering that it is much easier to add things than to change existing features. But this would still be a good time to think through these issues, especially as we may want to drive some things into main design.
Derived Rule
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.
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 sources and sinks.
State Machine
Do we want more explicit support for state machines? (Ala AnyLogic?) Or is this really more of an editor issue? IOTW, are there things that we can't do easily now?
Support for Equation Models (ODE/PDE)
With the current model it should be possible to infer potential equation models from model contents. Is there any additional meta-data that would be helpful in that regard?
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:
- 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.
- 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?
- 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.