Slides Handout

8/3/2019 Slides Handout

1/100

Slides for

Design Methods for Reactive Systems:

Yourdon, Statemate and the UML

Roel Wieringa

Department of Computer Science

University of Twente,

the Netherlands

[email protected]

www.cs.utwente.nl/roelw

1

List of Slides

3 Chapter 1. Reactive Systems

11 Chapter 2. The Environment

28 Chapter 3. Stimulus-Response Behavior

43 Chapter 4. Software Specifications

55 Chapters 57. Mission Statement, Function Refinement

Tree, Service Description

77 Chapter 8. Entity-Relationship Diagrams

99 Chapter 9. ERD Modeling Guidelines

125 Chapter 10. The Dictionary

139 Part IV. Behavior Notations

154 Chapter 11. State Transition Lists and Tables

166 Chapter 12. State Transition Diagrams

2

188 Chapter 13. Behavioral Semantics

210 Chapter 14. Behavior Modeling and Design Guidelines238 Part V. Communication Notations

246 Chapter 15. Data Flow Diagrams

265 Chapter 16. Communication Diagrams

276 Chapter 17. Communication Semantics

287 Chapter 18. Context Modeling Guidelines

300 Chapter 19. Requirements-Level Decomposition Guidelines

323 Chapter 20. Postmodern Structured Analysis (PSA)

332 Chapter 21. Statemate

351 Chapter 22. The Unified Modeling Language (UML)

381 Chapter 23. Not Yet Another Method

3

Chapter 1. Reactive Systems

Partitioning of systems into information systems, controlsystems and telecommunication systems is becoming obsolete.

More informative partitioning: Transformational versus

reactive systems.

Reactive systems respond to stimuli in order to bring aboutdesirable effects in their environment.

Reactive systems may do one or or of these things: Manipulate complex data,

engage in complex behavior,

communicate with many other systems.

4


2/100

Example 1

A training information system supports coordination of monthlyintroductory training courses for new employees of large company.

Nonterminating: When switched on, it should respond toevents such as queries, updates, arrival of downloads.

Interactive: When switched on, it can engage in dialogs with itsusers and with other software (personnel information system).

State-dependent response: Its response depends upon the datastored in it.

Environment-oriented response: Responses defined in terms ofcourses, participants, teachers etc.

Parallel processing: May interact with several users andprograms simultaneously.

5

Example 2

An electronic ticket system supports buying and using rail tickets

by means of a smart card in combination with a PDA.

Nonterminating: When switched on, it should respond toevents such as buy, show, use.

Interactive: When switched on, it can engage in dialogs withits users and with other software.

State-dependent response: Its response depends upon thetickets and the data about railroads stored in it.

Environment-oriented response: Responses defined in terms ofrailroad routes and segments.

Parallel processing: It may consist of several pieces of softwarerunning concurrently on smart card and PDA.

6

Example 3

A heating controller of heating tank in juice plant.

Nonterminating: When switched on, it should respond toevents such as start heating, too hot, too cold.

Interactive: When switched on, it can engage in dialogs withits users and with devices.

Interrupt-driven: It responds to time-outs and signals fromoperator and devices as and when they occur.

State-dependent response: Its response depends upon the datathat it stores, which is about the heating tank and its devices.

Environment-oriented response: Responses are about heatingtank and its devices.

Parallel processing: Monitoring temperature, monitoringpressure, listening to commands from operator.

Real time: Responses would be incorrect if too late.

7

Definition of reactive system

A reactive system is a system that, when switched on, is

able to create desired effects in its environment by enabling,

enforcing or preventing events in the environment.

Has most of the following characteristics:

nonterminating interactive interrupt-driven state-dependent environment-oriented

parallel real-time

8


3/100

Examples of reactive systems

Information systems Workflow systems Groupware EDI systems

Web market places Production control software Embedded software

9

Transformational systems

Contrast reactive systems with transformational systems, that

compute output from an input and then terminate.

terminating

sometimes interactive

not interrupt-driven output not state-dependent output defined in terms of input sequential usually not real-time

Compiler, assembler, loader, expert system, optimizationalgorithm, search algorithm, linear programming algorithm, etc.

10

Design approach to reactive systems

To design reactive systems, environment models are important:

Possible entities and behavior in environment (chapter 2).

Communication of system with environment (chapter 3)

11

Chapter 2. The Environment

Example 1

Joiner

(new employee)

Training

Information

System

Registration

desk

XYZ wants to

participate

I want to

participate

XYZ allocated to group 3

Group 3

12


4/100

Joiner

(new employee)

Training

Information

System

subject

of both messagesconnection

Informative

function

of TIS

Message about joiner

Registration

desk

XYZ wants to

participate

I want to

participate


Group 3

message about

joiner and group

subject

13

Example 2

Heating

controller

Heating

tankHeater

switch on

Operator

start

heating

the tank

heat

subjectof message 2

subjectof message 1

directive functionof controller

command about

heating tank

2

1

Console

14

Example 3

Conductor Conductors PDA

Travellers

smart card

Stamp ticket

for usage

enter travellers

smart card,

push usage button

Ticket

Subject

of message

Manipulative function

of Electronic Ticket System

15

Symbolic interactions

Reactive software systems communicate with their environ-

ment by means of linguistic messages.

Not in object-oriented sense. Post-it notes exchanged with environment. Flow of symbols is more important than of flow of energy or

matter.

Physical connection is what makes symbol flow possible. Effect not determined by physical causality but by symbol flow. We abstract from the physical realization of these messages.

16


5/100

Summary of examples

Messages entering and leaving a reactive software system are

characterized by three aspects:

A subject What is the message about?

About people, devices, conceptual entities, lexical entities.

A function What is the purpose of the message?

To inform or direct the environment, to manipulate lexical items

in the system.

A connection Through which path does the message travel from sender to

receiver?

Messages can get delayed, distorted or lost along the way.

17

Definitions

Subject domain of a reactive system: Set of all subjects of all

its input and output messages.

Functions of a reactive system: All services provided by thesemessage exchanges.

Connection domain of a reactive system: Channels throughwhich messages flow to and from the system.

18

Subject domain

The part of the world talked aboutby the messages that crossthe system interface.

To find it, ask what the messages entering and leaving the system

are about.

Physical entities. Have a weight and a size. Make noise,generate heat.

People

Devices

Conceptual entities. Invisible and weightless. E.g. bankaccounts, obligations, permissions.

Lexical items. Physical entities with a meaning. E.g. Tickets,contracts, receipts.

19

Example of a physical subject domain

Heating controller

Heater

Heating tank

ThermometerSubject domain

A physical subject domain always exists outside the software

system.

20


6/100

Example of conceptual, lexical, physical subjectdomain entities

Personnel

information

systemEmployee

Employment contract

Rights and obligationsEmployee

department

personnel

Subject domain

Conceptual entities always exist outside the software system. They

exist because people agree to treat them as existing.

21

Lexical entities can be copied

Employee

Employment contract

copy 2

Rights and

obligations

Employment contract

copy 1

Personnel

information

system

Employee

department

personnel

Subject

domain

Software system lexical entities

Lexical subject domain entities may exist in the software or in the

environment of the software. They may be copies of each other.

22

Physical and conceptual entities in a subjectdomain

Button

Elevator cage

Allocation record AllocationElevator

controller

Subject dmain

23

Functions of reactive systems

Registration. System registers events in environment. TIS registers participation in course.

Heating controller registers temperature.

Direction. System influences events in environment. Controller switches heater on.

Compact dynamic bus station controller: Tells driver at

which platform to park.

Manipulation. System manipulates virtual entities; this has ameaning in the social environment.

ETS stamps ticket.

TIS allocates joiner to group.

24


7/100

Connection domain

Events of interest usually do not occur exactly at the interfaceof the system.

Actions caused by the system usually do not occur exactly atthe interface of the system.

Communication channel needed. If represented explicitly it is

called a connection domain. Is possible source of

delay, loss, and distortion

of messages to/from the system.

25

Subject domain and connection domain

Library

member

Library

