Introduction to the

Unified Modeling Language

COM 213
Introduction to UML
Unified Modeling Language
• UML is an object-oriented modeling language (or more
precisely, a collection of modeling languages) that is
• expressive
• semi-formal (UML 2.0 added much more formality)
• capable of supporting incremental development
• Elements can be hidden
• Certain elements can be left incomplete
• Inconsistencies can exist
• process independent
• UML can be used with a variety software development process
models
• Customizable and extensible
A Brief Timeline for OO and UML
• 60’s
• Birth of initial OO ideas
• 70’s
• Nurturing of OO ideas
• Introduction of a few more OO Programming Languages
• 80’s
• Maturing of fundamental OO concepts
• Emergence of more OOPL’s
• OOPL’s gain widespread use
A Brief Timeline for OO and UML
▪ 90’s
• The Method Wars Booch, Jacobson, Rumbaugh
• Efforts to unify concepts
• Introduction and standardization of UML
• Emergence of next-generation ideas, like Patterns
• Current
• Widespread use of UML
• Widespread use Full-Life-Cycle development tools
UML Building Blocks
• Modeling Elements
• Structural Student
• Behavioral major: String
• Organizational gpa: Real
standing: String
• Annotational Contacts
add(Course)
• Diagrams that drop(Course)
communicate ideas -- Handle a registration in

using the modeling courses

elements See Fig. 2 for

more details
Registered *
Student
• Views
*
Graduate Course
Course
Modeling Elements
Modeling Elements are building blocks for
constructing conceptual descriptions of systems
• Definition and Scope Behavioral Things
• Use Cases – Messages
• Automation Boundaries – States
– Transitions
• Structural – Events
• Objects
• Classes Organizational Things
• Relations – Packages
• Interfaces – Views
• Components
• Nodes Annotation
• Extension – Comments
• Templates – Specifications
• Stereotypes

*Note that this is not a complete list

Modeling Elements and Diagrams
• Diagrams represent chunks of information that
need to be communicated as part of a conceptual
description.
• It usually requires many diagrams to describe a system
• Each diagram should focus on a single thought or a small
set of tightly related thoughts
• Diagrams are like paragraphs in a section of well-
structured text
UML Diagrams
• Use Case Diagrams
• Class Diagrams
• Object Diagrams
• Interaction Diagrams
• Sequence Diagrams
• Communication Diagrams
• State Charts (enhanced State Machines)
• Component Diagrams
• Deployment Diagrams
Views
• A view is a set of diagrams that describe one aspect of a system or describe
the system from a given perspective
• Views are like the sections of a book, and a model is like the entire book
• Some common views:
• Use-case view
• Logical view
• Implementation view
• Process view
• Deployment view
Views and Methods
• The construction and ultimate value of a view is that it is closely tied
to the process used to create the view.
• The process imposes a certain perspective on the modeling activity
• To understand a view, one needs to know the intended perspective
Three Software-Engineering
Modeling Perspectives
• Analysis – for understanding
• The objects represented in the models are real-world objects
• Models focus on problem-domains concepts
• They describe systems as they are

• Specification – for scoping and planning

• The models include both real-world and software objects
• The models show automation boundaries
• The models describe what the system is to become

• Implementation – for designing / building

• The objects in the models are mostly software objects
• The models focus on solution-oriented concepts
• The models describe what the software system is or will be
Analysis Perspective
• Classes are sets of objects
Student
• Classes may include attributes and name
operations, but more importantly major
their intents are defined by GPA
standing
responsibilities interests

• Relationships are set of links between

-- The set of students
objects known to the
registration system
• Components relate to the problem
Registered *
domain Student
*
Course
name

-- The set of possible

courses
Specification Perspective
StudentR • Classes define abstraction
name boundaries and
major
GPA encapsulations for software
standing
interests
objects
-- The set of students known to the
registration system

StudentS

name: String
major: String
GPA: real
standing: Scode
add(Course)
drop(Course)
-- Software representation of students;
support registration in courses
Implementation Perspective
StudentDialogBox Student
major: String
create()
GPA: Real
doDataExchange()
standing: String
onDelete()
onInsert() add(Course)
onOK() drop(Course)
-- Interact with user to add -- Handle a registration in
drop courses courses
0..1

1
Course
callNumber: Integer
CourseList department
number
-- Display a dynamic list section
courses title
Implementation Perspective
• Classes can represent software
Object components in frameworks,
libraries, or external systems
Frame

Window

Dialog ListBox

0..1 1
StudentDialogBox CourseList

-- Interact with user to add -- Display a dynamic list

