Outline of UML and Unified Process

1
Outline of UML and Unified Process
Koichiro OCHIMIZU School of Information
Science JAIST
2
Object Oriented Analysis/Design/Programming
Iterative and Incremental
OOA OOD/OOP
Definition of the problem
Construction of the solution
Program
Model
Domain
3
Modeling the Domain
4
UML

• Very popular now and help us make and analyze
• Use-case Diagrams for defining functional
  requirements
• Collaboration Diagrams for finding analysis
  classes
• Class Diagrams for designing the static structure
• Sequence Diagrams for defining objects
  interaction
• State Diagrams for defining the behavior of each
  object
• Deployment Diagrams for allocating objects to
  machines
• Component Diagrams for packaging

5
Relationship between Methods and UML
Method 1
Method 2
Method 3
Description
UML
6
The Views in UML
Logical View
Component View
Use-Case View
Concurrency View
Deployment View
H.E. Eriksson and M. Penker, UML Toolkit John
Wiley Sons, Inc.
7
Relationships between views and diagrams in UML

• Use-Case View
• Use-Case Diagram, (Activity Diagram)
• Logical View
• Class Diagram, Object Diagram
• State Diagram, Sequence Diagram, Collaboration
  Diagram, Activity Diagram
• Concurrency View
• State Diagram, Sequence Diagram, Collaboration
  Diagram, Activity Diagram
• Component Diagram,, Deployment Diagram
• Deployment View
• Deployment Diagram
• Component View
• Component Diagram

8
The Unified SoftwareDevelopment Process

• Use-Case Model
• Use-Case Diagram
• Analysis Model
• describe Realization of a Use-Case by a
  Collaboration Diagram and a Flow of Event
  Description
• Design Model
• Class Diagram , Sequence Diagram, and Statechart
  Diagram
• Deployment Model
• Deployment Diagram
• Implementation Model
• Component Diagram
• Test Model
• Test Case

9
A Use-Case diagram withan actor and three use
cases
Use Case
Actor
Withdraw Money
Use Case
Deposit Money
Bank Customer
Use Case
Transfer between Accounts
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
10
UML Notations
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
11
Stereotypes
Stereotype/keyword Applies to symbol Meaning
Actor
Specifies a coherent set of roles that users of
use cases play when interacting these use cases
class
Specifies that the target is an historical
ancestor of the source
trace
dependency
Specifies a grouping of elements of which some
constitute a specification of the behavior
offered by the other contained elements
package
subsystem
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
12
The Withdraw Money Use Case Description

• The Bank Customer identifies himself or herself
• The Bank Customer chooses from which account to
  withdraw money and specifies how much to withdraw
• The system decreases the amount from the account
  and dispenses the money.

Use case are also used as placeholders for
nonfuctional requirements
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
13
Use Case Description Event Sequences between
actors and the system
Functional Requirements
Use Case
System
Actor
14
The Realization of a Use Case in the Analysis
Model
Use-Case Model
Analysis Model
Use Case
Collaboration
Withdraw Money
Withdraw Money
Dispenser
Withdrawal
Account
Cashier Interface
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
15
UML notation
Collaboration
collaboration name
A collaboration gives a name to the mechanism of
the system It also serve as the realization of
a use case It defines a group of objects and
their interaction
A directed dashed line means dependency In this
case, trace dependency
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
16
Analysis of inside of the system
Use Case Description Event Sequences between
actors and the system
Collaboration
Use Case
Collaboration
Actor
Collaboration
17
Analysis Stereotypes
In the analysis model, three different
stereotypes on classes are used ltltboundarygtgt,
ltltcontrolgtgt, ltltentitygtgt.
Boundary
Dispenser
Cashier Interface
Control
Withdrawal
Entity
Account
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
18
Analysis Stereotypes

• ltltboundarygtgt classes in general are used to
  model interaction between the system and its
  actors.
• ltltentitygtgt classes in general are used to model
  information that is long-lived and often
  persistent.
• ltltcontrolgtgt classes are generally used to
  represent coordination, sequencing, transactions,
  and control of other objects. And it is often
  used to encapsulate control related to a specific
  use case.

