1. (c) Spiros Mancoridis127/09/1999 Software Design Topics in Architectural Design Material drawn from [Shaw96, Perry93] Modified by Ian Davis

2. (c) Spiros Mancoridis227/09/1999 Software Architecture Topics Terminology and Motivation Intuition About Architecture: –Building Architecture –Hardware –Network

3. (c) Spiros Mancoridis327/09/1999 Abstraction One characterization of progress in software development has been the regular increase in abstraction levels: –I.e., the conceptual size of software designer's building blocks. Resulted in ever more complexsoftware. Increased dependence on architecture.

4. (c) Spiros Mancoridis427/09/1999 Abstraction (Cont’d) Early 1950s: Software was written in machine language: –programmers placed instructions and data individually and explicitly in the computer's memory, –insertion of a new instruction in a program might require hand checking the entire program to update references to data and instructions.

5. (c) Spiros Mancoridis527/09/1999 Abstraction (Cont’d) Early 1950s: Reuse involved saving subroutines on paper tape, and filing in drawers. Subroutines were mechanically spliced into new paper tape programs when needed. Commitees meet to discuss which subroutines were best to use in a given situation.

6. (c) Spiros Mancoridis627/09/1999 Assemblers Some Machine code programming problems were solved by adding a level of abstraction between the program and the machine: –Symbolic Assemblers: Names used for operation codes and memory addresses. Memory layout and update of references are automated. –Macro Processors: Allow a single symbol to stand for a commonly used sequence of instructions.

7. (c) Spiros Mancoridis727/09/1999 Assemblers Early CPU’s had poor architectures. Different registers had different instruction sets, and could not be used interchangeably. Intelligent assemblers hide some of these problems. People started formulating rules about how registers could be used in subroutine calls, and how assember should be structured.

8. (c) Spiros Mancoridis827/09/1999 Programming Languages Late 1950s: The emerging of the first high- level programming languages. Well understood patterns are created from notations that are more like mathematics than machine code. –evaluation of arithmetic expressions, –procedure invocation, –loops and conditionals

9. (c) Spiros Mancoridis927/09/1999 Programming Languages (Cont’d) FORTRAN becomes the first widely used programming language. Algol and its successors followed with higher-levels of abstraction for representing data (types). No clear recognition for need to support complex structures, recursion, stack etc. Clear division between code and data.

10. (c) Spiros Mancoridis1027/09/1999 Abstract Data Types Late 1960s and 1970s: Programmers shared an intuition that good data structure design will ease the development of a program. Programmers recognized the need for standards, but disagreed on whose standards should be used.

11. (c) Spiros Mancoridis1127/09/1999 Abstract Data Types Intuition was converted into theories of modularization and information hiding. –Data and related code are encapsulated into modules. –Interfaces to modules are made explicit. –Type checking become the norm.

12. (c) Spiros Mancoridis1227/09/1999 Abstract Data Types (Cont’d) Various programming languages (e.g., Modula, Ada, Euclid) Module Interconnection Languages (e.g., MIL75, Intercol) emerge with implementations of this theory.

13. (c) Spiros Mancoridis1327/09/1999 Software Architecture As the size and complexity of software systems increases, the design problem goes beyond algorithms and data structures. Designing and specifying the overall system structure (Software Architecture) emerges as a new kind of problem.

14. (c) Spiros Mancoridis1427/09/1999 Software Architecture Issues Organization and global control structure, protocols of communication, synchronization, and data access, assignment of functionality to design elements, physical distribution, selection among design alternatives.

15. (c) Spiros Mancoridis1527/09/1999 State of Practice There is not currently a well-defined terminology or notation to characterize architectural structures. However, good software engineers make common use of architectural principles when designing complex software. These principles represent rules of thumb or idiomatic patterns that have emerged informally over time. Others are more carefully documented as industry standards.

16. (c) Spiros Mancoridis1627/09/1999 Descriptions of Architectures “Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers.” Client and server are multi-threaded. ODBC is employed by all interfaces.

17. (c) Spiros Mancoridis1727/09/1999 Descriptions of Architectures (Cont’d) “Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client-server model for the structuring of applications.”

18. (c) Spiros Mancoridis1827/09/1999 Descriptions of Architectures (Cont’d) “We have chosen a distributed, object- oriented approach to managing information.”