drop courses courses
Some Interesting UML Modeling
Questions
• How do we discover objects or classes?
• When should we focus on problem-domain objects,
solution-domain objects, or environment objects?
• How can we keep the different perspectives straight?
• Should each perspective be captured by a different
model or can they all be managed in one model?
• How much detail should you put in a diagram, a view, or
a model?
 More UML Modeling Questions

• How should you distribute responsibilities among classes?

• What happens when classes get too big, i.e. inadequate distribution?
• What happens when classes are too small, i.e. too fine of grain distribution?
• What happens when there are a lot of dependency relationships between
classes, i.e., inappropriate or ad hoc distribution?
 Object Oriented Model:
Requirements Analysis
• Requirements analysis
• specifies software’s operational characteristics
• indicates software's interface with other system elements
• establishes constraints that software must meet
• Requirements analysis allows the software engineer (called an
analyst or modeler in this role) to:
• elaborate on basic requirements established during earlier requirement
engineering tasks
• build models that depict user scenarios, functional activities, problem
classes and their relationships, system and class behavior, and the flow of
data as it is transformed.

18
 Analysis Phase: What is it?

Three objectives:
• To describe what the customer requires
• To establish a basis for the creation of a software design
• To define a set of requirements that can be validated once the
software is built

19
Analysis Modeling Approaches
• Structural analysis:
• The data: The model defines their attributes and relationships.
• The processes that transform the data: The model shows how they
transform the data objects as they flow through the system.
• Object-oriented analysis:
• Focus: Classes and their inter-relationships
• UML is predominantly object-oriented

But don’t be to dogmatic! 20

Elements of the Analysis Model
Scenario-based
elements Flow-oriented elements
Use-case diagrams
Use cases - text Data-flow diagrams
Activity Diagrams Control flow diagrams
Swim lane diagrams Processing narratives
Analysis
Model
Class-based elements
Class diagrams Behavioral elements
State diagrams
Analysis Packages
Sequence diagrams
CRC Models
Collaboration Diagrams
21
Data Modeling
• examines data objects independently of
processing
• focuses attention on the data domain
• creates a model at the customer’s level of
abstraction
• indicates how data objects relate to one
another

22
What is a Data Object?

Object —something that is described by a set

