Koichiro Ochimizu, JAIST

Schedule
• Feb. 27th
– 13:00 Scope and Goal
– 14:30 Basic Concepts on Representing the World
Outline of (object, class, association, …)
• Feb. 28th
UML and Unified Process – 13:00 Basic Concepts on Interaction
(message passing, operation, method,
polymorphism)
– 14:30 Basic Concepts on Reuse
Koichiro OCHIMIZU (super class, class inheritance, interface
inheritance)
School of Information Science • March 1st
– 13:00 Introduction to Java Programming
JAIST – 14:30 Outline of UML and Unified Process

Modeling the Domain

Abstraction of entities in the
Object Oriented
domain from the viewpoint Description of
of satisfy-one’s-hunger

h1 a1
possibility

state-of-
hunger
Analysis/Design/Programming
eat()
public class hungry-
hungry apple person {
person
state of volume int state-of-hunger
hunger
satisfy
eaten
void eat ()
state-of-
hunger
Iterative and Incremental
eat hunger
a2 } eat()
h2
public class apple {
：hungry person ：apple int volume
volume
OOA OOD/OOP
void eaten ()
eaten()
}
The world view：We can
represent the domain
volume
Domain Model Program
simply by “A set of objects
and their interaction) eaten() Definition of Construction of
Definition of static structure
and dynamic behavior
Program the problem the solution
Reproduction of the
Domain in the main
memory

Relationship UML1.5
between
Methods and UML • Very popular now and help us make and analyze:
– Use-case Diagrams for defining functional requirements
– Collaboration Diagrams for finding analysis classes
Method 1 Method 2 Method 3 – Class Diagrams for designing the static structure
– Sequence Diagrams for defining objects interaction
– State Diagrams for defining the behavior of each object
Description
– Deployment Diagrams for allocating objects to machines
– Component Diagrams for packaging
UML

UML&UP outline 1
Koichiro Ochimizu, JAIST

Relationships between
The Views in UML views and diagrams in UML
• Use-Case View
– Use-Case Diagram
• Logical View
Component Logical – Class Diagram, Object Diagram
View View – State Diagram, Sequence Diagram, Collaboration Diagram,
Activity Diagram
Use-Case • Concurrency View
View – State Diagram, Sequence Diagram, Collaboration Diagram,
Activity Diagram
Deployment Concurrency
– Component Diagram,, Deployment Diagram
View View
• Deployment View
– Deployment Diagram
• Component View
H.E. Eriksson and M. Penker, “UML Toolkit” John Wiley & Sons, Inc.
– Component Diagram

Use Case Description

The Unified Software Event Sequences between actors Functional Requirements
and the system
Development Process
• Use-Case Model
– Use-Case Diagram
• Analysis Model
– describe “Realization ｏｆ a Use-Case” by a Collaboration Use Case
Diagram and a Flow of Event Description
• Design Model
System
– Class Diagram , Sequence Diagram, and Statechart Diagram
• Deployment Model Actor
– Deployment Diagram
• Implementation Model
– Component Diagram
• Test Model
– Test Case

Use Case Description Analysis of inside of the system Use Case Description Analysis Classes
Event Sequences between actors and Event Sequences between actors and the System
the system

Collaboration Collaboration

Use Case Use case

Event Flow
Description
Collaboration
Collaboration
Collaboration
Diagram
Actor Actor
Collaboration
Collaboration

UML&UP outline 2
Koichiro Ochimizu, JAIST

Class Diagram (Analysis Class + Design Class) Final Step of Modeling (Definition of Static Structure
and Dynamic Behavior)

Use Case Use case

Actor Actor

A Use-Case diagram with UML Notations

an actor and three use cases Actor: icon for Stereotype Actor Use Case

Use Case
Actor
Withdraw Money Bank Customer Withdraw Money

Use Case Stereotypes