desk

Document

Acquisition

department

Publisher

Circulation

department

acquisition info

reminder

remind requestreserve, borrow,

return

Library

desk

notification

availability

DocumentCirculation

System

Connection

domain

Subject

domain

SuDLibrarian

queryanswer

26

System directly connected to subject domain

Elevator controller

Request

buttonMotor Doors

SuD

Subject

domain

Passenger

Arrival

sensor

Direction

indicator

27

Main Points

Let SuD be a Software System under Design.

Message that cross the interface of the SuD are about thesubject domain.

Subject domain entities exist outside the SuD; except lexicalitems, that may also exist inside the SuD.

Messages that cross the interface have three kinds of functions:Informative, Manipulative, Directive.

Messages travel to and from the SuD through a connectiondomain.

28


8/100

Chapter 3. Stimulus-Response Behavior A reactive system receives messages from sources in its

environment and it sends messages to destinations in its

environment.

At the sources, events o ccur. At the destinations, actions occur.

We now look at the chain of cause and effect from event to

system stimulus, and from system response to action.

We will see that to interpret stimuli and to motivate responses,we need to make assumptions about the environment.

29

Example 1

Joiner

(new employee)

Training

InformationSystem

Registration

desk

XYZ wants to

participate

I want to

participate


Group 3

event stimulus

responseaction

allocation

created

Assumptions:

Registration desk transmits message faithfully.

The employee is indeed a joiner.

30

Example 2

Heating

controller

Heating

tankHeater

switch

on

Operatorstart

heating

the tank

heat

ConsoleTime to

start heating

Heating started

action

response

stimulustemporal

event

Assumptions:

The message is transmitted faithfully by the console. The translates switch on into heat production. The heater is connected to the heating tank.

31

Example 3

Conductor Conductors PDA

Travellers smart cardStamp ticket

for usage

enter card

in PDA

Ticket

response and action

stimulus

stamp the ticket

event

Assumptions:

The PDA is indeed the conductors PDA.

The conductor requests to stamp the ticket while the ticket

owner is traveling on a segment for which the ticket is valid.

32


9/100

Example 4

Goods on shelves in the supermarket

Point-of-

sale-

terminal

Stock

information

system

Customer

buy

stock too lowSuppliers

information

system

order 30

widgets

Response Stimulus

A shelf becomesempty

Condition

change

event

SuD

Receive 30 widgets

Action

SuD discovers the change event by testing the condition stock < 4.

Assumptions:

Data in SIS accurately represent state of the shelves.33

Summary of stimulus-response behavior

Some named external event, condition change event or temporalevent occurs in the environment.

Through some some communication channel, this causes anSuD stimulus.

May be modeled explicitly as connection domain.

The SuD responds. Through some communication channel, this causes an action in

the environment.

For virtual entities, response and action coincide.

34

Structure of stimulus-response behavior

event or condition

Reactive system

action

action 1

action 2

effect 1

effect 2

desired effect

effect 3

stimulusresponse

Connection domain

35

The role of assumptions

These are statements about the environment ...

that must be true for the (stimulus, response) pair to bedesirable;

but the SuD cannot guarantee them to be true. If assumption is false, (stimulus, response) pair may still be

desirable, or indifferent, or even undesirable!

Typical assumptions concern laws of nature and properties of

devices (e.g. observers and actors) and people (e.g. users and

operators).

36


10/100

Observers and actors are in the connectiondomain

Observer

Reactive system

ActorConnection domain

event action

stimulus response

37

Assumptions about observers

Plate cutting controller

Metal plate

Photoelectric cell Cutter

on, off

close, open cut

move

Events of interest: begin of plate arrives, end of plate arrives Available stimuli: on, off.

We need the following assumptions:

The photo-electric cell is functioning properly.

The cell is stimulated only by the arrival of the begin or end of a

metal plate.

38

Event recognitionSystem must respond to the event

a point arrives where the sheet must be cut.The system must infer the occurrence of this event. Event

recognition:

Record the point in time at which plate arrives.

Wait for time at which desired point is under the cutter.Additional assumption needed:

Speed of the plate is n meters / second.

39

Observability of events

Elevator controllerButtonclosepush

decide to take the elevator,

decide to take the stairs

What is the subject domain of the elevator controller?

40


11/100

Observing temporal events

Timer

Reactive system

Actor

action

Connection domain

stimulus response

time to perform action

41

Realizability of actions

Controller

Solenoid

Coolant Valve Spring

Tube

42

Main points

Reactive software system is connected to interesting events andactions by a communication channel.

Stimulus is event observation. Response is assumed to cause desired action. If assumptions about environment are true, (stimulus,

response) pairs are desirable; otherwise, they may beundesirable or indifferent.

Assumptions cannot be guaranteed by the system.

43

Chapter 4. Software Specifications

We call any creative decision about a system a design decision. To design a system is to make a plan how it will be built.

A specification is a description of design decisions.

A reactive system specification must describe the place of the SuD in the system hierarchy,

it must describe functions, behavior and communication of

the SuD, and

it must describe its composition.

The specification must be used to motivate the design in a

systems engineering argument.

44


12/100

Systems engineering argument example 1

Training department

Training

Information

System

Course

coordinatorSecretary Staff

Upload/

downloadmodule PrintingAllocation Registration

If TIS allows registration of unexpected participants and the department keeps extra staff, then department is able to handle newcomers efficiently.

45


Juice pasteurization

unit

Heatingcontroller

Operator Heater Thermometer

Recipe

data

Batch

control

Device

data

Tank

control

Heating tank

If controller controls heater according to batch recipe and thermometer is functioning, then pasteurization unit heats batch according to recipe.

46


Railway

company

Rail

networkConductor

Conductors

PDA

Rail network

database

Tickets and

stamps

Bank

database

Central

ticket selling

computer

Traveler

Travelers

PDA

Travelers

smart

card

Clearing

houseBank

ETS

If ETS allows travelers to buy tickets through their PDA and travelers PDA interfaces with ETS, then railway company reduces operating costs.

47

System engineering argument

SuD External entityExternal entity

Composite system

Subsystem 1 Subsystem n

If SuD satisfies specification S and environment satisfies assumptions A then composite system has emergent properties E.

Emergent properties arise by interaction of component systems.They should satisfy goals of composite system.

48


13/100

The role of assumptions If assumptions are not satisfied by environment, the composite

system goal may not be reached.

System cannot guarantee the assumptions.Examples:

Heat will rise when switch on sent to heater.

Assume laws of thermodynamics and assume that devices work.

Ticket is stamped for segment of the current route.

Assume that the conductor, traveler and smart card are physically located

in the segment for which ticket is stamped.

49

Kinds of assumptions

laws of nature

specifications of devices rules for people (laws, procedures) definitions of conceptual structures (e.g. meaning of stamps

and tickets)

Only laws of nature are infallible ... we assume. Many assumptions

are about the subject domain and about the connection domain.

50

Kinds of properties

Functional properties

Services Behavior Communicationetc.

Composite

system

Software

system

Software

subsystem

Software

component

Decomposition

External

properties

Qualityattributes

Software

object

51

Properties occur at every level

SuD


Services

Behavior

Communication

Services

Behavior

Communication

Services

Behavior

Communication

......

Composite

system

External

entity

External

entity

Services

Behavior

Communication

Services

Behavior

Communication

Services

Behavior

Communication

Functional properties appear at every level.

Service = Interaction that delivers desired effect.

Behavior = Ordering of interactions over time.

Communication = Symbol flow between different entities.

52


14/100

Terminology

With respect to the SuD, we talk about:

Requirement = desired property.

Constraint = imposed property.

Aspect = group of properties.

53

Operational specification

Specification of set of reproducible operations to find out whether a

property is present.

Important class of operational specs has the form

If stimulus s occurs and system is in state C then produce response r.

Also called Event-Condition-Action (ECA) rule. Appears in state

transition table (see chapter 12).

54

Main points

Systems have functional properties and quality properties. Functional properties are services, behavior, communication. These reappear at every level in aggregation hierarchy. (There are really three aggregation hierarchies.) SuD needs external entities to jointly produce desired emergent

