Transcript 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 highlevel 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, objectoriented 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.
27/09/1999
(c) Spiros Mancoridis
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