Systems grenser mot omverdenen
Forelesning IN 265 18.3-2003
Are Use Cases necessarily the best start of
an OO System Development Process?
Basert på artikkel og lysark
av
Gerhard Skagestein,
Universitetet i Oslo
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
1
The Unified Modeling Language - UML
A set of 8 diagram techniques, established by
groups setting the tone within the OO
community
UseCase
view
Logical
view
Compo- Concur- Deploynent
rency
ment
view
view
view
Use-Case diagram
Class/object diagram
Sequence diagram
Collaboration diagram
State diagram
Activity diagram
Component diagram
Deployment diagram
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
2
Recommended sequence by most methods
Start here
UseCase
view
Logical
view
Compo- Concur- Deploynent
rency
ment
view
view
view
Use-Case diagram
Class/object diagram
Sequence diagram
Collaboration diagram
State diagram
Activity diagram
Component diagram
Deployment diagram
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
3
A Use Case for an
Automatic Teller Machine (see IN 102, ch. 9)
Automatic
Teller Machine
Withdraw
cash
Customer
•
•
•
•
•
Insert card
Give PIN
Select amount
Remove card
Take money
Show recent
transactions
Show currency
exchange rates
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
4
Whats nice with Use Cases
 Describe the expected functionality of the
system on an appropriate abstraction level
 Nice form of requirement specifications
 Excellent basis for test-programs
 Understandable by the users
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
5
What is bad with Use Cases
 Use Cases are build on assumptions about the
boundary of the system to be used
 Responsibilities of users and system are more or
less taken for granted
 Does not assist in getting new ideas on how to
organise things better – on the contrary, they prevent
you from getting such ideas
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
6
An alternative approach –
illustrated by a small example
The object-oriented loan
loan
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
7
The object-oriented loan
A loan-object may
» Know its own balance, interest rate, installment
dates etc.
» Calculate its own interests
» Ask for instalments
» Accept instalments
Hello, you should pay the instalment
loan
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
8
The Person and the Loan –
a simple collaboration diagram
:Person
:Loan
askforInstalment
Person
IN 265 Problemformulering, ..
classes
Loan
Forelesning 18.3.2003 Arild Jansen Ifi
9
Allocation of responsibilities
:Person
:Loan
askforInstalment
Person
classes
askHimforPayment(amount,date)
remindHim(amount,date)
acceptHisPayment(amount)
IN 265 Problemformulering, ..
Loan
calculateInterest( )
calculateBalance( )
calculateInstalment( )
askforPayment(amount,date)
acceptPayment(amount)
Forelesning 18.3.2003 Arild Jansen Ifi
10
The communication between
the real and the computerized part
the Protocol
Person
askHimforPayment(amount,date)
remindHim(amount,date)
acceptHisPayment(amount)
Example: remindHim(amount, date)
 Send him a typed letter
4 different
 Send him an e-mail
Use Cases!
 Ask a clerk to call him
 Send a SMS-message to his Mobile Phone
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
11
The harmful boundary
:object1
:object4
:object3
:object2
:object5
:object6
:object8
:object7
:object9
:objectn
Computerized system
system
Computerized
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
12
The better boundary
:object1
A user interface,
may be described
by Use Cases
:object4
:object3
:object2
:object5
:object6
:object8
:object7
:object9
:objectn
Computerized system
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
13
My message – first part
 The boundary between the computerized system and the
environment does neither go through messages between
objects, nor does it coincide with the interfaces of some
objects
On the contrary:
 The boundary runs right through some objects, splitting them
in a real world and a computerized part
 The communication between those two parts is governed by
a protocol, which may be documented by Use Cases
 This protocol may involve communication between objects,
but the on a lower abstraction level
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
14
My message – second part
 A Use Case is a way to document the protocol
between a human being (or another system) and
a computerized system
 It is obviously wrong to lay down this protocol
before we have
» Decided upon the distribution of responsibilities
between the human being and the computerized
system
» Decided upon the means of communication between
the two
 Conclusion: Sequence/collaboration diagrams
first!
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
15
Alternative sequence
Start here
UseCase
view
Logical
view
Compo- Concur- Deploynent
rency
ment
view
view
view
Use-Case diagram
Class/object diagram
Sequence diagram
Collaboration diagram
State diagram
Activity diagram
Component diagram
Deployment diagram
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
16
Is the alternative method
really ”better”?
 Difficult to prove empirically –
good designers make good systems even with bad
methods
But:
 A method should not be obviously counterproductive
in getting new ideas
 The basic models should be invariant with regard to
organizational and technical solutions
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
17
Punchline…
 ”A system is an inter-related set of components, with
an identifiable boundary, working together for some
purpose, and which we choose to regard as a whole”
 In other words: We select our systems to fit the
purpose.
 Before doing so, we should know as much as
possible about the purpose!
IN 265 Problemformulering, ..
Forelesning 18.3.2003 Arild Jansen Ifi
18