In the idealized waterfall model this is how "the pressure from below" drives refinement:
The software architect takes an analysis level model and transforms it into a design level model. The programmer takes an design level model and transforms it into an implementation level model. The compiler takes the implementation level model and transforms it into a machine level model.
So each real-life participant is a transformer.
Whenever a transformer sees a model that is not acceptable, i.e. it does not solely consist of concepts at the right level, he raises his hands up and asks the previous link in the process chain to finish his job.
(Note that the "levels" are implicit. A level is just a condition that must be met in order for a transformation to do its job.)
Usually metalanguages are tied to a strict metamodel that states what is legal and what is not. Furthermore, it is a general strategy given from outside (top-down, bottom-up etc that states in which order the transformations must be applied).
In ngrease the transformation strategy is defined in a rule-based way. The transformer for the top-level transformation request usually declares subrequests that must be applied before it can do its job and so on.
Furthermore, in ngrease syntax error is usually not an error. It's just a temporary condition: there are unsatisfied subrequests for the current request.
Maybe later a strict metamodel (that helps in creating a context-helping editor) can be dynamically generated from this rule-system, but for now I'm more interested in making good things possible than forcing them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the idealized waterfall model this is how "the pressure from below" drives refinement:
The software architect takes an analysis level model and transforms it into a design level model. The programmer takes an design level model and transforms it into an implementation level model. The compiler takes the implementation level model and transforms it into a machine level model.
So each real-life participant is a transformer.
Whenever a transformer sees a model that is not acceptable, i.e. it does not solely consist of concepts at the right level, he raises his hands up and asks the previous link in the process chain to finish his job.
(Note that the "levels" are implicit. A level is just a condition that must be met in order for a transformation to do its job.)
Usually metalanguages are tied to a strict metamodel that states what is legal and what is not. Furthermore, it is a general strategy given from outside (top-down, bottom-up etc that states in which order the transformations must be applied).
In ngrease the transformation strategy is defined in a rule-based way. The transformer for the top-level transformation request usually declares subrequests that must be applied before it can do its job and so on.
Furthermore, in ngrease syntax error is usually not an error. It's just a temporary condition: there are unsatisfied subrequests for the current request.
Maybe later a strict metamodel (that helps in creating a context-helping editor) can be dynamically generated from this rule-system, but for now I'm more interested in making good things possible than forcing them.