1. Architectural Approaches
Winter 2016
(c) Ian Davis

2. Hardware Architectures
Winter 2016
(c) Ian Davis

3. Hardware Architecture
RISC machines emphasize a small fast instruction set as an important feature.
Complex instructions are implemented using this simple fast set.
Pipelined and multi-processor machines emphasize the configuration of architectural pieces of the hardware, and the overlapped flow of instruction and operation.
Winter 2016
(c) Ian Davis

4. Hardware Architecture
Micro-coded machines employ a fast interpreter to translate from a rich end user instruction set, to the underlying instruction set. They can emulate many machine architectures.
Pentium incorporates all of the logic to perform dynamic memory allocation, page faults etc. within its hardware.
Winter 2016
(c) Ian Davis

5. Network Architectures
Winter 2016
(c) Ian Davis

6. Network Architecture
Networked architectures are achieved by abstracting the design elements of a network into nodes and connections.
Topology is the most emphasized aspect:
Star networks
Token ring networks
Ethernet
Unlike software architectures, in network architectures only few topologies interesting
(c) Ian Davis
Winter 2016

7. Network Architecture Synchronous versus asynchronous.
Unreliable versus reliable.
Re-use of software: eg: TCP/IP has TCP using the IP protocol to make unreliable communication, reliable.
Layered communications protocol.
ISO/OSI Ethernet Reference Model is a layered network architecture
(c) Ian Davis
Winter 2016

8. Data Flow Architecture
Winter 2016
(c) Ian Davis

9. Pattern: Pipes and Filters
Context
Data can arrive in different formats
Problem
Need to provide a series of ordered independent computations
Forces
Exploit existing programs / enforce data flow
Partition into step wise processes
Debug partitioned problem independently
Support parallelism
Winter 2016
(c) Ian Davis

10. Pipe and Filter Architecture
Pipelines: Restricts topologies to linear sequences of filters.
Batch Sequential: A degenerate case of a pipeline architecture where each filter processes all of its input data before producing any output.
(c) Ian Davis
Winter 2016

11. Pipe and Filter Examples
Unix Shell Scripts: Provides a notation for connecting Unix processes via pipes.
cat file | grep Erroll | wc -l
Traditional Compilers: Compilation phases are pipelined, though the phases are not always incremental. The phases in the pipeline include:
lexical analysis + parsing + semantic analysis + code generation
(c) Ian Davis
Winter 2016

12. Sequential batch processes
Winter 2016
(c) Ian Davis

13. Pipe and Filter Advantages
Easy to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters.
They support reuse, since any two filters can be hooked together, provided they agree on the data that is being transmitted between them.
(c) Ian Davis
Winter 2016

14. Pipe and Filter Advantages (Cont’d)
Systems can be easily maintained and enhanced, since new filters can be added to existing systems and old filters can be replaced by improved ones.
They permit certain kinds of specialized analysis, such as throughput and deadlock analysis.
The naturally support concurrent execution.
(c) Ian Davis
Winter 2016

15. Pipe and Filter Disadvantages
Not good for handling interactive systems, because of their transformational character.
Excessive parsing and unparsing leads to loss of performance and increased complexity in writing the filters themselves.
(c) Ian Davis
Winter 2016

16. Abstract Layer Architectures
Winter 2016
(c) Ian Davis

17. Pattern: Layer Context Problem Forces
Application has multiple layers of abstraction
Problem
Both high and low level issues to be addressed
Higher levels depends on lower levels
Forces
Localize changes to single components
Separate concerns into different components
Reusable logic easily accessible
Components cohesive but loosely coupled
Winter 2016
(c) Ian Davis

18. OSI/Ethernet Layers Physical - Wire, USB, Bluetooth, RS232 ...
Data Link – ATM, SDLC …
Network – IPv4, IPv6, AppleTalk …
Transport – UDP, TCP, DCCP …
Session – Named Pipe, SOCKETS, NetBios, …
Presentation – MIME, XDR, …
Application – Telnet, FTP, HTTP, NSF, SMTP
Winter 2016
(c) Ian Davis

19. Peer to Peer
Winter 2016
(c) Ian Davis

