Abstract
This article outlines the architecture of a universal visual model editor.
Project
This was on my job at InLine, aka JFX, aka ObjectVenture. Our product was a plug-in to several IDEs (Visual Cafe, JBuilder, NetBeans) that added support for J2EE, persistence, Web Development and Patterns.
My assignment
I was in charge of significant parts of the architecture of the product. I also took on design and coding of some of the critical parts of the tool. One of these parts was the source code/model round-trip: we wanted the visual model to instantly reflect changes in the source code. We also wanted that whenever the user modified the model, the change would be synchronously reflected in the source code.
Challenges
There were several challenges associated with this task:
- The model was heterogeneous: in J2EE some information is in the Java source code, some in compiled class files and JARS, and some is in XML descriptors. We wanted to present a unified view of all these piece-parts.
- We needed to support many different models: Java Classes, JavaBeans, EJB 1.0, EJB 2.0 etc. All of these models were substantially different.
- We wanted the model to be easily extended by plug-ins. For example, somebody might want to write a plug-in to our tool that would model the Abstract Factory pattern in terms of EJB home functions.
- The natural presentation of the J2EE model is a graph, but our tool was going to display a tree view of the model.
- The same model needed to be able to be displayed using different UI (for instance, standalone vs. IDE plugin, also with both Swing and SWT), therefore the UI mechanisms needed to be separated from the core functionality.
- The model was potentially very large. We did not want to construct it in its entirety every time the project was open. We wanted to instantiate only the parts that the user was working on.
All this needed to be reconciled.
Solution
The solution was a modification of the three-layer architecture. I introduced a whole new layer of controller objects consisting of Features and DisplayProperties.
Formally speaking, Feature and other classes of the Feature Framework implement a meta-meta-model, meaning that it could be used to describe arbitrary meta-models like Java classes, JavaBeans, EJB 1.1 Assembly, EDOC Subsystem etc. If the term meta-meta-model is a bit confusing, consider this example:
- Model: Dmitri Plotnikov drives Prius VIN 12112.... This is concrete.
- Meta-model: Person drives Car. This can be used to describe a family of similar concrete models.
- Meta-meta-model: Subject-Verb-Object. This can be used to describe a family of similar meta-models.
Feature Framework is a meta-meta-model. It allows you to define arbitrary meta-models and then access, modify, validate, display and edit them.
Features implement the Displayable interface. DisplayProperties is an object that describes how a Displayable object should be shown in the UIs.
At its core, the Feature framework is basically a tree where all parts: the root, nodes and sets of child nodes are represented by interfaces and implemented differently for different kinds of things.
In the context of the Java Class model, there will be an implementation of the Feature interface to handle the notion of Java Field . There will also be a class that implements the FeatureSet interface and represents a set of JavaFields. This class's job is to extract fields from a Java parse tree and insert new fields into it.
Another example is a Feature class for EJB Home JNDI Name in the EJB 2.0 model. Unlike the Java Field feature described above, this one works with the EJB Deployment Descriptor, extracts the necessary data element from it and/or inserts or modifies that data element.
There is a hierarchy of Abstract Factories that control the entire model. Everything starts with a FeatureModelFactory, which instantiates a FeatureModel based on the desired model type. FeatureModel is the hub of all activity. It manages resources (e.g. Java source) via Resource Adapters, elements of the UI via DisplayPropertyFactories and Features via FeatureFactories.
Features and FeatureSets participate in both phases of the modeling round-trip. They are responsible for parsing the underlying model (e.g. source code) initially and when it changes. They are also responsible for applying user actions to the underlying model. For the latter purpose there are FeatureActions (think menu items on the Feature's node in the TreeView), FeatureConstructors (implementations of the New... actions) and FeatureEditors, whose job is to provide UI for modifying properties of a Feature.
There are also FeatureModelConfigurators, whose job is to resolve conflicts between Features provided by different plug-ins.
Feature Framework is by its nature highly abstract, which makes it adaptable to all kinds of modeling applications. Some critics say that something so abstract cannot be practically useful. Feature Framework proves the opposite: we had a team of several developers churning out implementations of various models. Everything clicked together without being directly interdependent.
Please see the Javadoc APIs for further details.
Also see this presentation of JFX Studio, a compete development environment based on the Feature Framework. The product was renamed to ObjectAssembler before release.
InLine Software aka JFX aka ObjectVenture may have failed as a business, but Feature Framework was an undisputed technical success. I personally see it as the highest achievement of my career to date.
[UPDATE: today, in Feb 2021, I no longer see it like that. Several projects at Google, such as Android Contacts, the Core Framework of Google+ on Android and YouTube Music fore Android had much bigger impact.]