A tutorial toolbar would have a number of buttons for each step in the tutorial. It teaches the fundamentals of AToMPM:
create a metamodel;
create a concrete syntax model;
create rule-based operational semantics;
create rule-based translational semantics.
The question is: do we let the user create a language from scratch (i.e., the toolbar is simply an aid in going through the different steps in creating a DSL), or an already existing language which has "holes" the user needs to fill in?
A tutorial toolbar would have a number of buttons for each step in the tutorial. It teaches the fundamentals of AToMPM:
- create a metamodel;
- create a concrete syntax model;
- create rule-based operational semantics;
- create rule-based translational semantics.
The question is: do we let the user create a language from scratch (i.e., the toolbar is simply an aid in going through the different steps in creating a DSL), or an already existing language which has "holes" the user needs to fill in?
A toolbar for creating a new formalism is useful. It would have at least the functionality to 'create a new formalism', which would ask for its name. The backend then creates a folder with name , an AS model with name .model, a CS model with name .defaultIcons.model, and compile them to the appropriate metamodels. Further buttons could then open the AS and CS models, and a button to compile them. Potentially, one would be in the 'mode' of editing a formalism (so the toolbar remembers), at which point it controls the whole process of using AToMPM.
For creating a transformation, one could do the same, but it might be less useful.
A tutorial toolbar can be different: it could explain the basic functionality of AToMPM using a set of interactive buttons, that open one after the other models of an already-existing formalism (such as Petrinets), with text boxes explaining what is modelled.
A toolbar for creating a new formalism is useful. It would have at least the functionality to 'create a new formalism', which would ask for its name. The backend then creates a folder with name <name>, an AS model with name <name>.model, a CS model with name <name>.defaultIcons.model, and compile them to the appropriate metamodels. Further buttons could then open the AS and CS models, and a button to compile them. Potentially, one would be in the 'mode' of editing a formalism (so the toolbar remembers), at which point it controls the whole process of using AToMPM.
For creating a transformation, one could do the same, but it might be less useful.
A tutorial toolbar can be different: it could explain the basic functionality of AToMPM using a set of interactive buttons, that open one after the other models of an already-existing formalism (such as Petrinets), with text boxes explaining what is modelled.
A tutorial toolbar would have a number of buttons for each step in the tutorial. It teaches the fundamentals of AToMPM:
The question is: do we let the user create a language from scratch (i.e., the toolbar is simply an aid in going through the different steps in creating a DSL), or an already existing language which has "holes" the user needs to fill in?
A toolbar for creating a new formalism is useful. It would have at least the functionality to 'create a new formalism', which would ask for its name. The backend then creates a folder with name , an AS model with name .model, a CS model with name .defaultIcons.model, and compile them to the appropriate metamodels. Further buttons could then open the AS and CS models, and a button to compile them. Potentially, one would be in the 'mode' of editing a formalism (so the toolbar remembers), at which point it controls the whole process of using AToMPM.
For creating a transformation, one could do the same, but it might be less useful.
A tutorial toolbar can be different: it could explain the basic functionality of AToMPM using a set of interactive buttons, that open one after the other models of an already-existing formalism (such as Petrinets), with text boxes explaining what is modelled.