Chapter1 Train UML Example

8/3/2019 Chapter1 Train UML Example

1/35

Purposes of example:

Follow a design through several levels of

abstraction.Gain experience with UML.

Example: Model Train Controller


2/35

Model train setup

console

power

supply

rcvr motor

ECCaddressheader command


3/35

Requirements

Console can control 8 trains on 1 track.

Throttle has at least 63 levels.

Inertia control adjusts responsiveness with at least 8 levels.

Emergency stop button. Error detection scheme on messages.


4/35

Requirements form

name model train controllerpurpose control speed of


5/35


6/35

Basic system commands

command name parameters

set-speed speed (positive/negative)

set-inertia inertia-value (non-negative)

estop none


7/35

Typical control sequence

:console :train_rcvrset-inertia

set-speed

set-speed

set-speed

estop

Time


8/35

Message classes

command

set-inertia

value: unsigned-integer

set-speed

value: integer

estop


9/35

Roles of message classes

Implemented message classes derived from messageclass.

Attributes and operations will be filled in for detailed

specification. Implemented message classes specify message type by

their class.

May have to add type as parameter to data structure in

implementation.


10/35

Subsystem collaboration diagram

Shows relationship between console and receiver

(ignores role of track):

:console :receiver

1..n: commandmessage typesequence


11/35

System structure modeling

Some classes define non-computer components.

Denote by *name.

Choose important systems at this point to show basic

relationships.


12/35

Major subsystem roles

Console:

read state of front panel;

format messages;

transmit messages. Train:

receive message;

interpret message;

control the train.


13/35

Console class roles

panel: describes analog knobs and interface hardware.

formatter: turns knob settings into bit streams.

transmitter: sends data on track.


14/35


15/35

Train class roles

receiver: digitizes signal from track.

controller: interprets received commands and makes

control decisions.

motor interface: generates signals required by motor.


16/35

Train system classes

train set

train

receiver

controller

motor

interface

detector* pulser*

11..t

1

1

11

1 1

11

11


17/35

Detailed specification

We can now fill in the details of the conceptualspecification:

more classes;

behaviors. Sketching out the spec first helps us understand the basic

relationships in the system.


18/35

Train speed control

Motor controlled by pulse width modulation:

V

+

-

duty

cycle


19/35

Train system analog physical object

classes

knobs*

train-knob: integer

speed-knob: integer

inertia-knob: unsigned-integer

emergency-stop: boolean

pulser*

pulse-width: unsigned-

integer

direction: boolean

sender*

send-bit()

detector*

read-bit() : integer

set_knobs()


20/35

Class descriptions

panel class defines the controls.

new-settings() behavior reads the controls.

motor-interface class defines the motor speed held as

state.


21/35

Panel and motor interface classes

panel

train-number() : integerspeed() : integer

inertia() : integer

estop() : boolean

new-settings()

motor-interface

speed: integer


22/35

Class descriptions

transmitter class has one behavior for each type ofmessage sent.

receiver function provides methods to:

detect a new message; determine its type;

read its parameters (estop has no parameters).


23/35

Transmitter and receiver classes

transmitter

send-speed(adrs: integer,speed: integer)

send-inertia(adrs: integer,

val: integer)

send-estop(adrs: integer)

receiver

current: command

new: boolean

read-cmd()

new-cmd() : boolean

rcv-type(msg-type:

command)

rcv-speed(val: integer)

rcv-inertia(val:integer)


24/35

Formatter class description

Formatter class holds state for each train, setting forcurrent train.

The operate() operation performs the basic formatting

task.


25/35

Control input cases

Use a soft panel to show current panel settings for eachtrain.

Changing train number:

must change soft panel settings to reflect currenttrains speed, etc.

Controlling throttle/inertia/estop:

read panel, check for changes, perform command.


26/35

Formatter class

formatter

current-train: integer

current-speed[ntrains]: integercurrent-inertia[ntrains]:

unsigned-integer

current-estop[ntrains]: boolean

send-command()panel-active() : boolean

operate()


27/35

Control input sequence diagram

:knobs :panel :formatter :transmitter

changein

speed/

inertia/e

stop

changein

trainnumb

er

change in

control

settings

read panel

panel settings

panel-active

send-commandsend-speed,

send-inertia.

send-estop

read panel

panel settings

read panel

panel settingschange intrain

number

set-knobs

new-settings


28/35

Formatter operate behavior(in the formatter class)

idle

update-panel()

send-command()

panel-active() new train number

other


29/35

Panel-active behavior(in the formatter class)

panel*:read-train()current-train = train-knob

update-screen

changed = true

T

panel*:read-speed() current-speed = throttlechanged = true

T

F

...

F

...

current-train != train-knob

current-speed != throttle


30/35

Train controller class

controller

current-train: integer

current-speed[ntrains]: integercurrent-direction[ntrains]: boolean

current-inertia[ntrains]:

unsigned-integer

operate()

issue-command()


31/35


32/35

S di f d


33/35

Sequence diagram for set-speed

command

:receiver :controller :motor-interface :pulser*

new-cmd

cmd-type

rcv-speed set-speed set-pulse

set-pulse

set-pulse

set-pulse

set-pulse


34/35


35/35

Summary

Separate specification and programming. Small mistakes are easier to fix in the spec.

Big mistakes in programming cost a lot of time.

You cant completely separate specification andarchitecture.

Make a few tasteful assumptions.

Documents

Chapter1 Train UML Example