Few years back everybody in our shop was crazy with UML. Now everybody seems to have cooled off.
I am curious if there is still widespread use of UML in software projects.
If so, is this usage limited to whiteboarding? Do you use it for documentation? Do you use tools to generate code from it?
I use UML for initial designs and as an aid to discussion when talking to other developers. But, beyond initial design, the time spent trying to keep UML up to date is not worth the effort.
I use UML for initial designs as well. After doing the reqs phase and the use cases (both in UML and textual form), the basic system is laid out as a component diagram to identify single components, the interfaces as well as subsystems.
I've seen generated UML used to help new hires get a handle on what was a very involved and complex system. Since the UML was automatically generated from the code it was always up-to-date and some people found it helpful.
See SO: Is UML practical? for some more responses on the topic. It seems to be that UML is still useful for communicating concepts and systems. People seem to use it as a description, rather than a definition. If you separate UML from the implementation itself, you'll run into trouble keeping the two in sync.
UML is dead, dead, dead: Is UML Really Dead, Or Only Cataleptic?
Whiteboarding/Documentation are ok. Generating code from it? Who needs that and for what?
We use UML class diagrams only for some scratching mostly at the beginning of projects, but also when explaining our own code to other developers. But this is only sratching, not to document our software.
To my mind it is much talked about UML (by people, magazines), but not quite so many people really use it.
If you use Agile you should be using UML.
Modeling is important. If is of course more fun to get writing code, however you waste allot of time and have no idea if you are meting the customer requirements. You model to understand the problem you are being asked to solve, and speed up development time, and ship a useful product to your customers.
Save gold plating for the overpriced Monster cables.
I think agile flavor of UML (e.g. quick white board sketch) is quite successful than the waterfall flavor of UML (e.g. elaborate diagram with all gory detail for documentation, code generation, etc to make the document savvy managers happy. Oops sorry I got carried away a bit there. :)
UML is still quite useful to explain a design to someone else. I wonder how would you teach someone composite pattern without a simple class diagram (that is, after you are done with those interesting analogies).
Even when doing solo, if I had to understand a project with classes littered all over the place and with no good enough documentation, a few hand-drawn class diagrams and sequence diagrams really would get me going.
We are also quite successfully using UML for our database schema. 'Are there any better ways?' would be separate question.
I use UML in discussions with other developers. I often think to myself that I'm more successful in relaying information to other people via pictures, so I'll draw a class diagram or an activity diagram on a whiteboard when brainstorming with the rest of the team. Other members can draw and modify it, and once we all know what we're talking about, we tend to just roll with it. We didn't bother with generating code directly from it (partly because our tools were awful) but on the other hand we may have felt more constrained if we did. Those designs changed a LOT since the whiteboarding....
I have always used UML (or UML ispired) graphics as supporting documentation. The documents provide a slice in time such as "this was our original concept of a user". Keeping documents up to date is hard and would only be done if we need to change the our definition. Then we have another snap shot in time. UML was not the design but part of the design process.
I have used some code generating tools that used UML but only to generate initial stubs. Usually once the code was generated, it evolved seperately from the diagram.
One problem with UML was that in many cases arguements broke out about proper UML syntax/style instead of concentrating on whether the drawing helped the customer, analyst or developer understand the concept. I know syntax is important when code generating, but I found UML is best used to understand a concept.
I actually use UML to help me visualize and think through problems. For this purpose, sequence diagrams, activity diagrams and object diagrams are very useful.
Component diagrams are good when you're trying to communicate the software layers.
Deployment diagrams are very useful for figuring out packaging and deployment, as well as inter-node communication paths.
Class diagrams I find least useful, since most IDEs can give you the as-built class hierarchy quite easily.
We still use UML. Like others here, I find that they greatly aid in communication. It's a lot easier for people to communicate when they have visual aids (enter the popularity of PowerPoint). This is especially true in the initial phases of a project where scenarios like firebird84 explained happen a lot. The painstaking side to UML is the upkeep of the diagrams once the developers on the project start coding.
We don't generate code off of them though and I've yet to personally speak to someone that has used UML to that extent.
I've decided I like the Cockburn style usecases as described by Fowler in his book entitled "UML Distilled." I like them enough that I devised an experimental way to embed them directly into C# namespaces.
By doing this I could encode business or UI logic in terms of the use cases' English language content for free without having to write any kind of domain specific language. The most immediate benefit was that I improved the code readability (albiet in a very new and esoteric kind of way). It is still an experimental approach. However, I believe it could be useful.
Here is the link to a question I posted while trying to find other ways to do what I did.
I use class diagrams on a daily basis to discuss the model, both objects and schemas. This really throws DBAs off, until you point out that you can derive an ERD from a class diagram by sliding all the arrows the to the other end of the lines... The arrows still point in the same direction mind you. There, now it depicts an FK.
There are plenty of structural and semantic details that differ between the two types of diagrams, but the arrow conversion seems to clear the mental block.
Together/J is a good reference point because there is NO effort to produce the UML, it just is there alongside your Java code. Interesting to look see if I used the UML when it was there for "free".
Did I find it useful having it there? To be honest, I found it useful as an additional visual reassurance and cross check that the design I made was taking shape, and as a visual cataloguing tool. I didn't think about specific logic or schemas based on the diagrams. Well okay maybe sometimes I did.
Was it worth the money? It made me feel good about the process. It looked impressive to others. It shaved a few moments off thinking about the inventory of stuff I had going on. It made me think more about neatness and simplicity in general, what with every object occupying screen real estate. It made me ask do I really need that attribute or can I make it neater? It did occasionally helped me "think in UML".
With additional experience, would I now use Together/J? Would I now spend time building UML from scratch?
Well when I look at what I actually do for a project, it consists of writing UI designs, database schemas and communication protocols, considering use cases and memory use, bandwidth use and security. In fact almost everything possible to consider, except object-orientation / UML. And I don't use Together/J.
Why is this?
It is because I have now internalised my learnings from UML. I now focus on achieving speed, space and time efficiencies in designs. My designs are highly constrained by UML principles so it was worth learning all that stuff, but I don't use actual paper UML diagrams or think in UML any more.
UML is just assumed; a given. Or rather its influence on design is.
What I now have on the screen is pure code and data. I also have a sense of achievement. :-)
I think that traditional UML is dead. I mean static UML which spends few months of requirements modeling and code generation from a model. We can't wait more than a week before starting to code because we have to deliver our project faster and faster. If you model then generate a code, the generated code is usually so bad that you need to fix it. I spent more time fixing dirty UML generated code few years ago than writing a clean new code.
I think that MDD (e.g. model driven development) is dead but not UML graphical notation. I still use it every day and it works really well. When I get new requirements I immediately model it into a class diagram. I first reverse my existing project, then create new elements and merge it with existing code.It is no more than 2 hours to create the skeleton of my requirement into my existing project. I like to create my skeleton with a class diagram because it gives you higher level of abstraction and code. Really cool. I use Omondo EclipseUML and I am made for this tool, sorry for the other vendors but this tool has changed my life. I merge my project with offshore teams twice a day and recreate new diagrams. This is not automatic because I prefer to check the code before accepting the commit. I check the compilation and also the object approach and only UML can give me a view of what has been done, how and where the glue has been added to support new requirements. I am happy because I don't use anymore dirty MDD code generation, but can focus on UML notation and quality code.
I find ULM useless for me, it harms my creativity. I generate UML only as a documententation, if the customer wants it. But I don't use it to model classes. Architecture is an evolving process, where I think over and over again and got new ideas everywhere I am, not only in the office. I am constantly refactoring to get closer to the optimum, first in mind then in code. Hope I you understand what I mean.