oo design ch05

8/7/2019 Oo Design Ch05

1/35

1

ECE 355: Software Engineering

Bridge Material

Object Oriented Design


2/35

2

Overview What is OO Analysis & Design?

Vending Machine Example

Analysis Use case modeling

Domain modeling

Behavioral modeling

Design

Interaction diagrams

Refined class diagram

Concurrency and scheduling

Summary and Further Reading


3/35

3

OO Analysis & Design Analysis

Domain level - modeling real world objects

Really: part of requirements engineering requirements development = elicitation + analysis +

specification

Many domain objects will not make into the design

Domain structures usually make poor design structures

Design Assigning responsibilities to object

Taking illities (maintainability, reusability, etc.) andportability into account

Devising mechanisms


4/35

4

OO Analysis & Design Many methods (OMT, Booch, Unified

Process, etc.)

Similar goals and techniques


5/35

5

OO Analysis Activities Use case analysis

Mostly focused on writing text - one overview context diagram isoften enough

Use cases are just a part of functional requirements (only theinteractive ones)

Structural analysis domain modeling Finding the real-world objects involved in the use cases and

creating class diagrams to represent them

Behavioral analysis Creating activity diagrams and sequence diagrams to capture use

case details

Activity diagrams for business workflow

Sequence diagrams for reactive behavior (also with timing)

Possibly creating state charts to capture external reactive behaviorof the system and other domain objects


6/35

6

OO Design Activities Creating interaction diagrams and distributing

responsibilities

Devising mechanisms and introducing design objects Creating sequence diagrams

Creating collaboration diagrams

Creating refined class diagrams

Deciding on concurrency and scheduling model Possibly modeling detailed behavior of design

objects using state charts


7/35

7




Domain modeling

Behavioral modeling

Design






8/35


9/35

9

Use Case Diagram As a Context

Diagram

Use Case 1

(Buy a drink)Customer

Vending Machine

Use Case 2

(Restock)

Agent


10/35

10

Different Forms of Use Cases Casual version

User story

A narrative Fully dressed

Formal sections

Preconditions

Main scenario

Exception list

See Writing effective use cases by AlistairCockburn, 2000


11/35

11

Use Case 1 (Casual Version)Consider a simplified vending machine, which is used to dispense soft

drinks. The vending machine consists of a coin slot for inserting coins, a

return tray for returning the customer's money and three buttons used to

select Pepsi (tm), Coke (tm) or Dr. Pepper (tm). If the customer insertscoins and does not press a button within one minute, the coins will be

returned automatically (no coin-return lever). If the customer selects a

beverage which is out-of-stock (none left), the coins will also be returned.

This vending machine does not provide change - it is up to the customer to

insert only enough money to purchase a drink. If sufficient coins are

inserted and a button with available beverages is pressed, the appropriate

drink is dispensed, the corresponding button is illuminated for five

seconds, and the coin slot moves the coins to the general storage area (i.e.

the purchase has finished).


12/35

12

Use Case 1 (Fully Dressed Version)Primary actor: Customer

Goal in context: Customer buys a drink

Level: User level

Stakeholders and Interests:

Customer : wants to buy a drink

Vendor: wants to get paid for any goods dispensed

Preconditions: Machine is ready & awaiting interaction

Minimum guarantee: Customer gets his coins back if no drink dispensed

Success guarantees:

Customer has the drink; vending machine has the money for thedrink; Vending machine provides no change

Trigger: Customer starts interaction with the machine


13/35

13

Use Case 1 (Contd)Main success scenario:

1. Customer inserts sufficient money into the coin slot

2. Customer pushes one of the three select buttons

3. The selected drink is dispensed.4. The pushed select button lights up for 5 seconds.

5. Coins are taken by the machine.

Extensions

1a. Customer inserts no or insufficient money. Pushing a selection button hasno effect.

2a. Customer fails to push a button within 1 minute from insertion of the lastcoin. Coins are returned.

2b. Customer selects beverage out of stock. Coins are returned.

Frequency of use: several per day

Priority: 1

Implementation status:

Open issues:


14/35

14




Domain modeling

Behavioral modeling

Design






15/35

15

Noun analysisConsider a simplified vending machine, which is used to dispense soft

drinks. The vending machine consists of a coin slot for inserting coins, a

return tray for returning the customer's money and three buttons used

to select Pepsi (tm), Coke (tm) or Dr. Pepper (tm). If the customer insertscoins and does not press a button within one minute, the coins will be

returned automatically (no coin-return lever). If the customer selects a

beverage which is out-of-stock (none left), the coins will also be returned.

This vending machine does not provide change - it is up to the customer to

insert only enough money to purchase a drink. If sufficient coins are

inserted and a button with available beverages is pressed, the appropriate

drink is dispensed, the corresponding button is illuminated for five

seconds, and the coin slot moves the coins to the general storage area (i.e.

the purchase has finished).


16/35

16

Domain Model - Initial Class Diagram

Shelf

Vending

Machine

ReturnTray

CoinSlot

amount

Button

idlitUp

1

1

3

1

1

3

1

Contains

Contains

Customer

Contains

Inserts

coins

into

Pushes

1

1

Contains

Drink

0..*1

Contains

1


17/35

17




Domain modeling

Behavioral modeling

Design






18/35

18

Sequence Diagram for Use Case 1

