Discover the g9 Modeler and code generator – Tool review

g9 (formerly known as Genova) by Esito is a modeling environment with advanced code-generation capabilities. Given a domain model and a UI model, you are able to generate full Swing, React, Angular applications (among others), including the database, the data access layer and the client side. You can also add a Web Services / Rest backend and create your own generators.

g9 is distributed as an Eclipse plug-in (not a surprise, given the rich modeling ecosystem in Eclipse) and comes with a free plan allowing the generation of apps with up to 12 domain classes.

As most MDD tools, g9 is especially suited for data-intensive applications where the user can benefit from the power of model-driven development to automate as much as possible the large volume of repetitive code to manage the domain classes.

g9 is especially appealing for professional developers that want to increase their productivity and are not allergic to source code (contrary to other tools, targeting more a business user with no programming expertise and that therefore typically prefer a model interpretation strategy with automatic cloud deployment and very  limited options to refine / add additional behavior to the modeled application).

Let’s take a deeper look at g9, focusing on the aspects I found particularly exciting.

 Getting Started with g9

Given that the g9 website is not the fanciest one I’ve seen ????, the best way to get an idea of what g9 can do for you is to install the tool. As I said before, g9 is free for apps up to 12 classes, which is more than enough to understand how the tool works and get a feeling of the power of the tool.

Installing the tool follows the standard Eclipse procedure of adding an update site for the tool (full installation instructions). Once installed, g9 will show up in your Eclipse environment. If it’s the first time you execute g9 and therefore don’t have a valid license, you can easily request a free one filling the form that will pop-up immediately.

g9 comes with a set of predefined examples, so my recommendation is to start with those instead of creating a brand new project. Each example comes with the sample model and the corresponding generated code so you can take a look at both.

Modeling your application 

There are two main models in a g9 application: the domain model and the UI models (dialog models in the g9 terminology).

The domain model is not modeled using g9 itself but automatically imported from a variety of sources like Enterprise Architect or Ecore/Xcore (adding Papyrus to the list would be nice as well!). The domain model can include all the typical modeling primitives for static models (classes, associations, attributes, enumerations, generalizations,…). Complex associations (n-ary, association classes,…) must be normalized/reified before importing the model. To be honest, this is typically the case in most code-generators that try to reduce the complexity of the generators by focusing on the most common modeling constructs (and no, “normal” people do not often use n-ary associations in their models, I guess I’m one of the exceptions ???? ).

The UI model is specified using a WYSIWYG approach, where a Palette with all the possible widgets and controls (that change depending on the features offered by the target platform) allows you to quickly drag and drop in the UI canvas. I found it quite convenient and quick to use to get the forms I wanted.

One feature that deserves to be highlighted is the possibility to automatically generate some dialog models (CRUD-like ones) from the domain model so that I don’t need to create all of them from scratch. This scaffolding is something that many programming frameworks offer but something that it’s hardly ever seen in modeling tools (even if I don’t believe this to be too complex to implement).  In g9 this can be done in two ways:

1. by selecting a set of classes in the domain model and creating an Object Selection from which then create the dialogs.
2. by selecting a set of classes in the domain model and creating a Dialog for each class.

An improvement would be to have a rendering of the form closer to the final aspect of that form in the target technology (i.e. an even more real WYSIWYG). This is part of g9’s roadmap at the moment.

Beyond these two core models, you can also configure a database model to define how the domain model should be translated into a relational schema (e.g. mapping options for the generalizations) and one or more object selections, which are subsets of the domain model you’re going to use either in a web service implementation or as a data source for a form in the client side.

Generating your application

Once the models are ready you can go ahead with the generation of your full application by selecting any of the numerous generators available.

All generators are highly configurable but g9 makes easy also to create your own generator if needed. New generators can be written in Xtend or plain Java. Note that, instead of building a complete generator, you can just extend existing ones by

1. creating just custom widgets and controls to complement the palette available in the dialog model.
2. Intercept the code generation process by using one of the available hooks that allow you to write your own code for that specific part of the generation.

This flexibility and extensibility is one of the key points of g9. We all know how important is for a programmer to recognize himself in the code he manipulates; for the adoption of code-generators the generated code must feel like the handwritten one and adapting the generators to the code style of the company is a good step in that direction. Full source code is available for all generators and you might copy and edit it to your needs.

Moreover, g9 distinguishes between your manual code and the generated one. This prevents overwriting your own code when regenerating the application. It’s not full round-trip engineering support (your code is a separated extension of the generated one, it does not get propagated back to the model) but it’s powerful enough for most scenarios.

I expect Esito to release additional generators in the future. For instance, I’d like to see a more complete support for REST APIs (e.g. by providing an UMLtoOdata generator), or GraphQL (e.g. see our UMLtoGraphQL generator) which are becoming more and more popular nowadays.

g9 as a migration tool

One of the features I like the most is the tool capability to infer the domain model from an existing application. You can either infer it from a database schema or from Java source code.

For the former, you just need to indicate the JDBC database connection parameters and the tables you’d like to import.

For the Java source code, you can either derive the model from plain Java code or first annotate it using g9-specific annotations to better control what (and how)  to import the code. JPA annotations are also supported so you may just rely on those as well.

In both cases, you get a domain model for free. If then, you add it the dialog models you can then regenerate your application using a newer technology (e.g. moving from a plain Java application to a web-based React one), actually completing a migration of your “legacy” tool at a much faster pace than with a traditional migration project.

Of course, if the dialog models could also be inferred from the legacy code, that would be awesome but I´m afraid this is too much to ask (in fact, this is still an open research topic).

 

At a cost of around 500 EUR for a full license, g9 is really affordable and for sure one of the most flexible and adaptable code-generator tools I’ve seen and one of the few with such a deep integration in Eclipse. If you are looking for ways to boost your productivity, g9 should definitely be an option to consider. And if you try it (or are already using it) please share your comments below!