Lecture 02: UML
Objectives
Upon completion of this lecture, students will:
1. be able to draw an use case diagram
2. be able to draw a class diagram
3. be able to draw a sequence diagram
4. be able to draw an activity diagram
5. be able to draw a state diagram
Agenda
Engineering Design Cycles
Structured Design
Unified Modeling Language (UML)
The Development Stages
Requirements analysis and specs
Conceptual design
Detailed program design
Implementation
Unit and integration testing
System testing
System delivery
Maintenance
Example Development Life
Cycle Models
R The Waterfall Model
V cycle
Spiral
Rapid Prototyping
Agile Methods
Waterfall Model
V Cycle
Spiral
Rapid Prototyping
Break the problem into little pieces
Get a front-end implementation out quick
Agile Methods
Extreme Programming
Sprints
Focus on small increments
Pair-wise or team programming
Well defined quick tasks to get something out
Scrum
Quick meetings daily and/or weekly
The Actual Design Process
Key steps for success:
Requirement definitions
System specification
Functional design
Architectural design
Prototyping and Test
Structured Design
Breaking down a problem and
systematically deriving a solution
How do you represent this?
Unified Modeling Language
(UML)
A “language” for specifying various
aspects of the product during the design
process
Universal way of sharing ideas
What is UML?
The Unified Modeling Language (UML) is a standard language for
Specifying
Visualizing
Business Modeling
14
Constructing
Documenting
Communications
Different Views (Diagrams)
Users
15
Designers
Analyzers
Summary of UML Diagrams
Summary of UML Diagrams
/>
Use Case Diagram
Gives us an outside view of the system
Describes the public interface for the
module or system
Answers the questions:
What is the behavior that the user sees?
What is the behavior the user expects?
Repeatedly poses the question
“What?” until the external view of the system
has been satisfactorily captured
Use case datagram
presents the main components (use
cases) of the system
How the user interacts with those components
Like many of the diagrams we’ll work with
Use case diagram can be hierarchical in
nature
From top level drawing, one can expand each
use case into subuse cases as necessary
Components of an use case diagram
This diagram comprises three components
The system
The actor(s)
The use case(s)
And relationships:
Association: between actor and use case,
Generalization, include, extend: between one
use case and another
System
Meaning of system is self evident
It’s expressed in the diagram as a box
System boundary
We’ll often leave this off the diagram
Actors
An actor represents : “A coherent set of roles
users of use cases play when interacting
with these use cases.“
Represent any one or any thing that might
be using the system
Human
Hardware device
Another system
Drawn as simple stick figures
Viewed as being outside of the system
Use Cases – Graphical view
Use cases represented as a solid oval
Identify the various behaviors of the system or
ways that it might be used
They encapsulate the events or actions
That must occur to implement the intended behavior
of the system
Are stated or expressed from the point of view of
the user
Accompanying each use case is a textual
component fully describing it
A very powerful tool during the early stages of a
project (Requirements definition)
As we construct the diagram
We place the actor that executes the use case on
the left hand side
Supporting actors appear on the right hand side
Not restricted to human users
Actor can be a computer or other system as well
Set of use cases appears in the center of the
drawing
With arrows indicating the actors involved in the
use case (?)
Actor0UseCase1UseCase2UseCase3Actor1
A generic Use Case Diagram