Software Architecture - PowerPoint

							            Software Architecture

Software Architecture - both a discipline
of design, and a representation of design. Some key
points from Perry and Wolf [PW92] are:
• architecture is a discipline with standards, codified styles
 and education
• architecture captures important high-level concepts
 in a system which must be preserved, and which
 make global assertions about the system
• multiple views are needed to express an architecture
• strong analogies are made between the notions of
 "style" in software and classical architecture
6/25/2012               Software Architecture              1
                   The Effects of Size

                            Can be built by one person
                            Requires
                               - Minimal modeling
                               - Simple process
                               - Simple tools


Can only be built by many                         Built most efficiently and timely
   teams (i.e.companies)                              by a team
Requires                                          Requires
   - Extensive modeling                               - Modeling
   - Complex “need to                                 - Well-defined process
     define” process                                  - Power tools
   - Multitude of tools
     6/25/2012                   Software Architecture                          2
              Software Architecture as a
                  Maturing Discipline

A key attribute of a mature engineering discipline is the
routine use of existing solutions in the development of new
systems.

Designs are institutionalized by inclusion in handbooks,
technical publications, and corporate standards.
Corporate design standards usually limit usage, due to their
proprietary nature and the scope of their intended application.
These methods of dissemination lead to high levels of design
reuse.


  6/25/2012              Software Architecture             3
            Classical Building Architecture Analogy


Points of commonality:
• notations and representations (building: blueprints, physical models,
  perspective drawings; software: structural graphics, coupled with
  behavioral and informational views)
• architectural styles (building: Romanesque, Gothic, Victorian;
  software: distributed, layered, client/server)
• constraints (building: acoustics, air/water flow, lighting;
  software: throughput, timing, fault tolerance, ease of use)
• standards/practices (building: building codes & inspections;
  software: interface standards & walk-throughs/reviews)

6/25/2012                   Software Architecture                   4
        What is Software Architecture?
• Software architecture encompasses the set of
  significant decisions about the organization of a
  software system
   – selection of the structural elements and their
     interfaces by which a system is composed
   – behavior as specified in collaborations among
     those elements
   – composition of these structural and behavioral
     elements into larger subsystem
   – architectural style that guides this organization
  6/25/2012           Software Architecture         5
  Chemical (Unit Process) Architecture
                Analogy
Points of commonality
 • components (chemical: unit operations [e.g., heat exchanger];
   software: architectural components [e.g., DBMS])
 • connectors (chemical: pipes, conveyors; software: procedure calls,
   pipes)
 • architectural styles (chemical: operation [e.g., batch, continuous];
   software: topological styles [e.g., pipe & filter, blackboard])
 • constraints (chemical: precedence of elements in a process;
   software: precedence of elements in an execution sequence)
 • notation (chemical: process flowcharts; software: ADLs)
 • product (chemical: chemical plant; software: application system)
 6/25/2012                    Software Architecture                       6
                Fundamentals

  Architecture should establish a common vision of the
  project/product development. Acts as glue:




     Conceptual                               Relatively formal
    models of the                             models that are
     application                                the basis for
       domain                                 implementation

6/25/2012             Software Architecture                       7
               Architectural Specification Goals

• prescribe the architectural constraints - using the
  principle of least constraint.
• separate esthetics from engineering - identify the
  decoration from the load bearing elements
• provide multiple views of the structure - both context
  and components
• determine dependencies among elements & check consistency
    Want to avoid:
    • architectural erosions - violations of the architecture
    • architectural drift - insensitivity to the architecture
    • brittleness
   6/25/2012                Software Architecture               8
            Where it Fits . . .




6/25/2012        Software Architecture   9
            S/W Architecture Terminology

Software Architecture is (a sampling of definitions)...
• components + connectors; a family of architectures + constraints
  defines an architectural style or idiom (Garlan & Shaw [GS93])
• elements + form + rationale, where an element is composed of
  components and connectors (Perry & Wolf [PW92])
• fundamental structural attributes of a software system
   (Saunders et al [SHM])
• components + idioms/styles + common patterns of interaction
  between functional components; architecture identifies common
  design information that addresses the requirements of a family of
  similar products (Vestal [Ves93])
• elements + interfaces + connections + connection semantics
  (CFRP 3.2.1.2 [STARS93])
6/25/2012                  Software Architecture                 10
                  Taxonomy of Styles
Shaw and Garlan[‘96] define architecture in terms of design elements
and the constraints on the elements, but differ from Perry and Wolf in that
the elements are:
• components and connectors, described in some idiom specific manner.
Idioms are represented as topologies of the component/connector
vocabulary, along with constraints on how the topologies can be arranged.


        Shaw and Garlan have developed a taxonomy based on
        case studies of actual systems. The eventual goal is to
        develop a handbook for the selection and application of
        appropriate styles.



   6/25/2012                   Software Architecture                   11
