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

Tham khảo tài liệu ''bài giảng phân tích thiết kế hướng đối tượng (phần 4)'', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Contracts and

UML interaction diagrams

Lecture 4

System Sequence Diagram

Operation:

enterItem(…) Post-conditions:

-

Operation Contracts

Sale date

.

Sales LineItem quantity

1 *

Domain Model

Use-Case Model

Design Model

: Register enterItem

Require-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

scenario of a use case, the events that

external actors generate, their order, and

INTER-system events (not detailed

method calls between objects)

explaining why

System sequence diagram

enterItem(itemID, quantity)

:System : Cashier

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

total with taxes

change due, receipt

makeNewSale [ more items ]

loop

Use Cases and SSDs

: 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

6 Cashier tells Customer the total, and

asks for payment.

7 Customer pays and System handles

total with taxes

change due, receipt

makeNewSale [ more items ]

loop

Process Sale Scenario

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

enterItem(itemID, quantity)

scan(itemID, quantity) : Cashier

worse name

better name

:System

Iterative and Evolutionary SSDs

(remember agile style)

– Visualization of the interactions implied in the

use cases scenarios

Operation Contract

Operation:

enterItem(…) Post-conditions:

- Operation Contracts

Sale date

.

Sales LineItem quantity

1 *

Domain Model

Use-Case Model

Design Model

: Register enterItem

Require-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

 Contract CO2: enterItem

– 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).

Contract definition

schema

system or objects in the Domain Model before execution of the operation These are non-

trivial assumptions the reader should be told

objects in the Domain Model after completion

of the operation Discussed in detail in a

following section

Contract procedure

– 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

broken

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

Process Sale: makeNewSale

 Contract CO1: 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

Object design introduction

– Modeling with others

– Creating several models in parallel

– Using an internal wiki (www.twiki.org )

– 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

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

Use-Case Realization

realized within the design model, in terms

of collaborating objects” [RUP]

Use case -> System events -> System sequence diagram ->

System operation contracts -> Interaction diagrams -> Design classes

System operation

: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 LAYER

UI 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

: ProductCatalog desc = getProductDesc( itemID )

Design makeNewSale

– A façade controller is satisfactory if there are

only a few system operations

– Use Register here.

– Register create Sale

– Sale create a collection to store

SalesLineItems

Design makeNewSale

:Register

makeNewSale

:Sale create

Register creates a Sale by Creator

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

 Contract CO2: enterItem

– 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).

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

Design enterItem

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>

Partial Design Class Diagram

SalesLineItem quantity : Integer

ProductCatalog

getProductDesc( )

ProductDescription description : Text price : Money itemID: ItemID

1

1

1 catalog

currentSale

descriptions {Map}

lineItems {ordered}

description

Design endSale

:Sale tot = getTotal 1 *[ i = 1 n]: st = getSubtotal

:ProductDescription

1.1: pr = getPrice

lineItems[ i ] : SalesLineItem

«method»

public void getTotal()

{

int tot = 0;

for each SalesLineItem, sli

tot = tot + sli.getSubtotal();

return tot

}

Design makePayment

 Contract CO4: makePayment

– A Payment instance p was created (instance creation).

– p.amountTendered became amount (attribute modification).

– p was associated with the current Sale (association formed).

– The current Sale was associated with the Store (association formed); (to add it to the historical log of completed sales).

Design makePayment

1: makePayment(cashTendered)

1.1: create(cashTendered) :Register :Sale

:Payment makePayment(cashTendered)

by Controller by Creator and Low Coupling

addSale(s : Sale)

Store is responsible for knowing and adding completed Sales.

Acceptable in early development cycles if the Store has few

responsibilities.

SalesLedger is responsible for knowing and adding completed Sales.

Suitable when the design grows and the Store becomes uncohesive.

Sale

Sale

Logs-completed Logs-completed

Design makePayment

1: makePayment(cashTendered)

1.1: create(cashTendered) :Register s :Sale

:Payment makePayment(cashTendered)

:Store 2: addSale(s)

Design makePayment

– Who is responsible for knowing the balance?

 To calculate, sale total and payment tendered are required

– Sale already has visibility into Payment

– Payment does not have visibility into Sale

– Giving Sale primary responsibility doesn’t

increase overall coupling

getBalance design

bal = getBalance

2: t = getTotal { bal = pmt.amount - s.total }

Object Design: startUp

 Initial system operation

 Delay until all other system operations have been

considered

– What objects need to be there through out the use case

– What associations need to be there through out the use case

 Create a set of domain objects that need to be there to

support the use case execution

 Find a suitable initial object and request that object to

create a set of other objects

Create Initial Domain Object

public class Main {

public static void main( String[] args ) {

// Store is the initial domain object

// The Store creates some other domain objects

Store store = new Store();

Register register = store.getRegister();

ProcessSaleJFrame frame =

new ProcessSaleJFrame( register );

}

}

Designing Store.create()

 Create: Store, Register,

ProductCatalog,ProductSpecifications

 Associate: ProductCatalog with

ProductSpecifications; Store with

ProductCatalog; Store with Register;

Register with ProductCatalog

1.2.1*: create(id, price, description)

pd:

ProductDescription the * in sequence number indicates the

message occurs in a repeating section

pass a reference to the ProductCatalog to the Register, so that it has permanent visibility to it

by Creator create an empty

collection object