20. RFC3439
Layering of this type does have various conceptual and structuring advantages. However, in the data networking context structured layering implies that the functions of each layer are carried out completely before the protocol data unit is passed to the next layer. This means that the optimization of each layer has to be done separately. Such ordering constraints are in conflict with efficient implementation of data manipulation functions. One could accuse the layered model (e.g., TCP/IP and ISO OSI) of causing this conflict. In fact, the operations of multiplexing and segmentation both hide vital information that lower layers may need to optimize their performance. For example, layer N may duplicate lower level functionality, e.g., error recovery hop-hop versus end-to-end error recovery. In addition, different layers may need the same information (e.g., time stamp): layer N may need layer N-2 information
Winter 2016
(c) Ian Davis

21. Software Layer Architecture
Simple – divide and conquer
Clean – each layer is independent
Potential problems
Procedural implies tight binding of code
Synchronous (causes browser pause etc.)
Lack of hierarchical flow (eg. Co-routines)
Encapsulation denies access to important detail
Interrupts and Exceptions (violate hierarchy)
Winter 2016
(c) Ian Davis

22. The “Toaster” Model
(c) Ian Davis
Winter 2016

23. Layered Style Examples
Layered Communication Protocols:
Each layer provides a substrate for communication at some level of abstraction.
Lower levels define lower levels of interaction, the lowest level being hardware connections (physical layer).
Operating Systems
Unix
(c) Ian Davis
Winter 2016

24. Unix Layered Architecture
(c) Ian Davis
Winter 2016

25. Overlaid Layered Architecture
Dynamically load code as needed
Discard it when no longer needed
COBOL (Initial, mainline, final)
COM/OLE
Reference counting
Garbage collection
Winter 2016
(c) Ian Davis

26. Pattern: Microkernel (wrapper)
Context
Core functionality must deploy on different platforms
Problem
Connections to hardware / OS subject to change
Forces
Preserve abstraction rather than focus on detail
Minimise duplication of code
Encapsulate what may change so easier to change
Add low level functionality (eg. Detect memory leaks)
Share abstraction across all applications
Winter 2016
(c) Ian Davis

27. https://en.wikipedia.org/wiki/Microkernel
Winter 2016
(c) Ian Davis

28. Layered Style Advantages
Design: based on increasing levels of abstraction.
Enhancement: since changes to the function of one layer affects at most two other layers.
Reuse: since different implementations (with identical interfaces) of the same layer can be used interchangeably.
(c) Ian Davis
Winter 2016

29. Layered Style Disadvantages
Not all systems are easily structured in a layered fashion.
Performance requirements may force the coupling of high-level functions to their lower-level implementations.
Adding layers increases the risk of error.
Eg. getchar() doesn’t work correctly on Linux if the code is interrupted, but read() does.
(c) Ian Davis
Winter 2016

30. Implicit Invocation Architecture
Winter 2016
(c) Ian Davis

31. Implicit Invocation Model/View/Controller Publish/Subscriber
Data forms the Model
Controller changes the model
Controller announces to requesting views change
Publish/Subscriber
Publishes to topics
Subscribers listen to topics
Observer design pattern
Underlying implementation
Winter 2016
(c) Ian Davis

32. Pattern: Model View Controller
Context
Systems retrieve and display data in many formats
User interface may need new or altered views
Problem
Don’t want core application to be concerned with supporting the User Interface behaviour
Forces at work
User interface expected to evolve
Parallel tasks can be handled in different ways
Partition how things appear from how they change
Winter 2016
(c) Ian Davis

33. Model View Controller (MVC)
Winter 2016
(c) Ian Davis

34. Implicit Invocation Style
Suitable for applications that involve loosely-coupled collection of components, each of which carries out some operation and may in the process enable other operations.
A generalization of event driven code in which relevant state is included with the event, and multiple processes can “see” events.
(c) Ian Davis
Winter 2016

35. Implicit Invocation Style (Cont’d)
Instead of invoking a procedure directly ...
A component can announce (or broadcast) one or more events.
Other components in the system can register an interest in an event by associating a procedure with the event.
When an event is announced, the broadcasting system (connector) itself invokes all of the procedures that have been registered for the event.
(c) Ian Davis
Winter 2016

36. Implicit Invocation Style (Cont’d)
9/17/2018
Implicit Invocation Style (Cont’d)
An event announcement “implicitly” causes the invocation of procedures in other modules.
(c) Ian Davis
Winter 2016

