Introduction to UML:
Structural &Use Case Modeling
1. Software Engineering Tour
5 stages of software development process

Requirements analysis and definition:


Design:



Realize the design as a set of programs or program units
Unit testing verifies that each unit meets its specification
Integration and system testing:


Establish the system’s architecture
Implementation and unit testing:


Establish the application’s goals and constraints in consultation with users
Integrate the program units and test as a complete system
Maintenance:

Correct errors, improve implementation, and enhance the system’s services
as new requirements are discovered
What is the primary driver of software costs?
 Most money and effort (82%) spent in testing and
maintenance
 But: 85% of errors are introduced during requirements
analysis and design
3%
8%
7%
15%
Requirements -- 3%
Design
-- 8%
Implementation -- 7%
Testing
-- 15%
Maintenance
-- 67%
67%
Software Cost
Waterfall model of software process
A sequential software development model (a process
for the creation of software) in which development is
seen as flowing steadily downwards (like a waterfall)
through the phases of requirements analysis, design,
implementation, testing (validation), integration, and
maintenance.
Waterfall model
Progress flows from the top to the bottom, like a waterfall.
V model of software process
An extension of the waterfall model. Instead of moving
down in a linear way, the process steps are bent
upwards after the coding phase, to form the typical V
shape. The V-Model demonstrates the relationships
between each phase of the development life cycle and
its associated phase of testing.
V model
Prototyping of software process




This model adds prototyping as sub-process
A prototype is a partially developed product that enables
customers and developers to examine some aspect of a
proposed system and decide if it is suitable for a finished
product
Why add prototypes to the life cycle?
Used to explore the risky aspects of the system:



Risk of developing the “wrong” system (what customer doesn’t
want), can be a user interface without functionality
Other technical risks – e.g. performance, using a new technology,
alternative algorithms, etc.
Prototype may be thrown away or evolve into product
Rational Unified Process (RUP)

Developed by “three amigos” at Rational Software (IBM)






Grady Booch, Ivar Jacobson, and Jim Rumbaugh
Unified Modeling Language (UML) is a set of graphical and linguistic
notations for modeling systems, not a process or method
The three amigos also developed Rational Unified Process (RUP)
You don’t have to use RUP to use UML
Interestingly different from the traditional waterfall model
Highly iterative and incremental process


Software product is not released in one big bang at end of project
Instead, developed and released in pieces (prototypes, partial releases,
beta, etc.)
How do traditional stages iterate?
Workflows look traditional, but they iterate in four phases
What does iteration imply about RUP?
How can iterations reduce risk or reveal problems?
2. UML Modeling Basics
What is UML?



14
UML stands for Unified Modeling Language
In the field of software engineering, UML is a
standardized specification language for object
modeling.
UML is a general-purpose modeling language
that includes a graphical notation used to create
an abstract model of a system, referred to as a
UML model.
Why UML?
15
What is UML?
 Is a language. It is not simply a notation for drawing
diagrams, but a complete language for capturing
knowledge(semantics) about a subject and expressing
knowledge(syntax) regarding the subject for the
purpose of communication.
 Applies to modeling and systems. Modeling involves
a focus on understanding a subject (system) and
capturing and being able to communicated in this
knowledge.
 It is the result of unifying the information systems
and technology industry’s best engineering practices
(principals, techniques, methods and tools).
16
Unified Modeling Language (UML)




17
used for both database and software modeling
version 1.1 was adopted in November 1997 by the Object
Management Group (OMG) as a standard language for
object-oriented analysis and design
Initially based on a combination of the Booch, OMT (Object
Modeling Technique) and OOSE (Object-Oriented Software
Engineering) methods, UML was refined and extended by a
consortium of several companies, and is undergoing minor
revisions by the OMG Revision Task Force.
Ivar Jacobson is known as the father of Use Cases.
Topics on UML
1. Structural Modeling with UML
Structural model: a view of an system that emphasizes
the structure of the objects, including their classes,
relationships, attributes and operations.
2. Use Case Modeling with UML
Use case model: a view of a system that emphasizes
the behavior as it appears to outside users. A use case
model partitions system functionality into transactions
(‘use cases’) that are meaningful to users (‘actors’).
18
2.1 Structural Modeling




