Docstoc

SOFTWARE ARCHITECTURE

Document Sample
SOFTWARE ARCHITECTURE Powered By Docstoc
					        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.
         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.
           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
              SOFTWARE ARCHITECTURE
                                      Unfortunately, at the moment most
                                      systems are described in architectural
                                      terms using idiomatic language….
“Camelot is based on the client-server model
and uses remote procedure calls both locally
and remotely to provide communication                       “We have chosen a distributed,
among applications and servers”                             object-oriented approach to
                                                            managing information”


  “The easiest way to make the canonical sequential
  compiler into a concurrent compiler is to pipeline the
                                                           “Abstraction layering and system
  execution of the compiler phases over a number of
                                                           decomposition provide the appearance
  processors….A more effective way is to split the
                                                           of system uniformity to clients, yet
  source code into many segments, which are
                                                           allow Helix to accommodate a diversity
  concurrently processed through the various phases of
                                                           of autonomous devices. The
  compilation by multiple compiler processors before a
                                                           architecture encourages a client-server
  final, merging pass recombines the object code into a
                                                           model for the structuring of
  single program”
                                                           applications”
        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
global rates of flow                          or modules but do
patterns of communication                     provide a framework,
execution control structure                   the     skeleton,     to
                                      such as: understand system-level
scalability                                   arrangements
intended paths of system evolution
          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)
          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)
               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,            In Algol data typing moved
  loops, conditional statements                          on: it was a declaration of
increasing level of abstraction                          what you intended to do
                                                         with each grouping of data
  the black box                                               Advantage: compiler then
     idea for   Further abstraction                           checked the integrity of
   subroutines occurred by introduction                       these intentions
                of modules and separation
                of module specification
                from implementation
          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
           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        “Norman”
                                                           “Gothic”
 Reuse of software is impeded
 by differences in component
                                   in a consistent
 packaging
                                   manner
            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
                                                Architectural
                                data            descriptions
                                                   may help
                                                   with these
this may well carry over into maintenance          problems
when most effort usually goes into
 ...
understanding the existing code
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
            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"
        SOFTWARE ARCHITECTURE
Gamma et al. (1995)...
                         “patterns”
            a pattern has 4 essential elements:
1. NAME - a handle we              2. PROBLEM DESCRIPTION -
can use to describe a              when to apply the pattern, its
design problem, solutions,         context, conditions or specific
and consequences in short          design problems. It might
form. Naming lets us               describe class or object
design at a high level of          structures that are symptomatic
abstraction, lets us talk          of an inflexible design.
and write about them.
        SOFTWARE ARCHITECTURE
Gamma et al. (1995)...
                         “patterns”
             a pattern has 4 essential elements:
3. SOLUTION - elements that             4. CONSEQUENCES - the
make up the design, their               results and trade-offs of
relationships, responsibilities,        applying the pattern. This is
and collaborations, but not a           critical for evaluating design
particular concrete design or           alternatives and for
implementation. It is an                understanding the costs and
abstract description of a design        benefits in terms of space
problem and how a general               and time. Reuse in O-O can
arrangements of elements                affect system flexibility,
(classes, objects) solves it.           extensibility, or portability -.
                                        needs evaluation.
        SOFTWARE ARCHITECTURE
Gamma et al. (1995)...                       “patterns”
patterns? Points of view affect one's interpretation
               of what is and what isn't a pattern
                               One person's pattern can be another
 Volkswagen, Mercedes and person's primitive building block
 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
                  SOFTWARE ARCHITECTURE
                                   “patterns”
Kimble and Selby (2000)
An interdisciplinary study of
information systems: Christopher         in IS terms a pattern is a solution to
Alexander and IS failure (Proc. UKAIS,   a software problem that has been
p256-265)
                                         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)
             SOFTWARE ARCHITECTURE
                              “patterns”
Kimble and Selby (2000)…
  Alexander’s 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.
            SOFTWARE ARCHITECTURE
                       Software organisational styles
                       batch sequential
 dataflow systems      pipes and filters

                                                main programme and sub-routine