(Main Scenario + Extensions 1a & 2b)customer machine

insertMoney(x)

insertMoney(y)

m:=checkAmount(x+y)

a:=checkAvailability(z)

[!a] return()

5 seclightUp()

lightDown()

moveCoins()

dispenseDrink()

push(z)

[m&a]


19/35

19

Activity Diagram for Use Case 1

(Main Scenario + Extension 1a)

Insert money

Select drink

Dispense drink

Sufficientmoney? no

yes

VendingMachineCustomer

money

drink


20/35

20

State Chart for Vending Machine

(Full behavior)Insert money (x)

Ready

DispensingEntry/

dispense drink,

light up button,

take money

Push button Z [sufficient

money & drink Z in stock] after (5 seconds)/light down

Push button Z

[no drink Z]/

return money

after (60 seconds)/

return money


21/35

21

Hierarchical State Chart

DispensingEntry/

dispense drink,

light up button,

take money

Push button Z [sufficient

money & drink Z in stock]after (5 seconds)

Insert money (x)

Coin slotempty Coin slothas money

after (60 seconds)/return moneyPush button Z [no drink Z]/return money


22/35

22




Domain modeling

Behavioral modeling

Design






23/35

2

3

Sequence Diagramcustomer coinSlot button1 controller shelfRel1 shelfSens1

insertMoney(x)

insertMoney(y)

push() request(1)

m:=checkAmount()

getTotal()

a:=checkAvailability()

isEmpty()

[!a] return()

release()lightUp()

close()

lightDown()

open()5 sec

moveCoins()

[m&a]


24/35

24

Extension2a

customer coinSlot

insertMoney(x)

insertMoney(y)

button1 controller

request(1)push()

timer

return()

timeOut()

insertMoney(x)

insertMoney(y)

close()

set(60)

set(60)

reset()

set(60)

set(60)

< 60 sec

checkTime()

checkTime()60 sec


25/35

25

Collaboration Diagram

coinSlot

button1

controller

shelfRel

shelfSens

timer1

timer2

1: insertMoney(x)

2: push()

2.1: request(1)

2.1.2: m:=checkAmount()

2.1.2.1: getTotal()

2.1.3: a:=checkAvailability()

2.1.3.1: isEmpty()

2.1.4a [!a]: return()

2.1.7 [m&a]: moveCoins() 2.1.4 [m&a]: release()

2.1.5 [m&a]: lightUp()2.1.1: close()

3.2.2: lightDown()

3.1.1: open()

1.1: set(60)

2.1.1.1: reset()

2a: timeOut()

3: timeOut()

2.1.6: set(5)

self


26/35

26

Additional Design Technique: CRC Cards

CRC (class-responsibility-

collaborator) cards

Index cards

Written in a design session

Focus on assigning

responsibilities

Can be used in addition to

interaction diagrams Pioneered by ward

Cunningham & Kent beck


27/35

27




Domain modeling

Behavioral modeling

Design






28/35

28

Refined Class Diagram

Controller

price: Integer

request(Integer)checkAmount()

checkAvailability() ShelfRel

release()

CoinSlot

amount: Integer

opened: Bool

insertMoney(Int)

close()

open()getTotal()

return()

moveCoins()

Button

id: IntegerlitUp: Bool

push()

lightUp()

lightDown()

ShelfSens

empty: Bool

isEmpty()

1

1

3

1

11

3

Timer

set()

reset()

checkTime()

Signals

timeOut()

1

3

1

1


29/35

29




Domain modeling

Behavioral modeling

Design






30/35

30

Single Thread With Passive Objects Requires a top level control loop

Read input, compute, write output

Calls to procedures performing the processingsteps need to be scheduled manually

Simple: no synchronization of concurrent threads

or processes necessary

May waste computing resources

Polling style


31/35

31

Passive objects design with a

main control loop

// main control loop

while(true)

{

If (coinSlotSensor.coinInserted())coinSlot.insertMoney(coinSlotSensor.amount()) ;

If (buttonSensor1.pressed()) button1.push();

If (buttonSensor2.pressed()) button2.push();

If (buttonSensor3.pressed()) button3.push();timer1.checkTime();

timer2.checkTime();

}


32/35

32

Active Objects Define a statechart for each object

Communication through signals

E.g., SDL: asynchronous send, synchronous receive Synchronous communication requires sending a request

and waiting for the response

Avoid variables shared between processes

No direct support by most programming languages Need a framework/library

Better utilization of computing resources

Automatic scheduling


33/35

33




Domain modeling

Behavioral modeling

Design

Interaction diagrams Refined class diagram




34/35

34

Summary Analysis

Use case analysis - writing user stories

Structural analysis/domain modeling - finding real-world objects

Behavioral analysis Creating activity diagrams and sequence diagrams to capture use case

details

Creating state charts to capture external reactive behavior of thesystem and other domain objects

Design

Creating interaction diagrams and distributing responsibilities Creating refined class diagrams

Deciding on concurrency and scheduling model

Possibly modeling detailed behavior of design objects using statecharts


35/35

35

Further Reading Recommended OO Analysis & Design

book:

Applying UML & Patterns: An Introduction to

Object-Oriented Analysis and Design and the

Unified Process by Craig Larman, 2nd edition,

Prentice Hall, 2002

oo design ch05

Documents