of attributes (data items) and that will be
manipulated within the software (system)
each instance of an object (e.g., a book)
can be identified uniquely (e.g., ISBN #)
each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are
themselves data items

What are some typical data objects?

23
Typical Data Objects

external entities (printer, user, sensor)

things (e.g, reports, displays, signals)
occurrences or events (e.g., interrupt, alarm)
roles (e.g., manager, engineer, salesperson)
organizational units (e.g., division, team)
places (e.g., manufacturing floor)
structures (e.g., employee record)

24
Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

How do data objects differ from OO classes or do they?

25
 What is a Relationship?

relationship —indicates “connectedness”;

a "fact" that must be "remembered"
by the system and cannot or is not computed
or derived mechanically

• several instances of a relationship can exist

• objects can be related in many different ways

26
Elements of the Analysis Model
Scenario-based Onward to data flow diagrams!
elements Flow-oriented elements
Use-case diagrams
Use cases - text Data-flow diagrams
Activity Diagrams Control flow diagrams
Swim lane diagrams Processing narratives
Analysis
Model
Class-based elements
Class diagrams Behavioral elements
State diagrams
Analysis Packages
Sequence diagrams
CRC Models
Collaboration Diagrams
27
Object Oriented Analysis (OOA)

• The intent of OOA is to define all classes (and the

relationships and behavior associated with them) that are
relevant to the problem to be solved. For that, a number of
tasks must occur:
1. Classes must be identified (i.e., attributes and methods)
2. A class hierarchy is defined
3. Object-to-object relationships should be represented
4. Object behavior must be modeled
5. Tasks 1 through 4 are reapplied iteratively

28
Object-Oriented Concepts
• What are the basic object oriented concepts?

29
Object-Oriented Concepts
• What are the basic object oriented concepts?

• Classes and objects

• Attributes and operations
• Encapsulation and instantiation
• Inheritance

30
 Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
method method
manipulate the data #1 #2
data

method
method #3
#6

method method
#5 #4

Achieves “information hiding”

31
Scenario Based Modeling:
Use-Cases
“[Use-cases] are simply an aid to defining what exists
outside the system (actors) and what should be
performed by the system (use-cases).” Ivar Jacobson
• a scenario that describes a “thread of usage” for a
system
• actors represent roles people or devices play as the
system functions
• users can play a number of different roles for a given
scenario

32
Class-Based Modeling
• Identify analysis classes by examining the problem
statement
• Use a “grammatical parse” to isolate potential classes
• Identify the attributes of each class
• Identify operations that manipulate the attributes

33
Grammatical Parsing
• Write an informal description of the problem. The customer
requirements document is one such description.
• Underline all nouns in the description
• Decide which of these are really objects which the project
requires and organize them in related clusters

34
Grammatical Parsing
University Bank will be opening in Oxford, Mississippi, in January,
2000. We plan to use a full service automated teller machine (ATM)
system.The ATM system will interact with the customer through a
display screen, numeric and special input keys, a bankcard reader, a
deposit slot, and a receipt printer.Customers may make deposits,
withdrawals, and balance inquires using the ATM machine, but the
update to accounts will be handled through an interface to the
Accounts system.Customers will be assigned a Personal Identification
Number (PIN) and clearance level by the Security system. The PIN can
be verified prior to any transaction.In the future, we would also like to
support routine operations such as a change of address or phone
number using the ATM
35
Grammatical Parsing
• University Bank will be opening in Oxford, Mississippi, in January,
2000. We plan to use a full service automated teller machine (ATM)
system.The ATM system will interact with the customer through a
display screen, numeric and special input keys, a bankcard reader, a
deposit slot, and a receipt printer.Customers may make deposits,
withdrawals, and balance inquires using the ATM machine, but the
update to accounts will be handled through an interface to the
Accounts system.Customers will be assigned a Personal
Identification Number (PIN) and clearance level by the Security
system. The PIN can be verified prior to any transaction.In the future,
we would also like to support routine operations such as a change of
address or phone number using the ATM

36
Typical Classes (a reminder)
• External entities - printer, user, sensor
• Things - reports, displays, signals
• Occurrences or events (e.g., interrupt, alarm)
• Roles (e.g., manager, engineer, salesperson)
• Organizational units (e.g., division, team)
• Places (e.g., manufacturing floor or loading dock)
• Structures (e.g., sensors, four-wheeled vehicles, or computers)

But, how do we select classes?

37
Selecting Classes—Criteria

retained information
needed services
multiple attributes
common attributes
common operations
essential requirements

38
 CRC Modeling

• See specific CRC slides

39
 Rules of Thumb
• The model should focus on requirements that are visible within the
problem or business domain. The level of abstraction should be
relatively high.
• Each element of the analysis model should add to an overall
understanding of software requirements and provide insight into
the information domain, function and behavior of the system.
• Delay consideration of infrastructure and other non-functional
models until design.
• Minimize coupling throughout the system.
• Be certain that the analysis model provides value to all
stakeholders.
• Keep the model as simple as it can be.

40
Use Cases
Introduction
• Use Case: “... a typical interaction between a user
and a computer system”, Booch
• Here, “user” is anything that needs or invokes the
functionality of the system
• “Computer system” is the system being modeled
• Use cases can capture and document the user-visible
functionality of a system
• Use cases capture how the system will benefit the
user
• Each use case achieves a discrete goal for the user
Goals
• Use cases help everyone come to a common
understanding of what the system should do
• Developers
• End-users
• Domain Experts

• Use-cases are a communication tool for the design

(not the implementation)
• Use cases represent a functional requirement of
your system (as a whole)
User Goals
• User Goals are statements that represent what the
users need to accomplish, independent of specific
software features
• Examples of user goals for a Student Records
Management System
• Ensure that a student’s records reflects courses taken
and grades received in those courses
• Allow only authorized faculty and staff to update student
records
• Ensure that students can obtain copies of their own (and
only their) records in a timely manner
System Interactions
• Represent expected interacts between users and the
computer-based system
• Suggest how the system fulfills a user goal
• Examples:
• A teacher alters a course grade for a student by
• selecting a semester
• selecting a course
• selecting a student
• reviewing the previous grade
• entering a new grade
• confirming the change
• A process for an administrator to create a new user
• A process for granting a user access rights
User Goals vs. System Interactions

• In some cases, system interactions and user goals

can be very similar
• However, confusing system interactions with user
goals or neglecting to identify user goals can
• fail to bring out and document the reasons why a
system should must certain features
• result in lost opportunities for creativity
User Goals vs. System Interactions

• User goals help answer “What” and “Why”

questions
• System interactions help answer “How” questions
(from a user’s perspective)
• We will model user goals with Uses Cases
• Later, we will model system interactions with
interaction diagrams or activity diagrams
Use Case Diagrams
• Use Case Diagrams provide a visual way to
document user goals and explore possible
functionality
• Three primary modeling components:
• Actors
• Use Cases – Relationships between
use cases
Record class grades Review Transcripts

Teacher
Authorized Student
Staff Worker
Actors
• Actors are things outside the system that need to
interact with the system
• Actors carry out use cases
• Actors are represented as stick figures
• Although users are actors, not all actors are users
• Actors can be external software systems
• External hardware (sensors, actuators, etc.)
• Actors can be people that need the functionality of the
system, but may not be the ones who actually invoke
the software commands
Hints for Finding Actors
• Who or what will use the main functionality of the system?
• Who or what will provide input to this system?
• Who or what will use output from this system?
• Who will need support from the system to do their work?
• Are there any other software systems with which this one needs to interact
• Are there any hardware devices used or controlled by this system?
Hints for Modeling Actors
• An actor can be a role that a user plays with respect to
the system
• A single person may play different roles
• A single actor may perform many use cases
• A use case may be performed by many actors
• Show external systems as actors only when they are
the ones who need a use case
• Don’t worry too much about the details of an actor or
the relationship between actors and use cases
Relationships Between Actors
• Actors are Classifiers, meaning they are sets of
instances
• Therefore, an actor (a set of instances) can be a
subset of another actor (another set of instances)
• Generalization / Specialization

Student

Graduate
Student
Use Cases
• Each use case represents something the user
needs to do with the system – a goal
• A use cases is given a short name and textual
description (optional)
• Use cases can be large or small from a conceptual
perspective
• Use cases can relate to each other via
dependencies, such as
• <<extends>>
• <<includes>>
• Generalization or <<refines>> (“is a”)
Use Cases
• Extension point example:
• http://www.visualcase.com/kbase/usecase.jpg

Includes

Extends

Generalization
Hints for Finding Use Cases
• Try listing actors first and then look at the activities each
needs to perform and then try to express the goal that
represent these activities
• although this will uncover many valuable use cases, it will not find
them all
• Try listing external events and then look at what the
system needs to do in response to each one.
• This technique will find some additional use cases, but not all
• Be patient, allow the use cases to unfold
• Don’t over do it – Use Case Diagram should be broad-
brush characterizations of user goals
Hints for Modeling Use Cases
Establish the context of a user goal by
identifying the actors
For each actor, consider the behavior that it
expects or requires the system to provide
Name these common behaviors as use
cases
Factor common behavior into new use cases
Relate the use cases using the extend,
includes, and refines dependencies
Adorn uses cases with notes
Use-Case Relationships
• Extends dependency: defines a use-case that is a variation of another,
usually for handling an abnormal situation

Alter Student Grade

<<extends>>

Alter student grade for Authorized

a class taken more Staff Worker
than a year ago
Use-Case Relationships
• Includes Dependency: Defines how one use case can invoke behavior
defined by another use case

Alter Student Grade

<<includes>>

Record Grades for a

Teacher
Section
Use-Case Relations
• Generalization: Defines one use case as a
generalization of another.

Alter Student Grade

Alter Student Grade for

Teacher
a Graduate Course
Use-Case Relations
Alternate way of showing for use-case refinement

Alter Student Grade

<<refines>>

Alter Student Grade for

Teacher
a Graduate Course
Extends vs. Includes vs.
Generalization
• Extends, includes, and generalization may appear
similar, but differ in intent
• Extend dependencies model variations from normal
workflows
• Specializations are refinements of a general use cases
• “Include” uses case (or sub-use cases), unlike
specializations, can represent different goals or
processes
• Include dependencies are a form of aggregation
• The actors for a general use case are also actors for the
use cases that specialize it
• Often there are no actors for sub-use cases
Use Case Diagrams
• A use case diagram consists of actors, use cases, and
relations among use cases
• A use case diagram can also include
• notes
• constraints
• subjects (like the system) to show ownership of the use
cases
• packages to group elements into larger conceptual
chunks
• instances of use cases or actor, to show specific
examples
A Well-structured Use Case
Diagram
• Focuses on communicating one aspect of the system’s
functionality
• Describes the flow of events clearly enough for an outsider
to understand it
• Factors in common behavior by pulling such behaviors from
other use cases it includes
• Factors variants out by having other use cases “extend” itself
• Contains only those use cases and actors that are essential
to understanding that functionality
• Provides detail consistent with its level of abstraction
• Is not so minimal that it misinform the reader about
important semantics
More Hints
• When drawing a use case diagram:
• give the diagram a name that communicates its purpose
• lay out its elements to minimize crossing lines
• organize its elements spatially so behaviors and roles
that are conceptually close are laid out close together on
the diagram
• use notes and color as visual clues
Benefits of Use Cases
• Use cases diagrams capture user-visible functions
• Identifying actors help capture who needs the
system functionality
• Relationships between use cases document
opportunities for reuse
• Use cases provide a basis planning and scheduling
incremental development
• Use cases can provide a basis for system testing
Questions
• Who might be interested in reviewing or using use case
diagrams?
• When in the development life cycle should we employ use
cases?
• What do use cases have to do with object-orientation?
• What level of use-case granularity is best?
• How many use cases are enough?
• Can other modeling activities help in discovering use cases?
• When in the development life cycle do we stop referring to
or refining the use cases?
• What should the text description of use case contain?