What kind of UML diagrams do you use? [closed]

问题

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 6 years ago.

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?

回答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.

回答2:

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.

回答3:

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

Online tool

回答4:

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.

回答5:

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

回答6:

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

very little or no usage at all of anything else

回答7:

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.

回答8:

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.

回答9:

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.

回答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.

回答11:

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.

回答12:

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.

回答13:

I never, ever use any form of UML to communicate technical ideas. I’ve found it to be a singularly useless medium for that purpose. We've come a long way since using cave paintings to communicate ideas between individuals. For some millennia now, human beings have been using actual language, with all of its complexity, nuance and eloquence, to communicate all manner of concepts clearly and unambiguously. As a species, we made that important switch from ambiguous graphical representations of ideas to unambiguous language for a very good reason: clarity.

The only people I’ve seen using UML with any great vigour are non-technical individuals (typically, business analysts and project managers), to whom it mistakenly gives the impression that they are engaging in some precise problem-solving, when in fact they are merely producing highly-ambiguous drawings that often mean vastly differing and conflicting things to the various audiences upon which they are inflicted. I’ve seen end users, developers, DBAs, business analysts and project managers all sit around the same set of diagrams, nodding at each other in apparent understanding and harmony, and only later do they realise that they each took away a very different understanding of what the actual problem was, and what needed to be built to solve it.

I’ll stick with what’s worked well for me and the end users that I’ve built more than forty systems for over the past twenty years:

1) Writing unambiguous problem definition documents in plain English (supplemented with simple tables and diagrams relevant to the discrete problem to be solved where appropriate).

2) After the problem has been defined, writing a separate technical spec (also in English) that describes a proposed solution to that well-defined problem in terms that actual end users can understand.

3) Finally, coding up a solution that meets both the problem definition and the proposed technical spec produced in steps 1 & 2 above, adjusting the solution to meet reality where appropriate (steps 2 & 3 often overlap, with one feeding into the other).

I feel sorry for people that honestly believe they can skip step 1 (problem definition)* above, and somehow magically leap straight into step 2, attempting to describe a solution to a badly-understood and poorly-scoped problem, compounding their difficulty by using a clumsy medium like UML that is inherently ambiguous and subject to widespread misinterpretation amongst the various parties to the process. That way madness lies.

• Worse still, when you point out to non-technical UML evangelists that they haven’t defined the problem prior to attempting to describe a proposed solution, they usually point you at a load of “use cases” and diagrams with little stick figures that they like to call “actors”, and completely fail to appreciate that those aspects of what they have produced are, at best, merely incomplete descriptions of one possible solution, and do not in any way represent an abstract definition of a problem. E.g., the use case “Bob presses the accelerator pedal, and the car goes faster” is a part-description of a potential solution (a car), that is in itself only one possible solution (and, perhaps, not the most pertinent one) to the actual underlying problem that ‘Bob needs to get from A to B’. If you also know that Bob 1) can’t drive, 2) in any case lives on a boat - which facts only a complete definition of the actual problem would tell you - that use case about the pedal starts to look pretty irrelevant, doesn’t it?

回答14:

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)

回答15:

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).

回答16:

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.

回答17:

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...

回答18:

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

回答19:

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

回答20:

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

来源：https://stackoverflow.com/questions/743507/what-kind-of-uml-diagrams-do-you-use