UML in Practice | Hacker News Reader

UML in Practice

neverworkintheory.org

47 pointslsinger47 comments

Is the formalism of UML actually useful?

I don't think I've ever done a collaborative software project without scribbling some boxes representing system components on a piece of paper. Sequence diagrams are also quite useful (instead of showing who has a reference to whom, you're showing flow of control).

But, once the understanding has been passed on, the documents get scrunched up and chucked in the bin. No-one worries about representing the minutae of inheritance on them. I certainly don't see the point of showing them to a customer.

I'm with you on the proper lifetime of diagrams. They should be preserved only until someone else needs the whiteboard.

Even so, I happily took a little time years ago to learn UML basics, because I needed some notation for my whiteboard sketching, and having a common one seemed better than just everybody making up their own. (Even given that the one that I made up would of course be superior.)

I've never regretted it. It's sort of like blueprint symbols. I never do more than sketch out a couple of rooms. But I'd still rather use the standard symbol for a door or a window or a toilet then to screw around coming up with my own, and then hope others can figure it out.

If anybody wants a quick UML intro, I strongly recommend Martin Fowler's book: <http://martinfowler.com/books/uml.html>.

In practice, and I mean at mega-corps with government contracts that require UML diagrams for everything I've seen this as a common pattern:

1) An EA is hired who gins up a stack of UML diagrams which are sent for review and acceptance by the customer.

2) The system is then actually designed and built regardless of (and often despite) the accepted UML diagrams.

3) The built system is then documented in a new stack of UML diagrams by the EA which are then delivered to the customer as if the first stack didn't exist.

The problem in the industry with UML is not #3, UML can be a great way of describing a complex system, the problem is #1, UML is a terrible way at blueprinting how a working system will look like in the end.

UML is just a notation. It is great for blueprinting software (except that graphics create problems, and UML is graphical), it makes no difference if they exist or not.

The problem is that people are terrible for blueprinting sotfware that does not yet exist. Whatever notation you choose, the problem will still be there.

> The problem is that people are terrible for blueprinting sotfware that does not yet exist.

I agree, in addition the people who usually are doing the blueprinting usually don't really know much about the nuts and bolts of actually building software (or haven't built any in a very long time).

The worse problem is that the stack of UML diagrams in 1. is sent offshore to be implemented verbatim by many junior people working in parallel and in isolation, a manual test team produces thousands of bug reports on the resultant ball of mud which are then hastily patched over with sticky tape, and the whole sorry mess is hailed as an exemplar of software delivery process for being made to hobble over the line without exploding.

In school, UML seemed like a great idea. It wasn't very fun, but it was useful, and if you had a simple class project, UMLs certainly made things simpler if you were even okay at them.

When I got my first job, however, there were no UML diagrams. I was saddened to see this. I don't remember if I was surprised, but I was so sure that I would been useful to have a detailed UMI diagram available for studying the codebase.

So, as I got acclimated to the codebase, I took it upon myself to start putting together a UML for our existing product, so that training new people would be easier. After spending several days doing this, my opinion or UML changed dramatically for a couple of reasons:

1) Pretty much all of the UML tools out there are not a pleasure to use. Drawing UML diagrams was still infinitely better than using the various programs I tried. But drawing them on anything but a whiteboard wasn't scalable to the size of the project.

2) Once I had the basic classes drawn out, and realized how diverse the kinds of classes we had were, it became apparent that this just wasn't going to happen. A basic flowchart of the application would be equally valuable. The specificity of UML wasn't worthwhile, having a class with 10+ subclasses was a mess.

3) What I did have was hard to see. This goes back to the first point--the tools are not good. When you labored over all the clicking and dragging, you pulled together this monster of a graph that you can only see a small portion of at a time in a given screen. It was easy to get lost. Printing wasn't useful.

Ultimately, I only ended up using UMLs when we were thinking about how we were going to build out new features, or redesign stuff. It was a .NET shop building a Silverlight app, so serialization and strict static typing was critical. A decent JSON api would have made life easy, but since the back end and the front end were essentially all the same thing, class diagrams were very useful. So for the 2 or 3 times that we had to develop or redo class serialization while I was there, it came in handy only for working on small 2-5 class models.

