To blatantly answer your question:
It might or might not be worth it to draw a class diagram. You need to look at your system and determine what diagrams (if any) would add value to anyone working on the system. If producing a diagram will make the lives of developers, testers, or maintainers easier, then the diagrams should be produced. If they don't add any kind of value of anyone working on the system, then don't spend the time or effort on the work. If the system already exists, you might also want to consider reverse engineering to produce diagrams to allow a new developer to understand the system in less time.
In terms of costing more money, yes, creating diagrams for your system up front costs money as developers spend time creating them (and time costs money). However, this up-front (start of project in a sequential process or start of an iteration in an iterative product) cost can be off-set by the idea that having something that can be reviewed for mistakes, errors, or misunderstandings earlier in the development cycle. A mistake created in design costs more to fix in development, testing, or after release than it does to fix before you leave the design phase.
You explicitly mentioned class diagrams. Yes, class diagrams are widely used. But it's important to show things, but show the right things. Other diagram types can show some interesting views over the system, depending on the system that you are building. Sequence diagrams can show complexity, cohesion, and coupling in a system. Component and Deployment diagrams are useful when building distributed systems, to show the connections between each node. Object diagrams show how the system is going to behave under certain conditions at runtime. Activity diagrams can be used to show business logic and workflows. The list goes on - each diagram shows a particular view of the system, and each view might (or might not) add value to developers, maintainers, and testers.
The strength of UML is in its consistency. It provides a set of symbols that are required to model an object-oriented software system. Using this allows everyone to get on the same page, with reduced ambiguities and confusion across the team. Using words and sentences to describe a system leads to misunderstandings and ambiguities. With UML (as long as you use the standard notations and everyone on the team knows those notations), it becomes far easier to communicate the intended design, as well as actual implementation, of the system. If you are working alone, this isn't so important. However, on a team, it's important for everyone to be thinking of the system in the same light, and UML helps to provide a standard language with the constructs necessary to do this.
So far, I have never used the full extent of UML, either at work or in my personal projects. However, I do use UML notation to put my thoughts on paper and work through them, trying to make sure that they will work before I start coding. It's much easier to grab a piece of paper or use a whiteboard and make changes to sketches than it is to code once it's been written. This has also be my experience on most of the teams that I've been on, with a few exceptions. This goes for all kinds of diagrams, ranging from class diagrams through activity diagrams. It depends on the problem that I'm trying to solve and what I'm having problems thinking through.
In terms of the cost of using UML up-front, you are going to be spending the time to sit down, either as an individual or team and creating diagrams. Steve McConnell gives some numbers from Capers Jones and Barry Boehm (among others) in his books, Rapid Development: Taming Wild Software Schedules and Software Project Survival Guide: How to Be Sure Your First Important Project Isn't Your Last:
- Rework of defective requirements, design, and code is 40-50% of the cost of development.
- An hour of defect prevention will safe 3-10 hours of defect repair time.
- Cutting design time might seem to reduce the cycle time of the project. However, any time cut will be paid back with interest later in the product.
- An error in requirements or architecture tends to cost 50-200 times as much to correct late in the project as it does close to the point where it was injected (there's a graph showing this on p. 29 of the Survival Guide).
If you are using UML to capture your design decisions and adequately reviewing (a design review is very similar to a code review, but you look at the design documents and diagrams instead of code) and discussing those designs in a clear, concise, and unambiguous manner, then you should be able to find and remove defects early in a project or iteration. Discussing designs can reveal misunderstood requirements as well as designs that aren't able to meet all of the known requirements. Although it does require time, it'll save time and money down the road.
