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.
ICREA Research Professor at Internet Interdisciplinary Institute (UOC). Leader of the SOM Research Lab focusing on the broad area of systems and software engineering. Home page.
I agree with you in the difference between both.
But you forgot to mention that most modelling tools have as drawback quite a bad usability. For instance, I still haven’t FOUND IN modelling tools the features, USER-friendliness AND aesthetic result that Visio offers me… NOT TO mention that the ability TO break grammar rules IS important FOR me while I am IN the process OF conceiving the model.
So, I END up USING drawing tools FOR conceiving models FOR the FIRST TIME AND FOR communication purposes (e.g. showing models TO clients, including models IN research papers). However, AS you commented, I re-do the models IN modelling tools once I am sure that I want TO use them IN an MDD way.
TO be honest I don’t really know why usability is not one of the key priorities in modeling tools. At the beginning I can understand they focused on other aspects but now usability should be a top priority for them.
Regarding the break of “grammar rules” or well-formedness rules, I’d say that there ARE SOME rules that can be skipped IN the early modeling phases but I believe that others must be followed FROM the beginning.
For instance, consistency BETWEEN diagrams (e.g. that a method called IN a sequence diagram appears AS well IN the CORRESPONDING class) IS NOT necessary AT the beginning but the rule that a class IS NOT a supertype OF itself should be always respected
Yes, bad usability is the worst thing a tool vendor can have: It immediately proves that he is not using modeling to create the tool itself. If he would do “boot-strapping”, i.e. modeling the tool with early versions of the tool itself, developers would quickly remove annoying glitches that block their productivity.
In addition, I think usability was not too high on project’s evaluation sheets FOR modeling tools IN the past. If we look AT UML this starts TO change through the advent OF low-cost modeling tools AND now by great improvements IN the Eclipse modeling infrastructure.
E.g. Papyrus UML still has rough edges, but I expect it TO have very interesting USER interface concepts by the use OF tabular editors, Xtext based editors etc.
I think, perhaps any of a drawing tool can also be used AS a modeling tool.
To clarify possible debate here, may be need to define the term “model” more stringently then the well recognized…
AS LANGUAGE workbenches mature AND it turns TO be quite easy TO implement DSLs. It IS quite frustrating after going through DOMAIN analysis AND DSL implementations TO see END users reluctant TO use new modeling tool due TO usability issues.
I do requirements analysis USING models. It’s not like in design, where you usually have some dev environment already setup.
Often in req analysis you are restricted to a standard workplace config of the company you’re IN. Even if you can convince people TO install SOME modeling tool somewhere (servers preferred, but NOT always possible) you have the problem OF a proprietary tool that NOT ALL people can/ want access OR WRITE TO. Such organisational CONSTRAINTS don’t make it impossible to use modelling tools properly, but much harder.
sounds quite dull, but fortunately there are also other kinds of working environments :o)
The real problem with both modeling and drawing tools is efficiency.
I can draw an UML like diagram on a white board in a matter of minutes. I can discuss it with my collegues.
We don’t have TO care WITH exact UML notation, nor WITH irrelevant details. AND because nearly everybody AS a camera ON it’s phone today you can keep it easilly.
Or you can draw the same model on your prefered drawing/modeling software and it will take you 30 minute, more likely half of the day to do the same things.
And then if after discussion the diagram change, it a lot of time lost in the software.
Because theses tools use a verbose format with ton of irrelevant infos (like graphical position, text color…), it is almost impossible to merge, so impossible to correctly manage on a complex software stack with lot of branches and actives versions.
If you use a textual model, derived from what you discussed on the whiteboard with collegues, you can really be fast, you can use your favorite SCM with no problem. If really needed for documentation, a really usefull tool would be to generate a diagram from the textual representation.
Check this list of version control tools for models . They solve some of the problems you mention
Guys! What’s with the capitalization for emphasive? Is it REALLY necessary to shout so much, something’s just shouldn’t be copied. It’s so school teacher’ishly condescending, stop it.
In fact, the capitalization is a technical problem we had when migrating this blog from Drupal to WordPress (before we learnt how to do it propery and create a company to offer this service to others: http://migratetowp.com ), as part of the migration some words in the text and comments were transformed to uppercase. I correct the problem when I run into a post where this happened but for sure, you’ll see still a lot of uppercases around.