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"
(→Space) |
(→Design) |
||
| Line 33: | Line 33: | ||
=Design= | =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. | 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. | ||
| Line 44: | Line 44: | ||
#Transparant | #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== | ==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 changes: | |
| − | + | ||
| + | "SContext" -> ~"AEnsemble" | ||
| + | |||
| + | |||
| + | ===Space=== | ||
====Graphs / Networks==== | ====Graphs / Networks==== | ||
Revision as of 20:40, 3 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:
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.
- 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
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 changes:
"SContext" -> ~"AEnsemble"
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.