properties of composite system. System engineering argument.

55

Chapters 57. Mission Statement, Function

Refinement Tree, Service Description

We describe the utility of the system for its environment bydescribing its functions for the environment.

But a function is not a component; it is not a program; it isnot a part of a program. It is the added value, or utility, of the

SuD for its environment.

The function of this coffee machine is to brew coffee.

The added value of this coffee machine is to brew coffee.

The utility of this coffee machine is to brew coffee.

In this course, these three sentences mean the same thing.

56


15/100

Example 1: Goal tree of the training department

More efficient and effective management of introductory courses

Better information

to speakers

Faster handling of

unexpected participants

Less unexpected

participants

Faster handling of

expected participants

Prepare

material

Print badges

Allocate

participants

Other activities

Download

latest information

from personnel

information system

Online

registration

Adhoc

badge

printing

Adhoc

list printing

Better information

to personnel department

Upload

participation dataSelf

registration

TIS should contribute to goals in italics.

57

Example 1: Mission of TIS

Name: Training Information System

Acronym: TIS

Purpose: To support the management of monthly introduc-

tory training courses.

Responsibilities:

To support course preparation, including allocation of par-

ticipants to groups and printing badges

To support course handling (unexpected, absentees)

To support course wrap-up

Exclusions:

Data of unexpected participants is not checked.

No support for allocation of speakers to groups.

No support for allocation of groups to rooms.

58

Example 1: Function refinement tree of TIS

Support the coordination of introductory training courses

Download list

of joiners

Print list of

group members

Allocate joiners

to groups

Register

absentee

Register

unexpected

participant

Upload

participation

record

Print

badges

Course preparation support Registration

support

Course wrapup

support

59

Example 1: Description of a TIS service

Download joiners

Triggering event: Coordinator requests to download listof joiners from the personnel information system.

Delivered service: Download the list of people from the

Personnel Information System who have joined the com-

pany since the previous training.

Assumptions: The data in the Personnel Information

System reflects the situation accurately with a time lag

of not more than one working day.

60


16/100

Example 1: Description of another TIS service

Upload participant record

Triggering event: Coordinator requests to upload list of

joiners to personnel information system.

Delivered service: Upload the list of p eople who partici-

pated in the training to the Personnel Information System.

Assumptions: The Personnel Information Systems is

able to deal with data about unexpected participants, in-

cluding any remaining errors in that data.

61

Example 2: Goal tree of juice pasteurization plant

Juice pasteurization

Short set-up timeFast change

of recipes

Improved

traceabilityPasteurization

Maintain recipe

database

Initialization of controller

by software

Heating a batch

according to recipe Maintain log

Efficiency Effectiveness

62

Example 2: Mission of heating controller

Name: Juice heating controller. Purpose: To control the heating process of fruit juices

in a heating tank.

Responsibilities: To initialize itself with batch data and heat the batch

according to recipe.

To report on the heating process. To maintain safe conditions in a tank.

Exclusions: Filling the storage tanks with juice.

Transferring pasteurized juice to the canning line.

63

Example 2: Function refinement of heatingcontroller

Control the heating process of fruit juice in a heating tank

Provide a report

Log temperature

Stop heating

Raise alarm

Shut down

Heating function

Start heating

Switch on heater

Finish heating

Switch off heater

Reporting function Safety function

Create batch data

64


17/100

Example 2: A service description

Name: P1. Heat batch according to recipe. Triggering event: Operator command start heating batch b

according to recipe.

Delivered service: Upon reception of this command, thecontroller ensures that a heating process takes place in theheating tanks in which b is stored, according to the recipe of b.

Assumptions: There is a batch in the heating tank.

65

Example 2: Another service description

Name: Log temperature. Triggering event: When an execution of P1 starts, and then

every 10 seconds during this execution of P1.

Delivered service: The controller records the measuredtemperature in each tank in which b is stored.

66

Example 3: Mission statement of ETS

Name of the system: Electronic Ticket System (ETS).

Purpose: Provide capability to buy and use tickets of a rail-

way company using a PDA and a smart card.

Composition: Software distributed over smart cart, PDAs,

central computer.

Responsibilities of the system:

To support ticket buying

To support ticket usage

To support ticket refunding

Exclusions:

The system does not perform travel planning

Only tickets for one person and one trip (single or return).

67

Example 3: Function refinement of ETS

Provide capability to buy and use tickets

Traveler functions Conductor functions

Sell a ticket Show a ticket Stamp a ticket for use Refund a ticket

68


18/100

Two service descriptions of ETS

Name: Sell a ticket. Triggering event: Traveler requests to buy a ticket. Delivered service: Allow a traveler to buy a ticket at

any time and place chosen by the traveler.

Name: Show a ticket. Triggering event: Traveler requests to view a ticket. Delivered service: Display ticket attributes to the user.

69

Levels of design

Business

problem

analysis

Business

design

process

Software

problemanalysis

Software

designprocess

Business

problem

Business

problem

description

Business

solution

specification

Software

problemdescription

Software

requirementsspecification

Software

problem

Software

decomposition

problem

analysis

Software

decomposition

design

process

Software

decompo-

sition

problem

Software

decompo-

sition

problem

description

Software

decompo-

sition

specification

Decompo-

sition

Refine-ment

Decompo-

sition

A business solutution specification describe a decomposition ofthe business that solves a business problem.

A software specification refines the software part of a businesssolution.

70

Goal analysis

First separate the design levels as on previous slides. Next identify business goals.

In a goal tree, achievement of children goals is sufficient to

achieve parent goal.

Leaves of a business goal tree usually are desirable business

activities.

From the goals of the business solution, derive from thesoftware goals.

This gives us statement of purpose and major responsibilitiesof the software.

71

Mission statement

Highest level software specification. Talks about software solutions

instead of business solutions.

To find software mission, analyze business goals.

To find mission, find desired emergent properties E ofcomposite system.

Justify mission and responsibilities by system engineering

argument: Mission statement + environment assumptions

entail business goals.

Mission statement is updated as our understanding improves

during the project.

72


19/100

Function refinement tree.

Makes responsibilities more specific.

Not a system structure: Just an indented shopping list. Organization of tree is subjective: Determined by discussion

with customer.

The tree bounds functionality of the system.

It is the most implementation-independent description of the

system.

It justifies the presence of services. It prevents the presence of unnecessary services.

73

Terminology

Responsibilities

Mission

Services

Functions

Transactions

Function = ability to create desired effect in the environment.

Responsibility = Contribution to environment goal.

Service = Useful interaction triggered by event.

Transaction = Atomic interaction.

74

Service descriptions

Each service is identified by a(1) triggering event and a

(2) delivered value (benefit).

Each service may make assumptions about the environment. Do not give details about system behavior nor about

communication channels with the system.

Just describe the valuable effect that the system should haveon the environment.

A service may have a simple or a complex behavior; describethis later, using techniques from chapters 11 and 12.

75

Service descriptions are not system components

For programmers, it is hard to see a piece of text not as asoftware component.

A service description is not a software component; it is a description of something useful done by the software.

76


20/100

Main points

Mission relates system functions to business goals. Function refinement tree relates services to mission. Services have a discrete beginning and deliver a value.

Services may be non-atomic, consisting of many transactions.

77

Chapter 8. Entity-Relationship Diagrams

The subject domain of a software system is the part of

the world talked about by the messages that cross the system

interface.

To find the subject domain of a system

Look at the messages received and sent by the system, and Ask what these messages are about.

Document the meaning of these messages in a dictionary,

supplemented by an ERD of the subject domain.

78

Example 1: Subject domain of TIS

Branch1

Participation

absent : Bool

time

day : {1, 2}

Group

number

Employee

name

Coordi-

nator

name

identifier

Course

offering

starting date 11Joiner

Unexpected

participant

These entities are the topic of interactions with TIS.

79

Example 2: Subject domain of heating controller

Recipe

name

desired temperature

duration

Batch

batchID

