1. Event driven architectures
Spring 2017
(c) Ian Davis

2. Pattern: Event Driven Context Problem Forces
Events cause further events
Problem
N2 pairings of events with future events
Forces
Must perform events as and when they occur
Want to ignore relationship between events
Asynchronous behaviour model
Parallelism
Spring 2017
(c) Ian Davis

3. Event driven logic
The logic is essentially reversed so that the detail is performed at the highest level.
The decision as to what detail must be performed next is kept in a static or dynamic table, or message queue.
Communication is via event generation.
Useful when we are required to “return” from code, but don’t wish to leave it.
(c) Ian Davis
Spring 2017

4. Event driven examples Code called as events occur (e.g. mouse)
Barber shop simulation.
After creating an initial future event, events themselves introduce additional future events.
Servers which chit chat with clients.
AJAX
Windows O/S
State machines
(c) Ian Davis
Spring 2017

5. Co-routines
The whole is bigger than the parts, but the parts cannot easily be decomposed into sequential or layered operations.
Separate parts must communicate with each other without loosing stack state.
Parts may run in separate threads. Architecture uses tightly coupled messages, branching or language to produce the desired computation.
(c) Ian Davis
Spring 2017

6. Co-routine example (In above example could be implemented by a goto)
(c) Ian Davis
Spring 2017

7. Supported in Python
Spring 2017
(c) Ian Davis

8. Table driven architectures
Spring 2017
(c) Ian Davis

9. Table driven logic
The logic is essentially governed by tables or data structures which are precomputed and then compiled into the code.
Useful when we wish to reduce the run time complexity of the code by precomputing its appropriate behaviour in data inserted into the code at compile time.
Improves performance of system.
Makes some challenges easy to solve.
(c) Ian Davis
Spring 2017

10. Table driven examples Yacc Cribbage game
Tables are generated which determine how parsing is to be performed.
Cribbage game
Expected value of cribbage hands precomputed.
Probability cumulative functions
Implemented by generating static tables
Perhaps using Monte Carlo simulation
Random forests
(c) Ian Davis
Spring 2017

11. Table driven pros&cons
Can produce clean solutions to seemingly difficult problems
Can be hard to grasp what is going on since the data generated can appear meaningless.
Some programmers have difficulty making the transition from conventional code to table driven code.
Hard to debug (if one ever needs to)
(c) Ian Davis
Spring 2017

12. Interpreter Architecture (Virtual Machines)
Spring 2017
(c) Ian Davis

13. Interpreter Style
Suitable for applications in which the most appropriate language or machine for executing the solution is not directly available.
Interpreter language says what must do
Interpreter implements how to do it
Preserves high level semantics in code
(c) Ian Davis
Spring 2017

14. Interpreter Style (Cont’d)
Components: include one state machine for the execution engine and three memories:
current state of the execution engine
program being interpreted
current state of the program being interpreted
Connectors:
procedure calls
direct memory accesses.
(c) Ian Davis
Spring 2017

15. Interpreter Style (Cont’d)
(c) Ian Davis
Spring 2017

16. Interpreter Style Examples
Programming Language Compilers:
Java, Dex
Smalltalk
Rule Based Systems:
Prolog
Coral
Scripting Languages:
Awk, Perl, JavaScript
(c) Ian Davis
Spring 2017