37. Implicit Invocation Invariants
Announcers of events do not know which components will be affected by those events.
Components cannot make assumptions about what processing will occur as a result of their events (perhaps no component will respond).
Components cannot make assumptions about the order of processing.
(c) Ian Davis
Winter 2016

38. Implicit Invocation Specializations
Often connectors in an implicit invocation system also include the traditional procedure call in addition to the bindings between event announcements and procedure calls.
(c) Ian Davis
Winter 2016

39. Implicit Invocation Examples
Used in programming environments to integrate tools:
Debugger stops at a breakpoint and makes that announcement.
Editor responds to the announcement by scrolling to the appropriate source line of the program and highlighting that line.
LSEdit
(c) Ian Davis
Winter 2016

40. Implicit Invocation Examples (Cont’d)
Used to enforce integrity constraints in database management systems (called triggers).
Used in user interfaces to separate the presentation of data (views) from the applications that manage that data.
Used in user interfaces to allow correct mapping of function keys etc. to logic.
Used in forms to allow generic logic.
(c) Ian Davis
Winter 2016

41. Implicit Invocation Advantages
Provides strong support for reuse since any component can be introduced into a system simply by registering it for the events of that system.
Eases system evolution since components may be replaced by other components without affecting the interfaces of other components in the system.
Easy to add new views, etc.
(c) Ian Davis
Winter 2016

42. Implicit Invocation Advantages
Eases system development since one has to only map the events which occur to the software that manages them, and these events are often predefined.
Case tools hide the complexities of managing the flow of events.
Asynchronous interface improves performance, response times etc.
Parallelism?
(c) Ian Davis
Winter 2016

43. Implicit Invocation Disadvantages
When a component announces an event:
it has no idea what other components will respond to it,
it cannot rely on the order in which the responses are invoked,
it cannot know when responses are finished.
Feedback involves generating additional events that are routed to callback routines.
(c) Ian Davis
Winter 2016

44. Implicit Invocation Disadvantages
There is no single defined flow of logic within such systems.
It can be hard to consider all possible events that may occur, and their interactions.
Such systems can be very hard to both maintain and debug.
There is the risk that you end up communicating with “Trojan horses”.
(c) Ian Davis
Winter 2016

45. Event driven architectures
Winter 2016
(c) Ian Davis

46. 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
Winter 2016
(c) Ian Davis

47. 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
Winter 2016

48. 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
Winter 2016

49. 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
Winter 2016

50. Co-routine example (In above example could be implemented by a goto)
(c) Ian Davis
Winter 2016

51. Supported in Python
Winter 2016
(c) Ian Davis

52. Action Domain Responder
Stateful Request
JavaScript
Browser
Many scripts
PHP
SQL
HTML
Typical web development style
Winter 2016
(c) Ian Davis

53. Table driven architectures
Winter 2016
(c) Ian Davis

54. 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
Winter 2016

55. 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
Winter 2016

56. 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
Winter 2016

57. Interpreter Architecture (Virtual Machines)
Winter 2016
(c) Ian Davis

58. 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
Winter 2016

59. 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
Winter 2016

60. Interpreter Style (Cont’d)
(c) Ian Davis
Winter 2016

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

62. Interpreter Style Examples
Micro coded machine
Implement machine code in software.
Cash register / calculator
Emulate a clever machine using a cheap one.
Database plan
The database engine interprets the plan.
Presentation package
Display a graph, by operating on the graph.
(c) Ian Davis
Winter 2016

63. Interpreter Style Advantages
Simulation of non-implemented hardware, keeps cost of hardware affordable.
Facilitates portability of application or languages across a variety of platforms.
Behaviour of system defined by a custom language or data structure, making software easier to develop and understand.
Separates the how do we do this, from the how do we say what it is we want to do.
(c) Ian Davis
Winter 2016

64. Java Architecture
(c) Ian Davis
Winter 2016

65. Interpreter Style Disadvantages
Extra level of indirection slows down execution.
Java has an option to compile code.
JIT (Just In Time) compiler.
Can’t step outside language as interpreted
(c) Ian Davis
Winter 2016

66. Message Oriented Architectures
Winter 2016
(c) Ian Davis

67. Message Oriented Architecture
Client/Server
Peer to Peer
Publisher/Subscriber
Message Bus
Ajax (Synchronous/Asynchronous)
Mobile code
Eg. Javascript, Applets
Winter 2016
(c) Ian Davis

