Is UML practical? [closed]

Answer 1

In my experience:

The ability to create and communicate meaningful code diagrams is a necessary skill for any software engineer who is developing new code, or attempting to understand existing code.

Knowing the specifics of UML - when to use a dashed line, or a circle endpoint - is not quite as necessary, but is still good to have.

Answer 2

Throw away only in my opinion. UML is a great tool for communicating ideas, the only issue is when you store and maintain it because you are essentially creating two copies of the same information and this is where it usually blows. After the initial round of implementation most of the UML should be generated from the source code else it will go out of date very quickly or require a lot of time (with manual errors) to keep up to date.

Answer 3

UML is useful, yes indeed! The main uses I've made of it were:

• Brainstorming about the ways a piece of software should work. It makes easy to communicate what you are thinking.
• Documenting the architecture of a system, it's patterns and the main relationships of its classes. It helps when someone enters your team, when you're leaving and want to make sure your successor will understand it, and when you eventually forget what the hell that little class was meant for.
• Documenting any architectural pattern you use on all your systems, for the same reasons of the dot above

I only disagree with Michael when he says that using UML for a single developer and/or a simple software project seems overkill to him. I've used it on my small personal projects, and having them documented using UML saved me a lot of time when I came back to them seven months later and had completely forgotten how I had built and put together all those classes.

Answer 4

I found UML not really useful for very small projects, but really suitable for larger ones.

Essentially, it does not really matter what you use, you just have to keep two things in mind:

• You want some sort of architecture planning
• You want to be sure that everyone in the team is actually using the same technology for project planning

So UML is just that: A standard on how you plan your projects. If you hire new people, there are more likely to know any existing standard - be it UML, Flowchard, Nassi-Schneiderman, whatever - rather than your exising in-house stuff.

Using UML for a single developer and/or a simple software project seems overkill to me, but when working in a larger team, I would definitely want some standard for planning software.

Answer 5

I see sequence diagrams and activity diagrams used fairly often. I do a lot of work with "real-time" and embedded systems that interact with other systems, and sequence diagrams are very helpful in visualizing all the interactions.

I like to do use-case diagrams, but I haven't met too many people who think they are valuable.

I've often wondered whether Rational Rose is a good example of the kinds of applications you get from UML-model-based design. It's bloated, buggy, slow, ugly, ...

Answer 6

I will qualify my answer by mentioning that I don't have experience in large (IBM-like) corporate development environments.

The way I view UML and the Rational Unified Process is that it's more TALKING about what you're going to do than actually DOING what you're going to do.

(In other words it's largely a waste of time)