SOFTWARE ARCHITECTURE

1
SOFTWARE ARCHITECTURE
Software Design
the choice of algorithms and data structures for
computation has previously been the focus of
attention in application design
As size and complexity of software systems
increased, system structure became a more
significant issue.
2
SOFTWARE ARCHITECTURE
Definition

• the structure or structures of the system, which
  comprise software components, the externally
  visible properties of those components, and the
  relationships among them

The intent of this definition is that a software
architecture must abstract away some information
from the system and yet provide enough
information to be a basis for analysis, decision
making, and hence risk reduction.
3
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
4
SOFTWARE ARCHITECTURE
Unfortunately, at the moment most systems are
described in architectural terms using idiomatic
language.
5
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?
Architectural structures convey nothing about the
content of programs or modules but do provide a
framework, the skeleton, to understand
system-level arrangements
6
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)
7
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)
8
SOFTWARE ARCHITECTURE
increasing abstraction
The evolution of data typing .
1950s programming in machine language data and
instructions were explicitly placed in memory.
no abstraction everything was explicit
Then certain patterns of execution were usefully
automated arithmetic expressions, loops,
conditional statements
In Algol data typing moved on it was a
declaration of what you intended to do with each
grouping of data
increasing level of abstraction
the black box idea for subroutines
Advantage compiler then checked the integrity of
these intentions
Further abstraction occurred by introduction of
modules and separation of module specification
from implementation
9
SOFTWARE ARCHITECTURE
Data structures to software architecture.
Just as good programmers recognized useful data
structures in the late 1960s, good software
system designers now recognize useful system
organisations.
To build truly composable systems, we must allow
flexible, high-level connections between existing
systems in ways not foreseen by their original
developers
10
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
11
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
...
12
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
13
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"
14
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.
15
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.
16
SOFTWARE ARCHITECTURE
patterns
Gamma et al. (1995)...
patterns?
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
Volkswagen, Mercedes and Ferrari are design
patterns which might apply to the car industry
These names conjure 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
17
SOFTWARE ARCHITECTURE
patterns
Kimble and Selby (2000) An interdisciplinary
study of information systems Christopher
Alexander and IS failure (Proc. UKAIS, p256-265)
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)

18
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
in terms of functionality, the aim should be to
incorporate just those functions which help users
do what they want basic functional patterns.
19
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
20
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
21
SOFTWARE ARCHITECTURE
some transformation happens
this may be incremental output may begin before
input has ceased
components are termed filters
22
SOFTWARE ARCHITECTURE
Filters must be independent entities
filters do not know the identity of the upstream
and downstream filters
23
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
24
SOFTWARE ARCHITECTURE
Nice properties
allow designers to understand the overall
input/output behaviour of a system from 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
25
SOFTWARE ARCHITECTURE
LAYERED SYSTEMS
ORGANISED HIERARCHICALLY
each layer providing service to the one above it
and serving as a client to the layer below
in some layered systems inner layers are hidden
from all except the adjacent outer layer
in these systems the components implement a
virtual machine
26
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.
27
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.
28
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
29
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
30
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
31
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
32
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
33
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
34
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
35
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
36
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