Use Case

A use case illustrates a unit of functionality provided by the system. The
main purpose of the use-case diagram is to help development teams
visualize the functional requirements of a system, including the
relationship of "actors" (human beings who will interact with the system)
to essential processes, as well as the relationships among different use
cases. Use-case diagrams generally show groups of use cases -- either all
use cases for the complete system, or a breakout of a particular group of
use cases with related functionality (e.g., all security administrationrelated
use cases).


Class diagram

The class diagram shows how the different entities (people, things, and
data) relate to each other; in other words, it shows the static structures of
the system. A class diagram can be used to display logical classes, which
are typically the kinds of things the business people in an organization talk
about -- rock bands, CDs, radio play; or loans, home mortgages, car
loans, and interest rates. Class diagrams can also be used to show
implementation classes, which are the things that programmers typically
deal with. An implementation class diagram will probably show some of
the same classes as the logical classes diagram.The implementation class
diagram won't be drawn with the same attributes, however, because it will
most likely have references to things like Vectors and HashMaps.


Sequence diagram

Sequence diagrams show a detailed flow for a specific use case or even
just part of a specific use case. They are almost self explanatory; they
show the calls between the different objects in their sequence and can
show, at a detailed level, different calls to different objects.
A sequence diagram has two dimensions: The vertical dimension shows
the sequence of messages/calls in the time order that they occur; the
horizontal dimension shows the object instances to which the messages
are sent.


Statechart diagram

The statechart diagram models the different states that a class can be in
and how that class transitions from state to state. It can be argued that
every class has a state, but that every class shouldn't have a statechart
diagram. Only classes with "interesting" states -- that is, classes with
three or more potential states during system activity -- should be


Activity diagram

Activity diagrams show the procedural flow of control between two or
more class objects while processing an activity. Activity diagrams can be
used to model higher-level business process at the business unit level, or
to model low-level internal class actions. In my experience, activity
diagrams are best used to model higher-level processes, such as how the
company is currently doing business, or how it would like to do business.
This is because activity diagrams are "less technical" in appearance,
compared to sequence diagrams, and business-minded people tend to
understand them more quickly.


Component diagram

A component diagram provides a physical view of the system. Its purpose
is to show the dependencies that the software has on the other software
components (e.g., software libraries) in the system. The diagram can be
shown at a very high level, with just the large-grain components, or it can
be shown at the component package level.


Deployment diagram

The deployment diagram shows how a system will be physically deployed
in the hardware environment. Its purpose is to show where the different
components of the system will physically run and how they will
communicate with each other. Since the diagram models the physical
runtime, a system's production staff will make considerable use of this