19
What is structural modeling?
Core elements
Core relationships
Structural diagram
What is structural modeling?

20
Structural model: a view of an system that
emphasizes the structure of the objects, including
their classes, relationships, attributes and
operations.
Structural Modeling: Core Elements
Construct Description
a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
a named set of operations that
interface
characterize the behavior of an
element.
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
a run-time physical object that
node
represents a computational
resource.
Syntax
class
21
«interface»
Structural Modeling: Core Elements (cont’d)
Construct Description
constraint¹
Syntax
a semantic condition or restriction.
{constraint}
¹ An extension mechanism useful for specifying structural elements.
22
Structural Modeling: Core Relationships
Construct
Description
a relationship between two or more
classifiers that involves connections
among their instances.
A special form of association that
aggregation
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
generalization a taxonomic relationship between a
more general and a more specific
element.
a relationship between two modeling
dependency
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).
association
23
Syntax
Structural Modeling: Core Relationships (cont’d)
24
Construct
Description
realization
a relationship between a specification
and its implementation.
Syntax
Structural Diagram Tour

Show the static structure of the model
the entities that exist (e.g., classes, interfaces, components,
nodes)
 internal structure
 relationship to other entities



Do not show

temporal information

static structural diagrams
Kinds

25


class diagram
object diagram


component diagram
deployment diagram
implementation diagrams
Static Structural Diagrams


26
Shows a graph of class elements connected by static
relationships.
kinds
 class diagram: class view
 object diagram: instance view
Class/Object
Window
Window
size: Area
visibility: Boolean
display ()
hide ()
27
Window
{abstract,
author=Joe,
status=tested}
+size: Area = (100,100)
#visibility: Boolean = true
+default-size: Rectangle
#maximum-size: Rectangle
-xptr: XWindow*
+display ()
+hide ()
+create ()
-attachXWindow(xwin:Xwindow*)
Class: compartments with names
Reservation
operations
guarantee()
cancel ()
change (newDate: Date)
responsibilities
bill no-shows
match to available rooms
exceptions
invalid credit card
28
Class: method body
PoliceStation
alert (Alarm)
1 station
*
BurglarAlarm
isTripped: Boolean = false
report ()
29
{ if isTripped
then station.alert(self)}
Types and Implementation Classes
«type»
Object
* elements
«type»
Set
addElement(Object)
removeElement(Object)
testElement(Object):Boolean
30
«implementationClass»
HashTable
1 body
«implementationClass»
HashTableSet
addElement(Object)
removeElement(Object)
testElement(Object):Boolean
setTableSize(Integer)
Interfaces: Shorthand Notation
StoreHome
-storeId: Integer
-POSlist: List
POSterminalHome
POSterminal
<<use>>
POSterminal
Store
31
Store
+create()
+login(UserName, Passwd)
+find(StoreId)
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
Interfaces: Longhand Notation
StoreHome
-storeId: Integer
-POSlist: List
POSterminalHome
POSterminal
<<use>>
POSterminal
<<interface>>
Store
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
32
Store
+create()
+login(UserName, Passwd)
+find(StoreId)
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
Associations
Company
Job


employer employee
Job
salary
Person
boss
worker 
0..1
Manages
Person
Account
{X or}
Corporation
33
Composition
Window
scrollbar [2]: Slider
title: Header
body: Panel
Window
1
scrollbar
Slider
34
2
1
1
title
1
Header
body
1
Panel
Generalization
Shape
Separate Target Style
Polygon
Ellipse
Spline
. ..
Shape
Polygon
35
Ellipse
Shared Target Style
Spline
...
Dependencies
ClassA
ClassD
ClassB
«friend»
«friend»
operationZ()
«instantiate»
«call»
ClassC
«refine»
ClassD
36
ClassC combines
two logical classes
ClassE
Derived Attributes and Associations
Person
birthdate
/age
{age = currentDate - birthdate}
1
Company
1
 Department
