dimitar-asenov/Envision — Issue #3: Improve the design of the application model
Author: dimitar-asenov
Created: 2011-11-23 10:54:02+00:00
State: open

In Envision a program is not a piece of text but rather a tree structure called a model. This is similar to a traditional AST but has some differences:
- Envision's tree model does not use predefined programming constructs. It is extensible by the user. This means that arbitrary new nodes can be attached as children to any other nodes.
- It should provide a natural interface. User should be able to call methods normally on an object, such as `method.getReturnType()` instead of `(ReturnType) method.returnChild("returnType")`
- The tree should be easy to use and navigate. This should happen in a natural way: e.g. `method.getReturnType()` as opposed to `(ReturnType) method.getChildByName("returnType")`
- The model is meant to contain not only the "parsed" source code of an application but also all its supporting software engineering artifacts. This includes things like graphs, tables, images, comments, etc.

Envision currently implements an application model that (at least in theory) supports the following features
- interaction with a persistent store
- ability to partially load a project (this needs a better design)
- concurrent access to the tree structure (not really in use right now, so we have no experience with how it performs)
- undo stack
- extensibility with new node types (there might be a better way of doing this)
- node references (this could also use some more work)

As one can see above there are some things which need to be improved and some additional requirements
- Partial loading. It is crucial that a developer is able to open only a part of huge project. A part can be a class or several classes. Currently a project in the model consists of all artifacts associated with it: classes, modules, library specifications, methods, and so on. When a project is opened some nodes are only partially loaded, that means that some of their child nodes are not read. This mechanism might not scale very well. The original idea is that the model will be also be used to resolve links. A more traditional alternative might be to keep a separate data structure that keeps an index of all symbols and the model consists of independently loadable parts (such as classes). The pros cons need to be investigated better.
- Concurrent access. The current mechanism is OK, but since it is not well tested we need to have it mind when changing the model.
- Reference Resolution. This is connected to partial loading. More thought needs to be put in how we can resolve references. This will need a special interface with the persistent store mechanism when we need to resolve references which point to something that is not loaded.
- Usability and Extensibility. It is important that we have a second look at the current design for implementing tree nodes. Currently this is done directly in the source code. This might be very efficient but it is some times not convenient.
- Visitor pattern. As embarrassing as this is, I have designed a tree structure that does not implement the visitor pattern. This gets a bit tricky when dealing with arbitrary node types but there are some versions of the pattern that deal with this. In the end such a functionality must be implemented somehow.
- Additional Information. An additional important feature that is missing is the ability to attach extra information to a tree node. Ideally this extra information would itself just be another tree node that can have arbitrary structure. This is meant to be used to record analysis information with the program. So the output of various semantic analyses can be attached to corresponding nodes: errors, profiler measurements, etc. Having this information as part of the model might simplify visualization.
- Content linking. Having many different types of artifacts in the same model, it will be useful to implements link between them. Such as a link between a comment and a method, or a link between a table cell and value in the program. This is also a big separate topic, but needs to be considered when thinking about the way referencing of nodes will work.

The more interesting parts of the current model are described in my master thesis here: http://www.pm.inf.ethz.ch/education/theses/student_docs/Asenov_Dimitar/dimitar_asenov_MA_report
The corresponding source code is in the ModelBase directory and is one of the better commented parts of Envision.