Introduction to UML - Unified Modeling Language
The
Unified Modeling Language (UML) is a visual language for capturing
software designs and patterns. Dig a little deeper, though, and you’ll
find that UML can be applied to quite a few different areas and can
capture and communicate everything from company organization to business
processes to distributed enterprise software. It is intended to be a
common way of capturing and expressing relationships, behaviors, and
high-level ideas in a notation that’s easy to learn and efficient to
write. UML is visual; just about everything in it has a graphical
representation.
History, Need and Tools
You can apply UML in any number of ways, but common uses include:
• Designing software
• Communicating software or business processes
• Capturing details about a system for requirements or analysis
• Documenting an existing system, process, or organization
UML has been applied to countless domains, including:
• Banking and investment sectors
• Health care
• Defense
• Distributed computing
• Embedded systems
• Retail sales and supply
UML Basics
Note: Sometimes Implementation is called as "Realization"
Association
Associations
are stronger than dependencies and typically indicate that one class
retains a relationship to another class over an extended period of time.
The lifelines of two objects linked by associations are probably not
tied together (meaning one can be destroyed without necessarily
destroying the other). Associations are typically read as “…has a…”. For
example, if you have a class named Window that has a reference to the
current mouse cursor, you would say “Window has a Cursor”. Note that
there is a fine line between “…has a…” and “…owns a…” (see
“Aggregation” later in this section). In this case, Window doesn’t own
the Cursor; Cursor is shared between all applications in the system.
However, Window has a reference to it so that the Window can hide it,
change its shape, etc. You show an association using a solid line
between the classes participating in the relationship.
Navigability
Associations
have explicit notation to express navigability. If you can navigate
from one class to another, you show an arrow in the direction of the
class you can navigate to. If you can navigate in both directions, it is
common practice to not show any arrows at all, but as the UML
specification points out, if you suppress all arrows you can’t
distinguish nonnavigable associations from two-way associations.
However, it is extremely rare to use a nonnavigable association in the
real world, so this is unlikely to be a problem.
Multiplicity
Because associations typically represent lasting
relationships, they are often used to indicate attributes of a class. As
mentioned in the “Attributes by Relationship” section, you can express
how many instances of a particular class are involved in a relationship.
If you don’t specify a value, a multiplicity of 1 is assumed. To show a
different value, simply place the multiplicity specification near the
owned class.
Aggregation
Aggregation
is a stronger version of association. Unlike association, aggregation
typically implies ownership and may imply a relationship between
lifelines. Aggregations are usually read as “…owns a…”. For
example, if you had a classed named Window that stored its position and
size in a Rectangle class, you would say the “Window owns a Rectangle.”
The rectangle may be shared with other classes, but the Window has an
intimate relationship with the Rectangle.
Composition
Composition
represents a very strong relationship between classes, to the point of
containment. Composition is used to capture a whole-part relationship.
The “part” piece of the relationship can be involved in only one
composition relationship at any given time. The lifetime of instances
involved in composition relationships is almost always linked; if the
larger, owning instance is destroyed, it almost always destroys the part
piece. UML does allow the part to be associated with a different owner
before destruction, thus preserving its existence, but this is typically
an exception rather than the rule. A composition relationship is
usually read as “…is part of…”, which means you need to read the
composition from the part to the whole. For example, if you say that a
window in your system must have a titlebar, you can represent this with a
class named Titlebar that “…is part of…” a class named Window.
Generalization
A
generalization relationship conveys that the target of the relationship
is a general, or less specific, version of the source class or
interface. Generalization relationships are often used to pull out
commonality between difference classifiers. For example, if you had a
class named Cat and a class named Dog, you can create a generalization
of both of those classes called Animal. A full discussion of how and
when to use generalization (especially versus interface realization) is
the subject for an object-oriented analysis and design book and isn’t
covered here. Generalizations are usually read as “…is a…”, starting
from the more specific class and reading toward the general class. Going
back to the Cat and Dog example, you would say “a Cat…is a…Animal”
(grammar aside).
Realization or Implementation
An
interface is a classifier that has declarations of properties and
methods but no implementations. You can use interfaces to group common
elements between classifiers and provide a contract a classifier that
provides an implementation of an interface must obey. For example, you
can create an interface named Sortable that has one operation named
comesBefore(...). Any class that realizes the Sortable interface must
provide an implementation of comesBefore(...).
Dependency
The
weakest relationship between classes is a dependency relationship.
Dependency between classes means that one class uses, or has knowledge
of, another class. It is typically a transient relationship, meaning a
dependent class briefly interacts with the target class but typically
doesn’t retain a relationship with it for any real length of time.
Dependencies are typically read as “…uses a…”. For example, if
you have a class named Window that sends out a class named
WindowClosingEvent when it is about to be closed, you would say “Window
uses a WindowClosingEvent.”
Modeling
It
should go without saying that the focus of UML is modeling. However,
what that means, exactly, can be an open-ended question. Modeling is a
means to capture ideas, relationships, decisions, and requirements in a
well-defined notation that can be applied to many different domains.
Modeling not only means different things to different people, but also
it can use different pieces of UML depending on what you are trying to
convey.
In
general a UML model is made up of one or more diagrams. A diagram
graphically represents things, and the relationships between these
things. These things can be representations of real-world objects, pure
software constructs, or a description of the behavior of some other
object. It is common for an individual thing to show up on multiple
diagrams; each diagram represents a particular interest, or view, of the
thing being modeled.
Diagrams
UML
2.0 divides diagrams into two categories: structural diagrams and
behavioral diagrams. Structural diagrams are used to capture the
physical organization of the things in your system—i.e., how one object
relates to another.
There are several structural diagrams in UML 2.0:
Class diagrams
Class
diagrams use classes and interfaces to capture details about the
entities that make up your system and the static relationships between
them. Class diagrams are one of the most commonly used UML diagrams, and
they vary in detail from fully fleshed-out and able to generate source
code to quick sketches on whiteboards and napkins.
Component diagrams
Component
diagrams show the organization and dependencies involved in the
implementation of a system. They can group smaller elements, such as
classes, into larger, deployable pieces. How much detail you use in
component diagrams varies depending on what you are trying to show. Some
people simply show the final, deployable version of a system, and
others show what functionality is provided by a particular component and
how it realizes its functionality internally.
Composite structure diagrams
Composite
structure diagrams are new to UML 2.0. As systems become more complex,
the relationships between elements grow in complexity as well.
Conceptually, composite structure diagrams link class diagrams and
component diagrams; they don’t emphasize the design detail that class
diagrams do or the implementation detail that composite structures do.
Instead, composite structures show how elements in the system combine to
realize complex patterns.
Deployment diagrams
Deployment
diagrams show how your system is actually executed and assigned to
various pieces of hardware. You typically use deployment diagrams to
show how components are configured at runtime.
Package diagrams
Package
diagrams are really special types of class diagrams. They use the same
notation but their focus is on how classes and interfaces are grouped
together.
Object diagrams
Object
diagrams use the same syntax as class diagrams and show how actual
instances of classes are related at a specific instance of time. You use
object diagrams to show snapshots of the relationships in your system
at runtime.
Behavioral
diagrams focus on the behavior of elements in a system. For example,
you can use behavioral diagrams to capture requirements, operations, and
internal state changes for elements. The behavioral diagrams are:
Use case diagrams
Use
case diagrams capture functional requirements for a system. They
provide an implementation-independent view of what a system is supposed
to do and allow the modeler to focus on user needs rather than
realization details.
Activity diagrams
Activity
diagrams capture the flow from one behavior or activity, to the next.
They are similar in concept to a classic flowchart, but are much more
expressive.
Communication diagrams
Communication
diagrams are a type of interaction diagram that focuses on the elements
involved in a particular behavior and what messages they pass back and
forth. Communication diagrams emphasize the objects involved more than
the order and nature of the messages exchanged.
Interaction overview diagrams
Interaction
overview diagrams are simplified versions of activity diagrams.
Instead of emphasizing the activity at each step, interaction overview
diagrams emphasize which element or elements are involved in performing
that activity. The UML specification describes interaction diagrams as
emphasizing who has the focus of control throughout the execution of a system.
Sequence diagrams
Sequence
diagrams are a type of interaction diagram that emphasize the type and
order of messages passed between elements during execution. Sequence
diagrams are the most common type of interaction diagram and are very
intuitive to new users of UML.
State machine diagrams
State
machine diagrams capture the internal state transitions of an element.
The element could be as small as a single class or as large as the
entire system. State machine diagrams are commonly used to model
embedded systems and protocol specifications or implementations.
Timing diagrams
Timing
diagrams are a type of interaction diagram that emphasize detailed
timing specifications for messages. They are often used to model
real-time systems such as satellite communication or hardware
handshaking. They have specific notation to indicate how long a system
has to process or respond to messages, and how external interruptions
are factored into execution.
Views
While
not strictly part of UML itself, the concept of views of a system helps
the modeler choose diagrams that help convey the correct information
depending on his goals. Specifically, models are often divided into what
is called the 4+1 views of a system. The 4+1 notation represents four
distinct views of a system and one overview of how everything fits
together.
The four views are:
Design view
The
design view captures the classes, interfaces, and patterns that
describe the representation of the problem domain and how the software
will be built to address it. The design view almost always uses class
diagrams, object diagrams, activity diagrams, composite structure
diagrams, and sequence
diagrams to convey the design of a system. The
design view typically doesn’t address how the system will be
implemented or executed.
Deployment view
The
deployment view captures how a system is configured, installed, and
executed. It often consists of component diagrams, deployment diagrams,
and interaction diagrams. The deployment view captures how the physical
layout of the hardware communicates to execute the system, and can be
used to show failover, redundancy, and network topology.
Implementation view
The
implementation view emphasizes the components, files, and resources
used by a system. Typically the implementation view focuses on the
configuration management of a system; what components depend on what,
what source files implement what classes, etc. Implementation views
almost always use one or more component diagrams and may include
interaction diagrams,
statechart diagrams, and composite structure diagrams.
Process view
The
process view of a system is intended to capture concurrency,
performance, and scalability information. Process views often use some
form of interaction diagrams and activity diagrams to show how a system
actually behaves at runtime.
The four distinct views of a system are brought together with the final view:
Use case view
The
use case view captures the functionality required by the end users. The
concept of end users is deliberately broad in the use case view; they
include the primary stakeholders, the system administrator, the testers,
and potentially the developers themselves. The use case view is often
broken down into collaborations that link a use case with one or more of
the four basic views.
The use case view includes use case diagrams and typically uses several interaction diagrams to show use case details.