Architecture = Elements + Form + Rationale

Elements are:
• components (data)
• connections (bindings between components)
• control and processing (threads of execution)
Connections are as important as components as they determine how the
pieces fit together, if at all. For example, can a procedure call a pipe, or a
pipe access a file, or call-backs occur between processes?

Form is:
• properties - desired constraints on elements
• relationships - placement of architectural elements
These are weighted to indicate importance (load bearing vs. decoration).
Rationale is the motivation for the choices made in defining the
architecture (especially as to how it satisfies the system requirements).
  6/25/2012                     Software Architecture                    12
            Shaw & Garlan Taxonomy




6/25/2012           Software Architecture   13
              Common Architecture Styles
Data Flow style:
• Batch Sequential - each step runs to completion; old style data
  processing architecture
• Pipes and Filters - linked stream transformers
  Each filter is a stand-alone process that incrementally transforms its
  input streams into output streams.

Call and Return style:
• Main program and subroutines - traditional functional decomposition,
  a controlling main program determines flow of control
• Hierarchical layers - well defined interfaces and information
  hiding (e.g., kernels, shells)

Object-oriented systems - abstract data types with inheritance;
  objects only interact through defined interfaces

  6/25/2012                   Software Architecture                   14
              Common Architecture Styles

Independent Components style:
• Communicating processes - asynchronous message passing
• Event systems - implicit invocation; rather than invoking a procedure
  directly, a component generates a request for service event that is
  broadcast

Virtual Machines style:
• Interpreters - input driven state machine
• Rule-based systems - rule based interpreter

Data-centered systems:
• Transactional Database Systems - central data repository/query driven
• Blackboards - central shared representation/opportunistic execution

  6/25/2012                  Software Architecture                  15
              Common Architecture Styles


Distributed Processes and Client/Servers
Processes connected by a specific communication topology
(ring, star, etc.) along with protocols for communication.
Servers don't know their clients beforehand, while clients can
dynamically chose among servers. Client-server interactions can be

• direct - where the client activates the server directly (for example by
  calling the server as a procedure)
• polled - where the client indicates that it would like a service and
  the server periodically checks to see if any client requests are pending.
• interrupt driven - where the server is dormant, and the client
  generates an event that eventually activates the server.


  6/25/2012                    Software Architecture                   16
     Common Architecture Styles
Model, View, Controller
Typical paradigm of user interface design. The underlying element is
modeled by some object. Various representations of this object are
presented through views. Alterations of the state of the object are
achieved through controllers.

State Transition Systems
• Standard design of many reactive systems.

Process Control Systems
• Dynamic control via feedback loops.

Heterogeneous

6/25/2012                   Software Architecture                 17
     Process Control Systems Architecture




     Inputs          Control                  Outputs
                    Equations
   (monitor                                (set control
   pressure &                              valves and
   temperature)                            pumping rates)
                     Control
                    Feedback


6/25/2012          Software Architecture            18
              Combining Styles
Systems are not usually developed according to a single ,
consistent idiom. Variations may occur at different levels
of refinement/abstraction.




6/25/2012              Software Architecture            19
             Reference Architectures
Architectural idioms need not be constrained to usage
within system development. They can also serve
as tools for the analysis of system design. For example,
a natural language processing system viewed through the
interpreter and blackboard idioms.




 6/25/2012             Software Architecture          20
     4+1 View Model of Architecture

   • Organizes a description of software architecture using five
     concurrent views.
   • Architects capture their design decisions in four views and
     use the fifth to illustrate and validate the other four.




6/25/2012                   Software Architecture                  21
                     The 4 Views
 The logical view describes the design's object model when an
  object-oriented design method is used. To design an application
  that is very data-driven, you can use an alternative approach to
  develop some other form of logical view, such as an
  entity-relationship diagram. [Use UML Class Diagram]
 The process view describes the design's concurrency and
  synchronization aspects. [Use UML Collaboration Diagram/
  Sequence Diagram]
 The development view describes the software's static organization
  in its development environment. [Use UML Component Diagram]
 The physical view describes the mapping of the software onto the
  hardware and reflects its distributed aspect. [No UML Counterpart]


6/25/2012                  Software Architecture                     22
            Logical View




6/25/2012     Software Architecture   23
            Process View




6/25/2012      Software Architecture   24
            Development View




6/25/2012        Software Architecture   25
            Physical View




6/25/2012      Software Architecture   26
            Scenarios - Dimension 5




6/25/2012           Software Architecture   27
          Mappings Between Views



Mapping from the logical
      to the process view




  6/25/2012                 Software Architecture   28