Finite Automata

• Two types – both describe what are called regular languages – Deterministic (DFA) – There is a fixed number of states and we can only be in one state at a time – Nondeterministic (NFA) –There is a fixed number of states but we can be in multiple states at one time

• While NFA’s are more expressive than DFA’s, we will see that adding nondeterminism does not let us define any language that cannot be defined by a DFA. • One way to think of this is we might write a program using a NFA, but then when it is “compiled” we turn the NFA into an equivalent DFA.

1

Informal Example

• Customer shopping at a store with an electronic transaction with the bank – The customer may pay the e-money or cancel the emoney at any time. – The store may ship goods and redeem the electronic money with the bank. – The bank may transfer any redeemed money to a different party, say the store.

• Can model this problem with three automata

Bank Automata

Actions in bold are initiated by the entity. Otherwise, the actions are initiated by someone else and received by the specified automata Start pay

a

b

ship

redeem ship redeem

d e 2

transfer

f

ship

Store

Cancel

c

transfer

g

Pay

Cancel

1

Redeem

3

Transfer

4

Start

Start

Customer

Bank

2

Ignoring Actions

• The automata only describes actions of interest

– To be more precise, with a DFA (deterministic finite automaton) we should specify arcs for all possible inputs. – E.g., what should the customer automaton do if it receives a “redeem”? – What should the bank do if it is in state 2 and receives a “redeem”?

• The typical behavior if we receive an unspecified action is for the automaton to die. – The automaton enters no state at all, and further action by the automaton would be ignored. – The best method though is to specify a state for all behaviors, as indicated as follows for the bank automaton.

Complete Bank Automaton

Redeem, Transfer, Pay, Ship, Cancel

2

Cancel Transfer, Pay, Ship

Redeem, Pay, Ship, Cancel

Redeem, Transfer, Pay, Ship, Cancel

1

Redeem

3

Transfer

4

Start

Bank Ignores other actions that may be received

3

Entire System as Automaton

• • • When there are multiple automata for a system, it is useful to incorporate all of the automata into a single one so that we can better understand the interaction. Called the product automaton. The product automaton creates a new state for all possible states of each automaton. Since the customer automaton only has one state, we only need to consider the pair of states between the bank and the store.

– For example, we start in state (a,1) where the store is in its start state, and the bank is in its start state. From there we can move to states (a,2) if the bank receives a cancel, or state (b,1) if the store receives a pay.

•

To construct the product automaton, we run the bank and store automaton “in parallel” using all possible inputs and creating an edge on the product automaton to the corresponding set of states.

Product Automaton

start

a

P C C

b

S C

c

d

e

f

g

1 2 3 4

R S

P R S T T S

4

Product Automaton

• How is this useful? It can help validate our protocol. • It tells us that not all states are reachable from the start state.

– For example, we should never be in state (g,1) where we have shipped and transferred cash, but the bank is still waiting for a redeem.

• It allows us to see if potential errors can occur.

– We can reach state (c, 2). This is problematic because it allows a product to be shipped but the money has not been transferred to the store. – In contrast, we can see that if we reach state (d, 3) or (e, 3) then the store should be okay – a transfer from the bank must occur • assuming the bank automaton doesn’t “die” which is why it is useful to add arcs for all possible inputs to complete the automaton

Simple...