What kind of UML diagrams do you use?

Question

UML2 offers different kinds of diagrams. Up to now I only used class diagrams.

What kind of UML diagrams do you use? What kinds of diagrams do you recommend for design & documentation of a software project?

Answer 1

I use following diagrams more frequently:

1. class diagrams: To explain the class relationship
2. Sequence Diagrams: To capture object interactions
3. Activity diagrams: To explain the activities (algorithm flow).

EDIT: Added links as per comment from @Smith325.

Answer 2

I will put in a vote for use-case diagrams, as these are about the only UML diagram type that users/clients can actually understand and find relevant to their needs.

Answer 3

Sequence diagrams are the primary type for me, very little useage of anything else really.

Online tool

Answer 4

I often use some kind of deployment diagram when modelling the system (though, admittely, I tend to use non-UML stuff in my diagrams as well)

Answer 5

• use cases diagrams: to capture a behavioral requirements
• sequence diagrams: to capture object interactions

very little or no usage at all of anything else

Answer 6

I use state transition diagrams to model the complexity of - well - the different states of a particular application.

Answer 7

Perhaps it would be better to ask what practical benefit do i get from using UML ?

• UML failed to deliver tools that understand diagrams and spit out templated code.
• Non technical users dont really understand UML.
• Do sequence diagrams really capture all the program flow ?
• Class diagrams - Most people end up with sphaghetti - as they try and put too much in.
• Use Case Diagrams - are often overly simple they are worthless.
• RUP - the less said about this the better..

Any diagramming mechanism along with a clear narrative can be used to convey any idea. Just make it legible, clear and logical and it should help be self explanatory.

Answer 8

I use none.

I have hardly seen them since university times and my diploma projects.

Have an impression mainly students/profs are interested in these methodologies, the world of practice lives happily without UML.

While I'm not saying that UML can not bring any benefits.

Answer 9

I use class diagrams quite often to document the high-level design and relationships between the most important classes. I often use state-transition diagrams, but not done in UML style. I rarely use sequence diagrams, finding them difficult to read (and write).

Answer 10

They can all be used for design and documentation of a project. This is very open to interpretation.

It is going to depend on the project and who you are creating the documentation for. In some cases UML is next to useless, but can help you build a simpler non-UML diagram that end users can understand.

At other times when you are just documenting for other software developers UML diagrams can be useful. In this case, state transition diagrams might be useful for systems developers whilst use case diagrams may be better for analysts documenting requirements.

Overall using UML for the sake of it is not helpful for other programmers, users, or your customers. It's only one tool for communication. If you get too religious with your UML usage you are not servicing the needs of any of these groups.

Answer 11

I work in an agile environment, so most of the UML I write is short-lived drawings on a whiteboard.

I use class diagrams for illustrating how classes relate to one another. I use activity diagrams instead of traditional flowcharts to explain general program flow. State machine diagrams can be useful to explain state changes in object lifecycles. Very occasionally, I'll use a sequence diagram to work through some tangled program logic, though I'll often refactor the code to gain that understanding.

Answer 12

I don't like use case diagrams. The diagram doesn't really show much, I find a bulletted list with descriptions to be much more useful, if not full use case descriptions with scenarios, failure conditions, etc.

Class diagrams are useful, though I never really put all of the details into them. Getting the connections between the domain objects and how everything fits together seems to be more useful than going through and filling in the behaviors and fields.

Sequence diagrams are great if you're trying to figure out the flow of something that's getting a little too complicated and you're having trouble visualizing what is going on.

Class diagrams, sequence diagrams, and state diagrams are also great for trying to figure out what existing code is doing.

I don't worry about formalities in my diagrams; they're rough sketches on a whiteboard.

Answer 13

Use-Case diagrams do not provide any detail, but I haven't seen a better way to quickly give an overview of all the use-cases in the system.

Class diagrams are useful for showing the classes that are part of each package. However, I seldom see them used for that purpose by other developers. They are usually used to throw a bunch of classes on a picture with little rhyme and reason as to why the particular classes are in each picture. Thus, the diagrams end up not being very useful.

Sequence diagrams are indispensable. The tools absolutely do not support useful usage of sequence diagrams so you have to be somewhat inventive within the limitations of the tools. But I use sequence diagrams to prove that my use-cases match my architecture and my design matches my package operations etc... I don't think there is a more useful diagram. However, most people don't use them, probably because it forces you to think about your design.

The concept of the component diagram is useful. The UML version is pretty ugly, so I usually end up drawing my own diagram using Powerpoint or Visio.

I'm not much of a fan of state or activity diagrams. I had some bad experiences with other people's state machine designs early in my career and thus avoid them like the plague.

When it comes to presenting to a customer/manager then I use the information from these diagrams but I put it in a format that is easier to understand and at a much higher level.

However, for presenting to other software developers then these diagrams should be sufficient to convey the required information through design. But, usually they do require some narrative text be written in order to be of value.

Answer 14

Ask yourself what do my users understand, am I truely able and committed to keeping my diagrams current and accurate or will they rot and add confusion...

Answer 15

Ask yourself does .Net or Java deliver UML anywhere as part of its documentation bundle ?

Answer 16

I only use Use Case diagram and deployment diagram only as I find them useful in explaining the functionality and deployment setup respectively.

Answer 17

A domain model is indispensable in most projects. It gives the technical staff a consistent, clear and unambiguous understanding of the domain vocabulary. A UML class diagram is the best notation for this (yes, even better than an English language glossary).

A use case model (that's model, not diagram) is much easier to manipulate than a dozen Word documents (depending on your choice of UML tool, of course) and so I'd recommend you follow the UML route in documenting your use cases. Your UML tool will almost certainly allow you to assign additional information to your use cases, such as test scripts, metrics etc. Having this in a model will allow you to create custom reports on this extra information.

Beyond that, I'd say that if you need a state diagram, use a UML state diagram; if you need a flow chart, use a UML activity diagram; if you need a call graph, use a UML sequence diagram. In each case, the UML notation is going to be more widely understood than whatever ad hoc notation you invent on your own.

But the general message is, to use whatever tools you have at hand to make your job easier.

Answer 18

My personal vote: Use Case Diagrams Sequence Diagrams Class Diagrams

with the occasional, supplemental Activity Diagram.

But I think mileage varies. I typically work on systems with lots of use cases, some of which are served by integrating commercial solutions and writing a little bit of code. So for me, use cases are often the most relevant part of UML, with an occasional component diagram.

Sequence and Class have been the defacto diagrams for software design, but I've seen them be used very poorly. It's easy to fall into a pattern of designing cookie cutter diagrams with these, and not really drilling into a diagram that shows the really critical design aspects of the system.

I love UML for it's ability to provide a clear, standardized syntax for explaining design problems in a consistent way. But I hate that sometimes its considered a development "standard" and not just one tool for the job. I say use them if they help to enlighten a critical group of people and skip them entirely if they serve now useful purpose for making a technical decision.

Answer 19

Sequence diagrams to help me keep track of things when I try to grok other people's code.