Bài Giảng Phân tích thiết kế hướng đối tượng (phần 4) potx

Contracts and
Contracts and
UML interaction diagrams
UML interaction diagrams
Lecture 4
Lecture 4
Hoa Sen University 1
Agenda
Agenda

System sequence diagram

Operation Contract

On to Object design
–
Interaction diagrams

Sequence diagrams

Communication diagrams
Hoa Sen University 2
System Sequence Diagram
System Sequence Diagram
Hoa Sen University 3
Operation:
enterItem(…)
Post-conditions:
- . . .
Operation Contracts
Sale

date
. . .
Sales
LineItem
quantity
1
*
1
. . .
. . .
Domain Model
Use-Case Model
Design Model
: Register
enterItem
(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Require-
ments
Business
Modeling
Design
Sample UP Artifact Relationships
: System
enterItem
(id, quantity)
Use Case Text

System Sequence Diagrams
make
NewSale()
system
events
Cashier
Process
Sale
: Cashier
use
case
names
system
operations
Use Case Diagram
Vision
Supplementary
Specification
Glossary
parameters and
return value details
starting events to design for
Process Sale
1. Customer
arrives
2. Cashier
makes new
sale.
3.
What is System Sequence Diagram

What is System Sequence Diagram

A diagram that shows, for ONE particular
scenario of a use case, the events that
external actors generate, their order, and
INTER-system events. (not detailed
method calls between objects)

Describe what a system does without
explaining why
Hoa Sen University 4
System sequence diagram
System sequence diagram
Hoa Sen University 5
enterItem(itemID, quantity)
:System
: Cashier
endSale
makePayment(amount)
a UML loop
interaction
frame, with a
boolean guard
expression
external actor to
system
Process Sale Scenario
system as black box
the name could be "NextGenPOS" but "System" keeps it
simple

the ":" and underline imply an instance, and are explained in a
later chapter on sequence diagram notation in the UML
a message with
parameters
it is an abstraction
representing the
system event of
entering the
payment data by
some mechanism
description, total
return value(s)
associated with the
previous message
an abstraction that
ignores presentation
and medium
the return line is
optional if nothing is
returned
total with taxes
change due, receipt
makeNewSale
[ more items ]
loop
Use Cases and SSDs
Use Cases and SSDs
Hoa Sen University 6
: Cashier
:System

Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done.
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and
asks for payment.
7. Customer pays and System handles
payment.

enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]
loop
Process Sale Scenario
Choosing events and operation name
Choosing events and operation name


System events should be expressed at the abstract level
of intention rather than in terms of the physical input
device
Hoa Sen University 7
enterItem(itemID, quantity)
scan(itemID, quantity)
: Cashier
worse name
better name
:System
Iterative and Evolutionary SSDs
Iterative and Evolutionary SSDs

Do not create SSDs for all scenarios
(remember agile style)

SSDs are part of the Use-Case Model
–
Visualization of the interactions implied in the
use cases scenarios
Hoa Sen University 8
Operation Contract
Operation Contract
Hoa Sen University 9
Operation:
enterItem(…)
Post-conditions:
- . . .
Operation Contracts
Sale

