I've just been reading about TextUML, which is a language and IDE for textually defining UML diagrams by a start-up company called abstratttechnologies.
This seems like both a stroke of brilliance and painfully obvious. It makes me wonder why UML isn't already defined in terms of a serializable language. The big advantage of this I think would be the ability to have a clearly defined semantics. In the past when reading about UML I've been quite frustrated by an apparent lack of rigour in the definition of the various UML concepts and diagrams. It's always seemed to me that a metalanguage like UML is more in need of fully-defined semantics than application languages. Most (all?) application languages after all are executable, which gives provides a final authority for the meaning of a program written in them - run it and see what happens. AFAIK UML isn't really (or not conveniently) executable in the same way.
Which brings me to the paradox promised in the title of this post. One of the claims for TextUML is that it is easier to write and express complex models in than a purely diagram-based UML tool. I can easily believe this - developing a complex model by diagrams seems cumbersome and limited compared to writing a textual description. And I think this generalizes to the concept of visual programming in general. We've had easy access to powerful graphics capabilities for over 20 years now, culminating in today's basically unlimited in graphical capabilities. In spite of this, text-base programming still rules the roost when it comes to expressiveness, flexibility and speed.
So the paradox is: why is a 1-dimensional representation more powerful than a 2-dimensional representation? To put this another way, why does a 1D representation seem less "flat" than a 2D representation?
For further study: would the same apply to a 3D representation? Or would a move to 3D jump out of some sort of planar well, and end up being more expressive than 1D?
By the way, abstratt is right here in l'il ol' Victoria, and the lead designer (and CEO) Rafael Chavez is giving a talk at VicJUG in March. I'm definitely going to attend - I suspect he may have an interesting take on this issue.
Subscribe to:
Post Comments (Atom)
6 comments:
This is not totally new, I've been helping Diomidis Spinellis on something quite similar some time ago, see:
http://www.umlgraph.org/
I still have access to cvs for umlgraph and guess what, one of the late committers is a certain "Rafael Chaves" (coincidence)?
What I've found using UMLGraph is that it's good for small diagrams, but breaks when there are lots of classes around due to the limited layouting abilities of Graphviz (the layout looks nice, but does not make much sense from a designer point of view) and due to the sheer amount of relationships that you end up having if you really reverse engineer all of them (like UMLDoc does).
Soo, works fine as long as you're designing, are in control of the diagram, and can accept whatever layout comes out of the tool, works less good when you move to coding and still want to keep diagrams up to date.
I tried to contact the authors or a real UML layouter such as http://wwwi2.informatik.uni-wuerzburg.de/mitarbeiter/eichelberger/SugiBib/ but did not manage to get them involved. Maybe things have changed in the last years, anyone knows of a freely usable UML layouter? ;)
Hi,
Creating diagrams from text is a nice thought, but it simply does not scale beyond the simple and trivial.
Believe me, I've tried. It's ok if you want to create a simple diagram of which you already know how it is going to turn out.
But if you need to change things afterwards or want to do some exploratory design, the approach breaks down.
I've tried it for sequence diagrams, and once you have to update it, it becomes too cumbersome. Plus you don't really see what you're doing : a picture's worth a thousand words as they say. Also, some elements like comments and comment connectors don't work from a text format unless you want to fiddle with pixel positions.
The problem isn't that 2D is difficult, the problem is that UML tool vendors have been doing a crappy job when it comes to usability, right from the start.
If you want to see what a well thought out way of interacting with sequence diagrams looks like and how easy it can be, check out my Trace Modeler.
If you're in a hurry, here's a 30 sec demo.
Let me know what you think of it, I'm always happy to get feedback!
Best regards,
Yanic
Great comments, guys!
@Andrea: Yes, I can imagine how layout is still an issue. No magic bullet there, it still requires manual input to get a nice, sensible diagram.
@yanic: I do actually agree with you that a picture is worth 1000 words. My post was partially motivated by my disappointment that visual programming has never seemed to transcend textual. But for modelling the situation is closer, and I do find that I prefer starting in the visual domain. And especially for sequence diagrams!
Sequence diagrams have a lot of potential, but they're so fiddly to update. Your tool looks like it might solve that problem, though - so I'm definitely going to have a look!
@ Martin: I am glad to learn you found the approach I took in the TextUML Toolkit promising. Will be looking forward to meeting you at the ViJUG meeting in March.
Note though that TextUML does not redefine or extend the UML semantics. It is just a notation for the semantics already defined by OMG.
I just added a FAQ section and hope that is more clear now. Here is a link.
Re: benefits - well, as a programmer I hate the point and click paradigm. I prefer a declarative approach that lets me use my keyboard.
Re: text vs. graphics - well, this is a bit of a complex issue. I have been meaning to write about it for a some time, maybe the time has come. The gist of it is that each approach has its own benefits and shortcomings. It depends on the needs of your audience and use cases.
===
@ Andrea: TextUML and UMLGraph are different things, but they sure are related. The TextUML toolkit allows you to create models. UMLGraph allows you to create diagrams. My involvement with UMLGraph is for separating input processing (javadoc'd code) from diagram generation. My goal is to be able to reuse the later capability. But automatic diagram generation for the TextUML Toolkit is a peripheral, nice-to-have feature only.
===
@ Yanic: please see my comment above - TextUML is not about creating diagrams, it is about creating models. My interest in UML is model-driven development: code generation, model execution. In those scenarios, diagrams are not relevant.
Post a Comment