Anti Visual (Meta) Programming

Sebastien Devaux — Mon, 01 Sep 2014 09:51:00 +0200

More than ten years after the delivery of the first really useable UML software engineering tools, it's time to look backwards and think about the real gains enabled by those tools. It appears that the promises are not yet there and finally many have failed to increase significantly software engineers productivity than just using paper and pen. Most coders are skilled in thinking of classes and writing line of codes, not drawing. But good drawing are really useful, those are only too costly to build and maintain. Then imagine if you can drawing by coding. The same coders that didn't produce any documentation before the availability of doc extractors like doxygen won't no more refuse to present diagrams if their drawing does no more require overwork.

Assumptions

Designing software by drawing and aligning boxes using the mouse and editing properties through forms is not efficient.
Keeping code and diagram synchronized is time consuming and in most practical cases, synchronization is definitely broken as soon as the real implementation starts.
most coders are more skilled at typing text than drawing nice diagrams.
whiteboard, paper and pen remain the best tool to support software engineers brainstorming.

First proposition - reverse the process

Instead of drawing many diagrams and then generate code, why not do just the opposite: write some code and interactively, while entering text, let the tool render automatically some diagrams of the edited code. For most coder, it is quicker to just enter "class MyClass" than drag and drop a class widget, then click, then enter class name... Instead of opening forms when selecting a box on the graphical view, locating the cursor to the textual definition location of the pointed entity is enough to navigate the code and enable the coder to edit the entity’s properties. This of course does not forbid to keep some cool toolbar to have some one click template application features.

Second proposition - a true and complete textual (extended) UML

Think about software as a high dimensional space. Then any UML diagram is in fact a projection of the wide space into a narrower one. Then there is many information loss from the full space to the projected one. The implemented code itself is also a projection with information loss (for instance: think about how to implement aggregation and composition using a language like java or C#, no really visible difference). Then today software engineering remains a very difficult task because it consist in defining a very complex object only through restricted and limited views. And many coders still think only the code view matters.

UML stands for Unified Modeling Language. But in fact, where is the language? We only have some kind of graphical grammar, not so easy to process. Indeed, XMI has been introduced, but it was designed only to support modeling tools interoperability (that is still so limited than finally it is rarely use). It is so hard to read (by human), so don't think about edit XMI files by hand. However a modeling language like what anyone may imagine when thinking about what the language word means in any acronym ending by L letter is a great idea. So why not define one? A real textual language not just only hieroglyphs. Think about why most humans today use alphabets to tell stories in place of some shiny little icons sequences! May be because images is not enough to let people understand each other. Don't be too focus on the learning curve. The most easy to learn tool is rarely the most powerful and efficient. Something like actual UML diagram should be a view and only a view. Such view shall be defined as a query from the high dimensional space :

the list of entity it shall display.
the projection direction, e.g. the diagram type (class, sequence, collaboration, etc)
some rendering options: layout, coloring, filtering some details.

A complete modeling language should be able to describe the whole high dimensional space defining software, not only what is describe by the today known projections:

main entities as UML does: package, classes, relations...
algorithms, processes and equations (are you really able to design any algorithm using sequence or state diagrams?)
threading and synchronization (I simply don't know how to figure threading aspects meaningfully with UML).
documentation (documentation of entities may also be rendered live as the diagrams).
etc: there's surely many missing things that didn't came in my mind while writing this.

It's sad to say we still need another language. Too many people lose time in creating new languages while most of them really need only a good new library of an existing one. Then, if something that looks like what is describe here already exists, please leave a comment. I'd rather like to extend or improve if needed something already there than implementing something completely new.

Third proposition - meta programming

Design patterns are to me the best improvement in the scope of object oriented software engineering of the last years. Then our next generation software engineering shall support design patterns. It shall also support some way of programming automation. Think about how many time you write the same lines of code, specially when applying coding standards and rules: most private class members will need the same getter and setter. Having a collection requires to the enclosing class to have also members to add/remove/check members. Writing all this common stuff can involve more than half the coding effort of a class. Then such definitions should be implemented automatically just by defining some attributes to the class properties that need it.

What is already available

Most of the basic features needed to implement a tool such as the one described above are already available from the eclipse platform and its many plugins:

advanced text editors with automatic completions.
structural model extraction from plain text (or XML) files.
synchronized views
UML drawing

Plantuml is a good example of how to draw diagram by text. It is in fact today my favorite UML drawing tool. It is for me the fastest one. And since it use text file, it is easy to manage under revision control aside the code as any source file. But it remains far away what I dream for:

it is finally a drawing tool only. It is not designed to do anything else even I don't see anything preventing the addition of some cool feature looking like the ones described above.
the syntax is not so convenient. It is quite easy to learn because it tries to match the UML drawing. Going back to real UML concepts should be better.