virtual machines         call and return   systems       0 0 systems
                                                      hierarchical layers
    interpreters
ruled-based systems



data-centred systems (repositories)
                                             independent components
                 databases
              hypertext systems                  communicating processes
                blackboards                          event systems
          SOFTWARE ARCHITECTURE

                   batch sequential
dataflow systems   pipes and filters



       each component has a set of
       inputs and a set of outputs

                                       A degenerate case of
                                       pipeline architecture
  Each component reads a               occurs when each filter
  stream of data on its inputs         processes all of its
  and produces a stream of             inputs data as a single
  data on its outputs                  entity. This is the batch
                                       sequential system.
        SOFTWARE ARCHITECTURE

                   batch sequential
dataflow systems   pipes and filters



  some transformation happens


  this may be incremental:
  output may begin before
  input has ceased


       components are                  connectors are
       termed “filters”                termed “pipes”
         SOFTWARE ARCHITECTURE

                   batch sequential
dataflow systems   pipes and filters
                                       Filters must be
                                       independent entities
                                                  they should not share the
  filters do not know the
                                            =     same state as each other

  identity of the upstream
  and downstream filters
                       Specification simply restricts what
                       appears on the input pipe or guarantees
                       what appears on the output pipe

             input            filter
                                         output
        SOFTWARE ARCHITECTURE

                   batch sequential
dataflow systems   pipes and filters



     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
            SOFTWARE ARCHITECTURE

                         batch sequential
  dataflow systems       pipes and filters
                                                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
Systems are easy to maintain and enhance:
                                                 being transmitted between them
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
          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
                    SOFTWARE ARCHITECTURE
                                                            LAYERED SYSTEMS

         most widely known example
                           layered communication protocols

                                 OSI ISO model for the Internet


Open Systems Interconnect                   International Organization for Standardization
    A seven layer model of network
    architecture and a suite of protocols   A voluntary, nontreaty organisation founded in 1946,
    (a protocol stack) to implement it,     responsible for creating international standards in
    developed by ISO in 1978 as a           many areas, including computers and communications.
    framework for international
    standards in heterogeneous
    computer network architecture.
      SOFTWARE ARCHITECTURE
  OSI ISO model for the Internet      LAYERED SYSTEMS


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.
                 SOFTWARE ARCHITECTURE
                                      LAYERED SYSTEMS

    DESIRABLE PROPERTIES


                                 supports designs
                               based on increasing
                               levels of abstraction
          supports
        enhancement                                     partition problems
                                                        into a sequence of
                                                        incremental steps
changes to a layer
affects at most         supports
two other layers          reuse
                                    layers interchangeable
                                    provided they have same
                                    interfaces to adjacent layers
           SOFTWARE ARCHITECTURE
                                   Event based implicit invocation

   in implicit invocation 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 it
                                         When an event is announced, the
                                         system invokes all procedures that
                                         have been registered for the event
AN EVENT ANNOUNCEMENT IMPLICITLY
CAUSES THE INVOCATION OF
PROCEDURES IN OTHER MODULES
       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
          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
          SOFTWARE ARCHITECTURE
                                Event based implicit invocation
principles:


   announcers of events do
       not know which
                                       thus components
     components will be
                                         cannot make
   affected by those events
                                    assumptions about the
                                     order of processing

                 or even about processing
                   which will occur as a
                   result of their events
         SOFTWARE ARCHITECTURE
                                Event based implicit invocation
application examples:


  in database management
      systems to ensure
                                       in programming
   consistency constraints
                                       environments to
                                        integrate tools



              in user interfaces to separate
                presentation of data from
            applications that manage the data
           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
                                         this significantly eases the
   affecting the interfaces of other
                                           evolution of the system
      components in the system
           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          data exchange can be
 knowing there is ANY response               problematic



reasoning about correctness can
        be very difficult         since the meaning of a procedure that
                                  announces events will depend on the
                                  context of bindings in which it is invoked
         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 designer’s work

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:2/13/2012
language:
pages:36