employer
1
employer


department
WorksForDepartment
Person
/WorksForCompany
{ Person.employer=Person.department.employer }
37
Constraints and Comments
 Member-of 
Person
Committee
{subset}
1

Person
0..1
boss
Chair-of
Represents
an incorporated entity.

employee

employer
0..1
Company
{Person.employer =
Person.boss.employer}
38
Implementation Diagrams


Show aspects of model implementation, including
source code structure and run-time implementation
structure
Kinds
 component
diagram
 deployment diagram
Component Diagram


Shows the organizations and dependencies among
software components
Components may be
specified by classifiers (e.g., implementation classes)
 implemented by artifacts (e.g., binary, executable, or
script files)

Component Diagram Example
Order System component depends both on the Customer
Repository and Inventory System components
Deployment Diagram


Models the physical deployment of artifacts (software
components) on nodes (hardware components)
Deployment diagrams are used to show which
components may run on which nodes
Deployment Diagram Example
Deployment Diagram of Order Management System
(a web based application is deployed in a clustered environment using
server 1, 2, and 3.)
2.2 Use Case Modeling





44
What is use case modeling?
Core elements
Core relationships
Diagram tour
Example: Online HR System
What is use case modeling?

45
use case model: a view of a system that emphasizes
the behavior as it appears to outside users. A use
case model partitions system functionality into
transactions (‘use cases’) that are meaningful to users
(‘actors’).
Use Case Modeling: Core Elements
Construct
Description
use case
A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with
actors of the system.
A coherent set of roles that users
of use cases play when interacting
with these use cases.
actor
Syntax
UseCaseName
ActorName
system
boundary
46
Represents the boundary between
the physical system and the actors
who interact with the physical
system.
Use Case Modeling: Core Relationships
Construct
Description
The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
A relationship from an extension use
extend
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.
Syntax
association
47
<<extend>>
Use Case Modeling: Core Relationships (cont’d)
Construct
Description
include
An relationship from a base use case
to an inclusion use case, specifying
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.
48
Syntax
<<include>>
Use Case Diagram Tour



Shows use cases, actor and their relationships
Use case internals can be specified by text and/or
interaction diagrams
Kinds
 use
case diagram
 use case description
49
Use Case Diagram
College Registration System
50
Example: Online HR System
51
Online HR System: Use Case Relationships
Update Medical
Plan
<<include>>
Update Dental
Plan
<<include>>
Update
Insurance Plan
<<include>>
Update Benefits
Employee
______________
Extension points
benefit options:
after required enrollments
<<extend>>
employee requests
reimbursement option
Elect
Reimbursement
for Healthcare
52
extension point
name and
location
<<extend>>
employee requests
stock purchase option
Elect Stock
Purchase
extension
condition
Online HR System: Update Benefits Use Case

Actors: employee, employee account db, healthcare plan system, insurance
plan system

Preconditions:
o

Employee has logged on to the system and selected ‘update benefits’
option
Basic course
o
System retrieves employee account from employee account db
o
System asks employee to select medical plan type; include Update
Medical Plan

o
System asks employee to select dental plan type; include Update Dental
o
Plan
…
Alternative courses
o
53
If health plan is not available in the employee’s area the employee is
informed and asked to select another plan...
Ideas to Take Away





54
UML is effective for modeling large, complex software
systems
It is simple to learn for most developers, but provides
advanced features for expert analysts, designers and
architects
It can specify systems in an implementation-independent
manner
Structural modeling specifies a skeleton that can be refined
and extended with additional structure and behavior
Use case modeling specifies the functional requirements of
system in an object-oriented manner
3. UML Modeling Tools
Violet UML Editor Tool