amount1*1..2 0..1

Allocation1

1

1

1

Heating

tank

Thermometer

Heater

These entities are the topic of interactions with the controller.

80


21/100

Example 3: Subject domain of ETS

See next slide.

These entities are the topic of interactions with the ETS.

Some of them are lexical entities to be stored in ETS.

81

Railway station

Rail segment

Route

Refund

1to 1from

1..*

Ticket

date of validity

class

price

train type

return or single

0..1

1

1

from

1

Account

number

balance

Bank

name

identifier

address

Account

holder

name

address

Ticket refund stamp

time

date

0..1

1

Ticket usage stamp

time

date

trip number

1

where

used

Payment

date

amount

11

1

where

aborted

1

1

82

Syntax and semantics of ERDs

Bank Railway station Ticket

Entity type.

Represented by a rectangle. Extension = All possible instances of entity type.

Extent = All existing instances of entity type. Intension = All properties shared by all possible instances. Defining intension = Properties used to define the entity

type. This is an abstraction (simplification) of the full,

informal meaning.

83

Attributes

Bank

name

identifier

address

Railway station

name

Ticket

date of validity

classprice

train type

Properties of entities. Can be listed in a compartment directly below the type name

compartment.

Question: Which properties of a railway station did we describe inthis diagram?

84


22/100

Relationships

A set of tuples of entities. Arity is the number of related entities. Binary, ternary, etc. Everything in the world is related to everything else!

We only describe a relationship if we want to express relativecardinality properties: How many entities of one type can existfor each entity of another type.

85

Binary relationships

E1 E2c1 c2

role1 role2R

Binary relationship represented by a line. Relationship name can have a read direction. Role names indicate the role an entity plays in a relationship. Relationship name and role names can all be omitted if this

does not lead to ambiguity.

86

Relationships of higher arity

E1

E2 E3R

c2

role2

c1role1

c3

role3

Relationships with arity 3 represented by a diamond. Name must be independent from direction of reading.

87

Cardinality properties: Elevator example

1111

doors cage

2 1

10

1cage

1 1

doors

1

1

20

Destination

button

0..2

1 current floor

10

Floor

2

Entry

sensor

2

Eleva-

tor

door

2

Motor

2

Location indicator

2

Elevator

cage

88


23/100

The meaning of cardinality properties

A snapshot of the subject domain is the state of the subjectdomain at one point in time.

Cardinaility properties are snapshot properties. An absolute cardinality property says how many instances of

an entity can exist in a snapshot.

A relative cardinality property says how many entities canexist relative to some existing entity.

To find a cardinality property, imagine looking at an arbitrary state

of the domain and ask how many instances of some entity type can

exist in that state.

89

First example of inconsistent cardinality

properties

1 1

doors3

Entry sensor

2

Elevator door

90

Second example of inconsistent cardinalityproperties

2Account

1

0..1

Refund

Payment

1

from

For p: Payment,

p. from = p . refund. account

91

Ternary relationships

Teacher

Course

RoomCourseoffering0..1 1..*

Cardinality properties of relationships with arity /geq3 are hard to

understand.

Questions

1. Can a course have more than one teacher?

2. Can a teacher give several courses?

92


24/100

Association entities

Juice specification

name

percentage of solids

Recipe

name

desired temperature

duration

Mixture

percentage of juice

1..*

An association entity is a relationship with attributes. Each instance is really a relationship. It is identified by a tuple

of component identifiers.

93

Generalization

Heating tank Storage tank

Tank

tank ID

volume

Heater

Thermometer

Characteristic of specialization:

Instance of a subtype is instance of a supertype.

94

Dynamic versus static specialization

Tank

Heating

tank

Storage

tank

dc

Tank

Heating

tank

Storage

tank

dc

Static specialization:

Subtype extensions aredisjoint and cover

supertype extension.

Dynamic

specialization: Subtypeextents are disjoint and

cover supertype extent.

NB. If any heating tank can become a storage tank and vice versa,

then all three extensions are equal! Why?

95

Main points

We make an ERD of the subject domain, not of databases.Even virtual entities are interesting only because they are part of

the subject domain.

ERD represents identification and classification of entities; andcardinality properties.

Counting and classification are closely related. Class (= type)

provides identification criterion.

Classification can be static or dynamic.

96


25/100

Questions

Recipe

name

desired temperature

duration

Batch

batchID

amount1*1..2 0..1

Allocation

1

1

1

1

Heating

tank

Thermometer

Heater

Suppose we interpret cardinalities historically: the number ofinstances related to in a lifetime. Change the cardinalities to

historical ones.

97

Gadgets

Warehouse CustomerDelivery

storage

If w: Warehouse and g: Gadgets

are related by Delivery,

then w = g.Storage

Gadgets

Warehouse Customer

storage

Delivery

Order

Are these diagrams equivalent? Beware of the connection trap.

98

Gadgets

Warehouse CustomerDelivery

storage

If w: Warehouse and g: Gadgets

are related by Delivery,then w = g.Storage

Gadgets

Warehouse Customer

storage

Delivery1

1

1

If d: Delivery, then

d . gadgets . storage = d. warehouse

Are these diagrams equivalent?

99

Chapter 9. ERD Modeling Guidelines

ERDs can be used to declare any set of entity types and theircardinality properties.

In this course we use ERDs only to represent the structure ofthe subject domain.

Guidelines to determine the boundary of the subject domainare relevant for this kind of use of ERDs only.

All the other guidelines are relevant for all possible uses ofERDs.

100


26/100

Subject domain boundary

The subject domain consists of entities and events. To find the

boundary:Roughly: What entities and events do the service descriptions

refer to?More precisely: What are the messages entering and leaving

the system about?Look for

Physical bodies

Devices

(Parts of) organizations

Conceptual entities

Lexical items

and events in their life.Entities and events should be identifiable by the SuD.

101

Unobservable events

Elevator

controllerButton

closepush

decide to take the elevator,

decide to take the stairs

Connection between events of interest (decisions by passenger) and

stimuli of controller are too weak to include passenger in subject

domain.

102

Including unobservable entities in a diagram ofexternal communications

Elevator controller

Request

buttonMotor Doors

SuD

Subject

domain

Passenger

Arrival

sensor

Direction

indicator

The subject domain contains devices with whom and aboutwhom the elevator controller exchanges messages.

However, we can include unobservable entities in a diagramthat shows external communication channels (the context

diagram).

103

Questions

Which entities are in the subject domain of a railway travelplanner?

Passenger, Station, Railway track, Trip segment, Route. Is a Passenger part of the subject domain of the Electronic

Ticket System? Why (not)?

The answers are determined by

(1) desired functionality of system and

(2) choices in connection technology.

104


27/100

Entities versus attributes

Entities are the things that the system talks about.

Attributes are the things said about entities.

So if you want to store information about it, it is an entity.

If information about it can change, it is an entity.

105

Example

Person

name

passport number

Person

name

Passport

date issued

number1 0..1

Counting persons is not the same as counting passports. Persons are not created at the same time as passports.So they are different entities. But which ERD is correct? That

depends:

If the SuD must be able to talk about persons withoutpassports, or

about persons with multiple passports (change cardinalityproperty for that),

then we must include a separate passport entity type.

106

Entities versus relationships

Relationships are identified by their components.So they are counted differently from the way entities are

counted.

Document Member0..1

Loan

date Document

Member

Loan

date

0..1

1

1

Several loans may co-exist!

Not what we intend

107

Taxonomic structures

Use a specialization attribute.

Vehicle

medium: {ground, air, water}

dc

Boat

{medium = water}

Aircraft

{medium = air}

Car

{medium = ground}

Any subtypes missing?

Do we need these subtypes?

108


28/100

Static versus dynamic specialization

Vehicle

Car Airplane

dc

Tank

Heating tank Storage tank

dc

According to this ERD, if you are born as a car, you are always a

car. But heating tanks can become storage tanks and vice versa.

Creating a static subtype instance is creating a supertype

instance.

Creating a dynamic subtype instance may not involve creating

a supertype instance.

