OO Methodology Elaboration Iteration 3 – Part 2 Refining Models

OO Methodology

Elaboration Iteration 3 – Part 2

Refining Models

2

Table of Contents

• Iteration 1– Use-Case Model

– Process Sale Use Case

– Domain Model

– Design Model

• Iteration 2 – GRASP: More Patterns for Assigning Responsibilities

– Designing Use-Case Realizations with GoF Design Patterns

• Iteration 3– Related Use Cases

– Modeling Generalization

– Refining the Domain Model

– Modeling Behavior in Statechart Diagrams

– Activity Diagrams

– Designing the Logical Architecture with Patterns

– Designing More Use-Case Realization with Paterns

– Designing a Persistence Framework with Patterns

3

Using Packages to Organize the Domain Model

• Package– a general-purpose mechanism for organizing elements into

groups

– a package is a group of model elements and diagrams

• package and name space– every model element that is not part of another model

element must be declared within exactly one namespace

– the namespace containing the declaration of an element is said to be own the element

– a package is general-purpose namespace that can own any kind of model element

SalesCore Elements

Sale

Core Elements::Register

Captures

Store RegisterHas1..*1

1

1

Domain

Core Elements Sales

4

Using Packages to Organize the Domain Model

• Package Dependencies– there exists at least one usage dependency between elements

of the two packages (Usage Dependency)

• Visibility– private: are not available at all outside the containing package

– public: available to importing packages and to descendants of the package

– protected : available to specialized package of the containing package

– nested package has access to any elements directly contained in outer packages

– outer package must import the contained packages

Domain

Core Elements Sales

5

Packages in NextGen POS

• Packages in Domain Model

• Core/Misc Package

Core/Misc

Register Manager

Store

addressname

Houses

1..*

Employs

1..*1

1

Domain

Core/Misc Payments Products Sales

AuthorizationTransactions

6


• Payments Package

Payments

Check

AccountsReceivable

CreditPayment

CheckPayment

CheckAuthorization

Service

CreditAuthorization

Service

Authorized-by

Authorized-by

***

AuthorizationService

addressnamephoneNumber

Core::StorePayment

amount

Establishes-credit-for

Logs

*

CreditCard

expiryDatenumber

DriversLicense

number

1..*

Establishes-identity-for

Paid-by

CashPayment

amountTendered *

Sales::CustomerAbused-by

Identifies

Authorization Transactions::PaymentAuthorizationReply

- CheckPayments have CheckPaymentReplies

- CreditPayments have CreditPaymentReplies

1

1

1

111

1

1 1

1

1

Authorizes-payments-of

merchantID

ServiceContract

1

7


• Products

• Sales

Products

1..*

Core::Store

Stocks

*

Describes

*

Sales::SalesLineItem

Described-by *

Records-sale-of

0..1

ProductSpecification

descriptionpriceitemID

ProductCatalog

Item1

1

1

1

1

Sales

Cashier

Customer

1..*

SalesLineItem

/quantity

Sale

dateisCompletetime

Initiates

Core::Register

Records-sales-on

Captured-on

Core::Store

Logs-completed

*1

1

1

1

1

1

1

1

TaxLineItem

descriptionpercentageamount

1..* 1

8

• Authorization Services


Authorization Transactions

CreditPaymentApprovalRequest

CheckPaymentApprovalRequest

PaymentAuthorizationRequest

CreditPaymentApproval

Reply

CheckPaymentApproval

Reply

CreditPaymentDenialReply

CheckPaymentDenialReply

Payments::Authorization

ServiceSends Receives

Payments::CreditPayment

Payments::CheckPayment

PaymentAuthorizationTransaction

datetime

Core::Store

PaymentAuthorization

Reply

Receives

*

Sends

*

* *

1

11

1

1

1

1

1

1

1

1 1

1

1 1

1

9

Modeling Behavior in Statechart Diagram

• Modeling Dynamic Behavior– Sequencing Diagram

– Collaboration Diagram

– Statechart Diagram

– Activity Diagram

• Statechart Diagram– describe which states an object can have during its life cycle,

and the behavior in those states, along with what events cause the state to change

• Events, States, and Transitions– an event is a significant or noteworthy occurrence