19. (c) Spiros Mancoridis1927/09/1999 Descriptions of Architectures (Cont’d) “The easiest way to make a canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors. A more effective way is to split the source code into many segments, which are concurrently processed through the various phases of compilation (by multiple compiler processes) before a final, merging pass recombines the object code into a single program.”

20. (c) Spiros Mancoridis2027/09/1999 Some Standard Architectures ISO/OSI Reference Model is a layered network architecture. X Window System is a distributed windowed user interface architecture based on event triggering and callbacks. NIST/ECMA Reference Model is a generic software engineering environment architecture based on layered communication substrates.

21. (c) Spiros Mancoridis2127/09/1999 The “Toaster” Model

22. (c) Spiros Mancoridis2227/09/1999 Intuition About Architecture

23. (c) Spiros Mancoridis2327/09/1999 Intuition About Architecture It is interesting that we have so few named software architectures. This is not because there are so few architectures, but so many. We next look at several architectural disciplines in order to develop an intuition about software architecture. Specifically, we look at: –Building Architecture –Hardware Architecture –Network Architecture

24. (c) Spiros Mancoridis2427/09/1999 Building Architecture Multiple Views: skeleton frames, detailed views of electrical wiring, etc. Various levels of abstraction. Architectural Styles: Classical, gothic Romanesque, and so on. Various constraints on design. Materials: One does not build a skyscraper using wooden posts and beams. Problems with implementation using available tools.

25. (c) Spiros Mancoridis2527/09/1999 King Henry 1V, Act 1, Scene 3 LORD BARDOLPH: When we mean to build, we first survey the plot, then draw the model; And when we see the figure of the house, then must we rate the cost of the erection; which if we find outweighs ability, what do we then but draw anew the model in fewer offices, or at last desist to build at all?

26. (c) Spiros Mancoridis2627/09/1999 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.

27. (c) Spiros Mancoridis2727/09/1999 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.

28. (c) Spiros Mancoridis2827/09/1999 Differences & Similarities Between SW & HW Architectures Differences: –relatively (to software) small number of design elements, resulting in greater reuse. –scale is achieved by replication of design elements. Similarities: –we often configure software architectures in ways analogous to hardware architectures. (e.g., we create multi-process software and use pipelined processing).

29. (c) Spiros Mancoridis2927/09/1999 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 –Manhattan Street networks Unlike software architectures, in network architectures only few topologies interesting

30. (c) Spiros Mancoridis3027/09/1999 Network Architecture Synchronous versus asynchronous communication. Unreliable communication versus reliable communication. Layered communications protocol. Re-use of software: eg: TCP/IP has TCP using the IP protocol to make unreliable communication, reliable.

31. (c) Spiros Mancoridis3127/09/1999 Architectural Styles of Software Systems

32. (c) Spiros Mancoridis3227/09/1999 Architectural Styles of Software Systems An Architectural Style defines a family of systems in terms of a pattern of structural organization. It determines: – the vocabulary of components and connectors that can be used in instances of that style, –a set of constraints on how they can be combined. For example, one might constrain: the topology of the descriptions (e.g., no cycles). execution semantics (e.g., processes execute in parallel).

33. (c) Spiros Mancoridis3327/09/1999 Determining an Architectural Style We can understand what a style is by answering the following questions: –What is the structural pattern? (i.e., components, connectors, constraints) –What is the underlying computational model? –What are the essential invariants of the style? –What are some common examples of its use? –What are the advantages and disadvantages of using that style? –What are some of the common specializations of that style?

34. (c) Spiros Mancoridis3427/09/1999 Describing an Architectural Style The architecture of a specific system is a collection of: –computational components, –description of the interactions between these components (connectors).

35. (c) Spiros Mancoridis3527/09/1999 Describing an Architectural Style (Cont’d) software architectures are represented as graphs where nodes represent components: procedures modules processes tools databases and edges represent connectors: procedure calls event broadcasts database queries pipes

36. (c) Spiros Mancoridis3627/09/1999 Software Architecture Topics Architectural Styles of Software Systems: –Layered –Layered by language –Pipe and Filter –Object-Oriented –COM/OLE objects –Event driven –Table driven –Implicit Invocation