68. Client-Server Advantages
Distribution of data is straightforward.
Transparency of location.
Mix and match heterogeneous platforms.
Easy to add or upgrade servers.
Functional client server interface.
Simplifies distant levels of recursion.
One server can support multiple clients
(c) Ian Davis
Winter 2016

69. Client-Server Disadvantages
Security
No central register of names/services -- hard to find out what services are available
Hard to asynchronously communicate with server. Eg. cancel database query..
Server can’t initiate communication with clients. The best it can do is provide complex responses (callback) when its services are requested.
(c) Ian Davis
Winter 2016

70. Client-Server Disadvantages
Overhead of packing and unpacking data encoded in messages, particularly when client and server on same machine. (In good client-server implementations this problem is avoided).
Potential restrictions on the data types and structures that can be passed. Eg.__int64, unicode, etc.
Uncertain server lifetime
Unpredictable server load
(c) Ian Davis
Winter 2016

71. Broker Architecture Clients shouldn’t know how to reach Service
Offers additional Dynamic Services
For adding, removing, exchanging, activating and locating components as needed
Security may be enforced by brokers
Who can talk to what, and how
Broker may act as an adaptor (Bridge)
Load balancing, etc.
Winter 2016
(c) Ian Davis

72. RPCs Versus ORBs Handles security/adaptors/etc. (c) Ian Davis
Winter 2016

73. Message Bus Architecture
Context
N2 number of possible peer-peer connections
Problem
Need to reduce cost of adding new connections
Forces
Want to reduce application dependencies
Applications use different interfaces
Don’t want every application to know all interfaces
Winter 2016
(c) Ian Davis

74. Message Bus Solution All peers communicate with the bus
Bus has an agreed-upon message schema
Bus has a common set of command messages
Bus provides shared infrastructure
For managing peer-peer connections
For sending messages to recipients
Winter 2016
(c) Ian Davis

75. https://msdn.microsoft.com/en-us/library/ff647328.aspx Winter 2016
(c) Ian Davis

76. N-tier Architectures
Winter 2016
(c) Ian Davis

77. Multi tier Architecture
Winter 2016
(c) Ian Davis

78. Layered .v. Multi Tier Layered architecture Multi tier architecture
Architecture based on logical division
Multi tier architecture
Leverages Client Server
Architecture based on physical division
Architecture more dependent on infrastructure
Assume client has browser
Assume server running apache, etc.
Winter 2016
(c) Ian Davis

79. Multi-tier advantages
Code is located where most efficiently run
Scalability
Multiple clients can share one server
Multiple servers can share one data base
Multi-threading support
built in to Browsers, Apache and SQL
Leverages existing technology
Winter 2016
(c) Ian Davis

80. Multi tier Disadvantages
Communication overhead
Hard to perform regression testing etc.
Hard to debug
No single debugger can watch everything
Hard to interpret logs
Dependent on remote resources
More points of possible failure
Winter 2016
(c) Ian Davis

81. Data Centric Architecture
Winter 2016
(c) Ian Davis

82. Repository/Blackboard Style
Suitable for applications in which the central issue is establishing, augmenting, and maintaining a complex central body of information.
Typically the information must be manipulated in a variety of ways. Often long-term persistence is required.
(c) Ian Davis
Winter 2016

83. Repository Style (Cont’d)
Components:
A central data structure representing the correct state of the system.
A collection of independent components that operate on the central data structure.
Connectors:
Typically procedure calls or direct memory accesses.
(c) Ian Davis
Winter 2016

84. Repository Style (Cont’d)
(c) Ian Davis
Winter 2016

85. Repository Style Database Database is viewed as a server
SQL (Relational database)
OMDG (Object oriented database)
Database is viewed as a server
All requests performed by clients
Winter 2016
(c) Ian Davis

86. Blackboard Style Triggers External clients can be notified of changes
Invoke PL/SQL
External clients can be notified of changes
Implicit invocation
SQL3 promises to be computationally complete.
Winter 2016
(c) Ian Davis

87. Repository Style Specializations
Data structure in memory
Real time
Persistent but limited memory
Ipod Nano
Data structure on disk
SQL
Ipod Classic
Atomic Transactions
Concurrent computations and data accesses.
(c) Ian Davis
Winter 2016

