7 ms·

UML in Practice

47 points by lsinger 13y ago

Yhippa 13y ago
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.
bane 13y ago
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.
- marcosdumay 13y ago
  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.
  - bane 13y ago
    > 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).
- dreamfactory 13y ago
  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.
aggronn 13y ago
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.
- styluss 13y ago
  Have you tried Umlet http://www.umlet.com/ http://www.umlet.com/ ?
jacob019 13y ago
was hoping for an article on user mode linux
- duskwuff 13y ago
  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.
GlennS 13y ago
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.
- wpietri 13y ago
  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> http://martinfowler.com/books/uml.html>.
QEDturtles 13y ago
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.
Pamar 13y ago
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.
- Pamar 13y ago
  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/IWSSD-10.pdf https://files.ifi.uzh.ch/rerg/amadeus/publications/papers/IW...
RogerL 13y ago
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.
- a3n 13y ago
  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.
eliben 13y ago
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 ;-) ?
- bobm_kite9 13y ago
  Someone in the thread above suggested the same. This needs doing.
ssn 13y ago
How do you document a web application?
contingencies 13y ago
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.
jrobbins 13y ago
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 http://www.youtube.com/results?search_query=argouml Tons of fairly recent videos of how to use ArgoUML. Mostly in Spanish, Portuguese, or Vietnamese.
biofox 13y ago
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?
- 13y ago
abawany 13y ago
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.
dykesa 13y ago
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.

47 points by lsinger 13y ago

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.

bane 13y ago

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.

marcosdumay 13y ago
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.
- bane 13y ago
  > 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).
dreamfactory 13y ago
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.

aggronn 13y ago

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.

styluss 13y ago
Have you tried Umlet http://www.umlet.com/ http://www.umlet.com/ ?

jacob019 13y ago

was hoping for an article on user mode linux

duskwuff 13y ago
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.

GlennS 13y ago

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.

wpietri 13y ago
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> http://martinfowler.com/books/uml.html>.

QEDturtles 13y ago

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.

Pamar 13y ago

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.

Pamar 13y ago
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/IWSSD-10.pdf https://files.ifi.uzh.ch/rerg/amadeus/publications/papers/IW...

RogerL 13y ago

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.

a3n 13y ago
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.

eliben 13y ago

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 ;-) ?

bobm_kite9 13y ago
Someone in the thread above suggested the same. This needs doing.

ssn 13y ago

How do you document a web application?

contingencies 13y ago

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.

jrobbins 13y ago

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 http://www.youtube.com/results?search_query=argouml Tons of fairly recent videos of how to use ArgoUML. Mostly in Spanish, Portuguese, or Vietnamese.

biofox 13y ago

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?

13y ago

abawany 13y ago

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.

dykesa 13y ago

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.