• e.g. a telephone receiver is taken off the hook

– a state is the condition of an object at a moment in a time• e.g. a telephone is in the state of being “idle”

– a transition is a relationship between two states tht indicates that when an event occurs

• e.g. off hootransition from the idle to active state

off hookIdle Active

on hook

Telephone

state

transition event

initial state

10


• Subject of a Statechart Diagram– classes

– use cases

– etc.

• Use Case Statechart Diagrams– to describe the legal sequence of external system events

handled by a system in the context of the use case

WatingForSale EnteringItems

enterItem

WaitingForPayment

makeNewSale

makeCashPayment

endSale

AuthorizingPayment makeCheckPayment

makeCreditPayment

authorized

Process Sale

11


• Statechart Diagrams for Classes– useful for state-dependent objects with complex behavior

– cf. state-independent objects

– process control and telecommunication domains often have more state-dependent objects than business information systems

• Examples of State-Dependent Classes– use cases (viewed as types)

– systems

– stateful session

– windows

– controllers

– transactions

– devices

– role mutators

– etc.

12


• Additional Notations in Statechart– transition action and guard condition

– state variable and activities within state

Onfirst floor

do/moving to floor

Moving up

Idle

timer=0

do/increasetimer

MovingDown

do/movingto floor

[timer = time-out]/go down(first floor)

go up(floor)

arrived

go down(floor)

arrived

13


• Nested States– a state allows nesting to contain substates

– a substate inherits the transitions of its superstate

Idle

off hook / play dial tone

on hook

Active[valid subscriber]

PlayingDialTone

Dialing Connecting

digitdigit

complete

Talking

connected

14


• Example

Timeout

do/play message

DialTone

do/play dialtone

Invalid

do/play message

Dialing

Connecting

Busy

do/play busytone

Ringing

do/play busytoneTalking

Idle

dial digit(n)[incomplete]after(15sec)after(15sec)

dial digit(n)

dial digit(n)[valid]/connect

dial digit(n)[invalid]

connectedbusy

callee answers

caller hang ups/disconnect

lift receiver

Active

15


• Implementation– Conditional Logic (e.g. Case Statement)

– State Pattern

• Example : Digital Watch

Display Set Hours Set Minutes

mode_button

mode_button

inc/h = h + 1

do/display current time

do/display hours

do/display minutes

inc/m = m + 1

mode_button

Watch

h, m, state

mode_button()

inc()

void mode_button(){ switch (state ) { case DISPLAY: ... case HOURS : ... case MIN : ... }}

16


• Example : Digital Watch

– Using State Pattern

Watch

h, m

mode_button()

inc()

State

mode_button()

inc()

Display

mode_button() Sethours

mode_button()

inc()

Sethours

mode_button()

inc()

17

Activity Diagrams

• Activity diagram – is a state machine in which all or most of the states are

activity state or action states

– shows a procedure or workflow

– shows sequential and concurrent activities

• Activity diagrams may be used in various purpose– to capture the work to be performed in the implementation of

an operation

– to show how a set of related actions may be performed and how they will affect objects around them

– to show how an instance of a use-case may be performed

– to show how a business works in terms of workers, workflows, organization, and objects

• Elements– Actions

– Transitions (guard-condition, send-clause, action)

– Swimlanes

– Objects

– Signals

18

Activity Diagrams

• Example

Set up order

Assignseats

Chargecreditcard

Awardmemberbonus

Assignseats

Debitaccount

merge

fork

join

branch

[subscription]

[member]

[single order]

19

Activity Diagrams

• Swimlanes– groups activities with respect to who is responsible for them

or where they reside in an organization

RequestOrder

TakeOrder

FillOrder

Pay

DeliverOrder

CollectOrder

Order[placed]

Order[delivered]

Order[entered]

Order[entered]

Customer Sales Stockroom

object and its state

20

Activity Diagrams

• Signals and Deferred Events– signal is a way of asynchronous communication between two

objects

– deferred event is an event whose occurrence must be deferred for later use while some other activities is underway

Turn onMachine

Get Cupslight goes out/defer

PourCoffee

turn on

light goes out

deferred event

Documents

OO Methodology Elaboration Iteration 3 – Part 2 Refining Models