88. Repository Style Examples
Information Systems
Programming Environments
Graphical Editors
AI Knowledge Bases
Ipod
Web (HTML data model)
Architecture nodes and links between them
(c) Ian Davis
Winter 2016

89. Repository Style Advantages
Efficient way to store data.
Sharing model is available as a schema
Centralized management:
backup
security
concurrency control
Ability to easily extend the data schema
Reliable (no need to test)
(c) Ian Davis
Winter 2016

90. Repository Style Disadvantages
Must agree on a data model a priori.
Partially addressed through views
Difficult to distribute data.
Partially addressed through distributed DB.
Data evolution is expensive.
Because much may have to be changed
Scalability (read once write everywhere)
Somewhat addressed by distributed DB
(c) Ian Davis
Winter 2016

91. DISTRIBUTED REPOSITORY
Winter 2016
(c) Ian Davis

92. Scalable Data Architectures
Vertical Scaling
Buy Faster CPU / More memory / Larger Disks
Horizontal Scaling
Buy more cheap servers
Parallelism
Routing
Winter 2016
(c) Ian Davis

93. Usage of Data On-line Transaction Processing (OLTP)
Large volumes of INSERT/UPDATE/DELETE
Simple SELECT statements (direct recovery)
Goal: Storage/Retrieval: Transactions Per Second
On-line Analytical Processing (OLAP)
Warehoused data (Extract / Transform / Load) (ETL)
Very complex operations on the data
Goal: Knowledge: Response time per query
Winter 2016
(c) Ian Davis

94. Winter 2016
(c) Ian Davis

95. Winter 2016
(c) Ian Davis

96. Star Schema https://en.wikipedia.org/wiki/Star_schema Winter 2016
(c) Ian Davis

97. Snowflake Schema https://en.wikipedia.org/wiki/Snowflake_schema
Winter 2016
(c) Ian Davis

98. RDBMS SQL systems Oracle DB2 MySQL SQL Server Etc. Etc. Winter 2016
(c) Ian Davis

99. Winter 2016
(c) Ian Davis

100. Apache Hadoop (NoSQL) Open Source Written in JAVA
Replication / Load Balance / multiple servers
Replicates code execution at each server
Map (Bit like SQL grouping)
Gets back results from every server
Merges results into a single deliverable
Reduce (MapReduce) to a desired deliverable
(Bit like SQL aggregation)
Winter 2016
(c) Ian Davis

101. Advantages/Disadvantages
Divide and Conquer (speeds massive data searches)
Highly parallel and scalable (execution on local data)
Reduced network traffic
Robust / Reentrant (node execution can be restarted)
Replication (use first past the post response)
Disadvantage
Have to write Map and Reduce Logic
Not focused on data structure, schema, indexes etc.
Still have to wait for all parallel activity to complete
Winter 2016
(c) Ian Davis

102. MongoDB (NoSQL) Distributed database system Object Oriented DB
Each record encodes Binary JSON
JSON is a way of describing nested structure/content
No Meta Schema
Employed by Java, Javascript, PhP, etc
Indexed searching supported
Replication / Load Balancing / Sharding
Winter 2016
(c) Ian Davis

103. Advantages / Disadvantages
Moving towards DB
Uses MapReduce like Hadoop
Disadvantages
Custom query language
Complexity of stored data structures
Not as flexible as RDBMS
No clear meta schema
Risk of storing erroneous data
Winter 2016
(c) Ian Davis

104. http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis Winter 2016
(c) Ian Davis

105. Other NoSQL systems Redis Cassandra ElasticSearch CouchDB Accumulo
Hbase
Hypertable
OrientDB
Neo4j
Etc. Etc. Etc.
Winter 2016
(c) Ian Davis

106. Other data mining strategies
Genetic Programming
Try to find random formula’s that signal something interesting
Gradient Descent
Construct a cost formula for how close answer is to desired answer (0 = perfect)
Find optimal parameterization
Regression – Fourier Transform
Prediction of future patterns
Winter 2016
(c) Ian Davis

107. Methodology Filter Train Validate Test Use
Clean up / sanitize the data (optional)
Train
Optimise logic on given set of data with given ground truth (achieve answer ~= ground truth)
Validate
Prove that not over-fitting or under-fitting by testing on a second data set (want to see similar accuracy)
Test
See if the results are good on a third data set
Use
Winter 2016
(c) Ian Davis

