Perspectives in Software Architecture

1
Perspectives in Software Architecture
2
Overview

• To frame our discussion, consider
• Where do software architecture considerations fit
  in the life-Cycle?
• Why a focus on software architecture?
• What is the state of theory and practice in
  software architecture?

3
Outline

• Architecture in the Life-Cycle
• Software Architecture
• Elements, Form, Rationale
• Architectural Style
• Benefits

4
Architecture in the Life-Cycle (1)

• Views of a Software System
• "An important objective of software
  architecture is the production of a consistent
  set of views of the system and its parts
  presented in a structure that satisfies the needs
  of both the end-user and later designers."(Witt
  et al., p. 2)

5
Architecture in the Life-Cycle (2)

• Customer
• Concern
• Schedule and budget estimation
• Feasibility and risk assessment
• Requirements Traceability
• Progress Tracking

6
Architecture in the Life-Cycle (3)

• User
• Concern
• Consistency with requirements and
  usage scenarios
• Future requirement growth accommodation
• Performance, reliability,
  interoperability,
• etc.

7
Architecture in the Life-Cycle (4)

• Architect
• Concern
• Requirements Traceability
• Support of tradeoff analyses
• Completeness, consistency of
• architecture

8
Architecture in the Life-Cycle (5)

• Developer
• Concern
• Sufficient detail for design
• Reference for selecting/assembling
  components
• Maintain interoperability with
  existing systems

9
Architecture in the Life-Cycle (6)

• Maintainer
• Concern
• Guidance on software modification
• Guidance on architecture evolution
• Maintain interoperability with
  existing systems

10

• "architecture is concerned with the selection of
  architectural elements, their interactions, and
  the constraints on those elements and the
  interactions necessary to provide a framework in
  which to satisfy the requirements and serve as a
  basis for the design."(Perry and Wolf, p. 43)

11

• "At least three levels of design specifications
  exist external design specifications, which
  describe the external characteristics of a
  software system architectural design
  specifications, which describe the structure of
  the system and detailed design specifications,
  which describe the control flow, data
  representation, and other algorithmic details
  within the modules." (Fairley, p. 152)

12
Software Architecture (1)

• From Perry and Wolf
• Software Architecture Elements, Form,
  Rationale
• From Garlan Shaw
• an architecture is a collection of
  computational components together with a
  description of the interactions between these
  components (the connectors)

13
Software Architecture (2)

• Abowd, Allen, Garlan
• At the software architectural level of
  abstraction, a system is typically described as a
  collection of interacting components. Components
  perform the primary computations of the system.
  Interactions between components include high
  level communication abstractions such as pipes,
  procedure calls, message passing, and event
  broadcast.

14
Software Architecture (3)

• Shaw, et al.
• The architecture of a software system defines
  that system in terms of componentsand
  interactions among those components. In addition
  to specifying the structure and topology of the
  system, the architecture shows the correspondence
  between the system requirements and elements of
  the constructed system. It addresses system-level
  properties such as capacity, throughput,
  consistency, and component compatibility.
  Architectural models clarify structural and
  semantic differences among components and
  interactions.

15
Software Architecture (4)

• Schwanke, Altucher, Platoff
• architecture is used to refer to the
  structural aspects of the program and not its
  function. The structure of a program is the set
  of connections between software units. The
  architecture is a set of allowed connections.

16
Thought Example (1)

• We are developing a city information system
  running on a wide-area network. Computers on the
  network host service that maintain information
  about aspects of the city. People access the
  information from public kiosks or their desk-top
  computers using a web-browser.

17
Thought Example (2)

• The system should evolve over time as new
  services are added and old services are modified
  or removed. Client software should access
  services without know their location. This
  provides the flexibility of moving, replicating,
  adding, or migrating services.

18
Thought Example (3)

• This is a distributed environment of possibly
  heterogeneous systems with independent
  components.
• This requires a structure that is flexible,
  maintainable, changeable, and scalable.

19
Software Architecture Elements, Form,
Rationale

• Architectural Elements
• processing elements are those components that
  supply the transformation on the data elements.
• Data elements are those that contain the
  information that is used and transformed
• Connecting elements (which at times may be
  either processing or data elements, or both) are
  the glue that holds the different pieces of the
  architecture together.

20
Software Architecture Elements, Form,
Rationale

• Architectural Form
• Consists of weighted properties and
  relationships. The weighting indicates one of two
  things either the importance of the property or
  the relationship, or the necessity of selecting
  among alternatives, some of which may be
  preferred over others.
• Properties are used to constrain the choice of
  architectural elements - that is, the properties
  are used to define constraints on the elements to
  the degree desired by the architect. Properties
  define the minimum desired constraints unless
  otherwise stated.
• Relationships are used to constrain the
  "placement" of architectural elements - that is,
  they constrain how the different elements may
  interact and how they are organized with respect
  to each other in the architecture.

21
Software Architecture Elements, Form,
Rationale

• Rationale
• The rationale captures the motivation for the
  choice of architectural style, the choice of
  elements, and the form. The rationale explicates
  the satisfaction of the system constraints. (This
  would include functional and non-functional
  aspects.)

22
Architectural Style (1)

• architectural style is that which abstracts
  elements and formal aspects from various specific
  architectures.

23
Architectural Style (2)

• Architectural styles determine three kinds of
  properties -
• 1. They provide a vocabulary of design elements
• 2. They define a set of configuration rules or
  topological constraints that determine permitted
  compositions of those elements.