109

Classification and identification

A type definition should provide a recognition criterion and an

identification criterion.

The recognition criterion for Car gives us the answer to this

question Is this a car?

The identification criterion gives us the answer to the

question How many cars do we have here?

To find the identification criterion of type C, it is often useful

to look at the creation event of an instance of C.

110

Questions

Give recognition and identification criteria for the following

concepts:

Person Company Passenger Elevator button

Your PC

The chair you are sitting on.If an instance of C is in the subject domain, then the SuD is able to

talk about a C, and so the SuD should be able to recognize and

identify Cs!

111

Subtypes versus roles

If an entity can play several roles of the same type, we can turn the

role into an entity type.

Companyemployee Person

name

Company

1

Person

name

Employee

employee nr 1

role player

112


29/100

What is the difference between these two models?

PersonEmployeeCompany1

Company

1

Person

name

Employee

employee nr 1

role player

113

Validation of an ERD (1)

Check consistency of cardinality properties.

Elevator

cage

Destination

button

Floor

1

10

21

2

1

currentfloor

2

If a diagram is not consistent, it cannot represent any subject

domain.

114


Railway station

Rail segment

Route

1to 1from

1..*

Ticket

date of validity

class

price

Ticket refund stamp

time

date

0..1

1

Ticket usage stamp

time

date

trip number

1

where

used

1

where

aborted

1

1

Are all loops commutative (any starting / destination node)?

115


Describe by elementary sentences and show to domain

specialist.

At each moment:

A batch of juice has exactly one recipe.

A recipe may be applicable to any number of batches.

At any point in time, a heating tank has at most one batch

allocated to it.

At any point in time, a batch is allocated to either 1 or 2 heating

tanks.

Each heating tank has exactly one heater.

etcetera.

116


30/100


Describe snapshot and show to domain specialist.

Ticket Route SegmentUsage

stamp

Refund

stamp

(t1, April 2)

Return

Enschede-

Apeldoorn

Enschede-

ApeldoornMarch 31 None

(t1, April 2)

Return

Enschede-

Apeldoorn

Apeldoorn-

EnschedeApril 1 April 1

Flaws in the model: Ticket cannot be used before bought!

No usage and refund for the same segment!

Return must be on the same day!

These are subject domain properties.

117


Check against messages entering and leaving the system.

Or against service descriptions:

Name: Sell a ticket.

Triggering event: Traveler requests to buy a ticket. Delivered service: Allow a traveler to buy a ticket at any

time and place chosen by the traveler.

Name: Show a ticket. Triggering event: Traveler requests to view a ticket. Delivered service: Display ticket attributes to the user.

Why is Traveler not an entity in the subject domain?

118

Main points

Subject domain bounded by the topic of the conversation with

SuD.

Entities have contingent properties, attributes do not. Relationships are identified by their components. Use specialization attribute. Static and dynamic specializations are distinguished by what

happens at creation time.

Classification and identification closely connected. Roles can be reified to entity types. Validate your ERD: consistency, elementary sentences,

snapshots, check against interface of SuD.

119

Chapter appendix (slides only): describinghistories and events in an ERD

120


31/100

Histories

Person

blood type

Date

Person snapshot

name

weight

Fixed attributes in the Person type box. Date-dependent attributes in an associative entity which

represents the person at a certain date.

121

Events

DocumentBorrow

Person

Borrow is an event. An instance of Borrow exists for one moment only.

122

DocumentPerson Borrow

Date

Borrow is a dated event. An instance of Borrow represents the fact that at a certain

date, a person borrowed a certain document. An instance of Borrow has identifier (p, dt, dc). We can include a time indication in the date too.

123

DocumentPerson

Date

Borrow

due date

Now Borrow has an attribute.

124


32/100

DocumentPerson date

Borrow

due date

Convention that abbreviates the diagram on the previous slide.

125

Chapter 10. The Dictionary

The dictionary documents the meaning of important terms:

Words used in service descriptions Words used in messages that cross the external SuD interface Domain-specific jargon etc.

The subject domain ERD is a visual supplement to the dictionary,

that adds some precision to terms that refer to subject domain

entities.

In our dictionary, we use only a few syntactic categories of terms,

that are motivated by our domain ontology.

126

Domain ontology Domain is part of the world treated as a whole. Ontology is a metaclassification.

Individual Property

Enti ty Event occurrence Entity type Relationship Attribute

State

dc d

127

Individuals are entities and event occurrences

Entity type

Entity

Event

Event occurrence

Timed event occurrence

instance occurrence in the life of entities

occurrence at a particular time

1 1

1

Dated entity

1

No reincarnation of entities. Event occurrence can occur at many times.

sell(coffee, 0.2 l) is an occurrence of event sell and it can occur

at times 9:00, 9:02, etc.

128


33/100

Syntactic categories

Identifier. Unique proper name. Predicate name.

Entity type name.

Relationship name.

State predicate name. Boolean property.

Attribute name. Event name.

129

Definitions from the ETS specification

Railway station. Entity type. Entity used to bound rail segments. May

consist of platforms where passengers can enter or leave a train. Can

also be a mathematical point used to bound a segment. Examples: The

point where the line of rail passes the Dutch-German border; one can

buy a ticket to that point. Can also be a collection of physical stations.

Example, a ticket to Berlin U-Bahn is a ticket to any subway station

in Berlin.

Rail segment. Entity type. A shortest path between two Railway

stations. Segments are directed and are identified by the two stations

they connect. So all shortest paths through the rail network from A to

B are considered the same segment, called AB; and all shortest paths

from B to A are the same segment, called BA; and AB and BA are two

different segments.

Route. Entity type. A path through the rail network that consists of a

connected series of rail segments, where each segment occurs at mostonce in the route.

130

Definitions from an elevator control specification

planned direction(c: Elevator cage). Attribute. The preferred

direction in which c will depart after closing its doors. If there arerequests to be served higher and lower than the current floor of the

elevator cage, then it will depart in the planned direction.

Round trip time. The time in seconds for a single car trip around a

building from the time the cage doors open at the main terminal until

the doors reopen when the cage has returned to the main terminal floor

after its trip [Barney & dos Santos 1977].

Atfloor(b: Request button, c: Elevator cage). Predicate. c

.current floor = b.floor.

continue(c: Elevator cage). Action. Term is applicable only if c

.planned direction = none.

If c.planned direction = up then start up(c.motor).

If c.planned direction = down then start down(c.motor).

The motor of c is started in the planned direction of c.

131

Path expressions

Definitions may use path expressions, that refer to paths through

the ERD.

See section 10.3 for syntax of path expressions.

132


34/100

Extensional and intensional definitions

Extensional definitions list a few instances of the concept.Easy to give. But do not define an intension.

Intensional definition lists the defining properties shared byall instance of the concept.

Difficult to find.

Open-textured terms have no intensional definition.

Define these by giving a few examples, a sketch of the intent,and indicating the procedure if any that determines

whether an instances falls under the concept.

Examples: Boat, title, document, vehicle, house, elevator, ...

133

When to define a term

To clarify a term.

To indicate that the term is open-textured.

To indicate that we attach little meaning to it.

The term is absolutely obvious to all stakeholders but they

attach different meanings to it.

When not to define a term

To raise a cloud of obscurity. (Bad idea, but frequent practice.)

Definitions can also be found in technical documentation of

devices. Dont repeat these.

The term is absolutely obvious to all stakeholders and they

understand the same by it.

134

Definition by genus and difference

Without genus With genus

A compiler translates source code

into object code.

A compiler is a program that trans-

lates source code into object code.

A catamaran has two hulls.A catamaran is a boat with two

hulls.

A heating tank heats juice.

A heating tank is a tank with a

heater and thermometer in which

juice can be heated.

Joiners recently joined the com-pany.

A joiner is an employee that re-cently has joined the company.

A ticket represents the passengers

right to make a trip by train.

A ticket is a lexical item that repre-

sents the passengers right to make

a trip by train.

135

The genus provides the identification criterion of the entity

type.

The difference provides the recognition criterion of the entity