37. (c) Spiros Mancoridis3727/09/1999 Software Architecture Topics More Styles of Software Systems: –Client-Server –Interpreter –Repository –Process-Control –Co-routines –Bootstrapped –Iteratively extended

38. (c) Spiros Mancoridis3827/09/1999 Layered Style Suitable for applications that involve distinct classes of services that can be organized hierarchically. Each layer provides service to the layer above it and serves as a client to the layer below it. Only carefully selected procedures from the inner layers are made available (exported) to their adjacent outer layer.

39. (c) Spiros Mancoridis3927/09/1999 Layered Style (Cont’d) Components: are typically collections of procedures. Connectors: are typically procedure calls under restricted visibility.

40. (c) Spiros Mancoridis4027/09/1999 Layered Style (Cont’d)

41. (c) Spiros Mancoridis4127/09/1999 Layered Style Specializations Often exceptions are be made to permit non-adjacent layers to communicate directly. –This is usually done for efficiency reasons.

42. (c) Spiros Mancoridis4227/09/1999 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

43. (c) Spiros Mancoridis4327/09/1999 Unix Layered Architecture

44. (c) Spiros Mancoridis4427/09/1999 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.

45. (c) Spiros Mancoridis4527/09/1999 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.

46. (c) Spiros Mancoridis4627/09/1999 Layered by language Different languages meet very different needs. It is sometimes useful to layer software according to language layers. The languages employed define the interfaces between layers.

47. (c) Spiros Mancoridis4727/09/1999 Layered language example The web. –HTML –ASP –VBScript –OLE –OLE/DB –C++

48. (c) Spiros Mancoridis4827/09/1999 Pipe and Filter Architectural Style Suitable for applications that require a defined series of independent computations to be performed on ordered data. A component reads streams of data on its inputs and produces streams of data on its outputs. Very little feedback available from later operations applied to data.

49. (c) Spiros Mancoridis4927/09/1999 Pipe and Filter Architectural Style (Cont’d) Components: called filters, apply local transformations to their input streams and often do their computing incrementally so that output begins before all input is consumed. Connectors: called pipes, serve as conduits for the streams, transmitting outputs of one filter to inputs of another.

50. (c) Spiros Mancoridis5027/09/1999 Pipe and Filter Architectural Style (Cont’d)

51. (c) Spiros Mancoridis5127/09/1999 Pipe and Filter Invariants Filters do not share state with other filters. Filters do not know the identity of their upstream or downstream filters. The correctness of the output of a pipe and filter network should not depend on the order in which their filters perform their incremental processing.

52. (c) Spiros Mancoridis5227/09/1999 Pipe and Filter Specializations 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.

53. (c) Spiros Mancoridis5327/09/1999 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

54. (c) Spiros Mancoridis5427/09/1999 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.

55. (c) Spiros Mancoridis5527/09/1999 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.

56. (c) Spiros Mancoridis5627/09/1999 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.

57. (c) Spiros Mancoridis5727/09/1999 Case Study: Architecture of a Compiler

58. (c) Spiros Mancoridis5827/09/1999 Hybrid Compiler Architectures The new view accommodates various tools (e.g., syntax-directed editors) that operate on the internal representation rather than the textual form of a program. Architectural shift to a repository style, with elements of the pipeline style, since the order of execution of the processes is still predetermined.

59. (c) Spiros Mancoridis5927/09/1999 Architecture of a Compiler The architecture of a system can change in response to improvements in technology. This can be seen in the way we think about compilers.

60. (c) Spiros Mancoridis6027/09/1999 Early Compiler Architectures In the 1970s, compilation was regarded as a sequential (batch sequential or pipeline) process:

61. (c) Spiros Mancoridis6127/09/1999 Early Compiler Architectures Most compilers create a separate symbol table during lexical analysis and used or updated it during subsequent passes.

62. (c) Spiros Mancoridis6227/09/1999 Modern Compiler Architectures Later, in the mid 1980s, increasing attention turned to the intermediate representation of the program during compilation.

63. (c) Spiros Mancoridis6327/09/1999 Hybrid Compiler Architectures

64. (c) Spiros Mancoridis6427/09/1999 Object-Oriented Style Suitable for applications in which a central issue is identifying and protecting related bodies of information (data). Data representations and their associated operations are encapsulated in an abstract data type. Components: are objects. Connectors: are function and procedure invocations (methods).