• 3. They define a semantic interpretation, whereby
  compositions of design elements, suitably
  constrained by the configuration rules, have
  well-defined meanings.

24
Problem Context (1)

• You are building a system that must process or
  transform a stream of data. The system has to be
  built by several developers, the overall system
  decomposes into several processes, and the
  requirements are likely to change.

25
Problem Context (2)

• Future enhancements are likely through changing
  individual processes.
• Non-adjacent processes do not share information.
• There are different sources of input information.
• It may be possible to support multiple processors.

26
Pipes and Filters (1)

• An entire application is the composition of
  computations.
• Each computation is an incremental transformation
  of the data. These transformation are combined so
  that outputs of certain transformations serve as
  inputs to other.

27
Pipes and Filters (2)

• Filter
• Transform streams of data. Each filter has input
  ports, from which it reads data, and output
  ports, to which it writes results. A filter
  performs its computation incrementally and
  locally A single computational step consists of
  reading a portion of the data from its input
  port, transforming that data, and writing the
  result to the output port.

28
Pipes and Filters (3)

• Pipe
• Pipes are the connectors of the system. Pipes
  control the flow of data through the system. Each
  pipe links an output port to an input port,
  indicating the path that data will take and
  carrying out the transmission.

29
Pipes and Filters (4)

• A computation step in a pipe-filter system
  consists of either
• an incremental transformation of data by a
  filter, or
• a communication of the data between ports by a
  pipe.

30
Pipes and Filters (5)

• Constraints
• Filters must be independent entities, they should
  not share state with other filters.
• Filters do not know the identity of upstream or
  downstream filters. Their specification might
  restrict what appears on the input pipes or make
  guarantees about what appears on output ports,
  but they may not identify the components at the
  ends of those pipes.

31
Pipes and Filters (6)

• Advantages
• They allow the designer to understand the overall
  I/O behavior of a system as a simple composition
  of individual behaviors.
• They support reuse.
• Systems can be easily maintained and enhanced.
• They permit certain kinds of specialized
  analysis.
• They support concurrent execution.

32
Pipes and Filters (7)

• Disadvantages
• Lead to batch sequential thinking. Designers tend
  to think of filters as providing a complete
  transformation of input prior to the activation
  of the next filter.
• Typically are not good representation for
  interactive applications.
• Parallel processing is sometimes an illusion.
• Error handling is difficult.

33
Example (compiler)
Program Text
Lexical Analysis/Scanner
Token stream
Syntax Analysis/Parser
Abstract Syntax Tree
Semantic Analysis
Augmented Syntax Tree
Code generation
Program
Optimization
34
Problem Context (1)

• You are designing a system which contains both
  high- and low-level issues. Furthermore the
  high-level issues depend on the low-level ones.
  Low-level issues would include hardware traps,
  sensor input, and bit streams from files. The
  high-level is represented as user-level
  functionality.

35
Problem Context (2)

• Portability is required.
• The work has to be distributed to a number of
  project teams.
• Parts of the system should be replaced as
  alternative implementations arise.

36
Layered Style (1)
The layered style helps structure applications
where there is an apparent collection of tasks at
different levels. The mix of low and high level
tasks rely on one another for the completion of a
higher level task.
37
Layered Style (2)

• Applications such as these may also require both
  horizontal and vertical structuring.

38
Advantages

• They support designs based on increasing levels
  of abstraction.
• They support reuse.
• Systems can be easily maintained and enhanced.

39
Disadvantages

• Not all systems can be structured as a layered
  system.
• Performance considerations may make it difficult
  to separate high and low level functions.

40
Layered Style Example
41
Problem Context

• There are different solutions to different
  partial problems.
• There are different representations for data
  during processing.
• An algorithm usually works on the results of
  other algorithms.
• Approximate solutions are involved.

42
Blackboard Style (1)

• The blackboard architecture is a collection of
  independent programs working cooperatively on a
  common data structure.

43
Blackboard Style (2)

• The system is divided into components
• A blackboard - a central data store
• Knowledge Sources - independent subsystems that
  solve different aspects of the problem.
• Control - monitors the changes in the
  blackboard and decides what actions to take. This
  includes notifying knowledge sources of change.

44
Benefits of Architectural View

• 1. Provides a framework within which to satisfy
  the requirements.
• 2. Provides both the technical and managerial
  basis for the design and implementation of the
  system.
• 3. Supports analysis of the consistency of the
  architecture with the requirements.
• 4. Supports analysis of the consistency of the
  design with the architecture.
• 5. Design or architectural reuse.

45
Caveat

• Architecture should be driven by the properties
  of the application being developed.
• Architecture helps you achieve global system
  properties.
• Most systems cannot be structured according to
  one particular architectural style.

46
Design Patterns

• A design pattern is a recurring structure of
  components that solves a general design problem.
• Christopher Alexander A Timeless way of building

47
Description

• Context
• the situation giving rise to a design problem
• Problem
• the problem arising from the situation
• Solution
• a proven solution to that problem

48
Proxy Pattern

• Context
• A client needs services from another component.
  Direct access may not be appropriate.
• Problem
• We do not want to hard-code access due to
  inefficient or insecure.
• Solution
• The client communicates with a representative of
  the component.

49
Reference

• Erich Gamma, Richard Helm, Ralph Johnson, and
  John Vlissides
• Design Patterns Elements of Reusable
  Object-Oriented Software.