108. Horses for Courses
Winter 2016
(c) Ian Davis

109. Winter 2016
(c) Ian Davis

110. Process Control Architectures
Winter 2016
(c) Ian Davis

111. Process-Control Style
Suitable for applications whose purpose is to maintain specified properties of the outputs of the process at (sufficiently near) given reference values.
Components:
Process Definition includes mechanisms for manipulating some process variables.
Control Algorithm for deciding how to manipulate process variables.
(c) Ian Davis
Winter 2016

112. Process-Control Style (Cont’d)
Connectors: are the data flow relations for:
Process Variables:
Controlled variable whose value the system is intended to control.
Input variable that measures an input to the process.
Manipulated variable whose value can be changed by the controller.
Set Point is the desired value for a controlled variable.
Sensors to obtain values of process variables pertinent to control.
(c) Ian Davis
Winter 2016

113. Feed-Back Control System
The controlled variable is measured and the result is used to manipulate one or more of the process variables.
(c) Ian Davis
Winter 2016

114. Open-Loop Control System
Information about process variables is not used to adjust the system.
(c) Ian Davis
Winter 2016

115. Process Control Examples
Real-Time System Software to Control:
Automobile Anti-Lock Brakes
Nuclear Power Plants
Automobile Cruise-Control
(c) Ian Davis
Winter 2016

116. Process Control Examples
Hardware circuits that implement clocks, count, add etc.
Logic circuits
Quantum circuits
(c) Ian Davis
Winter 2016

117. Rule Based Architectures
Winter 2016
(c) Ian Davis

118. Iterative enhancement style
Want appearance of intelligent behaviour.
Impossible to quantify what intelligence is.
Start by writing a very dumb program.
Keep adding logic which makes it less dumb.
Terminate when can’t improve behaviour of resulting logic.
(c) Ian Davis
Winter 2016

119. Iterative enhancement pro/cons
Allows concurrent design and development.
Can lead to surprising intelligence.
Displays the same characteristics as human intelligence.. Rather unpredictable and not always right.
Very hard to predict apriori how successful exercise will be.
(c) Ian Davis
Winter 2016

120. Iterative enhancement example
Bridge program..
Deal hand
Enforce basic rules of play
Add sensible rules for how to play well
Consider making finesses etc. etc.
Logic identifies the least worse card to play based on huge number of empirical rules drawn from observation of codes prior behaviour.
Release code when changes do not improve play
(c) Ian Davis
Winter 2016

121. Cribbage Table driven discard logic
For every pair of cards I can discard
And for every cut
What is average value of my resulting hand
What is average value of the box
Add if my box else subtract since opponents
Maximize score
Winter 2016
(c) Ian Davis

122. Pegging For each card I might still play
For every possible card played in response
And for each card I might then play
Play the card that maximizes my score minus their score.
Winter 2016
(c) Ian Davis

123. Model Driven Architectures
Winter 2016
(c) Ian Davis

124. Model driven architecture
Architecture is formalised in a model
Model is computer readable
A computer tool produces the implementation
Pro’s
Consistent mapping from design to implementation
Efficient approach to software development
Con’s
Limited by power of the model and translation tool
Hard to test, maintain, and very hard to debug
Winter 2016
(c) Ian Davis

125. Model driven Examples RPCgen / DCOM Object Management Group (OMG)
Marshalling/unmarshalling interfaces
Object Management Group (OMG)
Given UML produce code
Liqui|>
Given quantum machine expressed in F#
Generate code to simulate this machine
Winter 2016
(c) Ian Davis

126. Future Architectures
Winter 2016
(c) Ian Davis

127. Quantum Computing And then a miracle happens
Invoke an Oracle
Mapping from non-deterministic problem
To deterministic performance speeds
Liqui|>
Public domain quantum computer simulator
Logical behaviour
Physical behaviour
Winter 2016
(c) Ian Davis

128.
Winter 2016
(c) Ian Davis

129. Quantum Computers Available on the cloud
In 10 to 20 years
Easily within your lifetime
Need tools to use them a-priori
Simulation provides a head start
Great opportunity to get involved now
Promising subject for future research
Liqui|> presentation
Good overview of many architectural issues
Winter 2016
(c) Ian Davis

130. Liqui|> Open Source Software
Some versions of this software are free
Have fun
Winter 2016
(c) Ian Davis