Therefore we want to discuss whether there is a possibility to furhter improve the STEM usability. Previously we discussed as a long term goal to create a fully graphical solution, but this is probably highly ambitious. So we were thinking whether there are other possibilities.

Maybe that could then work as follows:

In the drop-down list of NewDisease\DiseaseModel a new entry could be called "enter formula-based model". A click could open a new window where users can define a disease model by entering formulas with a standardized notation. Or users select an existing disease model and adapt it to their specific needs.

Of course this is not trivial, as this would imply, that the system would have to "translate" a formula expression into executable java code. But anyhow this would also bring us a big step forward with respect to the transparency of calculations as then the performed calculations would be directly connected to a human-readable formula.

What do you think?

Alex and Matthias

]]>

I think we all agree that creation of new computational models needs to be made easier. Getting to a fully graphical solution is going to be quite complicated, but I think is possible. We need to break it down into smaller steps though.

We've discussed internally how to do this and here's a sketch of how we're planning to approach the problem. Any feedback you have would be helpful!

1. We currently use the Eclipse Modeling Framework's modeled code generation facilities to create the computational (disease/population) model's empty stub. First problem is the generated stub isn't "minimally complete". As you know, the generated code requires manual additions and changes before you can even begin implementing the science. Getting a fully generated stub is step 1 and in progress now.

2. Once you can generate minimally complete code for a disease model from a data model, the next step is to make the creation of the data model easier. We see step 2 as creating an intermediate (more domain-specific) data model for describing the disease model. Initially this will be simple (just the structure, such as disease parameters or the list of compartments) but expandable to include mathematical notations.

3. Once we have our domain-specific data model for describing a computational model, we can begin working on UI tools to make the whole process more user friendly. Again, first step will probably be a simple UI wizard to define the disease model parameters and compartments and generate the code.

4. Step 4 would be a diagramming tool that accepts mathematical notation and allows you to create/edit the science interactively using a UI tool. Perhaps a state diagram editor where the transitions are graphically edited. Step 4(b) is some type of code injection and/or just-in-time compiler to allow interactive changes to the underlying code and immediately run / compare changes in the science.

It'd be great to jump straight to step 4 today because it contains a lot of really interesting software problems and questions. However, we need to get through steps 1-3 to be able to do #4.

-Matt]]>