Software Engineering Seminar

GT-SARG (Georgia Tech Software Architecture Reading Group

CS 8112 Winter Quarter 1995
Moderator: Gregory Abowd

Jan. 12: Introduction/Foundations

Discussant: Gregory Abowd

Readings

Dewayne E. Perry and Alexander L. Wolf, "Foundations for the study of software architecture," Software Engineering Notes, Vol. 17, No. 4, October 1992, pages 40-52.

David Garlan and Mary Shaw, "An introduction to software architecture," In Advances in Software Engineering and Knowledge Engineering," Volume 1, World Scientific Publishing Company, 1993.

Additional readings

None

Summary of readings

These papers were chosen because they are generally considered seminal articles in the recent emergence of software architecture as a separate field of study within software engineering. Much of what is now being documented in the software architecture literature is mainly a reflection of good high level design practices that have emerged over the past several decades. Both articles make this clear, and they both emphasize that one of the educational goals in software engineering needs to be the production of software architects,that is, practitioners who are versed in the production and use of this high-level design artifact. Though much of the work on software architecture is concerned with the process of developing an architecture (e.g., domain engineering), these articles concentrate more on the artifact itself.

Both papers begin with a motivation for why software architecture is an important field of study. Perry and Wolf draw from analogies to other architectural disciplines computer hardware architecture, computer network architecture and building architecture. Of these three potential analogies, they find the two computer analogies ineffective for motivating software architecture because they reflect practices that are not relevant to software. Building architecture is an effective analogy, emphasizing the importance of multiple views of an artifact's architecture and the importance of style to reflect formal relationships between architectural components and how they are engineered to exploit the properties of their constituent materials. Garlan and Shaw point to the growing size and complexity of software systems, noting that advances in computer science have come as the result of increasingly powerful abstractions up from machine code through high level programming languages. The natural progression of this tendency to abstract is the software architectural level consisting of the gross organization of computing components and their global control and data relationships or connections. They agree, roughly speaking, on the building blocks of an architecture. Both identify computation and data storage elements (both referred to with the generic term components by Garlan and Shaw). Both also highlight the importance of connection as a first-class architectural building block or glue, and they concede that this connection can be "implemented" by means of either processing or data elements (or both). They both identify style as a means of identifying common architectural characteristics of various systems. Perry and Wolf refer to style as an abstraction from a single architectural instance to a more generic reference model for a class of systems. Garlan and Shaw look to common idioms or patterns of architectural descriptions to identify important emergent styles of description (e.g., pipe-filter, data abstraction, event-based, etc.).

Both papers rely on the use of case studies as paradigms to further the understanding of software architecture. The compiler example is used by both and is the only case study examined by Perry and Wolf. Perry and Wolf use the compiler to demonstrate the duality between processing and data views. They use the connection view to demonstrate how significant differences between a batch sequential compiler and an incremental one can be revealed. Garlan and Shaw provide several other case studies, each one serving to highlight another important feature of architecture (KWIC for the comparison of different architectural alternatives, oscilloscope for the match between style and development, compiler for evolution of architectural emphasis from computation to data, process control and expert systems for heterogeneous architectural descriptions, and a speech recognition system to show how style can simplify architectural descriptions) The papers then diverge. Perry and Wolf concentrate on describing a generalized model of software architecture, whereas Garlan and Shaw present more of a catalogue of interesting architectural idioms.

The major difference between the papers is that the Perry and Wolf work is a much more general attempt to define an architectural model, whereas the Garlan and Shaw work is more taxonomic and less analytic in its intention.

Summary of disccussion

The Perry and Wolf paper seemed to spur more discussion within the group. There seems to be two reasons for this. First, Perry and Wolf tries to draw analogies to other computing and non-computing disciplines and these kinds of analogies (especially the non-computing ones) tend to provoke much discussion amongst software engineers. There was a general agreement that building architecture provides some useful insights into what we should expect out of a mature software architectural profession. But it is also clear that a lot of time can be wasted taking this kind of analogy too seriously. Perry and Wolf demonstrate great judgment in limiting their analogy throughout the paper. Some of the points that provided the most agreement were:

the notion of "load-bearing" information in an architectural description;
drift and erosion as results of evolution;
effective exploitation of the properties of the building blocks in architectural composition

Some points of greater contention were:

the meaning and utility of the concept of style in building architecture and the use of software architectural style in both papers;
the usefulness of the building analogy with respect to maintenance and life cycle issues;
whether building architecture's neglect for interior design considerations is similar or dissimilar to the amount of detail needed in a software architecture; and
whether software structure has more or less variability that building designs.

The second reason Perry and Wolf was more discussed than the Garlan and Shaw paper is because the latter is a straightforward catalogue of different styles and case studies, without much of an attempt to divulge a general model. Thus, you can read Garlan and Shaw, and it is informative but not so thought provoking. Perry and Wolf, on the other hand, in attempting to provide a general model of software architecture, provide a lot more issues up front that can be discussed at a general level across all architectural instances. This is both a blessing and a curse. It promotes discussion, but that discussion can sometimes degenerate into an abstract war of words. Garlan and Shaw is a straightforward compilation and reference book, the beginnings of an architectural handbook. Its utility is not so much in the discussion it provokes, but in the history it attempts to document and codify. Terminology is a double-edged sword. We need it to proceed with a common understanding, but arriving at an accepted lexicon is frequently an arduous and time-consuing task, especially when done by committee. I will not attempt at this point to produce a definitive lexicon for future use by this group, but I will point out some emerging distinctions. Architecture as a term can refer to several things. It can refer to a profession and its practitioners, such as building architecture. It can refer to a single instance of an artifact, such as the architecture of the College of Computing. It can refer to a collection of similar instances, such as the Gothic or Baroque Rococo architecture. A software architecture has both static and dynamic characteristics. Garlan and Shaw emphasized the static features of an architecture (the configuration of components and connectors), whereas Perry and Wolf demonstrated the need to consider dynamic time-varying properties of architectures in order to make important distinctions (batch vs. incremental multi-phase compiler). An architecture reveals important non-functional features of an artifact. Pretty much any architectural configuration can be used to address a set of functional requirements, but when considerations such as modifiability, performance, security, etc. come into play, architectural decisions are frequently critical.