Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Download
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword
Like this
242Activity
×
0 of .
Results for:
No results containing your search query
P. 1
UML 2.0 Cheatsheet

UML 2.0 Cheatsheet

Ratings:

4.89

(27)
|Views: 57,510|Likes:
Published by James

More info:

Published by: James on Oct 16, 2007
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See More
See less

01/18/2014

pdf

text

original

 
1
 
UML 2.0
 
Reference
 
Card
 
Meta
 
Model
 
=
 
set
 
of 
 
definitions
 
 
It
 
has
 
a
 
precise
 
syntax
 
 
Describes
 
underlying
 
meaning
 
of 
 
each
 
element
 
 
Draws
 
relationships
 
among
 
elements
 
 
Model
 
consist
 
of 
 
domains
 
/
 
ontology
 
/
 
hierarchies
 
Class
 
includes:
 
 
Component
 
parts
 
 
Attributes
 
 
Operations
 
MODELS
 
Meta
 
Model
 
 –
 
Defines
 
concepts
 
of 
 
Class,
 
Attribute,
 
Operation..etc.
 
Model
 
 –
 
Defines
 
the
 
language
 
to
 
use
 
to
 
describe
 
the
 
domain
 
e.g.:
 
Defines
 
the
 
concepts
 
of 
 
Order,
 
Shipment,
 
Product,
 
ProductID,
 
Buy()
 
User
 
Objects
 
 –
 
Defines
 
Order
 
#12322,
 
Shipment
 
#4545,
 
the
 
product:
 
CD
 
ROM,
 
Price
 
METHODOLOGIES
 
consist
 
of:
 
 
Process
 
 –
 
A
 
set
 
of 
 
activities
 
that
 
accomplish
 
the
 
goals
 
 
Vocabulary
 
 –
 
Used
 
to
 
describe
 
the
 
process
 
and
 
the
 
work
 
products
 
 
A
 
Set
 
of 
 
Rules
 
and
 
Guidelines
 
 –
 
Define
 
the
 
quality
 
of 
 
the
 
process
 
and
 
work
 
products
 
The
 
vocabulary
 
(expressed
 
as
 
notation)
 
is
 
applicable
 
to
 
many
 
methodologies
 
3
 
PRIMARY
 
VIEWS:
 
View
 
is
 
a
 
collection
 
of 
 
diagrams
 
that
 
describe
 
a
 
similar
 
aspect
 
of 
 
a
 
project:
 
Views
 
the
 
system
 
from
 
the
 
perspective
 
of 
 
how
 
external
 
entities
 
(ppl
 
&
 
systems)
 
need
 
to
 
interact
 
with
 
the
 
system
 
 
Functional
 
View
 
 –
 
functions
 
are
 
expresses
 
initially
 
as
 
goals,
 
then
 
fleshed
 
out
 
in
 
narrative
 
to
 
describe
 
what
 
the
 
function
 
is
 
expected
 
to
 
do
 
to
 
achieve
 
the
 
goal;
 
Models
 
the
 
workflow
 
&
 
business
 
process
 
Use
 
Case
 
Diagram
 
 –
 
describes
 
the
 
features
 
that
 
the
 
users
 
expect
 
the
 
system
 
to
 
provide
 
Activity
 
Diagram
 
 –
 
describes
 
processes
 
including
 
sequential
 
tasks,
 
conditional
 
logic,
 
and
 
concurrency
 
(flowchart
 
enhanced
 
for
 
use
 
with
 
object
 
modeling)
 
 
Static
 
View
 
 –
 
provide
 
a
 
snapshot
 
of 
 
elements
 
of 
 
the
 
system;
 
but
 
do
 
not
 
tell
 
you
 
have
 
the
 
elements
 
behave;
 
analogy
 
of 
 
a
 
blueprint
 
which
 
are
 
comprehensive,
 
but
 
descriptions
 
(elements)
 
are
 
stationary;
 
inventory
 
of 
 
what
 
exists
 
in
 
the
 
system
 
and
 
attributes
 
and
 
methods
 
contained
 
within
 
those
 
elements.
 
Class
 
Diagram
 
 –
 
models
 
the
 
rules
 
about
 
types
 
of 
 
objects
 
(classes),
 
the
 
source
 
for
 
code
 
generation
 
and
 
system
 
and
 
sub
system
 
auditing.
 
Object
 
Diagram
 
 –
 
illustrates
 
facts
 
in
 
the
 
form
 
of 
 
objects
 
to
 
model
 
examples
 
and
 
test
 
data.
 
 
2
 
 
Dynamic
 
View
 
 –
 
represents
 
how
 
objects
 
work
 
together
 
and
 
interact
 
and
 
respond
 
to
 
the
 
environment
 
Sequence
 
Diagram/Collaboration
 
Diagrams
 
 –
 
describe
 
how
 
object
 
talk
 
to
 
each
 
other
 
Statechart
 
Diagrams
 
 –
 
looks
 
at
 
how
 
an
 
object
 
reacts
 
to
 
