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.
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.
For class diagrams, I have a little python script that takes a language like:
Foo -> Bar
Bar *--1 Baz
Foo
- name : String
- flag : boolean
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.
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)
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.
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 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?
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.
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://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).
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.
UML is helpfull for comunicating ideas ,etc ... but i dont believe in RAD tools based on drawing class diagrams,these tools never work properly.
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.
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.
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).
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'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.
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.
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.
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.
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>.
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.
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.
- 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.
Sometimes I think the implementation is just wrong - because programmers are obviously voting with their fit.
A modern replacement for UML, anyone ;-) ?
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.
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.
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.
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.