1 ECE 355: Software Engineering Bridge Material Object Oriented Design.

1

ECE 355: Software Engineering

Bridge Material

Object Oriented Design

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

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

portability into account– Devising mechanisms

4

OO Analysis & Design

• Many methods (OMT, Booch, Unified Process, etc.)

• Similar goals and techniques

5

OO Analysis Activities

• Use case analysis– Mostly focused on writing text - one overview context diagram is often

enough– Use cases are just a part of functional requirements (only the interactive

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 behavior of the system and other domain objects

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

Overview

• What is OO Analysis & Design?• Vending Machine Example

– AnalysisUse case modeling• Domain modeling• Behavioral modeling



8

Use Case Diagram As a Context Diagram

Use Case 1(Buy a drink)Customer

Vending Machine

9

Use Case Diagram As a Context Diagram

Use Case 1(Buy a drink)Customer

Vending Machine

Use Case 2(Restock)

Agent

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 Alistair Cockburn, 2000

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 inserts coins 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

Use Case 1 (“Fully Dressed” Version)

Primary actor: CustomerGoal in context: Customer buys a drinkLevel: User levelStakeholders and Interests:

Customer : wants to buy a drinkVendor: wants to get paid for any goods dispensed

Preconditions: Machine is ready & awaiting interactionMinimum guarantee: Customer gets his coins back if no drink dispensedSuccess guarantees:

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

Trigger: Customer starts interaction with the machine

13

Use Case 1 (Cont’d)

Main success scenario:1. Customer inserts sufficient money into the coin slot2. Customer pushes one of the three select buttons3. The selected drink is dispensed.4. The pushed select button lights up for 5 seconds.5. Coins are taken by the machine.Extensions1a. Customer inserts no or insufficient money. Pushing a selection button has no effect.2a. Customer fails to push a button within 1 minute from insertion of the last coin.

Coins are returned.2b. Customer selects beverage out of stock. Coins are returned.Frequency of use: several per dayPriority: 1Implementation status: …Open issues: …

14

Overview


– Analysis• Use case modelingDomain modeling• Behavioral modeling



15

Noun analysis

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 inserts coins 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

Domain Model - Initial Class Diagram

Shelf

VendingMachine

ReturnTray

CoinSlotamount

ButtonidlitUp

1

1

3

1

1

3

1

Contains

Contains

Customer

Contains

Insertscoinsinto

Pushes

1

1Contains

Drink0..*1

Contains

1

17

Overview


– Analysis• Use case modeling• Domain modelingBehavioral modeling



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

Activity Diagram for Use Case 1(Main Scenario + Extension 1a)

Insert money

Select drink

Dispense drink

Sufficientmoney? no

yes

VendingMachineCustomer

money

drink

20

State Chart for Vending Machine(Full behavior)

Insert money (x)

Ready

DispensingEntry/

dispense drink,light up button,

take money

Push button Z [sufficientmoney & drink Z in stock] after (5 seconds)/light down

Push button Z[no drink Z]/return money

after (60 seconds)/return money

21

Hierarchical State Chart

DispensingEntry/

dispense drink,light up button,

take money

Push button Z [sufficientmoney & 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

Overview



– DesignInteraction diagrams• Refined class diagram• Concurrency and scheduling


23

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

Extension 2acustomer 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

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

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

Overview



– Design• Interaction diagramsRefined class diagram• Concurrency and scheduling


28

Refined Class Diagram

Controllerprice: Integerrequest(Integer)checkAmount()checkAvailability() ShelfRel

release()

CoinSlotamount: Integeropened: BoolinsertMoney(Int)close()open()getTotal()return()moveCoins()

Buttonid: IntegerlitUp: Boolpush()lightUp()lightDown()

ShelfSensempty: BoolisEmpty()

1

1

3

1

11

3

Timer

set()reset()checkTime()SignalstimeOut()

1

3

1

1

29

Overview



– Design• Interaction diagrams• Refined class diagramConcurrency and scheduling


30

Single Thread With Passive Objects

• Requires a top level control loop– Read input, compute, write output

• Calls to procedures performing the processing steps need to be scheduled manually

• Simple: no synchronization of concurrent threads or processes necessary

• May waste computing resources– “Polling style”

31

Passive objects design with a main control loop

// main control loopwhile(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

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

Overview




Summary and Further Reading

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 the system 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 state

charts

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

1 ECE 355: Software Engineering Bridge Material Object Oriented Design.

Documents

case analysis

use case diagram

context diagram use

behavioral analysis

design domain structures

oo design activities

oo analysis activities

domain objects