external
 
stimuli
 
and
 
manages
 
internal
 
changes;
 
how
 
and
 
why
 
object
 
changes
 
over
 
time
 
4
 
REQUIREMENT
 
CATEGORIES
:
 
1)
 
Business
 
Process
 
 –
 
To
 
use
 
a
 
system,
 
you
 
need
 
to
 
know
 
how
 
to
 
interact
 
with
 
it
 
and
 
why;
 
describe
 
your
 
relationship
 
with
 
the
 
system
 
in
 
terms
 
of 
 
interactions;
 
look
 
beyond
 
the
 
process
 
into
 
the
 
reason
 
of 
 
the
 
process
 
(justification
 
of 
 
having
 
the
 
process)
 
 
What
 
results
 
does
 
the
 
operation/process
 
produce?
 
 
What
 
would
 
happen
 
to
 
the
 
rest
 
of 
 
the
 
system
 
if 
 
you
 
didn’t
 
have
 
the
 
process
 
in
 
place?
 
 
Would
 
another
 
alternative
 
process
 
fail?
 
Focus
 
on
 
results
 
than
 
processes;
 
quantify
 
the
 
value
 
of 
 
the
 
results;
 
allocate
 
resource
 
proportional
 
to
 
the
 
value
 
of 
 
results
 
2)
 
Constraints
are
 
limitations/boundaries
 
around
 
what
 
you
 
can
 
do
 
to
 
develop
 
a
 
solution
 
for
 
the
 
system;
 
it
 
limits
 
the
 
options
 
you
 
have
 
at
 
every
 
phase
 
of 
 
development.
 
Type
 
of 
 
constraints:
 
user
 
limits
 
like
 
client
 
skills;
 
limitations
 
imposed
 
by
 
policies,
 
procedures,
 
laws,
 
contracts;
 
technical
 
limits
 
like
 
protocols,
 
legacy,
 
data
 
conversions,
 
data
 
types
 
and
 
sizes;
 
performance
 
limits
 
that
 
conflict
 
with
 
or
 
sabotage
 
business
 
requirements.
 
3)
 
Rules
 
 –
 
where
 
constraints
 
are
 
like
 
mandates,
 
rules
 
are
 
agreements.
 
Rules
 
should
 
be
 
enforced
 
but
 
if 
 
a
 
better
 
way
 
to
 
do
 
something
 
is
 
found,
 
it
 
can
 
be
 
negotiable
 
to
 
the
 
stakeholders;
 
business
 
directives
 
and
 
decisions
 
derived
 
from
 
legislation,
 
regulations
 
are
 
common;
 
rules
 
refocus
 
your
 
attention
 
on
 
why
 
the
 
client
 
is
 
doing
 
the
 
 job
 
a
 
particular
 
way.
 
4)
 
Performance
 
 –
 
how
 
well
 
the
 
system
 
should
 
perform
 
when
 
you
 
use
 
it;
 
questions
 
on
 
how
 
many
 
users
 
will
 
use
 
the
 
system?
 
How
 
many
 
concurrently?
 
How
 
slow
 
can
 
the
 
system
 
be
 
before
 
it
 
interferes
 
with
 
work,
 
operation
 
or
 
transaction?
 
 
Object
 
Orientated
 
Principles
 
(OOP)
 
:
 
Abstraction
 
is
 
a
 
representation
 
of 
 
something;
 
only
 
describes
 
information
 
that
 
you
 
need
 
in
 
order
 
to
 
solve
 
a
 
problem.
 
The
 
rules
 
that
 
define
 
the
 
representation
 
make
 
up
 
a
 
class.
 
(Defintion,
 
template,
 
blueprint)
 
An
 
object
 
is
 
an
 
instance
 
(representation)
 
of 
 
the
 
class
 
which
 
created,
 
manufactured
 
or
 
instantiated.
 
To
 
function
 
properly,
 
every
 
object
 
has
 
to
 
know
:
 
 
Its
 
own
 
current
 
condition
 
(state)
 
 
Can
 
describe
 
itself 
 
 
Knows
 
what
 
it
 
can
 
do
 
 
What
 
can
 
be
 
done
 
to
 
it
 
Encapsulation
 
 
What
 
you
 
need
 
to
 
know
 
in
 
order
 
to
 
use
 
the
 
object
 
 
What
 
you
 
need
 
to
 
know
 
to
 
make
 
the
 
object
 
work
 
properly
 
 
(exposing
 
interfaces)
 
What
 
needs
 
to
 
be
 
inside
 
the
 
object
 
to
 
work
 
properly
:
 
 
Implementations
 
for
 
each
 
interface
 
 
Data
 
that
 
describes
 
the
 
structure
 
of 
 
the
 
object
 
 
Data
 
that
 
describes
 
the
 
current
 
state
 
of 
 
the
 
object
 
Purpose
 
drives
 
the
 
design
 
and 
 
use
 
of 
 
the
 
object 
 
 
USE
 
CASE
 
Use
 
Case
 
Model
 
includes:
 