Deposit Money Stereotype/keyword Applies to symbol Meaning
Bank
Customer Use Case Actor
Specifies a coherent set of roles
class that users of use cases play
Transfer between Accounts when interacting these use
cases
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, G.Booch, J.Rumbaugh, I. Jacobson , ”The Unified Modeling Language User
Addison Wesley, 1999. Guide”, Addison Wesley, 1999.

The Realization of a Use Case in

The Withdraw Money
the Analysis Model
Use Case Description Use-
Use-Case Model Analysis Model
<<trace>>
Use Case Collaboration
1. The Bank Customer identifies himself or herself
2. The Bank Customer chooses from which account to Withdraw Money Withdraw Money
withdraw money and specifies how much to withdraw
3. The system decreases the amount from the account and
dispenses the money.

Use case are also used as “placeholders” for nonfuctional requirements Dispenser Cashier Withdrawal Account
Interface
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
Addison Wesley, 1999. Addison Wesley, 1999.

UML&UP outline 3
Koichiro Ochimizu, JAIST

UML notation Analysis Stereotypes

In the analysis model, three different stereotypes on
collaboration name Collaboration classes are used: <<boundary>>, <<control>>, <<entity>>.
Boundary
A collaboration gives a name to the mechanism Dispenser Cashier Interface
of the system
It also serve as the realization of a use case
Control
It defines a group of objects and their
interaction Withdrawal

A directed dashed line means dependency Entity

<<trace>> In this case, trace dependency Account

G.Booch, J.Rumbaugh, I. Jacobson , ”The Unified Modeling Language User I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
Guide”, Addison Wesley, 1999. Addison Wesley, 1999.

A collaboration diagram for the

Analysis Stereotypes
Withdraw Money use-case realization in
• <<boundary>> classes in general are used to the analysis model
model interaction between the system and its
actors.
1: identify 2: request withdrawal
• <<entity>> classes in general are used to model : Cashier
information that is long-lived and often persistent. Interface 3: validate and withdraw
• <<control>> classes are generally used to
: Bank : Withdrawal
: Account
represent coordination, sequencing, transactions,
Customer
and control of other objects. And it is often used 4: authorize dispense
to encapsulate control related to a specific use 5: dispense money
:Dispenser
case. I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, Addison Wesley, 1999.
Addison Wesley, 1999.

Flow of Events Description

UML notation 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
１： identify how much to withdraw and from which (1).
Message
The Cashier Interface verifies the Bank Customer’s identity and asks a
Withdrawal object to perform the transaction (2).
If the Bank Customer’s 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) .
G.Booch, J.Rumbaugh, I. Jacobson , ”The Unified Modeling Language User
Guide”, Addison Wesley, 1999. I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
Addison Wesley, 1999.

UML&UP outline 4
Koichiro Ochimizu, JAIST

A Class Participating in Several Use- Analysis Class

Case Realizations in Analysis Model
Use-
Use-Case Model Analysis Model • Focus on functional requirements in defining analysis class.
Deal with non functional requirements in design phase or
implementation phase.
Dispenser Withdrawal
• Make the class responsibility clear
Withdraw Money
• Define attributes that exist in a real world
• Define association but do not Include details like
Transfer between
Accounts Cashier Transfer Account navigation
Bank Bank
Customer Interface • Use stereotype classes; <<boundary>>, <<control>>, and
Customer
<<entity>>.
Deposit Money
Money Deposit
receptor
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
Addison Wesley, 1999.

Analysis Class and Design Class

Add solution domain classes to problem domain classes
Analysis classes
UML notation

Cashier Interface Dispenser Withdrawal Account Client

Manager
Active Class
<<trace>> <<trace>>
<<trace>> <<trace>>
withdrawal
Dispenser Account
Display
Sensor
Client Persistent Has a thread and can initiate a control activity
Key Pad Dispenser Manager Class
Feeder

Card Transaction Account

Cash
Reader Manager Manager
Counter
G.Booch, J.Rumbaugh, I. Jacobson , ”The Unified Modeling Language User
Design Classes Guide”, Addison Wesley, 1999.
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
Addison Wesley, 1999.

