UML: Unified Modeling
Language
Story:
What UML is for
Some of the main diagrams are and what
you use them for
Class diagrams and class forms
Use Case Diagrams
Sequence (Event) Diagram
State Diagrams
An example
UML: Unified Modeling
Language
Developed by the “Three Amigos”: Grady
Booch, Jim Rumbaugh, Ivar Jacobson
Each had their own development
methodology
More or less emphasis on notation and
process
UML is a notation and a process
Diagrams and notation from UML 1.3
Definition (http://www.rational.com)
Diagrams
Class diagrams: Represents static
structure
Use case diagrams: Sequence of actions
a system performs to yield an observable
result to an actor
Sequence diagrams:Shows how groups of
objects interact in some behavior
State diagrams: Describes behavior of
system by describing states of an object
Class Diagrams
Better name: “Static structure diagram”
Doesn’t describe temporal aspects
Doesn’t describe individual objects: Only the
overall structure of the system
There are “object diagrams” where the
boxes represent instances
But rarely used—other diagrams serve the
role of describing object interaction better
When used, object diagrams describe static
structure, like a data structure
Different Levels of
Specifying Classes
Notation in Class Boxes
Abstract classes (and operations) in italics
+ is public, - is private, # is protected
Can also specify stereotypes or
compartments
“constructors” or “query”
“controller”
Other variations in Class
specifications
Use of
templates,
interfaces, and
types
Can even
specify body of
methods
Components of Class
Diagrams
Multiplicities
How many of
each?
Labels to
indicate how
reference is
viewed
Role and
Association
classes
Navigability and
Aggregations
Navigability
Who owns/contains/has who?
Arrows not strictly required
Aggregation: Open diamond
“Part-of” relationship, but disagreement
Composition:
closed diamond
Part can only
belong to whole
Qualifiers
Serves to describe an instance variable
that partitions the relationship.
Use Case Diagrams
Means of capturing requirements
Document interactions between user(s)
and the system
User (actor) is not part of the system itself
But an actor can be another system
An individual use case represents a task
to be done with support from the system
(thus it is a ‘coherent unit of functionality’)
Simple Use Case Diagram
Reserve book
Borrow book
Return book
Use Case Diagram with
Multiple Actors
Use Cases
Are actually defined as text, including
descriptions of all of the normal and
exception behavior expected
Do not reveal the structure of the system
Collectively define the boundaries of the
system to be implemented
Provide the basis for defining
development iterations
Example Use Case Diagram
(Advanced Features)
Sequence (Event) Diagrams
Shows individual objects and how they
interact
Describes
Lifelines of objects
Who sends what messages when
Can also describe sending messages to self
("self-delegation")
Can describe guards, notes, etc.
Example Sequence
Diagram
State Diagrams
Describe all the possible states a
particular object can get into, and the
events that lead to those changes
Also called a "statechart"
Example State Diagram
Other Kinds of UML
Diagrams
Collaboration Diagrams
An alternative to sequence diagrams for
describing the flow of messages between
objects
Other kinds of UML
Diagrams
Activity Diagrams
Alternative to
statecharts
Other kinds of UML
Diagrams
Implementation
Diagrams
Down at the detail
level
What piece of code
goes where?
How are they
connected?
UML in Real Practice
You don't typically use all the diagrams
You'll choose between them based on preference and
particular situation
You typically use many diagrams
A single use case may not capture all scenarios
If you are going to use statecharts, there are probably
lots of objects with states
Each sequence/collaboration diagram only shows one
interaction
Example: Student
Registration System
Not going to do all the diagrams
Not all types, not even all that completely
specify the system
But this is an application you know, so the
examples may help make sense
Student Registration Class
Diagram
Student
1
transcript
major
schedule
registrar
*
Registrar
Section
course
daysAndTime
roster
addStudent
removeStudent
1
1
Department
courses
requiredCourses
courseGrades
1
*
enrollInClass:
gradeInCourse:
takenCourse:
Transcript
1
*
*
1
getSectionsFor:
enrollInSection:
dropFromSection:
*
1*
1..3
1
courses
sections
gradeForCourse:
takenCourse:
1
*
CourseGrade
*
course
grade
termEnrolled
*
1
Course
*
name
number
0..3
department
creditHours
prereqs
prerequisites
Partial Use Case Diagram
Apply for
Admission
Enroll in
the University
Student
Enroll in
a Course
Withdraw
from a Course
Admissions
States of a Student
Apply [ Must be accepted first ]
Enrolled
EnrollInClass ( Add a Transcript )
Withdraw
Registered
AddCourse
Graduate [ All courses must be completed ]
Sequence Diagram:
Registering for Course
aStudent
theRegistrar
aSection
theTranscript
getSectionsFor:
return sections
enrollInSection:
takenCourse: prerequisite
takenCourse: prerequisite
state of prereq
have prereq
addStudent:
enrolled
enrolled
Process to Representations
OOA
CRC Cards (but they’re not officially UML)
Use Cases
OOD
Just about all of the rest
But variations—some detail is later
OOP
Can actually go UML->code with some tools!
UML v1.3 Copyright Notice
Copyright © 1997, 1998, 1999 Object Management Group, Inc.
Copyright © 1997, 1998, 1999 Hewlett-Packard Company
Copyright © 1997, 1998, 1999 IBM Corporation
Copyright © 1997, 1998, 1999 ICON Computing
Copyright © 1997, 1998, 1999 i-Logix
Copyright © 1997, 1998, 1999 IntelliCorp
Copyright © 1997, 1998, 1999 Electronic Data Services Corporation
Copyright © 1997, 1998, 1999 Microsoft Corporation
Copyright © 1997, 1998, 1999 ObjecTime Limited
Copyright © 1997, 1998, 1999 Oracle Corporation
Copyright © 1997, 1998, 1999 Platinum Technology, Inc.
Copyright © 1997, 1998, 1999 Ptech Inc.
Copyright © 1997, 1998, 1999 Rational Software Corporation
Copyright © 1997, 1998, 1999 Reich Technologies
Copyright © 1997, 1998, 1999 Softeam
Copyright © 1997, 1998, 1999 Sterling Software
Copyright © 1997, 1998, 1999 Taskon A/S
Copyright © 1997, 1998, 1999 Unisys Corporation