Time for UML tools to evolve There's an audible rhythm to development tools. Modern integrated development environments (IDEs) go like this: tap, tap, bam! Diagramming tools go like this: point, click, pause, point, click, pause... Now that the two are starting to overlap through things like UML plug-ins for IDEs and round-trip engineering as standard, …
Come on Matt. Don't tease us with throwaway statements like "while they're being left behind in terms of productivity, though, modeling tools are making headway with advanced features...". What does productivity mean for a UML modelling tool?
Number of A4 pages per day? Number of lines drawn between boxes per hour? System features deployed to customers per week? Money made from the system per financial year?
Define your terms.
I have read many articles on the benefits of UML and how it can save the world (or at the very least, save your project), but real-life experience has been very different.
I work on a contract basis, and as I've worked for many different companies in my time. I have lost count of the number of times I have been asked "so, what's your UML experience like then?". A perfectly reasonable question. However, next time you are asked this, ask "why? Do you use it? Does it work for you?"
And therein lies the rub. In the real world, many projects start off with good intentions of using UML models and the various (usually very expensive) tools needed to generate them. In every single case I have experience though, the use of UML (and especially the use of the tools) has failed. the top reasons for this are as follows:
Time. I have seen this many times. The project starts off with good intentions, modelling everything. After a few months, someone points out that there is a deadline looming and shit, we don't actually have anything to show for it. Using UML to it's full is simply way too expensive. It simply takes too long. And once you have your UML model (assuming you've not given up on it long before, which you probably have), you then have to write some code that actually works and does some real-world stuff. More time. More expense.
Which brings me on to the next problem - the tools are just not good enough. Of course, this is what you are addressing in this article, but they haven't been good enough for absolutely donkey's years. I don't know why this is, and I don't know why the writers of these tools think they ARE good enough (or why the people who buy these tools think it's a good idea). As a general rule, your average UML tools is :-
* Incredibly tedious and slow to use. As you say, "point, click, point, click...". But "point click, point click..." is REALLY tedious. It's REALLY slow. It's REALLY inefficient. Of course, this isn't just a problem with UML tools. For many applications, the classic (generic) windows GUI is a very inefficient and a very very slow way of working. I can put up with it to write a short letter in a word processor. But developing an entire software project? No way.
* Half-baked. Many of these tools allow you to draw your blobs and link them together with arrows and stuff. They let you draw your sequence diagrams etc etc. Great! Until you get down to the nitty gritty and then it's incredibly difficult and incredibly time consuming to express the subtleties of your system. Sometimes, what you want to express is simply not possible in the confines of the modelling tool. Sometimes, it would take you a lifetime to do it so it's totally unrealistic. You end up embedding lumps of conventional code into the model to express what you actually want to do. This is infinitely worse than coding the thing up in the normal way, because what you end up with is a model that has lots of important detail scattered all over the place. It then becomes very difficult to understand the whole, or even be aware that more exists. It becomes very difficult to see the (often) subtle connection between components of the model. Ok, you can annotate the model so that you don't loose track of what's going on, but again, this just adds noise.
You may have gathered by the above that I'm not a big fan of UML and even less of a fan of the tools that are available. Quite frankly, I have never seen a successful application of either. I'm not saying there ARE no successful applications. I KNOW that there are. But the cost factors, the incredible amounts of time involved, and the mess that you usually end up with is, in my experience, simply not worth it. So, "why? Do you use it? Does it work for you?". Answers to these questions range from "no, we don't use it, but we're planning on doing so", or "we have used it in the past, but it wasn't very successful", or "yes we use it - it's really good" (but when get down to it, it's been used in a very cursory way and even then hasn't been particularly useful).
Maybe I'm a Luddite, but to me, UML is the Emperor's new clothes, and I have yet to see a realistic, commercially cost effective, application of it to any great extent. I think It's a GREAT idea. I WISH it were true. But in reality, it simply does not deliver the benefits it's sold on. it just doesn't work anything like well enough.
UML has no practical purpose.
It cannot be used for real modelling.
If it can be round-tripped it is just another representation of the code but graphical diagrams cannot scale up as well as text and we already have excellent tools for working with code (as the article says).
It could be useful to support informal discussions about designs, except that it's not very good for visualising object-oriented software.
We use UML, but we learned a long time ago that you mustn't go mad with the detail or it kills you.
The tools are almost all crap - and expensive crap, at that (except for Sparx Enterprise Architect which is reasonably nice and very cheap, and no, I don't work for them).
Nowadays we use UML just to illustrate the key ideas and the basic structure of what we're doing, plus some of the really important sequences or state diagrams etc. The rest of it we describe in good old Word docs and then we use Doxygen output to define our interfaces.
It's not perfect, but it's a compromise between having everything modelled to the Nth degree or having nothing at all (which is equally nightmarish on a big system).
Round trip engineering, in C++ at least, is in the same category as Father Christmas and the World Peace as far as I'm concerned. Great concepts, but I've never seen any of them in real life. Next time a sales rep comes round to show you their whizz-bang system doing round-trip engineering of either traffic lights or a vending machine, I suggest you slap them repeatedly until they see sense.
We have had some success with Use Cases for requirement capture and linking this to acceptance testing. No real exploitation of tools though other than drawing stick men and bubbles.
Also had a little play with the robustness modelling outlined in a previous Reg Developer article. Wondered if anyone had given this a go or could recommend a good free tool other than whiteboard and pen?
Cheers
(same AC as "If only" above)
"Nowadays we use UML just to illustrate the key ideas and the basic structure of what we're doing, plus some of the really important sequences or state diagrams etc. The rest of it we describe in good old Word docs and then we use Doxygen output to define our interfaces."
Exactly! And this is very much typical of the extent to which anyone gets to use UML in the real world. As you say, it's ok (ish?) to model the very high level system, but as soon as you try and add any kind of detail (ie - the stuff that would make it truly useful), the tools can't hack it, and (probably more importantly) the poor old engineer can't hack (the tedium of) it either.
One other bullet point I meant to add previously, was about code generation. Without going on too much (I know I do, once I get going!), code generation DOES NOT WORK. It doesn't work because the model is never good enough (for reasons already cited), and it doesn't work because the actual code generators are crap. If you've ever actually looked at some code generated from your average UML tool, you'll know what I mean; it's enough to make you run for the hills! It's awful; name your criteria, it's truly truly AWFUL!
If there was a "Bin UML for anything other than very high level stuff, because when it comes down to it, it's actually a pretty rubbish idea" campaign, I'd sign-up to it like a shot (as an AC or course :-) )
I've written and designed systems for 28 years now in almost every field of IT there is. (Military, Space, C3I, Distributed, Retail, Trading, ECommerce, Telecommunications, Gaming, Health, Datawarehousing, etc.)
Outside of realtime safety critical systems, the only thing that ever works reliably for me is...
a. The design document is a prototype. (The users can see it.)
b. A short step iterative lifecycle. (The users can see it going wrong quickly.)
c. A periodic refresh to dig out the creeping featuritis. (The users aren't involved.)
Everything else is basically created by people to make money for themselves, not to solve your problems. Object relational technology seems to me only to exist to sell books, hardware and middle tier training courses. Just look at "Design Patterns" for instance. Modelling tools are an aim in themselves.
Some things, such as development of a Datawarehouse, can't be done any other way than evolutionary.
That's a good point Mr Coward.
The way I look at it is this - I don't trust a fairly large percentage of human developers to write decent code, so why should I trust some half-arsed UML tool?
Having said all that, I do like UML for the things it's good at - like showing you what a pattern looks like, or where your module dependencies are, or how your system components are wired together.
I think one of the reasons why systems become more complex and nasty than necessary is because programmers often don't have a visual representation of the mess they are in (or have created). So we need some kind of UML, even if "our" UML isn't it.
There was a recent Reg thread about Crystal Reports, which attracted a surprising (and entertaining) amount of bile from developers forced to use it. One very common theme was that it was brought in by pointy-haired manager types as a kind of universal panacea that would cure all ills for them. I think UML tools are very much in this category. Out-of-touch management types are always looking for that magic bullet that will take care of troublesome software development problems for them, but we all know there's no such thing.
Ok, so first I've never actually seen round trip engineering work well. You can usually do it 1 full cycle. After that you usually start getting strange artifacts. For example, methods you removed from a class previously magically reappear. Types mysteriously change. Declarations are lost. etc.
Honestly the tools are not much better than in the early 90s when I used betas of Software Through Pictures on Sun workstations. Which really shouldn't be the case.
By now I should be able to define a set of interfaces, some data classes, and some sequences and have it generate optimized and parallelized code for deployment on a grid computer.
Oh Hypercard, why have you forsaken us?
I've been using UML for a number of years now and have worked with various tools. I think that the mistake that many people make with them (and UML generally) when they first start is to believe that somehow they can make the uber-blueprint of 'the system' and then show their pointy-haired boss "look, this is the complete unambigious design for the system". Following the agile principles "model with a purpose" and "when stuck, iterate to another model" drastically improved my productivity in this area because I started to think about what I was trying to describe with the model rather than to try and describe everything at every level of abstraction (the point where many people get bogged down and give up).
This is all fine and dandy until you start to use tools which are trying to be clever. When all I want to do is make a quick model and save it I don't want dozens of pop-ups/warnings about this n that and be forced to put classes into packages etc, this just impedes me and my goal to capture an idea and communicate it quickly.
Round-trip engineering? Enough's already been said about that - I'd settle for decent reverse engineering with good automatic layout of classes/components etc - that way i'd be able to quickly generate "The UML" that's been promised as a project deliverable to someone who won't even understand it (don't even get me started on that one)
Two things, one on the article and one on the comments.
Firstly, Matt is dead right about the mouse being a crap interface to modelling tools. I've been doing back end code for modelling tools for a long time, and I always hated using the mouse. My hopes were briefly raised that the author would suggest something else, but I'm not sure that "lots of keyboard shortcuts" really does it. Things like multi-touch GUIs and tablets would probably help, but there is some deep thought to be put in on this and no one seems to be thinking about it at all at the moment.
Secondly, round trip engineering is *hard*. A lot of the back end code I mentioned was round trip engineering in one form or another, and the only target that ever really worked properly was the database structure one. Otherwise you need things like ID labels for code elements, or wild guesses about what's just been renamed on the file system. Hideous.
Having said all of that, I rather like UML - I've been using it in anger for ten years or so and it has served me well for describing interactive and event-driven systems. My approach is to model enough to understand the system before getting on with implementation. The bits I use are:
- class diagrams: useful mainly as a pedagogical tool, explaining the parts of a system and providing the vocabulary for the implementation.
- sequence diagrams: understanding object life cycles and timed interactions between those objects. A critical diagram for me, also rather annoyingly the last one often implemented in modelling tools.
- communication diagrams: similar purpose as sequence diagrams, but better at capturing order of messages in a clear format.
- state transition diagrams and their ilk
But I have to agree with the majority of posters that the tools really aren't good enough and yet they still cost as much as minor surgery.
To all the people complaining how much UML-tools suck :
Why not write down explicitly what it is you don't like about 'your' UML-tool? I certainly agree with you, but if no one writes down what exactly is wrong/missing, don't expect much change.
And furthermore, the vendors that do a better job are never recognized because there's no 'metric' to compare..
I did it for myself when it came to sequence diagrams and simply created my own tool : Trace Modeler.
See http:/www.tracemodeler.com/download/index.html#demo for a 30 sec demo.
If you look at the kind of actions you do to a sequence diagram, add an activation, move an activation, move a target, ... I'm pretty sure that Trace Modeler makes it easier than any other tool : simply count the number of clicks/drags you need to do for a change and I'm confident Trace Modeler will come out the more productive tool.
What I'm trying to say is, define your typical scenarios of things you do with the tool, and write about how much effort it takes. It gives UML vendors something to aim for!
I agree with the remark that some UML-vendors are not eating their own dogfood and display little sense in what they produce. I created Trace Modeler in about a year (after hours!), and the reason Trace Modeler lets you be productive is because I've drawn my share of sequence diagrams and I knew what was needed.
So imagine what a big corporation with a decent budget could do if only they had some kind of vision on software development.
Btw, next month I'll be releasing something really new for sequence diagrams that will be truly awesome, so keep an eye on the rss feed at the site ;o)
of UML.
I always find myself doing diagramming in a bastardised hybrid of DFD, ERD and JSP notation*, which is basically what UML is anyway, only with those bloody annoying stick figures and all that puke inducing cutesy language grafted on.
In keeping with the spirit, although not the letter, of all the recent XP/Agile/TDD bollocks, I find it's usually best for your team to cherry pick the bits of stuff that work for you, and sod the rest.** Fully embracing UML for example, requires you to implement your process around it's concepts, which to me seems the wrong way around, but some version of those horrid playschool-esque stick figure pictures can be useful for communicating with non technical people, YMMV.
* I'm not /that/ old, it's just that most of my lecturers were SSADM fetishists and/or former COBOL programmers.
** Pair programming ? You lean over and type into any code I've got checked out and I'll chop your bloody hands off, sonny Jim.
Like here. I've always been suspicious of UML and so never invested the time to learn past the basics because I never got a concrete impression of what it did and what real value it added. Now I know why.
Listening to experts is always a pleasure. Thanks all.
"Why not write down explicitly what it is you don't like about 'your' UML-tool? I certainly agree with you, but if no one writes down what exactly is wrong/missing, don't expect much change."
Actually I have done this many times and I have gone further too - I have worked closely with vendors on several occasions to try and improve their tools.
The fact that I did so, and that you asked that question, shows that we have both demonstrated a remarkable but unfounded optimism in the abilities of UML tool companies.
The old stuff worked.
Booch's clouds were easier to distinguish from all the straight lines joining things.
Responsibility-driven Design, CRC cards and the other OO modeling stuff invented back in the late eighties still works better than UML-based modeling when it comes to seeing what happens in a system and auditing the bloody design!
I really struggle to see how anything much added in the last twenty years in diagramming has been a step forward for users, as opposed to owners and shareholders of companies selling seminars, books and tools.
However, I *DO* believe there is scope for massive improvement in modeling usability. I just haven't yet worked out how you can build an business around it given UML dominance. Better UI and ability to cope with variation as you design will help for a start!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
