Title: Outline of UML and Unified Process
1Outline of UML and Unified Process
Koichiro OCHIMIZU School of Information
Science JAIST
2Object Oriented Analysis/Design/Programming
Iterative and Incremental
OOA OOD/OOP
Definition of the problem
Construction of the solution
Program
Model
Domain
3Modeling the Domain
4UML
- 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
5Relationship between Methods and UML
Method 1
Method 2
Method 3
Description
UML
6The 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.
7Relationships 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
8The 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
9A 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.
10UML Notations
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
11Stereotypes
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.
12The 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.
13Use Case Description Event Sequences between
actors and the system
Functional Requirements
Use Case
System
Actor
14The 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.
15UML 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.
16Analysis of inside of the system
Use Case Description Event Sequences between
actors and the system
Collaboration
Use Case
Collaboration
Actor
Collaboration
17Analysis 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.
18Analysis 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.
19A 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.
20UML notation
1 identify
Message
G.Booch, J.Rumbaugh, I. Jacobson , The Unified
Modeling Language User Guide, Addison Wesley,
1999.
21Flow 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.
22Analysis Classes
Use Case Description Event Sequences between
actors and the System
Collaboration
Use case
Event Flow Description
Collaboration
Collaboration Diagram
Actor
Collaboration
23A 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.
24Analysis 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.
25Analysis 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.
26UML 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.
27Class 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.
28Class Diagram (Analysis Class Design Class)
Use Case
Actor
29Sequence 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.
30Final Step of Modeling (Definition of Static
Structure and Dynamic Behavior)
Use case
Actor
31Group 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.
32Components 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.
33Test 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.