date
. . .
Sales
LineItem
quantity
1
*
1
. . .
. . .
Domain Model
Use-Case Model
Design Model
: Register
enterItem
(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Require-
ments
Business
Modeling
Design
Sample UP Artifact Relationships
: System
enterItem
(id, quantity)
Use Case Text

System Sequence Diagrams
make
NewSale()
system
events
Cashier
Process
Sale
: Cashier
use
case
names
system
operations
Use Case Diagram
Vision
Supplementary
Specification
Glossary
starting events to
design for, and
more detailed
requirements that
must be satisfied
by the software
Process Sale
1. Customer
arrives
2.
3. Cashier

enters item
identifier.
the domain
objects,
attributes,
and
associations
that undergo
changes
requirements
that must be
satisfied by
the software
ideas for
the post-
conditions
Example Contract
Example Contract

Contract CO2: enterItem

Operation: enterItem(itemID: ItemID, quantity: integer)

Cross References: Use Cases: Process Sale

Preconditions: There is a sale underway.

Postconditions:
–
A SalesLineItem instance sli was created (instance creation).

–
sli was associated with the current Sale (association formed).
–
sli.quantity became quantity (attribute modification).
–
sli was associated with a ProductDescription, based on itemID match
(association formed).
Hoa Sen University 10
Contract definition
Contract definition

A description of each section in a contract is shown in the following
schema.

Operation: Name of operation, and parameters

Cross References: Use cases this operation can occur within

Preconditions: Noteworthy assumptions about the state of the
system or objects in the Domain Model before
execution of the operation. These are non-
trivial assumptions the reader should be told.

Postconditions: This is the most important section. The state of
objects in the Domain Model after completion
of the operation. Discussed in detail in a
following section.
Hoa Sen University 11
Contract procedure
Contract procedure


To make contract
–
Identify System Operations from SSD
–
For system operations that are complex or
subtle in their results or are not clearly
express in use cases, construct a contract
–
To describe the post conditions, use the
following categories

Instance creation and deletion

Attribute change of value

Associations (to be precise, UML links) formed and
broken
Hoa Sen University 12
System operations
System operations
Hoa Sen University 13
: Cashier
enterItem(itemID, quantity)
endSale()
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale()

these input system events
invoke system operations
the system event enterItem
invokes a system operation
called enterItem and so forth
this is the same as in object-
oriented programming when
we say the message foo
invokes the method (handling
operation) foo
[ more items ]
loop
:System
Process Sale Scenario
Process Sale: makeNewSale
Process Sale: makeNewSale

Contract CO1: makeNewSale

Operation: makeNewSale()

Cross References: Use Cases: Process Sale

Preconditions: none

Postconditions:
–
A Sale instance s was created (instance creation).
–
s was associated with a Register (association formed).

–
Attributes of s were initialized.
Hoa Sen University 14
Object design introduction
Object design introduction

How do developers design objects
–
Code
–
Design-while-coding
–
Draw, then code
–
Only draw

Agile modelling: reduce drawing overhead and model to understand
and communicate
–
Modeling with others
–
Creating several models in parallel
–
Using an internal wiki (www.twiki.org )

How much time spent drawing UML before coding?
–
For a three-week timeboxed iteration, spend a few hours or at most one day
near the start of the iteration drawing UML for the hard, creative parts of the
detailed object design

Hoa Sen University 15
Static vs. dynamic modelling
Static vs. dynamic modelling

Dynamic models help design the logic,
the behavior of the code or the method
bodies
–
Sequence diagram, communication diagram

Static models help design the definition
of packages, class names, attributes, and
method signatures
–
UML class diagram
Hoa Sen University 16
Use-Case Realization
Use-Case Realization

“…describes how a particular use case is
realized within the design model, in terms
of collaborating objects” [RUP]

Individual scenarios are realized
Hoa Sen University 17
Use case -> System events -> System sequence diagram ->
System operation contracts -> Interaction diagrams -> Design classes
System operation
System operation
Hoa Sen University 18

:Register
enterItem
:Register
endSale
:Register
makePayment
1: ???
1: ???
1: ???
:Register
makeNewSale 1: ???
makeNewSale, etc., are the system operations from the SSD
each major interaction diagram starts with a system operation
going into a domain layer controller object, such as Register
DOMAIN LAYERUI LAYER
Window objects
or
GUI widget objects
or
Web control objects
. . .
The system operations in the SSD are used as the start messages into the domain layer
If communication diagrams are used, one per system operation
Same for sequence diagram
One diagram per system operation
One diagram per system operation
Hoa Sen University 19
: Register
: Sale
makeNewSale

create
: Register
enterItem( )
: ProductCatalog
desc = getProductDesc( itemID )
. . .
UI LAYER
Window objects
or
GUI widget objects
or
Web control objects
. . .
DOMAIN LAYER
Design makeNewSale
Design makeNewSale

Choosing the controller class
–
A façade controller is satisfactory if there are
only a few system operations
–
Use Register here.

Creating a new Sale
–
Register create Sale
–
Sale create a collection to store
SalesLineItems

Hoa Sen University 20
Design makeNewSale
Design makeNewSale
Hoa Sen University 21
:Register
makeNewSale
:Sale
create
Register creates a
Sale by Creator
create
lineItems :
List<SalesLineItem>
by Creator, Sale
creates an empty
collection (such as a
List) which will
eventually hold
SalesLineItem
instances
by Creator
and
Controller
this execution specification is implied to be
within the constructor of the Sale instance
Design: enterItem
Design: enterItem

Contract CO2: enterItem


Operation: enterItem(itemID : ItemID, quantity : integer)

Cross References: Use Cases: Process Sale

Preconditions: There is an underway sale.

Postconditions:
–
A SalesLineItem instance sli was created (instance creation).
–
sli was associated with the current Sale (association formed).
–
sli.quantity became quantity (attribute modification).
–
sli was associated with a ProductDescription, based on itemID match
(association formed).
Hoa Sen University 22
Design enterItem
Design enterItem

Choosing controller class

Display item description and price (ignore
at this stage)

Create a new SalesLineItem

Finding a ProductDescription

Visibility to ProductCatalog


Temporary and persistent storage
–
We can defer database design and use
temporary memory object instead
Hoa Sen University 23
Design enterItem
Design enterItem
Hoa Sen University 24
2: makeLineItem(desc, qty)
enterItem(id, qty)
1: desc = getProductDesc(id)
2.1: create(desc, qty)
1.1: desc = get(id)
:Register :Sale
:Product
Catalog
sl: SalesLineItem
lineItems :
List<SalesLineItem>
: Map<ProductDescription>
2.2: add(sl)
by Expert
by Controller
by Creator
add the newly created
SalesLineItem instance to the List
Partial Design Class Diagram
Partial Design Class Diagram
Hoa Sen University 25

SalesLineItem
quantity : Integer

ProductCatalog

getProductDesc( )
ProductDescription
description : Text
price : Money
itemID: ItemID

1
*
1
*
Register

enterItem( )

Sale
isComplete : Boolean
time : DateTime
makeLineItem( )

1
1
1
catalog
currentSale
descriptions

{Map}
lineItems
{ordered}
description