The Model Driven Software Network

Raise your level of abstraction

Perhaps this discussion has been hammered to death over the years on other sites and at workshops, but I'm still interested in thoughts about this subject and I think its a great discussion point for the site anyhow.

1. When is a textual model preferable to a graphical model and vice versa?

I think in general there has always been a big push for graphical models over textual ones. Graphical models often look better, are more sexy and probably improve your publication rate :D.

But textual models are still highly prevalent. Many component languages still use a textual format, domain specific languages and so forth..

Textual models allow for a different kind of expressivity and detail... whereas graphical models provide overview often at the expense of detail. Often graphical models are used in situations which impede the usage... for example there was a push for VR driven databases a decade or so back.. the user would wear a helmet and then point at data items in their 3D universe which would generate queries on the back end. I don't think it worked as well as your regular desktop database client.

But then again textual models are often used in the wrong way too... for example I've seen pure textual DSLs for input of data that would be best suited to being in a form (e.g. medical records, reservation systems, etc.).

Some interesting links I've been to over the past day or two

Object mentor


The final one interesting as it mentions generating UML models from code rather then the other way around. It also mentions how its often faster to create those models textually than graphically.

2. Are there other kinds of models that are somewhere in between?

Talking about graphical and textual models... what other types of input models are often used? I've often seen models expressed in spreadsheet like form, or of course form based models (using text boxes combo boxes and the like). Then of course there are hybrid cases where graphical and textual models are used (which could probably include the cases I just mentioned).

What other kinds of input models are there for expressing a model?

Best regards

Views: 1567

Reply to This

Replies to This Discussion

Neil, you are confusing UML models with UML diagrams. You can have models without diagrams. You can even draw UML diagrams without actually ever having a UML model.

You might find this post I wrote some time ago interesting.
> drawing nice diagrams without a standard and robust model is a nonsense.

My impression was that most people use those diagrammatic tools just for the purpose of diagrams (for papers, documentation etc..) and don't think about MDD at all... at least that's how I and many people I know have used them in the past.
>Neil, you are confusing UML models with UML diagrams. You can have models without diagrams. You can even draw UML diagrams without actually ever having a UML model.

Yeah good points... although I did realise this ;-)
Nice link Vlad!

back in the 1990s when I was doing my initial studies I came across pre UML CASE tools such as SELECT

I only saw these tools back then as merely documentation aids (and not really particularly awe inspiring ones either to be honest.. the usability was usually dreadful)... though I am assuming they could generate something from those diagrams (maybe C++ code, but I don't remember generating anything or even it being mentioned).... or maybe not... from doing that CASE course it wasn't really clear why we were developing those models and hand coding everything (probably lack of a metamodel I would imagine).. so at least I can see a huge change since those old days..

........I wonder if anyone still uses Select Yourdon pro? :-o

I think, the best way of editing is a mixture of graphical (to show/edit cross references) and textual (to show/edit details) concrete syntax. And maybe others, such as tabular or form based editors.

The new version of Xtext - a textual modelling framework that is now a component in Eclipse modeling - will provide that out of the box. As it implements an EMF Resource, it allows to implement other EMF based editors (e.g. using GMF) on a metamodel generated out of an Xtext grammar. On save, textual and graphical representation will synchronize automatically, as long as all editors listen to changes on their underlying files.

The primary storage format will then be text. This is not only very convenient for merging and diffing in a collaborative environment. It also allows arbitrary metamodel evolution without loosing the ability to load/restore old models.

Best regards
I think it's true that there are some objective reasons for going one way or another in particular cases, but the cost of bringing both into an organisation by the second project is likely to be seen as unnecessary. Whatever you pick the first time around is probably what you'll use subsequently. If it worked the first time around you'd have to sell in a change, and the effort both to sell and implement change will probably be greater than the benefit in swapping over.

So I think you need to go with whatever best fits the existing corporate culture, and stick with it for the first few projects. Typically you can progress with that first kind of model even if not optimally and only when the MDD approach is ingrained should you look to vary.

Yes you'll be using the "wrong" approach some of the time. But it's worth it.


Regardless of how it's expressed, it seems to me that the more important question is whether or not the model in question is sufficiently precise to serve its purpose. Text can be transformed into graphics and vice versa.




© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service