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:
- Use cases, which describe
how people interact with the System.
- A class diagram drawn from
the conceptual perspective, which can be a good way of building up a rigorous
vocabulary of the domain.
- 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.
- 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:
- Class diagrams from a
software perspective. These show the classes in the software and how they
interrelate.
- 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.
- Package diagrams to show the large-scale organization of the software.
- State diagrams for classes with complex life histories.
- 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:
- 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.
- 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.
- 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.