That brings us to the next point: do class diagrams have a place in an increasingly dynamically typed world? Functional programming in javascript. Frameworks that have their own detailed class system, or which aren't even class oriented.

UML has essentially become analogous to cursive. You learn about it early on, and its important to have a notion of how to read it. But ultimately, since we don't use it every day, we basically never use it.

Have you tried Umlet http://www.umlet.com/ ?

Looks promising, Thanks!

wow this looks remarkably good...at last somebody "gets" why incessant mousing around and piling through menus is a bad way to do things.

Thats actually what I had settled on using, and I think its a fine tool. But even umlet doesn't make writing and viewing large UML diagrams...pleasurable? In the sense that we have tools like vim, word, excel, and chrome that are very polished and allow you to get to work quickly and accurately. Even with umlet, i find myself worrying about the interface too much.

I suspect its more of a problem with the fundamental design of UML though. I think if there was like, a UML-lite spec or something. To me, i feel like UML is to what I want to use as XML is to JSON (or csv for that matter), if that makes any sense.

(plug starts)

Can I also suggest Kite9?

www.kite9.com/kite9/gui.html

Which does automatic diagram layout. It's not quite doing UML yet, but a reasonable approximation thereof. It's more visual/drag-and-drop than UMLet.

I intend to include a suite of actual UML symbols within the next week or so.

Hopefully this will be useful to you!

(end plug)

A uml design tool could easily be created in the browser , with export to different languages ... a few weeks ago i began building a class diagram designer ( uber limited ) http://umldesigner.herokuapp.com/ , as a proof of concept . Lucidcharts provides a more complete one.

UML is helpfull for comunicating ideas ,etc ... but i dont believe in RAD tools based on drawing class diagrams,these tools never work properly.

Thanks for the mention of Lucidchart (http://www.lucidchart.com). If there is any specific feedback on the app, would love to hear it -- and good luck with your tool!

There was a post, a little while ago, asking why developers disliked creating documentation. The only response that resonated with me was the double-work required to keep it in sync with the code base. The same can be said of UML and ER diagrams. Only the round-trip tools feel worth the effort to learn, because you can choose to use them when they are useful to you.

> Once I had the basic classes drawn out, and realized how diverse the kinds of classes we had were

You'd think there'd be a tool you could point at your repository and have it spit out appropriate UML. As a set of description diagramming techniques UML can be useful.

OT: you write "UML has essentially become analogous to cursive. You learn about it early on, and its important to have a notion of how to read it. But ultimately, since we don't use it every day, we basically never use it."

I come from Germany, where nearly everybody handwrites in cursive for text longer than a few words. And I must say: it's a lot faster than writing in block letters (of course writing in shorthand would be even faster - I don't understand why this isn't taught in schools anymore - my father could and took this as elective course).

So: what is the reason why writing in cursive is disliked in the US?

You usually learn cursive around the age of 7, while the teacher insists that cursive is all you will ever use once after that. In high school, I was told all the time that they only accept cursive in college.

I think the movement away from cursive is relatively recent, and entirely associated with the fact that virtually no teacher or professor will accept work that isn't typed up. You learn cursive in 3rd grade, then from there on all of your work is done on computers so you never reinforce it.

I had to look up what cursive was, for me that's just what you call handwriting. Are you saying that there's a move towards non-joined up handwriting?

In America, what you call "non-joined up handwriting" we call "handwriting". I don't know anyone (anecdotally) that uses cursive on a daily basis except for signing checks and contracts.

Non cursive hand seems like an incredibly slow way to write, impractical for classes etc. is this because everyone is bringing a laptop to class and just doesn't write much at all? I'm from the UK and as far as I know they still move kids into cursive as soon as possible. From personal experience at school I recall the quality of my writing was dramatically improved once I moved to a computer so I can understood a move in that direction. I'm just surprised cursive isn't still used because for note taking situations it is still incredibly useful.

Handwriting generally refers to both joined and non-joined writing. If there is a need to distinguish, usually people say cursive or print. As in "Print your name and sign below..."

Cursive in my experience is very difficult for someone other than the writer to read- even when it is written neatly, it is more difficult to read than print or type with a decent font selected :)

