UML: When to use each UML2 Diagram?

As I have studied from the book titled "UML Distilled 3rd Edition (Author Martin Fowler)", it is very handy book and useful for reviewing the UML 2 diagrams and techniques of usage.

Here are my summary for each UML diagram usage.

------------------------------------------------------------------------------------------------------------

When to use UML in development life cycle?

In requirements analysis:

The activity of requirements analysis involves trying to figure out what the Users and customers of a software effort want the System to do. A number of UML techniques can come in handy here:

1. Use cases, which describe how people interact with the System. 
2. A class diagram drawn from the conceptual perspective, which can be a good way of building up a rigorous vocabulary of the domain.
3. An activity diagram, which can Show the work flow of the organization, showing how Software and human activities interact. An activity diagram can Show the context for use cases and also the details of how a complicated use case works.
4. A state diagram, which can be useful if a concept has an interesting life cycle, with various states and events that change that state.

In design:

When you are doing design, you can get more technical with your diagrams. You can use more notations and be more precise about your notation. Some useful techniques are:

1. Class diagrams from a software perspective. These show the classes in the software and how they interrelate.
2. Sequence diagrams for common scenarios. A valuable approach is to pick the most important and interesting scenarios from the use cases and use CRC cards or sequence diagrams to figure out what happens in the software.
3. Package diagrams to show the large-scale organization of the software.
4. State diagrams for classes with complex life histories.
5. Deployment diagrams to show the physical layout of the software.

  

When to use Class diagram?

Class diagrams are the backbone of the UML, so you will find yourself using them all the time. The trouble with class diagrams is that they are so rich; they can be overwhelming to use. Here are a few tips:

1.  Don't try to use all the notations available to you. Start with the simple stuff: classes, associations, attributes, generalization, and constraints. Introduce other notations only when you need them.
2.  I've found conceptual class diagrams very useful in exploring the language of a business. For this to work, you have to work hard and keeping software out of the discussion and keeping the notation very simple.
3. Don't draw models for everything; instead, concentrate on the key areas. It is better to have a few diagrams that you use and keep up to date than to have many forgotten, obsolete models.

 The biggest danger with class diagrams is that you can focus exclusively on structure and ignore behavior. Therefore, when drawing class diagrams to understand software, always do them in conjunction with some form of behavioral technique. If you're going well, you'11 find yourself swapping between the techniques frequently.

When to Use Sequence Diagrams?

You should use sequence diagrams when you want to look at the behavior of several objects within a single use case. Sequence diagrams are good at showing collaborations among the objects; they are not so good at precise definition of the behavior.

If you want to look at the behavior of a single object across many use cases, use a state diagram. If you want to look at behavior across many use cases or many threads, consider an activity diagram.

If you want to explore multiple alternative interactions quickly, you may be better off with CRC cards, as that avoids a lot of drawing and erasing. It's often handy to have a CRC card session to explore design alternatives and then use sequence diagrams to capture any interactions that you want to refer to later. Other useful forms of interaction diagrams are communication diagrams, for showing connections; and timing diagrams, for showing timing constraints.

When to Use Object Diagrams?

Object diagrams are useful for showing examples of objects connected together. In many situations, you can define a structure precisely which a class diagram, but the structure is still difficult to understand. In these situations, a couple of object diagram examples can make all the difference.

When to Use Package Diagrams?

I find package diagrams extremely useful in larger-scale systems to get a picture of the dependencies between major elements of a System. These diagrams correspond well to common programming structures. Plotting diagrams of packages and dependencies helps you keep an application's dependencies under control. Package diagrams represent a compile-time grouping mechanism.

For showing how objects are composed at runtime, use a composite structure diagram.

When to Use Deployment Diagrams?

They are very handy in showing what is deployed where, so any nontrivial deployment can make good use of them.

When to Use "Use Cases"?

Use cases are a valuable tool to help understand the functional requirements of a system. A first pass at use cases should be made early on. More detailed versions of use cases should be worked just prior to developing that use case.

It is important to remember that use cases represent an external view of the system. As such, don't expect any correlations between use cases and the classes inside the System.