type.

136


35/100

Operational definitions

An operational definition of a term gives a procedure, that can befollowed by anyone, to determine whether or not the term is

correctly applied to a given case.

Heating tank. Entity type. A tank with a heater and thermometer

attached. The heater can be recognized by red, blue and black wires

leading up to it, and the thermometer by its rectangular shape.

This is a operational definition by genus and difference.

Round trip time. The time in seconds for a single car trip around a

building from the time the cage doors open at the main terminal until

the doors reopen when the cage has returned to the main terminal floor

after its trip.

Operational, but not as definition by genus and difference.

137

Abbreviations versus correspondence rules

Abbreviation reduces the meaning of a word to the meaningof other words defined in the same dictionary.

To determine whether an individual is an instance of the

defined concept, you do not need new observations but simply

look up words in the dictionary.

Correspondence rules relate a word to reality. The words inthe definition are not defined in the same dictionary.

To determine whether an individual is an instance of the

defined concept, you must make observations.

Which definitions in the examples given are abbreviations, and

which are correspondence rules?

138

Main points

The dictionary contains definitions of jargon, subject domainterms, and other important tersm needed to understand the

design specification.

We can structure definitions as a taxonomic hierarchy:definition by genus and difference.

Try to give operational definitions.

Distinguish abbreviations (no new phenomenon described)from correspondence rules (link words to reality).

139

Part IV. Behavior Notations

SuD


Services

Behavior

Communication

Services

Behavior

Communication

Services

Behavior

Communication

......

Composite

system

External

entity

External

entity

Services

Behavior

Communication

Services

Behavior

Communication

Services

Behavior

Communication

140


36/100

Road map of ways to find behavior descriptions ofthe SuD

Activities to be supported by SuD

Business goal

Goal

tree

Event-action list

(scenario)

Event-action list

(transactional)

Stimulus-response list

(scenario)


(transactional)

System purpose

System services

Solution goals

Function

refinement

tree

141

Example 1: Training Information System

We take the route through service descriptions to desired

environment behavior.

Download Joiners service description

Triggering event: Coordinator requests to download list of joiners from the personnel information system.

Delivered service: Download the list of people from thePersonnel Information System who have joined the company

since the previous training.

Assumptions: The data in the Personnel Information Sys-tem reflects the situation accurately with a time lag of not

more than one working day.

Declarative service description! Not a scenario.

142

Example 1: Desired event-action pairs

Now we give behavioral details.

Environment event Desired action

E1 Time to download list of

joiners

Personnel Information System

knows that list of joiners is

requested.

E2 Personnel Information System

sends list of joiners.

Coordinator knows that list has

been downloaded.

E3 System has been waiting for

list of joiners too long.

Coordinator knows that list has

not been downloaded.

The SuD is not mentioned here. We describe desired behavior in the itshape environment.

143

Example 1: Required stimulus-response behavior

StimulusCurrent system

stateResponse

Next system

state

Receive event

download list

of joiners fromcoordinator.

System

contains no list

of joiners.

send event

send me a list

of joiners to

personnelinformation

system.

System is

waiting for list

of joiners.

Receive list of

joiners.

System is

waiting for list

of joiners.

Confirm to

coordinator.

System

contains list of

joiners.

A timer times

out.

System is

waiting for list

of joiners.

Inform

coordinator of

problem.

System

contains no list

of joiners.

144


37/100

Example 1: Which steps did we take?

From desired system services we derived desired transactionalevent-action pairs in environment.

The service descriptions describe what is valuable to the

environment.

The event-action pairs operationalize this as desired

behavior in environment.

From event-action pairs we derive stimulus-response pairs at

the interface of the system. To make the SR pairs transactional, a system state is

introduced, which represents part of the environment state.

Compare our road map.

145

Example 2: Heating controller: Behavior to beenforced.

We start from a model of desired environment behavior.

Event Desired action

Operator

gives com-

mand to start

heating batch

b.

A heating process for the heating tanks of b is

started. If at the start of the process, tempera-

ture in a tank is too low, the heater of that tank

is switched on. When during the process, a tank

becomes 5 degrees Celsius warmer than the de-

sired temperature, its heater must be switched off.

When it becomes 5 degrees Celsius colder than the

desired temperature, its heater must be switched

on. When the heating process has lasted for the

duration of the recipe, heating must stop and the

operator must be notified of this fact.

146

Example 2: Same behavior in atomic transitions

EventSubject domain

state Desired action

E1 Operator gives com-

mand to start heating

batch b

Heaters of tanks of b that

are below recipe temper-

ature, are switched on.

E2 Temperature in tank

t rises 5 degrees above

recipe temperature

The juice in t is

being heated.

The heater of t is

switched off.


t falls 5 degrees below

recipe temperature

The juice in

t is n ot b eing

heated.

The heater of t is

switched on.

E4 The heating duration

has passed, counted since

the start of heating of b.

b is being

heated.

Heaters of b that are

on, are switched off.

Operator is informed.

147

Example 2: Same behavior described by twodiagrams

Not

pasteurized(b)

Pasteurizing(b)

start heating(b) /

start tanks(b)

after(b. duration) /

stop tanks(b),

inform operator

b: Batch

Pasteurized(b)

Not heating(t)

Heating(t)

too cold(t) /

switch on(t . heater)too hot(t) /

switch off(t. heater)

stop(t)

stop(t) /

switch off(t . heater)

t: Heating tank

148


38/100

Example 2: Definitions

start tanks(b: Batch). For each tank t of b, signal start(t). stop tanks(b: Batch). For each tank t of b, signal stop(t).

These supplement the diagram.

149

Example 2: Stimulus-response behavior thatenforces environment behavior

StimulusCurrent controller

stateDesired response

Next

state

S1 Operator gives

command to start

heating batch b

Not heating t and

not heating b.

Switch on heaters of

tanks with low tem-

perature.

Heating

t and b.

S2 Every 60 seconds.

Heating t and mea-

sured temp > desired

temp + 5

Controller switches

off the heater of t.

Heating

t.

Heating t and mea-

sured temp < desired

temp 5

Controller switches

on heater of t.

Heating

t.

S4 Recipe time since

the start of heating

of b has passed.

Heating b.

Switch off heaters

of b that are on.

Inform operator.

Not

heating

b.

150

Example 2: Questions

The behavior brought about by the SR pairs is not exactly the

same as the behavior that is desired.

What are the differences?

Why are these acceptable?

151

Example 2: Which steps did we take?

(Compare our roadmap)

Desired environment behavior was modeled by means of

non-atomic event-action pair.

This was decomposed into atomic event-action pairs. From this we derived desired system behavior as a set of

atomic stimulus-response pairs, that would approximately

bring about desired environment behavior.

152


39/100

Part IV: Main points

Behavior occurs in the environment and at all levels in thesystem.

Find required system behavior by Analyzing required system services or

modeling desired environment behavior.

Behavior can be described in tabular format or by diagrams.

153

Structure of part IV

State transition lists and tables

State transition diagrams Execution semantics Modeling and design guidelines

154

Chapter 11. State Transition Lists and Tables

Range from informal to formal Can be used at system level down to component or software

object level.

Different kinds of lists and tables: Event list


State transition table

Decision table

At system level, the lists are usually informal. At software object

level, they are usually formal.

155

The use of behavior descriptions

Behavior descriptions can be used to represent

Assumed environment behavior

Desired environment behavior

Required system behavior Required component behavior

You cannot tell how a behavior description is used by reading it.

Each behavior description must be supplemented by an indi-

cation of its intended use.

156


40/100

Event lists

List of event descriptions and, for each event, a description of its

effect.

Example: description of assumed device behavior.

light on(b). If b is not already in state On(b), then it entersstate On(b). Otherwise, nothing changes.

light off(b). If b is not already in state Off(b), then it entersstate Off(b). Otherwise, nothing changes.

157

Example event list: desired subject domainbehavior

Event Desired action

Operator

gives com-

mand to start

heating batch

b.

A heating process for the heating tanks of b is