Class Diagram Sequence Diagram

for use case “withdraw money” for use case “withdraw money”
：Card ：Client ：Cash ：Transaction
Reader ：Display ：Key Pad
：Bank Manager Counter Manager
Card
Transaction Customer
Reader Insert card
Manager Card inserted (ID)

Ask for PIN code

Display Client Show request
Persistent
Manager
Bank Class Specify PIN code PIN code (PIN)
Customer Request PIN validation (PIN)
Key Pad withdrawal Ask for amount to withdraw
Show request
Account
Specify amount
Dispenser Cash Amount (A)
Request cash availability
Feeder Counter
Account Request amount withdrawal (A)
Dispenser Manager
Sensor
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, Addison Wesley, 1999.
Addison Wesley, 1999.

UML&UP outline 5
Koichiro Ochimizu, JAIST

Group Classes into Subsystems Components that implements

<<subsystem>> <<subsystem>> <<sub
Design Classes
Transaction system>>
ATM Account
interface Management Management
<<executable>>
Client
Card Withdrawal
Transaction Manager client.exe
Reader <<trace>>
Manager Persistent
Client
Display Class
Manager Dispenser <<compilation>>
<<service <<file>>
Bank Feeder
Dispensing Account
Customer Key Pad subsystem>>
Withdrawal Manager client.c
Cash Management
Transfers Dispenser
Counter <<trace>>
Dispenser Sensor
Feeder Withdrawal
Account <<file>>
Dispenser Cash dispenser.c
Sensor Counter
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”,
Addison Wesley, 1999. Addison Wesley, 1999.

What do Software Engineering Projects

Test Cases are derived from Use Case consider important? by Pete McBreen
• Traditional Waterfall Projects
– Specialization of staff into different roles to support the different phases is
claimed to promote efficiency by reducing the number of skills a person needs.
Use Case Model Test Model – With clear milestones between phases and known dependencies between
deliverables, it is easy to display a waterfall project on a PERT chart.
– Comprehensive documentation is important, so that at the end of the project it is
possible to justify the overall costs. This supports the tracking of the project
<<trace>> because it makes everything available for external review. A side benefit of all of
this documentation is traceability.
• Unified Process ( supports Incremental development in the context of a
phased approach)
– Inception( evaluating the economic feasibility of the project, forcing the team to
Withdraw money Withdraw Money define the overall project scope, plan the remaining phases, and produce
– Basic Flow - estimates)
– Elaboration (evaluating the technical feasibility of the project by creating and
validating the overall software architecture)
– Construction ( at the end of each increment, new and changed requirements can
be incorporated into the plans, and the estimates can be refined based on
I. Jacobson, G.Booch, J.Rumbaugh,”The Unified Software Development Process”, experiences in the previous increments)
Addison Wesley, 1999.

Pete McBreen, “Questining eXtreme Programming”, Addison-Wesley, 2003.

What do Software Engineering Projects

consider important? by Pete McBreen Exercise
• Open Source Project
– Free, unrestricted access to the source code so that developers can share • Review the content of my lecture by answering the following
and learn simple questions. Please describe the definition of each technical
– The reputation of the project’s developers term.
– Frequent releases back to the community 1. Please describe the relationship between UML and methods.
2. Why do we define the use case model?
• Agile
3. What is a use case description ?
– Individuals and interactions over processes and tools 4. What is an collaboration of UML?
– Working software over comprehensive documentation 5. What are analysis ( or problem domain ) classes?
– Customer collaboration over contract negotiation 6. What are design classes?
– Responding to change over following a plan 7. How can we define the interaction among objects using UML
• XP notations?
8. How can we define the behavior (or lifecycle) of an object using
– A predictable, sustained, and sustainable pace in the face of changing UML notations?
requirements 9. What is a stereotype of UML?
– A collaborative, supportive environment for developers
– Enhancement of the skills and knowledge of the development team
Pete McBreen, “Questining eXtreme Programming”, Addison-Wesley, 2003.

UML&UP outline 6