Distributed Objects

							             Software Design


          Topics in
     Architectural Design

 Material drawn from [Shaw96, Perry93]
          Modified by Ian Davis
27/09/1999         (c) Spiros Mancoridis   1
   Software Architecture Topics
• Terminology and Motivation
• Intuition About Architecture:
  – Building Architecture
  – Hardware
  – Network




27/09/1999       (c) Spiros Mancoridis   2
                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 complex software.
• Increased dependence on architecture.


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


27/09/1999        (c) Spiros Mancoridis          4
             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.
27/09/1999        (c) Spiros Mancoridis    5
                  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.
27/09/1999           (c) Spiros Mancoridis               6
               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.
27/09/1999       (c) Spiros Mancoridis        7
       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

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


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




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




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



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

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


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


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




27/09/1999      (c) Spiros Mancoridis      18
    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.”
 27/09/1999        (c) Spiros Mancoridis          19
   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.
27/09/1999      (c) Spiros Mancoridis      20
             The “Toaster” Model




27/09/1999        (c) Spiros Mancoridis   21
    Intuition About Architecture




27/09/1999   (c) Spiros Mancoridis   22
    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
27/09/1999       (c) Spiros Mancoridis       23
             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.
27/09/1999         (c) Spiros Mancoridis   24
  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?

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

27/09/1999        (c) Spiros Mancoridis       27
   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).
27/09/1999        (c) Spiros Mancoridis           28
             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
27/09/1999        (c) Spiros Mancoridis      29
             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.
27/09/1999        (c) Spiros Mancoridis      30
             Architectural Styles
             of Software Systems




27/09/1999        (c) Spiros Mancoridis   31
             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).
27/09/1999             (c) Spiros Mancoridis                   32
            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? (c) Spiros Mancoridis
27/09/1999                                          33
Describing an Architectural Style
• The architecture of a specific system is a
  collection of:
  – computational components,
  – description of the interactions between these
    components (connectors).




27/09/1999        (c) Spiros Mancoridis             34
           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
27/09/1999              (c) Spiros Mancoridis   35
    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
 27/09/1999         (c) Spiros Mancoridis     36
    Software Architecture Topics
• More Styles of Software Systems:
   –   Client-Server
   –   Interpreter
   –   Repository
   –   Process-Control
   –   Co-routines
   –   Bootstrapped
   –   Iteratively extended

 27/09/1999           (c) Spiros Mancoridis   37
             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.
27/09/1999       (c) Spiros Mancoridis      38
             Layered Style (Cont’d)
• Components: are typically collections of
  procedures.
• Connectors: are typically procedure calls
  under restricted visibility.




27/09/1999         (c) Spiros Mancoridis      39
             Layered Style (Cont’d)




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




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

27/09/1999        (c) Spiros Mancoridis           42
      Unix Layered Architecture




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

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

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



27/09/1999        (c) Spiros Mancoridis      46
      Layered language example
• The web.
  –   HTML
  –   ASP
  –   VBScript
  –   OLE
  –   OLE/DB
  –   C++


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

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

27/09/1999       (c) Spiros Mancoridis      49
          Pipe and Filter
    Architectural Style (Cont’d)




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


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



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

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



27/09/1999       (c) Spiros Mancoridis       56
            Case Study:
     Architecture of a Compiler




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

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




27/09/1999      (c) Spiros Mancoridis      59
   Early Compiler Architectures
• In the 1970s, compilation was regarded as a
  sequential (batch sequential or pipeline)
  process:




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




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




27/09/1999       (c) Spiros Mancoridis       62
 Hybrid Compiler Architectures




27/09/1999   (c) Spiros Mancoridis   63
             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).
27/09/1999         (c) Spiros Mancoridis     64
             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.
27/09/1999         (c) Spiros Mancoridis        65
 Object-Oriented Style (Cont’d)




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




27/09/1999       (c) Spiros Mancoridis           67
 Object-Oriented Specializations
• Distributed Objects
• Objects with Multiple Interface
• COM




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

 27/09/1999       (c) Spiros Mancoridis         69
    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”.
27/09/1999       (c) Spiros Mancoridis          70
 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.
27/09/1999         (c) Spiros Mancoridis              71
 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.
27/09/1999        (c) Spiros Mancoridis            72
  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.
27/09/1999       (c) Spiros Mancoridis       73
  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.
27/09/1999        (c) Spiros Mancoridis        74
             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.
27/09/1999      (c) Spiros Mancoridis    75
             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.


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

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




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

27/09/1999       (c) Spiros Mancoridis       80
             Event driven examples

• Barber shop simulation.
  – After creating an initial future event, events
    themselves introduce additional future events.
• Servers which chit chat with clients.




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

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




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


27/09/1999      (c) Spiros Mancoridis     84
        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.
27/09/1999        (c) Spiros Mancoridis       85
        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.
27/09/1999      (c) Spiros Mancoridis         86
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.
27/09/1999        (c) Spiros Mancoridis          87
Implicit Invocation Style (Cont’d)
• An event announcement “implicitly” causes
  the invocation of procedures in other
  modules.




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




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



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

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

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

27/09/1999        (c) Spiros Mancoridis           95
             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”.
27/09/1999        (c) Spiros Mancoridis       96
             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.
27/09/1999        (c) Spiros Mancoridis         97
             Client-Server Style




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




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


27/09/1999        (c) Spiros Mancoridis      101
             RPCs Versus ORBs




27/09/1999       (c) Spiros Mancoridis   102
           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
    27/09/1999    (c) Spiros Mancoridis    103
   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.
27/09/1999       (c) Spiros Mancoridis      104
   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.

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


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

27/09/1999        (c) Spiros Mancoridis           107
       Repository Style (Cont’d)




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



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

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

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




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




27/09/1999       (c) Spiros Mancoridis      113
       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.
27/09/1999        (c) Spiros Mancoridis          114
       Interpreter Style (Cont’d)




27/09/1999     (c) Spiros Mancoridis   115
      Interpreter Style Examples
• Programming Language Compilers:
  – Java
  – Smalltalk
• Rule Based Systems:
  – Prolog
  – Coral
• Scripting Languages:
  – Awk
  – Perl
27/09/1999      (c) Spiros Mancoridis   116
      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.

27/09/1999           (c) Spiros Mancoridis        117
    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.
27/09/1999      (c) Spiros Mancoridis      118
             Java Architecture




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




27/09/1999        (c) Spiros Mancoridis   120
             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.
27/09/1999         (c) Spiros Mancoridis         121
 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. Mancoridis
27/09/1999           (c) Spiros                     122
      Feed-Back Control System
• The controlled variable is measured and the
  result is used to manipulate one or more of
  the process variables.




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




27/09/1999       (c) Spiros Mancoridis         124
      Process Control Examples
• Real-Time System Software to Control:
  – Automobile Anti-Lock Brakes
  – Nuclear Power Plants
  – Automobile Cruise-Control




27/09/1999      (c) Spiros Mancoridis     125
      Process Control Examples
• Hardware circuits that implement clocks,
  count, add etc.




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

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




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




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




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




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


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


27/09/1999      (c) Spiros Mancoridis      133
 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
27/09/1999       (c) Spiros Mancoridis        134
             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
27/09/1999        (c) Spiros Mancoridis              135