started. If at the start of the process, tempera-

ture in a tank is too low, the heater of that tank

is switched on. When during the process, a tank

becomes 5 degrees Celsius warmer than the de-

sired temperature, its heater must be switched off.

When it becomes 5 degrees Celsius colder than the

desired temperature, its heater must be switched

on. When the heating process has lasted for the

duration of the recipe, heating must stop and the

operator must be notified of this fact.

158

Example state transition table: Desired subjectdomain behavior

Event Subject domainstate

Desired action

E1 Operator gives com-

mand to start heating

batch b

Heaters of tanks of b that

are below recipe temper-

ature, are switched on.


t rises 5 degrees above

recipe temperature

The juice in t is

being heated.

The heater of t is

switched off.


t falls 5 degrees belowrecipe temperature

The juice in t is

being heated.

The heater of t is

switched on.

E4 The heating duration

has passed, counted since

the start of heating of b.

b is being

heated.

Heaters of b that are

on, are switched off.

Operator is informed.

159

Effect descriptions

Transactional. Description of one state transition. Intermediate states abstracted away (i.e., atomic).

Passage of time abstracted away (instantaneous).

Scenario. Description of several state transitions, with intermediate

states (i.e. not atomic).

Progress of time.

To transform a scenario description into a transactional list, we

need to introduce states.

160


41/100

State transition tables (STTs)

List of transactional entries of the form (event, current state,

actions, next state).

Variables are local to one entry. Bound in the left-hand side.

StimulusCurrent con-

troller state

Controller re-

sponse

Next con-

troller state

pass doors(c) Opened(c) Opened(c)

Closing(c) open do ors(c) Opened(c)

10 seconds af-ter the most re-

cent execution

of c .state :=

Opened

Opened(c) close doors(c) Closing(c)

161

Adding an initial state and initialization action

Initially close doors(c) Closing(c)

StimulusCurrent con-

troller state

Controller re-

sponse

Next controller

state

pass doors(c) Opened(c) Opened(c)

Closing(c) open do ors(c) Opened(c)

10 seconds af-

ter the most re-

cent execution

of c .state :=

Opened

Opened(c) close do ors(c) Closing(c)

162

Transformation table: no state change

Event Current state Action

arrive(b, c)Destination request(b, c)

and Atfloor(b, c)

stop motor(b, c)

open doors(c)

light off(b)

Forward request(b, c)

and Atfloor(b, c)

stop motor(b, c)

open doors(c)

light off(b)

show direction(c)

Ou termost reverse

request(b, c) and At-

floor(b, c)

stop motor(b, c)

open doors(c)

light off(b)

reverse and show di-

rection(c)

163

Transformation table = Decision tablebd, bf, br: Request button

c: Elevator cage

Destination request(bd, c) and Atfloor(bd,

c)T F T F T

Forward request(bf, c) and Atfloor(bf, c) F T T F F

Outermost reverse request(br, c) and At-

floor(br, c) F - - T T

stop motor(c) X X X X X

open doors(c) X X X X X

show direction(c) X X X

reverse and show direction(c) X X

light off(bd) X X X

light off(bf) X X

light off(br) X X

164


42/100

An STT with next states but without actions

Current button

stateEvent Next button state

On(b) light off(b) Off(b)

light on(b) On(b)

Off(b) light on(b) On(b)

light off(b) Off(b)

165

Main points

Tabular behavior descriptions range from informal (event list)to formal (state transition table).

Can be used for assumed or desired behavior of environment orsystem. List entry can describe a transition or a scenario. Variables can be declared for a table; binding is local to one

entry.

Stateless transition is really decision rule.

166

Chapter 12. State Transition Diagrams

Good at showing the structure of behavior. Not good at showing unstructured behavior. Can only show a limite amount of information because

restricted to one sheet of paper.

Tables and lists on the other hand can show unlimited amounts

of information, because they can continue on any number ofsheets.

167

Mealy diagram constructs

S1

/ aInitialization actions a, initial

state S1.

S2 S3

e [g] /a Trigger e, guard g, actions a.

S4 S5[g] / a

Take transition when g be-

comes true, or immediately.

S6 S7

/ a Take transition immediately.

S8e [g] /a Transition to final state.

168


43/100

Example

Not

HeatingHeating

check temp [Too low] /

switch on

check temp [Too high] /

switch offwhen(4 p.m.) /

finished

when(4 p.m.) /

switch off, finished

/ switch on

169

Events

An event is a discrete change in the condition of the world.

Named events. We gave a name to it. Condition change event. A Boolean condition g becomes

true.

Temporal event. Significant moment in time. Relativetemporal event: after(t), absolute temporal event: when(t).

170

Decision states

S0

e / aS1

S2

S3

[g] / b

[not g] / c

If g is not affected by a, this can be replaced by:

S0

S2

S3

e [g] / a; b

e [not g] / a; c

171

Variables

Not

HeatingHeating

receive temp(t) [t < d - 5] /

switch on

receive temp(t) [t > d + 5] /switch off

d, t: Rational

e: Time

when(e) / finishedwhen(e) /switch off, finished

/ switch on

Interface of this machine:

Heating

control

receive temp(t)

t

d

switch on

switch off

finished

e

172


44/100

Locality

Variables are local to a transition, except the identifier variable of a

diagram.

Not

Heating(h)Heating(h)


switch on(h)

receive temp(t) [t > d + 5] /

switch off(h)

d, t: Rational

e: Time

h: Heater

when(e) /

finished(h)when(e) /

switch off(h),

finished(h)

/ switch on(h)

173

Statecharts

Mealy diagrams plus

State reactions State hierarchy Parallelism

174

State reactions

Ready to sell

Acquiring route and ticket information

Ticket sale offered

traveller requests to buy ticket /

ask for information

traveller selects route / set route

traveller selects ticket type / set ticket type

[route and ticket type set] /offer to sell ticket

Saves space in diagram.

175

Example state reactions

S1

S2entry / a

e / b

exit / c

f /g / d

What happens when g occurs?

176


45/100

Conflict between state reaction and transition

S1S2

e / a

e [g] / b

What happens when e occurs and g is true?

Depends upon the semantics given to the notation by the

analyst. All readers and authors of the diagram should use the same

semantics!

177

Hierarchy

Not

Heating

Heating


switch on

receive temp(t)

[t > d + 5] /

d, t: Rational

e: Time

when(e) /

finishedexit /

switch off

Monitoring

/ switch on

178

Conflicts between transitions at different levels

S1 S2

e / bS3

e / aS0

What happens when e occurs?

UML: The lower transition is taken.

Statemate: The higher transition is taken.

UML views lower-level behavior as specialization. Statemate sees

higher-level behavior as more important, used e.g. to describe

interrupts and error-handling.

179

Parallelism

Not

Heating

Heating


switch on

receive temp(t)

[t > d + 5] /

d: Rational

e: Time

when(e) /

finishedexit /

switch off

Monitoring heat

Watchpressure

[pressure > max] /

alarm

Monitoring heating tank

Monitoring

pressure

/ switch on

180


46/100

Hyperedges

B11 B12

B21 B22

A C

B

B1

B2

ef

181

Breaking orthogonality by the in(State) predicate

Hi

Lo

p p

B1 B6push(1) [in(Hi)] / select 7

push(1) [in(Lo)] / select 1

push(6) [in(Hi)] / select 12

push(6) [in(Lo)] / select 6...

Channel selection

Range

selectButton 1 selection Button 6 selection

Now the behavior in one state depends upon the state of some

parallel component.

182

Breaking orthogonality by event broadcasting

Red

Yellow

Green

Red

Yellow

Green

after(5 secs) /

after(30 secs) /

after(5 secs) /

start NS

after(30secs) /

NS EW

Preparing

for green

Preparing

for green

start

NS /

after(5 secs) /

entry /

start EW

start

EW /

after(5 secs) /

Traffic light behavior

Now the behavior of one state depends upon events generated in

some parallel component.

183

Main points

STDs graphically represent reactive behavior, which consists ofa discrete state space and e [g] / a transitions.

