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: 1602

Reply to This

Replies to This Discussion

Hi Neil,

I think the structure of Domain-Specific Languages can vary along two different axes: the range of variation and the notation. Variation is about the amount of freedom (opposed to guidance) you receive when modeling, notation is mainly your question, i.e. visual versus textual languages.

I think the appropriate structure of DSLs depend on the user. Experienced users and specialist may prefer a textual DSL, while unexperienced users and domain experts may prefer visual languages. A possible way to handle this is to use an intermediate DSL or a DSL with multiple concrete syntax definitions (enabling the rendering of different representations).
Thanks Johan,

I also see the utility of both graphical and textual descriptions in combination. For example, writing say component descriptions in text and then rendering them graphically (e.g. with Graphviz, Prefuse or whatever).

I think in general I prefer to write component definitions and their relationships as text and then render them as graphics for overview; rather than say draw boxes, get deep into edit menus, drag these boxes around, etc.. as in your regular visual modelling tool.

It has been proven already that UML, "the" graphical notation, is not expressive enough to be transformed into final code. xUML tries to solve that, but I haven't seen much adoption.

In an MDSD-alike methodology I am developing (ABSE), I use a tree as the underlying modeling method. In ABSE, graphical models are unnecessary, and textual notation is all that is used. However, I agree that many ideas and architectures are better expressed trough a diagram, so I am contemplating the use of graphical models that can be linked to any node of the model tree.
It has been proven already that UML, "the" graphical notation, is not expressive enough to be transformed into final code.

The problem is that you are seeing UML as a graphical language, but that is not really true.

Short version: a) UML has an abstract syntax that is notation-independent, and the semantics are defined based solely on the abstract syntax; b) the specification states that a UML tool can be considered compliant even if the graphical notation is not supported.

For the long version, please read this post.


I understand that UML can be considered the "face" of an underlying abstract syntax. Your TextUML software proves just that. And that's fine to me: I also prefer a textual notation.

Graphics are easier to memorize (ie: help you locate yourself in the project faster), but are also pretty and help to market products. Text is however more expressive.

I did not prove that UML is not expressive enough. I was just echoing the industry's concerns...
Thanks Rui,

Can you explain more (perhaps by way of example) on the idea of a 'tree' as a textual notation for describing a model.

Well, instead of using an unstructured graphic (like UML does), we use an hierarchical tree. Relations are not made up of connecting lines, but by tree branching.

This is a simplistic view. It gets a little more complex than that in real world development.

Of course, having a tree implies some kind of graphic (a tree is, after all, a graphic), but as you know, textual trees (those we find on almost every non-trivial application, like Windows Explorer, Eclipse, Visual Studio, etc...) can be created and managed in a non-graphical way. This gives you some agility.

How to make this tree "work" for modeling, that's another story. I'm betting on presenting this methodology (ABSE - Atom-Based Software Engineering) as a world-first during CG2009, so I won't go into much detail before that.
Thanks for mentioning the TextUML Toolkit, Neil.

"generating UML models from code rather then the other way around"

A UML model described using TextUML is not really code, it is still a model represented using a textual notation. So when you use the TextUML Toolkit, you are not "generating" UML models, you are composing them natively, the only difference to the other UML modeling tools out there is that you will be using an alternate notation.


Thanks for your reply Rafael. I agree it's not code as such...

Where do you see the primary utility of your product? I could imagine its a nice way to develop a meta-model without needing to use graphical tools.
Well, you can see it as just another UML modeling tool, but with a developer-friendly notation, and a focus on creation of UML models for model-driven generation. The main purpose for such models is not communication/documentation (UML as sketch), but software specification (UML as blueprint/programming language), and in that case I strongly believe that text beats the hell out of graphics. You might wnt to take a look at this post on the modes of UML and relationship to tools.


I meant "UML models for model-driven generation development".
Thanks Vlad,

I have to confess I'm not up on UML modelling as much as I'd like to be so I'm not sure how sucessful it is in real world projects. Would there be a lot of complexity in creating the adapters? My feeling (based on my admittedly limited knowledge.. so please correct me!) is that UML models contain a lot of information that's often redundant for generating code (e.g. presentation details.. i.e. how the UML is presented in a graphical editor)... so how could we say think about writing a textual description for some model and then load it into a UML tool and visualise it? Do we assume some default kinds of views (like Graphviz does it?)... or do we just enjoy the benefits of the UML tools which aren't so related with the presentation content (e.g. code generation)?

hope I make sense... ;-)





© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service