I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
19
A collaboration diagram for the Withdraw Money
use-case realization in the analysis model
1 identify
2 request withdrawal
Cashier Interface
3 validate and withdraw
Withdrawal
Bank Customer
Account
4 authorize dispense
5 dispense money
Dispenser
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
20
UML notation
1 identify
Message
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
21
Flow of Events Description of a Use-Case
Realization
A Bank Customer chooses to withdraw money and
activates the Cashier Interface object. The Bank
Customer identifies himself or herself and
specifies how much to withdraw and from which
account (1). The Cashier Interface verifies the
Bank Customers identity and asks a Withdrawal
object to perform the transaction (2). If the
Bank Customers identity is valid, the Withdrawal
object is asked to confirm that the bank customer
has the right to withdraw the specified amount
from the Account. The Withdrawal object confirms
this by asking the Account object to validate the
request and, if the request Is valid, withdraw
the amount (3). Then the Withdrawal object
authorizes the Dispenser to dispense the amount
that the Bank Customer requested (4). The Bank
Customer then receives the requested amount of
money (5) .
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
22
Analysis Classes
Use Case Description Event Sequences between
actors and the System
Collaboration
Use case
Event Flow Description
Collaboration
Collaboration Diagram
Actor
Collaboration
23
A Class Participating in Several Use-Case
Realizations in Analysis Model
Analysis Model
Use-Case Model
Dispenser
Withdrawal
Withdraw Money
Transfer between Accounts
Cashier Interface
Account
Transfer
Bank Customer
Bank Customer
Money receptor
Deposit
Deposit Money
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
24
Analysis Class

• Focus on functional requirements in defining
  analysis class. Deal with non functional
  requirements in design phase or implementation
  phase.
• Make the class responsibility clear
• Define attributes that exist in a real world
• Define association but do not Include details
  like navigation
• Use stereotype classes ltltboundarygtgt,
  ltltcontrolgtgt, and ltltentitygtgt.

25
Analysis Class and Design ClassAdd solution
domain classes to problem domain classes
Analysis classes
Cashier Interface
Dispenser
Withdrawal
Account
ltlttracegtgt
ltlttracegtgt
ltlttracegtgt
ltlttracegtgt
withdrawal
Account
Dispenser Sensor
Display
Client Manager
Persistent Class
Key Pad
Dispenser Feeder
Card Reader
Transaction Manager
Account Manager
Cash Counter
Design Classes
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
26
UML notation
Active Class
Client Manager
Has a thread and can initiate a control activity
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
27
Class Diagramfor use case withdraw money
Card Reader
Transaction Manager
Display
Client Manager
Persistent Class
Bank Customer
Key Pad
withdrawal
Account
Dispenser Feeder
Cash Counter
Account Manager
Dispenser Sensor
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
28
Class Diagram (Analysis Class Design Class)
Use Case
Actor
29
Sequence Diagramfor use case withdraw money
Card Reader
Cash Counter
Display
Key Pad
Client Manager
Transaction Manager
Bank Customer
Insert card
Card inserted (ID)
Ask for PIN code
Show request
PIN code (PIN)
Specify PIN code
Request PIN validation (PIN)
Ask for amount to withdraw
Show request
Specify amount
Amount (A)
Request cash availability
Request amount withdrawal (A)
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
30
Final Step of Modeling (Definition of Static
Structure and Dynamic Behavior)
Use case
Actor
31
Group Classes into Subsystems
ltltsubsystemgtgt Transaction Management
ltltsub systemgtgt Account Management
ltltsubsystemgtgt ATM interface
Withdrawal
Card Reader
Transaction Manager
Persistent Class
Display
Client Manager
ltltservice subsystemgtgt Withdrawal Management
Bank Customer
Account Manager
Key Pad
Dispensing
Cash Counter
Transfers
Dispenser Feeder
Account
Withdrawal
Dispenser Sensor
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
32
Components that implements Design Classes
Client Manager
ltlttracegtgt
ltltcompilationgtgt
Dispenser Feeder
Dispenser Sensor
ltlttracegtgt
Cash Counter
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.
33
Test Cases are derived from Use Case
Use Case Model
Test Model
ltlttracegtgt
Withdraw Money Basic Flow -
Withdraw money
I. Jacobson, G.Booch, J.Rumbaugh,The Unified
Software Development Process, Addison Wesley,
1999.