SOFTWARE ARCHITECTURE

1
SOFTWARE ARCHITECTURE

• the choice of algorithms and data structures
  for computation has previously been the
  focus of attention in application design

As the size and complexity of software systems
increase, system structure becomes a more
significant issue.
2
SOFTWARE ARCHITECTURE
Structural issues include

• the organisation of a system as a composition of
  components
• global control structures
• the protocols for communication, synchronisation,
  and data access
• the assignment of functionality of design
  elements
• the composition of design elements
• physical distribution scaling and performance
• dimensions of evolution
• selection among design alternatives.

This is the software architecture level of design
3
SOFTWARE ARCHITECTURE
Unfortunately, at the moment most systems are
described in architectural terms using idiomatic
language.
4
SOFTWARE ARCHITECTURE

• What is pipeline architecture

• and when should one choose it over a layered
  one?

Are there significant consequences of choosing
one architecture over another?
5
SOFTWARE ARCHITECTURE
client a computer system or process that
requests a service of another computer system or
process ("server") using some kind of protocol
and accepts the server's response
Some translation of the language.
Applications are on the server and the client
machine accesses these through a remote procedure
call (rpc). This allows the client to always see
the same view on their machine irrespective of
how the server end is enacted and rpc is
flexible, not requiring a specific protocol like
http as used for internet access.
6
SOFTWARE ARCHITECTURE
Another example of translation of the language.
BLACK BOX DESIGN
Abstraction separation of what goes on inside a
box (program or here, at the server) allows the
designers to create the clients view
independently of how the server is built up
7
SOFTWARE ARCHITECTURE
Another example of translation of the language.
Pipelining is feeding each section in one after
the other necessary for compiling where the
result of one part of the program is required
before the next can be compiled.
Here the designers are saying an alternative is
divide the source code, compile each separately
and concurrently merge the results.
8
SOFTWARE ARCHITECTURE
Informal descriptions are not entirely
idiosyncratic as they are full of semantic content
though there is no universal consistency in the
terminology
Architectural structures convey nothing about the
content of programs or modules but do provide a
framework, the skeleton, to understand
system-level arrangements
9
SOFTWARE ARCHITECTURE
The value of architectural models.
In general, architectural models clarify what
components are and their interactions
In addition, the architecture should show the
correspondence between system requirements and
the elements built and their performance in terms
of

• Capacity
• Throughput
• Consistency
• Component compatibility

10
SOFTWARE ARCHITECTURE
Kimble and Selby (2000)
Progress in research on information systemslacks
an informed consideration of the geographical
dimension a surprising deficiency given the
inherent spatial nature of networked information
systems
the emergence of electronic space and the
consequent co-existence of two spaces
represents a fundamental change
the information revolution does not mark the end
of geography or the death of distance but that
a complex new geography is being created
11
SOFTWARE ARCHITECTURE
Kimble and Selby (2000)
propose that the concepts of physical and virtual
office spaces are interchangeable

• they exist to serve parallel organisational
  needs
• sometimes the virtual office space isnt as
  effective as the physical - why?

• the virtual office space the office is where
  you are

12
SOFTWARE ARCHITECTURE
Kimble and Selby (2000)

• the physical office

• a systems infrastructure
• a financial investment
• a place for work
• a focus for cultural interchange

1. Information systems 2. Comfort systems
the systems infrastructure is simply the
interface between users of an office and the
technology used to support it
13
SOFTWARE ARCHITECTURE
Kimble and Selby (2000)
design of the physical office
future proofing
nature of work will be reflected in the physical
design of an office
reversibility
interaction is affected by the layout of a
building - floor plans localise people proximity
is all important for chance communication
14
SOFTWARE ARCHITECTURE
Kimble and Selby (2000)
shouldnt we expect the virtual environment to
provide a similarly successful office space?
patterns
Christopher Alexanders work stemmed from
dissatisfaction with architectural designs
the theoretical value of Alexanders observation
is that by understanding the rules that govern
any design process we can formalise optimum
solutions
15
SOFTWARE ARCHITECTURE
patterns
Kimble and Selby (2000)
in IS terms a pattern is a solution to a software
problem that has been captured and documented in
a form others can understand and apply
to build complete applications

• a pattern language
• individual patterns
• network of connections
• (showing how they may be combined)

16
SOFTWARE ARCHITECTURE
patterns
Kimble and Selby (2000)
Alexanders argument is that an apparently
creative process is governed by an underlying set
of rules or constraints
once you admit that the rules are generative,
then you have sort of got right to the heart of
the creative core
Architects imagine they are creating buildings
To have a theory which claims that there are
these systems of rulesthat it is really the
implicit structure which governs, is pretty much
a shock to the ego.
17
SOFTWARE ARCHITECTURE
patterns
Kimble and Selby (2000)
architectural and IS failures have a lot in
common too
Failings in architecture, despite Alexanders
patterns, relate essentially to lack of
stakeholder (user) involvement and subsequent
dissatisfaction