The more I see of use cases, the less valuable the use case diagram seems to be. With use cases, concentrate your energy on their text rather than on the diagram. Despite the fact that the UML has nothing to say about the use case text, it is the text that contains all the value in the technique.

A big danger of use cases is that people make them too complicated and get stuck. Usually, you'll get less hurt by doing too little than by doing too much. A couple of pages per use case is just fine for most cases. If you have too little, at least you'll have a short, readable document that's a starting point for questions. If you have too much, hardly anyone will read and understand it.

When to Use Stare Diagrams?

Stare diagrams are good at describing the behavior of an object across several use cases. Stare diagrams are not very good at describing behavior that involves a number of objects collaborating. As such, it is useful to combine state diagrams which other techniques. For instance, interaction diagrams are good at describing the behavior of several objects in a single use case, and activity diagrams are good at showing the general sequence of activities for several objects and use cases.

Not everyone finds state diagrams natural. Keep an eye on how people are working with them. It may be that your team does not find state diagrams useful to its way of working. That is not a big problem; as always, you should remember to use the mix of techniques that works for you.

If you do use state diagrams, don't try to draw them for every class in the System. Although this approach is often used by high-ceremony completest, it is almost always a waste of effort. Use state diagrams only for those classes that exhibit interesting behavior, where building the state diagram helps you understand what is going on. Many people find that UI and control objects have the kind of behavior that is useful to depict which a state diagram.

When to Use Activity Diagrams?

The great strength of activity diagrams lies in the fact that they Support and encourage parallel behavior. This makes them a great tool for work flow and process modeling, and indeed much of the push in UML 2 has come from people involved in work flow.

You can also use an activity diagram as a UML-compliant flowchart. Although this allows you to do flowcharts in a way that sticks with the UML, it's hardly very exciting. In principle, you can take advantages of the forks and joins to describe parallel algorithms for concurrent programs. Although I don't travel in concurrent circles that muck, I haven't seen muck evidence of people using them there. I think the reason is that most of the complexity of concurrent programming is in avoiding contention an data, and activity diagrams don't help muck which that.

The main strength of doing this may come with people using UML as a programming language. In this case, activity diagrams represent an important technique to represent behavioral logic. I've often seen activity diagrams used to describe a use case. The danger of this approach is that often, domain experts don't follow them easily. If so, you'd be better off which the usual textual form.

When to Use Communication Diagrams?

The main question with communication diagrams is when to use them rather than the more common sequence diagrams. A strong part of the decision is personal preference: Some people like one over the other. Often, that drives the choice more than anything else. On the whole, most people seem to prefer sequence diagrams, and for once, I'm with the majority.

A more rational approach says that sequence diagrams are better when you want to emphasize the sequence of calls and that communication diagrams are better when you want to emphasize the links. Many people find that communication diagrams are easier to alter an a whiteboard, so they are a good approach for exploring alternatives, although in Chose Gases, I often prefer CRC cards.

When to Use Composite Structures?

Composite structures are new to UML 2, although some older methods had some similar ideal. A good way of thinking about the difference between packages and composite structures is that packages are a compile-time grouping, while composite structures show runtime groupings.

As such, they are a natural fit for showing components and how they are broken into parts; hence, much of this notation is used in component diagrams.

Because composite structures are new to the UML, it's too early to tell how effective they will turn out in practice; many members of the UML committee think that these diagrams will become a very valuable addition.

When to Use Component Diagrams?

Use component diagrams when you are dividing your System into components and want to Show their interrelationships through Interfaces or the breakdown of components into a lower-level structure.

When to Use Collaborations Diagrams?

Collaborations have been around since UML 1, but I admit I've hardly used them, even in my patterns writing. Collaborations do provide a way to group chunks of interaction behavior when roles are played by different classes. In practice, however, I've not found that they've been a compelling diagram type.

When to Use Interaction Overview Diagrams?

These are new for UML 2, and it's too early to get muck Sense of how well they will work out in practice. I'm not keen an them, as I think that they mix two styles that don't really mix that well. Either draw an activity diagram or use a sequence diagram, depending on what better serves your purpose.

When to Use Timing Diagrams?

Timing diagrams are useful for showing timing constraints between state changes an different objects. The diagrams are particularly familiar to hardware engineers.