Unified Modeling Language (UML)
Unified Modeling Language (UML)
Unified Modeling Language (UML)
(UML)
..
กก
Topics
Building Blocks
Extensibility Mechanisms
Building Blocks
Things
Relationships
Diagrams
Things
Structural things
Behavioral things
Grouping things
Annotational things
Structural things
Structural things are the nouns of
UML models.
The mostly static parts of a model,
representing elements that are either
conceptual or physical.
Structural things
Class
Interface
Collaboration
Use case
Component
Artifact
Node
Physical things
Class
A class is a description of a set of
objects that share the same
attributes,
operations,
relationships,
and semantics.
A class implements one or more
interfaces.
Class
Interface
An interface is a collection of operations
that specify a service of a class or
component.
An interface describes the externally
visible behavior of that element.
Interface
Collaboration
A collaboration defines an interaction
and is a society of roles and other
elements that work together to provide
some cooperative behavior that's bigger
than the sum of all the elements.
Collaboration
Use case
A use case is a description of
sequences of actions that a system
performs that yield observable results
of value to a particular actor.
A use case is used to structure the
behavioral things in a model.
Use case
Active class
An active class is a class whose
objects own one or more processes or
threads and therefore can initiate
control activity.
An active class is just like a class
except that its objects represent
elements whose behavior is concurrent
with other elements.
Active class
Component
A component is a modular part of the
system design that hides its
implementation behind a set of external
interfaces.
Component
Artifact
An artifact is a physical and
replaceable part of a system that
contains physical information.
An artifact typically represents the
physical packaging of source or run-
time information.
Artifact
Node
A node is a physical element that exists
at run time and represents a
computational resource, generally
having at least some memory and,
often, processing capability.
Node
Behavioral things
Behavioral things are the dynamic
parts of UML models.
These are the verbs of a model,
representing behavior over time and
space.
Behavioral things
Interaction
State machine
Activity
Interaction
An interaction is a behavior that
comprises a set of messages exchanged
among a set of objects or roles within a
particular context to accomplish a
specific purpose.
Message
State machine
A state machine is a behavior that
specifies the sequences of states an
object or an interaction goes through
during its lifetime in response to events,
together with its responses to those
events.
State
Activity
An activity is a behavior that specifies
the sequence of steps a computational
process performs.
Action
Behavioral things
In an interaction, the focus is on the set
of objects that interact.
In a state machine, the focus is on the
life cycle of one object at a time.
In an activity, the focus is on the flows
among steps without regard to which
object performs each step.
Grouping things
Grouping things are the organizational
parts of UML models.
These are the boxes into which a model can
be decomposed.
Packages are the basic grouping things with
which you may organize a UML model.
There are also variations, such as
frameworks, models, and subsystems (kinds
of packages).
Package
A package is a general-purpose mechanism
for organizing the design itself, as opposed to
classes, which organize implementation
constructs.
Structural things, behavioral things, and even
other grouping things may be placed in a
package.
Unlike components (which exist at run time),
a package is purely conceptual (meaning that
it exists only at development time).
Annotational Things
Annotational things are the
explanatory parts of UML models.
These are the comments you may apply
to describe, illuminate, and remark
about any element in a model.
Annotational Things
There is one primary kind of annotational
thing, called a note.
Notes can use to adorn diagrams with
constraints or comments that are best
expressed in informal or formal text.
There are also variations on this element,
such as requirements (which specify some
desired behavior from the perspective of
outside the model).
Note
A note is simply a symbol for rendering
constraints and comments attached to
an element or a collection of elements.
Note
Relationships
Dependency
Association
Generalization
Realization
Dependency
A dependency is a semantic
relationship between two model
elements in which a change to one
element (the independent one) may
affect the semantics of the other
element (the dependent one).
Dependency
Association
An association is a structural
relationship among classes that
describes a set of links, a link being a
connection among objects that are
instances of the classes.
Aggregation is a special kind of
association, representing a structural
relationship between a whole and its
parts.
Association
Generalization
A generalization is a specialization/
generalization relationship in which the
specialized element (the child) builds on
the specification of the generalized
element (the parent).
The child shares the structure and the
behavior of the parent.
Generalization
Realization
A realization is a semantic relationship
between classifiers, wherein one
classifier specifies a contract that
another classifier guarantees to carry
out.
Realization
Diagram
A diagram is the graphical
presentation of a set of elements, most
often rendered as a connected graph of
vertices (things) and paths
(relationships).
Diagram
Class diagram
Object diagram
Component diagram
Composite structure diagram
Use case diagram
Sequence diagram
Communication diagram
Diagram
State machine diagram
Activity diagram
Deployment diagram
Package diagram
Timing diagram
Interaction overview diagram
Diagram
Class diagram
A class diagram shows a set of classes,
interfaces, and collaborations and their
relationships.
These diagrams are the most common
diagram found in modeling object-oriented
systems.
Class diagrams address the static design
view of a system.
Class diagrams that include active classes
address the static process view of a system.
Class diagram
Object diagram
An object diagram shows a set of objects
and their relationships.
Object diagrams represent static snapshots
of instances of the things found in class
diagrams.
These diagrams address the static design
view or static process view of a system as do
class diagrams, but from the perspective of
real or prototypical cases.
Object diagram
Component diagram
A component diagram is shows an
encapsulated class and its interfaces,
ports, and internal structure consisting
of nested components and connectors.
Component diagrams address the
static design implementation view of a
system.
Component diagram
Composite structure diagram
A composite structure diagram
shows how objects fit together in an
aggregation or composition, showing
interfaces and collaborating objects.
Composite structure diagram
Use case diagram
A use case diagram shows a set of
use cases and actors (a special kind of
class) and their relationships.
Use case diagrams address the static
use case view of a system.
These diagrams are especially
important in organizing and modeling
the behaviors of a system.
Use case diagram
Sequence diagram
A sequence diagram is an interaction
diagram that emphasizes the time-
ordering of messages.
Sequence diagram
Communication diagram
A communication diagram is an
interaction diagram that emphasizes the
structural organization of the objects or
roles that send and receive messages.
Communication diagram
State machine diagram
A state machine diagram shows a state
machine, consisting of states, transitions,
events, and activities.
State machine diagrams show the dynamic
view of an object.
These diagrams are especially important in
modeling the behavior of an interface, class,
or collaboration and emphasize the event-
ordered behavior of an object, which is
especially useful in modeling reactive
systems.
State machine diagram
Activity diagram
An activity diagram shows the structure of
a process or other computation as the flow of
control and data from step to step within the
computation.
Activity diagrams address the dynamic
view of a system.
These diagrams are especially important in
modeling the function of a system and
emphasize the flow of control among objects.
Activity diagram
Deployment diagram
A deployment diagram shows the
configuration of run-time processing
nodes and the components that live on
them.
Deployment diagrams address the
static deployment view of an
architecture.
Deployment diagram
Package diagram
A package diagram shows the
decomposition of the model itself into
organization units and their
dependencies.
Package diagram
Timing diagram
A timing diagram is an interaction
diagram that shows actual times across
different objects or roles, as opposed to
just relative sequences of messages.
Timing diagram
Interaction overview diagram
An interaction overview diagram is
a hybrid of an activity diagram and a
sequence diagram.
Interaction overview diagram
Extensibility Mechanisms
Extensibility mechanisms help to
shape and grow the UML to meet the
project's needs.
These mechanisms also let the UML
adapt to new software technology.
Extensibility Mechanisms
Stereotypes
Tagged values
Constraints
Extensibility Mechanisms
Stereotype Tagged value
Constraints
Stereotypes
A stereotype extends the vocabulary
of the UML and helps to create new
kinds of building blocks that are derived
from existing ones but that are specific
problem.
Tagged values
A tagged value extends the properties
of a UML stereotype and helps to create
new information in the stereotype's
specification.
Constraints
A constraint extends the semantics of
a UML building block, helps to add new
rules or modify existing ones.
References
Grady Booch, James Rumbaugh, and Ivar Jacobson,
“The Unified Modeling Language User Guide”,
Addison Wesley Professional, 2005
http://en.wikipedia.org/wiki/Unified_
Modeling_Language
http://www.sparxsystems.com/
resources/uml2_tutorial/uml2_timingdiagram.html
Mike O’Docherty, “Object-Oriented Analysis and
Design Understanding System Development with UML
2.0”, John Wiley & Sons Ltd., 2005