• Lyytinen Hirschheim (1987). IS Failures - A
  survey and classification of the empirical
  literature. Oxford Surveys in IT, 4 257-309
• - clearly indicates many of the problems causing
  IS failure are due to insufficient attention
  being paid to the stakeholders
• Correspondence Failures
• Process Failures
• Interaction Failures
• Expectation Failures

18
SOFTWARE ARCHITECTURE
patterns
Gamma, E., Helm, R., Johnson, R. Vlissides, J.
(1995). Design patterns elements of reusable
object-oriented software.
expert designers know not to solve every problem
from first principles
they reuse solutions that have worked for them in
the past
An analogy with novelists and playwrights helps
illustrate the point genre is important in
constructing a plot - like the "tragically flawed
hero" or "unrequited love breeds contempt and
revenge"
19
SOFTWARE ARCHITECTURE
patterns
Gamma et al. (1995)...
a pattern has 4 essential elements
1. NAME - a handle we can use to describe a
design problem, solutions, and consequences in
short form. Naming lets us design at a high
level of abstraction, lets us talk and write
about them.
2. PROBLEM DESCRIPTION - when to apply the
pattern, its context, conditions or specific
design problems. It might describe class or
object structures that are symptomatic of an
inflexible design.
20
SOFTWARE ARCHITECTURE
patterns
Gamma et al. (1995)...
a pattern has 4 essential elements
3. SOLUTION - elements that make up the design,
their relationships, responsibilities, and
collaborations, but not a particular concrete
design or implementation. It is an abstract
description of a design problem and how a general
arrangements of elements (classes, objects)
solves it.
4. CONSEQUENCES - the results and trade-offs of
applying the pattern. This is critical for
evaluating design alternatives and for
understanding the costs and benefits in terms of
space and time. Reuse in O-O can affect system
flexibility, extensibility, or portability -.
needs evaluation.
21
SOFTWARE ARCHITECTURE
patterns
Gamma et al. (1995)...
a pattern has 4 essential elements
Points of view affect one's interpretation of
what is and what isn't a pattern. One person's
pattern can be another person's primitive
building block. For instance, Volkswagen,
Mercedes and Ferrari are design patterns which
might apply to the car industry. The use of
these names conjures up designs which are
generalised in our minds but are all different.
Equally, though VW Sharon and Golf are valid
pattern names which apply to the car industry
each conjures up a more detailed design pattern
in our minds and differentiates more clearly the
type of use and users
22
SOFTWARE ARCHITECTURE
Looking at the Hardware model.
Hardware systems have basically 4 levels
Circuits (transistors, resistors, capacitors etc)
Logic designs gates (flip-flops, register
arrays, NAND etc)
Programs (instructions, controls, operators etc)
PMSs (Processors, Memories, Switches, Controls
etc)
23
SOFTWARE ARCHITECTURE
Looking at the Software model.
Software has basically 3 levels
Executables (memory maps, call stacks, register
allocations etc)
Code (data structures, algorithms)
Architecture (overall association of system
components or modules)
24
SOFTWARE ARCHITECTURE
Modern paradigms.
So that high-level relationships among systems
can be understood we need to recognise modern
paradigms
New systems can then be built as variations on
old systems
Systems need to be described in a consistent
manner
Norman Gothic
25
SOFTWARE ARCHITECTURE
Modern paradigms.
Often, it is difficult to see if components can
interact properly if taken for reuse
the same function may be built as filter or a
procedure
they may interact through message passing or
sharing data
Architectural descriptions may help with these
problems
this may well carry over into maintenance when
most effort usually goes into understanding the
existing code
...
26
SOFTWARE ARCHITECTURE
Software architecture is also a lot about
STANDARDISATION
That is how to represent the varied forms of
software out there in the commercial world in a
few, consistent formats which could be automated
27
SOFTWARE ARCHITECTURE
Modern systems.
Often, it is difficult to see if components can
interact properly if taken for reuse
the same function may be built as filter or a
procedure
they may interact through message passing or
sharing data
Architectural descriptions may help with these
problems
this may well carry over into maintenance when
most effort usually goes into understanding the
existing code
...
28
SOFTWARE ARCHITECTURE
Software organisational styles
main programme and sub-routine 0 0
systems hierarchical layers
call and return systems
independent components
communicating processes event systems
29
SOFTWARE ARCHITECTURE
each component has a set of inputs and a set of
outputs
A degenerate case of pipeline architecture occurs
when each filter processes all of its inputs data
as a single entity. This is the batch sequential
system.
Each component reads a stream of data on its
inputs and produces a stream of data on its
outputs
30
SOFTWARE ARCHITECTURE
some transformation happens
this may be incremental output may begin before
input has ceased
31
SOFTWARE ARCHITECTURE
Filters must be independent entities
filters do not know the identity of the upstream
and downstream filters
32
SOFTWARE ARCHITECTURE
Furthermore the network output should not depend
on the order in which filters process
Unix supports pipe and filter architecture - run
time mechanisms implement pipes
33
SOFTWARE ARCHITECTURE
Compilers are often viewed as pipeline systems
lexical analysis parsing semantic analysis code
generation
being the filters
34
SOFTWARE ARCHITECTURE
Nice properties
allow designers to understand the overall
input/output behaviour of a system and a simple
composition of the behaviours of the individual
filters
They support reuse any 2 filters can be hooked
together provided they agree on the data that are
being transmitted between them
Systems are easy to maintain and enhance new
filters can be added to existing systems and old
filters can be replaced by improved ones.
supports concurrent execution
They support throughput and deadlock analysis
35
SOFTWARE ARCHITECTURE
LAYERED SYSTEMS
ORGANISED HIERARCHICALLY
each layer providing service to the one above it
and serving as a client to the layer below
some layered systems inner layers are hidden from
all except the adjacent outer layer
in these systems the components implement a
virtual machine
36
SOFTWARE ARCHITECTURE
LAYERED SYSTEMS
most widely known example
layered communication protocols
A seven layer model of network architecture and a
suite of protocols (a protocol stack) to
implement it, developed by ISO in 1978 as a
framework for international standards in
heterogeneous computer network architecture.
A voluntary, nontreaty organisation founded in
1946, responsible for creating international
standards in many areas, including computers and
communications.
37
SOFTWARE ARCHITECTURE
LAYERED SYSTEMS
OSI ISO model for the Internet
The OSI architecture is split between seven
layers 1 physical layer 2 data link layer 3
network layer 4 transport layer 5 session
layer 6 presentation layer 7 application
layer Each layer uses the layer immediately
below it and provides a service to the layer
above.
38
SOFTWARE ARCHITECTURE
LAYERED SYSTEMS
DESIRABLE PROPERTIES
partition problems into a sequence of incremental
steps
changes to a layer affects at most two other
layers
layers interchangeable provided they have same
interfaces to adjacent layers
39
SOFTWARE ARCHITECTURE
Event based implicit invocation
in implicit invocation a component can announce
(or broadcast) one or more events
AN EVENT ANNOUNCEMENT IMPLICITLY CAUSES THE
INVOCATION OF PROCEDURES IN OTHER MODULES
40
SOFTWARE ARCHITECTURE
Event based implicit invocation
For example
a debugger will stop at a break point in the code
and announce an event
this allows an editor to scroll to the
appropriate source line
41
SOFTWARE ARCHITECTURE
Event based implicit invocation
the components in an implicit invocation style
are modules
interfaces provide both a collection of procedures
and a set of events
42
SOFTWARE ARCHITECTURE
Event based implicit invocation
principles
announcers of events do not know which components
will be affected by those events
thus components cannot make assumptions about the
order of processing
or even about processing which will occur as a
result of their events
43
SOFTWARE ARCHITECTURE
Event based implicit invocation
application examples
in database management systems to ensure
consistency constraints
in programming environments to integrate tools
in user interfaces to separate presentation of
data from applications that manage the data
44
SOFTWARE ARCHITECTURE
Event based implicit invocation
One important benefit
provides strong support for reuse
Any component can be introduced into a system
simply by registering it for the events of the
system
can replace components without affecting the
interfaces of other components in the system
this significantly eases the evolution of the
system
45
SOFTWARE ARCHITECTURE
Event based implicit invocation
Significant drawbacks
components relinquish control over computation
being carried out in the system
after an event is announced no knowing there is
ANY response
data exchange can be problematic
reasoning about correctness can be very difficult
46
SOFTWARE ARCHITECTURE
The goal of Software architecture is to organise
and express software design knowledge in a useful
form
develop a vocabulary of well-understood, reusable
design concepts and patterns
These will provide the mental building blocks
and help in predicting the properties of a design
This will then reduce the number of new concepts
to be learned, thus help with understanding
another designers work
47
SOFTWARE ARCHITECTURE
With this type of information to hand we can then
look at the design of, say, a user-interface and
decide which architecture will best suit such an
application
within the design space what are the good and
bad combinations of choices?