65. (c) Spiros Mancoridis6527/09/1999 Object-Oriented Style Subtle shift in programming style. Not all parameters are equally significant. Procedure invocation is determined by object, rather than by case statements. Restrictions on how information within objects can be used (encapsulation). Usefulness determines life time of data. Reuse achieved through inheritance.

66. (c) Spiros Mancoridis6627/09/1999 Object-Oriented Style (Cont’d)

67. (c) Spiros Mancoridis6727/09/1999 Object-Oriented Invariants Objects are responsible for preserving the integrity (e.g., some invariant) of the data representation. The data representation is hidden from other objects.

68. (c) Spiros Mancoridis6827/09/1999 Object-Oriented Specializations Distributed Objects Objects with Multiple Interface COM

69. (c) Spiros Mancoridis6927/09/1999 Object-Oriented Advantages Because an object hides its data representation from its clients, it is possible to change the implementation without affecting those clients. Can design systems as collections of autonomous interacting agents. Intuitive mapping from real world objects, to implementation in software.

70. (c) Spiros Mancoridis7027/09/1999 Object-Oriented Advantages Good ability to manage construction and destruction of objects, centralizing these operations in one place. Relatively easy to distribute objects. Shifts focus towards object interfaces, and away from arbitrary procedure interfaces. Moves away from the “any procedure can call any procedure paradigm”.

71. (c) Spiros Mancoridis7127/09/1999 Object-Oriented Disadvantages In order for one object to interact with another object (via a method invocation) the first object must know the identity of the second object. –Contrast with Pipe and Filter Style. –When the identity of an object changes it is necessary to modify all objects that invoke it. Partially resolved by using conventions such as COM.

72. (c) Spiros Mancoridis7227/09/1999 Object-Oriented Disadvantages The distinction between an object changing its content, and becoming a new object are too harsh. Objects cause side effect problems: –E.g., A and B both use object C, then B's affect on C look like unexpected side effects to A. –Essentially the problem here is that objects have persistent state. Managing object destruction is hard.

73. (c) Spiros Mancoridis7327/09/1999 Microsoft’s COM Architecture “Component Object Model”. A collection of rules and restrictions on how objects may be both used and managed. An interface is a “named” collection of methods having a predefined purpose and call/return protocol. An object has one or more interfaces. It can be manipulated only through it’s interfaces.

74. (c) Spiros Mancoridis7427/09/1999 Microsoft’s COM Architecture Each interface name is identified by a globally unique id (GUID). Every COM object has Iunknown interface. –QueryInterface(REFIID riid, void **vPP) –AddRef(void) –Release(void) Other interfaces are accessed via a pointer to the interface returned by QueryInterface if the object supports the specified interface.

75. (c) Spiros Mancoridis7527/09/1999 COM advantages Methods supported by an object can be determined at runtime. Reduces risk of performing illegal operations on an object as a result of recasting it incorrectly. Reference counting simplifies management of object’s lifetime. Objects may incrementally be assigned new interfaces cleanly.

76. (c) Spiros Mancoridis7627/09/1999 COM advantages cont. Makes distribution of objects easier. Interfaces can be implemented in C++, by merely arranging for an object class to multiply inherit from each of its supported interfaces. Avoids the problem of trying to change an existing interface definition. You don’t.

77. (c) Spiros Mancoridis7727/09/1999 COM advantages cont. Objects can be registered in the NT registry. The software needed to support objects can be dynamically loaded from DLL’s upon demand. The software needed to support an object need only be loaded once.. not once per program. Common interfaces are shared by all objects that support them.

78. (c) Spiros Mancoridis7827/09/1999 COM disadvantages Tedium and overhead associated with obtaining and freeing interface pointers. All methods are called indirectly via the interface pointer, which is inefficient. Defined interfaces may not be changed. Need to dynamically create all COM objects. Can’t delete static objects.

79. (c) Spiros Mancoridis7927/09/1999 COM disadvantages Some difficulty aggregating COM objects into larger objects because of the shared IUnknown interface. Risk of loading a “Trojan horse”.

80. (c) Spiros Mancoridis8027/09/1999 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. Communication is via global or object state. Useful when we are required to “return” from code, but don’t wish to leave it.