at least when i last had to use them, none of the free uml tools were much good, but enterprise architect is not very expensive (at least in some editions) and surprisingly good. it would probably have been able to auto-create your uml for you from your code base, for example. and it's much more than a diagram editor - it's a tool to help you construct a "database" (in some abstract sense) of your design, which can then be rendered in various ways (as diagrams or code).

http://www.sparxsystems.com/products/ea/ (i've never used uml "from end to end" - in terms from the article i mainly communicate with shareholders. i'm also unrelated to EA - just have happy (well...) memories of it. in fact, apart from intellij idea, it's the only software i've ever paid for, i think).

> That brings us to the next point: do class diagrams have a place in an increasingly dynamically typed world?

I think so, at least in environments where OOP is the base metaphor, like Ruby or Python. I can't think of any major impedance to creating meaningful class diagrams for, for instance, a system of ActiveRecord relationships. RubyMine (last time I used it) actually will generate a nice class diagram for you based on the given ActiveRecord/schema definitions.

For me these days, since not many coders use it, I find UML mostly helpful as a personal tool I use to understand a new codebase or a complicated design/data modeling problem.

I also find sequence diagrams really helpful, particularly in complex async, service-oriented environments where many times there's just too much state to track and too many moving pieces to really see the essence of the problem.

UML is not everybody's cup of tea, but I continue to find it a valuable way to visualize complex code relationships, often times surfacing problems/solutions that would not have been as transparent just from reading the code.

I was sitting on a swing today, thinking about this line of thinking. UML is getting out of date, I've thought so before:

http://www.kite9.com/content/muddle-uml

I've also thought about what I would like in a modern visual language, but all of that was from a strongly-typed (typically Java) POV.

Having spent a lot more time with JavaScript & Ruby recently, I am now thinking that surely there is a need for a notation for dynamically typed languages. What the hell would that look like though? Anyone interested in trying to figure it out with me?

I had a similar experience. I've found a good happy medium is Graphviz. It's a bit different in that rather than drawing boxes and arrows on a canvas you edit a .dot file in your text editor and then have the tool do the layout and rendering. Having the layout happen automatically leads to some not-so-great looking graphs, but it ends up saving you a lot of time. Simply putting arbitrary text in nodes and connecting them via labeled edges gives you a lot of flexibility. When a graph gets too big and unwieldy (20+ nodes), I just split it in two. I'll color a node red to indiciate that there is more information about that node in another .dot file.

You do have to learn the .dot syntax, but it's nothing too crazy. A nice bonus is (at least with the OSX version of Graphviz) every time you save a .dot file via your text editor the renderer automatically re-renders the graph for you -- so you can make quick edits and get that instant feedback.

I like using graphviz for visualizing existing code and data. I write a script to generate the .dot file, maybe tweak it a little, and render with graphviz. I've used this for our data model, ER diagrams, jar dependencies, brew package dependencies, etc.

For class diagrams, I have a little python script that takes a language like:

   Foo -> Bar
   Bar *--1 Baz
   
   Foo
   - name : String
   - flag : boolean

