Many people assume that drawing tools and modeling tools are two interchangeable concepts but this is far from true. In fact, only some tools are drawing and modeling tools at the same time.

Some modeling tools use a concrete textual syntax for specifying models (yes! not all models need to be graphical models) and thus, there’s no support for drawing them, even if they may be able to render the textual definition into some kind of graphical export format for visualization purposes. As examples, see this list of textual modeling tools for UML or any of the DSLs you can create with tools like XText , TCS , or EMFText .

On the other hand, many drawing tools are not modeling tools. In my view, a drawing tool can only be considered a modeling tool if the tool “understands” the drawings, i.e. the tool does not see just shapes, lines and arrows but understands that they represent classes, associations… At least this understanding should be enough to validate that the model is a correct instance of its metamodel.

For instance, in a drawing tool I could draw something funny like this:

that breaks all kinds of UML rules. The icons and shapes may be the ones defined in the UML notation but the model has no meaning at all

My recommendation is that you always try to use a modeling tool to draw models because of two main reasons:

  • Ability to export or manipulate the models using (external) access APIs provided by the tools. The API of a drawing tool will offer methods like getAllRectangularShapes but not a getAllClasses method which is the kind of API methods you’d find in a modeling tool and that you need to easily manipulate the models. Similar for the export formats. Drawing tools will hardly ever offers some kind of XMI-based export format that you can easily import into other (modeling) tools.
  • A modeling tool guarantees you a minimum level of quality. Of course, some do a better job than others (check our previous discussion on the poor validation of UML models in some Eclipse tools ) but still it’s much better than nothing.

At the end of the day, and for the same drawing effort, I prefer to have a model as outcome and not just a drawing, even if the model has just been defined for communication purposes. Maybe tomorrow you discover that in fact those models could be useful for prototyping or code-generation and if you used just a drawing tool you’ll need to redraw them again to be able to use the models as a part of a MDE chain.

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This