81. (c) Spiros Mancoridis8127/09/1999 Event driven examples Barber shop simulation. –After creating an initial future event, events themselves introduce additional future events. Servers which chit chat with clients.

82. (c) Spiros Mancoridis8227/09/1999 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.

83. (c) Spiros Mancoridis8327/09/1999 Table driven examples Yacc –Tables are generated which determine how parsing is to be performed. Cribbage game –Value of cribbage hands precomputed.

84. (c) Spiros Mancoridis8427/09/1999 Event/table driven pros&cons Can produce clean solutions to seemingly difficult problems Can be hard to grasp what is going on as different events occur in unclear orders. Some programmers have difficulty making the transition from conventional code to event driven code.

85. (c) Spiros Mancoridis8527/09/1999 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. Particularly useful for applications that must be reconfigured on the fly: –Changing a service provider. –Enabling or disabling capabilities.

86. (c) Spiros Mancoridis8627/09/1999 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.

87. (c) Spiros Mancoridis8727/09/1999 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.

88. (c) Spiros Mancoridis8827/09/1999 Implicit Invocation Style (Cont’d) An event announcement “implicitly” causes the invocation of procedures in other modules.

89. (c) Spiros Mancoridis8927/09/1999 Implicit Invocation Invariants Announcers of events do not know which components will be affected by those events. Components cannot make assumptions about the order of processing. Components cannot make assumptions about what processing will occur as a result of their events (perhaps no component will respond).

90. (c) Spiros Mancoridis9027/09/1999 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.

91. (c) Spiros Mancoridis9127/09/1999 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.

92. (c) Spiros Mancoridis9227/09/1999 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 routine of function keys etc. to logic. Used in forms to allow generic logic.

93. (c) Spiros Mancoridis9327/09/1999 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.

94. (c) Spiros Mancoridis9427/09/1999 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.

95. (c) Spiros Mancoridis9527/09/1999 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.

96. (c) Spiros Mancoridis9627/09/1999 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”.

97. (c) Spiros Mancoridis9727/09/1999 Client-Server Style Suitable for applications that involve distributed data and processing across a range of components. Components: –Servers: Stand-alone components that provide specific services such as printing, data management, etc. –Clients: Components that call on the services provided by servers. Connector: The network, which allows clients to access remote servers.

98. (c) Spiros Mancoridis9827/09/1999 Client-Server Style

99. (c) Spiros Mancoridis9927/09/1999 Client-Server Style Examples File Servers: –Primitive form of data service. –Useful for sharing files across a network. –The client passes request for files over the network to the file server.

100. (c) Spiros Mancoridis10027/09/1999 Client-Server Style Examples (Cont’d) Database Servers: –More efficient use of distributing power than file servers. –Client passes SQL requests as messages to the DB server; results are returned over the network to the client. –Query processing done by the server. –No need for large data transfers. –Transaction DB servers also available.

101. (c) Spiros Mancoridis10127/09/1999 Client-Server Style Examples (Cont’d) Object Servers: –Objects work together across machine and network boundaries. –ORBs allow objects to communicate with each other across the network. –IDLs define interfaces of objects that communicate via the ORB. –ORBs are the evolution of the RPC.

102. (c) Spiros Mancoridis10227/09/1999 RPCs Versus ORBs

103. (c) Spiros Mancoridis10327/09/1999 Client-Server Advantages Distribution of data is straightforward, transparency of location, mix and match heterogeneous platforms, easy to add new servers or upgrade existing servers. Functional client server interface. Simplifies distant levels of recursion. One server can support multiple clients

104. (c) Spiros Mancoridis10427/09/1999 Client-Server Disadvantages No central register of names and services -- it may be 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 when its services are requested.

105. (c) Spiros Mancoridis10527/09/1999 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 used. Eg.__int64, unicode, etc.

106. (c) Spiros Mancoridis10627/09/1999 Repository 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.

107. (c) Spiros Mancoridis10727/09/1999 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.

108. (c) Spiros Mancoridis10827/09/1999 Repository Style (Cont’d)

109. (c) Spiros Mancoridis10927/09/1999 Repository Style Specializations Changes to the data structure trigger computations. Data structure in memory (persistent option). Data structure on disk. Concurrent computations and data accesses.

