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?
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?
I use following diagrams more frequently:
EDIT: Added links as per comment from @Smith325.
Perhaps it would be better to ask what practical benefit do i get from using UML ?
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.
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).
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.
I use state transition diagrams to model the complexity of - well - the different states of a particular application.
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.