Events can be named, condition change, or temporal.

Decision states are unstable. STDs can have local variables. Only the identifier variable is

global to the diagram.

Statecharts extend Mealy diagrams with state reactions, statehierarchy, parallelism.

The semantics of a diagram must be defined explicitly (seechapter 13).

184


47/100

Questions

Hi Lo

flipy [x = hot] /flipx [x = hot] / x := cold

flipx [x = cold] / x:= hotflipy [ x = hot]

x: {hot, cold}

Eliminate the variables as follows: Define two parallelcomponents, one component for each variable.

Is the resulting behavior equivalent to this one?

185

Solution

Hi

Lo

Hot

Cold

X Y

flipy [in(Hot)] flipy [in(Hot)]flipx(in(Hi)] flipx(in(Hi)]

Two variables

The important semantic difference between this statechart and the

Mealy diagram is that the statechart can respond to a flipx and a

flipy event at the same time.

186

Question

Encode all state information in variables. The result should bean STD with one state only.

Is the result equivalent to the original STD?

187

Solution

x: {hot, cold}

y: {Hi, Lo}

Ready

to

update

flipx [x=Hot and y=Hi] /

x:= cold

flipy [x=Hot and y=Hi] /

y := Lo

flipy [x=Hot and y=Lo] /

y:= Hi

flipx [x=Cold and y=Hi] /

x:= hot

This diagram does not indicate the initial value of the variables.

188


48/100

Chapter 13. Behavioral Semantics

STTs and STDs are descriptions of behavior. But they can be interpreted in many ways! That is a problem:

Designers, builders and users think they agree ...

... but nevertheless expect different behavior to be

implemented.

To execute a specification, it must be unambiguous.

To generate code, different code generation tools must usethe same semantics.

In this chapter we review the relevant semantic choices.

189

Discretization

Off On

switch on /

switch off /

STDs and STTs are abstract, and therefore necessarily incomplete,

descriptions of continuous behavior.

Atomicity. Ignore intermediate states of each transition. Possibility. There are no slightly different events or states.

switch on is possible when Off etc.

Isolation. Whatever else happens, switch on in state Off leadsto state On, etc.

Durability. A state is stable until an event occurs thattriggers an outgoing transition.

190

Wait States and Activity States: Semantic options

An activity state has internal activity, a wait state has not.

B

e /

A1 A2

e/A

This creates the possibility for conflict: What happens when e

occurs? Options:

Deferred response.

Forced termination. Higher level has priority (Statemate).

Lower level has priority (UML).

191

Final states: Semantic options

Activity states create ambiguity for final state node. What

happens when final state is reached?

Global termination: bulls eye indicates that overall processterminates (Statemate).

Local termination: Activity terminates; wait until e occurs(UML).

192


49/100

Pre- and postconditions: Problems

Current state Event Action Next state

1 P(x) e(x, y) a(x, y) Q(x)

Does P(x) become false? Should Q(x) be false in initial state? We will treat state descriptions in an STT as preconditions

and postconditions, that constrain the current and next

state. So:

Q(x) can have any value in initial state.

P(x) can have any value in next state.

If you dont want this, write down truth value explicitly.

193

Pre and postconditions: Possible solutions


1 P(x) e(x, y) a(x, y) Q(x)

2 P(x) f(x, y) a(x, y), b(y) R(x)

What happens with R(x) in transition 1? Not specified. If we must write down truth values explicitly, table entries

become very large.

Derivation rules. E.g. Q(x) R(x). Part of domainknowledge or SuD spec.

Frame rule. If the transition rule and derivation rules do notimply that P changes, then it does not change.

194

Pre and postconditions in STTs and STDs


1 P(x) e(x, y) a(x, y) Q(x)

P(x) Q(x)e(x, y) / a(x, y)

Equivalent?

No: STDs come with the interpretation rule that Si Sj fori = j.

So P(x) Q(x) in the STD!

195

Interpretation rules for statecharts

Q(x)e(x, y) / a(x, y)

S(x)P1(x) P2(x)

P(x)

Use the following interpretation rules for statecharts:

For all x, P(x) not S(x). For all x, Q(x) S(x). For all x, P1(x) P(x). For all x, P2(x) P(x).

196


50/100

Triggering (1)

The first problem with triggering is how we interpret what the

diagram does not say.

Freezing Cool Warm Hot

start freezing

Can start freezing occur in state Hot?

Physically impossible: Contradicts the laws of nature.If this is what we mean, we should add this interpretation rule to

the diagram.

197

Triggering (2)

Definition:

switch on is the event that leads the system from Off to On.

Off On

switch on /

switch off /

What does this mean? Can switch on occur in state On?

Logically impossible: Contradicts the definition in thedictionary. Whatever happens in state On is not the switch on

event.

Logically possible: switch on is a certain physical event thatcan occur in many states. Update the dictionary with this.

Whatever we mean, add this to the diagram.

198

Triggering (3)

What happens if switch on does occur in state On?

Ignore: Respond as if the event did not occur.

Off On

switch on

switch offswitch off / switch on /

Inhibit: Make the event physically impossible.

OnOff

after(10)

push

push /

199

Triggering (4)

Unknown effect: The system breaks down. This is the fragilesemantics.

Off Onswitch on

switch off

switch off switch on

Make clear whether you agree on the ignore, inhibit, or fragile

semantics as default interpretation for the STDs and STTs in a

specification.

200


51/100

Triggering multiple transitions: The problem

Current state Event Action Next state1 P(x) e(x, y) a(x, y) Q(x)

4 R(y) e(y, z) b(y) R(z)

5 R(x) e(x, y) c(x)P(x)and not

Q(x)

Suppose e(2, 4) occurs. Entries are instantiated as:

t1 P(2) e(2, 4) a(2, 4) Q(2)

t4 R(2) e(2, 4) b(4) R(4)

t5 R(2) e(2, 4) c(2)P(2) and not

Q(2)

Suppose P(2) and R(2) are true. What happens?

201

Triggering multiple transitions: Possible solutions

Step semantics. Execute as many transitions as possible inone step. (Statemate and UML multi-threaded semantics)

Two possible steps:

e(2, 4) / a(2, 4)e(2, 4) / a(2, 4), c(2)

Step 1= {t1, t4}Step 2 = {t4, t5}

P(2) and R(2)

P(2) and R(2)

not P(2) and

Q(2) and R(2)

Single-transition semantics. Choose one transitionnon-deterministically. Forget about the others. (UML

single-threaded semantics)

202

Responding to multiple events: The problem andpossible solutions

Suppose e(3, 4) and f(3, 4) occur at the same time. What happens?

t1 P(3) e(3, 4) a(3, 4) Q(3)

t2 P(3) f(3, 4) a(3, 4) R(3)

Concurrent-event semantics. Respond to all events not yetresponded to. (Statemate)

Sequential-event semantics. Respond to events in somesequence. (UML)

203

Multistep semantics: The problem

One transition can trigger further transitions. E.g. suppose f(3, 4)

happens in state P(3):

t2 P(3) f(3, 4) a(3, 4), b(4) R(3)

Action a(3, 4) in turn triggers an instance of entry 3:

t3 R(3) a(3, 4) b(3)P(3) and not

R(3)

What happens?

204


52/100

Multistep semantics: Possible solutions Single step semantics. After each step, the behavior can

respond to external as well as internally generated events.

(Statemate option)

Superstep semantics. The behavior first performs thecomplete multistep response before it is able to respond to

external events. (Statemate option)

Delayed step semantics. The behavior responds to internaland external events in some later step. (UML)

205

Action semantics

How is a complex action such as a, b, c executed?

Concurrent action semantics. The actions in a complexaction s are all executed simultaneously. (Statemate)

Sequential action semantics. The actions are executed in

some sequence. (UML)What if a UML action is an operation call?

P(3)

P(3) and

not R(3)

t2: f(3, 4) / a(3, 4)R(3)

t3: a(3, 4) / b(3)R(3)

t2: b(4)......

206

TimeA time point is a time inte

Documents

Slides Handout