1)
 
diagram
,
 
2)
 
narrative
 
&
 
3)
 
scenarios
.
 
Use
 
Cases
 
focuses
 
on
 
critical
 
success
 
factors
 
of 
 
the
 
system.
 
Features
 
can
 
be
 
tested,
 
modeled,
 
designed
 
and
 
implemented
 
 
3
 
Elements
 
of 
 
Use
 
Case
 
Diagram:
 
 
System
sets
 
the
 
boundary
 
of 
 
the
 
system
 
in
 
relation
 
to
 
the
 
actors
 
who
 
use
 
it
 
(outside
 
the
 
system)
 
and
 
the
 
features
 
it
 
must
 
provide
 
(inside
 
the
 
system)
 
 
Actor
 
 –
 
a
 
role
 
played
 
by
 
a
 
person,
 
system,
 
or
 
device
 
that
 
has
 
a
 
stake
 
in
 
the
 
successful
 
operation
 
of 
 
the
 
system
 
 
Use
 
Case
 
 –
 
key
 
feature,
 
without
 
the
 
system
 
will
 
not
 
fulfill
 
the
 
user/actor
 
requirements.
 
 
Association
 
 –
 
identifies
 
an
 
interaction
 
between
 
actors
 
and
 
use
 
cases.
 
Each
 
association
 
becomes
 
a
 
dialog
 
that
 
must
 
be
 
explained
 
in
 
the
 
narrative.
 
 
Dependency
 
 –
 
identifies
 
communication
 
relationship
 
between
 
two
 
use
 
cases.
 
 
Generalization
 
 –
 
defines
 
a
 
relationship
 
between
 
two
 
actors
 
or
 
two
 
use
 
cases
 
where
 
the
 
use
 
case
 
inherits
 
and
 
adds
 
to
 
or
 
overrides
 
the
 
properties
 
of 
 
another.
 
Set
 
the
 
context
 
of 
 
the
 
target
 
system
 
(frame
 
of 
 
reference);
 
problem
 
statement;
 
context
 
defines
 
place
 
of 
 
the
 
system
 
within
 
the
 
business,
 
work
 
processes,
 
people,
 
objectives,
 
dependent
 
systems,
 
 job
 
duties,
 
constraints
 
impositions.
 
 
Identify
 
the
 
actors
 
(person
 
or
 
system)
 
 
Identify
 
the
 
use
 
cases
.
 
What
 
does
 
the
 
system
 
produce
 
for
 
the
 
actor
 
(critical
 
outputs)?
 
What
 
does
 
the
 
actor
 
help
 
the
 
system
 
do?
 
What
 
does
 
the
 
system
 
do
 
to
 
help
 
the
 
actor.
 
 
Define
 
associations
 
Relationship
 
Notations:
 
 
 Association
 
notation
 
 –
 
actor
 
communicates
 
with
 
the
 
Use
 
Case
 
Stereotype
 
notation
 
use
 
of 
 
<<
 
>>
 
on
 
UML
 
classifiers
 
like:
 
classes,
 
Use
 
Case
 
Dependencies,
 
Packages
 
 
<<include>>
when
 
a
 
use
 
case
 
always
 
asks
 
for
 
help
 
from
 
another
 
use
 
case;
 
need
 
to
 
delegate
 
some
 
duties
 
 
<<extend>>
when
 
a
 
use
 
case
 
might
 
asks
 
for
 
help
 
from
 
another
 
use
 
case
 
Elements
 
of 
 
a
 
Use
 
Case
 
Narrative:
 
 
Assumptions
 
 –
 
state
 
of 
 
the
 
system
 
that
 
must
 
be
 
true
 
before
 
needed
 
conditions
 
are
 
met
 
 
Pre
conditions
 
 –
 
same
 
as
 
assumptions
 
except
 
it
 
is
 
tested
 
by
 
the
 
system
 
 
Use
 
Case
 
Initiation
 
 –
 
trigger
 
to
 
launch
 
use
 
case;
 
what
 
is
 
the
 
triggering
 
mechanism?
 
 
Process
 
or
 
Dialog
 
 –
 
step
by
step
 
description
 
of 
 
the
 
conversation
 
between
 
use
 
case
 
(system)
 
and
 
the
 
actor;
 
sequence
 
of 
 
events
 
(match
 
with
 
activity
 
diagram)
 
 
Use
 
Case
 
Termination
 
 –
 
Normal
 
and
 
Abnormal
 
(
 
Error
 
Messaging
 
/
 
Cancelling
 
/
 
Rollbacks
 
)
 
 
Post
Conditions
 
 –
 
state
 
of 
 
the
 
system
 
that
 
must
 
be
 
true
 
when
 
the
 
use
 
case
 
ends
 
Building
 
Attributes
 
in
 
Class
 
Diagram
 

Activity (242)

You've already reviewed this. Edit your review.
FGRibreau liked this
1 thousand reads
1 hundred reads
TheFDB liked this
ali_impulse liked this
liluuu liked this
Karol Dro liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->