TEXTUAL DIALOG NOTATIONS

• Formal grammars have been used as a dialog

notation.
• BNF (Backus–Naur Form) is widely used to
describe programming language syntax
• BNF has two connectives to denote sequence
and choice.
– use of ‘+’ as a symbol for sequence.
– | is for choice
• Terminals
– lowest level of user behaviour
– e.g. CLICK-MOUSE, MOVE-MOUSE
• Nonterminals
– ordering of terminals
– higher level of abstraction
– e.g. select-menu, position-mouse
• polyline drawing – Regular expression
select-line click click* double-click
– low-level terms select-line, click and double-click – defined
elsewhere (Assume).
– iteration, denoted by the Kleene star operator ‘*’.
– This says that you must select the line option from the menu,
click somewhere with the mouse, then click as many times as
you like on intermediate points, and finally double click.
 BNF - Example
• Basic syntax:
nonterminal ::= expression
• An expression – contains terminals and
nonterminals – combined in sequence (+) or as
alternatives (|)
draw line ::= select line + choose points + last point
select line ::= pos mouse + CLICK MOUSE
choose points ::= choose one | choose one + choose points
choose one ::= pos mouse + CLICK MOUSE
last point ::= pos mouse + DBL CLICK MOUSE
pos mouse ::= NULL | MOVE MOUSE+ pos mouse
represent in BNF
sentence ::= empty
| word sentence
| ‘(‘ sentence ’)’ sentence

• One advantage of using BNF or regular expressions is

that they are readily executed using existing tools.
• We have already mentioned the UNIX ‘yacc’ tool for
BNF;
• there is also a tool ‘lex’ for compiling regular expressions
 Production rules
• if condition then action - CCT
• These rules are represented in various forms, for
instance
condition → action
condition: action
• All rules are normally active and the system
constantly matches the condition part of the
rules against the user-initiated events which have
occurred and its own memory.
• When the conditions of a rule become true, the
rule is said to fire and the action part is
executed.
• The action may take the form of a response to
the user, or a change to the system’s memory.
• Note especially that the order in which the
rules are written is not important; any rule can
fire at any time, so long as its condition part is
true.
Event-oriented system - polyline drawing

Sel-line → start-line <highlight ‘line’>

C-point start-line → rest-line <rubber band on>
C-point rest-line → rest-line <draw line>
D-point rest-line → <draw line> <rubber band off>
• Events are of three types
– user events which begin in upper case
• Sel-line, C-point, D-point
– internal events which begin in lower case. These are
used by the dialog to keep track of the dialog state
• rest-line
– system response events, enclosed in angle brackets,
such as,
• <draw line> (visible/audiable events)
• All interaction with the user is mediated by this
event memory: user events, such as a mouse
click, are added to the memory, and system
responses, such as <draw line>, are removed
and acted upon by the display controller.
• When a rule fires, all the events named in the
condition are removed from the system’s
memory, and the events named in the action
are added to it.
• The event-oriented nature of these production rules
is evident in the way that events are removed from
memory if they are used in the condition of a rule.
• The event has been ‘dealt with’ and can therefore be
forgotten.
• Notice in the third rule how the event rest-line is
mentioned in both condition and action.
C-point rest-line → rest-line <draw line>
• It represents the state where additional points on the
line are being selected after the first point.
• The rule is fired by a single click, which means that
more points remain to be selected
• State-oriented production rules
– The system’s memory is a set of named values, but
these are not removed by default when a rule is
fired; instead they must be removed explicitly by
the action part of a rule.
– Some of the attributes are set as the result of user
actions, and others have an effect on the system’s
display
• Automatically set when the user performs the
relevant action
– Mouse: { mouse-off, select-line, click-point, double-
click }
• Used by the dialog to keep track of its state
– Line-state: { menu, start-line, rest-line }
• Controlling system responses
– Rubber-band: { rubber-band-off, rubber-band-on }
– Menu: { highlight-off, highlight-line, highlight-circle }
– Draw: { draw-nothing, draw-line }
• Propositional production system (PPS)
select-line → mouse-off start-line highlight-line
click-point start-line → mouse-off rest-line rubber-
band-on
click-point rest-line → mouse-off draw-line
double-click rest-line → mouse-off menu draw-line
rubber-band-off

