Perspective on Software Architecture

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?

OUTLINE

Architecture in the Life-Cycle

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)
Customer
Concern

User
Concern

Architect
Concern

Developer
Concern

Maintainer
Concern From Gacek, Abd-Allah, Clark, & Boehm (p. 7)

"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)

"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)

Software Architecture

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)

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.

Shaw, DeLine, Klein, Ross, Young, & Zelesnik
The architecture of a software system defines that system in terms of components and 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.

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.

Software Architecture = {Elements, Form, Rationale}

Architectural Elements

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.

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.)

Architectural Style

If architecture is a formal arrangement of architectural elements, then architectural style is that which abstracts elements and formal aspects from various specific architectures. An architectural style is less constrained and less complete than a specific architecture.

view the collection of conventions that are used to interpret a description as defining an architectural style.

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.

Pipes and Filters Style

Description

A common way to structure a program that basically transforms data is to divide it into a collection of computations where each computation is an incremental transformation of the data. These transformation are combined so that outputs of certain transformations serve as inputs to other. The entire application is then the composition of these computations/transformations. Systems of this type are referred to as coarse-grained dataflow or pipe-filter systems.

Pipes Example

Characteristics

Components

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.

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.

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.

    Constraints

    Advantages

    Disadvantages

    Unix Pipes and Filters

    A filter is a program that modifies or transforms its input in order to obtain its output. Filters read its input from standard input and writes it to standard output.

    grep <someregularexpression> /usr/dict/word | sort | less

    Layered Style

    Agent Layer
    (from Sycara's Pleiades System)

    Benefits

    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.

    Go To Lecture [Outline] [Overview]

    Go To [Course Outline]

    References

    Abowd, G., R. Allen, & D. Garlan (1993) Using Style to Understand Descriptions of Software Architecture.

    Fairley, R. (1985) Software Engineering Concepts. McGraw-Hill.

    Gacek, C., A. Abd-Allah, B. Clark, and B. Boehm (1994) Focused Workshop on Software Architectures: Issue Paper. USC-CSE-94-499. Univeristy of Southern California, Center for Software Engineering.

    Garlan, D. & M. Shaw (1993) An Introduction to Software Architecture. In V. Ambriola, & G. Tortora (eds.), Advances in Software and Knowledge Engineering. New Jersey: World Scientific Publishing Co.

    Perry, D. E. and A. L. Wolf (1992) Foundations for the Study of Software Architecture. Software Engineering Notes, 17(4), P. 40-52.

    Schwanke, R. W., R. Z. Altucher, & M. A. Platoff (1989) Discovering, Visualizing, and Controlling Software Structure. SIGSOFT Engineering Notes, 14, p. 147-150.

    Shaw, M., R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, & G. Zelesnik (????) Abstractions for Software Architecture and the Tools to Support Them.

    Witt, B. I., F. T. Baker, & E. W. Merritt (1994) Software Architecture and Design. Van Nostrand Reinhold.