Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "AMP/Acore Model Design"
(→Inheritance and Composition) |
(→Inheritance and Composition) |
||
Line 78: | Line 78: | ||
===Inheritance and Composition=== | ===Inheritance and Composition=== | ||
− | The most radical changes are actually to the basic composition structure. | + | 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. |
− | 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" through a scoping mechanism. | + | 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! --[[User:Milesparker.gmail.com|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: | ||
+ | |||
+ | |||
+ | |||
+ | What I would like to do 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 --[[User:Milesparker.gmail.com|Milesparker.gmail.com]] 19:12, 4 November 2009 (UTC) | ||
====Scope, Scale, Type/Kind and Space==== | ====Scope, Scale, Type/Kind and Space==== | ||
Line 86: | Line 92: | ||
What we need is a good way to define arbitrary semantic structures with an easily grokked one-line syntax. Here is a use case: | What we need is a good way to define arbitrary semantic structures with an easily grokked one-line syntax. Here is a use case: | ||
− | + | {{UseCase|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.}} | |
So here is what we know about Tim's model: | So here is what we know about Tim's model: |
Revision as of 15:12, 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:
What I would like to do 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 --Milesparker.gmail.com 19:12, 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. |
---|