And turns it into a diagram. (gist: https://gist.github.com/dunhamsteve/5274411 )

Of the free GUI tools, BOUML (the old, open v4.21 in Fedora 18) had the best combination of available UML components and editing flow. BOUML was restricted/automated enough to give me the impression that I was describing relations more I was drawing them.

However, at the end of the rainbow I found PlantUML. PlantUML renders nice graphs using a GraphViz/Dot-like language and affords all the benefits of being plain text - revisions are intelligible, syntax is highlightable, and edits flow at the speed of Vim.

http://plantuml.sourceforge.net/

I've never found UML useful for diagraming an entire application. However, I don't know if this is a fault in UML or a problem with the application architecture. Applications tend to get large and disjointed. They solve multiple problem sets and consist of several different layers. When we try to take a complex system and put it into a UML diagram things get really hairy fast.

UML is more useful when it is used for diagramming the components of systems. This practice also promotes the practice of identifying and decoupling system components. When complex problems or unfamiliar patterns emerge, UML is indispensable.

Still the biggest issues I've observed with UML adoption are: 1) A lack of tools developers want to use. 2) As developers become familiar with the codebase (you know, by writing it...) they begin to think it's self explanatory tedious documentation efforts like UML are unnecessary.

Ten years ago I spent a semester essentially learning UML and it's components. We got a lot of practice designing classes and using the CASE tools to generate code from them.

Since I graduated I've only ever run into a shop that uses UML once. They paid for Enterprise Architect and I was impressed at how useful the idea of UML is for documenting and architecting software.

I feel the big trend has moved towards spending effort around requirements definition and clarification thanks to Agile. By the time that's done it feels to me that creating UML artifacts is doing double-work when you could be coding instead. There's also inconsistent tooling and its associated monetary expenses.

UML slices code oddly.

You can't fit a big system on a piece of paper. So, let's say you have a big graphics system. One of your base classes is Widget. It is almost certainly worthless to show every class that derives from Widget on one page, even if you could. What you are really interested in is how subsystem interact when in various states. For example, you might have a map window that uses a small collection of items derived from Widget, some strategy pattern type things (to project to Mercator or whatever), and so on. The only useful graphic is a sheet that shows how all of these components interact. But, maps are complex, so you are probably pulling in and using 100+ classes. Most of which are not relevant. So it takes a human, and a lot of thought, to figure out how to slice through the code to produce a useful UML diagram for the area of interest.

And then the diagrams are static. You have a bunch of other stacks of paper to try to show how things happen in time. Typically there are several scenerios - each scenerio is going to involve a different subset of classes.

Its combinatorial explosion. No one can do this. Its far more work than writing and debugging the code itself. The code IS the documentation, for better and worse (and yes, sometimes it's worse).

So, like most people, I do whiteboard sketches of high level design. If I am particularly pressed, I'll sit down with pen and paper, sketch 2-4 competing UML diagrams, then hand write in different transactions/events - showing how data flows, and so on.

But capturing an entire source tree? Impossible, unless you just want the spaghetti diagrams that are not displayable on any monitor, and that are completely useless at telling a story.

I agree, the whole picture obscures the whole picture.

But having the whole picture without looking at it is useful. In doxygen, for example, you can capture an entire source tree, but then only zoom in to areas that you're interested in. You get the flexibility of seeing any portion of the whole that helps you understand.

Generating something like that before code, though, is a waste of time. Unless it's a government contract, and then it's profit.

I work on corporate level custom webapps. The main two areas where you have to be careful to design things correctly and to be able to convey your ideas to end users (in clear, unambiguous terms) are - in my experience, at least:

- Database design

- (Web) Interface design

Oddly enough, UML provides zero support for either. So it's always DBA stuff on one side and mockups/wireframing/prototype on the other. Especially to discuss user-front things (i.e. how the application will look and how you will work with it) UML is completely useless.

These are our primary concerns, and UML does not help at all. Use cases are too abstract, and the rest is of little value for the users.

So despite my attempts at learning it, I was never able to get any real value out of it.

Also, have a look at this to better explain my problems in using UML for practical purposes: https://files.ifi.uzh.ch/rerg/amadeus/publications/papers/IW...

I spoke at Code Generation 2010 in Cambridge about 'roll your own' code generation solutions and some examples of how I'd used them to reform an existing software development process.

While most people there were UML junkies, and the UML designing 'Object Group' were also in attendance, I still used the phrase UML hell during my talk which garnered significant cheers from the audience.

My conclusion was that there are often all sorts of useful, formal models just lying around and UML isn't necessarily the best thing to rely upon. Three useful and IMHO often overlooked examples of 'free' formal models are: software dependency trees in package managers, directory structures, and database definitions.

Trends come and go. Even the strongest software engineering trends seem to last about 10 years.

More than 10 years ago, I worked on a tool called ArgoUML. Years later, check out what I was surprised to find on YouTube: http://www.youtube.com/results?search_query=argouml

Tons of fairly recent videos of how to use ArgoUML. Mostly in Spanish, Portuguese, or Vietnamese.

Graphical modelling is an incredibly powerful tool, and it saddens me that UML is not valued more by hackers. I suspect one of the reasons it's not used, is that people simply don't need it most of the time. When I started in software I was apathetic about UML, in fact I thought the whole thing was a bit silly. I used the occasional class diagram to communicate an idea, but I could never see the point of modelling. Most of the time I know what needs coding and have a good intuition for how to implement it; but with experience, that has changed.

Only twice in my life have I had anything close to a religious epiphany: 1) the first time I tried psychedelics, and 2) the time I finally 'got' UML: I was faced with an enormously complex software project that was far beyond my level of experience and skill set, and I didn't have the faintest clue where to start... it was the sort of project that makes you feel slightly terrified and incompetent. After several false starts, I realised I needed to try a different approach, so out of desperation I dug up an old college textbook on systems analysis and tried to design the entire system on paper away from the computer. I started with a use case diagram, then numerous class diagrams, then sequence diagrams, then activity diagrams. In a matter of hours, I'd nailed the ENTIRE project, without straining my brain the slightest. I was ecstatic! It felt like I'd just acquired a superhuman power or a secret black art -- I'd transcended the capabilities of mere mortals, into the realm of gods! In that moment, I saw the essence of UML, and it was power! As nerdy as it sounds, it was certainly one of the most profound and memorable experience I've had -- taking something I knew moderately well (UML), and seeing an aspect of it that I could never have anticipated, and using it to solve a problem that was completely beyond me.