Each rule has to reset the Mouse attribute explicitly

 Concurrent dialog elements
• Syntax – event/state
event: condition → action
• We have three attributes:
– Bold: { off, on }
– Italic: { off, on }
– Underline: { off, on }
• The six rules defining the dialog box are then
select-bold: Bold=off → Bold=on
select-bold: Bold=on → Bold=off
select-italic: Italic=off → Italic=on
select-italic: Italic=on → Italic=off
select-under: Underline=off → Underline=on
select-under: Underline=on → Underline=off
 CSP and event algebras
• STNs which are very good at handling sequential
dialog, but weak on concurrency.
• production rules – good at concurrency and
weak at sequential dialog
• The problem of dealing with both sequential
and concurrent behavior is common to many
other areas of computing,
– telecommunications protocols
– and concurrent programming
• Process algebras - formal notations which
have been developed to handle concurrency
and sequential process.
– CSP (Communicating Sequential Processes) - CSP
notation is used because it is able to specify
concurrency and sequence equally well, and
because of its readability
• drawing tool – STN
Draw-menu = ( select-circle? → Do-circle
[] select-line? → Do-line )
Do-circle = click? → set-center → click?
→ draw-circle → skip
Do-line = Start-line ; Rest-line
Start-line = click? → first-point → skip
Rest-line = ( click? → next-point → Rest-line
[] double-click? → last-point → skip )
• ? - user’s mouse actions
• the rest being internal system events.
• description is built using four symbols
– ‘=’ meaning definition
– ‘→’ event sequence (or guard)
– ‘;’ process sequence and
– [] choice
• The names in the dialog denote events (all lower
case) or processes (initial upper case).
• Toggles
Bold-toggle = select-bold? → bold-on
→ select-bold? → bold-off → Bold-toggle
Italic-toggle = select-italic? → italic-on
→ select-italic? → italic-off → Italic-toggle
Under-toggle = select-under? → under-on
→ select-under? → under-off → Under-toggle
• Parallel composition of the individual toggles:
Dialog-box = Bold-toggle || Italic-toggle || Under-toggle
• For a drawing tool, we may decide that we would like
to allow keyboard shortcuts activated by the Alt key
Mouse = ( select-circle? → int-sel-circle → Mouse [] select-
line? → int-sel-line → Mouse)
Keyboard = alt-key-down? → ( Alt ; Keyboard )
Alt = ( alt-key-up? → skip
[] c-key? → int-sel-circle → Alt
[] l-key? → int-sel-line → Alt )
• The three processes can now be run in
parallel:
Mouse || Keyboard || Draw-menu
 Dialog semantics
• notation-specific semantics – special-purpose
semantic forms designed as part of a dialog
notation;
• links to programming languages – attaching
pieces of programming language code to the
dialog;
• links to specification notations – similar, but
where a formal specification notation is used.
• Notation-specific semantics
– Augmented transition networks (ATNs) - the system is
assumed to hold a set of registers, storage locations
which the transition network can set and test.
– The arcs have a condition as well as the event.
– the condition can refer to the system’s registers and
the arc is only followed if the condition is true and the
event occurs.
Production rule:
click_at(x,y) → dot_at(x,y), call another_point(x,y)
• Links to programming languages
– input tool description consists of ‘tool’ definitions, including
regular expressions intermingled with normal C code
tool number
{
input { ( digit* + sign; digit; digit* ) ; return
}
tool digit
{ input { key:| key_c>=‘0’ && key_c<=‘9’ | }
tool sign
• Links to formal specification
Login = login-mess → get-name → Passwd
Passwd = passwd-mess → ( invalid → Login
[ ] valid → Session)
• Event clauses
event: login-mess =
prompt: true
out: “login:”
event: passwd-mess =
prompt: invis
out: “passwd:”
event: valid =
uses: input, user-id, passwd-db
when: passwd-id = passwd-db(user-id)
event: invalid =
uses: input, user-id, passwd-db
when: passwd-id ≠ passwd-db(user-id)
out: “Sorry bad user-id/password”
 Dialog Analysis and Design
• non-determinism reflects semantic decisions in the
system.
atm ::= put-in-card get-number
get-number ::= digit digit digit digit
get-money return-card atm
| digit digit digit digit return-card atm
| digit digit digit digit atm
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
get-money ::= ...