110. (c) Spiros Mancoridis11027/09/1999 Repository Style Examples Information Systems Programming Environments Graphical Editors AI Knowledge Bases Reverse Engineering Systems SQL3 promises to be computationally complete.

111. (c) Spiros Mancoridis11127/09/1999 Repository Style Advantages Efficient way to store large amounts of data. Sharing model is published as the repository schema. Centralized management: –backup –security –concurrency control

112. (c) Spiros Mancoridis11227/09/1999 Repository Style Disadvantages Must agree on a data model a priori. Difficult to distribute data. Data evolution is expensive.

113. (c) Spiros Mancoridis11327/09/1999 Interpreter Style Suitable for applications in which the most appropriate language or machine for executing the solution is not directly available.

114. (c) Spiros Mancoridis11427/09/1999 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.

115. (c) Spiros Mancoridis11527/09/1999 Interpreter Style (Cont’d)

116. (c) Spiros Mancoridis11627/09/1999 Interpreter Style Examples Programming Language Compilers: –Java –Smalltalk Rule Based Systems: –Prolog –Coral Scripting Languages: –Awk –Perl

117. (c) Spiros Mancoridis11727/09/1999 Interpreter Style Examples Micro coded machine –Implement machine code in software. Cash register / calculator –Emulate a clever chip using a cheap one. Database plan –The database engine interprets the plan. Presentation package –Display a graph, by operating on the graph.

118. (c) Spiros Mancoridis11827/09/1999 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.

119. (c) Spiros Mancoridis11927/09/1999 Java Architecture

120. (c) Spiros Mancoridis12027/09/1999 Interpreter Style Disadvantages Extra level of indirection slows down execution. Java has an option to compile code. –JIT (Just In Time) compiler.

121. (c) Spiros Mancoridis12127/09/1999 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.

122. (c) Spiros Mancoridis12227/09/1999 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.

123. (c) Spiros Mancoridis12327/09/1999 Feed-Back Control System The controlled variable is measured and the result is used to manipulate one or more of the process variables.

124. (c) Spiros Mancoridis12427/09/1999 Open-Loop Control System Information about process variables is not used to adjust the system.

125. (c) Spiros Mancoridis12527/09/1999 Process Control Examples Real-Time System Software to Control: –Automobile Anti-Lock Brakes –Nuclear Power Plants –Automobile Cruise-Control

126. (c) Spiros Mancoridis12627/09/1999 Process Control Examples Hardware circuits that implement clocks, count, add etc.

127. (c) Spiros Mancoridis12727/09/1999 Co-routines The whole is bigger than the parts, but the parts cannot easily be decomposed into sequential operations. Separate parts must communicate with each other without loosing stack state. Parts run in separate threads and the overall operation is tightly coupled, to produce the desired computation.

128. (c) Spiros Mancoridis12827/09/1999 Co-routine examples Concurrent error detection and correction. Buffer management. Disk update by any must cause all to be notified, so that caches can be reloaded.

129. (c) Spiros Mancoridis12927/09/1999 Bootstrapped logic A quick but inefficient way of creating a tool can lead to a tool which allows creation of the same tool in better ways.

130. (c) Spiros Mancoridis13027/09/1999 Bootstrap examples Parsers accept as input a document whose syntax conforms to the parsers meta language. Therefore parsers must themselves contain parsers. Java engine written in C++, and then in interpreted Java, and then in compiled Java.

131. (c) Spiros Mancoridis13127/09/1999 Bootstrap pros/cons Avoids need to design good solution when a bad solution leads directly to a better one. Can’t recreate the tool if you loose the tool. Have to be very careful when changing bootstrapped code not to destroy ability to produce tool from source code.

132. (c) Spiros Mancoridis13227/09/1999 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.

133. (c) Spiros Mancoridis13327/09/1999 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.

134. (c) Spiros Mancoridis13427/09/1999 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

135. (c) Spiros Mancoridis13527/09/1999 Orthogonal issues Detect and eliminate memory leakage's Code should be re-entrant –Don’t condition logic based on static data Code should be thread safe –Avoid global state –Protect object state against concurrent update Code interrupt safe –Anticipate unexpected throws, interrupts etc. –Eg. out of memory or Cntl-C