Saying all that, I should qualify that I'm not a UML fundamentalist, nor do I think everything should be modelled. People often criticise over-abstraction and "architecture astronauts", and rightfully so. There is an inherent danger to modelling, but if you're an experienced coder (and more importantly the person who's going to be implementing the designs, so as to stay grounded and realistic) then there's immense power in abstracting away the code and the limitations that come with "thinking in code". Under the right conditions, modelling enables you to see the essence of the problem and derive a well-structured solution. That, at least, is my opinion.

...and on the topic of Agile doing away with the need for modelling: the whole point of modelling is to enable fast iterations. It's amazing how fast ideas can develop with just a whiteboard and some thinking space. Why waste time coding?

I should also add that I think a lot of the criticisms of UML itself are fair.

I'm talking exclusively about using it as a problem solving tool before the implementation stage. I do wish there were better alternatives for graphically tracking and documenting large code-bases... or even generating UML diagrams for that matter.

One of the problems is that there's an awful lot in the way of "Architecture Astronauts" who sit down for a few days and build (in UML) a brilliant and complex system design that has no grounding in reality.

I remember vaguely one argument with an EA who had built a very nice looking system blueprint in UML, who didn't understand that several of the ways various components needed to interact either required very large amounts of computing power or an algorithm that didn't exist. "But I carefully looked at that in the sequence diagrams here and here!"

In the usual best case, when the implementation starts to diverge away from the UML (as it usually does), it becomes nightmarish to keep the UML synched to the codebase. It's usually just easier to wait for the code to freeze, then go in and document what's there...which of course is not really the point of UML.

I agree with everything you say, this has been my experience as well. UML, even a lightweight truncated version of it, is incredibly powerful. The graphical syntax is not that hard to understand.

The biggest benefit to me has been that it expresses object relationships, imo, better than code. At a high level it's much easier to visualize fundamental design mistakes or solutions when object relationships have actual shape. OOP, for better or worse, was designed to model real world objects, actions or relationships, and graphical shapes, rather than sequential instructions, express that best.

I've found class diagrams very helpful for visualizing complex domains, and sequence diagrams extremely helpful when modeling service architectures especially.

I understand why many coders avoid it, but I also think it's unfortunate that UML has the reputation it does. I read Martin Fowler's UML Distilled (and I still recommend it) years ago. It made sense to me then, still does.

The idea of UML makes sense - why not have a common graphical language for the things programmers want to describe to each other all the time?

Sometimes I think the implementation is just wrong - because programmers are obviously voting with their fit.

A modern replacement for UML, anyone ;-) ?

Someone in the thread above suggested the same. This needs doing.

I use the hosted version of websequencediagrams.com for sequence diagrams and that works out very well. I know that sequence diagrams are a very small part of UML but I find that they have an extraordinary effect on clarifying a system's design without too much effort.

Actually, I really like UML; I especially like swimlanes. Of course it doesn't make sense for every design but I find that 12 months later, a map to what I was thinking during the original design is invaluable.

was hoping for an article on user mode linux

That UML is used about as often these days as UML notation, given the availability of virtualization solutions like KVM. Its time has come and gone.

How do you document a web application?

Reply on news.ycombinator.com