Is there any value in learning UML?

I have seen UML mentioned several places in the last few years, but never had a compelling reason to 开发者_如何学运维use it at work so far. Is there any value in putting the time and effort to learn it? (I am a Ruby on Rails developer.)

Edit: I'm also looking for stories about how UML has made a difference in your projects to give me an idea of how I might use it.

Yes. It is the international standard methodology for systems analysis and design. When moving from the initial analysis phase through the project life-cycle, the UML gives a good road-map on where to go and how you got there. A few benefits:

• It shows requirements in a way that clients / customers / management can understand.
• You can iterate the model and not lose track of where the model was before
• Shows exactly how you got from point A to point B
• It's a standard, so anyone who knows UML will be able to interpret your diagrams
• The "quickest" way to share ideas without needing to go through the entire code-base

No, save your time and don't learn it. If you are a coder and work alone and are a very careful person, you can completely ignore UML.

But, if you work with other people and want to share the result of your work, UML is a Unified language, a lingua franca that even non technical customers understand (at a certain level).

Yes and no.

Yes, learn the basics. Have a quick look at at the different diagram types etc. and have a general idea. That will help you eliminate your hesitance when someone boasts about UML.

No, if your work doesn't require to work with UML, you don't necessarily need to know UML to write good applications. If you need to discuss something on a white board just draw a few circles. That'll do.

It only helped me to produce documentation to management to impress them a little. Other than that I only find the deployment diagrams somewhat useful, that's all.

If you look at UML as a merely graphical language you consider just a very small part of it. You should instead look at UML as the primary language of the Model Driven Architecture framework which is very well implemented in Eclipse. In Eclipse UML is (correctly) considered as a Platform Independent language with a solid syntax defined by the MOF (ECORE in Eclipse) and semantics defined by the UML specification (http://www.omg.org/spec/UML). In Eclipse there are good implementation of the two main languages defined by the OMG for Model To Text and Model to Model transformation specifications which are respectively MOFM2T (ACCELEO in Eclipse) and QVT. Also Eclipse provides an implementation of the Object Constraint Language (OCL) which is used by both QVT and MOFM2T to evaluate queries on models. All this means you can easily define your own Model to Text and Model to Model transformations , in the form of Eclipse plugin, turning your UML models into whatever you need. Now I use that to automatically generate thousands of LOC, documentation and tests with an impressive return on investment. However I know the majority of people doesn't even know UML is a language but think it is just about tiny pictures.

Look at this links for some simple example

http://lowcoupling.com/post/46522537374/the-model-driven-architecture

http://lowcoupling.com/post/47800863669/qvt-in-place-transformations

http://lowcoupling.com/post/47347056110/models-to-text-transformations-with-mofm2t-and-acceleo

I think it's a question of scale in two dimensions: size of problem and size of team.

When a design gets to a certain size diagrams become useful in two ways: first, they help you reason about design issues. second they help you communciate the design to other poeople.

So if the team is say 20 or 30 it really does help to have some clear documentation of pieces of the overall design.

Personally I use UML maybe four or five times a year, but when I need it, I really need it. It really is better to ase a standard diagramming technique that devise your own. And with good tools it's pretty painless.

I would say that I use only a small subset of UML, class diagrams and occasional collaboration diagrams.